Aaron Star
Forum Replies Created
-
YouTube does accept xdcam-ex.mxf, XAVC.mxf, but not HDCAM.mxf ironically. HDCAM is older form of MPEG4 intra and was the go to format before Prores, but they support dnxhd and prores. Go figure.
-
The FFMPEG command I gave:
ffmpeg -i Filename.flv -vcodec copy -acodec copy OutputFilename.mp4
will not recompress the media like handbrake will, it just changes the container from .FLV to .MP4(vegas compatible) The audio and video are untouched and remain in the same form.
I recommend you check out https://www.ffsplit.com/download/ / XSplit (commercial version), it has the almost the same interface and it writes constant frame rate files. OBS’s lack of writing a video standard file is really odd. This is what happens when a computer guy builds a video application, instead of a video person. There are video standards for a reason.
You may want to think about running another instance of the encoder. One for local recording, and the other for the stream/feed. This would allow you to edit the recordings at a higher bitrate. YouTube for example encodes at 7.5Mbs for 720-60p, 12Mbs for 1080-60p. That means you should be editing and uploading 15-20Mbs+ files for good results.
https://support.google.com/youtube/answer/1722171?hl=en
https://help.twitch.tv/customer/portal/articles/1253460-broadcast-requirements
I don’t know just some thoughts.
-
You might also try the render to .MFX>XDCAM-ex-720-60p profile. This can be a lot quicker than AVC.
In the Sony AVC profile you are using keep the “Encode Mode” to auto.
The ATI 5850 is almost neck and neck with the Nv960. The ATI will have better OpenCL support, and has more OpenCL compute units than the NV card. The PCIe interface is slower on the 5850, but more compute units is better than the lesser NV960. For Vegas the ATI card would be a better choice.
NV960 – 2300 GFLOPS but lessor OpenCL support by NV driver.
ATI 5850 – 2000 GFLOPS but great OpenCL support by AMD driver. This card also has more memory bandwidth than the 960.
There could be other reasons for keeping the NV card, like other programs that take advantage of the card.
-
You can use George’s method in Movie Studio and not delete the clips on top, but rather right click and Mute the video clips not seen. This allows for easier changes to edits, or changing angles. I have done 4 camera angles using this technique.
Multi-cam in VP is really nice, but it can bite you in the ass if you are not careful. You can spend a lot of time recovering from an error, where as the mute top tracks method keeps things aligned better, and easier to make changes to clip effects. Converting your source material to an intra-frame codec like HDCAM,XAVC-I, or Cineform can help with multi angle playback. For AVC, converting an Intra-frame codec or even XDCAM-EX will allow for more angles with higher frame rates.
-
You can record to .mp4 in OBS by changing the .FLV under broadcast settings to .mp4. This will keep you from having to convert the .FLV, and allow you to drag and drop to the Vegas timeline.
You also could change to .MP4 without handbrake with an FFMPEG command:
D:\Videos>ffmpeg -i Filename.flv -vcodec copy -acodec copy OutputFilename.mp4
This way there is no re-encode with handbrake, and you save a visual generation.
In my testing with OBS and Vegas on my i7-870/HD5770, I was able to record 1080-60p by unchecking the CBR and upping the bitrate to 16000-22000.
Disabling resample in the timeline clips helped speed up encoding to SonyAVC-60p-16Mbs, and rendering to XDCAM-ex both 720-60p and 1080-30p were the fastest renders. YouTube supports converting XDCAM.mxf files.
OBS has Quicksync and NVENC support, have you tried these settings with your NV card and Gen4 i7? If these work, it would save a lot of system overhead on the screen capture.
FFSPLIT is another version of this application that seems to work better with lower overhead, but no Quicksync or NVENC support.
-
I agree with John for most of the points mentioned.
If YouTube is you workflow goal, there are other elements to consider as well. Here is how a video file moves through Vegas:
Source Codec -> Decompress and convert to RGB -> Vegas Engine (Timeline playback & Effects/titles) -> Encoder + Audio Encoder (HEVC,MPEG4,MPEG2,AAC,WAV,…)-> Write file to container(.AVI,.MP4,.MFX)
GPU assist (openCL) works at multiple points in the process:
- Source Codec decode/decompress and conversion to RGB
- Vegas Timeline engine
- Encoding to new compressed format, even if that is the same codec
ENCODERS:
Main Concept’s encoder works on older cards with CUDA (<=580 series), it also works with OpenCL AMD cards (not sure where it stops, and not sure why it would stop with OpenCL support.) The MC encoder attempts to run more of the encoder on the GPU than say the Sony AVC encoder. With fast supported GPUs, this was almost an offloading of the processes the Vegas engine had to do. Remember these are slower system days of Vegas. There have been tests done that show the MC GPU encodes actually add artifacts to the image, vs encoding CPU only.Sony’s AVC is a bandwidth constrained encoder and not really a true CBR encoder. You can use “Bitrate Viewer” and “Media Info” to see this. XDCAM422-50 is an example of a CBR codec, this means anything encoded will write 50mbs stream if the scene motion requires it or not. Sony AVC uses the OpenCL combo (CPU OpenCL Compute Devices + GPU OpenCL Compute devices) and performs math that would return faster results than on the CPU alone. CPUs perform floating point math slower than the OpenCL combo. CPUs are rated in MFLOPS, where as GPUs are rated in TFLOPS, combining the CPU+GPU performance in the OpenCL device. So the Sony AVC encoder will use your OpenCL abilities on your system, but it may be that your CPU is so slow at keeping up you are not seeing much utilization. If you system is busy on some other aspect of the workflow, then the encoder will have to wait on frames to encode. System optimization to best support the entire workflow in Vegas will offer the fastest .MP4 encodes.
TIMELINE:
Optimizing your system to best support the Vegas Engine will get frame data to the encoder the fastest. This means optimizing Memory Size, Memory bandwidth (freq + timing), CPU bandwidth (i7 vs i5, # of memory channels supported), GPU performance (GFLOP performance, VRAM bandwidth, PCIe interface speed), Disk drive latency vs throughput (most drives are fast enough to deliver Prores,DNxHD,AVC compressed codec speeds.) CPU core count matters due not only to computational speed, but also the way Vegas and windows multitask the overall workflow.SOURCE CODEC:
Source codec can make a big difference in final encode speed. An intra frame codec may take more space, but LGOP codecs like AVCHD take more CPU computation to reassemble frames to be converted to RBG. Intra frame codecs have less system overhead that can be put towards other areas of the workflow. Sony codecs like XAVC-intra, HDCAM, XDCAM are better optimized source formats inside Vegas than .MOV(dnxhd,prores) formats, and in some ways even better than uncompressed/cineform.AVI. Remember Sony made Vegas to work Sony codecs the best coming from their cameras and VTRs. Support for other codecs should be looked at as in roads, and ways to export for delivery compatibility. Timeline footage in Sony.MXF codec will be the most edit optimized and stable as far as GPU support and effects.OVERALL DATA QUANITY:
YouTube re-encodes all uploaded material to these standards – https://support.google.com/youtube/answer/1722171?hl=enThere is little reason to work uncompressed source material to be compressed to 8Mbs h.264. Some say upload h.264 files should be 10mbs-h.264, others say 2X the youtube bitrate, while I take a different approach.
Upload speed on your internet connection matters. My upload is fast, so I can upload large files in the same time someone else with restricted upload can upload an 8Mbs file. So I look at my workflow and find that rendering to XDCAM-EX(35mbs-VBR).mxf gets me both optimal quality and rendering speed due to optimizations in Vegas. YouTube supports converting XDCAM to the various MPEG-DASH frame sizes, and bit rates, and has no effective upload limit. Sure I am uploading more data, but who cares, set the upload and task switch.
60P:
60P is effectively doubling the amount of frame information to be processed. This means a slow machine will double the amount of time to encode a length of footage, vs a 30P file. Does your content really need 60P, if your system sucks and is slow? Are your viewers watching your frame rate, or the content of the material? Speed up your renders by dumping half the frames to be processed. -
Do all you project settings match? Are you working in 8-bit pixel format or 32-bit?
I notice on my machine that GPU assist helps greatly with PNGs and keyframing. Nested projects with animations do have a noticeable drop in frame rate vs running the animations in the root Veg file.
Make sure to open the nested project 1st, because all vegas instances after the 1st are CPU only. Only the 1st instance of Vegas will use the GPU assist.
-
Looks like one of the Nikon Trinity lens:
With an appropriate adapter.
-
Using MP4BOX for Dash setup.
-
I have an old version of Photoshop, and my permissions are the same for Vegas and Photoshop.
Have not tried to give User group full permission to both. I cant imagine this would make a difference, since the logged in user is a member a a group with higher privileges. The location I save VEG files to is clearly using the high privilege group since users have no write ability to save the VEG to the location.