hi, i am trying to use beosthread.c module, but i'm not able to find OS.h Is it a linux only file? unfortunatly because of my univer. job i must use windows...i tried to find OS.h with search but i did not find anything any suggestion? thanks a lot (as usual!) paolo -- C.N.I.T Consorzio Nazionale Interuniversitario per le Telecomunicazioni c/o Unit? di Ricerca di Ferrara Dipartimento di Ingegneria, Universita' di Ferrara Via Saragat 1, Ferrara
sorry i forgot the subject! here is may mail
hi,
i am trying to use beosthread.c module, but i'm not able to find OS.h Is it a linux only file? unfortunatly because of my univer. job i must use windows...i tried to find OS.h with search but i did not find anything
any suggestion?
thanks a lot (as usual!)
paolo
-- C.N.I.T Consorzio Nazionale Interuniversitario per le Telecomunicazioni c/o Unit? di Ricerca di Ferrara Dipartimento di Ingegneria, Universita' di Ferrara Via Saragat 1, Ferrara
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
-- C.N.I.T Consorzio Nazionale Interuniversitario per le Telecomunicazioni c/o Unit? di Ricerca di Ferrara Dipartimento di Ingegneria, Universita' di Ferrara Via Saragat 1, Ferrara tel 349/7549790 email:gamma2002 at virgilio.it
Paolo Giacon wrote:
sorry i forgot the subject! here is may mail
hi,
i am trying to use beosthread.c module, but i'm not able to find OS.h Is it a linux only file? unfortunatly because of my univer. job i must use Painful windows...i tried to find OS.h with search but i did not find anything
any suggestion?
beosthread.c is BeOS only code, completely linux unrelated. Have a look at haiku-os.org for more info lu -- Luca Barbato Gentoo/linux Developer Gentoo/PPC Operational Manager http://dev.gentoo.org/~lu_zero
I have noticed that the genere is not extracted from asf headers of asf files, and I patched it so that it will. The only problem is that I am a newbie with ffmpeg and I am not familiar with your patching methods. Until I will become more familiar with them I thought I will just post here the one line of code I added so that others can also use it. If there is anyone of the more experienced people that wouldn't mind adding this line to asf.c I would be very grateful. After line 335 which currently says: if (strcmp(name,"WM/AlbumTitle")==0) { pstrcpy(s->album, sizeof(s->album), value); } I added: else if (strcmp(name, "WM/Genre")==0) { strcpy(s->genre, value); }
On Fri, May 20, 2005 at 02:50:18PM -0400, Ronen Mizrahi wrote:
I have noticed that the genere is not extracted from asf headers of asf files, and I patched it so that it will. The only problem is that I am a newbie with ffmpeg and I am not familiar with your patching methods.
cvs diff -u or read http://mplayerhq.hu/DOCS/tech/patches.txt for a more detailed explanation. This info is MPlayer-specific, but most of it is valid for FFmpeg as well. Dego
I recently noticed that with mingw32, avcodec is statically linked into avformat.dll, is this intentional? Was the intention that from now on people will use one dll? I noticed it accidently when I saw that the size of avofmrat.dll (which sed to be one tenth of avcodec.dll) is now bigger than avcodec.dll. If this is an old feature that was already discussed then I apologize in advance for bringing this up again.
Hi, Ronen Mizrahi wrote:
I recently noticed that with mingw32, avcodec is statically linked into avformat.dll, is this intentional? Was the intention that from now on people will use one dll? I noticed it accidently when I saw that the size of avofmrat.dll (which sed to be one tenth of avcodec.dll) is now bigger than avcodec.dll. If this is an old feature that was already discussed then I apologize in advance for bringing this up again.
You can test if the attached patch helps. Alex (beastd)
I tried applying the patch and it looks like your Makefile was from a different date than the one I had. I was using the CVS head from yesterday and I though you were doing the same, were you not? Alexander Strasser wrote:
Hi,
Ronen Mizrahi wrote:
I recently noticed that with mingw32, avcodec is statically linked into avformat.dll, is this intentional? Was the intention that from now on people will use one dll? I noticed it accidently when I saw that the size of avofmrat.dll (which sed to be one tenth of avcodec.dll) is now bigger than avcodec.dll. If this is an old feature that was already discussed then I apologize in advance for bringing this up again.
You can test if the attached patch helps.
Alex (beastd)
------------------------------------------------------------------------
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
Ronen Mizrahi wrote:
I tried applying the patch and it looks like your Makefile was from a different date than the one I had. I was using the CVS head from yesterday and I though you were doing the same, were you not?
I'm sorry. Updated patch attached. Alex (beastd)
Sorry, I may be doing something wrong but the patch is still rejected when I try to apply it, see below exact output. Can you please tell me the exact time and date of the CVS version you created the patch against. $ patch -i /c/libav-w32buildshared10.diff patching file `configure' patching file `Makefile' Hunk #1 FAILED at 401. Hunk #2 FAILED at 424. 2 out of 2 hunks FAILED -- saving rejects to Makefile.rej patching file `Makefile' Hunk #1 FAILED at 98. Hunk #2 FAILED at 141. 2 out of 2 hunks FAILED -- saving rejects to Makefile.rej patching file `Makefile' Hunk #1 FAILED at 6. Hunk #2 FAILED at 37. Hunk #3 FAILED at 52. 3 out of 3 hunks FAILED -- saving rejects to Makefile.rej can't find file to patch at input line 111 Perhaps you should have used the -p or --strip option? The text leading up to this was: -------------------------- |Index: libavutil/common.h |=================================================================== |RCS file: /cvsroot/ffmpeg/ffmpeg/libavutil/common.h,v |retrieving revision 1.153 |diff -u -r1.153 common.h |--- libavutil/common.h 19 Sep 2005 23:26:47 -0000 1.153 |+++ libavutil/common.h 16 Nov 2005 08:40:27 -0000 -------------------------- Alexander Strasser wrote:
Ronen Mizrahi wrote:
I tried applying the patch and it looks like your Makefile was from a different date than the one I had. I was using the CVS head from yesterday and I though you were doing the same, were you not?
I'm sorry. Updated patch attached.
Alex (beastd)
------------------------------------------------------------------------
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
On Wed, Nov 16, 2005 at 01:28:59PM -0500, Ronen Mizrahi wrote:
Sorry, I may be doing something wrong but the patch is still rejected when I try to apply it, see below exact output. Can you please tell me the exact time and date of the CVS version you created the patch against.
$ patch -i /c/libav-w32buildshared10.diff [...] 3 out of 3 hunks FAILED -- saving rejects to Makefile.rej can't find file to patch at input line 111 Perhaps you should have used the -p or --strip option?
Have you tried the -p option as patch told you? It works flawlessly here with patch --dry-run -p0 -i /tmp/libav-w32buildshared10.diff Diego
Thanks, it seems that patch now works, it is just that I was not sure it was the right thing to do. In any case I will now test to see that the static linking no longer occurs... Diego Biurrun wrote:
On Wed, Nov 16, 2005 at 01:28:59PM -0500, Ronen Mizrahi wrote:
Sorry, I may be doing something wrong but the patch is still rejected when I try to apply it, see below exact output. Can you please tell me the exact time and date of the CVS version you created the patch against.
$ patch -i /c/libav-w32buildshared10.diff [...] 3 out of 3 hunks FAILED -- saving rejects to Makefile.rej can't find file to patch at input line 111 Perhaps you should have used the -p or --strip option?
Have you tried the -p option as patch told you?
It works flawlessly here with
patch --dry-run -p0 -i /tmp/libav-w32buildshared10.diff
Diego
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
Yes, I can confirm that it now works and the static linking of avcodec.dll into avformat.dll no longer occurs. Can the patch be pleasae applied to CVS by someone? Ronen Mizrahi wrote:
Thanks, it seems that patch now works, it is just that I was not sure it was the right thing to do. In any case I will now test to see that the static linking no longer occurs...
Diego Biurrun wrote:
On Wed, Nov 16, 2005 at 01:28:59PM -0500, Ronen Mizrahi wrote:
Sorry, I may be doing something wrong but the patch is still rejected when I try to apply it, see below exact output. Can you please tell me the exact time and date of the CVS version you created the patch against.
$ patch -i /c/libav-w32buildshared10.diff [...] 3 out of 3 hunks FAILED -- saving rejects to Makefile.rej can't find file to patch at input line 111 Perhaps you should have used the -p or --strip option?
Have you tried the -p option as patch told you?
It works flawlessly here with
patch --dry-run -p0 -i /tmp/libav-w32buildshared10.diff
Diego
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel at mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel
Hi, Ronen Mizrahi wrote:
Yes, I can confirm that it now works and the static linking of avcodec.dll into avformat.dll no longer occurs. Can the patch be pleasae applied to CVS by someone?
Principally I would like to apply it but the problem is: that it logically causes the generation of the static libs with the same objects to fail. As i wrote before disbabling static isn't easily possible with the current build system. Does anyone else have a good idea? Or should i go for modifying the buildsystem so the build of static libs could be disabled when --enable-shared is selected on win32? Alex (beastd)
On Thu, Dec 01, 2005 at 02:50:13PM +0100, Alexander Strasser wrote:
Does anyone else have a good idea? Or should i go for modifying the buildsystem so the build of static libs could be disabled when --enable-shared is selected on win32?
To be perfectly honest, I don't see why static libs should be generated at all when --enable-shared is specified. Then again, I bet somebody is going to come up with a compelling reason for it. Diego
Diego Biurrun said:
On Thu, Dec 01, 2005 at 02:50:13PM +0100, Alexander Strasser wrote:
Does anyone else have a good idea? Or should i go for modifying the buildsystem so the build of static libs could be disabled when --enable-shared is selected on win32?
To be perfectly honest, I don't see why static libs should be generated at all when --enable-shared is specified. Then again, I bet somebody is going to come up with a compelling reason for it.
Static and shared libs should be selected independently. The only constraint should be that at least one of them must be selected. -- M?ns Rullg?rd mru at mru.ath.cx
Ronen Mizrahi <ronen at tversity.com> writes:
I have noticed that the genere is not extracted from asf headers of asf files, and I patched it so that it will. The only problem is that I am a newbie with ffmpeg and I am not familiar with your patching methods. Until I will become more familiar with them I thought I will just post here the one line of code I added so that others can also use it. If there is anyone of the more experienced people that wouldn't mind adding this line to asf.c I would be very grateful.
After line 335 which currently says:
if (strcmp(name,"WM/AlbumTitle")==0) { pstrcpy(s->album, sizeof(s->album), value); }
I added:
else if (strcmp(name, "WM/Genre")==0) { strcpy(s->genre, value); }
Potential buffer overflow. -- M?ns Rullg?rd mru at inprovide.com
participants (7)
-
diego＠biurrun.de -
eclipse7＠gmx.net -
lu_zero＠gentoo.org -
mru＠inprovide.com -
mru＠mru.ath.cx -
pgiacon＠ing.unife.it -
ronen＠tversity.com