On Mon, 1 Nov 2004, Dik Takken wrote:

> >     -q 4 is the practical limit with 5 being the usual value used.
> 
> You mean that -q 4 can also trigger encoder bugs? I would like to get this 

        Ooops - I was unclear on that point.  >= 4 is fine - by "practical
        limit" I intended to say that "4 or greater has not been observed to
        have problems".   Values less than 4 (i.e. <=3) have been reported
        to have errors.

        You have mentioned seeing artifacts (induced by the errors in the
        DCT/iDCT) at -q 1 and 2.  There has been a report or two mentioning
        the same problem with -q 3 (at least on IA32 systems).  The Altivec
        routines have code to check for overflow and then redo the calculations
        to avoid the problem.

> one straight: Which q values can lead to encoding *errors*, not artifacts?

        errors == artifacts in this case.   The arithmetic overflow/truncation 
        is not only an error but it causes visible artifacts.

> I guess this method is safe, because it does not push mpeg2enc into 
> encoding really close to the b value, which leads to artifacts and spikes.

        It's not that the peak and average are too close (or the same).  It's
        that the quantizer scale ('qscale') at -q 1 thru 3 can cause 
        arithmetic errors (overflow) in the MMX/SSE routines.
        
        There will always be spikes until a two pass (or back up and retry)
        method of encoding is used.

> >     think there is a mention about "values below 4 are  extremes" in the 
> >     'howto'.
> 
> It said I should only use those values when I know what I'm doing. Well, I 

        :-)

> didn't because it didn't say what would happen. :) Now I know. :D It does 
> tell about the danger of artifacting, but it does not mention that it can 
> lead to encoding errors.

        Hmmm, "errors" in encoding (often) show up as visible artifacts ;)

        Artifacts are things present in the output that are not part of the 
        original input, in other word: error.

        It's better to leave the qscale at a more conservative level and
        process the data before it enters the encoding process.   An
        'unsharp' filter might be  one thing to try (don't think there is
        one at the moment - I have some notes based on the Gimp unsharp
        filter but I haven't created any working code yet).

        Cheers,
        Steven Schultz



-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Reply via email to