Date: Sat, 8 Apr 2000 22:45:16 -0700 (PDT) From: just matt <matt@dqc.org> To: Randall Hopper <aa8vb@ipass.net> Cc: multimedia@FreeBSD.ORG Subject: Re: fxtv - NTSC taps Message-ID: <Pine.BSO.4.21.0004082219040.18589-100000@dqc.org> In-Reply-To: <20000408215628.A7389@ipass.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > |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. The problem goes far beyond MpegTV. I've tried plenty of different win32 players as well as a hardware decoder. MpegTV will completely freeze after about 30 seconds of video, windoze multimedia player will keep playing after 30 seconds, but you get about 1 frame per 30 seconds(yes, that's right) and continued audio. The Xing mpeg player has variable results but all of them usually end in a reboot(I hate that thing), and trying to play the streams through the hardware decoder usually just gives me the audio portion of the screen and a black picture. For the last couple days I've had the theory that the video stream might have an invalid header or incomplete header at the begining of the stream, but without specs on the mpeg-1 format, it's pretty hard to do anything. Unfortunately, the iso/iec specs cost over $400. From switzerland. The docs are also online, mirrored in various places, in accounts for iso/iec "members" or something. Anyone have access to these? > > 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. > Sadly, the mpeg-1 stream is mysterious. I've spent a great deal of time looking for information on exact specs for it, without any luck. The secrets, shrouded in mystery, lay only in the iso/iec whitepapers on the standard. Without them all we can do is "suppose". It annoys me that this info is so expensive. > |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 > I'll try that if I get time to put voxware on my fbsd box and mess with it. Of course, seeing as pcm0 doesn't work at all for recording sound, it will prolly be a mute point if I can't verify audio is being correctly recorded from both sources for comparison purposes. > > That's interesting. So mpeg_encode may be the culprit. Is there another > MPEG video encoder for UNIX that you know of? Nope. Can't say that I've looked though. Seeing how the mpeg-1 stream specs are so terribly unavailable I'm not getting my hopes up. > > |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'm using a "NoteWorthy" ZV pcmcia decoder card for testing mainly. I had a pci card for my battered old windows box, but I ran out of pci slots and it dissapeared a while back. The results were similar though. mpeg-1 decoders are cheap nowadays, but it takes relatively little cpu time to decode them, so there isn't much of a market for them. I've found running a stream through a hardware encoder to be a very good test to see how well the stream conforms to mpeg-1 standards. Although, my hardware decoder will decode the video streams made with fxtv/mpeg_encode before they are mplexed with audio just fine, but after mplex'ed together, nothing doing. This originally made me think the problem was with mplex, but now I don't think so, although just about all of my results seem to have results that negate each other and generally are non-sensicle. That's why I want those mpeg-1 whitepapers, so I can whip up some C to parse mpeg files bit by bit and figure out what is/isn't going on in there that should/shouldn't be. > |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? > Yes, though I've tried various audio settings with identicle results. > 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. > I avoid capturing in anything but RGB, as anything else tends to lend to major machine instability. RGB 16bpp never crashes anything, but the other formats seems to get real angry if I leave them on for more than 45 second-1min, often freezing the machine. > 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. > I'm using an UW 9 gig scsi disk on an adaptec 2940UW controller for capture, so bandwidth isn't a huge issue. I normally stick with 30, though I'd like to capture at 29.97 in 352x240 so I could whip out vcd's. > > 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 > 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?Pine.BSO.4.21.0004082219040.18589-100000>