Steven M. Schultz wrote:
On Sat, 5 Nov 2005, [ISO-8859-1] Bernhard Fr�hmesser wrote:
I have a very old Video from a VHS source (about 20 years old).
The tape has certainly deteriorated then and is in need of
color correction. I've attached an image cut from the color correction
tool I use (the entire screen shot would be far too large for the
mailinglist). On the left is the "before" and on the "right" is
the corrected version.
Yep, definitely. Which color correction tool are you using (yuvcorrect?
:-) )
I did this:
What version of the tools are you using? The old 1.6.2, the recent
release (1.8.0) or even better (where the dynamic GOP size logic is
operational) the CVS version?
I use version 1.8.0 here.
lav2yuv testing.liste | yuvcorrect -Y CONFORM | y4mshift -n -8 -N 8 |
y4mscaler -O size=720x576 -I active=720x564+0+12 | yuvmedianfilter -I 1
| y4mdenoise -t 2/4 | y4munsharp | mpeg2enc -f 8 -I 0 -4 1 -2 1 -q 6 - b
4500 -V 450 -P -g 7 -G 14 -N 1.0 -M 2 -E -10 -a 2 -o videotest3.mpg
But after 11 Frames it all stopped with this as last output:
INFO: [y4mscaler] Frame number 12
INFO: [yuvcorrect] Frame number 14
Actually in this case the output _before_ the pipeline stalls
would be more valuable - that is where the programs log their
parameters.
Can anybody tell me what�s going wrong here?
There are what appear to be 2 typos in the command (maybe only 1
depending how the cut&paste worked). The 'script' program is
very useful for this type of output capture ;)
Ups yep, i missed somthing here :-)
With your version below it works, but i have still used y4mscaler too as
only with y4mshift this will result in a big big black border on the
right and on the top.
So far i have tested two versions of the cmd(s), for both versions i
have uploaded a picture of the "finished" mpeg to:
http://vi06n235.members.eunet.at/picture_test1.jpg
This is the result of following command(s):
v2yuv 24.liste | yuvcorrect -Y CONFORM | y4mshift -n -8 -N 8 | \
y4mscaler -O size=720x576 -I active=720x564+0+12 | yuvmedianfilter |
y4mdenoise -t 3 -z 3 | y4munsharp | mpeg2enc -f 8 -4 1 -2 1 -q 6 -b 4500
-K tmpgenc -E -10 -o videotest24.liste
The second picture at :
http://vi06n235.members.eunet.at/picture_test2.jpg
comes from this command(s):
lav2yuv 24.liste | yuvcorrect -Y CONFORM | y4mshift -n -8 -N 8 |
y4mscaler -O size=720x576 -I active=720x564+0+12 | yuvmedianfilter |
y4mdenoise -t 4 -z 3 | mpeg2enc -f 8 -4 1 -2 1 -q 6 -b 4500 -K tmpgenc
-E -10 -o video24_2.mpg
So i don´t see that much difference between the two, and it still looks
somehow to be interlaced (pay attention on the ppl on the picture and on
this small orange flag on the bottom).
This picture here:
http://vi06n235.members.eunet.at/picture_original.jpg
is from the source mov file i recorded with lavrec from the VHS tape.
I remember in version 1.6.2 of the mjpegtools i used yuvdenoise -F which
worked very well to deinterlace (for myself), is there anything i can do
here to get rid of that lines in the video and to improve quality a bit
more? I know, since the source is already 20 years old and the camera
which was used to record wasn´t that good (for nowadays) there might be
not much i can do, but then...
Thanks,
BF.
1. the arg to y4mdenoise should be "-t 4" not "-t 4/2"
y4mdenoise -t 2/4
should be simply
y4mdenoise -t 4
and probably, per the manpage, should be
y4mdenoise -t 4 -z 3
2. There appears to be a space between the '-' and the 'b' in the
mpeg2enc command:
mpeg2enc -f 8 -I 0 -4 1 -2 1 -q 6 - b
should be
mpeg2enc -f 8 -I 0 -4 1 -2 1 -q 6 -b
There are also several needless (most likely harmless but could
mask problems by silently overriding stream parameters).
The mpeg2enc command doesn't need "-I 0" (that's the default), the
"-a 2" (aspect will be picked up from the input stream and should
almost never be overridden/specified) and "-V 450" is needless
(when you gave "-f 8" the -V value was set to 224, higher values such
as 488 are only needed for HD bitrates and 4500 is not "High Def").
ALSO, "-g" is a NO-OP and is ignored. Then too the -M value defaults
to 0 for a reason - there is a race condition in the threading code.
-G isn't needed, the max for "PAL" is 15 so nothing really is gained
by forcing the max to 14. The "controversial" part is using B frames,
I've always gotten smaller files (lower bitrate) with "-R 0" (the
default) instead of "-P".
The above mpeg2enc command turns into
mpeg2enc -f 8 -4 1 -2 1 -q 6 -b 4500 -N 1.0 -E -10 -o videotest3.mpg
You might find that "-N 1.0" softens the image a bit too much - I think
better results would be obtained by using the TMPGEnc quantization
matrices:
mpeg2enc -f 8 -4 1 -2 1 -q 6 -b 4500 -K tmpgenc -E -10 -o videotest3.mpg
Turning the border areas to black is a Good Idea. y4mscaler can, as
you've noticed, do the job. But did you know that 'y4mshift' can do
it too - and at the same time as the shifting is being done? So
instead of "y4mshift | yuvscaler" a single y4mshift command is
enough:
y4mshift -n -8 -N 8 | y4mscaler -O size=720x576 -I active=720x564+0+12
can be replaced with
y4mshift -n -8 -N 8 -b 0,12,720,564
saves a stage in the pipeline - the data doesn't have to go down and
up another set of pipes.
Summary: The pipeline can be rewritten as
lav2yuv testing.liste | yuvcorrect -Y CONFORM | \
y4mshift -n -8 -N 8 -b -b 0,12,720,564 | \
yuvmedianfilter | \
y4mdenoise -t 4 -z 3 | y4munsharp |
mpeg2enc -f 8 -4 1 -2 1 -q 6 -b 4500 -K tmpgenc -E -10 -o videotest3.mpg
If that doesn't work perhaps the info logged before the pipeline
goes to sleep will provide a clue.
Cheers,
Steven Schultz
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Mjpeg-users mailing list
Mjpeg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
