Ok, I found this thread today because I was looking to a solution for proxy-editing, too.

I got a simple and maybe foolish idea:

1) right now i am converting three avchd test-files to an mpeg2video stream with high bitrtate

2) Then I will convert them again into the same format bit with very reduced bitrate.

[I will give them the same nametags, saved in different folders]

3) Then i will edit the proxy files, save the project, change the name of the proxy directory, so kdenlive is gonna loose the linking

4) Then I will restore the linking by linking them highbitrate files to the project.

Lets see...

Ok, I can't believe it!

It worked.

Proxyediting test succeded!

With audio- and video-fades and cuts and everything :D

I worked it over a little bit and I have to say: It's the greatest solution for editing on Linux I discovered by now. I am very excited about that.

For my Proxys I chose the following ffmpeg options:

ffmpeg -i test.m2ts -f avi -acodec libmp3lame -ab 92k -ar 48000 -vcodec mpeg2video -g 5 -r 25 -deinterlace -s 480x270 -b 2k test.avi

My "high quality" stream - if you can say so as the original is avchd - looks like:

ffmpeg -i test.m2ts -f avi -acodec libmp3lame -ab 256k -ar 48000 -vcodec mpeg2video -g 5 -r 25 -deinterlace -s 1920x1080 -b 25000k test.avi

As you can see the proxy has lower bitrates and lower resolution providing a really fast editing performance.

To Link the "high quality"-files to the project all you got to do is change the name of the folder you got them saved in into the name of the proxyfolder (same path, so you have got to change the name of the proxyfolder too)

Then render the project!

done

have questions? ask!

btw.:

I just finished editing and rendering a complete Project(37min) many cuts, transitions, etc using above described method and working with proxyfiles.

Besides a little problem with the speed-effect(witch I don't think came from the proxys) I didn't experience any problems.

greetz to all of you.

I tried this, really works :)
Thanks for the howto.

Hi,

That sounds interesting. Thanks also for the settings.

A few questions from a newbie...

Why did you choose mpeg2video codec? (I presume this is best choice).
How big are the HQ files created with this compared to the original AVCHD files?

Gary.

Good to see a proxy work flow is possible with kdenlive. Thanks OpenHawk.

However I also have a few comments:

The above conversion options I'd suggest are not applicable to all formats. So best that people don't just blindly copy them. Just apply OpenHawks principle.

Why deinterlace, why scale, why transcode original to supposed high quality, is it simply due to the wish to deinterlace?

Take care if anyone adopting this if you have a Canon 5DmkII, 7D or 550D / T2i they actually capture 1088 lines, so applying a scale 1920 1080 will invoke unnecessary scaling, cropbottom -8 should be used instead. The current kdenlive DNxHD transcode options all suffer that. There other minor things that are lost when transcoding, even at high quality, lossless operations,

I have a P4 laptop I'd like to be able to edit on when not at main desktop but even 36mb DNxHD is too much and DNxHD does not allow use of 4:3 PAR sources such as HDV unless scaling is applied, whether that be nearest neighbour, biliner, bicubic, lanczos which on top of deinterlacing is yet another degrading of the original source :-)

So maybe a DV route for HDV material.

I think one should not loose too much time agonizing how to compress/downscale the proxies, since this has ABSOLUTELY NO INFLUENCE on the quality of the final rendering, which is done from the original clips.

So, just squeeze enough for a fast workflow (DV would be a good choice, for example). Interlaced or not, does not matter. The final render will be done from the original clips anyway.

I you need to do some fine tuning of an effect, which requires high resolution, you can do it in the end, after doing 99% of the edinting on the proxies, just before render, on the original resolution clips.

"- Some people want to work with 1280x720 video (proxy or high quality) from 1920x1080 footage ; for them deinterlacing is mandatory. 1080 can be either interlaced or progressive, but 720 is always progressive. So people transcoding their AVCHD footage to DNxHD 90 or 60 (for instance) before editing have to use a deinterlacing filter."

Exception not the rule. Deinterlace if you have to, so many seem to think interlaced material is somehow defective and that it MUST be deinterlaced, shoot interlaced for slowmo maybe, but otherwise shoot at the delivery size. If 720 is the output then shoot 720 and for something like a DSLR have the option of 60fps progressive, save resources, disk space, back up drive space and ease the NLE realtime effort. :-) But each to their own, it wasn't the purpose of my reply.

" But AFAIK HDV can be edited directly in most editors (unlike AVCHD) so you usually don't have to transcode it before editing. Unless you have to work with old/weak hardware (like your P4 laptop or a netbook), there's usually not a great benefit to use a proxy for HDV."

Depends on the NLE, I struggle to get kdenlive realtime with HDV and a few effects on a dual Xeon, 8GB NVidia 210GT 1GB and a dedicated 7200 h/d. :-)

@marko, no ones talking about deinterlacing / quality in proxy generation :-) Just supposed deinterlaced 'high quality' from original source rather than using the original source, with reference to OpenHawk. So "original source is used anyway" as you say is NOT the case in his case and all I was refering to, not proxys workflow in general :-)

Just saying anyone reading OpenHawks process not blindly copy CLI options that's all. :-)

Sorry, did not detect that the debate went off topic, to pre-processing...

Since I think Kdenlive uses ffmpeg for the final render/encode, what is the point of doing a ffmpeg re-code before it?
Or is it not possible to give Kdenlive arbitrary ffmpeg switches?

Hi!

Just to let you know, I started to implement proxy editing in Kdenlive. The first steps are now committed to svn. In the Kdenlive settings dialog, under "Project defaults", you can enable proxy clips".
Then, when adding a clip to a project, Kdenlive will automatically create a proxy clip in the background (I used OpenHawk's parameters to create the proxy). This proxy clip will be used for editing in Kdenlive, and in the rendering dialog you now have an option to render using proxy clips or original clips.

Some work is still needed, for example to create / load proxy clips for existing projects, and correctly update the project if proxies are enabled / disabled, but if some of you want to test...

hello j-b-m,

nica to know. thanks for the work.

maybe this might help? (saw it on cinelerra-cv mailing list)

http://code.google.com/p/hdffxvrt/

cheers :D

Hi j-b-m!

Always good to hear about progress from one who takes the initiative to make something better *thumbs up*

BTW: my settings weren't meant to be standardized. They just seemed to be fitting for my project. I didn't try your new added feature yet. Is it possible to change the ffmpeg format options used for proxy-rendereing via a dialogue integrated in kdenlive? That would be nice.

greetings,
Benjamin

...perhaps using some of the same presets used for rendering?
or some presets created just for proxy use.

Perhaps it would make sense to use relative sizes, like 1/4 of the original video size? (To avoid 240p footage being scaled up for example :P)