[FFmpeg-user] GOP Structure - XDCAM RDD9

[Marton Balint]

On Fri, 19 Jun 2020, Anthony Smith wrote:

> Hello everyone,
>
> I am having an issue creating an RDD9 compliant MXF using FFMPEG within
> FFASTrans.
> I am transcoding from a QT ProRes 422 HQ MOV to XDCAM MXF then re-wrapping
> using BMX Trans Wrap to ensure RDD9 compliance.
>
> The base issue is the GOP structure and the last frame of each GOP.
> Clients Baton File QC is looking for a B frame, whereas FFMPEG outputs a P
> frame.
>
> The expected file specs after transcode are:
>
> PAL 1920x1080 50i XDCAM 422 50mbps long-gop, closed gop. M=3, N=12
> 2x AES PCM audio streams, 1 channel in each.
>
> My command is as follows:
>
> c:\FFAStrans1.0.0\FFAStrans1.0.0\Processors\ffmpeg\x64>ffmpeg.exe -i
> "z:\100_incoming_media\OM_TEST.mov" -profile:v 0 -level:v 2 -map 0:1 -r 25
> -pix_fmt yuv422p -aspect 16:9 -intra_vlc 1 -b:v 50000000 -minrate 50000000
> -maxrate 50000000 -bufsize 17825792 -rc_init_occupancy 17825792
> -sc_threshold 1000000000 -non_linear_quant 1 -color_primaries bt709
> -color_trc bt709 -colorspace bt709 -seq_disp_ext 1 -video_format component
> -color_range 1 -chroma_sample_location topleft -signal_standard 4 -dc 8
> -qmin 3 -qmax 28 -mpv_flags +strict_gop -strict 1 -g 12 -bf 2 -field_order
> tt -top 1 -flags +cgop+ildct+ilme -alternate_scan 1 -map 0:2 -map 0:3
> "z:\10000_temp\MXFTEST\OM_Test_Out.mxf"
>
> Everything is fine, except for the GOP structure.
> Running FFProbe, the GOP structure is IBB PBB PBB PB*P*
> I submit this to clients Baton File QC and they fail it, as the expected
> GOP is: IBB PBB PBB PB*B*
>
> If I remove the +cgop flag from the command I do get the desired IBB PBB
> PBB PBB
> But as expected, the GOP isn't closed and fails file QC.
>
> What else is interesting, doing the exact same transcode with the same
> parameters within Telestreams Vantage transcoding system, I get a GOP
> structure that looks like this at the very beginning "BB IBB PBB PBB PBB".
> It opens with two B frames at the beginning of the file and then
> subsequently follows the correct closed GOP pattern throughout.
>
> I'm thinking; I am either doing something wrong with the FFMPEG Command, or
> just missing something.  Or the output file from FFMPEG and its GOP
> structure is correct and Baton File QC parameters are being too strict.  Or
> there is a very slim chance that there is a bug with FFMPEG creating XDCAM
> Closed Gop MXF files.

AFAIK there is no bug, but ffmpeg only supports generating the first frame 
as an I-frame, because it makes little sense to start with a half-assed B 
frame which uses backward prediction only.

>
> At the end of the day, it's down to the difference between a "B" frame and
> "P" frame at the end of a Closed GOP output from FFMPEG.
>
> I understand that Closed GOPs are separate and don't cross reference each
> other, and makes sense why there would be a P frame at the end of the
> closed GOP and not a B frame...

Exactly. It is more correct to designate the last frame in the GOP as 
P-frame because it cannot use backward prediction because of the closed 
GOP requirement.

> Just annoying that the clients Baton file QC says this can't be so... a
> literal "computer says no" moment.

Yes. There is no support to generate "fake" B-frames which are in fact 
P-frames. I guess this can be implemented realtively easily although, but 
it would be less "correct" than what we have now, so an extra flag will be 
needed for it.

Regards,
Marton