Got the Sony a7siii and after done recording and import to Vegas pro 10 the footage playback doing so much lagging at 10bit
my pc -i9
gpu-RTX 3080
ram -32
@Rocky-Say Hi, download MediaInfo, https://mediaarea.net/en/MediaInfo it's free, right click on the media in your windows folder, open MediaInfo select Text from the View tab, Select & Copy All then paste on here in a new comment,
If your camera records in XAVC Vegas pro 10 might not be compatible,
@Rocky-Say I've tried a variety of test clips from the Sony A7Siii and Vegas seems to be a be able to play them. But some better than others. Seems to do best with 8-bit h.264/avc which has universal high performance gpu hardware decoding support for mov and mp4 clips. The 10-bit format that works best is h.265/hevc 420. Your 3080 gpu can decode that. But if you have an i9 with an Intel igpu, selecting that on the Vegas I/O tab will probably be more optimal. For smoother playback, also uncheck the legacy hevc decoder check-box. 10-bit h.265/hevc 422 might also be tolerable if your cpu has an onboard Intel 750 or greater igpu. But 422 hevc clips will be larger and likely be harder to process than 420 ones, even with hardware acceleration. None of the gpus support 10-bit h.264/avc so you might want to stay away from that.
I have Vegas pro 18 not 10 sorry …so Sony a7siii XAVC S 4:2:2 10bit won’t play back smoothly? It was a lot of lagging
Here's the MediaInfo from the 10-bit h.264/avc test clip I have which does not play so well although it does load without error into Vegas 18 build 527:
General Complete name : D:\MISC\test clips Sony A7Siii\A7SIII XAVC SLOG3 4K 10 422 (avc).mov Format : MPEG-4 Format profile : QuickTime Codec ID : qt 0000.00 (qt ) File size : 229 MiB Duration : 19 s 520 ms Overall bit rate mode : Variable Overall bit rate : 98.3 Mb/s Encoded date : UTC 2021-01-14 03:29:45 Tagged date : UTC 2021-01-14 03:29:48 Writing library : Apple QuickTime com.apple.proapps.reel : Untitled 1 com.apple.proapps.isGood : 0 com.apple.proapps.dataSize : Unknown kind of value! com.apple.proapps.displayFormat : H.264 com.apple.proapps.shootingRate : Unknown kind of value! com.apple.proapps.videoBitrate : 0 com.apple.proapps.originalFormat : H.264 com.apple.proapps.pulldown : 1 com.apple.proapps.mediaRate : Unknown kind of value! com.apple.proapps.timecodeFormat : 1 com.apple.proapps.numberOfAudioChannels : 2 com.apple.proapps.sampleRate : 48000 com.apple.proapps.bitsPerSample : 0 com.apple.quicktime.creationdate : 2021-01-13T12:07:20-0800 com.apple.proapps.clipFileName : 20210113_A7S30229 com.apple.proapps.clipID : 707974661c000000a16059b200e1d9141d0a782dd3a29fabe9bf6dbb86410bc8 0ad46cc2d564237df1017b2dee0850ca1d310aca061ec31cd978cd1d90f07faa2f55cb00952aa8711 com.apple.proapps.RADSDKVersion : 3.1 com.apple.proapps.cameraID : C8BF5026-0077-3F03-AA08-019E0A1DC444 com.apple.proapps.cameraName : Untitled 1 com.apple.proapps.ingestDate.description : 2021-01-13 19:29:45 -0800 Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High 4:2:2@L5.1 Format settings : CABAC / 2 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames : 2 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 19 s 520 ms Source duration : 19 s 561 ms Source_Duration_LastFrame : 42 ms Bit rate mode : Variable Bit rate : 96.7 Mb/s Maximum bit rate : 100.0 Mb/s Width : 3 840 pixels Height : 2 160 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 23.976 (24000/1001) FPS Color space : YUV Chroma subsampling : 4:2:2 Bit depth : 10 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.486 Stream size : 225 MiB (98%) Source stream size : 225 MiB (98%) Title : Core Media Video Encoded date : UTC 2021-01-14 03:29:45 Tagged date : UTC 2021-01-14 03:29:48 Color range : Full Codec configuration box : avcC Audio ID : 3 Format : PCM Format settings : Big / Signed Codec ID : lpcm Duration : 19 s 520 ms Bit rate mode : Constant Bit rate : 1 536 kb/s Channel(s) : 2 channels Channel layout : L R Sampling rate : 48.0 kHz Bit depth : 16 bits Stream size : 3.57 MiB (2%) Title : Core Media Audio Encoded date : UTC 2021-01-14 03:29:45 Tagged date : UTC 2021-01-14 03:29:48 Other ID : 2 Type : Time code Format : QuickTime TC Duration : 19 s 520 ms Frame rate : 23.976 (24000/1001) FPS Time code of first frame : 00:57:55;04 Time code, striped : Yes Title : Core Media Time Code Encoded date : UTC 2021-01-14 03:29:45 Tagged date : UTC 2021-01-14 03:29:48
This 10-bit h.265/hevc test clip plays fine for me, however:
General Complete name : D:\MISC\test clips Sony A7Siii\Sony A7S III movie main 4k 24p XAVC HS (hevc 422).MP4 Format : XAVC Codec ID : XAVC (XAVC/mp42/iso2/nras) File size : 192 MiB Duration : 16 s 20 ms Overall bit rate : 101 Mb/s Encoded date : UTC 2020-07-20 13:44:32 Tagged date : UTC 2020-07-20 13:44:32 Video ID : 1 Format : HEVC Format/Info : High Efficiency Video Coding Format profile : Format Range@L5@High Codec ID : hvc1 Codec ID/Info : High Efficiency Video Coding Duration : 16 s 16 ms Bit rate : 96.6 Mb/s Width : 3 840 pixels Height : 2 160 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 23.976 (24000/1001) FPS Color space : YUV Chroma subsampling : 4:2:2 Bit depth : 10 bits Bits/(Pixel*Frame) : 0.486 Stream size : 184 MiB (96%) Encoded date : UTC 2020-07-20 13:44:32 Tagged date : UTC 2020-07-20 13:44:32 Color range : Limited Color primaries : BT.709 Transfer characteristics : BT.709 Matrix coefficients : BT.709 Codec configuration box : hvcC Audio ID : 2 Format : PCM Format settings : Big / Signed Codec ID : twos Duration : 16 s 20 ms 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 : 2.93 MiB (2%) Encoded date : UTC 2020-07-20 13:44:32 Tagged date : UTC 2020-07-20 13:44:32 Other Type : meta Duration : 16 s 16 ms
Unfortunately, there's no indication in the metadata what firmware was used to shoot these.
Rocky,
Previewing in Vegas and Playback in a software player are two entirely different things.
There are relatively few systems that are able to preview 10 bit 422 at high bitrates consistently.
Without going into detail, there are a number of features available in Vegas to help you with previewing the Vegas timeline. Start by using the Proxy Render Option.
Got the Sony a7siii and after done recording and import to Vegas pro 10 the footage playback doing so much lagging at 10bit
my pc -i9
gpu-RTX 3080
ram -32
Vegas only uses a tiny amount of your CPU to decode HEVC when playing back on timeline. The odd thing is, Vegas is capable of using much more of your CPU when hardware encoding the same HEVC file. So this seems like a bug that is present in all vegas's. Vegas does not behave like this with AVC, where it's use of your CPU cores to decode to play on timeline, and decode to render to file is the same.
Playback as I've always thought of it, is rendering to preview video window instead of rendering (and encoding) to a file, so I don't know why this happens with HEVC. I'll post this example comparing HEVC playback of 4K 422 10 bit 120fps video between Premiere and Vegas. Vegas makes poor use of CPU, Premiere eats it all up. In this example I do not include AVC playback, but AVC playback is much better at using cores on Vegas and is similar to the same amount of CPU use when encoding
Ah, a teachable moment.
Preview in a nonlinear application is done from a decompressed bitstream. In the case of files, they are decoded to raw bits and stored in memory buffers first. The encoding pipeline is unable to distinguish between your HEVC, your still images, generated titles, media, or effects, except that the 10 bit raw stream is fatter. It is all done in real time by the CPU and/or GPU; that's why it is system-dependent. It is easy to overwhelm the system with math operations, iterations, and temporary data access, thus creating a choppy Preview.
Playback is done directly from the intact compressed files by players like VLC or optical disc drives. It is the nature of the playback decoder to fudge over bitstream errors, missing or corrupted IDRs, and truncated GOPs. That's why Playback is "usually" smooth and visually glitchless.
An analogy is decompressing (inflating) a .zip file to regular files and folders and opening them, as opposed to reading them directly from the zipped (compressed) archive.
Those are the definitions; please make a note of it.
Howard's advice is good for what formats will play back the best from your camera. For the rest, right click on media and create video proxy
General
Complete name : C:\Users\RAYRAY4L4\Desktop\C0091.MP4
Format : XAVC
Codec ID : XAVC (XAVC/mp42/iso2)
File size : 256 MiB
Duration : 3 s 505 ms
Overall bit rate mode : Variable
Overall bit rate : 613 Mb/s
Encoded date : UTC 2020-01-01 05:01:43
Tagged date : UTC 2020-01-01 05:01:43
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High 4:2:2 Intra@L5.2
Format settings, CABAC : No
Format settings, GOP : N=1
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 3 s 504 ms
Bit rate mode : Variable
Bit rate : 572 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 59.940 (60000/1001) FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 1.150
Stream size : 239 MiB (93%)
Encoded date : UTC 2020-01-01 05:01:43
Tagged date : UTC 2020-01-01 05:01:43
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : HLG
Matrix coefficients : BT.2020 non-constant
Metas : 3
Codec configuration box : avcC
Audio
ID : 2
Format : PCM
Format settings : Big / Signed
Codec ID : twos
Duration : 3 s 505 ms
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 : 657 KiB (0%)
Encoded date : UTC 2020-01-01 05:01:43
Tagged date : UTC 2020-01-01 05:01:43
572 Mbps Intra cannot be handled (previewed) or delivered in real time by any consumer system that I know of, I'm sure @john_dennis knows of some mainframes that could make easy work of it. Going forward, set your camera to a sane editing format, for instance 10 bit 4:2:0 75 Mbps.
For your current project, set your Vegas to automatically create Proxies.
Proper timeline playback for previewing requires proper setup and reasonable hardware without bottleneck.
My 4k60p-HDR10project plays ProRes pretty well (due to OBS-Recording it drops to ca. 43fps); AVC/XAVC etc. acceptable depending on the res./fps.
No go is HEVC by high res. and/or fps. This could lead back to my weak GPU.
Proper timeline playback for previewing requires proper setup and reasonable hardware without bottleneck.
No go is HEVC by high res. and/or fps. This could lead back to my weak GPU.
@Yelandkeil To check if your GPU is overloaded if you have a Nvidia, you would check 3D, and Cuda GPU engines. I know it's different with AMD, but I don't know what the engines are called. Once you verify your GPU is not the problem, you'll be able to rule it out as being a bottleneck for HEVC, and it's not your 32 core Ryzen 5950 that's the problem. Vegas is not able to utilize enough CPU cores, it's a software problem.
To test this, take a 4k50/60 AVC and encode to HEVC, instead of using more CPU it uses less, with much higher frame rate drop.
@Former user AMD Ryzen9 5950x 16 cores 😉😁
I finally uploaded the small clip of timeline playback.
For me, the real performance of CPU/GPU is how much power they have been consuming during previewing, or the temperature in good airflow. Their utility rate/percentage is quasi for your reference only - like the swing needle of a seismograph.
VEGAS pro19 is not perfect, it tends on.
And from AMD's statement, if you have a Ryzen5000X CPU, a B550-motherboard and an RX6000 gaphic card you will gain 30% extra power of your machine. As you guys see, all my hardware is fit waiting for that 6000 GPU (6800/XT).
I will report after my wallet gets fully recharged.
Ah, a teachable moment...
I think when Vegas users here use the word "preview" what they want is what VLC or WMP shows them -- a smooth preview they can use to watch clips in real time without stuttering and which they can use to set cut in and out points reliably.
It is frustrating that as of 2022 and v19, Vegas cannot, even in preview-->auto mode, reliably perform as well in this regard as free stand-alone media players, nor many of Vegas' direct competitors (ie, Resolve, PP)
@Former user I usually quote the logical cores because of the oddness of some CPU's like the 9700K with 8 physical cores, and 8 logical cores, instead of 16, not a big deal for gamers, but it will be slower for NLE's
I finally uploaded the small clip of timeline playback.
For me, the real performance of CPU/GPU is how much power they have been consuming during previewing, or the temperature in good airflow. Their utility rate/percentage is quasi for your reference only - like the swing needle of a seismograph.
@Yelandkeil I just played 2 minutes of 4K60 422 HEVC on Vegas, Temperature when up 1 degee and it doesn't even turn the GPU fan on, a new GPU unlikely to help in this HEVC playback situation. Interestingly 1440P60 420 AVC increases GPU temperature by 5 degree's in a minute and triggers the GPU fan
So with those results I think you have your HEVC bottleneck problem backwards. the GPU is doing nothing because the CPU is doing nothing, and there's nothing you can do to fix that.
It is frustrating that as of 2022 and v19, Vegas cannot, even in preview-->auto mode, reliably perform as well in this regard as free stand-alone media players, nor many of Vegas' direct competitors (ie, Resolve, PP)
It may be a bandwidth problem as @Musicvid said. I will show you an identical file format and resolution playing fine on Vegas except it is 50fps and 478Mb/s, somewhere between 478Mb/s and 572Mb/s either Vegas runs out of internal bandwidth or your CPU maxes out. This assumes you're using fast SSD's.
Because the encoder I use can't create Intra format AVC at 4K I chose normal 422 AVC, made encodes at 400,600,800,1000Mb/s . You can see the CPU use going up, eventually I will run out of CPU. I did this test with Resolve because Vegas could not run the test predictably without manual intervention
See if 4K50fps 422 Intra AVC plays fine, that might help you work out the problem.
I suspect @Musicvid is on to something with his definitions. I expect pixel-perfect "preview" when I'm paused on any given frame in the "best-full" mode. But for playback, what I really care about is temporal accuracy--smooth accurate framerate. Maybe this is something that isn't occurring to Vegas developers?
It clearly occurs to the developers as they have made big strides with so4compound and GPU decoding, adding support for the latest Intel processors that can accelerate 10-bit 4:2:2, GPU acceleration for ACES, etc.
It's just that achieving this goal doesn't appear to be trivial so progress is piecemeal.
VP 19 redid prerenders (shift-m) which is an option for tough transitions and the like and a proxy workflow is always available as well.
This discussion reminds me of a famous folk tale, The Blind Men and the Elephant.
One can preview on-the-fly (system dependent), selective RAM or file prerender, create proxies, or full quality intermediates. That's about it; Sonic Foundry decided against background preview rendering, and it remains so to this day.
Do you know that this exact discussion took place fully a quarter-century ago, when no one's 120 Mhz single core could handle software mpeg-2 decoding? (Yes, I tested the now-infamous Tsunami beta 12 codec).
But take heart: there will be consumer systems that can preview 600 Mbps Intraframe smoothly in real time. Of course, some claim "theirs" already will. Here's one:
A video player works executing the signal, structurewise, either
with GPU-decoding
or with CPU-computing or mixed anyhow.
A video editor works rebuilding the signal with or without GPU-acceleration/decoding, framewise.
It's often impossible to view the editing fluently one by one on fly, especially when frames in different size, thickness, weight...
A video editor works rebuilding the signal with or without GPU-acceleration/decoding, framewise.
It's often impossible to view the editing fluently one by one on fly, especially when frames in different size, thickness, weight...
@Yelandkeil With 4K HEVC where CPU use is very low, Vegas isn't building any frames except the ones you can see. Try a 4K high frame rate 422 AVC using BEST/FULL preview and compare CPU use even when it's dropping frames In the AVC example you can tell by the high CPU use that frames are being built even if they are not being displayed, but HEVC Vegas does not have enough access to CPU to be able to build the frames.
Playback your HEVC, look at cpu use, now hardware render and Vegas is now able to harness your CPU cores like it should. AVC doesn't behave like that.
But take heart: there will be consumer systems that can preview 600 Mbps interframe smoothly in real time. Of course, some claim "theirs" already will. Here's one:
@Musicvid I think it must work on other NLE's and probably even Vegas if you have enough CPU, because that bit rate of approx 9.55Mb/s per frame is the sony standard for that intraframe codec. If nobody can playback that format at 60fps when the whole point of intraframe is easy editing not needing proxies, they would have really goofed.
@Rocky-Say do you have a short 10second clip you could upload to putfile, google drive etc so others can try it?
Also what is your CPU use when playing that file?
This discussion reminds me of a famous folk tale, The Blind Men and the Elephant.
One can preview on-the-fly (system dependent), selective RAM or file prerender, create proxies, or full quality intermediates. That's about it; Sonic Foundry decided against background preview rendering, and it remains so to this day.
Do you know that this exact discussion took place fully a quarter-century ago, when no one's 120 Mhz single core could handle software mpeg-2 decoding? (Yes, I tested the now-infamous Tsunami beta 12 codec).
But take heart: there will be consumer systems that can preview 600 Mbps interframe smoothly in real time. Of course, some claim "theirs" already will. Here's one:
You're missing the point here. Vegas users are noticing, *on their existing systems*, that free players like VLC seem to effortlessly provide stutter-free playback of files (like 100Mbps GoPro 5k HEVC) that give VP fits in any preview mode (auto, draft, you name it). They are wondering why that is so. They are obviously not asking for something unreasonable; maybe you say Vegas has a more complicated job than VLC does. I say yes, and so does Resolve--and Resolve is free, too.
VLC is open source. I wonder what would happen if Vegas asked their community for help? (of course, a ridiculous question)
You're missing the point here. Vegas users are noticing, *on their existing systems*, that free players like VLC seem to effortlessly provide stutter-free playback of files (like 100Mbps GoPro 5k HEVC) that give VP fits in any preview mode (auto, draft, you name it). They are wondering why that is so. They are obviously not asking for something unreasonable; maybe you say Vegas has a more complicated job than VLC does. I say yes, and so does Resolve--and Resolve is free, too.
There's something wrong with HEVC playback on VegasPro, nobody can dispute that, but you making comparisons with media players is not correct, NLE require more processing, so higher hardware requirements. You are making a comparison between Resolve and media players, as if their ability to playback is the same, and Vegas is the black sheep.
This is an extreme example. 8K60 AV1 playback on Resolve on an 8K timeline compared with playback on a Media Player. Plays effortlessly on media player using very little resources, but my GPU is too weak to playback on Resolve. This is to be expected, but that's not the Vegas HEVC problem.