I'll try to debug this as soon as i have time, but was just wondering
if this is a know problem...
Chris
> Perian doesn't override apple's h.264 decoder on the appletv, and your
> file use h.264 high profile, that apple's decoder doesn't support.
I suspected that this might be the case. Anyone who has an AppleTV
want to run Fiendishthngs on it and tell me the full info of any imdc-
avc1 components? Though it might be that the only way to override
Apple's decoder on the AppleTV is to use Apple's manufacturer and a
higher version...
-David
-ben
It playing in AVI is expected; it has a different fourcc and Apple's
decoder doesn't handle it, so Perian's is the only option. It would
be more interesting if it plays in .mp4 or .mov since they should
have the same way of storing H.264 as .mkv and Apple's decoder could
attempt to handle it. The crash isn't expected of course... does it
happen on Macs too? Also, does it play in .mkv when you move /System/
Library/QuickTime/QuickTimeH264.component out of the way on the AppleTV?
-David
Apple Decoder:
Opened component: H.264 Decoder
Type: imdc
SubType: avc1
Manufacturer: appl
Instance: 0x860000
Version: 0x40003
------------------------------------
Decompressor Name: H.264
- version = 1
- revisionLevel = 1
- vendor = appl
- decompressionAccuracy = 128
- decompressionAccuracy = 200
- minimum height = 16
- minimum width = 16
- decompress pipeline latency = 0
- decompression capabilities:
directly decompresses into 32-bit pixels maps
supports temporal compression
- decompression format:
can decompress images from 24-bit color compressed format
compressed data requires non-key frames to be decompressed
in same order as compressed
- estimated decompression speed:
- test failed
p.s. : a totally unrelated thing... why does the matroska importer
create a new edit list every time it adds new samples?
2. Playing the test file i posted here works better - still
unacceptable framerates... (MUCH worse the the avi version - but no
crash)
3. The crash with the avi happens after ~30 seconds - fortunately not
only on apple-tv
Unfortunately i've not been able to reproduce it consistently... Im
working on this :)
EXC_BAD_ACCESS (0x0001)
KERN_INVALID_ADDRESS (0x0001) at 0x159480c8
Thread 8 Crashed:
0 ff_put_cavs_qpel16_mc00_mmx2 + 91
1 0 + -2139062144
>
> 1. After removing QuickTimeH264.component the (the full file is about
> 4 gig) video plays - with -horrible- performance tho...
>
> 2. Playing the test file i posted here works better - still
> unacceptable framerates... (MUCH worse the the avi version - but no
> crash)
Maybe scaling back on the frequency of idles for the Matroska
importer could help, though it would have to only be while playing,
and it could lead to more frame skips for content that isn't as CPU
intensive (since samples would have to be added to the track more
frequently causing a redecode of the current frame...)
>
> When I remove QuickTimeH264.component ben's mkv file plays fine. But
> unfortunately, ffh264 is a bit slower than apple decoder at decoding
> 720p samples available on http://www.apple.com/quicktime/guide/hd/ ,
> and removing QuickTimeH264.component isn't a solution for now.
Of course, but this does make it seem like Apple's decoder is using
GPU acceleration. Though I doubt that the API is public for our use,
just like the API for GPU MPEG-2 acceleration.
> p.s. : a totally unrelated thing... why does the matroska importer
> create a new edit list every time it adds new samples?
Probably due to http://trac.perian.org/ticket/30, we're currently
always subtracting 1 from the display duration since sometimes what
we calculate is 1 too large. Probably only subtracting 1 if there's
an error adding the media to the track would fix this; I'll check
this since I didn't realize that it was causing this for video tracks
without frame reordering. Of course, the proper fix is to figure out
why the duration we calculate is sometimes 1 too large, but I haven't
had much luck figuring that out yet.
-David
On Apr 22, 3:44 pm, David Conrad <umovi...@gmail.com> wrote:
> Maybe scaling back on the frequency of idles for the Matroska
> importer could help, though it would have to only be while playing,
> and it could lead to more frame skips for content that isn't as CPU
> intensive (since samples would have to be added to the track more
> frequently causing a redecode of the current frame...)
Well, we aren't setting droppable frames yet, are we? I think that
should improve things.
Obviously if I could get Shark profiles for an ATV I could work on it,
but that seems hard.
Well, I have discovered exactely the same problem the hard way before
I found out about this discussion group ;-)
mkv/h264 plays fine on MBP, but fails to play on aTV. (Crash if
QTH264.component installed, extremly stuttering if the
QTH264.component is removed).
I have installed shark on my aTV and I am happy to supply some
profiles, it you tell me what kind of profiles you want.
On May 5, 8:14 am, nikwest <west...@gmail.com> wrote:
> I have installed shark on my aTV and I am happy to supply some
> profiles, it you tell me what kind of profiles you want.
"Time Profile" of Everything while it's playing, then L2 Cache Miss
Profile if you can get it.
Oh, and has the mkv finished loading when you play it?
And is it on a network mount, or on the atv HD?