mchehab: I hope you haven't already received fixes for all the atomisp bugs I just spent half my day on fixing
hverkuil, Am I wrongly remember that S_FMT could be called during STREAMON if the driver can handle it? (Despite the fact that the documentation says it should return EBUSY)
svarbanov: I believe all proposal in this regards ended up in that we need to streamoff
but you are not forced to drop and reallocate teh buffers if they are not large enough
sorry, if they are large enough
ndufresne, I'm thinking if the new_buf_size > buf_size and new_buf_count > buf_count, The new buf_size can be get by G_FMT and the new buf_count through V4L2_CID_MIN_BUFFERS_FOR_CAPTURE/OUTPUT
then using VIDIOC_CREATE_BUFS
G_FMT should be valid in streaming
ndufresne, in theory it should do the job
but think you'd break existing userspace if you chang the FMT this way
G_FMT will change anyway because the stream parameters have changed
What is the problem you want to solve ?
how to avoid streamoff / streamon in case of source_change
well, streamoff/streamon is not by itself a problem, so I'll ask again, what problem are you solving ?
(also, is that only CAPTURE streamoff ? aka the produced format changes, but you still decode let's say H264)
svarbanov: cause even with the delete buf proposal, we'd streamoff(CAPTURE) to set the new format, but that was design with stateless decoder in mind (vp9 resolution change with stateless)
ndufresne, could you remember where that discussion happened, irc or emal
the delete buf proposal was during the workshop in Lyon, I thought you were there, Boris was driving it
we haven't got time to send an RFC yet, but we are not giving up, we'll need to have a VP9 compliant interface at some point
I must be slept :)
hi arnd, thanks for the patches! I did just a quick look, but I guess most will apply
(btw, there are lots of other warnings hidden)
svarbanov: actually it was not even the first time, pinchartl had proposed it in 2015, https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjYna7di9rpAhVHmuAKHfuZA6oQFjAAegQIARAB&url=https%3A%2F%2Flinuxtv.org%2Fdownloads%2Fpresentations%2Fmedia_ws_2015_seoul%2Fv4l2-workshop-2015.odp&usg=AOvVaw2TA73ui9cFQ09HyHAYkBuk
(sorry, should have used a link shortener, it's hverkuil report of the 2015 workshop)
if you take a look at drivers/staging/media/atomisp/Makefile, you'll see 5 warning types being disabled
ah damn, it's even worst, this link is the google tracker ...
the plan is to remove those warning disabling stuff after (a lot more) cleanups at the driver
there are simply too many abstraction layers there... getting hid of them should solve lots of stuff
ndufresne, the link is good. there is even one topic which I need to think of, encoder custom CSC
mchehab: I see now, but those are only W=1 warnings. I also build with an experimental patch set that ends up ignorigin the warnings flags in the Makefile because I set all warning options using a #pragma in a header file
fwiw, I was building with clang-11, which is more picky about certain bugs than gcc
ndufresne, there were a question can we use encoder 'Reset' state (got form the encoder spec under review) to change encoder input color format. The answer is obviously "no, we can't" but I started to think how we can avoid streamoff if the color format is the same (decoder case: level,profile change in the middle of the stream)