[FFmpeg-devel] [PATCH 1/10] GXF Encoder Fixes and HD support (patch broken up)

Reuben Martin reuben.m
Fri Sep 10 00:32:01 CEST 2010


Yo, back on Thursday, September 09, 2010 Baptiste Coudurier was all like:
> Hi,
> 
> On 09/08/2010 06:34 PM, Reuben Martin wrote:
> > Yo, back on Wednesday, September 08, 2010 Reuben Martin was all like:
> >> Here's the breakdown:
> >>
> >> 01-gxf__flt_offset_error.patch
> >>
> >> BUG: The offset values for the FLT packets were getting attached to the packet preceding the packet they were supposed to be attached to. This was causing all kinds of playback and seeking issues on GrassValley's Turbo.
> >>
> >>
> >>
> >> 01-gxf__flt_offset_error.patch
> >>
> >>
> >> --- ffmpeg-old/libavformat/gxfenc.c	2010-09-04 11:41:27.000000000 -0500
> >> +++ ffmpeg-new/libavformat/gxfenc.c	2010-09-08 16:39:20.405000084 -0500
> >> @@ -878,7 +878,11 @@
> >>                   return -1;
> >>               }
> >>           }
> >> -        gxf->flt_entries[gxf->flt_entries_nb++] = url_ftell(pb) / 1024;
> >> +
> >> +        if (!(gxf->flt_entries_nb))
> >> +            gxf->flt_entries[gxf->flt_entries_nb] = 4; /* First offset seems to be pretty close to this. May vary. */
> >> +        gxf->flt_entries_nb++;
> >> +        gxf->flt_entries[gxf->flt_entries_nb] = url_ftell(pb) / 1024;
> >>           gxf->nb_fields += 2; // count fields
> >>       }
> >>
> 
> Looks hackish to me.
> 
> 

would changing 

if (!(gxf->flt_entries_nb))

to 

if (gxf->flt_entries_nb == 0)

be more palatable?

I moved the incrementing of gxf->flt_entries_nb in front of setting  gxf->flt_entries[#] because in the previous method, the  gxf->flt_entries_nb would get incremented after setting  gxf->flt_entries[#] rather than before which caused the whole problem to begin with.

 gxf->flt_entries[0] is set to 4k since there is no media in front of it, just the header data, and in all my tests that always came out pretty close to ~4k

Let me know if I need to re-submit this.



More information about the ffmpeg-devel mailing list