pcHDTV :: View topic - Making a DVD from the .ts stream Captured from getatsc

rab45

OK, I have everything setup and running with the HD3000. I installed the NVIDIA binary driver (I'm using the 32-bit FC2 on an Athlon 64 system) so that viewing and playback are very smooth.

Is there a simple process for taking the .ts file from getatsc and making a DVD so I can play it back on most generic DVD players? I have K3B - can I use that? Do I have to do any conversions?

Rick B.

decourl

To burn pcHDTV-captured content to DVD in standard format: (rev. 2)

I have edited this post to reflect:

I hope to flesh out the script to respect a bunch of different run-time
options (ie: use brand-X encoder instead of brand-Y encoder;
use format A instead of format B; target PAL instead of NTSC;
letterbox instead of using anamorphic 16:9; etc). For the mean time,
here is the basic proof of concept script that demonstrates exactly what
needs to be done for the basic case.

The biggest feature of this script is the use of named pipes which
eliminates an entire generation of lossy encoding/decoding (ie mpeg4
or mjpeg) which would otherwise be necessary given the size of raw
video).

johnclubvec

Dear Lincoln,

I've tried out your code and I've written to say that I'm most impressed with your knowledge of the intricacies of this, and the result. I did have to reverse a few lines in your script to get it to work, however. Namely, I had to "cat stream.yuv" AFTER everything else; that is, I needed a completed stream.yuv before using mpeg2enc on it. That was the main thing: mencoder & + mplayer & were fine, then ffmpeg, then mpeg2enc.

The completed video quality was really high, and the .mpg file was about 1/5 the size of the original .ts file. On the downside, on my 2.53 Ghz P4, 5 minutes of .ts took about 23 minutes to process, AND the intermediate file (stream.yuv) was about 6 times the size of the original. Moral: you need gobs of time, and PLENTY of disk space.

Memo to anyone interested: in Lincoln's line:

-vf scale=720:480:1:0:0.00:0.75

the "1" appears to set the "Interlaced" flag; if you don't have interlaced content (FOX, ABC, I believe are both 720p), then you can change it to "0" (zero).

Thanks again, Lincoln!

johnclubvec

Update:

Said "What the heck" and tried it with a full-hour .ts file.

Report:

There are definitely economies of scale.
Total processing time, .ts to .mpg file: 47 min.
original .ts file: 7197 mb (1080i, 1 hr length, 1 stream total)
stream.yuv: 9664 mb
mpg file: 243 mb (yes, that's correct!)

Downside: about the last minute of the file was not processed.

Guest

johnclubvec

Dear "Guest,"

re bitrate -- I don't know; you'll have to look at Lincoln's code. For what it's worth, mpeg2enc reports this on processing the file:

INFO: [mpeg2enc] Bitrate: 7500 KBit/s

and in man mpeg2enc re "--format 8":

"Bit-rate defaults to 7500kbps, buffer sizes to the maximum permitted by the DVD specification."

ceenvee703

pfile

so one thing about this flow: why convert the audio to PCM and then back to AC3? i think AC3 is the only legal audio format for ATSC (maybe, but every show i've recorded has AC3 audio), and AC3 is a legal DVD audio format, why not just dump the audio with mplayer to a separate file, and then just skip the ffmpeg step, and pass the original AC3 audio to the DVD authoring tool?

mplayer -dumpaudio will dump the audio stream.

edit: also when using mplayer to dump the audio/video, i think you want to use -benchmark so it plays it as fast as it possibly can.

Guest

Better men than I have the answers to the questions raised (and I hope you do); my bit, it seems, is to try the script out and report the results. The idea of using lossless decoding and named pipes is attractive. There seem to be problems, particularly once "real" .ts streams of sizable length are processed; what the problems are and why they are, and how they can be fixed, is beyond my knowledge, but hopefully not beyond everyone's.

Followup to my above comments:

I am definitely getting a "broken pipe" error re mencoder on 1-hour files. Somewhere around minute 11-16, mencoder stops issuing messages (but apparently continues to do something at least occasionally, since I at least once obtained an almost-complete .mpg file). On another occasion the break was irretrievable and things just stopped.

I also got a very strange error once, which I could reproduce consistently with that particular .ts file. Everything began fine, but after a few minutes of watching the resulting .mpg file, I began to see a different video stream than the one I viewed when watching the original stream. (Yes, I examined the VID prior to running the script and correctly told it whcih to use). Maybe the VID changes somewhere? I don't know, I'm just reporting.

Best of luck to the wiser heads in this discussion.

johnclubvec

johnclubvec (me) is the author of the previous post:I thought for sure that I had logged in.... I am logged in now; hopefully this will "take."
Further update: the mencoder pipe is definitely breaking on longer files.; even my first 1-hour effort, which I had reported as successful but for the last minute, had broken long before the end. On a cursory look-see, I had misidentified the last scene I viewed in the resulting .mpg file as the last scene in the show. I was wrong; what I saw was another scene considerably before the end which looked similar to the final scene in the show.

Guest

Because the AC3 stream is picked up off-the-air, it is often (in my experience)
subtly corrupt due to recovery errors. On the Internet, you check what you receive
for errors. and ask for retransmission if one is detected. On the receiving end of
an ATSC broadcast, you don't check for errors and can't request retransmission.

mplayer/mencoder is engineered to handle subtle errors in input files gracefully, so I believe it is a good idea to have mencoder freshly recode the stream in question.

I have seen some articles suggest using mencoder -oac copy for the first step
and then later using mplayer -dumpaudio (or some similar AC3 extraction technique)
for the second step. I'm not sure if this "copy" process is guaranteed to generate
standards-conforming programs or not. It is difficult to tell: mplayer is forgiving,
maybe our hardware DVD player is forgiving, but what about an arbitrary DVD player?

I am not saying that it won't work, I'm just pointing out that there might be an issue.

-Lincoln

Guest

It was intended (but erroneously not mentioned) that stream.yuv was also intended
to be a named pipe. That is, there would be a mkfifo stream.yuv with the other
mkfifo lines.

This will allow the script to work in the presented order, and will eliminate the need for
excessive disk space.

If you want a potentially faster process, you can first use mencoder to scale to
NTSC resolution and to produce an AVI containing mpeg4- or mjpeg-encoded video.

There are many avi2vob-style scripts out there that will automate the generation
of dvdauthor-ready MPEG2 programs given an arbitrary AVI file. I have found
that most rely upon a program called transcode. This would greatly simplify
the process, and would likely result in faster processing. By default, transcode
uses a faster MPEG2 encoder called ffmpeg rather than mpeg2enc.

I'm not sure about the broken pipe issue. If this issue can't be rectified, then the
idea of using lossless coding for the intermediate step quickly becomes quite
unworkable.

pfile

fair enough. my signal strengths are so high that i rarely get a corrupted recording. unless of course i have the dreaded buffer overflow Smile

Scott Larson

I receive one station at 98%. I would be getting a perfect stream from them.... except they send me a corrupt a52 packet every time they switch to local commercials. Heaven knows how they're doing this. ATSC data can get corrupted even before it gets transmitted although I'm sure it's not intentional.

Guest