gst-plugins-good: multipartmux extensions

[Robin Haberkorn]

On Wed, 16 Mar 2016 10:20:34 +0200
Sebastian Dröge <sebastian at centricular.com> wrote:

> ...
> 
> If you're using something like yocto for building your system images,
> or even a normal Linux distro, it should be relatively easy to upgrade
> GStreamer to a newer version. Definitely easier than backporting all
> those changes :) Unless you also have more changes that would need to
> be forward-ported.
> Doing that would be a good idea independent of staying with linuxptp
> or not, which is an acceptable solution in many situations indeed.
> 
Indeed I'm using Yocto. But something being easy in theory is not
always easy in practice. Upgrading Gstreamer will very likely require
me to upgrade a lot of other packages as well. Not all of them will be
readily available. Also I will have to forward-port BSP and other
patches on top of Gstreamer. Speaking out of experience working many
years in the embedded Linux business, this sort of stuff __can__ be
annoying and is certainly not done in 5 minutes.

Since OpenCV 3 support will be finished in v1.8 -- as Nicolas Dufresne
has pointed out -- I think it would be wise to wait for that release.

> ...
> > My use case is probably much different than what you have in mind.
> > Clients receiving the video data will not have to sync against the
> > same clock. But I acknowledge that it's useful elsewhere.
> 
> What is your use case? Your clients get those buffers with the
> timestamps you put on them, and then just write them out as metadata
> instead of using them for synchronization?
> 
Exactly.

> > > If that ever becomes necessary for the RFC7273 implementation in
> > > the RTSP server or jitterbuffer (see patches), API could be added
> > > for specifying that the system clock is indeed synced to one
> > > specific PTP/NTP/etc clock. Or it could even be API on the system
> > > clock.
> > > 
> > Mhh... I don't think that's a good idea. What if you sync your
> > system clock to something else, like NTP? This can hardly be mapped
> > generically to SystemClock properties or methods. And even if it
> > could be by adding some new properties, you could not ask the OS
> > about the relevant properties; so you would have to update the
> > SystemClock properties from your App anyway using whatever means
> > necessary. So why not just use the "extra-headers" way of
> > delegating that task to the application?
> 
> That's exactly what I proposed, yes. Some API on the system clock so
> that the application can specify a clock the system clock is synced
> to, so the inside the pipeline elements can use this information for
> whatever they want to.
> 
> I also don't think it makes sense to somehow autodetect this, it must
> be the application in the end that provides this information.
> 
I still don't get why this needs a special API on the system clock side
then. Let the application simply use the proposed "extra-headers"
property on multipartmux.

Best regards,
Robin