Norman Black
Forum Replies Created
-
There is a free utility program called MediaInfo. Can you show us a report from MediaInfo on your MP4 file. Or post a very short phone clip to Dropbox or similar.
MP4 files are generic containers and can contain just about anything.
Your DSLR MP4s are most likely AVC/H.264 video and PCM/AAC audio.
Sometimes MP4 files are actually Quicktime MOV files, just with an MP4 extension. Visa versa as well.The phone files is most likely AVC video and the audio is the question.
MediaInfo will tell all.
-
If your tags that disappeared were on subclips, then this is a bug in Vegas. Tagging seems to work fine on other media, AFAIK, and seen.
-
When you start with Shift+Ctrl, also make sure to check the option for deleting saved data. I don’t know what Vegas cleans up but it cannot hurt.
What you can do is go to the Vegas Pro “AppData” folder and delete all the compiled OpenCL files. They are named, “OCL*.bin”. Vegas compiles their OpenCL code on the fly as needed, and on a driver change they will recompile but something may be messed up in the whole GPU world thing so deleting any Vegas saved GPU related items can help. Heck deleting everything in the AppData folder is just like a clean install.
-
[Sorin Nicu] “And even if that was the case, why is not Sony requesting DivX to update the MainConcept encoders? Don’t want to pay, that’s why.
“You have proof they have not asked Mainconcept to update support?
“Don’t want to pay”. You have proof of that?
Mainconcept has changed hands a couple of times in the last handful of years. Not much going on there at all.[Sorin Nicu] “As for “gpu doesn’t match the cpu quality” – that’s just something that people say because they assume it has to be true.”
This has been documented time and again.
https://compression.ru/video/codec_comparison/h264_2012/
A 30 minute video of the primary x264 developer about the problems of GPU encoding. The short story. Video encoding is not a very parallel task and forcing GPU use to get parallelism forces compromises.
https://www.youtube.com/watch?v=uOOOTqqI18A
[Sorin Nicu] “Same software algorithms can be run of CPU or on CUDA/OpenCL cores, so the result should be identical.”
Not really. Watch the video of the x264 developer. The real point is that GPU encoders are designed for speed and they make compromises in their algorithms to get that parallelism and thus speed on GPU.
Even within the same company like Mainconcept, the CPU encoder has better quality than either the OpenCL or CUDA encoders.
Of course it has to be said time and again. At high bitrates most all encoder look the same even though the SSIM and/or PSNR will be different. As one lowers the bitrate the best encoders start to shine.
Many think that GPUs are somehow faster because of all the GPU support things being done and the speed that can be gained. GPUs are *MUCH* slower than CPUs. What a GPU has is massive parallelism, and if and only if, an algorithm can map to the parallelism in an advantageous manner does one get the speed.
Image editing tasks like effects in Vegas are an obvious item that is typically very parallel.
-
[Sorin Nicu] “So why Sony didn’t developed their own encoders to use GPU either? Is lack of interest in investing money, just in taking them.
nVidia and Intel have free SDK’s and libraries to build encoders using their hardware. Other companies use those successfully, even the free apps make use of them – maybe they should just hire the guy from Handbrake for example.
“It is uncommon for NLE developers to develop their own encoders. They buy from people like Mainconcept. Even Adobe does this. SCS has developed the Sony AVC encoder.
SCS/Sony has used the Intel QuickSync hardware AVC encoder SDK. The Sony AVC encoder supports this. Maybe SCS will support the Nvidia and/or AMD hardware AVC encoders. I have actually entered a feature request to SCS in this regard. For me this is mostly for temp/text encodes. ALL the hardware encoders, and even the Mainconcept CPU and Sony AVC encoders pale in comparison to x264 in visual quality.
Which brings me to Handbrake. Handbrake, like SCS, supports Quicksync but not Nvidia/AMD. Nobody at Handbrake has ever developed an encoder. They just use open source encoders that are available, which includes x264 for AVC/H.264 encoding. SCS cannot include x264 in Vegas.
I am not an expert in legal issues with GPL, but I believe SCS could write an encoder plug-in for x264 and make that source code available and let us download that. Vegas could remain proprietary. I have even suggested this to SCS.
-
I don’t know anything free, but Vegasaur has some lower third templates at a reasonable price. They are Vegas project files. $20 for a package that has some news type templates. Beyond what the package has, they can be altered/customized and they will show you how to do some sophisticated things using the existing tools available in Vegas.
https://vegasaur.com/lower-thirds
-
[Sorin Nicu] “Sadly, your brand-new video card is useless in Vegas. Thanks to Sony lack of interest in updating a critical piece of software from December 2010 until now. Basically if your GPU is newer than that date, the MainConcept encoder will not use CUDA.”
It is not Sony lack of interest here. To this day, Mainconcept has never updated their AVC GPU encoders to support newer architectures.
Mainconcept hard coded their encoders to specific architectures in both CUDA and OpenCL. They never wrote generic GPU code that would work on anything old and new. It is okay to have optimized versions for specific architectures, but one must always have a generic version that will always work on anything meeting a minimum spec.
-
With the information given…Preview fine…render as pixelated.
It sounds like your render bitrate it too low. The preview window is uncompressed, before being set to an encoder (render as), so any encoding artifacts will never been seen in the preview window.
-
I have Kaspersky. I don’t think it gets in the way, and then the only thing it would cause is a slight delay on a file open. This might manifest itself is a transition. This is the FileIO protection feature. They may check the file when a program opens it, and then video files cannot contain code so no real checking really goes one.
Anyway if you trust Vegas is not a “bad” application, and I think that is safe assumption, then you can add it to the trusted applications list with exclusions for certain tasks. For example, scan files before opening, but leave other protections active.
On another method, you can provide exclusions to the folders where your video files are and provide File IO scanning exclusions on those folder(s).
These are just two different mechanisms you can use separately or in combination to have AV protection enabled but exclude certain things from any/certain possible AV overhead.
-
[Lukas Muller] “I see. The question is, why do my colors change when I encode in x264?”
Many factors. As JR said, the color space interpretation can differ. Your device is a still camera first and video device second.
Also your camera records full range, 0..255 (technically 1..254) and not video levels. The levels conversion in Vegas compresses that range into 16-235. Then a video player on a computer device expands that back to 0..255. This is not a perfect conversion. Some data/levels are lost. Also the conversion to video levels and the inverse operation in the playback device software may not be perfect inversions of each other. I am not sure about MS12 but Vegas uses .060 and .920 in the Computer to Studio levels conversion.
Small levels differences, which directly affect contrast, can show as saturation/color differences.