[FFmpeg-devel] [PATCH] Use AVOnce as a static variable consistently
Using AVOnce as a stack variable makes no sense as the state is lost
when the function exists.
This fixes repeated calls to av(filter/device)_register_all
---
libavdevice/alldevices.c | 2 +-
libavfilter/allfilters.c | 2 +-
libavformat/allformats.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
index 280a260bd3..a8ed53ae5d 100644
--- a/libavdevice/alldevices.c
+++ b/libavdevice/alldevices.c
@@ -73,7 +73,7 @@ static void register_all(void)
void avdevice_register_all(void)
{
-AVOnce control = AV_ONCE_INIT;
+static AVOnce control = AV_ONCE_INIT;
ff_thread_once(&control, register_all);
}
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 2bcfce77be..f8cd193dbe 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -390,7 +390,7 @@ static void register_all(void)
void avfilter_register_all(void)
{
-AVOnce control = AV_ONCE_INIT;
+static AVOnce control = AV_ONCE_INIT;
ff_thread_once(&control, register_all);
}
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 62661d14a4..b3ffe0f2b6 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -385,7 +385,7 @@ static void register_all(void)
void av_register_all(void)
{
-AVOnce control = AV_ONCE_INIT;
+static AVOnce control = AV_ONCE_INIT;
ff_thread_once(&control, register_all);
}
--
2.12.2.windows.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Use AVOnce as a static variable consistently
On Mon, 22 May 2017 12:06:19 +0200
Hendrik Leppkes wrote:
> Using AVOnce as a stack variable makes no sense as the state is lost
> when the function exists.
>
> This fixes repeated calls to av(filter/device)_register_all
> ---
> libavdevice/alldevices.c | 2 +-
> libavfilter/allfilters.c | 2 +-
> libavformat/allformats.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
> index 280a260bd3..a8ed53ae5d 100644
> --- a/libavdevice/alldevices.c
> +++ b/libavdevice/alldevices.c
> @@ -73,7 +73,7 @@ static void register_all(void)
>
> void avdevice_register_all(void)
> {
> -AVOnce control = AV_ONCE_INIT;
> +static AVOnce control = AV_ONCE_INIT;
>
> ff_thread_once(&control, register_all);
> }
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 2bcfce77be..f8cd193dbe 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -390,7 +390,7 @@ static void register_all(void)
>
> void avfilter_register_all(void)
> {
> -AVOnce control = AV_ONCE_INIT;
> +static AVOnce control = AV_ONCE_INIT;
>
> ff_thread_once(&control, register_all);
> }
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 62661d14a4..b3ffe0f2b6 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -385,7 +385,7 @@ static void register_all(void)
>
> void av_register_all(void)
> {
> -AVOnce control = AV_ONCE_INIT;
> +static AVOnce control = AV_ONCE_INIT;
>
> ff_thread_once(&control, register_all);
> }
That's a somewhat huge oversight. The fix looks correct, please push.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Use AVOnce as a static variable consistently
On Mon, May 22, 2017 at 12:25 PM, wm4 wrote:
> On Mon, 22 May 2017 12:06:19 +0200
> Hendrik Leppkes wrote:
>
>> Using AVOnce as a stack variable makes no sense as the state is lost
>> when the function exists.
>>
>> This fixes repeated calls to av(filter/device)_register_all
>> ---
>> libavdevice/alldevices.c | 2 +-
>> libavfilter/allfilters.c | 2 +-
>> libavformat/allformats.c | 2 +-
>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
>> index 280a260bd3..a8ed53ae5d 100644
>> --- a/libavdevice/alldevices.c
>> +++ b/libavdevice/alldevices.c
>> @@ -73,7 +73,7 @@ static void register_all(void)
>>
>> void avdevice_register_all(void)
>> {
>> -AVOnce control = AV_ONCE_INIT;
>> +static AVOnce control = AV_ONCE_INIT;
>>
>> ff_thread_once(&control, register_all);
>> }
>> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
>> index 2bcfce77be..f8cd193dbe 100644
>> --- a/libavfilter/allfilters.c
>> +++ b/libavfilter/allfilters.c
>> @@ -390,7 +390,7 @@ static void register_all(void)
>>
>> void avfilter_register_all(void)
>> {
>> -AVOnce control = AV_ONCE_INIT;
>> +static AVOnce control = AV_ONCE_INIT;
>>
>> ff_thread_once(&control, register_all);
>> }
>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
>> index 62661d14a4..b3ffe0f2b6 100644
>> --- a/libavformat/allformats.c
>> +++ b/libavformat/allformats.c
>> @@ -385,7 +385,7 @@ static void register_all(void)
>>
>> void av_register_all(void)
>> {
>> -AVOnce control = AV_ONCE_INIT;
>> +static AVOnce control = AV_ONCE_INIT;
>>
>> ff_thread_once(&control, register_all);
>> }
>
> That's a somewhat huge oversight. The fix looks correct, please push.
Pushed and backported to 3.3 (3.2 did not have this yet).
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]libavformat/http: fix http error eof
2017-05-18 15:19 GMT+08:00 raymond zheng : > Hi: > I find an issue about http. I don't use chunked, so s->chunksize will > be set as UINT64_MAX when http open, but because of "if (s->chunksize > 0) > s->chunksize -= len;" then chunksize will not be UINT64_MAX. > > If ffurl_read return to 0, s->off < target_end, http_buf_read will > return to 0, then this will lead to eof, so this is incorrect, and > http_buf_read should return to AVERROR(EIO). > if connect to CDN http edge server, this maybe incorrect. or need a timeout event to disconnect the link. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Use AVOnce as a static variable consistently
2017-05-22 18:06 GMT+08:00 Hendrik Leppkes :
> Using AVOnce as a stack variable makes no sense as the state is lost
> when the function exists.
>
> This fixes repeated calls to av(filter/device)_register_all
> ---
> libavdevice/alldevices.c | 2 +-
> libavfilter/allfilters.c | 2 +-
> libavformat/allformats.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
> index 280a260bd3..a8ed53ae5d 100644
> --- a/libavdevice/alldevices.c
> +++ b/libavdevice/alldevices.c
> @@ -73,7 +73,7 @@ static void register_all(void)
>
> void avdevice_register_all(void)
> {
> -AVOnce control = AV_ONCE_INIT;
> +static AVOnce control = AV_ONCE_INIT;
>
> ff_thread_once(&control, register_all);
> }
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 2bcfce77be..f8cd193dbe 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -390,7 +390,7 @@ static void register_all(void)
>
> void avfilter_register_all(void)
> {
> -AVOnce control = AV_ONCE_INIT;
> +static AVOnce control = AV_ONCE_INIT;
>
> ff_thread_once(&control, register_all);
> }
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 62661d14a4..b3ffe0f2b6 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -385,7 +385,7 @@ static void register_all(void)
>
> void av_register_all(void)
> {
> -AVOnce control = AV_ONCE_INIT;
> +static AVOnce control = AV_ONCE_INIT;
>
> ff_thread_once(&control, register_all);
> }
> --
> 2.12.2.windows.2
>
LGTM
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]libavformat/http: fix http error eof
I don't think it need a timeout event to disconnect the link, because when ffurl_read return to 0, it means the link disconnect. If s->off < target_end, it means AVERROR, otherwise, it's normal eof. I don't use chunked in HTTP, so s->chunksize should be initial value, and shouldn't be changed or even decreased. 2017-05-22 18:51 GMT+08:00 Steven Liu : > 2017-05-18 15:19 GMT+08:00 raymond zheng : > > > Hi: > > I find an issue about http. I don't use chunked, so s->chunksize will > > be set as UINT64_MAX when http open, but because of "if (s->chunksize > > 0) > > s->chunksize -= len;" then chunksize will not be UINT64_MAX. > > > > If ffurl_read return to 0, s->off < target_end, http_buf_read will > > return to 0, then this will lead to eof, so this is incorrect, and > > http_buf_read should return to AVERROR(EIO). > > > > if connect to CDN http edge server, this maybe incorrect. or need a > timeout event to disconnect the link. > > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/concatdec: do not transfer custom IO flag
From: Clément Bœsch If the source is using a custom IO, setting this flag causes heavy leaks since the segments will not have their avio context closed. Regression since f5da453b068f55d335ca403d2e2b4dd2ac3d4331. --- libavformat/concatdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c index 73f8a63a2b..e57e5ce0ec 100644 --- a/libavformat/concatdec.c +++ b/libavformat/concatdec.c @@ -324,7 +324,7 @@ static int open_file(AVFormatContext *avf, unsigned fileno) if (!cat->avf) return AVERROR(ENOMEM); -cat->avf->flags |= avf->flags; +cat->avf->flags |= avf->flags & ~AVFMT_FLAG_CUSTOM_IO; cat->avf->interrupt_callback = avf->interrupt_callback; if ((ret = ff_copy_whiteblacklists(cat->avf, avf)) < 0) -- 2.13.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]libavformat/http: fix http error eof
2017-05-22 22:36 GMT+08:00 raymond zheng : > I don't think it need a timeout event to disconnect the link, because > when ffurl_read > return to 0, it means the link disconnect. If s->off < target_end, it > means AVERROR, > otherwise, it's normal eof. > I don't use chunked in HTTP, so s->chunksize should be initial value, and > shouldn't be changed or even decreased. > > What will happen if not apply this patch? can you reproduce the bug step by step. > 2017-05-22 18:51 GMT+08:00 Steven Liu : > > > 2017-05-18 15:19 GMT+08:00 raymond zheng : > > > > > Hi: > > > I find an issue about http. I don't use chunked, so s->chunksize > will > > > be set as UINT64_MAX when http open, but because of "if (s->chunksize > > > 0) > > > s->chunksize -= len;" then chunksize will not be UINT64_MAX. > > > > > > If ffurl_read return to 0, s->off < target_end, http_buf_read will > > > return to 0, then this will lead to eof, so this is incorrect, and > > > http_buf_read should return to AVERROR(EIO). > > > > > > > if connect to CDN http edge server, this maybe incorrect. or need a > > timeout event to disconnect the link. > > > > > > > > ___ > > > ffmpeg-devel mailing list > > > ffmpeg-devel@ffmpeg.org > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/concatdec: do not transfer custom IO flag
On Mon, 22 May 2017 16:54:31 +0200 Clément Bœsch wrote: > From: Clément Bœsch > > If the source is using a custom IO, setting this flag causes heavy leaks > since the segments will not have their avio context closed. > > Regression since f5da453b068f55d335ca403d2e2b4dd2ac3d4331. > --- > libavformat/concatdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c > index 73f8a63a2b..e57e5ce0ec 100644 > --- a/libavformat/concatdec.c > +++ b/libavformat/concatdec.c > @@ -324,7 +324,7 @@ static int open_file(AVFormatContext *avf, unsigned > fileno) > if (!cat->avf) > return AVERROR(ENOMEM); > > -cat->avf->flags |= avf->flags; > +cat->avf->flags |= avf->flags & ~AVFMT_FLAG_CUSTOM_IO; > cat->avf->interrupt_callback = avf->interrupt_callback; > > if ((ret = ff_copy_whiteblacklists(cat->avf, avf)) < 0) Yeah, that would be unintended. The intention was to pass down the flag to disable side data packet merging. HLS had the same change and should probably be fixed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/mlpdec: Check quant_step_size against huff_lsbs
On Sun, May 21, 2017 at 01:42:18PM +0200, wm4 wrote:
> On Sat, 20 May 2017 23:01:04 +0200
> Michael Niedermayer wrote:
>
> > This reorders the operations so as to avoid computations with the above
> > arguments
> > before they have been initialized.
> > Fixes part of 1708/clusterfuzz-testcase-minimized-5035111957397504
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/mlpdec.c | 34 +-
> > 1 file changed, 25 insertions(+), 9 deletions(-)
> >
> > diff --git a/libavcodec/mlpdec.c b/libavcodec/mlpdec.c
> > index c0a23c5f0d..11be380d27 100644
> > --- a/libavcodec/mlpdec.c
> > +++ b/libavcodec/mlpdec.c
> > @@ -825,8 +825,6 @@ static int read_channel_params(MLPDecodeContext *m,
> > unsigned int substr,
> > return AVERROR_INVALIDDATA;
> > }
> >
> > -cp->sign_huff_offset = calculate_sign_huff(m, substr, ch);
> > -
> > return 0;
> > }
> >
> > @@ -838,7 +836,8 @@ static int read_decoding_params(MLPDecodeContext *m,
> > GetBitContext *gbp,
> > {
> > SubStream *s = &m->substream[substr];
> > unsigned int ch;
> > -int ret;
> > +int ret = 0;
> > +unsigned recompute_sho = 0;
> >
> > if (s->param_presence_flags & PARAM_PRESENCE)
> > if (get_bits1(gbp))
> > @@ -878,19 +877,36 @@ static int read_decoding_params(MLPDecodeContext *m,
> > GetBitContext *gbp,
> > if (s->param_presence_flags & PARAM_QUANTSTEP)
> > if (get_bits1(gbp))
> > for (ch = 0; ch <= s->max_channel; ch++) {
> > -ChannelParams *cp = &s->channel_params[ch];
> > -
> > s->quant_step_size[ch] = get_bits(gbp, 4);
> >
> > -cp->sign_huff_offset = calculate_sign_huff(m, substr, ch);
> > +recompute_sho |= 1< > }
> >
> > for (ch = s->min_channel; ch <= s->max_channel; ch++)
> > -if (get_bits1(gbp))
> > +if (get_bits1(gbp)) {
> > +recompute_sho |= 1< > if ((ret = read_channel_params(m, substr, gbp, ch)) < 0)
> > -return ret;
> > +goto fail;
> > +}
> >
> > -return 0;
> > +
>
>
> > +fail:
> > +for (ch = 0; ch <= s->max_channel; ch++) {
> > +if (recompute_sho & (1< > +ChannelParams *cp = &s->channel_params[ch];
> > +
> > +if (cp->codebook > 0 && cp->huff_lsbs <
> > s->quant_step_size[ch]) {
> > +if (ret >= 0) {
> > +av_log(m->avctx, AV_LOG_ERROR, "quant_step_size larger
> > than huff_lsbs\n");
> > +ret = AVERROR_INVALIDDATA;
> > +}
> > +s->quant_step_size[ch] = 0;
> > +}
> > +
> > +cp->sign_huff_offset = calculate_sign_huff(m, substr, ch);
> > +}
> > +}
> > +return ret;
>
> What's all this stuff for?
As described in the commit message it
"Check quant_step_size against huff_lsbs"
both these are updated independant and conditionally, so the loop
checking them is seperate after both which is ugly.
If you have an idea how to do this cleaner ...
as it is in git the case checked for results in negative shift
exponents
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/escape124: Check depth against num_superblocks
On Sat, May 20, 2017 at 11:01:02PM +0200, Michael Niedermayer wrote: > Fixes: runtime error: left shift of 66184 by 15 places cannot be represented > in type 'int' > Fixes: 1707/clusterfuzz-testcase-minimized-6502767008940032 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/escape124.c | 5 + > 1 file changed, 5 insertions(+) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: Enable in MP4 container both AMR-NB and AMR-WB
The MOV issue I am working on is likely an issue with our framework. I hope to have this resolved soon. Assuming MOV works, we still would like to use MP4 with AMR NB/WB. What is the difficulty with enabling this? Seems it has been updated to accept Opus recently. Bob On Fri, May 19, 2017 at 10:19 AM, Bob Kirnum wrote: > I tried adding support for MOV to see if I could use unpatched FFmpeg > libraries. Although both AMR-NB and AMR-WB do appear to record to MOV, > neither result plays properly using QuickTime or Windows 'Movies & TV' > app. The MOV (H.264 / AMR-NB) sometimes audio plays, sometimes video. > Appears that the MOV contains two moov atoms, one for audio one for video. > Similar is true for AMR-WB, however, there is never audio as QuickTime and > Windows app do not support AMR-WB. > > I also tried both MP4 and MOV using linear PCM (s16le @ 16 kHz). MP4 > rejects the codec, MOV seems to have a similar issue as AMR, only video > plays. > > I am using the exact same code as we use for MP4 so I am not sure what we > are doing wrong. Any suggestions for how to debug this? > > The recorded files are here . . . > > https://drive.google.com/open?id=0B-TtYdUjPHBmM29uWkU4aHdReE0 > > big-buck-bunny_trailer.h264_s16le.mov > big-buck-bunny_trailer.h264_amrnb.mov > big-buck-bunny_trailer.h264_amrwb.mov > > Thanks, > Bob > > On Thu, May 18, 2017 at 8:34 AM, Bob Kirnum wrote: > >> Hey Carl, >> >> I am not aware of non-FFmpeg apps which can record to MP4 containing >> AMR. That's not to say one does not exist. >> >> I would agree that we likely need no changes for playing these MP4 files. >> >> The MP4 requirement was from one of our customers. >> >> Thanks, >> Bob >> >> On Wed, May 17, 2017 at 8:01 PM, Carl Eugen Hoyos >> wrote: >> >>> 2017-05-17 23:26 GMT+02:00 Bob Kirnum : >>> > Did not realize the files I shared were too large. I copied them to a >>> > shared Google Drive here . . . >>> >>> The question was if you have files that were not created with FFmpeg. >>> >>> Anyway: Since both files can be decoded with unpatched FFmpeg, I >>> assume the demuxing hunk of your patch is unneeded, correct? >>> >>> Any reason why you cannot use mov for muxing? >>> >>> Carl Eugen >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >> >> > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/concatdec: do not transfer custom IO flag
On Mon, May 22, 2017 at 05:11:34PM +0200, wm4 wrote: > On Mon, 22 May 2017 16:54:31 +0200 > Clément Bœsch wrote: > > > From: Clément Bœsch > > > > If the source is using a custom IO, setting this flag causes heavy leaks > > since the segments will not have their avio context closed. > > > > Regression since f5da453b068f55d335ca403d2e2b4dd2ac3d4331. > > --- > > libavformat/concatdec.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c > > index 73f8a63a2b..e57e5ce0ec 100644 > > --- a/libavformat/concatdec.c > > +++ b/libavformat/concatdec.c > > @@ -324,7 +324,7 @@ static int open_file(AVFormatContext *avf, unsigned > > fileno) > > if (!cat->avf) > > return AVERROR(ENOMEM); > > > > -cat->avf->flags |= avf->flags; > > +cat->avf->flags |= avf->flags & ~AVFMT_FLAG_CUSTOM_IO; > > cat->avf->interrupt_callback = avf->interrupt_callback; > > > > if ((ret = ff_copy_whiteblacklists(cat->avf, avf)) < 0) > > Yeah, that would be unintended. The intention was to pass down the flag > to disable side data packet merging. > > HLS had the same change and should probably be fixed. Done the same for HLS and pushed. Thanks -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/mlpdec: Fix runtime error: shift exponent -5 is negative
On Sat, May 20, 2017 at 11:01:03PM +0200, Michael Niedermayer wrote: > Fixes part of 1708/clusterfuzz-testcase-minimized-5035111957397504 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/mlpdec.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavc/ffjni: add missing '\n'
On Sun, May 21, 2017 at 06:56:42PM +0200, Matthieu Bouron wrote: > On Sun, May 21, 2017 at 06:36:10PM +0200, Carl Eugen Hoyos wrote: > > 2017-05-21 18:17 GMT+02:00 Matthieu Bouron : > > > > > -av_log(log_ctx, AV_LOG_ERROR, "Failed to get the JNI environment > > > attached to this thread"); > > > +av_log(log_ctx, AV_LOG_ERROR, "Failed to get the JNI environment > > > attached to this thread\n"); > > > > Please commit such fixes without sending them to -devel. > > Does that include the 3 patches ? > I will push the patchset tomorrow if there is no objection (and backport it to the 3.3 release). [...] -- Matthieu B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: Enable in MP4 container both AMR-NB and AMR-WB
I resolved our issue with the MOV changes and now have H.264 / AMR-NB and H.264 / AMR-WB recording to MOV using non-patched FFmpeg. The former plays in both QuickTime and the Windows 10 'Movies & TV' app, video and audio. The MOV containing AMR-WB plays video only in QuickTime and neither in the Windows 10 'Movies & TV' app. This is equivalent to the MP4 files we record with our proposed patch. On Mon, May 22, 2017 at 11:41 AM, Bob Kirnum wrote: > The MOV issue I am working on is likely an issue with our framework. I > hope to have this resolved soon. > > Assuming MOV works, we still would like to use MP4 with AMR NB/WB. What > is the difficulty with enabling this? Seems it has been updated to accept > Opus recently. > > Bob > > On Fri, May 19, 2017 at 10:19 AM, Bob Kirnum wrote: > >> I tried adding support for MOV to see if I could use unpatched FFmpeg >> libraries. Although both AMR-NB and AMR-WB do appear to record to MOV, >> neither result plays properly using QuickTime or Windows 'Movies & TV' >> app. The MOV (H.264 / AMR-NB) sometimes audio plays, sometimes video. >> Appears that the MOV contains two moov atoms, one for audio one for video. >> Similar is true for AMR-WB, however, there is never audio as QuickTime and >> Windows app do not support AMR-WB. >> >> I also tried both MP4 and MOV using linear PCM (s16le @ 16 kHz). MP4 >> rejects the codec, MOV seems to have a similar issue as AMR, only video >> plays. >> >> I am using the exact same code as we use for MP4 so I am not sure what we >> are doing wrong. Any suggestions for how to debug this? >> >> The recorded files are here . . . >> >> https://drive.google.com/open?id=0B-TtYdUjPHBmM29uWkU4aHdReE0 >> >> big-buck-bunny_trailer.h264_s16le.mov >> big-buck-bunny_trailer.h264_amrnb.mov >> big-buck-bunny_trailer.h264_amrwb.mov >> >> Thanks, >> Bob >> >> On Thu, May 18, 2017 at 8:34 AM, Bob Kirnum wrote: >> >>> Hey Carl, >>> >>> I am not aware of non-FFmpeg apps which can record to MP4 containing >>> AMR. That's not to say one does not exist. >>> >>> I would agree that we likely need no changes for playing these MP4 files. >>> >>> The MP4 requirement was from one of our customers. >>> >>> Thanks, >>> Bob >>> >>> On Wed, May 17, 2017 at 8:01 PM, Carl Eugen Hoyos >>> wrote: >>> 2017-05-17 23:26 GMT+02:00 Bob Kirnum : > Did not realize the files I shared were too large. I copied them to a > shared Google Drive here . . . The question was if you have files that were not created with FFmpeg. Anyway: Since both files can be decoded with unpatched FFmpeg, I assume the demuxing hunk of your patch is unneeded, correct? Any reason why you cannot use mov for muxing? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> >> > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/takdec: Fix multiple runtime error: signed integer overflow: -512 * 4563386 cannot be represented in type 'int'
On Sat, May 20, 2017 at 11:06:45PM +0200, Michael Niedermayer wrote: > On Sat, May 20, 2017 at 07:26:50PM +0200, Marton Balint wrote: > > > > On Sat, 20 May 2017, Michael Niedermayer wrote: > > > > >Found-by: continuous fuzzing process > > >https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > > > > This URL is a 404 for me, I guess the correct URL is > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > yes that was apparently changed in a143b9b39a51412d133f846688194d68fe4197ba > > ill fix the link in future commits applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]libavformat/http: fix http error eof
1. An exception occurred in the CDN edge server, that will lead to close the http connection. 2. Because http is disconnected, so ffurl_read will return 0 3. Avformat will consider I/O is eof 4. Right now http is actually disconnect abnormally, it should return to ERROR, rather than return to EOF. 2017-05-22 23:05 GMT+08:00 Steven Liu : > 2017-05-22 22:36 GMT+08:00 raymond zheng : > > > I don't think it need a timeout event to disconnect the link, because > > when ffurl_read > > return to 0, it means the link disconnect. If s->off < target_end, it > > means AVERROR, > > otherwise, it's normal eof. > > I don't use chunked in HTTP, so s->chunksize should be initial value, and > > shouldn't be changed or even decreased. > > > > What will happen if not apply this patch? can you reproduce the bug step > by step. > > > 2017-05-22 18:51 GMT+08:00 Steven Liu : > > > > > 2017-05-18 15:19 GMT+08:00 raymond zheng : > > > > > > > Hi: > > > > I find an issue about http. I don't use chunked, so s->chunksize > > will > > > > be set as UINT64_MAX when http open, but because of "if > (s->chunksize > > > > 0) > > > > s->chunksize -= len;" then chunksize will not be UINT64_MAX. > > > > > > > > If ffurl_read return to 0, s->off < target_end, http_buf_read > will > > > > return to 0, then this will lead to eof, so this is incorrect, and > > > > http_buf_read should return to AVERROR(EIO). > > > > > > > > > > if connect to CDN http edge server, this maybe incorrect. or need a > > > timeout event to disconnect the link. > > > > > > > > > > > ___ > > > > ffmpeg-devel mailing list > > > > ffmpeg-devel@ffmpeg.org > > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > > > > > > ___ > > > ffmpeg-devel mailing list > > > ffmpeg-devel@ffmpeg.org > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]libavformat/http: fix http error eof
2017-05-23 10:47 GMT+08:00 raymond zheng : > 1. An exception occurred in the CDN edge server, that will lead to close > the http connection. > > 2. Because http is disconnected, so ffurl_read will return 0 > > 3. Avformat will consider I/O is eof > > 4. Right now http is actually disconnect abnormally, it should return to > ERROR, rather than return to EOF. > Can you reproduce it? and provide me try to reproduce it. I cannot sure if apply this patch will influence other people require function, for example: retry or reconnect again. > 2017-05-22 23:05 GMT+08:00 Steven Liu : > > > 2017-05-22 22:36 GMT+08:00 raymond zheng : > > > > > I don't think it need a timeout event to disconnect the link, because > > > when ffurl_read > > > return to 0, it means the link disconnect. If s->off < target_end, it > > > means AVERROR, > > > otherwise, it's normal eof. > > > I don't use chunked in HTTP, so s->chunksize should be initial value, > and > > > shouldn't be changed or even decreased. > > > > > > What will happen if not apply this patch? can you reproduce the bug > step > > by step. > > > > > 2017-05-22 18:51 GMT+08:00 Steven Liu : > > > > > > > 2017-05-18 15:19 GMT+08:00 raymond zheng >: > > > > > > > > > Hi: > > > > > I find an issue about http. I don't use chunked, so > s->chunksize > > > will > > > > > be set as UINT64_MAX when http open, but because of "if > > (s->chunksize > > > > > 0) > > > > > s->chunksize -= len;" then chunksize will not be UINT64_MAX. > > > > > > > > > > If ffurl_read return to 0, s->off < target_end, http_buf_read > > will > > > > > return to 0, then this will lead to eof, so this is incorrect, and > > > > > http_buf_read should return to AVERROR(EIO). > > > > > > > > > > > > > if connect to CDN http edge server, this maybe incorrect. or need a > > > > timeout event to disconnect the link. > > > > > > > > > > > > > > ___ > > > > > ffmpeg-devel mailing list > > > > > ffmpeg-devel@ffmpeg.org > > > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > > > > > > > > > ___ > > > > ffmpeg-devel mailing list > > > > ffmpeg-devel@ffmpeg.org > > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > > ___ > > > ffmpeg-devel mailing list > > > ffmpeg-devel@ffmpeg.org > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]libavformat/http: fix http error eof
You can close http link on your http server, and check ffurl_read result. Besides, this problem was caused by commit: 2a05c8f813de6f2278827734bf8102291e7484aa 2017-05-23 13:37 GMT+08:00 Steven Liu : > 2017-05-23 10:47 GMT+08:00 raymond zheng : > > > 1. An exception occurred in the CDN edge server, that will lead to close > > the http connection. > > > > 2. Because http is disconnected, so ffurl_read will return 0 > > > > 3. Avformat will consider I/O is eof > > > > 4. Right now http is actually disconnect abnormally, it should return to > > ERROR, rather than return to EOF. > > > Can you reproduce it? and provide me try to reproduce it. > I cannot sure if apply this patch will influence other people require > function, for example: retry or reconnect again. > > > > 2017-05-22 23:05 GMT+08:00 Steven Liu : > > > > > 2017-05-22 22:36 GMT+08:00 raymond zheng : > > > > > > > I don't think it need a timeout event to disconnect the link, because > > > > when ffurl_read > > > > return to 0, it means the link disconnect. If s->off < target_end, it > > > > means AVERROR, > > > > otherwise, it's normal eof. > > > > I don't use chunked in HTTP, so s->chunksize should be initial value, > > and > > > > shouldn't be changed or even decreased. > > > > > > > > What will happen if not apply this patch? can you reproduce the bug > > step > > > by step. > > > > > > > 2017-05-22 18:51 GMT+08:00 Steven Liu : > > > > > > > > > 2017-05-18 15:19 GMT+08:00 raymond zheng < > raymondzheng1...@gmail.com > > >: > > > > > > > > > > > Hi: > > > > > > I find an issue about http. I don't use chunked, so > > s->chunksize > > > > will > > > > > > be set as UINT64_MAX when http open, but because of "if > > > (s->chunksize > > > > > > 0) > > > > > > s->chunksize -= len;" then chunksize will not be UINT64_MAX. > > > > > > > > > > > > If ffurl_read return to 0, s->off < target_end, http_buf_read > > > will > > > > > > return to 0, then this will lead to eof, so this is incorrect, > and > > > > > > http_buf_read should return to AVERROR(EIO). > > > > > > > > > > > > > > > > if connect to CDN http edge server, this maybe incorrect. or need > a > > > > > timeout event to disconnect the link. > > > > > > > > > > > > > > > > > ___ > > > > > > ffmpeg-devel mailing list > > > > > > ffmpeg-devel@ffmpeg.org > > > > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > > > > > > > > > > > > ___ > > > > > ffmpeg-devel mailing list > > > > > ffmpeg-devel@ffmpeg.org > > > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > > > > ___ > > > > ffmpeg-devel mailing list > > > > ffmpeg-devel@ffmpeg.org > > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > > ___ > > > ffmpeg-devel mailing list > > > ffmpeg-devel@ffmpeg.org > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
