[Ffmpeg-devel] Bug in pts computation in compute_pkt_fields() ?
Måns Rullgård
mans
Tue Mar 20 18:34:21 CET 2007
Martin Wache said:
> Wolfram Gloger schrieb:
>> Hi,
>>
>>> I'm experiencing problems with the pts values of the audio packets given
>>> by av_read_frame(). The stream I feed to ffmpeg is a DVB-T stream mpeg2
>>> audio and video.
>>
>> That is probably raw mpeg-ts, right?
>>
> No, it is already remuxed to pes.
Are you aware that a PES stream may only consist of one elementary stream?
Files such as those produced by VDR are not conforming to specs.
>>> I'm not sure if it is just me getting the interface right, so I did some
>>> debugging, and here is what I found:
>>> First, I get audio frames without pts, the result is that st->cur_dts is
>>> set to 0 and starts to grow according to the length of the audio, which
>>> is fine. But as soon as I get a packet with pts, everything gets messed
>>> up by the lines
>>>
>>> /* handle wrapping */
>>> if(st->cur_dts != AV_NOPTS_VALUE){
>>> if(pkt->pts != AV_NOPTS_VALUE)
>>> pkt->pts= lsb2full(pkt->pts, st->cur_dts, st->pts_wrap_bits);
>>> if(pkt->dts != AV_NOPTS_VALUE)
>>> pkt->dts= lsb2full(pkt->dts, st->cur_dts, st->pts_wrap_bits);
>>> }
>>>
>>> The result is negative pts value for the packet. So I guess this is a
>>> bug in compute_pkt_fields(), or am I doing something wrong?
>>
>> Please check that st->pts_wrap_bits is set to 60 (and not 33) if the
>> input stream is mpeg-ts. A long time ago I had a similar problem
>> which was caused by the transport stream not being detected correctly.
>
> Hmm, you are right, st->pts_wrap_bits is 33 and it should be 60. If I
> manually set it to 60 it works as it should. How did you fix that problem?
Where do you get 60 from? All MPEG PTS/DTS values are 33 bits, nothing else.
--
M?ns Rullg?rd
mans at mansr.com
More information about the ffmpeg-devel
mailing list