[FFmpeg-devel] [PATCH] make mpeg4 parser set has_b_frames

[elupus]

> On Thu, Nov 22, 2007 at 12:45:01AM +0100, elupus wrote:
> >
> > On a different but related note, should pts really be set to dts in
> > compute_pkt_fields if pts is missing? wouldn't it be better to leave 
> > that
> > up to the player? or atleast be conditional on GENPTS flag.
>
> what you say makes no sense, because the code doesnt do what you claim
> it does, please RTFS!

compute_pkt_fields is called on each packet nomatter of genpts or not..
....
delay= st->codec->has_b_frames; // == 0
presentation_delayed = 0;
....
if(delay <=1)
    if(presentation_delayed)
    ...
    else if(pkt->pts != AV_NOPTS_VALUE || pkt->dts != AV_NOPTS_VALUE
           || pkt->duration)  {
            .....
            if(pkt->pts == AV_NOPTS_VALUE)
                pkt->pts = pkt->dts;
     }

But I assume you won't be bothered to look so the above was probably a waste 
of typing.

>
> also ffmpeg fills missing information in to simplify the code needed by
> applications. if you have a example where ffmpeg makes a mistake send
> a proper bug report.
>

Agreed, this was related to mpeg4 in matroska compatibility mode. Even with 
the proposed patch for matroska, in setting dts instead of pts on ms compat 
tracks. I got invalid pts values for mpeg4 with b frames, thus this patch. 
But had ffmpeg not copied pts straight from dts, our player hadn't 
complained.


> [...]
>
> > Index: libavcodec/mpeg4video_parser.c
> > ===================================================================
> > --- libavcodec/mpeg4video_parser.c (revision 11070)
> > +++ libavcodec/mpeg4video_parser.c (working copy)
> > @@ -85,6 +85,7 @@
> >     if (s->width) {
> >         avcodec_set_dimensions(avctx, s->width, s->height);
> >     }
> > +    avctx->has_b_frames = !s->low_delay;
> >     s1->pict_type= s->pict_type;
> >     pc->first_picture = 0;
> >     return ret;
>
> and stop sending mangled patches!
> besides that this is not a valid patch (and i wont bother doing your work
> fixing that), it would likely be ok
>

That's fine, if I could figure why they are mangled it would hopefully be 
easy to fix.
 http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071122/e7d65bd6/attachment.txti can't see anything mangled in the patch. Aleast not the invalid offset ofthe line you are getting.It was generated with svn diff without being touched manually. I assume itcould have something todo with "An embedded and charset-unspecified text wasscrubbed..." that mailman writes. I'm posting through gmane newsgroup, soprobably some oddness with my client and them.