<!-- 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>
pinchartl: <u>posciak</u>: pong
posciak: <u>pinchartl</u>: I think things got a bit clearer now :)
pinchartl: <u>posciak</u>: compared to what ? :-)
posciak: <u>pinchartl</u>: the code for the VP8 controls and structures is actually written by me as a part of the frame/slice API
<br> <u>pinchartl</u>: I meant regarding the VP8 parts you asked me about yesterday
pinchartl: do you mean that the code in that patch series is yours ?
posciak: not the driver itself
<br> did you see follow up replies on the list?
<br> the code for VP8 API changes is mine
<br> specifically
<br> https://chromium-review.googlesource.com/#/c/237670/
<br> it's a part of slice/frame API that is awaiting your request api before I can submit :)
pinchartl: brb, in a meeting
<br> <u>posciak</u>: back
<br> sorry for the delay
<br> I'm reading the replies now
<br> <u>posciak</u>: you can probably refresh my memory, have we discussed passing the parsed VP8 headers in a plane vs. a control ?
posciak: <u>pinchartl</u>: I believe so
pinchartl: and we concluded that we should use a control ? :-)
posciak: <u>pinchartl</u>: there are multiple potential problems, from how this would interact with format structures and fourccs, through potentially having to have variable plane numbers for formats more complicated than VP8 (like H264), to the fact that it'd probably be preferable not to allocate dmable memory for these, since they are intended to be used by the driver only. Hardware would not be able to read out from these
<br> anyway, so using dma memory may not be good. So we'd need to be able to have sglists, dmabufs, cache syncs and iommu mappings for only some planes, not all. I feel this would complicate videobuf2 and drivers quite a bit. Controls are much cleaner I feel, especially with request API. I might also be forgetting some other points we discussed previously.
<br> I don't exactly recall when we discussed this, but I think we concluded controls were the way to go. Hans may remember too.
<br> VP8 is simple as it's one frame header per frame, for H264 the API is much more complicated
<br> and has multiple controls
<br> and each frame can use different sets
pinchartl: <u>posciak</u>: good points
hverkuil: <u>posciak</u>: I can't remember the details of that discussion, but that says everything about my poor memory and nothing about the discussion itself.
<br> But I think using controls in combination with the request API does make sense. It's quite clean IMHO.
posciak: <u>hverkuil</u>: thanks
hverkuil: posciak, mchehab: are you planning to attend the ELC?
posciak: <u>hverkuil</u>: probably not
<br> you mean the one in San Diego?
hverkuil: y
mchehab: <u>hverkuil</u>: didn't decide yet
<br> <u>hverkuil</u>: https://mchehab.fedorapeople.org/mc-next-gen/wintv_usb2.png
posciak: are you considering any topics for it?
mchehab: I'm actually in doubt if we should either call tda9887 as tuner (like on that diagram) and adding a special type for the PLL...
hverkuil: <u>mchehab</u>: looks good. That tuner has no radio support, right?
mchehab: or calling the PLL as tuner and use an special type for tda9887
<br> no, this specific one doesn't
<br> it is one of the simplest TV device I have
<br> only ATV, no radio, just one capture port (s-video)
hverkuil: <u>posciak</u>: possible topics: request API status, data stream multiplexing (what Guennadi is working on), MC, ... I'm sure we can fill at least one day with discussions :-)
posciak: <u>hverkuil</u>: to be honest I was hoping we could get request API in before that ;)
<br> at least maybe some subset
<br> but Laurent's set is huge
<br> wondering if we could somehow split it into v4l part only
<br> separately from MC
<br> and maybe even split format requests
hverkuil: <u>posciak</u>: I doubt it. I want to have a clearer picture of the impact of Laurent's work. It might be that we can merge a subset of that (the control framework part) but I want to be certain that integrates well later on and we won't be stuck with a bad API.
posciak: <u>hverkuil</u>: perfectly understood and hard not to agree with this
<br> I guess splitting format requests from control requests would not be desirable either then
hverkuil: <u>mchehab</u>: just a heads up: I might ask you for help testing this: http://www.spinics.net/lists/linux-media/msg96816.html
<br> I try to do it today, but if I don't have the time then the next slot I have would be Friday next week and I rather have this tested earlier due to the impact of this regression.
mchehab: i won't likely be able of testing it today (or at least not this morning), as I'm busy with adding MC support for em28xx
<br> I don't test read() for ages ;)
<br> I'll see if I can test it after finishing the work with em28xx
hverkuil: I'll mail you if I run out of time. It's not about read(), the vb2_thread mechanism is also used for DVB streams in several drivers.
<br> This is DVB specific (I tested v4l2 read() myself and that's working)
mchehab: ah, true
<br> it uses the logic that it is very similar to read()
<br> only a few drivers actually use vb2-dvb:
<br> drivers/media/pci/cx23885/cx23885.h:#include <media/videobuf2-dvb.h>
<br> drivers/media/pci/cx88/cx88.h:#include <media/videobuf2-dvb.h>
<br> drivers/media/pci/netup_unidvb/netup_unidvb.h:#include <media/videobuf2-dvb.h>
<br> drivers/media/pci/saa7134/saa7134.h:#include <media/videobuf2-dvb.h>
hverkuil: true, but those are pretty popular devices :-)
mchehab: yes, but they all are PCI...
<br> I have to setup a machine for the test, as I didn't touch any PCI development since I moved to another address
<br> the hard part is likely find where I stored a machine with an old PCI slot ;)
<br> (if I still have such machine)
hverkuil: I'll really try to test it today. But I'm leaving for the Netherlands late this afternoon and I need to setup the DVB generator as well (and remember how to use it...).
<br> cx23885 is PCIe
mchehab: ah, true
<br> that makes it easier
<br> I guess I have one or two cx23885 DVB boards somewhere at the basement
<br> I won't promise doing it today
<br> but I'll see if at least I can prepare a machine to test it later
<br> and perhaps testing the board on an arm64 with a PCIe slot ;)
hverkuil: not for today, but tomorrow or early next week.
mchehab: ok.
hverkuil: I don't want to have to wait until Friday next week given the impact of this bug.
mchehab: yes, sure
<br> another thing: by adding MC support on em28xx, we're opening MC to the wild, as there are lots of different chipsets used on those boards...
<br> as they'll all use a single function to build the media graph, we need to standardize the PAD indexes for everything there: tuners, demods, IF-PLL TV video demods (tda9887), IF-PLL TV audio demods (msp3400), etc
<br> I see two options: add them at include/media/v4l2-subdev.h or create another header file, and include it at v4l2-subdev.h
<br> what do you think?
<br> I'm also considering to move such function to v4l2 core, instead of having a copy of it at au0828, em28xx, cx231xx, ...
<br> again, where it would be better to add such function?
<br> FYI, I'm talking about what's there on this patch: https://git.linuxtv.org/mchehab/experimental.git/commit/?h=mc_em28xx&id=d143ad4e75f579fd7939c26b7d30e39e1c6ca9c8
<br> at em28xx_v4l2_create_media_graph()
<br> the function is not yet generic enough to be moved to the core....
<br> making it generic would require to touch all V4L2 PCI and USB drivers to standardize the code that handles VIDIOC_ENUMINPUT/G_INPUT/S_INPUT
<br> as, right now, they use their own macros/logic for TV, composite, S-video, ...
hverkuil: <u>mchehab</u>: see Sakari's "Unify MC graph power management code" v2 patch set: I proposed that he creates a v4l2-mc.c for just utility functions. Seems to make sense.
<br> Standardizing pads can then be done in the v4l2-mc.h
mchehab: OK, works for me
hverkuil: I agree that we need more v4l2 mc helper functions, I noticed the same thing: too much duplicate code.
***: CarlFK has left
mchehab: <u>hverkuil</u>: I think this way the device is better represented: https://mchehab.fedorapeople.org/mc-next-gen/wintv_usb2.png
<br> (still missing the ALSA part, so the audio IF decoder doesn't have anything connected to pad 1)
<br> and just the analog part of hvr-950, where both IF decoders are integrated, and em2882 with VBI support: https://mchehab.fedorapeople.org/mc-next-gen/hvr_950.png
<br> I'm actually thinking on folding pads 1 and 2 on the ATV decoder, as both VBI and video are actually just one signal
<br> that are just cropped with different windows and sent through two different DMA engines
hverkuil: <u>mchehab</u>: looking at the wintv usb2: shouldn't the tuner have two output pads? One audio, one video?
<br> Never mind, one goes to the tda9887.
mchehab: <u>hverkuil</u>: the actual number of output pads depend on the tuner model...
<br> it is probably not worth to map it precisely
<br> I mean:
<br> some tuners have luma + chroma + audio outpus
<br> while others have video + audio
<br> and others may have a muxed stream with audio and video
<br> also I guess that sliced VBI can either be muxed or provided via a separate bus
<br> (forget about sliced VBI.. this is actually at the ATV decoder)
hverkuil: regarding folding pads 1 & 2 on the atv decoder: I don't think that's a good idea. It's generally separate paths inside the hardware.
mchehab: but I guess you're right: we should provide two separate outputs at the tuner, one for video and another one for audio
<br> shuah's patches actually added a separate line for audio (not sure if she touched just the ATV decoder or also the tuner)
sailus: <u>hverkuil</u>: Hi!
dc786: jmleo, remember yesterday about mencoder dropping 75% or more frames?
<br> trying to make progress on alternative to mencoder using linuxtv.org/wiki/index.php/V4L_capturing web page
<br> updated kernel by apt-get install linux-image-lowlatency-lts-vivid
<br> uname -r is now 3.19.0-49-lowlatency
<br> mencoder still drops 75% or more of frames
jmleo: dc786, that's weird... did you try to simply run v4l2-ctl with the stream-mmap option ?
<br> tried something else than mencoder ?
dc786: I got a gst-launch stream to save raw video and audio to a matroska mux, and video tracks the audio, but it has a weird plaid pattern (and takes lots of disk space)
<br> I think my graphical desktop now has compiz, and didn't on 12.04
<br> does compiz take too many resources for mencoder to do mpeg4 encoding?
jmleo: I can't answer you... you will have to profile (perf is a godd tool, but top is a good start too)
<br> s/godd/good
dc786: not sure what to try next, the gst-launch pipeline gives me the plaid video corruption, mpv plays beautiful picture from the card
<br> jmleo, you are probably about to call it a day, I here in Arizona, USA, am only about 4 hours into daylight
<br> I was using top yesterday, and it showed me pavumeter was using 100% CPU (but I have 4 cores)
<br> little else hit more than a percent or two very often
<br> perf with no specification of events says 8.43% of mencoder is in libc-2.19.so, __memcpy_sse2_unalign...
<br> all else under 3% each
<br> seems to be more about pulseaudio, but maybe Hauppauge card is just memory access (... above is "ed")
<br> oh, not running pavumeter made no difference
***: dc786 has left "Leaving"