Message ID | CAPUDrwd+5KWWCB8f372e=-_rRPpHqb+E451RZDiU3rb3JipSAQ@mail.gmail.com |
---|---|
State | New |
Headers | show |
+John Rummell <jrummell@chromium.org> just noticed this patch never landed upstream. Can this be landed? - dale On Thu, Feb 28, 2019 at 1:58 PM Dale Curtis <dalecurtis@chromium.org> wrote: > Such errors may make sense for specific formats, but general parsing > logic shouldn't be treating these as errors regardless of the error > recognition mode. > > Fixes loading of the following wave when using -err_detect explode: > > https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/webaudio/resources/4ch-440.wav > > Signed-off-by: Dale Curtis <dalecurtis@chromium.org> > >
Dale Curtis: > +John Rummell <jrummell@chromium.org> just noticed this patch never landed > upstream. Can this be landed? > > - dale > > On Thu, Feb 28, 2019 at 1:58 PM Dale Curtis <dalecurtis@chromium.org> wrote: > >> Such errors may make sense for specific formats, but general parsing >> logic shouldn't be treating these as errors regardless of the error >> recognition mode. >> >> Fixes loading of the following wave when using -err_detect explode: >> >> https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/webaudio/resources/4ch-440.wav >> >> Signed-off-by: Dale Curtis <dalecurtis@chromium.org> >> I doubt that this patch still applies as-is because of e2307f4ff197646a7feee0edbcdd2d3262932676. - Andreas
On Fri, Feb 21, 2020 at 11:26 AM Andreas Rheinhardt < andreas.rheinhardt@gmail.com> wrote: > I doubt that this patch still applies as-is because of > e2307f4ff197646a7feee0edbcdd2d3262932676. > > Ah, good point. Rebased and attached. - dale
On Fri, Feb 21, 2020 at 12:54 PM Dale Curtis <dalecurtis@chromium.org> wrote: > On Fri, Feb 21, 2020 at 11:26 AM Andreas Rheinhardt < > andreas.rheinhardt@gmail.com> wrote: > >> I doubt that this patch still applies as-is because of >> e2307f4ff197646a7feee0edbcdd2d3262932676. >> >> > Ah, good point. Rebased and attached. > Whoops, attached the wrong file. - dale
On Fri, Feb 21, 2020 at 12:55:57PM -0800, Dale Curtis wrote: > On Fri, Feb 21, 2020 at 12:54 PM Dale Curtis <dalecurtis@chromium.org> > wrote: > > > On Fri, Feb 21, 2020 at 11:26 AM Andreas Rheinhardt < > > andreas.rheinhardt@gmail.com> wrote: > > > >> I doubt that this patch still applies as-is because of > >> e2307f4ff197646a7feee0edbcdd2d3262932676. > >> > >> > > Ah, good point. Rebased and attached. > > > > Whoops, attached the wrong file. > > - dale > utils.c | 9 +-------- > 1 file changed, 1 insertion(+), 8 deletions(-) > 422825273de6afebc105fcfa6f4f8020c285fa5a no_errors_on_id3_v3.patch > From f9f2b953a1e71e439a88581894715568987cba5c Mon Sep 17 00:00:00 2001 > From: Dale Curtis <dalecurtis@chromium.org> > Date: Fri, 21 Feb 2020 12:53:30 -0800 > Subject: [PATCH] Don't trigger errors for multiple id3 tags. > > Such errors may make sense for specific formats, but general parsing > logic shouldn't be treating these as errors regardless of the error > recognition mode. > > Fixes loading of the following wave when using -err_detect explode: > https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/webaudio/resources/4ch-440.wav will apply thx [...]
From 14c2244631e7d02d6f66a6d5a678125002b89675 Mon Sep 17 00:00:00 2001 From: Dale Curtis <dalecurtis@chromium.org> Date: Thu, 28 Feb 2019 13:51:30 -0800 Subject: [PATCH] Don't trigger errors for multiple id3 tags. Such errors may make sense for specific formats, but general parsing logic shouldn't be treating these as errors regardless of the error recognition mode. Fixes loading of the following wave when using -err_detect explode: https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/webaudio/resources/4ch-440.wav Signed-off-by: Dale Curtis <dalecurtis@chromium.org> --- libavformat/utils.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/libavformat/utils.c b/libavformat/utils.c index d113a16c80..b940246512 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -635,13 +635,8 @@ FF_ENABLE_DEPRECATION_WARNINGS s->metadata = s->internal->id3v2_meta; s->internal->id3v2_meta = NULL; } else if (s->internal->id3v2_meta) { - int level = AV_LOG_WARNING; - if (s->error_recognition & AV_EF_COMPLIANT) - level = AV_LOG_ERROR; - av_log(s, level, "Discarding ID3 tags because more suitable tags were found.\n"); + av_log(s, AV_LOG_WARNING, "Discarding ID3 tags because more suitable tags were found.\n"); av_dict_free(&s->internal->id3v2_meta); - if (s->error_recognition & AV_EF_EXPLODE) - return AVERROR_INVALIDDATA; } if (id3v2_extra_meta) { -- 2.21.0.352.gf09ad66450-goog
Such errors may make sense for specific formats, but general parsing logic shouldn't be treating these as errors regardless of the error recognition mode. Fixes loading of the following wave when using -err_detect explode: https://cs.chromium.org/chromium/src/third_party/blink/web_tests/external/wpt/webaudio/resources/4ch-440.wav Signed-off-by: Dale Curtis <dalecurtis@chromium.org>