Opened 5 years ago

Closed 5 years ago

#786 closed defect (invalid)

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

Reported by: ryaowe Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: gxf
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


  • 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':
        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, called double_framerate.gxf

Change History (8)

comment:1 Changed 5 years ago by 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?

comment:2 Changed 5 years ago by cehoyos

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...)

comment:3 Changed 5 years ago by 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!

comment:4 Changed 5 years ago by 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).

comment:5 Changed 5 years ago by 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?

comment:6 Changed 5 years ago by 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:

commit 192c14fa5510e8b5e13ed5796ae87aabbfad84d6
Author: Reimar Döffinger <>
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://

comment:7 Changed 5 years ago by 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, even 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!

Last edited 5 years ago by ryaowe (previous) (diff)

comment:8 Changed 5 years ago by cehoyos

  • Keywords gxf added
  • Resolution set to invalid
  • Status changed from new to closed

Thank you for verifying!

Note: See TracTickets for help on using tickets.