GStreamer-devel

mp4 file repair - UPDATE 1

Classic

List

Threaded

15 messages Options

William Salibrici

mp4 file repair - UPDATE 1

I am creating mp4 recordings in a known format.

Below is the discover tool result [short version] for a test recording:

Topology:

container: Quicktime

audio: MPEG-4 AAC

video: H.264 (Constrained Baseline Profile)

Properties:

Duration: 0:00:48.000000000

Seekable: yes

Tags:

audio codec: MPEG-4 AAC audio

bitrate: 21346

language code: en

datetime: 2017-10-25T15:04:50Z

container format: ISO MP4/M4A

video codec: H.264 / AVC

maximum bitrate: 5222160

The problem is that sometimes I will get a recording that was not finalized so the data is there but the recording is unreadable.

However, the audio and video formats are known.

The question is this: does anyone know of a repair tool that can go over the existing data in the recording file and create the proper moov atom at the end of the file?

Thank you for your help,

--Bill

UPDATE 1 ->

I failed to clarify in my first post that I’m interested to know if anyone in the gstreamer development community has done any kind of mp4 file repair using gstreamer elements or gstreamer source code. I can google for repair tools but that’s not what I want.

I need some c/c++ code to do this repair. I can dig into the mp4mux and discoverer source code to see what’s going on but that’s a pretty big task. I’m thinking if anyone has already done some work in this area I could avoid reinventing the wheel so to speak.

Sorry about that.

Thanks again for any help,

Bill

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Mailing List SVR

Re: mp4 file repair - UPDATE 1

Hi,

if you are using GStreamer to create your mp4 recording you can set moov-recovery-file property on qtmux and then use qtmoovrecover element if the recording is unexpectedly interrupted to recover it,

Nicola

Il 08/11/2017 19:43, William Salibrici ha scritto:

I am creating mp4 recordings in a known format.

Below is the discover tool result [short version] for a test recording:

Topology:

container: Quicktime

    audio: MPEG-4 AAC

    video: H.264 (Constrained Baseline Profile)

Properties:

Duration: 0:00:48.000000000

Seekable: yes

Tags:

      audio codec: MPEG-4 AAC audio

      bitrate: 21346

      language code: en

      datetime: 2017-10-25T15:04:50Z

      container format: ISO MP4/M4A

      video codec: H.264 / AVC

      maximum bitrate: 5222160

The problem is that sometimes I will get a recording that was not finalized so the data is there but the recording is unreadable.

However, the audio and video formats are known.

The question is this: does anyone know of a repair tool that can go over the existing data in the recording file and create the proper moov atom at the end of the file?

Thank you for your help,

--Bill

UPDATE 1 ->

I failed to clarify in my first post that I’m interested to know if anyone in the gstreamer development community has done any kind of mp4 file repair using gstreamer elements or gstreamer source code. I can google for repair tools but that’s not what I want.

I need some c/c++ code to do this repair. I can dig into the mp4mux and discoverer source code to see what’s going on but that’s a pretty big task. I’m thinking if anyone has already done some work in this area I could avoid reinventing the wheel so to speak.

Sorry about that.

Thanks again for any help,

Bill
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

William Salibrici

RE: mp4 file repair - UPDATE 1

Hi Nicola,

Thank you for your reply.

Yes I am using GStreamer to create my mp4 recording.

I will look into your suggestion.

I checked the Gstreamer documentation for a qtmoovrecover example pipeline but there isn’t one there.

Can you send me an example pipeline?

Regards,

--Bill

From: gstreamer-devel [mailto:[hidden email]] On Behalf Of Mailing List SVR
Sent: Thursday, November 09, 2017 2:54 AM
To: [hidden email]
Subject: Re: mp4 file repair - UPDATE 1

I am creating mp4 recordings in a known format.

Below is the discover tool result [short version] for a test recording:

Topology:

container: Quicktime

    audio: MPEG-4 AAC

    video: H.264 (Constrained Baseline Profile)

Properties:

Duration: 0:00:48.000000000

Seekable: yes

Tags:

      audio codec: MPEG-4 AAC audio

      bitrate: 21346

      language code: en

      datetime: 2017-10-25T15:04:50Z

      container format: ISO MP4/M4A

      video codec: H.264 / AVC

      maximum bitrate: 5222160

The problem is that sometimes I will get a recording that was not finalized so the data is there but the recording is unreadable.

However, the audio and video formats are known.

The question is this: does anyone know of a repair tool that can go over the existing data in the recording file and create the proper moov atom at the end of the file?

Thank you for your help,

--Bill

UPDATE 1 ->

I failed to clarify in my first post that I’m interested to know if anyone in the gstreamer development community has done any kind of mp4 file repair using gstreamer elements or gstreamer source code. I can google for repair tools but that’s not what I want.

I need some c/c++ code to do this repair. I can dig into the mp4mux and discoverer source code to see what’s going on but that’s a pretty big task. I’m thinking if anyone has already done some work in this area I could avoid reinventing the wheel so to speak.

Sorry about that.

Thanks again for any help,

Bill
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Mailing List SVR

Re: mp4 file repair - UPDATE 1

Il 09/11/2017 15:09, William Salibrici ha scritto:

Hi Nicola,

Thank you for your reply.

Yes I am using GStreamer to create my mp4 recording.

I will look into your suggestion.

I checked the Gstreamer documentation for a qtmoovrecover example pipeline but there isn’t one there.

Can you send me an example pipeline?

very simple:

gst-launch-1.0 qtmoovrecover recovery-input=... broken-input=... fixed-output=....

Nicola

Regards,

--Bill

From: gstreamer-devel [[hidden email]] On Behalf Of Mailing List SVR
Sent: Thursday, November 09, 2017 2:54 AM
To: [hidden email]
Subject: Re: mp4 file repair - UPDATE 1

Hi,

if you are using GStreamer to create your mp4 recording you can set moov-recovery-file property on qtmux and then use qtmoovrecover element if the recording is unexpectedly interrupted to recover it,

Nicola

Il 08/11/2017 19:43, William Salibrici ha scritto:
I am creating mp4 recordings in a known format.

Below is the discover tool result [short version] for a test recording:

Topology:

container: Quicktime

    audio: MPEG-4 AAC

    video: H.264 (Constrained Baseline Profile)

Properties:

Duration: 0:00:48.000000000

Seekable: yes

Tags:

      audio codec: MPEG-4 AAC audio

      bitrate: 21346

      language code: en

      datetime: 2017-10-25T15:04:50Z

      container format: ISO MP4/M4A

      video codec: H.264 / AVC

      maximum bitrate: 5222160

The problem is that sometimes I will get a recording that was not finalized so the data is there but the recording is unreadable.

However, the audio and video formats are known.

The question is this: does anyone know of a repair tool that can go over the existing data in the recording file and create the proper moov atom at the end of the file?

Thank you for your help,

--Bill

UPDATE 1 ->

I failed to clarify in my first post that I’m interested to know if anyone in the gstreamer development community has done any kind of mp4 file repair using gstreamer elements or gstreamer source code. I can google for repair tools but that’s not what I want.

I need some c/c++ code to do this repair. I can dig into the mp4mux and discoverer source code to see what’s going on but that’s a pretty big task. I’m thinking if anyone has already done some work in this area I could avoid reinventing the wheel so to speak.

Sorry about that.

Thanks again for any help,

Bill
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

William Salibrici

RE: mp4 file repair - UPDATE 1

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.

Bill

From: gstreamer-devel [mailto:[hidden email]] On Behalf Of Mailing List SVR
Sent: Thursday, November 09, 2017 9:51 AM
To: [hidden email]
Subject: Re: mp4 file repair - UPDATE 1

Il 09/11/2017 15:09, William Salibrici ha scritto:

Hi Nicola,

Thank you for your reply.

Yes I am using GStreamer to create my mp4 recording.

I will look into your suggestion.

I checked the Gstreamer documentation for a qtmoovrecover example pipeline but there isn’t one there.

Can you send me an example pipeline?

very simple:

gst-launch-1.0 qtmoovrecover recovery-input=... broken-input=... fixed-output=....

Nicola

Regards,

--Bill

From: gstreamer-devel [[hidden email]] On Behalf Of Mailing List SVR
Sent: Thursday, November 09, 2017 2:54 AM
To: [hidden email]
Subject: Re: mp4 file repair - UPDATE 1

Hi,

if you are using GStreamer to create your mp4 recording you can set moov-recovery-file property on qtmux and then use qtmoovrecover element if the recording is unexpectedly interrupted to recover it,

Nicola

Il 08/11/2017 19:43, William Salibrici ha scritto:
I am creating mp4 recordings in a known format.

Below is the discover tool result [short version] for a test recording:

Topology:

container: Quicktime

    audio: MPEG-4 AAC

    video: H.264 (Constrained Baseline Profile)

Properties:

Duration: 0:00:48.000000000

Seekable: yes

Tags:

      audio codec: MPEG-4 AAC audio

      bitrate: 21346

      language code: en

      datetime: 2017-10-25T15:04:50Z

      container format: ISO MP4/M4A

      video codec: H.264 / AVC

      maximum bitrate: 5222160

The problem is that sometimes I will get a recording that was not finalized so the data is there but the recording is unreadable.

However, the audio and video formats are known.

The question is this: does anyone know of a repair tool that can go over the existing data in the recording file and create the proper moov atom at the end of the file?

Thank you for your help,

--Bill

UPDATE 1 ->

I failed to clarify in my first post that I’m interested to know if anyone in the gstreamer development community has done any kind of mp4 file repair using gstreamer elements or gstreamer source code. I can google for repair tools but that’s not what I want.

I need some c/c++ code to do this repair. I can dig into the mp4mux and discoverer source code to see what’s going on but that’s a pretty big task. I’m thinking if anyone has already done some work in this area I could avoid reinventing the wheel so to speak.

Sorry about that.

Thanks again for any help,

Bill
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Prabhakar Lad

Re: mp4 file repair - UPDATE 1

HI,

On Thu, Nov 9, 2017 at 3:00 PM, William Salibrici
<[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

William Salibrici

RE: mp4 file repair - UPDATE 1

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:[hidden email]] On Behalf Of Lad, Prabhakar
Sent: Thursday, November 09, 2017 4:29 PM
To: Discussion of the development of and with GStreamer <[hidden email]>
Cc: [hidden email]
Subject: Re: mp4 file repair - UPDATE 1

HI,

On Thu, Nov 9, 2017 at 3:00 PM, William Salibrici <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Thornton, Keith

AW: mp4 file repair - UPDATE 1

Hi
we use the reserved-* options together with splitmuxsink so that we can set the max size of the files to say 1Gb. Then it is possible to estimate how large the moov block will be.

-----Ursprüngliche Nachricht-----
Von: gstreamer-devel [mailto:[hidden email]] Im Auftrag von William Salibrici
Gesendet: Donnerstag, 9. November 2017 23:15
An: Discussion of the development of and with GStreamer <[hidden email]>
Betreff: RE: mp4 file repair - UPDATE 1

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:[hidden email]] On Behalf Of Lad, Prabhakar
Sent: Thursday, November 09, 2017 4:29 PM
To: Discussion of the development of and with GStreamer <[hidden email]>
Cc: [hidden email]
Subject: Re: mp4 file repair - UPDATE 1

HI,

On Thu, Nov 9, 2017 at 3:00 PM, William Salibrici <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

William Salibrici

RE: mp4 file repair - UPDATE 1

In reply to this post by Prabhakar Lad

Hi Prabhakar,
I am using the mp4mux and looking at the inspect data sheet I see that the reserved-max-duration, reserved-moov-update-period, and reserved-bytes-per-sec are all non-zero by default. The same is true for the qtmux. So they should be in operation. However, when I make a recording using these default values and unexpectedly interrupt the recording, the resultant recording file is unreadable for the standard windows media player. My development machine is windows 7. I just did a test using gstreamer version 1.12.3 with the gstreamer pre-built binaries for windows.
Am I missing something?
How do you get the reserved-* properties to work?
Thanks in advance for any help you can give.

Regards,

Bill

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

HI,

On Thu, Nov 9, 2017 at 3:00 PM, William Salibrici <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Michael MacIntosh

Re: mp4 file repair - UPDATE 1

You need to change the default values, they are max 64 bit unsigned int
by default. Which means it will only update the moov table every 585
years. Try changing them to other values.

On 11/10/2017 6:45 AM, William Salibrici wrote:

> Hi Prabhakar,
> I am using the mp4mux and looking at the inspect data sheet I see that the reserved-max-duration, reserved-moov-update-period, and reserved-bytes-per-sec are all non-zero by default. The same is true for the qtmux. So they should be in operation. However, when I make a recording using these default values and unexpectedly interrupt the recording, the resultant recording file is unreadable for the standard windows media player. My development machine is windows 7. I just did a test using gstreamer version 1.12.3 with the gstreamer pre-built binaries for windows.
> Am I missing something?
> How do you get the reserved-* properties to work?
> Thanks in advance for any help you can give.
>
> Regards,
>
> Bill
>
> -----Original Message-----
> From: gstreamer-devel [mailto:[hidden email]] On Behalf Of Lad, Prabhakar
> Sent: Thursday, November 09, 2017 4:29 PM
> To: Discussion of the development of and with GStreamer <[hidden email]>
> Cc: [hidden email]
> Subject: Re: mp4 file repair - UPDATE 1
>
> HI,
>
> On Thu, Nov 9, 2017 at 3:00 PM, William Salibrici <[hidden email]> 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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

William Salibrici

RE: mp4 file repair - UPDATE 1

Ok I will try that.
Thanks,

Bill

-----Original Message-----
From: gstreamer-devel [mailto:[hidden email]] On Behalf Of Michael MacIntosh
Sent: Friday, November 10, 2017 2:38 PM
To: [hidden email]
Subject: Re: mp4 file repair - UPDATE 1

You need to change the default values, they are max 64 bit unsigned int by default. Which means it will only update the moov table every 585 years. Try changing them to other values.

On 11/10/2017 6:45 AM, William Salibrici wrote:

> Hi Prabhakar,
> I am using the mp4mux and looking at the inspect data sheet I see that the reserved-max-duration, reserved-moov-update-period, and reserved-bytes-per-sec are all non-zero by default. The same is true for the qtmux. So they should be in operation. However, when I make a recording using these default values and unexpectedly interrupt the recording, the resultant recording file is unreadable for the standard windows media player. My development machine is windows 7. I just did a test using gstreamer version 1.12.3 with the gstreamer pre-built binaries for windows.
> Am I missing something?
> How do you get the reserved-* properties to work?
> Thanks in advance for any help you can give.
>
> Regards,
>
> Bill
>
> -----Original Message-----
> From: gstreamer-devel
> [mailto:[hidden email]] On Behalf Of
> Lad, Prabhakar
> Sent: Thursday, November 09, 2017 4:29 PM
> To: Discussion of the development of and with GStreamer
> <[hidden email]>
> Cc: [hidden email]
> Subject: Re: mp4 file repair - UPDATE 1
>
> HI,
>
> On Thu, Nov 9, 2017 at 3:00 PM, William Salibrici <[hidden email]> 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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

William Salibrici

RE: mp4 file repair - UPDATE 1

In reply to this post by Michael MacIntosh

Thank you Michael.
Do you know the units for the reserved-moov-update-period property?
Would that be milliseconds or seconds?

Regards,

Bill

-----Original Message-----
From: gstreamer-devel [mailto:[hidden email]] On Behalf Of Michael MacIntosh
Sent: Friday, November 10, 2017 2:38 PM
To: [hidden email]
Subject: Re: mp4 file repair - UPDATE 1

You need to change the default values, they are max 64 bit unsigned int by default. Which means it will only update the moov table every 585 years. Try changing them to other values.

On 11/10/2017 6:45 AM, William Salibrici wrote:

> Hi Prabhakar,
> I am using the mp4mux and looking at the inspect data sheet I see that the reserved-max-duration, reserved-moov-update-period, and reserved-bytes-per-sec are all non-zero by default. The same is true for the qtmux. So they should be in operation. However, when I make a recording using these default values and unexpectedly interrupt the recording, the resultant recording file is unreadable for the standard windows media player. My development machine is windows 7. I just did a test using gstreamer version 1.12.3 with the gstreamer pre-built binaries for windows.
> Am I missing something?
> How do you get the reserved-* properties to work?
> Thanks in advance for any help you can give.
>
> Regards,
>
> Bill
>
> -----Original Message-----
> From: gstreamer-devel
> [mailto:[hidden email]] On Behalf Of
> Lad, Prabhakar
> Sent: Thursday, November 09, 2017 4:29 PM
> To: Discussion of the development of and with GStreamer
> <[hidden email]>
> Cc: [hidden email]
> Subject: Re: mp4 file repair - UPDATE 1
>
> HI,
>
> On Thu, Nov 9, 2017 at 3:00 PM, William Salibrici <[hidden email]> 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
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Michael MacIntosh

Re: mp4 file repair - UPDATE 1

Hey Bill,

The default unit of time in gstreamer is the nanosecond (10^-9 seconds),
so unless otherwise stated, assume nanoseconds. This is because the
clocks gstreamer use have that level of precision, so usually everything
just follows that.

Hope that helps!

Cheers,
Michael.

On 11/10/2017 12:13 PM, William Salibrici wrote:

> Thank you Michael.
> Do you know the units for the reserved-moov-update-period property?
> Would that be milliseconds or seconds?
>
> Regards,
>
> Bill
>
> -----Original Message-----
> From: gstreamer-devel [mailto:[hidden email]] On Behalf Of Michael MacIntosh
> Sent: Friday, November 10, 2017 2:38 PM
> To: [hidden email]
> Subject: Re: mp4 file repair - UPDATE 1
>
> You need to change the default values, they are max 64 bit unsigned int by default. Which means it will only update the moov table every 585 years. Try changing them to other values.
>
>
> On 11/10/2017 6:45 AM, William Salibrici wrote:
>> Hi Prabhakar,
>> I am using the mp4mux and looking at the inspect data sheet I see that the reserved-max-duration, reserved-moov-update-period, and reserved-bytes-per-sec are all non-zero by default. The same is true for the qtmux. So they should be in operation. However, when I make a recording using these default values and unexpectedly interrupt the recording, the resultant recording file is unreadable for the standard windows media player. My development machine is windows 7. I just did a test using gstreamer version 1.12.3 with the gstreamer pre-built binaries for windows.
>> Am I missing something?
>> How do you get the reserved-* properties to work?
>> Thanks in advance for any help you can give.
>>
>> Regards,
>>
>> Bill
>>
>> -----Original Message-----
>> From: gstreamer-devel
>> [mailto:[hidden email]] On Behalf Of
>> Lad, Prabhakar
>> Sent: Thursday, November 09, 2017 4:29 PM
>> To: Discussion of the development of and with GStreamer
>> <[hidden email]>
>> Cc: [hidden email]
>> Subject: Re: mp4 file repair - UPDATE 1
>>
>> HI,
>>
>> On Thu, Nov 9, 2017 at 3:00 PM, William Salibrici <[hidden email]> 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
>> [hidden email]
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Prabhakar Lad

Re: mp4 file repair - UPDATE 1

On Sat, Nov 11, 2017 at 1:38 AM, Michael MacIntosh
<[hidden email]> wrote:
> Hey Bill,
>
> The default unit of time in gstreamer is the nanosecond (10^-9 seconds), so
> unless otherwise stated, assume nanoseconds. This is because the clocks
> gstreamer use have that level of precision, so usually everything just
> follows that.
>

But Start initially with seconds and then fine tune it.

Cheers,
--Prabhakar Lad
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

William Salibrici

RE: mp4 file repair - UPDATE 1

In reply to this post by Michael MacIntosh

Hi Michael,
Thanks for clarifying that.
I'm up and working now.

Regards,

Bill

-----Original Message-----
From: gstreamer-devel [mailto:[hidden email]] On Behalf Of Michael MacIntosh
Sent: Friday, November 10, 2017 8:39 PM
To: [hidden email]
Subject: Re: mp4 file repair - UPDATE 1

Hey Bill,

The default unit of time in gstreamer is the nanosecond (10^-9 seconds), so unless otherwise stated, assume nanoseconds. This is because the clocks gstreamer use have that level of precision, so usually everything just follows that.

Hope that helps!

Cheers,
Michael.

On 11/10/2017 12:13 PM, William Salibrici wrote:

> Thank you Michael.
> Do you know the units for the reserved-moov-update-period property?
> Would that be milliseconds or seconds?
>
> Regards,
>
> Bill
>
> -----Original Message-----
> From: gstreamer-devel
> [mailto:[hidden email]] On Behalf Of
> Michael MacIntosh
> Sent: Friday, November 10, 2017 2:38 PM
> To: [hidden email]
> Subject: Re: mp4 file repair - UPDATE 1
>
> You need to change the default values, they are max 64 bit unsigned int by default. Which means it will only update the moov table every 585 years. Try changing them to other values.
>
>
> On 11/10/2017 6:45 AM, William Salibrici wrote:
>> Hi Prabhakar,
>> I am using the mp4mux and looking at the inspect data sheet I see that the reserved-max-duration, reserved-moov-update-period, and reserved-bytes-per-sec are all non-zero by default. The same is true for the qtmux. So they should be in operation. However, when I make a recording using these default values and unexpectedly interrupt the recording, the resultant recording file is unreadable for the standard windows media player. My development machine is windows 7. I just did a test using gstreamer version 1.12.3 with the gstreamer pre-built binaries for windows.
>> Am I missing something?
>> How do you get the reserved-* properties to work?
>> Thanks in advance for any help you can give.
>>
>> Regards,
>>
>> Bill
>>
>> -----Original Message-----
>> From: gstreamer-devel
>> [mailto:[hidden email]] On Behalf Of
>> Lad, Prabhakar
>> Sent: Thursday, November 09, 2017 4:29 PM
>> To: Discussion of the development of and with GStreamer
>> <[hidden email]>
>> Cc: [hidden email]
>> Subject: Re: mp4 file repair - UPDATE 1
>>
>> HI,
>>
>> On Thu, Nov 9, 2017 at 3:00 PM, William Salibrici <[hidden email]> 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
>> [hidden email]
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel