Re: [Mjpeg-users] yuvdenoise -S and -b
Hi! Mark Heath wrote: On 02/10/2005, at 6:35 PM, Frank Albrecht wrote: Is it possible to use mencoder or ffmpeg for capturing for mjpegtools? I couldn't figure out how to create an input satifying lav2yuv/mpeg2. Hopefully this is will answer what you are asking. Mplayer and ffmpeg can both produce a yuv4mpeg stream which works nicely with mjpeg tools. the command lines would be like this: ffmpeg -i input_file.ext -f yuv4mpegpipe outfile.yuv you can replace outfile.yuv with - if you want to use standard out. mplayer will only write to a file called stream.yuv, so if you want to pipe it, you have to use mkfifo. It messes up the interlacing field, it says that every file is progressive and the aspect field saying that the file is 0:0 mplayer -vo yuv4mpeg input_file.ext It's been my experience with mplayer 1.0pre7-3.3.5 and later (cvs) that interlacing isn't messed up. However, you must specify that the piped output should be interlaced. When piping to mpeg2enc, it detects when the input file is interlaced and encodes appropriately. My command line looks like: mplayer -nosound -noframedrop -benchmark -vo yuv4mpeg:interlaced infile If your source video is bottom-first, then change "interlaced" to "interlaced_bf". Joe --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] yuvdenoise -S and -b
On Tue, 4 Oct 2005, Frank Albrecht wrote: It might be a better idea to reply to this list (especially with lavrec or V4L problems - I abandoned the Bt878 card several years some time ago). > > Perhaps others who capture to mjpeg can help with some ideas - but > > I thought 'lavrec' was the usual method used to capture mjpeg data. > > I spent much time for trying out lavrec. With a BT878 > (software-encoding) and a 2.4 GHz/512MB Machine i can't get a > good quality. Either dropped frames or quality(<50) goes down. Couple things can cause that - an unsteady source (VHS decks in particular are very jittery) or the mjpeg compression routines are taking just a little too long to get the job done. The kernel driver(s) are the same for both lavrec and streamer so the problem is probably not in the kernel. Is this from a VHS tape deck? Maybe a signal stabilizer would help, something like: http://www.kramerelectronics.com/indexes/item.asp?desc=98 or a TBC but that's probably more money than you want to spend ;) If it's a matter of the software mjpeg compression taking too long (are you using the jpeg-mmx routines?) maybe capturing to 4:2:2 uncompressed ( I think the Bt878 and drivers are capable of this) might be better - at the cost of MUCH more diskspace (not to mention I think the general YUV handling in the lavtools is broken ;)). > Streamer can also write mjpeg avis, cuttable by glav, but if > size goes > 2GB, neither lav2yuv nor avisplit can handle that > avi. Streamer can't create with %01d mjpegtools can. If someone knows of a good replacement for the lavtools/avilib.c which implements the ODML extensions (or at least provides some code that can be "borrowed") then the lav* programs can support > 2GB files. The better long term solution is to find out why streamer can't write quicktime files - but I see that's in the next mail item ;) Cheers, Steven Schultz --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] yuvdenoise -S and -b
On Tue, 4 Oct 2005, Frank Albrecht wrote: > > > > What does a gdb backtrace look show?... > > [...manual for dummies such as me...] > Thank you. You're welcome. Oh, I forgot to mention "chapter 2" in the manual ;) When you configure libquicktime add the "--enable-debug": ./configure --enable-debug that will provide more info > (gdb) run streamer -t 0:30 -o movie.mov -f yv12 -F mono16 ... > (gdb) where > #0 0x4022f1d9 in quicktime_set_audio () from > /usr/local/lib/libquicktime.so.0 > #1 0x402a0af7 in ?? () from /usr/local/lib/libquicktime.so.0 > #2 0x0001 in ?? () > #3 0x4022f1b8 in quicktime_set_audio () from /usr/local/lib/libquicktime.so.0 > #4 0x402140ff in ?? () from /usr/local/lib/xawtv/write-qt.so > I woldn't have expected it's an audio related problem. It' the > same with rpm package and self-compiled. Ok - that's a good start. It's something in how xawtv/streamer is initializing or writing the audio track. The audio track handling is something that did change in libquicktime as I recall. > Thank you for the gdb hints, i've learnt a lot. Happy to be of service. I think the next steps are to build both streamer and libquicktime with debug symbol information. For libquicktime that is easy (just add --enable-debug at ./configure time). The other thing that can be done is find where streamer is calling 'quicktime_set_audio' and find out if it is setting things up correctly for what libquicktime is expecting. Cheers, Steven Schultz --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] yuvdenoise -S and -b
On Wednesday 05 Oct 2005 09:30, Steven M. Schultz wrote: > or a TBC but that's probably more money than you want to spend ;) Unless you are familiar with electronics : http://www.astro.uu.se/~marcus/private/newvidproc.html --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] yuvdenoise -S and -b
On Wed, 5 Oct 2005, E.Chalaron wrote: > Unless you are familiar with electronics : > > http://www.astro.uu.se/~marcus/private/newvidproc.html Nice looking unit - wonder how much he would charge to build one? (soldering irons and I do not get along ;)) I noticed it was done in 2001 and there are a couple comments about specific chips being hard to get even then - not a problem for a digital electronics engineer but way out of my area of expertise. Stabilizing the signal can be an important thing to do - if the capture card is struggling with sync then the probability of dropped frames increases dramatically. Sometimes the signal sync is lost completely - and then the capture is worthless after that point. It's not a certainty that's what the problem is - but it is a possibility worth considering. Cheers, Steven Schultz --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
