I've read this thread (twice).
I'm editing PAL frame rate (25fps AVCHD - yes I know it's 50i)
Using subclips and clips.

And I'm currently editing a music vid.

Megabit is right. The proxies are doing something odd on the timeline.

If you consider that a single frame out when editing tightly to beats is noticeable.

In my case I can see a frozen frame at the end of every clip. Every single clip, no matter how short.

However, when rendered it looks good.

So the problem is yet again that an advertised feature, and the one that I upgraded from the abortion that was 11 for, doesn't quite work.

So everyone who is saying Megabit is wrong are just not listening. I'm not sure if the technical arguments are valid, on either side, and I don't care. It's not working as one would expect (on 25fps at least).

There is no difference at all when working inside the proxy workflow. You would only have this difference when using the .sfvp0 files which you actually should never touch.

Could someone offer a demo project where these differences appear without touching the .sfvp0 files?

Sorry Marco, no time or upload capability for a project like this.

What I've just found out however is that the resolution and framerate of the proxy files is inconsistent - within the same project, all original clips 1080/25p, most proxies created are 720/23,976p but SOME are 1080/25p... Only the compression is always the same (XDCAM EX).

Now that's interesting - can you explain this?

Piotr

I can't neither explain nor repro. All my proxys ever matched exactly the source frame rate and were 1280x720.

Oh, so now you're saying the proxy's frame rate SHOULD match the original, after all!

But all this thread has been about it NOT matching the original, and you have been defending some "black magic" (or "technical reasons", as you put it) behind that fact...

Piotr

Report by Mediainfo

Original file: 23.7 Mbps, 1920*1080, 50fps, AVC

Proxy file: 19.5 Mbps, 1280*720, 23.976fps, MPEG Video... XDCAM EX 35

Original file size: 14.484
Proxy file size: 23.773

Edit: project is HDV 720-25p (1280x720; 25.00 fps)

Edit 2: during proxy creation the clip is not usable on the timeline, missing or garbled frames.

I'd always said proxys does match the source frame rate. But I suspect you often refer to the .sfvp0 files what I NEVER do. All the misunderstanding usually comes from focusing on the .sfvp0 instead of just leaving them untouched.

To me the "proxy" is NOT the .sfvp0 file but the event used in the Vegas Pro timeline when having switched the preview to any value below good.

This again is misleading because you use the .sfvp0 files which doesn't work at all. The .sfvp0 files are useless if you can't use the source file information in them. It is impossible to get useful information out of the soloed .sfvp0 files (regarding length and frame rate).

You might test this if you want:

- Download this zipped project file "proxy", unzipp and start the project.

- Set the preview to "Best/Full" so the original source file is used.

- Step through the timeline frame by frame and you can count the frames from 1 to 100.

- Set the preview to "Preview/Half".

- Again step through the timeline frame by frame and count the frames from 1 to 100. You will see there is no frame dropped nor will any frames be interpolated or blended.

As in this test project a 100 fps source file is used and the proxys' already created I can't see any problem (regardingn frame rate/length) using the Vegas Pro given proxy workflow.
All you need to do to keep it working fine is resist to touch the .sfvp0 files.

I'm probably experiencing another kind of "problem"...

proxy generated for TM900 camera seems to be really "pixelated"... cpu load is very low and filters applied are run without problems with really fluid playback.

but video looks pixelated... (there are no FX nor rotation....)

Gh-1 video, rotated and cropped looks low res but not pixelated

But all this thread has been about it NOT matching the original, and you have been defending some "black magic" (or "technical reasons", as you put it) behind that fact...

I think a short summary might be in order. ;)

You say Media Info reports 23.976 fps on the .sfvp0 files, media players play it at 23.976 fps and dragging it into a Vegas timeline, Vegas reports 23.976 fps. That is correct. And quite irrelevant. Now, why is that?

Vegas does not discard your original file. Even when there's a proxy, most operations are still performed on the original file. Framerate, length, timecode, dimensions... all these things are read from the original. And very right, too, as it would be pretty inconvenient if your proxy had a different frame rate than your source or if you were to specify some pixel measurement based on a 1280x720 proxy frame which would look completely different once you switch back to your 1920x1080 master. The one big difference when using proxies is that whenever actual pixels are needed, these aren't read from the original file but from the proxy instead (and scaled to the proper size).

When creating a proxy, Vegas will read every frame of the source and store it in the proxy file, so the proxy file will contain the exact same number of frames, just at a different resolution and compression scheme. When you put your play cursor to 00:00:01,00 in a 100 fps project, Vegas will calculate that it requires frame 100 of the original file and decide to read frame 100 of the proxy instead. Except for resolution and compression, this will be an exact replica of the original frame 100. Note that the framerate you see in Media Info is never read nor used in any of these processes. You could set it to minus pi and Vegas wouldn't care.

Now, for these black magic technical reasons: Why is it 23.976 and not minus pi?

For one thing, you noted that these files are essentially XDCAM files, so Vegas uses its XDCAM encoder and decoder to handle them. This decoder is not going to be amused seeing a file with a framerate of minus pi. In fact, there are quite a few frame rates in this world that are not legal XDCAM frame rates, so always setting it to the original frame rate isn't an option either. 23.976 is the lowest legal XDCAM frame rate and since the bitrate is given in seconds, this will give the highest picture quality for a given bitrate. In fact, this means that picture quality is independent of your frame rate, as it will assign bits per frame rather than bits per second.

The problem then is that SCS have taken a word that has a specific meaning in the industry and used it to mean something else.

I can't comment on industry practice as a whole, but from my experience, it's quite common to take "proxy" files to mean stand-ins for originals that are simpler a way (smaller and/or easier to decode/process). For example, raw cameras might record a separate, compressed stream for easier editing and playback, which is quite in line with this definition. What Vegas does, seems very similar to me, the most notable difference being that it handles proxies entirely "behind the scenes" and does not provide a separate video file.

So everyone who is saying Megabit is wrong are just not listening.

Oh, I'm listening. And I'm not saying he's wrong in saying that he perceives an undesirable effect on his system. I'm saying that his assumptions on the technical causes and effects are incorrect and that I recommend discarding that theory and looking into other possible causes. As for your own problem, I can't comment on that without knowing your project. I can tell you it's not a general problem with proxies, but of course there are other possible causes. Maybe your project frame rate is not 25 fps, or you've disabled frame quantization.

proxy generated for TM900 camera seems to be really "pixelated"...

I'm afraid I can't comment on that either. Proxies will certainly not be as sharp as your original 1080p. I'm not sure if that is your issue.

And since you keep mentioning file sizes: Depending on your source format, your proxies will likely be larger than the source, as they favor decoding speed over file size. The effect will be more pronounced for low-bitrate and/or high-framerate sources, as proxies use a constant bitrate per frame, not per second.

"For one thing, you noted that these files are essentially XDCAM files, so Vegas uses its XDCAM encoder and decoder to handle them. This decoder is not going to be amused seeing a file with a framerate of minus pi. In fact, there are quite a few frame rates in this world that are not legal XDCAM frame rates, so always setting it to the original frame rate isn't an option either. 23.976 is the lowest legal XDCAM frame rate and since the bitrate is given in seconds, this will give the highest picture quality for a given bitrate. In fact, this means that picture quality is independent of your frame rate, as it will assign bits per frame rather than bits per second."

XDCAM supports frame rates from seconds per frame to as many fps as you want. XDCAM can do 27fps, it can probably even handle variable frame rates, the frame rate is stored as essence markers within the video stream.


"I can't comment on industry practice as a whole, but from my experience, it's quite common to take "proxy" files to mean stand-ins for originals that are simpler a way (smaller and/or easier to decode/process). For example, raw cameras might record a separate, compressed stream for easier editing and playback, which is quite in line with this definition. What Vegas does, seems very similar to me, the most notable difference being that it handles proxies entirely "behind the scenes" and does not provide a separate video file."

Yes, and the proxies can be edited offline, the editor doesn't need the camera original to complete the task. In fact (heaven forbid) people have decided the proxies were "good enough" and never used the camera original RAW files.

There's absolutely no need for all this "behind the scenes" messing around that SCS have inflicted us with.

"This again is misleading because you use the .sfvp0 files which doesn't work at all."

The only misleading thing is SCS calling this "proxy editing".

"The .sfvp0 files are useless if you can't use the source file information in them. It is impossible to get useful information out of the soloed .sfvp0 files (regarding length and frame rate)."

Then this feature is a useless waste of SCS's time and our money.
There's absolutely no need for them to be using .sfvp0 files for proxy editing.
For years Vegas has supported proxy editing and without scripts etc.

That this faux proxy editing thing requires the camera original files to work is inexplicable. Today's cameras can generate camera original files of terabytes in a few minutes. That such massive files need to be kept online is plain daft. That Vegas will be having to read these massive files negates the entire intent of using proxies.

Bob.

This description almost sounds to me as if the given proxy workflow would not work. I think it works pretty fine.

It is meant to be able to playback and edit video formats which either needs extremely high decoding performance or extremely high data rates even on lower powered PCs within Vegas Pro smoothly. And this works almost perfectly, e.g. I can edit RED video, 12 bit DPX sequences, 4k 60p AVC footage or whatever else even on my older laptops with smooth playback and without any glitches as supposed above.

Granted that the nature of this new feature has been troubled by a lack of info, that is why, I brought the local Forum Admin, Paddy, in to this discussion the day VP12Pro was released.

I don't think getting hung-up over the term defined as proxy editing is of any real consequence. From day one I have been calling it "auto proxy" and always drawing clear reference of its difference to controlled proxy in plug-ins like Vasst Gearshift.

But I do think the discussion on this thread has been very helpful and would like to think everyone here has made really good points.

XDCAM can do 27fps

Like AVCHD uses AVC, XDCAM uses the MPEG-2 video compression scheme. AVC and MPEG-2 support a wide variety of different video formats, but both AVCHD and XDCAM include specifications for audio, container, frame sizes, frame rates, and bit rates that restrict the allowable properties of the material. So while you can create a valid MPEG-2 video at 27 fps, this is not a valid XDCAM frame rate. For 720p, XDCAM supports 23.976, 25, 29.97, 50, and 59.95 frames per second.

There's absolutely no need for all this "behind the scenes" messing around that SCS have inflicted us with.

You may be misunderstanding the purpose of these proxies. As Marco has pointed out, they are meant as a temporary replacement to speed up editing, not as digital intermediates that will replace the original footage altogether. If you want those, this feature is not for you, agreed.

VideoITguy said:
"From day one I have been calling it "auto proxy" and always drawing clear reference of its difference to controlled proxy in plug-ins like Vasst Gearshift."

My understanding was that this new feature was exactly the same as Gearhsift except it was natively coded into Vegas for convenience and speed. In fact one can do proxy editing by hand, you don't even need Gearshit. Just render all your source footage to a suitable codec in it's own folder and by a process of renaming folders you can trick Vegas into either using your proxies or source footage.
The neat trick is you can take your source footage "offline" and edit away in ignorant bliss of what the source footage is.

Satevis said:
"Like AVCHD uses AVC, XDCAM uses the MPEG-2 video compression scheme. AVC and MPEG-2 support a wide variety of different video formats, but both AVCHD and XDCAM include specifications for audio, container, frame sizes, frame rates, and bit rates that restrict the allowable properties of the material. So while you can create a valid MPEG-2 video at 27 fps, this is not a valid XDCAM frame rate."

Not exactly and I do own an XDCAM EX camera.
XDCAM EX will record from I think 1 frame every 5 seconds to 60 fps, the camera quite literally takes frames at that rate, sends them off to the mpeg-2 encoder and writes them into a container. The container specifies the playback rate which is set by the user. So I can tell the camera to take and record record 27 frames per second but flag it to be played back at 25 fps. End result would be a very slight slo motion. I've never bothered to check this but others have reported that with Slow & Quick motion that yes, the bitrate can go up to around 70 Mbps compared to the normal 30Mbps.

Of course the specified playback is simply a piece of data that has nothing directly to do with the encoded data. The encoded data is simply frames of video and the playback fps specifies at what frame rate the frames, once decoded, should be played back at. From what's been discovered so far this is exactly the trick that Vegas is using in this proxy editing process. It can actually encoded 100fps, flags the file as 23.98 fps and effectively ignores that value and instead take the playback frame rate from the source media.

All of this could be simply avoided by specifying the playback fps the same as the source, Gone is the need to reference the source to determine playback rate. The resultant file might not exactly conform to the definition of XDCAM EX but so what, nothing should blow up and no one surely is going to try to load these files back into a XDCAM camera.

"As Marco has pointed out, they are meant as a temporary replacement to speed up editing, not as digital intermediates that will replace the original footage altogether."

A digital intermediate is a different thing . It is full raster and at least visually lossless version of the original. Oftenly used with footage from cameras that use an easy to encode but hard to decode codec. Examples would be ProRes, Cineform and DNxHD. Of course some cameras create proxies using those codecs e.g. RED and ProRes and some record directly to the higher quality variants of these codecs.
--------------------------------------------------------------------------------------

My suggestion for how this should have been implemented:

1) Permit the user to specify the proxy codec. Limiting it to only a long GOP HD codec means being stuck with a high overhead codec that requires a fair amount of buffering. The option to use an intraframe codec such as DV would enhance the user's ability to match the codec to the capabilities of their system.
2) Allow the user to specify the location of the proxy files.
3) Flag the proxy files for the same fps as the source.

Such a system would be simpler to implement, could be used both for proxy editing and for offline / online editing. It would also be less prone to errors and problems such as are being reported by users here.

Bob.

The Proxy Stream script seems to do all of this and is free.

Dave T2

I've always been doing all that Bob iterated, by hand.

"The Proxy Stream script seems to do all of this and is free."
Where can the latest version of this script be found?

Piotr

Proxy Stream 1.5e, from here, seems to work fine VP12.

Willem.

XDCAM EX will record from I think 1 frame every 5 seconds to 60 fps

Yes, as an image acquisition frame rate for over-/undercranking. But as you said, the recording is still stored and played back at one of the standard frame rates.

Thanks, Willem :)

Piotr