| *** ubuntu is now known as Guest73149 | 01:37 | |
| *** ChanServ sets mode: +v T4 | 05:05 | |
| T4 | <adampigg> abranson, another day for brainstorming ;) | 06:40 |
|---|---|---|
| abranson | adampigg: r0kk3rz was right, native video renderers don't touch the video at all, they just hand it to the display which already knows the format and displays it straight. | 06:42 |
| abranson | the suggestion was that you change the caps so it'll be able to negotiate 64z32 with downstream | 06:44 |
| T4 | <adampigg> abranson, point me to where the caps can be changed then....will that/also get around the assert i hit? | 08:31 |
| ghosalmartin | guhl, ive setup an obs project here for chiron https://build.merproject.org/project/show/home:mgrover:devel:hw:xiaomi:chiron, lemme know what your obs username is and i can add you permissions for it. makes life much easier than building locally imo | 09:09 |
| abranson | adampigg: i'd grep the vdec file for 'i420' and go from there. there shouldn't be any i420 left in your test | 09:12 |
| T4 | unomind was added by: unomind | 14:26 |
| guhl | ghosalmartin: I think the experiment with the raspberry3 is leading nowhere | 16:13 |
| guhl | I do have a self built LOS 15.1 running on the rp3 and have serial console access | 16:13 |
| guhl | but it also boots perfectly when i enable the config_vt | 16:14 |
| ghosalmartin | guhl :'( | 16:16 |
| taixzo | Is the barometer on an Xperia X accessible to sfos? | 16:47 |
| guhl | porting for a device with serial console access would be a lot easier ;-) | 16:48 |
| mal | taixzo: I had it working but forgot how I did it, I was the one who added support for it to middleware, I'll test if I can make it work again, just found the modified Messwerk app for testing it | 16:53 |
| T4 | alberone was added by: alberone | 16:53 |
| mal | taixzo: yes, seems to still work after modifying two configuration files | 17:10 |
| piggz | abranson: around? | 17:16 |
| piggz | mal: in https://developer.gnome.org/gst-plugins-libs/stable/gst-plugins-base-libs-gstvideo.html#GST-VIDEO-CAPS-MAKE:CAPS ... what would format sring be for nv12 32-64 tile zigzag :D | 17:17 |
| mal | piggz: NV12_64Z32 https://github.com/GStreamer/gst-plugins-base/blob/1c8bf44dea2af3b8bbed3e230479fe5405a5bad6/gst-libs/gst/video/video-format.h#L93 | 17:19 |
| mal | https://github.com/GStreamer/gst-plugins-base/blob/1c8bf44dea2af3b8bbed3e230479fe5405a5bad6/gst-libs/gst/video/video-format.c#L5352 | 17:20 |
| taixzo | mal: which files? | 17:21 |
| mal | taixzo: add "QPressureSensor=sensorfw.pressuresensor" to /etc/xdg/QtProject/Sensors.conf and "pressureadaptor = hybrispressureadaptor" to [plugins] section of /etc/sensorfw/primaryuse.conf and finally install messwerk from here https://build.merproject.org/project/show/home:mal:apps | 17:24 |
| mal | it seems my messwerk modification have a bug, the graph is not updating | 17:27 |
| mal | *has | 17:28 |
| *** ChanServ sets mode: +v T4 | 17:39 | |
| mal | taixzo: I fixed messwerk bug so now it should plot the value correctly | 17:41 |
| taixzo | mal: do I have to reboot after editing those conf files? Messwerk is showing pressure at 0.000 Pa. | 18:39 |
| r0kk3rz | sensorfwd might want a kick | 18:43 |
| taixzo | yep, that did it! | 18:44 |
| * vknecht symbolically links to « under pressure » | 18:52 | |
| piggz | mal: so, ive set the output caps to NV12....., and tagged the input frames with the same format..... | 18:53 |
| piggz | in the routing that does the conversion, im just not doing anything | 18:53 |
| piggz | im not getting an assert anymore on the formats being incorrect | 18:54 |
| piggz | but, i have a mainly green scrren with some purpue blocks, which i guess are tiles | 18:54 |
| vknecht | piggz, maybe this offline counsel can help, about LOG_NDEBUG : http://merproject.org/logs/%23sailfishos-porters/%23sailfishos-porters.2018-06-18.log.html#t2018-06-18T20:56:44 | 19:00 |
| piggz | vknecht: sod it ... i'll work on amazfish instead! | 19:35 |
| abranson | piggz: hi! | 19:51 |
| piggz | lo abranson | 19:52 |
| piggz | wanna help out? ;) | 19:52 |
| abranson | if I can. doesn't sound like you had much luck though | 19:52 |
| piggz | well, i think i got the output configured.... | 19:53 |
| piggz | 0:00:17.028174979 16821 0xe92bc7b0 DEBUG droidvdec gstdroidvdec.c:957:gst_droidvdec_set_format:<droidvdec0> peer caps video/x-raw, format=(string)NV12_64Z32, width=(int)[ 1, 2147483647 ], height=(int)[ 1, 2147483647 ], framerate=(fraction)[ 0/1, 2147483647/1 ] | 19:53 |
| piggz | the width/height are a bit odd | 19:53 |
| piggz | this line later looks better | 19:54 |
| piggz | 0:00:17.404658103 16821 0xe92162f0 DEBUG droidvdec gstdroidvdec.c:768:gst_droidvdec_configure_state:<droidvdec0> output caps video/x-raw, format=(string)NV12_64Z32, width=(int)640, height=(int)360, interlace-mode=(string)progressive, multiview-mode=(string)mono, multiview-flags=(GstVideoMultiviewFlagsSet)0:ffffffff:/right-view-first/left-flipped/left-flopped/right-flipped/right-flopped/half-aspect/mixed-mono, pixel-aspect-ratio=( | 19:54 |
| piggz | fraction)1/1, chroma-site=(string)jpeg, colorimetry=(string)bt601, framerate=(fraction)24000/1001 | 19:54 |
| abranson | that's the caps. just possible sizes. defaults 1-maxint | 19:54 |
| abranson | that looks really good | 19:54 |
| abranson | and did you say there's a colour conv element appearing in the pipeline too? converting it to i420? | 19:55 |
| abranson | is it still claiming that it's colour format 21 though? | 19:55 |
| piggz | the next lines are..... | 19:56 |
| piggz | 0:00:17.405403849 16821 0xe92162f0 DEBUG droidvdec gstdroidvdec.c:269:gst_droidvdec_convert_buffer:<droidvdec0> convert buffer | 19:56 |
| piggz | 0:00:17.405446038 16821 0xe92162f0 INFO droidvdec gstdroidvdec.c:273:gst_droidvdec_convert_buffer:<droidvdec0> using codec supplied width 640 | 19:56 |
| piggz | 0:00:17.405554842 16821 0xe92162f0 DEBUG droidvdec gstdroidvdec.c:366:gst_droidvdec_convert_buffer:<droidvdec0> Converting from crazy qcom format | 19:56 |
| piggz | 0:00:17.405587812 16821 0xe92162f0 DEBUG droidvdec gstdroidvdec.c:611:gst_droidvdec_finish_frame:<droidvdec0> finish frame | 19:56 |
| abranson | because it looks like QOMX_COLOR_FormatYUV420PackedSemiPlanar64x32Tile2m8ka is 0x7FA30C00 | 19:56 |
| abranson | 0x7FA30C03 sorry | 19:56 |
| piggz | and the comment comes from..... | 19:56 |
| abranson | one less than the xperia 0x7FA30C04 - QOMX_COLOR_FORMATYUV420PackedSemiPlanar32m | 19:56 |
| piggz | 0:00:17.405403849 16821 0xe92162f0 DEBUG droidvdec gstdroidvdec.c:269:gst_droidvdec_convert_buffer:<droidvdec0> convert buffer | 19:56 |
| piggz | 0:00:17.405446038 16821 0xe92162f0 INFO droidvdec gstdroidvdec.c:273:gst_droidvdec_convert_buffer:<droidvdec0> using codec supplied width 640 | 19:56 |
| piggz | 0:00:17.405554842 16821 0xe92162f0 DEBUG droidvdec gstdroidvdec.c:366:gst_droidvdec_convert_buffer:<droidvdec0> Converting from crazy qcom format | 19:56 |
| piggz | 0:00:17.405587812 16821 0xe92162f0 DEBUG droidvdec gstdroidvdec.c:611:gst_droidvdec_finish_frame:<droidvdec0> finish frame | 19:56 |
| piggz | sorry... | 19:57 |
| piggz | } else if (dec->hal_format == 21) { | 19:57 |
| piggz | GST_DEBUG_OBJECT (dec, "Converting from crazy qcom format"); | 19:57 |
| piggz | //do nothing | 19:57 |
| piggz | //qcom_convert(in->data, map_info.data + info->offset[0], map_info.data + info->offset[1], map_info.data + info->offset[2], | 19:57 |
| piggz | // width, height, | 19:57 |
| r0kk3rz | 'Converting from crazy qcom format' XD | 19:57 |
| piggz | // info->stride[0], info->stride[1], info->stride[2] ); | 19:57 |
| r0kk3rz | nobody likes the zigzags | 19:57 |
| abranson | are you copying the buffer like in the SemiPlanar32m block? | 19:57 |
| abranson | sorry the i420 block | 19:57 |
| piggz | no, i do nothing | 19:57 |
| piggz | i wasnt sure what the cropping would do... | 19:58 |
| piggz | ah shit, is my output buffer empty | 19:58 |
| abranson | yeah | 19:58 |
| piggz | i mis-read the above code,... | 19:59 |
| piggz | will the copy even work with zig zags? ... lets see | 19:59 |
| piggz | for some reason, i though the copy worked on the data in-place | 20:00 |
| abranson | well for i420 we manually apply the crop during the copy | 20:01 |
| abranson | the frames come out of the codec bigger than they should, with cropping instructions alongside | 20:01 |
| abranson | but i'm not sure if droidvdec is a bin, in which case we can add a cropping element after it and not worry | 20:02 |
| r0kk3rz | sounds worth trying | 20:03 |
| piggz | abranson: how should i copy the buffer? i dont think I can copy yuv planes can i like i420? | 20:17 |
| piggz | (it crashes when i try) | 20:17 |
| abranson | that is the tricky bit, if it weren't for the cropping we could just copy the buffer in one go | 20:19 |
| piggz | abranson: if we ignore cropping for now.... | 20:20 |
| piggz | memcopy, width* height * 3 ? | 20:20 |
| abranson | piggz: *3/2 maybe? | 20:22 |
| piggz | abranson: well, it shows 'something' | 20:28 |
| piggz | there is movement in there | 20:28 |
| piggz | mixed up in all the green | 20:28 |
| abranson | all diagonally shifted? | 20:28 |
| abranson | i do think the 64z32 might be a red herring though - and this one is 21: http://androidxref.com/8.1.0_r33/xref/hardware/qcom/media/msm8974/mm-core/inc/OMX_IVCommon.h#110 | 20:33 |
| piggz | abranson: yeah, the 21 came from a differnt code path than the 64x32... | 20:48 |
| piggz | (was afk...) | 20:48 |
| piggz | abranson: https://imgur.com/delete/KQLqpSKbSQchHfK | 20:52 |
| piggz | abranson: format 0x7FA30C03 was the output of convert->getDecoderOuputFormat() in droidmedia | 20:53 |
| piggz | how that gets to 21 i dont knwo | 20:53 |
| r0kk3rz | i think your 80s CRT needs calibrating | 20:57 |
| r0kk3rz | v-hold maybe | 20:58 |
| Mister_Magister | r0kk3rz: xd | 21:08 |
| abranson | piggz: so that was what the blob was producing? | 21:27 |
| piggz | abranson: ah, was it.....the blob is disabled for now.... | 21:29 |
| abranson | funny format for an i420color converter to be making | 21:29 |
| abranson | but that would explain why the output of the blob wasn't right in your browser | 21:29 |
| abranson | so one solution might be to reinstate the blob, but keep the retagging. with the blob i don't think you need to copy the buffers. | 21:30 |
| piggz | k i was thinking osmething similar .. | 21:33 |
| piggz | abranson: tag the output format, or the frames, or both? | 21:33 |
| piggz | with the blob, it will take a dffernt path to the buffer copy anyway wont it | 21:34 |
| piggz | abranson: with the blob used, it crashes | 21:38 |
| piggz | i think it crashes in if (droid_media_convert_to_i420 (dec->convert, in, data) != true) { | 21:43 |
| piggz | abranson: im done for the night ... im now getting the assert that the 2 formats are not the same | 21:49 |
| piggz | 0:00:08.419245922 11871 0xe9215750 DEBUG droidadec gstdroidadec.c:499:gst_droidadec_handle_frame:<droidadec0> handle frame | 21:49 |
| piggz | 0:00:08.419334567 11871 0xe9215750 DEBUG droidadec gstdroidadec.c:549:gst_droidadec_handle_frame:<droidadec0> decoding data of size 270 (270) | 21:49 |
| piggz | ** (sailfish-browser:11871): CRITICAL **: gst_video_frame_map_id: assertion 'info->finfo->format == meta->format' failed | 21:49 |
| piggz | 0:00:08.422214611 11871 0xe926b200 DEBUG droidmemory gstdroidmediabuffer.c:204:gst_droid_media_buffer_allocator_free:<droidmediabufferallocator0> free 0xd08da650 | 21:49 |
| piggz | 0:00:08.423072004 11871 0xe5aec6c0 DEBUG droidmemory gstdroidmediabuffer.c:136:gst_droid_media_buffer_allocator_alloc:<droidmediabufferallocator0> alloc 0xd08da6d0 | 21:49 |
| piggz | 0:00:08.423179712 11871 0xe5aec6c0 DEBUG droidvdec gstdroidvdec.c:612:gst_droidvdec_finish_frame:<droidvdec0> finish frame | 21:49 |
| piggz | gnight :) /away zzzZZZ | 21:49 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!