[mrabcx]

XBMC can decode non-h264 HD video on ATV2 in software but it's not fast enough ... so I was just wondering would it be possible to add some kind of delay of lets say 1 or 2 mins (or more) where the video would be decoded and buffered before a playback was started. Can something like that be made to avoid the stuttering issues ? If one would have to re-buffer a couple of times in a movie then I think even that will be more than acceptable.....

[chuckles]

XBMC can decode non-h264 HD video on ATV2 in software but it's not fast enough ... so I was just wondering would it be possible to add some kind of delay of lets say 1 or 2 mins (or more) where the video would be decoded and buffered before a playback was started. Can something like that be made to avoid the stuttering issues ? If one would have to re-buffer a couple of times in a movie then I think even that will be more than acceptable.....

If its that important to you what not get another device that can handle HD xvid (or whatever codec)?
or re-encode?
Honest question sorry if it sounds a little blunt.

[spiff]

sure, decoding two mins of video at 720p, 24fps would only take

resolution*data per pixel * number of frames * number of seconds =

1280*720*1.5*24*60*2 = 3.7GB memory for 720p.
1920*1080*1.5*24*60*2 = 8.3GB memory for 1080p.

assuming video is kept in yuv, multiply by 4/1.5 for rgba.

audio would be, assuming 48kHz 16bit 5.1 audio

48000*6*2*60*2 = 65MB.

so a total of approx 3.8GB memory for 720p, 8.4GB for 1080p. does your atv2 have that to offer? didn't think so.

[Memphiz]

sure, decoding two mins of video at 720p, 24fps would only take

resolution*data per pixel * number of frames * number of seconds =

1280*720*1.5*24*60*2 = 3.7GB memory for 720p.
1920*1080*1.5*24*60*2 = 8.3GB memory for 1080p.

assuming video is kept in yuv, multiply by 4/1.5 for rgba.

audio would be, assuming 48kHz 16bit 5.1 audio

48000*6*2*60*2 = 65MB.

so a total of approx 3.8GB memory for 720p, 8.4GB for 1080p. does your atv2 have that to offer? didn't think so.

impressive *laughs* ... not the best idea for atv2 hehe.

@ the users who are annoyed by stuttering non h.264 files

PLEASE! Be patient. When Eden is released we have some major changes and version bumps of dependend librarys on the plan. Just wait if things get better then.

And yes something like that can easily last a year - thats why we devs have so much fun on it - because we don't need to - you know?

The XBMC ios port isn't even 1 year old. And there isn't even a official release for it. So give it some more time.

[spiff]

we won't ever be able to lift this restriction. the hw is simply too weak.

[blacklist]

XBMC can decode non-h264 HD video on ATV2 in software but it's not fast enough ... so I was just wondering would it be possible to add some kind of delay of lets say 1 or 2 mins (or more) where the video would be decoded and buffered before a playback was started. Can something like that be made to avoid the stuttering issues ? If one would have to re-buffer a couple of times in a movie then I think even that will be more than acceptable.....

BTW, there are quite a few things you can do to avoid stuttering and decoding issues. Look elsewhere in the forums to find some techniques, including being wired, adjusting your cache settings, and using a different transport protocol (SMB is the worst, FTP a little better, and WebDAV the best in my experiance)

Before you assume that its just a hardware decoding issue, make sure you eliminate all the other potential bottlenecks. I use an ATV2 now as my every day device and have no stuttering issues at all, all the way up to 1080 movie content..

[Ned Scott]

we won't ever be able to lift this restriction. the hw is simply too weak.

Undocumented, more like it.

[Memphiz]

we won't ever be able to lift this restriction. the hw is simply too weak.

We can't lift the restriction of HW - but newer ffmpeg version make more out of neon... firecore player already showed us that it can handle 720p xvid in software.

[curlyjs]

Is the newer ffmpeg implementation targeted for eden release?

Thanks,

[davilla]

Is the newer ffmpeg implementation targeted for eden release?

Thanks,

No, we are in a code freeze while we hunt bugs. Updating to a newer ffmpeg would violate the code freeze.

[Paulkai]

Interesting comments, does this mean when Eden is released we will see a newer stable version of xbmc for atv2!!

[Memphiz]

Interesting comments, does this mean when Eden is released we will see a newer stable version of xbmc for atv2!!

and now you all start to ask all over when its done ... i swear i start deleting those posts if it gets too much ...

one last word to ffmpeg :

its not just compiling a new version and done it is - its a huge shit of workload to get a new version running for xbmc - and its on the plan ...

[davilla]

Interesting comments, does this mean when Eden is released we will see a newer stable version of xbmc for atv2!!

try a nightly build and report back, eden will come from that.

[akohlsmith]

I'm frankly surprised that SMB performance is so poor. The protocol itself isn't bad. I'd love to play 1080p MPEG2 content that I capture off of my antenna on the atv2 without transcoding but right now it's just not happening. It's a minor bump and I'm hoping with time the mythtv frontend plugin or plex plugins will help. :-)

[davilla]

I'm frankly surprised that SMB performance is so poor. The protocol itself isn't bad. I'd love to play 1080p MPEG2 content that I capture off of my antenna on the atv2 without transcoding but right now it's just not happening. It's a minor bump and I'm hoping with time the mythtv frontend plugin or plex plugins will help. :-)

That would be 1080i MPEG2 content, no station is transmitting 1080p MPEG2 off-the-air. Regardless 1080p/1080i MPEG2, the atv2 cannot use VideoToolBox to hardware decode MEPG2 and there's no way it can handle that size/format with CPU alone.