this channel seems dead
give pci id and i'll give a grep
I can wensday. Don't have access to the machine till then.
I might have a different card that I will ask about later tho that I do have access to.
mchehab: I've been playing with dvb-mmap this weekend.  Looks like I have it up and running in my userspace app, works pretty well if I select a single service using kernel pid filtering..... but if I try to pass the entire unfiltered TS treat to userspace, there is lots of data packet loss...
(unfiltered TS *stream)
weird
it chokes on WCBS_HD here in new york, which has always been high-bitrate broadcast.
are you sure this is due to dvb-mmap? there were some other changes that are a way more likely to cause regressions there
what driver are you using?
not 100% sure, but i switched the application to use read() instead of mmap() and all data is deleivered without any loss
repeated the test multiple times
it could always be a bug in my userspace code, too
or perhaps you're not allocating enough mmapped bffers
I remember I tested it without any filters
using the new discontinuity detectors I wrote for dvbv5-utils
in what digital standard did you test?
im currently using ATSC at 20mbps
I tested with more than one
for sure I tested with ISDB-T at 19MBps
also, i allocate ten buffers, size is:  (188*((384*1024)/188)
and I guess I tested with DVB-T2 and DVB-C
with higher bit rates
393216 x 10 buffers
yeah those higher bitrate standard should cover it -- maybe its my own bug
maybe
could you try using dvbv5-zap and see what happens?
I don't test it for a while... don't remember the exact details
you may also send me ~60 seconds of record with all PIDs for me to try test it later with my RF generators
I remember I did some tweaks at the buffer size
hmm, looks like maybe my buffer was too BIG
I guess I tried to find a buffer size that were multiple of both 188 and 4096
yeah, I guess I use a smaller buffer size
now im trying (188*(4096/188)) and getting much better results
10 of those ^^
I guess I mapped only 4 buffers :-)
regarding dvbv5-zap, i had trouble getting it to build .     i didnt spend much time figuring it out.  of course it worked for me in the past and ill see what happened soon
with mmaps, the buffer size requirements are different
hmm, so now its playing back perfectltly using much smaller buffers
now to try CBS_HD, the best test
:-)
worked fine?
i was up so late last night, trying bigger and bigger buffers...    ~4K buffers are perfect
yes, works fine
i have to go to the office soon, but tonight hopefully i'll have some time to set up an extended test
great!
i want to run it for some days and collect info about discontinuities, etc
yeah, sure
but yes, this is working very well - im using the hauppauge quad ATSC caprure board on PCIE
i used some code from dvb-vb2.c from your experimental dvb-mmap-2 branch
you should probably have a good way then to compare performance with quad capture with read() and mmap() :-)
ah yes, thats a good idea
the application tries to mmap and falls back to read otherwise, but i can certainly force read on one FE and do a bit comparison 
also, the code changes to the application were small, just changes the pipeline flow to a pull mechanism instead of push and use the dvb-vb2 code to handle the new IOCTLs
i made some small changes in dvb-vb2.c to make it build in cpp ....  also, there was a small optimization to move a calculation outside of a look 
*loop
will you be merging your dvb utils changes for mmap soon?
well, I need some time to work on it :-)
got sidetracked by other things lately
but feel free to submit your changes 
I'll merge to my tree
ok, ill submit them
after your merge
ok
I was able to use dvb-vb2 as-is, so id recommend allowing that lib header to be used independently of libdvbv5
i dont think the props first param is needed in any of those functions, but i know its a work-in-progress right now
i removed it in my copy
the plan is actually to better integrate it
the parms parameter is needed to allow libdvbv5 apps to redirect error messages to their handlers
so, a web-based app like tvd could output them at web...
and a GUI app like kaffeine could present on their interface
heh, i've been spoiler by golang.  i was about to suggest, "why not just return custom errors?" and then remembered that the lang is c
type:  i've been spoileD
^typo lol
a change like that would break ABI/API
we're doing a lot of efforts to not break it
yes i understand, no problem
if I had started it now, I would have designed it on a different way
the way it is, adding support for devices remotely located is more complex than it could have been
ah
(not that much complex, but still require more efforts than if the design was different)
what about this function `stream_expbuf()` - what is that for?
in thesis, it should allow zero-copy to some other driver that uses DMABUF
so, a FF board could benefit a lot with it
oh!  nice
I didn't test yet
I would need a codec driver that would get MPEG-TS inputs to test (or do some hacks to have something that would work like that)
alternatively, we could add some software-based MPEG-TS decoder, and use some H.264 (or MPEG2) codec
with a sw-based MPEG-TS in-kernel decoder, we could very likely use the GPU do do the decoding, having a "FF-like" approach with a simple device
sounds interesting
ok, this is the summary of changes needed to my app to use dvb-mmap: ``` Makefile.am       |    3 
 dvb-vb2.cpp       |  242 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 dvb-vb2.h         |  126 ++++++++++++++++++++++++++++
 linuxtv_tuner.cpp |   76 ++++++++++++++++
 linuxtv_tuner.h   |    7 +
 5 files changed, 452 insertions(+), 2 deletions(-)
```
and if those dvb-vb2 files are accesible in the library, its an even smaller change
this should not be difficult to patch all other DTV applications
good
mchehab: until when do you want/need something like a decision regarding ddbridge, sparse warnings and the proposed patch? I have a feeling nothing won't happen regarding this upstream, and thus I'd rather prepare a simpler fix (more appropriate for the in-kernel fork) for the warnings then.
nst: IMHO, for now let's apply the fix I proposed, and keep discussing downstream
or apply some other alternative cleanup patch
I want those warning patches to go before others... as it makes my life a lot easier knowing that every warning I see is a regression
(I tried an alternative way in the past, with a code that were supposed to "diff" the output, but it caused more harm than good)
so, I'd say that my plan is to apply those stuff early this week
well, in that case lets just get rid of the if'ery on ->dma, one of the reasons being that we're not going to support any hardware that doesn't do dma at all in the foreseeable future. I'll prep a patch for that then.
mchehab: https://patchwork.linuxtv.org/patch/48735/ - runtime tested, no complaints from smatch or sparse. please pick that one regarding sparse fixes
ok.
(runtime tested == four tuners plus CICAM, so both input and output verified)
FWIW, this causes a simple-to-fix conflict with https://patchwork.linuxtv.org/patch/48573/ so ddbridge-0.9.33 requires a rebase afterwards
nst: ok. so, it should come before ddbridge 19 patch series, right?
that makes easy for me
if the conflict is trivial, no need to repost
I'll handle when applying it
yes, its based on the plain media_tree master. The conflict is in ddb_input_start where the patch assumes the "if (input->dma)" is still there. Removing that again is sufficient.
ok