gst-plugins-good: multipartmux extensions

[Robin Haberkorn]

Hello again,

I just wanted to give an update here. Already some months ago, I
prepared to contribute the changes discussed here back to the
community. I rewrote them to work on top of gst-plugins-good v1.2.4.
However I did not yet implement the planned multipartmux changes
for clock source reporting, http_headers event support or
extra-headers property, etc.

What I did was just the minimum in order to comply with the LGPL should
we release our product. (Since it's easy to publish our gst-plugins-good
fork even if the changes don't get upstreamed.)

Still, I'm sending you these changes now as patches for the time being,
so they won't get lost and you can already have a look at them. When I
implement the remaining features (they're on my very long TODO
list...), I will probably publish my gst-plugins-good fork and create a
proper Bugzilla ticket.

Best regards,
Robin Haberkorn

On Wed, 16 Mar 2016 21:53:11 +0100
Robin Haberkorn <haberkorn at metratec.com> wrote:

> On Sun, 13 Mar 2016 11:28:31 +0200
> Sebastian Dröge <sebastian at centricular.com> wrote:
> 
> > On Sa, 2016-03-12 at 21:09 +0100, Robin Haberkorn wrote:
> > > ...
> > > Perhaps a good compromise would be to support both a custom
> > > GstMeta type and souphttpsrc's http_headers event.
> > > What do you think?
> > 
> > My idea was that both the event and the meta could share the
> > representation at least, and that for non-per-buffer headers you
> > could use the event and for per-buffer headers the meta. I.e.
> > having the event as the default values and let the meta override
> > them.
> > 
> This raises a new problem though. It makes sense to extend
> multipartdemux to parse additional headers as well, so the changes are
> symmetric and consistent. But which headers are parsed into a GstMeta
> and which ones will be transmitted via events?
> This information was lost when all structures were merged.
> I see three possibilities to resolve that: Either all headers will
> produce one GstMeta in multipartdemux; or all headers will produce one
> event; or multipartmux will have to encode the header's source into
> the header's name or field, so multipartdemux can infer what to do
> with them.
> For the time being I will not extend multipartdemux, though.
> 
> Best regards,
> Robin
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



-- 
Robin Haberkorn
Developer

metraTec GmbH
Niels-Bohr-Str. 5
39106 Magdeburg
Germany

haberkorn at metratec.com
www.metratec.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-added-GstStructureMeta-a-GstMeta-implementation-for-.patch
Type: text/x-patch
Size: 12401 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160618/60a8e441/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-multipartmux-coding-style-fixes-as-reported-by-the-G.patch
Type: text/x-patch
Size: 1103 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160618/60a8e441/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-multipartmux-an-X-Timestamp-header-is-now-added-for-.patch
Type: text/x-patch
Size: 2040 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160618/60a8e441/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-multipartmux-support-serialization-of-GstStructureMe.patch
Type: text/x-patch
Size: 5078 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160618/60a8e441/attachment-0007.bin>