Ignore invalid MP3 packets from ffmpeg.
Per upstream, this is totally normal to happen and they won't accept changes to fix this without undertaking a large refactoring of the AVParser infrastructure: http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225800.html This behavior may also occur with ADTS streams, but is rarer in practice because ffmpeg's ADTS demuxer does more validation on the packets, so when invalid data is received, av_read_frame() fails and playback ends. Since we haven't had a rash of complaints about too-short ADTS streams, don't bother doing this for ADTS streams at this time. BUG=822341,794782 TEST=existing tests all still pass. Cq-Include-Trybots: luci.chromium.try:linux_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Change-Id: Iabcad145bb75f742e4ba7658ab95c377b811efa1 Reviewed-on: https://chromium-review.googlesource.com/965121 Commit-Queue: Dale Curtis <dalecurtis@chromium.org> Reviewed-by:Matthew Wolenetz <wolenetz@chromium.org> Cr-Commit-Position: refs/heads/master@{#544181}
Showing
Please register or sign in to comment