[00:00.000 --> 00:27.000]  Okay, that starts. So our next talk is about the SFD-1 ecosystem done by someone who knows
[00:27.000 --> 00:37.000]  that very well. Please welcome Gérôme. Hello, a bit sooner Jean-Baptiste said that we don't
[00:37.000 --> 00:45.720]  speak enough about FFMPEG, so we'll speak about FFMPEG a bit more, but not about a very fancy codex.
[00:45.720 --> 00:58.720]  The word is about the lossy compression, H265, VVC, or AV1, but we will speak about something a bit more boring.
[00:58.720 --> 01:09.720]  It is the lossless compression. Because some people need to do some broadcasting and just broadcast and forget
[01:09.720 --> 01:18.720]  the content, people can watch and have a lot of compression artefact. If it is visually lossless,
[01:18.720 --> 01:28.720]  or if visually it is not so high level of artefact, it is fine. But for some other people, having a lossless
[01:28.720 --> 01:36.720]  video coding format is very important. And also something open, so no patent and so on.
[01:36.720 --> 01:44.720]  So FFV1 fits a lot of things about that. It is a very old technology, more than 30 years old technology,
[01:44.720 --> 01:52.720]  so no patent for sure. There is also a good reference encoder and decoder. It is FFMPEG. Thank you FFMPEG.
[01:52.720 --> 02:00.720]  It is widespread, so a lot of people can use it. We can embed FFV1 in a lot of different containers.
[02:00.720 --> 02:11.720]  The most used are AVI for all people, MP4, Matroska, MXF also. And FFV1 has a good balance between compression
[02:11.720 --> 02:20.720]  and speed, and also a bit about cost. So because there are some competitions, some open formats,
[02:20.720 --> 02:27.720]  also in FFMPEG, they can have a good compression, but they are very slow, or the compression is not so good.
[02:27.720 --> 02:36.720]  And outside of FFMPEG, we have GPEG 1000, 2000 for example, but encoders are pretty expensive sometimes and so on.
[02:36.720 --> 02:45.720]  But FFV1 is natively in FFMPEG. The compression is good. The speed for a lossless format is not so bad.
[02:45.720 --> 02:56.720]  So we use it a lot in some configurations, especially because with an open format and an open source implementation,
[02:56.720 --> 03:06.720]  it is easy to expand depending on the need we have. So with FFMPEG, we have only black and white or YUV or HGB,
[03:06.720 --> 03:13.720]  and we can also add an alpha channel. We can expand it up to 16 bits per component.
[03:13.720 --> 03:22.720]  So from 8 to 16, and also if we need 12 or 10, we can adapt a lot of FFV1 formats
[03:22.720 --> 03:29.720]  for being able to support every input we need. With the latest development, a few years ago,
[03:29.720 --> 03:38.720]  we have also a good multi-feed system in FFV1. We have checksum, so we are sure that when we store the content,
[03:38.720 --> 03:43.720]  we can detect if there is a problem during the storage.
[03:43.720 --> 03:52.720]  A lot of work was done by Michael Niedermeyer a few years ago, so he is the main developer of FFV1.
[03:52.720 --> 03:57.720]  So thank you to him about that. It helped a lot.
[03:57.720 --> 04:08.720]  So we are aware that a lossless compression is a very niche market because not so many people need it
[04:08.720 --> 04:19.720]  compared to the broadcasting of a lossless compression like H264 or AV1 and so on.
[04:19.720 --> 04:27.720]  And these people who need that are not rich, but it is pretty important for them to have a lossless compression.
[04:27.720 --> 04:34.720]  And also, actually, it is also for us important because a lot of users who need lossless compression
[04:34.720 --> 04:43.720]  is working in archives, so for our heritage, in 101,000 years, we need to have the content.
[04:43.720 --> 04:50.720]  And for that also, it is important to keep the content as best possible.
[04:50.720 --> 05:01.720]  So no compression artifacts. It is the reason these people want no compression, no lossy compression.
[05:01.720 --> 05:12.720]  And in this niche market from archives, some entities discovered that paying for FFV1 development inside FFMPEG, for example,
[05:12.720 --> 05:16.720]  is a lot less costly than buying products on the shelves.
[05:16.720 --> 05:22.720]  Even if the product are there, when you buy a product, it is pretty expensive.
[05:22.720 --> 05:25.720]  It is a package. You need to buy a package.
[05:25.720 --> 05:36.720]  And actually, if we take this money and don't buy the products on the shelves and we develop a product inside FFMPEG,
[05:36.720 --> 05:43.720]  it is less costly. And then after that, other entities discovered that, oh, it is in FFMPEG and it is open,
[05:43.720 --> 05:53.720]  it is free of charge, no patent, the software is also free, open source and free, and there is a lower cost for them too.
[05:53.720 --> 06:01.720]  So it is very good for these people. They are not rich. They need to have this lossless compression and FFMPEG is perfect for that.
[06:01.720 --> 06:10.720]  But yeah, they need to trust that this choice is sustainable and FFV1 is in FFMPEG, but it is not a standard.
[06:10.720 --> 06:24.720]  So Archive wanted to have more trust in the format, so it is not only about code, but we need also to have a standard, for example.
[06:24.720 --> 06:36.720]  And there was a work sponsored by the Open Union and there was a project called Preformer to help Archive to have checks on their file.
[06:36.720 --> 06:42.720]  And for the documents in Archive, it was easy, PDF, it is a NISO standard, fine.
[06:42.720 --> 06:49.720]  For images, when they do scan, it is also not so bad, they have teeth, it is a NISO standard, it is good.
[06:49.720 --> 06:59.720]  But now they have a lot of AV content and for that, there was no open and standardized format.
[06:59.720 --> 07:09.720]  So they decided to sponsor some work on Matroska and FFV1 and PCM for the audio, so no format for that.
[07:09.720 --> 07:20.720]  So we tried to work with Preformer and we helped to create an ITF working group.
[07:20.720 --> 07:29.720]  And why ITF and not ISO or SMBTE is mainly because ITF has no paywall for the standards.
[07:29.720 --> 07:35.720]  So it is very useful for people who are not rich, a lot of Archive are very small.
[07:35.720 --> 07:41.720]  They don't have the money to pay a lot of different standards and so on.
[07:41.720 --> 07:50.720]  And also, ITF is very welcoming new people, helping them to create a new standard.
[07:50.720 --> 07:52.720]  So thank you to ITF for that.
[07:52.720 --> 07:59.720]  On our side, we focused on different formats, so Matroska for the container part, FFV1 for the video part
[07:59.720 --> 08:05.720]  and also for some lossless audio compression flag.
[08:05.720 --> 08:13.720]  So now with ITF, we are working well, it is a bit slow because we are mostly now volunteers,
[08:13.720 --> 08:18.720]  but we are still working inside the CELAR working group.
[08:18.720 --> 08:28.720]  So Matroska, it is still a work in progress, some part, eBML, the base of Matroska is already published.
[08:28.720 --> 08:31.720]  It is AIFC, so it is good.
[08:31.720 --> 08:35.720]  Now we are working on the core of Matroska.
[08:35.720 --> 08:41.720]  It is on the way and then we will work on the codec, on the tax part and so on.
[08:41.720 --> 08:46.720]  A lot of work is done by Steve Lohm, thank you to him.
[08:46.720 --> 08:50.720]  And thank you Steve, you are there.
[08:50.720 --> 08:56.720]  And also for FFV1, we worked on having a standard.
[08:56.720 --> 09:04.720]  So now the version 01 and 03 are published, it is an AIFC, so people are more confident in that.
[09:04.720 --> 09:11.720]  And we want to have also FFV1 version 4, but we still need more development about that.
[09:11.720 --> 09:18.720]  About the audio part, it is still on the way, there is an ITF last call.
[09:18.720 --> 09:26.720]  So the specification is nearly ready, but there is still some review by ITF to do.
[09:26.720 --> 09:36.720]  So Martin is working a lot on that and we hope to have the AIFC maybe next month.
[09:36.720 --> 09:43.720]  But for video format, it is not only in ITF world, it is not only Matroska.
[09:43.720 --> 09:47.720]  We also need to have it accepted a bit more everywhere.
[09:47.720 --> 09:53.720]  We asked to SMT to accept FFV1 in MXF.
[09:53.720 --> 10:01.720]  So it is not something easy because SMT you need to register and you need to pay a lot and so on.
[10:01.720 --> 10:09.720]  But thanks to the Library of Congress, they wanted that to replace GPAC2000 by FFV1.
[10:09.720 --> 10:17.720]  So they worked with SMT and now FFV1 is officially supported by MXF.
[10:17.720 --> 10:25.720]  So it is not a standard but it is an ARDD, so registered disclosure document, a bit like ProRes in MXF.
[10:25.720 --> 10:36.720]  We have a universal label from MXF, available for FFV1, it is not a hack, it is registered in SMT.
[10:36.720 --> 10:50.720]  So FFV1 is not only in FFMpeg and not only in Matroska, it is also in other containers and not only the one used on the web.
[10:50.720 --> 10:54.720]  It is also used in MXF, so more for broadcasting.
[10:54.720 --> 11:00.720]  FFMpeg has support of FFV1 in MXF for demixing for the moment.
[11:00.720 --> 11:13.720]  And we sent a patch for the mix in FFMpeg Devol, so it is on the way to have a good support of FFV1 in MXF inside FFMpeg directly.
[11:13.720 --> 11:24.720]  For the archive, it is not only about storing the files, it is also being sure that the files are perfect compared to the specifications.
[11:24.720 --> 11:33.720]  So we work with an ecosystem, so it is not only the code, we create a file and then we put in the storage.
[11:33.720 --> 11:43.720]  We want to be sure that later it will be readable because it is not just an immediate usage, it is for the future.
[11:43.720 --> 11:48.720]  So a lot of people need to be sure that the file is fine.
[11:48.720 --> 11:58.720]  So we created a conformance shaker called Media Conch and based on the specification, from Matroska and FFV1 for example,
[11:58.720 --> 12:02.720]  we can say that the file is conformed or not to the specification.
[12:02.720 --> 12:12.720]  And before putting the file in the storage, we are sure that the file is conformed to specification so that it will be easy to read it later.
[12:12.720 --> 12:28.720]  But sometimes in the archive we have different inputs with very different formats and with some proprietary formats, sometimes about lossless storage.
[12:28.720 --> 12:43.720]  So for the archive it is very difficult to be sure that in 100 years they will be able to put to play a file with a codec only available for Windows 95 for example
[12:43.720 --> 12:54.720]  and it is only 32 bits and it is only for Intel CPU but maybe in 100 years there will be only ARM.
[12:54.720 --> 13:00.720]  So it is better to convert and for that a lot of people are using FFMpeg.
[13:00.720 --> 13:03.720]  So thank you FFMpeg about that.
[13:03.720 --> 13:16.720]  And archives, the PIM Institute and so on, they use FFMpeg, they don't develop FFMpeg but the community needs also to do some scripts.
[13:16.720 --> 13:20.720]  So they publish scripts about how to use FFMpeg.
[13:20.720 --> 13:30.720]  So we have two examples there about how archives are using FFMpeg for doing the transcoding.
[13:30.720 --> 13:39.720]  Another practical usage in FIM archives is that usually they receive from a scanner a dpx file.
[13:39.720 --> 13:46.720]  So they don't have only one file, they have one file per image.
[13:46.720 --> 13:57.720]  So it is totally crazy for the file system and it is difficult to store, it is very huge, there is no compression and so on.
[13:57.720 --> 14:02.720]  So we can help with open source format.
[14:02.720 --> 14:06.720]  So with Matroska, FFV1 and Flak, why not?
[14:06.720 --> 14:15.720]  It's still huge because it is lossless compression but dividing by two the cost of storage is good to take when you have petabytes of content.
[14:15.720 --> 14:22.720]  The issue is that not all workflow accepts FFV1 and Matroska.
[14:22.720 --> 14:32.720]  So we need something for doing the conversion between dpx and FFV1.
[14:32.720 --> 14:40.720]  There is also some legal commitments, it is a bit crazy but we need to have the exact same file.
[14:40.720 --> 14:53.720]  So if a dpx file comes in, the legal requirement is to provide the dpx file when it is requested by the state for example.
[14:53.720 --> 15:03.720]  So for the compression it is not so good because FFV1 compresses the video but not the dpx header for example.
[15:03.720 --> 15:20.720]  So we need a bigger ecosystem than FFV1 alone because FFV1 is about the video compression but not everything besides the video content.
[15:20.720 --> 15:33.720]  So we created a tool called RowCooked and this tool fills the gap between what exists, FFMpeg and what is needed to save the dpx header for example.
[15:33.720 --> 15:40.720]  So with RowCooked, we take the dpx header, we store it in an attachment in Matroska.
[15:40.720 --> 15:50.720]  So it is also useful to have an open source content, a container format because we can expand it and so on very easily.
[15:50.720 --> 16:09.720]  And we send the video content to FFMpeg, FFMpeg does the compression and besides that when we need again the dpx, we decode with FFMpeg, we inject again the dpx header and we create from that the exact source file.
[16:09.720 --> 16:23.720]  So we have this ecosystem around FFV1 and we want to expand it to have what could we do with that.
[16:23.720 --> 16:30.720]  FFV1 is good but speed is good but we could be better maybe.
[16:30.720 --> 16:39.720]  We want to expand the decoder and encoder maybe with SIMT or GPU acceleration but we need to work on that.
[16:39.720 --> 16:49.720]  And then maybe if we have other needs we will create FFV1 version 4 and with inside the IETF system.
[16:49.720 --> 17:02.720]  So as a summary, code is important, for example FFMpeg has a very good FFV1 encoder and decoder but it is not enough because we need to make user communicate and to share the scripts.
[17:02.720 --> 17:09.720]  We need to have the formats reviewed by standardization body to be sure that the format is fine.
[17:09.720 --> 17:21.720]  If the IETF when we worked on having a standard about FFV1 for example, we found some bugs in the reference encoder.
[17:21.720 --> 17:35.720]  So it was good to have reviewers about that and we create for that a big community not only about the code, the FFV1 code but also the users.
[17:35.720 --> 17:50.720]  And with that we show that open source can also help about niche needs and not only broadcasting and the big things like YouTube and so on.
[17:50.720 --> 18:06.720]  This is finished so if you have questions.
[18:06.720 --> 18:20.720]  So the main crisis was about speed encoding but I had that question since before so maybe the next version could be comparable to JPEG XS?
[18:20.720 --> 18:22.720]  You mean maybe JPEG XL?
[18:22.720 --> 18:26.720]  There is an XS, yes exactly.
[18:26.720 --> 18:36.720]  How is it comparable to JPEG XS?
[18:36.720 --> 18:39.720]  There was some discussion between us and JPEG XS developers.
[18:39.720 --> 18:45.720]  So JPEG XS is actually a bit base of FFV1.
[18:45.720 --> 18:54.720]  The developer took part of JPEG 2000 and also part of FFV1 for creating JPEG 2 XS.
[18:54.720 --> 19:00.720]  So there was a path between, there is something from FFV1 actually in JPEG XS.
[19:00.720 --> 19:09.720]  JPEG XS is also open but the specification is not open also.
[19:09.720 --> 19:20.720]  For FFV1 the specification at IETF varies a copyright on it and you cannot modify it.
[19:20.720 --> 19:26.720]  But the version in our GitHub is totally open source also.
[19:26.720 --> 19:32.720]  It is a creative command license.
[19:32.720 --> 19:43.720]  So also a big difference between FFV1 and JPEG XS is that FFV1 is easier to understand about the compression mechanism
[19:43.720 --> 19:50.720]  and also that the specification license is open also.
[19:50.720 --> 19:53.720]  And for us it is very important that everything is open.
[19:53.720 --> 19:59.720]  Not only the compression and the decompression but also the specification.
[19:59.720 --> 20:12.720]  But we need to do more performance comparison between speed or compression efficiency with JPEG XS for sure.
[20:12.720 --> 20:20.720]  Just to continue on JPEG XS there is also the issue that JPEG XS is not royalty free.
[20:20.720 --> 20:24.720]  So that also is a consideration I think that is important.
[20:24.720 --> 20:29.720]  You need to repeat what you said.
[20:29.720 --> 20:34.720]  There is an issue about JPEG XS about royalty.
[20:34.720 --> 20:46.720]  It is not completely sure about there is some risk about patents but the JPEG XS developers wanted that it is more or less free.
[20:46.720 --> 20:48.720]  So there is a discussion about that.
[20:48.720 --> 20:57.720]  But it is based on JPEG 2000 and there was some risk of patents with JPEG 2000 about the lossless part of JPEG 2000.
[20:57.720 --> 21:02.720]  So there is exactly some risk about patents in the compression system.
[21:02.720 --> 21:09.720]  With FFV1 we are completely sure that there is no patent because we created nothing about that.
[21:09.720 --> 21:17.720]  I didn't really have a question but I just want to thank the FFV1 project because it was...
[21:17.720 --> 21:26.720]  I made a free lossless image format and it was quite inspired by FFV1.
[21:26.720 --> 21:33.720]  The sense of the entropy going and the context modeling that is going on there was inspired by FFV1.
[21:33.720 --> 21:41.720]  And now these things have moved from FLIF to JPEG XS, which is the other JPEG standard,
[21:41.720 --> 21:49.720]  where some of the context modeling of FFV1 actually is used in JPEG XS as well.
[21:49.720 --> 21:58.720]  So the remark was about FFV1 helped to create FLIF and then JPEG XS.
[21:58.720 --> 22:05.720]  So it is part... FFV1 was... maybe I misunderstood.
[22:05.720 --> 22:10.720]  You talk about JPEG XS and I mix up with JPEG XS.
[22:10.720 --> 22:16.720]  I wanted to say about JPEG XS. So sorry about the confusion.
[22:16.720 --> 22:21.720]  So the names are confusing.
[22:21.720 --> 22:31.720]  So FFV1 was the base of JPEG XL and now we need to do some comparison between what is FFV1 now
[22:31.720 --> 22:36.720]  and if JPEG XL can help more than FFV1.
[22:36.720 --> 22:43.720]  But for the moment, it is pretty important for us to have open specifications and not behind the paywall.
[22:43.720 --> 22:48.720]  So with IETF for us, it is very important to have that.
[22:48.720 --> 22:59.720]  I agree that IETF is much better in that regard than ISO, which puts all the specifications behind the paywall, which is not helpful.
[22:59.720 --> 23:05.720]  Yeah, one other issue with JPEG XL is the paywall.
[23:05.720 --> 23:07.720]  Another question?
[23:07.720 --> 23:12.720]  In comparison to raw video, what kind of compression ratio can someone expect?
[23:12.720 --> 23:18.720]  The compression ratio is between 1 to 3, between half.
[23:18.720 --> 23:23.720]  The average is half. Sometimes it is a third, sometimes a bit more.
[23:23.720 --> 23:31.720]  But the average compression ratio is divided by two, the storage cost.
[23:31.720 --> 23:34.720]  Is the algorithm itself extensible?
[23:34.720 --> 23:40.720]  In the future, let's say you have a new compression algorithm that gets better ratios, can you switch that?
[23:40.720 --> 23:46.720]  We could switch. FFV1 is based on the range code for the moment.
[23:46.720 --> 23:50.720]  But if we find something better, we could switch.
[23:50.720 --> 23:59.720]  There is a discussion for FFV1 version 4 about what to use instead.
[23:59.720 --> 24:09.720]  Is there a theoretical limit on how much you can divide the file based on the information of, for example, the video?
[24:09.720 --> 24:13.720]  Is there a limit about the compression ratio?
[24:13.720 --> 24:21.720]  It is more that the content itself, we need to avoid to lose a pixel.
[24:21.720 --> 24:24.720]  So if you have a black frame, it is very, very small.
[24:24.720 --> 24:29.720]  So the range code, you can store in two bytes.
[24:29.720 --> 24:37.720]  If it is only black, it will be repeated and there is no bit consuming about that.
[24:37.720 --> 24:43.720]  But this is not a use case we have in reality.
[24:43.720 --> 24:54.720]  How does the output file size compare with other codecs that use high-quality parameters?
[24:54.720 --> 24:59.720]  Compared to lossy compression, you mean.
[24:59.720 --> 25:09.720]  A lot. The files are, if you have...