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 _______________________________________________ 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".
