On Sun, 21 Sep 2003, Richard Ellis wrote:
> For the numbers I posted, the q value was 7. It is interesting that
> -N would have differing effects depending on the -q value. That may
Initially I thought it unusual but after thinking about it a
bit it's to be expected. The low
On Sun, Sep 21, 2003 at 05:51:19PM -0700, Steven M. Schultz wrote:
>
> On Sun, 21 Sep 2003, Richard Ellis wrote:
>
> > The only difference between these files was different -N values.
> > All other denoise/mpeg2enc parameters were identical.
>
> What value are you using for -q? What I am find
On Sun, 21 Sep 2003, Richard Ellis wrote:
> The only difference between these files was different -N values. All
> other denoise/mpeg2enc parameters were identical.
What value are you using for -q? What I am finding is that
the effect of -N changes as -q is varied - especially
On Fri, Sep 19, 2003 at 10:47:35PM -0700, Steven M. Schultz wrote:
>
> 4 encodings were done using -N of 0, 0.5, 1.0 and 1.5 (and 2
> different -q values, and using yuvdenoise in -f and -l modes).
> Quite an exhaustive (and time consuming ;)) set of runs.
> ...
I have some more real world numbers
On Sat, 20 Sep 2003, Richard Ellis wrote:
> Yes, only 5%, but it's a 5% file size change, with only a 0.5% change
> to the value of -N. Or in other words, the -N value looks to
> possibly have a 10x effect on resultant file size.
>
That's not quite the way to look at it I believe. Is
On Fri, Sep 19, 2003 at 07:02:54PM -0700, Steven M. Schultz wrote:
>
> > The -N parameter does work quite well for shrinking a file, but
> > it seems it's a bit sensitive. In a test run, with -N 0.0 I got
> > a file size of 748,032 kbyte. With -N of 0.1 I got 708,956 kbyte
> > on the same input.
On Fri, 19 Sep 2003, Richard Ellis wrote:
> Increasing -X a little (200 vs. 100) does seem to make -Q have a bit
> more effect, if the fact that the quant=xx.xx value bounces around
> much more during encoding is partially caused by -Q.
The test I ran (with an SVCD encoding) showed a ~1%
On Wed, Sep 17, 2003 at 07:57:14PM -0700, Steven M. Schultz wrote:
>
> On Wed, 17 Sep 2003, Richard Ellis wrote:
>
> > is driven by Q (in that section at least) was reworked quite a bit in
> > January. That would account for the difference I'm seeing in the new
> > mpeg2enc's Q that does not see
On Wed, 17 Sep 2003, Richard Ellis wrote:
> Thanks for the pointer, yes, I looked at the diffs and the code that
Welcome.
> is driven by Q (in that section at least) was reworked quite a bit in
> January. That would account for the difference I'm seeing in the new
> mpeg2enc's Q that d
On Wed, Sep 17, 2003 at 03:08:25PM -0700, Steven M. Schultz wrote:
>
> On Wed, 17 Sep 2003, Richard Ellis wrote:
>
> > Has anyone else noticed that the -Q parameter to mpeg2enc v 1.6.1.90
> > seems to have much less effect than it did in version 1.6.1? I've
>
> ...
> If you look at
On Wed, 17 Sep 2003, Richard Ellis wrote:
> Has anyone else noticed that the -Q parameter to mpeg2enc v 1.6.1.90
> seems to have much less effect than it did in version 1.6.1? I've
No, I haven't noticed. But then I haven't used -Q since I was
warned of possible artifacts. Tha
Has anyone else noticed that the -Q parameter to mpeg2enc v 1.6.1.90
seems to have much less effect than it did in version 1.6.1? I've
got one pair of encodes (same capture file input to both) that I ran
yesterday where using -Q 0.0 and -Q 4.0 resulted in exactly the same
size encoded file. Unde
12 matches
Mail list logo
