mov atom

[James]

> On 7 Sep 2023, at 11:07 pm, Will McElderry via gstreamer-devel <gstreamer-devel at lists.freedesktop.org> wrote:
> 
> Hi James,
> 
> 
> 
> I can't provide any other method to recover your files, but some comments that may help below.
> 
> 
> 
> Untrunc:
> 
> untrunc is really easy to use if you have a working MP4 from the same camera and the necessary tools (git and docker).
> 
> #do once to build image:
> 
>     git clone https://github.com/ponchio/untrunc.git
>     cd untrunc
>     docker build -t untrunc .
> 
> 
> 
> #do each time to fix files (uses docker image just built)
> 
>     #assuming files are in same directory called '/my/dir'
> 
>     docker run --rm -v /my/dir:/files -w /files untrunc working_file.mp4 broken_file.mp4
> 
> 
> 
> Avoiding issues on new files:
> 
> gst-launch-1.0 -e
> 
>        -e, --eos-on-shutdown
>                Force an EOS event on sources before shutting the pipeline down. This is useful to make sure muxers create readable files when a muxing pipeline is shut down forcefully via Control-C.
> 
> 
> 
> Custom pipelines:  A similar approach can be applied with your own pipeline if you catch the signals that trigger application shutdown.
> 
> 
> 
> The following element properties on mp4mux:
> 
>   reserved-max-duration: When set to a value > 0, reserves space for index tables at the beginning of the file.
>                         flags: readable, writable
>                         Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 18446744073709551615
>   reserved-moov-update-period: When used with reserved-max-duration, periodically updates the index tables with information muxed so far.
>                         flags: readable, writable
>                         Unsigned Integer64. Range: 0 - 18446744073709551615 Default: 18446744073709551615
> 
> 
> 
> The 'reserved' options are more reliable than '-e' as there are situations where '-e' doesn't catch a termination, but the       'reserved-moov-update-period' property protects against that.
> 
> 
> 
> 
> 
> I've also seen the following element properties on mp4mux:
> 
>   moov-recovery-file  : File to be used to store data for moov atom making movie file recovery possible in case of a crash during muxing. Null for disabled. (Experimental)
>                        flags: readable, writable
>                        String. Default: null
> 
> 
> 
> And the pipeline element: qtmoovrecover
> 
> (see gst-inspect-1.0 qtmoovrecover for more info!)
> 
> I'm not sure if they are a related pair, but I've not been able to get them to work together - so if anyone else can comment that would be very interesting.
> 
> 
> 
> Hope some of that is useful!
> 
> 
> 
> Will.
> 
> 
> 
> On 07/09/2023 04:53, James via gstreamer-devel wrote:
>> If one aborts recording an mp4 file the mov atom is faulty or missing and the recording wont play. 
>> When I first started to play with gstreamer I saw and glossed over a simple pipeline to restore the atom. I can't find it again. 
>> Looking at untrunc the task is complex, and I don't know enough to invent a pipeline. Has anybody seen the tutorial or can think up a solution? 

I have built untrunc from git. 
When I tried, long ago, untrunc choked on gstreamer files. I'll try now.
untrunc now builds from avlib from src and the resultant file is nearly 20 Mb. No big deal but mild concern ...

My app runs on a dive-ship where power is VERY bad, sometimes killing the computer through the UPS. If the recording is the end of a long dive, deep so breathing expensive helium, and any hope of EOS is out the window then recovery is a big deal.
In any event I was casting for ideas, so thankyou
James