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

Tue Jul 16 16:50:04 CEST 2013

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-

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

On 14 Jul, 2013, at 8:16, Alexandr Kuznetsov wrote:

> Hi Ton,
> 
> Sorry for the late doc. I thought I copied it to wiki. Anyway, here is 
> an updated version:
> 
> http://wiki.blender.org/index.php/User:AlexK/Gsoc2013/vse
> 
> 
> I'm happy with DNA for the most part. Mostly, I will extend modifiers 
> number and maybe move proxies and some other things. This shouldn't be 
> anything major. I will write the converter if needed.
> 
> 3) Schlaile also wasn't so happy with it. I'm sorry. I thought that 
> current code is not yet useful for the artists, so I didn't bothered 
> with commits. Anyway, I plan to do a commit of everything soon, after a 
> clean up. Also, Schlaile and I agreed that engine should be in C++ 
> instead of C. It might take some time before a proper port.
> 
> Best,
> Alex
> 
> 
> On 7/13/2013 12:17 PM, Ton Roosendaal wrote:
>> Hi Alex,
>> 
>> I asked this two weeks ago too. You seem to work mostly on the internal part ("Scheduler") but I rather see the work targets confirmed too.
>> 
>> This doc is still a bit sparse:
>> http://wiki.blender.org/index.php/User:AlexK/Gsoc2013/vse
>> 
>> A good trick is to write down requirements - which is user-testable end results you will target to achieve with the GSoC.
>> 
>> Secondly I like to see written down how the DNA storage will change, and how it would affect the UI (possibilities) for sequencer.
>> 
>> Third: with just 2 commits in svn in past 4 weeks I'm not very happy. There's nobody working on this branch, just use it for daily updates?
>> 
>> -Ton-
>> 
>> --------------------------------------------------------
>> Ton Roosendaal  -  ton at blender.org   -   www.blender.org
>> Chairman Blender Foundation - Producer Blender Institute
>> Entrepotdok 57A  -  1018AD Amsterdam  -  The Netherlands
>> 
>> 
>> 
>> On 13 Jul, 2013, at 8:14, Alexandr Kuznetsov wrote:
>> 
>>> ==Week 4==
>>> * Dispatch system is almost finished
>>> ** for now, it is limited to one device due to limited (handmade)
>>> testing cases
>>> * Reviewed strip code
>>> ** Sadly, it is directly tight in with rendering code
>>> * Worked on strip code
>>> ** Created a dependency graph (more like a tree for simpler cases)
>>> ** Should allow more flexible system (effects = modifiers, blend = blend
>>> effects)
>>> 
>>> ==Next Week Todo==
>>> * finish strips graph
>>> * Create bucket generator
>>> ** From strip dependency graph
>>> ** for current filter
>>> ** Start implementing filters into our system
>>> * Make better dispatch system
>>> ** a smarter way for cpu + gpu interaction
>>> 
>>> == Questions ==
>>> Do we want unlimited -detail- number of video tracks?
>>> _______________________________________________
>>> Soc-2013-dev mailing list
>>> Soc-2013-dev at blender.org
>>> http://lists.blender.org/mailman/listinfo/soc-2013-dev
>> _______________________________________________
>> Soc-2013-dev mailing list
>> Soc-2013-dev at blender.org
>> http://lists.blender.org/mailman/listinfo/soc-2013-dev
> 
> _______________________________________________
> Soc-2013-dev mailing list
> Soc-2013-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2013-dev