XDCAM Encode / Blockiness

[dklooker]

Hi,

I have an issue where I encode to XDCAM and get random frames with blockiness/artefacts.

Our worklfow is:
Colorgrade in Davinci Resolve (Source is an Avid Videomixdown in OP1A XAVC-Intra 100)
Export to QT DNxHD185X to a watchfolder
FFAStrans encodes this file to XDCAM.

We use this workflow because exporting XDCAM straight from Resolve has a lot of problems. But now it seems FFAStrans has also some minor problem. When I encode/export the same source file with Premiere all is fine.

I have a link for my source and encoded files. Can you see what is going wrong and what I can do to solve this problem? https://we.tl/t-99Km4whe5w

Thanks
David

[emcodem]

Thanks for this, the stuff you delivered makes your point very clear.
We have been testing and discussing this a lot, its a really interesting topic. Chances are given that a future ffastrans version will benefit from this.

Meanwhile you can try to "workaround".
So from our analyzing, the difference between premiere and our version is that premiere puts less bitrate on I-frames which gives the rest of the frames, so B and P frames more bitrate which leads to a little bit less quality on the I Frames (little less sharp maybe) but more quality on the others in case of high motion and detail.

We played with qmin and qmax values and it looks like a good result is -qmin 5 -qmax 23 (instead of the original -qmin 3 -qmax 28 ).

As your input file should be always the same format, audio channels etc, you can use this in a commandline executor. This example will transcode the output file to the same location where the input is but add _transcoded.mxf - So you dont need to use a deliver node.

Code: Select all

%comspec% /C ""%s_ffmpeg%" -nostdin -hide_banner -analyzeduration 33554432 -i "%s_source%" -f lavfi -i "aevalsrc=0" -f lavfi -i "color=color=black:size=1920x1080" -shortest -map_metadata -1 -map 0:0 -filter_complex "[0:1]pan=1|c0=c0[a1],[0:1]pan=1|c0=c1[a2],[0:1]pan=1|c0=0*c0[a3],[0:1]pan=1|c0=0*c0[a4],[0:1]pan=1|c0=0*c0[a5],[0:1]pan=1|c0=0*c0[a6],[0:1]pan=1|c0=0*c0[a7],[0:1]pan=1|c0=0*c0[a8],[a1]amerge=1,apad[astr1],[a2]amerge=1,apad[astr2],[a3]amerge=1,apad[astr3],[a4]amerge=1,apad[astr4],[a5]amerge=1,apad[astr5],[a6]amerge=1,apad[astr6],[a7]amerge=1,apad[astr7],[a8]amerge=1,apad[astr8]" -map "[astr1]" -c:a:0 pcm_s24le -ar:a:0 48000 -map "[astr2]" -c:a:1 pcm_s24le -ar:a:1 48000 -map "[astr3]" -c:a:2 pcm_s24le -ar:a:2 48000 -map "[astr4]" -c:a:3 pcm_s24le -ar:a:3 48000 -map "[astr5]" -c:a:4 pcm_s24le -ar:a:4 48000 -map "[astr6]" -c:a:5 pcm_s24le -ar:a:5 48000 -map "[astr7]" -c:a:6 pcm_s24le -ar:a:6 48000 -map "[astr8]" -c:a:7 pcm_s24le -ar:a:7 48000 -vf "il=l=d:c=d,colorspace=fast=1:all=bt709:format=yuv422p:ispace=bt709:itrc=bt709:iprimaries=bt709,il=l=i:c=i,fps=25,setfield=tff,setdar=16/9,setsar=1" -timecode 00:13:45:00 -c:v mpeg2video -r 25 -pix_fmt yuv422p -aspect 16:9 -intra_vlc 1 -b:v 50000000 -minrate 50000000 -maxrate 50000000 -bf 2 -bufsize 17825792 -rc_init_occupancy 17825792 -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 5 -qmax 23 -g 12 -field_order tt -top 1 -alternate_scan 1 -flags +ildct+ilme -intra_matrix 8,10,22,27,29,37,37,40,9,12,14,28,29,37,39,40,9,14,27,31,34,37,40,48,12,22,27,29,34,37,40,58,26,27,29,34,37,38,48,58,26,27,29,36,38,38,48,69,18,27,34,36,38,38,48,69,26,26,34,34,38,40,58,79 -inter_matrix 16,20,22,26,28,32,32,36,18,20,22,28,28,32,34,36,18,22,26,30,30,32,36,38,20,22,26,28,30,32,36,42,24,26,28,30,32,34,38,40,24,26,28,32,34,34,38,42,24,26,30,32,34,34,38,42,24,24,30,30,34,36,40,44 -f mxf -max_muxing_queue_size 700 -map_metadata -1 -metadata "creation_time=now" -y "%s_source%_transcoded.mxf""

Let me know any question!

[dklooker]

Hi!

Great. It looks better, but still premiere pro has a better quality. Can I play with qmin and qmax for a little experimenting? Because I think we can assign more bittrate to the B and P frames. I will then compare in resolve with a differencekey.


Greetings,
David

[dklooker]

So for example qmin 3 qmax 20. I read that lowering qmax below 16 wil not improve anything visible. This will not have any influence on the bitrate?

[FranceBB]

Well, you're right about the MPEG-2 encoder in FFMpeg for XDCAM-50 files, we definitely noticed that by default far too many bits are assigned to the Intra and then you end up not having enough in the P and B with some visible artifacts, including blocking. The idea behind the default implementation in FFMpeg is that by providing lots of bits for the Intra, the partially and bi-predicted frames will benefit from it as well, however in practice, with real life contents, this doesn't happen and motion-compensation ain't that good either (mostly due to the 8bit precision calculations), leading to some unpleasant results. We've compared the Intra, P and B weight of the same source encoded with FFMpeg in MPEG-2 and with Adobe Premiere and we noticed that in Premiere Intra had far less bitrate so that it was possible to spend a few more bits on other frames as well.

This is the output of the default FFMpeg MPEG-2 Encode:

pkt_size=728158 I
pkt_size=270192 B
pkt_size=272571 B
pkt_size=478986 P
pkt_size=291032 B
pkt_size=292296 B
pkt_size=476047 P
pkt_size=127445 B
pkt_size=125467 B
pkt_size=287332 P
pkt_size=114072 B
pkt_size=147912 B
pkt_size=634226 I

and this is the same output from Adobe Premiere, both XDCAM-50:

pkt_size=453083 I
pkt_size=272350 B
pkt_size=218458 B
pkt_size=271059 P
pkt_size=192891 B
pkt_size=160016 B
pkt_size=262221 P
pkt_size=167412 B
pkt_size=162420 B
pkt_size=291359 P
pkt_size=158137 B
pkt_size=172380 B

This is what happens when setting these are the sizes with -qmin 5 -qmax 23 while still restraining the bitrate to 50 Mbit/s with the maxrate and bufsize to comply with XDCAM:

pkt_size=562788
pkt_size=204708
pkt_size=206329
pkt_size=275843
pkt_size=222392
pkt_size=223566
pkt_size=272964
pkt_size=202808
pkt_size=209773
pkt_size=292136
pkt_size=145158
pkt_size=196166

Which makes the whole bitrate distribution much more evenly spread, however we haven't been using it in production just yet, but you can definitely play with qmin and qmax yourself to "improve" things further (well, actually decide whether it's worth taking away more bits from Intra and assign them to P and B) but just make sure that you don't hit any vbv error (ffmpeg will tell you that anyway if it occurs).
Besides, if you're going to do it, please report back to us so that the whole community can benefit from it.


Bonus tip: If you don't mind about speed and quality is an absolute must for you, you should consider having a two pass encode. This way, you won't have to rely on the lookahead and the encoder will know exactly the complexity of the whole stream, therefore it's gonna be able to encode it in the best way possible as the first pass generates the stats and the second one encodes the file. In my tests, I've noticed a rather significant performance improvement, so we have been discussing internally whether it would be worth adding the option to have a two pass XDCAM-50 encode or not, but I can't guarantee anything.

[dklooker]

Hi,

We tried some different qmin / qmax settings but we cannot get near the quality of premiere with this example footage.

I also checked with other videofiles and there is actualy no noticable quality difference so I also suspect it has to do with the source material that does not work quite good with ffmpeg.

Are there more factors that I can tweak in the ffmpeg line? Maybe some sort of brickwall limiting of some sort?

Thanks in advance

David

[emcodem]

@dklooker

how did you judge the quality? We did some ssim checks and -qmin 5 -qmax 23 was pretty close to the premiere version...

[FranceBB]

Try with a two pass encode rather than using a single pass based on lookahead frames:

Code: Select all

ffmpeg.exe -i "\\mibctvan000\Ingest\MEDIA\temp\AVS Script.avs" -pix_fmt yuv422p -vcodec mpeg2video -s 1920:1080 -aspect 16:9 -vf setfield=tff -flags +ildct+ilme+cgop -b_strategy 0 -mpv_flags +strict_gop -sc_threshold 1000000000 -r 25 -b:v 50000k -minrate 50000k -maxrate 50000k -bufsize 36408333 -g 12 -bf 2 -profile:v 0 -level:v 2 -color_range 1 -color_primaries 1 -color_trc 1 -colorspace 1 -pass 1 -an -f mxf NUL

ffmpeg.exe -i "\\mibctvan000\Ingest\MEDIA\temp\AVS Script.avs" -pix_fmt yuv422p -vcodec mpeg2video -s 1920:1080 -aspect 16:9 -vf setfield=tff -flags +ildct+ilme+cgop -b_strategy 0 -mpv_flags +strict_gop -sc_threshold 1000000000 -r 25 -b:v 50000k -minrate 50000k -maxrate 50000k -bufsize 36408333 -g 12 -bf 2 -profile:v 0 -level:v 2 -color_range 1 -color_primaries 1 -color_trc 1 -colorspace 1 -pass 2 -y "\\mibctvan000\Ingest\MEDIA\temp\raw_video.mxf"

ffmpeg.exe -i "\\mibctvan000\Ingest\MEDIA\temp\AVS Script.avs" -c:a pcm_s24le -ar 48000 -af loudnorm=I=-24:LRA=12:tp=-2 -f wav -y "\\mibctvan000\Ingest\MEDIA\temp\audio.wav"

ffmpeg.exe -i "\\mibctvan000\Ingest\MEDIA\temp\raw_video.mxf" -i "\\mibctvan000\Ingest\MEDIA\temp\audio.wav" -c:v copy -c:a copy -f mxf -y "\\mibctvan000\Ingest\MEDIA\temp\pre-final_output.mxf"

bmxtranswrap.exe -p -y 10:00:00:00 -t op1a -o "\\mibctvan000\Ingest\MEDIA\temp\final_output.mxf" "\\mibctvan000\Ingest\MEDIA\temp\pre-final_output.mxf"

pause

[dklooker]

Hi,

I tried qmin5 qmax23 and compared in Premiere switching videotracks. And you can clearly see that FFMPEG exposes more blocks in the dress. But the complete picture gets less detail al together!

[emcodem]

The problem with the qmin and max stuff is that - depending on the picture content- different settings can easily lead to some buffer issues and ffmpeg fails to encode in that case. So we'd need to find not only the best setting for quality but also one that works stable with any picture content.

@dklooker
did you try the 2-pass from @FranceBB ? He didnt yet deliver any results or comparisons internally
also, did you try to increase/decrease qmin qmax in a way that the frame sizes match even more the ones from adobe?