Norman Black
Forum Replies Created
-
I concur with JR, you will likely be disappointed with HD over VGA to the TV. Ideal with DVI or HDMI.
Also, with a Canon DSLR be sure to make sure your levels are good. Canon DSLRs typically output full range and your encodes are probably going to want to be studio range (16-235).
-
Norman Black
January 28, 2014 at 3:16 am in reply to: First crash with SVP12.700 shows that preview does use OpenCL on nVidia[Stephen Crye] “but it is interesting that the fault module was nvopencl.dll , I’m guessing that is the vegas dll that interacts with nVidia’s OpenCL api.”
That is an Nvidia driver file implementing the OpenCL interface, or at least part of the OpenCL implementation. There might be more than one Nvidia DLL doing OpenCL work.
When you get GPU crashes or hangs you normally see the fault module as the OCL driver DLL. In my case it is AMD (amdocl64.dll).
Now the question is did the driver just crash by itself, or did Vegas pass some garbage data/parameters/setup/? to the driver and cause the driver to crash. That is the big/huge/massive question.
-
The difference between Good and Best is the image resize algorithm used. A slower better algorithm being used for Best.
Resize comes into play if you have crops or resize with track motion.
Also if your source material is not the same size as your project and/or render size.Also, note that a render as template can override the project render quality.
-
If you are talking about adding from the trimmer window, that shortcut is the Tab key. Pressing Tab cycles through both/video/audio.
-
The 444 setting is overkill given the source cameras you list. They all generate 4:2:0. If you are using an external recorder connected to the 5Dmkiii via hdmi you can get 4:2:2.
The normal (for lack of a better word) DNxHD settings should be sufficient to preserve the original camera quality. Normal DNxHD is 4:2:2.
Nothing “wrong” with 4:4:4. Just probably overkill.
-
Norman Black
January 23, 2014 at 11:30 pm in reply to: Is this lack of difference in CPU vs GPU-enabled render speed a case of the dreaded Kepler chip thing?[Stephen Crye] “Hmmm. But on my Quadro 2000 system, using MainConcept AVS with CUDA selected, it renders almost twice as fast as with CPU-only”
Quadro 2000 is Fermi and dates back to late 2010. If MC did silly things with the CUDA AVC encoder like they did with the AMD OpenCL encoder, then that card is likely fully supported and tweaked.
I don’t have multiple generations of Nvidia cards like I do with AMD. I need hardware in hand to do tests.
There is nothing wrong with having custom tuned and tweaked versions of the code. You just need to have the generic one around when the available hardware does not match any of the custom tuned versions.
-
I use the YTD Video Downloader and used “best available” for the file download quality. Looking at that video, 480 (640×480) is the largest version available. Your download was 480×360 which is one size smaller.
-
Norman Black
January 23, 2014 at 8:06 pm in reply to: Is this lack of difference in CPU vs GPU-enabled render speed a case of the dreaded Kepler chip thing?[Dave Haynie] “That was supposed to say “Main Concept”, not nVidia.”
Let me try wording that differently.
Mainconcept did that with the OpenCL AVC encoder which only works with AMD. Odds are that they, Mainconcept, did it with CUDA AVC encoder as well.” -
I downloaded the file. It is 236MB, not 140MB. I downloaded the 480 sized version. Maybe you had a smaller version like 360.
Here is the Mediainfo data
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 236 MiB
Duration : 48mn 8s
Overall bit rate : 686 Kbps
Writing application : Lavf54.63.104Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Main@L3.0
Format settings, CABAC : Yes
Format settings, ReFrames : 3 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 48mn 8s
Bit rate : 555 Kbps
Width : 640 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 25.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.072
Stream size : 191 MiB (81%)Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 48mn 8s
Bit rate mode : Constant
Bit rate : 126 Kbps
Channel count : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 43.2 MiB (18%)This is very compressed but that is not the point.
You want to convert to mpeg-2. When converting to something else you want to keep the same visual quality without an excessively large file. This all comes down to video bitrate. Bitrate determines the file size, NOT the type of video codec like AVC or mpeg-2. Now it gets more technical. Some codecs are more efficient at compressing than others. MPEG-4 AVC/H.264 is better at compression than MPEG-2. How much? That is a debate in itself but the dogma is around 2x better for AVC over mpeg-2.
What does that mean to you. This video is 555Kb/s bitrate AVC so maybe try 1Mb/s mpeg-2 for this example. This assumes you are keeping the video size the same. In this example 640×480.
The final judge is always your eyes and only trial and error and experience will let you know how low a bitrate you can use to get the video quality you desire.
-
Norman Black
January 23, 2014 at 5:22 pm in reply to: Is this lack of difference in CPU vs GPU-enabled render speed a case of the dreaded Kepler chip thing?[Dave Haynie] ” It could be that nVidia does the same brain-damaged things in CUDA that it does in OpenGL, only supporting cards it specifically knows about.”
MC did that with the OpenCL AVC encoder for AMD. Odds are they did it with Nvidia CUDA as well.
Looking at the mc_enc_avc_cuda.dll file one see a 2010 Copyright from Mainconcept. The mc_enc_avc_ocl.dll file has a 2011 copyright. This does not mean anything. MC could have missed updating a copyright string somewhere.