up-to-date lossless codec comparison?

[Peter B.]

Hi,

As soon as our digital-video-archive prototype is ready for production
use, I'm going to re-evaluate and benchmark the following lossless codecs:

- FFv1 (v1.2 / multithreading)
- JPEG2000
- Dirac (libdirac)
- Dirac (libschroedinger)
- x264
- Snow
- Huffyuv

Does anyone of you have suggestions about what I should keep in mind /
should not forget / etc?

Thanks,
Pb
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Dave Rice]

I'd recommend considering application of the codecs for video streams >8 bit as well as various colorspaces or chroma subsampling uses. For instance though one format may demonstrate advantages for YUV 4:2:0 at 8 bit, that format may offer no support for 10 bit YUV 4:2:2 or 8 bit RGBA material, so consideration of lossless codecs for particular application depends a lot on the source material that the user wishes to compress losslessly.
I'd also recommend publishing the full output of each test to facilitate later analysis or recreation of the tests.
Dave Rice

On Jan 5, 2011, at 6:55 AM, Peter B. wrote:

> Hi,
>
> As soon as our digital-video-archive prototype is ready for production
> use, I'm going to re-evaluate and benchmark the following lossless codecs:
>
> - FFv1 (v1.2 / multithreading)
> - JPEG2000
> - Dirac (libdirac)
> - Dirac (libschroedinger)
> - x264
> - Snow
> - Huffyuv
>
> Does anyone of you have suggestions about what I should keep in mind /
> should not forget / etc?
>
> Thanks,
> Pb
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Phil Rhodes]

> - FFv1 (v1.2 / multithreading)
> - JPEG2000
> - Dirac (libdirac)
> - Dirac (libschroedinger)
> - x264
> - Snow
> - Huffyuv

Are they all capable of lossless work?

If you really want to store it absolutely losslessly, there is probably no  
more universal solution than sequences of DPX still images which are  
ubiquitous in the industry. From an archivist's point of view, the format  
is fairly simple such that the files are likely to remain highly  
recoverable in future. It supports a wide range of pixel formats, so that  
material could be stored in its native format (RGB, YUV, 10-bit, 8-bit,  
16-bit, monochrome modes, etc etc). The official spec (ANSI/SMPTE  
268M-1994) is very cheap (or effectively free, since open source  
implementations abound) and as I understand it there is very little risk  
of legal problems arising from patents.

That said, playing back uncompressed DPX sequences at anything above  
standard definition currently requires reasonably upscale hardware.

I can't recommend FFv1, Dirac, Snow or even HuffYUV as archival formats -  
they're just too esoteric, and I don't think it's a good idea to start  
using them for archive now in the hope that they'll become less esoteric.  
My understanding is that both Dirac and Snow are effectively laboratory  
experiments at this point and they are not widely supported.

It really depends what you see this archive being used for. Can you give  
us any more background?

Regards,

Phil
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Peter B.]

Dave Rice wrote:
> I'd recommend considering application of the codecs for video streams >8 bit as well as various colorspaces or chroma subsampling uses.
Thanks for the reminder! :)

I'm definitely going to consider and test those properties, too.
Especially, because when we first evaluated Huffyuv for capturing, its
limitations regarding the choice of subsampling, colorspace, etc. forced
us to look for a more suitable codec.

I'm also going to do HD-resolutions too.
I've figured that many (mostly outdated) comparisons didn't bother to
test beyond SD.

Regarding >8bit:
Is it true, that you've found problems with FFv1 when using 10bit depth?

> I'd also recommend publishing the full output of each test to facilitate later analysis or recreation of the tests.
>  
Definitely.
I'm going to do as much of them on the commandline and wrap a script
around it, as well as post the exact versions of tools I've used (e.g.
SVN revision).

There will also be frame-by-frame integrity checks, just to make sure
that there are no silent implementation errors.
I've had that once: mencoder did not 100% losslessly transcode
interlaced Huffyuv material in a certain version.


Pb

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Dave Rice]

On Jan 5, 2011, at 10:39 AM, Peter B. wrote:
> Regarding >8bit:
> Is it true, that you've found problems with FFv1 when using 10bit depth?

No, I didn't mean to infer there were problems with FFV1 compression of 10 bit YUV 4:2:2 (yuv422p16le). In fact I think ffv1 is only of the only options with >8 in ffmpeg. Though one issue I've found is that although ffmpeg can losslessly decode yuv422p16le ffv1 I can't get VLC, mPlayer, or ffplay to play it back. For instance in myplayer I get [ffv1 @ 0x1007a9f60]colorspace not supported, thus for now to play back yuv422p16le ffv1 I have to decode it to another codec (v210) for playback.

>> I'd also recommend publishing the full output of each test to facilitate later analysis or recreation of the tests.
>>
> Definitely.
> I'm going to do as much of them on the commandline and wrap a script
> around it, as well as post the exact versions of tools I've used (e.g.
> SVN revision).
>
> There will also be frame-by-frame integrity checks, just to make sure
> that there are no silent implementation errors.
> I've had that once: mencoder did not 100% losslessly transcode
> interlaced Huffyuv material in a certain version.

Great. Running a -f framemd5 on the input and output would help.
dave

>
> Pb
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[compn]

Dave Rice <dave <at> avpreserve.com> writes:
> On Jan 5, 2011, at 10:39 AM, Peter B. wrote:
> > Regarding >8bit:
> > Is it true, that you've found problems with FFv1 when using 10bit depth?
>
> No, I didn't mean to infer there were problems with FFV1 compression of 10
bit YUV 4:2:2 (yuv422p16le). In
> fact I think ffv1 is only of the only options with >8 in ffmpeg. Though one
issue I've found is that although
> ffmpeg can losslessly decode yuv422p16le ffv1 I can't get VLC, mPlayer, or
ffplay to play it back. For
> instance in myplayer I get [ffv1 @ 0x1007a9f60]colorspace not supported, thus
for now to play back
> yuv422p16le ffv1 I have to decode it to another codec (v210) for playback.

could you upload a small sample file that works in ffmpeg/ffplay but not svn
mplayer? (hope that wasnt ffv1_sample.mov ?? if yes, it was rm'd to make space
doh!)

that message looks like a lavc error, so it would be nice to make sure you are
using svn mplayer.

if it is an mplayer problem, it could be as simple as adding the colorspace to
codecs.conf or fmt-conversion.c .

-compn

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Dave Rice]

On Jan 5, 2011, at 3:40 PM, compn wrote:

> Dave Rice <dave <at> avpreserve.com> writes:
>> On Jan 5, 2011, at 10:39 AM, Peter B. wrote:
>>> Regarding >8bit:
>>> Is it true, that you've found problems with FFv1 when using 10bit depth?
>>
>> No, I didn't mean to infer there were problems with FFV1 compression of 10
> bit YUV 4:2:2 (yuv422p16le). In
>> fact I think ffv1 is only of the only options with >8 in ffmpeg. Though one
> issue I've found is that although
>> ffmpeg can losslessly decode yuv422p16le ffv1 I can't get VLC, mPlayer, or
> ffplay to play it back. For
>> instance in myplayer I get [ffv1 @ 0x1007a9f60]colorspace not supported, thus
> for now to play back
>> yuv422p16le ffv1 I have to decode it to another codec (v210) for playback.
>
> could you upload a small sample file that works in ffmpeg/ffplay but not svn
> mplayer? (hope that wasnt ffv1_sample.mov ?? if yes, it was rm'd to make space
> doh!)

d'oh too. Perhaps the sample library could be dumped to archive.org occasionally to clear space.

> that message looks like a lavc error, so it would be nice to make sure you are
> using svn mplayer.
>
> if it is an mplayer problem, it could be as simple as adding the colorspace to
> codecs.conf or fmt-conversion.c .

A sample yuv422p16le ffv1 file is here
http://www.archive.org/details/test20100622_v210_and_ffv1
at
http://www.archive.org/download/test20100622_v210_and_ffv1/DHC36.ffv1.flac.mov
This should also the same 'ffv1 @ 0x1007a9f60]colorspace not supported'.

I wrote a ticket on this earlier at http://trac.videolan.org/vlc/ticket/3780 which may have been the wrong place.
Thanks,
Dave

> -compn
>
> _______________________________________________
> ffmpeg-user mailing list
> [hidden email]
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Peter B.]

Dave Rice wrote:
> Great. Running a -f framemd5 on the input and output would help
Thanks for the tip!
I remember that you've mentioned this built-in per-frame-checksum
calculation, but I couldn't find it anywhere in the documentation.

That's a really great feature for integrity checking.

Pb

PS: In order to spare someone else searching for the syntax, here's an
example of how to use the frame-md5 calculation:

ffmpeg -i video.avi -f framemd5 checksum_output.txt
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Thomas Worth-2]

> If you really want to store it absolutely losslessly, there is probably no
> more universal solution than sequences of DPX still images which are
> ubiquitous in the industry. From an archivist's point of view, the format is
> fairly simple such that the files are likely to remain highly recoverable in
> future.

I tend to agree. As soon as the word "archival" enters the discussion,
the only 100% way to guarantee recovery 100 years from now is by using
uncompressed formats like DPX, or formats that account for each pixel
in a discrete fashion. The same holds true for hardware-compressed
devices like tape drives. We deal with this problem right now with
incompatibilities between codecs and operating systems. Fortunately,
uncompressed formats can be read by any graphics-capable device in the
known universe which is why we recommend them for post archival
purposes over formats like Apple ProRes, etc.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Peter B.]

Phil Rhodes wrote:
> Are they all capable of lossless work?
At least, they're all claiming to be. ;)
Some codecs are there for the sake of completeness (e.g. Huffyuv).
I didn't bother to put Lagarith on the list, since I've been told that
it's ill-designed and unreliable [1] (and it's Windows-only, which is
unusable in real production environments)

> If you really want to store it absolutely losslessly, there is
> probably no more universal solution than sequences of DPX still images
> [...]
I know...
Unfortunately, there's still a gap between "what would/should/could be"
and "what is currently feasible and practical in order to provide a
living archive".
(and affordable, of course)

A major factor is not only retrieval time from the archive (for
production usage), but also the running expenses of large storages.

> That said, playing back uncompressed DPX sequences at anything above
> standard definition currently requires reasonably upscale hardware.
Unfortunately, the limitations and challenges are independent of the
image format/codec used. ;)

We've done extensive tests with image sequences and audiofiles (because
that's what we wanted to use in the first place as our archive format) -
but we ran into a series of problems. Here are some of them:

*) implementation glitches with several video editing applications,
regarding the audio (yes, audio is often treated as a stepchild when
dealing with video)
*) file access (e.g. having more than 5000 files in a single folder
already starts to cause troubles for Windows clients)
*) performance: Even if using a lightweight image codec, regarding CPU
power, many transcoding processes turned out to be waaaaay slower,
because of the file handling overhead
*) codec support: Video editing applications only support a limited
number of image formats.

So, when dealing with image sequences and audiofiles, our personal
conclusion was to have some kind of transcoding entity, to request the
archive content from.

> I can't recommend FFv1, Dirac, Snow or even HuffYUV as archival
> formats - they're just too esoteric
What exactly do you mean by "esoteric"?
I know that they're not widespread, but neither is JPEG2000, which is
officially announced as *the* only current alternative to uncompressed
for archival purposes.

> My understanding is that both Dirac and Snow are effectively
> laboratory experiments at this point and they are not widely supported.
From what I've read about Snow, I tend to agree, but Dirac?

BBC didn't invent, implement and Dirac as a lab-experiment, but because
they needed a codec that didn't exist at that time. Especially DiracPro
was designed with broadcast production usage in mind [1]. They've even
got hardware devices for handling it [2].


Pb

== References:
[1] http://web.archiveorange.com/archive/v/yR2T4M7bwEF8UpzRy7PZ
[2] http://www.bbc.co.uk/rd/projects/dirac/diracpro.shtml
[3] http://www.bbc.co.uk/rd/projects/dirac/press.shtml

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Jason Garrett-Glaser-2]

> I can't recommend FFv1, Dirac, Snow or even HuffYUV as archival formats -
> they're just too esoteric, and I don't think it's a good idea to start using
> them for archive now in the hope that they'll become less esoteric. My
> understanding is that both Dirac and Snow are effectively laboratory
> experiments at this point and they are not widely supported.

Portable C code is not going to stop working in 20, 40, or 100 years.
Something encoded in a format with open source encoders and decoders
will be available for as long as computers exist as long as it's
packaged with source code.  Nobody cares about how "estoteric"
anything is: if a computer can run C code, it can decode anything.

Jason
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Phil Rhodes]

> Portable C code is not going to stop working in 20, 40, or 100 years.

Jason, I know that you are deeply committed to the idea that all of  
ffmpeg's codebase is highly portable, but I find it difficult to reach  
that conclusion myself when it is so difficult to make it compile on the  
world's most overwhelmingly popular operating system. Archival formats  
need to be very highly accessible and requiring that people use a  
unix-like OS, while it may appeal to your political views, does not  
satisfy that requirement. I know there are a lot of people in the world  
that have a deep-seated emotional need to promote that state of affairs  
but concepts such as the universal portability of C are, unfortunately,  
rather idealised.

This is not about open source activism, this is about creating something  
that does a job. A bunch of text files containing C code is not software  
anymore than a pile of bricks and lumber is a house.

P
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[compn]

Dave Rice <dave <at> avpreserve.com> writes:
> On Jan 5, 2011, at 3:40 PM, compn wrote:
> > Dave Rice <dave <at> avpreserve.com> writes:
> >> On Jan 5, 2011, at 10:39 AM, Peter B. wrote:
> A sample yuv422p16le ffv1 file is here
> http://www.archive.org/details/test20100622_v210_and_ffv1
> at
> http://www.archive.org/download/test20100622_v210_and_ffv1/DHC36.ffv1.flac.mov
> This should also the same 'ffv1 @ 0x1007a9f60]colorspace not supported'.

well carl fixed this in mplayer r32764
if your mplayer is new enough, you should be able to just add out 422P16 under
videocodec fffv1 in your codecs.conf.

note that the 'ffv1 @ 0x1007a9f60]colorspace not supported' means you are using
an old mplayer (or an old shared ffmpeg). and you need to update.

> I wrote a ticket on this earlier at http://trac.videolan.org/vlc/ticket/3780 
which may have been the
> wrong place.

well its the right place for videolan support. i'm sure its a similar easy fix
for them as well.

-compn

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Jason Garrett-Glaser-2]

On Thu, Jan 6, 2011 at 5:30 AM, Phil Rhodes <[hidden email]> wrote:
>
>> Portable C code is not going to stop working in 20, 40, or 100 years.
>
> Jason, I know that you are deeply committed to the idea that all of ffmpeg's
> codebase is highly portable, but I find it difficult to reach that
> conclusion myself when it is so difficult to make it compile on the world's
> most overwhelmingly popular operating system.

The world's most popular operating system is Linux.  There are more
computers running Linux than any other operating system; literally
billions worldwide.  One is probably sitting in your pocket right now.
 I don't think ffmpeg is very hard to compile on Linux.

> Archival formats need to be
> very highly accessible and requiring that people use a unix-like OS, while
> it may appeal to your political views, does not satisfy that requirement.

"Political"?  POSIX is the only widely-adopted operating system
environment standard.  There is no alternative with significant market
share.  Even Windows now supports POSIX.  What other standardized
environment do you suggest?

Also, acting as if ffmpeg doesn't run on Windows is not just
disingenuous, it's outright retarded.  The world's second most popular
media player is VLC, which runs on hundreds of millions of Windows
systems worldwide -- and uses ffmpeg.

> I know there are a lot of people in the world that have a deep-seated
> emotional need to promote that state of affairs but concepts such as the
> universal portability of C are, unfortunately, rather idealised.

You talk about "being around for 100 years" despite the fact that
Windows will almost certainly be replaced within a decade or two --
probably by Microsoft themselves.  An application written for POSIX in
1960 will run on any computer today, and it will run on any computer
in 2050, and it will run on any computer in 2100.  An application
written for Windows in 1995 won't even run on a Windows computer
today.

You're insane.  Don't shill for your stupid proprietary JPEG-2000
hardware manufacturers here; we aren't going to buy your bullshit.

Jason
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Phil Rhodes]

> The world's most popular operating system is Linux.  There are more
> computers running Linux than any other operating system; literally
> billions worldwide.  One is probably sitting in your pocket right now.

Right, Jason, and we should believe you because you think an Android  
handset is an ideal archival retrieval device?

I could go through paragraph by paragraph and refute the rest of it but  
I'm fully aware that you cannot be persuaded, and nobody with half an  
ounce of sense needs persuading, that this is a completely preposterous  
argument.

Nevertheless, I shall add "smartphone as postproduction workstation" to my  
list of highly amusing concepts proposed by practicality-challenged free  
software people.

P
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Corne Beerse]

On 7-1-2011 6:23, Phil Rhodes wrote:

>
>> The world's most popular operating system is Linux.  There are more
>> computers running Linux than any other operating system; literally
>> billions worldwide.  One is probably sitting in your pocket right now.
>
> Right, Jason, and we should believe you because you think an Android
> handset is an ideal archival retrieval device?
>
> I could go through paragraph by paragraph and refute the rest of it
> but I'm fully aware that you cannot be persuaded, and nobody with half
> an ounce of sense needs persuading, that this is a completely
> preposterous argument.
>
> Nevertheless, I shall add "smartphone as postproduction workstation"
> to my list of highly amusing concepts proposed by
> practicality-challenged free software people.

For data archive purposes, you'd never say anything about the
implementation of the applications. The only thing you want is the data
to be as independent as possible, as free as possible and as clear as
possible: The complete file specification should be free from any stuff
irrelevant to the data you are archiving. Hence, no encryption, no
patents, no security stuff, no obscurity stuff. On the compression side:
that should be documented as good as the archive format itself. However,
somewhere in the middle, the routines to extract the archive can be part
of the data specification.

CBee
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Phil Rhodes]

> For data archive purposes, you'd never say anything about the  
> implementation of the applications.

Precisely, which is why I suggested DPX or failing that something widely  
implemented.

I'm afraid all this talk about how easy it is to compile ffmpeg for your  
iThing is as irrelevant as it is inaccurate.

P
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Dave Bevan]

Hi.
 
In terms of lossless, independent archiving, here in the BBC our policy for high-end original BBC content is to use raw uncompressed YUV. It's obviously completely lossless, and doesn't involve any wrappers.
 
The only things you need to remember at the point of restoration in the future are your YUV packing format, frame size, frame rate and what, if any (in these modern days of HD ... bring back PAL I say!), interlacing was used.
 
If you're archiving off SDI or HD-SDI inputs (Bluefish444, BlackMagic, AJA, DVS etc), then save YUV frames directly off your capture hardware framebuffer.
 
If archiving files, and /long-life/ is your ultimate goal (it is of course, by use of the word "archive"), then "upres" from your file's compressed format to YUV, maintaining the same frame size, frame rate and interlacing strategy as the original file - that way you don't introduce any standards-conversion artifacts that may creep in due to non-optimal conversion software.
 
Yes, YUV is expensive in terms of disk / tape space, but it's selection as an archive format is driven by how much you value your archive - i.e. it's a business-led decision, not a technical one.
 
Rgds,
 
-- Dave.

 
________________________________

From: [hidden email] on behalf of Corne Beerse
Sent: Fri 07/01/2011 09:06
To: [hidden email]
Subject: Re: [FFmpeg-user] up-to-date lossless codec comparison?



On 7-1-2011 6:23, Phil Rhodes wrote:

>
>> The world's most popular operating system is Linux.  There are more
>> computers running Linux than any other operating system; literally
>> billions worldwide.  One is probably sitting in your pocket right now.
>
> Right, Jason, and we should believe you because you think an Android
> handset is an ideal archival retrieval device?
>
> I could go through paragraph by paragraph and refute the rest of it
> but I'm fully aware that you cannot be persuaded, and nobody with half
> an ounce of sense needs persuading, that this is a completely
> preposterous argument.
>
> Nevertheless, I shall add "smartphone as postproduction workstation"
> to my list of highly amusing concepts proposed by
> practicality-challenged free software people.

For data archive purposes, you'd never say anything about the
implementation of the applications. The only thing you want is the data
to be as independent as possible, as free as possible and as clear as
possible: The complete file specification should be free from any stuff
irrelevant to the data you are archiving. Hence, no encryption, no
patents, no security stuff, no obscurity stuff. On the compression side:
that should be documented as good as the archive format itself. However,
somewhere in the middle, the routines to extract the archive can be part
of the data specification.

CBee
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user



http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
                                       

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[compn]

Dave Bevan <dave.bevan <at> bbc.co.uk> writes:
> In terms of lossless, independent archiving, here in the BBC our policy
for high-end original BBC content
> is to use raw uncompressed YUV. It's obviously completely lossless, and
doesn't involve any wrappers.

no offense to you personally, but historically the bbc is terrible at archiving
things. remember: you can have a perfect copy of whatever show, but if you lose
the tape or tape over it, its gone forever.

-compn

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user

[Dave Bevan]

Ah....
 
Yes we did, back in the days when video tape was /really/ expensive, and most programmes we made and transmitted live. Many programmes didn't even have a tape recorder running over the studio out - it simply went directly to from our vision mixer to your TV!
 
All that has changed of course, and there has been a lot of investment in recent years in re-digitising old archive material. Read http://www.bbc.co.uk/blogs/bbcinternet/2010/08/safeguarding_the_bbcs_archive.html if you're really interested.
 
Rgds,
 
-- Dave.
 
________________________________

From: [hidden email] on behalf of compn
Sent: Fri 07/01/2011 11:44
To: [hidden email]
Subject: Re: [FFmpeg-user] up-to-date lossless codec comparison?



Dave Bevan <dave.bevan <at> bbc.co.uk> writes:
> In terms of lossless, independent archiving, here in the BBC our policy
for high-end original BBC content
> is to use raw uncompressed YUV. It's obviously completely lossless, and
doesn't involve any wrappers.

no offense to you personally, but historically the bbc is terrible at archiving
things. remember: you can have a perfect copy of whatever show, but if you lose
the tape or tape over it, its gone forever.

-compn

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user



http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
                                       

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-user