Re: Re: Problems compiling libavcodec with SuSE 9.0 gcc 3.2 compiler

Hello,
On Sun, Feb 29, 2004 at 11:10:27PM +0100, Michael Niedermayer wrote:
[skipped]

> > Patch attached.
> applied

Thanks you. Here is another patch. Somehow when I was compiling ffmpeg,
postproc compiled OK, but with MPlayer it fails.
Patch attached.

--

-- 
With best wishes
Dmitry Baryshkov

? libavcodec/amr_float
? libavcodec/amrwb_float
Index: libavcodec/libpostproc/postprocess.c
===================================================================
RCS file: /cvsroot/ffmpeg/ffmpeg/libavcodec/libpostproc/postprocess.c,v
retrieving revision 1.92
diff -u -r1.92 postprocess.c
--- libavcodec/libpostproc/postprocess.c	31 Jan 2004 22:58:32 -0000	1.92
+++ libavcodec/libpostproc/postprocess.c	1 Mar 2004 08:10:31 -0000
 <at>  <at>  -104,13 +104,13  <at>  <at> 
 //#define NUM_BLOCKS_AT_ONCE 16 //not used yet

 #ifdef ARCH_X86
-static uint64_t __attribute__((aligned(8))) w05=		0x0005000500050005LL;

Re: Re: Problems compiling libavcodec with SuSE 9.0 gcc 3.2 compiler

On Mon, Mar 01, 2004 at 11:16:28AM +0300, Dmitry Baryshkov wrote:
> Hello,
> On Sun, Feb 29, 2004 at 11:10:27PM +0100, Michael Niedermayer wrote:
> [skipped]
> 
> > > Patch attached.
> > applied
> 
> Thanks you. Here is another patch. Somehow when I was compiling ffmpeg,
> postproc compiled OK, but with MPlayer it fails.
> Patch attached.

Or even better patch.

--

-- 
With best wishes
Dmitry Baryshkov

? libavcodec/amr_float
? libavcodec/amrwb_float
Index: libavcodec/libpostproc/postprocess.c
===================================================================
RCS file: /cvsroot/ffmpeg/ffmpeg/libavcodec/libpostproc/postprocess.c,v
retrieving revision 1.92
diff -u -r1.92 postprocess.c
--- libavcodec/libpostproc/postprocess.c	31 Jan 2004 22:58:32 -0000	1.92
+++ libavcodec/libpostproc/postprocess.c	1 Mar 2004 08:18:36 -0000
 <at>  <at>  -103,14 +103,20  <at>  <at> 
 #define TEMP_STRIDE 8

Re: Blocky picture for Divx5/XVid stream

On Sun, Feb 29, 2004 at 02:54:33PM +0100, Måns Rullgård wrote:
> Michael Niedermayer <michaelni <at> gmx.at> writes:
> 
> > u must not set CODEC_FLAG_TRUNCATED for AVI
> 
> Why is that?  I never noticed any ill effects from doing that.

Probably you weren't decoding files with B frames. Even if it does
work for other files, CODEC_FLAG_TRUNCATED is complete nonsense with
AVI. AVI always gives you whole frames because it's a frame-based
container.

Rich

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: Blocky picture for Divx5/XVid stream

D Richard Felker III <dalias <at> aerifal.cx> writes:

> On Sun, Feb 29, 2004 at 02:54:33PM +0100, Måns Rullgård wrote:
>> Michael Niedermayer <michaelni <at> gmx.at> writes:
>> 
>> > u must not set CODEC_FLAG_TRUNCATED for AVI
>> 
>> Why is that?  I never noticed any ill effects from doing that.
>
> Probably you weren't decoding files with B frames.

I've decoded lots of files.  I'm not sure which ones have B frames,
though, statistically, some of them are likely to.

> Even if it does work for other files, CODEC_FLAG_TRUNCATED is
> complete nonsense with AVI. AVI always gives you whole frames
> because it's a frame-based container.

Right, but my decoder module doesn't know where the stream is coming
from.

--

-- 
Måns Rullgård
mru <at> kth.se

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id56&alloc_id438&op=click

CVS: ffmpeg/libavcodec/libpostproc postprocess.c,1.92,1.93

Update of /cvsroot/ffmpeg/ffmpeg/libavcodec/libpostproc
In directory mail:/var2/tmp/cvs-serv17523

Modified Files:
	postprocess.c 
Log Message:
attribute_used patch by (mitya at school dot ioffe dot ru (Dmitry Baryshkov))

Index: postprocess.c
===================================================================
RCS file: /cvsroot/ffmpeg/ffmpeg/libavcodec/libpostproc/postprocess.c,v
retrieving revision 1.92
retrieving revision 1.93
diff -u -d -r1.92 -r1.93
--- postprocess.c	31 Jan 2004 22:58:32 -0000	1.92
+++ postprocess.c	1 Mar 2004 12:46:20 -0000	1.93
 <at>  <at>  -103,14 +103,20  <at>  <at> 
 #define TEMP_STRIDE 8
 //#define NUM_BLOCKS_AT_ONCE 16 //not used yet

+#if defined(__GNUC__) && (__GNUC__ > 3 || __GNUC__ == 3 && __GNUC_MINOR__ > 0)
+#    define attribute_used __attribute__((used))
+#else
+#    define attribute_used
+#endif
+
 #ifdef ARCH_X86
-static uint64_t __attribute__((aligned(8))) w05=		0x0005000500050005LL;
-static uint64_t __attribute__((aligned(8))) w20=		0x0020002000200020LL;
-static uint64_t __attribute__((aligned(8))) b00= 		0x0000000000000000LL;

Re: Re: Problems compiling libavcodec with SuSE 9.0 gcc 3.2 compiler

Hi

On Monday 01 March 2004 09:26, Dmitry Baryshkov wrote:
> On Mon, Mar 01, 2004 at 11:16:28AM +0300, Dmitry Baryshkov wrote:
> > Hello,
> > On Sun, Feb 29, 2004 at 11:10:27PM +0100, Michael Niedermayer wrote:
> > [skipped]
> >
> > > > Patch attached.
> > >
> > > applied
> >
> > Thanks you. Here is another patch. Somehow when I was compiling ffmpeg,
> > postproc compiled OK, but with MPlayer it fails.
> > Patch attached.
>
> Or even better patch.
applied

--

-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with

Re: adopting AVFrame to the audio codecs

Hi,

> I agree some players will be too primitive to do this themselves, so
> IMO there should be the ugly "truncated" support. Maybe this could be
> a separate optional layer in lavc rather than introducing mess into
> each codec. For example, codecs could provide a function to determine
> "does this buffer contain a full frame?" and if not, the "truncated
> stream layer" could buffer the data and wait for the next chunk of
> data from the calling program.
I fully agree, the only sane thinking is that a codec should only do one
way in the body. We shouldn't pollute every single codec with such
features in the main decoding function.

--

-- 
Alex Beregszaszi 			e-mail: alex <at> fsn.hu
Free Software Network
ISOs: http://www.fsn.hu/?f=download	cell: +36 70 3144424

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: compiling troubles / xlc

On dimanche février 29th 2004, Måns Rullgård wrote:

Hi Mans,

> Olivier Kaloudoff <kalou <at> kalou.net> writes:
> > 	I'm trying to compile ffmpeg with xlc,
> [bunch of errors]
> > 	I saw that xlc was supported,
> Where did you see that?  I tried to patch it to compile with xlc a few
> months ago, but I gave up.  There were just too many little quirks it
> didn't like.

Never give up, Mans :) I saw announce for xlc support in the 2 posts below
(one regarding Mplayer, the other about FFmpeg/libavcodec

http://mplayerhq.hu/pipermail/mplayer-cvslog/2003-October/017258.html
http://linuxfr.org/~malat (CTRL-F xlc)

According to the following post, XLC compiled binaries can drop significantly CPU
usage, that's why I'm really interested to try it. If some people on the list are
interested in this, would be great to do some work and benchmarks...

http://www.hydrogenaudio.org/index.php?act=Print&client=printer&f=11&t=15629&

 OK, here is an initial revision of the mppenc binary:

Edit: See new link below

Despite the ppcv part, the encoder will run on a G4. Right now I'm getting ~7.2x with a G4 1.3ghz powerbook.
This is compiled with IBM xlc with the best combination of optimization flags that I was able to arrive at.

Re: adopting AVFrame to the audio codecs

On Mon, Mar 01, 2004 at 01:54:59PM +0100, Alex Beregszaszi wrote:
> Hi,
> > stream layer" could buffer the data and wait for the next chunk of
> > data from the calling program.
> I fully agree, the only sane thinking is that a codec should only do one
> way in the body. We shouldn't pollute every single codec with such
> features in the main decoding function.

As long as the codec stays in the reasonable sized output buffer it
should be no problem - i.e. 4-8KB so it will fit into L1 cache.
But if the produced output size is bigger maybe we should add
some callback mechanism just like we do for slices.

--

-- 
  .''`.       Litigation: The Business Model of the Future! (TM)
 : :' :        http://www.microsoft.com/mscorp/ip/tech/fat.asp
 `. `'    Zdenek Kabelac  kabi <at> {debian.org, users.sf.net, fi.muni.cz}
   `-         Debian GNU/Linux maintainer - www.debian.{org,cz}     

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click

Re: compiling troubles / xlc

Olivier Kaloudoff <kalou <at> kalou.net> writes:

> On dimanche février 29th 2004, Måns Rullgård wrote:
>
> Hi Mans,
>
>> Olivier Kaloudoff <kalou <at> kalou.net> writes:
>> > 	I'm trying to compile ffmpeg with xlc,
>> [bunch of errors]
>> > 	I saw that xlc was supported,
>> Where did you see that?  I tried to patch it to compile with xlc a few
>> months ago, but I gave up.  There were just too many little quirks it
>> didn't like.
>
> Never give up, Mans :)

I simply had more urgent things that needed attention.  I may have had
an old version of xlc or something also, because it choked on hundreds
of places.

> I saw announce for xlc support in the 2 posts below (one regarding
> Mplayer, the other about FFmpeg/libavcodec

That must have happened later than my experiments.

--

-- 
Måns Rullgård
mru <at> kth.se

-------------------------------------------------------