Opened 3 years ago

Last modified 3 years ago

#5761 new defect

GOP inconsistencies when transcoding H.264 to MPEG2 MXF

Reported by: edob Owned by:
Priority: normal Component: undetermined
Version: 3.0.2 Keywords:
Cc: cus@passwd.hu Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Hi,

here's my summary of the bug:

When transcoding H.264 video files from a GoPro? Hero3 (1920x1080,25fps,High@L4.1,30Mbps VBR,CABAC, M=1,N=13) to XDCAM HD422-Style MPEG2 video (50Mbps CBR, 1080i25, M=3,N=12), one seems to only get proper files if t<=60.00 seconds, but if t>60 seconds, the GOPs of the output file are of variable length (always multiples of M). I've encountered similar behaviour with other H.264 files as well, but this one is easier to reproduce (because it's not "some file from some guy").

[ Src file can be supplied but is 230M. ]

How to reproduce:

% ffmpeg -i C:\FFMPEG\GOPR_61sec.mp4 -vcodec mpeg2video -b:v 50M -minrate 50M -maxrate 50M -g 12 -bf 2 -vf colormatrix=bt601:bt709 -color_primaries bt709 -color_trc bt709 -colorspace bt709 -flags +ildct+ilme -top 1 -s 1920x1080 -r 25.000 -pix_fmt yuv422p -acodec pcm_s24le -ar 48000 -filter_complex "[0:a]channelsplit=channel_layout=stereo[a1][a2]" -map 0:v:0 -map "[a1]" -map "[a2]" C:\FFMPEG\GOPR_Test.mxf
ffmpeg version N-81306-g26695ae
built on 08/08/16 (Win32 static by zeranoe)

Please let me know if you need more detail.

Attachments (2)

ffmpeg-20160809-171146.log (403.3 KB) - added by edob 3 years ago.
ffmpeg-report
console.log (1.7 MB) - added by edob 3 years ago.
ffmpeg-console

Change History (12)

Changed 3 years ago by edob

ffmpeg-report

Changed 3 years ago by edob

ffmpeg-console

comment:1 Changed 3 years ago by cehoyos

Please provide the input file.

comment:3 Changed 3 years ago by edob

Note: The above file has been sliced from the original file with the latest FFmpeg build, video and audio streams have been copied. Slicing a 60 sec file from the above will also result in the variable GOPs.
However, slicing a 60 second file from the original and trancoding it will give the proper GOPs.

comment:4 Changed 3 years ago by cus

  • Cc cus@passwd.hu added

comment:5 Changed 3 years ago by cehoyos

Please provide the input file.

comment:6 Changed 3 years ago by cehoyos

What I mean is: Your original report is about a file coming from a GoPro Hero but the file you provided was made with FFmpeg.

comment:7 Changed 3 years ago by cus

You have not disabled scene change detection, therefore your gops have variable size. Use -sc_threshold 1000000000. Are you sure your tests depend on file size? That part I could not reproduce.

comment:8 Changed 3 years ago by edob

You might be on to something here...
I just ran a test with the original file ( https://www.dropbox.com/s/go0hg21gnjtlz3z/GOPR0358.MP4?dl=0 ) and now the GOP structure is as expected (M=3, N=12). Will run some more tests with other files.

comment:9 Changed 3 years ago by edob

So far this has succeeded on all the files I used to have trouble with.
Just for clarification and deeper understanding: Is this "the proper way to go", i.e. required/recommended practice, or just a handy workaround for something that would need to be fixed otherwise?

comment:10 Changed 3 years ago by cus

I kind of assumed that -mpv_flags +strict_gop is the proper way, but that does not work. Anyhow, disabling scene change detection is the way to go for x264 as well for example to get fixed length GOPs.

Note: See TracTickets for help on using tickets.