Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
9th March 2022, 06:44 | #1 | Link | |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
|
Encoding XDCAM HD422 with ffmpeg for compatibility and max quality
Hello!
I'm having to implement XDCAM HD422 encoding (in 2022 lol) and am using ffmpeg to do it, so I'm using their MPEG-2 encoder. Based on some digging, here's the settings I'm using for 1080i29.97 content. Any suggestions on how I can improve quality? Quote:
These encodes compare pretty well with the Mainconcept encoder in Adobe Media Encoder, but I do think the latter is still a bit better. Can I squeeze any more out of ffmpeg?
__________________
These are all my personal statements, not those of my employer :) |
|
9th March 2022, 19:10 | #3 | Link | ||||
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
|
Quote:
Quote:
Quote:
Quote:
__________________
These are all my personal statements, not those of my employer :) |
||||
9th March 2022, 20:42 | #4 | Link | ||
Registered User
Join Date: Dec 2013
Posts: 347
|
I do not know if -pix_fmt yuv422p is enough to trigger 422 Profile @ High Level signaling in ffmpeg. Maybe "-profile 422 -level high" will help because High Profile supports 422 as well. And I do not think ffmpeg does Level Limit checking.
I would drop -qmax or set it to 28 if you really want to use -non_linear_quant, don't know if vbv constraints are upheld in complex content otherwise. I do not think mpeg2 has a syntax element for chroma_sample_location; And 422 formats do not have a concept of chroma being "topleft", only "left". The matrices being not flat matters if quality is high on clean, non-dithered content. It being the ffmpeg encoder quality wont get too high probably though. The ffmpeg mpeg2 encoder kicks the shit out of mpeg2 encoders from the late 90s but is not modern in any way. There have been some additions over time that help somewhat. So I would do two passes and add the following: Quote:
Shameless plug: Before you give the resulting quality a pass, maybe try what y262 can do. Although it is very rough around the edges with limited error checking its pretty close to x264 'veryslow' tool wise at the core. It aims to be pretty and not fast. https://github.com/rwillenbacher/y262 2-pass: Quote:
|
||
10th March 2022, 08:56 | #5 | Link | |
Broadcast Encoder
Join Date: Nov 2013
Location: Royal Borough of Kensington & Chelsea, UK
Posts: 2,902
|
XDCAM is still well widespread across broadcasters for FULL HD materials.
This is mostly due to the fact that most of them used MPEG-2 for SD with standards like IMX30 and IMX50 and decided to stick with the same codec for FULL HD by using XDCAM-50. There has been XDCAM-85 for a very brief moment but it has never really been officially supported and has never been as widespread as the 50 Mbit/s variant was. Most playout ports still rely on it like Harmonic Omneon playout ports. This being said, this is the command line created automatically by FFAStrans (the free software we work on) for XDCAM encodes in 25i using the built-in FFMpeg MPEG-2 encoder when Avisynth delivers 50p input: Quote:
About the chroma sample location, top_left is right in the sense that top_left and left is the same for 4:2:2, we had this discussion in the Avisynth section, however for whatever reason XDCAM files (every one of them I received) had "top_left" specified, so I think we should stick with top_left. 2) Qmin Qmax Unfortunately it really depends on the content. I noticed that you set qmin and qmax to be really low, so you aim for the best quality, however, depending on how complex your scene is, you might end up with a buffer underflow. In such an event, FFMpeg will raise a warning, but the encode will keep going, but of course the quality will be really really bad. In my personal experience, if you want something that always works, you can use -qmax 28, however quality will of course suffer. In FFAStrans we created 4 different quality presets which the user can choose and which will select a different qmin qmax setting. The reason why I say this, is that even something like -qmin 5 -qmax 25 ended up with some buffer issue in some scenarios. 3) Open GOP vs Closed GOP Ask the one you're sending the file to. The overwhelming majority require closed GOP as per their specs for legacy reasons and have software like Cerify, Aurora, Baton etc set to check the closed GOP. You can achieve closed GOP with: -flags +cgop Some playout ports might play Open GOP files as well just fine, but it really depends on who you're sending those files to. 4) Wrong GOP issues Unfortunately, in FFMpeg, even if you specify something like: Code:
-g 12 -bf 2 -mpv_flags +strict_gop 5) container No matter what, do not, ever, use the FFMpeg mxf muxer unless you really really really have to. I've had several regressions over the past 7 years and I've been one of the very first people to report them every time and after a while I've said: enough is enough. The built-in mxf muxer is rather sloppy and has several issues, so once your file is encoded, I would strongly suggest you to remux it with BBC BMX Transwrap, which is the official BBC MXF Muxer. Ever since I moved to it, I've never had any issues. The good thing is that you don't have to wait for the encode to finish, you can pipe the FFMpeg output to bmx and let it mux it on the fly while the file is in encoding, thus saving time. There are other muxers like ommcp which is the one made by Harmonic which is the creator of Omneon, however is a paid muxer which is licensed to those using Omneon playback ports etc (but it has its flaws too, just saying...). |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|