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