On Sat, 3 Jun 2006, E.Chalaron wrote:

> Got some troubles here with probably y4mstabilizer

        Oh, you've got a problem but I don't think it's with y4mstabilizer ;)

> However, things are getting tricky because when I use stream of a picture of 
> 1244x934 or 1008x764 , guess what ... it works :-)

        And that's the type of problem you've had in the past as I recall.

        Certain sizes would cause y4mscaler to compute scaling factors which
        overflowed and caused the program to abort.  That would break the
        pipeline and you'd have things "mysteriously" come to a grinding
        halt.

> BTW frames are square pixels and prog.

> Any ideas ?? thanks a lot

        This is for displaying on a computer from the looks of it - can't
        be putting 1024x768 on a DVD ;)

> #!/bin/bash
> reel_name=$1
> lum=$2
> (find . -name \* -type f | sort | xargs cat) | yuyvtoy4m -w 1116 -h 832 -a 1:1

        Ok - I'll ask, why "-name \*"?

        find . -type f | sort | xargs cat

        will work just fine.

> -i p -r 17:1 | y4mscaler -v 1 -O chromass=444 | y4mstabilizer -a  0.7 | yuvd
> enoise | y4munsharp | yuvcorrect -v 0 -Y LUMINANCE_"$lum"_16_235_16_235 | 
> y4mscaler -v 0 -O size=1024x768 -O chromass=422 | y4mshift -b 8,8,1008,752 | 

        When having problems it's a GOOD idea to turn on as much logging
        as possible.  'y4mscaler -v 0' is disabling the logging from the 2nd
        y4mscaler.  Not sure if the extra info will help but it can't hurt ;)

>    INFO: [y4munsharp] Luma amount: 0.300000
>    INFO: [y4munsharp] Luma threshold: 4
>    INFO: [yuvcorrect] yuvcorrect 1.9.0 (16-11-2002) is a general image 
> correction utility for yuv frames
>    INFO: [yuvcorrect] (C) 2002 Xavier Biquard <[EMAIL PROTECTED]>, yuvcorrect 
> -h for usage, or man yuvcorrect
>    INFO: [y4mscaler] Frame number 1
> xargs: cat: terminated by signal 13

        THERE is the explicit symptom of the problem.  'cat' is getting a 
        SIGPIPE because something later in the pipeline is exiting and
        breaking the pipe.

        What version (y4mscaler -V) of y4mscaler are you using?  I thought
        Matt had changed the scaling calculations to use either floating point
        or 64bit arithmetic to get around the problem you'd encountered in the
        past. 

        The other possibility is that with lengthy pipelines it's easy to
        introduce a syntax error.  It's easy to, especially when cutting&pasting
        to accidentally create an incorrect option to a command,  leave out a
        | or other error.  Can be hard to find - good indentation and so 
        on can help make those errors easier to spot/avoid.  That's why I find
        something like this:

(find . -type f | sort | xargs cat) | \
   yuyvtoy4m -w 1116 -h 832 -a 1:1 -i p -r 17:1 | \
   y4mscaler -v 1 -O chromass=444 | \
   y4mstabilizer -a  0.7 | yuvdenoise | \
   y4munsharp | \
   yuvcorrect -v 0 -Y LUMINANCE_"$lum"_16_235_16_235 | \
   y4mscaler -v 0 -O size=1024x768 -O chromass=422 |  \
   y4mshift -b 8,8,1008,752 |  yuvflip -H | \
   y4mtoqt -o "$reel_name"

        preferable to:

(find . -type f | sort | xargs cat) |yuyvtoy4m -w 1116 -h 832 -a 1:1 -i p -r 
17:1 | y4mscaler -v 1 -O chromass=444 | y4mstabilizer -a  0.7 | yuvdenoise | 
y4munsharp | yuvcorrect -v 0 -Y LUMINANCE_"$lum"_16_235_16_235 | y4mscaler -v 0 
-O size=1024x768 -O chromass=422|y4mshift -b 8,8,1008,752 |yuvflip -H | y4mtoqt 
-o "$reel_name"

        :)

        Cheers,
        Steven Schultz



_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users

Reply via email to