SVG Electronic Program Guides
Concolato, Cyril
With the development of convergent video codecs such as MPEG-4 AVC|H.264, it is now possible to view television progams on many types of devices, including mobile devices (e.g. iPhone). However, given the high number of available television programs, electronic program guides are required. There are many ways to provide electronic program guides applications on mobile devices. One way is to develop and deploy new native applications on each of the mobile plateforms (e.g. iPhone, Android, Windows Mobile). Another way is to rely on convergent Web standards such as SVG to leverage already deployed browsers. Following this second way, this paper presents the results of some investigations and experiments for the display of EPG data using SVG. In particular, we investigated different ways to generate and deliver EPG data. One traditional approach uses AJAX and SVG. On the client, some Javascript code pulls some XML representing the EPG data from a server and converts it into presentable SVG. Another approach consists in directly streaming SVG data, using 3GPP DIMS RTP format, to the client. We report on those two approaches showing the benefits and drawbacks of each. Finally, we demonstrate the EPG application on different clients such as PC equiped with GPAC or Opera, iPhone using Safari.
 Okay, so the topic of the talk that we present is a work that we're doing together with Jonathan Cilan here on the electronic program that is using the SDG. And this is completely in line with what you say about IPTV, for an analysis, we'll probably be the promised sort of thing, this issue is very consistent. So the context of our work is that we're witnessing convergence in many directions in a multilid world, right? First, there are convergent photo and video codecs. MPEG4 AC is supported in the most everywhere, AVC is also everywhere, no question about that. And for graphics, it's very similar, HTML, file or whatever, and SDG as well. So as people from Microsoft have said it, we will witness graphically and media-rich content everywhere, on PC, on set-top boxes, on phone, tablets, like this iPad here. And in this context, TV is also evolving. First, okay, it may be obvious that TV is becoming digital, right? But still, so yeah, and with digital TV we have more programs, more channels. And just to stress that it is really becoming digital and only digital. For example, in France, the switch off of the NLTV is scheduled for end of 2011. And there's an opportunity here with the TV becoming really digital to have more interactivity. And one of the standards that was not mentioned, you mentioned all IPF, there's a standard, new standard in Europe called HDB TV, or HTML broadcast broadband TV. It's an Etsy standard, so if you're interested you can have a look. So TV is evolving, devices and networks are evolving also. So as said, devices can play video, TVs can get connected to the internet already. And the mobile world also is changing. You can already have access to TV, 3G networks, but also mobile broadcast networks are being deployed. As you mentioned, the ATAC and H and in Europe, the DVH has not started, it would probably never start, I don't know. Maybe there would be a replacement like DVSH. But still, there are problems of deployment of these networks, cost problem. Especially when you want to reach, studies have shown that the usage of mobile TV is not really mobile. Most of the people use it at home, surprisingly. They are in their rooms with their phone and they look at the TV on their phone. Some studies have shown that. So one of the problems in deploying mobile TVs to have the single penetrating houses, so either you need to put more power in the antenna or you need to put more antennas. And that costs a lot. So here comes the project in which we are working, it's called Pingo. So it's a project to the three companies and us. Deepcom, French manufacturer for TV signal receivers, DVB, TV, HSH and so on. Baraco-Dameja is an integrator and it's financed by the French research institution. So we have this device here, it's an embedded platform. The goal is to have this device located near the window that captures the signal and redistributes it in the house and adapts it. So it can already receive DVBT, DVBH and DVBSH signals, transcode the video, changing the format. For example, if you receive HD signal and you want to send it to a mobile phone, you have to do some transcoding. If you receive a PEC2 video, you need to transform it into a PEC4AVC, things like that. And what is interesting for us is the transformation of the UPG data. And we'll talk about that later. And we're targeting PC phones and tablets, not TV, because TV can already receive the signal. And so the principle is that the end of our work at the ComparisTech is that we develop a framework or a method to receive the UPG data, to transform it into SVG and deliver it over Wi-Fi. And we investigate two approaches, one is streaming, and the other one is traditional AJAX. And of course we adapt it to the size of the screen, for example. So, okay, I will skip this. You know what is an electronic program down in UPG. To example, you showed some others. Just so that you know the ecosystem of the UPG, there are at least three. First, if you look at DVBT, so DVBT is the standard for terrestrial TV, not mobile, just for your TV in your house. And the UPG data is delivered over PEC2, a transportation stream. And the format is binary format. The format of the data, the UPG data, is a binary format called DVB and event information table. On the web, there are many examples. You retrieve it from the IP, and you can get either HTML or XML or whatever. And in DVBH and DVBSH, you have the same kind of protocol stack you showed for ATSC, MH. You have first the PEC2TS, then some IPDCs, a way to deliver IP packets on over MPEG2. And then you have the protocol to deliver the files over IP. And then you have some XMLs, maybe TV and ETIM, or something else. And so we implemented inputs from these three sources, types of sources. So again, why SVG? So yeah, well, of course, we like to work with SVG, and our player implements SVG, so it was natural to try it with SVG. But also SVG has interesting properties. The layout, for example, not having to rely on a flow layout allows you to put your programs into a layout that's not a table, that's not a strict table. Then you have gradients, you have animations, and you have interactivity, so that's nice. There is a video support, so in tiny, so that allows us to show the grid and the TV at the same time. Plus SVG is now supported more and more, so it's a big hit, this conference is a title. Then again, there's a mobile industry interest in SVG, through GPP, OMA, HTC, whatever. And what we wanted to investigate was the streaming of SVG, and we can do streaming using the RME or DIMS, it's almost the same thing. So for those who don't know what is DIMS, DIMS means Dynamic Interactive Motivating Scenes, it's a 3GPP standard based on the VET4 laser, which is based on SVG, so it's a stack of modifications to SVG. And the concepts are, okay, there are some extensions of SVG, but we didn't use them in our project. The most interesting part is that with DIMS you can send from a server to a client, you can send modifications of SVG when the server decides, not when the client requests them. And there can be insertions, removal, replacement, just as you would do them by script using the DOM. And there can be, these times, the modifications of SVG can be stored, either in files like MP4 files, and then you can synchronize them with the audio and video to make subtitles, to make regional interest tracking over a video. But you can also send them from a server, like any streaming server, or you can do progressive download of synchronized streams. So that's the architecture of DIMS. So the architecture of our system is first we have this server, which receives the DDB signals, transmits the transformed information over Wi-Fi to a phone, let's say an iPhone. And the architecture is first we have some demoderator receiving signal, we separate the audio and the EPG, the audio and video is transcode, the EPG is transformed in SVG, and then we have two paths. One is DIMS packaging and streaming over at RTP, which is as if we were doing video. And the second path is storing and then serving it with a classical web server. So there are, of course, advantages and drawbacks for all the approaches, and I'm not saying that one is better than the other, it's just different, and depending on your use cases you might want to use one or the other. But the traditional AJAX approach, our server will go on the web, retrieve or go with a T-signal, retrieve the program, generate XML files, store them in the web server, and they are able to fly it with parallelity, retrieve the XML and update its display. So with this approach, of course, we have a live server that's just decoding the programs, creating an XML and serving them. Adaptation is nice because then it's easier on the client than with the streaming approach because everything is on the client, so the client can do everything, can decide. There's no privacy issue of sending back my preferred programs, or there's no... It's simple, but okay, it's not as... The dynamicity is not as good as when you're just streaming, because when you're just streaming, every time there's a new program, you receive it, or a modification of the program, you receive it. But in the AJAX mode, you have to pull it, you have to wait for the next poll to update it. And also the layout, when we do the AJAX approach, we just send the XML of the APT programs. We don't change the layout. With the streaming approach, we can send modification of the scene to the date, the layout to the date, the charter to date, the style, and so on. So you can imagine that for Christmas, we could send updates of the theme, a theme like the Google page you have during Christmas is different from another time of the year. And for the streaming, the principle is that the program is retrieved from the broadcast source, they are transformed, packaged, and streamed over our RTP. And well, I don't know if it's a pro or a con, it's a pro or a con, but it reproduces the behavior of the broadcast channel, right? Things are pushed until the end user. There's no storage in the middle. The client is lighter. In our demonstration, we use JavaScript on the client only for the navigation, so I'll come back later on that. But for the construction, for the display, JavaScript is not used. We have a heavier server. The bandwidth between the server and the client is increased because we're sending EPG data plus presentation data, right? And it's more difficult, as I said, to adapt. To adapt, not to adapt. So some implementation details. The server, as you see in the picture, is an embedded platform running an R processor at 400 MHz with a video transcoding chip. The clients we are using, so for streaming, for DIMPS streaming, we're using only GPAC. It's the only player we could have. I don't know if you're a player, so for R and E. Okay, so we would be happy to test it for interpretability. And I know that someone else may be a keyboard. And for the Ajax, okay, we used all the browsers except IE9, and I tested just before my presentation. It doesn't work, so we have to fix it. So some results. Here is how it looks like on Chrome. So you have a grid, a typical grid. The video is displayed there, and then when you click on a program, you have some additional information here. We will see it on the video, in more detail, just to show you the looks. Opera. So in opera, we have some problems with the playback of the video. We have some problems with the same, the supported problems. This one is with Safari. Then we have, okay, this one is GPAC. It's a bit different than this one, and it's a DBBT example. The other one where the source was the web. This one is really DBBT, and in particular, it's in DBBT that when you retrieve programs, you only get two programs per channel. The current one and the next one, and they are being updated as the program goes. This is on the iPhone, and this is on the iPad. So you can see, for example, one kind of adaptation is that when you're on the iPad, you have room to show the video and the grid at the same time. When you're on the iPad, you cannot. You have a button here to switch between video mode and graphics mode back and forth. So I will show you the video of the iPad. So we're starting the application. It allows the grid and the video. And when you select the program, you can see that it's displayed here. We can shift the dates, like touching right and left moves the grid right and left, touching the grid vertically or changes the channel in display. You can zoom to display more or less, program changes the size of the grid. When we click on it, you can have more information, more of the abstract, the synopsis, the ratings, and still showing the video at the same time. And then if we want, we can go full speed, of course, just to show you the video. And then we have filters, so we can filter the content that we want to show, just movies, for example. And so programs have been removed and only the movies are remaining. Then we can go back to the app. So this is for the video. And then I have a live example. We're going to have to refresh because when I plug the keyboard, the resolution of my train has changed. So the layout is not dynamic, when we resize the window, we don't really reconcute the size of all the games. Yeah, okay, this is not live video. This is just one video because our server is in the other building and somehow it's down. So this is the same as the panoramic zone, actually. So it was down five minutes ago. And so you can see if I shift, I can browse, I can have more channels. And so on, okay? Okay, my last slide. Problems and limitations we faced when we did that. My first interoperability problems is usually the tiny one.do is not supported well enough to my taste. The first text area is not supported, so we don't have flow text easily. We have to do foreign objects, HTML, div. This is just not great. We can argue about that. Just turn everything inside out. Actually, we have first an HTML to have the video element of HTML. Then we have the SVG and then inside the SVG we have the foreign object with HTML. So we have three layers. But you do not need to take the whole area where you do the readout. You can do the multiple that demo. Yeah, let's give you first question. The trade access API is also not enough supported. And I think we have this discussion yesterday during the panel, the video element also. We had also a difference between events on mobile, like on the iPhone iPad. The name of events are not the same. Touch events instead of gesture events instead of clicks and so on. Lack of SVG support on Android platforms. Yes, I hope it will come. Lack of Vim support also. Windows, I think it's nice. And then we had some missing SVG features that we think would be nice to have. For example, screen orientation detection by events or whatever it means. Sorry. Pixel density detection. We wanted to change the font size or the layout depending on the pixel density just to make sure that the layout is proper, that legibility is correct. And this is missing. Text ellipses. When we have the name of a program that is that long but lasts for 30 seconds, we have to put it in a rectangle. And at the moment we just do a text area with clipping. Or I forgot where. Yeah, we do it also with clipping with CSS. Yeah, okay. We remove the name of the program instead of showing the program. And then we add a mode where we could replace long text with dot dot dot. It would be nice. And Z-Order also would be nice to manage more easily the different layers. The TV, the grid, things on top of the TV and so on. And there's an example in SVG spec. I think it's one of the two about nav index. And this example is exactly about EPG, right? There's a grid. You cannot use it. It's impossible. Why? Because you have to give next, well, north, south, northwest and so on. You have to give all the elements that are southeast, west and so on. But when you're doing this with programs that have duration, changing duration or small or short, the layout is not that easy. So it's very, it's not really usable. But we don't have yet a better proposal or fix it. We just wanted to report it. So, merci. Attention. I say it's on my computer. So, thank you. Thank you. Thank you. Thank you. Can you go back to the previous slide, please? It's just that this is the first part of my question, which is not really a question. I think some things you list as missing SVG features are not SVG features. Screen orientation detection. This shouldn't be SVG HTML, but I don't care. Right. So screen orientation is being worked on in, sorry. Yeah, that's being worked on. So density, there's a media query for that, I think, nowadays in the works. Text ellipses is in CSS. And that order is definitely on SVG features. But seriously, my question was, at some point you mentioned the differences between the streaming broadcast model and the HX model. I was wondering if you'd investigated things like comment support in browsers or using things like an XMPP library. They're very good ones. So that would give you push. Of course, other advantages of broadcast exist, but it might be interesting to compare XMPP with streaming. So you're saying you should have SVG HTML, CSS media queries, yeah? It's a stat, a tool box. Yeah, okay. I don't think it's... It just got in all the other users, so it doesn't have room to compare. Yeah, it's not a question of implementation, it can be read. Just because we split the spectrum... How many offering tools do you need to do that? You just need text-mates. That's all I use. You know, seriously, just because the spectrum is split into smaller parts doesn't mean it's more complicated. I mean, you know, you can take one thing and call it NPEG4. You know how much stuff is in there. You know what I mean? It's not a naming problem. What I'm saying is that, okay, the status-twin orientation has been defined in one. There's a general tool that we can see to do it. But there could be differences. I mean, I don't know the ways to apply it when you're only in an SVG context. It's not... It's a... It shouldn't be exclusive. It's not exclusive. You can use it with SVG. Yeah, this is not a client, but it's still the relevant tool. Okay, but what about the SVG? CSS can definitely be used on SVG. We don't know Oval's support everything yet. The text ellipsis, for example, is the... I was just looking at it being the text all over the property in CSS. And it does exactly what you want. I mean, your examples are second to dead. They're very interesting. We don't lay out the text if you can. But we could support the text ellipsis in SVG, too. And that makes total sense to us back. The other thing is your example kind of screams for the... It's exactly what we have in mind, what we say, in IT graphic to chronographic apps. And it screams for the mix of HTML, CSS, and SVG, because you have text that is flow... That is to flow. You need... In fact, you probably need all the power of CSS and HTML text if you start tackling complex scripts and all the other stuff that's important. You need to push. So it's really... Ultimately, you need all these features. You just gotta discover it's sort of... Okay, I like the demo. I like the box. I like the whole idea of collecting this broadcast and rebroadcasting it inside the house. I like it. But, I mean, you know, we're in an SVG conference, maybe this is heresy, but I didn't see anything on that UI that you couldn't have just done with absolutely positioned HTML. I mean, if you've got the JavaScript logic to lay out on the program grid, just use an absolutely positioned div of width and height, throw a queue, you know, round them and now with border radius and put a nice gradient background on it, and you pretty much got the same thing, and you could do the whole thing in HTML5. I mean, yes, we're in an SVG conference, but you didn't need an SVG to solve that problem. And also, there are historical reasons. We started with SVG because we started with a streaming approach where we had no JavaScript on the client. Yeah. Okay, so all the positioning was done, Bioserver sent as updates, and anything was positioned and the grid would be built progressively. And back then, there was no HTML5, so that's when they started. Oh, it was tired. No idea. Two years ago. Why do you have these types of data? Yeah, Ted kind of stole my question a little bit, but I had more questions about that, because, yeah, I mean, at first I thought that you were just going to lay the thing out using, you know, just like a regular viewbox, and then it was going to be the exact same UI, but, you know, the viewbox element had been scaled up for one. It's not at all. It's laid out. Is it that right? Do you think that, like, I mean, is it easier to do that? Like, when you're doing, because, like, when something needs to be laid out to take up the full screen orientation like that and have text position decided that, you know, I immediately think of HTML and divs, you know, because you have to do all of that. I mean, well, I guess there wasn't flow text in there, but there was definitely like flow, you know, flow. Sorry, I don't know if that's the essence to tell you, but I immediately think of HTML. So do you think it would actually be easier, I think, more sense to use that for this kind of application? Okay, SVG, the S stands for Scalability. Someone said it at the beginning of the conference, but scalability is not enough. Scalability in terms of graphic is not enough. When you're doing adaptation, you need to adapt the layout. And viewbox is the minimal tool, but in some cases it's not enough. So maybe for sure the layout logic can be implemented in scripts, and then you can do it in SVG or you can do it in HTML, CSS, and so on. There are different tools, but the result will be the same. So we pointed out. And again, historically when we push for the streaming approach, we push, we can filter the updates depending on the resolution, we get on the orientation and stuff like that. We wouldn't need the JavaScript to do the layouts, and even to change the orientation. So let's see. So, we have the demo on the iPad, we can also try it. So, give them a sec. Correct? No, depending on the approach. If you use the layout, it's done in the client. If you use streaming approach, there are several ways you can push the alternatives, like port 3 and landscape, and we tag the updates with port 3 and landscape, and then the player to decide on which orientation, but this is maybe static in this case. You choose like this or like that. Then you are at the piece. I'm used to the command, it's working on a scalable approach for updates, which is the size of the... Okay, yeah. Okay. Well, it seems to me, as I already mentioned earlier, it's good for the screen orientation, it would be better off with height and detection of medium curves. You don't need to know your orientation, because every day you want to watch the video on the side. So you would... In addition, you take the video on the side? Yeah, that's true. So it's applied immediately whenever you resize the voucher, it's applied constantly. So you don't need a refresh. And one tip about the video and opera, it's because you're using more files rather than... In this example, we use a H2TS. No, we own a spoiler, we have a Nogue, so it's a separate file from the section. That's what I said. Yeah. That's a good question. Thank you.
 Okay, so the topic of the talk that we present is a work that we're doing together with  Jonathan Cilan here on the electronic program that is using the SDG.  And this is completely in line with what you say about IPTV, for an analysis,  we'll probably be the promised sort of thing, this issue is very consistent.  So the context of our work is that we're witnessing convergence in many directions in a multilid world, right?  First, there are convergent photo and video codecs.  MPEG4 AC is supported in the most everywhere, AVC is also everywhere, no question about that.  And for graphics, it's very similar, HTML, file or whatever, and SDG as well.  So as people from Microsoft have said it, we will witness graphically and media-rich content everywhere,  on PC, on set-top boxes, on phone, tablets, like this iPad here.  And in this context, TV is also evolving.  First, okay, it may be obvious that TV is becoming digital, right?  But still, so yeah, and with digital TV we have more programs, more channels.  And just to stress that it is really becoming digital and only digital.  For example, in France, the switch off of the NLTV is scheduled for end of 2011.  And there's an opportunity here with the TV becoming really digital to have more interactivity.  And one of the standards that was not mentioned, you mentioned all IPF,  there's a standard, new standard in Europe called HDB TV, or HTML broadcast broadband TV.  It's an Etsy standard, so if you're interested you can have a look.  So TV is evolving, devices and networks are evolving also.  So as said, devices can play video, TVs can get connected to the internet already.  And the mobile world also is changing.  You can already have access to TV, 3G networks, but also mobile broadcast networks are being deployed.  As you mentioned, the ATAC and H and in Europe, the DVH has not started,  it would probably never start, I don't know.  Maybe there would be a replacement like DVSH.  But still, there are problems of deployment of these networks, cost problem.  Especially when you want to reach, studies have shown that the usage of mobile TV is not really mobile.  Most of the people use it at home, surprisingly.  They are in their rooms with their phone and they look at the TV on their phone.  Some studies have shown that.  So one of the problems in deploying mobile TVs to have the single penetrating houses,  so either you need to put more power in the antenna or you need to put more antennas.  And that costs a lot.  So here comes the project in which we are working, it's called Pingo.  So it's a project to the three companies and us.  Deepcom, French manufacturer for TV signal receivers,  DVB, TV, HSH and so on.  Baraco-Dameja is an integrator and it's financed by the French research institution.  So we have this device here, it's an embedded platform.  The goal is to have this device located near the window that captures the signal  and redistributes it in the house and adapts it.  So it can already receive DVBT, DVBH and DVBSH signals,  transcode the video, changing the format.  For example, if you receive HD signal and you want to send it to a mobile phone,  you have to do some transcoding.  If you receive a PEC2 video, you need to transform it into a PEC4AVC, things like that.  And what is interesting for us is the transformation of the UPG data.  And we'll talk about that later.  And we're targeting PC phones and tablets, not TV,  because TV can already receive the signal.  And so the principle is that the end of our work at the ComparisTech is  that we develop a framework or a method to receive the UPG data,  to transform it into SVG and deliver it over Wi-Fi.  And we investigate two approaches, one is streaming,  and the other one is traditional AJAX.  And of course we adapt it to the size of the screen, for example.  So, okay, I will skip this. You know what is an electronic program down in UPG.  To example, you showed some others.  Just so that you know the ecosystem of the UPG, there are at least three.  First, if you look at DVBT, so DVBT is the standard for terrestrial TV,  not mobile, just for your TV in your house.  And the UPG data is delivered over PEC2, a transportation stream.  And the format is binary format. The format of the data, the UPG data,  is a binary format called DVB and event information table.  On the web, there are many examples.  You retrieve it from the IP, and you can get either HTML or XML or whatever.  And in DVBH and DVBSH, you have the same kind of protocol stack  you showed for ATSC, MH. You have first the PEC2TS,  then some IPDCs, a way to deliver IP packets on over MPEG2.  And then you have the protocol to deliver the files over IP.  And then you have some XMLs, maybe TV and ETIM, or something else.  And so we implemented inputs from these three sources, types of sources.  So again, why SVG?  So yeah, well, of course, we like to work with SVG, and our player implements SVG,  so it was natural to try it with SVG.  But also SVG has interesting properties.  The layout, for example, not having to rely on a flow layout allows you to put your programs  into a layout that's not a table, that's not a strict table.  Then you have gradients, you have animations, and you have interactivity, so that's nice.  There is a video support, so in tiny, so that allows us to show the grid and the TV at the same time.  Plus SVG is now supported more and more, so it's a big hit, this conference is a title.  Then again, there's a mobile industry interest in SVG, through GPP, OMA, HTC, whatever.  And what we wanted to investigate was the streaming of SVG,  and we can do streaming using the RME or DIMS, it's almost the same thing.  So for those who don't know what is DIMS, DIMS means Dynamic Interactive Motivating Scenes,  it's a 3GPP standard based on the VET4 laser, which is based on SVG,  so it's a stack of modifications to SVG.  And the concepts are, okay, there are some extensions of SVG, but we didn't use them in our project.  The most interesting part is that with DIMS you can send from a server to a client,  you can send modifications of SVG when the server decides, not when the client requests them.  And there can be insertions, removal, replacement, just as you would do them by script using the DOM.  And there can be, these times, the modifications of SVG can be stored,  either in files like MP4 files, and then you can synchronize them with the audio and video  to make subtitles, to make regional interest tracking over a video.  But you can also send them from a server, like any streaming server,  or you can do progressive download of synchronized streams.  So that's the architecture of DIMS.  So the architecture of our system is first we have this server,  which receives the DDB signals, transmits the transformed information over Wi-Fi to a phone, let's say an iPhone.  And the architecture is first we have some demoderator receiving signal,  we separate the audio and the EPG, the audio and video is transcode, the EPG is transformed in SVG,  and then we have two paths.  One is DIMS packaging and streaming over at RTP, which is as if we were doing video.  And the second path is storing and then serving it with a classical web server.  So there are, of course, advantages and drawbacks for all the approaches,  and I'm not saying that one is better than the other, it's just different,  and depending on your use cases you might want to use one or the other.  But the traditional AJAX approach, our server will go on the web, retrieve or go with a T-signal,  retrieve the program, generate XML files, store them in the web server,  and they are able to fly it with parallelity, retrieve the XML and update its display.  So with this approach, of course, we have a live server that's just decoding the programs,  creating an XML and serving them.  Adaptation is nice because then it's easier on the client than with the streaming approach  because everything is on the client, so the client can do everything, can decide.  There's no privacy issue of sending back my preferred programs, or there's no...  It's simple, but okay, it's not as...  The dynamicity is not as good as when you're just streaming,  because when you're just streaming, every time there's a new program,  you receive it, or a modification of the program, you receive it.  But in the AJAX mode, you have to pull it, you have to wait for the next poll to update it.  And also the layout, when we do the AJAX approach, we just send the XML of the APT programs.  We don't change the layout.  With the streaming approach, we can send modification of the scene to the date,  the layout to the date, the charter to date, the style, and so on.  So you can imagine that for Christmas, we could send updates of the theme,  a theme like the Google page you have during Christmas is different from another time of the year.  And for the streaming, the principle is that the program is retrieved from the broadcast source,  they are transformed, packaged, and streamed over our RTP.  And well, I don't know if it's a pro or a con, it's a pro or a con,  but it reproduces the behavior of the broadcast channel, right?  Things are pushed until the end user. There's no storage in the middle.  The client is lighter. In our demonstration, we use JavaScript on the client only for the navigation,  so I'll come back later on that.  But for the construction, for the display, JavaScript is not used.  We have a heavier server.  The bandwidth between the server and the client is increased because we're sending  EPG data plus presentation data, right?  And it's more difficult, as I said, to adapt.  To adapt, not to adapt.  So some implementation details.  The server, as you see in the picture, is an embedded platform running an R processor  at 400 MHz with a video transcoding chip.  The clients we are using, so for streaming, for DIMPS streaming, we're using only GPAC.  It's the only player we could have. I don't know if you're a player, so for R and E.  Okay, so we would be happy to test it for interpretability.  And I know that someone else may be a keyboard.  And for the Ajax, okay, we used all the browsers except IE9,  and I tested just before my presentation. It doesn't work, so we have to fix it.  So some results.  Here is how it looks like on Chrome.  So you have a grid, a typical grid.  The video is displayed there, and then when you click on a program, you have some additional information here.  We will see it on the video, in more detail, just to show you the looks.  Opera. So in opera, we have some problems with the playback of the video.  We have some problems with the same, the supported problems.  This one is with Safari.  Then we have, okay, this one is GPAC.  It's a bit different than this one, and it's a DBBT example.  The other one where the source was the web. This one is really DBBT,  and in particular, it's in DBBT that when you retrieve programs, you only get two programs per channel.  The current one and the next one, and they are being updated as the program goes.  This is on the iPhone, and this is on the iPad.  So you can see, for example, one kind of adaptation is that when you're on the iPad,  you have room to show the video and the grid at the same time.  When you're on the iPad, you cannot.  You have a button here to switch between video mode and graphics mode back and forth.  So I will show you the video of the iPad.  So we're starting the application.  It allows the grid and the video.  And when you select the program, you can see that it's displayed here.  We can shift the dates, like touching right and left moves the grid right and left,  touching the grid vertically or changes the channel in display.  You can zoom to display more or less, program changes the size of the grid.  When we click on it, you can have more information, more of the abstract, the synopsis, the ratings,  and still showing the video at the same time.  And then if we want, we can go full speed, of course, just to show you the video.  And then we have filters, so we can filter the content that we want to show, just movies, for example.  And so programs have been removed and only the movies are remaining.  Then we can go back to the app.  So this is for the video.  And then I have a live example.  We're going to have to refresh because when I plug the keyboard, the resolution of my train has changed.  So the layout is not dynamic, when we resize the window, we don't really reconcute the size of all the games.  Yeah, okay, this is not live video.  This is just one video because our server is in the other building and somehow it's down.  So this is the same as the panoramic zone, actually.  So it was down five minutes ago.  And so you can see if I shift, I can browse, I can have more channels.  And so on, okay?  Okay, my last slide.  Problems and limitations we faced when we did that.  My first interoperability problems is usually the tiny one.do is not supported well enough to my taste.  The first text area is not supported, so we don't have flow text easily.  We have to do foreign objects, HTML, div.  This is just not great.  We can argue about that.  Just turn everything inside out.  Actually, we have first an HTML to have the video element of HTML.  Then we have the SVG and then inside the SVG we have the foreign object with HTML.  So we have three layers.  But you do not need to take the whole area where you do the readout.  You can do the multiple that demo.  Yeah, let's give you first question.  The trade access API is also not enough supported.  And I think we have this discussion yesterday during the panel, the video element also.  We had also a difference between events on mobile, like on the iPhone iPad.  The name of events are not the same.  Touch events instead of gesture events instead of clicks and so on.  Lack of SVG support on Android platforms.  Yes, I hope it will come.  Lack of Vim support also.  Windows, I think it's nice.  And then we had some missing SVG features that we think would be nice to have.  For example, screen orientation detection by events or whatever it means.  Sorry.  Pixel density detection.  We wanted to change the font size or the layout depending on the pixel density just to make sure that the layout is proper, that legibility is correct.  And this is missing.  Text ellipses.  When we have the name of a program that is that long but lasts for 30 seconds, we have to put it in a rectangle.  And at the moment we just do a text area with clipping.  Or I forgot where.  Yeah, we do it also with clipping with CSS.  Yeah, okay.  We remove the name of the program instead of showing the program.  And then we add a mode where we could replace long text with dot dot dot.  It would be nice.  And Z-Order also would be nice to manage more easily the different layers.  The TV, the grid, things on top of the TV and so on.  And there's an example in SVG spec.  I think it's one of the two about nav index.  And this example is exactly about EPG, right?  There's a grid.  You cannot use it.  It's impossible.  Why?  Because you have to give next, well, north, south, northwest and so on.  You have to give all the elements that are southeast, west and so on.  But when you're doing this with programs that have duration, changing duration or small or short, the layout is not that easy.  So it's very, it's not really usable.  But we don't have yet a better proposal or fix it.  We just wanted to report it.  So, merci.  Attention.  I say it's on my computer.  So, thank you.  Thank you.  Thank you.  Thank you.  Can you go back to the previous slide, please?  It's just that this is the first part of my question, which is not really a question.  I think some things you list as missing SVG features are not SVG features.  Screen orientation detection.  This shouldn't be SVG HTML, but I don't care.  Right.  So screen orientation is being worked on in, sorry.  Yeah, that's being worked on.  So density, there's a media query for that, I think, nowadays in the works.  Text ellipses is in CSS.  And that order is definitely on SVG features.  But seriously, my question was, at some point you mentioned the differences between the streaming broadcast model and the HX model.  I was wondering if you'd investigated things like comment support in browsers or using things like an XMPP library.  They're very good ones.  So that would give you push.  Of course, other advantages of broadcast exist, but it might be interesting to compare XMPP with streaming.  So you're saying you should have SVG HTML, CSS media queries, yeah?  It's a stat, a tool box.  Yeah, okay.  I don't think it's...  It just got in all the other users, so it doesn't have room to compare.  Yeah, it's not a question of implementation, it can be read.  Just because we split the spectrum...  How many offering tools do you need to do that?  You just need text-mates.  That's all I use.  You know, seriously, just because the spectrum is split into smaller parts doesn't mean it's more complicated.  I mean, you know, you can take one thing and call it NPEG4.  You know how much stuff is in there.  You know what I mean?  It's not a naming problem.  What I'm saying is that, okay, the status-twin orientation has been defined in one.  There's a general tool that we can see to do it.  But there could be differences.  I mean, I don't know the ways to apply it when you're only in an SVG context.  It's not...  It's a...  It shouldn't be exclusive.  It's not exclusive.  You can use it with SVG.  Yeah, this is not a client, but it's still the relevant tool.  Okay, but what about the SVG?  CSS can definitely be used on SVG.  We don't know Oval's support everything yet.  The text ellipsis, for example, is the...  I was just looking at it being the text all over the property in CSS.  And it does exactly what you want.  I mean, your examples are second to dead.  They're very interesting.  We don't lay out the text if you can.  But we could support the text ellipsis in SVG, too.  And that makes total sense to us back.  The other thing is your example kind of screams for the...  It's exactly what we have in mind, what we say, in IT graphic to chronographic apps.  And it screams for the mix of HTML, CSS, and SVG,  because you have text that is flow...  That is to flow.  You need...  In fact, you probably need all the power of CSS and HTML text  if you start tackling complex scripts and all the other stuff that's important.  You need to push.  So it's really...  Ultimately, you need all these features.  You just gotta discover it's sort of...  Okay, I like the demo.  I like the box.  I like the whole idea of collecting this broadcast  and rebroadcasting it inside the house.  I like it.  But, I mean, you know, we're in an SVG conference, maybe this is heresy,  but I didn't see anything on that UI  that you couldn't have just done with absolutely positioned HTML.  I mean, if you've got the JavaScript logic to lay out on the program grid,  just use an absolutely positioned div of width and height, throw a queue,  you know, round them and now with border radius  and put a nice gradient background on it,  and you pretty much got the same thing,  and you could do the whole thing in HTML5.  I mean, yes, we're in an SVG conference,  but you didn't need an SVG to solve that problem.  And also, there are historical reasons.  We started with SVG because we started with a streaming approach  where we had no JavaScript on the client.  Yeah.  Okay, so all the positioning was done,  Bioserver sent as updates,  and anything was positioned and the grid would be built progressively.  And back then, there was no HTML5, so that's when they started.  Oh, it was tired.  No idea.  Two years ago.  Why do you have these types of data?  Yeah, Ted kind of stole my question a little bit,  but I had more questions about that,  because, yeah, I mean, at first I thought that you were just going to lay the thing out using,  you know, just like a regular viewbox,  and then it was going to be the exact same UI,  but, you know, the viewbox element had been scaled up for one.  It's not at all.  It's laid out.  Is it that right?  Do you think that, like, I mean, is it easier to do that?  Like, when you're doing, because, like, when something needs to be laid out  to take up the full screen orientation like that  and have text position decided that, you know,  I immediately think of HTML and divs,  you know, because you have to do all of that.  I mean, well, I guess there wasn't flow text in there,  but there was definitely like flow, you know, flow.  Sorry, I don't know if that's the essence to tell you,  but I immediately think of HTML.  So do you think it would actually be easier,  I think, more sense to use that for this kind of application?  Okay, SVG, the S stands for Scalability.  Someone said it at the beginning of the conference,  but scalability is not enough.  Scalability in terms of graphic is not enough.  When you're doing adaptation, you need to adapt the layout.  And viewbox is the minimal tool,  but in some cases it's not enough.  So maybe for sure the layout logic can be implemented in scripts,  and then you can do it in SVG or you can do it in HTML, CSS, and so on.  There are different tools, but the result will be the same.  So we pointed out.  And again, historically when we push for the streaming approach,  we push, we can filter the updates depending on the resolution,  we get on the orientation and stuff like that.  We wouldn't need the JavaScript to do the layouts,  and even to change the orientation.  So let's see.  So, we have the demo on the iPad, we can also try it.  So, give them a sec.  Correct?  No, depending on the approach.  If you use the layout, it's done in the client.  If you use streaming approach, there are several ways  you can push the alternatives, like port 3 and landscape,  and we tag the updates with port 3 and landscape,  and then the player to decide on which orientation,  but this is maybe static in this case.  You choose like this or like that.  Then you are at the piece.  I'm used to the command, it's working on a scalable approach  for updates, which is the size of the...  Okay, yeah.  Okay.  Well, it seems to me, as I already mentioned earlier,  it's good for the screen orientation, it would be better off with height  and detection of medium curves.  You don't need to know your orientation,  because every day you want to watch the video on the side.  So you would...  In addition, you take the video on the side?  Yeah, that's true.  So it's applied immediately whenever you resize the voucher,  it's applied constantly.  So you don't need a refresh.  And one tip about the video and opera,  it's because you're using more files rather than...  In this example, we use a H2TS.  No, we own a spoiler, we have a Nogue,  so it's a separate file from the section.  That's what I said.  Yeah.  That's a good question.  Thank you.
SVG_Electronic_Program_Guides_2_0_59.png SVG_Electronic_Program_Guides_2_60_179.png SVG_Electronic_Program_Guides_2_180_515.png SVG_Electronic_Program_Guides_2_516_659.png SVG_Electronic_Program_Guides_2_660_1787.png SVG_Electronic_Program_Guides_2_1788_4991.png SVG_Electronic_Program_Guides_2_4992_7751.png SVG_Electronic_Program_Guides_2_7752_7955.png SVG_Electronic_Program_Guides_2_7956_11207.png SVG_Electronic_Program_Guides_2_11208_12947.png SVG_Electronic_Program_Guides_2_12948_14063.png SVG_Electronic_Program_Guides_2_14064_16991.png SVG_Electronic_Program_Guides_2_16992_19367.png SVG_Electronic_Program_Guides_2_19368_20303.png SVG_Electronic_Program_Guides_2_20304_20363.png SVG_Electronic_Program_Guides_2_20364_20435.png SVG_Electronic_Program_Guides_2_20436_20507.png SVG_Electronic_Program_Guides_2_20508_21527.png SVG_Electronic_Program_Guides_2_21528_21599.png SVG_Electronic_Program_Guides_2_21600_21671.png SVG_Electronic_Program_Guides_2_21672_22391.png SVG_Electronic_Program_Guides_2_22392_23087.png SVG_Electronic_Program_Guides_2_23088_23207.png SVG_Electronic_Program_Guides_2_23208_23291.png SVG_Electronic_Program_Guides_2_23292_23591.png SVG_Electronic_Program_Guides_2_23592_23903.png SVG_Electronic_Program_Guides_2_23904_25319.png SVG_Electronic_Program_Guides_2_25320_25415.png SVG_Electronic_Program_Guides_2_25416_28283.png SVG_Electronic_Program_Guides_2_28284_30707.png SVG_Electronic_Program_Guides_2_30708_31115.png SVG_Electronic_Program_Guides_2_31116_31187.png SVG_Electronic_Program_Guides_2_31188_33239.png SVG_Electronic_Program_Guides_2_33240_38495.png SVG_Electronic_Program_Guides_2_38496_38627.png SVG_Electronic_Program_Guides_2_38628_38747.png SVG_Electronic_Program_Guides_2_38748_39707.png SVG_Electronic_Program_Guides_2_39708_40415.png SVG_Electronic_Program_Guides_2_40416_41975.png SVG_Electronic_Program_Guides_2_41976_42143.png SVG_Electronic_Program_Guides_2_42144_42419.png SVG_Electronic_Program_Guides_2_42420_43691.png SVG_Electronic_Program_Guides_2_43692_45023.png SVG_Electronic_Program_Guides_2_45024_45107.png SVG_Electronic_Program_Guides_2_45108_45153.png
Okay, so the topic of the talk that we present is a work that we're doing together with Jonathan Cilan here on the electronic program that is using the SDG. And this is completely in line with what you say about IPTV, for an analysis, we'll probably be the promised sort of thing, this issue is very consistent. So the context of our work is that we're witnessing convergence in many directions in a multilid world, right? First, there are convergent photo and video codecs. MPEG4 AC is supported in the most everywhere, AVC is also everywhere, no question about that. And for graphics, it's very similar, HTML, file or whatever, and SDG as well. So as people from Microsoft have said it, we will witness graphically and media-rich content everywhere, on PC, on set-top boxes, on phone, tablets, like this iPad here. And in this context, TV is also evolving. First, okay, it may be obvious that TV is becoming digital, right? But still, so yeah, and with digital TV we have more programs, more channels. And just to stress that it is really becoming digital and only digital. For example, in France, the switch off of the NLTV is scheduled for end of 2011. And there's an opportunity here with the TV becoming really digital to have more interactivity. And one of the standards that was not mentioned, you mentioned all IPF, there's a standard, new standard in Europe called HDB TV, or HTML broadcast broadband TV. It's an Etsy standard, so if you're interested you can have a look. So TV is evolving, devices and networks are evolving also. So as said, devices can play video, TVs can get connected to the internet already. And the mobile world also is changing. You can already have access to TV, 3G networks, but also mobile broadcast networks are being deployed. As you mentioned, the ATAC and H and in Europe, the DVH has not started, it would probably never start, I don't know. Maybe there would be a replacement like DVSH. But still, there are problems of deployment of these networks, cost problem. Especially when you want to reach, studies have shown that the usage of mobile TV is not really mobile. Most of the people use it at home, surprisingly. They are in their rooms with their phone and they look at the TV on their phone. Some studies have shown that. So one of the problems in deploying mobile TVs to have the single penetrating houses, so either you need to put more power in the antenna or you need to put more antennas. And that costs a lot. So here comes the project in which we are working, it's called Pingo. So it's a project to the three companies and us. Deepcom, French manufacturer for TV signal receivers, DVB, TV, HSH and so on. Baraco-Dameja is an integrator and it's financed by the French research institution. So we have this device here, it's an embedded platform. The goal is to have this device located near the window that captures the signal and redistributes it in the house and adapts it. So it can already receive DVBT, DVBH and DVBSH signals, transcode the video, changing the format. For example, if you receive HD signal and you want to send it to a mobile phone, you have to do some transcoding. If you receive a PEC2 video, you need to transform it into a PEC4AVC, things like that. And what is interesting for us is the transformation of the UPG data. And we'll talk about that later. And we're targeting PC phones and tablets, not TV, because TV can already receive the signal. And so the principle is that the end of our work at the ComparisTech is that we develop a framework or a method to receive the UPG data, to transform it into SVG and deliver it over Wi-Fi. And we investigate two approaches, one is streaming, and the other one is traditional AJAX. And of course we adapt it to the size of the screen, for example. So, okay, I will skip this. You know what is an electronic program down in UPG. To example, you showed some others. Just so that you know the ecosystem of the UPG, there are at least three. First, if you look at DVBT, so DVBT is the standard for terrestrial TV, not mobile, just for your TV in your house. And the UPG data is delivered over PEC2, a transportation stream. And the format is binary format. The format of the data, the UPG data, is a binary format called DVB and event information table. On the web, there are many examples. You retrieve it from the IP, and you can get either HTML or XML or whatever. And in DVBH and DVBSH, you have the same kind of protocol stack you showed for ATSC, MH. You have first the PEC2TS, then some IPDCs, a way to deliver IP packets on over MPEG2. And then you have the protocol to deliver the files over IP. And then you have some XMLs, maybe TV and ETIM, or something else. And so we implemented inputs from these three sources, types of sources. So again, why SVG? So yeah, well, of course, we like to work with SVG, and our player implements SVG, so it was natural to try it with SVG. But also SVG has interesting properties. The layout, for example, not having to rely on a flow layout allows you to put your programs into a layout that's not a table, that's not a strict table. Then you have gradients, you have animations, and you have interactivity, so that's nice. There is a video support, so in tiny, so that allows us to show the grid and the TV at the same time. Plus SVG is now supported more and more, so it's a big hit, this conference is a title. Then again, there's a mobile industry interest in SVG, through GPP, OMA, HTC, whatever. And what we wanted to investigate was the streaming of SVG, and we can do streaming using the RME or DIMS, it's almost the same thing. So for those who don't know what is DIMS, DIMS means Dynamic Interactive Motivating Scenes, it's a 3GPP standard based on the VET4 laser, which is based on SVG, so it's a stack of modifications to SVG. And the concepts are, okay, there are some extensions of SVG, but we didn't use them in our project. The most interesting part is that with DIMS you can send from a server to a client, you can send modifications of SVG when the server decides, not when the client requests them. And there can be insertions, removal, replacement, just as you would do them by script using the DOM. And there can be, these times, the modifications of SVG can be stored, either in files like MP4 files, and then you can synchronize them with the audio and video to make subtitles, to make regional interest tracking over a video. But you can also send them from a server, like any streaming server, or you can do progressive download of synchronized streams. So that's the architecture of DIMS. So the architecture of our system is first we have this server, which receives the DDB signals, transmits the transformed information over Wi-Fi to a phone, let's say an iPhone. And the architecture is first we have some demoderator receiving signal, we separate the audio and the EPG, the audio and video is transcode, the EPG is transformed in SVG, and then we have two paths. One is DIMS packaging and streaming over at RTP, which is as if we were doing video. And the second path is storing and then serving it with a classical web server. So there are, of course, advantages and drawbacks for all the approaches, and I'm not saying that one is better than the other, it's just different, and depending on your use cases you might want to use one or the other. But the traditional AJAX approach, our server will go on the web, retrieve or go with a T-signal, retrieve the program, generate XML files, store them in the web server, and they are able to fly it with parallelity, retrieve the XML and update its display. So with this approach, of course, we have a live server that's just decoding the programs, creating an XML and serving them. Adaptation is nice because then it's easier on the client than with the streaming approach because everything is on the client, so the client can do everything, can decide. There's no privacy issue of sending back my preferred programs, or there's no... It's simple, but okay, it's not as... The dynamicity is not as good as when you're just streaming, because when you're just streaming, every time there's a new program, you receive it, or a modification of the program, you receive it. But in the AJAX mode, you have to pull it, you have to wait for the next poll to update it. And also the layout, when we do the AJAX approach, we just send the XML of the APT programs. We don't change the layout. With the streaming approach, we can send modification of the scene to the date, the layout to the date, the charter to date, the style, and so on. So you can imagine that for Christmas, we could send updates of the theme, a theme like the Google page you have during Christmas is different from another time of the year. And for the streaming, the principle is that the program is retrieved from the broadcast source, they are transformed, packaged, and streamed over our RTP. And well, I don't know if it's a pro or a con, it's a pro or a con, but it reproduces the behavior of the broadcast channel, right? Things are pushed until the end user. There's no storage in the middle. The client is lighter. In our demonstration, we use JavaScript on the client only for the navigation, so I'll come back later on that. But for the construction, for the display, JavaScript is not used. We have a heavier server. The bandwidth between the server and the client is increased because we're sending EPG data plus presentation data, right? And it's more difficult, as I said, to adapt. To adapt, not to adapt. So some implementation details. The server, as you see in the picture, is an embedded platform running an R processor at 400 MHz with a video transcoding chip. The clients we are using, so for streaming, for DIMPS streaming, we're using only GPAC. It's the only player we could have. I don't know if you're a player, so for R and E. Okay, so we would be happy to test it for interpretability. And I know that someone else may be a keyboard. And for the Ajax, okay, we used all the browsers except IE9, and I tested just before my presentation. It doesn't work, so we have to fix it. So some results. Here is how it looks like on Chrome. So you have a grid, a typical grid. The video is displayed there, and then when you click on a program, you have some additional information here. We will see it on the video, in more detail, just to show you the looks. Opera. So in opera, we have some problems with the playback of the video. We have some problems with the same, the supported problems. This one is with Safari. Then we have, okay, this one is GPAC. It's a bit different than this one, and it's a DBBT example. The other one where the source was the web. This one is really DBBT, and in particular, it's in DBBT that when you retrieve programs, you only get two programs per channel. The current one and the next one, and they are being updated as the program goes. This is on the iPhone, and this is on the iPad. So you can see, for example, one kind of adaptation is that when you're on the iPad, you have room to show the video and the grid at the same time. When you're on the iPad, you cannot. You have a button here to switch between video mode and graphics mode back and forth. So I will show you the video of the iPad. So we're starting the application. It allows the grid and the video. And when you select the program, you can see that it's displayed here. We can shift the dates, like touching right and left moves the grid right and left, touching the grid vertically or changes the channel in display. You can zoom to display more or less, program changes the size of the grid. When we click on it, you can have more information, more of the abstract, the synopsis, the ratings, and still showing the video at the same time. And then if we want, we can go full speed, of course, just to show you the video. And then we have filters, so we can filter the content that we want to show, just movies, for example. And so programs have been removed and only the movies are remaining. Then we can go back to the app. So this is for the video. And then I have a live example. We're going to have to refresh because when I plug the keyboard, the resolution of my train has changed. So the layout is not dynamic, when we resize the window, we don't really reconcute the size of all the games. Yeah, okay, this is not live video. This is just one video because our server is in the other building and somehow it's down. So this is the same as the panoramic zone, actually. So it was down five minutes ago. And so you can see if I shift, I can browse, I can have more channels. And so on, okay? Okay, my last slide. Problems and limitations we faced when we did that. My first interoperability problems is usually the tiny one.do is not supported well enough to my taste. The first text area is not supported, so we don't have flow text easily. We have to do foreign objects, HTML, div. This is just not great. We can argue about that. Just turn everything inside out. Actually, we have first an HTML to have the video element of HTML. Then we have the SVG and then inside the SVG we have the foreign object with HTML. So we have three layers. But you do not need to take the whole area where you do the readout. You can do the multiple that demo. Yeah, let's give you first question. The trade access API is also not enough supported. And I think we have this discussion yesterday during the panel, the video element also. We had also a difference between events on mobile, like on the iPhone iPad. The name of events are not the same. Touch events instead of gesture events instead of clicks and so on. Lack of SVG support on Android platforms. Yes, I hope it will come. Lack of Vim support also. Windows, I think it's nice. And then we had some missing SVG features that we think would be nice to have. For example, screen orientation detection by events or whatever it means. Sorry. Pixel density detection. We wanted to change the font size or the layout depending on the pixel density just to make sure that the layout is proper, that legibility is correct. And this is missing. Text ellipses. When we have the name of a program that is that long but lasts for 30 seconds, we have to put it in a rectangle. And at the moment we just do a text area with clipping. Or I forgot where. Yeah, we do it also with clipping with CSS. Yeah, okay. We remove the name of the program instead of showing the program. And then we add a mode where we could replace long text with dot dot dot. It would be nice. And Z-Order also would be nice to manage more easily the different layers. The TV, the grid, things on top of the TV and so on. And there's an example in SVG spec. I think it's one of the two about nav index. And this example is exactly about EPG, right? There's a grid. You cannot use it. It's impossible. Why? Because you have to give next, well, north, south, northwest and so on. You have to give all the elements that are southeast, west and so on. But when you're doing this with programs that have duration, changing duration or small or short, the layout is not that easy. So it's very, it's not really usable. But we don't have yet a better proposal or fix it. We just wanted to report it. So, merci. Attention. I say it's on my computer. So, thank you. Thank you. Thank you. Thank you. Can you go back to the previous slide, please? It's just that this is the first part of my question, which is not really a question. I think some things you list as missing SVG features are not SVG features. Screen orientation detection. This shouldn't be SVG HTML, but I don't care. Right. So screen orientation is being worked on in, sorry. Yeah, that's being worked on. So density, there's a media query for that, I think, nowadays in the works. Text ellipses is in CSS. And that order is definitely on SVG features. But seriously, my question was, at some point you mentioned the differences between the streaming broadcast model and the HX model. I was wondering if you'd investigated things like comment support in browsers or using things like an XMPP library. They're very good ones. So that would give you push. Of course, other advantages of broadcast exist, but it might be interesting to compare XMPP with streaming. So you're saying you should have SVG HTML, CSS media queries, yeah? It's a stat, a tool box. Yeah, okay. I don't think it's... It just got in all the other users, so it doesn't have room to compare. Yeah, it's not a question of implementation, it can be read. Just because we split the spectrum... How many offering tools do you need to do that? You just need text-mates. That's all I use. You know, seriously, just because the spectrum is split into smaller parts doesn't mean it's more complicated. I mean, you know, you can take one thing and call it NPEG4. You know how much stuff is in there. You know what I mean? It's not a naming problem. What I'm saying is that, okay, the status-twin orientation has been defined in one. There's a general tool that we can see to do it. But there could be differences. I mean, I don't know the ways to apply it when you're only in an SVG context. It's not... It's a... It shouldn't be exclusive. It's not exclusive. You can use it with SVG. Yeah, this is not a client, but it's still the relevant tool. Okay, but what about the SVG? CSS can definitely be used on SVG. We don't know Oval's support everything yet. The text ellipsis, for example, is the... I was just looking at it being the text all over the property in CSS. And it does exactly what you want. I mean, your examples are second to dead. They're very interesting. We don't lay out the text if you can. But we could support the text ellipsis in SVG, too. And that makes total sense to us back. The other thing is your example kind of screams for the... It's exactly what we have in mind, what we say, in IT graphic to chronographic apps. And it screams for the mix of HTML, CSS, and SVG, because you have text that is flow... That is to flow. You need... In fact, you probably need all the power of CSS and HTML text if you start tackling complex scripts and all the other stuff that's important. You need to push. So it's really... Ultimately, you need all these features. You just gotta discover it's sort of... Okay, I like the demo. I like the box. I like the whole idea of collecting this broadcast and rebroadcasting it inside the house. I like it. But, I mean, you know, we're in an SVG conference, maybe this is heresy, but I didn't see anything on that UI that you couldn't have just done with absolutely positioned HTML. I mean, if you've got the JavaScript logic to lay out on the program grid, just use an absolutely positioned div of width and height, throw a queue, you know, round them and now with border radius and put a nice gradient background on it, and you pretty much got the same thing, and you could do the whole thing in HTML5. I mean, yes, we're in an SVG conference, but you didn't need an SVG to solve that problem. And also, there are historical reasons. We started with SVG because we started with a streaming approach where we had no JavaScript on the client. Yeah. Okay, so all the positioning was done, Bioserver sent as updates, and anything was positioned and the grid would be built progressively. And back then, there was no HTML5, so that's when they started. Oh, it was tired. No idea. Two years ago. Why do you have these types of data? Yeah, Ted kind of stole my question a little bit, but I had more questions about that, because, yeah, I mean, at first I thought that you were just going to lay the thing out using, you know, just like a regular viewbox, and then it was going to be the exact same UI, but, you know, the viewbox element had been scaled up for one. It's not at all. It's laid out. Is it that right? Do you think that, like, I mean, is it easier to do that? Like, when you're doing, because, like, when something needs to be laid out to take up the full screen orientation like that and have text position decided that, you know, I immediately think of HTML and divs, you know, because you have to do all of that. I mean, well, I guess there wasn't flow text in there, but there was definitely like flow, you know, flow. Sorry, I don't know if that's the essence to tell you, but I immediately think of HTML. So do you think it would actually be easier, I think, more sense to use that for this kind of application? Okay, SVG, the S stands for Scalability. Someone said it at the beginning of the conference, but scalability is not enough. Scalability in terms of graphic is not enough. When you're doing adaptation, you need to adapt the layout. And viewbox is the minimal tool, but in some cases it's not enough. So maybe for sure the layout logic can be implemented in scripts, and then you can do it in SVG or you can do it in HTML, CSS, and so on. There are different tools, but the result will be the same. So we pointed out. And again, historically when we push for the streaming approach, we push, we can filter the updates depending on the resolution, we get on the orientation and stuff like that. We wouldn't need the JavaScript to do the layouts, and even to change the orientation. So let's see. So, we have the demo on the iPad, we can also try it. So, give them a sec. Correct? No, depending on the approach. If you use the layout, it's done in the client. If you use streaming approach, there are several ways you can push the alternatives, like port 3 and landscape, and we tag the updates with port 3 and landscape, and then the player to decide on which orientation, but this is maybe static in this case. You choose like this or like that. Then you are at the piece. I'm used to the command, it's working on a scalable approach for updates, which is the size of the... Okay, yeah. Okay. Well, it seems to me, as I already mentioned earlier, it's good for the screen orientation, it would be better off with height and detection of medium curves. You don't need to know your orientation, because every day you want to watch the video on the side. So you would... In addition, you take the video on the side? Yeah, that's true. So it's applied immediately whenever you resize the voucher, it's applied constantly. So you don't need a refresh. And one tip about the video and opera, it's because you're using more files rather than... In this example, we use a H2TS. No, we own a spoiler, we have a Nogue, so it's a separate file from the section. That's what I said. Yeah. That's a good question. Thank you.
Cilan here on the electronic program that is First, there are convergent photo and video codecs. MPEG4 AC is supported in the most also. So as said, devices can play video, TVs can mobile world also is changing. You can already the video, changing the format. For example, if UPG data, to transform it into SVG and deliver it over Wi-Fi. And we investigate two approaches, information table. On the web, there are many from these three sources, types of sources. So example, not having to rely on a flow layout SVG is now supported more and more, so it's a big DIMS you can send from a server to a client, you audio and video is transcode, the EPG is One is DIMS packaging and streaming over at RTP, advantages and drawbacks for all the approaches, But the traditional AJAX approach, our server AJAX approach, we just send the XML of the APT programs. We don't change the layout. With the for the construction, for the display, JavaScript bandwidth between the server and the client is with the playback of the video. We have some is on the iPhone, and this is on the iPad. So you the ratings, and still showing the video at the wondering if you'd investigated things like comment support in browsers or using things like flow... That is to flow. You need... In fact, you HTML, CSS, and so on. There are different tools,