Opened 6 months ago

Last modified 5 months ago

#6307 new defect

detected tbr different past 3.1.7 (1080i H.264)

Reported by: korylprince 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 korylprince 6 months ago.
ffprobe-3.2.log (40.4 KB) - added by korylprince 6 months ago.
ffprobe-3.2.4.log (40.4 KB) - added by korylprince 6 months ago.
ffprobe-3.3.log (39.6 KB) - added by korylprince 6 months ago.
bad_clip_2_cut.mts (2.4 MB) - added by cehoyos 6 months ago.

Change History (13)

Changed 6 months ago by korylprince

Changed 6 months ago by korylprince

Changed 6 months ago by korylprince

Changed 6 months ago by korylprince

comment:1 Changed 6 months ago by korylprince

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 Changed 6 months ago by cehoyos

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

comment:3 Changed 6 months ago by korylprince

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 Changed 6 months ago by cehoyos

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 Changed 6 months ago by korylprince

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 Changed 6 months ago by cehoyos

  • Component changed from undetermined to avcodec
  • Keywords h264 regression added
  • Version changed from unspecified to 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.

Changed 6 months ago by cehoyos

comment:7 Changed 6 months ago by cehoyos

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 Changed 5 months ago by richardpl

This is not bug.

Note: See TracTickets for help on using tickets.