ebu-tt-live-toolkit icon indicating copy to clipboard operation
ebu-tt-live-toolkit copied to clipboard

[ReSequencer] discard would restrict accept

Open kozmaz87 opened this issue 8 years ago • 2 comments

This means the sequence object's discard_before function would need to deal with setting the minimum computed time for a document to be considered for accepting into the sequence.

In turn the _check_document_compatibility function would have to consider this flag.

Reason: The discarded documents would be deallocated so their sequencenumbers are going to be lost. But since it is generally not a good idea to keep collecting these numbers in memory a cutoff computed time should be defined.

kozmaz87 avatar Jan 30 '17 17:01 kozmaz87

Yes, this is right - Here's an attempt to be more precise:

IF we have not got this sequence number already AND the sequence number is not greater than the largest that we have AND we have ever discarded anything (and therefore have a "discard before" time) THEN (Compare the earliest computed begin time of the document and the latest computed end time with the "discard before" time.) IF the latest computed end time is earlier than the "discard before" time, discard this document and exit. IF the latest computed end time is later than the "discard before" time, set it to the begin time of the document with the lowest sequence number greater than this document's sequence number. IF the latest computed end time is now earlier than the "discard before" time, discard this document and exit. Insert the document (i.e. do not discard it).

nigelmegitt avatar Jan 30 '17 23:01 nigelmegitt

Having slept on this I realised two things:

  1. This logic above is reproducing what is effectively already present elsewhere.
  2. The cost of waiting until the next discard is minimal.
  3. This issue is effectively a too-early optimisation.

So I propose marking this as Wontfix and closing, on the basis that doing nothing is fine here - any late arriving documents will be discarded at the next discard anyway. I'm thinking of the discard as a bit like a garbage collection. If we were really clever we would wait until we thought there was some downtime before triggering it, perhaps in a callLater scheduled for just after the next segment collection and emission.

@kozmaz87 does this proposal, to do nothing, work for you?

nigelmegitt avatar Jan 31 '17 09:01 nigelmegitt