splitmuxsink and timestamps

Vivia Nikolaidou n.vivia at gmail.com
Wed Apr 26 11:53:36 UTC 2017


On 26 April 2017 at 10:43, Philippe De Muyter <phdm at macq.eu> 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


More information about the gstreamer-devel mailing list