On Tue, 16 Dec 2003, Slepp Lukwai wrote:

> Tried it without any options, same effect. I'm definitely seeing nowhere
> near 40% speedup, which is what boggles me. I expected at least
> reasonable gains of 25%.

        I think that has to do with the -I setting...

> Sorry, upon further testing, I actually average around 14fps at DVD
> quality (720x480, 9800kbit/s). (see all the details of my command lines

        Ah, that's more like it then.   

> It's interesting that I'm faster with dual 2100s than the dual 2800 (or
> at least on par). I suppose it really comes down to command line
> options, but you would need to compare those yourself (since I haven't

        Friend of mine has dual 2400s and my setup is ~10-15% faster as I
        recall - he's getting around 11fps as a rule where I see 14 or so.

        I'm usually adding a bit of overhead with the chroma conversion.  I
        build smilutils with ffmpeg/libavcodec (to use ffmpeg's DV codec)
        and then run the data thru something like:
        "smil2yuv -i 2 file.dv | filters | y4mscaler -O chromass=420_MPEG2 |..."

        Produces better output that the default which uses libdv but does
        cost a bit in cpu use.

> According to the docs -I 1 turns on interlacing support, and causes
> un-needed overhead if it is known progressive material. Hence the -I 0
> (plus transcode sets that, though I could override it).

        But unless you have the raw 23.976fps progressive data (with the 3:2
        pulldown undone) then I think '-I 1' is the option to use.   But then 
        I might be confused (wouldn't be the first time ;)).

        That would explain why the encoding rate I see is lower since I'm
        using -I 1.

> >     wrong I'm sure someone will tactfully point that out ;)) the speedup
> >     comes from the motion estimation of the 2 fields/frame being done in
> >     parallel.
> 
> Oh. Son of a... If that's all it is...

        Yep - I'm fairly sure that is why you're not seeing any improvement
        when using "-M 2".

> >     without B frames.   Those are computationally a lot more expensive
> >     than I or P frames.   "-R 0" will disable B frames.
> 
> I just enabled that, and that's how I'm hitting 15fps instead of 8, and
> the quality is good and the size is just fine.

        Great!   It takes, from what I've seen, extraordinarily clean sources
        before -R 0 has no or little effect.

> to their potentials and give me the equivalent of a 4200+ ;> If it takes
> 6 hours to transcode a movie because I set -r32 (I noticed a larger
> difference with -4 -2 options, btw, than -r16 vs -r32), that's fine, but

        Yep - "-4 1" will close to double the time over "-4 2" and the 
        difference in bitrate/filesize is measured in tenths of a percent. 
        Hardly worth it.   Not all that much difference between "-4 2" and
        "-4 3" though.

> >     better results (especially with clean source material) can be obtained
> >     with "-E -8" or perhaps "-E -10".
> 
> Until I upgraded to .92, I didn't have those options. I'm using them

        On noisy source material the -E option has almost no effect  but the
        cleaner the input the more effect even modest values of -E have.

> now, in combination with -Q, but I find the artifacts are almost never
> there (I used to do -q 4 and -Q 4.0, and it looked about the same as the
> 5/3.0).

        Perhaps Richard Ellis could chime in with his experiences with -Q ;)

> >     Right, with -I 0 the cpus take turns but there's little parallelism.
> 
> And again, son of.... I didn't realize the parallelization was done
> based on interlacing settings.
        
        Looking back on it that makes sense though.   A P frame depends on the
        preceeding P frame - rather sequential in nature since you can't
        move on to the next one without completing the first one...

> The MPEG decoding doesn't take much, and the pipe overhead is negligble,

        Pipe overhead sneaks up on you though.   One pipe?  Not a real problem,
        two?  Begins to be noticed but isn't too bad.   Four or five?   Yeah,
        it starts to take a hit on the overall speed of the system - the data
        has to go up/down thru the kernel all those times and that's not "free".

> (As I write this, I'm still waiting for the -M 2 run to finish, so it'll
> arrive before the tests results to Bernhard make it out).

        You might try, for timing purposes, without -I 0 and see what, if any
        effect that has.   Might be a useful data point.

        Cheers,
        Steven Schultz



-------------------------------------------------------
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

Reply via email to