Opened 7 years ago
Closed 5 years ago
#6307 closed defect (invalid)
detected tbr different past 3.1.7 (1080i H.264)
Reported by: | Kory Prince | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avcodec |
Version: | git-master | Keywords: | h264 regression |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
The tbr of a 1080i H.264 clip is detected differently with versions 3.1.7 and early detecting 29.97 tbr (which should be correct) and versions after 3.1.7 (I've tested 3.2, 3.2.4, and current 3.3-dev) detecting 59.94 tbr.
I don't want to say either is wrong, because I don't know what the correct answer is; The behavior is definitely different. I don't know exactly how interlaced video works, but the fps should be 29.97 for this clip.
The clip in question is recorded from a Panasonic HDC-TM700.
This was discovered because newer versions of blender (including 3.2+ versions of ffmpeg) detect the given clip at 59.94 fps instead of 29.97 fps, meaning the video is imported twice as long as the audio. The bug report is here: https://developer.blender.org/T51153
I am attaching logs for versions 3.1.7, 3.2, 3.2.4, and 3.3-dev (commit efa89a8), and the clip used, 1080i_29.97.mts .
Command used:
ffprobe -v 9 -loglevel 99 -report 1080i_29.97.mts
Here is the relevant output from each ffprobe command:
3.1.7:
Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
3.2:
Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 59.94 tbr, 90k tbn, 59.94 tbc
3.2.4:
Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 59.94 tbr, 90k tbn, 59.94 tbc
3.3-dev:
Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 59.94 tbr, 90k tbn, 59.94 tbc
As you can see, 3.1.7 has 29.97 tbr, and the reset are identical and 59.94 tbr. My guess is this is incorrect, and it should be detected as 29.97 tbr.
I think the problem is in libavformat judging from the comments on the blender bug.
Attachments (5)
Change History (14)
by , 7 years ago
Attachment: | ffprobe-3.1.7.log added |
---|
by , 7 years ago
Attachment: | ffprobe-3.2.log added |
---|
by , 7 years ago
Attachment: | ffprobe-3.2.4.log added |
---|
by , 7 years ago
Attachment: | ffprobe-3.3.log added |
---|
comment:1 by , 7 years ago
comment:2 by , 7 years ago
Please provide ffmpeg -i
output for current FFmpeg git head to make this a valid ticket.
comment:3 by , 7 years ago
Current HEAD 6268f2ca7b:
$ ffmpeg -i 1080i_29.97.mts *[master] ffmpeg version N-85467-g6268f2ca7b Copyright (c) 2000-2017 the FFmpeg developers built with gcc 6.3.1 (GCC) 20170109 configuration: libavutil 55. 61.100 / 55. 61.100 libavcodec 57. 92.100 / 57. 92.100 libavformat 57. 72.100 / 57. 72.100 libavdevice 57. 7.100 / 57. 7.100 libavfilter 6. 84.101 / 6. 84.101 libswscale 4. 7.100 / 4. 7.100 libswresample 2. 8.100 / 2. 8.100 Input #0, mpegts, from '/tmp/1080i_29.97.mts': Duration: 00:00:09.54, start: 0.390400, bitrate: 8896 kb/s Program 1 Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 59.94 tbr, 90k tbn, 59.94 tbc Stream #0:1[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 384 kb/s Stream #0:2[0x1200]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090), 1920x1080 At least one output file must be specified
comment:4 by , 7 years ago
Not related to your report but a comment on the original blender report:
dd
is the only tool to reliably cut transport streams for upload as samples, as you found out other tools create new, different files that may or may not be suited to reproduce issues. It is also the preferred tool to cut other types of media files but in some cases special care has to be taken (mov).
comment:5 by , 7 years ago
Thanks for the clarification. I went ahead and just recorded a 10 second clip to remove any doubt. Good to know for the future.
comment:6 by , 7 years ago
Component: | undetermined → avcodec |
---|---|
Keywords: | h264 regression added |
Version: | unspecified → git-master |
If there were an issue, it would be a regression since 01fa4fb6 but I suspect the duplicated timebase is correct for paff-encoded video, see also tickets #3339 and #5378.
In any case, there is most likely a bug in blender as FFmpeg always detects the correct length of the clip, no matter the timebase.
by , 7 years ago
Attachment: | bad_clip_2_cut.mts added |
---|
comment:7 by , 7 years ago
I forgot to add that FFmpeg has known issues with h264 timestamps, I don't know if these bugs are related to the problem you see.
comment:9 by , 5 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Most likely not a valid ticket.
I submitted the video clip through the VLC uploader referenced on the first page. It's not showing up here, so if there's an issue, you can also download it from my latest comment on the blender bug: https://developer.blender.org/T51153