from:"王消寒"

[FFmpeg-devel] Initialize `layout_map` on declaration

2020-08-28 Thread 王消寒

Resend with @chromium.org account. Sorry for the noise.
From 3f9a085802bec62c9c7d35efcd30107e348c54d4 Mon Sep 17 00:00:00 2001
From: Xiaohan Wang 
Date: Fri, 28 Aug 2020 12:51:19 -0700
Subject: [PATCH] Initialize `layout_map` on declaration

Without this change, it'll cause use-of-uninitialized-variable error.
---
 libavcodec/aacdec_template.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index e8af01b084..76fffedfcb 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -3312,7 +3312,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx, void *data,
 break;

 case TYPE_PCE: {
-uint8_t layout_map[MAX_ELEM_ID*4][3];
+uint8_t layout_map[MAX_ELEM_ID*4][3] = {{0}};
 int tags;

 int pushed = push_output_configuration(ac);
-- 
2.28.0.402.g5ffc5be6b7-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Fix stts_data memory allocation

2018-03-06 Thread 王消寒

kingly ping!

On Tue, Feb 13, 2018 at 4:08 PM, Xiaohan Wang (王消寒) <xhw...@chromium.org>
wrote:

> "unsigned" is perfectly fine. Just trying to be consistent with the line
> above.
>
> On Tue, Feb 13, 2018 at 4:06 PM, Carl Eugen Hoyos <ceffm...@gmail.com>
> wrote:
>
>> 2018-02-13 23:48 GMT+01:00 Xiaohan Wang (王消寒) <xhw...@chromium.org>:
>>
>> Thank you for the fix!
>> (What's wrong with "unsigned"?)
>>
>> 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] Fix memset size on ctts_data in mov_read_trun()

2018-02-27 Thread 王消寒

Sure. Updated!

On Tue, Feb 27, 2018 at 2:38 AM, Michael Niedermayer <mich...@niedermayer.cc
> wrote:

> On Mon, Feb 26, 2018 at 10:37:51AM -0800, Xiaohan Wang (王消寒) wrote:
> > Thanks! Updated the patch. Please take a look again.
> >
> > On Sat, Feb 24, 2018 at 7:04 PM, Michael Niedermayer
> <mich...@niedermayer.cc
> > > wrote:
> >
> > > On Fri, Feb 23, 2018 at 05:12:05PM -0800, Xiaohan Wang (王消寒) wrote:
> > > > Michael: Dale and I dig into history a bit more and we don't
> understand
> > > why
> > > > the code is changed to the current state around memset. This new
> patch
> > > > reverted the change back to the previous state which we felt is much
> > > > cleaner. Please see the CL description for details and take a look
> at the
> > > > new patch. Thanks!
> > > >
> > > > On Wed, Feb 21, 2018 at 1:14 PM, Xiaohan Wang (王消寒) <
> xhw...@chromium.org
> > > >
> > > > wrote:
> > > >
> > > > > jstebbins: kindly ping!
> > > > >
> > > > > On Fri, Feb 16, 2018 at 2:42 PM, Xiaohan Wang (王消寒) <
> > > xhw...@chromium.org>
> > > > > wrote:
> > > > >
> > > > >> +jstebbins@ who wrote that code.
> > > > >>
> > > > >> On Fri, Feb 16, 2018 at 12:30 PM, Michael Niedermayer <
> > > > >> mich...@niedermayer.cc> wrote:
> > > > >>
> > > > >>> On Thu, Feb 15, 2018 at 12:10:33PM -0800, Xiaohan Wang (王消寒)
> wrote:
> > > > >>> >
> > > > >>>
> > > > >>> >  mov.c |3 ++-
> > > > >>> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > >>> > 5597d0b095f8b15eb11503010a51c2bc2c022413
> > > > >>> 0001-ffmpeg-Fix-memset-size-on-ctts_data-in-mov_read_trun.patch
> > > > >>> > From 7c1e6b50ebe35b2a38c4f1d0a988e31eccbd0ead Mon Sep 17
> 00:00:00
> > > 2001
> > > > >>> > From: Xiaohan Wang <xhw...@chromium.org>
> > > > >>> > Date: Thu, 15 Feb 2018 12:05:53 -0800
> > > > >>> > Subject: [PATCH] ffmpeg: Fix memset size on ctts_data in
> > > > >>> mov_read_trun()
> > > > >>> >
> > > > >>> > The allocated size of sc->ctts_data is
> > > > >>> > (st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
> > > > >>> >
> > > > >>> > The size to memset at offset sc->ctts_data + sc->ctts_count
> should
> > > be
> > > > >>> > (st->nb_index_entries + entries - sc->ctts_count) *
> > > > >>> sizeof(*sc->ctts_data))
> > > > >>> >
> > > > >>> > The current code missed |entries| I believe.
> > > > >>>
> > > > >>> shouldnt "entries" be read by this function later and so shouldnt
> > > need a
> > > > >>> memset?
> > > > >>> I didnt write this, but it looks a bit to me as if it was
> intended to
> > > > >>> only
> > > > >>> clear the area that would not be read later
> > > > >>>
> > > > >>
> > > > >> I thought we only had sc->ctts_count entries before
> av_fast_realloc,
> > > so
> > > > >> memset everything starting from sc->ctts_data + sc->ctts_count
> > > couldn't
> > > > >> go wrong. But I am not familiar with this code and that could
> totally
> > > be
> > > > >> wrong. I added jstebbins@ who wrote the code and hopefully we
> can get
> > > > >> expert opinion there.
> > > > >>
> > > > >>
> > > > >>> [...]
> > > > >>> --
> > > > >>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> > > 87040B0FAB
> > > > >>>
> > > > >>> No great genius has ever existed without some touch of madness.
> --
> > > > >>> Aristotle
> > > > >>>
> > > > >>> ___
> > > > >>> ffmpeg-devel mailing list
> > > > >>> ffmpeg-devel@ffmpeg.org
> > > > >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > >

Re: [FFmpeg-devel] Fix memset size on ctts_data in mov_read_trun()

2018-02-26 Thread 王消寒

Thanks! Updated the patch. Please take a look again.

On Sat, Feb 24, 2018 at 7:04 PM, Michael Niedermayer <mich...@niedermayer.cc
> wrote:

> On Fri, Feb 23, 2018 at 05:12:05PM -0800, Xiaohan Wang (王消寒) wrote:
> > Michael: Dale and I dig into history a bit more and we don't understand
> why
> > the code is changed to the current state around memset. This new patch
> > reverted the change back to the previous state which we felt is much
> > cleaner. Please see the CL description for details and take a look at the
> > new patch. Thanks!
> >
> > On Wed, Feb 21, 2018 at 1:14 PM, Xiaohan Wang (王消寒) <xhw...@chromium.org
> >
> > wrote:
> >
> > > jstebbins: kindly ping!
> > >
> > > On Fri, Feb 16, 2018 at 2:42 PM, Xiaohan Wang (王消寒) <
> xhw...@chromium.org>
> > > wrote:
> > >
> > >> +jstebbins@ who wrote that code.
> > >>
> > >> On Fri, Feb 16, 2018 at 12:30 PM, Michael Niedermayer <
> > >> mich...@niedermayer.cc> wrote:
> > >>
> > >>> On Thu, Feb 15, 2018 at 12:10:33PM -0800, Xiaohan Wang (王消寒) wrote:
> > >>> >
> > >>>
> > >>> >  mov.c |3 ++-
> > >>> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > >>> > 5597d0b095f8b15eb11503010a51c2bc2c022413
> > >>> 0001-ffmpeg-Fix-memset-size-on-ctts_data-in-mov_read_trun.patch
> > >>> > From 7c1e6b50ebe35b2a38c4f1d0a988e31eccbd0ead Mon Sep 17 00:00:00
> 2001
> > >>> > From: Xiaohan Wang <xhw...@chromium.org>
> > >>> > Date: Thu, 15 Feb 2018 12:05:53 -0800
> > >>> > Subject: [PATCH] ffmpeg: Fix memset size on ctts_data in
> > >>> mov_read_trun()
> > >>> >
> > >>> > The allocated size of sc->ctts_data is
> > >>> > (st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
> > >>> >
> > >>> > The size to memset at offset sc->ctts_data + sc->ctts_count should
> be
> > >>> > (st->nb_index_entries + entries - sc->ctts_count) *
> > >>> sizeof(*sc->ctts_data))
> > >>> >
> > >>> > The current code missed |entries| I believe.
> > >>>
> > >>> shouldnt "entries" be read by this function later and so shouldnt
> need a
> > >>> memset?
> > >>> I didnt write this, but it looks a bit to me as if it was intended to
> > >>> only
> > >>> clear the area that would not be read later
> > >>>
> > >>
> > >> I thought we only had sc->ctts_count entries before av_fast_realloc,
> so
> > >> memset everything starting from sc->ctts_data + sc->ctts_count
> couldn't
> > >> go wrong. But I am not familiar with this code and that could totally
> be
> > >> wrong. I added jstebbins@ who wrote the code and hopefully we can get
> > >> expert opinion there.
> > >>
> > >>
> > >>> [...]
> > >>> --
> > >>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> 87040B0FAB
> > >>>
> > >>> No great genius has ever existed without some touch of madness. --
> > >>> Aristotle
> > >>>
> > >>> ___
> > >>> ffmpeg-devel mailing list
> > >>> ffmpeg-devel@ffmpeg.org
> > >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >>>
> > >>>
> > >>
> > >
>
> >  mov.c |5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > e5bbe55f0b1260f787f431b5c45e6ca49a7d2d1e  0001-Fix-memset-size-on-ctts_
> data-in-mov_read_trun-round-.patch
> > From f34b35ec5749c17b21f80665a0b8859bce3e84ab Mon Sep 17 00:00:00 2001
> > From: Xiaohan Wang <xhw...@chromium.org>
> > Date: Fri, 23 Feb 2018 10:51:30 -0800
> > Subject: [PATCH] Fix memset size on ctts_data in mov_read_trun() (round
> 2)
> >
> > The allocated size of sc->ctts_data is
> > (st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
> >
> > The size to memset at offset sc->ctts_data + sc->ctts_count should be
> > (st->nb_index_entries + entries - sc->ctts_count) *
> > sizeof(*sc->ctts_data))
> >
> > The current code missed |entries| I believe, which was introduced in
> > https://patchwork.ffmpeg.org/patch/5541/.
> >
> > However, after

Re: [FFmpeg-devel] Fix memset size on ctts_data in mov_read_trun()

2018-02-23 Thread 王消寒

Michael: Dale and I dig into history a bit more and we don't understand why
the code is changed to the current state around memset. This new patch
reverted the change back to the previous state which we felt is much
cleaner. Please see the CL description for details and take a look at the
new patch. Thanks!

On Wed, Feb 21, 2018 at 1:14 PM, Xiaohan Wang (王消寒) <xhw...@chromium.org>
wrote:

> jstebbins: kindly ping!
>
> On Fri, Feb 16, 2018 at 2:42 PM, Xiaohan Wang (王消寒) <xhw...@chromium.org>
> wrote:
>
>> +jstebbins@ who wrote that code.
>>
>> On Fri, Feb 16, 2018 at 12:30 PM, Michael Niedermayer <
>> mich...@niedermayer.cc> wrote:
>>
>>> On Thu, Feb 15, 2018 at 12:10:33PM -0800, Xiaohan Wang (王消寒) wrote:
>>> >
>>>
>>> >  mov.c |3 ++-
>>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>>> > 5597d0b095f8b15eb11503010a51c2bc2c022413
>>> 0001-ffmpeg-Fix-memset-size-on-ctts_data-in-mov_read_trun.patch
>>> > From 7c1e6b50ebe35b2a38c4f1d0a988e31eccbd0ead Mon Sep 17 00:00:00 2001
>>> > From: Xiaohan Wang <xhw...@chromium.org>
>>> > Date: Thu, 15 Feb 2018 12:05:53 -0800
>>> > Subject: [PATCH] ffmpeg: Fix memset size on ctts_data in
>>> mov_read_trun()
>>> >
>>> > The allocated size of sc->ctts_data is
>>> > (st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
>>> >
>>> > The size to memset at offset sc->ctts_data + sc->ctts_count should be
>>> > (st->nb_index_entries + entries - sc->ctts_count) *
>>> sizeof(*sc->ctts_data))
>>> >
>>> > The current code missed |entries| I believe.
>>>
>>> shouldnt "entries" be read by this function later and so shouldnt need a
>>> memset?
>>> I didnt write this, but it looks a bit to me as if it was intended to
>>> only
>>> clear the area that would not be read later
>>>
>>
>> I thought we only had sc->ctts_count entries before av_fast_realloc, so
>> memset everything starting from sc->ctts_data + sc->ctts_count couldn't
>> go wrong. But I am not familiar with this code and that could totally be
>> wrong. I added jstebbins@ who wrote the code and hopefully we can get
>> expert opinion there.
>>
>>
>>> [...]
>>> --
>>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>>
>>> No great genius has ever existed without some touch of madness. --
>>> Aristotle
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>>
>>
>
From f34b35ec5749c17b21f80665a0b8859bce3e84ab Mon Sep 17 00:00:00 2001
From: Xiaohan Wang <xhw...@chromium.org>
Date: Fri, 23 Feb 2018 10:51:30 -0800
Subject: [PATCH] Fix memset size on ctts_data in mov_read_trun() (round 2)

The allocated size of sc->ctts_data is
(st->nb_index_entries + entries) * sizeof(*sc->ctts_data).

The size to memset at offset sc->ctts_data + sc->ctts_count should be
(st->nb_index_entries + entries - sc->ctts_count) *
sizeof(*sc->ctts_data))

The current code missed |entries| I believe, which was introduced in
https://patchwork.ffmpeg.org/patch/5541/.

However, after offline discussion, it seems the original code is much
more clear to read (before https://patchwork.ffmpeg.org/patch/5541/).

Hence this CL revert the memset logic to it's previous state by
remembering the |old_ctts_allocated_size|, and only memset the newly
allocated entries.
---
 libavformat/mov.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index a3725692a7..f8d79c7b02 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4713,6 +4713,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 st->index_entries= new_entries;
 
 requested_size = (st->nb_index_entries + entries) * sizeof(*sc->ctts_data);
+unsigned int old_ctts_allocated_size = sc->ctts_allocated_size;
 ctts_data = av_fast_realloc(sc->ctts_data, >ctts_allocated_size,
 requested_size);
 if (!ctts_data)
@@ -4722,8 +4723,8 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 // In case there were samples without ctts entries, ensure they get
 // zero valued entries. This ensures clips which mix boxes with and
 // without ctts entries don't pickup uninitialized data.
-memset(sc->ctts_data + sc->ctts_count, 0,
-   (st->nb_index_entries - sc->ctts_count) * sizeof(*sc->ctts_data));
+memset((uint8_t*)(sc->ctts_data) + old_ctts_allocated_size, 0,
+   sc->ctts_allocated_size - old_ctts_allocated_size);
 
 if (index_entry_pos < st->nb_index_entries) {
 // Make hole in index_entries and ctts_data for new samples
-- 
2.16.1.291.g4437f3f132-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Fix memset size on ctts_data in mov_read_trun()

2018-02-21 Thread 王消寒

jstebbins: kindly ping!

On Fri, Feb 16, 2018 at 2:42 PM, Xiaohan Wang (王消寒) <xhw...@chromium.org>
wrote:

> +jstebbins@ who wrote that code.
>
> On Fri, Feb 16, 2018 at 12:30 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> On Thu, Feb 15, 2018 at 12:10:33PM -0800, Xiaohan Wang (王消寒) wrote:
>> >
>>
>> >  mov.c |3 ++-
>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> > 5597d0b095f8b15eb11503010a51c2bc2c022413
>> 0001-ffmpeg-Fix-memset-size-on-ctts_data-in-mov_read_trun.patch
>> > From 7c1e6b50ebe35b2a38c4f1d0a988e31eccbd0ead Mon Sep 17 00:00:00 2001
>> > From: Xiaohan Wang <xhw...@chromium.org>
>> > Date: Thu, 15 Feb 2018 12:05:53 -0800
>> > Subject: [PATCH] ffmpeg: Fix memset size on ctts_data in mov_read_trun()
>> >
>> > The allocated size of sc->ctts_data is
>> > (st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
>> >
>> > The size to memset at offset sc->ctts_data + sc->ctts_count should be
>> > (st->nb_index_entries + entries - sc->ctts_count) *
>> sizeof(*sc->ctts_data))
>> >
>> > The current code missed |entries| I believe.
>>
>> shouldnt "entries" be read by this function later and so shouldnt need a
>> memset?
>> I didnt write this, but it looks a bit to me as if it was intended to only
>> clear the area that would not be read later
>>
>
> I thought we only had sc->ctts_count entries before av_fast_realloc, so
> memset everything starting from sc->ctts_data + sc->ctts_count couldn't
> go wrong. But I am not familiar with this code and that could totally be
> wrong. I added jstebbins@ who wrote the code and hopefully we can get
> expert opinion there.
>
>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> No great genius has ever existed without some touch of madness. --
>> Aristotle
>>
>> ___
>> 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] Fix memset size on ctts_data in mov_read_trun()

2018-02-16 Thread 王消寒

+jstebbins@ who wrote that code.

On Fri, Feb 16, 2018 at 12:30 PM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:

> On Thu, Feb 15, 2018 at 12:10:33PM -0800, Xiaohan Wang (王消寒) wrote:
> >
>
> >  mov.c |3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 5597d0b095f8b15eb11503010a51c2bc2c022413  0001-ffmpeg-Fix-memset-size-
> on-ctts_data-in-mov_read_trun.patch
> > From 7c1e6b50ebe35b2a38c4f1d0a988e31eccbd0ead Mon Sep 17 00:00:00 2001
> > From: Xiaohan Wang <xhw...@chromium.org>
> > Date: Thu, 15 Feb 2018 12:05:53 -0800
> > Subject: [PATCH] ffmpeg: Fix memset size on ctts_data in mov_read_trun()
> >
> > The allocated size of sc->ctts_data is
> > (st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
> >
> > The size to memset at offset sc->ctts_data + sc->ctts_count should be
> > (st->nb_index_entries + entries - sc->ctts_count) *
> sizeof(*sc->ctts_data))
> >
> > The current code missed |entries| I believe.
>
> shouldnt "entries" be read by this function later and so shouldnt need a
> memset?
> I didnt write this, but it looks a bit to me as if it was intended to only
> clear the area that would not be read later
>

I thought we only had sc->ctts_count entries before av_fast_realloc, so
memset everything starting from sc->ctts_data + sc->ctts_count couldn't go
wrong. But I am not familiar with this code and that could totally be
wrong. I added jstebbins@ who wrote the code and hopefully we can get
expert opinion there.


> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No great genius has ever existed without some touch of madness. --
> Aristotle
>
> ___
> 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] Fix memset size on ctts_data in mov_read_trun()

2018-02-15 Thread 王消寒


From 7c1e6b50ebe35b2a38c4f1d0a988e31eccbd0ead Mon Sep 17 00:00:00 2001
From: Xiaohan Wang 
Date: Thu, 15 Feb 2018 12:05:53 -0800
Subject: [PATCH] ffmpeg: Fix memset size on ctts_data in mov_read_trun()

The allocated size of sc->ctts_data is
(st->nb_index_entries + entries) * sizeof(*sc->ctts_data).

The size to memset at offset sc->ctts_data + sc->ctts_count should be
(st->nb_index_entries + entries - sc->ctts_count) * sizeof(*sc->ctts_data))

The current code missed |entries| I believe.

BUG=812567
---
 libavformat/mov.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index a3725692a7..6407d60050 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4723,7 +4723,8 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 // zero valued entries. This ensures clips which mix boxes with and
 // without ctts entries don't pickup uninitialized data.
 memset(sc->ctts_data + sc->ctts_count, 0,
-   (st->nb_index_entries - sc->ctts_count) * sizeof(*sc->ctts_data));
+   (st->nb_index_entries + entries - sc->ctts_count) *
+   sizeof(*sc->ctts_data));
 
 if (index_entry_pos < st->nb_index_entries) {
 // Make hole in index_entries and ctts_data for new samples
-- 
2.16.1.291.g4437f3f132-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Fix stts_data memory allocation

2018-02-13 Thread 王消寒

"unsigned" is perfectly fine. Just trying to be consistent with the line
above.

On Tue, Feb 13, 2018 at 4:06 PM, Carl Eugen Hoyos <ceffm...@gmail.com>
wrote:

> 2018-02-13 23:48 GMT+01:00 Xiaohan Wang (王消寒) <xhw...@chromium.org>:
>
> Thank you for the fix!
> (What's wrong with "unsigned"?)
>
> 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

[FFmpeg-devel] Fix stts_data memory allocation

2018-02-13 Thread 王消寒


From 241d5e45eb8750521d07d07aa55ea637359ab55d Mon Sep 17 00:00:00 2001
From: Xiaohan Wang 
Date: Tue, 13 Feb 2018 14:45:14 -0800
Subject: [PATCH] ffmpeg: Fix stts_data memory allocation

In this loop, |i| is the "index". And the memory allocated should be at
least the current "count", which is |i + 1|.

BUG=801821
---
 libavformat/mov.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 5adba52e08..1e02ffb445 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2882,7 +2882,7 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 for (i = 0; i < entries && !pb->eof_reached; i++) {
 int sample_duration;
 unsigned int sample_count;
-unsigned min_entries = FFMIN(FFMAX(i, 1024 * 1024), entries);
+unsigned int min_entries = FFMIN(FFMAX(i + 1, 1024 * 1024), entries);
 MOVStts *stts_data = av_fast_realloc(sc->stts_data, _size,
  min_entries * sizeof(*sc->stts_data));
 if (!stts_data) {
-- 
2.16.1.291.g4437f3f132-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Abort early on decode_slice error

2018-02-13 Thread 王消寒

New patch as discussed offline:



On Sat, Feb 3, 2018 at 2:29 AM, Xiaohan Wang (王消寒) <xhw...@chromium.org>
wrote:

>
>
From e8ad6159640c913773583a8b551ecebcff6b9c63 Mon Sep 17 00:00:00 2001
From: Xiaohan Wang <xhw...@chromium.org>
Date: Sat, 3 Feb 2018 01:43:35 -0800
Subject: [PATCH] ffmpeg: Set valid qscale value in ff_h264_decode_mb_cavlc()

When ff_h264_decode_mb_cavlc() failed due to wrong sl->qscale values,
e.g. dquant out of range, set the qscale to be a valid value before
returning -1 and exiting the function. The qscale value can be used
later e.g. in loop filter.

BUG=806122
---
 libavcodec/h264_cavlc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/h264_cavlc.c b/libavcodec/h264_cavlc.c
index 2421beed9d..a7e60676a0 100644
--- a/libavcodec/h264_cavlc.c
+++ b/libavcodec/h264_cavlc.c
@@ -1110,6 +1110,7 @@ decode_intra_mb:
 elsesl->qscale -= max_qp+1;
 if (((unsigned)sl->qscale) > max_qp){
 av_log(h->avctx, AV_LOG_ERROR, "dquant out of range (%d) at %d %d\n", dquant, sl->mb_x, sl->mb_y);
+sl->qscale = max_qp;
 return -1;
 }
 }
-- 
2.16.0.rc1.238.g530d649a79-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Fix ctts_index calculation

2018-02-09 Thread 王消寒

I uploaded a new patch. Is this what you meant?

I am confused with the code though. In the case *ctts_index == ctts_count,
this while loop will do nothing. Is this what we want? Also, the "wrong"
|ctts_index| will be available outside of this function. How do we make
sure it won't cause trouble later?

On Fri, Feb 9, 2018 at 12:26 PM, Sasi Inguva <isasi-at-google@ffmpeg.org
> wrote:

> >
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 5adba52e08..f0bd3e3623 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -3148,7 +3148,7 @@ static int find_prev_closest_index(AVStream *st,
> >  *ctts_index = 0;
> >  *ctts_sample = 0;
> >  for (index_ctts_count = 0; index_ctts_count < *index;
> > index_ctts_count++) {
> > -if (*ctts_index < ctts_count) {
>
> +if (*ctts_index < ctts_count - 1) {
> >
> If you do this, then we are skipping, looking at ctts_samples in the last
> ctts entry where (*ctts_index == ctts_count -1), which is not desired.
>
>  (*ctts_sample)++;
> >  if (ctts_data[*ctts_index].count == *ctts_sample) {
> >  (*ctts_index)++;
> >
>
> Here *ctts_index == ctts_count  only iff   the *ctts_index is the last CTTS
> entry, and we still didn't reach   *index. That means that it's file with
> CTTS truncated i.e. no corresponding CTTS entries for some STTS entries.
> This issue can be fixed by checking for  *ctts_index <  ctts_count, in the
> line after this loop.
> while (*index
> <https://cs.corp.google.com/piper///depot/google3/third_
> party/ffmpeg/next/libavformat/mov.c?l=3123=xref_jump_to_
> def=index=184932376>
> >= 0 && (*ctts_index
> <https://cs.corp.google.com/piper///depot/google3/third_
> party/ffmpeg/next/libavformat/mov.c?l=3124=xref_jump_to_
> def=ctts_index=184932376>)
> >= 0) {
> we already check for (*ctts_index) >=0 so we can check for the upper bound
> too.
>
> On Sat, Feb 3, 2018 at 12:36 PM, Michael Niedermayer
> <mich...@niedermayer.cc
> > wrote:
>
> > On Fri, Feb 02, 2018 at 05:55:38PM -0800, Xiaohan Wang (王消寒) wrote:
> > >
> >
> > >  mov.c |2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 87157b4053de0e044e78db72ef13e8058075c235
> 0001-Fix-ctts_index-calculatio
> > n.patch
> > > From bb376fd2de5da5f9ecdef41621a579252b899d7d Mon Sep 17 00:00:00 2001
> > > From: Xiaohan Wang <xhw...@chromium.org>
> > > Date: Fri, 2 Feb 2018 17:33:56 -0800
> > > Subject: [PATCH] Fix ctts_index calculation
> > >
> > > An index should never be equal to the count. Hence we must make sure
> > > *ctts_index < ctts_count.
> > > ---
> > >  libavformat/mov.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > should be reviewed by sasi idealy, he wrote this
> >
> > thx
> >
> >
> > [...]
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Democracy is the form of government in which you can choose your dictator
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
From cedc04aec7703ce63a7e2b78ee394fcb0999b016 Mon Sep 17 00:00:00 2001
From: Xiaohan Wang <xhw...@chromium.org>
Date: Fri, 2 Feb 2018 17:33:56 -0800
Subject: [PATCH] Fix ctts_index calculation

An index should never be equal to the count. Hence we must make sure
*ctts_index < ctts_count.
---
 libavformat/mov.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 5adba52e08..c7f70f141e 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3157,7 +3157,7 @@ static int find_prev_closest_index(AVStream *st,
 }
 }
 
-while (*index >= 0 && (*ctts_index) >= 0) {
+while (*index >= 0 && (*ctts_index) >= 0 && (*ctts_index) < ctts_count) {
 // Find a "key frame" with PTS <= timestamp_pts (So that we can decode B-frames correctly).
 // No need to add dts_shift to the timestamp here becase timestamp_pts has already been
 // compensated by dts_shift above.
-- 
2.16.0.rc1.238.g530d649a79-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Abort early on decode_slice error

2018-02-03 Thread 王消寒




0001-ffmpeg-Abort-early-on-decode_slice-error.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Fix ctts_index calculation

2018-02-02 Thread 王消寒


From bb376fd2de5da5f9ecdef41621a579252b899d7d Mon Sep 17 00:00:00 2001
From: Xiaohan Wang 
Date: Fri, 2 Feb 2018 17:33:56 -0800
Subject: [PATCH] Fix ctts_index calculation

An index should never be equal to the count. Hence we must make sure
*ctts_index < ctts_count.
---
 libavformat/mov.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 5adba52e08..f0bd3e3623 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3148,7 +3148,7 @@ static int find_prev_closest_index(AVStream *st,
 *ctts_index = 0;
 *ctts_sample = 0;
 for (index_ctts_count = 0; index_ctts_count < *index; index_ctts_count++) {
-if (*ctts_index < ctts_count) {
+if (*ctts_index < ctts_count - 1) {
 (*ctts_sample)++;
 if (ctts_data[*ctts_index].count == *ctts_sample) {
 (*ctts_index)++;
-- 
2.16.0.rc1.238.g530d649a79-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Remove carriage return ('\r') in Windows CC_IDENT

2018-01-31 Thread 王消寒


From 07e33b2aa09b8b224ac35a5b56b29490a6486bdf Mon Sep 17 00:00:00 2001
From: Xiaohan Wang 
Date: Wed, 31 Jan 2018 14:20:02 -0800
Subject: [PATCH] Remove carriage return ('\r') in Windows CC_IDENT

Currently the Windows CC_IDENT is ended with '\r\n'. "head -n1" will not
remove the '\r' and this is causing building error in Chromium.

This CL adds "tr -d '\r'" to remove '\r' in the CC_IDENT string. Since in
most cases '\r' only appears at the end of a string/line, this should
work in most cases.

See example:

printf "hello\r\nworld\r\n" | head -n1 | hd
  68 65 6c 6c 6f 0d 0a  |hello..|

printf "hello\r\nworld\r\n" | head -n1 | tr -d '\r' | hd
  68 65 6c 6c 6f 0a |hello.|

Also note a similar previous change at:
https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2013-October/069950.html
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index a83581ea98..4a68c6364d 100755
--- a/configure
+++ b/configure
@@ -4289,7 +4289,7 @@ probe_cc(){
 _ld_path='-libpath:'
 elif $_cc -nologo- 2>&1 | grep -q Microsoft; then
 _type=msvc
-_ident=$($_cc 2>&1 | head -n1)
+_ident=$($_cc 2>&1 | head -n1 | tr -d '\r')
 _DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1 | awk '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if (!match($$0, / /)) print "$@:", $$0 }'\'' > $(@:.o=.d)'
 _DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -showIncludes -Zs'
 _cflags_speed="-O2"
-- 
2.16.0.rc1.238.g530d649a79-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Fix read-after-free in matroska_read_seek()

2014-11-07 Thread 王消寒

Hello ffmpeg-devel:

This is my first patch to FFmpeg, let me know if I am doing anything wrong
:)

This is a small patch to fix a read-after-free error in matroskadec.c.
Please take a look.

Xiaohan
From 45a523e9213cc887aa90cdf4953e66918b34f689 Mon Sep 17 00:00:00 2001
From: Xiaohan Wang xhw...@chromium.org
Date: Thu, 6 Nov 2014 12:59:54 -0800
Subject: [PATCH] Fix read-after-free in matroska_read_seek().

In matroska_read_seek(), |tracks| is assigned at the begining of the function.
However, functions like matroska_parse_cues() could reallocate the tracks so
that |tracks| can get invalidated.

This CL assigns |tracks| only before we use it so that it won't be invalidated.

BUG=427266
TEST=Test case in associated bug passes now.

Change-Id: I9c7065fe8f4311ca846076281df2282d190ed344
---
 libavformat/matroskadec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 5abf0f8..42dbd81 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2925,7 +2925,7 @@ static int matroska_read_seek(AVFormatContext *s, int stream_index,
   int64_t timestamp, int flags)
 {
 MatroskaDemuxContext *matroska = s-priv_data;
-MatroskaTrack *tracks = matroska-tracks.elem;
+MatroskaTrack *tracks = NULL;
 AVStream *st = s-streams[stream_index];
 int i, index, index_sub, index_min;
 
@@ -2955,6 +2955,7 @@ static int matroska_read_seek(AVFormatContext *s, int stream_index,
 goto err;
 
 index_min = index;
+tracks = matroska-tracks.elem;
 for (i = 0; i  matroska-tracks.nb_elem; i++) {
 tracks[i].audio.pkt_cnt= 0;
 tracks[i].audio.sub_packet_cnt = 0;
-- 
2.1.0.rc2.206.gedb03e5

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Initialize `layout_map` on declaration

Re: [FFmpeg-devel] Fix stts_data memory allocation

Re: [FFmpeg-devel] Fix memset size on ctts_data in mov_read_trun()

Re: [FFmpeg-devel] Fix memset size on ctts_data in mov_read_trun()

Re: [FFmpeg-devel] Fix memset size on ctts_data in mov_read_trun()

Re: [FFmpeg-devel] Fix memset size on ctts_data in mov_read_trun()

Re: [FFmpeg-devel] Fix memset size on ctts_data in mov_read_trun()

[FFmpeg-devel] Fix memset size on ctts_data in mov_read_trun()

Re: [FFmpeg-devel] Fix stts_data memory allocation

[FFmpeg-devel] Fix stts_data memory allocation

Re: [FFmpeg-devel] Abort early on decode_slice error

Re: [FFmpeg-devel] Fix ctts_index calculation

[FFmpeg-devel] Abort early on decode_slice error

[FFmpeg-devel] Fix ctts_index calculation

[FFmpeg-devel] Remove carriage return ('\r') in Windows CC_IDENT

[FFmpeg-devel] Fix read-after-free in matroska_read_seek()

16 matches

Site Navigation

Mail list logo

Footer information