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