[FFmpeg-user] Correct conversion of yuvj420p?

[Paul B Mahol]

On Wed, Sep 23, 2020 at 11:31:43PM +0200, Peter B. wrote:
> 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?

What is wrong with my 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.
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
> 
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".