[FFmpeg-trac] #4955(undetermined:new): Converting H.264 Video in MPEG-TS container doubles tbc

FFmpeg trac at avcodec.org
Fri Oct 23 18:03:49 CEST 2015

#4955: Converting H.264 Video in MPEG-TS container doubles tbc
             Reporter:  nixscripter  |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:  h264         |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0

Comment (by nixscripter):

 Replying to [comment:2 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

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

 Output #0, mpegts, to 'mts_conv_x2_fr_output.mts':
     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.

Ticket URL: <https://trac.ffmpeg.org/ticket/4955#comment:3>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list