GNOME Bugzilla – Bug 764684
adaptivedemux: Forward upstream buffer offsets
Last modified: 2016-07-01 12:11:37 UTC
This gives a more consistent picture of the structure of the data for downstream, e.g. could be used by downstream to detect gaps in the media. As a side-effect, also makes the hlsdemux code a bit easier to read and clears per-fragment data when needed.
Created attachment 325482 [details] [review] adaptivedemux: Get rid of internal stream adapter and let subclasses handle this directly This allows subclasses to have more control and especially ensure that they push data downstream with the correct offsets.
Created attachment 325483 [details] [review] hlsdemux: Clear pending data when needed When switching fragments we don't want to keep any data around from the last one, and also forget about all data when doing flushing seeks or selecting new bitrates.
Created attachment 325484 [details] [review] hlsdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves.
Created attachment 325485 [details] [review] dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves.
Created attachment 325494 [details] [review] dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves.
How should we proceed with this? The goal here is that downstream of e.g. dashdemux can know where in the stream it is, and then can e.g. handle gaps in the stream (if adaptivedemux e.g. decides to only download and output I-frames). Patches for that are also in the works :)
Is this related to https://bugzilla.gnome.org/show_bug.cgi?id=766647 ? Does this offset also include headers/indexes or is it only about the stream payload? (In reply to Sebastian Dröge (slomo) from comment #6) > How should we proceed with this? The goal here is that downstream of e.g. > dashdemux can know where in the stream it is, and then can e.g. handle gaps > in the stream (if adaptivedemux e.g. decides to only download and output > I-frames). > > Patches for that are also in the works :) Shouldn't this be handled by using the DISCONT flag? What is the use case to knowing exactly the byte offset of the data other than detecting disconts?
(In reply to Thiago Sousa Santos from comment #7) > Is this related to https://bugzilla.gnome.org/show_bug.cgi?id=766647 ? > > Does this offset also include headers/indexes or is it only about the stream > payload? I only care about consistent offsets inside a single fragment :) The code however just passes through the offsets that come from souphttpsrc. > (In reply to Sebastian Dröge (slomo) from comment #6) > > How should we proceed with this? The goal here is that downstream of e.g. > > dashdemux can know where in the stream it is, and then can e.g. handle gaps > > in the stream (if adaptivedemux e.g. decides to only download and output > > I-frames). > > > > Patches for that are also in the works :) > > Shouldn't this be handled by using the DISCONT flag? What is the use case to > knowing exactly the byte offset of the data other than detecting disconts? You split a single fragment into "virtual" fragments per I-frame (similar to what the sidx mode does with the individual moof already). And then omit everything in between. However the demuxer needs to be able to know to which sample inside the moof the current buffer belongs, and can correlate that with the buffer offset now.
Created attachment 329305 [details] [review] adaptivedemux: Get rid of internal stream adapter and let subclasses handle this directly This allows subclasses to have more control and especially ensure that they push data downstream with the correct offsets.
Created attachment 329306 [details] [review] hlsdemux: Clear pending data when needed When switching fragments we don't want to keep any data around from the last one, and also forget about all data when doing flushing seeks or selecting new bitrates.
Created attachment 329307 [details] [review] hlsdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves.
Created attachment 329308 [details] [review] dashdemux: Properly keep track of current offset GstAdapter does not guarantee to pass through all the offsets, we have to keep track of it ourselves.
Created attachment 329309 [details] [review] dashdemux: Implement SIDX tracking based on buffer offset This simplifies the code but also removes a bug with tracking of the remaining size for the initial subfragment: we were not considering the size between the index and the start of the first moof here.
Attachment 329305 [details] pushed as ca9f62e - adaptivedemux: Get rid of internal stream adapter and let subclasses handle this directly Attachment 329306 [details] pushed as 3469104 - hlsdemux: Clear pending data when needed Attachment 329307 [details] pushed as 8344854 - hlsdemux: Properly keep track of current offset Attachment 329308 [details] pushed as 9374643 - dashdemux: Properly keep track of current offset Attachment 329309 [details] pushed as 91e398d - dashdemux: Implement SIDX tracking based on buffer offset