Something's not registering for me there. Can you provide MediaInfo readouts for each?
Here is a media info grab for the first file from each of these folders. Yes the YUV is smaller but I would not consider it extreme.
I do not have the files any more from my first test where I said the RGB was smaller - but it was when I took the 10-bit footage and rendered them out as 8-bit files. I still have my figures from that. The RGB on that test ended up being smaller than the YUV. That might be the only reason for the difference - doing 8-bit instead of 10-bit I am guessing - and not something I would normally do.
Although from the previous version, these results (yellow bar) demonstrate the size differences we're used to seeing. @JN_ also ran some tests. The reason for 4:2:2 and 4:2:0 chroma subsampling is smaller files. I'm looking forward to running new tests soon.
I do appreciate your help, even though I seem like a clueless basket case at times.
Well I am not seeing those sizes. I did a full range render of my 8-bit 30p footage in both YUV and RGB. RGB was averaging 8-10GB/minute and YUV was averaging 4-5GB/Min.
Again I am probably wasting CPU and HDD usage here doing this while I learn, but at least I will have options for a full day of editing soon.
So that goes back to a previous question - since the rendered files do not seem to be affected by changing my project from full to limited range, and I will be mixing cameras going forward that both have full and limited ranges, would I be better off trans-coding my limited rage files directly to full range? Or keep them limited range and just color grade accordingly to "stretch it out"? The full range YUV outputs are only about 4.5% larger compared to the limited for the entire folder.
If you set your project to full range, Vegas will automatically expand your limited footage to full range.
It is not doing that for the files that I have rendered using MagicYUV. Only the source footage. The MagicYUV files seem to stay the exact same range depending on how they were originally rendered.
Not sure why the response above was marked as a solution.
At this point I'm completely confused as to your workflow. What project type did you end up with- 8-bit full or video? 32 bit full or video? What are the Magic files you are working with? 8 or 10 bit? RGB? YUV? Vegas behaves differently in different modes.
Not sure why the response above was marked as a solution.
At this point I'm completely confused as to your workflow. What project type did you end up with- 8-bit full or video? 32 bit full or video? What are the Magic files you are working with? 8 or 10 bit? RGB? YUV? Vegas behaves differently in different modes.
I am not sure why a solution was tagged either... I am confused by my workflow too... Going forward I will be using a7s II and similar (8-bit video levels listed as YUV in mediainfo) and a7s III (10-bit Full Range listed as YUV in mediainfo). They will be mixed in the timeline. I have rendered almost every file to both RGB and YUV to try and figure out what is the best.
Mainly starting with the 8-bit transcodesfrom MagicYUV - If I render them as video levels, they "stay" at the same less contrasty levels both visually and in the scopes regardless if I switch my project to full or video levels (source footage does change visually and in scopes when I switch it up). If I render them as full levels, they "Stay" at the same more contrasty levels both visually and in the scopes no matter how I set my project up.
So - if that is the case am I best off converting my 8-bit limited files during the transcode to full if they will be in the full range project anyway?
My final Highest Quality output for a project before exporting anywhere will likely and should be 10-bit full levels. From my understanding that would be easiest to change levels back to video levels for a render if absolutely needed for a reason?
A rule of thumb is to honor the lowest common denominator with mixed project footage. In your case, both project and render at 8 bit video levels, 4 :2:0.
A rule of thumb is to honor the lowest common denominator with mixed project footage. In your case, both project and render at 8 bit video levels, 4 :2:0.
I completely understand where you are coming from and respect that statement.
For more detail, 90%+ of the footage will come from the 10-bit full range cameras. Only in cases where I need more than 2 cameras, like a wedding ceremony, will the 8-bit footage be used, and in spare amounts.
What are the issues I would run into if I opted to change the limited to full range in transcoding?
If you are shooting 10-bit files for a reason (like you are in S-log 3) then you need to at a minimum get yourself back from log to a regular viewing gamma before converting the files to 8-bit. If you don't especially need 10-bit, I suppose you could just shoot an 8-bit Cine format and skip transcoding entirely, though that isn't making full use of the sIII.
To do the color corrections to 10-bit log files, you need to be in a 32-bit mode in Vegas from my understanding. You can take the source 10-bit footage and output 10-bit MagixYUV footage, but still need to do color correction in 32-bit pixel format mode. Full or limited range doesn't really matter, I think, as long as Vegas is interpreting it correctly. Then you can output a final corrected file in 8-bit 4:2:0.
Feel free to correct me if I'm missing something with how VP works.
I completely understand where you are coming from and respect that statement.
For more detail, 90%+ of the footage will come from the 10-bit full range cameras. Only in cases where I need more than 2 cameras, like a wedding ceremony, will the 8-bit footage be used, and in spare amounts.
What are the issues I would run into if I opted to change the limited to full range in transcoding?
Wouldn't you need to focus on why, how, and what you are delivering in order to answer those questions? Immersing yourself in only the process throws you into an eternal thinking loop unless you fundamentally address and work toward your goal, the outcome, the result.
Just adding to @Musicvid 's comment re delivery - is delivery going to be in BD, DVD, YT etc? If in the latter two, surely bit rate isn't going to matter all that much. Regardless, think in terms of what your clients are expecting. While you may have technical reservations about some footage in relation to other footage in the project, are your clients really going to perceive that slight difference? Is it that your wedding clients are going to look at the video in years to come and instead of 'cooing' about the happiness of the day, they look at it and criticise it because some shots are 8-bits rather than 10 or 32-bits? Even these days, people still look at their Beta/VHS wedding videos with great affection.
It's emotion, not just a technological exercise - but of course it should still look good within the basic standards of the day.
EDIT: Description within the video linked below is wrong. Second clip is from grading YUV Limited transcoded clips, not full.
This was my observation this morning.
Original Source - 8-bit YUV Video Levels (a7S II)
The first clip was from MagicYUV rendered at Full levels and then put back into VP18 and color graded. The second clip (same) was MagicYUV rendered at video levels and then put back into VP18 and color graded the exact same as the first (copied properties) and then added an adjustment levels layer to match. Renders matched my project properties for each of these.
The MagicYUV footage that I originally transcoded to full levels, even though the source showed as limited in media info, is definitely cleaner. The MagicYUV footage that I originally transcoded to video levels (same as source) got pretty ugly once I graded it like the first clip.
Look at the shadows on the walls. The shadows behind her are the worst. The banding is much more rigid, noisy and the colors are wicked. The shadows in front of her also have much sharper banding when using the YUV video level footage to edit from.
I tried these renders as both full and limited, as well as changed the project properties to both full and limited, and all results were equally as ugly (changing the basic adjustment levels to have the clips match each other). I also graded a RGB full level version which gave me similar results as the YUV full level.
Yes I do care what my footage looks like. I am looking for easy/smooth to edit full quality master files that are as precise as possible. I hate looking at the ugly proxies - I have found myself over and over again accidentally skipping over something that truly looks wonderful from the source because I thought it was out of focus when in fact the shot was 100% usable.
Yes my final outputs will likely be watched 90%+ Web based so the outputs will be limited and 8-bit, but I also do provide the highest quality outputs for my clients as well for viewing at home on a PC or TV.
I do more than just weddings. Commercial work this will be even more important.
Of course - Youtube's compression slightly diminished the differences you see from when I play the file straight from my computer but you can still see them - SO - I have added screenshots as well for comparison.
Cine profile on the 8-bit and it shows as video levels in meida info. I found out quick my XAVC-S files do not edit well and it has been a nightmare. Especially since VP18. Usually when I am culling clips my VP crashes literally every 5-10 minutes. I had to set my auto saves to every 30 seconds. I can look back at my last 12 weddings and each one has 30-40 auto save recovers each. That brings my patience down and anxiety up.
TODAY I was able to go through that entire wedding in 3 hours (Usually takes me a few days because of the frustration of crashes. There is INSTANT response no matter how fast or where I click on the timeline and the footage plays at full speed, no hiccups.
ABSOLUTELY ZERO VP18 CRASHES!
When I copy clips from one project window to another project window - BAM! - it was instant. Sometimes this would cause my PC to hang for 20-30 seconds while changing windows back and forth before these transcoded files.
With my PC build you think everything should have been smooth to begin with, but it just wasn't and I didn't realize how bad or out of the normal it was until today when I was putting these files to use.
I remember a thread near launch of VP 18 talking about how VP18 hangs if you split clips while playing. I had that issue bad. I have had that problem for years. I had NONE of that today. I even tried for a bit going split crazy while playing and jumping around the timeline and I could not get it to crash. I have not visited that thread in a while to see if they have any official fix or work around for it, but I would bet the video file source might have something to do with it.
TODAY I was able to go through that entire wedding in 3 hours (Usually takes me a few days because of the frustration of crashes. There is INSTANT response no matter how fast or where I click on the timeline and the footage plays at full speed, no hiccups.
@hambonio - Sooo....? What’s been YOUR solution? I have lost the thread/plot of your process. Would you please simplifying for me, just what it was you did?
EDIT: FWIW that process yesterday eliminated 7 bugs that did not appear while editing that I have has listed on my notepad for discussions here when I had the time. So if just using these MagicYUV files correctly fixed those (or appears to so far) that saves that many more separate posts from me in the forums :P This is also why I am being particular to get my workflow going.
- Sooo....? What’s been YOUR solution? I have lost the thread/plot of your process. Would you please simplifying for me, just what it was you did?
The wedding I culled yesterday in 3 hours was all 8-bit footage that was transcoded to full RGB from being listed as limited in media info. I have figured out for this is the best route for me and gave me phenomenal results that was better than any other method I tried. So I will stick with that - whether it is technically correct or not - some reason I am doing it wrong but this way works.
Now this morning starting to work with the wedding with 10-bit files.... Yes off the bat I am confused again.
I am doing trying to do my own investigating here before I release my fugue - and try not to make it a full symphony.
AHA! I missed this post, sorry but it might explain it better for me.
Just to elaborate a bit on the ranges for MagicYUV:
All 8-bit codec variants (both RGB and YUV) expect full range data, as they communicate RGB with Vegas underneath, and RGB is always expected to be full range. 8-bit YUV codec variants do RGB<->YUV conversion internally inside the codec, and the resulting encoded YUV data will have limited range, but as far as Vegas is concerned, it will only ever get full range RGB from the codec.
10-bit+ RGB codec variants expect full range RGB.
10-bit YUV codec variants expect limited range. Note this is different compared to 8-bit, the reason being that the codec communicates YUV data with Vegas (not RGB) in this case.
When a project is set to 32-bit full range mode, Vegas will do automatic full->limited conversion before sending the YUV data to the 10-bit YUV codec variants.
When a project is set to 32-bit video levels mode, Vegas should not do automatic full->limited conversion before sending the YUV data to the 10-bit YUV codec variants, however there is a bug in Vegas (confirmed by MAGIX), and currently it's still doing full->limited conversion even in 32-bit video levels mode. This will be fixed in a future release of Vegas
From my understanding - I was correct to render the 8-BIT RGB as full. The 8 bit versions I rendered as limited were much noisier with more banding as stated above once stretched to the levels I wanted. I am guessing if you use the limited option you are losing some data.
@hambonio Hi, you seem to me someone who values having the best possible quality possible. I'm surprised that you didn't try the built in Magix Intermediate 422 HQ, it doesn't claim to be lossless, but it's really very high quality. You can see some RQM, render quality comparisons via the "Tables" link in my profile.
I had a long discussion with MagicYUV re: the new plugin, so if you don't care about losing the will to live, have a look.
With the recent release of b373 I checked it out again, but nothing has improved i.e. the best render quality results that I have found is by not using the new plugin. Instead use MagicYUV from within VFW, Video For Windows, it's slower, but once you check the box in the "Config." item to Full Range then you get the very best quality output result. This check box is not available as an option in the Plugin, previously explained as to why by MagicYUV.
With b373 I again tried many different combinations, 16 output files, 8 bit 420, from a test file that has various levels within it, not fixed as yours might be at say FULL or Limited.
I varied the timelines medias range, FULL/LIMITED, the VP Properties pixel format Legacy/FULL, the output render Project properties FULL/LIMITED, the VFW Config FR Checked/not checked, so 4 variables plus of course either Plugin or VFW.
You should try the VFW option with a sample of your media, see if it can help.
@hambonio Hi, you seem to me someone who values having the best possible quality possible. I'm surprised that you didn't try the built in Magix Intermediate 422 HQ, it doesn't claim to be lossless, but it's really very high quality. You can see some RQM, render quality comparisons via the "Tables" link in my profile.
I just tried a few variations of Magix 422 HQ settings exporting both limited and full. It is just not as snappy when playing and splitting and bouncing around the timeline. I also had a couple crashes which I did not have yesterday - but I will chalk that up to still having the source XAVCS 10-bit footage also on the timeline for clip comparisons.
EDIT: After the latest crash I cannot even open the restored project anymore without crashing on loading,