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

[Rob]

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