Overview of Upipe modules for broadcast professionals
Massiot, Christophe
Upipe is a flexible dataflow framework with multiple structural innovationswhich have been discussed in previous FOSDEM talks. In this talk, the speakerwill give an overview of the available modules, with real-life use cases fromtelevision broadcast professionals.
 I don't have the microphone. Never mind. This man needs no introduction, but because he has run the vast majority of the work for POSTEV for the Open Media Room, in conjunction with Adi and Fran and myself, I'd like to bring him around. Thank you. So it's Christophe Massio and he'll be talking about U-Pipe, a very interesting project that we work on as well. Thank you, Kieran. Maybe I should have changed my t-shirt because I'm not the Dev Room person now, but I'm the company person now, but they told me not to do that in front of the camera, so it was too dangerous. So a new talk about U-Pipe, we already did one last year and the year before, but it will be on a different topic this time. The first question for people who weren't there at the previous year is what is U-Pipe? So U-Pipe is a young multimedia framework written in C. We started in 2012, so that means we're quite young, not as young now, but still quite young compared to similar projects were born in the 1990s. That means we have, of course, a lot fewer modules, fewer support, but also we have been able to make some educated choice about the technologies of today. So U-Pipe was initiated by my company, Open Head End, and some of my employees, but there are now three supporting companies, including Kieran as well, we use it, and last time I counted seven contributors. The focus of U-Pipe is a bit different from what you can see with VLC or maybe G-Streamer. We focus on reliability and efficiency and above all compliance. So that means we don't aim at playing any kind of file that's on the Internet. If it doesn't comply to the standard it's supposed to comply to, we will say May. We also focus on broadcasting professional applications. Actually, most of the use cases I have today are on the real world, in the real broadcast world with real customers in the broadcast domain. The license of U-Pipe is MIT and LGPL, so it's not both. Some modules are MIT, the core is MIT, the headers are MIT. The main pipes are MIT, that is what you need to build a pipeline, basically, duplication, source, file-source, file-sync, UDP and so on. All of that is MIT. We have some modules that are LGPL, that's mainly the code that deals with the codec format, so what we call the framers in our lingo. And also some support libraries are also LGPL, like Liby Codec. So the binding code is also LGPL. So those of you whether the previous year, what's new, the question is simple. So too long don't read. We've had a lot of work on the Eventloop API to make it more complete. So now you don't need to call anymore the Eventloop directly from your program. And it's also easy launching P-threads, P-thread workers. We have a nice utility to dump pipeline in GraphViz format. So some of the slides we will see later have been automatically generated from U-Pipe using GraphViz. You will see that it's quite nice, quite verbal as well. The legit bindings, I talked about them last year, but it's finally been merged in. So you can now write a U-Pipe client using just Lua. And Lua is interesting for that because it abstracts all the ref counting of the structure. Most of our structures are ref counted, but in Lua, Lua takes care of the ref counts and freeze automatically the structure you don't use anymore. In C you have to do it by hand. So that's interesting. In the feature side, we've had people contributing, a third company contributing an HLS client. So some other frameworks have also HLS clients, but we now do have one where you could choose the bandwidth or the variant you want to have. And you can re-multiplex it, repurpose it in a different format. I will show later an example where we repurpose HLS to a Transports Stream, a UDP Transports Stream, standard Transports Stream. We've had some work on X265 as well, so we're able to decode it and support it. Vang supporting the SDI if you don't know what that means, don't care. If you do, bad for you. And well, I wanted to release Previz number five, but the work is not finished yet, but we'll probably do that in the next few weeks. And after that, 1.0, we hope. So unlike Previz here, I'm not here to give you an extensive talk on the insides of your pipe and why it's a good pipeline, but I will give you examples of what you can do with your pipe. And I will start with an inventory of all the modules we have for inputs, output theaters and so on. And then I talk about use cases, typical use cases that are in production today. So the inputs we have, well, some of them are quite standard. Of course, in the broadcast world, we still have specific connections like SDI and ASI, so we support two vendors for that. Natively, inside your pipe, we support, of course, the DIU, DPH, ETP and so on protocols. We have a compliant ESDMUX, or compliant is important for us, as I said. We also have an RTP DMAX to be able to read one or several RTP streams from the same program. HLS Client, I talked about it already. I have here MultiCAD directory, but it's a bit of a specific format that allows you to record 24-7 streams in chunks and expire older chunks. So we can also support that with U-Pipe. It's come from a program that's called MultiCAD as part of the VDRAN project. Externally, we support the BD format for sources. It's actually a work in progress. Some of the formats may not work at the moment because there are still adaptations to do. As for the outputs, well, again, we have hardware outputs from SDI and ASI that have not been merged at the moment, but they exist from where I'm getting them. So if you look for it, you can ask us and we'll tell you where it is. Natively, we support, as usual, the FI UDP RTP. We also support compliant ESMUX. So that's one of the kind that's probably the thing that differentiates us most from other projects. In that, we have a compliant ESMUX, that output streams that are analysed by a professional analyser, and they say it's okay. So that's quite a good thing. MultiCAD directory again. And we can use also Externally, the BD format. This time, it works. In production, I have streams to RTMP, ICAST, and other formats using the BD format. And GLX, Alizar. And we were talking yesterday about Wayland. Fernman was talking about Wayland outputs also that is working on. So inputs and outputs are okay, but what can you do in between? So first, the filters that we have, so internally, natively, we support, well, the standard interlaced, bleeding, bleeding means to take a picture and you bleed it on top of your video, like a logo, without transparency. Bleeding also allows us to do mosaic. I will show you later. Crop. We also have V210 pack and pack assembly optimised functions. If you don't know what it is, good for you. It's some kind of a format output by some SDI cards for 10-bit video. And so it's more compact than the traditional reports on 16-bit, but it's also much harder to read. External libraries, of course, are very useful for filters. Of course, CBCD-Codec provides most of our decoders and encoders. X264 is also an encoder we use a lot. And the traditional software resample as well. Leavespix is a recent addition that allows us to do resampling without changing the pitch. So it's actually much nicer in the broadcast world where you have to compensate for a drift where you don't hear it thanks to Leavespix. And we also have bindings to Leavesvbi, but just for American subtitling system. Another important piece of our project is what we call the framers. So the framers are analog to what EVCodec calls the parsers. So that's basically a place where you have the knowledge about the codecs. So that's pieces of code that will parse the codecs, tell you this is a frame, this is a head of a frame, this is a 25 FPS for a stream, and interpolates the PTS from frame to frame and so on. But in addition to that, it's not just a parser, but it also acts as what EVCodec again calls Bstream Filter, that allows you to transform the format, the stream format into another. For instance, in X264, if you want to put X264 into TS, you have an annex called annex B. That is, you put a start code in front of your structures. If you want to put X264 in MP4, it's a different format. It's not start code anymore, but it's based on size. And so this transformation is dealt with by the framers in our project. We also have an interesting mechanism in which all of this is actually performed automatically without even you knowing it. So basically, the thing talks to the previous pipes and say, I need annex B. And so the framer will say, I don't receive an annex B, so I will convert automatically. And we have support for a few video formats, MP2, X264, and now X265, that's a recent addition. A lot of audio formats and subtitling systems, so telotex and DVD subtitles. Why would you use U-Pipe for broadcast world? Well, we have several assets, in addition to those I already mentioned. Our clock system is actually one of the major points, as we said yesterday at the meetup. In U-Pipe, we keep actually three clocks for each packet, the original timestamp that was in the stream. Reconstructed timestamps, that's always monotonously increasing. So the demux makes sure that it's always a monotonously increasing. And that's what we call the program timestamp. It's basically the clock of the encoder, the guy that gives you the stream. And we have the system timestamp. So the system timestamp is based on the clock of your hardware, your machine. And so typically for display, you would use the system timestamp. Most of the projects only keep the system timestamp, but that means that if you have a drift, sometimes you have a shorter delay or longer delay, and so you normally have 40 milliseconds exactly between frames. And that's a problem for some codecs. So that's why we keep all of those clocks. Also, the system timestamp, I said it was the system time. That's not completely true. Usually it's a get time of day or a clock get time. But there are also use cases, which is interesting to get the clock of hardware clock, like on the ASI or SDI card. And that's the use case we have in reality. So we can replace all of these by any other hardware clock, if you want. In U-Pipe, everything is dynamic. That means the model of U-Pipe is to, is transpose stream. So in transpose stream, you can have new elementary stream. You can remove an elementary stream at any time. So you can have subtitling, arriving, all of a sudden. So everything has been built in U-Pipe to allow for automatic forking of a new decoder, a new parser, and so on, if needed. If the user wants it, of course. But so the framework allows that. We also have efficient threading. You decide where you put the threads, not our framework. So if you have a thread, let's say AV codec, usually, you want to depot another thread. You just create what we call worker, and it will move to another thread. If you don't want it, for some reason, because for instance, you're a very low latency, you can work with no thread at all. The framework allows that as long as your core is enough, of course, to do all of that. We also have shared buffers with Copian white and the Eurocopy semantics. So now you can see that more and more, but without that in 2012. And we were binding, so I already talked about earlier. So that was for the assets and the inventory. Let's see a few real-world examples. The first example, I'm not sure you will see properly, but let's try. The first real-world example I have is some kind of a player. So it can be a player on your PC, but it can also be an IRD integrated receiver decoder, like in the professional world. So these graphs have been made by the U-PipeDump API that I talked about earlier. So it's actually everything that is spawned when you start a U-Pipe pipeline. So on top of it, you have the source. Actually, it's the worker, the W worker source. So it's in a different thread for performance reasons. And we read from, in that case, from a file. It can be also a FIFO. Then is coming the TSD-Mux. So the TSD-Mux is the main thread here, is the main pipe, super pipe, we call it. That has a son, that's the program, and two other sons. The program has two other sons, the audio and the video. So inside the D-Mux, it says there are a lot of sub-pipes that do a lot of things like D-Caps, PSD-Caps, Framers and so on. And on the output, you have your frames. And in two different workers for audio and video, you decode it with EV codec. Here is the part of the pipeline that is with subtitles, bleeding subtitles, if you have some. In our case, we don't have. FFMT is something that uses software scale and the interlace to the interlace and, well, put it in the correct format. It's RGB in that case, because we are using GLX. And the TRIGP and Play Video and Play pipe are used for synchronization. So GLX and the audio is also on its own thread, that's why it's a worker. I'm not sure if you can see it properly, I don't see it in that distance, but I hope so. Let's take a little bit more complicated example, a program that does a TS-reimba multiplexing. So we have a TS at the source. So again, in our worker source here, we have a UDP source, this time RTP-D-Caps. And we want to create another UDP and we remitteplex in between. We could also transcode, but that would add more complexity to the graph. So the graph is already barely readable, so let's try to keep it simpler. So again, after the source, we enter the TS-D-Mux. So again, in that case, we only have one elementary stream, so I chose to have only one video, because otherwise it's complicated things a lot. So the internal of the TS-D-Mux is the split pipe that allows to select which PID you want. And we also have decoders for PAT and PMT, which has internal structures of the TS. And then you have the TS-Mux, which is quite symmetric compared to the TS-D-Mux program and input elementary stream. The output of the TS-Mux is then sent to also another worker thread that adds an RTP header and outputs it to UDP. The last use case, because I'm running out of time, is quite a nice application we use in my company for recording. In fact, actually, I simplified it a lot, because otherwise it would be too big to display on the screen. But basically, we have an application where we receive a stream from UDP again, UDP RTP. We record it immediately as TS, but at the same time, we decode it, so D-Mux decode it, to get some frames, the key frames, for thumbnails. And we recreate JPEGs from the thumbnails. So here you see a depth pipe that one is directly written to the disk, and the other is sent to the TS-D-Mux again. So now you're used to it. And at the output of the TS-D-Mux, we have a bit more pipeline. Between the arrows, you can see the types, but it's a bit... So evico-deck, the interlace, because for JPEG you want an interlace. And this pipeline here is ad hoc, create some out of the frames we've selected. And we record it with evico-deck encoder, this one, for JPEG, and write it with a file sync to a file. Okay, last use case, but this time I won't show you a graph, because it would be enormous. It's a mosaic. So this is, for instance, a mosaic we have at work. So this is a real life example. So basically all of this is done with your pipe, using a pipeline per input, outputting two bleed functions, so bleed pipes, that will bleed each of the thumb to a single picture. And so normally it's also live. This is also for the audio, so that's a nice contribution by OBS. It moves with your audio level. So all of this is done with a U-pipe pipeline. Other use cases that we have in production that I did not have time to talk about here. So IRD, of course, we have a company using that from TS, we could also imagine it from HLS. Live encoder, live transcoder, to TS, or to RTMP, I SCAST, anything that I use for my support, basically. Live transcoder, that's something we have in our company as well. We would from TS usually to MP4, that's a typical use case for us. We also have an MPTS max, that's a product from my company as well, based entirely based on your pipe and the TS max that you've seen earlier. It would be quite a large workflow to show, but it works with your pipe. And also something we demonstrated actually at the IBC last year, is a play out system with overlay. So we've just played out files, decoded files, and added a logo that moves and a banner and a picture inside of a picture, picture in picture and so on. I think I'm right on time for some questions. I just wanted to, you mentioned HTTP, is it compatible with HTTPS? So you said I talked about HTTP, but is it compatible with HTTPS? At the moment, I don't think so. Because the company that provided it doesn't use it. Alright, third party, work with you? Yes, it's a nameless network operator, I'm not sure we can say who it is, who contributed that part to us. And they did HTTP, they did AES, also unscrambling, if the stream is scrambled. AES inclusion is available? Yes, it's already merged in. So it also supports whether you have the audio inside, mixed with the video or a separate file, or variant, I don't know how you call it, in your M3 or U8. You said that the MPEGTS standard is compatible with many MPEGTS standards? So which MPEGTS standard do we comply to? First, the ISO, and what I was actually referring to with that is the fact that we TSTD compliant. That means that the timing of a packet has very strong constraints in the TST specification. You can't send the packet to early, you can't send it too late either, you can't burst, and so on. All of that is specified in this specification, and it's actually very difficult to understand it to years. So that's what I was referring to. We also comply to DVB, and we have decoders for SDT, NIT, and so on, whether usual. That's not specific to our project, but yeah. Any more questions? The use cases, do you have the code for the sample online or anything? The use cases for? Yeah, we published the code for the new cases, new cases that you showed. So have we published the codes for use cases? Some of them are online. So the player basically is an example that we call UPLAY. That's in the example directory of the UPLAY repository. So if you want to see how I code this on GitHub. So the player is the transcoder, the TS-REMEX is also, it's a test unit actually called UPLAY TS-TEST that we use to test that our D-MUX and MUX don't send behavior from release to release. The third one was recording is not. It's actually not published yet. Probably at some point we will, but not so far. One also very important thing, if you wish to contact us, so we have a website, UPLAY.org of course, we have our GitHub, and if you wish to talk to us, the best is to come to our IRC, UPLAY.org on FreeNode. We also have a mailing list, but usually when I say that, Q1 laughs. Sorry for asking. So what are you supporting? Bank? Can you type? So you support the tenant exchange in the bank? So what kind of subtitles standard we support in UPLAY? For bank? For bank, ah, for bank, sorry. So for video and series, for those of you who don't know that video and series, a part of the picture on the SDI interface, the raw video, that embeds some structure. So basically OP47, so that means teletext basically. So we take that and we turn it into a teletext packet. And other things that we do. All the Americans, so in SD, CEA 608, legacy teletext, NHD 708, and some other things, all the American SD and all the European SD, and the pass through of the US bank as well. So captions and subtitles. I'm not sure it's in bank, it's in VBI, right? When in SD it's VBI. I was specifically referring to bank because I worked on it last summer. And the other thing we support is COTY 104. That's not for subtitling, but that's to determine the timing of the beginning of show, or the end of the show, or splicing and so on. One more question. How about DVB sub? So how about DVB sub? The thing is DVB sub, you won't find it in SDI. As far as I know, there's no standard to invest in SDI. From a TS to a TS, we of course demultiplex it and remultiplex it. I think you have code that allows you to put it on screen. That's actually for teletext. Not just for teletext. It should work. It's a bit much. We don't do subtitles. Actually it's never been tested, but it should work. If your question was do we support transcoding teletext to DVB sub, that's the moment no. But this is something we're seriously thinking about. Thank you. That's it, I think. Thank you. You're welcome. Thank you.
 I don't have the microphone.  Never mind. This man needs no introduction, but because he has run the vast majority of the work for POSTEV for the Open Media Room,  in conjunction with Adi and Fran and myself, I'd like to bring him around.  Thank you.  So it's Christophe Massio and he'll be talking about U-Pipe, a very interesting project that we work on as well.  Thank you, Kieran. Maybe I should have changed my t-shirt because I'm not the Dev Room person now,  but I'm the company person now, but they told me not to do that in front of the camera, so it was too dangerous.  So a new talk about U-Pipe, we already did one last year and the year before, but it will be on a different topic this time.  The first question for people who weren't there at the previous year is what is U-Pipe?  So U-Pipe is a young multimedia framework written in C. We started in 2012, so that means we're quite young,  not as young now, but still quite young compared to similar projects were born in the 1990s.  That means we have, of course, a lot fewer modules, fewer support,  but also we have been able to make some educated choice about the technologies of today.  So U-Pipe was initiated by my company, Open Head End, and some of my employees,  but there are now three supporting companies, including Kieran as well, we use it,  and last time I counted seven contributors.  The focus of U-Pipe is a bit different from what you can see with VLC or maybe G-Streamer.  We focus on reliability and efficiency and above all compliance.  So that means we don't aim at playing any kind of file that's on the Internet.  If it doesn't comply to the standard it's supposed to comply to, we will say May.  We also focus on broadcasting professional applications.  Actually, most of the use cases I have today are on the real world,  in the real broadcast world with real customers in the broadcast domain.  The license of U-Pipe is MIT and LGPL, so it's not both.  Some modules are MIT, the core is MIT, the headers are MIT.  The main pipes are MIT, that is what you need to build a pipeline, basically,  duplication, source, file-source, file-sync, UDP and so on.  All of that is MIT. We have some modules that are LGPL,  that's mainly the code that deals with the codec format,  so what we call the framers in our lingo.  And also some support libraries are also LGPL, like Liby Codec.  So the binding code is also LGPL.  So those of you whether the previous year, what's new, the question is simple.  So too long don't read.  We've had a lot of work on the Eventloop API to make it more complete.  So now you don't need to call anymore the Eventloop directly from your program.  And it's also easy launching P-threads, P-thread workers.  We have a nice utility to dump pipeline in GraphViz format.  So some of the slides we will see later have been automatically generated from U-Pipe using GraphViz.  You will see that it's quite nice, quite verbal as well.  The legit bindings, I talked about them last year,  but it's finally been merged in.  So you can now write a U-Pipe client using just Lua.  And Lua is interesting for that because it abstracts all the ref counting of the structure.  Most of our structures are ref counted, but in Lua, Lua takes care of the ref counts  and freeze automatically the structure you don't use anymore.  In C you have to do it by hand.  So that's interesting.  In the feature side, we've had people contributing,  a third company contributing an HLS client.  So some other frameworks have also HLS clients,  but we now do have one where you could choose the bandwidth or the variant you want to have.  And you can re-multiplex it, repurpose it in a different format.  I will show later an example where we repurpose HLS to a Transports Stream,  a UDP Transports Stream, standard Transports Stream.  We've had some work on X265 as well, so we're able to decode it and support it.  Vang supporting the SDI if you don't know what that means, don't care.  If you do, bad for you.  And well, I wanted to release Previz number five,  but the work is not finished yet, but we'll probably do that in the next few weeks.  And after that, 1.0, we hope.  So unlike Previz here, I'm not here to give you an extensive talk on the insides of your pipe  and why it's a good pipeline, but I will give you examples of what you can do with your pipe.  And I will start with an inventory of all the modules we have for inputs,  output theaters and so on.  And then I talk about use cases, typical use cases that are in production today.  So the inputs we have, well, some of them are quite standard.  Of course, in the broadcast world, we still have specific connections like SDI and ASI,  so we support two vendors for that.  Natively, inside your pipe, we support, of course, the DIU, DPH, ETP and so on protocols.  We have a compliant ESDMUX, or compliant is important for us, as I said.  We also have an RTP DMAX to be able to read one or several RTP streams from the same program.  HLS Client, I talked about it already.  I have here MultiCAD directory, but it's a bit of a specific format that allows you to record 24-7 streams  in chunks and expire older chunks.  So we can also support that with U-Pipe.  It's come from a program that's called MultiCAD as part of the VDRAN project.  Externally, we support the BD format for sources.  It's actually a work in progress.  Some of the formats may not work at the moment because there are still adaptations to do.  As for the outputs, well, again, we have hardware outputs from SDI and ASI that have not been merged at the moment,  but they exist from where I'm getting them.  So if you look for it, you can ask us and we'll tell you where it is.  Natively, we support, as usual, the FI UDP RTP.  We also support compliant ESMUX.  So that's one of the kind that's probably the thing that differentiates us most from other projects.  In that, we have a compliant ESMUX, that output streams that are analysed by a professional analyser,  and they say it's okay.  So that's quite a good thing.  MultiCAD directory again.  And we can use also Externally, the BD format.  This time, it works.  In production, I have streams to RTMP, ICAST, and other formats using the BD format.  And GLX, Alizar.  And we were talking yesterday about Wayland.  Fernman was talking about Wayland outputs also that is working on.  So inputs and outputs are okay, but what can you do in between?  So first, the filters that we have, so internally, natively, we support, well, the standard interlaced,  bleeding, bleeding means to take a picture and you bleed it on top of your video, like a logo,  without transparency.  Bleeding also allows us to do mosaic.  I will show you later.  Crop.  We also have V210 pack and pack assembly optimised functions.  If you don't know what it is, good for you.  It's some kind of a format output by some SDI cards for 10-bit video.  And so it's more compact than the traditional reports on 16-bit, but it's also much harder to read.  External libraries, of course, are very useful for filters.  Of course, CBCD-Codec provides most of our decoders and encoders.  X264 is also an encoder we use a lot.  And the traditional software resample as well.  Leavespix is a recent addition that allows us to do resampling without changing the pitch.  So it's actually much nicer in the broadcast world where you have to compensate for a drift  where you don't hear it thanks to Leavespix.  And we also have bindings to Leavesvbi, but just for American subtitling system.  Another important piece of our project is what we call the framers.  So the framers are analog to what EVCodec calls the parsers.  So that's basically a place where you have the knowledge about the codecs.  So that's pieces of code that will parse the codecs, tell you this is a frame,  this is a head of a frame, this is a 25 FPS for a stream,  and interpolates the PTS from frame to frame and so on.  But in addition to that, it's not just a parser, but it also acts as what EVCodec again calls Bstream Filter,  that allows you to transform the format, the stream format into another.  For instance, in X264, if you want to put X264 into TS, you have an annex called annex B.  That is, you put a start code in front of your structures.  If you want to put X264 in MP4, it's a different format.  It's not start code anymore, but it's based on size.  And so this transformation is dealt with by the framers in our project.  We also have an interesting mechanism in which all of this is actually performed automatically without even you knowing it.  So basically, the thing talks to the previous pipes and say, I need annex B.  And so the framer will say, I don't receive an annex B, so I will convert automatically.  And we have support for a few video formats, MP2, X264, and now X265, that's a recent addition.  A lot of audio formats and subtitling systems, so telotex and DVD subtitles.  Why would you use U-Pipe for broadcast world?  Well, we have several assets, in addition to those I already mentioned.  Our clock system is actually one of the major points, as we said yesterday at the meetup.  In U-Pipe, we keep actually three clocks for each packet, the original timestamp that was in the stream.  Reconstructed timestamps, that's always monotonously increasing.  So the demux makes sure that it's always a monotonously increasing.  And that's what we call the program timestamp.  It's basically the clock of the encoder, the guy that gives you the stream.  And we have the system timestamp.  So the system timestamp is based on the clock of your hardware, your machine.  And so typically for display, you would use the system timestamp.  Most of the projects only keep the system timestamp, but that means that if you have a drift,  sometimes you have a shorter delay or longer delay, and so you normally have 40 milliseconds exactly between frames.  And that's a problem for some codecs.  So that's why we keep all of those clocks.  Also, the system timestamp, I said it was the system time.  That's not completely true.  Usually it's a get time of day or a clock get time.  But there are also use cases, which is interesting to get the clock of hardware clock, like on the ASI or SDI card.  And that's the use case we have in reality.  So we can replace all of these by any other hardware clock, if you want.  In U-Pipe, everything is dynamic.  That means the model of U-Pipe is to, is transpose stream.  So in transpose stream, you can have new elementary stream.  You can remove an elementary stream at any time.  So you can have subtitling, arriving, all of a sudden.  So everything has been built in U-Pipe to allow for automatic forking of a new decoder, a new parser, and so on, if needed.  If the user wants it, of course.  But so the framework allows that.  We also have efficient threading.  You decide where you put the threads, not our framework.  So if you have a thread, let's say AV codec, usually, you want to depot another thread.  You just create what we call worker, and it will move to another thread.  If you don't want it, for some reason, because for instance, you're a very low latency, you can work with no thread at all.  The framework allows that as long as your core is enough, of course, to do all of that.  We also have shared buffers with Copian white and the Eurocopy semantics.  So now you can see that more and more, but without that in 2012.  And we were binding, so I already talked about earlier.  So that was for the assets and the inventory.  Let's see a few real-world examples.  The first example, I'm not sure you will see properly, but let's try.  The first real-world example I have is some kind of a player.  So it can be a player on your PC, but it can also be an IRD integrated receiver decoder, like in the professional world.  So these graphs have been made by the U-PipeDump API that I talked about earlier.  So it's actually everything that is spawned when you start a U-Pipe pipeline.  So on top of it, you have the source. Actually, it's the worker, the W worker source.  So it's in a different thread for performance reasons.  And we read from, in that case, from a file. It can be also a FIFO.  Then is coming the TSD-Mux.  So the TSD-Mux is the main thread here, is the main pipe, super pipe, we call it.  That has a son, that's the program, and two other sons. The program has two other sons, the audio and the video.  So inside the D-Mux, it says there are a lot of sub-pipes that do a lot of things like D-Caps, PSD-Caps, Framers and so on.  And on the output, you have your frames.  And in two different workers for audio and video, you decode it with EV codec.  Here is the part of the pipeline that is with subtitles, bleeding subtitles, if you have some.  In our case, we don't have.  FFMT is something that uses software scale and the interlace to the interlace and, well, put it in the correct format.  It's RGB in that case, because we are using GLX.  And the TRIGP and Play Video and Play pipe are used for synchronization.  So GLX and the audio is also on its own thread, that's why it's a worker.  I'm not sure if you can see it properly, I don't see it in that distance, but I hope so.  Let's take a little bit more complicated example, a program that does a TS-reimba multiplexing.  So we have a TS at the source.  So again, in our worker source here, we have a UDP source, this time RTP-D-Caps.  And we want to create another UDP and we remitteplex in between.  We could also transcode, but that would add more complexity to the graph.  So the graph is already barely readable, so let's try to keep it simpler.  So again, after the source, we enter the TS-D-Mux.  So again, in that case, we only have one elementary stream, so I chose to have only one video,  because otherwise it's complicated things a lot.  So the internal of the TS-D-Mux is the split pipe that allows to select which PID you want.  And we also have decoders for PAT and PMT, which has internal structures of the TS.  And then you have the TS-Mux, which is quite symmetric compared to the TS-D-Mux program and input elementary stream.  The output of the TS-Mux is then sent to also another worker thread that adds an RTP header and outputs it to UDP.  The last use case, because I'm running out of time, is quite a nice application we use in my company for recording.  In fact, actually, I simplified it a lot, because otherwise it would be too big to display on the screen.  But basically, we have an application where we receive a stream from UDP again, UDP RTP.  We record it immediately as TS, but at the same time, we decode it, so D-Mux decode it,  to get some frames, the key frames, for thumbnails.  And we recreate JPEGs from the thumbnails.  So here you see a depth pipe that one is directly written to the disk,  and the other is sent to the TS-D-Mux again.  So now you're used to it.  And at the output of the TS-D-Mux, we have a bit more pipeline.  Between the arrows, you can see the types, but it's a bit...  So evico-deck, the interlace, because for JPEG you want an interlace.  And this pipeline here is ad hoc, create some out of the frames we've selected.  And we record it with evico-deck encoder, this one, for JPEG, and write it with a file sync to a file.  Okay, last use case, but this time I won't show you a graph, because it would be enormous.  It's a mosaic.  So this is, for instance, a mosaic we have at work.  So this is a real life example.  So basically all of this is done with your pipe, using a pipeline per input,  outputting two bleed functions, so bleed pipes, that will bleed each of the thumb to a single picture.  And so normally it's also live.  This is also for the audio, so that's a nice contribution by OBS.  It moves with your audio level.  So all of this is done with a U-pipe pipeline.  Other use cases that we have in production that I did not have time to talk about here.  So IRD, of course, we have a company using that from TS, we could also imagine it from HLS.  Live encoder, live transcoder, to TS, or to RTMP, I SCAST, anything that I use for my support, basically.  Live transcoder, that's something we have in our company as well.  We would from TS usually to MP4, that's a typical use case for us.  We also have an MPTS max, that's a product from my company as well,  based entirely based on your pipe and the TS max that you've seen earlier.  It would be quite a large workflow to show, but it works with your pipe.  And also something we demonstrated actually at the IBC last year, is a play out system with overlay.  So we've just played out files, decoded files, and added a logo that moves and a banner and a picture inside of a picture, picture in picture and so on.  I think I'm right on time for some questions.  I just wanted to, you mentioned HTTP, is it compatible with HTTPS?  So you said I talked about HTTP, but is it compatible with HTTPS?  At the moment, I don't think so.  Because the company that provided it doesn't use it.  Alright, third party, work with you?  Yes, it's a nameless network operator, I'm not sure we can say who it is, who contributed that part to us.  And they did HTTP, they did AES, also unscrambling, if the stream is scrambled.  AES inclusion is available?  Yes, it's already merged in.  So it also supports whether you have the audio inside, mixed with the video or a separate file, or variant, I don't know how you call it, in your M3 or U8.  You said that the MPEGTS standard is compatible with many MPEGTS standards?  So which MPEGTS standard do we comply to?  First, the ISO, and what I was actually referring to with that is the fact that we TSTD compliant.  That means that the timing of a packet has very strong constraints in the TST specification.  You can't send the packet to early, you can't send it too late either, you can't burst, and so on.  All of that is specified in this specification, and it's actually very difficult to understand it to years.  So that's what I was referring to.  We also comply to DVB, and we have decoders for SDT, NIT, and so on, whether usual.  That's not specific to our project, but yeah.  Any more questions?  The use cases, do you have the code for the sample online or anything?  The use cases for?  Yeah, we published the code for the new cases, new cases that you showed.  So have we published the codes for use cases? Some of them are online.  So the player basically is an example that we call UPLAY.  That's in the example directory of the UPLAY repository.  So if you want to see how I code this on GitHub.  So the player is the transcoder, the TS-REMEX is also, it's a test unit actually called UPLAY TS-TEST  that we use to test that our D-MUX and MUX don't send behavior from release to release.  The third one was recording is not.  It's actually not published yet.  Probably at some point we will, but not so far.  One also very important thing, if you wish to contact us,  so we have a website, UPLAY.org of course, we have our GitHub,  and if you wish to talk to us, the best is to come to our IRC, UPLAY.org on FreeNode.  We also have a mailing list, but usually when I say that, Q1 laughs.  Sorry for asking.  So what are you supporting?  Bank?  Can you type?  So you support the tenant exchange in the bank?  So what kind of subtitles standard we support in UPLAY?  For bank?  For bank, ah, for bank, sorry.  So for video and series, for those of you who don't know that video and series,  a part of the picture on the SDI interface, the raw video,  that embeds some structure.  So basically OP47, so that means teletext basically.  So we take that and we turn it into a teletext packet.  And other things that we do.  All the Americans, so in SD, CEA 608, legacy teletext, NHD 708,  and some other things, all the American SD and all the European SD,  and the pass through of the US bank as well.  So captions and subtitles.  I'm not sure it's in bank, it's in VBI, right?  When in SD it's VBI.  I was specifically referring to bank because I worked on it last summer.  And the other thing we support is COTY 104.  That's not for subtitling, but that's to determine the timing of the beginning of show,  or the end of the show, or splicing and so on.  One more question.  How about DVB sub?  So how about DVB sub?  The thing is DVB sub, you won't find it in SDI.  As far as I know, there's no standard to invest in SDI.  From a TS to a TS, we of course demultiplex it and remultiplex it.  I think you have code that allows you to put it on screen.  That's actually for teletext.  Not just for teletext.  It should work.  It's a bit much.  We don't do subtitles.  Actually it's never been tested, but it should work.  If your question was do we support transcoding teletext to DVB sub,  that's the moment no.  But this is something we're seriously thinking about.  Thank you.  That's it, I think.  Thank you.  You're welcome.  Thank you.
Overview_of_Upipe_modules_for_broadcast_professionals_0_131.png Overview_of_Upipe_modules_for_broadcast_professionals_132_1379.png Overview_of_Upipe_modules_for_broadcast_professionals_1380_1943.png Overview_of_Upipe_modules_for_broadcast_professionals_1944_8123.png Overview_of_Upipe_modules_for_broadcast_professionals_8124_22103.png Overview_of_Upipe_modules_for_broadcast_professionals_22104_22355.png Overview_of_Upipe_modules_for_broadcast_professionals_22356_24455.png Overview_of_Upipe_modules_for_broadcast_professionals_24456_24767.png Overview_of_Upipe_modules_for_broadcast_professionals_24768_24827.png Overview_of_Upipe_modules_for_broadcast_professionals_24828_26387.png Overview_of_Upipe_modules_for_broadcast_professionals_26388_26531.png Overview_of_Upipe_modules_for_broadcast_professionals_26532_26639.png Overview_of_Upipe_modules_for_broadcast_professionals_26640_26927.png Overview_of_Upipe_modules_for_broadcast_professionals_26928_27035.png Overview_of_Upipe_modules_for_broadcast_professionals_27036_30131.png Overview_of_Upipe_modules_for_broadcast_professionals_30132_31691.png Overview_of_Upipe_modules_for_broadcast_professionals_31692_31859.png Overview_of_Upipe_modules_for_broadcast_professionals_31860_33383.png Overview_of_Upipe_modules_for_broadcast_professionals_33384_33767.png Overview_of_Upipe_modules_for_broadcast_professionals_33768_34223.png Overview_of_Upipe_modules_for_broadcast_professionals_34224_34571.png Overview_of_Upipe_modules_for_broadcast_professionals_34572_34715.png Overview_of_Upipe_modules_for_broadcast_professionals_34716_34943.png Overview_of_Upipe_modules_for_broadcast_professionals_34944_35099.png Overview_of_Upipe_modules_for_broadcast_professionals_35100_35447.png Overview_of_Upipe_modules_for_broadcast_professionals_35448_36011.png Overview_of_Upipe_modules_for_broadcast_professionals_36012_36395.png Overview_of_Upipe_modules_for_broadcast_professionals_36396_36755.png Overview_of_Upipe_modules_for_broadcast_professionals_36756_38495.png Overview_of_Upipe_modules_for_broadcast_professionals_38496_38674.png
I don't have the microphone. Never mind. This man needs no introduction, but because he has run the vast majority of the work for POSTEV for the Open Media Room, in conjunction with Adi and Fran and myself, I'd like to bring him around. Thank you. So it's Christophe Massio and he'll be talking about U-Pipe, a very interesting project that we work on as well. Thank you, Kieran. Maybe I should have changed my t-shirt because I'm not the Dev Room person now, but I'm the company person now, but they told me not to do that in front of the camera, so it was too dangerous. So a new talk about U-Pipe, we already did one last year and the year before, but it will be on a different topic this time. The first question for people who weren't there at the previous year is what is U-Pipe? So U-Pipe is a young multimedia framework written in C. We started in 2012, so that means we're quite young, not as young now, but still quite young compared to similar projects were born in the 1990s. That means we have, of course, a lot fewer modules, fewer support, but also we have been able to make some educated choice about the technologies of today. So U-Pipe was initiated by my company, Open Head End, and some of my employees, but there are now three supporting companies, including Kieran as well, we use it, and last time I counted seven contributors. The focus of U-Pipe is a bit different from what you can see with VLC or maybe G-Streamer. We focus on reliability and efficiency and above all compliance. So that means we don't aim at playing any kind of file that's on the Internet. If it doesn't comply to the standard it's supposed to comply to, we will say May. We also focus on broadcasting professional applications. Actually, most of the use cases I have today are on the real world, in the real broadcast world with real customers in the broadcast domain. The license of U-Pipe is MIT and LGPL, so it's not both. Some modules are MIT, the core is MIT, the headers are MIT. The main pipes are MIT, that is what you need to build a pipeline, basically, duplication, source, file-source, file-sync, UDP and so on. All of that is MIT. We have some modules that are LGPL, that's mainly the code that deals with the codec format, so what we call the framers in our lingo. And also some support libraries are also LGPL, like Liby Codec. So the binding code is also LGPL. So those of you whether the previous year, what's new, the question is simple. So too long don't read. We've had a lot of work on the Eventloop API to make it more complete. So now you don't need to call anymore the Eventloop directly from your program. And it's also easy launching P-threads, P-thread workers. We have a nice utility to dump pipeline in GraphViz format. So some of the slides we will see later have been automatically generated from U-Pipe using GraphViz. You will see that it's quite nice, quite verbal as well. The legit bindings, I talked about them last year, but it's finally been merged in. So you can now write a U-Pipe client using just Lua. And Lua is interesting for that because it abstracts all the ref counting of the structure. Most of our structures are ref counted, but in Lua, Lua takes care of the ref counts and freeze automatically the structure you don't use anymore. In C you have to do it by hand. So that's interesting. In the feature side, we've had people contributing, a third company contributing an HLS client. So some other frameworks have also HLS clients, but we now do have one where you could choose the bandwidth or the variant you want to have. And you can re-multiplex it, repurpose it in a different format. I will show later an example where we repurpose HLS to a Transports Stream, a UDP Transports Stream, standard Transports Stream. We've had some work on X265 as well, so we're able to decode it and support it. Vang supporting the SDI if you don't know what that means, don't care. If you do, bad for you. And well, I wanted to release Previz number five, but the work is not finished yet, but we'll probably do that in the next few weeks. And after that, 1.0, we hope. So unlike Previz here, I'm not here to give you an extensive talk on the insides of your pipe and why it's a good pipeline, but I will give you examples of what you can do with your pipe. And I will start with an inventory of all the modules we have for inputs, output theaters and so on. And then I talk about use cases, typical use cases that are in production today. So the inputs we have, well, some of them are quite standard. Of course, in the broadcast world, we still have specific connections like SDI and ASI, so we support two vendors for that. Natively, inside your pipe, we support, of course, the DIU, DPH, ETP and so on protocols. We have a compliant ESDMUX, or compliant is important for us, as I said. We also have an RTP DMAX to be able to read one or several RTP streams from the same program. HLS Client, I talked about it already. I have here MultiCAD directory, but it's a bit of a specific format that allows you to record 24-7 streams in chunks and expire older chunks. So we can also support that with U-Pipe. It's come from a program that's called MultiCAD as part of the VDRAN project. Externally, we support the BD format for sources. It's actually a work in progress. Some of the formats may not work at the moment because there are still adaptations to do. As for the outputs, well, again, we have hardware outputs from SDI and ASI that have not been merged at the moment, but they exist from where I'm getting them. So if you look for it, you can ask us and we'll tell you where it is. Natively, we support, as usual, the FI UDP RTP. We also support compliant ESMUX. So that's one of the kind that's probably the thing that differentiates us most from other projects. In that, we have a compliant ESMUX, that output streams that are analysed by a professional analyser, and they say it's okay. So that's quite a good thing. MultiCAD directory again. And we can use also Externally, the BD format. This time, it works. In production, I have streams to RTMP, ICAST, and other formats using the BD format. And GLX, Alizar. And we were talking yesterday about Wayland. Fernman was talking about Wayland outputs also that is working on. So inputs and outputs are okay, but what can you do in between? So first, the filters that we have, so internally, natively, we support, well, the standard interlaced, bleeding, bleeding means to take a picture and you bleed it on top of your video, like a logo, without transparency. Bleeding also allows us to do mosaic. I will show you later. Crop. We also have V210 pack and pack assembly optimised functions. If you don't know what it is, good for you. It's some kind of a format output by some SDI cards for 10-bit video. And so it's more compact than the traditional reports on 16-bit, but it's also much harder to read. External libraries, of course, are very useful for filters. Of course, CBCD-Codec provides most of our decoders and encoders. X264 is also an encoder we use a lot. And the traditional software resample as well. Leavespix is a recent addition that allows us to do resampling without changing the pitch. So it's actually much nicer in the broadcast world where you have to compensate for a drift where you don't hear it thanks to Leavespix. And we also have bindings to Leavesvbi, but just for American subtitling system. Another important piece of our project is what we call the framers. So the framers are analog to what EVCodec calls the parsers. So that's basically a place where you have the knowledge about the codecs. So that's pieces of code that will parse the codecs, tell you this is a frame, this is a head of a frame, this is a 25 FPS for a stream, and interpolates the PTS from frame to frame and so on. But in addition to that, it's not just a parser, but it also acts as what EVCodec again calls Bstream Filter, that allows you to transform the format, the stream format into another. For instance, in X264, if you want to put X264 into TS, you have an annex called annex B. That is, you put a start code in front of your structures. If you want to put X264 in MP4, it's a different format. It's not start code anymore, but it's based on size. And so this transformation is dealt with by the framers in our project. We also have an interesting mechanism in which all of this is actually performed automatically without even you knowing it. So basically, the thing talks to the previous pipes and say, I need annex B. And so the framer will say, I don't receive an annex B, so I will convert automatically. And we have support for a few video formats, MP2, X264, and now X265, that's a recent addition. A lot of audio formats and subtitling systems, so telotex and DVD subtitles. Why would you use U-Pipe for broadcast world? Well, we have several assets, in addition to those I already mentioned. Our clock system is actually one of the major points, as we said yesterday at the meetup. In U-Pipe, we keep actually three clocks for each packet, the original timestamp that was in the stream. Reconstructed timestamps, that's always monotonously increasing. So the demux makes sure that it's always a monotonously increasing. And that's what we call the program timestamp. It's basically the clock of the encoder, the guy that gives you the stream. And we have the system timestamp. So the system timestamp is based on the clock of your hardware, your machine. And so typically for display, you would use the system timestamp. Most of the projects only keep the system timestamp, but that means that if you have a drift, sometimes you have a shorter delay or longer delay, and so you normally have 40 milliseconds exactly between frames. And that's a problem for some codecs. So that's why we keep all of those clocks. Also, the system timestamp, I said it was the system time. That's not completely true. Usually it's a get time of day or a clock get time. But there are also use cases, which is interesting to get the clock of hardware clock, like on the ASI or SDI card. And that's the use case we have in reality. So we can replace all of these by any other hardware clock, if you want. In U-Pipe, everything is dynamic. That means the model of U-Pipe is to, is transpose stream. So in transpose stream, you can have new elementary stream. You can remove an elementary stream at any time. So you can have subtitling, arriving, all of a sudden. So everything has been built in U-Pipe to allow for automatic forking of a new decoder, a new parser, and so on, if needed. If the user wants it, of course. But so the framework allows that. We also have efficient threading. You decide where you put the threads, not our framework. So if you have a thread, let's say AV codec, usually, you want to depot another thread. You just create what we call worker, and it will move to another thread. If you don't want it, for some reason, because for instance, you're a very low latency, you can work with no thread at all. The framework allows that as long as your core is enough, of course, to do all of that. We also have shared buffers with Copian white and the Eurocopy semantics. So now you can see that more and more, but without that in 2012. And we were binding, so I already talked about earlier. So that was for the assets and the inventory. Let's see a few real-world examples. The first example, I'm not sure you will see properly, but let's try. The first real-world example I have is some kind of a player. So it can be a player on your PC, but it can also be an IRD integrated receiver decoder, like in the professional world. So these graphs have been made by the U-PipeDump API that I talked about earlier. So it's actually everything that is spawned when you start a U-Pipe pipeline. So on top of it, you have the source. Actually, it's the worker, the W worker source. So it's in a different thread for performance reasons. And we read from, in that case, from a file. It can be also a FIFO. Then is coming the TSD-Mux. So the TSD-Mux is the main thread here, is the main pipe, super pipe, we call it. That has a son, that's the program, and two other sons. The program has two other sons, the audio and the video. So inside the D-Mux, it says there are a lot of sub-pipes that do a lot of things like D-Caps, PSD-Caps, Framers and so on. And on the output, you have your frames. And in two different workers for audio and video, you decode it with EV codec. Here is the part of the pipeline that is with subtitles, bleeding subtitles, if you have some. In our case, we don't have. FFMT is something that uses software scale and the interlace to the interlace and, well, put it in the correct format. It's RGB in that case, because we are using GLX. And the TRIGP and Play Video and Play pipe are used for synchronization. So GLX and the audio is also on its own thread, that's why it's a worker. I'm not sure if you can see it properly, I don't see it in that distance, but I hope so. Let's take a little bit more complicated example, a program that does a TS-reimba multiplexing. So we have a TS at the source. So again, in our worker source here, we have a UDP source, this time RTP-D-Caps. And we want to create another UDP and we remitteplex in between. We could also transcode, but that would add more complexity to the graph. So the graph is already barely readable, so let's try to keep it simpler. So again, after the source, we enter the TS-D-Mux. So again, in that case, we only have one elementary stream, so I chose to have only one video, because otherwise it's complicated things a lot. So the internal of the TS-D-Mux is the split pipe that allows to select which PID you want. And we also have decoders for PAT and PMT, which has internal structures of the TS. And then you have the TS-Mux, which is quite symmetric compared to the TS-D-Mux program and input elementary stream. The output of the TS-Mux is then sent to also another worker thread that adds an RTP header and outputs it to UDP. The last use case, because I'm running out of time, is quite a nice application we use in my company for recording. In fact, actually, I simplified it a lot, because otherwise it would be too big to display on the screen. But basically, we have an application where we receive a stream from UDP again, UDP RTP. We record it immediately as TS, but at the same time, we decode it, so D-Mux decode it, to get some frames, the key frames, for thumbnails. And we recreate JPEGs from the thumbnails. So here you see a depth pipe that one is directly written to the disk, and the other is sent to the TS-D-Mux again. So now you're used to it. And at the output of the TS-D-Mux, we have a bit more pipeline. Between the arrows, you can see the types, but it's a bit... So evico-deck, the interlace, because for JPEG you want an interlace. And this pipeline here is ad hoc, create some out of the frames we've selected. And we record it with evico-deck encoder, this one, for JPEG, and write it with a file sync to a file. Okay, last use case, but this time I won't show you a graph, because it would be enormous. It's a mosaic. So this is, for instance, a mosaic we have at work. So this is a real life example. So basically all of this is done with your pipe, using a pipeline per input, outputting two bleed functions, so bleed pipes, that will bleed each of the thumb to a single picture. And so normally it's also live. This is also for the audio, so that's a nice contribution by OBS. It moves with your audio level. So all of this is done with a U-pipe pipeline. Other use cases that we have in production that I did not have time to talk about here. So IRD, of course, we have a company using that from TS, we could also imagine it from HLS. Live encoder, live transcoder, to TS, or to RTMP, I SCAST, anything that I use for my support, basically. Live transcoder, that's something we have in our company as well. We would from TS usually to MP4, that's a typical use case for us. We also have an MPTS max, that's a product from my company as well, based entirely based on your pipe and the TS max that you've seen earlier. It would be quite a large workflow to show, but it works with your pipe. And also something we demonstrated actually at the IBC last year, is a play out system with overlay. So we've just played out files, decoded files, and added a logo that moves and a banner and a picture inside of a picture, picture in picture and so on. I think I'm right on time for some questions. I just wanted to, you mentioned HTTP, is it compatible with HTTPS? So you said I talked about HTTP, but is it compatible with HTTPS? At the moment, I don't think so. Because the company that provided it doesn't use it. Alright, third party, work with you? Yes, it's a nameless network operator, I'm not sure we can say who it is, who contributed that part to us. And they did HTTP, they did AES, also unscrambling, if the stream is scrambled. AES inclusion is available? Yes, it's already merged in. So it also supports whether you have the audio inside, mixed with the video or a separate file, or variant, I don't know how you call it, in your M3 or U8. You said that the MPEGTS standard is compatible with many MPEGTS standards? So which MPEGTS standard do we comply to? First, the ISO, and what I was actually referring to with that is the fact that we TSTD compliant. That means that the timing of a packet has very strong constraints in the TST specification. You can't send the packet to early, you can't send it too late either, you can't burst, and so on. All of that is specified in this specification, and it's actually very difficult to understand it to years. So that's what I was referring to. We also comply to DVB, and we have decoders for SDT, NIT, and so on, whether usual. That's not specific to our project, but yeah. Any more questions? The use cases, do you have the code for the sample online or anything? The use cases for? Yeah, we published the code for the new cases, new cases that you showed. So have we published the codes for use cases? Some of them are online. So the player basically is an example that we call UPLAY. That's in the example directory of the UPLAY repository. So if you want to see how I code this on GitHub. So the player is the transcoder, the TS-REMEX is also, it's a test unit actually called UPLAY TS-TEST that we use to test that our D-MUX and MUX don't send behavior from release to release. The third one was recording is not. It's actually not published yet. Probably at some point we will, but not so far. One also very important thing, if you wish to contact us, so we have a website, UPLAY.org of course, we have our GitHub, and if you wish to talk to us, the best is to come to our IRC, UPLAY.org on FreeNode. We also have a mailing list, but usually when I say that, Q1 laughs. Sorry for asking. So what are you supporting? Bank? Can you type? So you support the tenant exchange in the bank? So what kind of subtitles standard we support in UPLAY? For bank? For bank, ah, for bank, sorry. So for video and series, for those of you who don't know that video and series, a part of the picture on the SDI interface, the raw video, that embeds some structure. So basically OP47, so that means teletext basically. So we take that and we turn it into a teletext packet. And other things that we do. All the Americans, so in SD, CEA 608, legacy teletext, NHD 708, and some other things, all the American SD and all the European SD, and the pass through of the US bank as well. So captions and subtitles. I'm not sure it's in bank, it's in VBI, right? When in SD it's VBI. I was specifically referring to bank because I worked on it last summer. And the other thing we support is COTY 104. That's not for subtitling, but that's to determine the timing of the beginning of show, or the end of the show, or splicing and so on. One more question. How about DVB sub? So how about DVB sub? The thing is DVB sub, you won't find it in SDI. As far as I know, there's no standard to invest in SDI. From a TS to a TS, we of course demultiplex it and remultiplex it. I think you have code that allows you to put it on screen. That's actually for teletext. Not just for teletext. It should work. It's a bit much. We don't do subtitles. Actually it's never been tested, but it should work. If your question was do we support transcoding teletext to DVB sub, that's the moment no. But this is something we're seriously thinking about. Thank you. That's it, I think. Thank you. You're welcome. Thank you.
So some of the slides we will see later have been will start with an inventory of all the modules you this is a frame, this is a head of a frame, U-pipe pipeline. Other use cases that we have in