[Ffmpeg-devel] Bug in pts computation in compute_pkt_fields() ?

Wolfram Gloger wmglo
Tue Mar 20 14:17:46 CET 2007


> > That is probably raw mpeg-ts, right?
> 
> What do you mean by "raw mpeg-ts"?

Well, a raw mpeg transport stream, such as obtained
> 
> >> 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.
> 
> MPEG-TS PTS is always 33 bits.  The PCR is 42 bits.  Nothing is 60 bits.
> 
> -- 
> M??ns Rullg??rd
> mans at mansr.com
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> http://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
> 




More information about the ffmpeg-devel mailing list