[Ffmpeg-devel] mpeg transport streams

[Måns Rullgård]

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.

> Instead, if I use ffmpeg + the mpegtsenc patches (ermmm... hacks :) that
> I sent to the list about 1 year ago and I add the PCR (based on real
> time) before sending the TS in the DVB-T local loop, most of the DVB-T
> receivers I tried are quite happy :).

I recall reading something like that.

There are two things I keep wondering: 1) why did they make the
standard so difficult to follow, and 2) why are some products so picky
with what they tolerate?

-- 
M?ns Rullg?rd
mru at inprovide.com