File previews came together rapidly, after the initial refactoring.  The mane unknown is how well PlaybackEngine::interrupt_playback is going to work when it's asynchronously receiving start commands.  Interrupt_playback is normally called with the window unlocked so it can wait for the tracker to finish drawing.  The problem is it's now going to get start commands when the window is unlocked.

 It normally works around this by locking FilePreviewer::previewer_lock.  This causes a deadlock when interrupting playback so instead, it's locking the window.

The file previewer has to call it with the window locked & the previewer_lock unlocked.  It seems to work as long as the tracker has an is_playing variable.  Instead of waiting for the tracker to finish drawing, the previewer can set is_playing to make the tracker ignore further draw commands.

Lions are pondering making this the universal way of interrupting playback.  The key requirement is for all the trackers to do their drawing in their window threads instead of the update_tracker calls & have is_playing variables.  Interrupting playback with the windows unlocked was always janky.  Of course, the is_playing variable might belong in the PlaybackEngine.

-------------------------------------------------------------------------------------------------------------


Another trick with file previews is the ability to play files without a table of contents.  It can't seek, but it can rewind & pause.  That depends on all the file readers so far being written in such a way that they can read frames without knowledge of the file offsets.

To avoid the case of a file preview crashing as soon as the window is opened, it doesn't preview the default file selection.  That keeps the user from getting stuck

Then it was a lot of rote coding for window resizing, end of playback, rewind, stop, seek, adding previews to all the file dialogs.

Some files break the previewer but don't crash.  The program has to restart to get the previews back.  It's going to be a while before all the trouble spots are found.






The previews range from a full scroll bar with video to a crusty speaker icon, to just a still photo.  The horizontal margins got dropped to fit as much in.  It's undecided if there's going to be a way to resize the preview.  The preview size is what Firefox uses, but firefox still has wasted margins.


Helas, it's still going to be easier to find a photo in Geeqie/GQView.  That decodes all the photos in the background & uses the thumbnail directory.  It's still a bit bloated at this point to go back to a picon based file browser & lions don't care to devote gigabytes to persistent thumbnails.  The file dialog did originally support an icon mode which just showed generic file type icons.  The resource window originally generated a picon for each asset, slowly.

There's not only a desire to get rid of clips, but get rid of all of the resource window except the asset list.  It wouldn't have to show the title of the current folder/bin anywhere.  In that case, it would be closer to having a preview of its own.  If it was just for the lion kingdom's own use, the clips would be gone.

It now appears the clips could have been regular EDL files.  There could have been a method of saving a selection to an EDL file.  They could have been pasted or nested from the file dialog.  If there was a way to have EDL previews, it would have enabled clip previewers in a file dialog without replicating everything in the resource window.  It's still a feature lions would never have used.

So much of video editor design came from the tradition of physical rolls of film in bins, before there were even filesystems with directories.  Home computers didn't have directories until the mid 80's.  It was a big deal to run that first mkdir command.

Part of what the bins of clips, effects do is allow dragging & dropping, but lions never use that.  The clip feature has automatic names & clips from different EDL's don't overwrite each other.  The automatic names could be unique for each EDL file.

The big question if it's going to stay a program that someone else might use, rooted in ancient film editing traditions, or if it's going to be just for lions.  The useless features are manely a software manetenance issue nowadays.

The goal posts tend to move forever.  The decision has to be based on cost vs quality of life.

-------------------------------------------------------------------------------------------------------

The next item is track bouncing 2 layers deep. 


This doesn't render anything & used to crash because the bounce is 2 layers deep.

 

 

While this renders the image because the bounce is 1 layer deep.  At this time, there's never been a use for bouncing 2 layers deep.  Track bouncing was another thing all audio editors just did but wasn't solving any lion problem.  To this day, lions have never used track bouncing & it's unlikely any video editors do it.  

 It might have been a convenient alternative once for stacking images.  There was a dark frame & a light frame.  To subtract the dark from the light, both frames needed the same unsharp mask, histogram, hue saturation.  That was just 1 layer deep though.  It's never been used for audio.

 

The closest feature which gets used all the time is shared plugins. There is a case for sharing a stack of plugins by defining it in 1 track & bouncing all the media tracks to the 1 track of plugins.

 

It's always been easier to just attach the same plugins to all the tracks as shared plugins.  Maybe it's harder to change the stack this way.  A bunch of bounced tracks can have a common plugin stack which changes over time.  It might be useful for a shared audio effect that only happens briefly in a timeline but this would normally create glitches.  It's more practical to keyframe the plugin.

Modern video editors use a graph for compositing.  It's unknown if they have random access or always feed the frames sequentially.  The Davinci product pages don't show anything like track bouncing in graph form.

 

The example use cases for track bouncing are out there, but all lions ever needed was shared plugins.  Sometimes lions miss the days of a command line program which just cuts audio files & sometimes they want the luxury of file previews.

 

The double bounce creates the following:

VirtualNode 0x7f7ec4038f40 title=Video 3 real_module=0x7f7ec4038480 *
 Plugins total=1
  VirtualNode 0x7f7ec4039360 title=Video 1 real_module=0x7f7ec4038a30  
   Plugins total=1
    VirtualNode 0x7f7ec4039780 title=Video 2 real_module=0x7f7ec4038710  
     Plugins total=1
      VirtualNode 0x7f7ec4039ba0 title=Video 2 real_module=(nil)  
    Plugin Hue saturation



         VModule::render 1009 current_edit=nil position=0 title='Video 2' use_gl=1
      PluginServer::read_frame 956 start_position=0 channel=0 nodes=1 modules=0
    VirtualVNode::render_as_plugin 228 track='Video 2' plugin='Hue saturation' use_gl=1
    VirtualVNode::render_fade 369 track='Video 2' fade=100.000000 use_gl=1
    VirtualVNode::render_projector 488 track='Video 2' use_gl=1
    VirtualVNode::render_fade 369 track='Video 1' fade=100.000000 use_gl=1
    VirtualVNode::render_projector 488 track='Video 1' use_gl=1
    VirtualVNode::render_fade 369 track='Video 3' fade=100.000000 use_gl=1
    VirtualVNode::render_projector 488 track='Video 3' use_gl=1


The single bounce creates the following:

VirtualNode 0x7f7ec4038f40 title=Video 3 real_module=0x7f7ec4038a30 *
 Plugins total=1
  VirtualNode 0x7f7ec4039360 title=Video 2 real_module=0x7f7ec4038710  
   Plugins total=1
    VirtualNode 0x7f7ec4039780 title=Video 2 real_module=(nil)  
    Plugin Hue saturation
 

       File::read_frame 1958 path='/home/jpeg/2024/sunset1.jpg' current_frame=0 colormodel=YUV-8 Bit use_gl=1
    VModule::render 1121 position=0 title='Video 3' use_gl=1
    PluginServer::read_frame 956 start_position=0 channel=0 nodes=1 modules=0
  VirtualVNode::render_as_plugin 228 track='Video 2' plugin='Hue saturation' use_gl=1
  VirtualVNode::render_fade 369 track='Video 2' fade=100.000000 use_gl=1
  VirtualVNode::render_projector 488 track='Video 2' use_gl=1
  VirtualVNode::render_fade 369 track='Video 3' fade=100.000000 use_gl=1
  VirtualVNode::render_projector 488 track='Video 3' use_gl=1

The divergence happens at the Hue Saturation plugin.  It reads from Video 3 in the single bounce & Video 2 in the double bounce.  In both cases, Hue Saturation is in the Video 2 track.  It somehow knew to back up 1 more layer to read the frame.



 







Comments

Popular posts from this blog