[Bug 754230] qtdemux: support sparse time ranges in qtdemux without needing a seek for MSE

[GStreamer (GNOME Bugzilla)]

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

--- Comment #26 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Enrique Ocaña González from comment #25)
> First of all, thank you very much both to you and Calvaris for moving this
> forward. I couldn't test the patch from
> https://bugzilla.gnome.org/show_bug.cgi?id=767354 myself because adapting
> GStreamer 1.9.1 to work with our patched buildroot environment for the
> Raspberry turned out to be harder than I thought.

It's also not going to help, it's solving a different problem that you don't
have :)

> About the solution you're proposing now, yes, it should work. We append the
> data using gst_app_src_push_buffer(), and those buffers are created using
> gst_buffer_fill(), with no PTS/DTS/duration info on them. I guess that
> generates a byte stream.

appsrc has a "format" property. If you set that to GST_FORMAT_BYTES, then
that's what it would do. PTS/DTS/duration are somewhat independent of that (but
only really make sense for GST_FORMAT_TIME).

> Regarding weird appends, we do have the case you describe (appending first
> half of one fragment followed by some other fragment). However, when that
> happens, our client code must call abort() before feeding the second
> segment. We handle aborts by resetting the pipeline (changing it to READY),
> so it shouldn't be a problem.

That wouldn't be a problem as long as we know when to flush and expect
discontiguous data.

> Once again, thanks a lot for your help moving this forward.

Would you be able to update your patch accordingly and check if that solves all
your problems? There is already other code in qtdemux doing such distinction
(search for upstream_format_is_time).

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