Author Topic: [bug?] filter 'blacken borders' can't be made partial (ASCII too..)  (Read 769 times)


  • Newbie
  • *
  • Posts: 36
Since this filter doesn't alter video size (don't confuse with add black borders), I guess it should be partial-enabled.
NB, it does work perfectly as a partial filter when set up manually in the project file.

(And as a side note, I still can't figure out why temporal filters [needing a pre-/post-frame] can't be made partial... as already asked, where is the difference of processing the whole video from 0 to X, and processing only A to B?

PS: ASCII output filter can't be partial, too - although I think it's a fun-only filter and therefore not so important, I can't see why it can't be partial


  • Hero Member
  • *****
  • Posts: 1077
Re: [bug?] filter 'blacken borders' can't be made partial (ASCII too..)
« Reply #1 on: April 29, 2017, 11:19:28 AM »
Layman's explanation:

Avidemux doesn't know the order of the "virtual frames" in the video buffer.
And it doesn't know which other frames that "virtual frame A" depends on.

All that is handled internally by the video decoder used by Avidemux.
Avidemus operates on the next frame spit out by the video decoder (ie looks ahead by 1 frame only)

Hence why no smart copy and partial filers that need future frames or past frames decoding (ADM doesn't know how the fetch them).

The old ADM 2.5 branch kept track of all this frame ordering and frame referencing (hence why it was called a frame based video editor).
The new ADM branch 2.6 has given up this functionality in order to get along with current advanced codecs.
These advanced codecs have become very complex in this frame ordering and referencing.
I guess that's why ADM 2.6 is called a time based video editor and operates on sequentially/fully-decoded frames (relying on PTS and PAT to navigate).

This is just how I perceive the workings of ADM, based on the info gleaned in this forum
Feel free to provide a better/correct explanation.