[FFmpeg-devel] vp8: decoder rewrite, spec cleanup

[John Koleszar]

On Fri, May 28, 2010 at 2:56 PM, Diego Biurrun <diego at biurrun.de> wrote:
> On Fri, May 28, 2010 at 01:47:38PM -0400, John Koleszar wrote:
>>
>
> I suggest that you work with us on getting a native decoder into FFmpeg.
> It's the natural place for such a decoder, we have ample experience and
> an extensive and optimized infrastructure is in place. ?Also, a decoder
> in FFmpeg will directly benefit all FFmpeg users, which at this point
> means 100% of the FOSS world and 50% of the rest of the world.
>

What sort of help do you need? Ok, probably none, but what sort of
help would you like? :) I'm not in a position to commit to anything
right now, I just want to get a discussion going.

>> Also, if you have any other ideas on how we could work with the open
>> source video community, I'd love to hear them. The webm-discuss@ list
>> is a good place for these topics, technical topics should remain on
>> codec-devel at . We want to work with everybody and be good citizens, but
>> please bear with us; we're new to working in the open source
>> environment and it will take some time to come up to speed.
>
> You are on the right track.
>
> I would suggest that you remain open to changing the libvpx API and
> even the VP8 bitstream for the time being. ?The project is still young
> and could benefit from extensive changes. ?If you value backwards
> compatibility too highly, go for VP9. ?Nothing is set in stone yet,
> you should not miss that window of opportunity.
>


I'm going to be starting a branch in our repo to handle changes to the
bitstream as soon as possible. This is mostly trivial, but I want to
set up an automated periodic merge from our master branch. This will
probably happen Tuesday, or at least enough to get it ready for people
to contribute to it.

The issue of how and when the bitstream can change is a complicated
one, and nothing has been decided yet. I think ideas on how that can
work would be appreciated. This is going to be a long term project,
and I think we'll always be looking at what the next version is going
to look like, so people interested in bitstream-incompatible changes
should definitely get involved.

With regard to the API, I think that's definitely open to change. Like
any other library with widespread adoption, we need to be careful and
provide a reasonable amount of stability, but there are certainly
aspects of the current API that may not make sense in this new
context. Part of the reason for numbering this release 0.9 was that I
expected there'd be some feedback on the API.