Re: [Mjpeg-users] y4mstabilizer segmentation fault

[Richard A. <rh...@ju...>]

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 <wa...@zo...> 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.000000)
   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.