avc1 and mp4v

347 views
Skip to first unread message

MyCometG3

unread,
Apr 27, 2007, 9:37:44 AM4/27/07
to perian discussion
Hi, team.
Perian is, really usuful. Improved avi/mkv support are greatly
helpful. But...

I wonder why Perian uses avc1 and mp4v implementation, "without user
select-ability".

Both two fourCC with manufacturer code appl, are defined by default
under all quicktime env.
At 1.0b1, Perian defines component resource with avc1/Peri and mp4v/
appl.
I think they are better to be avc1/appl and mp4v/appl, because Perian
overrides default apple native decoders.

//

And also, I hope you team members consider of making two fourcc
different from default implementation.

Movie import feature for avi/mkv files are pretty good, but I have
currently found most libavcodec based h.264 implementation seems not
to be perfect (including CPU usage on PPC mac). i.e. Heavy than
native.

That is, why I think it is better to add user select-ability. (And
also why I make my components separated)

Thanks.

dsd...@gmail.com

unread,
Apr 27, 2007, 12:04:13 PM4/27/07
to perian discussion
Hey team,

Perian is a great and very useful tool for me. I love being able to
watch avi and DiviX movies through Front Row on my beautiful new apple
display . I would really love to see an implementation of the .dvr-ms
format in Perian. If this is outside the scope of what you plan to do
I would welcome any suggestions you may have regarding this.

Thanks

David Conrad

unread,
Apr 29, 2007, 3:31:07 PM4/29/07
to perian-...@googlegroups.com

On Apr 27, 2007, at 9:37 AM, MyCometG3 wrote:

>
> Hi, team.
> Perian is, really usuful. Improved avi/mkv support are greatly
> helpful. But...
>
> I wonder why Perian uses avc1 and mp4v implementation, "without user
> select-ability".
>
> Both two fourCC with manufacturer code appl, are defined by default
> under all quicktime env.
> At 1.0b1, Perian defines component resource with avc1/Peri and mp4v/
> appl.
> I think they are better to be avc1/appl and mp4v/appl, because Perian
> overrides default apple native decoders.

However, if Apple's manufacturer is used, Apple's decoder is
completely hidden. Some players support the ability to use one
decoder over another for a format, and this means that they couldn't
choose. Admittedly, I only know of two players that actually support
this.

We use Apple's manufacturer for mp4v only because of some weird
behaviour apparently unique in QuickTime regarding this format: if we
use our manufacturer, we're only used when Apple's decoder decides it
can't decode a stream. This would be okay, except that Apple's
decoder thinks it can decode quite a few streams that it really
can't. Ideally, I think we'd like to use our own manufacturer for
mp4v. Also, using our manufacturer makes it easier to figure out in
apps like Fiendishthngs what all Perian includes at the QuickTime
component level.

> //
>
> And also, I hope you team members consider of making two fourcc
> different from default implementation.

You mean having Matroska set some other fourcc for native H.264 and
MPEG-4 than avc1 and mp4v?

> Movie import feature for avi/mkv files are pretty good, but I have
> currently found most libavcodec based h.264 implementation seems not
> to be perfect (including CPU usage on PPC mac). i.e. Heavy than
> native.

Indeed, lavc's H.264 decoder isn't quite as as fast as Apple's
decoder currently is on PPC (though it is faster than Apple's was
before QuickTime 7.1). And that's why we're working on speeding up
the decoder; 1.1 will have a H.264 decoder at least as fast as
Apple's is on PPC.

> That is, why I think it is better to add user select-ability. (And
> also why I make my components separated)

Unfortunately, I don't think it's possible to globally disable a
QuickTime decoder without either removing the .component file from
the QuickTime folder or modifying the resource file. The first would
require separate components, duplicating code, another option on the
prefpane, and some other work. The second is plain ugly, since we'd
have to compile multiple rez files, and a user wouldn't easily know
what was enabled in a given Perian.component.

Either way, we'd still want to use lavc's H.264 decoder by default,
since one feature of 1.0 is Matroska support, and I've already seen
quite a few people think that Perian didn't support mkvs properly on
the AppleTV just because lavc's H.264 decoder wasn't being used.
Since adding in a feature to disable it would really only be relevant
for 1.0 and some users, I don't see it happening.

Augie Fackler

unread,
Apr 29, 2007, 3:33:20 PM4/29/07
to perian-...@googlegroups.com

On Apr 29, 2007, at 3:31 PM, David Conrad wrote:

>> That is, why I think it is better to add user select-ability. (And
>> also why I make my components separated)
>
> Unfortunately, I don't think it's possible to globally disable a
> QuickTime decoder without either removing the .component file from
> the QuickTime folder or modifying the resource file. The first would
> require separate components, duplicating code, another option on the
> prefpane, and some other work. The second is plain ugly, since we'd
> have to compile multiple rez files, and a user wouldn't easily know
> what was enabled in a given Perian.component.
>
> Either way, we'd still want to use lavc's H.264 decoder by default,
> since one feature of 1.0 is Matroska support, and I've already seen
> quite a few people think that Perian didn't support mkvs properly on
> the AppleTV just because lavc's H.264 decoder wasn't being used.
> Since adding in a feature to disable it would really only be relevant
> for 1.0 and some users, I don't see it happening.

*nod* I'd consider 1.0 feature frozen for something this simple - I
didn't even notice a difference, to be perfectly honest.
Augie

Reply all
Reply to author
Forward
0 new messages