Re: [Mjpeg-users] Encoding aspect ratio for SVCD
Hi! > Am I right expecting better quality results > with a 16:9 aspect ratio in the SVCD? Yes, except the fact that many DVD players doesn't correctly play 16:9 SVCDs :-( Alexei --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Encoding aspect ratio for SVCD
Hi! On Monday 19 January 2004 5:14 pm, Steven M. Schultz wrote: > As Alexei mentioned (and I have observed the same thing) many DVD/VCD > players do NOT perform the letterboxing function for SVCD/VCD. In > fact I have yet to encounter a DVD player that will pay attention to > the aspect ratio flags in a SVCD MPEG file. As I remember from some of my experiments my DVD player (Philips 724) understands 16:9 SVCD (at least in NTSC) but plays it a bit strange - it scales it so that the image doesn't have black bars at the top/bottom (or have them very small), something like with 2x zoom - aspect rate looks correct but left and right part of the image are lost :-((( 16:9 can be better even if player doesn't understand it and will play as 4:3 - if you can switch TV to 16:9 mode. In this case TV will use all available video information to construct 16:9 image, will add black bars by itself - no information will be lost. But AFAIK this doesn't work with all TV sets and will require manual intervention. Alexei --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
[Mjpeg-users] mpeg2enc + Pentium-4 Hyperthreading testing results
Hi! I've decided to investigate a bit a dependence of mpeg2enc encoding speed from the value of its -M (--multithread) encoding option & the type of the kernel (UP/SMP) the system runs on the Pentium 4 with hyperthreading support. For the tests with UP kernel hyperthreading was disabled in BIOS, for SMP - enabled. Testing platform: System: Pentium-4 2,4Gz with hyperthreading support, i865PE, 256M RAM (single-channel mode) OS: Linux, Fedora Core 1, kernel-2.4.22-1.2194.nptl (and its SMP version) Software version: mjpegtools-1.6.2 Source file: stream.yuv, $ LANG=C ls -lh stream.yuv -rw-rw-rw- 1 root root 1.5G Jan 21 16:23 stream.yuv This is a actually a small uncompressed fragment of "Finding the Nemo" NTSC DVD (3000 frames). Testing command: time cat stream.yuv | yuvscaler -n n -O SVCD 2> /dev/null | mpeg2enc -f 4 -F 1 -p -M -o stream.m2v 2> /dev/null Results: 1. Hyperthreading disabled, UP kernel: -M 0 1m42.133s -M 1 1m41.043s * -M 2 1m44.355s -M 3 1m46.544s -M 4 1m43.633s ??? -M 5 1m51.273s 2. Hyperthreading enabled, SMP kernel: -M 0 1m53.083s -M 1 1m47.157s -M 2 1m37.317s -M 3 1m31.565s -M 4 1m31.379s * -M 5 1m31.832s So, the results show that encoding with hyperthreading enabled is about 10% faster and the optimal thread number for uniprocessor P4 system without hyperthreading is 1, and 3 or 4 (not 2!!!) if hyperthreading is enabled. For some reason the testing with 4 threads with hyperthreading disabled produced very different results each run - I've got results ranging from 1m40s to 1m51s (in all other modes the difference between sequential runs were usually not bigger than 0.1-0.2s). BTW, also the results showed that on a such system it is possible to encode to SVCD resolution in real time, even faster - the video fragment is ~ 2min. :-) I also tried the -R 2 switch (since the default -R 0 is known to produce artifacts sometimes & --no-dualprime-mpeg2 switch is not available in 1.6.2 version), this time only with the best settings (-M 1 & -M 4). The results are very different unfortunately: Hyperthreading disabled, UP kernel: -M 1 2m3.095s (~21% slower compared to default -R 0) Hyperthreading enabled, SMP kernel: -M 4 2m13.267s (~45% slower...) Encoding without hyperthreading is ~7% faster in this case - "-R 2" perfomance hit is terrible for the system with hyperthreading (or to any SMP system?) - nearly half ot the perfomance is lost :-( BTW, the resulting file is also a bit bigger :-( Alexei --- 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] mpeg2enc + Pentium-4 Hyperthreading testing results
Hi! On Thursday 08 July 2004 10:17, Steven M. Schultz wrote: > On Thu, 8 Jul 2004 [EMAIL PROTECTED] wrote: > > > The "HT" isn't a full/complete cpu (dual core cpus are in the process > > > of being developed by Intel (and others))... > > > > scheduler in the 2.4 series kernel is not HT "aware". Thus the processor > > afinity is incorrectly treated like a traditional second CPU, which HT is > > not. This > > Exactly. AFAIK Fedora Core 1 kernel is HT-aware. Alexei --- 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] mpeg2enc + Pentium-4 Hyperthreading testing results
Hi!
On Thursday 08 July 2004 00:14, Steven M. Schultz wrote:
> Hype(r)Threading (it's mostly "hype" by Intel) is not the same
> as actually having a 2nd cpu.
Not the same, sure. That's why I wanted to see the difference :-)
> > So, the results show that encoding with hyperthreading enabled is about
> > 10% faster and the optimal thread number for uniprocessor P4 system
> > without
>
> I've very suprised to see those results! When I enabled HT the
> entire system slowed down and encoding ran about 15-20% *SLOWER*. That
> was on a real dual P4/Xeon. With HT enabled the system showed
> 4 "cpus" (of which only 2 were the real/heavy ones and 2 were the
> partial/lightweight ones). The kernel treated all 4 pretty much
> the same and scheduled processes accordingly - and that is something
This was a 2.4.x kernel from the kernel.org? I'm not using them since a long
time because they really SUCK compared to RedHat kernels.
RedHat's 2.4.x kernels have a big set of features from 2.6.x kernels: they are
low-latency, preemptive, have NPTL threads etc. And they know difference
between real SMP system & system with hyperthreading and shedule processes
differently. This can explain the difference.
> Place a yuvdenoise, yuvmedianfilter, or y4mdenoise in the pipeline and
> see what happens :-)
BTW, it will be really interesting - what will be the difference in this case,
than processor has more different tasks to run? Can you propose additions to
my command line ("cat stream.yuv | yuvscaler -n n -O SVCD 2> /dev/null |
mpeg2enc -f 4 -F 1 -p -M -o stream.m2v 2> /dev/null") to
test?
> Oh, you're not running the CVS version. That's where changes/fixes
> would be made if bottlenecks/bugs are found and fixed as a result of
> testing/profiling/etc...
Ok, I'll try with CVS version also.
Alexei
---
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] mpeg2enc + Pentium-4 Hyperthreading testing results
Hi! On Tuesday 06 July 2004 13:19, Bernhard Praschinger wrote: > > OS: Linux, Fedora Core 1, kernel-2.4.22-1.2194.nptl (and its SMP version) > > Software version: mjpegtools-1.6.2 > > The values should be even better with a new 2.6.x Kernel I'll try to retest it with 2.6.x kernel. Now, finally, NVidia drivers are available :-) > Were you able you use your system like normal ? Or was moving the mouse > a bit tricky ? Hmm, actually I was tring to not move the mouse - to get consistent results :-) I'll retest. As for HT system than it was not a problem - I was able to work normally during encoding except windows/programs switching - it became more slower. > But you can compensate that with filtering the video. Than yuvdenoise > needs about 85% of one cpu and the other CPU is decoding the images (i > was lazy and used a mjpeg encoded avi the cpu had to decode) and doing > some encoding. Ok, so I just need to add yuvdenoise to the pipe? No problem :-) Alexei --- 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] DVD "safe" limits
Hi! > In your experience, is it "safe" (same meaning as above) to use variable > bitrate? Yes. > VBR is automatically set when using -q, right? > What becomes then the meaning of -b parameter? Does it become the > _maximum_ bitrate? Yes. This is mentioned in the docs :-) Alexei --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] the -S option
Hi! On Saturday 16 August 2003 22:05, Florin Andrei wrote: > Is there a way to accomplish this task (specifying where to split) just > once, just in mplex? The fact that now i have to re-convert the whole > thing again is rather frustrating, since it's a very slow process. I think that it is impossible with mplex. But don't worry, you don't need to reconvert it - you can use tcmplex from transcode to multiplex any interval you want - it doesn't understand mpeg2enc splits and will just ignore them ;-) Alexei --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] the -S option
Hi!
> Meanwhile i realised i'll have to reconvert anyway, that's an amateur
> video with high detail and LOTS of motion, so i'll probably have to use
> -I 2 instead of -I 1.
> Even at -b 9000, i still get square artifacts, that's how bad it is...
I'm not sure that it will help. You can try to use bigger value for -r option
(for ex., 24) - it will encode slower but produce _much_ better results in
the motion scenes compared to default (16). AFAIK maximum is 32.
> > you can use tcmplex from
> > transcode to multiplex any interval you want - it doesn't understand
> > mpeg2enc splits and will just ignore them ;-)
>
> Good point.
> But... I remember, long time ago, having some issues with using the
> multiplexer from one application to mux streams generated with the other
> (transcode vs. mjpegtools).
> What is your experience with using the "other" muxer? (tcmplex with
> mjpegtools, or mplex with native transcode MPEG codec)
transcode doesn't have native MPEG codec :-) It uses bbmpeg or mpeg2enc -
depends on the command line switches ;-))) tcmplex works fine with streams
produced by mpeg2enc - but doesn't understand mpeg2enc splits and works a bit
slower than mplex. At least these were the only differences I've noticed.
Oh, one more difference - vcdimager ("stable", 0.6.x) can crash on the file
produced by mplex and doesn't crash on the file from tcmplex. Though it is
vcdimager bug, newer versions (0.7.14) don't have the bug.
Alexei
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] the -S option
Hi! On Sunday 17 August 2003 00:42, Florin Andrei wrote: > I find it surprising i'm having so many difficulties and yet results are > only moderately good (not perfect) while commercial DVDs, at the same > resolution (720x480), using smaller bitrate, offer a much better image > quality. > Is it due to the codecs they use? Probably other factors matter too - for example, cameras ;-))) BTW, if you want maximum quality you should not run mpeg2enc with default settings - increase -r (-r 24, -r 32) and set -4 -2 to 1 (-4 1 -2 1). Warning: these settings will make your encoding SLOW. Default settings is a compromise between speed & quality. Also it is possible to play with -N, -H and different quantization matrices: tmpgenc & kvcd matrices can give you significantly better compression (so you can decrease -q and get a better quality for the same file size). And CVS version provides better quality compared to 1.6.1 with the same settings (thanks to Steven to convince me :-). Alexei --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Mjpegtools 1.6.2 rc1 (Upgrading!)
Hi! On Monday 25 August 2003 15:01, Ronald Bultje wrote: > > abandoned that course when I was asked for libquicktime-devel, and found > > out that the libquicktime people didn't have any official rpms for > > download. The mjpegtools project can't be blamed for that, though. > > If I'm correct, using a --nodeps should work. We don't specifically need > it. I just added it so that normal people will understand that they can > get quicktime support by this. And libquicktime rpms are available on freshrpms.net... Alexei --- 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] Re: mpeg2enc custom matrix
Hi! > Just a few small, easy, dumb questions ... :-) > > 1. In what way are the kmpg and tmpgenc matrices better >than the default? (It would be great if I could get >a technical explanantion as well as an understandable >one.) ;-) kvcd & tmpgenc matrices provide better compression with comparable (read - the same) quality. kvcd guys say that it also reduces the blockiness in the dark areas and so even improves quality. I've tested it on some different videos and it seems to me that this is true but I can't say this for sure because I always knew how was the file encoded, so, may be it was only perception ;-) Files produced with these matrices usually have bigger I-frames and always smaller P & B-frames. Movies have much more P & B frames, this is the source of savings. Though somebody else should explain why these matrices work this way :-) > 2. And _if_ they are really better, then why isn't one >of them the default? Because it is not default in the standard? > 3. Which of them is better, the kvcd one or the tmpgenc >one? Assuming that they have the same quality kvcd one is better - it will always give you smaller files than TMPGenc. Compression depends on the source material, in my experiments the biggest difference was on the videos with lots of dark scenes. In my experiments maximum difference in file size (compared to default matrix) was more than 30% though typical file size savings are about 15-20% in case of kvcd and 8-15% in case of TMPGenc. Alexei --- 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] problem with mplex
Hi! On Tuesday 09 September 2003 04:32, Ralf Haller wrote: > I want t multiplex a mpeg file for creating a VCD with vcdimager. I > created a video stream and an audio stream with the required bitrates. Are you sure? Look here: >INFO: [mplex] VIDEO STREAM: e0 ... >INFO: [mplex] Bit rate: 151 bits/sec ^ ... >INFO: [mplex] AUDIO STREAM: >INFO: [mplex] Bit rate :28672 bytes/sec (224 kbit/sec) ^^^ And target (VCD) data rate is 1411200 - even less that your video data stream bitrate! So, you are making XVCD, VCD that is out of official specs. You should multiplex it as user VCD and provide a maximum bitrate you want: mplex -f 2 -r 1800 ... If your streams are VBR you should pass -V flag also. Alexei --- 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] VCD 2500vbr better quality than SVCD
Hi! On Monday 06 October 2003 04:21, Maarten de Boer wrote: > television want show you the higher resolution anyway). Or do you think > that with the proper settings, my SVCD should look at least as good as > VCD, with the additional advantage of following the standard? Properly encoded SVCD looks significantly better than VCD. Alexei --- 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] Half D1 pixel aspect ratio
Hi! On Saturday 11 October 2003 13:20, Steven M. Schultz wrote: > Try it - it works fine. But 16:9 SVCDs have played correctly only > with software players for me. Are you sure? AFAIR you have a Philips DVD 724 (as I do) and AFAIR I saw in Internet that it will play _NTSC_ 16:9 SVCD without any problems (but not PAL ones). I had some experiments with PAL SVCD 16:9 disks - player played them at 4:3 (though aspect ratio was correct, it just cropped left & right parts of the image to convert 16:9 to 4:3). Alexei --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] MPEG2 encoding performance
Hi! On Tuesday 11 November 2003 17:10, Steven M. Schultz wrote: > Main feature that 1.6.1.90 brought to the party was the -K option > and libquicktime (instead of the old/incompatible quicktime4linux) > support. Since then quite a few improvements have been made. Yes, lots of new features... Can we expect a stable _release_ version anytime soon? Current CVS mjpegtools are FAR better than 1.6.1 but it is impossible to get it in the packaged form - all distributions are packaging the latest release... :-((( Alexei --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] hello
Hi! On Wednesday 03 December 2003 17:13, Paul Miller wrote: > Oddly enough, my SVCDs play fine on my special xbox > (software decoder evox/xbmp), just not on my (sony) DVD > player. > > Well, strictly speaking, they play fine, but the audio skips > horribly. Check fps of your movie. NTSC SVCD should have ~30 (29,97) frames per second. 24 fps is not allowed on SVCD! My hardware DVD player will behave exactly like you are describing in this case. If your source is 24 fps you should encode it with -p (or --3-2-pulldown) command line switch to mpeg2enc. WBW, Alexei --- This SF.net email is sponsored by OSDN's Audience Survey. Help shape OSDN's sites and tell us what you think. Take this five minute survey and you could win a $250 Gift Certificate. http://www.wrgsurveys.com/2003/osdntech03.php?site=8 ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] [mplex] Too many frame drops
Hi! On Thursday 04 December 2003 10:34, [EMAIL PROTECTED] wrote: > I am using ripmake to produce a (non-standard) SVCD, and got Ripmake is your source of the problem: it is NOT ABLE to produce VCD/SVCD because it passes completely STUPID and INCORRECT options to transcode. Even if mplex run will be successfull quality of the resulting video will be VERY BAD. Just don't use it, forget about it, read manual for mpeg2enc/transcode and use them directly - results will be MUCH better. Yes, ripmake looks nice and easy but... :-( Alexei --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] [mplex] Too many frame drops
Hi! > The 3059 value is exactly the sum of the audio and video bitrates, > calculated by the ripmake script. Maybe this ripmake script should > be changed to add this 1-2% margin to the calculated bitrate. Oh, it should be changed A LOT! :-))) If you really want to improve ripmake to the point that it will become usefull to SVCD production than first of all you should completely rewrite bitrate & "-q" calculations. Ripmake doesn't know at all that encoding bitrate for SVCD (and any other VBR encoding by mpeg2enc) specified with -b option to mpeg2enc is the _maximum_ bitrate, not average. Also it doesn't know that in the wast majority of cases "-q 3" (or something like this, some low value) is a very stupid setting for SVCD. In fact, it can't calculate q value, it uses just some stupid preset. So, imagine that you want to encode 1 hour of video to 700mb SVCD: ripmake will encode it with the options like "-b 1800 -q 3". Quality will be awful! Even much worse than VCD from the same source... Also should be fixed some minor problems - like your one with incorrect (and unnecessary) bitrate setting for mplex... Once again - if you want SVCD quality, don't use ripmake for SVCD production. Alexei --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Padding VCD image?
Hi! On Wednesday 17 December 2003 1:42 pm, [EMAIL PROTECTED] wrote: > I posted this question on vcdhelp.com forums and got the following answer: > > --x--- > The problem of "bloating" is almost certainly because your MPEG files > weren't multiplexed in the way that VCDImager wants them. This leads it to > "autopad" the MPEG file (i.e., putting in null data to fit it into the > right sectors) and can inflate the size of the file to quite a large > degree. > > The way to fix this is to make sure that your MPEG files are appropriately > multiplexed before using VCDImager (or other programs that use VCDImager > like VCDEasy). > > You can do this with TMPGEnc. > > Go to Files --> MPEG Tools --> Simple Multiplex. > > Put in your original MPEG file. Change the setting to "MPEG-1 Video CD" > (for VCD compliant MPEG-1 files) or "MPEG-1 Video CD (non-standard)" if you > are making an XVCD. > > Then, save it to a new file. > ---x--- I think that yes, this is the correct answer. > Question for you guys: Is mplex doing something wrong when muxing the > audio/video that makes vcdimager pad the files? What does TMPGEnc do that > mjpegtools cannot? Mplex is doing everething correct if you are multiplexing file as VCD/SVCD MPEG and _not_ if you are multiplexing it as a generic mpeg1/mpeg2. Check your -f setting. Also for VBR mpeg1 you'll need -V. BTW, if the padding takes place vcdimager will warn you. Alexei --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
