(2017-04-06, 16:54)wrxtasy Wrote: [...]
@danjames92, Frame Packed 3D on AML S9xx depends on developers getting interested and actually having 3D display equiptment to test on. Quite a few of us don't even have 3D TV's.
[...]
Had some thoughts about this the last couple of days, so sorry to pick that up again, but feel to mention it here
There are some points worth thinking about this Frame Packing thing, if we assume that this Frame Packing commit would work:
- Frame Packing could be used as a new "refresh rate mode". So that means that if a 3D movie starts, the auto-refresh-rate switch routine in Kodi could send e.g. 1080fp24 as a movie refresh rate instead of the usual 1080p24. And the TV would be forced to turn on 3D mode automatically. Hence the "beloved" 3D TV-autoswitch topic alltogether with "missing 3D-Support on C2" would end with this.
- Working Frame Packed mode would also open the way for full-rez MVC instead of half-rez like it was on Jarvis before. Hence this would be more interesting and especially be more worth investing time and effort for programmers who want to see MVC on non-Raspberry Hardware.
- But in any way: Frame Packed could be the basis to get away from specific kodi patches on AML hardware to be more compliant with Raspberry or general code.
I'm quite sure that the raspberry also triggers the 3D-TV-Autoswitch simply by signalling a refresh-rate-switch into FramePacking "Resolution" to the TV:
Code:
OpenELEC:~ # tvservice -s
state 0x12000a [HDMI CEA (32) 3D FP RGB lim 16:9], 1920x1080 @ 23.98Hz, progressive
This is from my raspberry by playing a simple H-SBS (non MVC) 3D file. Although it is not MVC, it simply sends FramePacked ("
3D FP") Resolution/Refresh-rate-mode to the TV and the TV switches into proper 3D.
So from a non-programmer POV I imagine that it could be possible that the Raspberry 3D autoswitch code may be then compatible (or used as a draft) with odroid refresh-rate switch code, as raspberries 3D trigger is probably a simple Refresh-rate-switch to a FramePacking refresh-rate. So same principle could be used on Odroid to solve all the 3D-support requests.