Kodi Community Forum
OpenELEC Testbuilds for RaspberryPi Part 2 - Printable Version

Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166)
---- Thread: OpenELEC Testbuilds for RaspberryPi Part 2 (/showthread.php?tid=184866)



RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Trixster - 2014-03-31

After a bit more testing I agree that 0.14 is very marginally better than 0.8, for both sd and 720p content.

Is there a way to make this the default kernel for these resolution videos, but leave 1080p untouched? It's a pain to have to go into the OSD for each sd/720p video.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-03-31

(2014-03-31, 15:15)rbej Wrote: When i seek some movies (mkv) to beginning i dont have audio and picture freeze after few seconds.

A debug xbmc.log showing the issue may help.
A sample file that suffers from the issue would be even more useful.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-03-31

(2014-03-31, 15:33)Trixster Wrote: After a bit more testing I agree that 0.14 is very marginally better than 0.8, for both sd and 720p content.

Is there a way to make this the default kernel for these resolution videos, but leave 1080p untouched? It's a pain to have to go into the OSD for each sd/720p video.

Just change it and enabled the "set as default for all videos".
For 1080p video on a 1080p display, the scaling kernel won't be used, so no need to worry.

It is likely there will be a change to the default scaling kernel soon as 0.14 does seem preferred (it was my favourite too).
Ideally we should stretch the shape of the kernel with the scaling ratio.

These were the kernels:

0.00 Sinc over the range +-3*PI with Hamming window applied,
0.02 Sinc with Hamming window applied,
0.04 Sinc over the range +-2.5*PI with Hamming window applied,
0.06 Sinc,
0.08 Sinc with Blackmann window applied,
0.10 Sinc with no side lobes,
0.12 Sinc with half the first side lobe
0.14 Mitchell Netravali (with B=1/3,C=1/3)
0.16 nearest_neighbour,

Here's another suggested by the image scaling guy (you can just enter that while video is playing):
Code:
vcgencmd scaling_kernel   0  -4  -8 -14 -18 -19 -16  -8   9  39  77 122 166 206 237 255 255 237 206 166 122  77  39   9  -8 -16 -19 -18 -14  -8  -4   0
It's a cubic with A=-0.5.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-03-31

(2014-03-30, 09:29)MrNice Wrote: Every time I open System>system>video output, I get the message "Save resolution. Would you like to keep this change"

Any change with latest build?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - ajp2k14 - 2014-03-31

@popcornmix

Is something like lanczos/spline/catmull-rom possible or are they completely different algorithms?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - abudabi - 2014-03-31

(2014-03-31, 10:28)Stilt Wrote: Ok, Did a complete new install:
1) Installed Gotham OpenELEC Beta - Raspberry Pi ARM Version:3.95.3
2) Samba copied Gotham build: #0330 .tar to Upgrade
3) Rebooted

Hi guys

Is this the suggested way to install from scratch?

Thanks


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-03-31

(2014-03-31, 16:40)ajp2k14 Wrote: @popcornmix

Is something like lanczos/spline/catmull-rom possible or are they completely different algorithms?

No, should be possible with right coefficients. This is lanczos with A=2.
Code:
vcgencmd scaling_kernel   0  -2  -7 -14 -19 -23 -20  -9  12  41  79 123 167 207 237 253 253 237 207 167 123  79  41  12  -9 -20 -23 -19 -14  -7  -2   0



RE: OpenELEC Testbuilds for RaspberryPi Part 2 - ajp2k14 - 2014-03-31

(2014-03-31, 16:50)popcornmix Wrote:
(2014-03-31, 16:40)ajp2k14 Wrote: @popcornmix

Is something like lanczos/spline/catmull-rom possible or are they completely different algorithms?

No, should be possible with right coefficients. This is lanczos with A=2.
Code:
vcgencmd scaling_kernel   0  -2  -7 -14 -19 -23 -20  -9  12  41  79 123 167 207 237 253 253 237 207 167 123  79  41  12  -9 -20 -23 -19 -14  -7  -2   0

Nice! I use Lanczos3 in MadVR on my laptop (or Jinc3) and quality is very good...

Might be worth checking out this thread....unfortunately, my own knowledge in this area is very limited but please let me know if there's anything I can do to help...

http://forum.doom9.org/showthread.php?t=146228

Any suggestions where I can find the right numbers to input for different scaling kernels?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Trixster - 2014-03-31

(2014-03-31, 16:21)popcornmix Wrote:
(2014-03-31, 15:33)Trixster Wrote: After a bit more testing I agree that 0.14 is very marginally better than 0.8, for both sd and 720p content.

Is there a way to make this the default kernel for these resolution videos, but leave 1080p untouched? It's a pain to have to go into the OSD for each sd/720p video.

Just change it and enabled the "set as default for all videos".
For 1080p video on a 1080p display, the scaling kernel won't be used, so no need to worry.

It is likely there will be a change to the default scaling kernel soon as 0.14 does seem preferred (it was my favourite too).
Ideally we should stretch the shape of the kernel with the scaling ratio.

Super, thank you!


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-03-31

I'm seeing a problem when playing an MKV with dvdplayer that has both TrueHD and AC3 audio tracks. With either the TrueHD or AC3 audio track, if I start the movie from the beginning there's a long-ish delay (due to ffmpeg complaining about a "Non-increasing DTS") and eventually the movie will play both video and audio. However when starting the same movie from a resume point (eg. "Play from 09:00") there is never any video, only audio (either TrueHD or AC3).

omxplayer will play both video and audio when resuming, or starting from beginning.

Debug log of dvdplayer resuming from about 9 minutes (with default TrueHD audio stream #1) here.

This doesn't seem to be a new problem, I've gone back several weeks worth of builds and the behaviour is the same.

I have a 500MB sample with which to reproduce the "resume from" problem if you need this (dropbox).

Watch (using either omxplayer or dvdplayer) until about 03:00 and stop, then try playing again with dvdplayer this time resuming from 03:00 - it will be very slow to resume but should eventually give you just TrueHD audio and no video. Stop and resume using omxplayer and you'll have both video and TrueHD audio. I can also reproduce this behaviour with the AC3 track (you need to switch audio tracks when starting from beginning).


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - MonsterCross - 2014-03-31

(2014-03-30, 18:02)popcornmix Wrote: Don't try it when video is 1080p and display is 1080p or you won't see anything. It's more interesting when playing SD content on a HD display
It's not magic. The kernels are a compromise between sharpening (producing more detail, but increasing noise) and blurring (hides the noise and the detail).
The best option for SD video may be different to the best option for 720p.
It will make a difference for watching a 1080P movie on a 1080P display - but more for the chroma than the luma. So the effect would be a bit subtle. In this case the chroma is being upsampled 2x in x & y.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-03-31

(2014-03-31, 16:21)popcornmix Wrote: Here's another suggested by the image scaling guy (you can just enter that while video is playing):
Code:
vcgencmd scaling_kernel   0  -4  -8 -14 -18 -19 -16  -8   9  39  77 122 166 206 237 255 255 237 206 166 122  77  39   9  -8 -16 -19 -18 -14  -8  -4   0
It's a cubic with A=-0.5.

I've tried comparing +4 (0.08, Blackmann), +7 (0.14, Mitchell Netravali), cubic with A=-0.5, and lanczos with A=2 and I'm not seeing any significant difference between them - they're all quite similar, all being sharper than the default +0/0.00. Very hard to say which is best. This is while viewing text on SD/xvid material.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Forage - 2014-03-31

Am I the only one who still has the network connection (wired) dropping randomly? It happens on MilouseVH's builds, as well as with OE 4beta3. They still occur, during playback, as well as while not using the RPi.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - MonsterCross - 2014-03-31

(2014-03-31, 16:40)ajp2k14 Wrote: Is something like lanczos/spline/catmull-rom possible or are they completely different algorithms?
I think for catmull-rom you want something like:
Code:
vcgencmd scaling_kernel    0 -4 -8 -14 -18,-19,-16 -8  9 39 77 122 166 206 237 255
255 237 206 166 122  77  39   9  -8 -16 -19 -18 -14  -8  -4   0
But it's probably got too much overshoot. These kernels are operating on the [4:2:0] output of the codecs, which is encoded with gamma. So the effect is exaggerated in linear light on the monitor.
Kernels with nice mathematical or signal-processing properties don't always look best.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - ajp2k14 - 2014-03-31

(2014-03-31, 18:56)MonsterCross Wrote:
(2014-03-31, 16:40)ajp2k14 Wrote: Is something like lanczos/spline/catmull-rom possible or are they completely different algorithms?
I think for catmull-rom you want something like:
Code:
vcgencmd scaling_kernel    0 -4 -8 -14 -18,-19,-16 -8  9 39 77 122 166 206 237 255
255 237 206 166 122  77  39   9  -8 -16 -19 -18 -14  -8  -4   0
But it's probably got too much overshoot. These kernels are operating on the [4:2:0] output of the codecs, which is encoded with gamma. So the effect is exaggerated in linear light on the monitor.
Kernels with nice mathematical or signal-processing properties don't always look best.

Interesting, thanks! I'm just trying to translate my experiences with MadVR scaling to the Pi. Catmull-rom is probably better for downscaling though, in fact I think it's the recommended method in MadVR for downscaling (in linear light).

It would be interesting to see more Lanczos variants, lanczos3 is a good compromise between sharpness and ringing I think. MadVR probably has more tricks when scaling and converting so it's probably not scaling gamma encoded video... ?

(2014-03-31, 18:44)MilhouseVH Wrote:
(2014-03-31, 16:21)popcornmix Wrote: Here's another suggested by the image scaling guy (you can just enter that while video is playing):
Code:
vcgencmd scaling_kernel   0  -4  -8 -14 -18 -19 -16  -8   9  39  77 122 166 206 237 255 255 237 206 166 122  77  39   9  -8 -16 -19 -18 -14  -8  -4   0
It's a cubic with A=-0.5.

I've tried comparing +4 (0.08, Blackmann), +7 (0.14, Mitchell Netravali), cubic with A=-0.5, and lanczos with A=2 and I'm not seeing any significant difference between them - they're all quite similar, all being sharper than the default +0/0.00. Very hard to say which is best. This is while viewing text on SD/xvid material.

I think you have to sit very close to the TV to notice the differences between some of them and concentrate on text, diagonals and textures? It would be interesting to try Lanczos with A=3 and perhaps even A=4 and perhaps Jinc with A=3 too if possible. Those ones produce very good results in video players on the PC at least. I read that Intels HD Graphics (at least 4000+) uses something like Lanczos3...

I mostly watch 720p and up though so not sure which one is best for SD...


This forum uses Lukasz Tkacz MyBB addons.