Ah, thanks for the clarification! :)

Turns out, I was wrong. The issus got a bit better, but there still is a significant slowdown happening.
I have prepared a file with the default world, no lamps, just the 2 objects (camera and mesh from your file). There are 2 keyframes, on frame 1 it renders fast, and frame 2 it renders slow.
I have tested with latest master as well as 2.79a. So I would say, bug confirmed.

Wow, what a weird file! I can confirm there are differences in render time, but could not figure out why. I tried with not light source, with a different camera, with a different world, with no materials.
Still the same problem, in some rotation it renders really fast, and then, the more I increase the rotation, the render time increases as well.
It also doesnt depend on the camera angle, since rotating the object and the camera together still produce the same issue. However, copying the object and the camera and pasting it in a different file seems to eliminate the problem. Weird!

@Dalai Felinto (dfelinto) I am wondering if it even makes sense to have an EEVEE setup at this point. As far as I can see EEVEE does not have something like a shadow catcher, nor can collections ins view_layers be set to holdout, which is both kind of important for a working setup. So I would first make it use Cycles.

I have managed to make the Setup_Tracking_Scene operator work without errors by disabling the old BI and layer stuff, now I am trying to make the renderlayer setup work again.
However, it seems as if there are some python bindings missing still.
To make the setup work I am planning to have 2 Viewlayers, Background and Foreground (as was already implemented in the new script), with two collections, "background" and "foreground". In the Foreground viewlayer, the background collection will be set to "holdout", in the Background view_layer the foreground collection will be set to indirect only.
I can make the setup work with the outliner View_Layer menu, however I could not find a way to do that via python. Something like bpy.context.scene.view_layers["Background"].collections["foreground"].holdout = True
That or at least something similar does not seem to exist yet.
Or if it does, maybe someone can give me a hint?

I will have a look. Maybe first just kick out all the old stuff so that at least the basic setup of constraints and background images work. Speaking of which, the whole camera background image stuff doesnt seem to work all that great yet. Footage is always drawn in front of objects, no matter the front/back setting in camera background images. Also the colors are completely off in solid mode.

As mentioned before it's a very useful feature, also works great after a bit of testing. So I guess from artist's side it can be committed! :)

The last revision that worked was this: https://developer.blender.org/rB59b4c675361b54b32b6238855fe4a82117cc48c7
Starting with this commit Blender hangs when using a filepath directly: https://developer.blender.org/rB08274433e1bd9db5a2a27e5d2f8862e9cc3f27f0
Maybe @Bastien Montagne (mont29) wants to have a look? :)

This one looks really useful, also works great. :)

It's an interesting feature. But I would want to be able to set the amount of frames that are blended and also to be able to turn it off. I think it could also be an extra operator with separate shortcut, or maybe a mod to G (like the operator modes of knife tools). Or it could be a mode to enable, like proportional editing.

Please attach a blendfile with the bug, otherwise we have no chance of looking into your issue. Also, please provide the information required in the bug report guidelines.

Let me guess: You are not in edit mode when you press "W"? However, that's hard to tell, since you did not attach a blend-file, as required by the bug reporting guidelines ;)

This is not a bug. The renderer has nothing to do with camera solving. The fact that you got different results has to do with slightly different positions of your markers in the 2 different attempts. In fact the position of the tracking markers is your biggest problem.
In the video you had put the markers only on a flat plane, and only in the very center of the frame. That's a problem. Instead you should try to cover as much of the frame as possible, and also different heights, not just a plane. In your example don't just track the markers in the center of your frame, but instead also track for example the scissors, the pencil, the background objects.

I tested it with latest master on elementaryOS 0.4.1. and it renders a nice and round ball.

Did you also try with the most recent version of Blender from builder.blender.org?

Just noticed that also the eyedropper tool to pick other things like parent objects, camera focal distance etc. doesnt work anymore.

@Sergey Sharybin (sergey) Thanks! I tried the patch, but it did not work. Neither the MCE nor the IE can open the image. If I try, it gives me an error: IMB_ibImageFromMemory: unknown fileformat (/home/sebastian/1-38_A002.0000811.dpx)
I'll open a report.

What a pleasant coincidence! I just had the problem a few days ago that I could not load a DPX file into Blender which I got from some other application. I used EXR instead as workaround. But I tried the patch and that actually works (even though the frame itself is flipped)! Here's a frame from the sequence that did not work:

This is most likely the same issue as this one: https://developer.blender.org/T52802
And that one is confirmed and still open, so marking this report as confirmed as well. Not sure what the correct policy here would be though...

Here's a fix that seems to work:

True. I'd also consider this a bug. Not a dramatic one of course, but it is indeed an inconsistency...

That patch works great, thanks a lot! :)
But man, the ToS footage was soo much better than the one I have to deal with right now...

Oh alright, sorry. Thanks a lot for the answer! :)

Yeah, I agree. Also, playblast from viewport should ideally not be affected by filmic.
Although, thinking about it, it probably is not really a bug, but rather a TODO…

Please follow the bug reporting guidelines and make sure you include the following information in your bug report:

Yeah, I am currently suffering from the same problem. I think it's mainly a problem with the very bright intensities of glossy reflections. At least in my case it doesn't need any SSS to produce the issue, just a rather reflective surface. I am facing this problem mostly with metals in scenes with bright lamps. I think the denoiser somehow tries compensate for the brightness differences between the glossy reflection and the much darker surrounding areas, and by overcompensating that brightness differences it makes the problematic areas black. Or something like that. No idea how to solve that but maybe as a workaround the denoiser could just keep the super bright highlights just white?
Here's the above file but without SSS and point lamp, but with a metal surface, still producing a black artefact.

Oh that's right, I did not test previous versions before. Probably never worked, at least not in 2.77 which I just tried.

Yes, here is a file demonstrating the issue (GTX980ti here, on linux).

Yeah, it's true. Not quite sure if it's actually a bug, but it's annoying nonetheless. However, I think we can be sure that it will be more than fixed in 2.8 ;)

I didn't test this yet, but I can see how this can be quite useful, especially in large and complex nodetrees with long noodle connections, where you want to compare the effect of a node input with the original node input value. Visually it is consistent with the red color of the mute node functionality and seems pretty straight forward to use.

At least on a GTX1080 with Cuda on Linux and latest master it does not happen. So probably it's more an issue with AMD Cards, OpenCL or OSX.

Thanks for the report. However, this is very similar to a recent report about custom transform orientations, which turned out not to be a bug. Especially Extrude works totally as intended. See my answer in the other report here: https://developer.blender.org/T52558
It might be a bit counter-intuitive (though thinking bout it I wouldn't even agree to that), but it's not a bug, therefore I am closing this.
Unless you find another case except extrude where custom orientations do not work. If so, please describe in detail where and when it happens.

Yep, turning off AO solves your problem. No bug here, this report can be closed then, I guess...

It seems to me you are trying to open an OBJ file, which for some reason got renamed to .blend. Anyhow, without the attached file we cannot reproduce or test your bug report.
Also, please use the bug reporting guidelines, otherwise the report is considered incomplete.

Yeah, just displaying the finished tiles is totally fine. @Brecht Van Lommel (brecht)'s solution takes up even less space in the interface! Win-win! :)

I replied in the other report as well.
And yeah, I also think it should be changed. It might not be a code bug, but a grammar bug it definitely is. For instance it says it is working on tile 11 from 12, when it is actually working on tile 12 from 12. A bit confusing for the user.

I think that is actually weird as well. If I have 12 tiles in total it would report "Path Tracing Tile 11/12" when working on the very last tile. Isn't that confusing for the user? It says it is working on tile 11 from 12, when it is actually working on tile 12 from 12. So maybe not a bug code wise, but definitely a grammar bug ;)

The shadow catcher is indeed only catching shadows, as the name suggests. It will not pick up any reflections.
Of course it would be nice if it would catch every aspect of light interaction, but so far the shadow catcher doesn't do that.
So, not a bug here, as far as I can see.

My guess is that it could be a problem with extreme clip_start, clip_end settings in your view panel. But to check that you would need to attach your blendfile, if possible.

Sure! And a well written, detailed bug report never hurts, even if it turns out that it wasn't really a bug! So, cheers! :)

I don't think this is really a bug.
Extrude is actually a combination of 2 actions:
First it creates the new face, connected to the previous one.
Then it jumps into translate mode, with the face normal set as lock axis. For extrusion it usually makes the most sense to have the movement follow the face normal.
However, if you press Z the first time, it will "free" the axis lock, meaning that if you keep on moving the newly extruded face it will follow your mouse cursor in any direction.
If you press Z the second time it will move the face along the global axis, and if you hit Z the third time it will set it back to extrusion along the face normal again.
If you don't like the behavior, simply press Esc right away after Extrude and then G+ZZ to move it along your custom axis orientation.

Yeah, that's true. It's weird, the meshes are also note really broken nor do they have flipped normals, so I don't see why it shouldn't work here.
I also noticed it myself that sometimes Carve works better than BMesh for no apparent reason.

Yeah, I can confirm that.

This looks more like a feature request than a bug. There is no broken feature here that doesn't work as intended, but something that you miss as a feature.
I think it should still be possible to use the previous filmic blender config the same way you did before.
I am pretty sure that for 2.8 the whole color system will be investigated and improved anyway.

I am not sure if this task includes the compositor, but I'll post it anyway

It's true, happens here as well. It is a bit weird indeed. Every other draw type has a far better performance than solid draw type, be it wireframe, textured view, material view, bounding box. Just solid draw drops to about the same speed as if I join everything to one mesh, modifiers applied and switch to edit mode.

It would be interesting to see a file where it does work as expected. Because having the same case sometimes work and sometimes not seems weird. Would be interesting to see why :)

As a follow up to this:
Blender is in fact doing a bit of color management stuff with your alpha channel somehow. Or something else is going on.
Anyway: If you duplicate the node with your image (prop_shield_01_sg.tif), set the new node to non-color (as you did with your roughness map input image). Then you can use the alpha channel the way you want. However it will look differently than with the image you saved (the previous alpha channel, prop_shield_01_sg_a.png). Reason is that when you saved the alpha channel as an image, Blender was in fact applying the current colormanagement viewtransform to it.
You can simulate the same effect though when you add a gamma node with 2.2 after your non-color gloss+roughness map alpha channel output.

Thanks for attaching the blendfile.
You're right, it should work. I didn't properly double check the alpha output after disabling the "use alpha" option. So yeah, looks like a bug indeed. :)