00:52 <memeka> is there a way to do full rotation with gscaler?

00:52 <memeka> with gstreamer i can do this: v4l2video21convert extra-controls="convert,rotate=90"

00:53 <memeka> but this will keep the original video size, e.g. 1920x1080 won't rotate to 1080x1980

00:54 <memeka> if i manually add caps (e.g. ! video/x-raw,width=1080,height=1920 ! ) then the performance is very bad (fps drops from 25 to 11)

01:01 <memeka> looks like rotating directly in glimagesink produces better results ....

04:34 <memeka> did anyone managed to use the jpeg decoder for mjpg?

04:34 <memeka> with gstreamer pipeline: gst-launch-1.0 filesrc location=mjpeg.mov ! parsebin ! v4l2jpegdec ! fakesink => I get this error: :gst_v4l2_buffer_pool_start:<v4l2jpegdec0:pool:sink> we received 1 buffer from device '/dev/video31', we want at least 2

04:35 <memeka> is the jpeg decoder limited to 1 buffer ?

04:35 <memeka> snawrocki: did you work on the jpeg decoder in the past? :D

06:24 <memeka> mszyprow: ping

06:24 <mszyprow> memeka: pong

06:24 <memeka> with gstreamer pipeline: gst-launch-1.0 filesrc location=mjpeg.mov ! parsebin ! v4l2jpegdec ! fakesink => I get this error: :gst_v4l2_buffer_pool_start:<v4l2jpegdec0:pool:sink> we received 1 buffer from device '/dev/video31', we want at least 2

06:24 <memeka> 3:05 PM is the jpeg decoder limited to 1 buffer ?

06:25 <mszyprow> memeka: I don't think so, it should work with any number of buffers

06:26 <mszyprow> memeka: maybe gst simply selects minimal number of buffers supported by device

06:26 <mszyprow> memeka: jpeg driver definitely advertises that it is capable of processing a single buffer

06:27 <mszyprow> memeka: aren't there any options for v4l2 gst plugins to specify the number of buffers?

06:28 <memeka> Hm ok I will have another look

06:28 <memeka> Afair, gst asks for how many it wants

06:28 <memeka> Then checks driver

06:29 <memeka> Eg mfc it uses many

06:29 <memeka> So i will check why gst thinks jpegdec is limited to 1 buffer

07:35 <mszyprow> memeka: mfc always requires more than one buffer (exact value depends on the selected codec)

11:36 <memeka> mszyprow: ping

11:36 <mszyprow> memeka: pong

11:36 <memeka> mszyprow: so basically there is a VIDIOC_REQBUFS for 2 buffers, the jpeg decoder returns only 1

11:38 <memeka> .vidioc_reqbufs= v4l2_m2m_ioctl_reqbufs :(

11:41 <mszyprow> memeka: okay, I see why it is requiring only one buffer

11:42 <mszyprow> memeka: see drivers/media/platform/s5p-jpeg/jpeg-core.c s5p_jpeg_queue_setup()

11:42 <memeka> f (ctx->mode == S5P_JPEG_DECODE)

11:42 <memeka> count = 1;

11:42 <memeka> this? :)

11:43 <mszyprow> memeka: destination format depends on the queued compressed data

11:43 <mszyprow> memeka: it may work if you remove that and you will queue jpeg frames of the same format

11:43 <memeka> so it should be a if (ctx->state == HEADER) then count = 1

11:44 <memeka> would that be better?

11:44 <mszyprow> memeka: you may try to remove the check at all

11:44 <mszyprow> memeka: vb2 core should handle it (untested)

11:44 <memeka> oki i will try :D

11:45 <mszyprow> assuming that all queued frames will be of the same format

11:46 <memeka> mszyprow: it makes sense to be the same format, right? unless you decode multiple files at the same time

11:47 <mszyprow> memeka: yes, so if it works then that check can be removed to give userspace more flexibility

11:47 <mszyprow> memeka: at least it is not related to any hw limitation, just a way v4l2 m2m jpeg decoding is implemented

11:48 <memeka> mszyprow: doesn't this means that it's also a hw limitation - decode only 1 format at a time?

11:48 <memeka> e.g. MFC can decode h264 and mpeg4 at the same time, right?

11:49 <memeka> or actually ... for multiple files decoded you get different setup right? is that queue associate with the hardware of with the buffers allocated by v4l2?

11:50 <mszyprow> memeka: jpeg driver uses m2m framework which keeps the context for each opened file handle and does time multiplexing/sharing of the hw

11:50 <memeka> right so it's associated with the v4l2 not the hw

11:50 <memeka> which means you can have multiple decodings at the same time

11:50 <mszyprow> jpeg hw is context-less basically

11:51 <mszyprow> it process a single image data at once

11:51 <memeka> the only "limitation" is to have all the frames in 1 file the same format, correct?

11:51 <mszyprow> and requires complete configuration for every processed image

11:51 <mszyprow> yep

11:52 <memeka> mszyprow: compiling kernel now and testing, will let you know

11:53 <memeka> mszyprow: btw i did look again at older code for thermals, and there's 4 trip points indeed :P so i revised my patch but still kept 8 points there just to eliminate the warning that there are more than 4 trip points in dts

11:54 <memeka> i picked up the irq-mode patches from samsung-soc list, so I am using irq trip points, and 3 polling ones

11:55 <memeka> but I think this means that the critical trip point is disabled (diff irq) :) so i have to re-check the code again :P

12:00 <mszyprow> memeka: I didn't check thermal yet, feel free to mail your comments to Bartlomiej

12:01 <memeka> mszyprow: actually i see "3" is hardcoded

12:01 <memeka> mszyprow: https://github.com/mihailescu2m/linux/blob/ef4bc80594bd8270036370e39a0d4a0a1b29d591/drivers/thermal/samsung/exynos_tmu.c#L414 -> i assume this is for CRITICAL?

12:02 <memeka> mszyprow: my comments are basically useless, don't have manual etc so it's just guesswork :))

12:32 <memeka> mszyprow: it works ... i can play a mjpeg video :D thanks!

12:36 <memeka> mszyprow: ermmm there is still an issue :))

12:37 <memeka> at the end(? - or at some point in time) there an infinite "<v4l2jpegdec0> Decoder is producing too many buffers" :)

12:39 <memeka> mszyprow: yeah it fails on V4L2_DEC_CMD_STOP

12:40 <memeka> VIDIOC_DECODER_CMD

12:41 <memeka> then it remains stuck in decoder loop with that error

12:48 <memeka> mszyprow: there is no VIDIOC_DECODER_CMD from what i see, so gst does this: /* keep queuing empty buffers until the processing thread has stopped, _pool_process() will return FLUSHING when that happened */

12:49 <memeka> but then the buffers are empty => they are not the same format (JPEG) ? => error getting stuff back :)

12:52 <mszyprow> memeka: v4l2jpegdec need to be improved then

12:53 <memeka> mszyprow: i will just add a VIDIOC_DECODER_CMD that returns 0 :)

12:53 <mszyprow> memeka: yea, this might make gst v4l2 plugin happy

12:54 <memeka> i don't think there is anything it needs to do to stop decoding so it should be ok

12:54 <mszyprow> memeka: jpegdecoding is context-less, so there is no need for separate STOP command

12:57 <memeka> i think the issue is that to "stop", at least gst, will try 1. issue VIDIOC_DECODER_CMD(V4L2_DEC_CMD_STOP), and if this fails then 2. send some empty buffers

12:58 <memeka> then, here: https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/blob/master/sys/v4l2/gstv4l2videodec.c#L501

12:58 <memeka> mszyprow: it's not getting back a valid frame

12:58 <memeka> and remains stuck in the loop

12:59 <mszyprow> memeka: I don't know what the v4l2jpegdev is doing...

16:18 <PabloPL> krzk: About that kernel oops on s5pv210 and sgx - it was my mistake (when porting driver from old kernel). Fixed and it looks like gpu is initializing (kernel is not crasing), but getting information that there is no available egl configuration

16:18 <PabloPL> krzk: Need more investigation

16:18 <PabloPL> EGL Version 1.4

16:18 <PabloPL> Extensions: EGL_KHR_get_all_proc_addresses EGL_ANDROID_presentation_time EGL_KHR_swap_buffers_with_damage EGL_ANDROID_create_native_client_buffer EGL_ANDROID_front_buffer_auto_refresh EGL_KHR_image EGL_KHR_image_base EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_fence_sync EGL_ANDROID_image_native_buffer EGL_ANDROID_recordable

16:18 <PabloPL> Available configurations: 0