[Ffmpeg-devel] mpeg transport streams
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
> 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?
mru at inprovide.com
More information about the ffmpeg-devel