Code:General Complete name : E:\video.avi Format : AVI Format/Info : Audio Video Interleave Format profile : OpenDML File size : 1.55 GiB Duration : 10s 10ms Overall bit rate : 1 327 Mbps TCOD : 35999964000 Video ID : 0 Format : YUV Codec ID : v210 Codec ID/Hint : AJA Video Systems Xena Duration : 10s 10ms Bit rate : 1 326 Mbps Width : 1 920 pixels Height : 1 080 pixels Display aspect ratio : 16:9 Frame rate : 29.970 fps Color space : YUV Chroma subsampling : 4:2:2 Bit depth : 10 bits Compression mode : Lossless Bits/(Pixel*Frame) : 21.333 Time code of first frame : 01:00:00:00 / 01:00:00:00 Time code source : Adobe tc_A / Adobe tc_O Stream size : 1.54 GiB (100%)
+ Reply to Thread
Results 1 to 22 of 22
OK. However, I recently rebuilt my computer and cleaned it of all the players/codecs I had installed over the years (VLC, MPC, Potplayer, etc.). Now I only have two players: WMP and QT. And I have been trying to be parsimonious in installing codecs to determine exactly what I need for playback. As it stands, I have only the following installed:
- QT 7 (for my ProRes footage)
- Avid codecs (for my DNxHD footage)
- utvideo (for lossless intermediates)
- cedocida (for DV-AVI captures)
- xiph (FLAC support)
So, are you saying that it is OK to install VLC and it doesn't screw with your system by installing a bunch of unwanted codecs? Thanks.
EDIT: added xiph
Last edited by SameSelf; 29th Jan 2016 at 10:42.
^Yes, VLC comes as a "portable" version in a folder. Nothing is installed
Technically, a "codec" compresses , and decompresses data . v210 is already decompressed (it's uncompressed 10bit YUV 422) so there is nothing to compress or decompress, thus no codec.
But not all programs handle 10bit video natively. Some are only 8bit compatible. You can install a "codec" to have some applications handle 10bit YUV422 that normally do not handle 10bit video. For example, blackmagic, aja, cineform, dt all have v210 "codecs" that allow you to export (not really compress) and import v210 in applications that normally do not handle 10bit
Wow, thanks pdr for the greater insight and understanding. I did not realize that it was the 10 bit aspect of my file that was causing problems versus a non-existent codec. I exported the file from DaVinci Resolve, so you were right on the mark about blackmagic having a v210 "codec".
Full disclosure here. The real reason I am trying to figure this out is I want to find a way to generate a lossless intermediate from Resolve versus exporting to ProRes 422. It sounds like I need to figure out a way to export to an 8 bit lossless because I know the 10 bit export will give me fits when I try to frameserve to x264 via Avisynth. I suppose I could always bring it into PPro and frameserve from there. But I am trying to avoid that step if possible. Do you have any tips?
There is no problem with 10bit export and frameserving with avisynth. You can use dither tools to handle it (and keep 10bit, and encode 10bit x264) or properly dither down to 8bit if your end goal is 8bit x264. You need to open 10bit video as stacked 16bit in avisynth to keep the full 10bit; most people do that with l-smash these days, but the hacked ffms2 version can do it too. Or vapoursynth can handle it natively too
UTVideo has QT components (MOV) and a 10bit YUV 422 variant. But I can't recall offhand if it appears in Resolve, but the option appears in QTPro
Thanks for the clarification. I am not interested in 10 bit x264 encodes (maybe I should be?), so I definitely need to figure out how to properly dither down to 8 bit. I am assuming that if I want to dither down to 8 bit then I don't need to open as stacked 16 bit (only if I intend to keep 10 bit)?
Also, utvideo does not appear in Resolve 12.
EDIT: I should probably mention that the only reason I am dealing with 10 bit is because that is what my Atomos Ninja encodes to.
QTPro is $30. As someone who shoots a ton of ProRes 422 footage, would you highly recommend that I purchase QTPro? I am not too interested in encoding for iPhones or stuff like that. I am wondering more about the functionality of a proper video editing suite.
The "best practices" workflow is to keep 10 bit all the way through until the end if you have to use 8bit. That will give the highest quality, most flexibility in grading. That is assuming you have true 10bit in the first place. Not all camera have 10bit output; if you're recording through HDMI, a consumer camera, it's most likely 8bit (you have 8bit data in 10bit prores). HD-SDI outputs 10bit, but not all cameras have true 10bit output from SDI. No consumer level camera will have SDI output or 10bit data
If you open true 10bit data as 8bit straight without dithering, you will get banding because intermediate values will be truncated. You will get "gaps" or jumps in data if you have a gradient like a blue sky or a 1 tone wall, or a shadow.
So you won't see the benefit with 8bit data in 10bit. But if you still dither it, you can reduce banding. But IMO, it's not worth jumping through all the hoops if you're starting with 8bit data.
Currently, all end delivery formats are still 8bit. But next gen, HEVC, etc.. will make 10bit become more common place
Resolve is very picky though, and anything not Apple certified won't show up, so UT probably won't show up either
Most Windows editing suites are moving away from Apple QT or at least Apple's own implementation of QT (windows QT is 32bit, poorly multithreaded, slow as molasses). For example, Adobe has their own QT importer and 64bit bridge, same as NukeX. They no longer rely on Apple's own QT importer. However, QT on a Mac is a different beast. It's almost as if they nerfed QT for Windows on purpose
Thank you. I understand the need to keep everything 10-bit until the final step of encoding to avoid banding and such. Yes, I have a consumer camera (Canon HV40) which outputs 8-bit via HDMI. The Ninja however packs it into a 10-bit container and doesn't offer an 8-bit option. So I am not clinging to 10-bit for some placebo-like benefit (however, I have heard it said that it is still preferable to grade in 10-bit even if the source footage is 8-bit). Rather, the Ninja delivers 10-bit, and I don't want to transcode.
Fortunately, the Ninja is Apple Certified, and Resolve recognizes my ProRes 422 files and works like a dream with them. I have no problems scrubbing and editing. But you are right, Resolve is picky. It reads .mts files, but it won't read .m2ts or MPEG2 Intra .m2v files. I guess Blackmagic builds their software to mainly support their hardware.
I could switch my Ninja to DNxHD in a QT container. I just haven't decided whether this is preferable to ProRes 422 or not. However, I am surprised to hear that most Windows editing suites are moving away from Apple QT. I am under the impression that ProRes 422 is well entrenched in the video editing space. I wonder if Blackmagic built their own 64-bit QT importer as well.
Yes, prores is still entrenched as the standard for many professional workflows, but what I meant is the software (at least on windows software) has been moving away from using Apple's own Windows 32bit QT decoder, and instead using some custom 64bit implementation for import/export. If you look at the last few sony vegas versions, many of the crashes can be directly traced to that module (and Vegas is Windows only). Adobe made the switch I think in CS5
DNxHD is a good choice, but it can have issues with gamma shifts in some software, even more often than Prores. If I was choosing between those two I would use prores, unless you were editing on Avid MC . DNxHD works very well there and is the preferred intermediate there, analgous to how prores is the preferred intermediate with FCP/FCPX
I am going to go with your suggestion and stay with ProRes 422 versus DNxHD. I often wondered what the benefit of one over the other is. However, Avid MC is out of my league while Resolve hits my sweet spot i.e. FREE!
Also, FWIW, I transcoded an AVCHD file to ProRes 422 using ffmbc, and Resolve reads it flawlessly just like my Ninja files while refusing to render the first 45 frames or so of the MP4 source. So whatever ffmbc's secret sauce is, it is spot on!
I would be wary - because some users have reported issues, even with the ffmbc variant of prores, on both FCP/X and Resolve. It might work for a while then you might get a black frame or glitch. The other issue is a slight color difference and gamma shift. In the current Adobe CC versions, there is a discernable difference on the scopes with the ffmbc prores variant , but not the ffmpeg prores variant (but naked eye can't see anything on typical content) . Apple certified variants seem to never have those issues, they seem more consistent
Thanks for the heads up. I am unaware of any glitches or gamma shifts. But fortunately, I don't have to convert video very often. Most of the video I edit is my own shot on my Ninja. Only when I end up with other parent shot video do I need to convert because that video is invariably AVCHD. And I only use other parent shot video for multicam edits which requires frame accurate transcodes.
However, your comments got me thinking, so I decided to do a test. I shot some gray bars on my Canon HV40 in Cine mode to my Ninja in ProRes 422 HQ. I brought it into AE and using Color Finesse grabbed a scope. Then, I took the Ninja file and pushed it through ffmbc using the following:
ffmbc -i graybars.mov -vcodec prores -profile hq -qscale 1 -pix_fmt yuv422p10le -an ffmbc.mov
Ninja ProRes HQ Gray Bars
FFMBC Transcode to ProRes HQ
Sorry I should have been more clear instead of rambling 2 sentences . For non Apple Prores variants, there is sometimes a gamma shift in programs like resolve and FCP. It doesn't seem to plague Adobe (or at least as frequently), which is more forgiving. Quicktime in general can be problematic in many scenarios and is riddled with various gamma shift issues. This is very well known. DNxHD as mentioned eariler, especially the MOV variant is especially susceptible. The MXF variant is less susceptible
For ffmbc prores specifically, there is a slight discrepancy, but only when there is a bit depth difference in input vs. output. So in your case for a prores input, you shouldn't see any difference with a prores output because both are 10bit YUV422 formats. This is a true difference and affects everything (not just Adobe or software title x,y,z). The reason is ffmbc applies floyd-steinberg dithering for colorspace bit depth conversions by default, which is different than ffmpeg behaviour .This dithering behaviour is nothing to be worried about in most cases, in fact you might argue it's beneficial. But the inconsisitencies in handling in FCP/X and Resolve is something to be worried about
But the other problem to be aware of is ffmbc cannot handle newer avs 2.6 additional colorspace scripts properly. eg. So if you feed a dither tools YV16 script, you will get an even more visible (even to naked eye) shift
Last edited by poisondeathray; 30th Jan 2016 at 13:35.
Thank you as always. I did a little more research on the web and came across the following which is quite interesting:
So I decided to perform a different test. I generated the bars and tone in PP which are 75% SMPTE. And while I don't usually do this, I exported from PP as a QT format and brought that back into PP and sure enough there is a shift in the color. Notice how in the original image, each color bar is exactly in the color squares on the scope. However, in the QT export they have moved and this movement is obvious to the naked eye. So there is definitely some gamma shift being applied. The good news is I usually export from PP using utvideo. I brought this back into PP and the colors were very accurate. Phew. But you are correct. When I take the utvideo export and transcode it to ProRes 422 HQ using ffmbc 0.7-rc8 there is a slight color shift. Specifically, Red, Magenta, and Yellow are more saturated while Blue, Green, and Cyan are pretty close. I couldn't get ffmbc to read the utvideo avi and had to load it via Avisynth using AVISource(). However, I don't think Avisynth was the source of the shift because I transcoded the utvideo export to ProRes using ffmpeg and ffmpeg was able to read the utvideo avi natively. But honestly, the difference between ffmpeg and ffmbc is non-existent when I brought the ffmpeg encode back into PP.
Also, and this is quite interesting. I took the ProRes file generated by ffmbc and loaded this into Resolve (Note: this file and the QT export from PP were the only files that Resolve would read. It would not read the ProRes file from ffmpeg or the utvideo export.) When I vectorscoped the ffmbc generated file in Resolve, it looked fine. Then, I exported this from Resolve as QT uncompressed 422 10-bit and brought that back into PP, and believe it or not, the colors look fine. No shift! The vectorscope is a little messy, but rest assured the color bars are exactly where they are supposed to be. So it looks like the problem is not with the colors per se. But rather how the programs read the flags embedded in the ProRes file.
Finally, when I read into Resolve the QT export from PP, the colors are off just as before.
So I am going to go out on a limb and say that ffmbc is accurate. The problem lies in the program and how it reads the encoded file.
Note: I generated the bars in a project set at 1920x1080 and exported all of them as 1920x1080 YUV 4:2:2 BT.709.
So, in summary, below are the vectorscopes of the SMPTE color bars:
1. Original bars generated in PP and scoped prior to export
2. Exported as QT (color shift)
3. Exported as utvideo YUV422 BT.709 (no color shift)
4. Exported as Lagarith YUY2 (no color shift)
5. Transcode the utvideo to ProRes 422 HQ using ffmbc (color shift)
6. Transcode the utvideo to ProRes 422 HQ using ffmpeg (color shift)
7. Round trip through Resolve using ffmbc (no color shift)
1. Original SMPTE Color Bars
2. QT Export from PP
3. UTVideo Export from PP
4. Lagarith Export from PP
5. UTVideo Transcode to ProRes 422 HQ using ffmbc
6. UTVideo Transcode to ProRes 422 using ffmpeg
7. Resolve Export as QT
Last edited by SameSelf; 1st Feb 2016 at 20:12. Reason: Added Lagarith export for comparison and documentation
If you feed ffmbc YUV (but not YV16 or YV24) and export YUV in the same bit depth there should be no difference, unless the receiving program handles it differently, and some programs do handle it differently. Important to note that Premiere has a YUV capable since CS5 ; because many other programs work in RGB, and that is a common source of these discrepancies
But when you convert an RGB source=>YUV (eg. maybe a color chart, maybe an image sequence, maybe an RGB export from AE you're converting to prores, not YUV colorbars), ffmbc will use Rec709 and ffmpeg will use Rec601, regardless of resolution . They will even write this in the metadata (but not all programs use the metadata to convert to RGB for display, most actually ignore the metadata). This also results a significant color shift and visible difference. This is also important to note if you're handling SD vs HD material . (There are ways to use colormatrix as -vf and to signal in/out color matrix with flags now, I'm just taking about default conversion)
The other minor differences I was talking about refer to the dithering, those aren't large difference visible to naked eye under normal circumstances but detectable with scopes and certain situations like logos with gradients , those sorts of things. Single colors like color bars won't show those types of differences because there is no gradient. But something like a shadow, a sky those types of things will show those dithering differnences. The gradients will be smoother. This is also one of the reasons why the ffmbc prores encodes are much heavier (higher bitrate) than ffmpeg - the diterhing is essentially fine "noise"
Last edited by poisondeathray; 30th Jan 2016 at 16:26.
Yes, I guess the bottom line is to test your workflow end to end. There are so many little "gotchas", mostly dealing with YUV<=>RGB conversions. That is a large contributor behind the various dreaded QT gamma shifts as well.
I'm far from an Apple fanboy - but Apple certified Prores is definitely more strict. One reason for this is the certified version doesn't allow for extended range values (full range) . This leads to more consistency in recieving programs - they all map to 64-940 in 10 bit values internally as the black and white point, not 0-1023 (1024 values), but expand to 0-1023 in RGB when decoded in the host program. So for your Ninja/Shotgun or any certified recorder, you can be sure you're not losing data by clipping due to the recording format (user exposure/lighting problems, of course, are a separate issue). However, you can encode ffmpeg or ffmbc prores full range data - this can sometimes cause discrepancies in the recieving program due to differences in mapping
A very common scenario on Windows is maybe you do some edits then send it to AE for some effects and color work. If you don't stay in some RGB format, but instead use ffmbc prores (some places / clients require you to submit prores), you end up with something very different depending on the recieving program. If you re-import it back into AE , it looks significantly different. ffmpeg prores looks closer to the original (albeit with more banding). But in other programs both sometimes look similar. These are the types of inconsistencies I'm talking about. Now prores does have a 4444 variant , but that comes in either YUV or RGB flavours, so that isn't immune to some inconsistencies either. That PDF chart shows that as well
UT video is good; but the imported YUV variant is actually treated as RGB in PP. If you have extended range values in YUV, they will get clipped - this is easy to demonstrate I'm sure I've posted some examples before. (It's not just Adobe, other NLE's do this as well). So it's not actually "lossless" in PP in every situation. When might you have extended range values? Commonly in consumer recordings with AVCHD, DV, HDV, XDCAM, XAVC, etc.. they usually have usable 235-255 8bit values. They usually record 16-255. If you converted to UT Video in YUV, those 235-255 values get clipped
PS. I would still be on the lookout for black or corrupted frames in resolve when using non-certified Prores, despite being perfectly fine in other programs.
Last edited by poisondeathray; 30th Jan 2016 at 17:45.