[wrxtasy]

. Pi1 has a standard overclock (arm_freq=100, core_freq=500, over_voltage=6).

So, if you have a Pi1 with overclock and a decent network setup (e.g. wired/nfs) then MVC/framepacked is possible.

Thanks for that Popcornmix, did you perhaps mean the Turbo Overclock settings on the Pi1 ? ...

arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6

[popcornmix]

Thanks for that Popcornmix, did you perhaps mean the Turbo Overclock settings on the Pi1 ? ...

arm_freq=1000
core_freq=500
sdram_freq=500
over_voltage=6

That will work - I happened not to have the sdram_freq when testing.
By "standard overclock", I just meant "common overclock" (as it not a ridiculously high one, rather than any official meaning).

[hdmkv]

No. If you play a TrueHD track it will be decoded and downmixed to "number of channels" (from system/audio settings).
If you set "number of channels" to 8 then all 8 channels will be output as PCM.
If the file has multiple tracks you may need to switch (in OSD audio settings) to the TrueHD track.

TrueHD is quite expensive to decode, so is not recommended on Pi1. Pi2 has no trouble with it.

Thanks popcornmix. It appears 3D is only supported for MKV (created by MakeMKV), not in ISO container? Also, in MKV, TrueHD won't have core track unless you add it as a separate track. Is this needed, or only the TrueHD w/o core is fine for both Pi2 decoding or passing as PCM?

[lolli_lutscher]

Do I need a special setting to decode TrueHD to PCM?

No. If you play a TrueHD track it will be decoded and downmixed to "number of channels" (from system/audio settings).
If you set "number of channels" to 8 then all 8 channels will be output as PCM.
If the file has multiple tracks you may need to switch (in OSD audio settings) to the TrueHD track.

TrueHD is quite expensive to decode, so is not recommended on Pi1. Pi2 has no trouble with it.

Thanks, I'm using the Raspi 2.
It seems to work fine with output to 5.1 for me.

[popcornmix]

Thanks popcornmix. It appears 3D is only supported for MKV (created by MakeMKV), not in ISO container? Also, in MKV, TrueHD won't have core track unless you add it as a separate track. Is this needed, or only the TrueHD w/o core is fine for both Pi2 decoding or passing as PCM?

ffmpeg doesn't support extracting the second eye view from BluRay ISOs (or folders). It is something we are working on to support.
makemkv does support this, which is why the mkv files work.

TrueHD doesn't have a core track. All Blu-Ray's must include an AC3 track if they include TrueHD (as TrueHD support is not mandatory for a BluRay player).
So, you may consider the AC3 track as the "core" track, but the two tracks are independent (i.e. if you support TrueHD you don't require the AC3 track).

You say "decoding or passing as PCM", but these are really the same thing. All non-passthrough(*) audio is passed as PCM.
The PCM may be stereo PCM, which needs decoding and downmixing, or multichannel PCM which still needs decoding, but may not need downmixing (if number of channels match).

(*) technically all passthrough formats are passed as PCM too, just with specific sample rate, number of channels and framing data.
Unfortunately HD audio passthrough chooses 8 channels @ 192kHz as it's transport which the Pi cannot support.
The vast majority of BluRays are encoded at 48kHz which we can support at 8 channels, but we need to decode the audio first.
The receiver won't recognise HD passthrough in a 48kHz channel, but obviously will play the 48kHz decoded PCM stream.

[hdmkv]

Thanks. Again, frame-packed 3D via Kodi is a terrific achievement. Will follow progress.

Re: 3D, possible to switch left/right eye? Some 3D BD's have right-eye first (like 'Drive Angry', 'Edge of Tomorrow', etc.). Some displays make it easily to swap l/r, but on some, it's somewhere in settings, so having ability in playback to switch is ideal.

[popcornmix]

Thanks. Again, frame-packed 3D via Kodi is a terrific achievement. Will follow progress.

Re: 3D, possible to switch left/right eye? Some 3D BD's have right-eye first (like 'Drive Angry', 'Edge of Tomorrow', etc.). Some displays make it easily to swap l/r, but on some, it's somewhere in settings, so having ability in playback to switch is ideal.

Which eye is which is very explicit from MVC, so I'd expect this to be correct without manual intervention.
Feel free to test and let me know (or upload a sample and I'll test).
It would be simple to add a eye swap option if it is required.

[hdmkv]

I was on the fence about getting a Pi 2, but now, ordering one to try out .

[Milhouse]

If eye swapping is required, this sounds like it should be set in the OSD on a per-movie basis, where it could also be set as the default for all movies?

[popcornmix]

If eye swapping is required, this sounds like it should be set in the OSD on a per-movie basis, where it could also be set as the default for all movies?

Yes. There is an OSD setting, but it's not been plumbed in yet for MVC.
I'm wondering whether it is actually needed.
It seems hard to imagine that a BluRay would make it impossible to detect which view belongs to which eye, and so require every user who ever watches it to manually select the correct option.
And assuming that information is in the MVC stream, then we should parse it correctly. If the information is there and we are not parsing it, then fixing it there would be preferable.

For something like a re-encoded half-TAB 3D movie, then there are more stages where someone may have got things wrong, so a manual override makes more sense
(although I've got ~50 3D samples of different formats and I've never required this so far).

But as the gui/osd support is already there I'd may as well plumb it in.
But, any samples of files where this isn't determined automatically would be interesting.

[lolli_lutscher]

If eye swapping is required, this sounds like it should be set in the OSD on a per-movie basis, where it could also be set as the default for all movies?

Yes. There is an OSD setting, but it's not been plumbed in yet for MVC.
I'm wondering whether it is actually needed.
It seems hard to imagine that a BluRay would make it impossible to detect which view belongs to which eye, and so require every user who ever watches it to manually select the correct option.
And assuming that information is in the MVC stream, then we should parse it correctly. If the information is there and we are not parsing it, then fixing it there would be preferable.

For something like a re-encoded half-TAB 3D movie, then there are more stages where someone may have got things wrong, so a manual override makes more sense
(although I've got ~50 3D samples of different formats and I've never required this so far).

But as the gui/osd support is already there I'd may as well plumb it in.
But, any samples of files where this isn't determined automatically would be interesting.

There is media players like Popcorn Hour, which check the filename for .3DRL. If it's in the name, then they automatically change to the right eye first.
I like this, but a function in the OSD is ok.

[da-anda]

we could add support for filename detection as we already have a keyword parser for the 3D flags. Not sure if it's worth the effort though as I don't think there is much content with reverse order of eyes

[movie78]

IS BLURAY 3D ISO FRAME PACKED SUPPORTED?

Is this update only applies to Pi?

[cncb]

Sorry if I missed this but is there a special installation procedure for the "firmware" part of it? I downloaded the tar for RPi1 and put it in the "Update" folder and rebooted to upgrade from OE 5.0. I did a "soft reset" and the new 3D settings are turned on but 3D output is not working.

[lolli_lutscher]

we could add support for filename detection as we already have a keyword parser for the 3D flags. Not sure if it's worth the effort though as I don't think there is much content with reverse order of eyes

I know about 11 or 12 movies right now, maybe a few more.
Unfortunately, I can't find a list with all of them.