[MPlayer-users] How to identify missing video-codec?

Ivan Kowalenko ivan.kowalenko at gmail.com
Wed Apr 19 18:53:40 CEST 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 19, 2006, at 08.23, Jeff Clagg wrote:

> On Tue, Apr 18, 2006 at 07:00:58PM -0500, Ivan Kowalenko wrote:
>
>> This is probably your problem. I don't think Apple started using H.
>> 264 in QuickTime until mid 2005. As such, there was no real call for
>> H.264 in the main stream, and its development was kind of ignored for
>> the time being.
>
> All untrue. Do you seriously imagine the entire world was watching  
> Apple
> to decide whether or not to deploy a new video codec?

No, I'm just saying that until Apple made a big deal out of it, your  
average user was more concerned with a new version of XviD than the  
latest release of x264. Besides, no one really produced a lot of H. 
264 content, so there wasn't much demand for a decoder. I'm not  
saying that Apple made H.264 a reality, nor that people were ignoring  
it until Apple brought it up. I'm just simply saying that until Apple  
advertised the hell out of it with QuickTime 7, most people didn't  
know it existed.

>
>> Anyway, your version of MPlayer is way out of date, and it doesn't
>> know what to do with H.264 video. You should be warned that the
>> version of H.264 produced in open source (known as x264) isn't
>> totally up to snuff.
>
> Oh, it's not? Would you rather people use Apple's encoder, which is
> 10-50 times slower? And in what way is x264 not up to snuff, exactly?

Correction: I meant the decoder. However, x264 still has a way to go  
before being 100% complaint, otherwise we would have seen x264  
version 1.0. As a side note, I've used QuickTime 7 to encode H.264  
material. True, it's noticably slower than x264, but 10-50 times  
slower, definitely not.

>
>> The FFMPEG H.264 decoder is pretty good, though,
>> but not perfect. Playing a two and a half minute long trailer (Apple
>> produced, H.264, 480p at 2.35:1), MPlayer produced a lot of "Error
>> while decoding frame!" messages, mostly because all of H.264 hasn't
>> been fully reverse engineered.
>
> Lately, these usually turn out to be demuxing issues. Nico has already
> replied to the "reverse engineering" idea.

My bad on the reverse engineering thing. And I stand corrected on the  
demuxing issues. I don't deal with a lot of H.264 in MPlayer, so I'm  
not always on top of the decoder/demuxer news.

>
>> Your experience might be better, since
>> you're using an x86 CPU and might be able to nab some QuickTime DLLs,
>> but using FFmpeg, we'll see.
>
> In most respects, Apple's decoder really sucks compared to  
> libavcodec's:
> it's something like baseline + 1 b-frame iirc. I wouldn't recommend it
> to anyone using x86.

Well, either way, the experience should be better, given I have a 1  
GHz PPC CPU, and the user has a 2.4 GHz x86 CPU. More power and more  
support = generally better experience (but not always)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFERmsY187keuSyQSQRAjC9AKCNp4G1LqRy8UCZyo/VS3zFfnaa/wCfZKGs
TsNOpMDStKfZJ0eRxVQU7YU=
=4FF5
-----END PGP SIGNATURE-----




More information about the MPlayer-users mailing list