[MPlayer-dev-eng] Status of CoreAVC (last time) and using win32 codecs on x86_64
Guillaume Poirier
gpoirier at mplayerhq.hu
Wed Jul 25 11:36:47 CEST 2007
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
More information about the MPlayer-dev-eng
mailing list