mov atom

[James]

> On 8 Sep 2023, at 6:31 am, James via gstreamer-devel <gstreamer-devel at lists.freedesktop.org> wrote:
> 
> 
> 
>> 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
> 
untrunc from github works perfectly.
James