Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> General pcHDTV topics -> tssave: Utility to save TS files in minute-long chunks
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
tssave: Utility to save TS files in minute-long chunks
PostPosted: Mon Dec 01, 2003 7:11 pm Reply with quote
koreth
 
Joined: 04 Nov 2003
Posts: 8




Here's a utility, tssave, to which you can pipe the output of the getatsc utility. It takes as arguments a base filename and a duration in minutes, e.g.

Code:
getatsc /dev/dtv 42 | tssave /home/hdtv/myshow/file 60


to record a 60-minute program into /home/hdtv/myshow/file.0000.ts etc. You can use it from cron jobs if you like.

tssave uses a shared-memory message-passing scheme internally so that temporary slowdowns in disk I/O won't cause getatsc to drop any data. Think of it as Walkman-style skip protection for your HDTV recordings -- it can get up to 10 seconds behind before it starts dropping data.

Why I wrote this: I use my HD-2000 to record shows onto a fileserver, and a Samba share to play back the recordings on a Windows machine using a Hipix DTV-200 card. The Hipix expects its recordings to be in a directory full of numbered .ts files (file.0001.ts, file.0002.ts, etc.) usually with one file per minute of video.
View user's profile Send private message
PostPosted: Sun Dec 07, 2003 6:35 pm Reply with quote
koreth
 
Joined: 04 Nov 2003
Posts: 8




I have updated tssave to not require getatsc, which makes the recording process a little more efficient. To record an hourlong show on channel 42:
Code:
tssave -c 42 /home/hdtv/myshow/file 60

See the link in the first message for the source. If you don't specify a channel number, it records from standard input as before. (But still get the new version since there were a couple bugs in the old one that resulted in file corruption -- oops!)
View user's profile Send private message
Re: tssave: Utility to save TS files in minute-long chunks
PostPosted: Wed Dec 10, 2003 6:36 am Reply with quote
CoffeeBreath
 
Joined: 05 Oct 2003
Posts: 9
Location: NE Mass




koreth wrote:
Why I wrote this: I use my HD-2000 to record shows onto a fileserver, and a Samba share to play back the recordings on a Windows machine using a Hipix DTV-200 card. The Hipix expects its recordings to be in a directory full of numbered .ts files (file.0001.ts, file.0002.ts, etc.) usually with one file per minute of video.


Note that the Hipix doesn't actually *require* the .ts files to be in 1-minute chunks -- it will happily play back hour-long single-file recordings I've made with my pchdtv card.

The skip prevention sounds pretty cool.

Steve.
View user's profile Send private message
Problems with tssave?
PostPosted: Wed Feb 25, 2004 10:16 am Reply with quote
koreth
 
Joined: 04 Nov 2003
Posts: 8




On another thread someone reported problems with tssave's recording lengths being inconsistent. If you've seen that problem -- or any other problem, for that matter -- please post here with as much detail as you know. I'd like to fix the program if it's not working properly in some circumstances. (It's working fine for me and I was quite surprised to see the mention of that problem.) Please make sure you're using the second version of the code, as linked in the top message; the initial release did have some pretty serious issues.
View user's profile Send private message
Re: Problems with tssave?
PostPosted: Fri Feb 27, 2004 6:47 pm Reply with quote
Ulmo
 
Joined: 06 Nov 2003
Posts: 95
Location: Aptos,CA,USA




I had trouble with it before. For some reason, I can't reproduce it now. One theory I have I cannot test without disturbing my antenna.

SDTV 704x480 4:3 for NTSC output, good signal:
Signal: 087 (051) #############################
Code:
$ ./tssave -c 13 -i 0 -d /dev/video0 -v /v/manual/now 3 &
[... output ...]
$ ls -l --full-time /v/manual/*ts
-rw-r--r--   145444320 2004-02-27 17:41:32.185677852 -0800 /v/manual/now.0000.ts
-rw-r--r--   145444320 2004-02-27 17:42:32.189549126 -0800 /v/manual/now.0001.ts
-rw-r--r--   143020248 2004-02-27 17:43:31.180597779 -0800 /v/manual/now.0002.ts
$
[mencoder output for now.0001.ts:]
[...]
Pos:  59.9s   1789f (100%) 193fps Trem:   0min 108mb  A-V:-0.025 [14956:192]
Writing AVI index...
Fixing AVI header...

Video stream: 14956.466 kbit/s  (1869558 bps)  size: 111911865 bytes  59.860 secs  1789 frames

Audio stream:  192.000 kbit/s  (24000 bps)  size: 1436688 bytes  59.862 secs
$


Another channel:

HDTV 1920x1088 16:9 (actually a 4:3 put inside 16:9 format), decent signal:
Signal: 091 (053) ##############################
Code:
$ ls -l --full-time hdtv.000*
-rw-r--r--    1 145444320 2004-02-27 17:56:55.573491962 -0800 hdtv.0000.ts
-rw-r--r--    1 145444320 2004-02-27 17:57:55.577454517 -0800 hdtv.0001.ts
-rw-r--r--    1 143020248 2004-02-27 17:58:54.568591615 -0800 hdtv.0002.ts
$ mencoder hdtv.0000.ts -o /dev/null -oac copy -ovc copy
[...]
Pos:  60.2s   1781f (100%) 430fps Trem:   0min  94mb  A-V:-0.045 [12723:384]
Writing AVI index...
Fixing AVI header...

Video stream: 12723.166 kbit/s  (1590395 bps)  size: 95784912 bytes  60.227 secs  1781 frames

Audio stream:  384.000 kbit/s  (48000 bps)  size: 2873056 bytes  59.855 secs
That's OK.

Next is going to be a dual stream channel, with both HDTV and SDTV, with worst signal:
Signal: 087 (-26) #############################
Code:
$ tssave -c 12 -i 0 -d /dev/video0 -v /v/manual/two 3 &
$ ls -l --full-time two*
-rw-r--r--    1 145444320 2004-02-27 18:03:27.487025567 -0800 two.0000.ts
-rw-r--r--    1 145444320 2004-02-27 18:04:27.491021060 -0800 two.0001.ts
-rw-r--r--    1 143020248 2004-02-27 18:05:26.482190072 -0800 two.0002.ts
$
[decode HDTV stream:]
$ mencoder two.0001.ts -tsprog 4 -o /dev/null -ovc copy -oac copy
[...]
Pos:  60.3s   1787f (100%) 525fps Trem:   0min  94mb  A-V:-0.058 [12746:384]
Writing AVI index...
Fixing AVI header...

Video stream: 12746.958 kbit/s  (1593369 bps)  size: 96017194 bytes  60.260 secs  1787 frames

Audio stream:  384.000 kbit/s  (48000 bps)  size: 2873856 bytes  59.872 secs
$


I don't know why it's working today. Perhaps I had lower signal quality when it didn't work right. It could also have been bugs in the driver that were fixed when jiffies were fixed. The signal quality for the last one was too high for today, however it was lower for a few days recently, and causing more trouble.
View user's profile Send private message Send e-mail
PostPosted: Fri Feb 27, 2004 7:38 pm Reply with quote
Ulmo
 
Joined: 06 Nov 2003
Posts: 95
Location: Aptos,CA,USA




Quoted text from other thread problem first mentioned:

koreth wrote:
Code:

...
        time(&end_time);
        end_time += seconds - 1;

        while (time(NULL) < end_time &&
               (bytesread = full_read(input_fd, buffer + offset, bytes_to_read)) > 0)
        {
...


That should result in a very precise end time. Okay, maybe off by up to 1 second depending on how long it took to start up, but that level of uncertainty is going to be there no matter what if your system is heavily loaded.

But I'm perfectly willing to believe there's a bug in there somewhere. Details, please!


No. I know when I tested it at first, it did not work right. Now it works right. Furthermore, I was also reading this when I made some assumptions about the whole code while diagnosing my initial error:
Code:
#define CHUNK_SIZE 2424072      /* 1 second's worth of TS data */
#define CHUNKS_IN_BUFFER 10
#define CHUNKS_PER_FILE 60

#define BUFFER_SIZE (CHUNK_SIZE * CHUNKS_IN_BUFFER)
#define FILE_SIZE (CHUNK_SIZE * CHUNKS_PER_FILE)


Now I see your loop. Now that I see it, I have confidence in it too. I wonder what happened! Perhaps I had a loose ntpdate -b process grabbing time from very corrupt places, and looping? No ... can't be. I just don't know. Perhaps a reiserfs bug? Very curious! Now I'm using linux kernel 2.6.3-bk9 with my draft 3n patch (identical to 3m except with twice the buffer space in the driver), and having no problem.


P.S., I included your program (with input selection modification) in my hd2000 tools (at ftp://DeepThought.Armory.Com/pub/user/ulmo/hd2000/tools/).
View user's profile Send private message Send e-mail
transport stream cutter
PostPosted: Sat Feb 28, 2004 4:22 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




Sounds like what you need is a transport stream cutter.

Mine does a wonderful job of cutting commercials, even if it is rather tedious to keep the stopwatch handy. There is the odd cut that doesn't play right and I have go to back a second or two. I suspect I should be cutting on adaptation headers.

It would be nice if xine-hd would report the stream time, or any time at all for that matter. Frame rate would be nice, too, but not as useful as some kind of timer

I've found I get 20Mbits no matter what, even out of tune.

Just 20Mbits of trash instead of 20Mbits of good packets,.

As long as I keep the cutters measurement method the same each time, I get consistent results since I work with static streams generated by my pchdtvr program.

-ink

Yeah I know, lovely usage, but where's the code?
Still in testing, soon to be posted, along with pchdtvr

/*
tsc.c by <inkling@nop.org>
transport stream cutter

usage:
tsc filein.ts SCALE START END [fileout.ts]

open filein, open fileout or stderr if not given,
reads packets until START reached, includes START.
writes packets until END reached, includes END.

SCALE:
p packets (one packet is 188 bytes)
a adaptation headers (unknown rate, just count em)
s for seconds (13298 packets per second)
m for minutes (797872 packets per minute)
*/
View user's profile Send private message
tssave: Utility to save TS files in minute-long chunks
  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 1  

  
  
 Post new topic  This topic is locked: you cannot edit posts or make replies.  


Powered by phpBB © 2001-2003 phpBB Group
Theme created by Vjacheslav Trushkin