Interview met Peter Bubestinger en Herman Lewetz (Österreichische Mediathek)

ÖsterreichischeMediathek,Vienna, May 6 2014.

 

The Austrian Mediathek is in charge of the long-term preservation and access to the Austrian audiovisual heritage. People in this institution have been working for several years towards building a digitisation- and preservation-workflow as open source as possible. Today they show that open source formats and software can be used to make a working and efficient long-term preservation environment for audiovisual material. Emanuel Lorrain met Peter Bubestinger and Herman Lewetz to know more about the infrastructure and the tools they have developed to secure the Austrian audiovisual heritage in their collection.

 

PACKED: Could you tell us about your respective backgrounds?

Herman Lewetz: I studied cinematography and post-production in a film school. I started working at the Austrian Mediathek1 in 1997 where I was responsible for filming events. Later on, I worked for the archive because I was the person in-house with most experience with audiovisual material because of my background in film and video production. I've been involved from the beginning in setting up the audio digitisation and the mass storage system.

Peter Bubestinger: My background is in IT. I studied computer science and at the same time I was doing audio engineering as a hobby. A company called 'NOA audio solutions'2 started to make audio digitisation solutions for large audio archives and their first customer was the Austrian Mediathek. I worked for 'NOA audio solutions' for about 7 years so I was familiar with the Austrian Mediathek.

 

PACKED: The Austrian Mediathek is one of the first archives to use FFV13, an open source codec for video preservation. How did you choose this codec that no other institution was using then?

Herman Lewetz: In 2010, we received funding to make a number of recordings of the collection accessible online. As some videos were part of the list, I decided that we had to develop a solution for the video archive. At the time, the only solution I knew for video digitisation was the Samma Solo4, an American system with an intelligent workflow. I had seen it through IASA5 and Presto6 and I had talked to people to collect information about the system and calculate a budget to buy one. But when I received a file produced by a Samma Solo, I realised that I wasn't able to open it and play it back without using the Samma Solo itself. I thought that it wasn't OK for an archive to rely only on one tool and solution.

 

A MII tape player at the Austrian Mediathek. Photo: PACKED vzw.

 

Peter Bubestinger: Shortly after I quit my work at NOA, Herman told me that they wanted to start digitising their video collection. He wanted my opinion on formats and on the MXF/JPEG20007 files that he didn't know how to handle. We started evaluating what existed as ready solutions for video digitisation and basically there was only Samma.

Herman Lewetz:Before considering FFV1, we first thought of using picture sequences. Although I still think it is a good idea, performance was too big of an obstacle.

Peter Bubestinger: Yes, we first thought about storing digital images just like it is done with film scanning, because image files have been around for a long time and they are well documented. DPX is an uncompressed only image format resulting in files that were too big to store for the archive so we needed compression. Of course, it had to be lossless formats only: PNG, JPEG LS (JPEG Lossless), Lossless JPEG2000 and TIFF. Unlike with uncompressed video where you can make the calculation on paper, with lossless compression, you need to make tests with different types of material to see how well it behaves according to the algorithm. I made tests about these compression ratios, so I knew what to expect in terms of file size.

 

PACKED: Why did you decide not to use image file format in the end?

Peter Bubestinger: The first problem was that some of these image file formats didn't support YUV colorspace8. It was also very hard to find tools for Lossless JPEG2000, and even harder to find tools that could do JPEG LS. PNG showed really good compression ratio, but at high performance costs. The second big problem with image sequences is that the overhead of accessing a file is unbearable.

 

PACKED: What were the video formats you then evaluated?

Peter Bubestinger: We considered Lossless JPEG2000, but it was really hard to find any video codec to do it. We used the Morgan encoder9 for our test, but the framemd5-procedure10 didn't match. Since the Morgan encoder is a blackbox, we just couldn't verify the losslessness of the compression. It also always crashed with 4:2:0 chroma subsampling11 during our tests. Christoph Gerstbauer at NOA was doing tests in parallel and they also had gaps with Morgan and JPEG2000. Then we asked the “Phonogrammarchiv”12 that had a Samma Solo if we could get files to make tests.

 

PACKED: When did you make these tests with Jpeg2000 files produced by the Samma encoder?

Herman Lewetz: It was in 2010. It was the first generation of Samma Solo encoders.

Peter Bubestinger: Phonogrammarchiv was not able to convert their MXF/JPEG2000 on a file-to-file basis, because the tools to convert the MXF/JPEG2000 came out of the Samma Solo. If somebody would ask a file for production purposes, they told us that they needed to stop the ingest procedure.

Herman Lewetz: I also asked the Library of Congress how they were working with these files as they have several Samma installations. They told me that they were making two files: an archive file in MXF/JPEG2000 and a so-called production file in MPEG-2.

Peter Bubestinger: In the end, JPEG2000 was so difficult to handle that we dropped the idea of using it. I then continued to evaluate other lossless codecs and their accessibilities. I already knew HuffYUV13 had great performance, as it was designed to have good encoding performance for the era of Pentium 266 MHz14. Sadly HuffYUV didn't compress much compared to JPEG2000 or PNG.

Herman Lewetz: We kept asking around, because we just wanted something that works without having to reinvent the wheel. Answers of institutions were just: "We don't know, we can't do this, we have these systems, but then we still use lossy files actually. We don't even know in which shape the archive copy is, because we've never opened it, but we believe it is in good shape."

Peter Bubestinger: All the systems that were developed for video digitisation at that time were targeting a market, so they were thinking in terms of products rather than solutions. We were just looking for a solution. We were not looking to have it for free, but we wanted to have it sustainable and accessible.

 

PACKED: Did you consider other codecs such as Dirac15 and H.26416 Lossless in your tests?

Peter Bubestinger: Yes and I was very sorry that I had to say goodbye to Dirac because it had the same performance issues as JPEG2000 while being even less available. Although the BBC did all the efforts of making it completely open, the final pieces of the puzzle, which is just a codec/wrapper package that you can have in a GUI, were not there. As for H.264 the main use case is lossy and Lossless H.264 is hardly implemented and tested because of the small user base.

 

PACKED: Long-term preservation guidelines often recommend using formats adopted by other archives and especially big institutions. Weren't you a little bit scared to be alone in choosing FFV1?

Peter Bubestinger: After tests with FFV1 we saw that it was the codec with the best performance, good compression ratios and also the most accessible, which was really surprising because we hadn't heard about it from anyone in the professional field before. I first heard of FFV1 in a Russian document from 2004 (updated in 2007) comparing lossless codecs. I then read the source of the codec and it said "experimental", so I contacted the FFmpeg mailing list to know about the codec's status. The next message I received was from the developer Michael Niedemayer who wrote "Sorry I just forgot to remove 'experimental'". FFV1's bit stream was frozen since 2006 but there was no documentation about it online, and Wikipedia just said that it existed.

 

The FFmpeg project logo.

 

Herman Lewetz: FFV1 is very simple, because it can only do lossless. So many websites talk about JPEG2000. Sometimes you have to install a program completely to find out that it can only do lossy JPEG2000 and not lossless.

 

PACKED: Once you had chosen FFV1 as a codec, you chose AVI as a container, which is also quite uncommon for an archival format. Did you consider other containers as well?

Peter Bubestinger: We checked four different containers: MXF, Matroska, AVI and MOV17. From a pure IT technical point of view, I wondered what properties I needed to judge and estimate the long-term sustainability and accessibility of a format. To answer the question of how to get out of a format, I can't only think of what exists now, I must also think of what could exist in the future, because technical properties and environments are changing rapidly as we speak.

We first thought that using a standard such as MXF was a good idea, but if the implementation of the standard is proprietary then it is an interpretation of a paper and you never know what you're going to get. That is why our choice was to have open implementations from A to Z if possible. By doing that we could archive all the components we use in our workflow and in our transcoding system: the source codes, the documentation, blue prints, and the parts. With digital media you can archive your player and that is what we did.

 

PACKED: Do you experience any limitation with the use of AVI as a container?

Peter Bubestinger: AVI doesn't possess a number of features. One of them is 'variable bitrate'18, but we use uncompressed PCM and it doesn't have variable bitrate. Neither can you wrap timecodes in AVI, but we don't have timecodes and it is the same for the majority of archives that are not broadcast. Moreover if you have a container where you can put fancy time-based metadata, then there is a risk that applications treat these metadata also in a fancy way. If we ever needed it we would treat this special case, but for the rest of the material it is not necessary.

Herman Lewetz: AVI is so simple and pure as a container, that the numbers of mistakes you can have when using it are very limited.

 

PACKED: In order to have a fully open source archival format why didn't you choose Matroska or another open source container instead of AVI?

Peter Bubestinger:  Matroska has very good properties in the real world, because its developers didn't need a product, they needed something that works. It has its origins in the open source domain and it is based on non-professional and non-institutional use cases. It is interoperable, and it can handle a lot of different things. From a technical point of view, everything I know about Matroska at the moment, is nice.

Herman Lewetz: Technically, Matroska would have been the best choice, but we didn't dare.

Peter Bubestinger:One reason was that it hadn't been around for very long, so it was not as well supported as AVI. Then, even if it is getting better and highly interoperable, it is not supported yet and/or not supported by principle by the professional domain. Because Matroska is used to make illegal copies of DVDs it is very unlikely that, for example, the SONY Playstation for instance will support Matroska anytime soon. Matroska has a reputation linked to illegal activities and when you have to deal with the people from the production side, they just consider it as an enemy and not as a technical option. The same is true for torrent as a protocol for instance.

Herman Lewetz: If we ever want to change our container, I think it won't be MXF, but Matroska. In the City of Vancouver Archives19, they are already using FFV1 in Matroska as an archival format.

Peter Bubestinger: The City of Vancouver Archives pointed out some legal grey zones of AVI. But in fact, even if Microsoft decided to forbid something, the whole world would probably ignore it for a very long period of time because it can do no less.

Herman Lewetz: The other thing is that we don't sell it. We just have it in our archive and no one can forbid that.

Peter Bubestinger: We have FFmpeg and we archive its GIT20 repository. Even if Microsoft legally forced us to remove AVI, we would still have everything we need to migrate our files to another container.

 

PACKED: You just mentioned the Vancouver City Archive as another archive using FFV1. At the time you chose it as your archival format did you know any other institution that was also using it?

Herman Lewetz: I'm a member of the technical committee of IASA and people were only talking about uncompressed video or JPEG2000. When I went to the 2010 AMIA Conference21, Dave Rice22 from the New York City University Archive23, was the first other person from the field who knew about FFV1.

Peter Bubestinger: When Herman talked about it with Dave Rice, I knew that someone else on earth was willing to get his hands dirty. We collaborated, shared our tests and then started to list the things that we wanted FFV1 to be able to do, such as 10-bit encoding, multi-threading24 and CRC checksums25. FFV1 version 3 now includes all these features and the bit stream was officially sanctioned as stable and tested in August 2013.

 

PACKED: How did you proceed to get properties that are important for archiving to be added to the codec?

Herman Lewetz: We took our money and we asked the developer Michael Niedermayer directly.

 

PACKED: Could you describe the Austrian Mediathek's digitisation workflow?

Peter Bubestinger: We use an A/D converter, a Leitch DPS 575 that is not produced anymore since Harris bought Leitch. It is an old machine, but the best compared to all the newer ones we tested. A lot of recent models don't have all the analogue inputs we need; they have component and composite, but no S-video for example. The other problem we had is that we couldn't have recent A/D converters to be genlocked26 correctly during our tests. A/D converters heavily interfere with the material and we want to have A/D converters that do it accurately.

 

A Leitch DPS 575 A/D converter. Photo: PACKED vzw.

 

Herman Lewetz: It is logical that an A/D converter changes some things, but the question is how and how often it does it.

Peter Bubestinger:  Unfortunately, archiving is not an interesting market for A/D converter manufacturers. For them it is more important to do 3D, HD and things that target the broadcasters and the production side. Manufacturers are moving towards making it more fun and less hassle just to cover up the technical rough part. We recently made a new batch of “DVA-Fidelity27” tests with A/D converters and we found out that even the professional ones are moving towards this. The majority of people using these boxes usually don't need analogue as an input source anymore. The broadcasting and production market that archiving was profiting from, is moving more and more towards digital production while the analogue side is getting less tested and less documented. Analogue is like a stepchild in newer A/D converters and the older ones are coming to the end of their life. We talked to other institutions and to say it boldly, most of them just buy something and if there's an image in the end, they're happy.

 

PACKED: What capture card and capture software do you use?

Peter Bubestinger: We have a Black Magic Decklink SDI card and on the capture workstations we currently still use a Windows OS for driver and support issues of the capture card. We use VirtualDub, which is another reason why we use Windows. VirtualDub is incredibly accurate; it doesn't do anything that you don't tell it to. It doesn't do any fancy correction; it really keeps the material authentic. Currently, we capture using “ffdshow-tryouts”28 in order to have FFV1 support in Windows and capture directly in FFV1. We don't have an intermediate state, where we would capture to uncompressed and then transcode to FFV1.

 

Screenshot of the DVA-Profession system.

 

PACKED: When does the DVA-Profession system29 you developed for the Austrian Mediathek come into play?

Peter Bubestinger: DVA-Profession does the workflow management system. You get a capture request from the catalogue, which is just a plain text file that contains information such as the title, the archive signature and some minimal descriptive information. Then you go on onto the next step, which is digitising the tape. With DVA-Profession you're not bound to VirtualDub, you can use any capture application you want. We wanted to keep it as open as possible so we could digitise one format with this application and one other format with another application. DVA-Profession just produces a folder and an empty file, so there is no manual file naming because that is a common source of errors. The DVA system only works with text files, no database, just folders. Of course, it is not as powerful as a database, but it is just for digitisation, not for mass storage and retrieval.

Once captured, we don't store one large file, but we export it into segments. We cut it into 1500 frames per segment, which for PAL is one minute. In our wildest dreams we would never have imagined that we would be able to open the lossless archive copy as easily and conveniently on a regular machine over the network. We thought we would have to build some kind of transcoding infrastructure.

Herman Lewetz: When we made the concept for the DVA system, we didn't know yet that we would be able to play the lossless archive video file through our network without problems. That is why we decided to make the access copy not in parallel, but afterwards. So we have the segmented archive copy and from this file we make the MPEG-2 access copy. In terms of performance, it is the worst way to do it, but by doing so, we are sure that what we see in the access copy is also in the archive copy.

Peter Bubestinger:  We just say 'in point/out point' and then it gets cut into minute segments. It is still not transcoded at all at this point, so we still have the information as it is captured but re-multiplexed into segments. Then we make DVD specifications conform MPEG-2 access copies. We produce thumbnails for each minute and we run an open source tool that looks for scene changes when there is a cut.

 

PACKED: What is that scene detection software that you are using?

Peter Bubestinger: It is called “Shotdetect”30. It is an open source shot detection program that was actually designed for an art installation in Centre Pompidou. It also produces analysis graphs, that were used to visualise something in this artwork, but they didn't have a timescale on it, or any information about how long it was, etc. I contacted the developer and I improved a few things and added a timescale to it. With the analysis graphs, we can do the quality analysis, because the shot detection goes for scenery changes of pixels from one image to the other. If you have certain artifacts in your picture it triggers the scene change. So you can use the minute images without having to actually look into the video. Within these preview images, you can very often see distortions that trigger the jumping of a field, or color loss, you can see this in the shotdetect preview images. Marion Jaks, our colleague who does the digitisation and quality control can read these analysis graphs. When you look at the graph you also know what to expect in the image. Sometimes when we are making tests, she's going through the graph and she knows that some things are just someone taking a picture or somebody moving his hand. She can see a lot of things just by looking at the graph and the thumbnails that correspond to that moment of the graph.

 

Screenshot of DVA Profession's analysis graphs.

 

PACKED: So these graphs help you to perform the quality control of the files?

Herman Lewetz: Yes. If you see anything that seems wrong on the thumbnails that are created from the segments, you can click on it and it will open a big, aspect ratio corrected version of the picture. Then if you click on this big picture, you open VirtualDub31 and the lossless file to which it refers. After this check, we can be pretty sure that these files are in the condition in which the operator found them. We checksum them and since we have minute segments, we checksum each minute.

 

Screenshot of the DVA-Profession system.

 

PACKED: How do you deal with born digital formats such as DV formats? Do you normalise everything to FFV1 as well?

Herman Lewetz: The best way to do it would be to use only one codec and one container. In reality, there are so many codecs and containers and ways of putting the information inside, that you can't build your archive like this. Whether it is tape-based or file-based, we keep it as close as possible to the source.

Peter Bubestinger: We found out that there are different types of DV formats depending on, for instance how cameras dealt with the organisation of the file's header32. There are also several types under the name DV. There is the original I-frame DV codec, HDV, DVCam, DVCPRO50, 25, etc. We transfer them over Firewire and we dump the bitstream as we get it off the tape. To verify that it is really exact I ingested the same tape with two different DV tape players and two different computers. I did a framemd5 comparison for audio and video and it came out as a perfect match. So I am very sure that the way we are ingesting DV is as bit-proof as it can be. Sometimes you loose a few frames at the beginning because it depends on the tape player and on the tape condition. We store it in AVI with PCM audio and we also segment it just like for FFV1 files.

 

PACKED: So DV tape formats are the only ones that you don't ingest in FFV1?

Peter Bubestinger: Yes, for space reasons also. For audio material, we always transcode it to uncompressed PCM, because we can afford it storage-wise. For video, we decided to have a whitelist with DV, MPEG-4 (standard profile) as well as H.264 and MPEG-2. It would surely be easier to normalise to the codec and container you chose for the rest of your collection.

Herman Lewetz:  I wouldn't allow XDCAM to enter the archive for instance. It is a wonderful format for production, but it is relying so much on SONY's decisions, that if they ever stopped it we wouldn't be able to access it anymore. Even the XDCAM decks are not so widespread.

 

PACKED: Can FFV1 handle HD material as well?

Peter Bubestinger: Yes it can, and it can even handle 4K. FFV1 is totally resolution independent.

Herman Lewetz: When we capture, we capture directly in our capture format, because it makes the workflow much quicker. In HD, it would be an HD 10-bit and I don't know if the computer would be able to do it in real time. I think that with FFV1 version 3 it is possible, but the HD area is almost only file-based so we don't need real time encoding. HDCAM is the exception, but we don't have any of these tapes or machines in our collection.

 

PACKED: Could you explain how you store the files?

Herman Lewetz: This is the project we're working on at the moment. We have two raid systems, one in-house and one in St. Johann which is a bunker in the mountains in which there is a five floor building and on one of these floors there is IT where we have two square meters, a rack and the cable.

 

RAID server system at the Austrian Mediathek. Photo: PACKED vzw.

 

Peter Bubestinger: We have three copies in total. One is in the production pool on which we ingest, work, read and write. Another copy is in the bunker, in case all hell breaks loose, or a war or other things that could happen that we hope will not. And because hard disks behave differently from a preservation point of view we have a copy on tapes and we do checksums. At the moment we’re doing checksums, but not as I would like to. I would like to include framemd5 into DVA-Profession, but we don't have it yet, we just have file checksums, but in our case we have it for every minute. When we copy to the two other pools, we verify these checksums.

 

LTO data tape robot at the Austrian Mediathek. Picture: PACKED vzw.

 

Herman Lewetz: Compared to a single MD5 checksum of a one-hour file, here we can at least know which minute is wrong in case of a problem. If I have three copies I can go to one of the two other copies and just change the faulty minute.

Peter Bubestinger: It is very convenient to only have to replace a one minute file; especially if you have narrow-bandwidth, which is the case in this bunker in the mountain. That is one of the reasons why we chose this segmentation. We shift certain problems that are very tricky, especially with very large video files. The only effort we're adding is that you have to glue it back together.

Herman Lewetz: Which showed to be much easier than we expected. We just take the whole folder of a recording and put it into VLC and it plays. It ignores the metadata files and the thumbnails, etc. and only plays the video files. In VirtualDub it is also easy and it behaves just like if it was one file.

 

PACKED: So the playback software you're using are VirtualDub and VLC?

Peter Bubestinger: For the software with a GUI33 yes, otherwise, in the back end it is almost completely FFmpeg34 or FFmpeg-based applications for transcoding the files, etc. For audio files I also sometimes use SoX, which is basically for audio what FFmpeg is for video.

 

PACKED: What are the audio formats that you digitise?

Herman Lewetz: DAT, MiniDiscs, 78s, wax cylinders, tapes with all kinds of speeds and audiocassettes.

 

Storage shelves for audio cassettes at the Austrian Mediathek. Photo: PACKED vzw.

 

PACKED: Do you use the same quality requirements for all the formats?

Herman Lewetz: We use the same except for CDs and DAT because they come with their original audio sampling frequency.

Peter Bubestinger: There is also the third ingest line at the Austrian Mediathek: the digital born material on optical carriers such as CDs, DVDs and Blu-rays. For audio CDs we use a system built by NOA, but for video we use a tool called DVDisaster35 which was actually intended for error corrections when handling and ripping problematic burned CDs or DVDs. DVDisaster can handle any optical media and just creates an ISO or UDF image. You can set how it should behave in case of read errors, such as telling the software to re-read the sector or retry. It also gives documentation about found errors, so you also get metadata from this program. We keep the image and then we re-multiplex for DVD for example to an MPEG-2. So we don't lose anything.

 

PACKED: What quality requirements do you use for audio digitisation?

Peter Bubestinger: Ingest is 96 kHz/32 bits float and then it is stored as 96 kHz/24-bits archive Broadcast Wave files.

 

PACKED: Is there a supplementary feature you would like FFV1 to have?

Peter Bubestinger: I personally would love to see collaborations between archiving institutions. We did this for ourselves because we needed something that works, now imagine what would be possible if just a handful of institutions would join their resources, be it time, knowhow and expertise, because money is always a problem. We have a complete lossless workflow from ingest to archive and back on a level from properties that could be compared to what the BBC has from the features36. Except for timecode we cover all the use cases they have.

With open source it is not a problem to get application support, because you can make it happen. If you can't do it yourself then you can pay someone to do it and it only costs you a fraction of begging a proprietary vendor and then have it implemented in their way where you don't know if they make it interoperable. If they used the existing implementation of FFV1 that everybody is allowed to use, it would be good, but it could be that they don't use the open implementation because they might be afraid of having to open some parts of their components and code.

Herman Lewetz: One of the main advantages of FFV1 is that the vendors haven’t adapted it yet. The actual situation is that there is only one public implementation that is open and accessible.

Peter Bubestinger: FFV1 is not officially standardised, but as an IT guy I don't really mind. From a sustainability point of view, the one reference implementation that is being used is open and I can archive its source code and its repository back to the day zero of the existence of the codec. I don't know what could prevent us from accessing this codec even in a very unknown future with aliens and mind benders. The worst-case scenario would be that we have to migrate to another format, which is something we will have to do in the future anyway. I don't see anything that would prevent us from doing so. On the other hand it would not be the case if one of the chains in the workflow was closed or proprietary.

An open standard on paper with a proprietary closed implementation poses more practical challenges up to the point that I cannot do it without losses of information, be it metadata especially. When I think of all the money and resources that are put into making MXF and Jpeg2000 work in the unknown future, why not invest our time and resources in something that works?

 

PACKED: What is the legal situation of AVI?

Peter Bubestinger: AVI is in a questionable legal grey zone just because it is unknown whether Microsoft will or will not impose any restrictions on this format in the future. Even if we have to get rid of AVI it is probably the least problem compared to the challenges of all of the containers, because it has been around the block forever and it is cross-platform. We thought it through, and if anybody knows something we haven't looked at, please tell us.

 

PACKED: Are you aware of any legal issue with FFV1?

Peter Bubestinger:  From what I know it is based on a very simple mathematical work from the 1960s intelligently applied to video compression. Even if something was found we could switch to something else. You can compile FFmpeg differently for different legal situations; non-free full-free, etc. Then it removes some codecs or some parts of the code depending on the license. For vendors, license is a major issue, but for archives it is not at all, actually. The worst thing that could happen is that there is a claim for patent. Then it could be a local patent or an international patent.

The only problem with FFV1 is that some people are afraid to use it because it is not endorsed by big institutions. Although it is faster and as efficient as JPEG2000 in terms of size, this leads to people being skeptical about using it. I ran all the tests and I can personally judge a bit stream by its technical properties, but I think that there are a lot of people out there that just don't have the luck or the time to be able to do this. In the end, I think more and more people will be using FFV1 just because it works - apart from the small proprietary island. I think that a huge breakthrough will happen when Final Cut Pro will start supporting FFV1.

Herman Lewetz: That would be great. We don't have direct problems with FFV1, but some people are asking for recordings to edit them in Final Cut or other editing software.

Peter Bubestinger: For instance the Apple Pro-Res format is not that much smaller than FFV1, but you can open it in Final Cut.

 

PACKED: Austrian Mediathek is setting a sort of standard on how to set up an environment as open source as possible to preserve audiovisual material for the long-term. Do institutions that are interested in pursuing a similar way and use FFV1 contact you?

Peter Bubestinger: We never intended to be the support facility for FFV1 and there is no need for us to have people come here, but it is very easy to show them how we do it and how they can do it themselves. All the tools you need are accessible for anyone. Anyone can use exactly the same tools. For me it has to be open source, because we are dealing with public money, and it must have the most beneficial use for other public institutions. If a lab or company wants to offer FFV1 encoding, they can capture in uncompressed and then transcode to the final format anyway.

You can also choose another container but the only thing is that if the customer demands MXF it is not possible because there is no specification for FFV1 in MXF. Again, adding FFV1 to the specified list of codecs usable with MXF and how to layer it in that container should be solvable too. It should be a matter of weeks to make that MXF could wrap FFV1, it is very doable and doesn't require a lot of efforts. But again if no one asks for it, it won't happen.

Herman Lewetz: If you need a new feature in a proprietary tool, you first have to pay the company and then they do it their own way and you’re not able to see what they exactly do and if it is accurate. You're not sure that they will do it and you're not sure how they will do it.

Peter Bubestinger: What led us to test all the A/D converters in the first place was the firmware bug that we found in the first one we had. We contacted the vendors and they said "we don't have time". When they had time, nine months later, we had developed a system to find out where the bug was and how to test it when they would fix it to see if it was fixed. This is why I made the DVA-Fidelity system, because we thought we would need to see if it is fixed when they say it is. At the end they said: “We won't fix it because it is not a bug it is a feature. It is for HD and all of our customers are dealing with HD and they don't see it. We won't fix it and you should deal with it.”

That's why we want our workflow open and not because we want it cheap. It is so depressing to know that you could fix or improve a piece of your workflow, but that you can't do it because it is a blackbox. It was so incredibly cheap to modify FFV1 for multi-threading that it embarrasses me to tell you how much it cost us.

Herman Lewetz: The other advantage is that with FFV1 version 3, we have gained features such as CRC checksum or support for 14-bit RGB, for which others have paid.

Peter Bubestinger: There is an incredible potential for open tools. If institutions would invest in it, they could have any bugs fixed or missing features added. You could for instance get an A/D that only does conversion without making it look fancier or nicer, but just as accurately as possible. An A/D converter where the schematics would be available and with an open firmware so that the institutions could adapt it for their needs with a fraction of the money that they spend to have equipment that is actually not designed to do the work that they're trying to do.

There is often an argument that if Michael Niedemayer disappears, then there will be no one anymore to sustain FFV1. But the knowledge is here for anybody to get. It seems that it is viewed as unbearable, but when I see the number of plane tickets and rooms that are booked to attend meetings just to discuss what could be done, I'm thinking that these costs are probably way higher than what would be needed to develop certain solutions. As a developer, I find it very mysterious: it seems to me like a funny game that I don't understand.

Herman Lewetz: DVA-Profession is a very good example. We took the budget needed to buy a Samma Solo and used it to have DVA-Profession developed.

Peter Bubestinger: As long as there will be vendors with their own commercial interest in the consortiums that specify the standards and formats, you will end up with proprietary extensions. People know this and it is no secret.

 

 

Notes:

 

  • 1. See: http://www.mediathek.at/
  • 2. See: http://www.noa-audio.com/
  • 3. See: http://en.wikipedia.org/wiki/FFV1. See also see 'A short guide to choosing a digital format for video archiving masters': http://scart.be/?q=en/content/short-guide-choosing-digital-format-video-...
  • 4. See the interview with René Paquet from the Library and Archives of Canada for more information about the Samma Solo system: http://scart.be/?q=en/content/interview-ren%C3%A9-paquet-lac. See also the website of Front Porch Digital: http://www.fpdigital.com/solutions/samma/sammasolo
  • 5. See: http://iasa-web.org/
  • 6. See: https://www.prestocentre.org/
  • 7. For more information about the MXF/JPEG2000 format see 'A short guide to choosing a digital format for video archiving masters': http://scart.be/?q=en/content/short-guide-choosing-digital-format-video-...
  • 8. See: http://en.wikipedia.org/wiki/YUV
  • 9. See: http://www.morgan-multimedia.com/morgan/php/products.php?sProductId=4
  • 10. A framemd5-procedure is used with audiovisual data to produce one checksum per frame.
  • 11. Chroma subsampling is the practice of encoding images by implementing less resolution for chroma information than for luma information, taking advantage of the human visual system's lower acuity for color differences than for luminance. It is used in many video encoding schemes — both analog and digital — and also in JPEG encoding. Source: Wikipedia.
  • 12. See: http://www.phonogrammarchiv.at/wwwnew/index_e.htm
  • 13. Huffyuv (or HuffYUV) is a lossless video codec. See: http://en.wikipedia.org/wiki/Huffyuv
  • 14. The Pentium II brand refers to Intel's sixth-generation microarchitecture ("P6") and x86-compatible microprocessors introduced on May 7, 1997. Source: Wikipedia.
  • 15. Dirac is an advanced royalty-free video compression format designed for a wide range of uses, from delivering low-resolution web content to broadcasting HD and beyond, to near-lossless studio editing. Source:  Wikipedia: Dirac (video compression format)
  • 16. H.264 or MPEG-4 Part 10, Advanced Video Coding (MPEG-4 AVC) is a video compression format that is currently one of the most commonly used formats for the recording, compression, and distribution of video content. Source: Wikipedia.
  • 17. To find out more about these containers, please read the article on the Scart website 'A short guide to choosing a digital format for video archiving masters': http://scart.be/?q=en/content/short-guide-choosing-digital-format-video-...
  • 18. Variable bitrate (VBR) is a term used in telecommunications and computing that relates to the bitrate used in sound or video encoding. As opposed to constant bitrate (CBR), VBR files vary the amount of output data per time segment. Source: Wikipedia.
  • 19. See: http://vancouver.ca/your-government/city-of-vancouver-archives.aspx
  • 20. Git is a distributed revision control system with an emphasis on speed, data integrity, and support for distributed, non-linear workflows. Source: Wikipedia.
  • 21. See: http://2010.iasa-web.org/
  • 22. See: http://dericed.com/
  • 23. See: http://www.cuny.tv/
  • 24. Multithreading is a widespread programming and execution model that allows multiple threads to exist within the context of a single process. These threads share the process's resources, but are able to execute independently. The threaded programming model provides developers with a useful abstraction of concurrent execution. Multithreading can also be applied to a single process to enable parallel execution on a multiprocessing system. Source: Wikipedia.
  • 25. Checksum and CRC are used to ensure that data has not been corrupted during transmission or encryption.
  • 26. Genlock (generator locking) is a common technique where the video output of one source, or a specific reference signal from a signal generator, is used to synchronize other television picture sources together. The aim in video applications is to ensure the coincidence of signals in time at a combining or switching point. When video instruments are synchronized in this way, they are said to be generator locked, or genlocked. Source: Wikipedia.
  • 27. See: http://www.dva-profession.mediathek.at/fidelity_analyzer/content.php@ind...
  • 28. ffdshow is a codec mainly used for decoding of video in the MPEG-4 ASP (e.g. encoded with DivX or Xvid) and H.264/MPEG-4 AVC video formats, but it supports numerous other video and audio formats as well. It is free software released under GNU General Public License 2.0, runs on Windows, and is implemented as a Video for Windows (VFW) codec and a DirectShow filter. Source: Wikipedia.
  • 29. See: http://www.dva-profession.mediathek.at/
  • 30. See: https://github.com/johmathe/Shotdetect
  • 31. See: http://www.virtualdub.org/
  • 32. In information technology, header refers to supplemental data placed at the beginning of a block of data being stored or transmitted. Source: Wikipedia.
  • 33. In computing, a graphical user interface (GUI, sometimes pronounced "gooey" or "gee-you-eye") is a type of interface that allows users to interact with electronic devices through graphical icons and visual indicators such as secondary notation, as opposed to text-based interfaces, typed command labels or text navigation. Source: Wikipedia.
  • 34. FFmpeg is a free software project that produces libraries and programs for handling multimedia data. FFmpeg includes libavcodec, an audio/video codec library used by several other projects, libavformat, an audio/video container mux and demux library, and the ffmpeg command line program for transcoding multimedia files. FFmpeg is published under the GNU Lesser General Public License 2.1+ or GNU General Public License 2+ (depending on which options are enabled). Source: Wikipedia.
  • 35. See: http://dvdisaster.net/en/index.html
  • 36. Here, Peter Bubestinger refers to the Ingex Archive system developed by BBC Research, a suite of open source software for ingest in uncompressed UYVY 8-bit 4:2:2 video wrapped in OP-1a MXF. For more information, see: http://ingex.sourceforge.net/archive/.
logo vlaamse overheid