Re: [Mjpeg-users] y4mstabilizer segmentation fault

2009-06-04 Thread Richard Archer
At 3:41 PM +0200 3/6/09, Hervé wrote:

hello, I'm not developper but it could not be a buffer concern? (it's
just an idea)

Following this hint, I doubled the buffer sizes allocated
by y4mstabilizer and it now works! I have no idea how much
overkill this solution is... for all I know it may have
been an off-by-one error. But this patch (below) got it
working for me.

As it turns out, this tool doesn't do what I wanted it
to anyway.

Thanks for all your help everyone. I've learned a good
deal about all these tools, and I thought I knew them
pretty well already!

And @Mark Heath... I had seen your tools before, and I
will have another look at them in future. You have some
really interesting code there, and with a bit of
cleaning up and packaging it could be a great supplement
to mjpegtools.

 ...Richard.




diff -U3 -r mjpegtools-1.9.0/lavtools/y4mstabilizer.c
mjpegtools-1.9.0-patch/lavtools/y4mstabilizer.c
--- mjpegtools-1.9.0/lavtools/y4mstabilizer.c   2007-04-03
01:43:33.0 +1000
+++ mjpegtools-1.9.0-patch/lavtools/y4mstabilizer.c 2009-06-04
10:12:06.0 +1000
@@ -1,5 +1,5 @@
 /*
- * $Id: y4mstabilizer.c,v 1.9 2007/04/01 18:06:06 sms00 Exp $
+ * $Id: y4mstabilizer.c,v 1.10 2009/01/24 18:06:45 sms00 Exp $
  *
  * written by J. Macropol j...@wx.gd-ais.com
  * Framework and shifting code adapted from y4mshift by Steve Schultz.
@@ -350,7 +350,7 @@
 static void
 alloc_yuv (u_char **yuv, int h, int w)
 {
-int len = h * w;
+int len = h * w *2;
 int uvlen = Stab.nosuper ? (len / (SS_H * SS_V)) : len;
 yuv[0] = malloc(len);
 if (yuv[0] == NULL)

--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] y4mstabilizer segmentation fault

2009-06-04 Thread Mark Heath

On 04/06/2009, at 4:04 PM, Richard Archer wrote:

 As it turns out, this tool doesn't do what I wanted it
 to anyway.

Does what you want it to do be a suitable extension to the tool.

I was about to pick up the code and debug it, however if you've found  
that increasing the buffer size fixes the bug, then it's probably not  
as urgent.

I need a video project to take my mind off work.


 And @Mark Heath... I had seen your tools before, and I
 will have another look at them in future. You have some
 really interesting code there, and with a bit of
 cleaning up and packaging it could be a great supplement
 to mjpegtools.

Thanks for the feed back.

I've got no idea about writing a proper configure script and build  
system for them or if they are useful to anyone.

If you have any ideas for a video filter I'd be interested to hear of  
them.

Mark

--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] y4mstabilizer segmentation fault

2009-06-04 Thread Dan Scholnik
On Thu, 2009-06-04 at 16:04 +1000, Richard Archer wrote:
 At 3:41 PM +0200 3/6/09, Hervé wrote:
 
 hello, I'm not developper but it could not be a buffer concern? (it's
 just an idea)
 
 Following this hint, I doubled the buffer sizes allocated
 by y4mstabilizer and it now works! I have no idea how much
 overkill this solution is... for all I know it may have
 been an off-by-one error. But this patch (below) got it
 working for me.

I don't know if it's the same issue, but several years ago I was getting
segfaults with y4mstabilizer that seemed related to how big the
correction shift was (how far the image wandered in the frame).  I think
only very large shifts caused problems (my video was handheld while
running.)  I lost interest before I could track the bug down, but I
always assumed that it was inadvertently addressing outside the buffer
in that case.

Dan


--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] y4mstabilizer segmentation fault

2009-06-03 Thread Mark Heath

 Input #0, mpegvideo, from 'test.m2v':
  Duration: 00:00:46.50, bitrate: 3938 kb/s
Stream #0.0: Video: mpeg2video, yuv420p, 720x576 [PAR 16:15 DAR  
 4:3], 3938 kb/s, 25 tbr, 1200k tbn, 50 tbc
 Output #0, yuv4mpegpipe, to 'pipe:':
Stream #0.0: Video: rawvideo, yuv444p, 720x576 [PAR 16:15 DAR  
 4:3], q=2-31, 200 kb/s, 90k tbn, 25 tbc

   UGH!  What is a PAR (Pixel Aspect Ratio) of 16:15?  PAL is  
 something like 59:54 as
   I recall.  But then I always ignored the y4m header that ffmpeg  
 output and
   put on my own ;)

16:15 is the pixel aspect ratio you get if you make the assumption  
that 720x576 frame size is 4:3. (similar to 64:45)

As we all know the correct PAR for PAL is 128:117 using true square  
pixels.
If you were using industry square pixels it would be 59:54 (an  
industry square pixel is 768:767)

Unless you know why you would want one and not the other then either  
true square or industry square is probably fine.

[snip]

 I'm happy to follow instructions to help isolate the bug and
 to apply patches and rebuild to test a solution.

   I would try getting correct data into the program  before any more  
 debugging ;)

   with ffmpeg something like this might stand a better chance:
[snip]

Could I plug my program which interfaces libav and the mjpeg  
libraries, libav2yuv? :-)

http://silicontrip.net/~mark/lavtools/#libav2yuv

You can override all the yuv header values with command line switches.
It also uses swscaler to convert to other chroma subsampling mode, so  
you can output 444 from within the tool.

libav2yuv -S 444 -c -A 59:54 test.m2v |  yuvdeinterlace  | ...

I would also like some people to test it and someone to help package  
it up since it is only C source.

Mark

--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] y4mstabilizer segmentation fault

2009-06-03 Thread Richard Archer
Hi Steven,

Wow, thanks for such a detailed response!


At 9:10 PM -0700 2/6/09, Steven M. Schultz wrote:

mjpegtools build either from the last release (end of Dec 2009)
or from CVS (which hasn't changed too much)?

I was using the atrpms RPM of mjpegtools 1.9.0.
I then downloaded the 1.9.0 source and applied the patch from CVS
for y4mstabilizer but that didn't help.

I could try checking out the entire CVS tree but I don't think
that would help.


ffmpeg doesn't know the rate or frame size?  I would have thought
that none of those options would be necessary if the input stream
is properly formed.

The command line is extracted from a larger script which
accepts almost any file as input and converts it to a
standard format (x264). So yes, it is designed to work with
damaged streams, although in this case the stream is fine.


The PROBLEM the use of -pix_fmt yuv444p.  -pix_fmt does not
scale or resample the data!!   -pix_fmt simply tells ffmpeg what
value to put into the yuv4mpeg header.

Oops, I assumed ffmpeg would convert to the specified format.
I have installed some extra tools, mpeg2dec and y4mscaler.


 Seems stream 0 codec frame rate differs from container frame
 rate: 50.00 (50/1) - 25.00 (25/1)
ffmpeg is saying your input is 50 frames/sec?  Hmmm, interesting.

Yeah, it's been doing that for a while now. It bothers me
but it does seem to work correctly regardless.


UGH!  What is a PAR (Pixel Aspect Ratio) of 16:15?  PAL is
something like 59:54 as I recall.  But then I always ignored
the y4m header that ffmpeg output and put on my own ;)

The file is 720x576 with an output DAR of 4:3. Which would
be 768x576, or a PAR of 16:15. The other players I've tried
all agree to display it at 768x576, correct or not!


  ffmpeg -i test.m2v -pix_fmt yuv420p | \
  yyuvdeinterlace | \
  y4mscaler -v 0 -O sar=src -O chromass=444 | \
  y4mstablizer | \
  y4mscaler -v 0 -O sar=src -O chromass=420_MPEG2 | ...

I tried that, with the same crash.

This also results in the same crash:

mpeg2dec -o pgmpipe test.m2v |
pgmtoy4m -a 16:15 -i t -r 25:1 -x 420mpeg2 |
yuvdeinterlace |
y4mscaler -v 0 -O sar=src -O chromass=444 |
y4mstabilizer -v -v |
y4mscaler -v 0 -O sar=src -O chromass=420_MPEG2  test

   INFO: [yuvdeinterlace] -
   INFO: [yuvdeinterlace]Motion-Compensating-Deinterlacer
   INFO: [yuvdeinterlace] -
   INFO: [yuvdeinterlace] SETTING EXTENDED MMX for MOTION!
libmpeg2-0.5.1 - by Michel Lespinasse wal...@zoy.org and Aaron Holtzman
   INFO: [pgmtoy4m] P5 cols: 720 rows: 864 maxval: 255
   INFO: [yuvdeinterlace] Y4M-Stream is 720x576(420mpeg2)
   INFO: [yuvdeinterlace]  Stream is interlaced, top-field-first.
   INFO: [y4mstabilizer]   frame size:  720x576 pixels (1244160 bytes)
   INFO: [y4mstabilizer]   chroma:  4:4:4 (no subsampling)
   INFO: [y4mstabilizer]   frame rate:  25/1 fps (~25.00)
   INFO: [y4mstabilizer]interlace:  none/progressive
   INFO: [y4mstabilizer] sample aspect ratio:  16:15
   INFO: [y4mstabilizer] Frame 1
   INFO: [y4mstabilizer] global motion xy*2=0,3 Accumulated
xy=0,1.5 shift xy=0,-2

   INFO: [y4mstabilizer] Frame 2
Segmentation fault (core dumped)


The backtrace is the same as before.

It's not getting very far and it's completely reproducible, which
should make it fairly easy to track down the problem. I'm just not
sure how to go about it.

 ...Richard.

--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] y4mstabilizer segmentation fault

2009-06-03 Thread Richard Archer
At 10:19 AM +0200 3/6/09, Hervé wrote:

one tip to Richard:
if your contents is interlaced, deinterlace (from ffmpeg or another
mjpeg tool)
if your contents is progressive (and only the wrapper is interlaced),
correct headers with yuvcorrect

That's interesting...

ffmpeg -deinterlace -i test.m2v -f yuv4mpegpipe -pix_fmt yuv420p - |
y4mscaler -v 0 -O sar=src -O chromass=444 |
y4mstabilizer -v -v test

produces, among other things:
   INFO: [y4mstabilizer]interlace:  top-field-first

So, ffmepg is still calling the video interlaced.


If I use yuvdeinterlace:
ffmpeg -i test.m2v -f yuv4mpegpipe -pix_fmt yuv420p - |
yuvdeinterlace |
y4mscaler -v 0 -O sar=src -O chromass=444 |
y4mstabilizer -v -v test

that line in the output changes to:
   INFO: [y4mstabilizer]interlace:  none/progressive

It still crashes after two frames though :(


a great tool, with a great result :-))

If only I could see what it produced!
I'm starting to regret converting this system to 64 bit.

 ...R.

--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users


Re: [Mjpeg-users] y4mstabilizer segmentation fault

2009-06-03 Thread Hervé
(update)
hello, I'm not developper but it could not be a buffer concern? (it's  
just an idea)

uname -a
Darwin MacMini-2.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31  
22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386

tests with the official release 190 (and not an RC nor recent CVS)
CL = … | /y4mstabilizer -v -v

-

commun parts to all tests (PS: I tried with y4mscaler or ppmtoy4m or  
ffmpeg, same results with all 444 converters):

[...]
INFO: [ppmtoy4m] Output Stream parameters:
[...]
INFO: [ppmtoy4m] chroma:  4:4:4 (no subsampling)
INFO: [ppmtoy4m] frame rate:  25/1 fps (~25.00)
INFO: [ppmtoy4m]  interlace:  none/progressive
INFO: [ppmtoy4m]   sample aspect ratio:  1:1
[...]
INFO: [y4mstabilizer]   chroma:  4:4:4 (no subsampling)
[...]
INFO: [y4mstabilizer]interlace:  none/progressive
INFO: [y4mstabilizer] sample aspect ratio:  1:1
INFO: [y4mstabilizer] Frame 1
INFO: [y4mstabilizer] global motion xy*2=0,2 Accumulated  
xy=0,1 shift xy=0,-1
[...]


-

test one: an HD file (720p)
crashed immediately:
INFO: [y4mstabilizer]   frame size:  1280x720 pixels (2764800 bytes)
INFO: [y4mstabilizer]   chroma:  4:4:4 (no subsampling)
INFO: [y4mstabilizer]   frame rate:  25/1 fps (~25.00)
INFO: [y4mstabilizer]interlace:  none/progressive
no outputed frame

-

test two: the same HD file (720p) but I rescaled it (720x576) before  
sending it to y4mscaler

INFO: [y4mstabilizer]   frame size:  720x576 pixels (1244160 bytes)
INFO: [y4mstabilizer]   chroma:  4:4:4 (no subsampling)
INFO: [y4mstabilizer]   frame rate:  25/1 fps (~25.00)
INFO: [y4mstabilizer]interlace:  none/progressive
INFO: [y4mstabilizer] sample aspect ratio:  1:1
INFO: [y4mstabilizer] Frame 1
INFO: [y4mstabilizer] global motion xy*2=0,2 Accumulated  
xy=0,1 shift xy=0,-1

INFO: [y4mstabilizer] Frame 2
INFO: [y4mstabilizer] global motion xy*2=0,0 Accumulated  
xy=0,0.95 shift xy=0,-1
[...]
INFO: [y4mstabilizer] Frame 265
INFO: [y4mstabilizer] global motion xy*2=0,-5 Accumulated  
xy=-1.45501,-19.4269 shift xy=1,19

INFO: [y4mstabilizer] Frame 266
(crashed)

-

test 3: the same HD file (720p) but I rescaled it (320*240) before  
sending it to y4mscaler

INFO: [y4mstabilizer]   frame size:  320x240 pixels (230400 bytes)
INFO: [y4mstabilizer]   chroma:  4:4:4 (no subsampling)
INFO: [y4mstabilizer]   frame rate:  25/1 fps (~25.00)
INFO: [y4mstabilizer]interlace:  none/progressive
INFO: [y4mstabilizer] sample aspect ratio:  1:1
INFO: [y4mstabilizer] Frame 1
INFO: [y4mstabilizer] global motion xy*2=0,1 Accumulated  
xy=0,0.5 shift xy=0,-1
[...]
INFO: [y4mstabilizer] Frame 1415
INFO: [y4mstabilizer] global motion xy*2=0,-20 Accumulated  
xy=3.60354,36.8782 shift xy=-4,-37

INFO: [y4mstabilizer] Frame 1416
(crashed)

-

test 4: the same HD file (720p) but I rescaled it (160*120) before  
sending it to y4mscaler

INFO: [y4mstabilizer]   frame size:  160x120 pixels (57600 bytes)
[...]
INFO: [y4mstabilizer] Frame 1
INFO: [y4mstabilizer] global motion xy*2=0,0 Accumulated  
xy=0,0 shift xy=0,0
[...]
INFO: [y4mstabilizer] Frame 1421
INFO: [y4mstabilizer] global motion xy*2=-1,-8 Accumulated  
xy=-0.721807,-10.8797 shift xy=1,11

INFO: [y4mstabilizer] Frame 1422
(and crash)

-

so,
littler size, more frames …seems that size matters (spam joke ;-))

-

crash log:

Process: y4mstabilizer [65490]
Path:/Users/herve/_Tools/_CVS/_MjpegTools/mjpegtools/ 
mjpegtools-1.9.0release_BIN/intel_Tiger-2009:02:20-25/y4mstabilizer
Identifier:  y4mstabilizer
Version: ??? (???)
Code Type:   X86 (Native)
Parent Process:  bash [65469]

Interval Since Last Report:  1056 sec
Crashes Since Last Report:   10
Per-App Interval Since Last Report:  0 sec
Per-App Crashes Since Last Report:   10

Date/Time:   2009-06-03 15:29:00.352 +0200
OS Version:  Mac OS X 10.5.7 (9J61)
Report Version:  6
Anonymous UUID:  8CDFC8BB-54FD-4F31-AF37-8EEF871D4795

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000fd000
Crashed Thread:  0

Thread 0 Crashed:
0   y4mstabilizer   0x17c7 subsample + 75  
(y4mstabilizer.c:396)
1   y4mstabilizer   0x480b main + 1214  
(y4mstabilizer.c:215)
2   y4mstabilizer   0x175e _start + 216
3   y4mstabilizer   0x1685 start + 41

Thread 0 crashed with X86 Thread State (32-bit):
   eax: 0x003fa680  ebx: 0x435e  ecx: 0x0500  edx: 0x0063
   edi: 0x000fd000  esi: 0x003fa400  ebp: 0xb318  esp: 0xb2f4
ss: 0x001f  efl: 0x00010202  eip: 0x17c7   cs: 0x0017
ds: 0x001f   es: 0x001f   fs: 0x   gs: 0x0037
   cr2: 0x000fd000

Binary Images:
 

Re: [Mjpeg-users] y4mstabilizer segmentation fault

2009-06-03 Thread E Chalaron




I have been experiencing crashes with y4mstabiliser for a while now.
even with a proper pipe and mjpegtools.
Cheers
E

Hervé wrote:

  (update)
hello, I'm not developper but it could not be a buffer concern? (it's  
just an idea)

uname -a
Darwin MacMini-2.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31  
22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386

tests with the official release 190 (and not an RC nor recent CVS)
CL = … | /y4mstabilizer -v -v

-

commun parts to all tests (PS: I tried with y4mscaler or ppmtoy4m or  
ffmpeg, same results with all 444 converters):

[...]
INFO: [ppmtoy4m] Output Stream parameters:
[...]
INFO: [ppmtoy4m] chroma:  4:4:4 (no subsampling)
INFO: [ppmtoy4m] frame rate:  25/1 fps (~25.00)
INFO: [ppmtoy4m]  interlace:  none/progressive
INFO: [ppmtoy4m]   sample aspect ratio:  1:1
[...]
INFO: [y4mstabilizer]   chroma:  4:4:4 (no subsampling)
[...]
INFO: [y4mstabilizer]interlace:  none/progressive
INFO: [y4mstabilizer] sample aspect ratio:  1:1
INFO: [y4mstabilizer] Frame 1
INFO: [y4mstabilizer] global motion xy*2=0,2 Accumulated  
xy=0,1 shift xy=0,-1
[...]


-

test one: an HD file (720p)
crashed immediately:
INFO: [y4mstabilizer]   frame size:  1280x720 pixels (2764800 bytes)
INFO: [y4mstabilizer]   chroma:  4:4:4 (no subsampling)
INFO: [y4mstabilizer]   frame rate:  25/1 fps (~25.00)
INFO: [y4mstabilizer]interlace:  none/progressive
no outputed frame

-

test two: the same HD file (720p) but I rescaled it (720x576) before  
sending it to y4mscaler

INFO: [y4mstabilizer]   frame size:  720x576 pixels (1244160 bytes)
INFO: [y4mstabilizer]   chroma:  4:4:4 (no subsampling)
INFO: [y4mstabilizer]   frame rate:  25/1 fps (~25.00)
INFO: [y4mstabilizer]interlace:  none/progressive
INFO: [y4mstabilizer] sample aspect ratio:  1:1
INFO: [y4mstabilizer] Frame 1
INFO: [y4mstabilizer] global motion xy*2=0,2 Accumulated  
xy=0,1 shift xy=0,-1

INFO: [y4mstabilizer] Frame 2
INFO: [y4mstabilizer] global motion xy*2=0,0 Accumulated  
xy=0,0.95 shift xy=0,-1
[...]
INFO: [y4mstabilizer] Frame 265
INFO: [y4mstabilizer] global motion xy*2=0,-5 Accumulated  
xy=-1.45501,-19.4269 shift xy=1,19

INFO: [y4mstabilizer] Frame 266
(crashed)

-

test 3: the same HD file (720p) but I rescaled it (320*240) before  
sending it to y4mscaler

INFO: [y4mstabilizer]   frame size:  320x240 pixels (230400 bytes)
INFO: [y4mstabilizer]   chroma:  4:4:4 (no subsampling)
INFO: [y4mstabilizer]   frame rate:  25/1 fps (~25.00)
INFO: [y4mstabilizer]interlace:  none/progressive
INFO: [y4mstabilizer] sample aspect ratio:  1:1
INFO: [y4mstabilizer] Frame 1
INFO: [y4mstabilizer] global motion xy*2=0,1 Accumulated  
xy=0,0.5 shift xy=0,-1
[...]
INFO: [y4mstabilizer] Frame 1415
INFO: [y4mstabilizer] global motion xy*2=0,-20 Accumulated  
xy=3.60354,36.8782 shift xy=-4,-37

INFO: [y4mstabilizer] Frame 1416
(crashed)

-

test 4: the same HD file (720p) but I rescaled it (160*120) before  
sending it to y4mscaler

INFO: [y4mstabilizer]   frame size:  160x120 pixels (57600 bytes)
[...]
INFO: [y4mstabilizer] Frame 1
INFO: [y4mstabilizer] global motion xy*2=0,0 Accumulated  
xy=0,0 shift xy=0,0
[...]
INFO: [y4mstabilizer] Frame 1421
INFO: [y4mstabilizer] global motion xy*2=-1,-8 Accumulated  
xy=-0.721807,-10.8797 shift xy=1,11

INFO: [y4mstabilizer] Frame 1422
(and crash)

-

so,
littler size, more frames …seems that size matters (spam joke ;-))

-

crash log:

Process: y4mstabilizer [65490]
Path:/Users/herve/_Tools/_CVS/_MjpegTools/mjpegtools/ 
mjpegtools-1.9.0release_BIN/intel_Tiger-2009:02:20-25/y4mstabilizer
Identifier:  y4mstabilizer
Version: ??? (???)
Code Type:   X86 (Native)
Parent Process:  bash [65469]

Interval Since Last Report:  1056 sec
Crashes Since Last Report:   10
Per-App Interval Since Last Report:  0 sec
Per-App Crashes Since Last Report:   10

Date/Time:   2009-06-03 15:29:00.352 +0200
OS Version:  Mac OS X 10.5.7 (9J61)
Report Version:  6
Anonymous UUID:  8CDFC8BB-54FD-4F31-AF37-8EEF871D4795

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000fd000
Crashed Thread:  0

Thread 0 Crashed:
0   y4mstabilizer 	0x17c7 subsample + 75  
(y4mstabilizer.c:396)
1   y4mstabilizer 	0x480b main + 1214  
(y4mstabilizer.c:215)
2   y4mstabilizer 	0x175e _start + 216
3   y4mstabilizer 	0x1685 start + 41

Thread 0 crashed with X86 Thread State (32-bit):
   eax: 0x003fa680  ebx: 0x435e  ecx: 0x0500  edx: 0x0063
   edi: 0x000fd000  esi: 0x003fa400  ebp: 0xb318  esp: 0xb2f4
ss: 0x001f  efl: 0x00010202  eip: 0x17c7   

Re: [Mjpeg-users] y4mstabilizer segmentation fault

2009-06-02 Thread Steven M. Schultz

On Wed, 3 Jun 2009, Richard Archer wrote:

 I'm running mjpegtools on a Centos 5 x86_64 (Intel) system and 
 y4mstabilizer is crashing.

mjpegtools build either from the last release (end of Dec 2009) or from 
CVS (which
hasn't changed too much)?

 My source file is a snippet of interlaced video from a DVD.
 I pre-process it with ffmpeg and pipe it into y4mstabilizer. 

Oh - and I think that is the problem.

 I have also tried using yuvdeinterlace prior to y4mstabilizer 
 but then it crashes on frame 2.

I think it's the output from ffmpeg that's the problem.

 I have tried scaling the stream to 768x576 (SAR 1:1) but that 
 didn't help either.

Not necessary.

 Here's the setup and the results:
 
 $ ffmpeg -deinterlace -i test.m2v -r 25.000 -s 720x576 
 -aspect 4:3 -f yuv4mpegpipe -aspect 4:3 -pix_fmt yuv444p - | 
 y4mstabilizer -v -v /dev/null

ffmpeg doesn't know the rate or frame size?  I would have thought that 
none of those
options would be necessary if the input stream is properly formed.

The PROBLEM the use of -pix_fmt yuv444p.  -pix_fmt does not scale or 
resample the
data!!   -pix_fmt simply tells ffmpeg what value to put into the 
yuv4mpeg header.

So the next application is getting 4:2:0 data but is TOLD that the data 
is 4:4:4

and that I think is causing the problem.

MPEG-2 is 4:2:0.  The correct -pix_fmt ot use is 420p.

You need to use y4mscaler to do the chroma upsampling.

Maybe ffmpeg can do the chroma resampling but I'm fairly sure that 
-pix_fmt is not
the way to do it.

 Seems stream 0 codec frame rate differs from container frame rate: 50.00 
 (50/1) - 25.00 (25/1)
ffmpeg is saying your input is 50 frames/sec?  Hmmm, interesting.

 Input #0, mpegvideo, from 'test.m2v':
   Duration: 00:00:46.50, bitrate: 3938 kb/s
 Stream #0.0: Video: mpeg2video, yuv420p, 720x576 [PAR 16:15 DAR 4:3], 
 3938 kb/s, 25 tbr, 1200k tbn, 50 tbc
 Output #0, yuv4mpegpipe, to 'pipe:':
 Stream #0.0: Video: rawvideo, yuv444p, 720x576 [PAR 16:15 DAR 4:3], 
 q=2-31, 200 kb/s, 90k tbn, 25 tbc

UGH!  What is a PAR (Pixel Aspect Ratio) of 16:15?  PAL is something 
like 59:54 as 
I recall.  But then I always ignored the y4m header that ffmpeg output 
and
put on my own ;)

Maybe it's just as well the programs crashed :)  Looks like the video 
is being 
mangled.

 Press [q] to stop encoding
INFO: [y4mstabilizer]   frame size:  720x576 pixels (1244160 bytes)
INFO: [y4mstabilizer]   chroma:  4:4:4 (no subsampling)
INFO: [y4mstabilizer]   frame rate:  25/1 fps (~25.00)
INFO: [y4mstabilizer]interlace:  top-field-first
INFO: [y4mstabilizer] sample aspect ratio:  16:15

The 'frame size' is calculated by multiplying the width, height, and 
chroma sampling.
That value is correct for 4:4:4 but the data is still just 4:2:0

 And there ends my ability to debug this problem :(

I can't recall if there were issues with y4mstabilizer on the 64 bit 
platforms or
not.  I never used the program much and the author has abandoned the 
program
(you can try email to jmac8...@gmail.com (Jim) but I suspect he hasn't 
been actively
involved with the program for some time).

 I'm happy to follow instructions to help isolate the bug and 
 to apply patches and rebuild to test a solution.

I would try getting correct data into the program  before any more 
debugging ;)

with ffmpeg something like this might stand a better chance:

   ffmpeg -i test.m2v -pix_fmt yuv420p | \
   yyuvdeinterlace | \
   y4mscaler -v 0 -O sar=src -O chromass=444 | \
   y4mstablizer | \
   y4mscaler -v 0 -O sar=src -O chromass=420_MPEG2 | ...

the last y4mscaler goes back to 4:2:0 for encoding, etc.

My preference for decoding is to use 'mpeg2dec' but I think if you let 
ffmpeg emit
4:2:0 things will work OK.

Good Luck!

Cheers,
Steven Schultz


--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
___
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users