XDCAM Encode / Blockiness

[FranceBB]

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?

Because I forgot the command you used to see the exact weight of each frame and I was afraid of telling you cause I asked you like two times already and I promised you I saved it last time (which I was sure) but I can't find it anywhere xD

About human like perception, on a footage I tried, I noticed that it's slightly more consistent across frames immediately after a scene change and I saw a bit less blocking in complicated scenes with like smoke, so it seems to be doing something, but still I wouldn't wait so much for all my files, but for movies it might be worth it.

[emcodem]

Code: Select all

ffprobe -select_streams v:0 -show_frames %THEFILE% |findstr pkt_size

Note that ffprobe output is always display order instead of coded order, this is important when comparing with other tools.
Also note that the "XDCAMHD" mpeg2 stream from ffastrans always starts with a GOP of 10 instead of 12, this is because ffmpeg is not able to start with "BBI" (display order) but instead it starts with "PI".. and don't ask me why it's not a first GOP length of 11 then, i didnt yet take a close look at it hehe

So, after all when using this method to compare adobe with ffmpeg, we don't have the I-frames aligned at the same position in the stream, this makes it bit more complex to interpret the frame size comparison unfortunately.

[Ferdinand2021]

Dear all,

just came across the same issue as threadopener with visible blockiness on complex multicopter-footage with lots of detail when encoding to XDAMHD50. (I´m not referring to the interlace flickering, that can result from transcoding ultra sharp footage to 1080i50. I´m specifically referring to block artefacts popping up randomly on encoded xdcamhd frames)

I checked the latest ffastrans version (I was using ffastrans version 1.2.0 until today very happily) and found out that you implemented some tuning option in the XDCAMHD processor. I guess this is exactly related to the thing, setting the qmin and qmax parameters (what needed to be done before in command executor), right?
When choosing "complex" or "very complex" which parameters are set for qmin and qmax?

I wondered a bit about your sentence in the processor description in the wiki "Note if you have high complexity for the set tuning you may encounet encoding anomalies cause the bit rate to become out of spec."

So three questions:
1. it is not recommended to use for example "complex" for all general purpose encodings? How would "encoding anomalies" show themselves, will the encoding just fail or will the encoded footage be corrupt? Just asking, as I often have to procress multicopter-footage with that node and there often I have the situation with lots of detail in picture. So I was hoping to just set it from "Normal" to "Complex" and forget about it

2. I see there are severel new settings in the xdcamhd processor in this new version and I was wondering which thing to choose for GOP and Videorange. GOP "open" and VideoRange "Set to limited", is this the default that was used in the older ffastrans 1.2.0 version, although there wasn´t a switch for that options, right? My usecase is to further edit the files in avid mediacomposer, but without the "create avid project structure" option. Just ama link and consolidate afterwards.

Thank you very much for further developing this great tool.
Best regards,

Ferdinand

[admin]

Hi Ferdinand,

The XDCAM-HD encoder has been a headache for us in the team for a while now. With FFAStrans being a free transcoding/workflow tool we are for now bound to use the unbuilt mpeg2 encoder in ffmpeg. Sadly, it's not top notch when it encounters complex video and it simply cannot stay within the desired bit rate when it's too complex. This is the reason why we have included the tuning options, so that one can squeeze some more quality out of this encoder to match their footage. Luckily, if you're using the file for editing in an NLE or just archiving, you can probably use the "Static" option which is the highest quality setting that make some sense. However, if you're planning to air an FFAStrans encoded XDCAM-HD clip on a hardware playout port you might have issues due to bitrate probably being out of spec. There should be no other artifacts or anomalies other than too high bitrate.
Normally new options are added in order to give the user an option to chose settings that might work better for them. This is also true with the GOP and video range options. Open gop is usually better quality but in this case it's added for the sake of trying to make various decoders happy that expects a certain type. The video range option was earlier set to limited (which is normal for XDCAM-HD) but the option was added bdue to some rewriting of the generic processing logic that enable any encoder to utilize custom video ranges.
As an option to the XDCAM-HD encoder I might suggest using the XAVC or AVC-Intra encoders which will give you much higher quality. Of course this is only viable if your production infrastructure is ready for it.

-steinar

[emcodem]

@Ferdinand2021 (just to send you the notification)
Here also some additional related post about XDCAMHD related and standard conformance:
viewtopic.php?f=5&t=1288&p=7214&hilit=mainconcept#p7218