Hi -

On Wed, 21 Jul 2004, Marc Gregoire wrote:

        Combination reply to the last couple postings ...

> >     What size/resolution are the slides (source .jpg files)?   Are they 
> 
> I had scaled the original image to 720x576 with an external program and used 
> the scaled version for both mpeg2enc and the other encoder.

        I'm still curious what the originals were before any scaling - were
        they from a multi-megapixel camera, a scanner, how were they converted
        to .jpg, etc.   

        One other thought just hit me - if you can get the image into PPM
        format (which should be a lossless operation) then y4mscaler (and
        other mjpegtools programs) can be used.  That would avoid going thru
        JPG which may introduce ringing at edges.

> I scaled the image before encoding with another program. (720x576) This 
> scaled image can be seen at:
> http://www.nuonsoft.com/temp/flower_orig.jpg

        I was hoping to get the raw unscaled/processed original so I could
        run an experiment or two and see if the distortion is coming in during
        the conversion to .jpg and scaling.  From what I've seen that is the 
        case - look at the flower_orig.jpg at a 2x or 4x zoom in the GIMP, there
        is the same ringing on the edges of the flowers and so on as the 
        mpeg2enc version shows. 

> In response to your other reply:
> I was using an older version of mpeg2enc as can be seen from the -h parameter 
> which is -H in the latest version.

        Ok.  Yeah, using -h wasn't a good idea since that's conventionally
        the way to request help or the usage summary.

>So I downloaded mjpegtools 1.6.2 and compiled it with cygwin without a problem.
        
        Super!   I was fairly sure that was ok - but after that release
        a lot of changes were made.  Some of those changes stood a good chance
        of breaking the win32 build.   If you can try building the CVS version
        it'd be of interest (apparently none of the developers has much 
        interest in windows - I know I don't ;)).

> Using that mpeg2enc version, changing -h to -H I get almost the same 
> results. Even with a -q 1, the filesize just barely increases.

        The largest file I got was about 61000 bytes or so.   Which is
        correct - even with a small number (1) of frames the rate control
        of mpeg2enc is better than the other encoder and is attempting to
        keep the bitrate out of the stratosphere.

> Even when I increase the bitrate with -b to 15000 (which is way to high 
> for DVD !) I get a .M2V of barely 100 KB.

        True - but, that's just 1 frame.  Peaks need to be a bit longer
        in duration than that (apparently) to cause problems - you definitely
        couldn't have that as any kind of longer term average.

> If you find the time, could you take a look at the original image I posted 

        Yes, I took a look at the image and experimented for a little while.

        One part of the experiment does require, I believe, the CVS version
        of mpeg2enc because a bug was recently fixed.   Until a few days
        ago the "--no-constraints" option was broken - the effect of that
        breakage was that mpeg2enc would enforce the maximum bitrate for
        [EMAIL PROTECTED] (Main Profile @ Main Level), there was no way to give huge
        values for -b.

> .M2V generated by mpeg2enc and by the commercial encoder. The results are:
> For mpeg2enc:

>    INFO: [???] No. I Frames    :        1 avg. size 58161 bytes
>    INFO: [???] No. P Frames    :        0 avg. size     0 bytes
>    INFO: [???] No. B Frames    :        0 avg. size     0 bytes
>    INFO: [???] Average bit-rate : 11632000 bits/sec
>    INFO: [???] Peak bit-rate    :        0  bits/sec
> 
> For the other encoder:
>    INFO: [???] No. I Frames    :        1 avg. size176348 bytes
>    INFO: [???] No. P Frames    :        0 avg. size     0 bytes
>    INFO: [???] No. B Frames    :        0 avg. size     0 bytes
>    INFO: [???] Average bit-rate : 35269600 bits/sec
>    INFO: [???] Peak bit-rate    :        0  bits/sec

> So somehow the commercial DVD author package is creating a .M2V with a 
> reported average bitrate of 35 Mbit. This really confuses me

        Averages require more than 1 sample to be significant :)   1 frame
        isn't enough to compute an average.

        In fact for 1 frame you don't even need mplex.   Just take the size
        of the frame, multiply by 25 (frames/sec) and then by 8 (bits/byte).

        That's all mplex is really doing in this case.

        Thus it appears that the rate control for the other encoder is
        rather wacked ;)

> tested the DVD on (standalone and software players). I thought DVD's

        Well, software players will play anything subject to the available
        cpu power.

> were limited to something around 10 Mbit max.

        They are - and if you created a stream at the bitrate above no player
        around would touch the resulting disc.   But I wouldn't be surprised
        if there were a player somewhere that was allergic to 170KB frames.

> When multiplexing (with a silent audio-frame) the commercial generated .M2V file 
> with mplex I do get the following warnings:
> ++ WARN: [???] Stream e0: data will arrive too late sent(SCR)=13019 
> ++ required(DTS)=0

        That's because the VBV (Video Buffer Verifier) size is too small - 
        that's the "-b" option to mplex.    The VBV size is correct for up to
        ~10Mb/s but if you get a huge spike (as in ~35Mb/s) then the default
        220KB buffer isn't the right size any more.

        HDTV (which in the US uses a 19.8Mb/s stream) has a VBV of 488KB for
        example.

        Ok, now on to the results of my testing this afternoon/evening.

        Created the Y4M file with:

jpeg2yuv -n 1 -f 25 -I p -j flower_orig.jpg > flower_orig.y4m

        Then encoded that with:

cat flower_orig.y4m | mpeg2enc -q 1 --no-constraints -b 30000 -V 488 -f 8 -I 0 -4 1 -2 
1 -D 10 --keep-hf -o flower.m2v

        (I used 'cat' so I could easily place other filters inline before the
        encoder if I wanted to - and indeed using yuvmedianfilter was one
        that I tried, seemed to work ok).

        Note: the 30Mb/s rate and the use of a large VBV size.  To go with
        higher rates I'd need to bump up -V some more but for now 30Mb/s was
        enough.

        The resulting .m2v file size is: 

        -rw-rw-r--  1 sms   wheel       155345 Jul 21 10:35 flower.m2v

        If I used -b 35000  I think the size (and appearance) would be almost
        identical to the other encoder's.

        mplex -b 488 -o /dev/null flower.m2v 
        reports:  Average bit-rate : 31068800 bits/sec

        Now to view the result it's necessary to decode the .m2v file and
        get it to something the GIMP can display.  For this I used 'mpeg2dec'
        (from the libmpeg2 project).  Ordinarily I'd use MPlayer but it chokes
        on 1 frame .m2v files ;(

        mpeg2dec -o pgm flower.m2v

        produces a file that 'pgmtoy4m' (from the cvs version of mjpegtools)
        can convert to a Y4M file.  From Y4M to PPM is done with 'y4mtoppm'
        of course.

        cat 0.pgm | pgmtoy4m | y4mscaler -O chromass=444 | y4mtoppm -L > 0.ppm

        Then use the GIMP to view 0.ppm (not going to .jpg at this point
        avoids further degradation).   The 0.ppm file is large of course
        at "1244175 Jul 21 10:35 0.ppm" - even bzip2'd it's 674580 bytes.

        The differences between encoders is, as you'd expect, much less when
        comparable (but wildly high) bitrates are used.   Not identical but
        close enough.

        If the image were processed or the data filtered the bitrate can be
        left at "sane" levels and the appearance improved that way.   Perhaps
        a higher quality scaling method would exhibit less ringing on the
        edges - that would be one thing to try.   Another thing to try would
        be processing the downsized image with the GIMP - perhaps a slight
        blur or median filter would help.    One thing I did try, and it dropped
        the bitrate like a rock was add 'yuvmedianfilter' to the command
        sequence:

cat flower_orig.y4m | yuvmedianfiler | \
mpeg2enc -q 1 --no-constraints -f 8 -I 0 -4 1 -2 1 -D 10 --keep-hf -o flower.m2v

        Came out looking quite decent - on a typical TV set I doubt you'd be
        able to tell the difference between that and the original.

        An interesting experiment would be to convert from BMP to PPM (which
        is lossless) instead of JPEG.   Then use 'ppmtoy4m' to convert to Y4M
        (lossless) and use 'y4mscaler' with a 6 or 7 tap sinc scaling kernel -
        that is lossy of course BUT it's different than JPEG's lossy 
        compression.   Might result in better data going into the encoder but
        then it might not make all that much difference - have to try it and
        see what happens.

        Cheers,
        Steven Schultz



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Reply via email to