[Soc-2013-dev] Weekly Report #4 VSE

[Ton Roosendaal]

Hi Alexander,

Where are your commits?

-Ton-

--------------------------------------------------------
Ton Roosendaal  -  ton at blender.org   -   www.blender.org
Chairman Blender Foundation - Producer Blender Institute
Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands



On 17 Jul, 2013, at 7:07, Alexandr Kuznetsov wrote:

> Hi Ton and David,
> 
> GLSL is might be too limiting for our tasks. Most video editors use 
> openCL or CUDA. GLSL works only when screen renders. Plus, it is not 
> very good for dynamic structure:  you have to do render to textures or 
> compose and compile kernels on the fly. Plus, I cannot imagine creating 
> histograms with GLSL.  Possibly those constrains can be avoided, but I 
> had enough problems with using GL buffer from another thread.
> 
> Objectives: agreed
> Requirements:
> Sequencer will be fast and interactive with the rest of blender.
> 
> Sequencer Canvas. I'm actually was working on something like that today. 
> Sequencer has a number of outputs with their own resolutions. Blender 
> calculates backwards the sizes and positions of images on each stages, 
> in order to calculate only displayed pixels. But I think you are 
> defining it more clearly. I will work on better coordinate system.
> As David suggested, I plan to add mute buttons per channels. I can also 
> add collapse and other things.
> Strips will have native position support. They will be editable from  
> preview region. Hopefully the speed improvements will allow live 
> interaction. (Or we can revert to wireframe boxes!)
> 
> Strips with visual feedback + splitting. It probably will be towards the 
> end of the project.
> As David writes, we can add a quick TAB mode for playback and editing 
> the strip itself.
> 
> Caches and proxies visibility: this will be added when I will be working 
> on cache.
> Prefetch will be done after cache.
> 
> GPU: probably all effects will be implemented on gpu first. That way we 
> get cpu->gpu->screen. I still didn't come up with good transfer decision 
> algorithm from gpu back to cpu.
> 
> Linked audio and video: yes
> Snapping should come out of newer sequence evaluation.
> Animated attribute: cannot promise it yet. Too much hacking, despite 
> being nice feature.
> 
> I hope I didn't forget anything. I will update the wiki tomorrow.
> 
> Best,
> Alex
> 
> 
> On 7/16/2013 10:50 AM, Ton Roosendaal wrote:
>> Hi Alexander,
>> 
>> Thanks for the doc. It is still more a list of specs and decisions though. Most of these sound OK. (BTW, why OpenCL and not GLSL)?
>> 
>> I would try to define more top level design issues, and pin down the simple requirements for which we'll value and confirm a succesful GSoC project.
>> 
>> Most evidently it goes straight to the core why we have put Sequencer on GSoC in first place.
>> 
>> Here's my summary of what I liked to see:
>> 
>> Problem:
>> Blender Sequencer is currently carrying over 18 years of code history. It's unclear what the design is, nor how all the code should work. The code doesn't make maintenance (fixes) or future improvements well possible.
>> 
>> Objectives:
>> - Reconfirm the technical design of the code, based on enabling future requirements
>> - Cleanup the current code in a way it becomes understandable for any active developer.
>> - Keep existing (good) functionality to work
>> - Optionally add new features
>> 
>> Requirements:
>> 
>> - Above all: Sequencer is for real-time editing of shots. It is a Blender tool, well working with rest of Blender, for Blender artists to manage their work. We don't make a generic video editor.
>> 
>> - Add a "Sequencer Canvas" concept.
>> Formally define a Canvas size and coordinate system where strip/images map to. The actual rendered size can differ, and has a mapping to this canvas. This allows to crop, border render, make letterbox images, render tiles, etc.
>> Canvas only follows 'render percentage' (like render size).
>> Typically 'canvas' will be input image size, and same as render size. But in many cases you input images with different aspect as a render, it then should just work by defining canvas size to be image size. Animated images also are in canvas coords.
>> 
>> - Redesign strips to have better visual feedback and control over its workings.
>> I think of preview images, in/out points, and the strange "start/end still". Also strip splitting and merging should work perfectly.
>> 
>> - Ensure strip properties and layering is editable in a preview region/editor.
>> This can be with handles for the size/position, but also interesting to see the layers somehow. Editing in the preview region should result in real time updates.
>> 
>> - Make preview region/editor more useful in general
>> Scrub on 1 strip could only show that strip in the preview, for example. It could allow play there as a loop in 'strip time', without need to set ranges. Fast opengl playback of scenes should happen there too (is depsgraph related though, can be postponed).
>> 
>> - Make threaded prefetch work again
>> Simple thing... but someone who adds a strip should get it to play within the fastest possible time.
>> 
>> - Make use of proxy and caches logical and visual
>> This feature currently is very invisble and unclear. In none of the movie projects here I saw anyone use it... Also caching and memory use should be very well in control.
>> 
>> - Make Sequencer stereo and GPU ready
>> Both don't have to be implemented, but it should be possible to add.
>> 
>> Specifications:
>> 
>> Here we get to the doc you wrote, which explains a number of design decisions you made.
>> 
>> -Ton-
>> 
>> 
> 
> _______________________________________________
> Soc-2013-dev mailing list
> Soc-2013-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2013-dev