[FFmpeg-devel] [PATCH & RFC] GXF Encoder Fixes and HD support (patch broken up)
Thu Sep 9 03:26:51 CEST 2010
I posted a patch earlier today that wasn't intended to be committed, but rather for as RFC and getting feedback. However the immediate feedback seemed to indicated that people would be more willing to provide feedback if I went ahead and broke it up now instead of waiting.
So, I have broken the patch up according to bugs fixed or features added. Hopefully I can help get more eyes looking at it.
Patches will be posted individually to this thread.
Here's the breakdown:
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.
BUG: MPEG1 packets were not having the umf header data written, even though the function supports MPEG1.
BUG: There was always an error the the number of FLT packets was over the limit by one. This fixes that error. Mostly cosmetic, I don't think it was causing any (noticeable) playback issues.
BUG: The encoded line hight value was set one increment too low for line-heights not an even multiple of 16. (e.g. 1080i content was tagged as having an encoded line-height of 1072 instead of 1088)
FEATURE: Support for properly identifying DVCPROHD video steams.
FEATURE: Support for properly identifying AVCI video streams (H264 Intra encoding) Note: the video will decode, but doesn't decode correctly. Seems to have issues with the color-space conversion, and complains that number of reference frames exceeds max. If you want to test for yourself, sample clips can be found here: http://www.gvgdevelopers.com/concrete/products/k2/test_clips/
FEATURE: Adds support for storing the video content's display aspect ration in the GXF file. This is particularly important with 16:9 NTSC where it is rather difficult to deduce the display aspect ratio simply from the frame size. Also useful for differentiating beween 1920x1080 and 1440x1080 since the main header on indicates line-height.
FEATURE: Adds support for HD MPEG2 content and to a lesser extent DVCPROHD. Also makes changes in setting the frame/field rates depending on the time base rather than line-height. This is the patch needed the most input since I'm not sure how best to deal with detecting interlaced video streams.
FEATURE - OPTIONAL: This is a disabled chunck of code that would enable AVCI support. Two reasons it's not enabled: 1) I have no idea if the UMF media header for it uses the same mpeg header as MPEG1 and MPEG2 or if it has it's own unique media header. 2) Probably not a good idea to attempt encoding until ffmpeg can at least decode the AVCI samples correctly.
OPTIONAL: Tables I mad within the code mapping out what features correspond to which bits. May or may not be helpful or desired to be in the code base. Personally found it useful for quick reference.
I'm pasting the text from my previous email below:
============= snip =============
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
- 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.
- 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
***If you have access to SMPTE docs for this format, your review /
input is also appreciated!!***
Comments, suggestions, code, flames all welcome.
More information about the ffmpeg-devel