End time numbers in partial filters off by .001 meaning extra frame is affected

[Who]

In the past, when you used a filter that could be set to "partial", and you clicked on "partial" in the right-click menu, it would come up showing the times for the A & B Markers UNLESS the video had been edited, and then sometimes the times would be wildly inaccurate and all you could do was type in the correct times.  That appears to have been fixed (and a HUGE THANK YOU for that), BUT quite often the end time that is copied will be exactly .001 seconds more than what is shown for the B marker, and if I don't notice it and click the down arrow to go back .001 seconds then an extra frame is included in the operation (which sometimes doesn't matter, but sometimes it does, depending on the operation).

I am seeing this in the latest MacOS nightly from July 30, so I suppose it is possible that you have already discovered and fixed this, but if not I just wanted to mention it.  It's probably just a rounding error and it's still way better than having the times be off by several seconds or minutes, as was the case previously, but if it's something that has been fixed or can be fixed, that would be great!

[szlldm]

Using partial filter the frame at the B marker is included, because otherwise the last frame couldnt be filtered with a partial filter.
The actual marker values (and frame timestamps) have microsecond resolution, and that will be rounded to millisecond resolution. If the partial filter add a .001 seconds, that is happens to ensure, the frame at B marker will be filtered as well.

[eumagga0x2a]

Now, as the Avidemux behaviour WRT marker B has been reverted back to the original behaviour (i.e. the end point of a selection does not belong to the range and is excluded from save/export operations), I am at a loss whether a different handling in partialized filters needs to be changed as well or left as-is.

[szlldm]

I am at a loss whether a different handling in partialized filters needs to be changed as well or left as-is.

If you exclude the frame at marker B, then you can not filter the last frame of the video with a partial filter. (If im not mistaken.)

[eumagga0x2a]

To include the last frame of the video, marker B needs to be set past its pts, usually to the total duration.

[Who]

Now, as the Avidemux behaviour WRT marker B has been reverted back to the original behaviour (i.e. the end point of a selection does not belong to the range and is excluded from save/export operations), I am at a loss whether a different handling in partialized filters needs to be changed as well or left as-is.

In the past, it always appeared that if I made a selection with the A and B markers, the A marker was always the start of the video to be affected, while the B marker was always the start of the video that was not part of the affected range, UNLESS the B marker was on the last frame of the video, in which case that single final frame would also be included.  This still appears to be the case as far as I can tell, and that makes perfect sense to me.

And also in the past, when I enabled a partial filter, it followed the same rules, EXCEPT in the case where the times for the A and B markers were not copied accurately (as would often happen if portions of the video had been cut out prior to the area included in the markers).  But now it is more accurate, but adds this .001.  To me it makes no sense to include the additional .001 (and therefore the additional frame) in the partial filter, because that means that part of Avidemux is working one way and another part a different way, and that's confusing.  It also means that if you forget to click the down arrow to reduce the count by .001, you will affect one frame more than you intended, and in some circumstances that could mean having to go back and re-encode the entire video.

It just doesn't make any sense to me to copy the A marker verbatim, but copy the B marker and then deliberately add .001 (if that is indeed what is happening).  And I did not realize this was happening for a few days (that it was including an extra frame), so I may have screwed up some videos and not realized it (by only one frame here and there, but still, if you're a perfectionist that's bothersome).  I had initially thought that an extra .001 was probably just a rounding error in the display, and didn't think for a minute that it would actually include another frame, until I saw that it did.

[eumagga0x2a]

In the past, it always appeared that if I made a selection with the A and B markers, the A marker was always the start of the video to be affected, while the B marker was always the start of the video that was not part of the affected range, UNLESS the B marker was on the last frame of the video, in which case that single final frame would also be included.

This behaviour would have been problematic as it would not allow to exclude the last frame (just the last frame) from range – the choice would be either to include the last one or to exclude two last frames.

The only missing part now is a function to reset (i.e. set to the total duration of the video) marker B only.

[Who]

In the past, it always appeared that if I made a selection with the A and B markers, the A marker was always the start of the video to be affected, while the B marker was always the start of the video that was not part of the affected range, UNLESS the B marker was on the last frame of the video, in which case that single final frame would also be included.

This behaviour would have been problematic as it would not allow to exclude the last frame (just the last frame) from range – the choice would be either to include the last one or to exclude two last frames.

The only missing part now is a function to reset (i.e. set to the total duration of the video) marker B only.

I'm just saying how I thought it worked, I may be wrong.  I really can't think of any circumstance where I'd want to exclude just the very last frame from a range, in all the time I have been using Avidemux I've never had the occasion to just want to keep the very last frame but not some of the ones that come just before it.

Basically, here's what I don't want to see messed up.  Let's say you have two parts of a video (the start in one file and the end in another) and they overlap in the middle.  So you load the first file, append the second one (or maybe use an external program such as ffmpeg to combine them, doesn't matter), and then you go to the first occurrence of a frame that's in both parts and set the A marker.  Then you go to that exact same frame in the second part and set the B marker.  Then you delete the section indicated by the markers.  The frame that the A marker was on will be the first one deleted, while the frame that the B marker was on will be the first one kept after the deletion.  If it were to work any other way, not only would you either duplicate the frame or lose it completely, but worse yet you'd probably create a very noticeable audio glitch.

So the way I have always understood it is that the A marker is the first frame in the range, while the B marker is the first frame after the range.  But if that were true at the end of the file, you could never get rid of the last frame, and I've always been able to get rid of the last frame, so that's why I thought there was an exception if the last frame is at the end (that is, if the B marker is set to the very last frame in the file).  What I have never checked to see is if you press the button to go to the end of the file, does that actually set the B marker to a time that is slightly beyond the last frame?  If that were the case then that would explain why I've always been able to delete the last frame.

In any case, if someone ever ran into a situation where they needed just that one frame at the end, they could always copy and paste it (in effect duplicating it).  But I just cannot think of any practical situation where you'd ever want to delete (or otherwise act upon) a section right up to the end with the exception of the very last frame.  I'm not saying it could never happen, but I'd think it would be extremely rare that anyone would want to do that.  Usually, if you're doing a delete at the end, you're trimming off some excess video that's after the part you really want to keep.

Anyway, sometimes you talk in technical terms and confuse me, all I'm saying is that it's a problem if you apply a partial filter and it is adding .001 to the value in the B marker.  Then it is acting upon one extra frame that you don't want affected by the filter.

[eumagga0x2a]

Let's say you have two parts of a video (the start in one file and the end in another) and they overlap in the middle.  So you load the first file, append the second one (or maybe use an external program such as ffmpeg to combine them, doesn't matter), and then you go to the first occurrence of a frame that's in both parts and set the A marker.  Then you go to that exact same frame in the second part and set the B marker.  Then you delete the section indicated by the markers.  The frame that the A marker was on will be the first one deleted, while the frame that the B marker was on will be the first one kept after the deletion.

Nothing has changed here, it works exacltly as you describe. The recent changes affect saving (exporting) a selection, not deleting it.

But if that were true at the end of the file, you could never get rid of the last frame, and I've always been able to get rid of the last frame, so that's why I thought there was an exception if the last frame is at the end (that is, if the B marker is set to the very last frame in the file).

Right, I introduced this exception (now removed) for exactly the same reasons. This means, that a different action needs to be taken to facilitate extending the B marker past the last frame.

What I have never checked to see is if you press the button to go to the end of the file, does that actually set the B marker to a time that is slightly beyond the last frame?

Going to the end (to the last frame) of a video obviously doesn't touch markers, but setting the B marker to the last frame works the same way as for any other frame, i.e. it is necessary to reset the marker (set it to the total duration of the video, usually equal the PTS of the last frame + time increment of the video) for the last frame to be included into output when saving.

[eumagga0x2a]

In the fresh set of nightlies, the handling of the end point of a range in partial filters has been aligned with the handling of the B marker when saving a selection.

[Who]

In the fresh set of nightlies, the handling of the end point of a range in partial filters has been aligned with the handling of the B marker when saving a selection.

Thank you, I really appreciate that, having to remember to deduct that .001 was driving me crazy!

[eumagga0x2a]

It was szlldm who did all the work :-)

[Who]

It was szlldm who did all the work :-)

A big thank you to szlldm then, for fixing this!

[Who]

Unfortunately, there is another big problem with partial filters now, please see my post in the "Avidemux2.7.9 - Latest dev Version thread".

[eumagga0x2a]

A new nightly containing the presumable fix is available, please try it.