mp4 file repair - UPDATE 1

[William Salibrici]

Prabhakar,
Thank you for your reply - you are absolutely right.
I think a problem may be that the approximate recording duration  has to be known in advance to estimate how much free space to reserve  for the moov.
I could probably work with your approach by over-estimating the amount of space  to reserve at the cost of wasting some amount of  free space at the start of file. Now the recording would always carry the wasted free space.
However, using the moov-recovery-file property of the mp4mux [qtmux] creates an additional file for repair and a separate recovery step with the qtmoovrecover element is required. 
Using the reserved-* of the mp4mux eliminates the separate recovery file and this could be advantageous.
I will experiment with your suggestion.

Regards,

Bill

-----Original Message-----
From: gstreamer-devel [mailto:gstreamer-devel-bounces at lists.freedesktop.org] On Behalf Of Lad, Prabhakar
Sent: Thursday, November 09, 2017 4:29 PM
To: Discussion of the development of and with GStreamer <gstreamer-devel at lists.freedesktop.org>
Cc: lists at svrinformatica.it
Subject: Re: mp4 file repair - UPDATE 1

HI,

On Thu, Nov 9, 2017 at 3:00 PM, William Salibrici <bsalibrici at latticeinc.com> wrote:
> I came to that conclusion myself after reading the inspect data sheet 
> for the qtmoovrecover element.
>
> I noticed that it has no pads and has an internal pipeline.
>
> Thanks for your confirmation – I will give it try.
>
>
alternatively you could use the reserved-* of qtmux so that the moov atoms are written periodically and you can still play the file.

Cheers,
--Prabhakar Lad
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel at lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel