FAQ Search Memberlist Usergroups Profile You have no new messages Log out [ viking1 ] Need help with Next generation sasc (sasc-ng) View next topic View previous topic Watch this topic for replies DVBN Forum Index » Linux DVB-Sat-TV Author Message NooneImportant SatGuru Joined: 12 Aug 2004 Posts: 525 Posted: Thu Jul 13, 2006 11:14 pm -------------------------------------------------------------------------------- Ok, well, I've been banging my head against the wall for quite a while, and I am just getting frustrated now. Overview: The code in question works something like this: when a blocking-read on the DVR device is requested: do { fill the ringbuffer; signal the decrypting thread; } while (bytes decrypted < bytes requested) return requested # of decrypted bytes from the ringbuffer (the code is quite a bit more complicated than that, but that is the high-level intent) The problem is that some applications rely on the dvb device returning data at the playback rate. So if we take too little or too much time in the above code, the app starves or overflows its own buffers. I have tried several different implementations to get a reliable ringbuffer to work, and have had little success. The code does work quite well if I don't use a ringbuffer and decrypt packets as we read them, however, this approach is very sensitive to the size of the read (if the app requests 100k bytes at a time, the delay in processing those bytes can be too long, and if the app requests < ~ 6k at a time, innefiency of FFdecsa goes way up) Basically, I would like to find a good programmer, familiar with C who can implement a reliable ringbuffer implementation for this situation, which can work with a wide range of hardware/input streams, and does not rely on careful tweaking of paramteres to get right. I've spent several days working on this, and I am reaching the end of my patience with this portion of the code. Note: I don't care about non-blocking reads at all. That implementation is trivial in comparison, and not causing an issue. I believe both myth and vdr use nonblocking reads, so this won't affect those apps. The code below has many known issues, and shouldn't be used for anything except addressing this problem. Specifically, (a) I have ripped out all nonblocking support, so it wouldn't work with vdr or myth as is, (b) the code can only support a single 'open' request on the frontend. Once you have tuned one time, you need to restart the userspace app, so it is completely useless for watchng anything, (c) there are still a few deadlock issues in the dvbloopback driver, (d) you need to be running at least a 2.6.15 kernel, (e) it is only for budget cards The operation I'm using to test is: start the userspace driver (sasc-ng) fetune to 19031 (CNNAV) mplayer /dev/adapter#/dvr0 The above works fine on NASA, and with the ringbuffer disabled, but is very marginal with the current ringbuffer code. how to use it: make module make insmod dvbloopback.ko ./sasc-ng -r -v ex: you have a budget card on adapter 0 the dvbloopback module creates a virtual adapter on adapter 1 ./sasc-ng -r 0 -v 1 the sc related files go into the 'test' directory (same files that sasc requires to run). There are no shared library files needed (sasc-ng is fully standalone). I am leaving this task for the time being and working on cleaning up the other issues so I can actually create a viable release, maybe next week. http://www.f-forge.com?d=bSwcntIOq8hrRKLzAa7B ffdecsa stuff is in dvblb_plugins/plugin_ffdecsa.c ring buffer is in dvbloopback/src/plugin_ringbuf.c NOTE: the above code is setup to not use the ringbuffer at all. To enable the ringbuffer (for what it is worth), disable the line in the makefile which says NO_RINGBUF mrgandalf SatGuru Joined: 01 Nov 2005 Posts: 514 Posted: Fri Jul 14, 2006 12:58 pm -------------------------------------------------------------------------------- I really wish I could help noone but my code would most likely be much worse than yours. I have a question though. Doesn't dvb_core implement a ringbuffer (although small) which could be borrowed from? I take it you probably need something more than a simple ringbuffer to handle all that you need? - Mark. NooneImportant SatGuru Joined: 12 Aug 2004 Posts: 525 Posted: Fri Jul 14, 2006 2:47 pm -------------------------------------------------------------------------------- mrgandalf wrote: I really wish I could help noone but my code would most likely be much worse than yours. I have a question though. Doesn't dvb_core implement a ringbuffer (although small) which could be borrowed from? I take it you probably need something more than a simple ringbuffer to handle all that you need? - Mark. Yeah it is more complicated than that. you end up with a head (where you write to), a tail (where you read from) and a decrypt-pointer (somewhere between head and tail which shows the last byte you decrypted). Without the decrypt ptr it is quite straight forward, but with it, things get much more complicated. the goal would be to always keep at least 5kb in the buffer decrypted, 10kb free and more than 6kb ready for decyption. However, you don't want to blobk if you aren't meeting those targets, you want the system set up to naturally maintain them, and those numbers only apply to a single SD stream. If you are capturing more than one channel (on the same transponder), or HD material, those numbers are quite different (except fir the 6k one, which is the sweet-spot for ffdecsa). If I make the buffer really small (<200k) the code bounces back and forth between full and empty at a rate which gives pretty smooth playback, but this isn't ideal, as ffdecsa is working on packets smaller than 6k most of teh time, and the numbers are tuned to a specific media (again, doesn't work for HD). If I make the buffer reasonably sized (2M) I need to hand-tune some of the constants to keep it working. The ideal solution is probably to implement a rate monitor and try to maintain the same outgoing rate as incoming, but this would be complicated, and require a high-precision timer to work well (SD material runs at ~400bytes/msec and average read sizes are 2k-4k so you need control to about 5 to 10msec (which is hard even in kernel space (as evidenced by the legacy switch code). If you were pulling audio-only,, reads would take 10x less time to occur, which would be unworkable) mrgandalf SatGuru Joined: 01 Nov 2005 Posts: 514 Posted: Fri Jul 14, 2006 3:22 pm -------------------------------------------------------------------------------- NooneImportant wrote: Yeah it is more complicated than that. you end up with a head (where you write to), a tail (where you read from) and a decrypt-pointer (somewhere between head and tail which shows the last byte you decrypted). Without the decrypt ptr it is quite straight forward, but with it, things get much more complicated. the goal would be to always keep at least 5kb in the buffer decrypted, 10kb free and more than 6kb ready for decyption. However, you don't want to blobk if you aren't meeting those targets, you want the system set up to naturally maintain them, and those numbers only apply to a single SD stream. If you are capturing more than one channel (on the same transponder), or HD material, those numbers are quite different (except fir the 6k one, which is the sweet-spot for ffdecsa). If I make the buffer really small (<200k) the code bounces back and forth between full and empty at a rate which gives pretty smooth playback, but this isn't ideal, as ffdecsa is working on packets smaller than 6k most of teh time, and the numbers are tuned to a specific media (again, doesn't work for HD). If I make the buffer reasonably sized (2M) I need to hand-tune some of the constants to keep it working. The ideal solution is probably to implement a rate monitor and try to maintain the same outgoing rate as incoming, but this would be complicated, and require a high-precision timer to work well (SD material runs at ~400bytes/msec and average read sizes are 2k-4k so you need control to about 5 to 10msec (which is hard even in kernel space (as evidenced by the legacy switch code). If you were pulling audio-only,, reads would take 10x less time to occur, which would be unworkable) The only simple way I can think to match outgoing with incoming is to read the source non-blocking and when there's nothing to read then block on out-going. However, I would suppose if the rate changes then your outgoing rate change will reflect on slightly newer data than what's being read by the program. You'd almost have to embed block points in the buffer and block outgoing based on those points. Hope I'm not way off base here. - Mark. Droopdude SatGuru Joined: 01 Mar 2004 Posts: 227 Posted: Fri Jul 14, 2006 4:12 pm -------------------------------------------------------------------------------- I'm not sure I completey understand the issue, nor the terminology, but what about implementing two rings. One for reading the stream, and an interlocking/overlapping ring that is used for decrypting and outputing to the display device. The rings could be sychronized, the interlock/overlap could be designed to a fixed size and the varying packet sizes/rates could be padded between the rings so that the second ring always had a uniform packet size. Or, the rings could be unsynchronized so that the varying packet sizes/rates could be compensated by the speed of the second ring. Or maybe use three rings. One for capture, one for decrypt, and one for output. Also, the rings could have parallel tracks for multiple/simultaneous streams from the same transponder. Although the analogy is incorrect, think of an old 8 track tape cartridge. Just my thoughts. Droopdude. _________________ Droopdude Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First DVBN Forum Index » Linux DVB-Sat-TV Jump to: Select a forum Announcements----------------Forum Announcements/InfoTip: If you cannot see all of our forums, u ain't logged in! Satellite data services----------------Casablanca/Sat@OnceInternet Via Satellite DVB in North America----------------DVB SoftwareHDTV HardwareHDTV SoftwareInternet Via SatelliteSatellite in North AmericaSection nord-americaine en francais Standards----------------DVB-C (Digital Cable)DVB-S (Digital Satellite)DVB-T (Digital Terrestrial) Hardware----------------Dishes/Antenna'sHDTV Hardware (Europe)SkyStar-1 / TT-CompatibleSkyStar-2Twinhan DVB Cards Software----------------Alt-DVBAudiorip Plugin (Part of DVBN)Audio/video creation & masteringCardSharingCapiDevelopmentDVB Control (Part of DVBN)DVB Core, MyTheatreDVB DreamDVB eXtremeDvbTnEmuNationFreedecHispaDVBLinux DVB-Sat-TVMultidec 8.X/9.3New Users << <