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! However, I've also been using transcode to work with the output of dvbstream and have run into problems. I'm not the first one to have discovered this as recent postings to the transcode-users mailing list reveal. Finally, I record TV using a mixture of at jobs and the -n parameter to dvbstream. Yuck! 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" Getting it to start at or in a specific time: dvbstream --at 20:55 "BBC ONE" or dvbstream --in 15m "BBC ONE" Where you could say things like 1d2h3m4s for 1 day, 2 hours, 3 minutes and 4 seconds from now. Getting it to run for a specific time (improvement to -n): dvbstream --at 20:55 --for 40m "BBC ONE" Getting it to output to a file: dvbstream --at 20:55 --for 40m -o "AbsFabs.ts" "BBC ONE" 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. 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. Does this make sense to anyone? How many people use dvbstream rather than a more high-level application like VDR? Looking forward to people's responses, Jim. -- Jim Darby <jim@jimbocorp.uklinux.net> The Jimbo Corporation
Attachment:
signature.asc
Description: This is a digitally signed message part