On Sat, 13 Nov 2004 20:51:29 -0800 (PST), Steven M. Schultz wrote: > > 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.
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 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 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? (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) when a) the media are almost never "read" over many years and b) the media are frequently read? Does anyone have a link to a good 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. > 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 better choice? Doesn't it result in slightly lower quality? Is q 4 a better choice because of the max bitrate I have selected? (Why only IA32 and not any CPU? Bugs in assembly routines?) > 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. OK, I'll stick to -K. > 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. 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 aliasing from the CCD), but the SNR is probably high. I have never 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. > 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 in the man page what "This filter looks _around_ the current point for a radius..." meant (emphasis added). > 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 ;) OK, I'll try these out. > > 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 > > That's what compilers are for, no? TO build things with, right? ;) 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 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? > > 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 :) 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" uses the full range. However, I think this was too much of an expert question for my amateur purposes and it appears that I should just leave this alone. > > 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. Yes, I think I will keep the original DV as well. I didn't originally know that a DV stream is encoded frame-by-frame (or field-by-field) instead of as a series of frames, therefore lending itself more easily to editing than mpeg2. 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? Thanks for the advice! - Matt ------------------------------------------------------- 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
