[linux-dvb] Re: dvbstream and transcode

[Dave Chapman <dave@dchapman.com>]

Jim Darby wrote:
> Hello all,
>
> I've been thinking about Dave Chapman's dvbstream for a while. Earlier
> on this year I put a few little fixes in (things like the use of poll
> system call). I didn't update the main software CVS because the fixes
> were quick work-arounds and I didn't want to put the code out.
>
> Bearing in mind that I haven't touched the code since May my guess is
> that it must be pretty stable. It's probably time to commit my changes
> to CVS and let the world laugh!
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.

> Finally, I record TV using a mixture of at jobs and the -n parameter to
> dvbstream. Yuck!
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?

Or are you thinking about implementing dvbstream as a daemon, and using 
a VDR-style "timers.conf" to control the recordings?

> So, what I'm think of is a new, improved dvbstream. It would pretty much
> be a re-write from scratch (let's call it 2.0) and would have a few new
> features.
>
> Tuning from tzap, to avoid all those tedious manual parameters. In other
> words something like:
>
> 	dvbstream "BBC ONE"
That would be useful - but it could also be implemented using a wrapper 
script.  But don't remove the option to tune manually.

> Getting it to start at or in a specific time:
>
> 	dvbstream --at 20:55 "BBC ONE"
See above - I think cron acts as the perfect recording scheduler.

> or	dvbstream --in 15m "BBC ONE"
You can replace that with:

sleep 15m ; dvbstream "BBC ONE".

Again, why duplicate the "sleep" command?

> Getting it to do TS to PS conversion (it does this now):
>
> 	dvbstream --at 20:55 --for 40m --ps -o "AbsFabs.mpeg" "BBC ONE"
>
> This last brings me onto the transcode problem.
>
> dvbstream provides us with a slice of program. This doesn't compare too
> favourably with a nice, properly formatted MPEG-2 file.
>
> So, what I was thinking was putting a ``MPEG cleaner'' into the PS
> generation. In other words finding out what annoys transcode about
> dvbstream output and fixing it.
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..

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.

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.

> Secondary to this is getting the new dvbstream to spot transmission
> errors and dropped packets and omitting them. At the moment dropped data
> seems to cause a TRUNCATED packet which causes an error. The reader then
> has to recover and skip the next correct packet to re-sync (because the
> next packet's header has already gone past). Better would be to omit the
> entire packet then bit-stream synchronisation would not be lost.
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 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.

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.

> Does this make sense to anyone? How many people use dvbstream rather
> than a more high-level application like VDR?
Yes - I use dvbstream daily for my recordings.  But I use it with cron, 
so most of the functionality you describe is already available.

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. 
   But there is obviously a better way.  Maybe your proposed "--at", 
"--in" and "--for" functions could be used to implement this.

Regards,

Dave.



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.