[Ffmpeg-devel] mpeg transport streams

[Zoltan NAGY]

M?ns Rullg?rd wrote:

>Luca Abeni <lucabe72 at email.it> writes:
>
>  
>
>>Hi M?ns,
>>
>>On Fri, 2005-05-27 at 13:06, M?ns Rullg?rd wrote:
>>    
>>
>>>Luca Abeni <lucabe72 at email.it> writes:
>>>
>>>      
>>>
>>>>>Once the PCR is there (the patch adds it apparently) it might be good 
>>>>>enough (tm)
>>>>>          
>>>>>
>>>>I do not think so... In my experience, even if the PCR field is
>>>>correctly filled the mpegts muxer will still produce streams that cause
>>>>buffer overruns/underruns in most set-top-boxes (this problem is not
>>>>visible using a software player, because it generally has larger
>>>>buffer).
>>>>        
>>>>
>>>At least one STB I've used ignores the PCR entirely.
>>>      
>>>
>>This is not so uncommon... I have some DVB-T set-top-boxes at work, and
>>some time ago I used a DVB-T local loop to test the TS generated by
>>ffmpeg... It turned out that about 50% of the receivers did not care
>>about the PCR (!!!). 
>>    
>>
>
>I'm talking about IP STBs, but I suppose they use pretty much the same
>decoder chips internally.
>
>  
>
>>>Instead it has another peculiarity.  I requires the video stream to
>>>be about 100 ms ahead of the audio
>>>      
>>>
>>Yes this is the big problem... My understanding is that the amount of
>>data that the decoder has to buffer is proportional to the difference
>>between the audio and the video pts (if we want to play audio and video
>>in synch, of course).
>>    
>>
>
>Yes, it will obviously have to buffer any data that arrives too early.
>
>  
>
>>So, if this difference is too big the decoder will experience a
>>buffer overflow and skip some video frames (if it uses the audio
>>clock as master clock), disable the audio, or show some audio/video
>>artifacts. (if the decoder really uses the PCR, what matters is the
>>difference between pts and PCR). In my experience, the "100ms" value
>>depends on the video and audio bitrate.
>>    
>>
>
>100 ms is 2.5 or 3 frames (depending on video system).  My guess is
>that the audio needs to be delayed just enough to allow the video to
>be decoded with B frame reordering.  I did some experiments with an
>STB based on an IBM chip, using MPEG2 MP at ML video of 5Mbps, and 224
>kbps MPEG layer 2 audio.  Without B frames, I could set the delay as
>low as 40 ms before it started acting up.  In the other direction,
>the picture started getting artifacts somewhere around 150 ms.
>
>  
>
>>>BTW, how are other TS muxers faring these days?  Has anyone tried VLC
>>>recently?
>>>      
>>>
>>I just quickly tried it some weeks ago, but a philips DTR6600 DVB-T
>>receiver did not like the generated TS.
>>    
>>
>
>VLC 0.7 was terrible at TS muxing.  0.8 seems to be a bit better, but
>I haven't tested it thoroughly, hence the question.
>  
>
latest SVN version of VLC is quite nice...
only that it's mpegts is not exactly rfc-compliant if you pack mpeg4 
inside..

Regards,

--
Zoltan NAGY,
Software Engineer