Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On 7/2/16, Vignesh Venkatasubramanian wrote: > On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje > wrote: >> Hi, >> >> On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje >> wrote: >> >>> Hi, >>> >>> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian < >>> vigneshv-at-google@ffmpeg.org> wrote: >>> On Fri, Jul 1, 2016 at 11:06 AM, James Almer wrote: > On 7/1/2016 2:53 PM, Ronald S. Bultje wrote: >> Hi, >> >> On Fri, Jul 1, 2016 at 1:40 PM, James Zern < jzern-at-google@ffmpeg.org> >> wrote: >> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos >>> wrote: > Do we have decoder support (for either vp8 or vp9) for these > files? No, only encoding and muxing. >>> >>> Seems like a feature request, but no reason to block this one if the >>> vp8 one is here. >> >> >> I'm not sure I have an opinion on this... But it feels strange to >> allow >> encoding of content we cannot decode. Being ffmpeg, how do we >> recommend >> people handle the files created with this feature, if not by using ffmpeg >> itself? One plausible reason is that Chrome can decode this. So it will be useful for people who already have ffmpeg in their pipelines and want to create such files. And like James Almer mentioned, this isn't a first. VP8 Alpha has been this way too. >>> >>> >>> The fact that something is the way it is, does not prove that it is >>> therefore right, or that we should therefore continue doing it that way >>> in >>> other cases. >>> >>> So you're suggesting that it is perfectly fine for people to use Chrome >>> as >>> decoder if FFmpeg is the encoder. What if people don't have Chrome >>> installed? Or what if they want a way of UI-less batch-processing such >>> files, e.g. what if a service like Youtube/Vimeo wants to allow upload of >>> vp8a/vp9a files without invoking Chrome for decoding? >>> >> >> Additional evidence in [1], [2]. >> >> There absolutely seems to be interest in support for vp8a/vp9a decoding >> outside Chrome. I'm not saying you should implement it in all multimedia >> frameworks ever created in human history, but doing it in one of them >> (e.g. >> ffmpeg, since it already supports encoding) certainly sounds helpful? >> > > I'm not saying alpha decoder shouldn't ever be implemented in ffmpeg. > I'm just saying that it shouldn't be a reason to block this patch. :) > Sorry if i wasn't clear before. The libvpx is used for both encoding and decoding, so it should be able to decode alpha planes and provide them to ffmpeg. Do you have idea how hard is adding decoding support this way? Can you do it? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
On 7/2/16, Ronald S. Bultje wrote: > Hi, > > On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian < > vigneshv-at-google@ffmpeg.org> wrote: > >> On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje >> wrote: >> > Hi, >> > >> > On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje >> wrote: >> > >> >> Hi, >> >> >> >> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian < >> >> vigneshv-at-google@ffmpeg.org> wrote: >> >> >> >>> On Fri, Jul 1, 2016 at 11:06 AM, James Almer >> wrote: >> >>> > On 7/1/2016 2:53 PM, Ronald S. Bultje wrote: >> >>> >> Hi, >> >>> >> >> >>> >> On Fri, Jul 1, 2016 at 1:40 PM, James Zern < >> >>> jzern-at-google@ffmpeg.org> >> >>> >> wrote: >> >>> >> >> >>> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos < >> ceho...@ag.or.at> >> >>> >>> wrote: >> >>> > Do we have decoder support (for either vp8 or vp9) for these >> files? >> >>> >> >>> No, only encoding and muxing. >> >>> >>> >> >>> >>> Seems like a feature request, but no reason to block this one if >> the >> >>> >>> vp8 one is here. >> >>> >> >> >>> >> >> >>> >> I'm not sure I have an opinion on this... But it feels strange to >> allow >> >>> >> encoding of content we cannot decode. Being ffmpeg, how do we >> recommend >> >>> >> people handle the files created with this feature, if not by using >> >>> ffmpeg >> >>> >> itself? >> >>> >> >>> One plausible reason is that Chrome can decode this. So it will be >> >>> useful for people who already have ffmpeg in their pipelines and want >> >>> to create such files. And like James Almer mentioned, this isn't a >> >>> first. VP8 Alpha has been this way too. >> >> >> >> >> >> The fact that something is the way it is, does not prove that it is >> >> therefore right, or that we should therefore continue doing it that way >> in >> >> other cases. >> >> >> >> So you're suggesting that it is perfectly fine for people to use Chrome >> as >> >> decoder if FFmpeg is the encoder. What if people don't have Chrome >> >> installed? Or what if they want a way of UI-less batch-processing such >> >> files, e.g. what if a service like Youtube/Vimeo wants to allow upload >> of >> >> vp8a/vp9a files without invoking Chrome for decoding? >> >> >> > >> > Additional evidence in [1], [2]. >> > >> > There absolutely seems to be interest in support for vp8a/vp9a decoding >> > outside Chrome. I'm not saying you should implement it in all multimedia >> > frameworks ever created in human history, but doing it in one of them >> (e.g. >> > ffmpeg, since it already supports encoding) certainly sounds helpful? >> > >> >> I'm not saying alpha decoder shouldn't ever be implemented in ffmpeg. >> I'm just saying that it shouldn't be a reason to block this patch. :) >> Sorry if i wasn't clear before. > > > I totally understand that you would think that, since it means you don't > have to do anything :). > > But there's an issue with this thinking. We're essentially already the > dumping ground for anything multimedia-related nowadays. After all, we > maintain it and keep it working (assuming basic tests), things couldn't get > much easier than that, right? But is it actually useful to anyone? I mean > not just useful for you, but useful to a wider set of people, at least in > theory. > > If there's no decoder, I would claim that the wider utility of this thing > is essentially zero. And that's somewhat of a concern. > > So, how do we get a decoder? vp8a suggests that just waiting for one to > spontaneously combust out of thin air just doesn't work. So I'm suggesting > you provide us with one. It's ok if it uses libvpx instead of ffvp8/9. > Since vp8a encoding is already in, I won't ask for a vp8a decoder either. > I'm just asking for a vp9a decoder. It might even be OK if it's implemented > on top of ffmpeg instead of inside libavcodec (I'm not sure how others feel > about this), i.e. just something that invokes libavformat to parse a webm > file, create two decoders to get the yuv and a planes, and then merge them > together into a yuva420p picture. I'm just asking for something _small_ and > _simple_ (i.e. not "Chrome") that we can point users to when they ask "how > do I decode vp9a files". > > I asked on IRC (#ffmpeg-devel) and several people concurred: > > jamrial: so … I’m looking for a second opinion here, like, an > independent one… am I being too hard on these guys for saying “an encoder > needs a decoder”? > BBB: I do tend to agree that in general it goes dec->enc, or both at > the same time. be it a fully lavc decoder or just utilizing a decoder > library > BBB: no, you're not being hard > > So it seems I'm not entirely alone in this opinion within the ffmpeg > developer community. > > Ronald Roland, aren't you one of the main developers of ffvp9? I remember you have spent a lot of time making it faster. You know that codec well, don't you? Thus my question is: Why are you wasting your time blocking things that people want, instead of implementing the alpha plane support
Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding
Ivan Kalvachev gmail.com> writes: > Do you have idea how hard is adding decoding support this way? It is non-trivial because the format is quite broken. But I really don't see how any of this is related... Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] need guidance
Hello, I am Minerva , pursuing my undergraduate studies , B.Tech in Computer science and Engineering from India. I am interested for contributing to FFmpeg. I know C/C++,Android and Java. I am new to open source and need guidance about how to start. I am keen to participate in coming outreachy round. Regards, Minerva ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] fate/pngdec : add test for rgba64 and interleaved rgb
Hello, In attach a patch to add fate test for png decoder for non interleaved rgba64 and interleaved rgb sample can be found here : https://we.tl/SNtjbUQqms and need to be put inside ./fate-suite/png1 lena-rgba64.png is already in the fate samples but not used by image.mak Martin From 449ab70d87f4960c7e3cf015b173ab5466cc97e3 Mon Sep 17 00:00:00 2001 From: Martin Vignali Date: Sat, 2 Jul 2016 15:18:45 +0200 Subject: [PATCH] fate/png : add test for rgba64 and interleaved rgb --- tests/fate/image.mak | 5 - tests/ref/fate/png-int-rgb24 | 6 ++ tests/ref/fate/png-rgba64| 6 ++ 3 files changed, 16 insertions(+), 1 deletion(-) create mode 100644 tests/ref/fate/png-int-rgb24 create mode 100644 tests/ref/fate/png-rgba64 diff --git a/tests/fate/image.mak b/tests/fate/image.mak index 500da48..178624a 100644 --- a/tests/fate/image.mak +++ b/tests/fate/image.mak @@ -263,9 +263,12 @@ FATE_PNG += fate-png-$(1) fate-png-$(1): CMD = framecrc -i $(TARGET_SAMPLES)/png1/lena-$(1).png -sws_flags +accurate_rnd+bitexact -pix_fmt rgb24 endef -PNG_COLORSPACES = gray8 gray16 rgb24 rgb48 rgba ya8 ya16 +PNG_COLORSPACES = gray8 gray16 rgb24 rgb48 rgba rgba64 ya8 ya16 $(foreach CLSP,$(PNG_COLORSPACES),$(eval $(call FATE_IMGSUITE_PNG,$(CLSP +FATE_PNG += fate-png-int-rgb24 +fate-png-int-rgb24: CMD = framecrc -i $(TARGET_SAMPLES)/png1/lena-int_rgb24.png -sws_flags +accurate_rnd+bitexact -pix_fmt rgb24 + FATE_PNG-$(call DEMDEC, IMAGE2, PNG) += $(FATE_PNG) FATE_IMAGE += $(FATE_PNG-yes) fate-png: $(FATE_PNG-yes) diff --git a/tests/ref/fate/png-int-rgb24 b/tests/ref/fate/png-int-rgb24 new file mode 100644 index 000..a37aac8 --- /dev/null +++ b/tests/ref/fate/png-int-rgb24 @@ -0,0 +1,6 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 128x128 +#sar 0: 2835/2835 +0, 0, 0,1,49152, 0xe0013dee diff --git a/tests/ref/fate/png-rgba64 b/tests/ref/fate/png-rgba64 new file mode 100644 index 000..3a66f19 --- /dev/null +++ b/tests/ref/fate/png-rgba64 @@ -0,0 +1,6 @@ +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 128x128 +#sar 0: 1/1 +0, 0, 0,1,49152, 0x04f35063 -- 1.9.3 (Apple Git-50) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] fate/apng : add test for apng decoding
Hello, In attach patch to add test for apng decoding based on these samples : http://littlesvr.ca/apng/samples.html can also be found here : https://we.tl/FNVAVl5dQs and need to be put inside ./fate-suite/apng (folder doesn't exist) Martin From c7f7f7e945f5a1ffed76fe4e3f6a53523f1a2ba4 Mon Sep 17 00:00:00 2001 From: Martin Vignali Date: Sat, 2 Jul 2016 16:08:55 +0200 Subject: [PATCH] fate/apng : add test for apng decoding --- tests/Makefile | 1 + tests/ref/fate/apng-clock | 45 + tests/ref/fate/apng-osample | 11 +++ 3 files changed, 57 insertions(+) create mode 100644 tests/ref/fate/apng-clock create mode 100644 tests/ref/fate/apng-osample diff --git a/tests/Makefile b/tests/Makefile index 019203c..895944d 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -109,6 +109,7 @@ include $(SRC_PATH)/tests/fate/als.mak include $(SRC_PATH)/tests/fate/amrnb.mak include $(SRC_PATH)/tests/fate/amrwb.mak include $(SRC_PATH)/tests/fate/api.mak +include $(SRC_PATH)/tests/fate/apng.mak include $(SRC_PATH)/tests/fate/atrac.mak include $(SRC_PATH)/tests/fate/audio.mak include $(SRC_PATH)/tests/fate/bmp.mak diff --git a/tests/ref/fate/apng-clock b/tests/ref/fate/apng-clock new file mode 100644 index 000..54db094 --- /dev/null +++ b/tests/ref/fate/apng-clock @@ -0,0 +1,45 @@ +#tb 0: 6667/10 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 150x150 +#sar 0: 0/1 +0, 0, 0,1,23524, 0xf09caaa1 +0, 1, 1,1,23524, 0x1a329f21 +0, 2, 2,1,23524, 0x9b0ca017 +0, 3, 3,1,23524, 0x73b09deb +0, 4, 4,1,23524, 0x23039f49 +0, 5, 5,1,23524, 0x58869e7b +0, 6, 6,1,23524, 0xc26397d2 +0, 7, 7,1,23524, 0xe07f7d87 +0, 8, 8,1,23524, 0x619a82ba +0, 9, 9,1,23524, 0x696c9757 +0, 10, 10,1,23524, 0x7303a4a6 +0, 11, 11,1,23524, 0x1e149aee +0, 12, 12,1,23524, 0x78dd97e0 +0, 13, 13,1,23524, 0xad8092d3 +0, 14, 14,1,23524, 0x27c090b4 +0, 15, 15,1,23524, 0x904c97be +0, 16, 16,1,23524, 0x54d29b9e +0, 17, 17,1,23524, 0x57689bfa +0, 18, 18,1,23524, 0x2772a00e +0, 19, 19,1,23524, 0x6a769ef6 +0, 20, 20,1,23524, 0x94d8aad5 +0, 21, 21,1,23524, 0x52f79ec4 +0, 22, 22,1,23524, 0x99ee9fbc +0, 23, 23,1,23524, 0xbd6a9e4d +0, 24, 24,1,23524, 0xaf4aa1cf +0, 25, 25,1,23524, 0xdb929f98 +0, 26, 26,1,23524, 0x9e189a6f +0, 27, 27,1,23524, 0x3ffb9410 +0, 28, 28,1,23524, 0x6fc9917d +0, 29, 29,1,23524, 0xe43e94ca +0, 30, 30,1,23524, 0x03b6a24f +0, 31, 31,1,23524, 0xc54f99b3 +0, 32, 32,1,23524, 0x4b9a9748 +0, 33, 33,1,23524, 0x25a19003 +0, 34, 34,1,23524, 0x2b9d77cc +0, 35, 35,1,23524, 0x4a5a9217 +0, 36, 36,1,23524, 0x241b9a7c +0, 37, 37,1,23524, 0xc9d39b38 +0, 38, 38,1,23524, 0xcca69f30 +0, 39, 39,1,23524, 0xe50f9ec9 diff --git a/tests/ref/fate/apng-osample b/tests/ref/fate/apng-osample new file mode 100644 index 000..5fca5e6 --- /dev/null +++ b/tests/ref/fate/apng-osample @@ -0,0 +1,11 @@ +#tb 0: 3/50 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 116x135 +#sar 0: 0/1 +0, 0, 0,1,62640, 0x31eb581d +0, 3, 3,1,62640, 0x29e11b82 +0, 6, 6,1,62640, 0x207ed588 +0, 9, 9,1,62640, 0x3845c906 +0, 12, 12,1,62640, 0x6797fe69 +0, 15, 15,1,62640, 0x1f086a09 -- 1.9.3 (Apple Git-50) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate/apng : add test for apng decoding
On 7/2/2016 11:12 AM, Martin Vignali wrote: > Hello, > > In attach patch to add test for apng decoding > > based on these samples : http://littlesvr.ca/apng/samples.html > > can also be found here : https://we.tl/FNVAVl5dQs > > and need to be put inside ./fate-suite/apng (folder doesn't exist) > > > Martin > > > 0001-fate-apng-add-test-for-apng-decoding.patch > > > From c7f7f7e945f5a1ffed76fe4e3f6a53523f1a2ba4 Mon Sep 17 00:00:00 2001 > From: Martin Vignali > Date: Sat, 2 Jul 2016 16:08:55 +0200 > Subject: [PATCH] fate/apng : add test for apng decoding > > --- > tests/Makefile | 1 + > tests/ref/fate/apng-clock | 45 > + > tests/ref/fate/apng-osample | 11 +++ > 3 files changed, 57 insertions(+) > create mode 100644 tests/ref/fate/apng-clock > create mode 100644 tests/ref/fate/apng-osample > > diff --git a/tests/Makefile b/tests/Makefile > index 019203c..895944d 100644 > --- a/tests/Makefile > +++ b/tests/Makefile > @@ -109,6 +109,7 @@ include $(SRC_PATH)/tests/fate/als.mak > include $(SRC_PATH)/tests/fate/amrnb.mak > include $(SRC_PATH)/tests/fate/amrwb.mak > include $(SRC_PATH)/tests/fate/api.mak > +include $(SRC_PATH)/tests/fate/apng.mak You forgot to git add this file. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate/apng : add test for apng decoding
2016-07-02 16:50 GMT+02:00 James Almer : > On 7/2/2016 11:12 AM, Martin Vignali wrote: > > Hello, > > > > In attach patch to add test for apng decoding > > > > based on these samples : http://littlesvr.ca/apng/samples.html > > > > can also be found here : https://we.tl/FNVAVl5dQs > > > > and need to be put inside ./fate-suite/apng (folder doesn't exist) > > > > > > Martin > > > > > > 0001-fate-apng-add-test-for-apng-decoding.patch > > > > > > From c7f7f7e945f5a1ffed76fe4e3f6a53523f1a2ba4 Mon Sep 17 00:00:00 2001 > > From: Martin Vignali > > Date: Sat, 2 Jul 2016 16:08:55 +0200 > > Subject: [PATCH] fate/apng : add test for apng decoding > > > > --- > > tests/Makefile | 1 + > > tests/ref/fate/apng-clock | 45 > + > > tests/ref/fate/apng-osample | 11 +++ > > 3 files changed, 57 insertions(+) > > create mode 100644 tests/ref/fate/apng-clock > > create mode 100644 tests/ref/fate/apng-osample > > > > diff --git a/tests/Makefile b/tests/Makefile > > index 019203c..895944d 100644 > > --- a/tests/Makefile > > +++ b/tests/Makefile > > @@ -109,6 +109,7 @@ include $(SRC_PATH)/tests/fate/als.mak > > include $(SRC_PATH)/tests/fate/amrnb.mak > > include $(SRC_PATH)/tests/fate/amrwb.mak > > include $(SRC_PATH)/tests/fate/api.mak > > +include $(SRC_PATH)/tests/fate/apng.mak > > You forgot to git add this file. > > > Sorry, new patch in attach Martin From 7fcc33cf25b599399be4d06c2a260a440fff4c0d Mon Sep 17 00:00:00 2001 From: Martin Vignali Date: Sat, 2 Jul 2016 17:48:45 +0200 Subject: [PATCH] fate/apng : add test for apng decoding --- tests/Makefile | 1 + tests/fate/apng.mak | 10 ++ tests/ref/fate/apng-clock | 45 + tests/ref/fate/apng-osample | 11 +++ 4 files changed, 67 insertions(+) create mode 100644 tests/fate/apng.mak create mode 100644 tests/ref/fate/apng-clock create mode 100644 tests/ref/fate/apng-osample diff --git a/tests/Makefile b/tests/Makefile index 019203c..895944d 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -109,6 +109,7 @@ include $(SRC_PATH)/tests/fate/als.mak include $(SRC_PATH)/tests/fate/amrnb.mak include $(SRC_PATH)/tests/fate/amrwb.mak include $(SRC_PATH)/tests/fate/api.mak +include $(SRC_PATH)/tests/fate/apng.mak include $(SRC_PATH)/tests/fate/atrac.mak include $(SRC_PATH)/tests/fate/audio.mak include $(SRC_PATH)/tests/fate/bmp.mak diff --git a/tests/fate/apng.mak b/tests/fate/apng.mak new file mode 100644 index 000..696c503 --- /dev/null +++ b/tests/fate/apng.mak @@ -0,0 +1,10 @@ +FATE_APNG += fate-apng-clock +fate-apng-clock: CMD = framecrc -i $(TARGET_SAMPLES)/apng/clock.png + +FATE_APNG += fate-apng-osample +fate-apng-osample: CMD = framecrc -i $(TARGET_SAMPLES)/apng/o_sample.png + +FATE_APNG-$(call DEMDEC, APNG, PNG) += $(FATE_APNG) + +FATE_SAMPLES_FFMPEG += $(FATE_APNG) +fate-apng: $(FATE_APNG-yes) diff --git a/tests/ref/fate/apng-clock b/tests/ref/fate/apng-clock new file mode 100644 index 000..54db094 --- /dev/null +++ b/tests/ref/fate/apng-clock @@ -0,0 +1,45 @@ +#tb 0: 6667/10 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 150x150 +#sar 0: 0/1 +0, 0, 0,1,23524, 0xf09caaa1 +0, 1, 1,1,23524, 0x1a329f21 +0, 2, 2,1,23524, 0x9b0ca017 +0, 3, 3,1,23524, 0x73b09deb +0, 4, 4,1,23524, 0x23039f49 +0, 5, 5,1,23524, 0x58869e7b +0, 6, 6,1,23524, 0xc26397d2 +0, 7, 7,1,23524, 0xe07f7d87 +0, 8, 8,1,23524, 0x619a82ba +0, 9, 9,1,23524, 0x696c9757 +0, 10, 10,1,23524, 0x7303a4a6 +0, 11, 11,1,23524, 0x1e149aee +0, 12, 12,1,23524, 0x78dd97e0 +0, 13, 13,1,23524, 0xad8092d3 +0, 14, 14,1,23524, 0x27c090b4 +0, 15, 15,1,23524, 0x904c97be +0, 16, 16,1,23524, 0x54d29b9e +0, 17, 17,1,23524, 0x57689bfa +0, 18, 18,1,23524, 0x2772a00e +0, 19, 19,1,23524, 0x6a769ef6 +0, 20, 20,1,23524, 0x94d8aad5 +0, 21, 21,1,23524, 0x52f79ec4 +0, 22, 22,1,23524, 0x99ee9fbc +0, 23, 23,1,23524, 0xbd6a9e4d +0, 24, 24,1,23524, 0xaf4aa1cf +0, 25, 25,1,23524, 0xdb929f98 +0, 26, 26,1,23524, 0x9e189a6f +0, 27, 27,1,23524, 0x3ffb9410 +0, 28, 28,1,23524, 0x6fc9917d +0, 29, 29,1,23524, 0xe43e94ca
Re: [FFmpeg-devel] [PATCH] libavcodec/mmaldec.c: add interlaced_frame and format struct to AVFrame for deinterlacing
On Sun, Jun 26, 2016 at 17:12:14 +0200, Jens Ziller wrote:
> +ctx->interlaced_frame = !(interlace_type.eMode ==
> MMAL_InterlaceProgressive);
What's wrong with using the "!=" operator instead?
> if (avctx->pix_fmt == AV_PIX_FMT_MMAL) {
> if (!ctx->pool_out)
> +// in data[2] give the format struct for configure deinterlacer and
> renderer
> +frame->data[2] = ctx->decoder->output[0]->format;
Incorrect indentation.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate/pngdec : add test for rgba64 and interleaved rgb
On Sat, Jul 02, 2016 at 03:26:40PM +0200, Martin Vignali wrote: > Hello, > > In attach a patch to add fate test for png decoder for non interleaved > rgba64 > and interleaved rgb > > sample can be found here : > https://we.tl/SNtjbUQqms > > and need to be put inside ./fate-suite/png1 uploaded thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate/apng : add test for apng decoding
On Sat, Jul 02, 2016 at 04:12:43PM +0200, Martin Vignali wrote: > Hello, > > In attach patch to add test for apng decoding > > based on these samples : http://littlesvr.ca/apng/samples.html > > can also be found here : https://we.tl/FNVAVl5dQs > > and need to be put inside ./fate-suite/apng (folder doesn't exist) uploaded thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] web/index: add news entry for ffmpeg 3.1.1
Signed-off-by: James Almer --- src/index | 10 ++ 1 file changed, 10 insertions(+) diff --git a/src/index b/src/index index eb66060..4cdd94b 100644 --- a/src/index +++ b/src/index @@ -37,6 +37,16 @@ News + July 1st, 2016, FFmpeg 3.1.1 "Laplace" + +FFmpeg 3.1.1, a new point release from the 3.1 release branch, is now available! +It mainly deals with a few ABI issues introduced in the previous release. + + +We strongly recommend users, distributors, and system integrators, especially those who experienced issues upgrading from 3.0, to +upgrade unless they use current git master. + + June 27th, 2016, FFmpeg 3.1 "Laplace" FFmpeg 3.1 "Laplace", a new -- 2.9.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/h264_slice: use sps directly when checking for invalid 8x8 inference
---
libavcodec/h264_slice.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index ca492ba..22916f1 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1466,7 +1466,7 @@ static int h264_slice_header_parse(H264Context *h,
H264SliceContext *sl)
if (sps->frame_mbs_only_flag) {
picture_structure = PICT_FRAME;
} else {
-if (!h->ps.sps->direct_8x8_inference_flag && slice_type ==
AV_PICTURE_TYPE_B) {
+if (!sps->direct_8x8_inference_flag && slice_type ==
AV_PICTURE_TYPE_B) {
av_log(h->avctx, AV_LOG_ERROR, "This stream was generated by a
broken encoder, invalid 8x8 inference\n");
return -1;
}
--
2.9.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] web/index: add news entry for ffmpeg 3.1.1
On Sat, Jul 2, 2016, at 08:35 AM, James Almer wrote: > Signed-off-by: James Almer > --- > src/index | 10 ++ > 1 file changed, 10 insertions(+) Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat: Add FIFO pseudo-muxer
Hi,
just some formal (non-functional) comments from me.
On Tue, Jun 28, 2016 at 13:35:41 +0200, sebechlebsky...@gmail.com wrote:
> From: Jan Sebechlebsky
>
> FIFO pseudo-muxer allows to separate decoder from the
> actual output by using first-in-first-out queue and
> running actual muxer asynchronously in separate thread.
This and the documentation could use some grammar-cleaning, especially
articles. BTW, it's the encoder, not the decoder. Let me attempt:
> The fifo pseudo-muxer allows to separate the encoder from the actual
> output by using a first-in-first-out queue and running the actual
> muxer asynchronously in separate thread.
>
> It can be configured to attempt transparent recovery
> of output on failure.
More fixes by me here:
> @section fifo
>
> The fifo pseudo-muxer allows to separate encoding from any other
> muxer by using a first-in-first-out queue and running the actual
> muxer in a separate thread. This is especially useful in combination
> with the @ref{tee} muxer and output to several destinations with
> different reliability/writing speed/latency.
(Note the @ref{}.)
> The fifo muxer can operate in regular or fully non-blocking mode.
> This determines the behaviour in case the queue fills up. In regular
> mode the encoding is blocked until the muxer processes some of the
> packets from the queue; in non-blocking mode the packets are thrown
> away rather than blocking the encoder (this might be useful in
> real-time streaming scenarios).
> +@item queue_size
> +Specify size of the queue (number of packets)
Do mention the defaults, please.
> +@item block_on_overflow 0|1
I think this is usually the doc syntax:
@item block_on_overflow @var{bool}
> If set to 0 (false), fully non-blocking mode will be used and in case
> the queue fills up, packets will be dropped. By default this option
> is set to 1 (true), so in case of queue overflow the encoder will be
> block until the muxer processes some of the packets.
> +@item attempt_recovery 0|1
Same here, and for all other boolean options
> +If failure happens, attempt to recover the output. This is especially useful
^^^ "occurs" seems better.
> +when used with network output, allows to restart streaming transparently.
> +By default this option is turned off.
0, false, off. So many ways of expressing it. ;-) Yet okay, I guess.
> +@item max_recovery_attempts
> +Sets maximal number of successive unsucessfull recovery attempts after which
> +the output fails permanently. Unlimited if set to zero.
- the maximal ("maximum"?) number
- unsuccessful (one 'l' only)
And please document the default.
> +@item recovery_wait_time
> +Waiting time before the next recovery attempt after previous unsuccessfull
> +recovery attempt.
- unsuccessful (one 'l' only)
- please add that it's in seconds
> +@item recovery_wait_streamtime 0|1
> +If set to 0 (default), the real time is used when waiting for the recovery
> attempt
> +(i.e. the recovery will be attempted after at least recovery_wait_time
> seconds).
> +If set to 1, the time of the processed stream is taken into account instead
> +(i.e. the recovery will be attempted after at least recovery_wait_time
> seconds
> +of the stream is ommited).
- "omitted"
- please state the default
> +@item recover_any_error 0|1
> +If set to 1, recovery will be attempted regardless of type of the error
> causing
> +the failure (by default, in case of certain errors the recovery is not
> attempted
> +even when attempt_recovery is on).
Make this two sentences instead of an appended bracket case.
> +#define FIFO_DEFAULT_RECOVERY_WAIT_TIME100 // 1 second
You're assigning it as a default to an option which claims to be
in seconds:
> +{"recovery_wait_time", "Waiting time between recovery attempts
> (seconds)", OFFSET(recovery_wait_time),
> + AV_OPT_TYPE_DURATION, {.i64 = FIFO_DEFAULT_RECOVERY_WAIT_TIME}, 0,
> INT64_MAX, AV_OPT_FLAG_ENCODING_PARAM},
So the default you are setting happens to be 100 seconds. Or am I
missing something? (I could check by applying your patch. Sorry, didn't
do so.)
> +for (i = 0;i < avf2->nb_streams; i++)
Nit: spaces
> +switch (err_no) {
> +case AVERROR(EINVAL):
> +case AVERROR(ENOSYS):
> +case AVERROR_EOF:
> +case AVERROR_EXIT:
> +case AVERROR_PATCHWELCOME:
> +return 0;
> +default:
> +return 1;
> +}
I believe switch/case is indented differently in ffmpeg.
> +} while(ret == AVERROR(EAGAIN) && fifo->block_on_overflow);
Nit: space
> +if (ret < 0) {
> +return ret;
> +}
You should probably drop the brackets, according to ffmpeg style.
> +}else if (ret < 0) {
Nit: bracket
> +static const AVOption options[] = {
> +{"fifo_format", "Target muxer", OFFSET(format),
> + AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0,
> AV_OPT_FLAG_ENCODING_PARAM},
> +
> +{"queue_size", "Size of fifo queue", OFFSET(que
Re: [FFmpeg-devel] [PATCH] lavc/h264_slice: use sps directly when checking for invalid 8x8 inference
On Sat, Jul 02, 2016 at 07:23:35PM +0200, Clément Bœsch wrote: > --- > libavcodec/h264_slice.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests/fate: Add test for ticket 3386 ([H264] [Regression] illegal short term buffer state detected)
On Fri, Jul 01, 2016 at 07:23:27PM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > tests/fate/h264.mak |2 ++ > tests/ref/fate/h264-3386 | 52 > ++ > 2 files changed, 54 insertions(+) > create mode 100644 tests/ref/fate/h264-3386 applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests/checkasm/pixblockdsp: Test only aligned by 8 diff/get pixels
On Mon, Jun 27, 2016 at 10:48:01PM +0200, Michael Niedermayer wrote:
> On Sun, Jun 26, 2016 at 01:59:05PM +0200, Hendrik Leppkes wrote:
> > On Sun, Jun 26, 2016 at 11:16 AM, Michael Niedermayer
> > wrote:
> > > They are documented as requiring 8 byte aligned source
> > >
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > tests/checkasm/pixblockdsp.c |4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/tests/checkasm/pixblockdsp.c b/tests/checkasm/pixblockdsp.c
> > > index 66bfdb7..28ee500 100644
> > > --- a/tests/checkasm/pixblockdsp.c
> > > +++ b/tests/checkasm/pixblockdsp.c
> > > @@ -49,7 +49,7 @@
> > > int i;
> > > \
> > > declare_func_emms(AV_CPU_FLAG_MMX, void, int16_t *block, const
> > > uint8_t *pixels, ptrdiff_t line_size);\
> > >
> > > \
> > > -for (i = 0; i < BUF_UNITS; i++) {
> > > \
> > > +for (i = 0; i < BUF_UNITS; i+=8) {
> > >\
> > > int src_offset = i * 64 * sizeof(type) + i; /* Test various
> > > alignments */ \
> > > int dst_offset = i * 64; /* dst must be aligned */
> > > \
> > > randomize_buffers();
> > > \
> > > @@ -66,7 +66,7 @@
> > > int i;
> > > \
> > > declare_func_emms(AV_CPU_FLAG_MMX, void, int16_t *av_restrict
> > > block, const uint8_t *s1, const uint8_t *s2, int stride); \
> > >
> > > \
> > > -for (i = 0; i < BUF_UNITS; i++) {
> > > \
> > > +for (i = 0; i < BUF_UNITS; i+=8) {
> > >\
> > > int src_offset = i * 64 * sizeof(type) + i; /* Test various
> > > alignments */ \
> > > int dst_offset = i * 64; /* dst must be aligned */
> > > \
> > > randomize_buffers();
> > > \
> > > --
> > > 1.7.9.5
> > >
> >
> > BUF_UNITS is 8, so that change would entirely eliminate the loop.
> > Maybe src_offset should just be changed to be aligned properly,
> > keeping the loop? Or is the only purpose of the loop to test
> > alignment?
>
> you mean something like this? :
> commit e3ff4df1c0a83a178d0aaf102486d7fbc97994d1
> Author: Michael Niedermayer
> Date: Mon Jun 27 22:03:14 2016 +0200
>
> tests/checkasm/pixblockdsp: Test 8 byte aligned positions
>
> The code is documented as to require 8byte alignment
>
> Signed-off-by: Michael Niedermayer
applied
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
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/3] avformat: factorize iso 8601 timestamp writer to a dictionary avutil function
On 6/30/2016 7:58 PM, Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> libavformat/internal.h | 1 +
> libavformat/utils.c| 16 ++--
> libavutil/dict.c | 17 +
> libavutil/internal.h | 10 ++
> 4 files changed, 30 insertions(+), 14 deletions(-)
>
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index 647ad65..3ec4b0c 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -24,6 +24,7 @@
> #include
>
> #include "libavutil/bprint.h"
> +#include "libavutil/internal.h"
> #include "avformat.h"
> #include "os_support.h"
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index d2a709c..0993bf9 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -5140,20 +5140,8 @@ int ff_standardize_creation_time(AVFormatContext *s)
> {
> int64_t timestamp;
> int ret = ff_parse_creation_time_metadata(s, ×tamp, 0);
> -if (ret == 1) {
> -time_t seconds = timestamp / 100;
> -struct tm *ptm, tmbuf;
> -ptm = gmtime_r(&seconds, &tmbuf);
> -if (ptm) {
> -char buf[32];
> -if (!strftime(buf, sizeof(buf), "%Y-%m-%dT%H:%M:%S", ptm))
> -return AVERROR_EXTERNAL;
> -av_strlcatf(buf, sizeof(buf), ".%06dZ", (int)(timestamp %
> 100));
> -av_dict_set(&s->metadata, "creation_time", buf, 0);
> -} else {
> -return AVERROR_EXTERNAL;
> -}
> -}
> +if (ret == 1)
> +return avpriv_dict_set_timestamp(&s->metadata, "creation_time",
> timestamp);
> return ret;
> }
>
> diff --git a/libavutil/dict.c b/libavutil/dict.c
> index f70c7e0..2c98bb5 100644
> --- a/libavutil/dict.c
> +++ b/libavutil/dict.c
> @@ -19,6 +19,7 @@
> */
>
> #include
> +#include
>
> #include "avstring.h"
> #include "dict.h"
> @@ -253,3 +254,19 @@ int av_dict_get_string(const AVDictionary *m, char
> **buffer,
> }
> return av_bprint_finalize(&bprint, buffer);
> }
> +
> +int avpriv_dict_set_timestamp(AVDictionary **dict, const char *key, int64_t
> timestamp)
> +{
> +time_t seconds = timestamp / 100;
> +struct tm *ptm, tmbuf;
> +ptm = gmtime_r(&seconds, &tmbuf);
You need to include time_internal.h which has a gmtime_r fallback
implementation for targets like old mingw where it's not available.
> +if (ptm) {
> +char buf[32];
> +if (!strftime(buf, sizeof(buf), "%Y-%m-%dT%H:%M:%S", ptm))
> +return AVERROR_EXTERNAL;
> +av_strlcatf(buf, sizeof(buf), ".%06dZ", (int)(timestamp % 100));
> +return av_dict_set(dict, key, buf, 0);
> +} else {
> +return AVERROR_EXTERNAL;
> +}
> +}
> diff --git a/libavutil/internal.h b/libavutil/internal.h
> index 61784b5..e995af9 100644
> --- a/libavutil/internal.h
> +++ b/libavutil/internal.h
> @@ -330,6 +330,16 @@ static av_always_inline av_const int avpriv_mirror(int
> x, int w)
>
> void ff_check_pixfmt_descriptors(void);
>
> +/**
> + * Set a dictionary value to an ISO-8601 compliant timestamp string.
> + *
> + * @param s AVFormatContext
> + * @param key metadata key
> + * @param timestamp unix timestamp in microseconds
> + * @return <0 on error
> + */
> +int avpriv_dict_set_timestamp(AVDictionary **dict, const char *key, int64_t
> timestamp);
> +
> extern const uint8_t ff_reverse[256];
>
> #endif /* AVUTIL_INTERNAL_H */
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libopusenc: Add channel mapping family argument
On Sun, Jun 26, 2016 at 04:55:56PM -0700, Michael Graczyk wrote: > Michael, > Thanks for your comments. > > On Sat, Jun 25, 2016 at 4:28 AM, Michael Niedermayer > wrote: > > yes, rereading this a bit > > can you explain what is the difference between the mapping familiy > > and he channel_layout we have ? > > The Opus channel mapping family and FFmpeg channel layout both provide > a mapping between stream position and semantic meaning. That is, they > both answer the question "What does the channel at position k in the > stream contain?" > > The two parameters are both defined by explicitly enumerating > acceptable possibilities. There are some channel mappings which are > defined by Opus but are not defined by FFmpeg. Likewise, there are > channel mappings defined by FFmpeg which are not defined by Opus. > Because of the differences, there is no unambiguous 1:1 correspondence > between Opus channel mapping family and FFmpeg channel_layout. For > example, FFmpeg has no way of specifying "channel k is an SN3D > normalized ambisonic channel kth in ACN order". Opus does (or soon > will) have a way of specifying that, namely mapping_family==2. > > > > if the channel_layout is not set its undefined, if its set it should > > be correct > > why do you need this additional user parameter ? > > The additional parameter is necessary to disambiguate between multiple > cases which are all unknown to FFmpeg. For example, there is no way > for FFmpeg to differentiate between inputs which consist of Ambisonics > and inputs which have truly no semantic meaning. These two cases are > differentiated by Opus, with mapping_family 2 and 255 respectively. > > > Also the way this patch is written, mapping_family==-1 preserves > existing FFmpeg behavior while mapping_family==1 does not. Although > both values indicate the same semantic channel meanings, the latter > configures libopus to use surround masking, which is a potentially > quality-degrading change from current behavior. That is why I did not > change default behavior with this patch. patches applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2 2/3] avformat: factorize iso 8601 timestamp writer to a dictionary avutil function
Signed-off-by: Marton Balint
---
libavformat/internal.h | 1 +
libavformat/utils.c| 16 ++--
libavutil/dict.c | 17 +
libavutil/internal.h | 10 ++
4 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index 647ad65..3ec4b0c 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -24,6 +24,7 @@
#include
#include "libavutil/bprint.h"
+#include "libavutil/internal.h"
#include "avformat.h"
#include "os_support.h"
diff --git a/libavformat/utils.c b/libavformat/utils.c
index d2a709c..0993bf9 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -5140,20 +5140,8 @@ int ff_standardize_creation_time(AVFormatContext *s)
{
int64_t timestamp;
int ret = ff_parse_creation_time_metadata(s, ×tamp, 0);
-if (ret == 1) {
-time_t seconds = timestamp / 100;
-struct tm *ptm, tmbuf;
-ptm = gmtime_r(&seconds, &tmbuf);
-if (ptm) {
-char buf[32];
-if (!strftime(buf, sizeof(buf), "%Y-%m-%dT%H:%M:%S", ptm))
-return AVERROR_EXTERNAL;
-av_strlcatf(buf, sizeof(buf), ".%06dZ", (int)(timestamp %
100));
-av_dict_set(&s->metadata, "creation_time", buf, 0);
-} else {
-return AVERROR_EXTERNAL;
-}
-}
+if (ret == 1)
+return avpriv_dict_set_timestamp(&s->metadata, "creation_time",
timestamp);
return ret;
}
diff --git a/libavutil/dict.c b/libavutil/dict.c
index f70c7e0..0ea7138 100644
--- a/libavutil/dict.c
+++ b/libavutil/dict.c
@@ -24,6 +24,7 @@
#include "dict.h"
#include "internal.h"
#include "mem.h"
+#include "time_internal.h"
#include "bprint.h"
struct AVDictionary {
@@ -253,3 +254,19 @@ int av_dict_get_string(const AVDictionary *m, char
**buffer,
}
return av_bprint_finalize(&bprint, buffer);
}
+
+int avpriv_dict_set_timestamp(AVDictionary **dict, const char *key, int64_t
timestamp)
+{
+time_t seconds = timestamp / 100;
+struct tm *ptm, tmbuf;
+ptm = gmtime_r(&seconds, &tmbuf);
+if (ptm) {
+char buf[32];
+if (!strftime(buf, sizeof(buf), "%Y-%m-%dT%H:%M:%S", ptm))
+return AVERROR_EXTERNAL;
+av_strlcatf(buf, sizeof(buf), ".%06dZ", (int)(timestamp % 100));
+return av_dict_set(dict, key, buf, 0);
+} else {
+return AVERROR_EXTERNAL;
+}
+}
diff --git a/libavutil/internal.h b/libavutil/internal.h
index 61784b5..e995af9 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -330,6 +330,16 @@ static av_always_inline av_const int avpriv_mirror(int x,
int w)
void ff_check_pixfmt_descriptors(void);
+/**
+ * Set a dictionary value to an ISO-8601 compliant timestamp string.
+ *
+ * @param s AVFormatContext
+ * @param key metadata key
+ * @param timestamp unix timestamp in microseconds
+ * @return <0 on error
+ */
+int avpriv_dict_set_timestamp(AVDictionary **dict, const char *key, int64_t
timestamp);
+
extern const uint8_t ff_reverse[256];
#endif /* AVUTIL_INTERNAL_H */
--
2.6.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 2/3] avformat: factorize iso 8601 timestamp writer to a dictionary avutil function
On 7/2/2016 7:10 PM, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > libavformat/internal.h | 1 + > libavformat/utils.c| 16 ++-- > libavutil/dict.c | 17 + > libavutil/internal.h | 10 ++ > 4 files changed, 30 insertions(+), 14 deletions(-) > > diff --git a/libavformat/internal.h b/libavformat/internal.h > index 647ad65..3ec4b0c 100644 > --- a/libavformat/internal.h > +++ b/libavformat/internal.h > @@ -24,6 +24,7 @@ > #include > > #include "libavutil/bprint.h" > +#include "libavutil/internal.h" utils.c already includes this, so no need to include it here. Don't resend the patch just for this. Wait for a real review, or locally fix and apply if there's no need for another patch revision. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] ffmpeg: fix -stream_loop with -re
Otherwise the stream failed with EAGAIN.
Signed-off-by: Marton Balint
---
ffmpeg.c | 4
1 file changed, 4 insertions(+)
diff --git a/ffmpeg.c b/ffmpeg.c
index 9ffd833..f06fee5 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3805,6 +3805,10 @@ static int process_input(int file_index)
if ((ret = seek_to_start(ifile, is)) < 0)
return ret;
ret = get_input_packet(ifile, &pkt);
+if (ret == AVERROR(EAGAIN)) {
+ifile->eagain = 1;
+return ret;
+}
}
if (ret < 0) {
if (ret != AVERROR_EOF) {
--
2.6.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] ffmpeg: make seeking back to file start more robust
av_seek_frame to start time can fail and it can also seek after the start of the stream... Signed-off-by: Marton Balint --- ffmpeg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ffmpeg.c b/ffmpeg.c index f06fee5..83a179ee 100644 --- a/ffmpeg.c +++ b/ffmpeg.c @@ -3723,7 +3723,7 @@ static int seek_to_start(InputFile *ifile, AVFormatContext *is) int i, ret, has_audio = 0; int64_t duration = 0; -ret = av_seek_frame(is, -1, is->start_time, 0); +ret = avformat_seek_file(is, -1, INT64_MIN, INT64_MIN, INT64_MAX, 0); if (ret < 0) return ret; -- 2.6.6 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavfilter/af_hdcd.c: Collect HDCD stats and report
The new HDCD filter really does nothing to show that it is working or
that HDCD control
information was even detected in the stream. This patch collects
information about the
decode, like which features were used, and reports it to the user at the end.
First patch I've ever tried to submit to ffmpeg. Has a couple long lines.
Signed-off-by: bp0
---
libavfilter/af_hdcd.c | 54 +++
1 file changed, 54 insertions(+)
diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
index 16bdcb0..f298765 100644
--- a/libavfilter/af_hdcd.c
+++ b/libavfilter/af_hdcd.c
@@ -823,11 +823,25 @@ typedef struct {
int code_counterA;
int code_counterB;
int code_counterC;
+
+/* For user information/stats, pulled up into HDCDContext
+ * by filter_frame() */
+int _hdcd_detected;
+int _peak_extend;
+int _gain_min; /* 4-bit (3.1) fixed-point, << 7 */
+int _gain_max; /* 4-bit (3.1) fixed-point, << 7 */
+int _transient_filter;
} hdcd_state_t;
typedef struct HDCDContext {
const AVClass *class;
hdcd_state_t state[2];
+
+/* User information/stats */
+int hdcd_detected;
+int peak_extend;
+int transient_filter; /* detected, but not implemented */
+float gain_min, gain_max; /* stored positive, but values are negative */
} HDCDContext;
static const AVOption hdcd_options[] = {
@@ -853,6 +867,12 @@ static void hdcd_reset(hdcd_state_t *state, unsigned rate)
state->code_counterA = 0;
state->code_counterB = 0;
state->code_counterC = 0;
+
+state->_hdcd_detected = 0;
+state->_peak_extend = 0;
+state->_gain_min = 0;
+state->_gain_max = 0;
+state->_transient_filter = 0;
}
static int integrate(hdcd_state_t *state, int *flag, const int32_t
*samples, int count, int stride)
@@ -982,14 +1002,20 @@ static int hdcd_envelope(int32_t *samples, int
count, int stride, int gain, int
return gain;
}
+/* update the user info/flags */
+#define UPDATE_INFO(s,pe,tg,tf) do{if (pe || tg || tf || s->sustain)
{ s->_hdcd_detected = 1; } if (pe) { s->_peak_extend = 1; } if (tf) {
s->_transient_filter = 1;} if (tg < s->_gain_min) { s->_gain_min=tg; }
if (tg > s->_gain_max) { s->_gain_max=tg; } }while(0);
+
static void hdcd_process(hdcd_state_t *state, int32_t *samples, int
count, int stride)
{
int32_t *samples_end = samples + count * stride;
int gain = state->running_gain;
int peak_extend = (state->control & 16);
int target_gain = (state->control & 15) << 7;
+int transient_filter = (state->control & 32);
int lead = 0;
+UPDATE_INFO(state, peak_extend, target_gain, transient_filter);
+
while (count > lead) {
int envelope_run;
int run;
@@ -1006,6 +1032,8 @@ static void hdcd_process(hdcd_state_t *state,
int32_t *samples, int count, int s
lead = run - envelope_run;
peak_extend = (state->control & 16);
target_gain = (state->control & 15) << 7;
+transient_filter = (state->control & 32);
+UPDATE_INFO(state, peak_extend, target_gain, transient_filter);
}
if (lead > 0) {
av_assert0(samples + lead * stride <= samples_end);
@@ -1015,6 +1043,9 @@ static void hdcd_process(hdcd_state_t *state,
int32_t *samples, int count, int s
state->running_gain = gain;
}
+/* convert to float from (4-bit (3.1) fixed-point, << 7) */
+#define GAINTOFLOAT(g) ((float)(g>>8) + ((float)(g>>7 & 1) * 0.5))
+
static int filter_frame(AVFilterLink *inlink, AVFrame *in)
{
AVFilterContext *ctx = inlink->dst;
@@ -1024,6 +1055,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
const int16_t *in_data;
int32_t *out_data;
int n, c;
+int _gain_min = 0;
+int _gain_max = 0;
out = ff_get_audio_buffer(outlink, in->nb_samples);
if (!out) {
@@ -1042,8 +1075,17 @@ static int filter_frame(AVFilterLink *inlink,
AVFrame *in)
for (c = 0; c < inlink->channels; c++) {
hdcd_state_t *state = &s->state[c];
hdcd_process(state, out_data + c, in->nb_samples, out->channels);
+
+s->hdcd_detected |= state->_hdcd_detected;
+s->peak_extend |= state->_peak_extend;
+s->transient_filter |= state->_transient_filter;
+if (state->_gain_min < _gain_min) { _gain_min = state->_gain_min; }
+if (state->_gain_max > _gain_max) { _gain_max = state->_gain_max; }
}
+s->gain_min = GAINTOFLOAT(_gain_min);
+s->gain_max = GAINTOFLOAT(_gain_max);
+
av_frame_free(&in);
return ff_filter_frame(outlink, out);
}
@@ -1104,6 +1146,12 @@ static av_cold void uninit(AVFilterContext *ctx)
av_log(ctx, AV_LOG_VERBOSE, "Channel %d: counter A: %d, B:
%d, C: %d\n", i, state->code_counterA,
state->code_counterB, state->code_counterC);
}
+
+av_log(ctx, AV_LOG_INFO, "HDCD detected: %s, peak_extend: %s,
transient_filter: %s, min_gain: -%0.1f dB, max_gain: -%0.1f dB\n",
+(s->hdcd_detected) ? "yes" : "no",
