[Live-devel] doGetNextFrame() timing in mpeg2ts context

[Horst Weglanz]

Hello

I have a question regarding whether I use liveMedia or mpeg2ts correctly or not. I want to mux video frames to mpeg2ts, since I needed another interface than the once already included, I build my own *MySource* derived from *FramedSource*. In there is the appropriate *doGetNextFrame()* method to process a new frame - this is already working, but I was wondering whether or not correctly. In there I do something like:

| if ( isFrameAvailable() )
| {
|    processFrame();
| }
| else
| {
|    usleep(10);
|    nextTask() = envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSource::afterGetting, this);
| }

So even if no data is available at the moment the new *afterGetting(this)* task is scheduled (same thing happens in *processFrame()*) and I've noticed that mpeg2ts frames are written to the output even if no data is coming in. Is this correctly? Does an mpeg2ts stream need some sort of null-frames to keep up some sort of clock cycle? And I was wondering about the sleep I put in there since I've seen it in some example. Does the scheduler call *doGetNextFrame()* according to the desired frames per second or instantly when he has finished this task and there is a new one waiting (like always when going through this method). Which means every time *doNextFrame()* is called regardless of data is available or not at least one mpeg2ts frame is created and (if this is called independent of the FPS rate) the amount of null frames depends on the amount of time I sleep in this function? Or is the concept of null frames total incorrect and I'm doing something wrong
 here?

Hope someone can shed a bit of light on this, since I haven't found any answers on this, thank you very much.
HW