<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
mchehab: <u>hverkuil</u>: pong
hverkuil: <u>mchehab</u>: I tried to use dvbnet with vidtv, but I noticed that it segfaults when given an unknown commandline option (e.g. dvbnet -h). Is anyone maintaining this?
<br> Has it been tested with vidtv?
mchehab: no, never tested it with vidtv
hverkuil: I see no dvbnet replacement in v4l-utils, is dvbnet still intended to be used?
mchehab: probably something else is needed
<br> bbiab
hverkuil: Hmm, it looks like you should either call vb2_dvb_register_bus() or explicitly call dvb_net_init, and vidtv doesn't call either of these.
<br> You really want vb2_dvb_register_bus so the streaming I/O support can be tested with vidtv.
mchehab: for dvb_net to work, a MAC address is needed
<br> vb2_dvb_register_bus() doesn't make any sense... vidtv doesn't use VB2
<br> <u>hverkuil</u>: FYI, dvb_net's main usage is to receive TCP/IP packets from some Satellite providers
<br> this was never ported to v4l2-utils due to a single reason: I never actually tested it
<br> well, I did some tests to check if it is creating the DVB network interfaces...
<br> but never did a test in a way that I would be starting to actually receive TCP/IP packets
<br> (because I would need first to tune into non-encrypted channel with TCP/IP traffic)
<br> there weren't any such DVB/S on the satellite antena from where I used to live...
<br> and I don't have any DVB-C boards that would support TCP/IP
hverkuil: <u>mchehab</u>: vb2_dvb_register_bus() doesn't make any sense... vidtv doesn't use VB2
<br> But shouldn't it use vb2? I know it doesn't now, but is there any reason for that limitation?
mchehab: <u>hverkuil</u>: it could use VB2, if MMAP support for DVB is compiled, but this is transparent for the driver
friki-: Hi. I'm trying to get working a Conceptronic device to capture video&audio. It works for video when i load em28xx module with param "card=9" but seems to be unable to capture audio. I think I've tested all other "card" already
<br> This is the "Quick installation gide manual" for the device (pag7 english): http://download.conceptronic.net/manuals/C08-025_CHVIDEOCR_Quick_Guide_ML.pdf
<br> I can fill a bug if it's preferred
mchehab: friki-: it probably requires a different setting than the already known boards. Each em28xx-based board use different internal wirings.
<br> the "card" entries is actually a a pointer to some descriptors at the Kernel source which tells where things were wired
<br> and how to enable the chips inside the board
<br> it is possible to add those if you have some programming knowledge
<br> (there are some tools at v4l-utils that would allow to sniff the traffic when used with its original driver)
<br> it might also be possible to figure out the parameters by looking at the .inf file from the original driver's setup
<br> the .inf files sometimes contain what's missed
friki-: <u>mchehab</u>: thanks! I'll try to collect some more info (.inf from original driver and, may be, a usb traffic capture)
koike: hverkuil tfiga: o/ Hello/ping, I was wondering if there is any particular reason to not get the buffer size always from the dma buf info https://git.linuxtv.org/media_tree.git/tree/drivers/media/common/videobuf2/videobuf2-core.c#n1217
hverkuil: <u>koike</u>: this was discussed in this thread: https://www.spinics.net/lists/linux-media/msg171475.html
koike: <u>hverkuil</u>: I'll check, thanks!
hverkuil: See my reply from Oct 29.
koike: ok
hverkuil: It was never implemented, but that's the way to do it. It's a bit more work than you would expect.
sailus: <u>koike</u>: Would you be able to recheck the async cleanup set? I'd send a pull request to Mauro including it.
koike: <u>sailus</u>: sure, I'll take a look
sailus: <u>koike</u>: Thanks!
ndufresne: <u>hverkuil</u>: async question for you, do we have an event to signal that v4l2_input.status have changed ? (e.g. it gained or lost the NO_SIGNAL flag)
hverkuil: <u>ndufresne</u>: that's V4L2_EVENT_SOURCE_CHANGE, at least w.r.t. having a valid signal or not. But note that while this event is compulsory for DV_TIMINGS interfaces such as HDMI, it is optional and usually missing for SDTV analog video (G/S/QUERYSTD).
<br> In part because analog video support predates that event, in part because some analog video HW doesn't even have an interrupt for it.
ndufresne: that's fine for me, we have only one input, an HDMI signal over HDBaseT
<br> it's first time I look at it, basically I'm teaching GStreamer to detect and redo the negotiation when resolution changes
<br> <u>hverkuil</u>: I wonder, what happens when no-signal, or no-power regarding resolution
<br> do we still receive buffers, like blue frames, or do streaming actually stop ?
<br> I also see two venu after this even is signalled, a) the driver has scaling support and will start scaling to current resolution, b) the driver does not have this capability and will fails somehow, EPIPE like CODEC are doing ?
<br> * venuE after this evenT
<br> <u>hverkuil</u>: thanks as usual btw !
pinchartl: <u>hverkuil</u>: the v4l2_event_src_change.changes bitfield has a single bit defined, V4L2_EVENT_SRC_CH_RESOLUTION
<br> when the signal is lost and detected back, with the same resolution, should V4L2_EVENT_SRC_CH_RESOLUTION still be set ?
<br> or could .changes be 0 ?
<br> it seems weird to have the event reporting no changes
ndufresne: <u>pinchartl</u>: I just assumed that flag was called "reserved" not too long ago
-: ndufresne checking
ndufresne: wrong, it was introduced like this
<br> commit says "resolution change detected by a video decoder OR a format change detected by an input connector."
pinchartl: does hotplug or hotunplug count as a format change ?
ndufresne: well, I think it would make userspace life simplier, right now we get random IOC failing
hverkuil: <u>pinchartl</u>: yes, when the signal disappears that bit should be set as well.
ndufresne: admitedly I was lazy, but it seems quite hard to catch that correctly
hverkuil: It really means that you need to check QUERYSTD or QUERY_DV_TIMINGS to see what is going on.
pinchartl: <u>hverkuil</u>: and when the signal reappears too I suppose ?
hverkuil: yes
<br> There is a patch pending that adds another flag (CH_COLORIMETRY or something like that) for changes that do not involve a resolution/format change.
<br> ah, that patch is marked as RFC for now.
ndufresne: <u>pinchartl</u>: for UVC hotplug though it's gonna be complicated, since there is no way to know for sure if it's the same camera that got plugged in, would you just re-associate a random UVC camera to whatever userspace is holding on ?
pinchartl: <u>ndufresne</u>: for UVC hotplug the video node will disappear, so there's nowhere to report an event :-)
<br> I was thinking about hot(un)plug of, for instance HDMI or SDI cables
friki-: <u>mchehab</u>: I've modified the em28xx module adding a new card (106) for testing purposes. I've rebuild several times with different audio setups I've found for other hardware without success. I also have found the drivers (containing .inf file) here: http://download.conceptronic.net/drivers/C08-025_CHVIDEOCR_Drivers.zip
<br> by now i can't test the hardware on a supported OS (windows), so i can't capture usb traffic on a working audio capture
ndufresne: <u>pinchartl</u>: noted