splitmuxsink and timestamps

[Philippe De Muyter]

Hello list

I work on a arm board running linux equipped with a camera sensor, and must
be able to produce on-demand video recordings from recent past events with
exact timestamps.  My board is synchronised using ntp and myv4l2 driver
produces UTC-time timestamps of each frame.  I plan to use 'splitmuxsink'
to record continuously the video stream split in small chunks, and I would
like the name of the produced file to include the (ntp) timestamp of the
first frame.  Is that possible using a gst-launch-based pipeline ?

If I need to enhance splitmuxsink to provide a "location" property based
on strftime, how could I access the ntp timestamp from the first frame ?

When "replaying" files to concatenate them and split them at the asked
timestamps, how can I retrieve the 'capture-time' timestamps of the original
frames ?

In the end the produced files must be h264-compressed, and for efficiency
and quality reasons I plan to use the same compression for the small chunks.
I plan to use mp4 container for the final files, but I have no problem using,
if needed, another container format for the small chunks.

TIA

Philippe

--
Philippe De Muyter [phone] Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Philippe De Muyter]

Hello Jan and list

I would like to enhance splitmuxsink's "location" property with a way
to produce files named after the absolute timestamp of the first frame
included in the file.

Which of GST_BUFFER_PTS, GST_BUFFER_DTS or GST_BUFFER_TIMESTAMP
should I use for that purpose ?

I work on a arm board running linux equipped with a camera sensor, and
synchronised using ntp.  Myv4l2 driver produces UTC-time timestamps of
each frame.

Also, is there a container format that can hold those absolute timestamps,
in order to retrieve them when replaying the file ?

TIA

Philippe

--
Philippe De Muyter [phone] Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim Müller]

On Tue, 2017-04-18 at 11:26 +0200, Philippe De Muyter wrote:

Hi Philippe,

> I would like to enhance splitmuxsink's "location" property with a way
> to produce files named after the absolute timestamp of the first
> frame included in the file.

For what it's worth, in git master (soon-to-be-released 1.12)
splitmuxsink has a "format-location-full" signal that gives you the
first buffer of the new chunk, so you can derive the filename from
buffer metadata if you want.

Cheers
 -Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Jan Schmidt]

Hi,

On 18/04/17 19:26, Philippe De Muyter wrote:

> Hello Jan and list
>
> I would like to enhance splitmuxsink's "location" property with a way
> to produce files named after the absolute timestamp of the first frame
> included in the file.
>
> Which of GST_BUFFER_PTS, GST_BUFFER_DTS or GST_BUFFER_TIMESTAMP
> should I use for that purpose ?
>
> I work on a arm board running linux equipped with a camera sensor, and
> synchronised using ntp.  Myv4l2 driver produces UTC-time timestamps of
> each frame.
>
> Also, is there a container format that can hold those absolute timestamps,
> in order to retrieve them when replaying the file ?

In GStreamer 1.12 (and in the 1.11.90 pre-release), there's a
format-location-full signal on splitmuxsink that lets you do what you
want. It passes the first buffer of a new fragment, and you can use
whichever timestamp you want for generating the output filename.

GST_BUFFER_TIMESTAMP is an alias for GST_BUFFER_PTS, so they're the same
time.

Regards,
Jan.

>
> TIA
>
> Philippe
>

--
Jan Schmidt, Centricular Ltd - http://centricular.com/


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

[Philippe De Muyter]

Hi Jan,

On Tue, Apr 18, 2017 at 09:05:56PM +1000, Jan Schmidt wrote:

> Hi,
>
> On 18/04/17 19:26, Philippe De Muyter wrote:
> > Hello Jan and list
> >
> > I would like to enhance splitmuxsink's "location" property with a way
> > to produce files named after the absolute timestamp of the first frame
> > included in the file.
> >
> > Which of GST_BUFFER_PTS, GST_BUFFER_DTS or GST_BUFFER_TIMESTAMP
> > should I use for that purpose ?
> >
> > I work on a arm board running linux equipped with a camera sensor, and
> > synchronised using ntp.  Myv4l2 driver produces UTC-time timestamps of
> > each frame.
> >
> > Also, is there a container format that can hold those absolute timestamps,
> > in order to retrieve them when replaying the file ?
>
> In GStreamer 1.12 (and in the 1.11.90 pre-release), there's a
> format-location-full signal on splitmuxsink that lets you do what you
> want. It passes the first buffer of a new fragment, and you can use
> whichever timestamp you want for generating the output filename.

Thanks

Is that useable by a gst-launch pipeline ?

>
> GST_BUFFER_TIMESTAMP is an alias for GST_BUFFER_PTS, so they're the same
> time.
>
Is it meant to contain the absolute capture timestamp of the frame ?
Or is another timestamp field available for that purpose ?

And when replaying h264 encoded files produced by splitmuxsink using splitmuxsrc,
is it possible to retrieve the original capture timestamps of the frames ?

Philippe

--
Philippe De Muyter [phone] Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Jan Schmidt]

Hi,

On 19/04/17 10:21, Philippe De Muyter wrote:

> Hi Jan,
>
> On Tue, Apr 18, 2017 at 09:05:56PM +1000, Jan Schmidt wrote:
>> Hi,
>>
>> On 18/04/17 19:26, Philippe De Muyter wrote:
>>> Hello Jan and list
>>>
>>> I would like to enhance splitmuxsink's "location" property with a way
>>> to produce files named after the absolute timestamp of the first frame
>>> included in the file.
>>>
>>> Which of GST_BUFFER_PTS, GST_BUFFER_DTS or GST_BUFFER_TIMESTAMP
>>> should I use for that purpose ?
>>>
>>> I work on a arm board running linux equipped with a camera sensor, and
>>> synchronised using ntp.  Myv4l2 driver produces UTC-time timestamps of
>>> each frame.
>>>
>>> Also, is there a container format that can hold those absolute timestamps,
>>> in order to retrieve them when replaying the file ?
>>
>> In GStreamer 1.12 (and in the 1.11.90 pre-release), there's a
>> format-location-full signal on splitmuxsink that lets you do what you
>> want. It passes the first buffer of a new fragment, and you can use
>> whichever timestamp you want for generating the output filename.
>
> Thanks
>
> Is that useable by a gst-launch pipeline ?

No, you need some code to connect to the signal and calculate the
filenames. A python script should do it.

>> GST_BUFFER_TIMESTAMP is an alias for GST_BUFFER_PTS, so they're the same
>> time.
>>
> Is it meant to contain the absolute capture timestamp of the frame ?
> Or is another timestamp field available for that purpose ?

Short answer: No.
Longer answer: PTS can contain whatever timestamp upstream decides -
it's just an incrementing time with some arbitrary start point that
increases according to the playback/capture rate of the video according
to the clock it's being measured against..

> And when replaying h264 encoded files produced by splitmuxsink using splitmuxsrc,
> is it possible to retrieve the original capture timestamps of the frames ?

You'll need to use timecodes for that. Hopefully someone else can
answer, because I've never used them.

- Jan.

>
> Philippe
>

--
Jan Schmidt, Centricular Ltd - http://centricular.com/


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

[Philippe De Muyter]

On Wed, Apr 19, 2017 at 01:05:40PM +1000, Jan Schmidt wrote:

> >> GST_BUFFER_TIMESTAMP is an alias for GST_BUFFER_PTS, so they're the same
> >> time.
> >>
> > Is it meant to contain the absolute capture timestamp of the frame ?
> > Or is another timestamp field available for that purpose ?
>
> Short answer: No.
> Longer answer: PTS can contain whatever timestamp upstream decides -
> it's just an incrementing time with some arbitrary start point that
> increases according to the playback/capture rate of the video according
> to the clock it's being measured against..
>
> > And when replaying h264 encoded files produced by splitmuxsink using splitmuxsrc,
> > is it possible to retrieve the original capture timestamps of the frames ?
>
> You'll need to use timecodes for that. Hopefully someone else can
> answer, because I've never used them.
>

Why timecode ?  Would that not make sense to add a third GST_BUFFER timestamp
to hold the capture time of the frame in timestamp, not timecode, format.

I am under the impression I am not the only one to see that as a needed
functionality.  Not every plugin should use it, but multifilesink, timeoverlay
and splitmuxsink are natural candidate users.

Philippe

--
Philippe De Muyter [phone] Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Vivia Nikolaidou]

On 26 April 2017 at 10:43, Philippe De Muyter <[hidden email]> wrote:

> On Wed, Apr 19, 2017 at 01:05:40PM +1000, Jan Schmidt wrote:
>> >> GST_BUFFER_TIMESTAMP is an alias for GST_BUFFER_PTS, so they're the same
>> >> time.
>> >>
>> > Is it meant to contain the absolute capture timestamp of the frame ?
>> > Or is another timestamp field available for that purpose ?
>>
>> Short answer: No.
>> Longer answer: PTS can contain whatever timestamp upstream decides -
>> it's just an incrementing time with some arbitrary start point that
>> increases according to the playback/capture rate of the video according
>> to the clock it's being measured against..
>>
>> > And when replaying h264 encoded files produced by splitmuxsink using splitmuxsrc,
>> > is it possible to retrieve the original capture timestamps of the frames ?
>>
>> You'll need to use timecodes for that. Hopefully someone else can
>> answer, because I've never used them.
>>
>
> Why timecode ?  Would that not make sense to add a third GST_BUFFER timestamp
> to hold the capture time of the frame in timestamp, not timecode, format.
>
> I am under the impression I am not the only one to see that as a needed
> functionality.  Not every plugin should use it, but multifilesink, timeoverlay
> and splitmuxsink are natural candidate users.

You can take a look here and give feedback:
https://bugzilla.gnome.org/show_bug.cgi?id=779213 This sounds like
what you need, if I understand correctly.

Best regards,

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

[Philippe De Muyter]

On Wed, Apr 26, 2017 at 02:53:36PM +0300, Vivia Nikolaidou wrote:

> On 26 April 2017 at 10:43, Philippe De Muyter <[hidden email]> wrote:
> > On Wed, Apr 19, 2017 at 01:05:40PM +1000, Jan Schmidt wrote:
> >> >> GST_BUFFER_TIMESTAMP is an alias for GST_BUFFER_PTS, so they're the same
> >> >> time.
> >> >>
> >> > Is it meant to contain the absolute capture timestamp of the frame ?
> >> > Or is another timestamp field available for that purpose ?
> >>
> >> Short answer: No.
> >> Longer answer: PTS can contain whatever timestamp upstream decides -
> >> it's just an incrementing time with some arbitrary start point that
> >> increases according to the playback/capture rate of the video according
> >> to the clock it's being measured against..
> >>
> >> > And when replaying h264 encoded files produced by splitmuxsink using splitmuxsrc,
> >> > is it possible to retrieve the original capture timestamps of the frames ?
> >>
> >> You'll need to use timecodes for that. Hopefully someone else can
> >> answer, because I've never used them.
> >>
> >
> > Why timecode ?  Would that not make sense to add a third GST_BUFFER timestamp
> > to hold the capture time of the frame in timestamp, not timecode, format.
> >
> > I am under the impression I am not the only one to see that as a needed
> > functionality.  Not every plugin should use it, but multifilesink, timeoverlay
> > and splitmuxsink are natural candidate users.
>
> You can take a look here and give feedback:
> https://bugzilla.gnome.org/show_bug.cgi?id=779213 This sounds like
> what you need, if I understand correctly.
>

Yes, that's it

Thank you

Philippe

--
Philippe De Muyter [phone] Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel