[FFmpeg-devel] [RFC] - GXF Encoder fixes and HD support

Reuben Martin reuben.m
Wed Sep 8 19:26:52 CEST 2010


I've been working on this small patch for about a week to improve gxf
encoding. The company I work at recently purchased some GrassValley
Turbo (1st generation) playback / record units. Importing video is a
painfully long process, but import of gxf is pretty instantaneous.

It turned out that the current code only supports standard def NTSC /
PAL resolutions, and I wanted to be able to use it for HD content.

As it stands, with this patch I can correctly encoded MPEG2 GXF files
at 1080i that will import and play back correctly. Please note that I
am more of a 2-bit hack than a programmer. ;) I've only been poking
around in the ffmpeg code for the last week or so.

Current limitations and issues:

- First off, I've come to realize this format was conceived by the
type of ?broadcast engineers who tend to fling poo at people who
venture too close to their cages. All kinds of redundant information
and lack of flexibility. (although in a streaming context perhaps some
of it makes more sense)

- I'm still trying to work out how to determine if the video stream is
interlaced or not. I just today had a reply to an earlier request for
help that I might be able to us AVFrame for that, but I have not yet
had time to look into that. At first glace it seems to be specific to
MPEG 1/2/4 content. It would be nice if I could find a more generic
means that would also apply to things like DV, and MJPEG formats also
supported by ffmpeg. Until I figure out something better, everything
is assumed to be interlaced except for content with 720 lines.

- Frame rate vs Field rate (or "Sample rate") : These make no sense AT
ALL based on gxf samples available. I can find 480i samples that have
frame rate of 30 and sample rate of 60, 1080i samples that have frame
rate of 30 and sample rate of 30, 720p samples that have frame rate of
30 and sample rate of 60.

- Starting line: I can't find any documentation on what the starting
lines for 720 and 1080 content should be, so for now they are using
PAL's default starting line. For what it's worth, starting lines from
gxf samples I've found vary (almost randomly it seems) from what
ffmpeg uses.

- Most of my testing was done using a win32 gxf parser provided by
GrassValley. I do not have access to any of the official SMPTE
documents, so if the parser has bugs or doesn't follow spec correctly
there may be issues I'm not aware of.
http://www.gvgdevelopers.com/concrete/products/k2/tstream___gxf_file_parser_and_checker/

- I can't really test MPEG1, MJPEG, and haven't tried DVCPROHD yet.
The Turbo unit only works well with MPEG2 yuv422p for SD and MPEG2
yuv420p for HD, so there may be issues with those formats.

I hope to chop up the diffs according to features / bug fixes and
submit them for official review in a week or so. Please let me know if
you see any issues.

***If you have access to any hardware / software that is not based on
ffmpeg and supports gxf file imports, you success or failure of
importing gxf files with this patch applied would be very
appreciated!!***

***If you have access to SMPTE docs for this format, your review /
input is also appreciated!!***

Comments, suggestions, code, flames all welcome.

Best regards,
-Reuben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gxf.diff
Type: application/octet-stream
Size: 1038 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100908/937ab134/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gxfenc.diff
Type: application/octet-stream
Size: 17798 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100908/937ab134/attachment-0001.obj>



More information about the ffmpeg-devel mailing list