On Tue, 10 Jan 2012 11:24:11 +0000, Måns Rullgård <[email protected]> wrote: > Anton Khirnov <[email protected]> writes: > > > It is not supposed to be done outside lavc. > > > > This is basically a revert of 818062f2f346df30f4ec0c0c1f54e8025cc3a80a. > > > > It is unclear what issue this was supposed to fix, if it reappears again > > it will have to be fixed in a more proper place. > > --- > > libavformat/utils.c | 4 ---- > > 1 files changed, 0 insertions(+), 4 deletions(-) > > > > diff --git a/libavformat/utils.c b/libavformat/utils.c > > index a796658..6424eec 100644 > > --- a/libavformat/utils.c > > +++ b/libavformat/utils.c > > @@ -961,10 +961,6 @@ static void compute_pkt_fields(AVFormatContext *s, > > AVStream *st, > > if((s->flags & AVFMT_FLAG_IGNDTS) && pkt->pts != AV_NOPTS_VALUE) > > pkt->dts= AV_NOPTS_VALUE; > > > > - if (st->codec->codec_id != CODEC_ID_H264 && pc && pc->pict_type == > > AV_PICTURE_TYPE_B) > > - //FIXME Set low_delay = 0 when has_b_frames = 1 > > - st->codec->has_b_frames = 1; > > - > > /* do we have a video B-frame ? */ > > delay= st->codec->has_b_frames; > > presentation_delayed = 0; > > -- > > Seems OK. I trust you ran fate without issues. >
I still didn't push this because it breaks the recently added wtv-demux test. In it, the input contains mpeg2 video that apparrently starts with a B-frame. After this patch, has_b_frames isn't set until a few frames later and compute_pkt_fields() random generator produces a different dts for the first frame. Do we care? Should the parser set has_b_frames immediately when it sees a B-frame? Or shall I push it as is? -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
