AV1: Status update
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Pehlivanov, Rostislav
For a long time the multimedia world has had to pay attention to whom theintellectual property of a codec or tool belonged to such that they could payroyalties for each and every device or program using it. In 2012 thestandardization of Opus changed that for audio through the combined effort ofseveral individuals who were part of the free software community and largecompanies bringing together their research and patents and offering it forfree use by everyone. By avoiding existing patents, interesting new techniquesfor efficient audio compression were invented. Now, in the effort to make aroyalty free video codec in the same spirit as Opus, even more companies havejoined into the "Alliance for Open Media" organization, with its first codectitled "AV1". Starting from the codebase of Google's VP9 codec, AV1 hascurrently over 45 experimental coding tools contributed by its membercompanies with the hopes that many will make it into the final version of thecodec. This talk will serve as an update to the overall progress of the codecas well as to briefly explain the principles of operation of several codingtools expected to make it into the final version.
 Alright, so I'm Adam Yooker, I am an FMMPG developer, I've done a lot of work on audio codecs and video codecs, I was crazy enough to write a Dalit decoder a year ago and I wrote the first non-Livopas based encoder just when I released it just like a week ago. So what I'm going to be talking about today is AV1. Now for those of you who don't know what AV1 is, I've prepared a slide for that. So AV1 is supposed to be interoperable and open, so it's always going to be royalty free and it's going to be optimized for the internet so that many of the people in this room can directly benefit from that, the increase in video compression, the royalty free and all the other stuff. It's going to be scalable to any modern device, any bandwidth mostly, it's going to be optimized for the hardware so that you can easily decode that with little power on a hardware decoder and as well encode it with varying degrees of success and all the other stuff which you see all the time in marketing. This is, by the way, I stole from the AOM website so I would never write something like that. So decode it, this would mean something like that. These are the real bullet points. So it's going to be royalty free, it's going to be, it is already in development and it's already open and lots of companies are participating in the development of this codec. So all of the major players like Amazon, Netflix, Google, YouTube, Mozilla and so on. So whatever happens the codec will see an option. So what's important now is to get the codec to be competitive with other codecs that are being developed right now and also make it an upgrade to any codecs which are currently being used. So now unfortunately not all companies have joined so there is still some intellectual property out there which we cannot use. So that means that we have to get clever and we have to go around that in some ways. And the whole process of going around means rediscovering new ways of doing something which might or might not be more efficient. So moving on, the reference encoder is based on VP9 without VP8 support but with bug fixes. So some of those bug fixes were meant to go into VP9 but they didn't. So they made it into VP10 but VP10 got turned into AV1 and so we carry on. So the way that the development works is companies contribute experiments and these experiments make it into get master of the encoder. And after being integrated the experiments are supposed to go through intellectual property review. So there's a team of lawyers who looks at the description of the encoding tool and tries to find patents which have been updated or which haven't been updated which match the description of what the tool does. So and eventually after the bitstream has been frozen which should happen around Q4 of this year all the experiments should be removed. This is what's in my imagination what's meant to happen but it hasn't happened yet. So about the experiments there are currently 50 experiments and granted some of them might don't sound appealing or don't sound like they contribute anything like emulated hardware or debug bitstream. But the point is that most of these experiments increase encoding efficiency and well there's just 50 of them and they're being constantly developed and updated so there's a whole lot of development going on right now. So I cannot really cover every single of the 50 tools of the experiments which are currently in the codec and not to mention that every month new experiments get added and some experiments get enabled by default. And so it's kind of difficult to keep track of but I'll just go through some of the coding tools which have been demonstrated to give gains and have our good candidates for being part of the codec and the specifications later on. So the first tool which I'll cover is directional deering. Now directional deering was something which was supported from DALA and it was required in DALA because DALA used overlap and most of the encoding techniques in DALA contributed to some degree of ringing in the image so this deering filter was developed for DALA but it turns out that since it's arrived at the very end of the encoding process, at the decoding process you can just easily paste that into any codec and it would just work. So the way it works is you first segment the image into 8 by 8 blocks and then you scan for a direction inside this 8 by 8 block so you do that by computing the least squares method I think. So the direction doesn't really matter. What matters is that it does a conditional replacement filter so instead of blurring out any artifacts and by extension any detail in the image, it only acts on very obvious ringing patterns. So in case a single pixel deviates by some amount which varies as a function of how far away you're particularly from the direction vector, it will replace it with some kind of an average. So it works really well and it gives around around 2 or 3% improvements. It's also easily sendable and it has currently been enabled by default in AV1 so this still is probably going to make it into the final version of the codec. Another tool is pvq. Now pvq is going to give by far the most gains but it's by far the most difficult tool to integrate. And what you can think of pvq is you can think of it as a black box where you can insert any kind of coefficients in the frequency domain and pvq will predict from both the current image and whatever you give it in to predict from. So it can be previous pixel values, previous coefficient values or it can be for instance coefficients from Luma and you want to predict Chroma. So the way it works is well I'm not really going to explain it but you can see from the diagram that if you imagine the coefficients inside a block as a vector you can describe that vector as pointing to the surface of an in dimensional sphere and if you have another vector which is what you're wanting to predict from you can do just a half store reflection and then you just send a t-tangle which is n minus one values long. So I just wanted to spend some time on discussing pvq search because I think pvq search is a well it's an important problem which also needs to be solved and made faster. We currently have an implementation which is carried on from Opus because Opus used a pvq search as well. We do RDO on the pvq search so that's a bit different but the root of the problem is very simple. So if you have a vector and you want to quantize it using a pvq search you just normalize the vector to an L2 which is the Euclidean norm which is basically you sum up the squares of each component then you do a square root and then you divide each component of the vector by the square root and you do that for the output vector quantized as well. So it's a simple problem but it gives great results and I think it's the way to do vector quantization. So if some of you want to go ahead and give it a go and give it a try on improving it you will improve your performance not just in Dala, not just in Opus but in everyone as well so that will be useful. But the properties of pvq is also what makes it very interesting. Using pvq we can vary the code book so we can optimize it for instance for areas which have low contrast so this is what activity masking tries to do. It attempts to provide better resolution in low contrast images and this is in contrast with HVCU which attempts to aggressively remove details from the original image and if any of you has done any encoding using HVCU they will know that SAO basically is a tool which you turn off if you see any bad results immediately. So activity masking is something which is difficult to make it into AV1 since it requires a different distortion function but we are all actively working on trying to make it into something usable in AV1. So another tool which is also supported from Dala is Chroma from Luma and since we do pvq entirely in the frequency domain this means that we can also inject values from Luma coefficients and more accurately describe what exactly are the details in the Chroma. So you might ask well how does it work when you have a sub-sampled Chroma? Well we use TF switching to throw away any details. This is all in the frequency domain so you cannot do rescaling and conversion in the spatial domain since we are all in the frequency domain. So the resulting coefficients will be used in a DCT transform and that's one of the difficulties in implementing Chroma from Luma in AV1. Since AV1 has currently two different transforms, AV1 has DCTs which are the standard way of doing transforms and there is an ADSD which allows you to in some circumstances get better results but there are more transforms being planned to be added into AV1. So Chroma from Luma is kind of a difficulty to implement but the results really show that there is a big improvement in Chroma detail and in Luma detail as well since in order to better describe Chroma you need better Luma. So that's why CFL is looking like a nice feature to implement into the final version of the codec. Now a note is that it works for 4.44 and it works for 4.20 formats but it doesn't work for 4.22. So if you want to use 4.22 please don't just use 4.44 or 4.20 or just increase the bit rate you can always just increase the bit rate like the old 80 megabits impact streams and pad the bit stream but in order to pad the bit stream there is a convenient segue here. You need to ensure that the codec, that the ray control system will not overshoot. So it will not overshoot grossly since if you plan to pad then you obviously want to pad to some bit rate but you don't want to overshoot of course. So this is what I'm currently working on, I'm trying to fix the ray control system in AV1 by just scrapping it and by inserting the ray control system from DALA which was also the ray control system from Tioro but was ported to DALA. So the ray control system which I'm working on tries to basically predict the amount of bits that the current frame will use and it does that by just this simple model and the scale value is what's modified from frame to frame. So the codec will first use the scale value from the previous frame and will predict the bits the current frame will take and will then after the frames being encoded it will measure the real scale value since you know how many bits you've used and you know the quantizer and alpha is just an exponentiate value which is different for all frame types and it will try to smoothly transition scale from one frame to the other frame using a second order Bessel filter which will also throw away any extremes in the final quantization values being used and as such it will give a smoother visual experience of encoding. So it won't do any gross overshoots that the current ray control system does and just to share something with you I have seen on YouTube a 200 megabits sustained for five or so seconds on a screen directly from YouTube. Granted it was VP9 but it was 4K at 30 frames but still nothing warrants 200 megabits of continuous usage for a few seconds. So this ray control system also will support a way of easily providing chunks to kind of encode so instead of encoding separate temporary chunks I mean a few seconds worth of video of chunks you can just signal a reset in the two pass mode of the ray control system and it will reset all the statistics and you can just continue on encoding as if you've just started encoding a new frame. And yeah, yeah, alright. And another feature which I'd also like to talk about shortly is RNS and RNS is being developed by Google currently and RNS will offer big improvements in the coding speed but unfortunately there are some drawbacks. It needs a big enough buffer to store all the symbols in the encoder before reversing them and writing that as a bit stream because it works kind of as a stack. So there are some hardware manufacturers which aren't content with having a huge buffer but at the end it's either this or the DALA entropy coding system both of which have the same efficiency but RNS has the advantage of having a higher recording speed. And there are also some experiments which I cannot really dedicate the entire time to talk about but there is EXT-ETX which will give more transforms which as I already mentioned will kind of be a bit of a problem for CFL but I'm sure we can do it with it somehow. There's also an adaptive coding order so the old zigzag which isn't paid in anymore, it turns out that the old zigzag may not result in the best encoding efficiency so if you have some kind of other patterns you can use and you can do RDO to figure out which pattern is the best then if the experiment turns out to give improvements we'll also make it in and also there's 64 by 64 transforms which aren't quite certain that we'll make it in but we'll provide big gains on any kind of large uniform images. So with that I'd like to end the presentation and if there are any questions I'd be happy to answer them. We have time for three or four questions. We will support Interlaced and... Yeah that's the million dollar question. So the question was are we going to support Interlaced and well I'm not sure. No comment. Just say no. I cannot say no. I mean you know how it is. It's not designed by committee but it is still designed by some people with various interests so whether it will not make it or make it I cannot say but you know many of us have strong opinions about it not making it. Very strong. Yeah so... Yeah well the question was wasn't the Bistream going to be frozen in March of this year and well the Bistream was going to be frozen last year and it was going to be frozen many times before that but you know how it is you know you just have to keep you know extending because some features you really don't you need some more research to improve some features but what's important is that we don't want to delay it too much because by that time H266 will be out and we'll have to compete with that and we want to get adapted before that so that less people will adapt the less royalty free equivalents of you know video compression products. So anyone else? Yeah. Well so this is some pretty amazing work and my question is from the outside it looks like you either follow the footsteps of H264 and the family or be like a foreign work and I think I've seen some research work on motion religion that is stored as a free teaching. Yeah. Is it? Well you should look into yeah so the question was have we looked into storing motion information as a kind of a 3D type of thing where the third dimension is time I presume right? Well there was an experiment that ZIF tried to make it was a codec I don't remember its name but it used wavelets and three dimensions to try to compress video and as far as I remember you could actually see you know information images ahead of time you know before it happened as kind of a ghostly you know images but apart from that nothing is being looked into it because it's just so radically different and sounds and is difficult to kind of do enough research to get something which is actually implementable and gives encoding gains and doesn't require you know much hardware you know to actually implement so I don't think that it's the way to do it and I don't think it's the way to do it for the next 50 years or something. All right there's a person there in the back. I have a question which is not really codec related but Mux related. It would work on MP4 right from the start because that would simplify the problem very much. So the question was are we going to work on MP4 encapsulation right? Well let's first get a codec which is which is presentable and then we'll work on MP4 you know Muxing because as it is right now all of us are working on improving the codec but you know I'm not sure why you won't use MP4 you know because MP4 is what 20 years old now. Is it in a broke? If it ain't broke yeah. It doesn't look like another office cage where most people can't use it because it's not your place to go. Well regardless of whether it's in MP4 it will mostly be used on MP4. It will be used on the internet and right now WebM is the default standard for video and audio coding on the internet so it will first be implemented in WebM. So well sorry about that. Any other? Yeah. This is maybe more of an implementation thing. Yeah. Maybe some of the new experiments be included. Is there a plan for non-tile multi-training? So the question is are there plans for non-tile multi-training? Or the experiments might be for tri-training. Well there will always be frame-training but there will always be well in the decoder but there will always be tile-training as well so right now there are no plans to drop tile-training decoding. But I think there were some plans to drop frame parallel decoding so there's that. You have to ask Thomas Didi on IRC. All right. We have time for I think one more. All right one more question. Someone. It was first. All right. Yeah. Not to play around with future of the internet but about hardware decoding. I've memorized the file and I've created some formats and put the hardware inside. So the question is how do you decide which code is implementable in hardware and which one to actually implement it into the codec. And the answer is that during initial review you'll get some feedback on whether the tool you're trying to encode is feasible. And finally after IP review or around that time after it's in Gitmaster the hardware companies which are part of the alliance will go over the coding tool and will try to see if it's implementable using current hardware decoding production means. And if they give it a go then then you know they give it a go and it goes in. All right last question. How is the compression ratio. Well right now we're doing quite a lot better than H64. We're doing better than H6 5 on basically all metrics. And after the encoding tools which which I've mentioned are implemented we'll do a slightly worse maybe PSNR base but PSNR is a horrible metric so so perceptually we will look you know quite a lot better than anything which is currently out there. All right well that's it so thank you for having me.
 Alright, so I'm Adam Yooker, I am an FMMPG developer, I've done a lot of work on audio  codecs and video codecs, I was crazy enough to write a Dalit decoder a year ago and I  wrote the first non-Livopas based encoder just when I released it just like a week ago.  So what I'm going to be talking about today is AV1.  Now for those of you who don't know what AV1 is, I've prepared a slide for that.  So AV1 is supposed to be interoperable and open, so it's always going to be royalty  free and it's going to be optimized for the internet so that many of the people in this  room can directly benefit from that, the increase in video compression, the royalty  free and all the other stuff.  It's going to be scalable to any modern device, any bandwidth mostly, it's going to be optimized  for the hardware so that you can easily decode that with little power on a hardware decoder  and as well encode it with varying degrees of success and all the other stuff which you  see all the time in marketing.  This is, by the way, I stole from the AOM website so I would never write something like that.  So decode it, this would mean something like that.  These are the real bullet points.  So it's going to be royalty free, it's going to be, it is already in development and it's  already open and lots of companies are participating in the development of this codec.  So all of the major players like Amazon, Netflix, Google, YouTube, Mozilla and so on.  So whatever happens the codec will see an option.  So what's important now is to get the codec to be competitive with other codecs that are  being developed right now and also make it an upgrade to any codecs which are currently  being used.  So now unfortunately not all companies have joined so there is still some intellectual  property out there which we cannot use.  So that means that we have to get clever and we have to go around that in some ways.  And the whole process of going around means rediscovering new ways of doing something  which might or might not be more efficient.  So moving on, the reference encoder is based on VP9 without VP8 support but with bug fixes.  So some of those bug fixes were meant to go into VP9 but they didn't.  So they made it into VP10 but VP10 got turned into AV1 and so we carry on.  So the way that the development works is companies contribute experiments and these experiments  make it into get master of the encoder.  And after being integrated the experiments are supposed to go through intellectual property  review.  So there's a team of lawyers who looks at the description of the encoding tool and tries  to find patents which have been updated or which haven't been updated which match the  description of what the tool does.  So and eventually after the bitstream has been frozen which should happen around Q4 of  this year all the experiments should be removed.  This is what's in my imagination what's meant to happen but it hasn't happened yet.  So about the experiments there are currently 50 experiments and granted some of them might  don't sound appealing or don't sound like they contribute anything like emulated hardware  or debug bitstream.  But the point is that most of these experiments increase encoding efficiency and well there's  just 50 of them and they're being constantly developed and updated so there's a whole  lot of development going on right now.  So I cannot really cover every single of the 50 tools of the experiments which are currently  in the codec and not to mention that every month new experiments get added and some experiments  get enabled by default.  And so it's kind of difficult to keep track of but I'll just go through some of the coding  tools which have been demonstrated to give gains and have our good candidates for being  part of the codec and the specifications later on.  So the first tool which I'll cover is directional deering.  Now directional deering was something which was supported from DALA and it was required  in DALA because DALA used overlap and most of the encoding techniques in DALA contributed  to some degree of ringing in the image so this deering filter was developed for DALA  but it turns out that since it's arrived at the very end of the encoding process, at  the decoding process you can just easily paste that into any codec and it would just work.  So the way it works is you first segment the image into 8 by 8 blocks and then you scan  for a direction inside this 8 by 8 block so you do that by computing the least squares  method I think.  So the direction doesn't really matter.  What matters is that it does a conditional replacement filter so instead of blurring  out any artifacts and by extension any detail in the image, it only acts on very obvious  ringing patterns.  So in case a single pixel deviates by some amount which varies as a function of how far  away you're particularly from the direction vector, it will replace it with some kind  of an average.  So it works really well and it gives around around 2 or 3% improvements.  It's also easily sendable and it has currently been enabled by default in AV1 so this still  is probably going to make it into the final version of the codec.  Another tool is pvq.  Now pvq is going to give by far the most gains but it's by far the most difficult tool to  integrate.  And what you can think of pvq is you can think of it as a black box where you can insert  any kind of coefficients in the frequency domain and pvq will predict from both the  current image and whatever you give it in to predict from.  So it can be previous pixel values, previous coefficient values or it can be for instance  coefficients from Luma and you want to predict Chroma.  So the way it works is well I'm not really going to explain it but you can see from the  diagram that if you imagine the coefficients inside a block as a vector you can describe  that vector as pointing to the surface of an in dimensional sphere and if you have another  vector which is what you're wanting to predict from you can do just a half store reflection  and then you just send a t-tangle which is n minus one values long.  So I just wanted to spend some time on discussing pvq search because I think pvq search is a  well it's an important problem which also needs to be solved and made faster.  We currently have an implementation which is carried on from Opus because Opus used  a pvq search as well.  We do RDO on the pvq search so that's a bit different but the root of the problem is  very simple.  So if you have a vector and you want to quantize it using a pvq search you just normalize the  vector to an L2 which is the Euclidean norm which is basically you sum up the squares  of each component then you do a square root and then you divide each component of the  vector by the square root and you do that for the output vector quantized as well.  So it's a simple problem but it gives great results and I think it's the way to do vector  quantization.  So if some of you want to go ahead and give it a go and give it a try on improving it  you will improve your performance not just in Dala, not just in Opus but in everyone  as well so that will be useful.  But the properties of pvq is also what makes it very interesting.  Using pvq we can vary the code book so we can optimize it for instance for areas which  have low contrast so this is what activity masking tries to do.  It attempts to provide better resolution in low contrast images and this is in contrast  with HVCU which attempts to aggressively remove details from the original image and if any  of you has done any encoding using HVCU they will know that SAO basically is a tool which  you turn off if you see any bad results immediately.  So activity masking is something which is difficult to make it into AV1 since it requires  a different distortion function but we are all actively working on trying to make it  into something usable in AV1.  So another tool which is also supported from Dala is Chroma from Luma and since we do pvq  entirely in the frequency domain this means that we can also inject values from Luma coefficients  and more accurately describe what exactly are the details in the Chroma.  So you might ask well how does it work when you have a sub-sampled Chroma?  Well we use TF switching to throw away any details.  This is all in the frequency domain so you cannot do rescaling and conversion in the  spatial domain since we are all in the frequency domain.  So the resulting coefficients will be used in a DCT transform and that's one of the difficulties  in implementing Chroma from Luma in AV1.  Since AV1 has currently two different transforms, AV1 has DCTs which are the standard way of  doing transforms and there is an ADSD which allows you to in some circumstances get better  results but there are more transforms being planned to be added into AV1.  So Chroma from Luma is kind of a difficulty to implement but the results really show that  there is a big improvement in Chroma detail and in Luma detail as well since in order  to better describe Chroma you need better Luma.  So that's why CFL is looking like a nice feature to implement into the final version  of the codec.  Now a note is that it works for 4.44 and it works for 4.20 formats but it doesn't work  for 4.22.  So if you want to use 4.22 please don't just use 4.44 or 4.20 or just increase the bit  rate you can always just increase the bit rate like the old 80 megabits impact streams  and pad the bit stream but in order to pad the bit stream there is a convenient segue  here.  You need to ensure that the codec, that the ray control system will not overshoot.  So it will not overshoot grossly since if you plan to pad then you obviously want to  pad to some bit rate but you don't want to overshoot of course.  So this is what I'm currently working on, I'm trying to fix the ray control system in  AV1 by just scrapping it and by inserting the ray control system from DALA which was  also the ray control system from Tioro but was ported to DALA.  So the ray control system which I'm working on tries to basically predict the amount of  bits that the current frame will use and it does that by just this simple model and the  scale value is what's modified from frame to frame.  So the codec will first use the scale value from the previous frame and will predict the  bits the current frame will take and will then after the frames being encoded it will  measure the real scale value since you know how many bits you've used and you know the  quantizer and alpha is just an exponentiate value which is different for all frame types  and it will try to smoothly transition scale from one frame to the other frame using a  second order Bessel filter which will also throw away any extremes in the final quantization  values being used and as such it will give a smoother visual experience of encoding.  So it won't do any gross overshoots that the current ray control system does and just to  share something with you I have seen on YouTube a 200 megabits sustained for five or so seconds  on a screen directly from YouTube.  Granted it was VP9 but it was 4K at 30 frames but still nothing warrants 200 megabits of  continuous usage for a few seconds.  So this ray control system also will support a way of easily providing chunks to kind of  encode so instead of encoding separate temporary chunks I mean a few seconds worth of video  of chunks you can just signal a reset in the two pass mode of the ray control system and  it will reset all the statistics and you can just continue on encoding as if you've just  started encoding a new frame.  And yeah, yeah, alright.  And another feature which I'd also like to talk about shortly is RNS and RNS is being  developed by Google currently and RNS will offer big improvements in the coding speed  but unfortunately there are some drawbacks.  It needs a big enough buffer to store all the symbols in the encoder before reversing  them and writing that as a bit stream because it works kind of as a stack.  So there are some hardware manufacturers which aren't content with having a huge buffer but  at the end it's either this or the DALA entropy coding system both of which have the same  efficiency but RNS has the advantage of having a higher recording speed.  And there are also some experiments which I cannot really dedicate the entire time to  talk about but there is EXT-ETX which will give more transforms which as I already mentioned  will kind of be a bit of a problem for CFL but I'm sure we can do it with it somehow.  There's also an adaptive coding order so the old zigzag which isn't paid in anymore, it  turns out that the old zigzag may not result in the best encoding efficiency so if you  have some kind of other patterns you can use and you can do RDO to figure out which pattern  is the best then if the experiment turns out to give improvements we'll also make it in  and also there's 64 by 64 transforms which aren't quite certain that we'll make it in  but we'll provide big gains on any kind of large uniform images.  So with that I'd like to end the presentation and if there are any questions I'd be happy  to answer them.  We have time for three or four questions.  We will support Interlaced and...  Yeah that's the million dollar question.  So the question was are we going to support Interlaced and well I'm not sure.  No comment.  Just say no.  I cannot say no.  I mean you know how it is.  It's not designed by committee but it is still designed by some people with various interests  so whether it will not make it or make it I cannot say but you know many of us have strong  opinions about it not making it.  Very strong.  Yeah so...  Yeah well the question was wasn't the Bistream going to be frozen in March of this year and  well the Bistream was going to be frozen last year and it was going to be frozen many times  before that but you know how it is you know you just have to keep you know extending because  some features you really don't you need some more research to improve some features but  what's important is that we don't want to delay it too much because by that time H266  will be out and we'll have to compete with that and we want to get adapted before that  so that less people will adapt the less royalty free equivalents of you know video compression  products.  So anyone else?  Yeah.  Well so this is some pretty amazing work and my question is from the outside it looks  like you either follow the footsteps of H264 and the family or be like a foreign work and  I think I've seen some research work on motion religion that is stored as a free teaching.  Yeah.  Is it?  Well you should look into yeah so the question was have we looked into storing motion information  as a kind of a 3D type of thing where the third dimension is time I presume right?  Well there was an experiment that ZIF tried to make it was a codec I don't remember its  name but it used wavelets and three dimensions to try to compress video and as far as I remember  you could actually see you know information images ahead of time you know before it happened  as kind of a ghostly you know images but apart from that nothing is being looked into it  because it's just so radically different and sounds and is difficult to kind of do enough  research to get something which is actually implementable and gives encoding gains and  doesn't require you know much hardware you know to actually implement so I don't think  that it's the way to do it and I don't think it's the way to do it for the next 50 years  or something.  All right there's a person there in the back.  I have a question which is not really codec related but Mux related.  It would work on MP4 right from the start because that would simplify the problem very  much.  So the question was are we going to work on MP4 encapsulation right?  Well let's first get a codec which is which is presentable and then we'll work on MP4  you know Muxing because as it is right now all of us are working on improving the codec  but you know I'm not sure why you won't use MP4 you know because MP4 is what 20 years  old now.  Is it in a broke?  If it ain't broke yeah.  It doesn't look like another office cage where most people can't use it because it's  not your place to go.  Well regardless of whether it's in MP4 it will mostly be used on MP4.  It will be used on the internet and right now WebM is the default standard for video  and audio coding on the internet so it will first be implemented in WebM.  So well sorry about that.  Any other?  Yeah.  This is maybe more of an implementation thing.  Yeah.  Maybe some of the new experiments be included.  Is there a plan for non-tile multi-training?  So the question is are there plans for non-tile multi-training?  Or the experiments might be for tri-training.  Well there will always be frame-training but there will always be well in the decoder  but there will always be tile-training as well so right now there are no plans to drop  tile-training decoding.  But I think there were some plans to drop frame parallel decoding so there's that.  You have to ask Thomas Didi on IRC.  All right.  We have time for I think one more.  All right one more question.  Someone.  It was first.  All right.  Yeah.  Not to play around with future of the internet but about hardware decoding.  I've memorized the file and I've created some formats and put the hardware inside.  So the question is how do you decide which code is implementable in hardware and which  one to actually implement it into the codec.  And the answer is that during initial review you'll get some feedback on whether the tool  you're trying to encode is feasible.  And finally after IP review or around that time after it's in Gitmaster the hardware  companies which are part of the alliance will go over the coding tool and will try to see  if it's implementable using current hardware decoding production means.  And if they give it a go then then you know they give it a go and it goes in.  All right last question.  How is the compression ratio.  Well right now we're doing quite a lot better than H64.  We're doing better than H6 5 on basically all metrics.  And after the encoding tools which which I've mentioned are implemented we'll do a slightly  worse maybe PSNR base but PSNR is a horrible metric so so perceptually we will look you  know quite a lot better than anything which is currently out there.  All right well that's it so thank you for having me.
AV1_Status_update_Progress_expected_features_and_encoding_gains_0_839.png AV1_Status_update_Progress_expected_features_and_encoding_gains_840_887.png AV1_Status_update_Progress_expected_features_and_encoding_gains_888_6035.png AV1_Status_update_Progress_expected_features_and_encoding_gains_6036_6443.png AV1_Status_update_Progress_expected_features_and_encoding_gains_6444_6539.png AV1_Status_update_Progress_expected_features_and_encoding_gains_6540_7283.png AV1_Status_update_Progress_expected_features_and_encoding_gains_7284_8183.png AV1_Status_update_Progress_expected_features_and_encoding_gains_8184_10379.png AV1_Status_update_Progress_expected_features_and_encoding_gains_10380_11183.png AV1_Status_update_Progress_expected_features_and_encoding_gains_11184_12215.png AV1_Status_update_Progress_expected_features_and_encoding_gains_12216_14147.png AV1_Status_update_Progress_expected_features_and_encoding_gains_14148_14807.png AV1_Status_update_Progress_expected_features_and_encoding_gains_14808_15719.png AV1_Status_update_Progress_expected_features_and_encoding_gains_15720_17015.png AV1_Status_update_Progress_expected_features_and_encoding_gains_17016_18911.png AV1_Status_update_Progress_expected_features_and_encoding_gains_18912_20183.png AV1_Status_update_Progress_expected_features_and_encoding_gains_20184_26411.png AV1_Status_update_Progress_expected_features_and_encoding_gains_26412_26519.png AV1_Status_update_Progress_expected_features_and_encoding_gains_26520_27239.png AV1_Status_update_Progress_expected_features_and_encoding_gains_27240_27683.png AV1_Status_update_Progress_expected_features_and_encoding_gains_27684_29195.png AV1_Status_update_Progress_expected_features_and_encoding_gains_29196_31619.png AV1_Status_update_Progress_expected_features_and_encoding_gains_31620_32039.png AV1_Status_update_Progress_expected_features_and_encoding_gains_32040_32579.png AV1_Status_update_Progress_expected_features_and_encoding_gains_32580_37535.png AV1_Status_update_Progress_expected_features_and_encoding_gains_37536_37631.png AV1_Status_update_Progress_expected_features_and_encoding_gains_37632_37753.png