Hello, welcome everyone to this course on Fourier analysis and applications and this is a course that is very popular among undergraduate students. No doubt you are seen vestiges of Fourier series in your undergraduate curriculum particularly while solving boundary value problems for various partial differential problems, particularly the Laplace's equation, the heat equation and the wave equation. So, you solve the Laplace's equation on a circle on a disk or the wave equation on a square etcetera and the technique is very routine. You try to expand the function as a Fourier series, a fairly general function f of x, you try to write it as a infinite superposition of sines and cosines namely f of x equal to a naught plus summation n from 1 to infinity a n cos n x plus b n sin n x the displayed equation 1.1 on the slide. Before we plunge into the theory behind these kinds of expansions, the Fourier expansions let us trace back to the early genesis of this theory of Fourier series. So, let us look at certain early trials and a little history. It always helps to start a course with a little historical background as to how it all began. A very important historical source from which I learned some of these things is this book of Ivor Gratin Guinness, Convolutions in French Mathematics 1800 to 1840 volume 2. This is in 3 volumes, the second volume is what we are talking about the turns. The book was published by Berkhauser in 1990. Let us look at a few aspects during the nascent stages of the development of Fourier analysis. The page numbers refer to this book of Gratin Guinness. Experts are expressing a fairly general function f of x as a series of the form 1.1 that we just saw predate Fourier by at least 50 years about half a century in the works of Daniel Bernoulli and Leonhard Euler. Again in connection with physical problems about vibrations and such. The perplexing issue was the following. How can a series of 2 pi periodic functions? All these functions sin x sin 2 x sin 3 x cos x cos 2 x cos 3 x they are all 2 pi periodic smooth functions on the real line. How can a superposition of such 2 pi periodic functions produce in general a priori non-periodic function? This problem seems to have languished in the state of affairs until the time of 4 year. Fourier's researches were pervasive in advocating the method of separation of variables. So commonly found today in modern undergraduate courses in PDEs. The method of separation of variables and the idea of using Fourier series of the expansions in terms of sines and cosines was not popular in as much as the solution presents itself in a form in which the boundary conditions remain masked in the coefficients of the expansion. Remember what do you do? When you write this method of separation of variables you get the solution as an infrared series and the coefficients are determined using the initial conditions of the boundary conditions etcetera. So the side conditions that you have when you solve a PDE they get incorporated and it is these coefficients of the sines and cosines that encode this information about the boundary data. So that is what I that is what it means when I write that the solutions present themselves in a form in which the boundary conditions remain masked in the coefficients of expansion 1.1 the a n's and the b n's. In contrast the functional form was preferred such as the Poisson's integral representation for solutions of the Laplace's equation of D'Alembert's solution of the wave equation in one space dimension. There you see the solutions written as integrals and the integrals involve directly the boundary condition or the initial conditions. Fourier also obtained interesting series expansions such as the one displayed in equation 1.2 in the slide that you see. Here you see the number pi by 4 has been written as a series of cosines and this is valid in the interval 0 to pi. Of course Fourier was well aware of the convergence issues there are subtle issues and he established rigorously the convergence of this equation of the series that appears in 1.2 and likewise issues pertaining to completeness also cropped up. Besides trigonometric functions Fourier also employed Bessel's functions in the summons of his series. This point was acknowledged by Lommel and Heiner. Lommel and Heiner were two significant contributors to the theory of Bessel's functions and this use of Bessel's functions by Fourier was acknowledged by Lommel and Heiner proposed the name Fourier Bessel's expansions for these. Now let us go to the researches of Lesion Dirichlet, Jordan and Paul Dubois Raymond. The first significant step towards the general convergence theorem is due to Dirichlet in 1829. So what did Dirichlet do? Dirichlet proved the first point wise convergence theorem. So for what kind of functions did Dirichlet prove the theorem of point wise convergence? He took functions which are piece wise continuous and monotone. So you take the interval minus minus pi to pi you chop it up into finitely many pieces and the function is continuous on each piece and it is monotone on each piece at the junction of between two intervals the function could have a jump discontinuity. So you could have a function which is defined piece wise and each piece is monotone the pieces may not join up continuously. At points of continuity the Fourier the series converges to the function f of x. At points of discontinuity the series converges to the arithmetic mean. We shall prove this theorem of Dirichlet rigorously at a later point in the course. We need some preparations such as the mean value theorem for integrals due to Bonnet. Dirichlet was of the view that the failure of point wise convergence would stem from some lack of integrability or the function f whose expansion is being sought. Jordan generalized the results of Dirichlet to include functions of bounded variations. We shall discuss later in detail what functions of bounded variations mean and we shall give that precise definitions later. In the year 1873 Paul Dubois Raymond produced an example of a continuous function whose Fourier series failed to converge. So even continuity or the function does not guarantee the convergence of the Fourier series. It is a very important point to be kept in mind. Continuity alone does not suffice and I have given a reference to a book by Kehane and others and I have listed all the three authors. The complete reference will be available in a few slides to follow. Let us look at some 20th century milestone. In 1926, A. N. Kolmogorov found a function in L1, L1 is the Lebesgue space, L1, L2, Lp these are the space of functions which are Lebesgue integrable on the closed interval minus pi pi. So Kolmogorov found a function which is integrable which is Lebesgue integrable on minus pi pi whose Fourier series diverges everywhere and N N Luzin conjectured that the Fourier series of a function in L2 must converge point wise almost everywhere. In particular, if you take a continuous function from minus pi to pi, a continuous function is in L2, right. A continuous function from minus pi to pi is obviously in L2. So although Dubois-Reymond established that the Fourier series of a continuous function may diverge, it must converge almost everywhere. That is the set of places where the Fourier series diverges has set of measure 0. The conjecture of Luzin was finally settled decades later by Leonard Carlson, it is a monumental achievement, later it was generalized by Hunt for Lp functions where p is strictly bigger than 1. These are some of the 20th century milestones. Let us move a little further and let us see after Dirichlet, in fact there is a bit of anachronism, we are going back to the 19th century here. We are going back to Bernard Riemann. After Dirichlet, the study of Fourier series was significantly furthered by Bernard Riemann in his habilitation shift which he wrote in 1854. In 1859, there appeared his epoch making memoir on the distribution of primes and the Riemann zeta function, where he gives a proof of the famous functional equation that bears his name and he gives two proofs in fact for the functional equation and one of them uses Fourier analysis. Basically what he does is that he derives the theta function identity of Jacobi and he uses the he via the melaintransform that theta function identity goes over to the functional equation for the zeta function and the theta function identity itself can be established via Fourier methods, namely you solve the heat equation in two ways using Fourier series and Fourier transforms and you compare the results invoking some uniqueness theorem for the initial value problem for the heat equation with periodic initial conditions. The theta function identity is as I said is related to the functional equation of the zeta function. Of course Riemann's memoir opened up as we know a new vista in the theory of analytic number theory. The pervasive nature of Fourier analysis, the theory of Fourier series and Fourier transforms has been profoundly generalized and its use extends far beyond the purpose for which it was originally invented, namely for solving partial differential equations. Today Fourier analysis is an indispensable tool in several diverse areas of mathematics such as probability theory, number theory, geometry to name a few. Besides the book of Gratton Guinness, the authoritative account of Kahane and Lemaire ought to be consulted for any serious understanding of the historical developments of the subject. The three of this book of Kahane and Lemaire is devoted to the work of Riemann. The discussion of Riemann's work can be found in this particular chapter 3 of this book. Let us now look at the impact of Fourier analysis in the late 19th and early 20th century mathematics. Fourier analysis provided much impetus for the development of point set topology as well as the development of measure theory. In fact, the significant researchers of Georg Cantor in set topology in the late 19th century and early 20th century was due to his interest in problems originating in Fourier analysis. There are two references for this that are very important. One is by A. Keshiris set theory in the uniqueness of trigonometric series and this a reading of this would be an excellent project for a student in the master's level. The second reference that I would like to point out is Roger Cook's beautiful article a somewhat lengthy article, but a very very comprehensive article on the uniqueness of Fourier series and descriptive set theory and he spans more than a century 1870 to 1985. It appeared in 1993 in the archive of the history of exact sciences and let us begin with the first chapter the basic notions. Let us go through the plan of the chapter. In this chapter we focus on the following. We look at a class of 2-py periodic functions of the real line. There are Lipschitz continuous and Holder continuous of exponent alpha. Now by the way these words which appear in blue are new concepts and concepts and like Lipschitz continuity, Holder continuity, Riemann, LaBaglama they will be highlighted in blue and names of references will be highlighted in purple. So, Lipschitz continuous functions and Holder continuous functions they will be defined later. We prove a fundamental theorem called the Riemann LaBaglama for functions in L1. The Riemann LaBaglama says that if you take a function which is in L1 then the Fourier coefficients will decay to 0 as n goes to infinity. This is a very important step in the proof of the convergence theorem. Then we will derive an expression for the so called Dirichlet kernel and the behavior of the Dirichlet kernel is extremely important with regard to the convergence of the Fourier series. We must examine the nature of the singularity of the Dirichlet kernel. The Dirichlet kernel is an oscillatory kernel. It is a highly oscillatory function near the origin and it is these oscillations and the mutual cancellations that are to be studied very carefully. And we will also try to understand the obstacle to proving point wise convergence. When the function is merely assumed to be continuous and nothing more the argument breaks down. Whereas, if you have a little extra regularity such as Holder continuity or Lipschitz continuity then we can prove the convergence theorem. The singularity in the Dirichlet kernel is to some extent destroyed by this Holder continuity or Lipschitz continuity or whatever. Let us look at a simple example of Lipschitz continuous function. What are the Lipschitz continuous function? Let us recall a function is said to be Lipschitz continuous if mod f x minus f y is less than or equal to L times mod x minus y. Formal definition will come later. I will just speak the definition out in a later slide we will put it down it will appear explicitly. So, you have probably encountered Lipschitz continuity in your courses particularly in your course on ordinary differential equation where we prove existence uniqueness under a Lipschitz condition under a Lipschitz hypothesis. So, one of the popular conditions to impose in the function is Lipschitz continuity. So, let us look at a simple example of a Lipschitz continuous function take cos A x on the interval minus pi pi is a smooth function on the on the interval minus pi pi and it is an even function being an even function it takes the same value at minus pi and pi. So, what I do is I simply take the 2 pi periodic extension. The 2 pi periodic extension is just a bunch of arches one following the other, but at the at the at the junction from minus pi to pi and from pi to 2 pi at the point pi this extension will not be differentiable, but it will be holder continuous it will be in fact, it will be even be Lipschitz continuous. So, the 2 pi periodic extension of cos A x is an example of a holder continuous function. So, the basic convergence theorem that we prove will hold for this cos A x. So, if you take this function cos A x and write the Fourier series for that we are going to get this expression we are going to derive all these things later just I am just giving you a sneak preview of what is going to come. Cos A x is when you write it as a Fourier series the constant term is sin pi A upon pi A. Since cos A x an even function in the Fourier series will only contain even functions. So, the sin n x term will not be there at all. What are the coefficient of cos n x you see displayed out there minus 1 to the power n upon A squared minus n squared and there is a common 2 A sin A pi upon pi for all the terms that has been pulled out of the summation sin. So, here is a Fourier series for cos A x and this is going to be true for all values of x because cos A x is the 2 pi periodic extension of cos A x is Lipschitz continuous on the entire real line. So, I am allowed to put whatever value of x I want and this equation will be valid. So, let us put x equal to 0 put x equal to the left hand set becomes 1 and the right hand set instead of cos n x I simply get minus 1 to the power n upon A squared minus n squared and a little rearrangement will give you this partial fraction expansion or the Metag Leffler expansion for cosecant pi A. The partial fraction decomposition for the cosecant can be derived using Fourier series and you see displayed cosecant pi A equal to 1 upon pi A plus 2 A by pi summation n from 1 to infinity minus 1 to the power n upon A squared minus n squared. Similar expansions for cotangent and other things can also be derived using just the basic convergence theorem we prove the basic convergence theorem and these are some of the corollaries that we can derive. So, it gives back some very beautiful formulas in classical analysis using these expansions using these Metag Leffler expansions we can find for instance special values of the zeta function. We shall discuss the special case of the Poisson summation formula for the using the Gaussian. We take the Gaussian and we use the Gaussian to cook up a 2 pi periodic function determine the Fourier series and will derive a special case of the Poisson summation formula and will also derive the Jacobi theta function identity. As mentioned earlier this is equivalent to Riemann's functional equation for the zeta function. We will also discuss the Bernoulli numbers and will obtain a generating function for the Bernoulli numbers and we shall get special values of zeta functions. We close the chapter with a discussion of the generating function for the Bessel's function of the first kind. We will recall what the Bessel's functions are using ordinary differential equations. So, there will be a slight bit of digression to get the requisite Bessel's function identities recursion formulas for the Bessel's function and these Bessel's functions will be embedded into a power series and a generating function will be determined in closed form using Fourier analysis. And later in a later chapter we will use these in a in an application to a problem in celestial mechanics. Now this concludes the historical sketch of the early genesis of Fourier analysis and also the plan of the first chapter that we shall be studying. So, now let us formally begin the chapter 1 the basic convergence theorem. So, to set the stage let us begin with the 2 pi periodic function f from r to r which at present is quite arbitrary except that over the interval minus pi to pi the integral exists. Now it is extremely important to use the Lebesgue integrals in our discussion it is not convenient to use Riemann integration. The space we want spaces that are complete Cauchy sequences must converge. So, l 2 for example, so we must work with l 2 of minus pi pi in a later chapter. So, Lebesgue integrals are absolute must. So, Lebesgue theory is a must. So, for technical reasons we must use Lebesgue integrals. So, we assume that the function f is integrable in the sense of Lebesgue on the interval minus pi pi. As explained earlier the objective is to express f as an infinite series f of x equal to a naught plus summation n from 1 to infinity a n cos n x plus b n sin n x a series of the form 1.1 is called a trigonometric series. The fundamental question of course is regarding the meaning of the equality in 1.1. For instance in what sense does the series in 1.1 converge? The series can converge in a variety of ways already you know in your undergraduate courses you can talk about point wise convergence, you can talk about uniform convergence, you know that uniform convergence is very strong point wise convergence is very weak. To list some of the alternatives let us look at what are the other modes in which 1.1 can converge. So, first let us add the first 2 n plus 1 terms of the series I said 2 n plus 1 because there will be cause and there is a sign and there is a constant term. So, I will take n cosines n sines and the constant. So, a naught plus summation a j cos j x plus b j sin j x j from 1 to n. So, I take the first n terms involving the cosine the first n terms involving the sin and the constant term. So, s n of f of x is the nth partial sum of the series, but this nth partial sum really is a sum of 2 n plus 1 terms. I am going to call it the nth partial sum just for convenience. So, we say that the series converges to f of x point wise almost everywhere if this partial sum s n f x converges to f x as n tends to infinity for all x except on a set of measure 0. We say this the series f 1.1 converges to f x in mean if the difference s n f x minus f x the norm the l 2 norm converges to 0. That is if the sequence s n converges to f in l 2 the third form of convergence is Cesaro convergence that you take s 1 x s 2 x s n x you take and then you take the arithmetic means of these partial sums. The arithmetic means of these partial sums must converge to f x. These are the 3 important modes of convergence that one can think about. One can also talk about distribution convergence in the sense of distributions. One can also try to include that, but for that we need to develop the theory of distributions. I do not think you have studied distribution theory in your earlier courses. You are for sure studied point wise convergence. You also studied mean convergence or if you are an engineer you would have encountered this so called RMS root mean squared. They integrate from minus pi to pi mod g x squared dx and you normally put a 1 upon 2 pi to make it an average value and then you take the square root. So, that dimensionally everything is correct. So, it is a RMS in electrical engineering you will call it the convergence in RMS converges a root mean squared. And the third is Cesaro convergence. These 3 modes of convergence are going to be extremely important. We are going to devote a whole chapter to mean convergence and we are going to devote an entire chapter to Cesaro convergence. And Cesaro convergence will give us a very important theorem on Wiles equidistribution theory. So, we shall need of course, we are not going to get these for free. The F must satisfy additional hypothesis before we can get any of these things. For the mean convergence we will need that F must be in L 2. For point wise convergence we are going to assume that the function is holder continuous to exponent alpha or lipchitz continuous or something or we could assume that the function is piece wise continuous and monotone that is Dirichlet's theorem. So, Cesaro convergence for example, if F is continuous just continuity then we know from Paul Dubu Arayman's example that point wise convergence fails, but Cesaro convergence will happen. But not only that Cesaro convergence will happen very strongly if FFX is continuous then these Cesaro means actually converge uniformly. It is far better we get something much much better. So, there are there is a tradeoff sometimes we need additional hypothesis if you want point wise convergence we need better than continuity like lipchitz continuity holder continuity monotonosity piece wise monotonosity. Mean convergence is easy we just need F should be in L 2 and the Cesaro convergence it is not point wise convergence it is convergence of arithmetic means F is just assumed to be continuous, but the Cesaro means give you uniform convergence. Why does this happen? We will understand this better when we average the Dirichlet kernel it improves we get what is called as a Feier kernel. The last thing that I talked about is known as a Feier's theorem we will have a whole chapter on this Cesaro convergence. I think this is a very good place to stop this particular module and I think I will stop here and we will continue this in the next module we will derive things and we will develop the theory further. So, thank you very much and goodbye.


Thank you everyone for staying for the latest session. It was my first day at DevConf, and there were a lot of nice sessions, a lot of nice people, so it's a pleasure for me to... Actually, I got a feeling about what it is like, and it's a pleasure for me to present here. I hope that you will enjoy what I have to share with you. So this talk is about sharing our experience of trying to run video streaming and processing in a service measure that title says already. So I'm Nikoi Nikoi, I work for VMware's open-source technology center in Bulgaria, and we do some cool and interesting stuff there. This is kind of a pet project that I started a couple of months ago when I was trying to figure out what interesting stuff you could do with service mesh, but we'll see later. Okay, so the agenda for this afternoon is first we'll go through the introduction of the problem, then we have an initial approach to what we did in the beginning, then how we did this with Kubernetes, then we applied service mesh on top and what we have in the future for us for the project. So first, who am I? So I did a lot of things in my professional career, and you can see some of the icons here that are actually showing some of the projects that I was involved in one way or another. But the main topic that I always was involved in was networking stuff and telco domain problems from programming point of view. And that's why when I started digging into the service mesh like six months ago, maybe, I was approaching it and this is what we tried to do here. I was approaching it from the point of view of a telco domain guy. And I wanted to figure out an interesting use case and say, okay, so we have these cool new technologies, containers, orchestration on top of them and service mesh on top of them. So what we can do, what could be interesting to do? So I discussed this is actually some project that we started with a couple of other people. I was the main one developing and doing it, but it was discussed internally with several other people. And during the discussions we figured out that maybe this could be an interesting thing, like edge computing, everyone knows about it or it's kind of a hot topic today. But specifically for the telco guys it is very interesting because it allows them to do, to enable some new services, new things to sell to their customers. And with the upcoming 5G networking standards and initiatives, these things become more and more important. So what we said, okay, so fine, for a telco guy, for a telco company, it would be interesting how they could stream and process video starting from a central office, going through the edge data center and then down to the customers. And what we see here is actually three types of different customers.  And eventually it would require different video sizes if you want. So your phone, although today the phones have larger screens, higher DPI and higher resolution than the notebooks, but for VR you can imagine that you can do that. So we started with this and then we said, okay, let's see if we want to do this kind of video processing pipeline to be able to satisfy this use case, what we can do? What would be the requirements? And actually these are the requirements. So we said, okay, we will not be processing a live streaming video like we don't want to complicate the setup. We just want to have one container or one service that streams the video by just looping a predefined video. It would be a full HD video in MP4 and then we want to be able to apply different filters on top of it. So as an example of filters, it doesn't really matter the actual function that you want to do there. So we just said, okay, let's do, let's apply a timestamp on top of it, let's apply a logo and let's be able to scale it up and down. Actually it's only down in this case, but yes, different sizes. And we wanted to be able to do this by being able to select an arbitrary set of functions. So I should be able to select to have 480p video and apply only a timestamp of it, not always to apply all the functionalities that are able there. So for the reason that you see further down the slides and the presentation, we chose to use HTTP as a transport within the mesh, so all the services are communicating and the video is transferred on top of HTTP. We could argue, and this is something in the conclusions, so kind of preview, we could argue if that's the most optimal thing, but that's what we have today. And then of course as an encoder we are using H.264. So next topic is what we did in the beginning. So the very first version is we just took VOC, containerized it with a shell script on top of it just to process the arguments and prepare the proper argument for VOC. And then, okay, we learned two containers, connect them together to talk to each other, and then, you know, we learned VOC as a client and we thought, okay, the video got resized. So it was kind of a start, but we somehow saw that it's not the ideal solution and we'll see why later. So this is a screenshot of H.TOP of this video's running, so we were having some older machine there, running kind of virtual instance, 16 virtual CPUs, as you see, the RAM is not really used, but it was a good proof of concept that with that machine, Kubernetes deployed there, you can actually do some video processing, but it was only the start. There was a lot more. So we did, and this is actually an old slide, that's why you can see that and you can probably notice that the source video is in different format and these things are not exactly as what was there. So this is what we did in the beginning as a start and we just got some numbers, so you have this source video with this bandwidth, then when you scale it up and down, you get different bandwidth. So if you're running over Wi-Fi, you can get one size of the video with one bandwidth. If you're running over 3G, you get different things like that. And we said, okay, that's good, but maybe there's something missing, because the very initial thing that we did was just composed of two stages, so you have the source and then you have the scaling. So it's not really what we wanted, because we actually wanted to be able to apply additional functions and this should be arbitrary, right? If the client wants in some way or by authentication gets the rise that there should be a logo applied on top of the video, this should be able to be done dynamically and it was not really the case of what we were able to do with the default setup by that time. So we started thinking, okay, let's think what should be the next step, the next design in our design. And yeah, this is actually just an overview of the script, how it looked like back then, and by looking at it you can easily see that, okay, you just parse some arguments and then you prepare the command line for VOC and it kind of does the job, but it's not really extensible and if you want to do more complex things, it's not there. So we sat down and said, okay, let's draw a different design picture and this is what we came up with. So essentially this is what we have today. So essentially we wrote a small application in Go that actually terminates the HTTP requests and then for each HTTP request it spawns an FNPEC and the FNPEC pipes back the processed video and this gets streamed back to the client. Now the first difference that you will notice probably is that there is FNPEC instead of VOC, so we found that actually with VOC at some point it got too much complex to prepare all the arguments. I'm not saying that VOC is a bad choice, it's a great tool, it does its job perfectly. It was just for us at some point we were not able to achieve whatever we want. So we started looking at alternatives, we started playing with FNPEC and we found that at least for us it was a lot easier to achieve whatever we needed. So things like the overlay logo, the timestamp that you'll see later, so all these things were just a lot easier for us to do. I guess that you should be able to do this with VOC also. And one of the things actually that we wanted to do is that we wanted to have the container just wrapping all these video processing details and just get these generic arguments like this is the source of your video, you should listen to this part and you should size it. And then the purpose of this shim layer or this adapter layer which we call the streamer here to actually transfer these arguments into the specific engine's arguments or calls or whatever is needed there. So that is something that we preserved from the script approach here. And in the current project that we have, this is what we call a local view pipeline. So you can run this on your local host, it will spawn four of these applications, a chain like this, and you can see how the different filters get applied, scaling and things. And it's demo time. So I will show you how this is done now. Okay, is it big enough? Yeah, this one probably not. So if you just run the script, it will just say, okay, so this is... these are the four applications running. And so if I do... I'm using Emplayer. CP, localhost, and we can select the port from... So we have 1003, which is the full pipeline, so let's do the full pipeline, and this should... hopefully it was working. Yeah. So this essentially is the video scaled down to this particular... and you can see actually down below... it's... this is the HD resolution, not full HD, so it's scaled down. And if you want to verify... so if I run this on port 2000, this is actually the original video playing here.  So that's not really pressified, I know what you think, but it was something that actually allowed us to do the development on localhost without having to deploy and back and forth and do this. So, okay, so next thing is, of course with these applications already, you know, are working, we just took these things and put them in Kubernetes. Yeah, we had to write these... these descriptions, deployment plus services. We had one source container that actually was streaming the video, a couple of containers that do the processing, but as you can see, it's essentially, again, static pipeline. So I don't have a demo for that because I don't have deployed pure Kubernetes. I don't have only a demo with the service mesh, but essentially, as you can imagine, it's just like if you connect one of these ports, and that's why I actually have the screenshots here, if you connect one of these ports, these are node ports exposed, you can just see the different sizes, but you cannot actually select what you want to do. And although it's a simple example here, I mean, again, I want to reiterate all that these filters could be whatever you want. Like, you can have a big pool of filters and try to do different interesting stuff on top. So the next thing is about the service mesh. So I don't know how many of you actually are using service mesh or you know what it is about. So who has an idea of what these two is? Can you raise hands? Okay, good, perfect. So I have a couple of slides just to quickly say why we wanted service mesh. So back in the old days, so this is kind of stepping a little bit back from the current project. Back in the old days, we had the physical servers with all the physical infrastructures connected together. Then we moved to virtualization. We all know this. Virtualization just replicated from point of view of a networking guy. It just replicated whatever we had. Then we started using containers. They had isolated processes. They communicate over sockets. They need layer 3 connectivity. They don't need much more than that. That's what the CNI does. And then at some point we arrived at the situation where actually we started writing applications that care only about endpoints. They don't want to know if there's any layer 2, layer 3. And at some point we ended up in a situation where we just wanted to manage endpoints. So our infrastructure should know about all the layer 7 protocols that are out there. So all the RESTs and GRPCs and whatever the databases are doing on top of that. And that's where service mesh came. So I guess that everyone that is familiar with service mesh should have seen this specific picture. It's very popular. But if you look at it, and you can imagine that this is a pot in terms of Kubernetes, the green thing is your application, and the blue thing is the so-called sidecar proxy. The purpose of the sidecar proxy and all this, the whole mesh that is built here is to just be able to provide the underlying infrastructure so that your application can be run on top and actually you can have all the nice visibility, debuggability, and of course you can manipulate all the requests that are going within the service mesh. So it's not a really complex concept, but it appears to be pretty powerful. So what we used is a project called Istio. And this is the basic layout of its architecture. So you can see that it basically is split into data plane and control plane. The data plane is essentially this set of envoy proxies which are kind of intercepting all the ingress and ingress traffic from your application. They are controlled by the pilot, and there are other components which I guess that it's not very interesting to discuss here. So taking this as a basic architecture that we want to build our solution top, we moved to the defining how we can leverage the means of the service mesh to have our dynamic video pipeline. And we took a rather simple approach, but I think that it kind of took out the strong parts and the strong sides of the service mesh, specifically Istio. So we defined HTTP header, which we call Process Video, and it had three fields which essentially define each stages of the video processing, and essentially program your stages through this HTTP header. It's not really complex, as I said, but it did the job. And if you think about it, in practice, at each hop envoy is just checking this header and deciding, okay, are you applying the scaling or are you doing something different? Are you passing it to the next stage? And one thing that actually we can say here is that this is why we chose HTTP, because the truth is that essentially envoy and Istio can do manipulation of TCP, so kind of layer 4, and HTTP. So you can do matching and, you know, writing. But think of that with TCP, actually you don't have these kind of custom fields that you can pass through your request, so meaning that you can't really program and propagate whatever the client wants from the service mesh, right? So that's why HTTP was chosen in the first place, like in the beginning. And what we also figured out is that service mesh doesn't propagate the request for you. So the job of the service mesh is that HTTP request gets to your service and then it's your job to propagate it down the service mesh. So that's why actually our streamer, and this is how the picture looks like in real life, so once the request gets into the port, it passes to envoy, envoy checks it and says, okay, should we apply this function or not? And if it's yes, then it passes to the streamer. Passes it to the streamer, which essentially just terminates the HTTP request and then it has to read the HTTP header and pass it down for the next guy. So this means that you have to propagate this request right from entering your service mesh down to the last level, and it's your job. And if you think about it, the promise of the service mesh was that it should be something invisible, like you develop your application on top and you don't care, but the fact is that if you want to do more complex things and kind of service chaining if you want to call it, then your application has to be designed to do these things. It's not like you just deploy it and the service mesh does all the things for you. At least that's the current state, that's what we found. And the full picture, actually all the envoys and all the containers and all the data paths, at least the request paths are shown here. It's quite complex, I would say. It does its job. I think it's that if you want to scale, if you want to have kind of, I don't know, 100 functions, then it would become really complex. And that's not really great. And okay, so it's time for a live demo. Let's see how the wireless network is today. Okay. Yes, I should stop the show like this. Okay. So I will run this script. So why we run this script? Because apparently Envoy doesn't speak so HTTP 1.0 and then player speaks only HTTP 1.0. So if you want to enter the service mesh with mPlayer, you are not able to. So okay, so we have this script, which essentially runs kernel for, and then pipes the output to mPlayer to be able to play it. Of course, we can use VLC also. But okay, let's say that we are fans of fmpeg guys today. So this script essentially takes three arguments. So if you omit them, they essentially disable. So if I say low, then I should do dash, and then I say enable. They should run the lower scale video. So this is connecting to our office's data center. I hope that it would be able to connect. It's over VPN, wireless, and a lot of technology. So if the video goes through, we'll be lucky. Yeah, so this essentially is giving you the lowest, like, 240p video with only the logo applied. Now, if I do, let's say, I think it was high, and then enable, then you can see here, there is the header generation shown here. So I guess that this is going to take some time before, because it does some caching before it starts playing the video, but I hope that you'll be able to get the picture, at least, to see that it's applied. That's all. Okay, I'll let it run for a while, then we can discuss a little bit. So if you've seen them, maybe we can just... Yeah, okay, so here's the video. It came through. It's a little bit slow, as I said. It's wireless VPN, then some data center doing things. So that's actually the result of... That's what we have today. Of course, you can request directly for the original video. You can actually request any combination, which was our initial goal. So if you think about it, though, you'll have a lot more components than what you would imagine. I mean, you have all these proxies, you have the ingress gateway here, then all the envoy proxies. So for this to work in the full pipeline, like from start to the beginning, there's a lot of components involved. So one of the things that this probably is the time to... Yeah, this is how our virtual service, from the point of view of FIST, you have it looks like. So the virtual services are essentially the description of the configuration of the envoy proxies, or whatever the proxies should be able to do, like matching the headers, getting some routing decisions. Please, here, that's what we see. But I wanted to move a little bit to the conclusions. We have some time here. So if you think about it, there's a lot of processing involved in this solution. So this is whatever we wanted to do initially, but it's not really effective. So first of all, use HTTP. This means that you'll get all these encapsulations. Then on each stage, in order to apply each of the functions, you have to decode the video, apply whatever you want, like a logo on top of it, and then encode it again. Yeah, if you have to do it like five times, and if you have to consider, again, the edge video processing use case, that's not really great, right? Because it just eats resources, and on the edge you're not full of resources, you're kind of power constrained, and there are heat constraints, or whatever. So there could be better solutions possibly, and we are looking into some of them, as I will show in a while. But for now, this is the state. So our conclusion is somehow, if you want to use Istio to do these kind of things in this way, or kind of the service mesh approach that is available out there, you have to go with it. It gives you the flexibility, you could do nice things, but you just have to have the resources. Yeah, so you are also bound to HTTPS at transport if you want to be able to pass all these headers around and to manipulate them, and it's not really great. So one thing actually that reminds me here of the slide is about HTTP2. So we looked a little bit into this. It could be a solution to some of the problems, or instead of, you know, all the time just, you know, opening connections, closing connections, and maybe HTTP2 can help us with their streams, and, you know, it's binary in nature. Maybe it could ease the things a little bit. But from what I saw at least, the new VLC has some mention, at least in the documentation, I'm not sure how I should be able to use it if I wanted to, but FMPEC, of course, it's an old school, and it's not really having it today. And we're a little bit ahead of time, but let me share our future plans. So actually we have all the work that we had with all the things shared in GitHub repository. I uploaded it this morning from the site over there. So it's public now. Whoever wants to play with it can just log in. These slides are going to be available, I guess, on the site, so if someone wants, or if you can reach out to me. This is my own GitHub account, but it's public for everyone to work with it. And some of the things that we wanted to do in the future. So in the last couple of months, I was also involved in this new interesting project called Network Service Mesh. Someone may have here heard a bit, someone not. But, essentially, it doesn't have the burden of the site card process the way that the traditional service meshes have. So instead it just wires the connectivity between the containers. It doesn't rely on CNI. This is all the interesting things. I hope that we will have the chance to grow this project to something further. I was actually trying to prepare a demo based on this. I get somehow halfway through it. I'm sorry I was not able to actually finalize and show it. I hope I have the chance to do this maybe next year. And I think that it could be an interesting demonstration on top of that. Actually, the whole purpose of this project, as I said, it was kind of a pet project for me that I was doing kind of site of my main activities. And the whole purpose was to be able to demonstrate and kind of push the limits a little bit of the service meshes and these whole container technologies and see how telco-like workloads could behave there and what you could do with them. Of course, it would be really interesting to measure the real impact of the site card process because we're kind of stating things and we know that MBO is kind of pretty fast and optimal. I don't know if someone noted that, but I have a couple of patches and this icon is on my first slide. So I know some insights of MBO. I know that it's really good. Still, when you apply five of them, then probably you'll get some impact. There's no way to not have impact. And whatever we did up till now was like with a single replica, no really scaling up down, no multiple clients. I think I can run up to three clients at once and it was kind of working. But if you want to kind of get the real picture, you should scale it and have a multi-node deployment and see how all these things communicate together in a bigger environment. And this was actually my last slide. So we have at least 10 minutes, maybe more. So, questions. Yeah, yeah, yeah. So that's actually one of the goals of Network Service Mesh. So I am part of the Network Service Mesh team now and one of the things that we want to do there is to enable telco type of use cases. So like multicast is the perfect example. Thanks for asking this question of where actually you don't want to rely on this higher level protocols. You just want to be able to do the most optimal data streaming that you can do. You're absolutely right that here. If you want to scale with all these proxies and you kind of want to do hundreds and thousands of users, this would be impossible. If you consume just so many resources, it won't be... So, as I said, we just wanted to push the limits and say, okay, what we can do? What we can do with the available technologies? I know that maybe the result is not really optimistic, but that's kind of a reality check. That's what we can do today. You're right. I mean, of course, the standard way, at least up till now, to distribute video in the most optimal one is to do multicast. But yeah, with the modern tech technologies, things are shifting away a little bit from there. Now, with Network Service Mesh, we are trying to bring telcos back and all the telco type of approaches. Yeah? Yeah? So the question is what happens, or the question is what happens when the client closes the connection? So essentially what happens is that the containers, once the whole service mesh is brought up, the containers are sitting in this idle waiting for connection state, and when the connection is closed, it's just because the FMPEG for the processing is spawned as a sub-process. Right? And we just pipe from its output like an HTTP reply. And what happens is that just this spawn process is closed. It just is terminated. Yeah, but you actually... Because... No, no, no, no. Everyone stops working. So if you look at this, actually, once this connection is terminated here is alive and is established, then this process is spawned. But when this connection gets disconnected, the server notices that its client goes away because essentially this guy is a client to this guy. So when this gets the notification that, okay, the socket is gone. The connection is terminated. Terminate the spawn process. You mean the different scalers at the same time, yeah? Yeah, currently the HTTP implementation of the streamer doesn't have any limitations on the amount of connections accepted. So whatever you might reach as a limit in this specific scenario would be if the Kubernetes applied some limits on the types of CPU resources, I mean on the amount of CPU resources that you're using. Because if you spawn 5 FM packs in a single container, you would just use too much CPU, right? So you will get kind of restricted if there are such limitations, of course, applied. Okay, I guess that's the end of it. So thank you again for staying with me.


So I'm Osa Persson, I'm Research Director and Deputy Director at the Stockholm Environment Institute and I have also been contributing as a member of the independent group of scientists to the Global Sustainable Development Report underpinning the SDG Summit this year. So the SDG Summit coming up marks the halfway point in Agenda 2030 and it's an important moment to review progress and commit to new action to really advance on the goals. Unfortunately we are not on track and reports show that we're on track with only 10 or 20% of the goals so it's a big task ahead for world leaders as they gather in New York. Well considering the last few years with major crisis in the world, the pandemic, the Ukraine war, it is a difficult situation and tensions between countries are pretty high. Nevertheless I hope they take this quite unique opportunity now to set us up for a more successful second half of Agenda 2030. A lot of determination will be required but there are definitely things they could bring to the table like SDG financing, showcasing domestic policy and regulation initiatives and also working more with science because there is a plethora of tools and analysis available to governments.


How do I know that? Well, I live in Sweden. Thanks for watching, I'll be back with more quality content. If you enjoy this video, please like, share and subscribe. You're still here. Fine. It's not only because I live in Sweden. It's also got to do with the conceit that propels you to action in but not yacht in addition. The king is dead. And whereas most people just say long live the king. Apparently we can't do that because we're in the middle of a Viking invasion. Yes, indeed. These bad Northmen are coming. So it's time to pull out the old bows, the arrows, the sticks with the pointy pointy bits and send those nasty boys packing. If you want games with tight mechanics, almost singular in their execution, you look first and foremost to the indie market. Bad North is an example of a few core ideas polished to damn near perfection and remarkably enjoyable to mess about with. What does Bad North offer you? The small island map with several buildings to defend, up to four squads to develop in one of three classes, warriors, peer men, archer. A single ability for each class also upgradeable and scores upon scores of enemies, waves of them to be stopped. Positioning is king. Maybe that's where long live the king should come in. This is a lesson every great historical battle will teach you in the main precept of Bad North. This is the core of the game, along with a straightforward, but not, rock-paper-scissors mechanic which dictates which squads to use against which types of vikings. Most basic Viking enemy types have a direct counter. The dual wielders are countered by archers. The huskals is showing axes unnegated by the shields of the swordsman infantry, as are the Viking archers' arrows. Even the advanced enemies, the brutes, are accounted by the pikemen, so you might not be able to tell it at first glance. If you're like me and lucky enough to come across an item that allows you to expand the roster of one of your squads, if you find yourself with an archer's squad, give that item to the archers, turns out an extra eight bows really, really makes a difference. What else does Bad North just an addition offer? A number of items, each of which offers some bonus or another. The one I mentioned already, adding additional units to a commander's squad. Additional coins as payment after every successful defense. Even the holy grail makes an appearance allowing you to resurrect a commander who has fallen. Something I was particularly thankful for, as my single spearman unit died over a really dumb mistake I'd made over in attention. Two islands later, I resurrected him, just in time for the final island battle. The music is minimalistic, but of a fine quality, especially memorable in that very first note that plays whenever the Vikings' skirmish of the latest island you defend begins. The sound effects are all around excellent, some of them downright funny. The graphics are so simplistic and slick, which is to say I love this aesthetic, I love it. It looks great, it plays at a consistent 144 fps, the game is a 250 megabyte in store. There's lessons to be done there.  Mine took me a little less than three. There's a difficulty spike two thirds into the run that demands you use everything you've learned about your enemies and about positioning. The game makes sure that you don't have a moment's calm during these later defenses. It does not pull any punches, and the continued assaults by many different enemies dare you to react with split second decisions. The tension is palpable. The random generation of the islands also means you'll always be forced into further adapting your tried and tested strategies with awareness to any limitations and strategic opportunities the terrain offers. You can take it real easy that first hour for the first dozen islands or so. You fill in your roster of your false quads, you repel all the basic Vikings, you get an idea of how this plays out. Fair enough, little by little, you get your feet into a game that has a fair amount of complexity worth exploring later on. This is the very definition of easy to get into hard to master. I failed once, and it was more a choice rather than actual failure, because I had only just passed through the first of three checkpoints. I had lost a unit due to getting distracted and I really liked that unit, so I gave up. This isn't as punishing as most road lights I've played in recent memory, and I'm not complaining. There's a bit of meta progression, but it's really quite basic. There's a codex which offers you some information and a number of basic traits to begin a new game with. This game is sold for €15. I played it on the Xbox Game Pass for PC, but I know it's leaving that soon. That's what drew me to it. I've had bad nought installed on my computer for the entirety of the summer, and only when it's leaving Xbox Game Pass did I finally find the time to play it. For shame. It's a game worth the money, and I might just buy it when I get this crutch for more of its unique proposition. What I would like to see improved in bad nought is the progression of your squads. It's a little too simple and lacks the degree of customisation that the enemy is showcased. I know this game is driven by the colorful simplicity in aesthetics and systems boat, but I think a little extra complexity, a few more variables for the players to engage with, could really make this a must-play in this strategy. As it is, what you will find in bad nought yorton edition is a strategy game, absolutely in love with micromanagement, that puts in its money on exploring basic concepts at a commendable depth. With slick controls and adorable presentation, it plays great. A well-rounded package, which I'm happy to recommend for fellow fans of the RTS genre. Thank you for watching. If you enjoyed this review, please like it, share it with your friends, subscribe, send it to your grandmother in the post. Yes, that's right. Write the link longhand and mail it to your grandmother. She will like it, she will love it. She was around back when the bad vikings came. She will appreciate the tactics it takes to deal with them. Probably. If you enjoyed this video, please, once again, look forward to the next one. What games would you like me to tackle next? Let me know. I'm very excited to do more. Next up, I think I'm going to talk about Wasteland 3 and I'm also preparing a long-ass critique of Tell Me Why, which is full of praise, not only. See you next time. Bye!


What's good everybody Chris from jassescasebricks.com doing our R&B for 2022 Diamond Icons based on one box PYT number 26 15 teams in this R&B Mariners Royals Rays Tigers Dodgers White Sox Padres Blue Jays A's Pirates Giants Marlins Brewers Twins and Rockies So big four right here with our big rookies It's a big name vets for a lot of those teams will throw the dice and randomized for the R&B Nathan down to Nicole Rob Ed Michael Thanks for giving it in and then one to zero on the numbers spot zero being any redemptions even if they are numbered One of one on the checklist. Let's do it for the dice and randomized two and five seven times. Good. Look. Thanks one two three four five six and seven seventh and final time Nicole with the last spot module up top down to Nathan And seven times for the numbers. Good luck again. Thanks y'all one two three four five six and seven Seven final time. Nice one for Nicole up top All right, let's see how it all shakes out on our R&B So Nicole with last Bob Mojo gets spot zero any redemptions. We'll be going to Nicole for this 15 teams Excuse us There you go. Nathan with one and two Rob with three Nathan four Ed five Michael six Rob seven and Nathan closes it out with eight and nine All right, there we go. Thanks y'all next break next video will be the one box of diamond icons number 26 Josh's case breaks.com. Thanks in y'all. Bye


What did you see from Garrett this afternoon? At the beginning, I really thought he was making a lot of good pitches. We kind of just got burned on some weak contact. And from there, it kind of unfolded pretty poorly for us. But on the whole, I thought we were, we did get burned by some weak contact. He almost seemed perplexed when he just spoke to us saying that you guys were still talking after the game about what went wrong and what you could have potentially done differently. What in your mind could you guys have done differently this afternoon as far as execution? You know, it is easier for us to look back once it's already happened. But I think we definitely discussed some things that we could do. I don't really want to get into two specific stuff just because for upcoming opponents, I don't really want to get into specifics. But we came up with a couple ideas of what we can do to be better next time. When Garrett Cole's on the mound, you guys expect to win. He had pitched prior to this very well coming off the COVID IEL. Just what type of blow is today's loss to this team? It's tough. I mean, I think every single one of us thinks we didn't play the way we wanted to today. So it's just we got another game tomorrow, and we're going to have to strap it on and try to be our best. Because it's definitely no time left. So we got to get it done.


My name is Elizabeth Van Overbeek. I'm originally from Toronto, Canada, but now I am based in Kinshasa in the Democratic Republic of the Congo. I'll be an E4C fellow in 2021 advancing sustainable development goals, SDG 11, Sustainable Cities and Communities, and SDG 8, Decent Work and Economic Growth. I am most excited about this fellowship because it will be bringing together a talented and interdisciplinary group of people who will be working on a large array of projects with partners who are making an impact around the world. As an E4C fellow, I will be working with UNHCR and Bridges to Prosperity. With UNHCR, we will be providing support in the delivery of settlement planning tools and templates, and with Bridges to Prosperity, we will be analyzing the impact of rural trail bridges on adjacent infrastructure in East Africa. Through this fellowship, I hope to gain confidence and experience in leading, managing and mentoring others. I want to apply my engineering skills for social good because I believe we are called to be stewards of our planet and that everyone should be able to live and work in quality and meaningful spaces.