[FFmpeg-devel] [RFC] Merge of Libav's bitstream filter

[James Almer]

On 4/2/2017 1:58 PM, Clément Bœsch wrote:
> Hi,
> 
> We've been merging Libav's work for weeks now after a long period of
> stagnation. We were at 1000+ commits to merge and we're now below 600.
> 
> We also just reached the first commit of the controversial new bitstream
> API. API to which they currently have updated 91 decoders to (in their
> main tree, more in reviews). The remaining major ones are under discussion
> because they do have under certain circumstances a negative impact on the
> performances.
> 
> We now have to decide whether we want to merge the API and the
> implementation, but there are drawbacks in both cases.
> 
> Here is a list of pro arguments for merging:
> 
>  - it is (overall) much faster on 64-bits 
>  - it greatly simplifies the next merges
>  - the API is simpler
>  - it is internal so it should be less problematic than any other
>    previous controversial merges affecting the public API such as frame
>    ref counting or codecpar
> 
> Here is a list of con arguments for merging:
> 
>  - speedlosses have been observed in various decoders, in particular on
>    32-bits platforms
>  - the API naming is annoying

Just in case, for those that were thinking about suggesting renaming the
functions because it's all internal, that would introduce as many conflicts
during merges as not implementing the new API at all, so it's not an option.

>  - the API does not actually allow specialized optimizations so it may
>    be a problem when trying to update it to be on par with the current
>    implementation
>  - Libav developers did not yet investigate the root cause of the issue
>    (even though it's likely related to the 64-bit cache instead of 32) and
>    only focused on benchmarking.
>  - it's been months since they introduced it, and it seems progress is
>    very slow on pushing the main decoders ports, potentially revealing the
>    design issues.
> 
> My position is currently that I do not want to make merges more
> complicated than they already are. But I also understand that we do not
> want to put ourselves in the same rabbit hole due to an API misdesign.
> 
> I'm pretty sure we won't agree with the politic to follow for this case in
> the next days, but on the other hand I do not want to delay even more the
> merge progress.
> 
> So here is what I suggest:
> 
> - We skip all the bitstream commits for now (except maybe the first one
>   introducing the API header) and continue with the merges

+1

Much better than waiting who knows how long until we can finally agree on
what to do with it, or until its drawbacks are fixed.
If we decide to apply it, we can do it in a separate commit in the future.
And if we decide to not apply it, then we will already be set.

> - I will poke the people who opposes to the bitstream API merge to help
>   with the merges when there is a conflict in the decoders due to this
> - Someone opposing with the bitstream merge should work on improving our
>   API to be as fast on 64-bits
> 
> Comments?

I think Rostislav (One of the devs against this new API) said he would
help solve future potential conflicts with merges. If that's true them
lets not waste time and go with your suggestion.