Should solve your issues. Mainline OpenELEC didn't yet update lirc package and I refuse to do something dramatic so I can merge easily. But I can add these patches to project folder.
About rewrite - We will wait on Kodi 17 at least few months if I'm not mistaken. From what I gathered, renderer will receive it's own task, they want to remove (almost?) all singleton objects, etc. If we do this now, some refactoring will definetly be required, but most of it would be still useful.
If you tell me what exactly to do. I don't have any I2S board here, so I can't test it. script.bin also needs to be changed because settings for I2S clash with others. You can do this in your script.bin but I won't enable it by default because it is rarely used. So, if there is any kernel driver missing, I will enable it, just tell me which.
jernej replied at 2016-2-15 05:39
I updated the patch. Can you please pull latest changes and test again? As I said in my previous p ...
Tomorrow i will build an updated image for my OPiPC and will try to test if channels switching works
Thank you for you work jernej. It's really appreciated.
I know that code for H3 need a bit of refactoring but do you think it will difficult to add VSync for videos?
(Maybe there is a way with a quick and dirty hack for now?)
I think this is one of the last important thing we miss.
Probably the most affected use case is mainly with interlaced TV.
You can also test now automatic refresh rate switching (or whatever is this called). Resolution switching is also enabled, but broken due to buggy fbdev driver. All valid combinations (resolution/refresh rate) are derived from HDMI EDID values and driver capabilities.
I know a few things which would be nice to have:
- screenshots
- proper video renderer (ffmpeg decoded videos would benefit with fast rendering)
- vsync
- analog TV out
- open source HW decoder
Probably vsync is actually the easiest, but I'm not sure how fast it could be implemented. I'm not a fan of hacks, I hate them very much. But because whole H3 support needs a rewrite anyway, I think I can go along with it. I will think a bit how to implement.
Great Thank you.
I'm building right now and test when finished.
Yes. I know there are other problems but i would rate vsync as one of the most important because it directly affects video quality.
And talking about a media player, video quality is probably the first thing
I will try with my USB tuner but i'm not sure if it is supported.
In case i need to buy a new USB tuner, can anyone advice a cheap USB tuner known to work on OPi?
I'm also building an image (for the OrangePi PC), will upload to Mega. It's almost done.
Will also test a cheap USB-tuner which I bought for like 7$ on Aliexpress (rtl8192eu based) Though will not be able to actually test if it fully works as I don't have sufficient DVB-T signal.
I actually doubt if VSync is a good thing though. It does require quite a bit of extra GPU power and can cause artifacts. I've never experienced tearing so don't see the real need. Just look at (a lot more powerful) GPU's in PC's: you'll also see a significant frame drop by activating VSync.
Dima replied at 2016-2-16 18:19
I'm also building an image (for the OrangePi PC), will upload to Mega. It's almost done.
Will also t ...
This is interesting Please let us know if that USB tuner works.It can be a good option for a cheap USB tuner.
About vsync, i need to say that here we are talking about vsync for video.
I think we don't need vsync for the gui too as you do.
(and i don't even know if it works now, but i can't see tearing so it isn't needed)
But vsync for video is a different thing.
We need to be sure that every frame of the video is displayed "in sync" to prevent half rendered frame.
This is mostly evident with interlaced videos as of now.
[Copy link]
Show IP Card
Radar Card
Published in 2016-2-16 01:46:56
Anonimous Post
Published in 2016-2-16 06:27:08
