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

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

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.

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

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?

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

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!