Hi all,
A few weeks ago I took a look at kaa.record because I was thinking of
adding IVTV support to it. I got looking at the code and had some
second thoughts, at least until I raise them on the list. Since we're
going to be working on the tv/recording area again soon now is the time
to raise these issues.
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. For those who don't know much about kaa.record and would
like to reference the things I'm talking about, you can go to:
http://cvs.sourceforge.net/viewcvs.py/freevo/kaa/record/
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.
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.
Actually perhaps the only thing the output plugins should care about
receiving is raw data (from an optional remuxer plugin). 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).
Another advantage of moving DVB/MPEG/remux code out of any output
plugins is that this code won't have to be copied into any new plugins.
So, all this is going through my head and is making me wonder if we want
to be doing all this 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. We already
have programs to deal with DVB, IVTV, and V4l inputs. 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.
Other ideas:
What about making a kaa.mencoder that's similar to kaa.mplayer? That
way we'll still have the flexibility of mencoder's options. I know that
one reason we'd like to control the input ourselves is that we'd like to
do timeshifting using chunked files. It may be easy to add chunked file
output to mencoder or we could pipe an output stream into our output
plugin for chunked output.
RFC,
-Rob
--
-------------------------------------------------------
Rob Shortt | http://tvcentric.com | Freevo
[EMAIL PROTECTED] | http://freevo.sf.net | Free your TV
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Freevo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
