[gstreamer-bugs] [Bug 332031] [PATCH] avimux ported to 0.10

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=332031
 GStreamer | gst-plugins-good | Ver: 0.10.2





------- Comment #11 from Mark Nauwelaerts  2006-04-27 20:32 UTC -------
(In reply to comment #9)
> Hi Mark, great work!
OK, thanks for the feedback/comments :), some nice guidelines to bear in mind.

> - commented out audio_pad_eos and video_pad_eos members - are they
>   actually needed/used anywhere?
It seems they once were in the old muxing code, but no longer now that
GstCollectPads is in the game; overlooked this to clean up.

> - the assumption is that the incoming streams are perfect streams, right?
>   (ie. no gaps)
I hope not :)
That is, the mux-decision is "segment-aware", and decides what to mux in next
based on the running-time (computed on buffer-time and segment info).
After all, a muxer should "create" (in a sense) a "new" media-timeline.
So, if the gaps/discontinuities are (properly) signaled using segments, it
should be OK (if not, there could indeed be an imbalance between pads, and
therefore problems).  In particular, avimux can handle a gap/discontinuity that
results from sending a seek to the pipeline.  At least, I have used this many
times to do some simple cut-list transcoding using (segment-)seek.

> - gst_avimux_do_one_buffer():
>   are avimux->video_buffer_queue and avimux->audio_buffer_queue needed
>   for anything? Looks to me like they could just as well be replaced
>   by local variables.
Indeed, I think I almost intended to do so, but then apparently decided to
stick a bit closer to the original code.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.