Kodi Community Forum

Full Version: [AppleTV] .iso playback broken with Broadcom CrystalHD
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hi all,

I'm seeing an issue playing .iso files with r28256 and later (up to r30092) with the broadcom CrystalHD enabled.

Already checked in the .iso related threads but I don't see anything similar; also cheched the "CyrstalHD Status as of r28256:" by Davilla and again, my issue is not listed there.

In detail:

Playback of .iso file was perfect with 9.11. With r28256 and broadcom cristalHD selected as render method the .iso files are not played correctly: a huge black horizontal line is present on top of the screen and the video seems to be streched vertically and almost half of it (the bottom side) is outside the TV display.
When, still with r28256, I select "software" as render method the .iso plays correctly (just slower, as expected).
Tried with the latest r30092 and the problem is exactly the same with the difference that I don't see anymore the render method setting (why??)

My TV (xbmc) resolution is 1280x720@60Hz.

I'm trying to post xbmc.log (after "cleaning it": changing svn back and forth seems to have caused a 775 MB xbmc.log file!)

Thanks
Tested with the latest svn r30164.

The behavior is reproducible and here I'm providing more info and logs.

Platform is aTV
Launcher 3.2.4
XBMC version: svn r30164 (copied XBMC.app into .../Applications from the .dmg)

Here is the first xbmc.log: http://pastebin.com/8te22PEz

This has been taken when the HW decoding is enabled and the playback problem is present. This is the exact sequence related to this log:

- delete xbmc.log
- start xbmc (r30164) set as follows:
- render method: basic shaders (ARB)
- allow hw acceleration (crystalHD): enabled

- browse smb folder
- start playback of .iso file (resume): playback is KO as already described: large black horizontal line on top of the TV screen and video stretched with almost half outside the bottom of the tv screen.
(BTW: if there is any way to take a screen-shot pls let me know)
- stop playback after about 2 mins
- shutdown XBMC

Then I tried again disabling the HW acceleration and the playback is great.

Here is the xbmc.log: http://pastebin.com/ebLUKvpV

And the sequence:
- delete xbmc.log
- start xbmc (r30164) set as follows:
- render method: Software
- allow hw acceleration (crystalHD): disabled

- browse smb folder
- start playback of .iso file (resume): playback is great
- stop playback
- shutdown XBMC

I'm not posting the mediainfo as it's not returning any relevant info as the video is inside an .iso "container".
davidg Wrote:Tested with the latest svn r30164.

The behavior is reproducible and here I'm providing more info and logs.

Platform is aTV
Launcher 3.2.4
XBMC version: svn r30164 (copied XBMC.app into .../Applications from the .dmg)

Here is the first xbmc.log: http://pastebin.com/8te22PEz

This has been taken when the HW decoding is enabled and the playback problem is present. This is the exact sequence related to this log:

- delete xbmc.log
- start xbmc (r30164) set as follows:
- render method: basic shaders (ARB)
- allow hw acceleration (crystalHD): enabled

- browse smb folder
- start playback of .iso file (resume): playback is KO as already described: large black horizontal line on top of the TV screen and video stretched with almost half outside the bottom of the tv screen.
(BTW: if there is any way to take a screen-shot pls let me know)
- stop playback after about 2 mins
- shutdown XBMC

Then I tried again disabling the HW acceleration and the playback is great.

Here is the xbmc.log: http://pastebin.com/ebLUKvpV

And the sequence:
- delete xbmc.log
- start xbmc (r30164) set as follows:
- render method: Software
- allow hw acceleration (crystalHD): disabled

- browse smb folder
- start playback of .iso file (resume): playback is great
- stop playback
- shutdown XBMC

I'm not posting the mediainfo as it's not returning any relevant info as the video is inside an .iso "container".

Odd in that CrystalHD is excluded from being used for mpeg2 playback from DVDs. Your 1st is using mpeg2codec, the second is using ffmpegcodec. mpeg2codec is the proper choice for mpeg2 DVDs (in iso's or not).

If you type 'o' during playback, an OSD pops and you can see the codec being used. "ff-xxx" is ffmepg, "chd-xxx" is crystalhd, etc"
Hi Davilla,

Thanks for the prompt reply (and the great work done!)

How can I type 'o' during playback with the aTV? I just have the apple standard remote...

Also, I've seen there is a setting for the screen-shot folder but how can I take screen-shots?

Thanks
davidg Wrote:Hi Davilla,

Thanks for the prompt reply (and the great work done!)

How can I type 'o' during playback with the aTV? I just have the apple standard remote...

Also, I've seen there is a setting for the screen-shot folder but how can I take screen-shots?

Thanks

not possible with the Apple IR remote unless you re-map one of the limited number of buttons.

if you have an osx box, there's http://code.google.com/p/atv-xbmc-launch...bmc_remote

that's a command-line app the sends key-presses to a remote xbmc box

./xbmc_remote <IP of remote xbmc> 9777

you must have the remote set to respond to command from an external source.
Hi Davilla,

I'd say that remapping just for troubleshooting purposes may be easier but I've been digging quite a lot but I did not find any guidance for remapping remote buttons to strings, like the 'o' you mentioned.

On the other side, I managed to download xbmc_remote on my MBP (Mac OS 10.6.3) but - sorry for asking - should I compile it? Also what is "9777"? Does it correspond to the 'o' char?

Thanks
davidg Wrote:Hi Davilla,

I'd say that remapping just for troubleshooting purposes may be easier but I've been digging quite a lot but I did not find any guidance for remapping remote buttons to strings, like the 'o' you mentioned.

On the other side, I managed to download xbmc_remote on my MBP (Mac OS 10.6.3) but - sorry for asking - should I compile it? Also what is "9777"? Does it correspond to the 'o' char?

Thanks

if you grabbed the binary, "chmod +x xbmc_remote"

9777 is the default tcp/ip port for remote control.

setup your xbmc for access by remote computers, run xbmc_remote (see other post)

it makes a window, when that window is in front, anything you type will get sent to the remote xbmc. you can control a remote xbmc as if it's running locally.
Thanks Davilla! I'm able to send keys to XBMC! :-)

In both cases, ie 1) with .iso not playing correctly with CrystalHD enabled and 2) .iso playing fine with software rendering I see, typing 'o', that the decoder is always "mpeg2video.

How can I take a screen-shoot to post the images?

I wonder if anybody else isn't seeing the same issue with .iso and CrystalHD...
Davilla, it seems I got it!

Playing with the video settings I see that changing the "interlaced handling" from the default value "auto select" to "none" the video playback gets normal.

So it should not be related with CrystalHD, but with the svn after 9.11 where it seems to me (checked with 9.11) the default setting for "interlaced handling" has been changed from none to auto select.

Thanks Davilla for your valuable support.
davidg Wrote:Davilla, it seems I got it!

Playing with the video settings I see that changing the "interlaced handling" from the default value "auto select" to "none" the video playback gets normal.

So it should not be related with CrystalHD, but with the svn after 9.11 where it seems to me (checked with 9.11) the default setting for "interlaced handling" has been changed from none to auto select.

Thanks Davilla for your valuable support.

Very odd, interlace handling should not be causing issue with files that are not decoded with CrystalHD.
Davilla,

So there could be something else broken in the post 9.11 svn's and it may be worth reproducing the issue, do you agree?

That should be easy, I'm seeing the problem with *all* my .iso files. Please let me know in case some additional info is needed.
davidg Wrote:Davilla,

So there could be something else broken in the post 9.11 svn's and it may be worth reproducing the issue, do you agree?

There's been 30234 - 26018 = 4216 commits between 9.11 and todays svn trunk. No doubt it's been working, broke, working, broke (rinse/repeat) many times since 9.11.

I'll take a look when I get a chance.