Converting H.264 Video in MPEG-TS container doubles tbc

[nixscripter]

When converting video to H.264 in an MPEG-TS container, something strange happens. FFmpeg claims that the output has the same framerate (and tbc and tbn) as the input, but according to FFprobe, the calculated tbc is doubled. This is regardless of vsync or rate (-r) option.

ffplay seems able to deal with it, but other players don't play it back correctly, and it is those other players that led me to this issue.

[nixscripter]

Input Example

[nixscripter]

Output of Converting Example

[nixscripter]

Log Level 99 Output of Converting Example

[nixscripter]

To clarify, other players (such as mplayer) playback the video at twice the speed of the audio, i.e. at the calculated tbc rate.

[Carl Eugen Hoyos]

I wasn't able to find another player that fails for the output file you uploaded: Isn't this a bug in MPlayer?

[nixscripter]

Replying to cehoyos:

I wasn't able to find another player that fails for the output file you uploaded: Isn't this a bug in MPlayer?

It may very well be. However, I wonder if the bug is being triggered by an encoder output that is still unexpected.

As I previously noted, if you ffprobe the output file, you get:

Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 360x240 [SAR 32:27 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc

When it was encoded, ffmpeg thought it was generating a file that would be 29.97:

Output #0, mpegts, to 'mts_conv_x2_fr_output.mts':
  Metadata:
    encoder         : Lavf57.10.100
    Stream #0:0, 0, 1/90000: Video: h264 (libx264), -1 reference frame, yuv420p(center), 360x240 [SAR 32:27 DAR 16:9], 1001/30000, q=-1--1, 29.97 fps, 90k tbn, 29.97 tbc

Since even ffprobe read the file and computed an incorrect AVCodecContext time base based on something in the stream, doesn't that indicate something odd happened during encoding? Or is that calculation by ffprobe considered completely arbitrary and lacking any defined behavior?

If the latter is the case, then you can close this bug.

[Carl Eugen Hoyos]

Also reproducible with 2d3beedee28fe45f370c9a1bad4e84e65dcbc0c6