On Mon, 6 Feb 2012, Anton Khirnov wrote:
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?
I'm ok with this (with the fate ref updated), since it
simplifies/clarifies the roles of which parts of the code actually sets
has_b_frames.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
