Hi, Rob Shortt wrote: > There has been some effort put into the architecture of kaa.record in > that there's an output plugin layer, which is good. After a closer > look I noticed there seems to be a few DVBisms in places that I think > there shouldn't.
Yes. kaa.record is copied from our mbus based dvb recorder fred (http://cvs.sourceforge.net/viewcvs.py/freevo/fred). So yes, some stuff is dvb specific and will be changed at our big hacking day. > The filenames in general: this is more of a cosmetic thing. I like > the op_ prefix on the output plugin files, and some of the files are > prefixed by dvb. There are some files there that are also particular > to dvb: dmx.h, filter.h, filter.cc, frontend.h, remux.cc, remux.h, > tuner.cc, and tuner.h. It would be nice if these files were in a dvb/ > directory or prefixed by dvb_ so they not be confused by files for > other input types. For example v4l2 and ivtv devices will have a > different tuner object and their related files should be visibly > separate. Agreed. > There is also some logic in the output plugin layer that probably > belongs in a separate remuxer layer. Looking op_filewriter.* you will > see reference to pids and DVB/MPEG-TS. It looks like FT_MPEG is being > used for MPEG-TS and would break with other MPEG types. If we make an > IVTV device for kaa.record I would assume it be ok to say it uses > FT_MPEG, but IVTV provides a MPEG-PS (DVD format) stream which is > muxed audio+video - no pids. IVTV would have to use FT_RAW. Yes. We want to create a filter chain. device -> n * filter -> output So the remuxer is a filter you can add for dvb. More filters could be ad detection. > Actually perhaps the only thing the output plugins should care about > receiving is raw data (from an optional remuxer plugin). Yes. We have a stream to connect stuff. Device creates a stream, a filter creates a stream and write another. And output will terminate a stream to file or into the LAN. > Some input devices wouldn't care to use a remuxer (ivtv, since the > mpeg comes muxed) and some would have to use a more complicated > remuxer, like v4l because the audio must come from a dsp device and > both sets of data are in raw formats (and would also need to be > transcoded). I'm still not sure how to handle v4l. Maybe we could drop it for now and support live pause for dvb and ivtv. > So, all this is going through my head and is making me wonder if we > want to be doing all this work. :) It's not that much work. > Remember, our mottos have been "the right tool for the job" and "the > unix way" because we've chosen not to reinvent the wheel. Yes. > We already have programs to deal with DVB, IVTV, and V4l inputs. But none can do the live pause stuff. We waited long enough for xine or mplayer to support live pause. And if you use external apps like mplayer, you can't record two channels on the same bouquet. So yes, there are apps but they don't fit our needs. But we also don't reinvent the wheel. IIRC the tuner from kaa.record is from xine, the remuxer from VDR. > Adding IVTV support to kaa.record won't be a big deal but V4l input > is a whole new can of worms. Right now we have the flexibility of > mencoder. Maybe a hack could be to the mencoder to support v4l devices. I'm not sure. Again, I want to focus for dvb and ivtv for now. The v4l stuff should work with Freevo, but maybe not with live pause. > What about making a kaa.mencoder that's similar to kaa.mplayer? That > way we'll still have the flexibility of mencoder's options. It's too much for only receiving mpeg data for dvb or ivtv. Can can you access teletext from mencoder? Can you get the epg? Can you record two programs at once (e.g. two programs follwing each other, but both with padding)? IIRC, the answer is no to everything. > I know that one reason we'd like to control the input ourselves is > that we'd like to do timeshifting using chunked files. We don't even want that right now. It won't work with the recorder on a different machine and NFS between them. We are thinking of some sort of net communication (either UDP/RAW or TCP/HTTP -- or both). And it will be a pain to add that into mencoder, the mplayer people are not very open to strange suggestions like this. Again, creating kaa.record isn't that big deal. You only need to tune and write the mepg data to a stream. That's all. Maybe for v4l we need mplayer with mpeg output for that. I'm still very confident we can make it all work with one day extreme hacking. When Soenke and I have some free minutes the days, we will send a small proposal what we want to do. o How to support a network for recorder o How to get data without using NFS o Different ideas (Raw UDP/RTP/HTTP) o Where to use the chunk file system o How to sync EPG data o How to autoconfigure the system Dischi -- Boat: A hole in the water surrounded by wood.
pgpEescc4n1rq.pgp
Description: PGP signature
