Is there a way to recover an interrupted ProRes 4444 encoding?

[Cary Knoop]

I was running a Vapoursynth script for about 7 hours with a few more hours to go when I got the BSOD.

Is there a way to recover the frames that were already encoded?

FFMpeg message I get is:

moov atom not found
video.mov: Invalid data found when processing input

[richardpl]

You are very lucky, prores frames have size and signature at start. so you can recover it easily with little of coding. Is there audio too?

Next time use better container for encoding, like mkv.

[Cary Knoop]

You are very lucky, prores frames have size and signature at start. so you can recover it easily with little of coding. Is there audio too?
Ok, so how do I recover?

No audio.

[richardpl]

I'm unaware of existing tool that does it already. But as already said, program can be coded and build in few minutes and than it will recover all video frames in few seconds when run on such file.

[benwaggoner]

Ok, so how do I recover?

No audio.
Remuxing it through mp4box might do the trick. Or with ffmpeg.

Some tools add audio while writing video, others may do all the audio at the end. The .mov file format is extremely flexible. If there is an audio track in the file, remuxing might salvage that as well.

[Cary Knoop]

Remuxing it through mp4box might do the trick. Or with ffmpeg.

I tried that without success.

It's not the end of the world, just a lot of wasted electricity and time. :)

[ChaosKing]

I tried different tools for the exact same problem but it was a mp4 instead of a mov. Never could rescue anything. That is why I use mkv now, lesson learned!

[Cary Knoop]

I tried different tools for the exact same problem but it was a mp4 instead of a mov. Never could rescue anything. That is why I use mkv now, lesson learned!
Cool, using Matroska works!
Interrupting the encoding still allows viewing the already encoded frames!

ffmpeg -i test.mov -c:v prores_ks -profile:v 4444 -pix_fmt yuva444p10le test.mkv

[kolak]

If mov is readable by ffmpeg then you should not need to re-encode. You can try to use copy.

[LoRd_MuldeR]

Cool, using Matroska works!
Interrupting the encoding still allows viewing the already encoded frames!

It's because in MP4/MOV all the frames/samples are actually stored in one giant monolithic block, that contains no "packet headers", "sync bytes" or whatsoever to indicate the frame boundaries :scared:

The really only way (except maybe by using some heuristics) to locate individual frames within a MP4/MOV file is by using the "sample size", "sample to chunk" and "chunk offset" tables.

Unfortunately, these tables usually will be written at the very end of the file, after all the frames have been written. So, if the encoding process is interrupted, these tables have not been written yet - and you are pretty much screwed.

MKV, on the other hand, is based on EBML, a "binary" variant of XML. It means that, in a MKV file, each frame is wrapped in its own separate EBML element. This can be recovered quite easily, even from an "incomplete" file.

[Cary Knoop]

It's because in MP4/MOV all the frames/samples are actually stored in one giant monolithic block, that contains no "packet headers", "sync bytes" or whatsoever to indicate the frame boundaries :scared:

The really only way (except maybe by using some heuristics) to locate individual frames within a MP4/MOV file is by using the "sample size", "sample to chunk" and "chunk offset" tables.

Unfortunately, these tables usually will be written at the very end of the file, after all the frames have been written. So, if the encoding process is interrupted, these tables have not been written yet - and you are pretty much screwed.

MKV, on the other hand, is based on EBML, a "binary" variant of XML. It means that, in a MKV file, each frame is wrapped in its own separate EBML element. This can be recovered quite easily, even from an "incomplete" file.
Thanks for that info.

From now on it is going to be mkv all the way!

[Blue_MiSfit]

It's because in MP4/MOV all the frames/samples are actually stored in one giant monolithic block, that contains no "packet headers", "sync bytes" or whatsoever to indicate the frame boundaries :scared:

The really only way (except maybe by using some heuristics) to locate individual frames within a MP4/MOV file is by using the "sample size", "sample to chunk" and "chunk offset" tables.

Unfortunately, these tables usually will be written at the very end of the file, after all the frames have been written. So, if the encoding process is interrupted, these tables have not been written yet - and you are pretty much screwed.

MKV, on the other hand, is based on EBML, a "binary" variant of XML. It means that, in a MKV file, each frame is wrapped in its own separate EBML element. This can be recovered quite easily, even from an "incomplete" file.

That's actually fantastic information! Thanks for sharing that.

[richardpl]

My offer still stands to recover complete file, unfortunately I do not work for free.

[Cary Knoop]

My offer still stands to recover complete file, unfortunately I do not work for free.
I have already reprocessed the file.

[ChaosKing]

In some cases, like x264 with mkv output, the mkv file has "no index". That it why seeking can take very long with big files. I noticed it with my 40gb lossless encodes. Remuxing the mkv fixes it.

[benwaggoner]

It's because in MP4/MOV all the frames/samples are actually stored in one giant monolithic block, that contains no "packet headers", "sync bytes" or whatsoever to indicate the frame boundaries :scared:

The really only way (except maybe by using some heuristics) to locate individual frames within a MP4/MOV file is by using the "sample size", "sample to chunk" and "chunk offset" tables.

Unfortunately, these tables usually will be written at the very end of the file, after all the frames have been written. So, if the encoding process is interrupted, these tables have not been written yet - and you are pretty much screwed.
If fragmented MP4 (fMP4) is used, recovery is much easier since it will have that data. That's how adaptive bitrate streaming works, as each GOP is independently accessible via a byterange request.

That said, a good remuxing tool can build the index post-hoc by analyzing an existing non-fMP4 file.