"Vegas is not able to decode H.264 10bit 422 high profile files," What?

XAVC is high profile h.264 that is 10 bit, 422 capable.

I would like to see the MediaInfo on the source material. You may be able to craft an FFMPEG command to re-wrap the video, and convert the audio to PCM, then stick it into an MXF container. Vegas will then treat it like XAVC.

"2) The XAVC Format The Sony XAVC format complies with H.264 Advance Video Coding, level 5.2 which is the highest level of performance determined by the H.264 standard. The video essence is encapsulated in an industry standard MXF OP-1a wrapper, accompanied by audio and meta-data elements. The compression algorithm is completely flexible in establishing compression tools for Intra-frame as well and Inter-frame compression (Long Group of Pictures or Long GOP), for interlace as well as progressive video formats, and with color sampling structures of 4:2:0, 4:2:2 and 4:4:4 at up to 12 bits of color pixel bit-depth."

Taken from: https://pro.sony.com/bbsccms/assets/files/micro/xdcam/solutions/Technology_Newsletter_XAVC_2015.pdf

MediaInfo instructions: https://www.vegascreativesoftware.info/us/forum/faq-how-to-post-mediainfo-and-file-properties--104561/

Also, how exactly were the files created?

This particular clip was produced with the x264vfw encoder, recorded with Virtualdub 1.10.4
input was seto to keep/accept only YUV 4:2:2 input, preset ultrafast, tuning none, profile auto, QP 15, zero-latency.

This is the source file. It's produced as an AVI file with a PCM audio track

General
Complete name                            : \\DESKTOP-77EBJFB\New folder\capture9.avi
Format                                   : AVI
Format/Info                              : Audio Video Interleave
Format profile                           : OpenDML
File size                                : 6.73 GiB
Duration                                 : 6 min 14 s
Overall bit rate                         : 154 Mb/s

Video
ID                                       : 0
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High 4:2:2@L4.2
Format settings, CABAC                   : No
Format settings, ReFrames                : 1 frame
Codec ID                                 : H264
Duration                                 : 6 min 14 s
Bit rate                                 : 153 Mb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate                               : 60.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:2
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 1.230
Stream size                              : 6.66 GiB (99%)
Writing library                          : x264 core 148 r2694bm 3b70645
Encoding settings                        : cabac=0 / ref=1 / deblock=0:0:0 / analyse=0:0 / me=dia / subme=0 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=0 / intra_refresh=0 / rc=cqp / mbtree=0 / qp=15 / ip_ratio=1.40 / aq=0

Audio
ID                                       : 1
Format                                   : PCM
Format settings, Endianness              : Little
Format settings, Sign                    : Signed
Codec ID                                 : 1
Duration                                 : 6 min 14 s
Bit rate mode                            : Constant
Bit rate                                 : 1 536 kb/s
Channel(s)                               : 2 channels
Sampling rate                            : 48.0 kHz
Bit depth                                : 16 bits
Stream size                              : 68.5 MiB (1%)
Alignment                                : Aligned on interleaves
Interleave, duration                     : 21  ms (1.28 video frame)

Current attempts to re-wrap into mxf are tripping up with a weird error

[mxf @ 0000000004e00520] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 2490 >= 24

and so on and so forth, I get it repeated various times, even when muxing only the video track. I looked at an MXF output from Vegas and it identifies as 1channel audio (mono?) in Media Info which struck me as weird but probably not related to this issue (or maybe idk).

I tried flagging the audio for reencoding as Big Endian and that didn't do anything but.

If I do a video only re-wrap, with those errors the video will load into vegas, and its not a blank green screen but the image is severely garbled with decoding errors/macroblocks etc.

Initial attempts to get this file into vegas were the aforementioned MP4/AAC remux. Video stream was copied while audio was reencoded to AAC.

One more interesting piece of information.

While Vegas won't even import the file and flat out refuses to touch the source AVI.

Virtualdub can open said source AVI just fine and even play it back.

Try rewrapping from AVI to MP4.

Try rewrapping from AVI to MP4.

I've tried that already it's what made me come here to ask. I even tried straight up reencoding the stream with libx264 through ffmpeg using bogstandard options (aside from the colorspace).

So far the only workable option I've found is to take source AVI, index with LSMASHWorks, edit script to include my audio source, and then mount the script with AVFS. That'll import fine. Scrubbing and Playback are slow as crap though.

The problem is that Vegas doesn't ingest the AVC Long High422@Lx.x format (independent of the container... be it MOV MP4 etc... or the bit depth 8 or 10). This problem was already discussed in a post a month ago.

Gary Rebholz said Magix would look into it...

Catalyst Browser is a way to read and convert it.

Thank you forum, for eating my post.....

Catalyst would not load the source AVI. I could remux into MOV/AAC or MP4/AAC and it would work with them. However getting the export button to light up required me to not use PCM audio, which really chaffes me because THE OUTPUT STREAM USES PCM AUDIO. (Mediainfo also says there are 10 mono tracks.....lol)

the output file does work (XAVC Long 50mbps option), but I feel like its too many steps and I'm not a pro doing this for a client so I am about ready to wash my hands of it and deal with any deficiencies of capturing in 4:2:0 and using a simple remux step to get it into vegas. I also don't like having to transcode source files.

Also my Colormunki DISPLAY just arrived so I want to run off and play with that for a bit as well.

I am starting to feel like it should be mandatory to explain that a question about user captured Game footage, or footage created by utility apps should be stuck in Off Topic. So as to not waste the video editing communities time trying to sort out someones fail capture configuration. Push the onus back out the capture utility to create a video standard file.

"Vegas is not able to decode H.264 10bit 422 high profile files," What?

XAVC is high profile h.264 that is 10 bit, 422 capable.

I would like to see the MediaInfo on the source material. You may be able to craft an FFMPEG command to re-wrap the video, and convert the audio to PCM, then stick it into an MXF container. Vegas will then treat it like XAVC.

Sure, XAVC I is also 10bit 422 high profile, I do that with my FS all the time - but that is sitting in a different container. For sure XAVC I can be decoded, but - also - for sure the GH5 files cannot be decoded in Vegas. Yes, you can convert the footage with Tools like TMPGenc 6 or the Catalyst Prepare, but that is an additional step in the workflow. And true, Gary said they will look into that issue. And FFMPEG is not everyones tool.

So at the end we need a change in the decoders of Vegas, that will allow to import and decode this type of footage direct in Vegas, without preparation and conversion.

I am starting to feel like it should be mandatory to explain that a question about user captured Game footage, or footage created by utility apps should be stuck in Off Topic. So as to not waste the video editing communities time trying to sort out someones fail capture configuration. Push the onus back out the capture utility to create a video standard file.

That is a sort of judgment that is not so easy. I agree that there are different types of approaches between "Gamers" and "Filmers" - but only the "Filmers" should have the right to discuss their issues in the Vegas forum? Tough point.

"I can't take umbrage with that feeling/position in this case, because x264vfw was basically built to shove an H.264 stream into a container it didn't belong in, breaking god knows what standards along the way."

I agree.

"...its a failure on Vegas' part to not be adaptive enough where other utilities clearly have no trouble."

I disagree. Vegas is not a utility. It's a video editor.

"...a professional should be prepared to deal with the unexpected and adapt."

That a professional should be able to deal with the unexpected and adapt is an admirable goal, but that doesn't mean that Vegas coders should be expected to solve all of your problems for the price of a single tool.

"Video is video is video"

That's naïve and doesn't do anything to strengthen any other point you might like to make.

"...to try and learn something and pick up some knowledge along the way..."

I applaud you for that. Stick around and contribute. This community has been very helpful over the years. Many people have cooperated to solve some intractable problems even when the solution was never integrated into Vegas Pro. That's the primary reason I'm still here.

For the purposes of this forum, video is video is video. Someone has a problem working with their video files in Vegas. People discuss how to solve it. That's all I meant, the type of content is mostly irrelevant here unless it can be demonstrated otherwise.

It's like arguing over whether you should help someone edit video of a police chase versus a Broadway play. It's pretentious and dumb.

I will stick around. I'm not gonna leave over one disagreement or anything.

there was a lot to be said for betasp... ;-)

since the dawn of nle's i have always transcoded 'esoteric' formats to whatever the nle was happiest with. nowadays i use xavc-i for use in both vegas and resolve. no problems at all.

quite frankly i would prefer ANY nle coders to be working on known bugs and refining their nle rather than simply adding codecs that might well introduce even more bugs...

when looking at acquiring footage, some thought should be given to the nature of its acquisition format and whether it's going to play well with your nle. if you choose to go with some more specialized codec then it would make sense to test a sample BEFOREHAND, in nle and if problematic, whether it can be transcoded easily.

I don't disagree with any of that. A lot of what I do is testing random stuff out.

tquite frankly i would prefer ANY nle coders to be working on known bugs and refining their nle rather than simply adding codecs that might well introduce even more bugs...

A codec integrated in a nle does not introduce more bugs, if that is done by the development team. For every technology movement - so from SD zu HD, from HD to UHD, and now from UHD to UHD HDR - we have seen the requirement of new codecs. It will be important for the future development of Vegas to add codecs.

Since we see now new mainstream cameras like the GH5 emerging, there will be the need to implement H.264 10bit 422 high profile even in other containers then X AVC I. Yes I think this may become a mainstream camera, and Vegas should support that.

Another example will be H.265 with 10bit - since we have that up to now with 8bit only.

By the way, we have seen that this high profile 10bit 422 H.264 was implemented in the Catalyst Suite too. So no reason why that should not be done in Vegas too.