gst-plugins-good: multipartmux extensions

[Sebastian Dröge]

On Di, 2016-03-15 at 21:28 +0100, Robin Haberkorn wrote:
> 
> > linuxptp+system clock requires you to synchronize your system clock to
> > one specific PTP clock, and it requires root permissions to actually
> > do so. With the GStreamer PTP clock you can synchronize your media to
> > different PTP/NTP/etc servers without affecting your system clock time
> > and without requiring root permissions.
> > 
> Both of these advantages are irrelevant to me as I'm developing an
> embedded product. My biggest concern on using GstPtpClock is however
> that it is a recent feature only implemented in 2015. I'd have to update
> my on-board GStreamer - or backport GstPtpClock - which may be a lot
> of work. It's not always pleasant to upgrade a large project like
> GStreamer in an embedded system as all components must fit together.
> (Of course I will have similar problems with my multipartmux changes,
> but it's relatively isolated.) So for the sake of simplicity I'm staying
> with linuxptp at least for the time being.

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.


> btw. I had compatibility problems with OpenCV and thus patched
> gst-plugins-bad to compile with OpenCV 3. I should probably post that
> here. Unfortunately, the code base of gst-plugins-bad has changed so
> much recently that this patch won't work anymore. At the same time
> gst-plugins-bad is still not OpenCV 3 compatible. So when I upgrade
> gstreamer, I will have to completely rewrite that, too. At least the
> patch may then be merged upstream, finally adding support for OpenCV 3.

See https://bugzilla.gnome.org/show_bug.cgi?id=760473


> > The main advantage here is IMHO that you have this information next to
> > media instead of having to distribute it somehow else (like making it
> > a requirement of your product that the system clock is synchronized to
> > that specific PTP clock).
> > 
> 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?

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

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160316/3e45fc7c/attachment.sig>