Re: [FFmpeg-devel] FFmpeg/MPlayer/rtmpdump possibly searching for a new server and hosting
Hi, If it helps anyone, just to clarify, we offer that the OVH server is contracted to the ffmpeg group name, not ours, in an account over the control of the community, not libnova. We'll just pay it for 2 years. Regards, AG. Antonio Guillermo Martínez Largo Libnova, SL Paseo de la Castellana, 153 - Madrid [t] +34 91 449 08 94 [f] +34 91 141 21 21 www.libnova.es -Mensaje original- De: Michael Niedermayer [mailto:mich...@niedermayer.cc] Enviado el: sábado, 18 de julio de 2015 4:19 Para: FFmpeg development discussions and patches CC: Antonio Guillermo Martínez (libnova); rtmpd...@mplayerhq.hu; mplayer-dev-...@mplayerhq.hu Asunto: Re: [FFmpeg-devel] FFmpeg/MPlayer/rtmpdump possibly searching for a new server and hosting On Fri, Jul 17, 2015 at 08:04:37PM -0400, Ronald S. Bultje wrote: > Hi, > > On Fri, Jul 17, 2015 at 7:20 PM, Kieran Kunhya wrote: > > > On 17 July 2015 at 22:00, Michael Niedermayer > > > > wrote: > > > On Fri, Jul 17, 2015 at 04:16:53PM +0200, Michael Niedermayer wrote: > > >> On Fri, Jul 17, 2015 at 03:30:26PM +0200, Jean-Baptiste Kempf wrote: > > >> > On 15 Jul, Michael Niedermayer wrote : > > >> > > longer awnser, > > >> > > videolan IIUC would be willing to host some of our services > > >> > > on their existing server but this would require a "quite a > > >> > > bit" of work. videolan uses LXC we do not. > > >> > > > >> > Indeed, and there is a good reason for that, called security. > > >> > > > >> > > also videolan of course would have to agree to everything, > > >> > > its their server of course ... > > >> > > > >> > VideoLAN has very powerfull machines, connected in a correct > > datacenter, > > >> > with a contract, that will outlive any single member. > > >> > > > >> > > >> > Don't take it bad, but seeing the discussions, and the way you > > >> > manage your roots and services migration, you don't seem to > > >> > care that much about being correctly deployed, but to do it fast. > > >> > > >> iam not taking it bad but when you are being told your boxes > > >> could be shutdown without prior notice by the new managment, then > > >> yes you try to move fast, which is what we did. > > >> Not because thats a great thing to do but because it was needed > > > > > > also speaking of that, id like to take the opertunity to thank > > > everyone who helped making that quick move to the current servers > > > possible That is at least alex, arpi, fabrice, beastd, kieran, > > > reimar, roberto, lou, tim, ubitux and probably more who i have > > > forgotten to list > > > > > > In principle we could stay at these servers but i think its better > > > if we use the time available now to move things to some free, > > > higher end servers and hosting and also if possible (volunteers) > > > move to something like LXC or qemu/kvm in the process and have > > > services properly seperated > > > > > > That would give us better servers, more robust hosting than what > > > you get with a 50euro/mo box. more security and at less cost. > > > > Sorry but this is a bizzare and short-sighted goal. Whilst I am sure > > most of the offers mean well it's much better to get help from the > > community because at least we know who they are, where the data is > > stored, easily contactable etc. The person offering free hosting > > could just leave their company and the machine wiped one day. > > > J-B offered that videolan will host ffmpeg. I, for one, would be > thrilled if that were to happen. I trust videolan a lot. so do i, i trust JB, but will JB still be in charge in 5 years? in 10 years? can we trust whoever will come after JB ? I think FFmpeg should stay with a "neutral" provider/hoster. We did something like this once when moving away from sourceforge and it ultimately resulted in the libav fork. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] [RFC] avformat/async: support filling with a background thread.
2015-07-17 21:52 GMT+08:00 Michael Niedermayer : > On Fri, Jul 17, 2015 at 12:00:57PM +0800, Zhang Rui wrote: >> 2015-07-16 22:00 GMT+08:00 Michael Niedermayer : >> > On Thu, Jul 16, 2015 at 03:04:42PM +0800, Zhang Rui wrote: >> >> --- >> >> configure| 1 + >> >> libavformat/Makefile | 1 + >> >> libavformat/allformats.c | 1 + >> >> libavformat/async.c | 380 >> >> +++ >> >> 4 files changed, 383 insertions(+) >> >> create mode 100644 libavformat/async.c >> > >> > please add some information about this and an example to the docs >> >> OK >> >> > a fate test also could be added >> >> fate rsync is a little slow from my home network, I'll add one in a week or >> two. > > the fate suite is on multiple servers > if fate-suite.ffmpeg.org is slow please try rsync from fate.ffmpeg.org > also if fate-suite is slower than fate for you, please tell us Never mind, many websites out of China are difficult to access from my place. I can handle this myself. Thank you. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5] Add support for Audible AAX (and AAX+) files
Dana 18. 7. 2015. 11:46 osoba "Vesselin Bontchev" <
vesselin.bontc...@yandex.com> napisala je:
>
> 18.07.2015, 01:45, "Michael Niedermayer" :
> > On Thu, Jul 16, 2015 at 03:57:26AM +0300, Vesselin Bontchev wrote:
> >> + // extracted from libAAX_SDK.so and AAXSDKWin.dll files!
> >
> >> + uint8_t fixed_key[] = { 0x77, 0x21, 0x4d, 0x4b, 0x19, 0x6a, 0x87,
0xcd,
> >> + 0x52, 0x00, 0x45, 0xfd, 0x20, 0xa5, 0x1d, 0x67 };
> >
> > I think this should not be hardcoded but provided by the user via
> > an AVOption.
>
> I fear that doing this will impact the usability negatively. Are there
strong reasons for suggesting this change?
>
> How about documenting the fixed key (and then going the AVOption way),
sounds fair?
Using AVOption will set default key to what is already now hardcoded.
>
> Vesselin
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5] Add support for Audible AAX (and AAX+) files
18.07.2015, 01:45, "Michael Niedermayer" :
> On Thu, Jul 16, 2015 at 03:57:26AM +0300, Vesselin Bontchev wrote:
>> + // extracted from libAAX_SDK.so and AAXSDKWin.dll files!
>
>> + uint8_t fixed_key[] = { 0x77, 0x21, 0x4d, 0x4b, 0x19, 0x6a, 0x87, 0xcd,
>> + 0x52, 0x00, 0x45, 0xfd, 0x20, 0xa5, 0x1d, 0x67 };
>
> I think this should not be hardcoded but provided by the user via
> an AVOption.
I fear that doing this will impact the usability negatively. Are there strong
reasons for suggesting this change?
How about documenting the fixed key (and then going the AVOption way), sounds
fair?
Vesselin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Rename FF_CODEC_PROPERTY_* as AV_CODEC_PROPERTY_*
On Fri, Jul 17, 2015 at 12:27:40AM +0200, Carl Eugen Hoyos wrote: > Hi! > > I am not really happy with attached patch as most defines in avcodec.h > use the FF_ prefix. > > Please comment, Carl Eugen > doc/APIchanges |4 > libavcodec/avcodec.h |4 ++-- > libavcodec/h264.c |2 +- > libavcodec/mjpegdec.c |4 ++-- > libavcodec/mpeg12dec.c |2 +- > libavcodec/utils.c |4 ++-- > libavcodec/version.h |2 +- > libavcodec/vp9.c |2 +- > libavcodec/webp.c |2 +- > 9 files changed, 15 insertions(+), 11 deletions(-) > 74154d7ebedba679bea09d9c150d1e605f363828 patchavcodecproperties.diff > diff --git a/doc/APIchanges b/doc/APIchanges the patch is techincally ok, i dont know which prefix people prefer though [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB DNS cache poisoning attacks, popular search engine, Google internet authority dont be evil, please signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v6] Add support for Audible AAX (and AAX+) files
Thanks for all the feedback.
VesselinFrom 99d97f2d1f0a62fb75ba9af4c20edaa59f02bb51 Mon Sep 17 00:00:00 2001
From: Vesselin Bontchev
Date: Sat, 11 Jul 2015 18:02:47 +
Subject: [PATCH] Add support for Audible AAX (and AAX+) files
---
doc/general.texi | 2 +
doc/muxers.texi| 7 +++
libavformat/isom.h | 8
libavformat/mov.c | 128 +
4 files changed, 145 insertions(+)
diff --git a/doc/general.texi b/doc/general.texi
index dc22d90..617be66 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -226,6 +226,8 @@ library:
@item 4xm @tab @tab X
@tab 4X Technologies format, used in some games.
@item 8088flex TMV @tab @tab X
+@item AAX @tab @tab X
+@tab Audible Enhanced Audio format, used in audiobooks.
@item ACT Voice @tab @tab X
@tab contains G.729 audio
@item Adobe Filmstrip @tab X @tab X
diff --git a/doc/muxers.texi b/doc/muxers.texi
index d75d7de..b5fc598 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -667,6 +667,13 @@ point on IIS with this muxer. Example:
ffmpeg -re @var{} -movflags isml+frag_keyframe -f ismv http://server/publishingpoint.isml/Streams(Encoder1)
@end example
+@subsection Audible AAX
+
+Audible AAX files are encrypted M4B files, and they can be decrypted by specifying a 4 byte activation secret.
+@example
+ffmpeg -activation_bytes 1CEB00DA -i test.aax -vn -c:a copy output.mp4
+@end example
+
@section mp3
The MP3 muxer writes a raw MP3 stream with the following optional features:
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 5d48989..aee9d6e 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -198,6 +198,14 @@ typedef struct MOVContext {
MOVFragmentIndex** fragment_index_data;
unsigned fragment_index_count;
int atom_depth;
+unsigned int aax_mode; ///< 'aax' file has been detected
+uint8_t file_key[20];
+uint8_t file_iv[20];
+void *activation_bytes;
+int activation_bytes_size;
+void *audible_fixed_key;
+int audible_fixed_key_size;
+struct AVAES *aes_decrypt;
} MOVContext;
int ff_mp4_read_descr_len(AVIOContext *pb);
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9d6b2e4..92bf2f8 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -37,6 +37,8 @@
#include "libavutil/dict.h"
#include "libavutil/display.h"
#include "libavutil/opt.h"
+#include "libavutil/aes.h"
+#include "libavutil/sha.h"
#include "libavutil/timecode.h"
#include "libavcodec/ac3tab.h"
#include "avformat.h"
@@ -807,6 +809,120 @@ static int mov_read_mdat(MOVContext *c, AVIOContext *pb, MOVAtom atom)
return 0; /* now go for moov */
}
+#define DRM_BLOB_SIZE 56
+
+static int mov_read_adrm(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+uint8_t intermediate_key[20];
+uint8_t intermediate_iv[20];
+uint8_t input[64];
+uint8_t output[64];
+uint8_t file_checksum[20];
+uint8_t calculated_checksum[20];
+struct AVSHA *sha;
+int i;
+int ret = 0;
+uint8_t *activation_bytes = c->activation_bytes;
+uint8_t *fixed_key = c->audible_fixed_key;
+
+c->aax_mode = 1;
+
+sha = av_sha_alloc();
+if (!sha)
+return AVERROR(ENOMEM);
+c->aes_decrypt = av_aes_alloc();
+if (!c->aes_decrypt) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
+/* drm blob processing */
+avio_read(pb, output, 8); // go to offset 8, absolute postion 0x251
+avio_read(pb, input, DRM_BLOB_SIZE);
+avio_read(pb, output, 4); // go to offset 4, absolute postion 0x28d
+avio_read(pb, file_checksum, 20);
+
+av_log(c->fc, AV_LOG_INFO, "[aax] file checksum == "); // required by external tools
+for (i = 0; i < 20; i++)
+av_log(sha, AV_LOG_INFO, "%02x", file_checksum[i]);
+av_log(c->fc, AV_LOG_INFO, "\n");
+
+/* verify activation data */
+if (!activation_bytes || c->activation_bytes_size != 4) {
+av_log(c->fc, AV_LOG_FATAL, "[aax] activation_bytes option is missing!\n");
+ret = AVERROR(EINVAL);
+goto fail;
+}
+if (c->activation_bytes_size != 4) {
+av_log(c->fc, AV_LOG_FATAL, "[aax] activation_bytes value needs to be 4 bytes!\n");
+ret = AVERROR(EINVAL);
+goto fail;
+}
+
+/* verify fixed key */
+if (c->audible_fixed_key_size != 16) {
+av_log(c->fc, AV_LOG_FATAL, "[aax] audible_fixed_key value needs to be 16 bytes!\n");
+ret = AVERROR(EINVAL);
+goto fail;
+}
+
+/* AAX (and AAX+) key derivation */
+av_sha_init(sha, 160);
+av_sha_update(sha, fixed_key, 16);
+av_sha_update(sha, activation_bytes, 4);
+av_sha_final(sha, intermediate_key);
+av_sha_init(sha, 160);
+av_sha_update(sha, fixed_key, 16);
+av_sha_update(sha, intermediate_key, 20);
+av_sha_update(sha, activation_bytes, 4);
+av_sha_final(sha, intermediate_iv);
+av_sha_init(sha, 160);
+
Re: [FFmpeg-devel] FFmpeg/MPlayer/rtmpdump possibly searching for a new server and hosting
On Sat, 18 Jul 2015 04:19:15 +0200 Michael Niedermayer wrote: > On Fri, Jul 17, 2015 at 08:04:37PM -0400, Ronald S. Bultje wrote: > > Hi, > > > > On Fri, Jul 17, 2015 at 7:20 PM, Kieran Kunhya > > wrote: > > > > > On 17 July 2015 at 22:00, Michael Niedermayer > > > wrote: > > > > On Fri, Jul 17, 2015 at 04:16:53PM +0200, Michael Niedermayer > > > > wrote: > > > >> On Fri, Jul 17, 2015 at 03:30:26PM +0200, Jean-Baptiste Kempf > > > >> wrote: > > > >> > On 15 Jul, Michael Niedermayer wrote : > > > >> > > longer awnser, > > > >> > > videolan IIUC would be willing to host some of our services > > > >> > > on their existing server but this would require a "quite a > > > >> > > bit" of work. videolan uses LXC we do not. > > > >> > > > > >> > Indeed, and there is a good reason for that, called security. > > > >> > > > > >> > > also videolan of course would have to agree to everything, > > > >> > > its their server of course ... > > > >> > > > > >> > VideoLAN has very powerfull machines, connected in a correct > > > datacenter, > > > >> > with a contract, that will outlive any single member. > > > >> > > > > >> > > > >> > Don't take it bad, but seeing the discussions, and the way > > > >> > you manage your roots and services migration, you don't seem > > > >> > to care that much about being correctly deployed, but to do > > > >> > it fast. > > > >> > > > >> iam not taking it bad but when you are being told your boxes > > > >> could be shutdown without prior notice by the new managment, > > > >> then yes you try to move fast, which is what we did. > > > >> Not because thats a great thing to do but because it was needed > > > > > > > > also speaking of that, id like to take the opertunity to thank > > > > everyone who helped making that quick move to the current > > > > servers possible That is at least alex, arpi, fabrice, beastd, > > > > kieran, reimar, roberto, lou, tim, ubitux and probably more > > > > who i have forgotten to list > > > > > > > > In principle we could stay at these servers but i think its > > > > better if we use the time available now to move things to some > > > > free, higher end servers and hosting and also if possible > > > > (volunteers) move to something like LXC or qemu/kvm in the > > > > process and have services properly seperated > > > > > > > > That would give us better servers, more robust hosting than > > > > what you get with a 50euro/mo box. more security and at less > > > > cost. > > > > > > Sorry but this is a bizzare and short-sighted goal. Whilst I am > > > sure most of the offers mean well it's much better to get help > > > from the community because at least we know who they are, where > > > the data is stored, easily contactable etc. The person offering > > > free hosting could just leave their company and the machine wiped > > > one day. > > > > > > J-B offered that videolan will host ffmpeg. I, for one, would be > > thrilled if that were to happen. I trust videolan a lot. > > so do i, i trust JB, but will JB still be in charge in 5 years? > in 10 years? can we trust whoever will come after JB ? > > I think FFmpeg should stay with a "neutral" provider/hoster. I also trust JB. But I remember the libav fork and some vlc devels/admins during that time. http://ffmpeg.org/pipermail/ffmpeg-devel/2011-January/106458.html i think vlc would be a good host as long as JB is there. -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v5] Add support for Audible AAX (and AAX+) files
18.07.2015, 13:03, "Paul B Mahol" :
> Dana 18. 7. 2015. 11:46 osoba "Vesselin Bontchev" <
> vesselin.bontc...@yandex.com> napisala je:
>> 18.07.2015, 01:45, "Michael Niedermayer" :
>> > On Thu, Jul 16, 2015 at 03:57:26AM +0300, Vesselin Bontchev wrote:
>> >> + // extracted from libAAX_SDK.so and AAXSDKWin.dll files!
>> >
>> >> + uint8_t fixed_key[] = { 0x77, 0x21, 0x4d, 0x4b, 0x19, 0x6a, 0x87,
>> >
>> > I think this should not be hardcoded but provided by the user via
>> > an AVOption.
>>
>> I fear that doing this will impact the usability negatively. Are there
>> strong reasons for suggesting this change?
> Using AVOption will set default key to what is already now hardcoded.
Thanks for explaining this! I have now uploaded a new revision (v6) of the
patch, which uses an AVOption.
Vesselin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/developer: add url for sample files
Signed-off-by: Ganesh Ajjanagadde
---
doc/developer.texi | 4
1 file changed, 4 insertions(+)
diff --git a/doc/developer.texi b/doc/developer.texi
index d9ccf7b..9060bd1 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -544,6 +544,10 @@ should not crash, end in a (near) infinite loop, or
allocate ridiculous
amounts of memory when fed damaged data.
@item
+Did you test your decoder or demuxer against sample files?
+Samples may be obtained at @url{samples.ffmpeg.org}.
+
+@item
Does the patch not mix functional and cosmetic changes?
@item
--
2.4.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2] doc/developer: add url for sample files
Signed-off-by: Ganesh Ajjanagadde
---
doc/developer.texi | 4
1 file changed, 4 insertions(+)
diff --git a/doc/developer.texi b/doc/developer.texi
index d9ccf7b..7e9f0b2 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -544,6 +544,10 @@ should not crash, end in a (near) infinite loop, or
allocate ridiculous
amounts of memory when fed damaged data.
@item
+Did you test your decoder or demuxer against sample files?
+Samples may be obtained at @url{http://samples.ffmpeg.org}.
+
+@item
Does the patch not mix functional and cosmetic changes?
@item
--
2.4.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Hosting offer for ffmpeg by DreamHack
Hello all! We at DreamHack would like to offer the ffmpeg project free hosting. Location for this hosting would be in Sweden, and to be more exact Stockholm. Hardware: We have a few machines spare, and the most suitable of those machines would be this: 1x E5-2407 48GB Ram 4x 4TB SATA (In what ever raid config you want) Network: The location where it will be hosted as redundant 10G connection from AS12552 (www.ip-only.se). The machine would get an own VLAN with a /29 IPv4 and a /64 IPv6 allocation. If you want to traceroute/ping something in the network, you can do that against www.dreamhack.se. The only requirement we have for this is that we can SNMP monitor the machine. // Markus Viitamäki suom1 @ IRC ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] conversion of FFV1 specification from lyx to markdown
> On Jul 10, 2015, at 3:51 PM, Michael Niedermayer
> wrote:
>
> On Fri, Jul 10, 2015 at 03:47:45PM -0400, Dave Rice wrote:
>>
>>> On Jul 10, 2015, at 2:06 PM, Michael Niedermayer
>>> wrote:
>>>
>>> On Fri, Jul 10, 2015 at 07:51:20PM +0200, Michael Niedermayer wrote:
On Fri, Jul 10, 2015 at 07:47:46PM +0200, Michael Niedermayer wrote:
> On Fri, Jul 10, 2015 at 11:52:24AM +0200, Michael Niedermayer wrote:
>> On Thu, Jul 09, 2015 at 02:14:36PM -0400, Dave Rice wrote:
>>>
On Jul 9, 2015, at 1:53 PM, Michael Niedermayer
wrote:
On Tue, Jul 07, 2015 at 11:03:39AM -0400, Dave Rice wrote:
> Hi,
>
>> On Jul 7, 2015, at 10:35 AM, Michael Niedermayer
>> wrote:
>>
>> On Thu, Jul 02, 2015 at 09:50:21AM -0400, Dave Rice wrote:
>>> Hi all,
>>> Last month I posted a draft of the FFV1 specification formatted in
>>> Markdown [1], whereas it currently lives in lyx. From that post
>>> there were responses in favor of the use of Markdown formatting and
>>> suggestions to not use mathml within a draft targeting an RFC
>>> specification and suggestions to update a few urls. I propose to
>>> proceed with a format conversion of the FFV1 specification from lyx
>>> to Markdown and then I'll file tickets or patches to explore
>>> simplifying the mathml expressions and updating the urls. Attached
>>> is a patch to convert the formatting (but not meaning) of the FFV1
>>> specification from lyx to markdown.
>>>
>>> Best Regards,
>>> Dave Rice
>>>
>>> [1] http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/193851
>>>
>>
>> how can this be edited and converted ?
>
> Via pandoc you can get outputs that are close to the current
> ffv1.html and ffv1.pdf outputs of ffv1.lyx.
>
> pandoc --mathml -s --number-sections ../ffv1.md -c lyx.css -o
> ffv1.html
> pandoc -s --number-sections ../ffv1.md --latex-engine=xelatex -V
> geometry:margin=1in -o ffv1.pdf
>
> I can move this info to a readme.
please do
>>>
>>> Sure. Would you prefer a patch on ffmpeg-devel or a PR in github?
>>
>> whatever you prefer
>
> generated files like pdf should not be checked into git.
> instead add a Makefile to generate them, so a simple
> make
> or
> make ffv1.pdf
> generates the file
also the readme should document which version of markdown/pandoc
this needs
and something should check for that version ideally so the user
is nt left wondering why "make" produces broken tables
>>>
>>> reviewing the pull req
>>>
>>> The conventions section 3.
>>> lacks vertical alignment
>>
>> Fixed in
>> https://github.com/MediaArea/FFV1/commit/d25fb39f7514547f72cbc13ef3851f3c9d9c0c5f
>>
>>> theres an empty line after
>>> for(i=0;i>
>> Fixed in
>> https://github.com/MediaArea/FFV1/commit/1291e6c3e90ea6816b543a9e12c08d1cbbc1f31c
>>
>
>>> 4.6.2.5:
>>> log2_run[41]={JPEGLS.
>>> 0,0,0,0,1,1,1,1,
>>>
>>> that JPEGLS is supposed to be a link/reference/whatever but its a
>>> litteral word
>>
>> I'm having trouble getting a footnote to work within a codeblock. It is
>> feasible to use this footnote in a reference to JPEGLS in a sentence above
>> the codeblock?
>
> of course
> whatever works
updated here
https://github.com/MediaArea/FFV1/commit/0c2ab02152e61a5a59e1e003b8c8b7f0acb1a70c
[...]
Dave Rice
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] conversion of FFV1 specification from lyx to markdown
> On Jul 10, 2015, at 4:55 PM, Michael Niedermayer
> wrote:
>
> On Fri, Jul 10, 2015 at 04:19:41PM -0400, Dave Rice wrote:
>>
>>> On Jul 10, 2015, at 3:51 PM, Michael Niedermayer
>>> wrote:
>>>
>>> On Fri, Jul 10, 2015 at 03:47:45PM -0400, Dave Rice wrote:
> On Jul 10, 2015, at 2:06 PM, Michael Niedermayer
> wrote:
>
> On Fri, Jul 10, 2015 at 07:51:20PM +0200, Michael Niedermayer wrote:
>> On Fri, Jul 10, 2015 at 07:47:46PM +0200, Michael Niedermayer wrote:
>>> On Fri, Jul 10, 2015 at 11:52:24AM +0200, Michael Niedermayer wrote:
On Thu, Jul 09, 2015 at 02:14:36PM -0400, Dave Rice wrote:
>
>> On Jul 9, 2015, at 1:53 PM, Michael Niedermayer
>> wrote:
>>
>> On Tue, Jul 07, 2015 at 11:03:39AM -0400, Dave Rice wrote:
>>> Hi,
>>>
On Jul 7, 2015, at 10:35 AM, Michael Niedermayer
wrote:
On Thu, Jul 02, 2015 at 09:50:21AM -0400, Dave Rice wrote:
> Hi all,
> Last month I posted a draft of the FFV1 specification formatted
> in Markdown [1], whereas it currently lives in lyx. From that
> post there were responses in favor of the use of Markdown
> formatting and suggestions to not use mathml within a draft
> targeting an RFC specification and suggestions to update a few
> urls. I propose to proceed with a format conversion of the FFV1
> specification from lyx to Markdown and then I'll file tickets or
> patches to explore simplifying the mathml expressions and
> updating the urls. Attached is a patch to convert the formatting
> (but not meaning) of the FFV1 specification from lyx to markdown.
>
> Best Regards,
> Dave Rice
>
> [1] http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/193851
>
how can this be edited and converted ?
>>>
>>> Via pandoc you can get outputs that are close to the current
>>> ffv1.html and ffv1.pdf outputs of ffv1.lyx.
>>>
>>> pandoc --mathml -s --number-sections ../ffv1.md -c lyx.css -o
>>> ffv1.html
>>> pandoc -s --number-sections ../ffv1.md --latex-engine=xelatex -V
>>> geometry:margin=1in -o ffv1.pdf
>>>
>>> I can move this info to a readme.
>>
>> please do
>
> Sure. Would you prefer a patch on ffmpeg-devel or a PR in github?
whatever you prefer
>>>
>>> generated files like pdf should not be checked into git.
>>> instead add a Makefile to generate them, so a simple
>>> make
>>> or
>>> make ffv1.pdf
>>> generates the file
>>
>> also the readme should document which version of markdown/pandoc
>> this needs
>> and something should check for that version ideally so the user
>> is nt left wondering why "make" produces broken tables
>
> reviewing the pull req
>
> The conventions section 3.
> lacks vertical alignment
Fixed in
https://github.com/MediaArea/FFV1/commit/d25fb39f7514547f72cbc13ef3851f3c9d9c0c5f
> theres an empty line after
> for(i=0;i>>>
Fixed in
https://github.com/MediaArea/FFV1/commit/1291e6c3e90ea6816b543a9e12c08d1cbbc1f31c
>>>
> 4.6.2.5:
> log2_run[41]={JPEGLS.
> 0,0,0,0,1,1,1,1,
>
> that JPEGLS is supposed to be a link/reference/whatever but its a
> litteral word
I'm having trouble getting a footnote to work within a codeblock. It is
feasible to use this footnote in a reference to JPEGLS in a sentence above
the codeblock?
>>>
>>> of course
>>> whatever works
>>
>> I don't understand the relationship between the function and the reference
>> to JPEG-LS. I could simply move the footnote reference to JPEGLS to outside
>> of the codeblock, but it would be better to also explain the relationship at
>> the same time. Could you provide some background as to why JPEGLS is
>> referenced here.
>
> This table is also used by jpegls, see ff_log2_run in libavcodec
>
>
> some other things
> nested TOC and numbering in TOC is lost
Switching here to use pandoc's TOC features instead of maintaining them
manually.
https://github.com/MediaArea/FFV1/commit/64f643534c10ac6d680b63c75fa1b7cb670bd9c4
> in "4.6.1.4 State transition table" there should be a newline
> before one_statei = ...
Added here:
https://github.com/MediaArea/FFV1/commit/701edaf67ad1f0933cac1fc74f4921a209461164
> 4.6.2 Huffman coding mode
> the content and headings seem to mismatch
> the prefix table is above the prefix heading
> the examples empty
Can you review again in git master. I've already made changes in this section
according to Timothy Gu's comments.
> the stuff inside
> ConfigurationRecord()
> lo
Re: [FFmpeg-devel] [PATCH]Rename FF_CODEC_PROPERTY_* as AV_CODEC_PROPERTY_*
On Sat, 18 Jul 2015 13:58:20 +0200 Michael Niedermayer wrote: > On Fri, Jul 17, 2015 at 12:27:40AM +0200, Carl Eugen Hoyos wrote: > > Hi! > > > > I am not really happy with attached patch as most defines in avcodec.h > > use the FF_ prefix. > > > > Please comment, Carl Eugen > > > doc/APIchanges |4 > > libavcodec/avcodec.h |4 ++-- > > libavcodec/h264.c |2 +- > > libavcodec/mjpegdec.c |4 ++-- > > libavcodec/mpeg12dec.c |2 +- > > libavcodec/utils.c |4 ++-- > > libavcodec/version.h |2 +- > > libavcodec/vp9.c |2 +- > > libavcodec/webp.c |2 +- > > 9 files changed, 15 insertions(+), 11 deletions(-) > > 74154d7ebedba679bea09d9c150d1e605f363828 patchavcodecproperties.diff > > diff --git a/doc/APIchanges b/doc/APIchanges > > the patch is techincally ok, i dont know which prefix people prefer > though FF_ is just a historic mistake (and was probably kept because they're not linker-level symbols?) - no need to repeat this mistake with new identifiers. I expect some day all public FF_ constants will be changed to AV_. (Maybe Libav will do this.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add sidechain compress audio filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 45 ++
libavfilter/Makefile | 1 +
libavfilter/af_sidechaincompress.c | 316 +
libavfilter/allfilters.c | 1 +
4 files changed, 363 insertions(+)
create mode 100644 libavfilter/af_sidechaincompress.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 1bef836..9ad75e7 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -622,6 +622,7 @@ slope
Specify the band-width of a filter in width_type units.
@end table
+@anchor{amerge}
@section amerge
Merge two or more audio streams into a single multi-channel stream.
@@ -2020,6 +2021,7 @@ Applies only to double-pole filter.
The default is 0.707q and gives a Butterworth response.
@end table
+@anchor{pan}
@section pan
Mix channels with specific gain levels. The filter accepts the output
@@ -2121,6 +2123,49 @@ At end of filtering it displays @code{track_gain} and
@code{track_peak}.
Convert the audio sample format, sample rate and channel layout. It is
not meant to be used directly.
+@section sidechaincompress
+
+This filter acts like normal compressor but has the ability to filter detected
+signal before sending it to the compression stage.
+It needs two input streams and returns one output stream.
+First input stream will be processed depending on second stream signal.
+The filtered signal then can be filtered with other filters in later stages of
+processing. See @ref{pan} and @ref{amerge} filter.
+
+The filter accepts the following options:
+
+@table @option
+@item threshold
+If a signal of second stream raises above this level it will affect the gain
+reduction of first stream.
+By default is 0.125. Range is between 0.00097563 and 1.
+
+@item ratio
+Set a ratio about which the signal is reduced. 1:2 means that if the level
+raised 4dB above the threshold, it will be only 2dB above after the reduction.
+Default is 2. Range is between 1 and 20.
+
+@item attack
+Amount of milliseconds the signal has to rise above the threshold before gain
+reduction starts. Default is 20. Range is between 0.01 and 2000.
+
+@item release
+Amount of milliseconds the signal has to fall bellow the threshold before
+reduction is decreased again. Default is 250. Range is between 0.01 and 9000.
+
+@item makeup
+Set the amount by how much signal will be amplified after processing.
+Default is 2. Range is from 1 and 64.
+
+@item knee
+Curve the sharp knee around the threshold to enter gain reduction more softly.
+Default is 2.82843. Range is between 1 and 8.
+
+@item link
+Choose if the average level between all channels of sidechain stream or the
+louder channel of sidechain stream affects the reduction.
+@end table
+
@section silencedetect
Detect silence in an audio stream.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a259851..b497b58 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -79,6 +79,7 @@ OBJS-$(CONFIG_LOWPASS_FILTER)+= af_biquads.o
OBJS-$(CONFIG_PAN_FILTER)+= af_pan.o
OBJS-$(CONFIG_REPLAYGAIN_FILTER) += af_replaygain.o
OBJS-$(CONFIG_RESAMPLE_FILTER) += af_resample.o
+OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER) += af_sidechaincompress.o
OBJS-$(CONFIG_SILENCEDETECT_FILTER) += af_silencedetect.o
OBJS-$(CONFIG_SILENCEREMOVE_FILTER) += af_silenceremove.o
OBJS-$(CONFIG_TREBLE_FILTER) += af_biquads.o
diff --git a/libavfilter/af_sidechaincompress.c
b/libavfilter/af_sidechaincompress.c
new file mode 100644
index 000..0dc6932
--- /dev/null
+++ b/libavfilter/af_sidechaincompress.c
@@ -0,0 +1,316 @@
+/*
+ * Copyright (C) 2001-2010 Krzysztof Foltman, Markus Schmidt, Thor Harald
Johansen and others
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Sidechain compressor filter
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/common.h"
+#include "libavutil/opt.h"
+
+#include "audio.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+
+typedef struct SidechainCompressContext {
+const AVClass *class;
+
+double attack, attack_coeff;
+doubl
[FFmpeg-devel] [PATCH] fate: add tblend filter test
Signed-off-by: Paul B Mahol --- tests/fate/filter-video.mak | 3 +++ tests/ref/fate/filter-tblend | 50 2 files changed, 53 insertions(+) create mode 100644 tests/ref/fate/filter-tblend diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index 909aa29..641546e 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -238,6 +238,9 @@ fate-filter-shuffleplanes-swapuv: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf shuff FATE_FILTER_VSYNTH-$(CONFIG_SHUFFLEPLANES_FILTER) += $(FATE_SHUFFLEPLANES) +FATE_FILTER_VSYNTH-$(CONFIG_TBLEND_FILTER) += fate-filter-tblend +fate-filter-tblend: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf tblend=all_mode=difference128 + FATE_FILTER_VSYNTH-$(CONFIG_TELECINE_FILTER) += fate-filter-telecine fate-filter-telecine: CMD = framecrc -c:v pgmyuv -i $(SRC) -vf telecine diff --git a/tests/ref/fate/filter-tblend b/tests/ref/fate/filter-tblend new file mode 100644 index 000..3ff689a --- /dev/null +++ b/tests/ref/fate/filter-tblend @@ -0,0 +1,50 @@ +#tb 0: 1/25 +0, 1, 1,1, 152064, 0x8e50e5e5 +0, 2, 2,1, 152064, 0x7187a95e +0, 3, 3,1, 152064, 0xbd73863e +0, 4, 4,1, 152064, 0xabaefc78 +0, 5, 5,1, 152064, 0xf080523f +0, 6, 6,1, 152064, 0x2ba7c11c +0, 7, 7,1, 152064, 0x1bfe0964 +0, 8, 8,1, 152064, 0xe081d9db +0, 9, 9,1, 152064, 0x26eee75b +0, 10, 10,1, 152064, 0xcc28e18c +0, 11, 11,1, 152064, 0x3d2ed08b +0, 12, 12,1, 152064, 0x4567acbe +0, 13, 13,1, 152064, 0xa22f09db +0, 14, 14,1, 152064, 0xe4438e6f +0, 15, 15,1, 152064, 0x34d02799 +0, 16, 16,1, 152064, 0x4c9230b3 +0, 17, 17,1, 152064, 0x08e6c23c +0, 18, 18,1, 152064, 0xa0a475a5 +0, 19, 19,1, 152064, 0x47f5d5e9 +0, 20, 20,1, 152064, 0x0713219a +0, 21, 21,1, 152064, 0x9e4434a2 +0, 22, 22,1, 152064, 0xc06a2482 +0, 23, 23,1, 152064, 0xba321552 +0, 24, 24,1, 152064, 0x74070b31 +0, 25, 25,1, 152064, 0x92188f27 +0, 26, 26,1, 152064, 0x29cf1fae +0, 27, 27,1, 152064, 0x04fd06ea +0, 28, 28,1, 152064, 0xcbbded09 +0, 29, 29,1, 152064, 0x7f731df8 +0, 30, 30,1, 152064, 0x9fd5b56f +0, 31, 31,1, 152064, 0x82217442 +0, 32, 32,1, 152064, 0x95496106 +0, 33, 33,1, 152064, 0xb9c50804 +0, 34, 34,1, 152064, 0xa7051cba +0, 35, 35,1, 152064, 0x76bc5e88 +0, 36, 36,1, 152064, 0x8276cfb2 +0, 37, 37,1, 152064, 0x88bbf936 +0, 38, 38,1, 152064, 0x160c5d4e +0, 39, 39,1, 152064, 0x0b61942a +0, 40, 40,1, 152064, 0x4a4aae9b +0, 41, 41,1, 152064, 0x049978fa +0, 42, 42,1, 152064, 0x12584f81 +0, 43, 43,1, 152064, 0xada82b80 +0, 44, 44,1, 152064, 0x3a4876ef +0, 45, 45,1, 152064, 0x7ccb86f2 +0, 46, 46,1, 152064, 0x11bef54d +0, 47, 47,1, 152064, 0xb1714cd0 +0, 48, 48,1, 152064, 0x950a3388 +0, 49, 49,1, 152064, 0x1c1cc3ec -- 1.7.11.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] doc/developer: add url for sample files
On Sat, Jul 18, 2015 at 08:34:02AM -0400, Ganesh Ajjanagadde wrote: > Signed-off-by: Ganesh Ajjanagadde > --- > doc/developer.texi | 4 > 1 file changed, 4 insertions(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avdevice/decklink: Fix build error caused by a change in the SDK.
GetBufferedAudioSampleFrameCount() used to take an unsigned long, but this
changed at some point and the latest version of the DeckLink SDK (10.4.1) takes
an unsigned int.
Signed-off-by: Chris Spencer
---
libavdevice/decklink_common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 96912a7..41fb5fb 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -82,7 +82,7 @@ struct decklink_ctx {
typedef enum { DIRECTION_IN, DIRECTION_OUT} decklink_direction_t;
#ifdef _WIN32
-typedef unsigned long buffercount_type;
+typedef unsigned int buffercount_type;
IDeckLinkIterator *CreateDeckLinkIteratorInstance(void);
#else
typedef uint32_t buffercount_type;
--
1.9.5.msysgit.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avdevice/decklink: Add missing libraries when building with DeckLink support on Windows.
Signed-off-by: Chris Spencer --- configure | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configure b/configure index 1752a35..c2a9564 100755 --- a/configure +++ b/configure @@ -4298,6 +4298,8 @@ case $target_os in else target_os=mingw32 fi +decklink_outdev_extralibs="$decklink_outdev_extralibs -lole32 -loleaut32" +decklink_indev_extralibs="$decklink_indev_extralibs -lole32 -loleaut32" LIBTARGET=i386 if enabled x86_64; then LIBTARGET="i386:x86-64" -- 1.9.5.msysgit.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avdevice/decklink: Add support for decoding 8-bit RGB formats.
This adds a new pixel_format option to allow argb or bgra inputs. This is
necessary to capture RGB HDMI inputs.
Signed-off-by: Chris Spencer
---
doc/indevs.texi | 25 +++
doc/outdevs.texi| 2 +-
libavdevice/decklink_common.cpp | 4 ++--
libavdevice/decklink_common.h | 1 +
libavdevice/decklink_common_c.h | 1 +
libavdevice/decklink_dec.cpp| 44 +++--
libavdevice/decklink_dec_c.c| 7 ---
libavdevice/decklink_enc.cpp| 2 ++
8 files changed, 66 insertions(+), 20 deletions(-)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index d5415bb..fd5fe57 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -158,12 +158,12 @@ DeckLink devices.
To enable this input device, you need the Blackmagic DeckLink SDK and you
need to configure with the appropriate @code{--extra-cflags}
and @code{--extra-ldflags}.
-On Windows, you need to run the IDL files through @command{widl}.
+On Windows, you need to run the IDL files through @command{midl}.
-DeckLink is very picky about the formats it supports. Pixel format is
-uyvy422 or v210, framerate and video size must be determined for your device
with
-@command{-list_formats 1}. Audio sample rate is always 48 kHz and the number
-of channels can be 2, 8 or 16.
+DeckLink is very picky about the formats it supports. Pixel format is uyvy422,
+v210, argb or bgra, framerate and video size must be determined for your device
+with @command{-list_formats 1}. Audio sample rate is always 48 kHz and the
+number of channels can be 2, 8 or 16.
@subsection Options
@@ -177,9 +177,18 @@ Defaults to @option{false}.
If set to @option{true}, print a list of supported formats and exit.
Defaults to @option{false}.
-@item bm_v210
-If set to @samp{1}, video is captured in 10 bit v210 instead
-of uyvy422. Not all Blackmagic devices support this option.
+@item bm_v210 @emph{(deprecated)}
+If set to @samp{1}, video is captured in 10 bit v210 instead of uyvy422. Not
all
+Blackmagic devices support this option. This option is deprecated, use
+@option{pixel_format=yuv422p10} instead.
+
+@item pixel_format
+Sets the pixel format for the device to use. If the pixel format does not match
+the input source you may not get any video (it may be necessary to use an RGB
+format if capturing HDMI from a computer graphics card, for instance). Not all
+Blackmagic devices support all formats. Available pixel formats are:
+@code{uyvy422, yuv422p10, argb, bgra}
+Defaults to @option{uyvy422}.
@end table
diff --git a/doc/outdevs.texi b/doc/outdevs.texi
index e68653f..6015d29 100644
--- a/doc/outdevs.texi
+++ b/doc/outdevs.texi
@@ -128,7 +128,7 @@ DeckLink devices.
To enable this output device, you need the Blackmagic DeckLink SDK and you
need to configure with the appropriate @code{--extra-cflags}
and @code{--extra-ldflags}.
-On Windows, you need to run the IDL files through @command{widl}.
+On Windows, you need to run the IDL files through @command{midl}.
DeckLink is very picky about the formats it supports. Pixel format is always
uyvy422, framerate and video size must be determined for your device with
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index ac7964c..49a1487 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -157,12 +157,12 @@ int ff_decklink_set_format(AVFormatContext *avctx,
if (ctx->bmd_mode == bmdModeUnknown)
return -1;
if (direction == DIRECTION_IN) {
-if (ctx->dli->DoesSupportVideoMode(ctx->bmd_mode, bmdFormat8BitYUV,
+if (ctx->dli->DoesSupportVideoMode(ctx->bmd_mode, ctx->bmd_format,
bmdVideoOutputFlagDefault,
&support, NULL) != S_OK)
return -1;
} else {
-if (ctx->dlo->DoesSupportVideoMode(ctx->bmd_mode, bmdFormat8BitYUV,
+if (ctx->dlo->DoesSupportVideoMode(ctx->bmd_mode, ctx->bmd_format,
bmdVideoOutputFlagDefault,
&support, NULL) != S_OK)
return -1;
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 41fb5fb..5f3cab9 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -46,6 +46,7 @@ struct decklink_ctx {
BMDTimeValue bmd_tb_den;
BMDTimeValue bmd_tb_num;
BMDDisplayMode bmd_mode;
+BMDPixelFormat bmd_format;
int bmd_width;
int bmd_height;
int bmd_field_dominance;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index fb2b788..28db96c 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -29,5 +29,6 @@ struct decklink_cctx {
int list_formats;
double preroll;
int v210;
+enum AVPixelFormat pixel_format;
};
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index
Re: [FFmpeg-devel] [PATCH] fate: add tblend filter test
On Sat, Jul 18, 2015 at 02:31:58AM +, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > tests/fate/filter-video.mak | 3 +++ > tests/ref/fate/filter-tblend | 50 > > 2 files changed, 53 insertions(+) > create mode 100644 tests/ref/fate/filter-tblend this sefaults ==3437== Process terminating with default action of signal 11 (SIGSEGV) ==3437== Bad permissions for mapped region at address 0x0 ==3437==at 0x0: ??? ==3437==by 0x46F72F: worker (pthread.c:92) ==3437==by 0xD1C1E99: start_thread (pthread_create.c:308) ==3437==by 0xD4CA38C: clone (clone.S:112) [] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add tblend filter test
On 7/18/15, Michael Niedermayer wrote: > On Sat, Jul 18, 2015 at 02:31:58AM +, Paul B Mahol wrote: >> Signed-off-by: Paul B Mahol >> --- >> tests/fate/filter-video.mak | 3 +++ >> tests/ref/fate/filter-tblend | 50 >> >> 2 files changed, 53 insertions(+) >> create mode 100644 tests/ref/fate/filter-tblend > > this sefaults > ==3437== Process terminating with default action of signal 11 (SIGSEGV) > ==3437== Bad permissions for mapped region at address 0x0 > ==3437==at 0x0: ??? > ==3437==by 0x46F72F: worker (pthread.c:92) > ==3437==by 0xD1C1E99: start_thread (pthread_create.c:308) > ==3437==by 0xD4CA38C: clone (clone.S:112) Heh. Does blend also crash? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat/mpegtsenc: support storing PAT/PMT per frame
On Thu, Jul 16, 2015 at 01:54:56AM +0200, Michael Niedermayer wrote: > From: Michael Niedermayer > > Signed-off-by: Michael Niedermayer > --- > libavformat/mpegtsenc.c |9 + > 1 file changed, 9 insertions(+) improved option name, added docs applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: Support a user specified PAT/PMT period
On Thu, Jul 16, 2015 at 12:56:55PM +0200, Michael Niedermayer wrote: > From: Michael Niedermayer > > Can be used to fix Ticket3714 > > TODO, add docs added docs applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add tblend filter test
On 7/18/15, Paul B Mahol wrote: > On 7/18/15, Michael Niedermayer wrote: >> On Sat, Jul 18, 2015 at 02:31:58AM +, Paul B Mahol wrote: >>> Signed-off-by: Paul B Mahol >>> --- >>> tests/fate/filter-video.mak | 3 +++ >>> tests/ref/fate/filter-tblend | 50 >>> >>> 2 files changed, 53 insertions(+) >>> create mode 100644 tests/ref/fate/filter-tblend >> >> this sefaults >> ==3437== Process terminating with default action of signal 11 (SIGSEGV) >> ==3437== Bad permissions for mapped region at address 0x0 >> ==3437==at 0x0: ??? >> ==3437==by 0x46F72F: worker (pthread.c:92) >> ==3437==by 0xD1C1E99: start_thread (pthread_create.c:308) >> ==3437==by 0xD4CA38C: clone (clone.S:112) > > Heh. > > Does blend also crash? > Also, on what OS is this? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add tblend filter test
On 7/18/15, Paul B Mahol wrote: > On 7/18/15, Paul B Mahol wrote: >> On 7/18/15, Michael Niedermayer wrote: >>> On Sat, Jul 18, 2015 at 02:31:58AM +, Paul B Mahol wrote: Signed-off-by: Paul B Mahol --- tests/fate/filter-video.mak | 3 +++ tests/ref/fate/filter-tblend | 50 2 files changed, 53 insertions(+) create mode 100644 tests/ref/fate/filter-tblend >>> >>> this sefaults >>> ==3437== Process terminating with default action of signal 11 (SIGSEGV) >>> ==3437== Bad permissions for mapped region at address 0x0 >>> ==3437==at 0x0: ??? >>> ==3437==by 0x46F72F: worker (pthread.c:92) >>> ==3437==by 0xD1C1E99: start_thread (pthread_create.c:308) >>> ==3437==by 0xD4CA38C: clone (clone.S:112) >> >> Heh. >> >> Does blend also crash? >> > > Also, on what OS is this? > Forget it, stupid bug. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] fate: add tblend filter test
On Sat, Jul 18, 2015 at 09:15:47PM +, Paul B Mahol wrote: > On 7/18/15, Paul B Mahol wrote: > > On 7/18/15, Michael Niedermayer wrote: > >> On Sat, Jul 18, 2015 at 02:31:58AM +, Paul B Mahol wrote: > >>> Signed-off-by: Paul B Mahol > >>> --- > >>> tests/fate/filter-video.mak | 3 +++ > >>> tests/ref/fate/filter-tblend | 50 > >>> > >>> 2 files changed, 53 insertions(+) > >>> create mode 100644 tests/ref/fate/filter-tblend > >> > >> this sefaults > >> ==3437== Process terminating with default action of signal 11 (SIGSEGV) > >> ==3437== Bad permissions for mapped region at address 0x0 > >> ==3437==at 0x0: ??? > >> ==3437==by 0x46F72F: worker (pthread.c:92) > >> ==3437==by 0xD1C1E99: start_thread (pthread_create.c:308) > >> ==3437==by 0xD4CA38C: clone (clone.S:112) > > > > Heh. > > > > Does blend also crash? > > > > Also, on what OS is this? was, normal plain linux on x86-64 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avutil/intmath: check for ICC before GCC
Intel compiler also defines __GNUC__, so the Intel specific intrinsics were not really being used. Signed-off-by: James Almer --- libavutil/intmath.h | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/libavutil/intmath.h b/libavutil/intmath.h index f5ecc77..ef347f4 100644 --- a/libavutil/intmath.h +++ b/libavutil/intmath.h @@ -39,22 +39,22 @@ */ #if HAVE_FAST_CLZ -#if AV_GCC_VERSION_AT_LEAST(3,4) +#if defined( __INTEL_COMPILER ) #ifndef ff_log2 -# define ff_log2(x) (31 - __builtin_clz((x)|1)) +# define ff_log2(x) (_bit_scan_reverse((x)|1)) # ifndef ff_log2_16bit # define ff_log2_16bit av_log2 # endif #endif /* ff_log2 */ -#elif defined( __INTEL_COMPILER ) +#elif AV_GCC_VERSION_AT_LEAST(3,4) #ifndef ff_log2 -# define ff_log2(x) (_bit_scan_reverse((x)|1)) +# define ff_log2(x) (31 - __builtin_clz((x)|1)) # ifndef ff_log2_16bit # define ff_log2_16bit av_log2 # endif #endif /* ff_log2 */ -#endif #endif /* AV_GCC_VERSION_AT_LEAST(3,4) */ +#endif extern const uint8_t ff_log2_tab[256]; @@ -115,13 +115,13 @@ static av_always_inline av_const int ff_log2_16bit_c(unsigned int v) */ #if HAVE_FAST_CLZ -#if AV_GCC_VERSION_AT_LEAST(3,4) +#if defined( __INTEL_COMPILER ) #ifndef ff_ctz -#define ff_ctz(v) __builtin_ctz(v) +#define ff_ctz(v) _bit_scan_forward(v) #endif -#elif defined( __INTEL_COMPILER ) +#elif AV_GCC_VERSION_AT_LEAST(3,4) #ifndef ff_ctz -#define ff_ctz(v) _bit_scan_forward(v) +#define ff_ctz(v) __builtin_ctz(v) #endif #endif #endif -- 2.4.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avutil/x86/bswap: force inline asm versions with ICC
Recent ICC versions that define GCC as >= 4.5 (like ICC 13) apparently can't
optimize the generic C versions of av_bswap*() on their own.
Signed-off-by: James Almer
---
libavutil/x86/bswap.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/x86/bswap.h b/libavutil/x86/bswap.h
index 08e2a62..67f1747 100644
--- a/libavutil/x86/bswap.h
+++ b/libavutil/x86/bswap.h
@@ -39,7 +39,7 @@ static av_always_inline av_const unsigned av_bswap16(unsigned
x)
}
#endif /* !AV_GCC_VERSION_AT_LEAST(4,1) */
-#if !AV_GCC_VERSION_AT_LEAST(4,5)
+#if !AV_GCC_VERSION_AT_LEAST(4,5) || defined(__INTEL_COMPILER)
#define av_bswap32 av_bswap32
static av_always_inline av_const uint32_t av_bswap32(uint32_t x)
{
--
2.4.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] can amerge use .needs_fifo?
Hi, Topic says it all. Thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avutil/intmath: check for ICC before GCC
On Sat, Jul 18, 2015 at 06:45:43PM -0300, James Almer wrote: > Intel compiler also defines __GNUC__, so the Intel specific intrinsics were > not > really being used. > > Signed-off-by: James Almer > --- > libavutil/intmath.h | 18 +- > 1 file changed, 9 insertions(+), 9 deletions(-) should be ok, i dont have ICC here though so only tested with gcc [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- 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 1/2] avutil/intmath: check for ICC before GCC
On 18/07/15 7:53 PM, Michael Niedermayer wrote: > On Sat, Jul 18, 2015 at 06:45:43PM -0300, James Almer wrote: >> Intel compiler also defines __GNUC__, so the Intel specific intrinsics were >> not >> really being used. >> >> Signed-off-by: James Almer >> --- >> libavutil/intmath.h | 18 +- >> 1 file changed, 9 insertions(+), 9 deletions(-) > > should be ok, i dont have ICC here though so only tested with gcc There are a few ICC fate clients, so we'll know if something breaks soon enough. Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avutil/x86/bswap: force inline asm versions with ICC
On Sat, Jul 18, 2015 at 06:45:44PM -0300, James Almer wrote: > Recent ICC versions that define GCC as >= 4.5 (like ICC 13) apparently can't > optimize the generic C versions of av_bswap*() on their own. > > Signed-off-by: James Almer > --- > libavutil/x86/bswap.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) probably ok, but like the other no ICC here for testing [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avutil/x86/bswap: force inline asm versions with ICC
On 18/07/15 8:33 PM, Michael Niedermayer wrote: > On Sat, Jul 18, 2015 at 06:45:44PM -0300, James Almer wrote: >> Recent ICC versions that define GCC as >= 4.5 (like ICC 13) apparently can't >> optimize the generic C versions of av_bswap*() on their own. >> >> Signed-off-by: James Almer >> --- >> libavutil/x86/bswap.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > probably ok, but like the other no ICC here for testing Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] apng: Support inter-frame compression
The current algorithm is just "try all the combinations, and pick the best".
It's not very fast either, probably due to a lot of copying, but will do for
an initial implementation.
Signed-off-by: Donny Yang
---
libavcodec/pngenc.c | 420 +++-
1 file changed, 384 insertions(+), 36 deletions(-)
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index 7a9d0b0..1cc8e21 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -36,6 +36,14 @@
#define IOBUF_SIZE 4096
+typedef struct APNGFctlChunk {
+uint32_t sequence_number;
+uint32_t width, height;
+uint32_t x_offset, y_offset;
+uint16_t delay_num, delay_den;
+uint8_t dispose_op, blend_op;
+} APNGFctlChunk;
+
typedef struct PNGEncContext {
AVClass *class;
HuffYUVEncDSPContext hdsp;
@@ -59,6 +67,12 @@ typedef struct PNGEncContext {
// APNG
uint32_t palette_checksum; // Used to ensure a single unique palette
uint32_t sequence_number;
+
+AVFrame *prev_frame;
+AVFrame *last_frame;
+APNGFctlChunk last_frame_fctl;
+uint8_t *last_frame_packet;
+size_t last_frame_packet_size;
} PNGEncContext;
static void png_get_interlaced_row(uint8_t *dst, int row_size,
@@ -403,7 +417,7 @@ static int encode_frame(AVCodecContext *avctx, const
AVFrame *pict)
uint8_t *progressive_buf = NULL;
uint8_t *top_buf = NULL;
-row_size = (avctx->width * s->bits_per_pixel + 7) >> 3;
+row_size = (pict->width * s->bits_per_pixel + 7) >> 3;
crow_base = av_malloc((row_size + 32) << (s->filter_type ==
PNG_FILTER_VALUE_MIXED));
if (!crow_base) {
@@ -430,16 +444,16 @@ static int encode_frame(AVCodecContext *avctx, const
AVFrame *pict)
for (pass = 0; pass < NB_PASSES; pass++) {
/* NOTE: a pass is completely omitted if no pixels would be
* output */
-pass_row_size = ff_png_pass_row_size(pass, s->bits_per_pixel,
avctx->width);
+pass_row_size = ff_png_pass_row_size(pass, s->bits_per_pixel,
pict->width);
if (pass_row_size > 0) {
top = NULL;
-for (y = 0; y < avctx->height; y++)
+for (y = 0; y < pict->height; y++)
if ((ff_png_pass_ymask[pass] << (y & 7)) & 0x80) {
ptr = p->data[0] + y * p->linesize[0];
FFSWAP(uint8_t *, progressive_buf, top_buf);
png_get_interlaced_row(progressive_buf, pass_row_size,
s->bits_per_pixel, pass,
- ptr, avctx->width);
+ ptr, pict->width);
crow = png_choose_filter(s, crow_buf, progressive_buf,
top, pass_row_size,
s->bits_per_pixel >> 3);
png_write_row(avctx, crow, pass_row_size + 1);
@@ -449,7 +463,7 @@ static int encode_frame(AVCodecContext *avctx, const
AVFrame *pict)
}
} else {
top = NULL;
-for (y = 0; y < avctx->height; y++) {
+for (y = 0; y < pict->height; y++) {
ptr = p->data[0] + y * p->linesize[0];
crow = png_choose_filter(s, crow_buf, ptr, top,
row_size, s->bits_per_pixel >> 3);
@@ -530,6 +544,272 @@ static int encode_png(AVCodecContext *avctx, AVPacket
*pkt,
return 0;
}
+static int apng_do_inverse_blend(AVFrame *output, const AVFrame *input,
+ APNGFctlChunk *fctl_chunk, uint8_t bpp)
+{
+// output: background, input: foreground
+// output the image such that when blended with the background, will
produce the foreground
+
+uint32_t x, y;
+uint32_t leftmost_x = input->width;
+uint32_t rightmost_x = 0;
+uint32_t topmost_y = input->height;
+uint32_t bottommost_y = 0;
+const uint8_t *input_data = input->data[0];
+uint8_t *output_data = output->data[0];
+size_t input_linesize = input->linesize[0];
+size_t output_linesize = output->linesize[0];
+
+// Find bounding box of changes
+for (y = 0; y < input->height; ++y) {
+for (x = 0; x < input->width; ++x) {
+if (!memcmp(input_data + bpp * x, output_data + bpp * x, bpp))
+continue;
+
+if (x < leftmost_x)
+leftmost_x = x;
+if (x >= rightmost_x)
+rightmost_x = x + 1;
+if (y < topmost_y)
+topmost_y = y;
+if (y >= bottommost_y)
+bottommost_y = y + 1;
+}
+
+input_data += input_linesize;
+output_data += output_linesize;
+}
+
+if (leftmost_x == input->width && rightmost_x == 0) {
+// Empty frame
+// APNG does not support empty frames, so we make it a 1x1 frame
+leftmost_x = topmost_y = 0;
+rightmost_x = bottommo
Re: [FFmpeg-devel] GSoC Weely report (libswscale)
On Wed, Jul 15, 2015 at 08:06:49PM -0300, Pedro Arthur wrote:
[...]
> diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
> index 2299aa5..82713fd 100644
> --- a/libswscale/swscale_internal.h
> +++ b/libswscale/swscale_internal.h
> @@ -269,6 +269,9 @@ typedef void (*yuv2anyX_fn)(struct SwsContext *c, const
> int16_t *lumFilter,
> const int16_t **alpSrc, uint8_t **dest,
> int dstW, int y);
>
> +struct SwsSlice;
> +struct SwsFilterDescriptor;
> +
> /* This struct should be aligned on at least a 32-byte boundary. */
> typedef struct SwsContext {
> /**
> @@ -319,6 +322,12 @@ typedef struct SwsContext {
> uint16_t *gamma;
> uint16_t *inv_gamma;
>
> +int numDesc;
> +int descIndex[2];
> +int numSlice;
> +struct SwsSlice *slice;
> +struct SwsFilterDescriptor *desc;
> +
> uint32_t pal_yuv[256];
> uint32_t pal_rgb[256];
>
> @@ -908,4 +917,55 @@ static inline void fillPlane16(uint8_t *plane, int
> stride, int width, int height
> }
> }
>
> +#define MAX_SLICE_PLANES 4
> +
> +typedef struct SwsPlane
> +{
> +int available_lines;
> +int sliceY;
> +int sliceH;
> +uint8_t **line;
> +} SwsPlane;
> +
> +typedef struct SwsSlice
> +{
> +int width;
> +int h_chr_sub_sample;
> +int v_chr_sub_sample;
> +int is_ring;
> +int should_free_lines;
> +enum AVPixelFormat fmt;
> +SwsPlane plane[MAX_SLICE_PLANES];
> +} SwsSlice;
> +
> +typedef struct SwsFilterDescriptor
> +{
> +SwsSlice * src;
> +SwsSlice * dst;
> +
> +int alpha;
> +void * instance;
> +
> + int (*process)(SwsContext*, struct SwsFilterDescriptor*, int, int);
^^^
missing indentifier names, "int" alone says nothing about what they
represent
> +} SwsFilterDescriptor;
> +
> +typedef struct ConvertInstance
> +{
> +uint32_t * pal;
> +} ConvertInstance;
the instance context is generally called a WhateverContext
in FFmpeg, using the same naming style might reduce confusion
that is ConvertContext though "Convert" is maybe too generic,
if you have an idea for a more specific term then Convert then
please use that instead otherwise the name isnt important ATM
> +
> +typedef struct ScaleInstance
> +{
> +uint16_t * filter;
> +int * filter_pos;
> +int filter_size;
> +int xInc;
> +} ScaleInstance;
all the structs need documentation describing what they represent
also "Scale" too is a little generic unless its intended to be
used for (nearly) every scaling case
> +
> +int ff_init_slice_from_src(SwsSlice * s, uint8_t *src[4], int stride[4], int
> srcW, int lumY, int lumH, int chrY, int chrH);
> +int ff_init_slice_from_lp(SwsSlice *s, uint8_t ***linesPool, int dstW, int
> lumY, int lumH, int chrY, int chrH);
> +int ff_init_filters(SwsContext *c);
> +int ff_free_filters(SwsContext *c);
> +int ff_rotate_slice(SwsSlice *s, int lum, int chr);
similar also all the functions need documentation
(something basic like 2-3 lines describing what they do is fine)
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] apng: Fix decoding images with the PREVIOUS dispose op
---
libavcodec/pngdec.c | 47 +++
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 60c4975..eae778b 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -643,6 +643,11 @@ static int decode_idat_chunk(AVCodecContext *avctx,
PNGDecContext *s,
if ((ret = ff_thread_get_buffer(avctx, &s->picture,
AV_GET_BUFFER_FLAG_REF)) < 0)
return ret;
+if (avctx->codec_id == AV_CODEC_ID_APNG && s->last_dispose_op !=
APNG_DISPOSE_OP_PREVIOUS) {
+ff_thread_release_buffer(avctx, &s->previous_picture);
+if ((ret = ff_thread_get_buffer(avctx, &s->previous_picture,
AV_GET_BUFFER_FLAG_REF)) < 0)
+return ret;
+}
ff_thread_finish_setup(avctx);
p->pict_type= AV_PICTURE_TYPE_I;
@@ -917,20 +922,20 @@ static int handle_p_frame_apng(AVCodecContext *avctx,
PNGDecContext *s,
return AVERROR_PATCHWELCOME;
}
-// Copy the previous frame to the buffer
-ff_thread_await_progress(&s->last_picture, INT_MAX, 0);
-memcpy(buffer, s->last_picture.f->data[0], s->image_linesize * s->height);
-
// Do the disposal operation specified by the last frame on the frame
-if (s->last_dispose_op == APNG_DISPOSE_OP_BACKGROUND) {
-for (y = s->last_y_offset; y < s->last_y_offset + s->last_h; ++y)
-memset(buffer + s->image_linesize * y + s->bpp * s->last_x_offset,
0, s->bpp * s->last_w);
-} else if (s->last_dispose_op == APNG_DISPOSE_OP_PREVIOUS) {
+if (s->last_dispose_op != APNG_DISPOSE_OP_PREVIOUS) {
+ff_thread_await_progress(&s->last_picture, INT_MAX, 0);
+memcpy(buffer, s->last_picture.f->data[0], s->image_linesize *
s->height);
+
+if (s->last_dispose_op == APNG_DISPOSE_OP_BACKGROUND)
+for (y = s->last_y_offset; y < s->last_y_offset + s->last_h; ++y)
+memset(buffer + s->image_linesize * y + s->bpp *
s->last_x_offset, 0, s->bpp * s->last_w);
+
+memcpy(s->previous_picture.f->data[0], buffer, s->image_linesize *
s->height);
+ff_thread_report_progress(&s->previous_picture, INT_MAX, 0);
+} else {
ff_thread_await_progress(&s->previous_picture, INT_MAX, 0);
-for (y = s->last_y_offset; y < s->last_y_offset + s->last_h; ++y) {
-size_t row_start = s->image_linesize * y + s->bpp *
s->last_x_offset;
-memcpy(buffer + row_start, s->previous_picture.f->data[0] +
row_start, s->bpp * s->last_w);
-}
+memcpy(buffer, s->previous_picture.f->data[0], s->image_linesize *
s->height);
}
// Perform blending
@@ -1206,13 +1211,9 @@ static int decode_frame_apng(AVCodecContext *avctx,
PNGDecContext *const s = avctx->priv_data;
int ret;
AVFrame *p;
-ThreadFrame tmp;
-ff_thread_release_buffer(avctx, &s->previous_picture);
-tmp = s->previous_picture;
-s->previous_picture = s->last_picture;
-s->last_picture = s->picture;
-s->picture = tmp;
+ff_thread_release_buffer(avctx, &s->last_picture);
+FFSWAP(ThreadFrame, s->picture, s->last_picture);
p = s->picture.f;
if (!(s->state & PNG_IHDR)) {
@@ -1291,8 +1292,14 @@ static int update_thread_context(AVCodecContext *dst,
const AVCodecContext *src)
pdst->state |= psrc->state & (PNG_IHDR | PNG_PLTE);
ff_thread_release_buffer(dst, &pdst->last_picture);
-if (psrc->last_picture.f->data[0])
-return ff_thread_ref_frame(&pdst->last_picture,
&psrc->last_picture);
+if (psrc->last_picture.f->data[0] &&
+(ret = ff_thread_ref_frame(&pdst->last_picture,
&psrc->last_picture)) < 0)
+return ret;
+
+ff_thread_release_buffer(dst, &pdst->previous_picture);
+if (psrc->previous_picture.f->data[0] &&
+(ret = ff_thread_ref_frame(&pdst->previous_picture,
&psrc->previous_picture)) < 0)
+return ret;
}
return 0;
--
2.4.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] apng: Fix typos in decoder causing incorrect results
Signed-off-by: Donny Yang
---
libavcodec/pngdec.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index eae778b..7a5c464 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -856,13 +856,13 @@ static int decode_fctl_chunk(AVCodecContext *avctx,
PNGDecContext *s,
cur_w > s->width - x_offset|| cur_h > s->height - y_offset)
return AVERROR_INVALIDDATA;
-if (sequence_number == 0 && s->dispose_op == APNG_DISPOSE_OP_PREVIOUS) {
+if (sequence_number == 0 && dispose_op == APNG_DISPOSE_OP_PREVIOUS) {
// No previous frame to revert to for the first frame
// Spec says to just treat it as a APNG_DISPOSE_OP_BACKGROUND
-s->dispose_op = APNG_DISPOSE_OP_BACKGROUND;
+dispose_op = APNG_DISPOSE_OP_BACKGROUND;
}
-if (s->dispose_op == APNG_BLEND_OP_OVER && !s->has_trns && (
+if (blend_op == APNG_BLEND_OP_OVER && !s->has_trns && (
avctx->pix_fmt == AV_PIX_FMT_RGB24 ||
avctx->pix_fmt == AV_PIX_FMT_RGB48BE ||
avctx->pix_fmt == AV_PIX_FMT_PAL8 ||
@@ -870,8 +870,8 @@ static int decode_fctl_chunk(AVCodecContext *avctx,
PNGDecContext *s,
avctx->pix_fmt == AV_PIX_FMT_GRAY16BE ||
avctx->pix_fmt == AV_PIX_FMT_MONOBLACK
)) {
-// APNG_DISPOSE_OP_OVER is the same as APNG_DISPOSE_OP_SOURCE when
there is no alpha channel
-s->dispose_op = APNG_BLEND_OP_SOURCE;
+// APNG_BLEND_OP_OVER is the same as APNG_BLEND_OP_SOURCE when there
is no alpha channel
+blend_op = APNG_BLEND_OP_SOURCE;
}
s->cur_w = cur_w;
--
2.4.6
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
