On Sun, Jun 26, 2011 at 16:28, aviad rozenhek <[email protected]> wrote:
> 2011/6/26 Måns Rullgård <[email protected]> > >> aviad rozenhek <[email protected]> writes: >> >> > On Sun, Jun 26, 2011 at 04:14, Luca Barbato <[email protected]> wrote: >> > >> >> On 6/25/11 4:26 AM, Gil Pedersen wrote: >> >> >> >>> On 25/06/2011, at 01.39, Luca Barbato wrote: >> >>> >> >>> On 6/24/11 10:00 AM, Måns Rullgård wrote: >> >>>> >> >>>>> That would depend on the decoder. >> >>>>> >> >>>> >> >>>> Indeed. in the cases I had reports for (the patch had been in my >> github >> >>>> for a while) h264 was the only codec considered. >> >>>> >> >>> >> >>> If I can propose a solution, I think you should add a new flag to >> AVPacket >> >>> called something like AV_PKT_FLAG_CORRUPT and signal this on packets >> with >> >>> continuity errors. >> >>> >> >>> Then it will be up to the decoder to decide whether it can make sense >> of >> >>> packets containing corrupted data. >> >>> >> >> >> >> might make sense, still I'd rather have the user have the possibility >> to >> >> override the default behaviour. >> >> >> >> lu >> >> >> >> >> >> >> > I have a few samples where the decoder crashes when trying to decode the >> > corrupted data. >> > true, that the decoder _should_ be robust against such errors. >> >> And it should be fixed. Care to share those samples? >> >> > they are between 20mb - 120mb each and about 1-2 min long. > if its possible i'd like to upload them without cutting them first because > its hard to tell which byte caused the crash. > the bug report section clealrly limits size to 10mb which is a problem. > > > seems that both upload.ffmpeg.org and upload.libav.org are inaccessible ... ? -- Aviad Rozenhek
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
