 |
dtvstream 1.0b2 available |
 |
 Posted: Mon Apr 19, 2004 12:13 am |
 |
|
| pdicamillo |
|
|
| |
| Joined: 09 Mar 2004 |
| Posts: 68 |
| Location: Needham, MA |
|
|
 |
|
 |
|
Dtvstream is a tool for recording and processing the digital TV streams that come off a DTV tuner card such as the HD-2000. It can record or extract just a single program from the stream, creating a simple MPEG-2 transport stream file that works in many contexts, including with D-VHS devices. In some cases the program stream will use much less space than the full stream. Dtvstream can also display information about the stream, and can record for a specified amount of time.
I've finished a new version of dtvstream, 1.0b2. This version uses a separate thread to write to disk in order to eliminate loss of sync and buffer overruns when disk I/O is too slow. Also, it allocates output buffer space as necessary in order to keep up with data from the tuner. The new "-k" option sets an upper limit on how much memory will be used for the buffers. However, there should seldom be a need to use it. For disk input files the default is "-k 64".
There is also a new "-l" packet limit option for output. When a packet limit is specified, dtvstream will start a new file every time the limit is reached. The "-n" option can be used to specify the maximum number of files to create. The "nth" file will contain all remaining packets, regardless of the limit. For example, using "-l limit" with "-n 2" allows you to split a file at any arbitrary point (specified by the limit).
So far the only documentation for dtvstream is the help output from "dtvstream -h" or "dtvstream --help", which is also included in the readme file. However, I'll try to answer any questions that are posted here.
Here are links for the new version:
Linux version:
http://www.buzzlabs.com/~peter/dtvstream-linux-1.0b2.tar.gz
Mac OS X command line version (no tuner support):
http://www.buzzlabs.com/~peter/dtvstream-osx-1.0b2.tar.gz
Source code:
http://www.buzzlabs.com/~peter/dtvstream-source-1.0b2.tar.gz
There have been substantial changes to the code. Please let me know about any problems or bugs. |
|
|
|
|
|
|
big thanks! |
|
| Posted: Sun May 02, 2004 11:23 am |
|
|
| mk500 |
|
|
| |
| Joined: 11 Jan 2004 |
| Posts: 51 |
| Location: San Francisco, CA |
|
|
|
|
|
|
I just wanted to thank you for your excellent dtvstream tool. It's the one way I can reliably capture feeds from my card, and they look great. I wish Myth would use your code, as I still haven't been able to get Myth to reliably record on my system  Being able to choose the program is such a necessary feature, I'm surprised it's not more widely supported.
Anyway, huge thanks for the time you've put into this. |
|
|
|
|
| Posted: Thu Jun 10, 2004 5:44 pm |
|
|
| pdicamillo |
|
|
| |
| Joined: 09 Mar 2004 |
| Posts: 68 |
| Location: Needham, MA |
|
|
|
|
|
|
| I'm working on an updated version of dtvstream. The main addition I've made so far is a display of progress information. If you have any suggestions for changes or enhancements, post them here and I may be able to include them in the next version. |
|
|
|
|
|
|
|
|
| Posted: Fri Jun 11, 2004 9:08 pm |
|
|
| mk500 |
|
|
| |
| Joined: 11 Jan 2004 |
| Posts: 51 |
| Location: San Francisco, CA |
|
|
|
|
|
|
| pdicamillo wrote: | | I'm working on an updated version of dtvstream. The main addition I've made so far is a display of progress information. If you have any suggestions for changes or enhancements, post them here and I may be able to include them in the next version. |
Great! The status info will be very useful. I still think this tool is the best way to capture video from the hd-2000.
Here's a thought for a feature. I cron up jobs to record my TV shows, but it would be cool if there was some way to append a date at the end of the name automatically. That way if I cron a show to record daily, it will store new files each day. I haven't actually tried yet, but I'm assuming it currently will overwrite if you use the same name twice?
Thanks again for the great tool! |
|
|
|
|
|
|
|
|
| Posted: Fri Jun 11, 2004 9:28 pm |
|
|
| pdicamillo |
|
|
| |
| Joined: 09 Mar 2004 |
| Posts: 68 |
| Location: Needham, MA |
|
|
|
|
|
|
| mk500 wrote: | | Here's a thought for a feature. I cron up jobs to record my TV shows, but it would be cool if there was some way to append a date at the end of the name automatically. That way if I cron a show to record daily, it will store new files each day. I haven't actually tried yet, but I'm assuming it currently will overwrite if you use the same name twice? |
Unless you specify the -R option, dtvstream won't overwrite an existing file. It will print an error message and not write any file. I assume what you're asking for is a way to do daily or weekly recordings with cron, without having to change the cron job to get different file names each time. I can see how that would be useful and I'll see what I can do. |
|
|
|
|
|
|
|
|
| Posted: Sat Jun 12, 2004 7:33 pm |
|
|
| mk500 |
|
|
| |
| Joined: 11 Jan 2004 |
| Posts: 51 |
| Location: San Francisco, CA |
|
|
|
|
|
|
| pdicamillo wrote: | | mk500 wrote: | | Here's a thought for a feature. I cron up jobs to record my TV shows, but it would be cool if there was some way to append a date at the end of the name automatically. That way if I cron a show to record daily, it will store new files each day. I haven't actually tried yet, but I'm assuming it currently will overwrite if you use the same name twice? |
Unless you specify the -R option, dtvstream won't overwrite an existing file. It will print an error message and not write any file. I assume what you're asking for is a way to do daily or weekly recordings with cron, without having to change the cron job to get different file names each time. I can see how that would be useful and I'll see what I can do. |
Exactly. I was thinking the easiest thing would be for it to just append the date on the end of the file name if it sees the same file....instead of giving the error. That would also make it convenient to find a show from a particular date. Alternatively, you could just have a flag that would cause dtvstream to automatically append the date to every file name (actually, that sounds even better). |
|
|
|
|
|
|
|
|
| Posted: Sat Jun 12, 2004 7:47 pm |
|
|
| pdicamillo |
|
|
| |
| Joined: 09 Mar 2004 |
| Posts: 68 |
| Location: Needham, MA |
|
|
|
|
|
|
| mk500 wrote: | | Exactly. I was thinking the easiest thing would be for it to just append the date on the end of the file name if it sees the same file....instead of giving the error. That would also make it convenient to find a show from a particular date. Alternatively, you could just have a flag that would cause dtvstream to automatically append the date to every file name (actually, that sounds even better). |
How about if you could use %m, %d, and %y in file names, and they would be replaced by the current month, day, and year? |
|
|
|
|
|
|
|
|
| Posted: Mon Jun 14, 2004 2:28 pm |
|
|
| Scott Larson |
|
|
| |
| Joined: 15 Oct 2003 |
| Posts: 713 |
| Location: Portland, OR |
|
|
|
|
|
|
A marginally useful feature would be to save multiple subchannels to separate files. I would use it to save a station's HDTV stream to my main fast box while saving their SDTV stream to my laptop over the network since it's just barely fast enough to display SD. Right now I'm saving the raw stream and running dtvstream a couple of times to separate the streams afterwards. Only a couple of my local stations are multicasting HD and SD streams so I can't always do this but it's nice when I can.
Someday I'll understand transcode well enough to have it generate an SD version of the HD stream. |
|
|
|
|
|
|
|
|
| Posted: Mon Jun 14, 2004 3:49 pm |
|
|
| mk500 |
|
|
| |
| Joined: 11 Jan 2004 |
| Posts: 51 |
| Location: San Francisco, CA |
|
|
|
|
|
|
| pdicamillo wrote: | | mk500 wrote: | | Exactly. I was thinking the easiest thing would be for it to just append the date on the end of the file name if it sees the same file....instead of giving the error. That would also make it convenient to find a show from a particular date. Alternatively, you could just have a flag that would cause dtvstream to automatically append the date to every file name (actually, that sounds even better). |
How about if you could use %m, %d, and %y in file names, and they would be replaced by the current month, day, and year? |
Great solution. I guess that's why you're the developer |
|
|
|
|
| Posted: Wed Aug 04, 2004 4:33 pm |
|
|
| jpoet |
|
|
| |
| Joined: 11 Nov 2003 |
| Posts: 55 |
| Location: Albuquerque, NM |
|
|
|
|
|
|
Just want to say Thank You for a great tool. Helped me solve a problem I had figuring out what "program" I needed to designate in my MythTV setup.
John |
|
|
|
|
| Posted: Fri Sep 03, 2004 9:16 pm |
|
|
| kb7oeb |
|
|
| |
| Joined: 23 Mar 2004 |
| Posts: 32 |
|
|
|
|
|
|
|
| Another Thank You for writing this program |
|
|
|
|
| Posted: Sat Sep 04, 2004 9:58 pm |
|
|
| Scott Larson |
|
|
| |
| Joined: 15 Oct 2003 |
| Posts: 713 |
| Location: Portland, OR |
|
|
|
|
|
|
Here's another wacky feature request. Under rare conditions (probably bad data), dtvstream has crashed on me and the end of the program I was recording was lost.
One kludgy way to safeguard against this is to put in a signal handler for SIGSEGV, SIGBUS and the rest of the exception signals that will fork a new dtvstream process before exiting. The new process can continue writing to the old file and at worst there will be a small gap.
Of course no commercial product would ever have code like this!
[I should probably point out that was a joke!  ] |
|
|
|
|
|
|
|
|
| Posted: Sat Sep 04, 2004 10:08 pm |
|
|
| pdicamillo |
|
|
| |
| Joined: 09 Mar 2004 |
| Posts: 68 |
| Location: Needham, MA |
|
|
|
|
|
|
| Scott Larson wrote: | Here's another wacky feature request. Under rare conditions (probably bad data), dtvstream has crashed on me and the end of the program I was recording was lost.
One kludgy way to safeguard against this is to put in a signal handler for SIGSEGV, SIGBUS and the rest of the exception signals that will fork a new dtvstream process before exiting. The new process can continue writing to the old file and at worst there will be a small gap.
Of course no commercial product would ever have code like this!
[I should probably point out that was a joke! ] |
While the code that runs at the beginning and analyses the datastream might rarely crash from bad data, bad data shouldn't be a problem during recording. You should just get messages about losing sync and achieving it again. If you can get a crash log of some kind that shows where the code crashed, I'd be very interested in seeing that. |
|
|
|
|
|
|
|
|
| Posted: Sat Sep 04, 2004 10:15 pm |
|
|
| Scott Larson |
|
|
| |
| Joined: 15 Oct 2003 |
| Posts: 713 |
| Location: Portland, OR |
|
|
|
|
|
|
Like all good bugs, it doesn't happen very often. All my channels come in very strong and I rarely get any errors.
Are you saying that extracting a subchannel stream is completely foolproof? There's no way to flip a bit and have it think a buffer negative size or a zillion bytes or something like that? |
|
|
|
|
|
|
|
|
| Posted: Sat Sep 04, 2004 10:35 pm |
|
|
| pdicamillo |
|
|
| |
| Joined: 09 Mar 2004 |
| Posts: 68 |
| Location: Needham, MA |
|
|
|
|
|
|
| Scott Larson wrote: | Like all good bugs, it doesn't happen very often. All my channels come in very strong and I rarely get any errors.
Are you saying that extracting a subchannel stream is completely foolproof? There's no way to flip a bit and have it think a buffer negative size or a zillion bytes or something like that? |
What I was thinking of is that extracting a subchannel doesn't use the complex NIST parser code. After recording starts, all the code has to do is look at the packet id at a certain offset into the packet, and decide if it's an id that should be included in the output.
Here's another possibility. Unless you set a limit, dtvstream will use as much memory as necessary to buffer data from the tuner. If writing to disk proceeds normally, that shouldn't be a problem . But if a write took a very long time, longer than the disk drive itself would ever delay it, dtvstream could end up allocating all the memory available to it, and then it would probably crash. |
|
|
|
|
|
pcHDTV Forum Index -> General pcHDTV topics
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
All times are GMT - 7 Hours
Page 1 of 4
Goto page 1, 2, 3, 4 Next
|
|
|
|
|
