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)

ffprobe-3.1.7.log (40.1 KB ) - added by Kory Prince 7 years ago.
ffprobe-3.2.log (40.4 KB ) - added by Kory Prince 7 years ago.
ffprobe-3.2.4.log (40.4 KB ) - added by Kory Prince 7 years ago.
ffprobe-3.3.log (39.6 KB ) - added by Kory Prince 7 years ago.
bad_clip_2_cut.mts (2.4 MB ) - added by Carl Eugen Hoyos 7 years ago.

Change History (14)

by Kory Prince, 7 years ago

Attachment: ffprobe-3.1.7.log added

by Kory Prince, 7 years ago

Attachment: ffprobe-3.2.log added

by Kory Prince, 7 years ago

Attachment: ffprobe-3.2.4.log added

by Kory Prince, 7 years ago

Attachment: ffprobe-3.3.log added

comment:1 by Kory Prince, 7 years ago

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

comment:2 by Carl Eugen Hoyos, 7 years ago

Please provide ffmpeg -i output for current FFmpeg git head to make this a valid ticket.

comment:3 by Kory Prince, 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 Carl Eugen Hoyos, 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 Kory Prince, 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 Carl Eugen Hoyos, 7 years ago

Component: undeterminedavcodec
Keywords: h264 regression added
Version: unspecifiedgit-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 Carl Eugen Hoyos, 7 years ago

Attachment: bad_clip_2_cut.mts added

comment:7 by Carl Eugen Hoyos, 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:8 by Elon Musk, 7 years ago

This is not bug.

comment:9 by Carl Eugen Hoyos, 5 years ago

Resolution: invalid
Status: newclosed

Most likely not a valid ticket.

Note: See TracTickets for help on using tickets.