Thanks MV. Yeah, I saw the 16 bitness. Oddly PPro claims it's 8-bit but maybe that's because the project is 8-bit. Or it's lying. Or both.

I don't see the reference to level 6. Is that knowledge in your head or information in the text?

I'll follow the Blackmagic thread.

I did a quick scan of the Blackmagic post results. I'm not actually connecting to one of their devices, I'm just getting video from someone who used one for live capture. They've got issues to sort out of their own as the files are too big to do a rush backup at the end of the shoot day. 16 bitness is part of the problem, but they're also uncompressed. Not my circus but I'm still stuck with the monkeys.

In any case I can find workarounds while gently encouraging them to solve their capture problem.

I see a lot of mention on the forum that VP13 should read ProRes. That's not my experience so far but if it did I could save my money and skip the upgrade. Or just grease my elbows and dig in to PPro rather than fight it.

Level 6:

https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding_tiers_and_levels

Actually, MV, maybe you could explain to me the 16-bit detail. For a Prores 422 LT file that VP15 can open, MediaInfo reports:

Bits/(Pixel*Frame)                       : 1.864

For the YUV 422 file, MediaInfo reports:

Bits/(Pixel*Frame)                       : 16.000

I assume this is the info you're using to say that the file is 16-bit, but 16-bits per what? Fairly obviously MediaInfo isn't referring to bit depth here.

Okay, I think I need to write-off that 16-bit answer. MediaInfo appears to be reporting 16 bits per uncompressed pixel but with 422 sampling that'd be 8bits+4bits+4bits = 16bits. In other words it's 8 bit color depth. Nothing exotic. So more likely this is just a matter of it being a quicktime codec that VP15 isn't using.

For my purposes I can drop the entire folder into Adobe's media encoder and batch convert them to something Vegas likes. I'm not making a movie, I'm just reviewing footage and outputting stills. I'm not going to worry about transcoding when it's painless.

Next question is whether VP13 should be able to decode ProRes as ProRes is what they'll inevitably provide. If not then maybe I should upgrade to VP15.

Bits per pixel only tells you the efficiency of the compression.

The only time it reflects BIT DEPTH is uncompressed, which yours obviously is.

Your math is not correct. Bit depth and chroma subsampling are mutually exclusive quantifiers.

An example is "10 Bits per Channel, 4:2:2 Chroma Subsampling."

For purposes. of further discussion, we must refer to bits per channel*, and not bits per pixel nor chroma subsampling. A sample of your source (not youtube) would be most welcome by others for testing your observations.

10 bit 422 is considered every bit the equal of 8 bit 444, so your supplier of 720p capture (why?) is engaging in massive overkill. If ProRes or DNxHD aren't good enough, find better trained monkeys.

My search results contain references to the current state of affairs between Magix and Blackmagic, which "used" to be a partner. If that's not relevant, I apologize.

* Technically, bits per channel means "Uncompressed bits per pixel per color channel."

Okay, this isn't really helpful or useful. The file is 8-bit per channel. The mediaInfo field I cited isn't referring to bit depth per channel so you must be looking at something else in the mediaInfo output. I don't know what that is but it's not "Bits/(Pixel*Frame)". (there is a Bit Depth field with a value of 16, but it's in the audio section so I doubt that's what you're looking at)

After a bit of testing I determined that VP15 won't open that file's video stream even if it's using the QT plugin. So the workaround is to batch convert the media if I want to use it in Vegas.

The BMD UltraStudio HD Mini appears to just output a raw stream over Thunderbolt. The capture software is in charge of encoding the file and the choices are very limited 8-bit YUV 422 uncompressed was just the least-bad choice, evidently. As for us feeding it the BMD box 720p SDI, it's enough for our purposes. In any case I don't personally need to interface with the BMD hardware so that's not my problem. My problem was just an unreadable file.

The solution was for me to batch convert everything into something Vegas 15 could use. I was just hoping someone had some useful insight. Thanks for your effort!

You are welcome. If you ever get around to uploading that sample, im sure that useful insight will be forthcoming..

Right. I forgot the part about uploading a sample. Unfortunately the smallest file is 350+ MB and it's all under NDA anyway. So I don't think an upload is in the cards.

Mediainfo has misreported things in the past, like vfr and field order, but this is a new one on me. That was my reason for asking..

rmack350 -- Have you tried to rename the file's extension to .AVI ?

Could you try that?... Out of pure curiosity. Since it's essentially YUY2 in a MOV container.

Hi Jam_One. Renaming the Quicktime YUV422 file as an AVI allowed Vegas to load it into a project but only audio plays. Not surprising as Vegas knows what to do with the audio stream but not the video stream. Also, Windows media player did the same thing, playing the audio while ignoring the video. I guess I'd never tried that.

Playing the audio without the video is also what Vegas would do if it were using quicktime to play the .mov file, so I think this is pretty normal. Luckily I can transcode it to something else that Vegas can use.

MusicVid, I'm not trying to give you a hard time. The 16-bit idea seemed plausible until I realized the MediaInfo field I was looking at wasn't saying the file was using 16-bit color. So I'm sincere in asking you what you meant and what fields were leading you to that conclusion?

I did a quick scan of the Blackmagic post results. I'm not actually connecting to one of their devices, I'm just getting video from someone who used one for live capture. They've got issues to sort out of their own as the files are too big to do a rush backup at the end of the shoot day. 16 bitness is part of the problem, but they're also uncompressed. Not my circus but I'm still stuck with the monkeys.

In any case I can find workarounds while gently encouraging them to solve their capture problem.

I see a lot of mention on the forum that VP13 should read ProRes. That's not my experience so far but if it did I could save my money and skip the upgrade. Or just grease my elbows and dig in to PPro rather than fight it.

Even though I love Vegas.... I've stuck with PPro CS6 - Yes, it's more clunky compared to Vegas Pro 13 (Which I stil use for down and dirty projects), but PPro CS6 just works for my aged x58 desktop with Fermi based GTX-660ti graphics card. Slightly OC'd helps... I kind of dread the day I have to upgrade to newer hardware when my motherboard finally bites it...

Lacking a bit depth flag, MediaInfo "should" report actual bit depth as bpp, but only if it is uncompressed intra, which we've both agreed on. Obviously bpp is much lower in a compressed interframe file, as you've pointed out. Apple has been just plain weird with flags in the past, and I shouldn't have taken your readout at face value. Not owning PP for Mac, I should have "just" asked for a sample, and stuffed my impression for later. Too much time on my hands, that's all.

You know, there is an ancient tool called TSMuxer that may open your .mov and rewrap it as a Vegas-friendly transport stream. This, if it works, could save you that second encode step.

Not enough time or brain capacity on my hands, unfortunately, so I forget things I knew a year ago. Thanks for the reminder about TSMuxer.

I think what you were doing was taking a quick glance at the output text, seeing bits, seeing 16, and saying "ah-Hah!" because you expected to see a bit depth field that wasn't there.

So here's a snip of output from a plain 8-bit uncompressed AVI clip. Yes, MediaInfo picks up the Bit Depth for this one. It also shows average Bits per Pixel as 24, or 8-bits per channel for every pixel, which is what i was trying to say earlier (and failing as 422 refers to how often those U and V values are sampled, not that they're sampled at 4-bits. The average still comes out to 16 bits per pixel.)

Frame rate                               : 59.940 FPS
Bit depth                                : 8 bits
Bits/(Pixel*Frame)                       : 24.000

Yeah, files report different ways. Sometimes its needed.to dig under the surface.to find whats really there. Anyway, let us know if tsmuxer works.

Well, I had a copy of TSMuxer stashed away so I dusted it off and tried both a quicktime YUV422 and a ProRes file in it. For the ProRes it said it couldn't read the tracks, and for the YUV422 file it just shrugged it's shoulders and gave up with an empty dialog box. Reading the notes on it I think the only quicktime it can handle is mp4 in quicktime. No joy there, but thanks for nudging me to look at it.