Page 1 of 1

Interrupting processing of a damaged file

Posted: Mon Aug 11, 2025 1:22 pm
by DCCentR
Hi, cool user of FFAStrans! :)

I have encountered cases where damaged files (mp4, mxf) were successfully processed by the FFmpeg processor. This is understandable.

And I see that when processing with the FFmpeg processor, the file being processed is first checked by mediainfo. Mediainfo can detect integrity violations in mp4 and mxf files by marking them with the “IsTruncated” attribute:
Снимок экрана 2025-08-11 162248.png
Снимок экрана 2025-08-11 162248.png (161.75 KiB) Viewed 65732 times
I am wondering if it is possible to use this “standard” check to interrupt processing and terminate with an error?

Of course, I made a small CMD utility in Python that checks the file using Mediainfo and returns codes 0 or 1 upon completion, which can then be used by other processors in FFAStrans. But still, I wonder if there is a simpler solution? :?:

Re: Interrupting processing of a damaged file

Posted: Mon Aug 11, 2025 8:05 pm
by FranceBB
There absolutely is. :)
FFAStrans performs the ffprobe, exiftools and Mediainfo analysis of every incoming file.
The output of the analysis is always stored in the following variable: %s_info_mediainfo%
It's stored as a JSON and you can read it and have conditional nodes making decisions based on it.
In particular, it's gonna be in MediaInfo.General.IsTruncated, so you can just write a conditional that checks that section of the JSON to see if it's there and set to "Yes" so that the file is skipped and won't get processed. :)

Untested, but I think that in this case it would be something like:

Code: Select all

if $jsonget('%s_info_mediainfo%', 'General.IsTruncated) == "Yes"
then %s_error% = "File is Truncated!"
else keep going
By the way, the reason why we keep going by default is that, within FFAStrans, the motto is "if it exists, it must be decoded", so we're literally trying to do the best we can to always keep going in any situation for any file. This is true not just for the normal decoding but also for the indexers we're calling like FFVideoSource(), FFAudioSource() and BestAudioSource(). If a file is corrupted at some point, the indexer will duplicate the previous frame to fill the gap and it will keep going and in the same way I have a pull request pending for FFAudioSource() that will fill the audio with silence if there's a CRC error at some point and we're just gonna keep going.

I know that this *might* be undesirable for content processing when you're dealing with movies and tv series for instance, but think about production departments collecting shootings from everywhere or even partially corrupted files recorded on a mobile phone by people close to a natural disaster that sent those to our news channel: saving as much as we can to make it go on air is invaluable and that's why we do it.

By the way, whenever this happens, we always register it in the logs and you're gonna be able to see it from the Job Details anyway. :)

Re: Interrupting processing of a damaged file

Posted: Wed Sep 03, 2025 8:03 am
by DCCentR
FranceBB wrote: Mon Aug 11, 2025 8:05 pm There absolutely is. :)
FFAStrans performs the ffprobe, exiftools and Mediainfo analysis of every incoming file.
The output of the analysis is always stored in the following variable: %s_info_mediainfo%
It's stored as a JSON and you can read it and have conditional nodes making decisions based on it.
In particular, it's gonna be in MediaInfo.General.IsTruncated, so you can just write a conditional that checks that section of the JSON to see if it's there and set to "Yes" so that the file is skipped and won't get processed. :)

Untested, but I think that in this case it would be something like:

Code: Select all

if $jsonget('%s_info_mediainfo%', 'General.IsTruncated) == "Yes"
then %s_error% = "File is Truncated!"
else keep going
By the way, the reason why we keep going by default is that, within FFAStrans, the motto is "if it exists, it must be decoded", so we're literally trying to do the best we can to always keep going in any situation for any file. This is true not just for the normal decoding but also for the indexers we're calling like FFVideoSource(), FFAudioSource() and BestAudioSource(). If a file is corrupted at some point, the indexer will duplicate the previous frame to fill the gap and it will keep going and in the same way I have a pull request pending for FFAudioSource() that will fill the audio with silence if there's a CRC error at some point and we're just gonna keep going.

I know that this *might* be undesirable for content processing when you're dealing with movies and tv series for instance, but think about production departments collecting shootings from everywhere or even partially corrupted files recorded on a mobile phone by people close to a natural disaster that sent those to our news channel: saving as much as we can to make it go on air is invaluable and that's why we do it.

By the way, whenever this happens, we always register it in the logs and you're gonna be able to see it from the Job Details anyway. :)
Thanks for the tip! Wil try this way