Re: [libav-devel] ABI compatiblity with ffmpeg
On 9/6/2015 5:56 PM, Ganesh Ajjanagadde wrote: > Hi all, > > I am speaking on behalf of ffmpeg here regarding the question of ABI Speaking on behalf of the project would have at least required asking other devs if they were ok with that first. > compatibility with ffmpeg. Recent patch: > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178480.html > and other discussion reflects a change in policy of ffmpeg; with most > devs in ffmpeg not caring about ABI compatibility with libav anymore. There has been no change in any policy yet, just an attempt to put it in the agenda. I made sure that for the time being compatibility is still in place, and it will remain as such until an actual consensus is reached. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
On Mon, 07 Sep 2015 12:59:52 +0200 ni...@lysator.liu.se (Niels Möller) wrote: > Vittorio Giovara writes: > > > if (desc->flags & AV_PIX_FMT_FLAG_GRAY) > > > > is much simpler, more concise, and more correct than > > > > if ((desc->nb_components == 1 || (desc->nb_components == 2 && > > desc->flags & AV_PIX_FMT_FLAG_ALPHA) && !(desc->flags & > > AV_PIX_FMT_FLAG_RGB)) > > > > don't you think? ^_* > > Sure, but AV_PIX_FMT_IS_GRAY(desc) would be concise too. One can have > redundant interfaces with extra sugar, without putting redundant data in > the data structures. > > Happy hacking, > /Niels > As long as there's no meaning associated with each component descriptor in the pixfmt descriptor, it's definitely not redundant. A AV_PIX_FMT_IS_GRAY(desc) would encode internal knowledge about the pixel format into the ABI, which is definitely not what you want. (Provided that it'd be a macro.) ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] codec_desc: Add missing DXV entry
On 07/09/15 17:02, Vittorio Giovara wrote:
> ---
> reported by nevcariel.
> vittorio
>
> libavcodec/codec_desc.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 0919a89..c1be40b 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1155,6 +1155,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
> .long_name = NULL_IF_CONFIG_SMALL("Vidvox Hap decoder"),
> .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
> },
> +{
> +.id= AV_CODEC_ID_DXV,
> +.type = AVMEDIA_TYPE_VIDEO,
> +.name = "dxv",
> +.long_name = NULL_IF_CONFIG_SMALL("Resolume DXV"),
> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
> +},
>
> /* image codecs */
> {
>
Ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] codec_desc: Add missing DXV entry
---
reported by nevcariel.
vittorio
libavcodec/codec_desc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 0919a89..c1be40b 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1155,6 +1155,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("Vidvox Hap decoder"),
.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
},
+{
+.id= AV_CODEC_ID_DXV,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "dxv",
+.long_name = NULL_IF_CONFIG_SMALL("Resolume DXV"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
+},
/* image codecs */
{
--
1.9.5 (Apple Git-50.3)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] ABI compatiblity with ffmpeg
On Mon, Sep 7, 2015 at 12:06 AM, Anton Khirnov wrote: > > Quoting Ganesh Ajjanagadde (2015-09-06 22:56:57) > > Hi all, > > > > I am speaking on behalf of ffmpeg here regarding the question of ABI > > compatibility with ffmpeg. Recent patch: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178480.html > > and other discussion reflects a change in policy of ffmpeg; with most > > devs in ffmpeg not caring about ABI compatibility with libav anymore. > > > > I am writing this to get opinions from the libav side, as expressed in: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178527.html > > (later messages in the same thread). > > ubitux is right there, Libav never tried or wanted to have any kind of > compatibility. Thanks. > > -- > Anton Khirnov > ___ > libav-devel mailing list > libav-devel@libav.org > https://lists.libav.org/mailman/listinfo/libav-devel ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
On 07/09/15 14:27, Anton Khirnov wrote: > Ideally though we would transition to something like Kostya's > pixformaton thing, with an explicit descriptor field that would tell you > whether the colorspace is YUV, RGB or whatever. I'll get something along those lines "soonish" (depending on how many bugs I got to fix for $dayjob). lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
On 07/09/15 14:06, Anton Khirnov wrote: > Quoting Vittorio Giovara (2015-09-07 13:54:02) >> On Mon, Sep 7, 2015 at 1:12 PM, Hendrik Leppkes wrote: by that reasoning we should drop AV_PIX_FMT_FLAG_RGB and just do if (strstr(pix_fmt, "rgb") || strstr(pix_fmt, "bgr")) sometimes you need redundant data for consistency and for simpler interfaces, without having N different ways to access the same kind of information, in my opinion >>> >>> Now you're just being silly. >> >> I was rather being sarcastic, it's silly to discuss over a simple 1bit flag. >> >> I can see the point that macros are "useful" to hide the complexity of >> the test, but an interface to check for this kind of thing already >> exists (flags) and the downside of public macros is that you need to >> document, maintain and make sure the new interfaces work. >> >> I insist that a single bitwise check is simpler to understand, use and >> support for users and devs alike. > > The argument is not over one bit, but whether we want to store redundant > information in the descriptor. Having the bit there introduces the > possibility of doing it wrong, by someone adding a new format, but > forgetting to set the flag. So I'd say a function (not a macro, because > that inlines the logic in the caller and that is better avoided) is > preferable. > Surely having a strong interface (as a function) is probably a good idea. Yet the fact you have 1 channel or 2 of which one is alpha doesn't deliver by itself that the channel is gray per-se. I doubt I'll ever write the code for the IR channel enough cameras and film scanner do support, but it does exist =) Anyway the consensus seems to be not to add the GRAY flag. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
On Mon, Sep 7, 2015 at 2:27 PM, Anton Khirnov wrote: > Quoting Vittorio Giovara (2015-09-07 14:20:20) >> On Mon, Sep 7, 2015 at 2:06 PM, Anton Khirnov wrote: >> > Quoting Vittorio Giovara (2015-09-07 13:54:02) >> >> On Mon, Sep 7, 2015 at 1:12 PM, Hendrik Leppkes >> >> wrote: >> >> >> by that reasoning we should drop AV_PIX_FMT_FLAG_RGB and just do >> >> >> >> >> >> if (strstr(pix_fmt, "rgb") || strstr(pix_fmt, "bgr")) >> >> >> >> >> >> sometimes you need redundant data for consistency and for simpler >> >> >> interfaces, without having N different ways to access the same kind of >> >> >> information, in my opinion >> >> > >> >> > Now you're just being silly. >> >> >> >> I was rather being sarcastic, it's silly to discuss over a simple 1bit >> >> flag. >> >> >> >> I can see the point that macros are "useful" to hide the complexity of >> >> the test, but an interface to check for this kind of thing already >> >> exists (flags) and the downside of public macros is that you need to >> >> document, maintain and make sure the new interfaces work. >> >> >> >> I insist that a single bitwise check is simpler to understand, use and >> >> support for users and devs alike. >> > >> > The argument is not over one bit, but whether we want to store redundant >> > information in the descriptor. Having the bit there introduces the >> > possibility of doing it wrong, by someone adding a new format, but >> > forgetting to set the flag. So I'd say a function (not a macro, because >> > that inlines the logic in the caller and that is better avoided) is >> > preferable. >> >> Yes, but my point is that having a single function to only check for a >> single color space (gray) is not ideal either. >> > > In the current pixfmt model, gray is not a special colorspace, but just > YUV with U and V missing. I am not at all against having > av_pix_fmt_is_yuv()/av_pix_fmt_is_rgb() functions. > > Ideally though we would transition to something like Kostya's > pixformaton thing, with an explicit descriptor field that would tell you > whether the colorspace is YUV, RGB or whatever. Meh ok, let's hold this one off for now, hopefully Niels or Hendrik will step in and give us a hand for either solution. -- Vittorio ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
Quoting Vittorio Giovara (2015-09-07 14:20:20) > On Mon, Sep 7, 2015 at 2:06 PM, Anton Khirnov wrote: > > Quoting Vittorio Giovara (2015-09-07 13:54:02) > >> On Mon, Sep 7, 2015 at 1:12 PM, Hendrik Leppkes > >> wrote: > >> >> by that reasoning we should drop AV_PIX_FMT_FLAG_RGB and just do > >> >> > >> >> if (strstr(pix_fmt, "rgb") || strstr(pix_fmt, "bgr")) > >> >> > >> >> sometimes you need redundant data for consistency and for simpler > >> >> interfaces, without having N different ways to access the same kind of > >> >> information, in my opinion > >> > > >> > Now you're just being silly. > >> > >> I was rather being sarcastic, it's silly to discuss over a simple 1bit > >> flag. > >> > >> I can see the point that macros are "useful" to hide the complexity of > >> the test, but an interface to check for this kind of thing already > >> exists (flags) and the downside of public macros is that you need to > >> document, maintain and make sure the new interfaces work. > >> > >> I insist that a single bitwise check is simpler to understand, use and > >> support for users and devs alike. > > > > The argument is not over one bit, but whether we want to store redundant > > information in the descriptor. Having the bit there introduces the > > possibility of doing it wrong, by someone adding a new format, but > > forgetting to set the flag. So I'd say a function (not a macro, because > > that inlines the logic in the caller and that is better avoided) is > > preferable. > > Yes, but my point is that having a single function to only check for a > single color space (gray) is not ideal either. > In the current pixfmt model, gray is not a special colorspace, but just YUV with U and V missing. I am not at all against having av_pix_fmt_is_yuv()/av_pix_fmt_is_rgb() functions. Ideally though we would transition to something like Kostya's pixformaton thing, with an explicit descriptor field that would tell you whether the colorspace is YUV, RGB or whatever. -- Anton Khirnov ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
On Mon, Sep 7, 2015 at 2:06 PM, Anton Khirnov wrote: > Quoting Vittorio Giovara (2015-09-07 13:54:02) >> On Mon, Sep 7, 2015 at 1:12 PM, Hendrik Leppkes wrote: >> >> by that reasoning we should drop AV_PIX_FMT_FLAG_RGB and just do >> >> >> >> if (strstr(pix_fmt, "rgb") || strstr(pix_fmt, "bgr")) >> >> >> >> sometimes you need redundant data for consistency and for simpler >> >> interfaces, without having N different ways to access the same kind of >> >> information, in my opinion >> > >> > Now you're just being silly. >> >> I was rather being sarcastic, it's silly to discuss over a simple 1bit flag. >> >> I can see the point that macros are "useful" to hide the complexity of >> the test, but an interface to check for this kind of thing already >> exists (flags) and the downside of public macros is that you need to >> document, maintain and make sure the new interfaces work. >> >> I insist that a single bitwise check is simpler to understand, use and >> support for users and devs alike. > > The argument is not over one bit, but whether we want to store redundant > information in the descriptor. Having the bit there introduces the > possibility of doing it wrong, by someone adding a new format, but > forgetting to set the flag. So I'd say a function (not a macro, because > that inlines the logic in the caller and that is better avoided) is > preferable. Yes, but my point is that having a single function to only check for a single color space (gray) is not ideal either. Can you think of users reading the flag "check flag&RGB to see if pixel format is rgb, check flag&ALPHA to see if pixel format has alpha, but where is the check for gray? oh i have to check for number of components or call a function, let's read documentation there too... [skip to a different section of the documentation] hmm this function checks if pixel format is gray" it's terribly inconsistent and the likelihood of someone forgetting to add the bitmask for a new format is the same for rgb too, and yet that hasn't prevented the flag check to be the standard way to check for rgb -- Vittorio ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
Quoting Vittorio Giovara (2015-09-07 13:54:02) > On Mon, Sep 7, 2015 at 1:12 PM, Hendrik Leppkes wrote: > >> by that reasoning we should drop AV_PIX_FMT_FLAG_RGB and just do > >> > >> if (strstr(pix_fmt, "rgb") || strstr(pix_fmt, "bgr")) > >> > >> sometimes you need redundant data for consistency and for simpler > >> interfaces, without having N different ways to access the same kind of > >> information, in my opinion > > > > Now you're just being silly. > > I was rather being sarcastic, it's silly to discuss over a simple 1bit flag. > > I can see the point that macros are "useful" to hide the complexity of > the test, but an interface to check for this kind of thing already > exists (flags) and the downside of public macros is that you need to > document, maintain and make sure the new interfaces work. > > I insist that a single bitwise check is simpler to understand, use and > support for users and devs alike. The argument is not over one bit, but whether we want to store redundant information in the descriptor. Having the bit there introduces the possibility of doing it wrong, by someone adding a new format, but forgetting to set the flag. So I'd say a function (not a macro, because that inlines the logic in the caller and that is better avoided) is preferable. -- Anton Khirnov ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
On Mon, Sep 7, 2015 at 1:12 PM, Hendrik Leppkes wrote: >> by that reasoning we should drop AV_PIX_FMT_FLAG_RGB and just do >> >> if (strstr(pix_fmt, "rgb") || strstr(pix_fmt, "bgr")) >> >> sometimes you need redundant data for consistency and for simpler >> interfaces, without having N different ways to access the same kind of >> information, in my opinion > > Now you're just being silly. I was rather being sarcastic, it's silly to discuss over a simple 1bit flag. I can see the point that macros are "useful" to hide the complexity of the test, but an interface to check for this kind of thing already exists (flags) and the downside of public macros is that you need to document, maintain and make sure the new interfaces work. I insist that a single bitwise check is simpler to understand, use and support for users and devs alike. -- Vittorio ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
On 07/09/15 12:59, Niels Möller wrote: > Vittorio Giovara writes: > >> if (desc->flags & AV_PIX_FMT_FLAG_GRAY) >> >> is much simpler, more concise, and more correct than >> >> if ((desc->nb_components == 1 || (desc->nb_components == 2 && >> desc->flags & AV_PIX_FMT_FLAG_ALPHA) && !(desc->flags & >> AV_PIX_FMT_FLAG_RGB)) >> >> don't you think? ^_* > > Sure, but AV_PIX_FMT_IS_GRAY(desc) would be concise too. One can have > redundant interfaces with extra sugar, without putting redundant data in > the data structures. > > Happy hacking, > /Niels > I'm looking forward to see a patch the AV_PIX_FMT_IS_*() macros from you. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
On 07/09/15 13:12, Hendrik Leppkes wrote: > On Mon, Sep 7, 2015 at 1:11 PM, Vittorio Giovara > wrote: >> On Mon, Sep 7, 2015 at 1:10 PM, Hendrik Leppkes wrote: >>> On Mon, Sep 7, 2015 at 12:59 PM, Niels Möller wrote: Vittorio Giovara writes: > if (desc->flags & AV_PIX_FMT_FLAG_GRAY) > > is much simpler, more concise, and more correct than > > if ((desc->nb_components == 1 || (desc->nb_components == 2 && > desc->flags & AV_PIX_FMT_FLAG_ALPHA) && !(desc->flags & > AV_PIX_FMT_FLAG_RGB)) > > don't you think? ^_* Sure, but AV_PIX_FMT_IS_GRAY(desc) would be concise too. One can have redundant interfaces with extra sugar, without putting redundant data in the data structures. >>> >>> I agree. >> >> by that reasoning we should drop AV_PIX_FMT_FLAG_RGB and just do >> >> if (strstr(pix_fmt, "rgb") || strstr(pix_fmt, "bgr")) >> >> sometimes you need redundant data for consistency and for simpler >> interfaces, without having N different ways to access the same kind of >> information, in my opinion > > Now you're just being silly. The whole discussion over 1bit is silly. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
On Mon, Sep 7, 2015 at 1:11 PM, Vittorio Giovara wrote: > On Mon, Sep 7, 2015 at 1:10 PM, Hendrik Leppkes wrote: >> On Mon, Sep 7, 2015 at 12:59 PM, Niels Möller wrote: >>> Vittorio Giovara writes: >>> if (desc->flags & AV_PIX_FMT_FLAG_GRAY) is much simpler, more concise, and more correct than if ((desc->nb_components == 1 || (desc->nb_components == 2 && desc->flags & AV_PIX_FMT_FLAG_ALPHA) && !(desc->flags & AV_PIX_FMT_FLAG_RGB)) don't you think? ^_* >>> >>> Sure, but AV_PIX_FMT_IS_GRAY(desc) would be concise too. One can have >>> redundant interfaces with extra sugar, without putting redundant data in >>> the data structures. >>> >> >> I agree. > > by that reasoning we should drop AV_PIX_FMT_FLAG_RGB and just do > > if (strstr(pix_fmt, "rgb") || strstr(pix_fmt, "bgr")) > > sometimes you need redundant data for consistency and for simpler > interfaces, without having N different ways to access the same kind of > information, in my opinion Now you're just being silly. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
On Mon, Sep 7, 2015 at 1:10 PM, Hendrik Leppkes wrote: > On Mon, Sep 7, 2015 at 12:59 PM, Niels Möller wrote: >> Vittorio Giovara writes: >> >>> if (desc->flags & AV_PIX_FMT_FLAG_GRAY) >>> >>> is much simpler, more concise, and more correct than >>> >>> if ((desc->nb_components == 1 || (desc->nb_components == 2 && >>> desc->flags & AV_PIX_FMT_FLAG_ALPHA) && !(desc->flags & >>> AV_PIX_FMT_FLAG_RGB)) >>> >>> don't you think? ^_* >> >> Sure, but AV_PIX_FMT_IS_GRAY(desc) would be concise too. One can have >> redundant interfaces with extra sugar, without putting redundant data in >> the data structures. >> > > I agree. by that reasoning we should drop AV_PIX_FMT_FLAG_RGB and just do if (strstr(pix_fmt, "rgb") || strstr(pix_fmt, "bgr")) sometimes you need redundant data for consistency and for simpler interfaces, without having N different ways to access the same kind of information, in my opinion Cheers -- Vittorio ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
On Mon, Sep 7, 2015 at 12:59 PM, Niels Möller wrote: > Vittorio Giovara writes: > >> if (desc->flags & AV_PIX_FMT_FLAG_GRAY) >> >> is much simpler, more concise, and more correct than >> >> if ((desc->nb_components == 1 || (desc->nb_components == 2 && >> desc->flags & AV_PIX_FMT_FLAG_ALPHA) && !(desc->flags & >> AV_PIX_FMT_FLAG_RGB)) >> >> don't you think? ^_* > > Sure, but AV_PIX_FMT_IS_GRAY(desc) would be concise too. One can have > redundant interfaces with extra sugar, without putting redundant data in > the data structures. > I agree. PS: RGB is 3 components, even if packed. It doesn't count planes, but actual components. - Hendrik ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
Vittorio Giovara writes: > if (desc->flags & AV_PIX_FMT_FLAG_GRAY) > > is much simpler, more concise, and more correct than > > if ((desc->nb_components == 1 || (desc->nb_components == 2 && > desc->flags & AV_PIX_FMT_FLAG_ALPHA) && !(desc->flags & > AV_PIX_FMT_FLAG_RGB)) > > don't you think? ^_* Sure, but AV_PIX_FMT_IS_GRAY(desc) would be concise too. One can have redundant interfaces with extra sugar, without putting redundant data in the data structures. Happy hacking, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
On Mon, Sep 7, 2015 at 12:06 PM, Hendrik Leppkes wrote: > On Mon, Sep 7, 2015 at 11:44 AM, Vittorio Giovara > wrote: >> On Mon, Sep 7, 2015 at 9:13 AM, Anton Khirnov wrote: >>> Quoting Vittorio Giovara (2015-09-02 18:59:40) Applications can now detect rgb/yuv/gray/mono color types just by looking at pixdesc.flags. >>> >>> Can't you do it already by checking that the pixfmt is single component >>> and not rgb? >> >> you also have gray with alpha which is is two components > > So check if its one component, or two and has the alpha flag? =p if (desc->flags & AV_PIX_FMT_FLAG_GRAY) is much simpler, more concise, and more correct than if ((desc->nb_components == 1 || (desc->nb_components == 2 && desc->flags & AV_PIX_FMT_FLAG_ALPHA) && !(desc->flags & AV_PIX_FMT_FLAG_RGB)) don't you think? ^_* -- Vittorio ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] asfdec: add more checks for size left in asf packet buffer
---
libavformat/asfdec.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/asfdec.c b/libavformat/asfdec.c
index b7b8d6c..a39f6d4 100644
--- a/libavformat/asfdec.c
+++ b/libavformat/asfdec.c
@@ -1141,7 +1141,7 @@ static int asf_read_replicated_data(AVFormatContext *s,
ASFPacket *asf_pkt)
if (!asf_pkt->data_size) {
asf_pkt->data_size = asf_pkt->size_left = avio_rl32(pb); // read media
object size
if (asf_pkt->data_size <= 0)
-return AVERROR_EOF;
+return AVERROR_INVALIDDATA;
if ((ret = av_new_packet(&asf_pkt->avpkt, asf_pkt->data_size)) < 0)
return ret;
} else
@@ -1190,6 +1190,8 @@ static int asf_read_multiple_payload(AVFormatContext *s,
AVPacket *pkt,
skip = pay_len - asf_pkt->size_left;
pay_len = asf_pkt->size_left;
}
+if (asf_pkt->size_left <= 0)
+return AVERROR_INVALIDDATA;
if ((ret = avio_read(pb, p, pay_len)) < 0)
return ret;
if (s->key && s->keylen == 20)
@@ -1237,7 +1239,7 @@ static int asf_read_single_payload(AVFormatContext *s,
AVPacket *pkt,
return AVERROR_INVALIDDATA;
}
p = asf_pkt->avpkt.data + asf_pkt->data_size - asf_pkt->size_left;
-if (size > asf_pkt->size_left)
+if (size > asf_pkt->size_left || asf_pkt->size_left <= 0)
return AVERROR_INVALIDDATA;
if (asf_pkt->size_left > size)
asf_pkt->size_left -= size;
--
2.0.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] asfdec: add more checks for size left in asf packet buffer
On Mon, Sep 7, 2015 at 12:08 PM, Alexandra Hájková
wrote:
> ---
> libavformat/asfdec.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/asfdec.c b/libavformat/asfdec.c
> index b7b8d6c..f7d8859 100644
> --- a/libavformat/asfdec.c
> +++ b/libavformat/asfdec.c
> @@ -1141,7 +1141,7 @@ static int asf_read_replicated_data(AVFormatContext *s,
> ASFPacket *asf_pkt)
> if (!asf_pkt->data_size) {
> asf_pkt->data_size = asf_pkt->size_left = avio_rl32(pb); // read
> media object size
> if (asf_pkt->data_size <= 0)
> -return AVERROR_EOF;
> +return AVERROR_INVALIDDATA;
> if ((ret = av_new_packet(&asf_pkt->avpkt, asf_pkt->data_size)) < 0)
> return ret;
> } else
> @@ -1190,6 +1190,8 @@ static int asf_read_multiple_payload(AVFormatContext
> *s, AVPacket *pkt,
> skip = pay_len - asf_pkt->size_left;
> pay_len = asf_pkt->size_left;
> }
> +if (asf_pkt->size_left <= 0)
> +return AVERROR_INVALIDDATA;
> if ((ret = avio_read(pb, p, pay_len)) < 0)
> return ret;
> if (s->key && s->keylen == 20)
> @@ -1237,13 +1239,13 @@ static int asf_read_single_payload(AVFormatContext
> *s, AVPacket *pkt,
> return AVERROR_INVALIDDATA;
> }
> p = asf_pkt->avpkt.data + asf_pkt->data_size - asf_pkt->size_left;
> -if (size > asf_pkt->size_left)
> +if (size > asf_pkt->size_left || asf_pkt->size_left <= 0)
> return AVERROR_INVALIDDATA;
> if (asf_pkt->size_left > size)
> asf_pkt->size_left -= size;
> else
> asf_pkt->size_left = 0;
> -if ((ret = avio_read(pb, p, size)) < 0)
> + if ((ret = avio_read(pb, p, size)) < 0)
Unrelated/wrong re-indent?
> return ret;
> if (s->key && s->keylen == 20)
> ff_asfcrypt_dec(s->key, p, ret);
> --
> 2.0.1
>
> ___
> libav-devel mailing list
> libav-devel@libav.org
> https://lists.libav.org/mailman/listinfo/libav-devel
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] asfdec: add more checks for size left in asf packet buffer
---
libavformat/asfdec.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavformat/asfdec.c b/libavformat/asfdec.c
index b7b8d6c..f7d8859 100644
--- a/libavformat/asfdec.c
+++ b/libavformat/asfdec.c
@@ -1141,7 +1141,7 @@ static int asf_read_replicated_data(AVFormatContext *s,
ASFPacket *asf_pkt)
if (!asf_pkt->data_size) {
asf_pkt->data_size = asf_pkt->size_left = avio_rl32(pb); // read media
object size
if (asf_pkt->data_size <= 0)
-return AVERROR_EOF;
+return AVERROR_INVALIDDATA;
if ((ret = av_new_packet(&asf_pkt->avpkt, asf_pkt->data_size)) < 0)
return ret;
} else
@@ -1190,6 +1190,8 @@ static int asf_read_multiple_payload(AVFormatContext *s,
AVPacket *pkt,
skip = pay_len - asf_pkt->size_left;
pay_len = asf_pkt->size_left;
}
+if (asf_pkt->size_left <= 0)
+return AVERROR_INVALIDDATA;
if ((ret = avio_read(pb, p, pay_len)) < 0)
return ret;
if (s->key && s->keylen == 20)
@@ -1237,13 +1239,13 @@ static int asf_read_single_payload(AVFormatContext *s,
AVPacket *pkt,
return AVERROR_INVALIDDATA;
}
p = asf_pkt->avpkt.data + asf_pkt->data_size - asf_pkt->size_left;
-if (size > asf_pkt->size_left)
+if (size > asf_pkt->size_left || asf_pkt->size_left <= 0)
return AVERROR_INVALIDDATA;
if (asf_pkt->size_left > size)
asf_pkt->size_left -= size;
else
asf_pkt->size_left = 0;
-if ((ret = avio_read(pb, p, size)) < 0)
+ if ((ret = avio_read(pb, p, size)) < 0)
return ret;
if (s->key && s->keylen == 20)
ff_asfcrypt_dec(s->key, p, ret);
--
2.0.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
On Mon, Sep 7, 2015 at 11:44 AM, Vittorio Giovara wrote: > On Mon, Sep 7, 2015 at 9:13 AM, Anton Khirnov wrote: >> Quoting Vittorio Giovara (2015-09-02 18:59:40) >>> Applications can now detect rgb/yuv/gray/mono color types just >>> by looking at pixdesc.flags. >> >> Can't you do it already by checking that the pixfmt is single component >> and not rgb? > > you also have gray with alpha which is is two components So check if its one component, or two and has the alpha flag? =p ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
On 07/09/15 09:13, Anton Khirnov wrote: > Quoting Vittorio Giovara (2015-09-02 18:59:40) >> Applications can now detect rgb/yuv/gray/mono color types just >> by looking at pixdesc.flags. > > Can't you do it already by checking that the pixfmt is single component > and not rgb? > It is more uniform with a flag. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
On Mon, Sep 7, 2015 at 9:13 AM, Anton Khirnov wrote: > Quoting Vittorio Giovara (2015-09-02 18:59:40) >> Applications can now detect rgb/yuv/gray/mono color types just >> by looking at pixdesc.flags. > > Can't you do it already by checking that the pixfmt is single component > and not rgb? you also have gray with alpha which is is two components -- Vittorio ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mov: Allow more than one keyframe per trun
Quoting Martin Storsjö (2015-09-07 09:29:52) > On Mon, 7 Sep 2015, Anton Khirnov wrote: > > > Quoting Martin Storsjö (2015-09-05 19:33:39) > >> The previous restriction was partially designed to fix certain > >> (broken) samples from bug 215. There should be no restriction on the > >> number of keyframes per fragment or trun. > >> > > > > So what happens now to those broken samples? > > When the bug was filed, seeking failed completely, since there was no > keyframes at all. > > Now seeking succeeds (probably seeking to any frame), and the output still > is ok (since it probably doesn't output anything until it gets a proper > decodable frame anyway) - I just retested it. > > So the issue in bug 215 isn't broken again, but only behaves slightly > differently (possibly seeking to a different frame than before; possibly > even closer than before, if the file actually had more than one keyframe > per fragment). > Ok, sounds good to me then. -- Anton Khirnov ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mov: Allow more than one keyframe per trun
On Mon, 7 Sep 2015, Anton Khirnov wrote: Quoting Martin Storsjö (2015-09-05 19:33:39) The previous restriction was partially designed to fix certain (broken) samples from bug 215. There should be no restriction on the number of keyframes per fragment or trun. So what happens now to those broken samples? When the bug was filed, seeking failed completely, since there was no keyframes at all. Now seeking succeeds (probably seeking to any frame), and the output still is ok (since it probably doesn't output anything until it gets a proper decodable frame anyway) - I just retested it. So the issue in bug 215 isn't broken again, but only behaves slightly differently (possibly seeking to a different frame than before; possibly even closer than before, if the file actually had more than one keyframe per fragment). // Martin ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/4] lavu: Add grayscale pixel format flag
Quoting Vittorio Giovara (2015-09-02 18:59:40) > Applications can now detect rgb/yuv/gray/mono color types just > by looking at pixdesc.flags. Can't you do it already by checking that the pixfmt is single component and not rgb? -- Anton Khirnov ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/4] lavu: extend size of the AVPixFmtDescriptor.flags field
Quoting Vittorio Giovara (2015-09-02 18:59:37) > From: wm4 > > Signed-off-by: Vittorio Giovara > --- > I updated the lavu version reported to 55 (not sure if it was intentionally > left to 54 to mark the "unstable" tree phase). > Vittorio > > doc/APIchanges | 3 +++ > libavutil/pixdesc.h | 6 +- > 2 files changed, 8 insertions(+), 1 deletion(-) > > diff --git a/doc/APIchanges b/doc/APIchanges > index e500ac8..8f7d50d 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -13,6 +13,9 @@ libavutil: 2015-08-28 > > API changes, most recent first: > > +2015-xx-xx - lavu 55.0.0 > + xxx - Change type of AVPixFmtDescriptor.flags. Perhaps mention from what to what. so people don't have to look it up. -- Anton Khirnov ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] ABI compatiblity with ffmpeg
Quoting Ganesh Ajjanagadde (2015-09-06 22:56:57) > Hi all, > > I am speaking on behalf of ffmpeg here regarding the question of ABI > compatibility with ffmpeg. Recent patch: > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178480.html > and other discussion reflects a change in policy of ffmpeg; with most > devs in ffmpeg not caring about ABI compatibility with libav anymore. > > I am writing this to get opinions from the libav side, as expressed in: > https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178527.html > (later messages in the same thread). ubitux is right there, Libav never tried or wanted to have any kind of compatibility. -- Anton Khirnov ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] mov: Allow more than one keyframe per trun
Quoting Martin Storsjö (2015-09-05 19:33:39) > The previous restriction was partially designed to fix certain > (broken) samples from bug 215. There should be no restriction on the > number of keyframes per fragment or trun. > So what happens now to those broken samples? -- Anton Khirnov ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
