hverkuil, about the SLICE_RAW for H.264, I think I don't agree with ezequielg and ndufresne
anyway if it is just start code, we usually call the bitstream without start code as avc1 for h.264
which is used for MPEG-4 Part 14 file to store a nal unit
I don't think it is a big problem should create a new pixel format in v4l2
as the previous email with ayaka, I think it is a problem about SPS and PPS
gst-launch-1.0 v4l2src device=/dev/hdmi2usb/by-num/all0/video ! fakesink ... ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Could not read from resource.
http://paste.ubuntu.com/p/SQXG79M4f6/
this is when using https://www.armbian.com/odroid-c2/  Stretch  is the image
is that a good test to pass on to the kernel devs ?
sailus: ping
ezequielg, about https://patchwork.kernel.org/cover/10805973/#22477157 the long term reference
the current rkvdec doesn't need it at all
it is prepared for the future device which requests a different input data
and those data should be prepared in the userspace which is not a common requirement for any devices
jmondi: Pong.
sailus: Hi Sakari
jmondi: Buona giornata!
sailus: Bungiorno! miten sinä olet?
:-)
Well, I'd put it a little differently. ;)
E.g. "mitä kuuluu", "miten menee" or "kuinka voit".
Mutta oikein hyvin kiitos.
Entä itselläsi?
wow wow.. too fast for my google translate skills :)
I'm fine thanks (now translated the whole sentence :)
sailus: you pinged me yesterday, was that for v4l2-mux ?
Streams.
But, sorry, I need to go now.
will you be around in the afternoon ?
I'll be back later on. An hour and a half or so.
ok, I knew pinchartl was interested too, let's try to be all available this afternoon
see you later
jmondi: It seems I'm free now.
sailus: good, who knows if pinchartl is around too...
What I wanted to talk about is semantics of the [SG]_ROUTING interface.
sailus: anyway, streams you said... have you read my email from yesterday? I feel a bit uncertain about extending v4l2_mbus_frame_desc with phy configurations...
sailus: yup, go on
Do all the routes exist on the device at all times, or can new routes be created?
are you afraid of the complexity (and size) of the routing tables?
(answering a question with another question...)
If the former is holds, then what parameters are used to identify a route?
I'm not sure I'm following
Yeah...
This is complicated. :-)
a route is defined by a tuple (sink_pad, sink_stream, source_pad, source_stream), and devices should list all the possible routes, am I wrong?
On receivers the stream is generally a software concept and depends on what the transmitter sent.
So you don't know the stream numbers in advance.
Unless we define, what they can be, of course.
But so far they haven't been defined.
isn't this related to exposing streams id through frame_desc more than related to [SG]_ROUTING ?
And... the number could be large. CSI-2 does multiplexing based on virtual channels and data types, and there are many virtual channels and about as many possible data types.
[GS]_ROUTING uses these stream IDs.
Usually the hardware has limited resources to pick, so only some of these streams can actually be enabled.
I always assumed stream ids range from 0 to 4, but that's actually not defined
What's from 0 to 4?
if I got you right, the issue is that  user space could set anything as 'source_stream' though S_ROUTING and that the stream id is then propagated to the next subdevice, which has not idea what a stream id could be
what I assumed ranged from 0 to 4 was the 'struct v4l2_subdev_route.source_stream' field, but that's not actually the case, as it is not specified anywhere
I think for receivers we should let the user specify anything, as long as it matches with the transmitting end.
But that means that there would be awfully many routes that are all disabled apart from just a few at any given point of time.
Unless routes were created at the time of enabling them.
and deleted once disabled?
Yes.
On transmitting devices (e.g. a sensor) the routes exist in hardware without much configurability, but receivers typically are designed to receive just about anything.
So the interface would probably be best designed around that.
This could pose some challenges to the uAPI --- how do you know when you should try creating new routes? When you don't have any, or you don't have what you needed?
I guess it could work just like that.
It's fairly practical at least. :-)
is your concern due the fact userspace can potentially use any value as "source_stream"?
because I'm actually wondering if the 'source_stream" value is actually releveant, and should not instead come from the number of routes directed to a pad
The transmitter may support more streams than a receiver.
Hmm. Are you talking about a (simple) transmitter or a receiver now?
transmitter, if we allow creation of routes with arbitrary "source_stream" ids
For simple transmitters the current API is just fine.
Semantics, that is.
But for receivers that can receive pretty much anything, I don't think it's sufficient.
if I look at how the routing table for, say, r-car csi-2 receiver is created, it's sink_stream numbers come from the transmitter's ones
s/it's/its/
and more generally the entries in a routing table of a receiver depends on the number of available streams exposed by the transmitter, and in the end, on what the media bus allows you to multiplex
a CSI-2 transmitter will have up to 4 streams for each one of its source pads, as that's the number of streams you can multiplex on that bus
am I too CSI-2 centric with my reasoning?
Well, you could have up to the number of virtual channels times the number of different data types.
doesn't the data type just depends on the transmitted format?
If you have a CSI-2 receiver that are limited to four virtual channels with a single data type at a time, then creating the routes beforehand is an option.
How do you know what the transmitter supports?
At the time of receiver driver initialisation, that is?
Yes, the data types depends on the format for *that stream*.
But there can be more streams using a different data type.
wouldn't associating a DT with a stream overlap with format configuration?
but yes, you could send multiple DT with the same VC, or separate each DT in a VC, it's up to the transmitter and the receiver does not know how it is handled
jmondi: There's no overlap really; the data type changes but the stream id shouldn't.
sailus: could you make a real use case example? Because I understand GS_ROUTING might fall short in describing complex DT/VC interleaving methods, but I still fail to see why the receiver might be confused by the number of streams on the transmitter side, as they only exchange informations though v4l2_mbus_frame_desc, which supports up to 4 entries, and for each entry you have one VC value and one DT value (and
this might not be enough to support complex DT/VC interleavingg schemes  as well)
jmondi: I'll write an e-mail.
Let's then continue over IRC.
sailus: thanks!
when I plug in usb devices, I don't see anything in dmesg.  except maybe once.
is there some way to force a scan or something ?
whoops, wrong #
paulk-leonov: hey
paulk-leonov: how would the h264 pixel format, with an offset into the start code work?
considering you probably need alignment for dma...