On Fri, 2003-11-14 at 09:39, Dave Chapman wrote:
> The poll system call is already being used. What other fixes have you
> done? I would be very happy to see you commit them to CVS.
There we some subtle implementation issues. Would you like me to e-mail
you my revised code so you can sanity check it before CVS committing it?
The fixes fix things for me, but I'd like to check they don't break
things for others.
> What's wrong with that? at/cron already do their jobs well, so why add
> that functionality to dvbstream? How would you set up repeat recordings?
This is perhaps the key points. There's nothing I'm proposing to add to
dvbstream that isn't already done by programs like at, cron, sleep and
the other DVB tools.
What I was looking to do was to put them into something that, for me, is
more convenient. I know this breaks the fundamental Unix ``primitives
not solutions'' paradigm, but it is jolly useful.
For example, this very evening I managed to not record Absolutely
Fabulous because I got BBC Three's PID wrong.
> Or are you thinking about implementing dvbstream as a daemon, and using
> a VDR-style "timers.conf" to control the recordings?
Jamie mentioned ``command line VDR''. There's an element of that, but I
was thinking more single shot rather than a daemon that does repeats.
The features I mentioned are useful to me. I'm just testing the water to
see if they're worth doing for a wider audience.
> That would be useful - but it could also be implemented using a wrapper
> script. But don't remove the option to tune manually.
A tzap wrapper could well work. Someone else (sorry, I can't recall who)
mentioned a channels.conf parser and I think that's where we're heading.
> See above - I think cron acts as the perfect recording scheduler.
All true. However, I would find the above more convenient. It doesn't
stop you from using cron of course.
> > or dvbstream --in 15m "BBC ONE"
>
> You can replace that with:
>
> sleep 15m ; dvbstream "BBC ONE".
>
> Again, why duplicate the "sleep" command?
Again, convenience. I'd just like something with a little nicer
interface. Having said which, the --at interface is what I'd really
like. Other software I've written has had the --in as well just because
it was useful.
> I personally don't use the "-ps" option any more - I always record and
> archive programs in their original "TS" format. This includes all
> related PIDs (video, multiple audio, subtitles, teletext etc). This is
> the main reason I don't use VDR. Another advantage is that you can
> very easily cut the recordings - just use "dd bs=188" to cut on
> transport stream packet boundaries..
I have to admit I do pretty much the same. I'd like a better editor than
dd though.
> The latest mplayer can play TS files perfectly (both from files and from
> dvbstream RTP broadcasts), so there is no need to convert them to
> Program Streams in order to use them with mplayer.
True. However, I also like to store things, sometimes, as SVCDs. In this
case a ``clean'' MPEG-2 stream for transcode or occasionally directly
can be very useful.
> The area where work is needed is converting the files to DVD-compliant
> Program Streams for burning onto DVD. There are various ways to do this
> now, but none of them are perfect.
Very true. I've only recently discovered dvb-mplex and it seems to do
most of the job.
> Maybe this could be improved by updating the "ts2ps" part of dvbstream
> to use Marcus's very latest dvb-code mpegtools code. Do you get the
> same problems if you record to TS in dvbstream, and then use the
> standalone ts2ps to convert it to a program stream?
I've not had a lot of chance to experiment. It looks like the external
ts2ps provides better output, but the case is far from proven.
The main problem is outright rejection of the MPEG-2 PS by transcode
unless it is filtered by using dvb-mplex. I'd like something to do all
the good things.
> I have written (but not released - email me privately if interested) a
> "dvbdemux" program that will extract all the elementary streams from a
> transport stream (up to 8192 of them!). This includes a lot of error
> detection, and drops complete PES packets if they contain errors. These
> can then be used as the input to a multiplexor (e.g. dvb-mplex, tcmplex)
> in order to produce a program stream.
This sounds like the sort of thing I was looking for! Break it down,
discard errors then put it all back together again. I have a horrible
suspicion that subtle problem with A/V sync may creep in. Careful work
with the PTSs must be applied.
> The next step is to add error correction to this - i.e. producing a set
> of elementary streams that are error-free and remain in sync if there
> are errors in the transport stream. Luckily, I very rarely get
> recording errors, so I have no need for this - but I do plan to work in
> this area.
Surely a bad TS packet implies a bad PES and therefore ES? I can't see
how you can fill in the missing bits. Am I missing something?
> Yes - I use dvbstream daily for my recordings. But I use it with cron,
> so most of the functionality you describe is already available.
That's exactly what I currently use. I was just after something a little
more friendly.... Maybe I'm just getting lazy in my old age....
> One feature that is missing however, is the ability to separately record
> overlapping recordings from the same transponder. e.g.
>
> BBC1 - 9.30 to 10.00
> BBC2 - 9.45 to 10.30
>
> I currently do this by recording both channels for 1 hour, and then
> split (using my ts_filter) and cut (using dd) the recordings afterwards.
Spooky! Guess how I record Have I Got News for You (BBC1) and Abs Fabs
(BBC3) at the same time!
> But there is obviously a better way. Maybe your proposed "--at",
> "--in" and "--for" functions could be used to implement this.
Now that hadn't occurred to me. Its a VERY good thought though.
On Fri, 2003-11-14 at 10:09, John Knottenbelt wrote:
> One feature that I would really like to see (although I'm not sure that it
> belongs in dvbstream) is to know what are the names of the currently showing
> programs.
You're right it doesn't belong in dvbstream as such, but programs the
allow navigation of the meta-data (program information and the wealth of
other goodies lurking around) would be most welcome.
I'm not quite sure how they could share the same card though. For
example, can dvbstream record two PIDs while something else scans others
looking for the ``interesting bits?''
Maybe what's needed is a very pure version of dvbstream that just
streams all of a single multiplex and then a host of other programs
sniff the ether and pick out the PIDs of interest to them. This also
solves Dave's multiple recordings problem. For example:
dvbstream 8192& (I think this will broadcast all PIDs)
then run records that sniff the data and record the right things at the
right time.
Is this where dvb-net is heading? I've seen mention of IP addresses, but
haven't been following it as well as I maybe should have.
On Thu, 2003-11-13 at 22:15, Jamie Honan wrote:
> These are good ideas; they are heading in the direction of a command
> line vdr. It might be wise to see if anyone else is heading
> in this direction.
That was sort of my reason for posting. I was planning a dvbstream-like
thing but didn't want to repeat others work. Stand on people's
shoulders, not on their toes.
> It might be better to put a kind of 'front end' to transcode, rather
> than delete stuff. I don't know. Or make transcode more
> robust?
I'd really like to know what it is about some of the DVB output that so
offends transcode. I can't see a lot of alternatives to just ``chopping
out the bad bits''. Its just a matter of making clean cuts around the
damage thus allow faster bit-stream resynchronisation and hence reducing
the loss to the PES packet where the error occurred.
Or am I missing something here?
> One thing sort of along these lines, I have been looking at is
> putting a lot of the functionality of zap + scan into a library.
Sounds like an excellent idea.
> There is a library that almost does this : dvbsak. (cvs version is
> ahead of tarball : tarball easier to build).
dvbsak looks to be an excellent piece of code. Unfortunately, there
seems to be very little documentation on it. A great pity!
Like a lot of open source stuff in its early days we have a lot of good
code, but its badly fragmented among several programs. For example, the
zap family share functionality with dvbstream, dvbsak and undoubtedly
others. Later on in the chain there are a load of manipulation programs
written to perform various useful tasks.
The problem is to try and join them all together. For example, just
having one definitive library to read and write channels.conf files. A
library interface to programs like dvbstream and dvbsak. These would all
be really useful.
Other useful things would allow parsing of times so that I could say
1h10m rather than 4200.
To me, the Things I'd Really Like are the named tuning ("BBC ONE") and
the symbolic times (1h10 for 1 hour and 10 minutes).
Anyone else?
Jim.
--
Jim Darby <jim@jimbocorp.uklinux.net>
The Jimbo Corporation
Attachment:
signature.asc
Description: This is a digitally signed message part