FFMPEG to convert yuvj420p to yuv420p without chroma shifting?

[Cyrax9]

I guess this is sort of two questions, but basically, is it even possible to convert yuvj420p to yuv420p, and more importantly, is it possible to do so in FFMPEG without any chroma or luma-shifting? Basically, it's my understanding that the reason yuvj420p is deprecated in FFMPEG is because there's a way to store the same data in yuv420p now. Is this correct, or am I completely missing the mark?

The problem:
I have some videos from a camera that shoots in yuvj420p. This is a relatively recent piece of gear, (released in 2022, actively still on sale as a current model literally as I'm typing this,) not obsolete by any measure, but the pixel format is causing me some issues. I want to transcode the footage to FFV1 and potentially run it through Topaz Video AI for some light noise reduction and sharpening, but Topaz is causing massive color and luma shifts with yuvj420p that it doesn't cause with yuv420p, and just transcoding to FFV1 is creating similar problems. Is there a way to convert yuvj420p into another format like yuv420p or yuv420p10le and not have these massive color shifts so that I can feed the mathematically lossless converted footage into TVAI and do the sharpening/noise reduction without having to do a bunch of color correction? Basically, I want to be able to literally just relink these clips in my editing software by pointing it to the versions from TVAI with the noise reduction and sharpening and not have to color correct the color corrections of original clips where corrections/grading have already been done. Any help would be greatly appreciated, thank you everyone.

Please note that although I'm doing this on a Mac, I would think the process should be the same for Windows/macOS/Linux since FFMPEG is cross-platform, as is my editing software. (And the problem with TVAI not recognizing yuvj420 for that matter, or offering full libx264 support under Windows or any libx264 support under macOS.)

[davexnet]

See if there is anything useful here:
https://stackoverflow.com/questions/30703987/convert-format-from-yuvj420p-to-yuv420p

[Cyrax9]

Thanks for the link, Davexnet. Unfortunately, that was literally what I started with when I began trying to figure this out before I posted here. I tried the

-vf "in_range=mpeg:out_range=full"

trick, but it still results in noticeable luma-shifting, (and thus noticeable color shifting,) as if something isn't being converted properly. I also tried replacing "mpeg" in the command with "tv" and "limited," and "full" with "jpeg" and "pc," just in case the way that FFMPEG behaves when those synonyms are used is slightly different, but I didn't notice a difference. (I didn't test every possible combination of them, but I wasn't seeing any difference at all.) My next step is probably going to be trying different codecs to see if one interprets the data correctly.

The closest I've gotten to an accurate output has been to use the video filter command above while converting to yuv444p10le, resulting in a file that's oversaturated, and to then feed that file through ffmpeg a second time applying a Zscale filter with the same input and output range data, (bt709 for trc, primaries and colorspace, and "pc" for range,) but this feels like overkill for something that's still glaringly incorrect. I've set my output format to yuv444p10le on the file created from the FFV1 file to avoid converting colorspaces twice, and to yuvj420p just to see if the issue was the result of remaining in a wider color gamut, but the output files had the same issue and looked largely identical to each other, but not to the input file. I'm still not sure why the Zscale filter gets things closer to where they should be during the second encode,when it should theoretically do nothing. If I don't filter the second encode and just convert the FFV1 file, I get a video that's excessively oversaturated after telling ffmpeg to use mpeg (limited) range input and full (jpeg) range output. If I flip the ranges and tell ffmpeg that it's a fll range input and I want a limited range output, it creates a video that's excessively desaturated, but never one that looks correct.

The reason I'm using FFV1 is that my editing software doesn't always like when clips are relinked with different parameters related to things like the various timescales. The source files are .MOV with a PCM audio track, and FFV1 doesn't mind being in an .MOV container. VP9 on the other hand won't allow me to store it in an .MOV container, and the encode will fail with the error message that I "must use MP4" for the VP9 codec. The problem there is that MP4 doesn't support PCM audio, and I'd have to reencode my audio tracks into a lossy format, which I don't want to do. Likewise, aside from the fact that my editing software doesn't recognize it, .MKV is incapable of having a "movie_timescale" or "video_track_timescale" setting of anything other than 1000, and I need both of those settings to be 24000 to avoid the issue I mentioned above where the editing software expects the clips to have the same timescale when they're relinked.

[ProWo]

Try a sample encode of 200 seconds with the following settings, using clever FFmpeg-GUI.


[Attachment 85452 - Click to enlarge]