[Ffmpeg-devel] mpeg transport streams

Måns Rullgård mru
Fri May 27 15:01:36 CEST 2005

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

More information about the ffmpeg-devel mailing list