[MPlayer-cvslog] CVS: main/DOCS/tech mpcf.txt,1.67,1.68

[Michael Niedermayer]

Hi

On Friday 04 March 2005 18:13, Reimar Döffinger wrote:
> Hi,
>
> > there's also the idea we had while arguing with ivan and others, of
> > making a separate 'nut recovery' file that would contain all the
> > packet headers but not data, and that could be distributed to repair
> > corrupt files. if we made a spec for such a thing, it could also serve
> > as an external-index file and be stored alongside the nut file for
> > applications with slow-media..
>
> I don't know if that's connected... It all depends on the amount of
> data, but I was against included error correction as at least in my case
> all of the videos are on realiable media that already includes _a lot_
> of error correction, so it is just a waste of space (quite a few people
> seem to use that "audio mode" with less error correction to burn videos
> - now I would be more for removing any error resilience from the file
>   and instead use the better correction on the media, because that at
> least is processed in hardware).

well the overhead nut has is pretty small (<0.5%) which isnt all related to 
error resilience while error correction used on media is rather large (>10%) 
so u wont gain much spacewise from moving some error resilience away from nut
and they arent the same, nuts error resilience will not turn damaged data into 
undamaged, it will just allow you to view and seek to the undamaged parts, 
while error correction will turn damaged data into undamaged, this logically 
needs more overhead


another somewhat related question is what happens if a file is damaged and 
what are the consequences

if the user notices it immedeately (warning printed by player) he could just 
try to redownload it or get it from somewhere else

if the user is unable to play (a partially downloaded or damaged) file at all 
or unable to seek the user will avoid the fileformat, the same happens if the 
user was not aware of any damage but then cant view 50% of the file because 
of a few damaged bytes in the middle

so with tar.gz or similar general propose containers theres little use for 
recovering from errors, as the user notices it immedeately when he tries to 
do anything with the file but for a multimedia container format its likely 
that the user will not know about the damage before he plays the file which 
could be long after he downloaded it


so we should IMHO
* require players to warn the user about detected damages (players not doing 
this would not be compliant to the nut spec)
* provide a small and easy to use tool (under bsd license) to check if a nut 
file is undamaged as far as this is quickly checkable


maybe we should just drop the index mess and return to a single index at the 
end, it would be so much simpler for the muxer and demuxer and damage to the 
index could be detected very quickly while still allowing (slow) seeking in 
damaged files
rich whats your oppinion about that?

[...]
-- 
Michael

"nothing is evil in the beginning. Even Sauron was not so." -- Elrond