give me a day or two and I'll tell you if it works :) I work on a VT4 system some for one of my clients and i can pull some of the 25 bit files in the two different codecs they have and I'll tell you if they open and I can drop em on a site for you to DL.

Dave

Thanks, I don't have any files here to try...getting a tricaster pro in but not for a week or so...I've gotten conflicting reports from Newtek tech support and forums....Tech support said should be no problem...but the forums state that even though we could load the NT25 Codec into our Vegas System and open the files that something goes wrong in rendering the files back out...It's also possible to render the nt25 files into dv avi within Tricaster and then use those files in Vegas, but I'm looking at 8-10 hours of footage per shoot and wouldn't want to do that. Another suggestion was to switch to Speededit but I'd prefer to stay with Vegas. Ira

yea, the Newtek forum folks are a bunch of .... well, lets just say their kinda like mac heads but about the toaster system.

I just set our VT4 to capture the newtek 25 Mbit stream and I am assuming that this is the one you're talking about, now on the VT4 they have two options for this one with the audio interleaved and one with it in a separated file. Their manual says to use the one with separate audio file for best compatibility outside of the Newtek family.

As for what the tech support says, I don't know that i believe them either, I've had them tell me more or less bogus information before, but I'll find out and post some clips today if I have time, other wise it will be after the weekend (father in-law's Birthday out of town this weekend leaving tonight).

Dave

I'm afraid i was unable to pull some footage today, I had some things come up, Sorry boss, I'll get them up when i get back. you could ask someone else to on the Forums to post for ya too, but I'll get it up after the weekend.

Dave

Dave, no sweat...enjoy the party... I'm not sure which version of the NT25 Codec the Tricaster records,,,audio interleaved or not....Ira

129MB Zip File Here as of this posting the Upload will be done in 30 min barring any unforseen difficulties.

I'll save you a bit though, the Newtek25 codec did not open at all, the DV Codecs however did, both interleved and non-interleved. The only thing I was able to pull of the Newtek25 codec was the audio, it put 4 channels of audio up and nothing else.

Any luck boss?

be interested to know if you can get it to work.

Dave

I'll have to first point out that there is no fundamental problem in getting video to appear at all as NT25 (and the impendingly more popular SpeedHQ that will replace it for anything above SD/DV resolution) is not a private codec like we have with Sony's internal Vegas DV codec. You need to have access to the codec. If you own a TriCaster or any other NewTek product, you could ask for access to it. No harm in that. If you aren't getting something to appear when you go into Vegas from the TriCaster source, or if you can't get NT25.AVI out of Vegas, then you have a specific issue locally.

What you do need to watch for is the levels. Other RGB applications seem to have no issue. Also Vegas has no issue with Edius' HQ codec and PICVideo MJPEG which are both YUV based and also not provided by Sony. Vegas does though have problems with reading and writing NewTek's special codecs from a levels perspective. They fall out of calibration in both directions. Yet other RGB based applications seem to be OK with it (from Adobe, Bauhaus and Thomson for example). I've not determined who is to blame exactly, but whoever it is - the problem only hits Vegas from the reports so far. Nothing too worrying though.

If you do CC in Vegas then you are correcting for something and the issue appears to be with the mapping of this specific YUV codec with Vegas' RGBA32 pipeline. It is easy to see how far out it is by using and comparing (with the Windows clipboard helping to transfer stills) using the test card generators within both NewTek and Sony systems. Matching these against the software oscilloscopes/vectorscopes gives the level issue game away.

Alarmingly, if you correct the bars using levels or color curves in Vegas, when you come to export back as NT25/SpeedHQ, the fact that you are now writing to this specific same codec causes Vegas to get it wrong on the way out too (or at least it is wrong in all the aforementioned vendor apps including NewTek's). In fact it is probably better to leave the levels as they are and correct in a non-Sony NLE, although you might be crushing the dynamic range - I haven't quite worked this out yet. If this doesn't make sense, do take the option of using DV.AVI as the codec to standardise when you go between apps/systems.

It is believed that the problem is with the Sony reader/writer (from VfW or directshow - whichever). It could be the codec itself and indeed such a problem may not show in the other apps if they are reading and writing from/to different hoses/taps on the codec. Many codecs provide more than just their native data packing format. So this could be where the error occurs. Just knowing that an NLE or compositor is RGB based isn't always enough to know what will be converting from differing formats. I'm not supposing that Sony has hand tuned their readers for codecs they've been asked to verify against rather than following some greater conformance convention. However this may be true for other non-Sony YUV formats.

Just keep in mind when you bring in and when you match back that you still have a good representation. Folks rarely calibrate for file types, including programmers probably. We are usually working out what to do with our camcorders proc-amps to easily overlook an issue like this. I'm doing my best to ignore the differences between NTSC-NorthAmerica-7.5IRE-pedestal, NTSC-Japan-0IRE, ITU R.601:ITU R.709 and the differences with analog and digital approaches to signal processing and special signaling. I am aware that pedestal is an analogue phenomenon. Digital video should assume this doesn't exist and the convention for video is 16-235 with the bottom and top end left for headroom or signaling.


Other than this levels issue, NewTek are very keen on the 486line D1 standard for NTSC and whilst this is reflected in the headers for AVI. You could get caught out with certain mixed workflows. I usually trust the original Sonic Foundry engineering for having got their maths right, but I'm not sure this time around.

The next-gen SpeedHQ codec may be available as a single product in 1Q2007. At least this has been spoken of. So if Sony cared to, or if we could work out what exactly is going wrong here, perhaps this could be fixed for Vegas7d?....

I'd say that the NewTek clique is rather more like the Amiga fraternity than the Mac. Far more about putting the best gear, hardware and software, in the hands of those that can ill afford the contemporary or industry standard. Sometimes standard isn't good enough. ;-)

One way or another the NT25 compatibility issue with Vegas will go away. It is entirely usable now as long as you know what you are doing and adjust the signals at some stage in your workflow. I'll happily report more when I've done some more testing myself. The reality is that I can't quite see Sony picking this issue up. So I've not reported it as yet. If anything I'm pointing out that it might not be shoddy YUV pre-processing by Sony (going back to the codec "pin" options for in/out). I'd say that this would be an unusual incident for them to have got this mathematical aspect wrong. Especially against any accepted YUY2:RGB convention. Compatibility is rarely that straightforward and competitors are hardly going to be itching to admit a fault now are they?

There is enough headroom even in the RGB equivalent of 16-235 YPbPr packed pixels to keep swinging the levels around. Much depends on how much you use software, VGA or more likely DV->analogue conversion sources on external scopes.

Great info RBartlet. As far as my comments about their clique'ness, they don't seem to be nearly as Leetest as they used to be. Back when The VT2 was out and I was doing some research, there some real buttheads that were all Leet and dissin the Vegas world at that time. Now they seem to be much more... not jerk faces :).

Dave

Dave, thanks for the files...when I tried to open the Zip it was corrupt...probably something on my end of the download..I should be getting the Tricaster in by next week at the latest and will do some testing,,,I'll be able to get the NT25 Codec from Newtek...I'm assuming you might not have been able to see the video on your end due to lack of the NT25 Codec in your Vegas system.
RBartlett's comments above do confirm though that there are some issues with working with the NT25 Codec within Vegas...My intended workflow was recording a live 3 camera mix in tricaster to NT25 (that's the codec tricaster uses when doing a live mix) and then doing final editing in Vegas...rendering out to MPG2 for DVD and / or AVI for output to tape. Wondering if there are any offsets to use for correct output of color and luminance going out to these files. I'll look forward to further info from RBartlett as he delves further into this , as he seems to know what he's talking about. Thanks again to all for your time and responses. Ira

RBartlett, Thanks for the info....just to clarify, is it your experience that the levels are off when rendering out to MPG2 / or AVI from the NT25 Codec within Vegas...or only when rendering back out to NT25? Ira

Only when rendering back to NT25. This assumes that you've brought the levels down to within legal values (for Vegas to use internally) some other way.

As these have been subject to a shift and you are aware of it, I don't think that the legalize filters are the ones to immediately dial-in. They are likely to bend down only the top end levels in fear of losing contrast. YMMV.

You'll be alright once you've corrected for the levels being oversaturated on arrival in Vegas (due to the internal reader getting it wrong, or the codec presenting an alternative RGBA32 mode incorrectly [Sony vs NewTek considerations aside]).

Just run a Tricaster test card into one of the files (even after the event) and then either do a luma+chroma / RGB shift in Vegas as necessary (I like to use the color corrector where possible as I feel that I can conform the capture or different cameras into a certain theme tone wise). Be sure that you have the vectorscope or oscilloscope set to the right scaling. You can double check by putting the equivalent Vegas color bar up. (even moving them between systems as stills or uncompressed YUYV if you care to)

The amount you cool it down by is a constant amount, thankfully. When writing all the popular codecs - Vegas gets it right. The actual amount may vary as when you think this through further, there is a lot that can be out due to the camera non-linearities and preferences, the cable length and the proc-amp settings on Tricaster.

Alternatively bring the clips in using the DV codec, but NT25 provides 4:2:2 and MPEG-2 for DVD is 4:2:0 - so with NTSC DV's 4:1:1 is a bit less preferable. TriCaster can capture to many formats, NT25 is high quality and space efficient compared to uncompressed.

Just be aware that the digital data in your AVI when it is NT25 will be too hot by the time it hits the timeline in Vegas.

I personally find DVDs from my videos look too cold by the time I've made them as shiny discs. The DV preview usually looks ok. However, take that notion with a pinch of salt as I use PAL and I'm not using much more than budget gear and pro stuff I've had kindly donated.

This situation has been the truth of the matter for as long as the NT25 codec has existed which goes back to Vegas5. So many folks have actually been quite happy with the look. Just that you did ask if there are any issues with it and strictly speaking, with your engineering head on, there are. Sony might fix it or an option maybe put into the codec (through properties) by NewTek to adapt the levels for the less YUV savvy NLEs. Don't get me wrong, DV is YUV based as is MPEG-2 (and most file and tape formats) but Vegas is crafted for them and/or codecs have been written to accomodate this weirdness.

You have to ask the question why even in this day and age, media being transferred between systems is best brought with a color bar segment, ideally a tone or two as well. It is easy to forget this and take it for granted that the guys in the programming suites will sort this out for us. Don't assume anything. This trade is both art and science.

If you test it and the problem doesn't appear, then something may have changed at either end of the workflow. This scaling issue is to be considered at the time of writing.

Is the NT25 a 10bit 4:2:2 codec?
As this is a broadcast system I assume capable of feeding SDI that'd make sense.

Why not do this simple test.
Shoot a grey scale card through the Tricaster to the NT25 codec. At the same time roll tape in the camera.
Bring both into Vegas and compare using scopes. Use color curves to match the NT25 to the DV on the scopes.
Crude and I'm certain they're more accurate ways but that should get you in the right ball park.

These AVI formats:

NT25, DV, Edius HQ, PIC MJPEG, uncompressed YUY2-mode, uncompressed RGBA32

All calibrate fine in NewTek's TriCaster, VT-Edit and SpeedEDIT's scopes.
Export, re-import, no issue.

Bring NT25 into Vegas and it is too hot. Bring it into other apps like Edius, Bauhaus Mirage and once again it is fine.

NT25 isn't 10bit. NewTek only support 8bit SDI at this point in time. (probably limited to 8bit YUV in at least one direction, maybe both). Alpha channel and 4:4:4 is more the subject of the recent resolution independent NewTek HQ codec, but some of this functionality is in NT25, forget which.

The mapping of YUV to RGB24 in Vegas has been identified by a couple of techies closer than it than I am as being a Sony issue. I'm not able to say either way until I see who fixes the last small piece.

TriCaster isn't the product known for having SDI options anyway. That would be VT[4] and before.

NTSC 75% bars peak at just above 110IRE, on the Vegas scopes, from memory (not at my edit bay right now). From NewTek's writing of the file to Vegas' reading - to confirm the direction. 100% bars from NewTek as the source, they when decoded by Vegas from NT25 range from levels at (8bit) 000 through to 255.

Real tests with a card and camcorder before any of this computer based influence gets in the way is a great idea. If levels are important and headroom beyond what you'll legally broadcast with for pgm-out isn't something you don't mind scaling to suit.

NewTek's video centric products used to have little or no notion of file formats for output other than if they were one of a few of the D1 standards. The world isn't so constrained, so understanding levels and where black and peak-white is can be more important as we move forward beyond the confines of the TV screen and 16bit per pixel sub-sampled imagery. A stills camera ought to use a grey scale reference card also, fwiw. Assuming you lock off all the controls in a manual fashion as per the videographer's best practice guidelines.

The confusing thing for me is that Vegas may be dealing with the transfer correctly. RGB and YUV are not the best cousins to party together. When RGB (or better) kills off the typically compressed (through sub-sampling sometimes with RF modulation) YUV signals - then we'll wonder what this was all about. However the concern is that the software scopes in Vegas may well be calibrated correctly in these cases. Then we have an issue where things are off.

A DV preview straight into a scope might help. If the deck also supports the right setup or if it can be scaled to make up for the lack of setup at the external "real" scope itself.


I think the important part is that live video rarely has any great amount of content below 16 or above 235 in the Y'PbPr world. So vectorscopes in Vegas ought to be the same as in the other apps, or there ought to be a warning symbol that extra latitude has been provided just in case this is a media clip heading for a non-video multimedia application with greater than 601 or 709 color space.

Ron,
my background is in data acquisition systems. Thermcouples, RTDs, pressure transducers, flow meters etc. This is I think no different. All those devices generated a confusing range of values, almost all of them non linear as well, many with the equivalent of setup in the video world ( 5 to 20mA, 0 to 20mA, 1 to 10V etc).

The problem(s) in both worlds are resolved by measurement against know values or by comparing two systems and applying a transfer function. The color curves in Vegas provides the means to pretty easily create your own transfer function. The video scopes provide the means to measure things, I find the waveform, not the vectorscope to be the simplest to work with.

I'm not suggesting that my methodology is 100% or foolproof given the nature of YUV to RGB conversion, things like clipping can trip you up. However it's a pretty good starting point. One that I'd suggest as a starting point. It maybe as simple as NT25 using 0 to 255 or a different gamma value. Either of these will be obvious in the waveform of a grad test card when comparing the recorded DV25 from tape with the recorded and Vegas decoded NT25 waveform. Using the Color Curves to provide a transfer function might well be all that's needed.

And yes, the Broadcast Colors FX I believe simply clips values outside legal, I don't really recommend it.
Most of the other levels FXs convert 0 to 255 to 16 to 235 and that too might not be exactly what's required, that's why I use a custom CC curve when encoding for DVD.

Bob.

When I edited, rendered or was saving tricaster files in vegas it would crash vegas to the desktop an awful lot. newtek tech support recomended that In the edit mode put the newtek files on newteks timeline and render the file "prepare for vcr". if I remember right that was to recompress it without the original newtek codec it was recorded in. seemed to solve the problem
Steven

Ok the problem *might* be this: Vegas is stupid when it comes to levels, and you have to manually wrangle your levels in Vegas.

My guess is that applying the "computer RGB to studio RGB" color corrector preset will make the colors right.

1- My method of doing things:
Get everything into studio RGB color space (RGB with legal values in the range 16-235). When you do lots of video work (as opposed to computer format work), this is appropriate.

--DV, MPEG2, SonyYUV (using default Vegas codecs) will decode to studio RGB.
--Many third party codecs will decode to computer RGB. You need to apply the computer RGB to studio RGB color corrector preset.
--Computer formats like still images decode to computer RGB. Again, convert.

On export:
--DV, MPEG2, SonyYUV expect studio RGB levels. Do nothing.
--Many third party codecs (practically everything via quicktime, windows media, and some others) expect computer RGB levels. Apply studio RGB to computer RGB conversion (i.e. nest the project, apply the filter to that nest).

When setting up the scopes, check the studioRGB checkbox.

2- The scopes (i.e. vectorscope, waveform monitor):
Vegas' scopes are confusing and not well designed. They are sort of designed to mimic analog scopes connected to your edit suite. For your DV (or whatever) video to get to an analog scope, it has to be converted from R'G'B' to Y'CbCr, then it goes over firewire, then it gets converted to analog (composite). Vegas doesn't know what happens in either of these two conversions- you have to explicitly tell it what happens.

The R'G'B' to Y'CbCr conversion is determined by the video codec you use. If it expects studioRGB levels, then check that corresponding setting in the scopes settings.

The Y'CbCr to analog/composite conversion happens in your DV camera or VTR. Let's assume that the DV device follows your country's TV standards (most don't, but that's another story). If your country uses 7.5 IRE setup, then check the corresponding setting.

If you do thing, then Vegas' scopes will emulate what an analog scope would do. However, Vegas' waveform monitor doesn't have a marking for 7.5 IRE (which all analog scopes have). Because of this, I don't personally setup Vegas' scopes this way. I would rather black level peg "0", since there is a marking there. Anyways, the simple thing to do is to ignore the vectorscope and waveform monitor in Vegas. They'll probably just cause confusion.

3- As far as colorspaces goes, I don't believe Vegas' DV/4:1:1 implementation is entirely correct as it ignores co-siting. The end effect is that the chroma gets shifted 1.5 pixels to the right (on decode) / left (if encoding), even if you add chroma blur. A similar but much smaller (and probably insignificant) problem happens with the default main concept MPEG2 encoder. Anyways, that's a different story.

--DV, MPEG2, SonyYUV (using default Vegas codecs) will decode to studio RGB.
======================================================
Unless I'm doing something wrong this is simply incorrect.
DV from most cameras is NOT Studio RGB.
Footage I'm working on now clearly shows levels from 16 to 255 and that is not Studio RGB, nor is it Computer RGB.
The Computer RGB to Studio RGB filter doesn't produce the correct results, the whites end up in the right place (235) but the blacks are pushed up i.e. grey. That makes the image look a tad washed out.
The Levels Filter in Vegas also seems to have a bug in it, I cannot get it to handle the blacks correctly.
The only thing that seems to work correctly is the Color Curves Filter.

Create a custom curve, start from (0,16) to (16,16) to (235,235), three straight lines. The blacks stay black, the whites don't get clipped either. Result in Vegas's Waveform Monitor are 16 to 235, correct Studio RGB. Results on a half decent monitor confirm this transform is correct.

I don't have an analoge waveform monitor here to check what happens once in analogue land however the last time I did check this the results were the same, DV by design exceeds legal white levels but the black levels are correct.

The waveform monitor in Vegas looks pretty correct to me, there's no 7.5 setup marking simply because there is no setup in DV, it's the responsibility of the A<->D converters to handle this. You certainly need to check the settings in them if working in NTSC.

Bob.

DV from most cameras IS studio RGB. Legal values land in the 16-235 range. Most DV cameras record 'illegal' values in the 235-254(Y') range. These values are prone to get clipped- and they kind of should be clipped.

It's the DV cameras that are "incorrect". Although the superwhite information is useful, so in that sense you can argue that it's correct/useful.

The Levels Filter in Vegas also seems to have a bug in it, I cannot get it to handle the blacks correctly.
It does have two bugs in that (not sure about V7):
A- If you use both input start and input weird, you get discontinuous behaviour. But only when you use both at once, and only when the input values are lower than input start.
B- It doesn't round numbers.

The waveform monitor in Vegas looks pretty correct to me, there's no 7.5 setup marking simply because there is no setup in DV
When people say that "there is no setup in DV", you need to pay attention to the context.
They are (or should be) referring to the digital Y'CbCr values, not the analog values (i.e. IRE).
The digital values should not have any setup applied; it should have black level at Y' = 16, always (some cameras disobey this).
When you convert from digital --> analog in a non-Japan US countries, the digital value Y' = 16 should map to analog (composite) 7.5 IRE (almost all DV equipment doesn't do this). Here, the analog signal should have setup applied.

Vegas' scopes' 7.5 IRE setting/check box and "saturation" mode both emulate analog scopes. Although the first feature is silly without a 7.5 IRE marking, and the second one is inconsistent in naming with analog scopes (it should be low pass on/off).

DV from most cameras IS studio RGB. Legal values land in the 16-235 range. Most DV cameras record 'illegal' values in the 235-254(Y') range. These values are prone to get clipped- and they kind of should be clipped.
=====================================================

Well if almost every bit if DV footage I've looked at has values well over 235 and the Studio RGB spec say 100% white shall be 235 then something is wrong. If there's usable detail in the range 235 to 255 why would I want to clip it off?

Perhaps there's some reason but so far all I see from clipping at 235 is simply yielding loss of usable detail. Why do this when it's simple enough to correctly convert to Studio RGB and retain the detail?

Bob.

If you do that:
A- It doesn't follow the standards. You aren't maintaining your video levels.
B- Too much of that and the image will look washed out.

The specs call for legal video to be from 16-235(Y'), with overshoot areas in 235-254 (Y') and 1-16 (Y'). Vegas passes legal video through, and maintains information in those overshoot areas (unlike some other NLEs, which clip the illegal values). That's what Vegas does.

By legal I really mean "in normal useable range", and by illegal I mean "not in normal (useable) range".

Studio RGB spec say 100% white shall be 235 then something is wrong
That's why they call those out-of-range values superwhites. They're whiter than white.