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

Clément Bœsch u at pkh.me
Sun Apr 2 19:58:39 EEST 2017


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
 - 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
- 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?

-- 
Clément B.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170402/11f60ac5/attachment.sig>


More information about the ffmpeg-devel mailing list