<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi James,</p>
<p><br>
</p>
<p>I can't provide any other method to recover your files, but some
comments that may help below.<br>
</p>
<p><br>
</p>
<p><b>Untrunc:</b><br>
</p>
<p>untrunc is really easy to use if you have a working MP4 from the
same camera and the necessary tools (<b>git</b> and <b>docker</b>).</p>
<p><i>#do once to build image:</i><br>
</p>
<p> git clone <a class="moz-txt-link-freetext" href="https://github.com/ponchio/untrunc.git">https://github.com/ponchio/untrunc.git</a><br>
cd untrunc<br>
docker build -t untrunc .</p>
<p><br>
</p>
<p><i>#do each time to fix files (uses docker image just built)</i><br>
</p>
<p> #assuming files are in same directory called '/my/dir'<br>
</p>
<p> docker run --rm -v /my/dir:/files -w /files untrunc
working_file.mp4 broken_file.mp4</p>
<p><br>
</p>
<p><b>Avoiding issues on new files</b>:</p>
<p>gst-launch-1.0 <b>-e</b><br>
</p>
<p> -e, --eos-on-shutdown<br>
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.<br>
</p>
<p><br>
</p>
<p>Custom pipelines: A similar approach can be applied with your
own pipeline if you catch the signals that trigger application
shutdown.</p>
<p><br>
</p>
<p>The following element properties on <b>mp4mux:</b><br>
</p>
<p> reserved-max-duration: When set to a value > 0, reserves
space for index tables at the beginning of the file.<br>
flags: readable, writable<br>
Unsigned Integer64. Range: 0 -
18446744073709551615 Default: 18446744073709551615<br>
reserved-moov-update-period: When used with
reserved-max-duration, periodically updates the index tables with
information muxed so far.<br>
flags: readable, writable<br>
Unsigned Integer64. Range: 0 -
18446744073709551615 Default: 18446744073709551615<br>
</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p><br>
</p>
<p>I've also seen the following element properties on <b>mp4mux:</b></p>
<p> 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)<br>
flags: readable, writable<br>
String. Default: null</p>
<p><br>
</p>
<p>And the pipeline element: <b>qtmoovrecover</b></p>
<p><i>(see gst-inspect-1.0 qtmoovrecover for more info!)</i><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>Hope some of that is useful!</p>
<p><br>
</p>
<p>Will.<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 07/09/2023 04:53, James via
gstreamer-devel wrote:<br>
</div>
<blockquote type="cite"
cite="mid:8c46122a-64bd-b46a-ac32-3b5fb65047ab@tigger.ws">If one
aborts recording an mp4 file the mov atom is faulty or missing and
the recording wont play.
<br>
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.
<br>
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?
<br>
Thanks
<br>
James
<br>
</blockquote>
</body>
</html>