implementing timeshifter - is GstIndex going to be ever public again?

[Krzysztof Konopko]

On 29/10/12 14:29, Rob wrote:
> Hello,
> 
> On 29 October 2012 12:19, William Manley <william.manley at youview.com> wrote:
>> On 26/10/12 21:34, Rob wrote:
> 
> [...]
> 
>>> As for your design, I was thinking of something similar once queue2
>>> and some ringbuffer and linear file buffer code had been refactored it
>>> of queue2. You need something to provide the index, it's good for it
>>> to be possible to write the index to disk for more seekable
>>> recordings, due to the use case of transitioning from time shift to
>>> recording it's useful to support both. And more.  :-) One difference I
>>> was thinking of was like the Fluendo element to have some data in RAM
>>> as well as writing to a disk cache and have the in memory data be
>>> centred at the play position so that you have data from the proximity
>>> in memory when looking at past data. Then trying to maintain it as is
>>> sensible and in a fashion similar to the Fluendo element.
>>
>>
>> Something I quite like about Krysz's approach is that:
>>  * The configuration is specified at run time rather than having to
>>    bake in any of the details in a compile-time.  e.g. you could
>>    replace queue2 with some other means of buffering the data.
> 
> That's a fair point. The indexing (creation of time to byte map
> points) and seeking (conversion of time-format seeks to byte-format
> seeks and forwarding upstream) based on the index is separated from
> the buffering element in your design.
> 
>>  * It doesn't require refactoring existing elements, re-use is provided
>>    by re-using existing gstreamer elements as is.
> 
> The purpose of refactoring was to isolate the useful functionalities
> implemented in queue2 ([sparse] file/RAM linear/ring buffer) into some
> cleaner classes/objects to support the overlaid solution implemented
> by Josep in the Fluendo timeshift element.
> 
> I think there is probably quite a performance benefit for normal use
> cases in having data from the close proximity in a RAM ring buffer but
> keeping all the time-shift cache data (including that that is in the
> RAM ring buffer) on disk. With your previously-mentioned point,
> there's no harm in implementing the solution your way and then
> refactoring functional pieces to achieve that later.
> 
>>  * Attaching timing information is the responsibility of the parsers
>>    rather than needing a different timeshifting element for each type
>>    of stream.
> 
> That part is basically the same as the Fluendo element. The idea there
> was to replace the parser according to format to extract and apply
> timestamps to buffers that could then be used to create the index in
> the later buffering element.
> 
> The difference between your design and Fluendo's is basically that you
> don't have the specialised timeshift buffering element and the parts
> that manage the index are split out of the buffering element.
> 
> On the whole yours is a more flexible design with regard to the
> buffering element, but it also loses functionality/efficiency without
> further work on the buffering elements that _can_ plug into the gap.
> Although, I suppose technically the Fluendo time-shift element could
> be plugged in as the buffering element if it were modified to not
> manage the indexing.
> 
>>  * If it would be more convenient or more sophisticated interactions
>>    between the elements were required a timeshiftbin could be created.
> 
> Yup.
> 
> You have a good design from the perspective of modularity but I don't
> know what your requirements/desires are for the buffering capability
> and interactions with other use cases (recording, trick modes, ...) as
> to how well queue2 will function in the buffering role.
> 
> Have you considered perhaps starting from Fluendo's element and
> refactoring parts to make it more modular and then swapping out the
> buffering element as you please? Might be worth investigating.
> 
> In any case, I look forward to seeing the results! :)
> 
> Best regards,
> Rob
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> 

If you're interested, I'm trying to come up with a proposal to get
something to work on and have others to share their opinions and
experience in this regards.

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

Cheers,
Kris