headers
guphex guphex | 6 Jan 2003 20:12
Picon
Favicon

unsuscribe guphex <at> hotmail.com


>From: Zdenek Kabelac <kabi <at> users.sourceforge.net>
>Reply-To: ffmpeg-devel <at> lists.sourceforge.net
>To: ffmpeg-devel <at> lists.sourceforge.net
>Subject: [Ffmpeg-devel] CVS: ffmpeg/libavcodec utils.c,1.50,1.51
>Date: Mon, 06 Jan 2003 10:10:31 -0800
>
>Update of /cvsroot/ffmpeg/ffmpeg/libavcodec
>In directory sc8-pr-cvs1:/tmp/cvs-serv14301
>
>Modified Files:
>	utils.c
>Log Message:
>* avoid usage of next/last buffer after flush
>   (but there still something wrong when the first frame isn't keyframe)
>
>
>Index: utils.c
>===================================================================
>RCS file: /cvsroot/ffmpeg/ffmpeg/libavcodec/utils.c,v
>retrieving revision 1.50
>retrieving revision 1.51
>diff -u -d -r1.50 -r1.51
>--- utils.c	5 Jan 2003 15:57:09 -0000	1.50
>+++ utils.c	6 Jan 2003 18:09:27 -0000	1.51
> <at>  <at>  -677,7 +677,8  <at>  <at> 
>             if(s->picture[i].data[0] && (   s->picture[i].type == 
>FF_BUFFER_TYPE_INTERNAL
>                                          || s->picture[i].type == 
>FF_BUFFER_TYPE_USER))
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Niedermayer | 6 Jan 2003 20:53
Picon
Picon

Re: CVS: ffmpeg/libavcodec/i386 dsputil_mmx.c,1.43,1.44

Hi

On Monday 06 January 2003 11:47, D Richard Felker III wrote:
> On Mon, Jan 06, 2003 at 01:55:54AM -0800, Michael Niedermayer wrote:
> > Update of /cvsroot/ffmpeg/ffmpeg/libavcodec/i386
> > In directory sc8-pr-cvs1:/tmp/cvs-serv19077
> >
> > Modified Files:
> > 	dsputil_mmx.c
> > Log Message:
> > 1000l (push & esp) using mangle now ...
>
> qpel still seems broken on my k6...i get random bright flashing blocks
> all over with it enabled. :( i tested with very minimal options, just
> bitrate and qpel.
hmm, c & mmx qpel give binary identical results (qpel + hq + 4mv + 2 bframes) 
for me ...
could u try to outcomment the SET_QPEL_FUNC* stuff in dsputil_mmx.c and tell 
me which of them is buggy?

[...]

Michael

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 13 comments |
headers
D Richard Felker III | 6 Jan 2003 21:19

Re: CVS: ffmpeg/libavcodec/i386 dsputil_mmx.c,1.43,1.44

On Mon, Jan 06, 2003 at 08:53:06PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Monday 06 January 2003 11:47, D Richard Felker III wrote:
> > On Mon, Jan 06, 2003 at 01:55:54AM -0800, Michael Niedermayer wrote:
> > > Update of /cvsroot/ffmpeg/ffmpeg/libavcodec/i386
> > > In directory sc8-pr-cvs1:/tmp/cvs-serv19077
> > >
> > > Modified Files:
> > > 	dsputil_mmx.c
> > > Log Message:
> > > 1000l (push & esp) using mangle now ...
> >
> > qpel still seems broken on my k6...i get random bright flashing blocks
> > all over with it enabled. :( i tested with very minimal options, just
> > bitrate and qpel.
> hmm, c & mmx qpel give binary identical results (qpel + hq + 4mv + 2 bframes) 
> for me ...
> could u try to outcomment the SET_QPEL_FUNC* stuff in dsputil_mmx.c and tell 
> me which of them is buggy?

I just commented out all the SET_QPEL_FUNC lines for mmx2 and 3dnow
and it made the output a lot worse... Rather than just a few random
blocks flashing there are bogus looking blocks everywhere that appear
to be mostly just the DC coefficient along with some sharp high
frequency noise in the horizontal direction. Could you perhaps
elaborate more on what you want me to test? Maybe I need to tell it to
set the C ones instead?

Rich
(Continue reading)

Permalink | Reply | 12 comments |
headers
Zdenek Kabelac | 6 Jan 2003 21:20
Picon

Re: CVS: ffmpeg/libavcodec/i386 dsputil_mmx.c,1.43,1.44

> > me which of them is buggy?
> 
> I just commented out all the SET_QPEL_FUNC lines for mmx2 and 3dnow
> and it made the output a lot worse... Rather than just a few random
> blocks flashing there are bogus looking blocks everywhere that appear
> to be mostly just the DC coefficient along with some sharp high
> frequency noise in the horizontal direction. Could you perhaps
> elaborate more on what you want me to test? Maybe I need to tell it to
> set the C ones instead?

Why don't you just dissable setting of some function poiters ??
(So the plain C version will be left there...)

--

-- 
  .''`.    Zdenek Kabelac  kabi <at> {debian.org, users.sf.net, fi.muni.cz}
 : :' :          Debian GNU/Linux maintainer - www.debian.{org,cz}
 `. `'                          Overclocker's house :)
   `-              http://www.bbspot.com/News/2002/08/house.html        

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 11 comments |
headers
D Richard Felker III | 6 Jan 2003 21:32

Re: CVS: ffmpeg/libavcodec/i386 dsputil_mmx.c,1.43,1.44

On Mon, Jan 06, 2003 at 09:20:13PM +0100, Zdenek Kabelac wrote:
> > > me which of them is buggy?
> > 
> > I just commented out all the SET_QPEL_FUNC lines for mmx2 and 3dnow
> > and it made the output a lot worse... Rather than just a few random
> > blocks flashing there are bogus looking blocks everywhere that appear
> > to be mostly just the DC coefficient along with some sharp high
> > frequency noise in the horizontal direction. Could you perhaps
> > elaborate more on what you want me to test? Maybe I need to tell it to
> > set the C ones instead?
> 
> Why don't you just dissable setting of some function poiters ??
> (So the plain C version will be left there...)

That's how I figured it would work, but like I said, it's not
working...

Rich

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 10 comments |
headers
Michael Niedermayer | 6 Jan 2003 22:59
Picon
Picon

Re: CVS: ffmpeg/libavcodec/i386 dsputil_mmx.c,1.43,1.44

Hi

On Monday 06 January 2003 21:32, D Richard Felker III wrote:
> On Mon, Jan 06, 2003 at 09:20:13PM +0100, Zdenek Kabelac wrote:
> > > > me which of them is buggy?
> > >
> > > I just commented out all the SET_QPEL_FUNC lines for mmx2 and 3dnow
> > > and it made the output a lot worse... Rather than just a few random
> > > blocks flashing there are bogus looking blocks everywhere that appear
> > > to be mostly just the DC coefficient along with some sharp high
> > > frequency noise in the horizontal direction. Could you perhaps
> > > elaborate more on what you want me to test? Maybe I need to tell it to
> > > set the C ones instead?
> >
> > Why don't you just dissable setting of some function poiters ??
> > (So the plain C version will be left there...)
>
> That's how I figured it would work, but like I said, it's not
> working...
hmm very strange, are u sure that its buggy at all? what bitrate /resolution 
do u use? does it happen at constant quantizer 2 too?

[...]

Michael

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
(Continue reading)

Permalink | Reply | 9 comments |
headers
Fabrice Bellard | 6 Jan 2003 23:10
Picon
Favicon

Re: Re: Questions about FFT implementations & performance

Romain Dolbeau wrote:
> Fabrice Bellard wrote:
> 
>  > Currently it is only used by the WMA decoder. Soon, it will also be used
>  > by the AC3 encoders and decoders.
> 
> So I guess it's worth adding to the ppc/ subdirectory.

Yes!

>  > > Second, is the SSE implementation supposed to work
>  > > even if it's not used (except for the explicitely
>  > > not handled inverse case) ?
>  >
>  > It worked someday. I disabled it mainly because I wanted to modify the
>  > configure/Makefile to compile it only if gcc 3.2 was being used.
>  >
>  > > I've been trying to do an AltiVec-optimized version
>  > > of the code, and whereas the naive implementation
>  > > works (and is marginally faster than the C code
>  > > using fft-test), I just can't get the version cloned
>  > > from the SSE code to work (it's much faster, but
>  > > the results are wrong :-)
>  >
>  > Maybe the constant table is not generated correctly. I'll make some
>  > tests next week.
> 
> It's not the SSE version that's broken, it's my brain.
> I forgot that reordering words inside a vector isn't
> the same on X86 little-endian processors and on ppc
(Continue reading)

Permalink | Reply | 0 comments |
headers
D Richard Felker III | 6 Jan 2003 23:34

advanced adaptive quantization

Hey. With all the recent business about improving PSNR (Rémi's tests,
Michael's new features, etc.) I've been wondering if it might be more
beneficial, at least for mere mortals like myself without 2 GHz
Athlons for encoding, to work more on improving perceptual quality
with better adaptive quantization. A couple ideas...

1) IMHO, the number one annoying artifact in moderate to low bitrate
encoding comes from the presence or large areas of low-frequency
material (especially solid color) immediately adjacent to a block with
a sharp boundary. Unless the quantizer for the block with the boundary
in it is really low, you get lots of ringing in the part of the
low-frequency 'background' present in the 'boundary' block, which
makes the block structure really stand out. This is particularly
noticable in animated material, for instance. Presumably, the natural
solution to this problem should be to detect such 'boundary' blocks
and sharply decrease the quantizer for their MB, stealing bits from
the low-frequency blocks nearby. The only question is whether it would
steal too many bits to be useful. I hope my explanation was clear; if
not I can provide some pictures showing what I mean.

2) Lumi/dark masking is pretty good as-is, but I think it could be a
lot more powerful if it took spatial and temporal information into
consideration. For instance, sharply increasing the quantizer on all
dark macroblocks may be a bad idea, but using huge quantizers on dark
macroblocks directly adjacent to very bright ones should be fine. Even
larger quantizers should work for dark macroblocks that are
immediately adjacent to a macroblock that just transitioned from dark
to very bright in the last few frames, since the human eye won't
perceive the dark area very well at all after the sudden nearby
increase in brightness.
(Continue reading)

Permalink | Reply | 4 comments |
headers
D Richard Felker III | 6 Jan 2003 23:38

Re: CVS: ffmpeg/libavcodec/i386 dsputil_mmx.c,1.43,1.44

On Mon, Jan 06, 2003 at 10:59:20PM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Monday 06 January 2003 21:32, D Richard Felker III wrote:
> > On Mon, Jan 06, 2003 at 09:20:13PM +0100, Zdenek Kabelac wrote:
> > > > > me which of them is buggy?
> > > >
> > > > I just commented out all the SET_QPEL_FUNC lines for mmx2 and 3dnow
> > > > and it made the output a lot worse... Rather than just a few random
> > > > blocks flashing there are bogus looking blocks everywhere that appear
> > > > to be mostly just the DC coefficient along with some sharp high
> > > > frequency noise in the horizontal direction. Could you perhaps
> > > > elaborate more on what you want me to test? Maybe I need to tell it to
> > > > set the C ones instead?
> > >
> > > Why don't you just dissable setting of some function poiters ??
> > > (So the plain C version will be left there...)
> >
> > That's how I figured it would work, but like I said, it's not
> > working...
> hmm very strange, are u sure that its buggy at all? what bitrate /resolution 
> do u use? does it happen at constant quantizer 2 too?

640x352, 1 mbit/sec. I just tried it with constant qscale=2, same
thing. And I tried a 320x192 movie too. I'm using mencoder. Would you
like samples of the broken output files?

Rich

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 8 comments |
headers
Michael Niedermayer | 6 Jan 2003 23:44
Picon
Picon

Re: CVS: ffmpeg/libavcodec/i386 dsputil_mmx.c,1.43,1.44

Hi

On Monday 06 January 2003 23:38, D Richard Felker III wrote:
> On Mon, Jan 06, 2003 at 10:59:20PM +0100, Michael Niedermayer wrote:
> > Hi
> >
> > On Monday 06 January 2003 21:32, D Richard Felker III wrote:
> > > On Mon, Jan 06, 2003 at 09:20:13PM +0100, Zdenek Kabelac wrote:
> > > > > > me which of them is buggy?
> > > > >
> > > > > I just commented out all the SET_QPEL_FUNC lines for mmx2 and 3dnow
> > > > > and it made the output a lot worse... Rather than just a few random
> > > > > blocks flashing there are bogus looking blocks everywhere that
> > > > > appear to be mostly just the DC coefficient along with some sharp
> > > > > high frequency noise in the horizontal direction. Could you perhaps
> > > > > elaborate more on what you want me to test? Maybe I need to tell it
> > > > > to set the C ones instead?
> > > >
> > > > Why don't you just dissable setting of some function poiters ??
> > > > (So the plain C version will be left there...)
> > >
> > > That's how I figured it would work, but like I said, it's not
> > > working...
> >
> > hmm very strange, are u sure that its buggy at all? what bitrate
> > /resolution do u use? does it happen at constant quantizer 2 too?
>
> 640x352, 1 mbit/sec. I just tried it with constant qscale=2, same
> thing. And I tried a 320x192 movie too. I'm using mencoder. Would you
> like samples of the broken output files?
(Continue reading)

Permalink | Reply | 7 comments |

Gmane