Norman Black
Forum Replies Created
-
You have enabled the video and/or audio bus track display. Go to the view menu to turn those off if that is what you want.
-
Vegas cannot handle an MP4 container with AC-3 audio. You will have to convert that audio to something Vegas can handle.
In MP4 containers, Vegas can handle
AVC video, AAC audio
mpeg-2 video (XDCAM), PCM audio
AVC video, PCM audio <= probably, but I've not tested. If you can separate the AC-3 audio from the video, you could probably import the video and audio separately into Vegas. -
That ffmpeg command does not work if the source file has a likely stereo audio channel. MXF always has individual mono channels so stereo needs to be split.
Something like this in a command script file will work with stereo audio. You can drag and drop any number of input files onto this script. The output files would have the same name with an _mxf appended and they will be in the same folder. This is just a remux. No transcoding.
@echo off:top
c:\systools\ffmpeg\bin\ffmpeg.exe -i %1 -c:v copy -c:a pcm_s16le -filter_complex channelsplit=channel_layout=stereo[FL][FR] -map 0:v:0 -map [FL] -map [FR] "%~dpn1_mxf.mxf"shift
if NOT %1$==$ goto toppause
-
[John Freeman] “You suggest purchasing an mpeg-2 decoder. It was my understanding the XDcam files were mp4 format.”
MP4 is not a video format. It is a generic file container which can contain any number of video and audio data streams. XDCAM is mpeg-2 video with PCM audio.
Your MediaInfo dump shows what I expected. The MOV file(s) contain XDCAM data. If you want to go through Quicktime to read those files you will need an mpeg-2 decoder for Quicktime as previously stated.
If you remux those MOV files into an XDCAM EX native MP4 file, or even MXF file, then Vegas will read those natively. Avidemux is a GUI program that should be able to do this remux but it cannot batch the process and you have a lot of files. ffmpeg should be able to batch a remux but I would have to work out the command line.
You can try changing the file extension to MP4 and see if Vegas will then handle the file directly. Best to do this from a Windows command line prompt. While MOV and MP4 are nearly identical twins, they do have a unique signature in the header a Vegas may still send the file to Quicktime for decoding.
-
What are the file contents you are trying to edit? You can use the free MediaInfo utility to find this out. You did not say specifically but seem to imply they are ProRes. I don’t think Sony XDCAM browser outputs ProRes MOV files. It will output a MOV file with the XDCAM data. Of course, some other process could have converted the XDCAM MOV files to ProRes.
Assuming the files are still XDCAM data…
Quicktime by default will not decode mpeg-2 without purchasing an mpeg-2 decoder. You can get one of those from Apple I believe.
https://www.apple.com/shop/product/D2189Z/A/quicktime-mpeg-2-playback-component-for-windowsBetter yet, just get to the original camera files not stored in a MOV file. Vegas will handle those fine. Or you can remux the MOV files into an MP4 file and Vegas will handle those directly without using Quicktime.
In general it is best to avoid Quicktime when possible.
-
[Danny Hays] “Are you saying that Sony Vegas Pro can’t render as something YouTube can make look better than that? I believe it can. “
Vegas did not render the the Youtube result. The Vegas result, the original, is good. If Youtube cannot maintain the Vegas quality level then how is improving the Vegas result going to help any.
——–
LukaI have a 50Mbps connection so I downloaded the 1.8GB file, installed the Lagarith codec, and rendered to 20Mbps MC AVC at 60.0p one pass VBR, resampling disabled. As expected the Vegas result looks fine. I rendered the 300p Lagarith to down to 60.0p and of course at 20Mbps the AVC version is not identical to the Lagarith 60p but it is close and quite good.
As expected a Youtube upload loses a bunch of quality compared to the Vegas AVC render. It looses it for all the reasons I have previously mentioned. I’ll not repeat myself. I even saw detail jump in/out which would be expected in a bitrate starved situation. e.g. The stone building on the right starts blurry and then the detail suddenly jumps in when we get closer.
Good luck on your quest for the Holy Grail.
-
Danny,
In the examples you posted of the good game there is very little high frequency (fine) detail so it compresses better. Not only would that compress better, but we are less likely to notice technical losses in quality even in a static pixel peep.
In Lukas example there is tons of high frequency detail. Also this is a first person view so when the game character is running compression suffers more.
I don’t know about the actual footage of this example but very often game footage looks like a squirrel on speed. The dart their view around abruptly. Generally the more camera movement the worse compression is. Movement of characters in front of a relatively still camera is not so much of a problem. The sophisticated codecs have mechanisms to help deal with that, and the best low bitrate encoders using said codecs, like x264, implement those features very well.
[Danny Hays] “There’s got to be a better render setting from Vegas to get better than that, don’t you think?”
If the original from Vegas looks good, nothing you can do. The complaint result is about the one from Youtube. How can giving Youtube something even better than “good” going to help the Youtube result become better. Youtube already cannot maintain quality with what they are being given that is already good.
I saw a setting screen from Luka with a 50Mbps average bitrate. Youtube will always be worse than that since it’s bitrate is way lower. He would probably be better off bailing on 60p. Most are not going to be able to watch that and Youtube only gives maybe 50% more bitrate for twice the frame rate. If someone has a video that does not compress well, then there is less bitrate available per frame than at 30p. Youtube is counting on 60p videos being able to compress better than 30p for similar quality.
-
One thing about Merc V4, is that is stabilizes with much less cropping of the source video than Merc V3. That is an additional advantage.
Vegas has a “Mercalli V2” plug-in built-in. The standard “sony” stabilizer is MercV2. It just has less control over options than the actual MercV2. The Vegas one also has unfortunate/misleading naming of the controls.
https://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=888701
-
[Lukas Hajk] “Well… and how did they do it? That’s the whole point. Is it like random that Youtube compresses someone’s videos better or something? I don’t understand it. Thanks for a reply!”
No it is not random. It is entirely dependent on the source video content. Some things compress better than others. I’ll give the long winded answer.
Consider a talking head interview, where most of the video is stationary and then consider a video with a stabilized camera attached to the front of some vehicle moving down a trail/road. This video has constant movement, which is itself is not purely a problem, but scale of everything is constantly changing because the camera is moving through the scene. The later is a big problem. Sophisticated codecs like AVC have mechanisms to deal with motion on screen, and eliminate redundancies and gain better compression. These things handle stuff like shaky handheld cameras and people moving/walking across screen, moving their head and such. It does not handle changes in scale like a zoom or a camera moving forward.
There are two ways video can be compressed. The encoder can find redundancies like things that don’t move, or things that did move an in a sense copy it from one frame to the next. The other item is exactly like using a lower quality level when you save a jpeg image. In the later the image becomes blocky and blurry.
So when a video encoder is targeting a bitrate, and not a video quality level, then if the encoder cannot find enough redundancies across a sequence of frames in time, then all that is left for it to do is “lower the jpeg quality level”. If an encoder is targeting a quality level, then material that compresses well would result in much smaller files than those that those that do not compress well.
The hard part about Youtube, aka internet, video delivery is that the bitrates are very low so videos have very high compression levels. Those videos where the the encoder cannot find enough redundancies result of poorer, possibly unacceptable visual quality.
One other thing to remember is that images with lots of fine detail never compress very well unless fairly static. Fine detail is the first thing an encoder is going to drop when it is attempting to encode a video stream.
I know all about the internet video delivery problem. GoPro cameras attached to my mountain bike, DO NOT compress very well. Stabilization is necessary to help this out.
-
[Lukas Hajk] “…but since I’ve seen a lot of moviemakers put up a great quality content on youtube, I just don’t get it. “
I answered than in my previous post.