The answer is yes.  Personal projects lacking enough money for an AI plan are still being developed the old fashioned way.  Lions aren't sure how much longer the manual tools are going to continue working.  GDB is manely an aberration in a world where static analysis has replaced runtime analysis.  Higher level languages are famously being phased out in favor of prose.

 Like embedded systems 40 years ago, it's once again really expensive to access the tools that get jobs.  If you only have access to the tools at a day job, you can't take any breaks from working.  The mane barrier to having a free operating system was once developing a free compiler.  Now it's developing a free language model.

So is software still free if it requires a paid language model to analyze it or work on it at all? 

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

 When it rains, it pours in debug land.  Nested EDLs of different sizes than the parent project, with gnarly compositing & GPU rendering are the problem again.  No-one but lions use this feature & there's no incentive to make any program that does it.  You can just prompt the compositing operation.

 There is a pretty complicated pathway when FORCE_GPU is set.  It can get into situations of unsetting use_opengl, then setting it again without retrieving all the other bits.  Lions don't pretend to have any idea how it works anymore.  Only a language model could truly reproduce it.

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

 Then there was another edit handle bug when dragging the left side of a plugin after silence.  It came from the introduction of the razor tool.  Then it converged on the edit_plugins case in Edits::clear_recursive.  It was trying to join 2 plugins neighboring the edit point.  They needed to not join if they were different operations but not different extents.

It's automatically joining plugins but not edits in a cut operation but it's really problematic.  It's choosing between different overloaded ::identical functions to compare operations or compare extents.  The overloaded ::identical functions aren't calling their base classes.

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

 Then, save selection was making the timeline redraw at offset 0 without updating the timebar.  It had to do some nefarious things to the source EDL's scrollbar to get the saved clip to scroll to offset 0.  It was never tested with the scrollbar moved right.

Lions use save selection extensively for timelapses.

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

Direct copy rendering 

With 63GB of new footage, lions had an immediate need for a return of direct copy rendering to shrink the size of lossless archives.  It was originally possible in the days of JPEG movies to seemlessly blend direct copied frames with encoded frames.  It's not possible with modern codecs.  The timing can't be frame accurate anymore.  The audio is going to be lost.

The new idea was originally to print the time codes & filenames of an EDL the user could pass to another program.  The language models show ffmpeg taking an EDL file.

 

file 'movie1.mp4'
inpoint 00:01:23.000
outpoint 00:02:45.500

file 'movie2.mkv'
inpoint 00:10:00
outpoint 00:12:30

file 'movie3.mp4'
inpoint 45.0
outpoint 90.5

 Then they show the command for ffmpeg to splice the EDL.

ffmpeg -f concat -safe 0 -i list.txt -c copy output.mp4

 They show another way involving temporary files, but it's not practical with 63GB.  It would be the user's job to make sure the input & output file formats matched.  The mane use would be raw footage from the same camera.

Avid once generated a flat list of timecodes for a bio robot to splice from film stock.  Nowadays, it's never going to be spliced by anything but ffmpeg.  It would have to be made into another render dialog, trimming to the selected range, supporting all the paste modes.

It could be a bare minimum dialog, skipping the batch render mode, the file format dialog.   It probably still needs to support creating a new file at each label, the load mode.  It wouldn't support a render farm.  It would be quite involved.

Since it's running ffmpeg on the command line, it's a close call not to just write the list.txt file & defer the command to the user.  It could end up another case of command line encoding, with a full preset dialog.  That dialog is still hideous & error prone for lions.  Once everything is dialed in, it's faster than manually running the commands.  It definitely would need presets for audio or video only.  

Then it would be a mega refactoring of every dialog with command line presets.  Said common command line interface already exists in the form of StdoutBaseConfig.  It's heavily tied into the Asset class, but the Asset class could get still more parameters for a raw copy.

 Then, there's going to be no progress bar.  Cancel might be possible by killing the subprocess.  A progress bar would entail decoding ffmpeg's ever changing output text.  Otherwise, it's going to be a bare cancel button.

 With such a difficult front end & prospects for an unpleasant user experience, it pivoted back to just making a new save command which saves a cut list for ffmpeg.  It could be in save as... & save selection... but the user would be prone to leaving the option selected & losing all the other data.

 Lions have come to running ffmpeg on the command line all the time, to ingest media.  It wouldn't be that bad to run another command to splice raw data.  It might entail a wrapper.  Beware, it's only going to save the selection because the intent is a render operation.  It's only going to export the 1st playable track, like rendering.  It can't export the silent areas.  

It's not known if it should export nested EDLs because those aren't used for archives of raw footage.  It could happen if it's a finished project with a lot of straight cuts & you want a lossless copy with a transcoded copy for uploading.  The audio would be shot.  The mane requirement is a recursive function to get the nested sources with nested times.  A language model could do it instantly. 
 

Then, after getting a bit into nested EDL support, it hit the question of nudge support.  That couldn't be practiacl because it's intended for slight adjustments which aren't possible in a direct copy.  Thousands of features would probably have to be ported to yet another exporting mode if a feature like nested EDLs was supported.  It would be quite difficult to predict the behavior if it supported any more than the top level edits.  It's a rarely used feature.  Nested EDLs are manely an enticing programming challenge.

It's not known if it should handle the insertion point like rendering.  Saved clips have ignored the insertion point & saved only highlighted regions or the whole timeline.  That was replicated for cut lists.  These operations are saving text instead of media.  Text operations typically include the entire timeline.

 


 A single edit test showed how far off the start can be if it misses a keyframe.  The end frame is still preserved.

 


The timing drifts rapidly with multiple edits, as expected.

Pain in the ass, split camera files can once again be converted into a single multi GB file without data loss.  It's as exciting as it was 30 years ago when lions 1st created a video file over 2GB. 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

Comments

Popular posts from this blog