GXF file frame rate double what it should be for some files.

[ryaowe]

• Trying to accomplish: Transcode a GXF (mpeg2 video, pcm16le audio) to any other format
• Problem encountered: Transcoded video plays back at twice the rate it should.
• Command line: ffmpeg -i fyi.gxf -t 30 -acodec libfaac fyi.mp4
• ffmpeg -v 9 -loglevel 99 -i fyi.gxf:

  ffmpeg version N-35872-g6d8e6fe, Copyright (c) 2000-2011 the FFmpeg developers
    built on Dec 16 2011 16:49:56 with gcc 4.2.1 (Apple Inc. build 5666) (dot 3)
    configuration: --enable-shared --disable-static --disable-doc --enable-memalign-hack --enable-nonfree --enable-gpl --enable-libfaac --cc=gcc-4.2 --prefix=/Users/ryanowen/src/protoven/uplynk/dependencies/encoder_Darwin_64 --enable-pic --extra-ldflags=-headerpad_max_install_names --enable-debug=3
    libavutil    51. 32. 0 / 51. 32. 0
    libavcodec   53. 46. 0 / 53. 46. 0
    libavformat  53. 26. 0 / 53. 26. 0
    libavdevice  53.  4. 0 / 53.  4. 0
    libavfilter   2. 53. 0 /  2. 53. 0
    libswscale    2.  1. 0 /  2.  1. 0
    libpostproc  51.  2. 0 / 51.  2. 0
  [gxf @ 0x7fa48303d820] Format gxf probed with size=2048 and score=100
  [mpeg2video @ 0x7fa48304e620] err{or,}_recognition separate: 1; 1
  [mpeg2video @ 0x7fa48304e620] err{or,}_recognition combined: 1; 10001
  [pcm_s16le @ 0x7fa48303fc20] err{or,}_recognition separate: 1; 1
  [pcm_s16le @ 0x7fa48303fc20] err{or,}_recognition combined: 1; 10001
  [pcm_s16le @ 0x7fa483040220] err{or,}_recognition separate: 1; 1
  [pcm_s16le @ 0x7fa483040220] err{or,}_recognition combined: 1; 10001
  [mpeg2video @ 0x7fa48304e620] Unsupported bit depth: 0
  [gxf @ 0x7fa48303d820] All info found
  
  Seems stream 0 codec frame rate differs from container frame rate: 119.88 (120000/1001) -> 59.94 (120000/2002)
  Input #0, gxf, from 'fyi.gxf':
    Metadata:
      gxf_timecode    : 01:00:48;38
      gxf_timecode_at_mark_in: 01:00:48;38
      gxf_timecode_at_mark_out: 01:11:38;50
    Duration: 00:05:25.09, start: 0.000000, bitrate: 85613 kb/s
      Stream #0:0, 41, 1001/120000: Video: mpeg2video (4:2:2), yuv422p, 1280x720 [SAR 1:1 DAR 16:9], 1001/120000, 50000 kb/s, 119.88 fps, 59.94 tbr, 119.88 tbn, 119.88 tbc
      Stream #0:1, 2, 1001/120000: Audio: pcm_s16le, 48000 Hz, 1 channels, s16, 768 kb/s
      Stream #0:2, 2, 1001/120000: Audio: pcm_s16le, 48000 Hz, 1 channels, s16, 768 kb/s
      Stream #0:3, 0, 1001/120000: Data: none
  At least one output file must be specified
  

Some GXF files end up with a frame rate for the video track that is twice what it should be. In my case, the time base should be 1001 / 60000, but was 1001 / 120000.

The problem seems to coincide with files that have a fields_per_frame value of 1 instead of 2. The following patch solved the problem for me, and allows me to dencode all of my GXF files correctly (both those that did and did not work correctly prior to the fix).

diff --git a/libavformat/gxf.c b/libavformat/gxf.c
index 95a8142..1d9f059 100644
--- a/libavformat/gxf.c
+++ b/libavformat/gxf.c
@@ -351,7 +351,7 @@ static int gxf_header(AVFormatContext *s, AVFormatParameters *ap) {
         st = s->streams[idx];
         if (!main_timebase.num || !main_timebase.den) {
             main_timebase.num = si->frames_per_second.den;
-            main_timebase.den = si->frames_per_second.num * 2;
+            main_timebase.den = si->frames_per_second.num * (si->fields_per_frame ? si->fields_per_frame : 2);
         }
         st->start_time = si->first_field;
         if (si->first_field != AV_NOPTS_VALUE && si->last_field != AV_NOPTS_VALUE)

I'll upload a test file to upload.ffmpeg.org, called double_framerate.gxf

[reimar]

GXF timestamps should be in fields always, thus this should not be correct.
How sure are you it is not your files that are broken?

[Carl Eugen Hoyos]

Unrelated to Reimar's comment:
Could you provide a significantly longer sample?
(Sorry for the text on bugreports, it is simply not correct for sync issues, but we received 30M samples in the past for decoding problems that were reproducible with the first frame...)

[ryaowe]

I'm uploading the full 15s clip, which is 104MB. double_framerate_15s.gxf. Let me know if that's still too short; I can find another example.

I'm not positive that the files aren't broken. They are given to me by a production broadcast house, so I've given them the benefit of the doubt. But sometimes the "profesional" tools are the worst offenders, it seems. I'll see if I can find out what software was used to produce them and any other detail surrounding that.

Thanks for looking into this!

[reimar]

There has been a reported issue that was similar, but not identical (as I understood it, a internal too removed the per-stream FPS marking there which had a similar effect in the end).
Their solution was to hack the assignment to stop the time base from going below 1/60.
I think you maybe should be consider this option.
Pro: It will work with files that I would consider correct, which always uses "fields" for time base
Contra: It will break if you ever need to process content with more than 60 frames per second / 120 fields per second.
If this would work for you, too, I'll start thinking of adding this as an option as it seems to be quite a common issue, even if it should be due to broken files.
The reason I would tend to believe your files are broken is because these fields are called "frames per second" and seem to contain "60" in your case. However I don't think your file is actually 60 frames per second, but only 60 fields per second (or 30 frames per second).

[ryaowe]

That makes sense. But I'm not sure that other case you're talking about applies to these files, even though the two sound similar. For this file, fields_per_frame=1, which implies that the frame rate really is 60fps. To verify this, we set up a small test that reads and decodes each AVFrame object, and the decoder emitted an AVPicture for each AVFrame of input. We also verified that, when played back at 60fps, the video looks correct, and matches up with the audio.

If the patch still doesn't seem right, can you help me understand that bit of code - i.e. what's the "*2" in " main_timebase.den = si->frames_per_second.num * 2; " for exactly? I was just assuming it was hardcoding the number of fields per frame (hence my change to take fields_per_frame into account instead of hardcoding it), but maybe it's for something else?

[reimar]

This is a bit difficult since I don't have the spec available, but basically it says that for the time stamps that even ones always indicate the first field and odd ones the second field (independent of number of fields per frame). So for progressive the time stamps should always the even and increment by 2.
Thus the time stamp always increases by two per frame regardless of progressive or interlaced, and the time base is 1/(2*fps) in both cases.
If your video is indeed 60 fps progressive that sounds like the timestamps are not encoded the way they are required by the specification (as I remember it) and that would make things a bit difficult.
Now it's not impossible that my understanding is based on misunderstanding the specification, but I was convinced enough to change it (the code was originally the way you suggest to change it).
Note the issue number is from the old roundup tracker, it seems a copy of it exists here: ​http://roundup.libav.org/issue1766

commit 192c14fa5510e8b5e13ed5796ae87aabbfad84d6
Author: Reimar Döffinger <​Reimar.Doeffinger@gmx.de>
Date: Sat Mar 6 22:20:33 2010 +0000

GXF time base is always based on "fields" per second even for
non-interlaced video.
Should fix issue 1766.

Originally committed as revision 22256 to ​svn://svn.ffmpeg.org/ffmpeg/trunk

[ryaowe]

You're brilliant! It took me a while to prove it to myself, but after much effort, it turns out you were spot on from the beginning.

I bought the spec from the mafia er SMPTE, then wrote enough of a parser to verify that avformat was reading header values correctly (I know, silly of me, but I had to prove it to myself).

As you say, the spec indicates that progressive content should only use even field numbers. The field numbers in the files I've been dealing with increment by 1. This would indicate interlaced content, event though fields_per_frame=1.

So either A) the 60fps should really be 30fps and fields_per_frame should be 2, or B) the field numbers in the media packets should be only even numbers.

I'll implement the hack you recommended for now, but the right fix is to get my content producer to solve the problem on their end. Thanks for your help and patience!

[Carl Eugen Hoyos]

Thank you for verifying!