Proxy codec for remote work?

[Taapo]

Hi there,

We're planning to work with a remote editor, and are looking into proxy codecs that can make the size of the video smaller so that it can work with our VDSL connection (140KB/s upload) without spending days to get it uploaded.

We work with Vegas internally and Cineform, and our first instinct is to upload avi files compressed in xvid format (resized, 500K) to our FTP server. With the right codecs, someone at the other side of the world would be able to download the files and import it in an editor, do the rough cuts and send back an EDL export file, right? This could then be loaded into Vegas again, and since cineform and xvid are both in an avi container, this should work flawlessly, not?

Any ideas on how to make this even more efficient or any remarks on this workflow? Anyone who has experience with this already?

Greets,
Frank

[Taapo]

Is there another codec that is widely available in editing software, and compresses pretty well?

[Cornucopia]

Here's what you need to do:

1. Import your media files (Cineform? etc) Save project as *.veg
2. Also save/export project as AAF type EDL.
3. Also export ALL imported & relevant project media files to proxy versions (could use a script for this) - make sure they are named the same as the original media files, but in a different folder.
4. Send VEG, AAF, and proxies to remote
5. They RELINK the VEG (if they are using Vegas) or AAF (if they aren't) to "media files" (which are now substituted with the proxies in similar folder structures) - make sure to re-interpret the files and regenerate thumbnails.
6.They do the rough cut, then save a new VEG and/or AAF - no media are re-exported except newly imported/created/generated media (and hopefully these will not be proxy quality).
7. Remote sends these to you.
8. You load revise VEG/AAF and RELINK it with the original media (again reinterpreting+regenerating), plus any of that newly created stuff.
9. Finesse the edit & Render the final outputs.

I would suggest a low bitrate codec type as a proxy, but preferrably one that is also Intraframe, not Interframe (like Xvid would have been). You don't want to have the added complication of GOPs for the roughcutters to deal with. Depends on what you need to remain quality - you could go with a much lower rez file, or a lower color depth file, or both. Example might be a 8bit 320x240 MJPEG at 150kbps. Fast, light, low demands. There are others...

Scott

[zoobie]

I think using these final display codecs you mentioned (also h264, wmv, and flv) are not worthy of re-editing and/or re-re-compressing. You're probably better off with a better connection and using something lightly compressed like DV-AVI or similar.

[Cornucopia]

I suggested "similar" like MJPEG, mainly because DV has a fixed bitrate (25Mbps) vs. MJPEG's flexible tiers of bitrates.

Scott

[Taapo]

@Cornucopia I don't completely understand your remark about the GOP problem with Xvid, care to elaborate? For "rough" cuttings, this shouldn't pose a problem though? I will get back an EDL file with the positions of the cuts.

Problem is - and I compared - if I take a Xvid codec, it's feasible in terms of file size and quality, once I use MJPEG the quality goes down quickly and the file size is 4 times as big as Xvid?

@zoobie: I'm not recompressing, I'm only sending the files and get back the edit list. A bigger pipe is no option over here. VDSL is already the biggest link you can get, aside from a leased line - which will amount to ten times the amount we'll have to pay.

[edDV]

In Vegas Pro Help search "proxy" and see their writeup. They recommend DV or SONY YUV frame based codecs for proxy editing.

From the Video for Windows, Sony YUV custom menu, you can set frame size and also replace codecs including MJPEG under ffdshow. You can then experiment with frame size and bit rates.

In this 1280x720 59.94 source example, I selected a quarter size proxy with RGB MJPEG compression. In this case the frame rate would come out 59.94. For frame accurate edits this could be reduced to 29.97 for the proxy.

[edDV]

click on picture to enlarge

Frame based codecs will allow precise edit point specification. xvid or h.264 will result in a sticky timeline depending on the speed of the user's computer. Search to frame will be more difficult with GOP based codecs. Experiment with similar equipment.

[Taapo]

Is the Sony YUV codec implemented in FFmpeg? Doesn't seem like it is supported.

[Taapo]

I just tried Sony Yuv. I can only set the video image size, not the bitrate. After reading up on the format, it's meant to be an "intermediate" format (as it creates files double in size from my cineform neoscene files), not as a proxy format. So, unfortunately this is no solution for my situation (small uploads). Is there a frame-based codec that allows me to go down to a 250Kbps bitrate and compresses as good or near the size of Xvid? I'm asking a lot, I know - but you never know if there is a codec I don't know of ...

[poisondeathray]

You can specify xvid to use I-frame only, but you should understand it's the long GOP , P and B frames that largely allow it to have better compression . Translation: If you force it to use I-frame only, the compression suffers, and you are forced to use higher bitrates for simlar image quality

intraframe h.264 (e.g. using x264 encoder) would give slightly better compression than intraframe xvid

[Taapo]

Can you elaborate how to make it intraframe? How can you specify that for example on the ffmpeg command-line?

[poisondeathray]

Can you elaborate how to make it intraframe? How can you specify that for example on the ffmpeg command-line?

I believe the switch is "-intra" for ffmpeg , but I don't use ffmpeg to encode xvid so I am not certain

It might be "-g 1" , for GOP size of 1

[Taapo]

Thanks a lot, you seem to be correct - from the ffmpeg docs:

`-g gop_size'
Set the group of pictures size.
`-intra'
Use only intra frames.

I'm gonna try this now and see how it affects the size.

[Taapo]

Nice tip, it works.

Result: double in size, much more block-y in the output. So I'm wondering if that's a solution ... not sure yet.

Any intraframe codecs that compress better than Mjpeg or Xvid? You mention X264, bit isn't that much heavier on the cpu for decoding?

[poisondeathray]

Thanks a lot, you seem to be correct - from the ffmpeg docs:

`-g gop_size'
Set the group of pictures size.
`-intra'
Use only intra frames.

I'm gonna try this now and see how it affects the size.

But are you using bitrate based encoding, or quantizer based encoding ?

In the former, it won't make a difference with the size, only the quality will be reduced at a fixed bitrate (because you are on the lower part of the compression curve)

Filesize = bitrate x running time

When you use I-frame only, you are trading off worse compression (larger filesizes), for better editing - which you should be doing IMO

[jagabo]

Also consider short GOPs (~6 frames) with only I and P frames.

[poisondeathray]

Any intraframe codecs that compress better than Mjpeg or Xvid? You mention X264, bit isn't that much heavier on the cpu for decoding?

Yes, x264, it is highly configurable. You can use --tune fastdecode for example, which will turn off high latency decoding options like CABAC which will be easier on the CPU (but worse compression) . It's slightly different using x264 through ffmpeg, they use preset files

But if you are using a SD proxy workflow, with reduced resolution (as you should be), you should not be having any issues with editing latency


What are your input file specs ?

What are you editing workstation specs ?

[poisondeathray]

Another option is to use long gop, high compression settings just for the transfer, then "force" your editor on the other side to transcode to an I-frame intermediate before importing. It adds an extra step, but I've seen many issues with editing long GOP, I think it's wise to use intraframe.

[Taapo]

Your last remark was something I was thinking about anyway, and it's a good idea worth exploring.

The thing I'm wondering is, if I can edit non-intraframe 640x360 250Kbps xvids perfectly on an atom-based laptop - what *could* be the problem then on any computer? If I'm having someone else doing "rough" edits which don't need a particular precision, why would I choose an intraframe encoding? Can there be errors, other things I don't know yet?

Basically I have something like this now:
i7 -> canon 7d 1280x720/1920x1080 mov -> cineform avi

I encode xvids:
mov -> ffmpeg xvid 250k 640x360 avi (same name as the cineform avis) -> upload to ftp

Someone else does the rough edits, and send me back a VEG or EDL file
I load it up in Vegas, with the cineform avi's instead of the xvid avis
Voila, should work perfectly, not?

[poisondeathray]

The potential problems are the EDL doesn't match up or files don't match up.

Sometimes you see an editor/software will "lose it's place" with interframe formats, or frames will be out of order

It doesn't happen all the time, but when it does, you are in for a lot of headaches...

[Taapo]

"The potential problems are the EDL doesn't match up or files don't match up."

Like the EDL won't load certain files? -> that's bad

Or are the images just a couple of frames off? -> that's manageable ...

[Taapo]

Oh, read too quickly ... frames out of order ... that's much worse indeed.

[poisondeathray]

not trying to scare you, you can edit long gop formats natively, successfully... but every now and then these errors pop up and you will kick yourself for not avoiding the headache

transcoding to an I-frame intermediate isn't only about editing speed (low latency), it definitely helps to prevent these errors

IMO, the "quality" of the proxy really doesn't matter that much unless you are doing fine detail or VFX work (which you shouldn't be doing anyways in a proxy edit, you should do things like final touches and fine detail work on the master)

it's up to you to decide what shortcuts or risks you are willing to take

[Taapo]

So if I would encode to non-intraframe xvids 250k versions, and ask the remote editor person to recode those to intraframe ones, that would solve the problem right?

[poisondeathray]

So if I would encode to non-intraframe xvids 250k versions, and ask the remote editor person to recode those to intraframe ones, that would solve the problem right?

Theoretically yes, in practice not necessarily. It would still be better IMO than using the longGOP version of the xvid for editing.

The more generations and transformations you incur, the higher the risk of something going wrong

Even the 1st step of using hdlink to convert to cineform, the framecount might vary between the cineform file and original file for example. The decoder and software used may vary in their interpretation of the file. Quicktime migth "see" 1001 frames, but a Directshow based decoder might see 1000 frames.

ffmpeg theoretically should give you consistent results, if you use the same build between you and the remote editor. It doesn't rely on system installed decoders and codecs like directshow. So if you use it to encode and decode, and you both use the same vegas version, this will minimze the chance of problems . If he takes the xvid file and converts it with a different method, you may get inconsistencies.

[Taapo]

Thanks a lot for the detailed explanation, it sure helped me a lot.

[poisondeathray]

Also "test drive" your intended workflow before you embark on a big project

Transfer some test files or a mini project, make sure everything works ok

[edDV]

I just tried Sony Yuv. I can only set the video image size, not the bitrate. After reading up on the format, it's meant to be an "intermediate" format (as it creates files double in size from my cineform neoscene files), not as a proxy format. So, unfortunately this is no solution for my situation (small uploads). Is there a frame-based codec that allows me to go down to a 250Kbps bitrate and compresses as good or near the size of Xvid? I'm asking a lot, I know - but you never know if there is a codec I don't know of ...

I was showing the menu path in Vegas to get to first an uncompressed baseline (Sony YUV as recommended in proxy help*), then to Video for Windows codecs for further compression (intraframe only recommended).

From there you experiment with frame size, codecs and bitrate testing on user level equipment.

It is important to test the full process including proxy edit on user level machine, then EDL load with original clips to online machine to see if the edit points match.


* the Sony YUV workflow recommended in Vegas help is more intended for a post house environment where original files are uncompressed or low compressed on a house video server. Their goal is to reduce bit rate to offline machine levels using SD DV or smaller frame size. Your requirements call for more aggressive intraframe compression.