Repaired video "too long" and won't play

[dopeless]

Repaired video "too long" and won't play

[ponchio]

Sure, send it! I have already seen some videos with multiple audio channels, but usually the problem is that the different audio gets mixed. I will gladly have a look. F.

…

On Mon, Apr 15, 2024 at 9:38 PM dopeless ***@***.***> wrote: Ciao, I've tried to repair some prores videos from Aromos Ninja 5 with no luck. The created file won't play, and it's length is some 10 times longer, that it should be I've also tried the forked version (https://github.com/anthwlock/untrunc) - it could restore video, but sound is a white noise. I've tried Grau - it restores video, but audio alternates between normal sound and white noise. I've got four audio channels, and i think that's the problem (I've read multiple threads about problems with multichannel sound). But I'm pretty sure, the video can be fully restored. Can I send you a sample to take a look? Thank you. — Reply to this email directly, view it on GitHub <#280>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUDV27UQ4CU2PIZE6MYMQTY5QUDVAVCNFSM6AAAAABGH63JPKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI2DINBWGY4DEMQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[dopeless]

Hello, have you had a chance to take a look at the videos? I've sent them to you via email a month ago, and still got no answer. Thanks.

[ponchio]

Hi, it took me a while because of the codec and some nasty behaviour of the encoder (coupled with a pretty busy month), but yes, I managed: You can recover the video here: http://78.134.70.236/baby.mp4 Actually the problem was not the number of channels but a very strange thing.[ Raw audio (non compressed) is just values (usually 16 bits or 24 bits) interleaved (channel 0, 1, 2, 3, 0, 1, 2, 3...) and a certain number consecutive samples are stored in a chunk. The formula to compute the size of the chunk is (bits/8)*channels*number of samples, in your case the reported number of channels is 24024. BUT the chunks are actually composed of 24064 samples. It took me a while to discover this discrepancy. I have no idea, why! That's the reason for the alternating noise. There was some other small problems (tmcd codec is tricky, and I had to just look for the first video packet). In case you want to reproduce it you need to pull the code, uncomment a line in codec_pcm (left as a reminder for myself) and use the option -b 99840 to find the first video packet starting point. Ciao, Federico.

…

On Tue, May 14, 2024 at 12:36 PM dopeless ***@***.***> wrote: Hello, have you had a chance to take a look at the videos? I've sent them to you via email a month ago, and still got no answer. Thanks. — Reply to this email directly, view it on GitHub <#280 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAUDV24P6TEWWROAJ4WMBOLZCHSJVAVCNFSM6AAAAABGH63JPKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBZHA2TQMRVGY> . You are receiving this because you commented.Message ID: ***@***.***>

[dopeless]

Hi, first of all - thank you so much for taking time to fix it.
I've tried to fix it myself, as you described - and it really works! The video is fully restored!
But how can i calculate (or at least estimate) the samples count for other videos?
I mean, how can I get the reported number, and if I get it - do I need just to guess the real working number, or is there some way you've got the 24064?
Now I'm very close to get all the videos restored, hope for the last bit of help from you )
Thanks again.

P.S. And what does the -b option do?

[ponchio]

As you know you need a working video with the same characteristics.

if you run untrunc -a good.mp4, you will see each chunk size and offset. In your case the size reported is 288288 which /12 is 24024 (because it is computed from the data written in the atom stsz.
BUT if you check the distance from the offset of an audio packet (for example the first packet is 51799040) and the offset of the next video packet 52087808, it is 288768 (or 24064x12).

This can happens usually for padding (zero or random) , but in your case the additional 480 bytes seems filled with audio samples, can for memory alighment, for page allocations etc.

In your case the extra length is constant, contains audio, the sequence of video/audio is very regular, it could very possibly that I am wrong in interpreting the values (I tried to follo the documentation, but it sucks, when it exists).

Anyway unless you changed the audio parameters it is very likely that all the mp4 have the same problem and solution.

-b instructs untrunc on where the mdat (the atom containing the packets) starts, we only need to point it at the beginning of packet and in our case video packets are easier to spot.

If you want to spot a video packet use a hexeditor (bless for ubuntu works great), search for the ascii text "icpf", and the video packet starts 4 bytes before (works only for your video codec apch, obviously) (you can use the -a options to get the offsets in the good video).

[dopeless]

That was much mor, than a "bit".
Everything seems more or less clear now.
I'll try to fix some videos on the weekend.
Thank you one more time.