[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