Quantcast Encoding miniDV tapes - XViD or progressive H264? - Page 2 - digitalFAQ Forum
Go Back    Forum > Digital Video > Video Project Help > Encode, Convert for streaming

Reply
 
LinkBack Thread Tools
  #21  
11-25-2015, 06:17 PM
ozshots ozshots is offline
Free Member
 
Join Date: Nov 2015
Posts: 19
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by sanlyn View Post
. Of course if a hard drive goes on the blitz and you have 40 videos on it, well....
I'm using RAID mirror for all valuable data, plus rotating offsite backup (HDD left at work). Learned that a hard way ;-/

I wouldn't bother resizing SD video if its aspect ratio is already 16:9. Set top players and most TV's and Smart TV's can scale to your TV's frame a lot better than the resizers and deinterlacers in most one-stop apps and NLE's.

Quote:
Originally Posted by sanlyn View Post
.Avisynth isn't that difficult if you start with some decent samples.
Can you please point me to 1-2-3 guide?
Reply With Quote
Someday, 12:01 PM
admin's Avatar
Ads / Sponsors
 
Join Date: ∞
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
  #22  
11-25-2015, 11:10 PM
sanlyn sanlyn is offline
Premium Member
 
Join Date: Aug 2009
Location: N. Carolina and NY, USA
Posts: 3,648
Thanked 1,198 Times in 959 Posts
The best examples are .avs scripts and Virtualdub filter examples in the restoration and capture forums. There are several r cent projects. One that i can link to now has source video so badly degraded that it makes your look like an MGM movie. Keep in mind that with many of these projects, the filters and exact procedures won't usually apply to your own projects -- there aren't any "one-size-fits-all" solutions in video work. The examples in this project won't tell you how to fix your video. But you'll get an idea what an avs script looks like, how the statements flow, and how they work. You'll notice that some filters or functions are used repeatedly, but with different settings. Besides, the video in the linked project was just too far gone for much real improvement.

Try browsing the images, scripts and explanations in this thread, VirtualDub filters to improve color?, posts #21, #22, #27, and #31. You're welcome to look over the entire thread, if you want.

After the big holiday rush smooths down here in Tennessee, I'll clean and post the scripts I used for the videos I posted earlier. Thanks for your patience.
Reply With Quote
  #23  
11-26-2015, 08:27 PM
ozshots ozshots is offline
Free Member
 
Join Date: Nov 2015
Posts: 19
Thanked 0 Times in 0 Posts
Thank you for a very useful thread!
VirtualDub filters to improve color?

This should be on Avisynh website "how to get started"! I will try to follow it and get Avisynh installed and configured.

I hope you are having a great holidays!
Reply With Quote
  #24  
11-30-2015, 06:08 PM
sanlyn sanlyn is offline
Premium Member
 
Join Date: Aug 2009
Location: N. Carolina and NY, USA
Posts: 3,648
Thanked 1,198 Times in 959 Posts
Sorry for the delay. Holidays are getting to be such chaos nowadays.

Well, take a breath and relax.....Most of this will be brand new. Why there is no one-stop tutorial for this seems odd t me. But it would certainly be one long, long tutorial. At least this is the sort of thing you learn once and just repeat, more or less.

This is the workflow, scripts, and filters I used on the video samples in post #5 (Encoding miniDV tapes - XViD or progressive H264?). You can always do things the way you want, and others might get the same results differenly.

Let's start with Daylight.avi. I used two Avisynth scripts, in two steps. The first script makes basic YUV color and levels adjustments, then deinterlaces/denoises, then converts to RGB for VirtualDub filters. The output was saved in Virtualdub to Lagarith lossless YV12. Next, script #2 resizes that output to HD 1280x720, which is also BluRayAVCHD compatible. Why use two steps? Frankly, if I had upscaled in the first script I'd have to hassle with big frames in Virtualdub. I avoid big frames until the end, if I can. The upscale also used 16-bit dithering plugins which use different support files than QTGMC. You could do it all in one script, but running a long script that does a lot of work is slo-o-o-o-ow. And sometimes you want to use two steps because Step 2 might be altered for some reason and it's a chore to run all the steps again from the start just for the last procedure.

The first Avisynth script for Daylight.avi (Step 1):

Code:
AviSource("E:\forum\ozshots\Daylight.avi")
ConvertToYV12(interlaced=true)
ColorYuv(off_y=-8,cont_u=-40)
SmoothLevels(16,0.90,255,16,245,chroma=200,limiter=0,tvrange=true,dither=100,protect=6)
SmoothTweak(saturation=1.15)
AssumeBFF().QTGMC(preset="medium",sharpness=0.7)
ConvertToRGB32(matrix="Rec601",interlaced=false)
AviSource("E:\forum\ozshots\Daylight.avi")
ConvertToYV12(interlaced=true):

The first statement opens and decodes the AVI. The path statement "E:\forum\ozshots\Daylight.avi" tells Avisynth that AVI's location in my system. You would have to edit that path statement for your system. AviSource() can open SONY DV because I have that codec in my system. Other formats like MPEG, h264 containers, etc., have other Avisynth functions and plugins to open those formats. I had to use "ConvertToYV12(interlaced=true)" to get plain vanilla YV12 as Avisynth's plugins know it, because SONY's DV codec is DVSD, a different flavor of YUV that stores chroma data in a manner that some Avisynth plugins don't interpret as "YV12". Note that "interlaced=true" has to be included for interlaced video -- otherwise, chroma gets interpreted as progressive and, thus, gets screwed up.

ColorYuv(off_y=-8,cont_u=-40):
The black level and gamma are too high. Basically the video is too bright, off to the right side of a histogram. The brights are clipped, as explained in an earlier post. Unfortunately I don't know how they got that way (Vegas, perhaps, did an sRGB conversion before saving it as SONY DV? I don't know how the sample was made). "off_y=-8" shifts all luma and color values 8 points to the left or dark end, and "cont_y=-40" lowers contrast to keep some of those brights from looking too "hot" when displayed in RGB. Often you would use this to help retrieve some blown-out highlights, but in this case the clipping had already occurred earlier but we'd not want to make it worse.

SmoothLevels(16,0.90,255,16,245,chroma=200,limiter =0,tvrange=true,dither=100,protect=6):
SmoothLevels() is a function in Avisynth's SmoothAdjust plugin. It's a more sophisticated version of Avisynth's built-in Levels() function. It's strength is that it uses parameters that can adjust its operations and uses dithering techniques to avoid banding issues or hard edges on gradients. Facial tones and soft gradations from darker to lighter areas of the face are examples of areas where hard edges and banding can occur during color adjustment or denoising.

The first 5 numbers in the SmoothLevels statement work this way: "16" is the dark level input starting point, specified as RGB 16. "0.90" adjusts gamma: the default is 1.0, but to bring midtones down to a more natural level gamma is adjusted down a bit. "255" represents the limit of bright level input to work with. The next "16" is what we want for dark level output -- in this case, the dark level's bottom was specified as RGB 16 and we want to keep RGB 16 values as-is. "245" is the bright level output target: with the hard bright clipping in this video, the specified "255" input values are gently toned down to RGB 245, or just enough to keep brights in histograms within RGB 16-245. Specifying 240 for bright output was a bit dark, so I used 245 to put a little snap in the brights without overrun into the unsafe bright area. In this case, a very slight amount of overrun wouldn't matter much, because the video is clipped anyway.

Other values in SmoothLevels(): chroma=200 specifies full dithering power for chroma adjustment. Limiter=0 specifies no clamping or crushing at bright or dark extremes. tvrange=true means, of course, to work with the desired RGB 16-235 range for video. dither=100 means do all the dithering you can (which is a bit slower than the default), and protect=6 means to make no adjustments on RGB values of RGB 6 or darker.

SmoothTweak(saturation=1.15):
SmoothTweak() is another function in the SmoothAdjust plugin. It increases color saturation in this somewhat washed-out video and, for video with bright clipping, it helps to add the impression of a bit more dynamic range than is possible with clipping. This function also performs chroma dithering to prevent hard edges on gradients and soft-edged shadows. The default is 1.0. Small saturation values with this plugin can go a long way, so be careful.

AssumeBFF().QTGMC(preset="medium",sharpness=0.7):
Obviously we want to insure that QTGMC knows that the interlaced fields are Bottom Field First (BFF). BFF is actually the default for Avisynth, but obsessive-compulsives like Yours Truly want to be certain about these things. The "medium" preset does some pretty good denoising and anti-aliasing without oversmoothing. The default denoiser in the "medium" preset is dfttest, which helps with macroblocks and DV compression artifacts. The default sharpness is 1.0, but I used 0.7 to avoid oversharpening effects, which are common with DV.

ConvertToRGB32(matrix="Rec601",interlaced=false):
Converts YV12 to RGB for VirtualDub processing. At this point the video is 50fps progressive, not interlaced. "Rec601" is the color matrix being used here for standard definition video.

VirtualDub processing:
While the Avisynth decoded and filtered output is being monitored in VirtualDub, I added some VDub filters to clean up Avisynth's output. Usually you can apply VDub filters on Avisynth output using "full processing mode", unless your script runs so slowly that jockeying back and forth in the video to check filter results puts you into an apoplectic state. In this case, things were going fast enough to make VDub filtration practical during a single run.

The three VDub filters used were gradation curves, ColorMill, and VDub's built-in "Levels". I also added VDub's ColorTools RGB histogram to check the results.

Below: VirtualDub with the ColorMill filter in action! ColorMill uses sliders that affect the image in all colors in three main ranges: darks, midtones, and brights, separately or all at once. In this image, the "Middle Point" is being adjusted upward slightly, from 0 to 2. In RGB, the center of the spectrum is RGB 128. The midpoint slider can raise or lower that target. In this case it's raised just a bit to lend the impression of greater "presence" to the image without affecting darks or brights.


Below: The VirtualDub "Levels" filter with its histogram activated. The adjustment here is strictly in the darks (left-hand pointer arrow) without affecting mids or brights. This is a very subtle adjustment but it adds a greater impression of depth.


Below: VDub's gradation curve is used to raise the midtone values just a tiny bit without affecting other parts of the spectrum, yet it also makes the image look brighter. The effects shown in these reduced images are subtle -- easier to see when using the real thing. Here, the RGB curve is also bent a little at the top right to tame the brightest colors above RGB 220. The small "dots" along the curve (diagonal line) are anchor points that hold the other parts of the curve in place.


Below: RGB histograms for the same frames, showing "before" readings of the original capture (left-hand image), and "after" AVisynth and VirtualDub adjustments (right-hand image). The left-hand histogram of the original video shows elevated blacks and high gamma, with a pink arrow pointing at the way Luma and two of the colors climb up the bright side of the histogram wall (clipping). The "after" histogram shows better darks, more natural midtones, and the clipping tamed and controlled.


The next steps of resizing and encoding require YV12. In VirtualDub, "full processing mode" was selected for output. Color depth was set to YV12, compression was set to Lagarith YV12. The results were saved this way with "Save AVI..." and given the name "Daylight_01.avi".

STEP 2:
You'll notice a more complicated plugin loading in the script, this time around. This is the code I used for the upscaling step:

Code:
# ------------- DITHER 16-bit PLUGINS ------------
dppath="D:\Avisynth 2.5\plugins\AVS26\dither\"
Import(dppath+"Dither.avsi")
Import(dppath+"mt_xxpand_multi.avsi")
LoadPlugin(dppath+"avstp.dll")
LoadPlugin(dppath+"dither.dll")
LoadPlugin(dppath+"masktools2.dll")

AviSource("E:\forum\ozshots\Daylight_01.avi")
Dither_convert_8_to_16 ()
Dither_resize16 (1280, 720, kernel="spline36", cplace="MPEG2")
DitherPost()

ColorMatrix(mode="Rec.601->Rec.709")
dppath="D:\Avisynth 2.5\plugins\AVS26\dither\":
OMG, why is he doing this? First, the dither plugin package uses its own version of some well known Avisynth plugins, as well as some of its own. Some of these plugins have names that are similar to "normal" plugins (like masktools2). You can't keep two plugins with the same name in the same plugin folder. Also, a lot of plugins are seldom used, so why make Avisynth search through a ton of unused plugins to find what it wants? And sometimes you'll devise your own set of special versions for this or that, which could be confusing and chaotic if they're all in the same place.

The default location for Avisynth plugins is in the Avisynth 2.5 or 2.6 program folder in Windows. You can make your own custome-named plugins folder and keep those custom folders wherever you want. I keep them as subfolders in the Avisynth program folder. But you do have to tell Avisynth specifically where those folders are located. Otherwise it looks in "plugins" and, not finding what it wants -- or finding something you didn't want it to find -- AVvsynth just gets stubborn and belches error messages.

Most people have Avisynth in "C:\Program Files\Avisynth 2.5" or "C:\Program Files(x86)\Avisynth 2.5". The Avisynth name might also be 2.6 instead of 2.5, depending on which version of Avisynth you installed and when you installed it. I'm using Avisynth 2.6, which a long time ago was installed earlier in a program folder named "Avisynth 2.5". In fact you can name Avisynth's program folder anything you want during installation, but let's not get so cool that you we can't tell what's going on. My Avisynth stuff is installed on my D: drive as "D:\Avisynth 2.5\" with all of its plugins. Why the D: drive? Did you ever have to re-install Windows? Or what if you should need to do that? Zap, you'd have to replace all your plugins -- if you can find copies of 'em. Avisynth on my D: drive is also backed up on a separate hard drive. The same copy of that folder and its plugins are also installed on the D: drive of another PC.

I have the dither plugins installed in a subfolder at "D:\Avisynth 2.5\plugins\AVS26\dither\". That subfolder is for special Avisynth 2.6 plugins that sometimes conflict with older 2.5 filters. What I can do is specifically point to the plugins I want, which will override the default plugins in the default folder. Avisynth won't even look in the default folder for those specified filters: instead, it will import or load the filters from the location I specify.

The dither package has several plugins. I want to load 5 of them. But I don't want to retype the path statement 5 times. Pain in the neck. Instead, I create a user-defined entity in memory (officially called a "user-defined variable") that I called "dppath". Of course, dppath is short for "dither plugins path" (cute!). I tell Avisynth that the user-created "dppath" contains a string of text characters, and the character string it contains is "D:\Avisynth 2.5\plugins\AVS26\dither\". Note that the closing "\" is also part of that character string. Then I tell Avisynth to join that dppath character string with the name of a plugin using the concatenate symbol ("+").
Thus, the statement
Import(dppath+"Dither.avsi")
becomes interpreted during run time as:
Import("D:\Avisynth 2.5\plugins\AVS26\dither\Dither.avsi")

In Avisynth, .dll's and .avsi's are automatically loaded if they're in the plugins folder. But if you're not using the default folder, you have to explicitly use Import() to load plugins that are text files (.avsi and .avs plugins are text files), and in this case I have to explicitly use LoadPlugin() to load dll's that are not in the default plugins folder.

These statements:

Code:
dppath="D:\Avisynth 2.5\plugins\AVS26\dither\"
Import(dppath+"Dither.avsi")
Import(dppath+"mt_xxpand_multi.avsi")
LoadPlugin(dppath+"avstp.dll")
LoadPlugin(dppath+"dither.dll")
LoadPlugin(dppath+"masktools2.dll")
at run time are interpreted as having been typed in this manner:

Code:
Import("D:\Avisynth 2.5\plugins\AVS26\dither\Dither.avsi")
Import("D:\Avisynth 2.5\plugins\AVS26\dither\mt_xxpand_multi.avsi")
LoadPlugin("D:\Avisynth 2.5\plugins\AVS26\dither\avstp.dll")
LoadPlugin("D:\Avisynth 2.5\plugins\AVS26\dither\dither.dll")
LoadPlugin("D:\Avisynth 2.5\plugins\AVS26\dither\masktools2.dll")
AviSource("E:\forum\ozshots\Daylight_01.avi"):
AviSource tells Avisynth to load and decode the Daylight_01.avi that I saved with VirtualDub in Step 1. That AVI is losslessly compressed Lagarith YV12.

Dither_convert_8_to_16 ()
Dither_resize16(1280, 720, kernel="spline36", cplace="MPEG2")
DitherPost():

The dither plugin documentation is pretty specific about most procedures, so these statements come pretty much right out of the html doc. Dither_convert_8_to_16() converts the incoming file from the conventional 8-bit data to 16-bit data. The Dither_resize16() function resizes that new version to 1280x720 using Spline36 resize and the color matrix for MPEG2 (that is, the colorspace is YV12 for MPEG2). You can use MPEG2 even if you later encode with h.264. DitherPost() returns the clip to 8-bit data -- or else you wouldn't be able to read it -- or AVisynth would likely crash trying to output what would look like 16-bit garbage.

Why use 16-bit? I don't always use it, but I use it a lot for DV source to avoid banding and other 8-bit resize/color effects such as posterizing. You can read all about it here: Color banding and noise removal (post #3) (http://forum.doom9.org/showpost.php?...59&postcount=3)

ColorMatrix(mode="Rec.601->Rec.709"):
ColorMatrix.dll is an Avisynth plugin that properly converts standard definition Rec.601 color matrices to HD Rec.709. You can also do this with the dither plugin, but it takes too long and usually isn't different. The .dll is in my default plugins folder, so it loads automatically with no help on my part.

The output of Avisynth STEP 2 is saved in VirtualDub using "fast recompress" with Lagarith YV12 for encoding.

You can save template scripts as text files so you don't have to retype all this stuff. I've used the same resizing script so many times it's now just a copy-and-rename job.

One big question: how do you save those Virtualdub filter settings or communicate them to others? It's a chore to tell someone in detail how to set up something like values for gradation curves. You can save its settings as a text file, but you'll see a text string for the settings that would be longer than 256 bytes. You can save VirtualDub settings using "File..." -> "Save processing settings" and give the resulting file a location and name. The file type is .vcf. It's really a plain text file with a .vcf file ending. You can even open it in Notepad and read it (but don't change anything. You'll be sorry). You can reload those filters and settings using "File..." -> "Load processing settings...", point to the saved .vcf file, and voila! As long as you or another user has those same VDub plugins in their VDub folder, the filters and settings will load as desired.

I guess that's enough exhaustion for now, so I'll wait to post details later for the "indoor grain" file. It used a similar script but with extra help for cleaning all that CMOS noise, and more color work.


Attached Images
File Type: png Daylight-ColorMill R.png (451.8 KB, 93 downloads)
File Type: png Daylight-VDub Levels R.png (320.7 KB, 91 downloads)
File Type: png Daylight-VDub Curves.png (478.6 KB, 92 downloads)
File Type: png Daylight-ColorTools Before-After.png (24.0 KB, 93 downloads)
Reply With Quote
The following users thank sanlyn for this useful post: Goldwingfahrer (12-02-2015), lordsmurf (12-01-2015), ozshots (12-01-2015)
  #25  
12-01-2015, 12:46 AM
ozshots ozshots is offline
Free Member
 
Join Date: Nov 2015
Posts: 19
Thanked 0 Times in 0 Posts
Hi Sanlyn, I'm totally speachless about such a detailed analysys of my video!
I will try to replicate your steps.

What worried me most:

Quote:
The black level and gamma are too high. Basically the video is too bright, off to the right side of a histogram. The brights are clipped, as explained in an earlier post. Unfortunately I don't know how they got that way (Vegas, perhaps, did an sRGB conversion before saving it as SONY DV? I don't know how the sample was made). "
Read more: Encoding miniDV tapes - XViD or progressive H264?
The sample was shot on Canon DV and captured using Vegas. I thought it just the camera making mistakes in exposure? Do you think Vegas made changes to the files, I thought they are always downloaded exactly as-is, 1 to 1? Should I try to use different program for the same file and see if any difference?
Reply With Quote
  #26  
12-01-2015, 01:36 AM
lordsmurf's Avatar
lordsmurf lordsmurf is offline
Site Staff | Video
 
Join Date: Dec 2002
Posts: 9,962
Thanked 1,693 Times in 1,471 Posts
Hopefully your master file were left intact as natively interlaced. Get the data off the tape, and leave the 13gb/hour files on a reliable hard drive. While people say that drives die -- and they do, but nowhere with the frequency suggested -- DV tape is more fragile than drives.

Yep, DivX/XviD (MPEG-4 Part 2) is 2000s.
Modern is H.264 (MPEG-4 Part 10) in MP4 or MKV wrapper.

good = de-noise
good = convert to progressive, doubling the frame rate (or use QTGMC and just deinterlace)
useless in software = up-scale the resolution (let the HDTV do it)
good = encode with H264

WDTV was always shaky, but it's the best box around. A higher-end Samsung Blu-ray player is another option. I actually prefer the BD for watching MP4. The WDTV Live (not regular) is what I use for DVD ISOs.

I'm not fond of NLEs for basic work like this. They really suck at interlace handling. Avisynth + VirtualDub is what you want for your tasks. Keep the NLE for editing before or after your conversions and clean-up.

x264vfw is a PITA. It's too buggy. Last I knew, it also had a huge delay from the official x264, which was itself buggy (crashes a lot for no reason) and continuously adding features. x264vfw works, but I rarely use it. I prefer Avidemux or MainConcept for the encoding. I'd rather encode out lossless from VuirtualDub, and let the encoder chew on it without worrying about losing VirtualDub or Avisynth work.

MC SDK (Adobe, etc) isn't bad. It's usually the people using it choosing the wrong bitrate or settings. The main complaint is that files are large. So yes, x264 can get small files. But arguably MainConcept looks superior to x264 when quality really matters (ie, studios, not home users). I used MC for work, x264 via Avidemux for play.

AAC needs to be 96mbps minimum, 44.1kHz minimum. That sounds fine, assuming the encoder is good. That's a spec insisted on by my last studio gig. Sometimes, for personal stuff, I use 128kbps AAC, but that's me purposely being overkill.

AC3 is licensed, and they started to crack down on unlicensed decoders in 2013-2014. Don't use it, else it may not play on some devices. AAC is open source. AC3 is fine for DVD, but lousy for streaming.

sanlyn seems to be giving you a crash course in Avisynth. Long post.

- Did my advice help you? Then become a Premium Member and support this site.
- Find television shows, cartoons, DVDs and Blu-ray releases at the TVPast forums.
Reply With Quote
The following users thank lordsmurf for this useful post: ozshots (12-01-2015)
  #27  
12-01-2015, 04:54 AM
ozshots ozshots is offline
Free Member
 
Join Date: Nov 2015
Posts: 19
Thanked 0 Times in 0 Posts
Yes, Iím leaving the original DV files intact Ė they are all on mirror RAID + a backup.
I have finished capturing of 47 tapes Ė big job 
Now I just want to play them conveniently on WDTV. The new model and latest firmware still canít handle DV files, and still displays combing on interlaced files. So Iím upscaling to 50fps.
I also have to resize Ė while I can change aspect ratio every time I play a file, itís just too much clicking.

Iím using batch mode, without de-noise filters for now, and I see scary messages on my test ďdaylight.aviĒ file Ė see encoding.log
Is that dropped frames? Should I try to re-capture using different program?
[getNextFrameAs] Audio thread stopped, no more data
[encode] [x264] Cannot get next image
[encode] Flushing delayed frames

[nextPicture] Cannot get next picture. Last segment
[getNextFrameAs] [Bridge] Base did not get an image
[refillPacketBuffer] Consumed all data from this audio segment
[OpenDmlDemuxer] Index Exceeded 346/346
[getPacket] AudioGetPacket failed, audioSegment=0
[getPacket] ..and this is the last segment
[DecodeNextPicture] getFrame failed for frame 222
[nextPictureInternal] Next picture failed
[DecodeNextPicture] getFrame failed for frame 223
[nextPictureInternal] Next picture failed
[DecodeNextPicture] getFrame failed for frame 224
[nextPictureInternal] Next picture failed
[DecodeNextPicture] getFrame failed for frame 225


Attached Files
File Type: zip encoding_log.zip (8.4 KB, 2 downloads)
Reply With Quote
  #28  
12-01-2015, 08:24 AM
sanlyn sanlyn is offline
Premium Member
 
Join Date: Aug 2009
Location: N. Carolina and NY, USA
Posts: 3,648
Thanked 1,198 Times in 959 Posts
@lordsmurf, thanks for the input. Always new insights.
Quote:
Originally Posted by lordsmurf View Post
useless in software = up-scale the resolution (let the HDTV do it)
I agree 1000% with that one. I made two versions of the Indoor AVI, 576p and 720p. I'm not sure why so many users feel the need to upscale standard def to High Def. Maybe a misunderstanding of some sort. The 576p isn't resized, to illustrate that a playback setup will upscale anyway. Upsizing SD requires a lot of work and careful methods to overcome the problem of interpolation errors. Every NLE I've ever used makes a mess of it. The #2 script shouldn't have been necessary, as a proper 576p will look just like 720p when played but without the extra interpolations needed to upscale in software first. Resizing, whether up or down, always entails some level of loss.

Quote:
Originally Posted by ozshots View Post
So Iím upscaling to 50fps.
I also have to resize Ė while I can change aspect ratio every time I play a file, itís just too much clicking.
Just a slight correction: converting 25fps to 50fps isn't "upscaling". The 576p and the 720p are both 50fps progressive videos. The 720p is upscaled, the 576p isn't.

Whatever you're using for playback should output the proper aspect ratio. The 576p was encoded for a 16:9 display aspect ratio. If you have to click buttons to make anamorphic video play properly, something's amiss. DVD at 16:9 and retail BluRay standard definition (yes, BluRay is often SD, not HD) encoded for 16:9, as well as MP4/MKV, etc., encoded for a 16:9 DAR, should display as 16:9.

I don't know how Vegas captures AVI. I've always seen DV transferred 1:1, not recorded or re-encoded for capture.

Some time back I had Vegas Pro v9 on a PC but after a year I just didn't use it any more. It's possible that the bright clamping on the Daylight video was done in Vegas, either during capture or during copy, but I don't know. When I used Vegas it was a problem with VHS captures, as it didn't convert YUY2 to RGB so well for color work. Since then I've used After Effects for a timeline NLE and its ColorFinesse plugin, but I have to input lossless media from Avisynth because AE didn't convert properly either, and it wasn't up to the task of repairing VHS glitches. AE has many priceless features, but I use it only with lossless input/output.

Below, the same image in post #5 with the YUV histogram of a frame from the original Daylight.avi. I've added a pink arrow to the upper right corner of the histogram. Note that the white graph (luma) has a sharp, straight upward spike at the right-hand edge. The luma values are well within the desired range of RGB 16-235, indicated by the darker shaded areas along the histogram's side borders. The right-hand spike indicates hard clipping of brights. Clipping means that any data above a certain point has been clamped to a single value. If the original bright end clipping point was at RGB 200, then no data beyond RGB 200 exists. It can't be recreated. You can lower the brights if you want, but no data will be retrieved; anything that was originally brighter than RGB 200 was clamped to RGB 200. The lowered brights will simply be darker, but its details won't change or expand to the original details that were brighter than RGB 200. You can see the effects of clipping in the lost detail in clothing highlights and the mild hot spot on the girl's forehead.


If you try to "brighten" those burned-out highlights, they'll just "glow" on the screen but won't reveal any more detail. If hard clipping had not occurred, you would still have a brightness range in the original video that included values at and even above RGB 255. Correcting in YUV with Avisynth, much of that detail could have been retrieved and interpolated into usable values brighter than the clipping point shown here. So you would be able to achieve more dynamic range at the bright end rather than use filtering tricks to make the image look more crisp than it really is.

I'm still working on some detail for the Indoor AVI, which posed some really interesting problems. But I have a PC repair customer this morning that's slowing things down. Will post more later.


Attached Images
File Type: png original - high IRE and clipping.png (636.4 KB, 88 downloads)
Reply With Quote
  #29  
12-01-2015, 10:54 AM
Goldwingfahrer's Avatar
Goldwingfahrer Goldwingfahrer is offline
Remembered
 
Join Date: Aug 2013
Location: Switzerland
Posts: 453
Thanked 75 Times in 70 Posts
Quote:
The sample was shot on Canon DV and captured using Vegas.
The original "daylight" is displayed here in Vegas 13 per way.

Avisynth is here the rescue, Sony Vegas works internally only in RGB


Attached Images
File Type: png 1.png (68.7 KB, 5 downloads)
File Type: png 2.png (93.3 KB, 2 downloads)
File Type: png 3.png (61.5 KB, 2 downloads)
File Type: png 4.png (61.0 KB, 2 downloads)
File Type: png 5.png (83.0 KB, 1 downloads)
File Type: png 6.png (103.6 KB, 4 downloads)
Reply With Quote
  #30  
12-01-2015, 07:18 PM
ozshots ozshots is offline
Free Member
 
Join Date: Nov 2015
Posts: 19
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by sanlyn View Post
Whatever you're using for playback should output the proper aspect ratio. The 576p was encoded for a 16:9 display aspect ratio. If you have to click buttons to make anamorphic video play properly, something's amiss.
Yes, I'm sorry this must be very basic question but I can't get this right!
In Avideumux, I have:
Video output: Mpeg4 AVC (x264)
Configure -> Output 1 -> Predefined Aspect Ratio 64:45 (PAL 16:9)

The output file is still 4:3 - I can post it here...
What is wrong? How do I setup 16:9 aspect ratio?

I prefer not to scale if I don't have to...

This is what's in the script. I can see "vui.sar_height=45", "vui.sar_width=64",

adm.videoCodec("x264", "useAdvancedConfiguration=True", "general.params=AQ=22", "general.threads=0", "general.preset=ultrafast", "general.tuning=film", "general.profile=baseline", "general.fast_decode=False", "general.zero_latency=False"
, "general.fast_first_pass=True", "level=-1", "vui.sar_height=45", "vui.sar_width=64", "MaxRefFrames=3", "MinIdr=25", "MaxIdr=250", "i_scenecut_threshold=40", "intra_refresh=False", "MaxBFrame=3", "i_bframe_adaptive=1"
, "i_bframe_bias=0", "i_bframe_pyramid=2", "b_deblocking_filter=True", "i_deblocking_filter_alphac0=0", "i_deblocking_filter_beta=0", "cabac=True", "interlaced=False", "constrained_intra=False", "tff=True"
, "fake_interlaced=False", "analyze.b_8x8=True", "analyze.b_i4x4=True", "analyze.b_i8x8=True", "analyze.b_p8x8=True", "analyze.b_p16x16=False", "analyze.b_b16x16=False", "analyze.weighted_pred=2", "analyze.weighted_bipred=True"
, "analyze.direct_mv_pred=1", "analyze.chroma_offset=0", "analyze.me_method=1", "analyze.me_range=16", "analyze.mv_range=-1", "analyze.mv_range_thread=-1", "analyze.subpel_refine=7", "analyze.chroma_me=True"
, "analyze.mixed_references=True", "analyze.trellis=1", "analyze.psy_rd=1.000000", "analyze.psy_trellis=0.000000", "analyze.fast_pskip=True", "analyze.dct_decimate=True", "analyze.noise_reduction=0", "analyze.psy=True"
, "analyze.intra_luma=11", "analyze.inter_luma=21", "ratecontrol.rc_method=0", "ratecontrol.qp_constant=0", "ratecontrol.qp_min=10", "ratecontrol.qp_max=51", "ratecontrol.qp_step=4", "ratecontrol.bitrate=0"
, "ratecontrol.rate_tolerance=1.000000", "ratecontrol.vbv_max_bitrate=0", "ratecontrol.vbv_buffer_size=0", "ratecontrol.vbv_buffer_init=0", "ratecontrol.ip_factor=1.400000", "ratecontrol.pb_factor=1.300000"
, "ratecontrol.aq_mode=1", "ratecontrol.aq_strength=1.000000", "ratecontrol.mb_tree=True", "ratecontrol.lookahead=40")
Reply With Quote
  #31  
12-02-2015, 03:50 AM
Goldwingfahrer's Avatar
Goldwingfahrer Goldwingfahrer is offline
Remembered
 
Join Date: Aug 2013
Location: Switzerland
Posts: 453
Thanked 75 Times in 70 Posts
Hello
I sanlyns readjusted steps.
I have the Canopus DV Enc only installed here.
So had to install the Sony Enc.

Step 1 but with Avisynth_MT [MT = Multitasking]...=23-24 fps
everything okay.

Step 2 of sanlyn
I have in line "ColorMatrix ..... put a # at the beginning
---------------------------

Addendum.
Brain turned ... ColorMatrix.dll lacked in Plugins folder.
Now it works


Attached Images
File Type: jpg sanlyn_2.Schritt.jpg (87.6 KB, 5 downloads)

Last edited by Goldwingfahrer; 12-02-2015 at 04:13 AM.
Reply With Quote
  #32  
12-02-2015, 05:04 AM
ozshots ozshots is offline
Free Member
 
Join Date: Nov 2015
Posts: 19
Thanked 0 Times in 0 Posts
Hi All, before I get onto deep waters of restoration, I want to make sure at least I have captured the video correctly. I have downloaded the same "daylight" video using STOIK CAPTURE instead of Vegas. This Stoik unfortunately does not recognize separate shots and capture the whole tape in a single file. So I've captured a bit longer shot.
What surprised me: Vegas captured 8 second file with 29.4 MB
Stoik capture for 12 seconds is whooping 246 MB! This goes beyond my understanding: I thought DV capture is just copying a file from A to B? Both files plays on PC and I can't spot much difference in quality.
If anyone have patience to download the 246mb file, its here: http://www.ozshots.com/daylight_stoik.avi

I should also say it's not Vegas 9, it's actually a separate exe file called "vidcap 6.0". The camera is Canon MVX430E
Thank you so much for helping me!
Reply With Quote
  #33  
12-02-2015, 05:30 AM
Goldwingfahrer's Avatar
Goldwingfahrer Goldwingfahrer is offline
Remembered
 
Join Date: Aug 2013
Location: Switzerland
Posts: 453
Thanked 75 Times in 70 Posts
I can not help you much.
your Sony DV-AVI is compressed.
The Stoik is therefore uncompressed RGB.

I work only once every leap year times with Stoik.
But you can because the settings, select which codec, see picture


Attached Images
File Type: jpg STOIK Capturer_2015-12-02_12-27-13.jpg (95.6 KB, 4 downloads)
File Type: jpg MediaArea.jpg (89.5 KB, 5 downloads)
Reply With Quote
  #34  
12-02-2015, 05:43 AM
ozshots ozshots is offline
Free Member
 
Join Date: Nov 2015
Posts: 19
Thanked 0 Times in 0 Posts
I'm totally confused... I always thought 1hour DV Tape holds about 13GB of data, and that's what Vegas is capturing. Stoik is uncompressing compressed data?
Reply With Quote
  #35  
12-02-2015, 06:08 AM
Goldwingfahrer's Avatar
Goldwingfahrer Goldwingfahrer is offline
Remembered
 
Join Date: Aug 2013
Location: Switzerland
Posts: 453
Thanked 75 Times in 70 Posts
Quote:
I always thought 1hour DV Tape holds about 13GB of data,
Yes, on mini-DV.
On large DV tapes course goes even more.

From DV tapes I read 1: 1 directly into Edius or take the free WinDV a.
I see differences only in the header.

Vegas I only now and then, I have been working with Avisynth / VDub and Edius.

What are you doing in Vegas ... cropping, so adjust movie length or?
-----------------------

In Vegas, it is possible to encode DV-AVI.
See image


Attached Images
File Type: jpg Ohne Titel - Vegas Pro 13.0_2015-12-02_13-12-43.jpg (65.7 KB, 5 downloads)
Reply With Quote
  #36  
12-02-2015, 07:15 AM
lordsmurf's Avatar
lordsmurf lordsmurf is offline
Site Staff | Video
 
Join Date: Dec 2002
Posts: 9,962
Thanked 1,693 Times in 1,471 Posts
Yes, miniDV = 13gb/hour

- Did my advice help you? Then become a Premium Member and support this site.
- Find television shows, cartoons, DVDs and Blu-ray releases at the TVPast forums.
Reply With Quote
  #37  
12-02-2015, 12:40 PM
sanlyn sanlyn is offline
Premium Member
 
Join Date: Aug 2009
Location: N. Carolina and NY, USA
Posts: 3,648
Thanked 1,198 Times in 959 Posts
Quote:
Originally Posted by ozshots View Post
Hi All, before I get onto deep waters of restoration, I want to make sure at least I have captured the video correctly.
A good idea. You've already seen how glitches during capture cause trouble later. I've always thought DV was copied 1:1 via Firewire and something like WinDV, not captured.

After many delays (and 2 more cups of coffee), here's the workflow and details I used for the Indoor grain.avi. This required some tricky denoising and color work. But you'll see that I used the same filters as with the Daylight avi, but with some help from others.

Here is the script:

Code:
Import("D:\Avisynth 2.5\plugins\LimitedSharpenFaster.avs")
# ------------- DITHER ------------
dppath="D:\Avisynth 2.5\plugins\AVS26\dither\"
Import(dppath+"Dither.avs")
Import(dppath+"mt_xxpand_multi.avs")
LoadPlugin(dppath+"avstp.dll")
LoadPlugin(dppath+"dither.dll")
LoadPlugin(dppath+"masktools2.dll")
LoadPlugin(dppath+"mvtools2.dll")

AviSource("E:\forum\ozshots\Indoor grain.avi")
ConvertToYV12(interlaced=true)
AssumeBFF().QTGMC(sharpness=0.7,EZDenoise=2)

source=last
  super = source.MSuper(pel=2, sharp=1)
  backward_vec2 = MAnalyse(super, isb = true, delta = 2, blksize=8, overlap=4, dct=0)
  backward_vec1 = MAnalyse(super, isb = true, delta = 1, blksize=8, overlap=4, dct=0)
  forward_vec1 = MAnalyse(super, isb = false, delta = 1, blksize=8, overlap=4, dct=0)
  forward_vec2 = MAnalyse(super, isb = false, delta = 2, blksize=8, overlap=4, dct=0)
  MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_vec2,thSAD=400)
TemporalSoften(4,4,8,15,2)
GradFun3(thr=0.6,mask=0)
LimitedSharpenFaster(strength=75)
AddGrainC(1.0,1.0)
ConvertToRGB32(matrix="Rec6-1",interlaced=false)
return last
Import("D:\Avisynth 2.5\plugins\LimitedSharpenFaster.avs")
LimitedSharpenFaster is stored as an .avs file in my Avisynth plugins, so it has to be imported as a script. As an .avs filter, it won't load automatically. Why did I save it as .avs instead of auto-loading avsi? Because this plugin has more than one version, but with pretty much the same internal code in each.

dppath="D:\Avisynth 2.5\plugins\AVS26\dither\"
Import(dppath+"Dither.avs")
Import(dppath+"mt_xxpand_multi.avs")
LoadPlugin(dppath+"avstp.dll")
LoadPlugin(dppath+"dither.dll")
LoadPlugin(dppath+"masktools2.dll")
LoadPlugin(dppath+"mvtools2.dll")

The dither plugins will be needed here. As mentioned earlier, there's a lot of grainy junk to be removed, but doing so also removes the grain that defined fine gradations and other small details. Later statements will compensate for that. Again, by using a variable to define the path character string, the above statements are interpreted at run time to read this way:
Quote:
Import("D:\Avisynth 2.5\plugins\AVS26\dither\Dither.avs")
Import("D:\Avisynth 2.5\plugins\AVS26\dither\mt_xxpand_multi.avs")
LoadPlugin("D:\Avisynth 2.5\plugins\AVS26\dither\avstp.dll")
LoadPlugin("D:\Avisynth 2.5\plugins\AVS26\dither\dither.dll")
LoadPlugin("D:\Avisynth 2.5\plugins\AVS26\dither\masktools2.dll")
LoadPlugin("D:\Avisynth 2.5\plugins\AVS26\dither\mvtools2.dll")
If you want, you can hard-code that path letter by letter. But usually manual typing like this involves typos, which are headaches.

AviSource("E:\forum\ozshots\Indoor grain.avi")
ConvertToYV12(interlaced=true)

AviSource() opens the DV file as usual, and ConvertToYV12() converts SONY's version of 4:2:0 to the format most Avisynth filters were designed for.

AssumeBFF().QTGMC(sharpness=0.7,EZDenoise=2)
This statement sets the interlaced field order (BFF) and runs QTGMC for deinterlacing. QTGMC denoisies, too, but it can't handle every kind of noise. Here, we're aiming for ragged edges, interlace combing, and clumpy CMOS grain. Because not all of the grain will be removed with this one step, sharpnbess=0.7 avoids oversharpening. EZDenoise=2 is a special QTGMC value which in this case overrides the default denoising for something more powerful. You can use stronger values, but it would look over filtered.

source=last
super = source.MSuper(pel=2, sharp=1)
backward_vec2 = MAnalyse(super, isb = true, delta = 2, blksize=8, overlap=4, dct=0)
backward_vec1 = MAnalyse(super, isb = true, delta = 1, blksize=8, overlap=4, dct=0)
forward_vec1 = MAnalyse(super, isb = false, delta = 1, blksize=8, overlap=4, dct=0)
forward_vec2 = MAnalyse(super, isb = false, delta = 2, blksize=8, overlap=4, dct=0)
MDegrain2(source,super, backward_vec1,forward_vec1,backward_vec2,forward_v ec2,thSAD=400)

This second denoising routine is pretty much a standby with Avisynth. I didn't make up this code myself. It's copied right out of the mvtools documentation for its MDegrain2 function, word for word. Note something special here: "source=last" tells Avisynth that the "last" result from the lines before entering this routine is to be known as "source". Those previous results will be referred to twice in this routine.

The first time "source" is pointed to is in the second line of the code, which is "super = source.MSuper(pel=2, sharp=1)". This line tells the routine to use the "source" named earlier and do something to it, and then call the result "super". Nice thing here is that you don't really have to know why it's called "super", just use it the way the filter's designer set it up.

Next, the code creates some "forward" and "backward" entities. What the code does is make a digital motion schematic of the two frames preceding the current frame (look 2 frames backward), and make digital motion schematics of the two frames following the current frame (look 2 frames forward).

Finally, the MDegrain2() function is used to compare the noise and motion patterns in the "source" with the noise and motion patterns in "super" and the "forward" and "backward" guys, then decide what's noise and what isn't noise, and clean up the current frame using all that info. Complicated? Yes. Slow? Well, yes. Effective? Yep, and it does it without destroying a lot of wanted detail. Many people do this in two steps. Being in a hurry, I did it all in the same script. The script ran at about 4 frames per second. Good work takes time.

TemporalSoften(4,4,8,15,2)
This is a built-in Avisynth function, used as recommended in the Avisynth doc. What remains after all of the above cleanup is still some flickering, simmering grunge, seen mainly in the walls as the video plays. It smooths that flickering, and also helps smooth hard edges in those delicate transitions you see in the skin shadows and highlights. TemporalSoften is a big favorite.

GradFun3(thr=0.6,mask=0)
GradFun3() is an anti-banding, anti-block function in the dither plugin package that uses dithering to soften hard edges in gradient areas, like skin shadows and walls. Now that I've removed much of the grain that defined smooth transitions, I have to repair that removal with something that makes those edges smooth again. GradFun3 also adds some very fine grain to mask transition edges. The "thr" (i.e, threshold) value determines the filter's strength. The default is 0.3 (I think), but 0.6 seemed work well.

LimitedSharpenFaster(strength=75)
Let's sharpen the results that might have been softened too much. LimitedShartpenFaster (aka "LSF") is another old standby that tries to sharpen without adding edge artifacts such as halos. A little more grain will be added in the next line, so sharpen first before adding any more film-like grain.

AddGrainC(1.0,1.0)
AddGrainC is one of QTGMC's support files used to avoid an over filtered, waxy look. It's also a filter in its own right that you can used by itself. The two "1.0" parameters control the amount of grain (0.1 for luma, and a second 0.1 for chroma). This would be grain so fine that it's hardly visible, even finer than movie film grain. 100% of that CMNOS noise hasn't been removed -- if we cleaned all of it, you wouldn't have muchy video left. So add some fine grain to close the gap between bigger clumps of CMOS noise. Adding too much would of course be noisy, as well as fuzzy.

I know, it seems bizarre to remove a ton of noise and then add some back, but this is controlled and purposeful noise -- not randomly dancing junk.

ConvertToRGB32(matrix="Rec6-1",interlaced=false)
This is for Virtualdub RGB filtering that follows. The video is now 50fps progressive, so "interlaced=false". Note that the script doesn't include any levels or color adjustment. That's OK, since levels here are safe. But the color needs fixing and overall brightness should be expanded upward to make the scene look more natural.

return last
This instruction tells Avisynth to output the results of the last thing the script did. The reason we need to specify that Avisynth should "return the last result" is because the script has named a bunch of other things that are actually different versions that were being processed. Some of things that were named are "source", "super", "backward_vec1", etc. Those entities are still named in memory -- Avisynth has to know exactly which version of the processing we want. What we want retruned is the "last" thing that was done.

Should you decide to use any of this stuff but have trouble getting or loading the pluigins, just ask. The forum and I have zip'd packages for these filters.

You could feed this script directly to VirtualDub and load VDub filters on top of it. But, really, it runs too slow for that to be practical. I elected to save the results of the script as a Lagarith RGB working file, which I can delete later. Then I opened that RGB file in VirtualDub. I'll cover that in the next post.
Reply With Quote
The following users thank sanlyn for this useful post: Goldwingfahrer (12-03-2015)
  #38  
12-02-2015, 12:59 PM
sanlyn sanlyn is offline
Premium Member
 
Join Date: Aug 2009
Location: N. Carolina and NY, USA
Posts: 3,648
Thanked 1,198 Times in 959 Posts
below is an unprocessed frame image from the original indoor avi. The CMOS noise doesn't look so bad here, although the image is rather fuzzy. But during play, the noise "moves" and bristles, and looks worse. There is also some chroma noise that can go unnoticed -- until you start removing the grain, when the chroma stains stand out and flutter.


Below, a 2X blowup of a portion of the walls from the above image. With all the grain it's difficult to see at first, but the chroma noise is magenta and cyan stains in bright and dark areas. Most degrainers have little effect on this kind of noise.


Below, the same area after denoising and color correction. The filter for the chroma stains was VirtualDub's Camcorder Color Denoise (aka "CCD").


Below are YUV (left) and RGB (right) histograms of a typical frame from the original indoors avi. Black levels are OK, but the scene lacks bright values beyond the midtones and looks rather grim and lifeless. The scene is also too yellow, thanks to indoor lighting. We don't want to make this scene look like bright daylight (that would look too artificial). But it would be nice to not have pumpkin colored skin and to have a you-are-there feeling to it.


To spruce up levels and colors, three VDub filters were used: Camcorder Color Denoise and two color filters, gradation curves and ColorMill. The CoilorTools histogram and an external pixel value sampler were used to monitor the results. The settings were saved in a .vcf file.

You don't need images of all the filter settings (they would fill several web pages), but the image below is screen shots of two of the gradation curve settings that were used. These show corrections for Green and Blue, mostly at the bright end. The corrections for brightness and Red are too minor to mention, though they do make a visible difference.

The green correction (left panel) is mostly at the bright end. The Blue correction (right panel) is more extensive, again mostly to extend the brighter part of the image. Note that when correcting RGB, adding or subtracting color also increases or decreases brightness at the same time, because brightness values and color values in RGB are stored in the same pixel. Brightness and color are stored separately in YUV. Also below you'll see the resulting RGB histogram for all of the filtering corrections made. The overall balance is still slightly warm to convey the look of indoor lighting.


By adjusting the diagonal line in this filter, you can correct specific color and brightness ranges without affecting other values. In this case, the diagonal line is adjusted for a smooth transition of brightness and color from the dark end (the bottom of the line) to the brights (the top of the line). Moving any part of the diagonal line to the left is an increase in values. Movement to the left is a decrease. A large or small portion of the line can be changed without affecting other parts of the line. The small "circles" are anchor points to hold parts of the line in place -- otherwise, the line would automatically spread into a "curve", which is why the filter is called a curves filter. There are dozens of free Photoshop and Vegas websites that show how to use gradation curves.

The filtered version was saved out of VirtualDub as Lagarith YV12 for encoding. I imported that YV12 file into TMPGenc Mastering Works for encoding -- and, being obsessive, I added a little more color and levels correction tweaks using some of TMPGenc's YUV filters collection. The filters can also be set to work in RGB and other colorspaces.


Notice in this image that the color of my desktop is RGB32 dark gray, almost black, to avoid distractions when working with video.

The file was encoded with the x264 encoder as 720x576 PAL 50fps progressive, with a 16:9 display aspect ratio.

Hope the capture problems are solved soon. Users more familiar with different DV capture methods and software should be able to clarify matters. The Firewire method is the only one I'm familiar with.


Attached Images
File Type: jpg original test scene A.jpg (108.7 KB, 70 downloads)
File Type: jpg indoors original - 2X detail.jpg (28.9 KB, 69 downloads)
File Type: jpg indoors filtered - 2X detail.jpg (25.3 KB, 69 downloads)
File Type: png original test scene-YUV-RGB .png (25.6 KB, 69 downloads)
File Type: png Curves-Blue and Green Corrections.png (94.3 KB, 68 downloads)
File Type: png Indoors TVMW5 576p.png (301.2 KB, 69 downloads)
Reply With Quote
  #39  
12-02-2015, 03:40 PM
ozshots ozshots is offline
Free Member
 
Join Date: Nov 2015
Posts: 19
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by Goldwingfahrer View Post

From DV tapes I read 1: 1 directly into Edius or take the free WinDV a.
I see differences only in the header.
I will re-capture again using WinDV and post it here.
I was under impression, that Vegas does exactly 1:1 read from the tape.

Looks like there is a bug with aspect ratio in Avidemux 2.6 so I will try 2.5...

http://avidemux.org/smif/index.php?topic=10970.0
Reply With Quote
  #40  
12-02-2015, 05:34 PM
sanlyn sanlyn is offline
Premium Member
 
Join Date: Aug 2009
Location: N. Carolina and NY, USA
Posts: 3,648
Thanked 1,198 Times in 959 Posts
If you have to get a PCI Firewire adapter card, don't get one that has a VIA chipset. I understand that Adaptec IEEE 1394 PCI adapter cards are the proper type.
Reply With Quote
Reply




Tags
minidv xvid

Similar Threads
Thread Thread Starter Forum Replies Last Post
Exporting H264 - Adobe Premiere MP4 vs Quicktime MOV? Winsordawson Encode, Convert for streaming 30 07-25-2014 03:52 AM
MiniDV Tapes not playing - blank blue screen? naripeddi Videography: Cameras, TVs and Players 4 03-05-2013 10:37 PM
JVC SR-VS10 Eats MiniDV Tapes - Help? jbd5010 Capture, Record, Transfer 3 02-10-2011 07:33 AM
Vdub won't recognise Xvid in W7 x64 wobbler44 Encode, Convert for discs 2 08-14-2010 11:13 AM
Converting xvid to dvd dmsinger Encode, Convert for discs 5 04-07-2005 05:45 AM

Thread Tools



 
All times are GMT -5. The time now is 04:11 AM