[03:01] *** noobie12 has left "Leaving"
[09:14] <funman> mchehab: I can't seem to get CBR reads: https://pastebin.com/r5qkadEp
[09:15] <funman> I can use small buffer sizes with set_pesfitler, e.g. 5*7*188, but only with some adapters and not others
[09:16] <funman> but the smaller I go the more discrepancy I get in timings
[09:19] <mchehab> that doesn't sound a libdvbv5-related issue, but either a Kernel, driver or device limitation...
[09:20] <mchehab> yet, I never heard about people reporting problems on reading from constant bit rate video sources
[09:20] <mchehab> with regards to the pesfilter size, for some devices, you indeed need a large buffer
[09:21] <mchehab> otherwise, you'll start seeing buffer overflows
[09:21] <funman> yep
[09:21] <mchehab> that's specially true for USB devices
[09:21] <funman> to be clear i'm not losing data but i wanted to use the timing information
[09:22] <funman> weirdly here it's the USB device that can use smaller buffers :)
[09:22] <funman> but i only tested 2
[09:22] <mchehab> the thing is that, on most usb devices, the device uses an internal buffer, and it sends URBs only when the buffer is full
[09:22] <mchehab> (PCI devices may actually be doing similar stuff... doing DMA only if the buffer is full)
[09:23] <mchehab> if you allocate a buffer with set_pesfilter that it is smaller than the data burst that will be sent when the device starts DMA, you get buffer overflows
[09:24] <funman> I see
[09:24] <mchehab> in practice, you need a buffer a little bigger than that, as otherwise you'll have underflows, if you didn't finish reading the buffer while a new one is filled
[09:25] <mchehab> there's not much we can do here
[09:27] <mchehab> also, let's say that the DMA burst is of size = n
[09:27] <mchehab> the actual PES filter buffer is: n + extra
[09:28] <mchehab> the "extra" size actually depends on how fast is the CPU
[09:28] <mchehab> in order to avoid CPU issues, people use to set extra = n
[09:29] <mchehab> (on v4l, where we know the "n" size)
[09:29] <mchehab> on DVB, we don't
[09:29] <mchehab> so, except on embedded hardware, we just use a large-enough value, based on experimental tests
[09:31] <mchehab> we could add some way for userspace to get some hints, but the thing is that, even with datasheets, we don't really know how big is the DMA burst, on most cases
[09:31] <mchehab> as this is not documented
[09:33] <funman> yeah i guess try and error works
[09:35] <mchehab> yep. anyway, if you have a better idea and want to try patching the kernel, feel free to send us the patches :-)
[09:36] <mchehab> I would love to be able to use smaller buffers, as this would make channel changes faster
[14:16] <funman> looks like the delay came from mismatch between DMA buffer size and pesfilter size
[14:16] <funman> that's why it was periodic
[14:16] <funman> if DMA transfers 8 buffers and you read 9, it takes 2 ticks 7 times and 1 tick 1 time
[15:26] <funman> mchehab: how would I discover the buffer size for my USB device ?
[15:27] <funman> looking in lmedm04.c, grep demux gives nothing, not sure if I have the right file
[17:16] <jonathan_x> Yo
[17:16] <jonathan_x> I am setting up a Philips DVB-T card that is very like some Asus card.
[17:16] <jonathan_x> I have managed to get it tuning but I receive no video or audio yet.
[17:17] <jonathan_x> I wonder what to do next.
[17:17] <jonathan_x> Kaffeine displays no image or sound
[17:17] <funman> how do you know it's tuned ?
[17:17] <jonathan_x> dvbtraffic gives no output
[17:17] <jonathan_x> dvbv5-zap
[17:19] <jonathan_x> This is output from dvbv5-zap: http://paste.debian.net/996724/
[17:20] <jonathan_x> Is that good or no?
[17:20] <funman> dunno, i never used dvbv5-zap
[17:20] <funman> could your channel.conf be out-of-date?
[17:21] <funman> the "lock (0x1f)" looks good at least you have signal
[17:22] <jonathan_x> I was using a dvbv5-scan channel file
[17:23] <funman> ah so it doesnt list the pids ?
[17:25] <jonathan_x> This is the channel.conf: http://paste.debian.net/996725/
[17:25] <jonathan_x> Or at least dvb_channel.conf
[17:25] <funman> what's your sat?
[17:25] <funman> oops not satellite
[17:26] <funman> well the pids could be out of date
[17:26] <jonathan_x> Well I just scanned it
[17:26] <funman> ah
[17:27] <jonathan_x> Is that dvbv5-zap output good enough to move on?
[17:27] <jonathan_x> It seems to use demux0
[17:27] <funman> probably
[17:27] <jonathan_x> But mplayer seem to hang on opening the demuxer
[17:27] <funman> ah do you have something still using the demuxer?
[17:28] <jonathan_x> Not that I know
[17:28] <jonathan_x> kaffeine seems to think everything is okay except no image or sound
[17:28] <jonathan_x> Also the page for the Asus card lists that a firmware file is needed, that I copied into /lib/firmware
[17:29] <funman> if you scanned you should be good wrt drivers
[17:32] <jonathan_x> Okay
[17:33] <jonathan_x> program guide also works Kaffeine just won't even start playing the stream
[17:34] <jonathan_x> But it says
[17:34] <jonathan_x> demux_wavpack: (open_wv_file:127) open_wv_file: non-seekable inputs aren't supported yet.
[17:34] <jonathan_x> net_buf_ctrl: dvbspeed mode
[17:34] <jonathan_x> net_buf_ctrl: slow/fast audio playback enabled
[17:34] <jonathan_x> net_buf_ctrl: enlarged video fifo to 800 buffers
[17:34] <jonathan_x> net_buf_ctrl: dvbspeed OFF
[18:18] <jonathan_x> The problem I have is to do with vdpau and nouveau
[18:18] <jonathan_x> Sucks.
[18:18] <jonathan_x> It appears I need to download and extract firmware from the nVidia installer.
[18:18] <jonathan_x> Running VLC now and I have audio :).
[18:18] <jonathan_x> But no Video yet.
[18:19] <jonathan_x> For some reason reception is excellent compared to my previous card in Windows.... :-/.
[18:19] <jonathan_x> I would always have staggering reception
[18:19] <jonathan_x> And now it is continuous :-/.
[18:19] <jonathan_x> :).
[18:19] <jonathan_x> Yay.
[18:23] <jonathan_x> This card has no driver in Windows though.
[18:23] <jonathan_x> Too old.
[21:53] <gstaraz> good day... anyone there ?
[21:55] <iive> no