Re: [Mjpeg-users] Mjpegtools 1.6.2 rc1 (Upgrading!)
Hey Martin,
On Tue, 2003-08-26 at 11:33, Martin Samuelsson wrote:
Does this make sense at all?
Perfect, I would have proposed the same thing. I don't see any advantage
for the current behaviour as default over the old behaviour.
I'll apply ... ehm... damn, I'm gone all week ('till monday). Please
apply yourself or wait for me to apply it next monday. :).
Ronald
--
Ronald Bultje [EMAIL PROTECTED]
---
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
___
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Weird interlacing -- 3:2 pulldown?
On Tue, Aug 26, 2003 at 08:53:20AM -0700, Steven M. Schultz wrote: On Tue, 26 Aug 2003, Scott Bigham wrote: The combing effect is visible with playdv, most clearly on changes of U, I thought the problem was 'juddering' which would indicate a field order problem of some type. [...] Again, I may be using the wrong terminology, but it's clear in the output that the wrong fields are being put together in the same frame. And for reference, I'm displaying it via TV-out on a TV, so it shouldn't be a progressive-display problem. Besides, that still wouldn't explain what I'm observing in Kino: three right frames followed by two wrong frames, repeating consistently (well, except for camera-angle changes, which always seem to be wrong-fields-together no matter where they land in the cycle). I've put up a couple sample frames extracted from Kino: http://www.killerbunnies.org/~dsb/temp/sample1_2859.png http://www.killerbunnies.org/~dsb/temp/sample2_3584.png You might try deinterlacing on playback to see if that makes a difference. I know MPlayer+ffmpeg offer a number of deinterlacing filters that can be tried. Xine's 'onefield' filter looks fine, but the name suggests that it's just papering over the problem by throwing one of the fields away. My ultimate goal is to convert this to SVCD format, which means I need to actually fix the problem. -sbigham --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mjpeg 1.6.1.90 libjpeg-mmx configure change
Hey, On Tue, 2003-08-26 at 10:21, Trent Piepho wrote: The help from the configure script no longer lists the --with-jpeg-mmx option, even though it appears to still exist. If the script doesn't guess where jpeg-mmx is, there is no error most users (especially those who don't know to look) are going to notice. The result is no MMX jpeg, which is a pretty big slowdown. Will fix. Why does the configure script check to see that g77 works? Is someone planning to create a codec in FORTRAN? The horror, the horror... Automatic check from autotools, it appears automatically. Simply ignore it. :). Ronald -- Ronald Bultje [EMAIL PROTECTED] --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
[Mjpeg-users] mpeg2nec in 1.6.1.90 slower - found the answer.
I found the answer... This newer version of mpeg2enc forces variable bit rate from
what I can tell, whereas the older one did not (I'm not sure if 1.6.1 actually turned
variable bit rate on before and I commented it out or if it came that way...but
nevertheless I see it commented out in my previous copy of mjpeg2enc.c..) That'd also
be why I did not see a problem with the older one with mplayer whereas I did with the
newer one. I prefer CBR so I can predict the size of the DVD, and at least with the
older mpeg2enc I could never get VBR to play right in my DVD player whereas CBR played
just fine. I like the way everything looks and works today so I'm not inclined to try
VBR :-) And I also believe that it wasn't necessary 4x slower now - maybe 2x. The
reason it appeared 4x slower was because when I was running mplayer on the .m2v as it
was being written passing the 'ss' parameter mplayer wasn't really going to the proper
place in the file (as pointed out by someone else), which made me believe it had not
encoded as much as perhaps it had...
Any thought to making CBR an option in mpeg2enc for DVD formats rather than forcing
VBR?
-- Ray
On Mon, 25 Aug 2003 18:34:18 -0500
Ray Cole [EMAIL PROTECTED] wrote:
Yep, I see the following:
INFO: [mpeg2enc] SETTING 3DNOW and EXTENDED MMX for QUANTIZER!
INFO: [mpeg2enc] SETTING EXTENDED MMX for MOTION!
INFO: [mpeg2enc] SETTING MMX for TRANSFORM!
INFO: [mpeg2enc] SETTING EXTENDED MMX for PREDICTION!
-- Ray
On Mon, 25 Aug 2003 19:27:08 +0200
Bernhard Praschinger [EMAIL PROTECTED] wrote:
Hallo
Guess that would help :-) mpeg2enc is what is running slower.
Here's the command line I used on the old one vs the new:
Old Command:
nice mpeg2enc -f 8 -b ${aRate} -V 230 -n n -s -a 2 -g 6 -G 18 -I 0 \
-r 24 -4 2 -2 2 -F 1 -p -v 0 -o ${aName}.m2v
New Command:
nice mpeg2enc -f 9 -b ${aRate} -V 230 -n n -s -a 2 -g 6 -G 18 -I 0 \
-r 24 -4 2 -2 2 -N 1.50 -Q 1.00 -v 0 -p -F 1 -o ${aName}.m2v
(Also tried -f 8 rather than -f 9).
I also noticed that using either -f8 or -f9 that something wasn't quite right
with some sort of timestamps. I did a 'mplayer test.m2v -ss 15:00' for example
and that really took me about 45 minutes into the movie (maybe a little
further). This worked when I encoded using the older version of mpeg2enc,
doesn't with the new.
tps://lists.sourceforge.net/lists/listinfo/mjpeg-users
Could it be that some optimations are not used when mpeg2enc start you
should find lines like that:
INFO: [mpeg2enc] SETTING 3DNOW and EXTENDED MMX for QUANTIZER!
INFO: [mpeg2enc] SETTING EXTENDED MMX for MOTION!
INFO: [mpeg2enc] SETTING MMX for TRANSFORM!
INFO: [mpeg2enc] SETTING EXTENDED MMX for PREDICTION!
If mpeg2enc does not use them it will be slower.
If you have compiled it yourselfe you should take a look what you see
when you configure it. Do you have a nasm installed ?
Else. It could be that mpeg2enc does not detect you cpu correct. Which
distirbution/kernel do you use ?
auf hoffentlich bald,
Berni the Chaos of Woodquarter
Email: [EMAIL PROTECTED] [EMAIL PROTECTED]
www: http://www.lysator.liu.se/~gz/bernhard
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mpeg2nec in 1.6.1.90 slower - found the answer.
On Tue, 26 Aug 2003, Ray Cole wrote: I found the answer... This newer version of mpeg2enc forces variable bit rate from what I can tell, whereas the older one did not (I'm not sure if 1.6.1 actually turned variable bit rate on before and I commented it out or if it came that way...but nevertheless I see it commented out in ALL previous versions that could generate DVD compatible streams were VBR I prefer CBR so I can predict the size of the DVD, and at least with the older mpeg2enc I could never get VBR to play right in my DVD player whereas CBR played just fine. I like the way everything looks and works today so I'm not inclined to try VBR :-) And I also believe that it No sense of adventure, eh? ;) There _were_ issues in earlier releases, now that the bugs have been fixed it's stay with the broken approach? I've made hundreds of DVDs using the VBR logic and they all play fine on a variety of standalone players ranging from an old Audiovox portable to a Philips (which will play anything it seems). wasn't necessary 4x slower now - maybe 2x. The reason it appeared 4x slower was because when I was running mplayer on the .m2v as it was Ah, that'll do it - MPlayer does use a lot of cpu (sure seems to use more than Ogle for playing DVDs - at least on my systems). My suspicion is that MPlayer was interfering more than was realized.The current encoder hasn't slowed down by 2x on the systems I use - but then they're all dual cpu systems so the filtering doesn't slow down the encoder too much. Any thought to making CBR an option in mpeg2enc for DVD formats rather than forcing VBR? Ick - that means scenes that need more bits will be starved and not look good while other scenes that don't need bit will waste them.All for making it easy to calculate the size? Why not use the '-b' bitrate as an upper bound and calculate according to that - if the project comes in smaller that's not a Bad Thing, I frequently use the extra space to put scans of the artwork, and so on onto the disc. Any player that can't handle VBR is busted/broken (and hopefully within the return period so the money can be refunded ;)). All commercial DVDs that I've seen are VBR. The commercial DVD makers use that to get as much as possible on a DVD without having to cut the bitrate down to poor quality levels. But there's no need for making CBR an option - it's already there. If you really want poorer quality then leave off the -q option - that is what tells the encoder to engage the VBR logic. Without the -q the encoder will generate CBR according to the -b value Vendors go out of their way to create VBR encoders (Apple's touting that as one of the main features in their new encoder - the one in Quicktime-Pro is CBR despite their claims to the contrary) - try it, it'll generate better movies. Steven Schultz --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mpeg2nec in 1.6.1.90 slower - found the answer.
Am Mittwoch, 27. August 2003 06:01 schrieb Steven M. Schultz: Ah, that'll do it - MPlayer does use a lot of cpu (sure seems to use more than Ogle for playing DVDs - at least on my systems). Well I guess this depends on the video card. If mplayer has to rely on X11 output it sure needs a lot of cpu power. With available xv/vidix/whatever it will be better. I don't believe that ogle is more performant than mplayer. Steffen --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
[Mjpeg-users] pipe video _through_ yuvplay?
Hi folks! I was wondering if it is possible to have yuvplay pass the video stream to stdout besides showing the frames in a window? I'd like to see how far my encoding has progressed so I'd like to do something like this: lav2yuv | filter_stuff | yuvplay | mpeg2enc Is that possible? See ya, Axel 'Anterion' Philipsenburg --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] mpeg2nec in 1.6.1.90 slower - found the
I've made hundreds of DVDs using the VBR logic and they all play fine on a variety of standalone players ranging from an old Audiovox portable to a Philips (which will play anything it seems). I'm sure it works now, but it's one of those situations where cbr is working plenty good for what I'm doing - I have a lot of trouble telling the difference between what I've recorded and watching it on directv. The problem I was having with previous versions I believe was with mplex - cbr or vbr, nothing would ever play if I used mplex. I had to use tcmplex, and it'd only work if it was cbr. Now that mplex appears to be working for me I will eventually give vbr another chance. Why not use the '-b' bitrate as an upper bound and calculate according to that - if the project comes in smaller that's not a Bad Thing, I frequently use the extra space to put scans of the artwork, and so on onto the disc. I'm not understanding how this would produce better quality if I'm setting the upper bound to be what I'm currently using for cbr. Seems to me at worst I'm wasting a few bits today using cbr, and if I switch to vbr I may save a little space but I'm not sure why I care :-) Typical bitrates I'm passing for cbr are around 5500. But there's no need for making CBR an option - it's already there. It isn't an option today if one selects -f8 or -f9 - there is a check in the code for these two types to see if -q was passed. If -q is 0 (default/unpassed) it forces it to 8. contrary) - try it, it'll generate better movies. I'll give it a whirl. I've burned around 80 DVD's now (largely converting old VHS tapes to DVD) and have been extremely pleased with the quality using CBR. I'll let you know if I can see any difference between CBR/VBR. Thanks for the encouragement - you've convinced me to at least try it once more :-) -- Ray --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] pipe video _through_ yuvplay?
On Wed, 2003-08-27 at 11:50, Axel Philipsenburg wrote: I'd like to see how far my encoding has progressed so I'd like to do something like this: lav2yuv | filter_stuff | yuvplay | mpeg2enc Is that possible? Try: mkfifo play.yuv yuvplay play.yuv lav2yuv | filter_stuff | tee play.yuv | mpeg2enc rm play.yuv Cheers, Charlie --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] pipe video _through_ yuvplay?
Hallo I was wondering if it is possible to have yuvplay pass the video stream to stdout besides showing the frames in a window? I'd like to see how far my encoding has progressed so I'd like to do something like this: lav2yuv | filter_stuff | yuvplay | mpeg2enc Is that possible? If you haven't tried it, just try it. It works (at least with the CVS). Here is my test: lav2yuv rocke.eli | yuvplay | mpeg2enc -f 8 video_test.m2v auf hoffentlich bald, Berni the Chaos of Woodquarter Email: [EMAIL PROTECTED] [EMAIL PROTECTED] www: http://www.lysator.liu.se/~gz/bernhard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
[Mjpeg-users] lpcm audio?
I am having difficulty getting linear PCM audio to work with mplex and mpeg2 files. Is lpcm in mplex working? I need it to make DVDs. I'm using recent CVS of mjpegtools. The audio comes out as noise, similar to endianness trouble, but I've tried both ways. Regards, Mark [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Mjpegtools 1.6.2 rc1 (Upgrading!)
I remember that I have changed that loop option. At least I applied the patch from a user to have that feature. I trie to answer all mails about that topic in one mail. Might aswell. :) Fine. Uh. That would mean cvs access, right? Guess I'll have to wait, then. :) You can get it if you want ... just tell you your SF user ;) Didn't have any at the time. Now I do, and CVS access too. I committed the --max-file-frames change of lavrec a few minutes ago; I hope it worked out ok on the server... Seems that you forgot to upload the changed lavrec manpage. ;) If you want only one pass you do not need the -l option, that is the default behavior of jpeg2yuv. Because of that -l 1 was used to for loop forever. Strange logic I know. A bit tricky to handle in the code. Because of that you have that that if statemt befor the while. If you really want a differnet behavior of the option please send me a manpage that describes how the programm should behave after the next change. ;) I have read the different solution, I really don't know which I sould use. I chose the -l -1 is forever, -l n=1 is number of loops because this is consistent with the way the already existing -n works. It felt somewhat odd to have two flags with very similar functions and completely different ways of specifying essentially the same thing. And it was easier to handle in the code. :) Ok, if you and all others can live with that till the weekend I'll change jpeg2yuv and the manpage of jpeg2yuv. Else someone else has to do it. How this is resolved in the end isn't something I'm religious about as long as I can use it to convert single images from single files, but I feel that it might be a good thing to keep backwards compatibility, at least until a more significant version bump than a 0.0.1 one, and to keep the argument handling consistent with similar arguments within the same tool. Ok, I see that point (consitency) you mention now. Sounds like you're already on top of this loop thing, and will handle it? Yes, but not before the weekend (SA). auf hoffentlich bald, Berni the Chaos of Woodquarter Email: [EMAIL PROTECTED] [EMAIL PROTECTED] www: http://www.lysator.liu.se/~gz/bernhard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Weird interlacing -- 3:2 pulldown?
On Sun, Aug 24, 2003 at 12:09:03PM -0700, Steven M. Schultz wrote: On Sun, 24 Aug 2003, Scott Bigham wrote: Actually, I'm probably using the 0.2.0 release; I couldn't find any mention of an associated CVS repository. It is a bit hard to track down - try this: :pserver:[EMAIL PROTECTED]:/cvsroot/kino Oh, Sourceforge. Okay, I know how to get stuff from there. How are you doing the capture? With 'dvgrab' perhaps? Yep, --format raw. Should I be using something else? (I'm hoping to automate this, so Kino is probably out.) If you play the raw DV data what does it look like? The combing effect is visible with playdv, mostly on changes of camera angle or objects moving against a contrasting background. I can also see the effect in Kino when stepping frame-by-frame. -sbigham --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
