[FFmpeg-user] Correct conversion of yuvj420p?

[Peter B.]

Hi Ted,

On 11.09.20 14:03, Ted Park wrote:
>>> My problem is, that I have literally hundreds (actually more than 1000+) of
>>> these H.264/yuvj420p files that are to be auto-converted to archival FFV1,
>>> but because of the "j" the "pix_fmt +" option cannot be used, which throws
>>> all those files into error - and I'd like to fix this :)
> setrange affects the frames, not any end result SPS i think. Leaving it out doesn’t set the parameters? Does it convert to limited range by default?

I'm still looking for a way to automatically transcode yuvj420p files 
along with other pix_fmts to FFV1, while keeping "-pix_fmt +" to make 
sure no silent conversions are happening.

Does anyone have a suggestion?


I currently have to fish out all yuvj420p files, because they require a 
different recipe than all other source files. This behavior doesn't seem 
technically necessary. Why do "yuv420p+colorinfo" files (created with 
FFmpeg) revert back to being interpreted as yuvj420p? I thought it's 
deprecated?
Not complaining, I'd just like to understand this behavior :)

How do I create a non-yuvj420p file - while keeping colorinfo proper?
btw: MediaInfo shows no difference between yuv420p+colorinfo and 
yuvj420p. Here's a related thread:
https://github.com/MediaArea/MediaInfo/issues/484


As long as the content hashcodes of the image data is identical and the 
color interpretation metadata set to correct values (=identical to the 
source), according to ffprobe - my _Archival Spidersenses(tm)_ are 
satisfied.

Am I overlooking something?


> Also, what are some of the benefits of reencoding footage for archival? I can maybe think of being able to detect partial corruption and possibly a increase in data/bitrate, but not much else.

Data format normalization is a thing.
It even helps to rewrap the container with "-c copy". Stabilizes 
behavior when dealing with different applications. Normalizing the 
codecs without loss is an additional plus.

Imagine dealing with thousands of recordings in the colorful rainbow 
variety of media formats over several decades from several sources. It's 
great fun actually! (when getting the time and resources to hack a bunch 
of bytes into making sense ;))

You wouldn't believe how many "dialects" of H.264/MP4 I encounter on a 
daily basis.

Yes it significantly increases the datarate, but it makes it possible to 
actually make our archival content as seamlessly accessible as possible. 
There's lots of custom ffmpeg-auto-transcode scripts running to fill 
archive's websites. In order to keep the data corruption at zero, we use 
content- and file-hashcodes to validate any changes to the archival 
recordings.
That's also great fun, actually! :)



Still grateful for a "-pix_fmt +" suggestion :)
Thanks!
Peter B.