headers
Gianluigi Tiesi | 1 Aug 2005 01:49
Picon
Favicon

Re: GCC 4 Compiler warnings

Most of them are comparison of signed/unsigned, it would be safe to fix
them, but this would be very dangerous since some stuff can stop working
if the warnings are fixed in the wrong way (i.e. using signed instead of
unsigned or vice-versa), I've encountered this problem by fixing warning
of win32 version of mplayer gui, some take a lot of attention before
fixing it.

Bye
--

-- 
Gianluigi Tiesi <sherpya <at> netfarm.it>
EDP Project Leader
Netfarm S.r.l. - http://www.netfarm.it/
Free Software: http://oss.netfarm.it/
Permalink | Reply | 1 comment |
headers
Alexander Strasser | 1 Aug 2005 02:19
Picon

Re: [PATCH] libavutil - splitting parts from libavcodec

Michael Niedermayer wrote:
> libavutil/ 	created
> integer.{c,h}  	copied from libavcodec to libavutil
> rational.{c,h}	copied from libavcodec to libavutil
> common.h 	copied from libavcodec to libavutil
> bswap.h 	copied from libavcodec to libavutil
> eval.c 		copied from libavcodec to libavutil
> 
> feel free to cvs commit/cvs remove stuff as needed unless i forgot some 
> copiing of course
> 
> note, i also copied eval.c which IMHO also belongs to libavutil

  ok, tho i'll add eval.c later (after initial commit of libavutil).

> PS: maybe i should also move utils.c -> mathematics.c, iam not sure though it 
> would preserve a little cvs history but its messy as mathematics.c is only a 
> very small part of utils.c

  ok, there is more stuff in there which should be moved but
i am gonna care about that later.

  I am planning to commit libavutil tonight (here in germany).

  Once this is commited there should probably also a news
article be posted on ffmpeg homepage; saying that the lib
structure changed and that libavutil is now there and that
people only using static libavcodec now also need to get
libavutil and link to it. Mike or Diego will you do it?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Juan Ramos | 1 Aug 2005 09:16
Picon
Picon
Favicon

ffmpeg crashes on windows

avcodec.lib is 12.035.784 bytes long
avformat.lib is 2.953.562 bytes long
Thanks for all!!

Juan Ramos

Hi,

Juan Ramos wrote:
> We are building project in VC .net 2003, and we have
> problems while running the code on Windows. We have
> called a function avcodec_close() which is causing 
> the error. When we execute our code, the error which
> we are getting is access violation, no output.
> 
> We have compiled the .dll and .lib with MinGW and
> MSys:
> Commands used:
> 
> ./configure --enable-memalign-hack --enable-shared
> --disable-strip
> 
> make
> 
> We have renamed libgcc.a as libgcc.lib and linked to
> our proyect in order to avoid linking problems. also
> EMULATE_INTTYPES is #defined. We are compiling the
> last cvs version.
> 
> Can you suggest solution on this problem
(Continue reading)

Permalink | Reply | 4 comments |
headers
Martin Boehme | 1 Aug 2005 09:34
Picon
Favicon

Re: Fix for overflow issue in mpegvideo.c

Michael Niedermayer wrote:
> On Tuesday 26 July 2005 16:15, Martin Boehme wrote:
>>Hm, my feeling, too... any chance of computing an upper limit on the
>>amount of data the encoder can spit out? (I'm not necessarily advocating
>>doing this... just interested...)
> 
> 1 bit modb
> 1 bit modb2
> 2bit mb_type
> 6bit cbp
> 2bit dquant
> 1bit interlaced dct
> 1bit mv type
> 4bit field select
> 2*2*2*20bit motion vectors
> 6*64*30bit dct coefficoents (YV12! otherwise its more)
> 47bit video packet header
> 
> -> 11745 bits per MB -> ~width*height*5.735
> 
> but note, if width and height are small then the size of the various headers 
> must be considered too ...
> 
> [...]

Interesting... thanks! Looks as if Loren got pretty close to that limit, 
then...

Martin
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ivan Wong | 1 Aug 2005 09:41

Re: ffmpeg crashes on windows

Hi,

Juan Ramos wrote:
> avcodec.lib is 12.035.784 bytes long
> avformat.lib is 2.953.562 bytes long
It sounds you are using static libraries by gcc, which can't be used
with MSVC. Instead of renaming .dll.a/.a to .lib, we usually use lib.exe:

lib /def:avcodec.def /name:avcodec.dll /out:avcodec.lib

Cheers,
--

-- 
Ivan, Wong Yat Cheung  <email <at> ivanwong.info>
GPG: 1024D/7775FDBB: CE88 DBE0 5AF3 D4AC 91F5  6C0E 2C84 B2AD 7775 FDBB
Permalink | Reply | 2 comments |
headers
Martin Boehme | 1 Aug 2005 10:13
Picon
Favicon

Re: jpeg to mpeg

Hi Willem,

> the last 3 week I have been struggling to convert my jpeg files from 
> zone minder to mpeg movies, can any one help me please

Try something like

     ffmpeg -i mypics%03d.jpg myvideo.mpg

BTW, this question would have been better suited to ffmpeg-user...

Martin

--

-- 
Martin Böhme
Inst. f. Neuro- and Bioinformatics
Ratzeburger Allee 160, D-23538 Luebeck
Phone: +49 451 500 5514
Fax:   +49 451 500 5502
boehme <at> inb.uni-luebeck.de
Permalink | Reply | 0 comments |
headers
Martin Boehme | 1 Aug 2005 10:15
Picon
Favicon

Re: Win32 compile

Hi Jeff,

> Hi all. Quick question. I was reading the web page regarding how
> to build ffmpeg for a win32 platform (http://www.salyens.com/mingw/)
> On that page, it list a whole multitude of config options.  My
> question is, for the lastest source, do you still need all those config
> flags? Thanks to any and all for any of your help.

I've built and used FFmpeg on MinGW/MSys using only ./configure; make...

Martin

--

-- 
Martin Böhme
Inst. f. Neuro- and Bioinformatics
Ratzeburger Allee 160, D-23538 Luebeck
Phone: +49 451 500 5514
Fax:   +49 451 500 5502
boehme <at> inb.uni-luebeck.de
Permalink | Reply | 2 comments |
headers
Diego Biurrun | 1 Aug 2005 12:20
Picon
Gravatar

Re: GCC 4 Compiler warnings

On Mon, Aug 01, 2005 at 01:49:01AM +0200, Gianluigi Tiesi wrote:
> I've encountered this problem by fixing warning
> of win32 version of mplayer gui

Have you sent them to mplayer-dev-eng?

Diego
Permalink | Reply | 0 comments |
headers
Robert Swain | 1 Aug 2005 12:53
Picon

[BUG] Snow chroma bug

Hello everyone,

I'm not sure if this is related to the ongoing 'strange' chroma
fluctuation I've noticed ever since I started looking at Snow (similar
problems were experienced in a Windows based wavelett codec called
Rududu which has since ceased development as far as I can tell) but in
the clip I've uploaded the problems are more serious.

Details are in the text file:

ftp://ftp.mplayerhq.hu/MPlayer/incoming/snow-chroma-bug.txt
ftp://ftp.mplayerhq.hu/MPlayer/incoming/snow-chroma-bug.avi

Regards,
Robert Swain (superdump on IRC)
Permalink | Reply | 5 comments |
headers
Alex Beregszaszi | 1 Aug 2005 13:08
Picon

Re: [BUG] Snow chroma bug

Hi,

> I'm not sure if this is related to the ongoing 'strange' chroma
> fluctuation I've noticed ever since I started looking at Snow (similar
> problems were experienced in a Windows based wavelett codec called
> Rududu which has since ceased development as far as I can tell) but in
> the clip I've uploaded the problems are more serious.
> 
> Details are in the text file:
> 
> ftp://ftp.mplayerhq.hu/MPlayer/incoming/snow-chroma-bug.txt
> ftp://ftp.mplayerhq.hu/MPlayer/incoming/snow-chroma-bug.avi

Moved to mplayerhq.hu/MPlayes/samples/V-codecs/SNOW/

--

-- 
Alex Beregszaszi	email: alex <at> fsn.hu
Free Software Network	cell: +36 70 3144424
Permalink | Reply | 0 comments |

Gmane