GOP Structure - XDCAM RDD9

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

GOP Structure - XDCAM RDD9

Anthony Smith
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.

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...
Just annoying that the clients Baton file QC says this can't be so... a
literal "computer says no" moment.

Anyways, hope this made sense.  Happy to clarify further.

Regards,

Anthony.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: 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
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".