[FFmpeg-user] Verifying lossless rewrapping/transcoding in one step?

Peter B. pb at das-werkstatt.com
Mon Aug 5 17:16:41 EEST 2019


Dear Moritz,

Thank you for your explanation!


On 03/08/2019 14:07, Moritz Barsnick wrote:
> I believe in using the right tools for the right tasks. If it can be
> glued together with a script, why worry about modifying an existing
> program to do the same?

I completely agree, but... ;)

One reason (for me) is that I haven't found a generic way to script this
check for inhomogenous source material. I don't know how many A/V
streams, in which configuration, etc. I know I can ffprobe, then parse,
etc - but:

The 2nd reason (also for me) is, that I've now written the same
functionality in different scripts for slightly different use cases.

And the 3rd reason (for me...) is:
It's actually not-so-trivial to explain this validation-check approach
when I do FFmpeg workshops (for commandline newbies, and people who
don't know what a "diff" even is)


:D


> That said, regarding your request, I believe the showstopper is in the
> concept: To re-calculate the checksum of the output, it needs to be
> decoded again. That's not something ffmpeg can do within its binary, it
> can't use the output and chain it as its own input.

That's a very interesting insight!
Thank you very much. I was sure there's a reason, but now I finally
know. Thank you!


> That's my take on it: Way too much effort for the gain.

Hm...
I'm thinking about how (under the given circumstances you've mentioned),
this could still be made a bit "easier"...

Would it be possible to, for example, modify the hash muxer to output a
hash for each stream - in a way that one could easily parse that
textfile and know which hash belongs to which stream?

For example, instead of "CRC32=...." let's say:
"v:0:CRC32=...
v:1:CRC32=...
a:0:CRC32...
a:1:CRC32...
a:2...
"

Something like that.
Just an idea... :D


Thank you very much again!
Peter




More information about the ffmpeg-user mailing list