Re: [libav-devel] [PATCH] h264: update avctx width/height when flushing
On 09/06/15 23:53, Andreas Cadhalpun wrote: > Inconsistencies between the dimensions of avctx and the frame can > confuse API users. For example this can crash the demuxing_decoding > example. > > Signed-off-by: Andreas Cadhalpun > --- > libavcodec/h264.c | 4 > 1 file changed, 4 insertions(+) > Would be better setting those in output_frame I think, I like the idea. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] takdec: ensure chan2 is a valid channel index
On 10/06/15 00:12, Andreas Cadhalpun wrote:
> If chan2 is not smaller than the number of channels, it can cause
> segmentation faults due to dereferencing a NULL pointer.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/takdec.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/takdec.c b/libavcodec/takdec.c
> index a453da8..4225030 100644
> --- a/libavcodec/takdec.c
> +++ b/libavcodec/takdec.c
> @@ -801,6 +801,12 @@ static int tak_decode_frame(AVCodecContext *avctx, void
> *data,
> if (s->mcdparams[i].present) {
> s->mcdparams[i].index = get_bits(gb, 2);
> s->mcdparams[i].chan2 = get_bits(gb, 4);
> +if (s->mcdparams[i].chan2 >= avctx->channels) {
> +av_log(avctx, AV_LOG_ERROR,
> + "invalid channel 2 (%d) for %d
> channel(s)\n",
> + s->mcdparams[i].chan2, avctx->channels);
> +return AVERROR_INVALIDDATA;
> +}
> if (s->mcdparams[i].index == 1) {
> if ((nbit == s->mcdparams[i].chan2) ||
> (ch_mask & 1 << s->mcdparams[i].chan2))
>
Looks fine to me.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] takdec: ensure chan2 is a valid channel index
If chan2 is not smaller than the number of channels, it can cause
segmentation faults due to dereferencing a NULL pointer.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/takdec.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/takdec.c b/libavcodec/takdec.c
index a453da8..4225030 100644
--- a/libavcodec/takdec.c
+++ b/libavcodec/takdec.c
@@ -801,6 +801,12 @@ static int tak_decode_frame(AVCodecContext *avctx, void
*data,
if (s->mcdparams[i].present) {
s->mcdparams[i].index = get_bits(gb, 2);
s->mcdparams[i].chan2 = get_bits(gb, 4);
+if (s->mcdparams[i].chan2 >= avctx->channels) {
+av_log(avctx, AV_LOG_ERROR,
+ "invalid channel 2 (%d) for %d
channel(s)\n",
+ s->mcdparams[i].chan2, avctx->channels);
+return AVERROR_INVALIDDATA;
+}
if (s->mcdparams[i].index == 1) {
if ((nbit == s->mcdparams[i].chan2) ||
(ch_mask & 1 << s->mcdparams[i].chan2))
--
2.1.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] h264: update avctx width/height when flushing
Inconsistencies between the dimensions of avctx and the frame can
confuse API users. For example this can crash the demuxing_decoding
example.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/h264.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 9a00214..d1eaa5e 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -1757,6 +1757,8 @@ static int h264_decode_frame(AVCodecContext *avctx, void
*data,
if (ret < 0)
return ret;
*got_frame = 1;
+avctx->width = pict->width;
+avctx->height = pict->height;
}
return buf_index;
@@ -1830,6 +1832,8 @@ static int h264_decode_frame(AVCodecContext *avctx, void
*data,
if (ret < 0)
return ret;
*got_frame = 1;
+avctx->width = pict->width;
+avctx->height = pict->height;
if (CONFIG_MPEGVIDEO) {
ff_print_debug_info2(h->avctx, pict, NULL,
h->next_output_pic->mb_type,
--
2.1.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: Provide an option to override the environment
On Tue, 9 Jun 2015, Diego Biurrun wrote: On Wed, Jun 03, 2015 at 08:49:00PM +0300, Martin Storsjö wrote: On Wed, 3 Jun 2015, Diego Biurrun wrote: >On Tue, May 12, 2015 at 01:24:40PM +0300, Martin Storsjö wrote: >>On Tue, 12 May 2015, Diego Biurrun wrote: >>>On Tue, May 12, 2015 at 12:34:25AM +0200, Luca Barbato wrote: On 11/05/15 23:09, Diego Biurrun wrote: >On Wed, May 06, 2015 at 01:37:31PM +0200, Luca Barbato wrote: >>Useful to have `make config` work with custom pkgconf path. >>--- >> configure | 6 ++ >> 1 file changed, 6 insertions(+) > >Foo=value1 BAR=value2 /path/to/configure ... See the patch comment. the idea is to provide a mean to configure once and then just do make config to reconfigure. >>> >>>This will only work if you happen to reconfigure inside the same shell >>>where the exports still exist. >> >>I'm not sure what you're trying to say here - yes, if you don't do things as >>in this patch, you'd need to set up the variables again. With this patch, >>the configure parameters that are saved in config.mak, which are reused in >>"make config", would persist this environment assuming that the user (me) >>would use it for setting them. >> >>>This is a brittle hack and should be done outside of configure. >> >>Hack? Yes, maybe - also convenient. Brittle in which way? > >For starters, what happens if no env is provided? What's with >quoting? You mean that the actual implementation of the patch isn't perfect yet - yes, one such issue was fixed - is there anything else concrete that you notice? I think quoting is broken, as might be whitespace treatment. I'd have to study in detail. Ok, that's a response I can relate to. What I can say is that it smells like a far too naive approach to a problem that is decidedly less trivial than it seems. Possibly So instead of running that script manually, why not pimp up your cd command to set up the environment for you? Add the following shell alias alias cd=mycd.sh and then the following shell script #!/bin/sh case $@ in /path/to/repo1) export ENV1=value1 export ENV2=value2 cd $@ ;; /path/to/repo2) export ENV1=othervalue1 export ENV2=othervalue2 cd $@ ;; [...] *) cd $@ ;; esac That should do the trick. Sure, it probably would. I don't particularly like this approach, but mostly for subjective reasons. If that's the alternative, I'll rather keep doing things as I do right now. (much more elegantly than autotools, where I'd love to have the same "make config" feature as libav has). I'm not sure what you are missing; autotools does automatically rerun configure if necessary, unlike our build system. Yes, that it does, but it lacks a command for me to manually trigger a reconfigure with the same parameters (e.g. when something else has changed, not the configure script or makefiles themselves). Also, with autoconf I often end up needing to set CC and CFLAGS via the env, which are lost in the process when reconfiguring later - on an automatic reconfigure they might not be set, while our configure can persist them nicely when they are set via --extra-cflags and --cc instead of picked from the env. // Martin ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/5] txd: Use the TextureDSP module for decoding
On 04/06/15 20:48, Vittorio Giovara wrote: > On Fri, May 29, 2015 at 7:41 PM, Vittorio Giovara > wrote: >> Using the internal DXTC routines brings support for non multiple of 4 >> textures. A new test is added to cover this feature. Hashes differ >> since the decoding algorithm is different, though no visual changes >> have been spotted. >> >> Signed-off-by: Vittorio Giovara >> --- >> No changes. > > ping > Fine for me. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: Provide an option to override the environment
On Wed, Jun 03, 2015 at 08:49:00PM +0300, Martin Storsjö wrote: > On Wed, 3 Jun 2015, Diego Biurrun wrote: > >On Tue, May 12, 2015 at 01:24:40PM +0300, Martin Storsjö wrote: > >>On Tue, 12 May 2015, Diego Biurrun wrote: > >>>On Tue, May 12, 2015 at 12:34:25AM +0200, Luca Barbato wrote: > On 11/05/15 23:09, Diego Biurrun wrote: > >On Wed, May 06, 2015 at 01:37:31PM +0200, Luca Barbato wrote: > >>Useful to have `make config` work with custom pkgconf path. > >>--- > >> configure | 6 ++ > >> 1 file changed, 6 insertions(+) > > > >Foo=value1 BAR=value2 /path/to/configure ... > > See the patch comment. the idea is to provide a mean to configure once > and then just do make config to reconfigure. > >>> > >>>This will only work if you happen to reconfigure inside the same shell > >>>where the exports still exist. > >> > >>I'm not sure what you're trying to say here - yes, if you don't do things as > >>in this patch, you'd need to set up the variables again. With this patch, > >>the configure parameters that are saved in config.mak, which are reused in > >>"make config", would persist this environment assuming that the user (me) > >>would use it for setting them. > >> > >>>This is a brittle hack and should be done outside of configure. > >> > >>Hack? Yes, maybe - also convenient. Brittle in which way? > > > >For starters, what happens if no env is provided? What's with > >quoting? > > You mean that the actual implementation of the patch isn't perfect yet - > yes, one such issue was fixed - is there anything else concrete that you > notice? I think quoting is broken, as might be whitespace treatment. I'd have to study in detail. What I can say is that it smells like a far too naive approach to a problem that is decidedly less trivial than it seems. > >>>Just run a short shell script that sets up your environment as you need > >>>it. > >> > >>That's what I do today, but Luca suggested this to ease my (and apparently > >>his) workflow. > >> > >>When you have literally dozens of different configurations, all with > >>potentially different buildroots, I prefer libs which are detected via plain > >>cflags/ldflags over pkg-config, because for cflags/ldflags I can set > >>--extra-cflags=-I/some/build/root/include etc, and when I need to > >>reconfigure, I just do "make config". > >> > >>With pkg-config, I need to run the right shell script to set up > >>PKG_CONFIG_LIBDIR/PKG_CONFIG_PATH for this particular configuration, which > >>is one step more than when relying solely on configure parameters (such as > >>--extra-cflags) that are brought in automatically when doing "make config". > > > >No need to run the right shell script, just do something like > > > >#!/bin/sh > > > >case $(pwd) in > > /path/to/repo1) > >[snip] > > My point wasn't so much about having to run the _right_ script, but about > having to run _a_ script (for the cases where I don't need to add things to > $PATH). > > When I need to retest one specific configuration, my workflow normally is > "cd libav-fooconfig; make -jX", which might fail since it needs to > reconfigure. If it failed for such a reason, I run "make config". And this > fails since I had forgotten to source the env script, which I only need > while running configure, not while building, and only in the configurations > where I use external libs that use pkg-config. > > For the cases where I need to add things to $PATH, I can't do make without > it, so in those cases it really isn't an issue. It's just to allow > encapsulating the environment that configure needs for running, to allow > rerunning "make config" without any extra setup. So instead of running that script manually, why not pimp up your cd command to set up the environment for you? Add the following shell alias alias cd=mycd.sh and then the following shell script #!/bin/sh case $@ in /path/to/repo1) export ENV1=value1 export ENV2=value2 cd $@ ;; /path/to/repo2) export ENV1=othervalue1 export ENV2=othervalue2 cd $@ ;; [...] *) cd $@ ;; esac That should do the trick. > >>To this, Luca investigated and noted that pkg-config lacks a command line > >>parameter that does the equivalent of setting PKG_CONFIG_LIBDIR/PATH, so it > >>really has to be set via the environment (otherwise it could be brought in > >>via --pkg-config-flags). By allowing preserving the extra environment > >>variables that need to be set while configuring in a configure parameter, it > >>can all be rerun via a plain "make config", which would simplify my workflow > >>a little bit. Yes, it's not much, running a shell script is no huge task, > >>but when it's something you do often, it would reduce the burden. > >> > >>For cases where I need to add some particular cross-env's bin dir to $PATH, > >>I would still need to keep using a env setup shellscript (because the > >>suggested configure parameter would only work within configure, not within > >>make),
Re: [libav-devel] [PATCH 1/1] movenc: fixes a questionable valgrind uninitialized value warning
On Tue, Jun 9, 2015 at 12:46 PM, Janne Grunau wrote: > display_matrix_size is only initialized when av_stream_get_side_data() > returns a side data pointer. The code is safe since the only effect this > has is setting the display_matrix pointer to NULL which it was already > anyway. > --- > libavformat/movenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/movenc.c b/libavformat/movenc.c > index 30d397a..761c3e8 100644 > --- a/libavformat/movenc.c > +++ b/libavformat/movenc.c > @@ -1518,7 +1518,7 @@ static int mov_write_tkhd_tag(AVIOContext *pb, > MOVMuxContext *mov, > > display_matrix = (uint32_t*)av_stream_get_side_data(st, > AV_PKT_DATA_DISPLAYMATRIX, > > &display_matrix_size); > -if (display_matrix_size < 9 * sizeof(*display_matrix)) > +if (display_matrix && display_matrix_size < 9 * > sizeof(*display_matrix)) > display_matrix = NULL; > } > > -- > 2.4.2 ok if you want -- Vittorio ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/1] movenc: fixes a questionable valgrind uninitialized value warning
display_matrix_size is only initialized when av_stream_get_side_data() returns a side data pointer. The code is safe since the only effect this has is setting the display_matrix pointer to NULL which it was already anyway. --- libavformat/movenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index 30d397a..761c3e8 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -1518,7 +1518,7 @@ static int mov_write_tkhd_tag(AVIOContext *pb, MOVMuxContext *mov, display_matrix = (uint32_t*)av_stream_get_side_data(st, AV_PKT_DATA_DISPLAYMATRIX, &display_matrix_size); -if (display_matrix_size < 9 * sizeof(*display_matrix)) +if (display_matrix && display_matrix_size < 9 * sizeof(*display_matrix)) display_matrix = NULL; } -- 2.4.2 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mkv: Correctly report the latest packet had been flushed
On Tue, Jun 9, 2015 at 10:52 AM, Luca Barbato wrote: > Bug-Id: 865 > CC: libav-sta...@libav.org > --- > > robUx4 I want your opinion about it. > > libavformat/matroskaenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c > index 91c4459..b1c0020 100644 > --- a/libavformat/matroskaenc.c > +++ b/libavformat/matroskaenc.c > @@ -1630,7 +1630,7 @@ static int mkv_write_flush_packet(AVFormatContext *s, > AVPacket *pkt) > mkv_flush_dynbuf(s); > avio_flush(s->pb); > } > -return 0; > +return 1; > } > return mkv_write_packet(s, pkt); > } LGTM. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] mkv: Correctly report the latest packet had been flushed
Bug-Id: 865 CC: libav-sta...@libav.org --- robUx4 I want your opinion about it. libavformat/matroskaenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c index 91c4459..b1c0020 100644 --- a/libavformat/matroskaenc.c +++ b/libavformat/matroskaenc.c @@ -1630,7 +1630,7 @@ static int mkv_write_flush_packet(AVFormatContext *s, AVPacket *pkt) mkv_flush_dynbuf(s); avio_flush(s->pb); } -return 0; +return 1; } return mkv_write_packet(s, pkt); } -- 1.9.0 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] lavf: add a format flag for separate carriers, and an event for detecting carrier presence.
On 08/06/15 11:28, John Högberg wrote: >> PS: The spring^Wsummer Sprint will be almost surely held in Stockholm, if you >> are close and you want to drop by would be great =) > > When? I'll see if I can make it. 26-29 June, some details [here](https://wiki.libav.org/Sprint/201506) lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
