Hi, On Sun, Apr 29, 2012 at 10:33 AM, Derek Buitenhuis <derek.buitenh...@gmail.com> wrote: > From: Hendrik Leppkes <h.lepp...@gmail.com> > > This reverts commit 5dd514af937ff4d74c3c263e4ca428b14b62d5f1. > Silently ignoring errors allows some broken files to simply be played, > instead of failing. > > The intended goal (as confirmed with its author) of fixing a crash has been > fixed differently prior to the application of this patch and this patch does > notsucessfully propagate parse errors either. > > Signed-off-by: Michael Niedermayer <michae...@gmx.at> > --- > libavformat/matroskadec.c | 11 +++++------ > 1 file changed, 5 insertions(+), 6 deletions(-)
This should be under an error resilience flag. More importantly, although the goal of the Chrome developers may have been to fix a crash, that's not true for us. We simply applied it because it forwards an error, which is the correct thing to do. If you play a corrupt stream, do you want to see probably-corrupt frames, or try and see some (probably garbage) output? It's not hard to generate samples that show either way of the argument, the question is what makes sense in the wild. We decided error by default is the right thing to do. Adding a check for the error resilience flag is probably best. Ronald _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
