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? > but having the ability to remove or mark errors at the demuxer level is > attractive and useful. Flagging damaged packets seems like a good idea. Then they can be discarded (or not) at a central location. Perhaps the flag should also be set in response to the transport error flag in the TS header. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
