On Sat, 13 Nov 2004, Matt Kleffner wrote:
> I own a Sony DV camcorder (NTSC interlaced, bottom field first), and I
> want to store all recordings on DVD media (keeping tapes seems more
> expensive and less convenient). I want to preserve the original dv as
Hmmm, DV tapes are small and it's possible to store a large number
of them in a attache case type of enclosure.
> Someone at
> http://www.linuxquestions.org/questions/showthread.php?s=&forumid=57&threadid=242686
> pointed out that Kino issuing -f 8 to mpeg2enc results in DVD's that
> aren't hardware playable - he said -f 3 should be used in mpeg2enc and
That someone does not know what he (or she) is in error. I
(and others) have made many DVDs with 'mpeg2enc -f 8' and the discs
have played fine in a wide variety of hardware players.
> -f 8 in mplex. This individual gave his usage with transcode, so I
> tried that. However, by default transcode passed a de-interlace
I have avoided transcode for MPEG-2/DVD encoding. A simple shell
script that runs the mjpegtools works just as well as a complex
program...
> command (-I 0) to mpeg2enc, which is not a good idea as my source is
> as interlaced as you can get (each field sampled at a different time
> instant). I then used --encode_fields b to correct this.
>
> transcode -i inputfile.dv --encode_fields b -y mpeg2enc -w 7500 -b 224
> -s 2 -F 3,"-G 18 -c" -V -o tcfile.mpeg
Use the 'smilutils' and you don't have to worry about specifying
all of those parameters. smilutils is related to (but not part of)
Kino - should be available at the same place.
The above command becomes simply:
smil2yuv inputfile.dv | mpeg2enc -f 8 -q 4 -o tcfile.m2v
Much simpler, cleaner and easier, no?
> Resulting mpeg2enc command:
> mpeg2enc -v 0 -I 1 -q 3 -f 3 -4 2 -2 3 -b 7500 -s -F 4 -n n -a 2 -o
Where did the 'q 3' come from? If transcode's using that by default
then you will possibly see artifacting if you're using an IA32
system!
> I've read that a hardware DVD player supports average total bitrates
> up to 8000 kb/s with a peak of somewhere around 9800 kb/s, so I passed
> a bitrate of 7500 kb/s to transcode (although I've read that DVDR
> media may cause that bitrate to be limited to something like 6800 kb/s
> in some players). To my surprise the bitrate wasn't constant -
mpeg2enc is a VBR (Variable Bit Rate) encoder.
> control the process more carefully, I grabbed most of the options
> transcode set and used smil2yuv as the input to mpeg2enc.
Ah, so you know about smilutils. Good!
> Next I tried filtering with yuvdenoise, yuvmedianfilter and throwing
> away high-frequency blocks (-N). Radii of 2 and 1 were tried with the
> median filter and -N 1 and -N 2 were tried in removing high-frequency
> blocks.
That's a lot of encoding runs :)
> VISUAL RESULTS:
> I used snapshots to evaluate the results - I had almost the same frame
> from each clip (see question at end). Lots of detail is present in the
> moment I chose. I couldn't really tell a difference between the
> default clip, the "-r 1 -R 1" median filter clip, and the "-N 1" clip
> - maybe there is a difference in peak-bitrate portions but I did not
> attempt to discover that in this test. The "-N 2" clip was little too
> blocky and given that the bitrate didn't drop much, I didn't
> investigate any other -N values and dropped this from consideration.
I think the documentation mentions that values of 2 or higher are
probably not good.
Did you try using the alternate (or even a custom) quantization
matrices? "-K kvcd", "-K tmpgenc" or "-K file=yourfile" (where
'yourfile' is 128 numbers (two blocks of 64) could give better
results than high values of -N.
> Yuvdenoise clip
> Yuvdenoise does not seem to be a good filter for clips with lots of
> motion (panning in this case). The temporal lowpass filtering washed
Hmmm, improvements have been made over the last year but I do not know
if they'd address your concerns.
yuvdenoise is useful for noisy (VHS) material - if you have clean
(from a DV camcorder) source then I would not use yuvdenoise. OR
perhaps "yuvdenoise -f" (the fast/bitnoise mode) only.
> Median-filtered clip
> The median filter at the default settings seems more satisfying as a)
> it appears to work in space and not time and b) it is nonlinear so
There is, in CVS, a spatial only filter 'y4mspatialfilter' you
may want to experiment with as well.
> edges should be preserved well. Results were reasonable - noise was
> reduced somewhat but textures weren't washed out. The only drawback I
> noticed is that the color space seems compressed slightly - whites in
Hmmm, medianfilter doesn't perform any "compression" or "scaling"
that I know of. It could be that what you're seeing is just what
median filtering does to a video stream ;)
> if you are looking for it. The major advantage of this filter appears
> to be that it gives a good result while lowering the bitrate by 30%.
> The picture is degraded somewhat but no "blocky" artifacts appear to
It's also possible to filter only the chroma or only the luma
components.
I wonder if the color compression effect would be reduced or
eliminated if you did "yuvmedianfilter -T 0" to disable the
processing of the chroma planes.
> Current conclusions and questions
> >From a bitrate perspective it seems I should just keep the "default"
> settings of mpeg2enc with no filter - although I haven't explored how
For clean material (not an old VHS tape) you don't want any filters
except perhaps a modest/conservative use of 'y4mspatialfilter'.
With good material and not using any filters it would be, I think,
better to explore the use of "-K" and the quantization matrices.
There are 3 that are "builtin" to mpeg2enc: "tmpgenc" (from the
TMPGEnc encoder) and "kvcd" (from Kvcd.net), "hi-res" (standard MPEG-2
HI-resolution - and your bitrate will go thru the roof!). You can
also craft your own - I often use a custom table that consists of the
'hi-res' Intra table and the 'tmpgenc' Inter (non-intra) table. Should
be available in the archives ;)
> high-motion/high-detail frames might suffer when noise isn't reduced
> (does anyone have any advice here?). If I am concerned about reducing
> the bitrate due to media/hardware limitations I should use the median
> filter - apparently I can get a 30% reduction in average bitrate
Or 'y4mspatialfilter' as a conservative 'low pass' spatial filter.
It's in CVS only though.
As for the questions - well, I'll just answer the ones I know the
answers to and leave the rest for someone else :)
> Question:
> Should I use -I 2 instead of -I 1? What are the trade-offs? Is -I 2 no
> longer being maintained? (My Debian binary segfaults with this option,
Hmm, prebuilt binary? Could be a bug in how it was built or some
other incompatibilty.
Short answer the question: leave -I alone. The encoder knows how
to use either -I 0 or -I 1 as appropriate.
Longer answer: Use -I 0 only if you have progressive films. The
encoder will automatically use -I 1 if you have interlaced content.
-I 2 may be buggy - it used to work but not a lot of effort has gone
into it for some time.
> Question:
> I wanted to provide links to bitmaps of the frames I used, but they
> were grabbed with a snapshot program and I wasn't entirely convinced I
> was comparing "apples to apples". How can I grab exactly the same
> frame from each clip for comparison? I am using Debian so I am unable
> to locate packages for an mpeg2 nle like LVE, and Mplayer and Xine
That's what compilers are for, no? TO build things with, right? ;)
> Question:
> Since I am interested in primarily "preserving the original", should I
> even be considering variable bitrates? Should I just max out the
I think so. The only way to "preserve the original" is to hold on
to the DV tapes - but you knew that.
> bitrate? What are the disadvantages of doing this (besides reducing
> playing time of a disc). At constant, high bitrates will I notice a
> difference between high and low-detail frames?
I've had enough CBR vs VBR for the month - I'll let someone else
jump in at this point. CBR from the MPEG-1 era meant 'padding' -
if the rate was low then extra/empty padding bits were stuffed in
to keep the bitrate constant.
> Question:
> If variable bitrates are the way to go, would I get better results
> using an encoder that supports two-pass encoding? My understanding is
> that mpeg2enc is single-pass. The only free-software competitor I am
> aware of that does two-pass encoding is ffmpeg. What is the opinion of
Hmmm, I saw they have a 2 pass option but wasn't sure if that applied
to the MPEG-2 encoder part or just the MPEG-4/DivX portion.
> mjpeg-users of high-vbr, two-pass encoding quality of ffmpeg compared
> to high-vbr mpeg2enc? Given the above commands, can anyone suggest a
Oh, you'll get a little better quality out of a 2 pass encoder but
I've yet to be convinced it's worth waiting twice as long.
> Question:
> Does mjpeg2enc do any [16...235] to [0...255] conversion? Should I be
mpeg2enc
> interested in keeping the range as it is?
No. That would be illegal (for broadcast) to go that way (expanding
the range to the full 8 bits). Or did you mean [0...255] to
[16...235] (for Luma) and [16...240] (for chroma)?
The stream must be conformant before it enters the encoder. A few
"superwhite" or "superblack" samples aren't going to kill anything
but if the data is consistently outside the broadcast range it'll
look bad on the TV. I think there should be an option for the
encoder to check the input stream and complain if out of range values
are being presented but at the present time that is not being done -
you can feed complete nonsense into the encoder and it'll encode it :)
> Question:
> Are there any errors in my assumptions, understanding, or reasoning?
> Any other advice is appreciated. Again, my primary goal is to use DVD
> media as my primary video storage medium, and I want to preserve the
> original dv as best as I can within the hardware DVD spec.
That's why I'm holding on to my DV tapes (and several 160GB drives
of captured data - I really should go 'print to video' and export
that data back out to miniDV tapes one of these days). That way I
can, when the tools improve, go and create new DVDs.
For the older stuff of lower quality (VHS tapes) the primary goal
was to have something that wouldn't degrade each time it was played
(and wouldn't degrade just by time passing by). Max play time was
the goal there. For higher quality items such as the laser discs
more care (and less filtering) was used and I kept the DV data around
in addition to making the DVDs.
If you're going for 'preservation' then it would be worth your time
to get the CVS version of the tools! 1.6.2 is old (almost a year now
and it doesn't look like a release is due out any time soon) and a lot
of improvements (some small, some bigger) and fixes have been made.
Good Luck!
Steven Schultz
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Mjpeg-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mjpeg-users
