| T4 | <RainSlide> 😶 | 00:27 |
|---|---|---|
| T4 | Varun (MISSING @USERNAME! telegram.org/faq#usernames-and-t-me) was added by: Varun (MISSING @USERNAME! telegram.org/faq#usernames-and-t-me) | 02:34 |
| *** ChanServ sets mode: +v T4 | 05:45 | |
| T4 | <adampigg> Abranson, if you could knock me.up a function that does i420 semiplanar > planar conversion thatd be great ;) | 07:02 |
| abranson | adampigg: the second one for the sony does packed semiplanar doesn't it? shouldn't be too different. but it'd be better to fix the blob - these manual conversions are slow | 07:04 |
| piggz | abranson: would that mean looking for a new blob from the vendor? | 07:21 |
| piggz | abranson: btw, that lib is gone in the los-15 branch ... only appears in the 14.1 branch | 07:23 |
| piggz | https://github.com/TheScarastic/proprietary_vendor_xiaomi/tree/cm-14.1/mido/proprietary/vendor/lib | 07:23 |
| abranson | piggz: i don't think a new blob would be possible. but maybe we need to use it differently in later devices | 07:24 |
| piggz | k | 07:25 |
| T4 | <meierrom> @adampigg [Abranson, if you could knock me.up a function …], Is there no way to find the source of the problem? To start coding new functions sounds like worst case scenario.😉 | 07:25 |
| abranson | meierrom: the source of the problem is that the android apis we're using are not designed to do what we're doing with them :) | 07:31 |
| piggz | abranson: i did a quick test, the 2 versions in the 14.1 branch fail the same way | 07:31 |
| abranson | hmm, so they work but the colours are wrong? | 07:31 |
| T4 | <meierrom> @abranson [meierrom: the source of the problem is that th …], I thought this problem is not general occuring on 2 phones only so far. | 07:37 |
| r0kk3rz | @meierrom: 3 phones that we happen to be porting to | 07:38 |
| r0kk3rz | thats more than a simple coincidence | 07:38 |
| r0kk3rz | but yes, a lot of this os porting stuff is hacks upon hack upon hacks :D | 07:39 |
| abranson | meierrom: these codecs don't use standard colour formats. they use device specific weird HAL formats that don't map onto standard gstreamer formats such as i420. that's fine when we're just displaying the format on a native surface, such as when you use the gallery app, but the browser doesn't support that so we have to present a colour format that it supports, and it doesn't do these. | 07:40 |
| abranson | usually you get a blob to convert these opaque formats to i420. you don't see what the internal format is, you just get i420 buffers out that the browser is happy with | 07:41 |
| abranson | but recently we've had devices that either don't have that blob for foss reasons, or the blob doesn't work | 07:42 |
| abranson | so we've had to add extra handling to convert these buffers | 07:42 |
| T4 | <meierrom> @abranson [so we've had to add extra handling to convert …], Thanks for explaining! 👍 | 07:48 |
| T4 | <meierrom> @r0kk3rz [thats more than a simple coincidence], OK. You have a point there. | 07:49 |
| r0kk3rz | @meierrom: also, this is all in our droidmedia/gst-droid framework, so its not that surprising that we need to write code for it | 07:51 |
| abranson | it could be that there's another colour conversion utility in android that we should be using, provided that it'll give us buffers that the browser can use | 07:53 |
| abranson | but I think if these blobs are present then they should work, so we must be using them incorrectly somehow | 07:53 |
| T4 | <adampigg> abranson: I did find a google patent on semi > planar conversion | 08:03 |
| T4 | <meierrom> @r0kk3rz [@meierrom: also, this is all in our droidmedia …], I'm a bit worried these extra codes will lead to a poor experience on slower devices. | 08:20 |
| Mister_Magister | mal: ye seems like update went smooth af | 08:26 |
| r0kk3rz | @meierrom: don't be. sfos works pretty well on slow devices | 08:28 |
| T4 | <meierrom> @r0kk3rz [@meierrom: don't be. sfos works pretty well on …], Generally that may be true but this issue is related to video displayed inside a browser. That's very tough. | 08:45 |
| r0kk3rz | if you've got a better way, im sure the jolla guys would love it hear it :P | 08:46 |
| T4 | <meierrom> @r0kk3rz [if you've got a better way, im sure the jolla …], I wish I could but that's way above me :) | 08:49 |
| r0kk3rz | @meierrom: also, can you stop using the reply function in this channel? | 08:52 |
| r0kk3rz | its annoying to read in the IRC channel | 08:52 |
| T4 | <meierrom> Oh sorry! I wasn't aware. | 08:57 |
| elros1 | anybody tired this patch with omap: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1234743. I am trying to adapt it for sunxi but udev events are still generated | 10:23 |
| merbot | Launchpad bug 1234743 in systemd "omapfb module floods system with udev events on samsung galaxy nexus" [High,Fix released] | 10:23 |
| mal | piggz: it would be interesting to know how 15.1 base works for you, is that lineage-15.1 as good as 14.1 i.e. all features work? | 10:25 |
| T4 | <abhishek_0> maybe i can try that too, that lib is also removed for me in 15.1 | 10:26 |
| T4 | <abhishek_0> are all the 15.1 pr for hybris merged ? | 10:30 |
| mal | no, libhybris is not, neither are the gps changes, not sure if something else is missing | 10:44 |
| piggz | mal: never used the los-15 .... but afaik, its good, i think many use it ... there is also a kerenl with treble support | 11:09 |
| piggz | mal: cant face the thought of rebasing everything....but, maybe its worth doing.... | 11:24 |
| piggz | is a particular release/date of 15.1 recomended? | 11:24 |
| mal | piggz: I have been planning on rebasing 15.1 | 11:25 |
| T4 | <adampigg> Mal, well, if you want me to work on it just say | 11:30 |
| mal | I think ghosalmartin did it already at least partially | 11:31 |
| ghosalmartin | mal: its done, wanna attempt to merge it in? :P | 11:31 |
| mal | ghosalmartin: have you used it? | 11:32 |
| mal | krnlyng: ^ | 11:32 |
| ghosalmartin | mal, well no, i cant get any devices to work | 11:32 |
| ghosalmartin | but thats due to other reasons | 11:32 |
| mal | but it builds at least? | 11:32 |
| ghosalmartin | oh yeah | 11:32 |
| ghosalmartin | i guess an example pr is here https://github.com/mer-hybris/android_system_core/pull/39 | 11:33 |
| ghosalmartin | or here https://github.com/mer-hybris/android_build/pull/10 | 11:34 |
| ghosalmartin | mal: yeah they defo build, i checked my manifest and they point to my org and not mer-hybris | 11:51 |
| T4 | <abhishek_0> i syncing trees for 15.1 tho | 11:55 |
| T4 | <abhishek_0> *i am | 11:58 |
| piggz | mal: abranson: was just looking at droidmedia, and I noticed I have a hack in mine to load AudioPolicyService ... does anyone else do that? | 13:45 |
| mal | piggz: I do | 13:48 |
| mal | kimmoli also | 13:48 |
| mal | I was planning on testing if it's still needed | 13:48 |
| T4 | <BirdZhang> me too | 13:48 |
| krnlyng | piggz, https://github.com/sailfishos/droidmedia/pull/11 | 13:49 |
| kimmoli | its my hak | 13:50 |
| kimmoli | as the usual "comment shutter sounds" is not helping | 13:53 |
| mal | krnlyng: you mean with audioflingerglue we don't need to comment out the shutter sound loading in frameworks/av? | 13:53 |
| T4 | <abhishek_0> mal what are the gps changes ? i mean what repository ? | 14:11 |
| T4 | <abhishek_0> for (hybris-15.1) | 14:12 |
| piggz | abranson: mall: would libI420colorconverter::convertDecoderOutputToI420 expect data in a particular format, and perhaps we are not supplying that format, if we have format 21? | 14:12 |
| abranson | piggz: that blob is usually expecting the native output format of the codec iirc | 14:13 |
| abranson | so it should be implemented for that particular device | 14:14 |
| piggz | i found https://github.com/SlimRoms/hardware_ti_omap4/blob/6b5ac0bc00ad195d1bef25fb428e166ead6e572b/libI420colorconvert/ColorConvert.cpp#L25 | 14:14 |
| mal | @abhishek_0 you haven't learned yet what provides gps support? https://github.com/mer-hybris/geoclue-providers-hybris that is needed if device is using new gnss interface | 14:14 |
| piggz | so, i dont see how implementing it in software in gst-droid would be any slower :) | 14:14 |
| mal | the PR in that repo | 14:14 |
| krnlyng | mal, i think so | 14:20 |
| mal | krnlyng: hmm, I'll need to test that then | 14:21 |
| krnlyng | mal, i thought about it hard back then at least | 14:21 |
| abranson | piggz: yeah, I don't think the device specific implementations are closed source because they use special fast code. most probably just because of the closed nature of the source colour formats | 14:21 |
| T4 | gischpelino was added by: gischpelino | 14:26 |
| T4 | <adampigg> Abranson, difficult to see how the interface could be misused.... | 14:28 |
| abranson | adampigg: it's has some querying capability to see what format it's expecting | 14:29 |
| T4 | <adampigg> I might just try and do it in sw....cant be too difficult to move bits around in an array correctly </famouslastwords> | 14:30 |
| T4 | <adampigg> Abranson, yeah, i saw that...ill see what my lib returns | 14:31 |
| r0kk3rz | @adampigg: twiddle the bits until it looks right ;) | 14:33 |
| piggz | abranson ... i added a log function that outputs this: | 15:38 |
| piggz | ALOGE("PGZ decoder output format is %d", convert->getDecoderOutputFormat()); | 15:38 |
| piggz | result is 2141391875 | 15:38 |
| piggz | which is 0x7FA30C03 | 15:38 |
| piggz | which is in https://android.googlesource.com/platform/frameworks/native/+/lollipop-release/include/media/openmax/OMX_IVCommon.h | 15:39 |
| piggz | and is OMX_QCOM_COLOR_FormatYUV420PackedSemiPlanar64x32Tile2m8ka | 15:39 |
| piggz | some stuff here https://stackoverflow.com/questions/28620790/converting-specialized-nv12-video-frames-to-rgb | 15:40 |
| piggz | not sure if any of that helps! | 15:41 |
| piggz | http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/omxil/qcom.c | 15:42 |
| T4 | <abhishek_0> lol what https://paste.ubuntu.com/p/QgVSG2k6cd/ | 15:45 |
| T4 | Donieck was added by: Donieck | 15:55 |
| mal | @abhishek_0 what is the problem, it clearly says what you have to do, or did that start to happen unexpectedly? | 16:15 |
| T4 | <abhishek_0> Actually this is unexpected, I know the solution. Since device trees are all arm it was weird to see that message | 16:19 |
| mal | @abhishek_0 https://github.com/LineageOS/android_device_cyanogen_msm8916-common/blob/lineage-15.1/BoardConfigCommon.mk#L28 | 16:22 |
| mal | it seems lineage-15.1 is different | 16:22 |
| piggz | abranson: some more info on that format https://stackoverflow.com/questions/10059738/qomx-color-formatyuv420packedsemiplanar64x32tile2m8ka-color-format | 17:01 |
| piggz | includes a conversion routine | 17:02 |
| mal | piggz: wow, that's a huge function | 17:06 |
| piggz | mal: i know! | 17:07 |
| piggz | it must be a friggin complex format | 17:07 |
| piggz | i probably wasnt gonna work that out :D | 17:07 |
| piggz | mal: looks like it outputs to 3 seperate buffers, gst-droid expects 1... | 17:10 |
| r0kk3rz | dude needs to learn what a function is | 17:10 |
| r0kk3rz | its probably converting to a different format than the one you need | 17:14 |
| T4 | <abhishek_0> mal seems like build_packages.sh script is not smart | 17:17 |
| piggz | it converts to regulat yuv420planar, which i think cab be used | 17:17 |
| mal | @abhishek_0 that's one of the reasons why the PR is not merged | 17:17 |
| T4 | <abhishek_0> it should have taken this https://github.com/LineageOS/android_device_wingtech_wt88047/blob/84e64fb9843f21c857be005c31ca27b335d941b7/BoardConfig.mk#L18 | 17:37 |
| *** ChanServ sets mode: +v T4 | 17:39 | |
| mal | @abhishek_0 it uses grep, it doesn't check for that other value | 17:44 |
| T4 | <abhishek_0> or we can just tell it not look at common trees at all , they contain code for all other devices too | 17:47 |
| T4 | <abhishek_0> okay nvm ,, not a good solution | 17:48 |
| mal | that is the reason why it has the option for override | 17:48 |
| T4 | <abhishek_0> didnt knew about that tho | 18:25 |
| T4 | <abhishek_0> here https://paste.ubuntu.com/p/gKV54mBq9q/ libhybris fails to build | 18:25 |
| mal | as mentioned before here, add back the removed nfc lines to spec | 18:28 |
| T4 | <abhishek_0> not sure which nfc line you are mentioning here , | 18:29 |
| T4 | <abhishek_0> havent removed anything | 18:29 |
| mal | the android8-initial branch has some stuff removed from spec compared to master branch | 18:33 |
| T4 | <abhishek_0> let me check | 18:36 |
| T4 | <abhishek_0> oh .. nfc stuff was removed tho | 18:36 |
| T4 | <abhishek_0> not sure why it is commented out ? | 18:37 |
| mal | because aosp builds didn't provide the needed headers | 18:39 |
| T4 | <abhishek_0> so de-commenting the commented stuff is the solution ? | 18:50 |
| T4 | <VeryOriginalUsername> Check if it doesn't break anything | 18:54 |
| T4 | <VeryOriginalUsername> Or does it even work 🤔 | 18:54 |
| T4 | <abhishek_0> well device doesnt even have nfc so :shrug: | 18:59 |
| T4 | <VeryOriginalUsername> That's a good point too | 19:02 |
| T4 | <VeryOriginalUsername> (Document) http://149.202.119.142:9090/RcRkjE9SZh.mp4 | 19:03 |
| piggz | mal: well, so far, my attempt to implement that function has given me a purple and green screen | 20:44 |
| r0kk3rz | woo! | 20:46 |
| piggz | r0kk3rz: commenting out the asserts that were failing probably didnt help it render correctly :D | 20:50 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!