"Changing your project framerate to 23.976 fps will actually force Vegas to compute a framerate conversion unless your original media file was 23.976 fps as well"

Thanks for the answer, but were the above true, the playback at the original project setting of 25fps would be faster, than after changing it to 23,976fps. The opposite is true here - how can you explain this?

Whatever the answer to the above question is, I'm still curious whether or not a user can influence the proxies' format...

Piotr

I can only state what Satevis wrote is true. We had a long discussion with many researches about it at another place. The proxys (used within the given workflow) always get their frame rate information from the source files. But you may never try to use the .sfvp0 files.

It's the .sfvp0 files where Mediainfo reports the settings (720p, 23,976fps).

I went one step further and - for experiment sake - changed my original 1080/25p project settings down to 720/23.976p, and the Preview/Full (the highest setting using the proxies by design) playback is even faster and rock solid at the full 23,976 fps. With original settings, and for the same 11 camera MC track, it's some 17-18 fps at the max, and dropping quite often. How would you account for that?

Even if there are some "technical reasons" for the container to report fps different than the original (while the actual content keeps the original frame speed), it certainly negates the very purpose of using proxies - i.e. enabling maximum playback speed possible with that high camera number in MC track...

Piotr

When playing back video at 720p and 23.976 fps instead of at 1080p and 25 fps, you reduce the number of pixels to be computed every second by 60%. This by itself will increase playback performance regardless of whether proxies are used.

Proxies are meant to decrease the time it takes to decode a source frame. They won't speed up any later processing such as effects, transitions or transformations (changing the project settings or the preview resolution will). Also, you won't see much gain for source material that is easy to read and decode as it is.

Thanks, but all you said is obvious, and doesn't address my doubts, unfortunately :(

Thanks for trying, though

Piotr

PS. Just one more interesting information: when playing back the proxy files in the original project settings (1080/25p), it takes a lot of CPU resources to "adapt" to their resolution and framerate; the result of this overhead is:

- CPU: up to 90%,
- GPU - only up to 30%.
- Maximum speed with 11-camera MC track at Preview/Half: 17 fps.

On the other hand - when project settings match those of the proxy files:

- CPU: 50% load
- GPU: up to 75%
- fps: full and solid 23.967 at Preview/Full

So - while of course the compression scheme change alone (from AVCHD to the more Vegas-friendly XDCAM EX) does increase the achievable playback speed, with the implemented resolution/fps change this gain is wasted considerably, IMHO.

This is why I think the proxy video format should be user-definable...

Just to be sure: In your tests you do not use the .sfvp0 files in the timeline, do you?

No, of course not - I leave proxy management to Vegas, so they are only used with the preview monitor resolutions of Preview/Full and lower.

Piotr

Proxies should always match the source frame rate and timecode.
Editing using proxies is very common in this industry, it enables editing without even needing the camera original files. The reason why the proxies must match the original frame rate and timecode should be entirely obvious.


Bob.

This is exactly what I mean, Bob - and unless SCS developers do not recognize that, hard-coded 25->24 fps conversion must be a bug (they didn't think about the non-US framerates when introducing this functionality).

Piotr

"Proxies should always match the source frame rate and timecode."

And actually it does in VP12.

Piotr, I can't repro what you see. Here the preview behaves as expected. It isn't any faster when switching the project setting to 23,976 for 25p timeline events.

We must be using different VP12s, Marco :)

Piotr

Even within region60 frame rates it's still just plain wrong.
If you edit a proxy that from a 29.97>23.976 conversion frames are missing, how does things such as EDLs make any sense?

Probably the reason SCS chose this fudge is because Vegas permits mixed frame rates on the one timeline. Once you permit mixed frame rates any form of project interchange is impossible to do reliably.

Vegas does actually do real proxy editing but only with XDCAM HD content where the camera generates the proxies. It's either that or roll it yourself by creating proxies yourself as some have been doing for years. SCS seem to have rolled out thie feature in V12 as a substitute for these workflows and it is not.

Bob.

There are no frames missing when using proxys. Not even if you have 100 fps footage. The proxy is treated just like an image sequence and takes it's frame rate information from the source files.

Marco,

I do appreciate your inside knowledge (have seen your German Vegas webpage), but the hard facts are:

- the proxy files are reported as XDCAM EX 720p, 23,976 fps by all players, Mediainfo, and Vegas itself
- this you would need to take my word for, but all the performance hit details I described earlier are true and accurate here.

Therefore, please enlighten us why would SCS choose such a complicated way of proxy creation & management? Why not simply generate clips of "easier" compression and resolution (even SD would suffice for cutting), but the same framerate?!!

Having many times gone through the nightmare of perfectly synchronizing my music videos, I just can't imagine relying on the current proxy mechanism - cut and synchronize using 24 fps clips within a 25 fps project, then render out to 25 fps deliverable... No thanks! I prefer rendering my own intermediates (with carefully and optimally chosen format) for cutting MC track!

Piotr

As for how proxies are handled: Understanding this does take some technical knowledge, agreed, but you will also agree that this is no concern for the ordinary user, as proxies work as expected when used as intended. Problems arise only when users go ahead and take apart Vegas' internals, draw the wrong conclusions, and accuse SCS of doing it all wrong. Encrypting these files just to hide them from view would solve the problem, but then again, adding another processing step just to account for the attempt take internal Vegas files and use them as standalone videos seems rather pointless.

Consider this example: A user notices Vegas creates .sfk files for most media and by experimentation concludes that these are the audio peak caches. He goes ahead and opens them in Photoshop as a raw file. After a lot of fiddling around, he gets something that resembles a waveform, but is still mangled beyond recognition. He gives up on the attempt and files a bug request ".sfk files cannot be opened in Photoshop". However, .sfk files are internal files to cache audio peaks. What would be the point of storing them as image files which would complicate the whole process of saving and loading them? If you want an image of your waveform, take a screenshot. It's similar with proxy files. So they're no valid video files, okay, but what's the big deal? If you want a video of your media, render it. You even get a whole lot of different render options. Dragging a proxy file onto media player, Media Info, or a Vegas timeline and complaining that it doesn't do what you thought it would is not too different from opening an audio peak cache in Photoshop.

About your performance gain: I don't see that either: Here, using a 1080p25 source with proxies, playing at 1080p25 Preview/Half uses 372 milliseconds of CPU time per second played as opposed to 436 ms/s at 720p25 Preview/Full. And as can be expected, CPU usage decreases when you lower the playback frame rate:

1080, 25.000 fps, Half: 372 ms/s (2.9 ns/pixel)
720, 25.000 fps, Full: 436 ms/s (1.9 ns/pixel)
720, 23.976 fps, Full: 434 ms/s (2.0 ns/pixel)
720, 23.000 fps, Full: 401 ms/s (1.9 ns/pixel)
720, 15.000 fps, Full: 333 ms/s (2.4 ns/pixel)

Without proxies:
1080, 25.000 fps, Half: 996 ms/s (7.7 ns/pixel)

Note that there is no significant advantage of using 23.976 fps over the original frame rate of 25 fps.

"There are no frames missing when using proxys. Not even if you have 100 fps footage"

In this case Vegas will interpolate frames. How one can make frame accurate editing decisions from blurred interpolated frames escapes me. What we're then talking about isn't editing using proxies, I don't know what it would be called, certainly not anything flattering by a professional editor.


"The proxy is treated just like an image sequence and takes it's frame rate information from the source files. "

Then the system is fundmentally broken. The frame rates should be taken from the proxy files, one should not even need the source files to edit proxies, in fact most proxy editing is done by people who don't have and never will have the source files. We should also be able to do quick and dirty renders directly from the proxy files. The majority of modern digital film cameras already provide low res, easy to edit proxies for this purpose. I'd assumed this was what this feature was in V12, sounded like it might even be useful. Instead I now find this half thought out useless mess.

Bob.

The only thing I can agree with is that probably the performance hit I'm talking about (potential syncing problems aside) may only be noticeable with a rather demanding project, like one of my multicamera ones (with camera number as high as 10-12). But with my real-life projects, the performance penalty is real and substantial.

The other aspects (practically disqualifying this proxy mechanism from use in my field at least) have been pointed out by Bob clearly enough.

Piotr

"In this case Vegas will interpolate frames."

It does neither drop frames nor does it interpolate or blend. Everything's fine when using the given proxy workflow.

"Understanding this does take some technical knowledge, agreed, but you will also agree that this is no concern for the ordinary user, as proxies work as expected when used as intended."

It is very much of concern to the ordinary user. No, they apparently don't work as anyone with any experience in the industry would take them to work. The word "proxy" has a well defined meaning in the industry, one that goes back many years.

"Encrypting these files just to hide them from view would solve the problem, but then again, adding another processing step just to account for the attempt take internal Vegas files and use them as standalone videos seems rather pointless"

Proxies have never been "internal" files on any editing system.

Vegas has had proxy editing via scripts for quite some time, that process has worked correctly, according to the way anyone in the industry would expect it to work, typically DV25 copies of the camera original.

"So they're no valid video files, okay, but what's the big deal?"

By defintion, one that Sony, the divison that makes cameras, that does seem to have a clue what it's doing, has used for years, proxies as viewable, match source frame rate and timecode. They're not internal, hidden files of dubious worth, they're real, usable video files.


Perhaps where the confusion is coming from is other NLEs such as Ppro seem to use internal proxies, they never mention them, never talk about them. As far as I can see though they most definately match sequence or project frame rate.

If this "proxy" thing in V12 is some attempt to emulate what other NLEs are doing internally, they've got it badly wrong. To do it correctly they need to go back to the drawing board and redesign Vegas from the ground to get it right. Perhaps what they've tried to do is just fudge it without rethinking the Vegas of old.

Bob.

"

It has to do something.
If the source file is 100fps and another file is 23.976 something has to give.

Perhaps what is not being explained is that the proxy does in fact contain 100 frames per second but it is incorrectly flagged as 23.976???

Bob.

I'm in the process of creating proxies for an editing session I will do on a notebook.

I see that cpu load on this 8 core system is under 50% (is it using CUDA ???)

Proxy for a gh-1 file is almost 1:1 in size.

Proxy for a tm900 file is 150% of the original size....

It has to do something.

It looks up frames. When in need of frame 100 of the source, it decodes frame 100 of the proxy instead. It's a frame-by-frame replacement, so there's no way how proxy and source might get out of sync, regardless of the source or project frame rate.

If the source file is 100fps and another file is 23.976 something has to give.

If you look at it in Vegas, it will show as 100 fps and you can single-step through it to confirm that the proxy contains the same 100 frames per second as the original. I think you assume that the "Create video proxy" option creates a video file that can be played, analyzed and used outside of Vegas. That is not the case. If you were to feed the .sfvp0 file to any video application, or even Vegas itself, you would end up with something that does contain your frames, but at an incorrect frame rate and length.

In Vegas' own terms, a "proxy" is nothing else than a way to speed up the decoding of complex video sources during editing while retaining the option to switch back to the original source for rendering. It is true that the proxy generation process fails miserably when used as a generic video conversion tool, but it never intended or claimed to be one.

If you require a proxy that can be used independently of Vegas or the original video source, you would have to, as before, use "Render as", one of the proxy scripts that can automate the process, or some external video conversion tool.