After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 790047 - basedemux: new base class for demux elements
basedemux: new base class for demux elements
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Windows
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-11-08 07:32 UTC by Seungha Yang
Modified: 2018-11-03 12:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Seungha Yang 2017-11-08 07:32:38 UTC 
To all maintainers

Gstreamer has several base classes for core components such as
src/sink, parse, decoder/encoder, etc. BUT demux elements are fragmented and has their flow. Actually demux's work flow is quite similar to each other.
Pushing input buffer to adapter, read header, expose src pads, feed demuxed ES streams, and so on.

Are there basedemux in backlog of maintainers, or even ongoing? Since we now might need to implement GstStream API to almost demux elements, right now seems to good timing to add the basedemux.... What do you think?
Comment 1 Tim-Philipp Müller 2017-11-08 07:42:23 UTC 
It's a decidedly non-trivial task to come up with APIs that work for all formats across the whole range of features and container idiosyncrasies.

It will have to be done by someone who has a strong understanding of all common container formats and demuxer implementations.

I don't think it's on anyone's radar, although Sebastian did a baseclass in Rust for his Rust flvdemux I believe.

This is a long-term task. I don't think we should block making demuxers use the GstStream API on this.
Comment 2 Seungha Yang 2017-11-08 15:51:14 UTC 
(In reply to Tim-Philipp Müller from comment #1)

Thanks to attention :)
I've been thought that gstreamer is much more developer friendly than ffmpeg 
(I'm not expert of gstreamer and ffmepg, though). In some other aspect, however, demuxer's of ffmpeg (libavformat) might seems to be simpler, because it enforces the high level behavior of each demuxer using virtual function, if may understanding is correct.

I can fully agree with your opinion that APIs for demux element is non-trivial... I just wanted to listen to maintainer's option in this ticket :)  so, please feel free dropping this ticket.
Comment 3 GStreamer system administrator 2018-11-03 12:42:53 UTC 
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/254.