#linuxtv 2019-06-05,Wed

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)
WhoWhatWhen
***ChanServ sets mode: +o mchehab [02:18]
......................................................................................................... (idle for 8h43mn)
mchehabmarc|gonzalez: some frontends provide just the TS payload (188), while a few provide also the headers (thus 204 bytes) [11:01]
marc|gonzalezmchehab: I read that "Packets are most often 188 bytes in length, but some transport streams consist of 204-byte packets which end in 16 bytes of Reed-Solomon error correction data."
I used to work with transport stream a lifetime ago, and I'm not sure which headers you're referring to... /me confused 		[11:02]
mchehabit is not just red solomon... ISDB-T has some additional things there too
I don't remember the exact details, though 		[11:02]
marc|gonzalezmchehab: OK no worries, I'm just grasping at straws at the moment.
Will try to come up with a minimal driver to get my work kickstarted 		[11:04]
mchehabtypically, 188 is all you need on 99% of the cases [11:04]
marc|gonzalezI know that Japan has some kind of weird earthquake thingy that makes packets larger as well [11:05]
mchehabwith regards to TS decoding in SW x HW, all drivers support SW decoding in software
some also offer HW decoding 		[11:05]
marc|gonzalezdecoding = demuxing ? [11:05]
mchehabyep
mchehab needs caffeine 		[11:05]
marc|gonzalezyah, I have no access to the HPG, so I'm going to take it step by step, looking at the downstream source code
HPG = hardware programming guide, sorry 		[11:06]
mchehabtypically, drivers start assuming SW decoding... [11:06]
marc|gonzalezright, SW demuxing ;-) [11:06]
mchehabthen they add some additional code for HW decoding
gah! 		[11:06]
marc|gonzalezsmirk [11:07]
mchehabyeah decoding -> demuxing [11:07]
marc|gonzalezmchehab: should I submit the minimal driver, and add HW filtering as a follow-on patch? [11:07]
mchehabthat would work for me [11:08]
marc|gonzalezOK would you be the reviewer or are there co-maintainers as well?
I worked with someone else on a IR driver a few years back 		[11:08]
mchehabwe work here with sub-maintainers... in the sense that this is a too big media subsystem...
so, we "split" it into some areas of expertise
syoung is doing dvb review 		[11:09]
marc|gonzalezsyoung, I think it was with him that I did the IR driver :-) [11:10]
mchehabhe also handles IR [11:10]
marc|gonzalezCool, I look forward to working with you guys! [11:10]
mchehabgreat
feel free to submit documentation patches as you detect issues there
on DVB, the documentation used to be outdated... I did a huge effort to make it in sync with the code, but it may still have issues 		[11:10]
marc|gonzalezmchehab: I see that you have a recurrent with/which snafoo ;-)
I'm looking into it right now 		[11:11]
mchehabI recently added a set of kAPI documents - but still too spartan [11:11]
marc|gonzalezmchehab: as a beginner, I feel that what's missing is some kind of "first draft driver skeleton" [11:12]
mchehabyeah I tend to write with instead of which... need to police myself to avoid such mistakes
marc|gonzalez: feel free to write one :-) 		[11:12]
marc|gonzalezthat's true of most drivers, sadly (pcie, irq, dma, are those I worked with) [11:13]
mchehabour desire is to have something like vivid for DVB... a driver that would work like a real driver, except that it would do everything in software
that would help having a dvb compliance tool 		[11:13]
marc|gonzalezreceive the TS in a buffer, then SW process it? [11:14]
mchehab(but nobody ever found the time to write it)
actually, generate some TS internally in software 		[11:14]
marc|gonzalezOh, I did that back in 2006 [11:14]
mchehabvivid has an image generator module that could be used [11:14]
marc|gonzalezMy knowledge of DVB and TS has faded a lot since then :-( [11:15]
mchehab(it doesn't produce MPEG data, though - just uncompressed one)
I guess that, in thesis, it could be possible to use uncompressed video inside a TS, but the best would be to have MPEG or MPEG2 video inside the TS) 		[11:15]
marc|gonzalezWe can generate NULL packets ... but that might not help testing for compliance?
since we want to test demux... 		[11:16]
mchehabNULL packets could be an start
we do have skeleton drivers for the frontend 		[11:16]
marc|gonzalezI'm using a si2168 as a frontend, so I'm hopefully covered for that ;-) [11:17]
mchehab(too basic, and probably not functional - but still...) [11:17]
marc|gonzalezI just need to attach, then register, then wire the SW demux
and hopefully see some TS packets coming in 		[11:17]
mchehabis it an USB driver or a platform one? [11:18]
marc|gonzalezplatform
qcom soc
TSIF/TSPP engine 		[11:18]
mchehabok [11:19]
marc|gonzalezthere is an existing driver downstream (v4.4) I use as reference (since I have no doc for it) [11:19]
mchehabprobably with lots of hacks and bad practices :-p
(as almost all downstream drivers) 		[11:20]
marc|gonzalez5000 lines, sweet baby jesus
Considering I'm a newb on the linux DVB API, it's kind of hard to wrap my head around the downstream driver + new API 		[11:20]
mchehabI bet they're re-implementing a lot of things that the DVB core already does [11:21]
marc|gonzalezI'll try to break it down, then build up from scratch [11:21]
mchehabthe entire SW demuxing is already covered by the core... all you need to do is to call a single function
dvb_dmx_swfilter() 		[11:21]
marc|gonzalezthanks [11:23]
mchehabthere are a few variants of this function
one of them checks for start of frames, another one assumes that, on every 188 bytes, a start of frame will be there as the first byte of the block...
and another one for 204 bytes
but, anyway, a demux driver is really easy to implement...
all it takes is to implement the DMA handler, and make it call dvb_dmx_swfilter() 		[11:24]
marc|gonzalezyou give me hope!
;-) 		[11:26]
mchehab(and do some kAPI initialization) [11:26]
marc|gonzalezthe DMA is an issue because qcom DMA is a mess
Thanks for the insight, I'll get to it right away (and send you the trivial typo fixes) 		[11:26]
mchehabwell, it could work without DMA
whatever works on your device. The code just needs you to fill a buffer with the data 		[11:27]
marc|gonzalezmchehab: is there a way to tell the front-end driver "just fill this buffer I'm giving you" ? [11:31]
mchehabit is not up to the frontend driver to fill a buffer
the frontend is only responsible for the tuning part
the hardware of a frontend provides the TS via either a serial or a parallel set of pins...
with are connected to the block that will handle the TS
the demux driver is meant to control such block
while the frontend drivers are meant to control the tuner part
as you said that the qcom hardware you're using has a si2168 frontend, if they didn't integrated the SI as an IP block...
the qcom SoC is probably receiving the TS on one (or multiple) GPIO ports
your driver needs to implement the logic that will read the data from the GPIO pin(s), filling the buffer. Then, call dvb_dmx_swfilter() 		[11:33]
LoggDoes Kaffeine have a way to stream Digital TV over the network? [11:47]
mchehabnot yet [11:48]
LoggWhat's the best way to accomplish that? [11:49]
mchehabI actually started implementing this, but didn't have time to finish [11:49]
Loggdarn lol.
ball game on tonight, I want to put it downstairs 		[11:49]
marc|gonzaleznba finals? [11:49]
Loggyeah. I want Canada to win [11:50]
marc|gonzalez"blame canada" [11:50]
Loggwell... Kaffeine I think uses libvlc, so, maybe there's a way to finagle it with VLC, which does support network streaming, but if there's a less hacky way to do it, I'd really like to hear it [11:51]
mchehabyou could do that using dvbv5-remote [11:51]
Loggnot sure it's packaged in Debian. dvb-tools only gives me -daemon, -scan, and -zap [11:53]
mchehab(that's the approach I wrote)
but then you'll need to use a command line tool to watch
dvbv5-zap
with dvbv5-zap, it should work, you you'll need to do some tests
https://linuxtv.org/wiki/index.php/Dvbv5-zap is your friend
ah, dvbv5-daemon
that's the one that should run at the machine you have the DVB/ATSC stick
dvbv5-zap has a command line argument to connect to it
it will write the data on a local file
and something like vlc will play such file
you could also run dvbv5-zap directly at the machine with the ATSC stick
(on that case, you won't need dvbv5-daemon)
and make it send the data via ssh
to the machine you're connecting to the TV set
dvbv5-zap -c dvb_channel.conf "trilhas sonoras" -r
mplayer -cache 800 /dev/dvb/adapter0/dvr0
(that's on a local machine)
you could run "dvbv5-zap -r" on one machine...
and do something like:
cat /dev/dvb/adapter0/dvr0 | ssh tvset_machine "mplayer -"
(or a variant of that)
it is hacky, in the sense that you won't have a way to switch channels - and if something gets wrong with the network, the ssh tunnel may end, but as you're just watching an specific program, this could work 		[11:54]
LoggYeah, I'm looking at dvbv5-zap now. I think I need to copy my channel scan from kaffeine or something because "dvbv5-zap -r" is asking f or <channel name> [12:03]
mchehabit is easier to just run dvbv5-scan
in order to generate a file with the channels on it
for dvbv5-scan to run, you'll need it with a file from dtv-scan-tables 		[12:03]
LoggI see, yeah, I was wondering what dvbv5-scan was asking for.. [12:04]
mchehablike
dvbv5-scan dtv-scan-tables/atsc/us-NTSC-center-frequencies
(the actual file depends on where you are)
the file basically has something like:
[CHANNEL]
DELIVERY_SYSTEM = ATSC
FREQUENCY = 69028615
MODULATION = VSB/8
INVERSION = AUTO 		[12:05]
LoggThat's the right one for me, just I think I need to find that file online, because it's saying "No such file or directory", so, maybe from here https://git.linuxtv.org//dtv-scan-tables.git [12:06]
mchehabhttps://git.linuxtv.org/dtv-scan-tables.git/plain/atsc/us-ATSC-center-frequencies-8VSB [12:06]
Loggand it's off to the races lol [12:07]
mchehabor some other file from https://git.linuxtv.org/dtv-scan-tables.git/tree/atsc [12:08]
marc|gonzalezmchehab: what is the notion of "inversion" ? [12:08]
Loggwhatever it is doesn't work for me
Scanning frequency #3 69028615
ERROR command INVERSION (6) not found during store
ERROR command INVERSION (6) not found during store 		[12:08]
mchehabmarc|gonzalez: no need to take care of it [12:08]
Loggseems to be working without INVERSION [12:08]
mchehabLogg: just ignore inversion errors/warnings
some channels have the spectrum inverted 		[12:09]
marc|gonzalezmchehab: my HW has an explicit GPIO to enable/disable inversion [12:09]
mchehabthe core handles it automatically [12:09]
Loggi c [12:09]
marc|gonzalezmchehab: like instead of 0x47, it's 0xb8 ? all bits inverted? [12:10]
mchehabno
well, I dunno what this GPIO controls...
but inversion is spectrum inversion 		[12:10]
marc|gonzalezOK, another thing to look into then. [12:10]
mchehabbasically, the frequencies are inverted
it is a transmission parameter
(yet, the GPIO could indeed be inverting the bits)
that's a different thing
marc|gonzalez: this is a typical ATSC spectrum: http://www.hdtvprimer.com/ANTENNAS/spectrum.gif

inversion would mean that the image was inverted... e. g. instead of ranging from 0 to 6 MHz, it would be ranging from -6MHz to 0 		[12:10]
marc|gonzalezOK thanks, I will pay attention when I get to that part [12:15]
mchehabI guess ATSC doesn't use inversion; only DVB
nowadays, most devices auto-detect it 		[12:16]
marc|gonzalezmchehab: if I do SW filtering, I'm not even supposed to call dvb_dmx_init() ? [12:27]
......... (idle for 41mn)
Logg@mchehab, it's working. :-) Thanks for your detailed instructions. Don't give up on the "click to stream" feature of Kaffeine, it would be a great one. [13:08]
.............................................. (idle for 3h46mn)
***_abbenormal has quit IRC (Quit: Leaving) [16:54]
↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)