neg: is this series OK? https://patchwork.linuxtv.org/cover/63056/ (media: add v4l2_pipeline_stream_{enable,disable} helpers)
neg: same question for this series: https://patchwork.linuxtv.org/cover/63086/ (media: rcar-vin: Enable MEDIA_BUS_FMT_SRGGB8_1X8 format)
hverkuil: I still need to test the later one (MEDIA_BUS_FMT_SRGGB8_1X8) it's on my list today
hverkuil: The first one somehow slipped my todo file will look at it straight away
hverkuil: Seems my bandwith for today is running out fast I might have to push MEDIA_BUS_FMT_SRGGB8_1X8 testing to next week is that OK for you ?
neg: sure, no problem. No hurry, I was just wondering about the status of that series.
hverkuil: If you are ok with Laurent's '[PATCH v8.1 3/6] media: v4l2: Extend VIDIOC_ENUM_FMT to support MC-centric devices' can you pick the series as is or want me to post a v9 ?
that should be fine. I'll look at that right away.
thanks
hverkuil: crasy idea, but do you think we could allocate an explicit fence from a MC request ?
ndufresne: not a clue. I'm not familiar enough with fences. Especially not on a Friday later afternoon :-)
late afternoon
no worries
hverkuil: as you may know, I've been adding native stateless decoder support in gst, initial implementation does lazy output, that gave us really good throughput, but now we added zero-latency support (like FFMPEG does) and that impact the throughput, because we endup decoding, waiting, pushing, which increase the idle time
we could introduce a thread, or a fence to solve this
we currently wait on a request, which is surprisingly similar to a fence really
have a nice weekend
You too!
tfiga: any idea were this V4L2_VP8_FRAME_HEADER_FLAG_EXPERIMENTAL came from ? are there stream using that ?
ezequielg: I think I missed that during review, https://chromium.googlesource.com/chromium/src/+/master/media/gpu/v4l2/v4l2_vp8_accelerator.cc#37
ah, there is only 2 modes, absolute (0) and delta (1), so I guess it's fine to keep as flag, it won't be updated anytime soon
ndufresne: no idea, but I suppose that's just a bit in the stream?
as defined by the spec
https://tools.ietf.org/html/rfc6386 indeed mentions is_experiemental, but the example code bails out with an error if it's 1
tfiga: ok, so I guess this will never exist, it won't cause issue to have it in the kernel, but it does not seem very useful
ezequielg: why do we pad the width height on output queue of VP8 decoder ? (e.g. VP8_FRAME 500x333 -> 512x333)
I don't see any logic to pad that value, of course the capture side, but for the output it's weird, it feels like that stream is not supported
I could be less stric, and just assume that if width/height is bigger it's fine, but it's just a little odd
ezequielg: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/merge_requests/1216
ezequielg: I'll check your response next week to complete this task ;-P works well otherwise
hum, yeah. Guess you are right. If there's any reason, I am most definitely unable to think of it Friday end of play!