[MPlayer-dev-eng] Status of CoreAVC (last time) and using win32 codecs on x86_64

[Guillaume Poirier]

Hi,

Mikael Abrahamsson wrote:
> On Wed, 25 Jul 2007, Anatoli Marinov wrote:
> 
>> Hi guys,
>>
>> Why we need such kind of closed decoder like coreAVC? Now ffh264 works
>> slower but I think it will be better if we try to optimize it, to add
>> threads like in closed decoder, to support multiple CPU and similar
>> things.
>> Of course this is a lot of work but my opinion is that this is the right way.
>>
>> What do you think?
> 
> Why not do both?

As Nico said, because the licences do not allow it.


> CoreAVC solves the problem of playing h264 1080p video NOW. Of course it 
> would be nice to have ffh264 support multithreading, but it doesn't now 
> and it's probably quite a bit into the future before it will.
> 
> I have done testing on an Core2Duo E6400 using linux, and playing VC-1 
> isn't quick enough using the single threaded codec available right now so 
> I get frame skips, so basically there is no way of playing 1080p VC-1 in 
> Linux that I am aware of.
> 
> Using ffh264 for h.264 is the same (frame skips, 100% cpu most of the 
> time), but with the CoreAVC patches I get smooth playback at between 
> 80-130% CPU utilization using CoreAVC since is multithreaded.
> 
> So the question is, is it better to do an interim solution that works, or 
> do we want to wait until a "proper" solution is in place and deny people 
> the ability to play 1080p media in the interim?

People are lazy. If they have a proprietary solution that just works,
the open source solution has little chance to get developed/improved.

I'm not saying that proprietary solutions are Evil. If you go
OpenSource, you have a chance to support a much wider range of
plateforms, such as x86, x86-64, PPC-32, PPC-64, MIPS, Sparc, ARM....
Everybody wins!

Guillaume