Hi, On Thu, Jun 16, 2011 at 12:08 PM, Tony Strauss <[email protected]> wrote: > On Wed, Jun 15, 2011 at 9:07 AM, Diego Biurrun <[email protected]> wrote: >> >> On Thu, Apr 21, 2011 at 04:30:35PM -0400, Ronald S. Bultje wrote: >> > >> > On Thu, Apr 21, 2011 at 4:22 PM, Tony Strauss <[email protected]> wrote: >> > > On Thu, Apr 21, 2011 at 3:34 PM, Mike Scheutzow >> > > <[email protected]> wrote: >> > >> Tony Strauss wrote: >> > >>> The >> > >>> key thing is that this file was encoded without b frames, so pts == >> > >>> dts for every frame. >> > >> >> > >> It requires more than "no B frames" for this statement to be true. >> > >> >> > >> Does the video contain P-frames? If it contains P-frames, then pts != >> > >> dts. Please post a link to a valid file so we can see. >> > > >> > > Interesting. I really don't know much about video encoding, but this >> > > surprises me. Certainly a patched ffprobe shows pts == dts for >> > > clip.no_bframes.ts (and this does have p frames, since refs=1). Why >> > > would the presence of p-frames change pts == dts? Since p-frames only >> > > depend on an earlier frame, can't they be presented as soon as they're >> > > decoded? >> > >> > Yes. If there's no B-frames, pts == dts is fine. >> > >> > (I intend to look at your bug at some point, but didn't get to it yet so >> > far.) >> >> ... ping ... > > My original patch was not accepted; Mike Scheutzow submitted an alternative > patch to ffmpeg that was accepted: > diff --git a/libavcodec/h264.c b/libavcodec/h264.c > index 6cd597e..a40afbc 100644 > --- a/libavcodec/h264.c > +++ b/libavcodec/h264.c > @@ -3413,7 +3413,8 @@ static int decode_nal_units(H264Context *h, const > uint8_t *buf, int buf_size){ > init_get_bits(&s->gb, ptr, bit_length); > ff_h264_decode_seq_parameter_set(h); > > - if(s->flags& CODEC_FLAG_LOW_DELAY) > + if(s->flags& CODEC_FLAG_LOW_DELAY || > + (h->sps.bitstream_restriction_flag && > !h->sps.num_reorder_frames)) > s->low_delay=1; > > if(avctx->has_b_frames < 2) > I think that my patch was the right idea, but I also think that it was a > potentially dangerous change, and I didn't have the time to follow through > fully. Mike's patch fixes the problem.
LGTM - Reinhard this should probably go into the release. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
