[FFmpeg-devel] [bug/patch] MPEG-TS muxer: PCR not in sync withPTS/DTS
Mike Scheutzow
scheutzow
Tue Oct 20 17:27:35 CEST 2009
Alexandre Ferrieux wrote:
>>>
>>> ffmpeg.r20212vbr -i file.wav -vn -ar 44100 file.ts
>>>
>> ...
>> Could you try this regression between the unpatched ffmpeg and the
>> version 4?
>
> Yes. Results below (20212 == unpatched) for the stereo file (ab) above:
>
> ab.20212.ts: delta PCR == 342432 -> very jerky
> ab.20212vbr.ts: delta PCR == 19890 -> no sound
> ab.19754vbr.ts: delta PCR == 182975 -> perfect
>
> -Alex
Alex,
It looks to me like the the first entry ("very jerky") is the closest to
being correct. If the clip is 4.8 seconds, it should give a delta of
about 430000 (= 4.8 * 90000).
Niobos,
I've been testing your patch, and see two major problems with the
transport stream that is created by ffmpeg.
1) The first problem (which you did not cause) is that
st->codec->bit_rate is 0 for some streams. This means the container
bitrate estimate is completely wrong, and therefore the PCR values
inserted are completely wrong.
In my local copy of the code, I hard-fail if st->codec->bit_rate is 0,
and suggest that the user use '-muxrate n' to specify the container bitrate.
2) The second problem (which may be what is happening above) is that PCR
output gets priority over null-packet insertion. This causes PES packets
on the pcr_pid to have a (DTS-PCR) much, much bigger than it should be.
Effectively, ts->max_delay is ignored.
My solution was to check for this case, and generate pcr_pid packets
with no pes payload (i.e. the adaptation_field_length is 183.)
Thanks for your efforts on the mpeg muxer.
--
Mike Scheutzow
scheutzow at alcatel-lucent.com
More information about the ffmpeg-devel
mailing list