It could be a context toggle like in the viewport, when a new mesh is added. Settings are manteined if changed once.. so the text font and alignment could stay the same once its font, color, position and alignment are changed.

In D2424#65827, @Campbell Barton (campbellbarton) wrote:

Some questions this patch raises.

• As Gottfried says, wouldn't it be better to use font data blocks instead of every user having to set the file path? This will become annoying fairly quickly if you ever want to change fonts.
• BLF_MAX_FONT is currently set to 16, after this patch is applied its likely someone will hit the limit, although it's best to handle this in a separate patch.

Some questions this patch raises.

• As Gottfried says, wouldn't it be better to use font data blocks instead of every user having to set the file path? This will become annoying fairly quickly if you ever want to change fonts.
• BLF_MAX_FONT is currently set to 16, after this patch is applied its likely someone will hit the limit, although it's best to handle this in a separate patch.

Hello developers,

I've had similar issues, in metastrips the opacity keyframes seem to disappear when the strip is condensed, reappear when expanded, and also I think it is related to the phenomenon that when scene strip (i.e. from scene A) is added to a new scene (i.e. scene B) as a metastrip (i.e. "use sequence") keyframes for both transform and opacity will become lost or corrupt for playback or rendering in scene B when the meta version is moved to in the timeline. It makes it impossible to rely on meta or scene strips at all for their intended purpose.

Are there any errors in the Command Prompt? This can be found with:

Thanks for editing, but we are still missing some demo files (at least video one) to reproduce the issue.

… and please follow our submission template and guidelines and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

@Sergey Sharybin (sergey) thanks, sounds clear enough to me :)

@Bastien Montagne (mont29), i'm not sure what is motivation in current code, but think OpenGL Preview is a historical redundancy from times when it was the only option to switch between final render and some shaded mode. Think now we need to remove that option and make internally things behave like:

I can't seem to have that problem with Arch Linux

Hmmpff… fact is, Image editor is not really designed to play videos, it does not even use proxies afaik. You should rather try to Clip Editor if you need an extra viewer for some reason, and set there the proxy & timecode settings just like in the VSE. Then (obviously!) stop and start playback again.

@Olly Funkster (Funkster) Spot on ! :) Nevermind, it's working when I manually enter the absolute path, selection from file explorer is still buged though...

Have you tried specifying an absolute path for the font?

Well that's surprising since I'm also using build 2.78c as the source. I redownloaded a clean 2.78c source this morning and did all the process again (manually adding the code shown below then compiling) and I still have this "Can't find font: //folder/font.ttf" error. As for now I can't figure what I did wrong.

I have this patch in my local builds (Fedora) and it works fine. Admittedly my source isn't really up to date, I think it's hovering somewhere close to 2.78c. It's been a while.

We definitely need that feature !

Indeed, I did not notice this box.
I tried again with several of my videos. This time, I manage to get a consistent behaviour (meaning that I always got the same result irrespective of the video I picked up).

Hmmm, afaik by default the Not TC In Use option is set for timecode, which means you are not using it. Typically, you’ll want to try with Record Run No Gaps option (same panel, below the proxy settings). Then rebuild proxies/timecodes, and check if issue is still there?

Thanks for your email.

• Did you enabled AV-sync synchronization mode in TimeLine editor's header bar?**

Yes

Difficult to help really without a simple .blend file to reproduce the issue, but two things to check:

1. Did you enabled AV-sync synchronization mode in TimeLine editor's header bar?
2. Did you generate valid timecode for your video?

Sorry for not responding earlier, but I was on vacation and didn't have access to my computer. Unfortunately I was not successful at reducing the file size while keeping the bug reproducible, so I have made a torrent of the file as is. I know it's quite bothersome to ask anyone to download 80 GB, so I can understand if you don't want to do it. I will keep trying to cut the file size down in the meantime.

Thanks for the suggestion, but we do not accept feature requests or suggestions on this tracker (use forums or bf-funboard ML for that).

Please use this bug tracker for reporting bugs. General discussion and inquiries like that shall go through IRC (#blendercoders on freenode.net) or ML (bf-committers@blender.org).

Hum, I don't want to seem pessimistic, but there have been already several attempts to make the sequencer faster. They've succeded a bit but it's indeed not enough compared to specialised softwares's performances.
From what I've heard it's very old code that is very hard to improve.

Currently the VSE is largely in a maintenance only mode. On your points:

Confirmed, looks as if premultiplied alpha is not being taken into account properly when doing the color space conversion.

I've tested with a recent 2.78 nighlty build. Buit on Sat Jul 15 04:29:23 2017, name: blender-2.78-8009564503-linux-glibc219-x86_64