They should fix the so4 reader, but not simplify to switch it on and off.

+1

+2

Only reason I requested a toggle button is because I know it would be simpler do create rather than rebuild the whole reader code itself. I'd like to think of it as dressing up a wound until they can determine the underlying problem and correct it.

If someone wants to go through the work of finding where they keep those prefs and decoding the file, hopefully it's a common format, it wouldn't take much work to write a program to toggle that value

Our focus is on making so4compoungplug both fast and stable - most of the newer features are developed in it, including the coming MXF hardware acceleration, so it would be more useful to help track down those issues and fix them, instead of offering a toggle button to go back to the older codebase. @ScrapyardFilms: the workflow you describe (import 10-bit via so4, render to 8-bit, and then edit) is painful - we would rather you edit in 10-bit natively instead.

I am aware of the following issues with so4compoundplug, compared to compoundplug - all performance related - and work to resolve them is in progress:

1. Slower startup times for large projects

2. Drop in frame rate going across transition events

3. Blacklisting of files from certain cameras.

As so4compoundplug uses GPU acceleration for decoding, there may be issues with decoding certain files, but we need help pinpointing those; we do not have much data in the PEFs we collect which point to that. Could you upload sample projects which demonstrate the instability clearly?

Understandable and I appreciate the answer. I'll try and see if I can get a sample project together. But in the meantime, what type of reports best help you pinpoint the problems? Would Windows Event Viewer reports help? Because sometimes when it crashes, it doesn't give me a "VEGAS Error Report" prompt. I know you'd want to know exact information like system specs, media specs, and what exactly I was doing to when the crash happened.

Next time it happens, I'll provide highly detailed information and the media files I used.

Will do. And would I post all this here in the forums or email the information?

Might be helpful to post here, especially when sharing full projects, so that users on a wider variety of hardware configs can download it and try to reproduce the issue.

Smart. I'll do that then. Thanks!

Our focus is on making so4compoungplug both fast and stable - most of the newer features are developed in it, including the coming MXF hardware acceleration,

Waaau. In Vegas 18, there will be GPU support for MXF.

I no longer need to use a proxy.

I updated to the latest VP build, 452, and started experiencing lots of crashes. I couldn't edit no more than 10 minutes, where before with the previous build, I could.

I looked to see if the So4 was still set at FALSE, I see now that it was reset (with the update build) back to TRUE.

Changing it to FALSE and I am back to editing.

I did send the project I was working on (6GB) to @VEGASHeman

I don't know if this problem is specific to my hardware (see sig), but now, I am editing and the stress is gone for now.

@VEGASHeman I reported the so4 compound reader issue with decoding mp4 files with 5.1 audio to Magix. Then I was replied that it will not be fixed. Could you elaborate please? I mean what types of the reader issues are you planing to fix? Is it related to crashes only?

@fifonik: I am not aware of this particular issue, but will look into it and get back to you as soon as possible.

Our focus is on making so4compoungplug both fast and stable - most of the newer features are developed in it, including the coming MXF hardware acceleration,

Waaau. In Vegas 18, there will be GPU support for MXF.

I no longer need to use a proxy.

This is Resolve using GPU acceleration. It makes a huge difference. Note also it does use the actual GPU, rather than hardware decoding chip. so with VP18 people with the really expensive cards are going to start getting their money's worth, as the video acceleration has to compete with VFX, scaling, levels etc.

2160P50fps plays back at 1.5fps in preview quality on Vegas17, while Resolve plays at full 50fps

@VEGASHeman here is a video that seems to make the So4 Compound Plugin go bonkers with memory when I try to play it in Vegas Pro 17 (b452). I don't even need to loop it, the memory shoots up on the first play after I have placed it on the timeline. It is a 6 second 4K 60fps clip I took on my iPhone 8 (iOS 13.5.1) and transferred to my PC in original HEVC format. I reset Vegas Pro 17 to default settings, and then changed the following preferences: unticked File I/O > "Enable legacy HEVC decoding via Intel QSV", and changed File I/O > "Hardware decoder to use" to NVIDIA NVDEC. GPU acceleration is set to NVIDIA GTX 1660 Super (Studio driver 442.92). System is i7-4790, 16GB RAM. When I view Properties on the media clip it shows it is using so4compoundplug.dll.

https://www.dropbox.com/s/wv4zuv3avs0ec8e/IMG_5591.MOV?dl=0

If I turn GPU acceleration off, or set it to Intel Graphics 4600, or tick File I/O > "Enable legacy HEVC decoding via Intel QSV", or set File I/O > "Hardware decoder to use" to Intel QSV, or disable the So4 plugin, there is no problem, the memory is stable.

Ken.

I'm not seeing that with your file on my desktop from signature, look

These are my settings for File I/O in preference

as you can see on the screengrab the Intel GPU is working to decode well

@fifonik: I have acknowledged the surround problem in your original thread, and put in on our list to fix.

@KenB: Thank you for the clip, and the detailed info - it seems the problem is specific to using so4compoundplug / NVDEC. I tried it briefly with a 1660, so4 ON, NVDEC, but for whatever reason, my machine was using the Intel QSV decoder (we will automatically switch to the Intel QSV decoder for certain scenarios, as both the NVIDIA and AMD hardware decoders can safely handle only a certain subset of files, though those are the most popular ones). I need to investigate this some more to figure out what is going on.

@j-v: Thank you for the test and report. Can you post the bold information from the the Media Properties dialog for the video event, by pressing the SHIFT key when clicking on the General tab? This will add some more debug entries, shown below, which indicates the actual decoder used, regardless of what was requested via the preferences: @KenB: could you also post this information?

General
  Name: IMG_5591.MOV
  Folder: M:\Customer Issues\VP18_BetaFeedback\NVDEC_Issues_KenB
  Type: HEVC
  Size: 43.56 MB (44,602,081 bytes)
  Created: Friday, June 5, 2020, 12:03:32 PM
  Modified: Friday, June 5, 2020, 12:03:32 PM
  Accessed: Friday, June 5, 2020, 12:03:32 PM
  Attributes: Archive

File (debug)
  Total datarate: 6,690,312 (bytes/sec)   =53,522 Kbps (calc.)
  Text datarate: not set, hr=0x00000001 (S_FALSE)
  Compatibility: 0000000000 

Streams
  Video: 00:00:06.667, 60.000 fps progressive, 3840x2160x32, HEVC
  Audio: 00:00:06.667, 44,100 Hz, Mono, AAC

Streams (debug)
  Raw stream: 0
  Video stream: 0
  Codec name: 'HEVC'
  Codec name: 'Intel QSV HEVC Decoder'
  Codec fourcc: 0x68766331 [1cvh]
  Data rate: 53,415,840 (bytes/sec)   =427,327 Kbps (calc.)
  Text data rate: '53415 kb/s (max: 0 kb/s)'  

Raw stream: 1
  Audio stream: 0
  Codec name: 'AAC'
  Codec fourcc: 0000000000 error
  Data rate: 92,334 (bytes/sec)   =739 Kbps (calc.)
  Text data rate: '11541 kb/s'

Summary
  [TCFM]: 7

ACID information
  ACID chunk: no
  Stretch chunk: no
  Stretch list: no
  Stretch info2: no
  Beat markers: no
  Detected beats: no

Other metadata
  Regions/markers: no
  Command markers: no
  Playlist: no

Media manager
  Media tags: no

Plug-In
  Name: so4compoundplug.dll
  Folder: C:\Program Files\VEGAS\VEGAS Pro 17.0\FileIO Plug-Ins\so4compoundplug
  Format: AVC
  Version: Version 1.0 (Build 8532)
  Company: MAGIX Computer Products Intl. Co.

@VEGASHeman

we would rather you edit in 10-bit natively instead.

Assuming your source is 10 bit and your output is 8 bit, grading in 32 bit float project space apparently introduces spurious monochrome quantization noise in the bottom ~4% of values, that does not get clipped out of the integer output range.

No such collateral exists when the grading and rendering is done in 8 bit project space. This is mentioned and documented in several tests of mine, but zeroed in on in this article, with an example of manual correction. This affects all ten bit source, not just the GH5 used for illustration.

https://www.vegascreativesoftware.info/us/forum/hdr-to-8-bit-vegas-grading-tip-reclaiming-the-shadows--117747/

@j-v: Thank you for the test and report. Can you post the bold information from the the Media Properties dialog for the video event, by pressing the SHIFT key when clicking on the General tab? This will add some more debug entries, shown below, which indicates the actual decoder used, regardless of what was requested via the preferences:

Vegas Heman, I don't see bold information when I push the General Tab of properties of the videofile on the timeline.
I show you 2 screenshots with half parts of that General Tab with the same info you published above I believe

@j-v: I had marked the text of interest for this exercise in bold - it is not output as such in that dialog (the rest of the information is not needed for this exercise). But your information shows that the Intel HEVC decoder is used on your machine too, inspite of the preferences requesting for NVDEC. So at least we have consistent behavior across our two machines - I will post my findings about why this may be occurring later.