Re: [Mjpeg-users] Best capture tools under Linux for V4L2?
On Tue, 2004-06-22 at 17:45, Steven M. Schultz wrote: On Tue, 22 Jun 2004, Steven Ellis wrote: Get yourself a IEEE1394 card (very cheap) and a Canopus ADVC100 or even better (but somewhat more expensive) ADVC300 analog to DV converter. The ADVC300 has a TBC and denoising capability built in so it's well suited to convering VHS tapes which have less than great picture stability/quality. Well thanks for the interesting tip. Already considered this angle and there are a couple of issues. 1. Can't really build a PVR around this, which is part of the long term goal. 2. Its too expensive here in NZ (NZ$ 600) On the firewire front already use it for my digital work. Wonder if anyone has played with realtime capture to DV from an analog card? Steve -- Steven Ellis [EMAIL PROTECTED] --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Best capture tools under Linux for V4L2?
A nVidia FX5200 is __cheap__ and comes with a MPEG_2 decoder than MPlayer and ffmpeg know how to tap into. Quite useful for playback even when the system is under heavy load (since the decoding is shoved out to the graphics card). Hey, that's really interesting, thanks. I have an nVidia FX5200, and I had no idea. A bit of googling tells me the mplayer driver is called vo_xvmc. I'll try it out soon. maarten --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Best capture tools under Linux for V4L2?
On Tue, Jun 22, 2004 at 07:31:58PM +1200, Steven Ellis wrote: On Tue, 2004-06-22 at 17:45, Steven M. Schultz wrote: On Tue, 22 Jun 2004, Steven Ellis wrote: Get yourself a IEEE1394 card (very cheap) and a Canopus ADVC100 or even better (but somewhat more expensive) ADVC300 analog to DV converter. The ADVC300 has a TBC and denoising capability built in so it's well suited to convering VHS tapes which have less than great picture stability/quality. Well thanks for the interesting tip. Already considered this angle and there are a couple of issues. 1. Can't really build a PVR around this, which is part of the long term goal. Why not? There's nothing specific about an ADVC100/300 that prevents it from being used as a PVR. Now, it may require a little more work to get everything setup and working, but it's perfectly capable of being the capture unit in a PVR. However, if your primary concern is PVR use, and ease of PVR use at that, you should seriously consider a Hauppauge PVR250 card. Real time mpeg compression, and onboard cable compatible (at least here in the US, I don't know about NZ) tuner. And it produces an absolutely beautiful capture. It's also extremely convenient for PVR use to have the card write a complete, multiplexed, ready to go mpeg file to disk in real time. 2. Its too expensive here in NZ (NZ$ 600) That's a wholly different problem that unfortunately we can't do anything about. :) That may also make the PVR250 solution problematic. Brand new PVR250's here in the US run for about $139-149 (US) or so. NZ's likely to be very different. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Best capture tools under Linux for V4L2?
On Tue, 22 Jun 2004, Maarten de Boer wrote: A nVidia FX5200 is __cheap__ and comes with a MPEG_2 decoder than MPlayer and ffmpeg know how to tap into. Quite useful for playback Hey, that's really interesting, thanks. I have an nVidia FX5200, and I had no idea. A bit of googling tells me the mplayer driver is called vo_xvmc. I'll try it out soon. I know that the nVidia drivers come with the necessary 'xvmc' library - so I build MPlayer with the '--enable-xvmc' option and MPEG-2 playback (even HDTV 1920x1080i) takes very little cpu. Cheers, Steven Schultz --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Best capture tools under Linux for V4L2?
On Tue, 22 Jun 2004, Steven Ellis wrote: Well thanks for the interesting tip. Already considered this angle and there are a couple of issues. Welcome! 1. Can't really build a PVR around this, which is part of the long term goal. You most certainly can. Might be an extra (S-Video or composite) cable or two involved but that shouldn't be an insurmountable problem. 2. Its too expensive here in NZ (NZ$ 600) Can't help with that (the ADVC100 is just $250 or less here) but there are the other models such as the 55 that might be suitable. Also, there are other brands such as Datavideo that are slightly less expensive. BUT - out of quality, speed and cheap you can specify two but NOT all three. Wonder if anyone has played with realtime capture to DV from an analog card? Quite cpu intense. You might try splicing/striping two discs together into a RAID-0 setup (each disc on its own IDE channel) - perhaps that'd be sufficient. For casual viewing (i.e. view and delete or discard) the analog cards are adequate. For archival purposes, well, quality isn't free/cheap ;( The other gotcha is that the analog cards (at least the Bt878 based ones) going thru the v4l layer yield square pixels which means you need to scale the data (to 10:11 pixels for NTSC, to 59:54 pixels for PAL) before encoding or the aspect and/or frame size will be wrong. Maybe that's better/different since the last time I checked. The main drawback of the PVR cards that go directly to MPEG-2 is that they don't give you a chance to run the data thru any filters to clean the picture up - and VHS sources are always (that I've seen) in dire need of filtering. After seeing what 'y4mdenoise' can do to a noisy VHS source I decided it was worth the extra hours of encoding time. Dual cpu systems are pretty much a requirement though when using a pipeline of filters but I haven't had a single cpu system since 1998 or so (except for the notebooks ;)). Cheers, Steven Schultz --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Best capture tools under Linux for V4L2?
On Tue, Jun 22, 2004 at 08:57:43AM -0700, Steven M. Schultz wrote: On Tue, 22 Jun 2004, Steven Ellis wrote: 1. Can't really build a PVR around this, which is part of the long term goal. You most certainly can. Might be an extra (S-Video or composite) cable or two involved but that shouldn't be an insurmountable problem. Wonder if anyone has played with realtime capture to DV from an analog card? ... The main drawback of the PVR cards that go directly to MPEG-2 is that they don't give you a chance to run the data thru any filters to clean the picture up - and VHS sources are always (that I've seen) in dire need of filtering. Quite true, assuming of course that one is duping vhs tapes off to DVD. But, the posters implied usage is PVR, which implies record / watch / throwaway (most of the time) functionality. And for that, the PVR cards excell, because there's no encoding effort after the fact. A ready to watch mpeg is saved out to disk, no fuss, no muss. And so far in my experience, sourcing signals from analog cable, my PVR250 card produces equally as good, if not better, picture quality compared to the best I can achieve from my DC10+'s mpeg2enc, in exactly the amount of time needed to capture the video in the first place. That's hard to beat for the normal PVR usage model. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] capture from poor quality tapes
Hallo I've got several home movies on vhs that my mom had had transfered from 8mm film The tapes are pretty poor quality When I try to capture I get [home]$ lavrec -fa -in -d2 -q100 -m -U -w -c2 test%02d.avi ++ WARN: [lavrec] Closing file(s) and exiting - output file(s) my not be readable due to error **ERROR: [lavrec] Error syncing on a buffer: Timer expired **ERROR: [lavrec] Error resetting buffer-queue: Invalid argument0.000 That lookes bad. Can you view the incomming video with a TV application ? I can view the video using the lml33 passthru It's jerky When I view the video normally (vcr - tv) the picture looks pretty good The normal TV has a different timing than the typical PC card has. And the TV has not that much problems with a sloppy timing. :-/ If that works, try recording without audio (-a 0). The videos have no audio Using -a 0 doesn't help I can't record a single frame Than I really fear that the timing is to bad. And the card is not able to sync on it. If you have a VCD, try to record it first to the VCR and that from the VCR to the LML33. Else I fear that the only way to recrod the video will be a box that makes the signal better. The only reference I found searching the mailing list said to remove the target file first That doesn't help I tried rerecording on to a new tape and capturing from that but no good I tried 2 different vcrs but no good I tried -c2, -c1, and -c0 but no good I'm using a LML33 with kernel 2.6.6 and mjpegtool 1.6.2 I've successfully captured from other tapes Do you use the original kernel driver or the CVS version ? I've tried both, no difference If you have the LML33R10, you have a SAA7111a, in the PDF specification the the IC, you finde on page 48 a description for the sync control register SA08 where you can set the TV mode VTRC. If you change that bit in the saa7111.c line 175 to 0 (TV mode recomended for poor quality only) that MIGHT help. You have to change the 0xc8 to 0xc0 Maybe there are other registers that help but that one looks as if it could be helpfull. auf hoffentlich bald, Berni the Chaos of Woodquarter Email: [EMAIL PROTECTED] www: http://www.lysator.liu.se/~gz/bernhard --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Best capture tools under Linux for V4L2?
On Tue, 22 Jun 2004, Richard Ellis wrote: Quite true, assuming of course that one is duping vhs tapes off to DVD. Which was one of the items mentioned - that's why I brought up the issue of being able to manipulate the data before encoding. But, the posters implied usage is PVR, which implies record / watch / throwaway (most of the time) functionality. And for that, For that you could simply playback the DV file - 25Mb/s gives real good quality and when you're done just rm the file :) exactly the amount of time needed to capture the video in the first place. That's hard to beat for the normal PVR usage model. Capture the DV, watch, rm. 250GB drive can hold ~20 hours of data and there's no conversion/encoding required at all. That also is hard to beat grin. Cheers, Steven Schultz --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] capture from poor quality tapes
I had this issue with my bt card. The video tape looked just fine on TV, but when I captured it would studder - it was duplicating frames, sometimes just a single field (which was really weird). The bttv module has a 'vcr_hack' option that eliminated this problem. I don't know if something similar is going on with the lml33 or not. The issue as I recall is the signal is a bit distorted. A TV can compensate for it. The capture card tries, but by the time it realizes it didn't get the sync signal it is too late so it has to wait for the next frame. This causes the capture to appear to stay on a frame for a period of time. The 'hack' was to not grab the last 2 lines (or something like that) which allowed the card enough time to recover. I only vaguely know what I'm talking about here, so please forgive me if I'm explaining this incorrectly. Anyway, it makes me curious if the lml33 has a similar issue that could be resolved in a similar manner. Enabling vcr_hack allowe d me to record a number of video tapes flawlessly that previously were very problematic to record. -- Ray --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Best capture tools under Linux for V4L2?
On Tue, 22 Jun 2004, Steven M. Schultz wrote: cards are adequate. For archival purposes, well, quality isn't free/cheap ;( The other gotcha is that the analog cards (at least the Bt878 based ones) going thru the v4l layer yield square pixels You are about that? I have no trouble setting my bt848 to capture at 720x480. This is since before v4l1 existed. --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
[Mjpeg-users] yuvdenoise problems when SSE instructions used?
Hi all I have encountered something rather odd about yuvdenoise from mjpegtools 1.6.2 and the way it works on two different machines. In short, I encoded a video in two 90 minute sections using the same command line - one was on a (PII-vintage) Celeron 466 and one on a 3.0GHz P4 with hyperthreading. The command line used was lav2yuv movie.mov | yuvfilter -l 2 -t 6 | \ mpeg2enc -f 8 -c -q 4 -N 1.5 -R 2 -E -10 -o movie.m2v What I observed was that when multiplexed with mp2 audio and burnt to DVD, the mpeg produced by the Celeron was fine but the stream from the P4 was very flickery around movement - even very slow movements. Next I hacked yuvfilter so SSE instructions were permanently disabled - only the basic MMX code was used (I replaced the conditional at yuvdenoise/main.c:524 with if (0)). When run on the same movie.mov file as before on the P4, the filesize of the resulting m2v stream was different. This seems odd - surely the stream contents should be independent of the instructions used to encode it. Anyway, when this new stream was multiplexed onto a DVD, the flickering was practically eliminated. Has anyone else noticed this effect? It doesn't seem right that the output of yuvdenoise differs depending on what CPU you run the program on. Any thoughts? Regards jonathan -- * Jonathan Woithe[EMAIL PROTECTED]* *http://www.physics.adelaide.edu.au/~jwoithe* ***---*** ** Time is an illusion; lunchtime doubly so ** * ...you wouldn't recognize a subtle plan if it painted itself purple and * * danced naked on a harpsichord singing 'subtle plans are here again'* --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Best capture tools under Linux for V4L2?
On Tue, 22 Jun 2004, Trent Piepho wrote: On Tue, 22 Jun 2004, Steven M. Schultz wrote: cards are adequate. For archival purposes, well, quality isn't free/cheap ;( The other gotcha is that the analog cards (at least the Bt878 based ones) going thru the v4l layer yield square pixels You sure about that? I have no trouble setting my bt848 to capture at 720x480. This is since before v4l1 existed. With 'xawtv'? That was the only thing I tried (a while back) and it adamantly insisted that 640x480 was the max (and the data rate was about 42GB/hr). I presume you're using a RAID-0 setup to handle the fullframe 4:2:2 data (and then resampling to 4:2:0 later on). But since moving away from the Bt cards a couple years ago I haven't revisited to see if the situation's improved. At one time there was the chroma bug where the chroma for the 2nd field was simply replicated from the first field (when 4:2:0 capturing was being done, the workaround was to capture in 4:2:2 and convert in software). All in all I don't miss the beast at all. Where in the configuration/setup menus is the choice if ITU-601 or square pixels offered? The WinTV card is targeted at computer playback/viewing and that would use square pixels... I had the complete datasheets for the Bt848 but tossed 'em out not too long ago - have to print 'em out again but I can't find in the xawtv or kernel where the pixel aspect is passed thru and actually set. But if they're doing 720x480 then they're doing something wrong - possibly capturing part of the blanking or whatever. Full frame NTSC analog video is 704x480 10:11 or 640x480 1:1.That's all the TV stations are putting out ... DV has the extra 8 pixels on each side of a 704x480 frame but Bt8x8 cards converting an analog signal shouldn't be giving out 720x480 unless the right and left 8 pixels are black and the center 704 are the actual data. I wouldn't be surprised if something is padding/scaling things up a bit. One app I had (on another OS) very carefully padded the 29.97... up to 30 :( Cheers, Steven Schultz --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] capture from poor quality tapes
On Tue, 22 Jun 2004, Ray Cole wrote: Took a while to reformat the 2KB line into something readable... ;) I had this issue with my bt card. The video tape looked just fine on TV, but when I captured it would studder - it was duplicating frames, sometimes just a single field (which was really weird). The bttv module has a 'vcr_hack' option that eliminated this problem. I don't know if something similar is going on with the lml33 or not. The issue as I recall is the signal is a bit distorted. A TV can compensate for it. The capture card tries, but by the time it realizes it didn't get the sync signal it is ... d me to record a number of video tapes flawlessly that previously were very problematic to record. Sounds like what you need is either a TBC or one of those image stabilizer units. Yes, I had similar issues with the Bt8x8 card a few years ago - some of the more warn/junkier tapes caused the card to lose it. Even when it didn't lose it the constant jitter caused the mpeg encoding to see the constant motion and waste a lot of bits encoding the motion. My solution then was to get the Sima SCC (not sure if that model is made now that the SCC-2 is out) and put it inline between the VCR and the capture device. Did absolute wonders to stabilize the picture, and on some of the really bad/faded tapes the color correction capability was quite useful - could boost the chroma, adjust the contrast, sharpness, hue, etc. As a pleasant side effect it also strips out the Macrovision copy junk which can also confuse capture cards. The Sima SCC-2 (and other similar devices can be found at) are made by Sima Corp: http://www.simacorp.com/ The units are sold at a number of places online (BH Photo for example). An inexpensive single channel TBC runs about $280 or so and a dual channel one (for genlocking two devices) about $450 - i think (the catalog is at the other end of the house and I'm lazy at the moment ;)). Good Luck! Cheers, Steven Schultz --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] yuvdenoise problems when SSE instructions used?
On Wed, 23 Jun 2004, Jonathan Woithe wrote: I have encountered something rather odd about yuvdenoise from mjpegtools 1.6.2 and the way it works on two different machines. In short, I encoded a video in two 90 minute sections using the same command line - one was on a (PII-vintage) Celeron 466 and one on a 3.0GHz P4 with hyperthreading. The Wow - you must have the patience of a saint to do encoding on a Celeron 466! :) Has anyone else noticed this effect? It doesn't seem right that the output No, can't say I've seen the effect but then I've been experimenting with y4mdenoise (from cvs) or working with digital data that doesn't require denoising at all. of yuvdenoise differs depending on what CPU you run the program on. Any thoughts? Makes perfect sense - if there's a bug in the SSE routines ;) There's also a chance that the bug has been fixed in the cvs version - don't suppose you could give that a go and see if the problem's still lurking about? The vintage Celeron doesn't have SSE capability (I think the newer ones do have it) so it uses only the MMX routines. The P4 on the other hand does have SSE (and SSE2) and will use the SSE based routines. You can probably speed things up a little on the P4 by disabling the hyperthreading. I tried it and on a good day the speed hit was only 10 or 15% but some job mixes the system slowed down by closer to 30%. When Intel comes out with their new true dual core cpus then that'll be nice but till then I haven't had much success with the hyperthreading's quasi 2nd cpu. Cheers, Steven Schultz --- This SF.Net email sponsored by Black Hat Briefings Training. Attend Black Hat Briefings Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
