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@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
