Dirk Meyer wrote:
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).
Right, I forgot to mention that I was aware of that, and that's
understandable.
So yes, some stuff is dvb specific and will be changed at our big
hacking day.
Great.
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.
Excelent. It makes me happy that we're on the same page here thinking
the same things. This kind of architecture will let us do gome very
good things.
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.
I took some time to read the mplayer v4l code and also read some
ffmpeg/libavcodec/libavformat code and samples. It's times like this I
wish there was an actual set of v4l libraries. It might be easy to hook
up a basic set of bindings to the ffmpeg libraries or rip some code from
mplayer.
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.
Right, I guess the work I am referring to is the possability of building
a v4l/dsp capture - transcode app from scratch since there's lots of
issues to deal with (A/V sync, codec issues, etc). Presumably we'd
transcode the v4l/dsp input into a low compression format like mpeg1 or
nupplevideo (both are streamable).
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
Very true, it's time to take matter's into our own hands. :)
mplayer, you can't record two channels on the same bouquet. So yes,
Right, this is very important for DVB.
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.
We will also need some diseqc support. I can probably help there when I
set my satellite gear back up. I have also written code for retrieving
EPG data from DVB.
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.
Ok, definately dvb and ivtv first, which will give us a chance to work
out the interfaces and stuff.
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 was definately only talking about mencoder for v4l, since it would be
too much work for us to worry about it right now.
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.
It's too bad NFS sucks. :( Maybe the reading chunked files thing would
work over samba. I have had some success testing with UDP/RAW as well
(and will be willing to do more). HTTP might be a viable solution
because you can seek in HTTP streams.
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 agree on both items.
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.
Yes, I think you (we :)) can do this with a good day's concentration.
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
I have some ideas on these items too. We can discuss these in more
detail when you send the email.
This puts my concerns to rest, thanks. It would be cool if someone
stepped up with the v4l part. :)
-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
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
