C++ code compiles but dies problem (Having a line (queue), a buffer, and if not empty problem)

So I have a class. .h file with some variables like:

  struct AudioSample
  { 
    const unsigned char * buffer;
      int len;
  };
        //...
      const unsigned char * VideoFrameBuffer;
      int VideoFrameLen;


  std::queue<AudioSample> AudioSamples;


  bool sampleSendingFinished;
  bool frameSendingFinished;
      //...

And .CPP file with functions

void VideoEncoder::UrlWriteData()
{
    while(1){
        if (AudioSamples.empty() && VideoFrameBuffer == NULL)
        {
            Sleep(1);
        }
        else if(!AudioSamples.empty())
        {
            struct AudioSample newAudioSample = AudioSamples.front();
            url_write (url_context, (unsigned char *)newAudioSample.buffer, newAudioSample.len);
        }
        else if (AudioSamples.empty() && VideoFrameBuffer != NULL)
        {
            url_write (url_context, (unsigned char *)VideoFrameBuffer, VideoFrameLen);
        }
    }

}
void VideoEncoder::AddSampleToQueue(const unsigned char *buf, int size )
{

    struct AudioSample newAudioSample;
    newAudioSample.buffer = buf;
    newAudioSample.len = size;
    AudioSamples.push(newAudioSample);
}
void VideoEncoder::AddFrameToQueue(const unsigned char *buf, int size )
{
    VideoFrameBuffer = buf;
    VideoFrameLen = size;
}

once in a while some functions call AddFrameToQueue and AddSampleToQueue. UrlWriteData lives in separete thread. My app compiles. But my problem is - when I run it it dies on line:

    开发者_开发百科    else if(!AudioSamples.empty())
        {
            struct AudioSample newAudioSample = AudioSamples.front();

Why it dies and how to make it not die?

There is a thread-safe producer-consumer queue using soon-to-be standard threading mechanisms here. This would be a good intro to the threading concepts you have to understand to make this design work.

The producer(s) are the functions that add to your queue, and the consumer(s) are the function(s) that read and (usually) process queue entries - UrlWriteData, here.

I believe you're a newbie, you've cut + copied this code from somewhere, stripping all the unnecessary things from it, until it compiled. And now you're curious why doesn't this work. Am I right?

Well, just a preliminary list of problems, without too much digging into details:

1. Multit-hreaded applications usually need sine synchronization mechanisms when accessing the same data from different threads. Such as critical sections, mutexes and etc. Or at least interlocked (lock-free) operations and/or memory barriers. I don't see anything like this in your code.
2. In your particular case the AudioSamples is a complex object which is operated from multiple threads. It must be guarded by critical section (or similar).
3. Same regarding setting/querying VideoFrameBuffer and VideoFrameLen.
4. After you take the next audio sample - you should take it out from the queue (call pop_front).
5. Both your "audio sample" and "video frame" data members contain just pointers to the actual data. It's unclear from your design (if there was such) - who has the "ownership" of the allocated memory. In simple words - who should free the allocated memory.

Have you traced what line is failing? Where is it dying? How is the memory of your buf managed? Is your code synchronised? (By the way it appears that FFmpeg library has been patched and url_write is now const-correct. You ideally should use const_cast if that is not the case rather than a C cast although some would say that is style).

As a general comment on your code:

• Polling has its advantages (you can, at this point, handle multiple queue items) but I'm not sure if it is what you want here. You may well wish to use some kind of block/wait system. If this is Windows it is done by WaitForSingleObject and similar kind of calls. On UNIX you may either pthread_cond_wait or select to cause the block. The thread will then be woken up when it has something to process.