[Bug 791858] GstTocSetter: proposal to help standardize elements behaviour

[GStreamer (GNOME Bugzilla)]

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

--- Comment #5 from fengalin at free.fr ---
The purpose of my application (1) is to build or modify TOCs. For this, I
proceed in three phases:

  1. The application builds a playback pipeline and sets it to Paused. The
global TOC is retrieved from the message bus. No problem here.
  2. The user can play, pause and seek, build or edit a chapter list using the
GUI.
  3. When the user wants to export the result, another pipeline is built to
export the media with the new TOC. I guess this is the kind of pipelines
Sebastian refers to as transmuxing.

First, I was focused on using matroskamux and setting the new Global TOC using
this muxer (2). It finally worked ok, though it doesn't comply with the
transient nature of the GstTocSetter (see "Current Status" above). Then, I
wanted to export audio only as individual tracks (one per chapter) to wave or
flac files. This is when I found out that GstTocSetter couldn't override not
reset the Upstream TOC (3). So the individual audio (part) files contained the
whole source media TOC. I solved this using pad probes, but I thought
GstTocSetter should allow this. Besides, I still use the muxer/encoder to write
the global TOC.

What would be the proper way of achieving this?
Should the GstTocSetter only be used for Current TOCs?
Could you point me to an element that implements TOC handling the way it is
supposed to work, so that I can get it right?

---

(1) https://github.com/fengalin/media-toc
(2) https://bugzilla.gnome.org/show_bug.cgi?id=790686
(3) https://bugzilla.gnome.org/show_bug.cgi?id=791736

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.