splitmuxsink and timestamps

[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 <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.
> 

Yes, that's it

Thank you

Philippe

-- 
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles