[FFmpeg-devel] GXF Encoder Fixes and HD support

[Reuben Martin]

These 2 patches apply to the current head and should allow for 720p and 1080i 
in GXF. It doesn't include patches for the test units.

I would discourage you from attempting to use these with 1080p. The frame rate 
in GXF is always in fields, even for progressive content. So it is not possible 
to determine if the content is progressive or interlaced from the frame rate. 
If the generic API for video streams included a bit field to indicate the frame 
structure (progressive, interlaced, PsF, field order, 3D packed, 3D 
interleaved, etc...) then this would be much easier to fix. Currently I think 
you would have to muck around at the codec level, which is different for each 
codec. So not a straight forward task. I could be wrong about that though, I 
haven't dug into it too deeply.

-Reuben

On Monday, May 05, 2014 05:49:09 PM Peter Stevens wrote:
> Hi Reuben,
> 
> 
> 
> If you are have access to/are able to post the patches for GXF HD
> support it would be appreciated.
> 
> 
> 
> Thanks,
> 
> Peter
> 
> On Tuesday, April 15, 2014 11:09:34 AM Peter Stevens wrote:
> > A patch set for supporting GXF HD support was posted a few years back
> 
> (http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2010-September/100889.ht
> 
> > ml
> > 
> > 
> > 
> > ) but I don't think it made its way into ffmpeg. Does anybody know if
> > 
> > this something still being worked on? or where I might find a copy of
> > 
> > the mentioned patch
> 
>  I wrote those patches. The biggest issue making me hesitant to push
> hard to
> 
> get them merged is that there was no direct means to determine if the
> stream
> 
> was interlaced or not. The differences between frame and field rates
> were
> 
> ambiguous. So 1080i at 29.94
> <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>  frames per sec, would
> return the same "rate" as
> 
> 1080p at 59.94 <http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>  frames
> per sec.
> 
> 
> 
> Perhaps that is not the case now, I'm not a regular dev for ffmpeg.
> Mostly just
> 
> an avid user. I created the patches to fix the horribly broken GXF
> 
> implementation at the time in order to save myself hours of mind-numbing
> time
> 
> importing large files into the old GrassValley Turbo playback machines.
> My
> 
> company has since discarded those pieces of junk, so I have little
> motivation
> 
> to do anything more with GXF. The format itself is rather arcane.
> (originally
> 
> intended for utilizing FTP transport. yuck.) GrassValley is the only
> company
> 
> I'm aware of that really promotes usage of that format. They wrote the
> spec
> 
> for it after all...
> 
> 
> 
> I probably still have the patches lying around. There were some updates
> 
> somebody asked me to make for it about a year ago. Some of those updates
> were
> 
> applied to the trunk. I might be able to find the HD parts that were not
> pulled
> 
> if you really need them.
> 
> 
> 
> -Reuben
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01_GXF_DAR.patch
Type: text/x-patch
Size: 5055 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140519/e888ac48/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 02_GXF_HD.patch
Type: text/x-patch
Size: 18070 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140519/e888ac48/attachment-0001.bin>