Re: [Mjpeg-users] Standards converter?
Le 12 mai 07 à 18:49, Steven M. Schultz a écrit : > > On Fri, 11 May 2007, herve.flores wrote: > >> http://jcornet.free.fr/linux/yuvmotionfps.html >> the last time I managed to reach jerome was... two years ago (he >> doesn't answer anymore :-( > > 480KB download, most of it is an OLD copy of mjpegtools. > >> yuvmotionfps comes with a configure from mjpegtools 1.7 (and this old > > It is worse than that. It comes with copies of old mjpegtools 1.7 > utils/ directory instead of using mjpegtools that is installed on a > system. > > Out of the 480KB download for yuvmotionfps-1.6 only a total of *6* > files (about 6KB compressed) are needed.A build script is all > that is needed. No autoconf or automake is needed. > > I created a build.sh script that will build yuvmotionfps using > mjpegtools installed on a system. > > It is called yuvmotionfps-1.7 to distinguish it from the older > 1.6 version that has benn, apparently, abandoned. > [...] > Cheers, > Steven Schultz thanks a lot, no pb for the compilke, but the tool crashes on my PPC computer with this build (it certainly needs some other old stuff from the 1.7version) My answer is not fast, because I tried to understand what was missing or else (without succes ;-)) sorry but I don't manage to use gdb to trace (it trace only thefirst pipe = the tool decoder) just for info, a log from my system (maybe it can explain something to you?): Exception: EXC_BAD_INSTRUCTION (0x0002) Code[0]:0x0002 Code[1]:0x00011d4c Thread 0 Crashed: 0 <<>>0x00011d4c psumsq + 0 1 yuvmotionfps0x379c search_backward_vector + 124 2 yuvmotionfps0x3948 motion_compensate_field + 100 3 yuvmotionfps0x32f8 main + 2184 4 yuvmotionfps0x25cc _start + 760 5 yuvmotionfps0x22d0 start + 48 Thread 0 crashed with PPC Thread State 64: srr0: 0x00011d4c srr1: 0x0208f030vrsave: 0x cr: 0x44000422 xer: 0x0004 lr: 0x379c ctr: 0x90014f40 r0: 0xf4c0 r1: 0xb670 r2: 0xf030 r3: 0x00015b3c r4: 0x004d7b3c r5: 0x02d0 r6: 0x r7: 0x r8: 0x0020 r9: 0x02c0 r10: 0x90016108 r11: 0x84000422 r12: 0x90014f40 r13: 0x r14: 0x r15: 0x00012a78 r16: 0x r17: 0x r18: 0xf5e0 r19: 0x r20: 0x00012a78 r21: 0xf5d0 r22: 0xfffc r23: 0xb770 r24: 0xf5fc r25: 0xfffc r26: 0x00012a78 r27: 0xfffc r28: 0x00012a78 r29: 0xf5fc r30: 0x r31: 0x3734 Binary Images Description: 0x1000 - 0xefff yuvmotionfps /tmp/MC/MC.app/Contents/ Resources/tools/yuvmotionfps 0x8fe0 - 0x8fe52fff dyld 46.12 /usr/lib/dyld 0x9000 - 0x901bdfff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x90215000 - 0x9021afff libmathCommon.A.dylib /usr/lib/system/ libmathCommon.A.dylib ...and thanks for your last try PS: just one think "strange" (for me), above you can see some .dylib from the system during the crash, but if I do otool -L /Users/herve/MovieConverter/tools/yuvmotionfps /Users/herve/MovieConverter/tools/yuvmotionfps: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.9) I can't see "libmathCommon" (but maybe it's normal, I'm not a developper ;-)) bye thanks Hervé - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Standards converter?
On Mon, 14 May 2007, herve.flores wrote: > thanks a lot, no pb for the compilke, but the tool crashes on my PPC > computer with this build cpu arch (intel or PPC) has, as it turns out, NOTHING to do with it. Program would crash on an Intel based MacBookPro. I haven't tested on other systems BUT I think there would be problems there also. > (it certainly needs some other old stuff from the 1.7version) Not exactly.Or rather, "maybe" ;) What it needed was a proper declaration of the 'psumsq' (pointer to the sumsq function). That s > just for info, a log from my system (maybe it can explain something > to you?): Thanks but as you might have guessed I needed more. Even then it took a long time to figure out what the problem was. There were, I think, 2 problems. One is that motionsearch.h is NOT installed by the mjpegtools installation and this line is needed in motionsearch_deint.c (where psumsq() is called): extern int (*psumsq) (uint8_t *blk1, uint8_t *blk2, int rowstride, int hx, int hy, int h); But even after doing that there is the same type of error that was found in yuvdeinterlace. There is a HUGE difference between: nframe[0] = buff_offset + (uint8_t *) bufalloc (buff_size); and inframe[0] = (uint8_t *) bufalloc (buff_offset + buff_size); The FIRST one is what was being done. It allocates a buffer of buff_size bytes and THEN modifies the pointer. The SECOND line allocates a larger buffer to allow for overshoot Also, I changed the 'malloc' to be bufalloc() which will allocate properly aligned buffers (required by MMX and Altivec routines). Try the attached source kit and see if it works (it should at least NOT crash ;)). If it doesn't work then well, try Compressor2 - I'm out of free time for a few days ;) Cheers, Steven Schultz yuvmotionfps.tar.bz2 Description: Binary data - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Standards converter?
The yuvmotionfps.tar.bz2 posted a few minutes ago has a bug that will corrupt the output - I forgot to delete a debug printf() statment. You can either delete the printf (line 110 in motionsearch_deint.c) or use the revised .tar.bz2 file attached to this mail item Sorry for the confusion. Steven Schultz yuvmotionfps.tar.bz2 Description: Binary data - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Standards converter?
Quoting "Steven M. Schultz" <[EMAIL PROTECTED]>:
> But even after doing that there is the same type of error that
> was found in yuvdeinterlace.
OK, so I will drop in here... :-)
All buffers in yuvdeinterlace, yuvdenoise and most probably
yuvmotionfps (as it is based on an old yuvdeinterlace-version *need*
*far* bigger buffers.
> There is a HUGE difference between:
>
> nframe[0] = buff_offset + (uint8_t *) bufalloc (buff_size);
>
> and
>
> inframe[0] = (uint8_t *) bufalloc (buff_offset + buff_size);
>
> The FIRST one is what was being done. It allocates a buffer of
> buff_size bytes and THEN modifies the pointer.
And that one was correct as buffsize was modified *before* to be
bigger. buff_size was added with the size of some lines above and
below the buffer. As the functions all rely on a pointer pointing
*inside* the buffer to the beginning of the data, the first line was
correct for yuvdeinterlace.
Steven, your malloc-bugfix introduced that bug...
// before the bugfix...
// code fragment (Revision 1.9 yuvdeinterlace.cc):
//-
void initialize_memory (int w, int h, int cw, int ch)
{
int luma_size;
int chroma_size;
// Some functions need some vertical overshoot area
// above and below the image. So we make the buffer
// a little bigger...
vertical_overshot_luma = 32*w;
vertical_overshot_chroma = 32*cw;
luma_size = ( w * h ) + 2 * vertical_overshot_luma;
chroma_size = ( cw * ch ) + 2 * vertical_overshot_chroma;
inframe[0] = (uint8_t *) malloc (luma_size) + vertical_overshot_luma;
inframe[1] = (uint8_t *) malloc (chroma_size) + vertical_overshot_chroma;
inframe[2] = (uint8_t *) malloc (chroma_size) + vertical_overshot_chroma;
...
...
...
}
~deinterlacer ()
{
int vertical_overshot_luma = 32*YUVdeint.width;
int vertical_overshot_chroma = 32*YUVdeint.cwidth;
free (inframe[0] - vertical_overshot_luma);
free (inframe[1] - vertical_overshot_chroma);
free (inframe[2] - vertical_overshot_chroma);
...
...
...
}
//-
This worked as follows:
The plain image-planes need a size of just w*h. As some functions
dramaticaly overshot (eg. the MC-functions, ELA and
antialiasing-filters...) by far more than just 1 or 2 lines of pixels,
a save-area is defined of 32 lines top of and below of the buffer. So
the buffer-size is increased by two times vertical_overshot. *But* to
make this work, it is absolutly required, that the pointer is shifted,
so it points *inside* the allocated memory and not to the beginnig of
it...
This is the code *after* your "bugfix":
// code fragment (Revision 1.0 yuvdeinterlace.cc):
//-
void initialize_memory (int w, int h, int cw, int ch)
{
int luma_size;
int chroma_size;
// Some functions need some vertical overshoot area
// above and below the image. So we make the buffer
// a little bigger...
vertical_overshot_luma = 32*w;
vertical_overshot_chroma = 32*cw;
luma_size = ( w * h ) + 2 * vertical_overshot_luma;
chroma_size = ( cw * ch ) + 2 * vertical_overshot_chroma;
inframe[0] = (uint8_t *) malloc (luma_size + vertical_overshot_luma);
inframe[1] = (uint8_t *) malloc (chroma_size + vertical_overshot_chroma);
inframe[2] = (uint8_t *) malloc (chroma_size + vertical_overshot_chroma);
...
...
...
}
~deinterlacer ()
{
free (inframe[0]);
free (inframe[1]);
free (inframe[2]);
...
...
...
}
//-
This makes the buffers even bigger than than in 1.9, but the pointer
is directing to the *beginning* of the malloced area. This make every
single function which need the overshot barf on machines with strict
memory-protection as they *will* now try to access memory outside of
the buffer...
> There is a HUGE difference between:
You are right. There *is* a big difference between these two...
:-) Could you please fix your fix?
cu
Stefan
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Standards converter?
Quoting "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>: > // code fragment (Revision 1.0 yuvdeinterlace.cc): Off course this should have been Revision "1.10" ... To make a more "graphical" explanation: . = allocated memory X = address the pointer needs to point at to satisfy the functions | Overshot | Image Area | Overshot | ...X.. ^ | +--- all functions need the pointer here! as otherwise the overshot is useless. cu Stefan - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
Re: [Mjpeg-users] Standards converter?
On Tue, 15 May 2007 [EMAIL PROTECTED] wrote: > You are right. There *is* a big difference between these two... > :-) Could you please fix your fix? Only when you fix the code so it doesn't crash on my systems. *before* yuvdeinterlace crashed. *after* it does not crash. Since yuvmotionfps is based on an older version of the deinterlacer logic the problem, I think remains. IF that is incorrect I can add yuvmotionfps to mjegtools CVS and you can "fix" it (since it appears to be an abandoned program). I do not fix programs which 1) are working and 2) do not crash :) So, no - I am not going to fix yuvdeinterlace. If you need an account on the system where it will crash with the OLD way of doing things let me know - that can be arranged. If yuvmotionfps works and doesn't crash then I have to say the same thing ;) BUT the concept of vastly overallocating buffers strikes me as nonsense. Why can't the code properly check the boundary conditions and NOT "overshoot" (and thus access areas outside the frame)? Is that too hard? (a few more lines of code perhaps ;)? 'night. Steven Schultz - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Mjpeg-users mailing list Mjpeg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mjpeg-users
