[infinity85]

Hi infinity85, I am trying to use a iso MVC file. Do you know how to many edit that? Thanks,

Hi MaDeMaNN

No I don't know it unfortunately, but as I posted right now this seems to be not necessary as the Odroid seems to decode MVC always to 3D if it is present (at least in my mkv's). Turns out (at least in my tests that I made in my last post) that the headersetting for MVC was mandatory in OpenELEC 6 but not in v7 anymore. Still I would set it for nonMVC 3D mkv's (H-SBS and H-TAB).

Regarding ISOs, I've never had any to try it and also I don't think there is such thing as headers to set there, should work automatically then.

As I also tested a regular H-SBS mkv 3d (non MVC) and it did not switch my tv automatically to 3D as expected from my Raspberry Pi2, I think that there is just somewhere a bug in this Kodi build.

But back to the ISO: Does it display only a proper 2D picture if you play it, or does it show both eyes? So TAB or SBS? That means... if you switch your tv manually to 3D, will it picture a proper 3D picture then?

[noggin]

As I also tested a regular H-SBS mkv 3d (non MVC) and it did not switch my tv automatically to 3D as expected from my Raspberry Pi2, I think that there is just somewhere a bug in this Kodi build.

I wouldn't expect a C2 to switch a TV to H-SBS mode when playing H-SBS content - though it may have the ability to send the required data over HDMI it may not.

AIUI the Pi can be persuaded to output H-SBS as Frame Packed (with the Pi doing the 2:1 stretch for each eye feed rather than the TV) - and that will definitely trigger 3D.

[infinity85]

As I also tested a regular H-SBS mkv 3d (non MVC) and it did not switch my tv automatically to 3D as expected from my Raspberry Pi2, I think that there is just somewhere a bug in this Kodi build.

I wouldn't expect a C2 to switch a TV to H-SBS mode when playing H-SBS content - though it may have the ability to send the required data over HDMI it may not.

AIUI the Pi can be persuaded to output H-SBS as Frame Packed (with the Pi doing the 2:1 stretch for each eye feed rather than the TV) - and that will definitely trigger 3D.

hmmm.. I think I don't understand this completely with the 2:1 stretch. If I don't set the header to 1 (SBS) or 3 (TAB) the pi simply outputs the regular 2 eyed picture as a 2D. So both eyes side by side. That is not a strech of 2:1 correct? So how could I imagine the 2:1 stretch that you mentioned?

Generally: It would be a real pity for this device if it could not trigger 3D on the TV. It can do almost everything now... I'm wondering what the Pi does over HDMI to trigger 3D on my TV. As it can also do HDMI CEC (which is not responsible for the automatic 3D switch, though) and so on, I thought there should be a quite complete featureset regarding HDMI compatibility :/


EDIT:
Found this post from popcornmix who is a pro afaik: http://openelec.tv/forum/124-raspberry-p...60p#109464

But somehow I don't get a clue what he means or how it has to be done what he wants. If somebody could explain me this a bit better, I could post the log here. May be this could help understanding the difference between RPi2 vs Odroid C2 in terms of handling 3D signals.

[noggin]

As I also tested a regular H-SBS mkv 3d (non MVC) and it did not switch my tv automatically to 3D as expected from my Raspberry Pi2, I think that there is just somewhere a bug in this Kodi build.

I wouldn't expect a C2 to switch a TV to H-SBS mode when playing H-SBS content - though it may have the ability to send the required data over HDMI it may not.

AIUI the Pi can be persuaded to output H-SBS as Frame Packed (with the Pi doing the 2:1 stretch for each eye feed rather than the TV) - and that will definitely trigger 3D.

hmmm.. I think I don't understand this completely with the 2:1 stretch. If I don't set the header to 1 (SBS) or 3 (TAB) the pi simply outputs the regular 2 eyed picture as a 2D. So both eyes side by side. That is not a strech of 2:1 correct? So how could I imagine the 2:1 stretch that you mentioned?

There are three ways to output HSBS 1080p (which is two 1920x1080 eye feeds 2:1 compressed to 960x1080 and put next to each other in a single 1920x1080 frame) over HDMI :

1. Output HSBS as if it is 2D 1920x1080. Don't do anything out of the ordinary. As far as the TV is concerned it is receiving a normal 2D image until you press the 3D button and select an SBS mode.

2. Output HSBS as a 1920x1080 video as above - but set a flag in one of the HDMI data packets that signals that the video signal contains HSBS content triggering the TV to automatically go into SBS mode.

3. Convert HSBS to a 1920x1080 3D Frame Packed output (in reality this is 1920x2205 video signal with two 1920x1080 eye feeds separated by 45 lines of blanking) The Pi is doing the 2:1 stretch to convert each 960x1080 eye feed to 1920x1080 before outputting (rather than leaving the TV to do it) This is - I think - what one of the 3D options does.

I suspect the ODroid is currently doing 1? but the Pi does 2 and/or 3?

Generally: It would be a real pity for this device if it could not trigger 3D on the TV. It can do almost everything now... I'm wondering what the Pi does over HDMI to trigger 3D on my TV. As it can also do HDMI CEC (which is not responsible for the automatic 3D switch, though) and so on, I thought there should be a quite complete featureset regarding HDMI compatibility :/

The Pi platform seems to 'do' 3D a bit better. It has Frame Packed output and seems more 'aware' of some aspects of HDMI as a result? Or maybe the C2 devs just haven't got there yet. (Though I think Frame Packed output may be a lost cause?)

[xxxbugxxxx]

BTW

somebody has already forked a 10bit output in windows based KODI in link below. maybe this can be done for linux also?


http://forum.kodi.tv/showthread.php?tid=212962

probably packed padding.

ARGB2101010 = SDL2.define_pixelformat(PIXELTYPE:ACKED32, PACKEDORDER::ARGB, PACKEDLAYOUT::N2101010, 32, 4)

Good blog post here on the challenges that 10 bit video can introduce with regard to byte-alignment. 8-bit video aligns nicely with bytes, 10 bit video can be done lots of different ways, some require more shuffling than others, and code optimisation can give big dividends : http://obe.tv/about-us/obe-blog/item/21-...onversions

Sounds like the ARGB2101010 is possibly v210?

[MaDeMaNN]

It gives me the option in the simplified menu to play 3D movie then it asks preferred mode and then after that its just split screen on the TV and it doesnt automatically go into 3D mode. I will try to put MVC in the iso file name to see if that helps. I also have a Q10 pro that automatically switches to 3D mode fine.

[infinity85]

I wouldn't expect a C2 to switch a TV to H-SBS mode when playing H-SBS content - though it may have the ability to send the required data over HDMI it may not.

AIUI the Pi can be persuaded to output H-SBS as Frame Packed (with the Pi doing the 2:1 stretch for each eye feed rather than the TV) - and that will definitely trigger 3D.

hmmm.. I think I don't understand this completely with the 2:1 stretch. If I don't set the header to 1 (SBS) or 3 (TAB) the pi simply outputs the regular 2 eyed picture as a 2D. So both eyes side by side. That is not a strech of 2:1 correct? So how could I imagine the 2:1 stretch that you mentioned?

There are three ways to output HSBS 1080p (which is two 1920x1080 eye feeds 2:1 compressed to 960x1080 and put next to each other in a single 1920x1080 frame) over HDMI :

1. Output HSBS as if it is 2D 1920x1080. Don't do anything out of the ordinary. As far as the TV is concerned it is receiving a normal 2D image until you press the 3D button and select an SBS mode.

2. Output HSBS as a 1920x1080 video as above - but set a flag in one of the HDMI data packets that signals that the video signal contains HSBS content triggering the TV to automatically go into SBS mode.

3. Convert HSBS to a 1920x1080 3D Frame Packed output (in reality this is 1920x2205 video signal with two 1920x1080 eye feeds separated by 45 lines of blanking) The Pi is doing the 2:1 stretch to convert each 960x1080 eye feed to 1920x1080 before outputting (rather than leaving the TV to do it) This is - I think - what one of the 3D options does.

I suspect the ODroid is currently doing 1? but the Pi does 2 and/or 3?

Generally: It would be a real pity for this device if it could not trigger 3D on the TV. It can do almost everything now... I'm wondering what the Pi does over HDMI to trigger 3D on my TV. As it can also do HDMI CEC (which is not responsible for the automatic 3D switch, though) and so on, I thought there should be a quite complete featureset regarding HDMI compatibility :/

The Pi platform seems to 'do' 3D a bit better. It has Frame Packed output and seems more 'aware' of some aspects of HDMI as a result? Or maybe the C2 devs just haven't got there yet. (Though I think Frame Packed output may be a lost cause?)

phuh, interesing post! I will have to read it again with a fresh head tomorrow morning xD. Do you have an idea how to find out what the pi does with a particular testfile?

Tried now this "tvservice -s" on my Raspberry Pi2 (OpenELEC 6.0.3) playing a H-SBS File:

Code:

OpenELEC:~ # tvservice -s
state 0x12000a [HDMI CEA (32) 3D FP RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive
OpenELEC:~ # tvservice -s
state 0x12000a [HDMI CEA (32) RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive
OpenELEC:~ #

1. File was with headersetting 1 (SBS): Switched TV automatically to 3D mode
2. Same file without headersetting: TV did not switch. Displays both eyes side by side, have to switch manually


Tried the same on my Odroid with LibreELEC... the service is not there haha:

Code:

LibreELEC:~ # tvservice -s
-sh: tvservice: not found

But did a "dmesg output" also on my Odroid and found this here (different topic):

Code:

[   19.671596] cectx c810023c.aocec: aml_cec_class_devnode(): mode is 1b6
[   19.736898] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   19.772518] CEC: tx msg len: 1   dat: 2b
[   19.936798] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   19.972447] CEC: tx msg len: 1   dat: 2c
[   20.136731] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   20.172415] CEC: tx msg len: 1   dat: 2c
[   20.336699] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   20.372555] CEC: tx msg len: 1   dat: 2d
[   20.536830] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   20.572546] CEC: tx msg len: 1   dat: 2d
[   20.736819] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   20.772713] CEC: tx msg len: 1   dat: 2e
[   20.936988] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   20.972517] CEC: tx msg len: 1   dat: 2e
[   21.136789] cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!
[   24.906993] cectx c810023c.aocec: aml_cec_class_devnode(): mode is 1b6

Any Idea why this TX error appears? I think this is the reason why I broke my head about not getting my RemotePi Board (msldigital) to work on the Odroid C2 with standard GPIO pinning

[MaDeMaNN]

Ok I can confirm it works now. I had to manually turn 3D on my TV then select the correct setting and it worked perfect. Thanks again all that have helped and wrxtasy especially for continuing to support this great little box.

[infinity85]

Ok I can confirm it works now. I had to manually turn 3D on my TV then select the correct setting and it worked perfect. Thanks again all that have helped and wrxtasy especially for continuing to support this great little box.

Interesting! So kodi recognizes it as 3D MVC I think? (it gives me the option in the simplified...) means that the prompt in kodi comes automatically? And how is the playback then in this split screen? Terrible like mine in my captures (jumping frames?) or is it smooth from the beginning? A real pity that we have to switch tv manually.. would be so nice and perfect, if it went automatically like on raspberry

[wrxtasy]

Thanks for testing guys...

I have no 3D TV to test but I can confirm just by looking at the Horizontally Split pictures that 3D MVC files have jumping frame problems.
3D ISO's however looked smooth as MaDeMaNN has found, when I selected the bottom 3D option on the Mini Kodi Bluray popup menu.

There are 3D ISO Samples found here:
http://kodi.wiki/view/Samples

I have not plugged the RPi code into the current release yet. There are some Kodi 3D GUI options I see sitting in there that may or may not work on AML.

Code:

cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!

You would have to ask Raybuntu over on the HK C2 forums about this as its to do with the new Hybrid CEC control code in the Kernel.
What you could do is switch the new CEC Adapter off completely in Kodi's Settings > System > Input > Peripherals > CEC Adapter and see if anything changes.

[infinity85]

[...]
I have not plugged the RPi code into the current release yet. There are some Kodi 3D GUI options I see sitting in there that may or may not work on AML.

Code:

cectx c810023c.aocec: tx_irq_handle(): TX ERROR!!!

You would have to ask Raybuntu over on the HK C2 forums about this as its to do with the new Hybrid CEC control code in the Kernel.
[...]

With RPi code you are referring to the possibility of autoswitch to 3D on TVs or something else?

Out of logic the automatic 3Dswitch for TVs should be linked somehow to the automatic framerateswitching in kodi. As framerateswitching is working for 2D material with 60hz, 50hz for IPTV and 24hz for Blurays the basics are there I assume.

Here I looked at the modes the rpi uses in my most usecases (tvservice -s)

• Kodi Gui: state 0x12000a [HDMI CEA (16) RGB lim 16:9], 1920x1080 @ 60.00Hz, progressive
  
• LiveTV (IPTV Simple Client): state 0x12000a [HDMI CEA (31) RGB lim 16:9], 1920x1080 @ 50.00Hz, progressive
  
• 3D movies: state 0x12000a [HDMI CEA (32) 3D FP RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive
  
• 2D movies: state 0x12000a [HDMI CEA (32) RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive
  

Its the list of modes my RPi gives me... if this could be useful somehow...:

Code:

OpenELEC:~ # tvservice -mCEA
Group CEA has 18 modes:
           mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
           mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
           mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
           mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive 3D:FP|TopBot|SbS-HH
           mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced 3D:TopBot|SbS-HH
           mode 6: 720x480 @ 60Hz 4:3, clock:27MHz x2 interlaced
           mode 7: 720x480 @ 60Hz 16:9, clock:27MHz x2 interlaced
  (prefer) mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive 3D:TopBot|SbS-HH
           mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
           mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
           mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive 3D:FP|TopBot|SbS-HH
           mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced 3D:TopBot|SbS-HH
           mode 21: 720x576 @ 50Hz 4:3, clock:27MHz x2 interlaced
           mode 22: 720x576 @ 50Hz 16:9, clock:27MHz x2 interlaced
           mode 31: 1920x1080 @ 50Hz 16:9, clock:148MHz progressive 3D:TopBot|SbS-HH
           mode 32: 1920x1080 @ 24Hz 16:9, clock:74MHz progressive 3D:FP|TopBot|SbS-HH
           mode 33: 1920x1080 @ 25Hz 16:9, clock:74MHz progressive 3D:TopBot|SbS-HH
           mode 34: 1920x1080 @ 30Hz 16:9, clock:74MHz progressive 3D:TopBot|SbS-HH

Thanks for referring to Raybuntu! I will ask him about this. Actually I am not using CEC for the remote, so I did not notice anything yet except these errormessages.


EDIT:
Another comparison testrun on Raspberry Pi with a Half-SBS file:

a) If using 3D.SBS. flags in filename (without stereoheader=1) and having activated Support MVC video (full frame 3D) in settings:

Code:

OpenELEC:~ # tvservice -s
state 0x12000a [HDMI CEA (32) 3D FP RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive

So the Raspberry tricks the TV into automatic 3D switch by sending some kind of FramePacked signal (but the video is not really sent framepacked to my TV I think.


But more interesting is the next try...

b) If using 3D.SBS. flags in filename (without stereoheader=1) and having deactivated Support MVC video (full frame 3D) in settings:

Code:

OpenELEC:~ # tvservice -s
state 0x12000a [HDMI CEA (32) 3D SbS RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive

Here is nothing related to framepacked, so triggering the TV into 3D must be somehow possible without using a framepacked signal or impuls or so.

[MidnightWatcher]

Has anyone else noticed that videos often start playback around the 7 second mark instead of the very beginning of the video? Large or small, doesn't matter. Any ideas what could be causing this?

I just noticed that too same with Live TV but i think it is the refrefreshrate switch on the C2 is slow compare too my rpi 3.

@Pienoet, I don't now what is going on with MidnightWatchers setup. The exact same files tested on my system start virtually instantaneously. Unable to reproduce his issue with the .mov files.

Even when disabling refresh rate switching the same still happens on my setup - playback often begins or plays "catch up" and sputters to then play normally around the 7 second mark. Tried files directly from the eMMC and from the attached USB HDD, same issue happens.

wrxtasy, what buffermode, cachemembuffersize and readbufferfactor settings are you using in advancedsettings.xml?

I also have another question. I've been noticing the occasional stutter or what appears to be a frame skipping from time to time. If I remember correctly I read elsewhere that the C2 is doing true 23.976 fps playback, even though the TV/projector may report 24.00. If that is the case, could what I'm seeing be somehow similar to or related to the issue described here in the link below?

https://discourse.osmc.tv/t/mmal-skipped...s/14455/15

[Sam.Nazarko]

Has anyone else noticed that videos often start playback around the 7 second mark instead of the very beginning of the video? Large or small, doesn't matter. Any ideas what could be causing this?

I just noticed that too same with Live TV but i think it is the refrefreshrate switch on the C2 is slow compare too my rpi 3.

@Pienoet, I don't now what is going on with MidnightWatchers setup. The exact same files tested on my system start virtually instantaneously. Unable to reproduce his issue with the .mov files.

Even when disabling refresh rate switching the same still happens on my setup - playback often begins or plays "catch up" and sputters to then play normally around the 7 second mark. Tried files directly from the eMMC and from the attached USB HDD, same issue happens.

wrxtasy, what buffermode, cachemembuffersize and readbufferfactor settings are you using in advancedsettings.xml?

I also have another question. I've been noticing the occasional stutter or what appears to be a frame skipping from time to time. If I remember correctly I read elsewhere that the C2 is doing true 23.976 fps playback, even though the TV/projector may report 24.00. If that is the case, could what I'm seeing be somehow similar to or related to the issue described here in the link below?

https://discourse.osmc.tv/t/mmal-skipped...s/14455/15

Fix for skips every 10 sec or so was fixed by moving hotplugging away from Render thread. You can pick popcornmix's fix which I rebased for Jarvis here: https://raw.githubusercontent.com/osmc/o...read.patch.

[MidnightWatcher]

Thanks Sam (fyi the link includes the period at the end making it invalid).

wrxtasy, is this something you could incorporate into the next build easily to test? Or is there a lirc module(s) being loaded that I can disable manually? I control LE using an app on my cellphone only, not with a standard remote control. Would like to test this out to see if it solves the judder/skipped frame issue.

[Sam.Nazarko]

The lag is caused by eventlircd. Not sure if LE lets you stop systemd services, but if you kill eventlircd, you should notice the stutter go away. If it doesn't, it's a different problem.