Thanks for files.
As far as I can see, this is same issue as T95683.

This was intentional change to allow retiming strips in a way, they can start and end at what would technically be subframe. Thanks for reminding, that this causes issues in existing scripts - added entry to release notes now.

ah ok! sorry didn't check commits but only logs. i have to update my scripts then ;)

The change looks intentional in rB302b04a5a3fc0e767ac784424f78ce2edf5d2844.
But I guess it should be added to the release notes regardless.

Sorry for delay, and thanks for new report, will check it out. This one I will close since other media players have trouble processing it too.

Thanks for investigating. Looking at your video files leaves me asking if this is a render output? I have problems with the preview. I use this overlaying method to find frames where the preview of the edited original (buttom layer) is different to the upper layer (render result). If I find one I refresh and see if it helps, often it doesn't. Rendering the composition of the two layers as video however does not show a difference, which suggests to me that the preview is off. Here is a screenshot of the preview + render result (right after refreshing, using currrent alpha version)

Ok, taking a step back from this. I reported a bug because I had problems with glitches in the Preview with different files. I chose a file that was most problematic/easy to reproduce. It turned out to be broken or at least not straight from blender. But I experience problems with other files, too. Its better in the alpha (when refreshing often). Now I do not know, should I investigate more into other video files or is it a known issue that the preview is not perfect?

In T100495#1407178, @Michael (wammerl) wrote:

My current understanding of this problem is, that file you have provided is broken, and I am 90% confident, it has either not been rendered with Blender or has been re-encoded at some point.

When looking into the working files I saw that for this specific project I used blender to render the picture and audio separately. Making some post production to the audio and then putting picture and audio together using VLC Mediaplayer. I did this only for this one project and forgot about it. I am Sorry! (If you want I still can upload the rerender)

We have implemenmted a fair bit of workarounds for seeking issues which unfortunately come in many forms. You would see that frame is off and refresh mostly works, but this is mostly true for all sorts of causes.

In any case I don't have file Alpha_CameraMP4Test.mp4, I assume I have to render it from file MVI_7312.MP4, is that correct? I did that and did not see any problem.

Better way to check for errors is color mix effect strip with difference mode and then multiply colors to better see tiny details

So if original strip and render are aligned here is difference:

Without colors being multiplied, you would see almost nothing, and what you see is pretty much loss of quality due to encoder optimizing the image. Perceptually lossless is not quite lossless.

Here I intentionally misaligned strips so there is 1-frame offset:

It would be quite obvious if any frame is misalligned

also here is my .blend file for reference:

T100495.blend615 KBDownload

My current understanding of this problem is, that file you have provided is broken, and I am 90% confident, it has either not been rendered with Blender or has been re-encoded at some point.

When looking into the working files I saw that for this specific project I used blender to render the picture and audio separately. Making some post production to the audio and then putting picture and audio together using VLC Mediaplayer. I did this only for this one project and forgot about it. I am Sorry! (If you want I still can upload the rerender)

In T100495#1407031, @Michael (wammerl) wrote:

So far it looks to me, that the provided video got corrupted somehow. Are you able to re-render the video with Blender 2.82? At least a portion of it?

The video file I uploaded was somewhat chosen by random. I just tried another file from 3 month later and one from 6 month before (not sure with blender version was used but i use most recent usually). They all have issues in 3.2. Current alpha is much better but i still felt like the preview glitches after a few split cuts. And after a refresh I also found cuts being off by a frame or two. Regarding this information what should do next? Regarding your question: I think I could rerender the file from the bugreport but as mentioned I do not feel its just this file.

So far it looks to me, that the provided video got corrupted somehow. Are you able to re-render the video with Blender 2.82? At least a portion of it?

The video file I uploaded was somewhat chosen by random. I just tried another file from 3 month later and one from 6 month before (not sure with blender version was used but i use most recent usually). They all have issues in 3.2. Current alpha is much better but i still felt like the preview glitches after a few split cuts. And after a refresh I also found cuts being off by a frame or two. Regarding this information what should do next? Regarding your question: I think I could rerender the file from the bugreport but as mentioned I do not feel its just this file.

Thanks for files.
Since it was saved with version 2.82, I have tried to render sample by adding own material to timeline. However even if I render with version 2.82, I get very different metadata:

Some actual solutions were described here, instead of removing the very useful Sequencer & Preview mode: https://developer.blender.org/T92584#1251138
Btw. no channel headers are implemented in the Sequencer & Preview mode either, afaik.

Can you upload the original project file? I would like to reproduce this issue and fix encoder settings if this still happens. I need the file, because it should contain blender version it was last saved with, unless you re-saved file in newer one.

sorry if this is leading away from the orignal bug. i feel like it is related.

Can you upload the original project file? I would like to reproduce this issue and fix encoder settings if this still happens. I need the file, because it should contain blender version it was last saved with, unless you re-saved file in newer one.

the video was rendered with blender on windows 10. i usually use the render preset from power sequencer and i am pretty sure it was the case for this video as well. I found the 2year old projectfile. Here is a screenshot of the render settings:

In T100495#1406008, @Michael (wammerl) wrote:

When trying to work around this bug i tried everything i could think of. Proxies, No Proxies, Prefetch Frames, etc. No solution

ah, I am too slow... :)

T92584: Mixing sequencer and preview regions causes logical problems is related

This is by design, or rather lack of design, see T92584. But in any case it is not a bug and since this is documented in form of design task, I will close this report. Thanks for reporting though.

You have mentioned, that this is video rendered with Blender - is this original file you have stored on HDD or is it downloaded from some service like Youtube? Some(most?) of these services do re-encode original files to save up storage space and may do some tricks to optimize seeking perhaps. but I think they should still be playable.

here you go! a messed up file. only split cuts no editing done to it. all i did was performing the described steps from my bugreport.
to reproduce this bug i loaded factory settings!
When trying to work around this bug i tried everything i could think of. Proxies, No Proxies, Prefetch Frames, etc. No solution

@Michael (wammerl) I was able to reproduce the issue, just quickly looking at debug output, seeking is definitely way off with this file. I am not sure why yet.
You have mentioned, that this is video rendered with Blender - is this original file you have stored on HDD or is it downloaded from some service like Youtube? Some(most?) of these services do re-encode original files to save up storage space and may do some tricks to optimize seeking perhaps. but I think they should still be playable.

The operators are also not registered in this case, so hotkeys dont work either.
Would assume this is a Known Issue for now @Richard Antalik (ISS)?

Can you also upload .blend file?

@Antonio Vazquez (antoniov) hi, if this is a known issue, can we mark it as "confirmed"?

Note for fix, to observe effect, set codec to different one and back to DNxHD.

@Pratik Borhade (PratikPB2123) Can you still reproduce this? There have been some changes, but not sure if this could be resolved by them...

Opening again, setting to Confirmed, since fix just posted was for master 3.4A only. Have a patch for prior versions to be approved.

ah, ok thank you

Effects are like "render composition"...so, these are only visible in the render and never in any preview mode.

I definitely see this issue in master, but caused only by {c0845abd897f}. This would only affect 3.4. It would be a simple correction to fix master.

In T100441#1404654, @Antonio Vazquez (antoniov) wrote:

I guess that maybe with the Eevee next we can fix it.

I guess that maybe with the Eevee next we can fix it.

for rendering it's working but in preview not, isit planned to break this limitation in the future 'by offering options default + others '

@Philipp Oeser (lichtwerk) - Harley might be interested as well.

This is a known limitation. The problem is the Tint only is visible if Shader attribute mode is enabled, but as the VSE scene is different, the Tint is not enabled. Did you try in render if you get the right result?

I have raised the prio here (since it turned out that packed fonts are totally broken in the VSE)

There also seems to be a problem accessing font->filepath in blf_font_new_from_mem > blf_font_new_ex [which is NULL] (at least in this case), so not sure if rB523bc981cfee just exposed another issue in font code).
@Harley Acheson (harley) might be interested as well.

Caused by rB523bc981cfee: Fix loading packed fonts for sequencer strips

The fix has been pushed to the 3.3 release branch.
Feel free to reopen if the issue persists.

• Set curve handles to auto clamped by default

Try in 3.4 Alpha. Here is seems to place the clips at mouse point when dragged from OS(Windows) folder.

This is changed in {b010985e4ac49a98e12802567efdf6b38f7b5bf2}
but it's not pushed to 3.3 branch. So issue still remains in 3.3 beta version.
cc @Sebastian Parborg (zeddb)

Thanks for the report I'm able to reproduce this. Checking...

In D14412#424815, @Sergey Sharybin (sergey) wrote:

For overshooting, I am not exactly sure what was requested, but gain is now limited, so I assume this is resolved.

See how the "Auto Clamped" interponation works for F-Curves.

Basically, curve should not go above the control point. This is not the case between the 2 left-most CVs on the picture.

For overshooting, I am not exactly sure what was requested, but gain is now limited, so I assume this is resolved.

Just heads up, until @Marcos Perez (pistolario) returns from vacation, I will take on this patch

Rebase

Thanks for the update.

Gif file format is not supported in Blender. From what I can see nor for reading or writing. Since this is not implemented, it's not a bug in current behavior. Closing as this bug tracker is only for bugs and errors.

Changes:

• little optimization of code
• little tweaks to the UI
• Implemented as "minimum phase filter"

Duplicate of T99812.

Duplicate of T99812.

Ran make format on the affected files

CC @Joerg Mueller (nexyon)

Unfortunately, such video formats are not supported. Blender assumes static image size. Will close since this is not a bug.

hhhh this will be really big feature

Be sure to run make format before landing the patch, as that causes some changes in anim_markers.c.

Looks like constant_rate_factor is set to FFM_CRF_MEDIUM, which shouldn't happen for DNxHD codecs, as it causes crf to be set in the FFMPEG options.