[vlc-devel] [RFC-PATCH 04/12] core: introduce input_Decoder{Set, Get}PrerollEnd

Filip Roséen filip at videolabs.io
Wed May 11 22:10:56 CEST 2016


> No. The point is that this API is broken by design and should not exist. In 
> fact, I think preroll end should not even exist at all, in any form, and most 
> definitely not as an API between ES out and decoder.

But given the current state of the codebase, how do you propose that we:
  
  1. fix the problems related to PREROLL and decoders?
  2. fix the issues we are facing at this time (such as broken
     audio/video/subtitle after seeking)?

This at least fixes some of the issues that has to do with the preroll, while
also (as a little perk) making the code a little bit easier to refactor in the
future.


There is only one code-path in which the input_Decoder{Get,Set}PrerollEnd could
cause issue with the decoder (after the patches), and it can be fixed as below
(draft implementation).

Please mind that this was just written at the top of my head (ie. there could be
typos):

  - https://gist.github.com/anonymous/87ab302de9d78301cb58f1ba8e210513

> Preroll end is a hack because decoders don´t perform preroll internally 
> correctly and

Agreed, there are many things that could be improved further regarding the
preroll; but those require some big changes to the core.

And even if the decoders are fixed to handle preroll in a more efficient manner
(such as not generating data that the core just discards), we are still faced
with the issue where an incoming block does not have a PTS.

For such blocks we can never know (since the demuxer cannot know) whether they
are supposed to be part of the preroll or not without getting back a decoded
packet, and deciding afterwars whether it should be played or not.

> it is fundamentally incompatible with asynchronous decoding.


The introduction of input_Decoder{Get,Set}PrerollEnd is certainly debatable,
which I agree with; but I fail to see how we could solve the issue in an easy
manner using some alernative implementation.

Given the current state, the ES out needs to be able to tell the decoder-side of
the core the preroll-end date; otherwise we cannot solve the issues described
earlier.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20160511/0b13c1d3/attachment.html>


More information about the vlc-devel mailing list