On Wed, 17 Nov 2004, Matt Kleffner wrote:
> I am reconsidering and I may in fact keep the original DV. I can do
> this on tapes or DVD+R. I have a Digital 8 camcorder, so the tapes are
> bigger than miniDV and compatibility with future playback devices is
It's possible (I did it when I moved from D8 to DV) to copy directly
from the D8 to the DV camcoder - just put a 4 to 4 pin IEEE1394
cable between the two and dub the tape.
> questionable. The cost per gig (and possibly space used) favors +R but
> I can only store twenty minutes of DV on a +R (35 minutes if +R DL's
The compatibility if the DVD+R9 (DL) media is going thru its
growing pains at the moment (not to mention that the price is
very high - around $11 each). A $7 DV tape can hold 60min in
standard mode and there are 80min tapes available for $9.
> were cheaply available). The remaining factor that is important to me
> is bit rot. It seems that anyone serious about backing up data does it
> on tape that is subsequently stored in a carefully-climate-controlled
> environment. How robust are tapes in a household environment?
I haven't had a problem with the Hi8/D8/DV tapes so far. Keep them
out of direct sunlight and away from the heating vents and they last
a long time. Certainly longer (and in better shape) than some of the
VHS tapes I've dealt with.
> (Magnetic fields, heat could cause problems.) The longevity of DVDR's
> and CDR's is now being questioned - does anyone know how disc media
> reliability compares to tape media reliability (household storage)
I have had quite a few (more than I expected) cases of "bit rot"
with CD media - some of which was only 3 or 4 years old. BUT, that
was a case of "you get what you pay for". The "cheap" media which
seemed like a good deal at the time is what failed most often - the
name brands that cost more have fared better.
DVDs have better error correction than CDs and there appears to be
better protection of the surfaces (CDs were very easy to destroy by
scratching, especially the top side - DVDs take a lot more effort
to damage).
> discussion of this topic? It seems that either way I will have to be
> prepared to carry the data to more "modern" media over time.
My philosophy exactly. In a few years there'll be afforable "Blu Ray"
(~25-50GB) "DVD" recorders. At that time the migration will be from
~4GB to 25GB media - just as I moved from CD to DVD a short time ago
(and it's about the same 6-7x size jump).
> > 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!
>
> Could you explain why q 3 likely results in artifacting? Why is q 4 a
I'm not sure how good the mailinglist archive search function is these
days - the problem has had many references in the past.
> better choice? Doesn't it result in slightly lower quality? Is q 4 a
What's lower quality than visible artifacts? :)
> better choice because of the max bitrate I have selected? (Why only
> IA32 and not any CPU? Bugs in assembly routines?)
Because the IA32 DCT/iDCT/quantization MMX routines can experience
undetected/corrected overflow and the Altivec routines check for and
avoid the problem.
> > 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.
>
> OK, I'll stick to -K.
-N was introduced as a bitrate saving measure before the ability to
specify alternate quantization matrices existed. -N used in moderation
(values less than 1.0!) was quite effective at reducing the bitrate
without visibly degrading the image.
The TMPGEnc tables work very well.
> I don't think I have a good grasp of what "noisy video" is. I can
> easily see some noise in my video (probably due in part to some color
Try watching a VHS tape and you're seeing noise :)
> seen an "uncleaned", digitized VHS tape - I may not truly know what
> "noisy" looks like. For now I will assume my DV is "clean" with
> respect to this filter.
Depending on what camcorder you have (the Sony TRV120 I had at one time)
could function as a analog->digital conversion unit - plug the analog
audio/video cables from a VHS deck into it (I used S-Video cable) and
then attach the IEEE1394 port to a machine running Kino or dvgrab.
> > There is, in CVS, a spatial only filter 'y4mspatialfilter' you
> > may want to experiment with as well.
>
> Oops... so yuvmedianfilter operates in time as well... it wasn't clear
No, yuvmedianfilter is not a temporal filter - it operates only on
1 frame at a time.
There's more than one way to filter data in either the spatial or
temporal domain.
Think of 'y4mspatialfilter' as a "low pass filter" and you'll get
the idea (mainly because that's what it is :)).
If you crank down the percentage of bandwidth to pass thru then
details will get blurred of course.
I'd start with a very conservative setting of "-L 5,0.85,5,0.85" and
and gradually lower the percentage from 0.85 until the effect is
just visible - then use the a slightly higher value. For D8/DV
source I don't think you'll see an effect until you get to 0.8 or
below (and that's good) but the bitrate will be slightly lower -
allowing more playtime on a disc.
For VHS (and especially older tapes) I tend to use 0.75 to 0.7.
There's also the -C option for processing the chroma - it's not
as critical because the chroma planes are so subsampled.
> If I can get my output into lav2yuv I can take snapshots. Can mpec2enc
> produce output that is readable by lav2yuv or do I need to pass its
mpeg2enc is a MPEG-2 encoder - it takes "YUV4MPEG" (4:2:0 Y'Cbcr)
data in and emits MPEG-2 out. lav2yuv is not a MPEG-2 decoder so
no, you can use the output of mpeg2enc as input to a "lav*" program.
What you may want to look at is a mpeg2 decoder such as mpeg2dec
http://sourceforge.net/projects/libmpeg2/
it can produce various output formats - two of which ('pgm' and
'pgmpipe') can be used to get individual frames out. Those formats
contain the Y'CbCr planes in an interesting arrangment that only
'pgmtoy4m' from mjpegtools really knows how to deal with).
> output through another program? My lav2yuv binary asks for avi or
> quicktime - are more file types supported if I compile it myself with
> the right options?
If you want "YUV" then you need to decode the MPEG-2 file - that's
mpeg2dec's job and not anything that lav2yuv can do.
> I thought that it might be better to have the output scaled to the
> full range for encoding, for computer viewing and in case future "TV"
Scaling the output damages it, at least a little bit. It is already
as "full range" as it should be when it comes out of the camcorder.
Future TVs will have the same limits for broadcast safe colors so
there's no reason to take a 16-235 range up to 0-255 and then back
down again. You'd be surprised how doing that a few times lowers
the visible quality (subtle color shifts too).
> question for my amateur purposes and it appears that I should just
> leave this alone.
For archival purposes that's a very good thing to do. Preservation
efforts should do NO processing that can't be perfectly undone later.
> Yes, I think I will keep the original DV as well. I didn't originally
The only other way to retain the originals would be with a RAID-5
storage array (preferably duplicated offsite). At 12GB/hour you can
get about 80 hours per terabyte... ;)
> know that a DV stream is encoded frame-by-frame (or field-by-field)
Yes, 120000 bytes/frame (25Mb/s). It's a 5 to 1 compression from the
original ~124Mb/s rate (uncompressed digital video).
> instead of as a series of frames, therefore lending itself more easily
> to editing than mpeg2.
MPEG2 is not an editing format ;) Oh, it can be made better if
a short GOP length is used and the GOPs are closed but editing MPEG2
involves a decode, edit, recode cycle that that can degrade the
quality (especially if the process is repeated a few times).
> I'll try the CVS tools with -K and y4mspatialfilter. Do I get the
> latest version or is there a more "stable" CVS version that I should get?
Regular CVS checkout from the "head" is the thing to use. The CVS
version has been stable for a long time. We're just having delays
getting a release cycle started ;)
Cheers,
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
