Date: Sat, 8 Apr 2000 21:56:29 -0400 From: Randall Hopper <aa8vb@ipass.net> To: just matt <matt@dqc.org> Cc: multimedia@FreeBSD.ORG Subject: Re: fxtv - NTSC taps Message-ID: <20000408215628.A7389@ipass.net> In-Reply-To: <Pine.BSO.4.21.0004081114040.25990-100000@dqc.org>; from matt@dqc.org on Sat, Apr 08, 2000 at 12:09:12PM -0700 References: <20000407180658.A1396@ipass.net> <Pine.BSO.4.21.0004081114040.25990-100000@dqc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
just matt:
|> |> That's what I'm after also. I found some Windows tools LSX/MPEG
|> |> converter. Free (30s play time limited) demo. Havn't yet found a
|> |> commandline tool for that.
|> |
|> |fxtv _uses_ a commandline ...
|
|...the instructions in the fxtv README help in encoding mpeg's.
|Unfortunately, you will probably run into other problems. I'll list some
|of the crazy inconsistencies I've experienced.
Great! Few folks that try it actually do provide feedback.
|If you experience the same or others, let me know, I might have found a
|solution.
Send any tips you have on and I'll add them to the README and maybe start
|and FAQ off the web page.
|First, mpeg's greater in length than 9 minutes or so become broken.
|By broken, I mean, 30 seconds or so of good video
|followed by the video(and audio if using mtv) streams freezing. Shorter
|videos (less than 9 minutes) don't seem to experience this problem. I've
|gotten around this by using an mpeg_cat utility and just recording clips 8
|minutes or shorter. It works but it's annoying.
Interesting. I've noticed that playback hangs have a lot to do with the
player, player version, and FreeBSD version as well. The hangs are worse
with 3.4R than 3.2R for instance, and some versions of MpegTV do much
better than others.
What I don't know is if there is some "audio-video synchronization cue"
that's supposed to be in the MPEG stream periodically that mplex doesn't
add (and maybe mpeg_cat does?)
You may know more than I about how the underlying MPEG stream is encoded.
|Second, when using the snd0 device, mpeg streams come out twice as big as
|when using pcm0. I've never solved this problem, but a vcd quality movie
|should be about 10 megabytes per minute of video, pcm0 keeps to that size,
|where as snd0 seems to take 20MB per minute. The video intermediates
|(before multiplexing) are the same size whichever deivce you use,...
|
|...but the audio streams are wildly different in size, and lead to the
|bloated mpegs. if you use snd0.
Odd. I wonder if one is stereo and one is mono, or something like that.
It'd be interesting to check. If you use mpg123 to play the generated
.mp2, do they both cite the same MPEG level, bit rate, sampling rate, and
number of channels? E.g.:
MPEG 1.0 layer II, 384 kbit/s, 44100 Hz stereo
|3rd, (This one's a new one), both pcm0 and the newpcm deal under 3.4 and
|4.0 respecively, don't seem to be able to record audio via fxtv
|anymore....I wish to god I could figure it out.
Hopefully someone that runs PCM can give you some tips. I run Voxware
since my card isn't supported under PCM.
|4th, I believe the video streams produced during this process are not
|exactly "up-to-code" as far as the mpeg-1 standard is concerned. Multiple
|win32 programs designed to edit mpeg-1 video streams scream about the
|bitrate being negative, and hardware mpeg-1 decoders generally won't play
|the mpeg's you make with this process. I think it's the video stream
|that's the problem, although a few months ago I thought it was the mplex
|program, but after using several multiplexing programs across different
|platforms, I'm convinced the problem is in the video stream.
That's interesting. So mpeg_encode may be the culprit. Is there another
MPEG video encoder for UNIX that you know of?
|only home-made mpeg's I've been able to play on my hardware mpeg-1
|decoders have been those produced with win32 encoders.
That's pretty cool (not that only win32 encoders work, but that you have
hardware mpeg decoders to work with).
|I've tried playing/editing the samples on the fxtv page with the same
|luck as those I've made, so I think this problem is probably pretty
|universal, and is probably at the heart of the first problem I described,
|about the streams freezing.
As a datapoint, when recording MPEG's I always leave it set to capture
44KHz 16-bit stereo. Is this what you do?
Also, a few more tips. When capturing using YUV (with NTSC), I've only
been able to get mpeg_encode to generate a valid video stream using the
320x240 resolution. I find that when capturing RGB 16bpp instead,
mpeg_encode will take just about any size.
Whether mpeg_encode is broken for reading odd-size YUV streams, or whether
fxtv just doesn't know how to write an odd-size YUV stream that mpeg_encode
will take, I don't know.
Another annoyance I've found is that mpeg_encode only supports encoding
with 24, 25, or 30fps. May be an MPEG-1 limitation or just an mpeg_encode
limitation. But basically capturing at one of those rates is the way to go.
|Well, those are the big problems I've experienced. If anyone knows how to
|get around these problems(or wants to donate a copy of the iso/iec mpeg-1
|video/audio/system papers to me so I have some point of reference when
|trying to figure out problems with mpeg-1 streams), let me know. If
|you've had problems with encoding mpeg's with fxtv/freebsd other than
|those listed, drop me a line, I might have had the problem before.
Please Cc me as well, or just Cc the list. The MPEG encoding is very
tempermental (partly fxtv, partly the tools, partly the sound drivers,
maybe partly the players), and I'd like to make it much less so.
|p.s. - now that my rant about mpeg encoding is over, how about a short
|rant about newpcm... when will it let me play mp3's without skipping all
|the time if the load average rises just a touch? I used to be able to run
|3 compile jobs, run netscape, and use mpg123 to play things without any
|skipping, now I can't even run one compile job without massive
|skipping. Is there any hope of this being fixed?
Hope so. Similar PCM complaints is one reason I'll be on 3.4R with Voxware
for a while.
Randall
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000408215628.A7389>