Re: [FFmpeg-devel] GSoC 2016 own ideas

[Matt Oliver]

On 19 February 2016 at 09:20, Gerion Entrup 
wrote:

> On Donnerstag, 18. Februar 2016 21:02:09 CET wm4 wrote:
> > On Thu, 18 Feb 2016 20:41:29 +0100
> >
> > Gerion Entrup  wrote:
> > > On Donnerstag, 18. Februar 2016 20:10:47 CET wm4 wrote:
> > > > On Thu, 18 Feb 2016 18:27:45 +0100
> > > >
> > > > Gerion Entrup  wrote:
> > > > > Good day,
> > > > >
> > > > > I'm a master student and long term FFmpeg-user. I want to
> participate
> > > > > in
> > >
> > > the GSoC 2016 for FFmpeg. The reason, I write this, is that I want to
> > > suggest some own ideas. It could be, that some of the mentioned things
> > > are wrong (because FFmpeg could do this already or it it much more
> > > difficult than I think). Please correct me if so.
> > >
> > > > > I'm excited to hear, what do you think about this ideas, if you
> think,
> > >
> > > they are suitable for GSoC and if you maybe are willing to mentor some
> of
> > > this.
> > >
> > > > > 1. *disc support
> > > > >
> > > > > What current FFmpeg could do:
> > > > > - Bluray support through protocol support with prefix "bluray:" and
> > >
> > > libbluray. The implemention is some kind of limited. There is missing
> > > chapter support. The "main movie" selection is simply the longest one.
> > > Menus are not supported. Afaik no metadata are transfered.
> > >
> > > > > - CD support through libavdevice and libcdio. Last time I tried
> it, it
> > >
> > > only works under some strange circumstances (I have to set the
> parameter
> > > "-ss 0"). I don't know if it is fixed right now. It recognizes a CD as
> > > one track with multiple chapters. Afaik CD-Text is not supported.
> > >
> > > > > - No DVD support at all. I saw, that Stefano ones write a patch [1]
> > >
> > > (protocol and libdvdnav based), which seems to work in principal, but
> was
> > > probably not ready to merge.
> > >
> > > > > Goal:
> > > > > - Implement an uniform solution for *disc support, that also
> support
> > >
> > > metadata.
> > >
> > > > > - Maybe (?): Add some kind of Menu Support, FFmpeg is not made for
> > > > > this
> > >
> > > atm, I think. Not sure how difficult it is.
> > >
> > > > > - Maybe (?): Try to change something on libdvdnav/libdvdread to
> make
> > > > > it
> > >
> > > more consistent (to libbluray ?). Similar idea from Flameeyes [2].
> > >
> > > > Hm, I'm not sure if that's even possible in a reasonable way. Full
> > > > DVD/Bluray support requires menus, which are hard to get right, and
> > > > which would require non-trivial interactions between applications and
> > > > libavformat.
> > > >
> > > > Improving support for merely transcoding a DVD to a file might be not
> > > > so hard and potentially a good idea, though.
> > > >
> > > > > Qualification task:
> > > > > - Maybe (?): Add chapter support for the current Bluray
> implementation
> > >
> > > (get the chapters out of libbluray is fairly simple, I'm not sure how
> > > difficult it is to get them into the stream).
> > >
> > > > This sounds like a hard design issue: currently bluray is implemented
> > > > as avio protocol, which can not pass things like chapters to the
> higher
> > > > level (demuxer). This would require coming up with a mechanism for
> > > > transferring this metadata, which sounds hard. Just reading the
> bluray
> > > > chapters should indeed be simple.
> > >
> > > Just reading the chapters and print them is too simple to be a
> > > qualification task.
> >
>

I to would be interested in better cd/bluray support as well as additional
dvd support. The big projects using ffmpeg already have their own
implementation but some of these are better than others and each can have
their own issues. So having a centralized implementation could be useful
(especially for new projects).
Interestingly cdio is currently part of avdevice while bluray is part of
avformat, perhaps moving bluray to be a device could alleviate some of the
issues around it being a protocol.

You will probably get a different answer from each developer, but my advice
> is very much that I would like it if ffplay used libavdevice and if
> libavdevice was powerful enough for that.
>

Having ffplay use avdevice in my mind would be an ideal solution. This way
it minimizes having separate code doing similar things.


> > In my personal opinion, audio/video output in libavdevice is an
> > abomination. It tries to force a muxer API to be used as API for
> > audio/video output, which is ridiculous and obviously has a bunch of
> > disadvantages. A real approach would realize such things as a separate
> > library with a proper API.

There is already SDL(1) output in libavdevice.
>
> But libavdevice is just bad libavformat ripof API wise.
> There is no libavdevice API. And it is shame.
>
> I had idea to improve it but seems nobody likes such idea.

I would be interested in such an idea as I think this would potentially
make avdevice much more usable. It would also provide a possible solution
to the above issues as well. An improved avdevice api would allow 

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mov: do not leak memory on ffio_read_size failure

[Michael Niedermayer]

On Sat, Feb 20, 2016 at 02:11:50AM +0100, Marton Balint wrote:
> Signed-off-by: Marton Balint 
> ---
>  libavformat/mov.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

LGTM

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Retire unused FATE IDs

[Michael Niedermayer]

On Fri, Feb 19, 2016 at 11:55:11PM -0300, James Almer wrote:
> On 2/19/2016 11:47 PM, Michael Niedermayer wrote:
> > On Fri, Feb 19, 2016 at 06:17:37PM -0800, Timothy Gu wrote:
> >> Hi all,
> >>
> >> For better security for the FATE server, I have just disabled the SSH keys
> >> corresponding to the following owners:
> >>
> >> - ab (only slot is "ab_haiku_fate;" has not been active for 9 months)
> >> - amalia (only slot is "x86_64-Fedora_20-gcc-4.8.3" with one run; has not 
> >> been
> >>   active for more than 1 year)
> >> - anshul (only slot is "x86-openSuse-gcc-4.7-dakudaddy" with one run; has 
> >> not
> >>   been active for more than two years)
> >> - dravorek (only slot is "x86-Win10-msvc-19.00.22609" with six runs; has 
> >> not
> >>   been active for 11 months)
> >> - fate1 (no current FATE stations)
> > 

> >> - fate10407 (no current FATE stations)
> > 
> > i think this is the fate server itself
> 
> That's a good enough reason to avoid taking action without checking/asking
> other FATE admins first next time...

i suspect disabling it does no harm, it was possibly used for some
fate client running on the server very long ago

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Retire unused FATE IDs

[James Almer]

On 2/19/2016 11:47 PM, Michael Niedermayer wrote:
> On Fri, Feb 19, 2016 at 06:17:37PM -0800, Timothy Gu wrote:
>> Hi all,
>>
>> For better security for the FATE server, I have just disabled the SSH keys
>> corresponding to the following owners:
>>
>> - ab (only slot is "ab_haiku_fate;" has not been active for 9 months)
>> - amalia (only slot is "x86_64-Fedora_20-gcc-4.8.3" with one run; has not 
>> been
>>   active for more than 1 year)
>> - anshul (only slot is "x86-openSuse-gcc-4.7-dakudaddy" with one run; has not
>>   been active for more than two years)
>> - dravorek (only slot is "x86-Win10-msvc-19.00.22609" with six runs; has not
>>   been active for 11 months)
>> - fate1 (no current FATE stations)
> 
>> - fate10407 (no current FATE stations)
> 
> i think this is the fate server itself

That's a good enough reason to avoid taking action without checking/asking
other FATE admins first next time...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Retire unused FATE IDs

[Michael Niedermayer]

On Fri, Feb 19, 2016 at 06:17:37PM -0800, Timothy Gu wrote:
> Hi all,
> 
> For better security for the FATE server, I have just disabled the SSH keys
> corresponding to the following owners:
> 
> - ab (only slot is "ab_haiku_fate;" has not been active for 9 months)
> - amalia (only slot is "x86_64-Fedora_20-gcc-4.8.3" with one run; has not been
>   active for more than 1 year)
> - anshul (only slot is "x86-openSuse-gcc-4.7-dakudaddy" with one run; has not
>   been active for more than two years)
> - dravorek (only slot is "x86-Win10-msvc-19.00.22609" with six runs; has not
>   been active for 11 months)
> - fate1 (no current FATE stations)

> - fate10407 (no current FATE stations)

i think this is the fate server itself


> - graham (no current FATE stations)
> - nbabic (seems to be superseded by "nedeljko2;" only slot is
>   "mips_linux_gcc_1_7_1;" has not been active for more than 1.5 years)
> - reimar (no current FATE stations)
> - wolfgang_lietz (only slot is "WL_dolinux" with three runs; has not been
>   active for 5 months)
> 
> If you are the owner of one of the aforementioned FATE stations/slots and wish
> your reporting access to FATE be restored, please contact me or
> fate-ad...@ffmpeg.org.

it could be a good idea to email all the owners of the affected
accounts, if someone knows email addresses


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/4] lavf/riffenc: Write space for palette

[Michael Niedermayer]

On Sat, Feb 20, 2016 at 12:02:15AM +0100, Mats Peterson wrote:
> 
> -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  riffenc.c |   23 +++
>  1 file changed, 19 insertions(+), 4 deletions(-)
> 63ec167e5794087397c65d3a5002e6bbd7a32caf  
> 0001-lavf-riffenc-Write-space-for-palette.patch
> From 41964552559234f19917a6ea40e71f0753a20ede Mon Sep 17 00:00:00 2001
> From: Mats Peterson 
> Date: Fri, 19 Feb 2016 23:55:25 +0100
> Subject: [PATCH v2 1/4] lavf/riffenc: Write space for palette
> 
> ---
>  libavformat/riffenc.c |   23 +++
>  1 file changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
> index ceb27f2..c7bad74 100644
> --- a/libavformat/riffenc.c
> +++ b/libavformat/riffenc.c
> @@ -210,6 +210,9 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext 
> *enc,
>!memcmp(enc->extradata + enc->extradata_size - 9, 
> "BottomUp", 9);
>  int extradata_size = enc->extradata_size - 9*keep_height;
>  
> +if (!enc->extradata_size && enc->bits_per_coded_sample >= 1 && 
> enc->bits_per_coded_sample <= 8)
> +extradata_size = 4 * (1 << enc->bits_per_coded_sample);

this should probably be limited to the CODEC_ID_RAWVIDEO case
and also to avi and not asf until it is implemented for asf too


> +
>  /* size */
>  avio_wl32(pb, 40 + (ignore_extradata ? 0 :extradata_size));
>  avio_wl32(pb, enc->width);
> @@ -228,10 +231,22 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext 
> *enc,
>  avio_wl32(pb, 0);
>  
>  if (!ignore_extradata) {
> -avio_write(pb, enc->extradata, extradata_size);
> -
> -if (!for_asf && extradata_size & 1)
> -avio_w8(pb, 0);
> +if (enc->extradata_size) {
> +avio_write(pb, enc->extradata, extradata_size);
> +if (!for_asf && extradata_size & 1)
> +avio_w8(pb, 0);
> +} else if (enc->bits_per_coded_sample >= 1 && 
> enc->bits_per_coded_sample <= 8) {
> +int i;

> +int64_t *pal_offset = (int64_t *)enc->priv_data;

the codec priv_data must not be accessed from a muxer, its private to
the codec


> +*pal_offset = avio_tell(pb);
> +for (i = 0; i < 1 << enc->bits_per_coded_sample; i++) {
> +/* Initialize 1 bpp palette to black & white */
> +if (!i && enc->bits_per_coded_sample == 1)
> +avio_wl32(pb, 0xff);
> +else
> +avio_wl32(pb, 0);
> +}
> +}
>  }
>  }


[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Retire unused FATE IDs

[Timothy Gu]

Hi all,

For better security for the FATE server, I have just disabled the SSH keys
corresponding to the following owners:

- ab (only slot is "ab_haiku_fate;" has not been active for 9 months)
- amalia (only slot is "x86_64-Fedora_20-gcc-4.8.3" with one run; has not been
  active for more than 1 year)
- anshul (only slot is "x86-openSuse-gcc-4.7-dakudaddy" with one run; has not
  been active for more than two years)
- dravorek (only slot is "x86-Win10-msvc-19.00.22609" with six runs; has not
  been active for 11 months)
- fate1 (no current FATE stations)
- fate10407 (no current FATE stations)
- graham (no current FATE stations)
- nbabic (seems to be superseded by "nedeljko2;" only slot is
  "mips_linux_gcc_1_7_1;" has not been active for more than 1.5 years)
- reimar (no current FATE stations)
- wolfgang_lietz (only slot is "WL_dolinux" with three runs; has not been
  active for 5 months)

If you are the owner of one of the aforementioned FATE stations/slots and wish
your reporting access to FATE be restored, please contact me or
fate-ad...@ffmpeg.org.

Thank you.

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/icodec: ico probe with unknown data

[Michael Niedermayer]

On Tue, Feb 16, 2016 at 01:42:50AM -0800, Mark Harris wrote:
> >> Header:  OK, 2 frames
> >> Frame 0: Unknown (offset points beyond end of probe buffer)
> >> Frame 1: Invalid
> >> Previously this example had a score of 25, even though the score would
> >> be 1 if the unknown frame was known to be valid or 0 if it was known
> >> to be invalid.  For this example the score is now 1.
> >
> > If the header is ok and the offset points beyond the end
> > of the probe buffer, the score was always 25 (before I
> > extended the check). Why should this be changed?
> > 25 is not very high after checking ~40 bit.
> 
> If you think that 25 is better when there is 1 unknown frame and 1
> invalid frame, I don't see an issue with that.  However in that case,
> when the unknown frame is known to be valid it should have a score
> that is at least the same value.  It doesn't make sense for the score
> with an unknown value to be higher than the highest score that could
> possibly be produced if the unknown value was known.
> 
> For this patch I just wanted to keep the behavior exactly the same in
> the common case where all of the data is in the buffer.
> 
> For the case of unknown data, the existing code can do strange things.
> For example if the probe buffer ends in the middle of a size or offset
> field then it can end up reading a partial value, which can cause it
> to check bytes at the wrong offset or produce false positives or false
> negatives.  There were also inconsistencies if there was a mixture of
> unknown and invalid data.  It seemed only logical that with unknown
> data the score should never be higher than what it would be if the
> data was known to be valid, and never be lower than what it would be
> if the data was known to be invalid.  So I preserved the existing
> behavior for the cases of known data, and adjusted the behavior for
> unknown data so that the scores would be within these constraints and
> so that there was no reliance on the zero padding.

patch applied

the hardcoded litteral offsets could be replaced by named constants
or comments be added

also the score should possibly be higher for truncated files,
it would be better if a decissive recognization could be done before
the whole file needs to be read

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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] avformat/icodec: Fix crash probing fuzzed file

[Michael Niedermayer]

On Mon, Feb 15, 2016 at 11:52:13PM -0800, Mark Harris wrote:
> Avoid invalid memory read/crash when frame offset >= 0xfff8.
> Base64-encoded example: AAABADAwMDAwMAAAMAAwMDAw/P///w==
> (The previous commit verifies that p->buf_size >= 22.)
> ---
>  libavformat/icodec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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] avformat/mov: merge mov_read_custom functions

[Marton Balint]

This also fixes reading gapless metadata when the entries do not start with the
mean atom. Such samples can be found here:
https://hydrogenaud.io/index.php/topic,93310.0.html

Signed-off-by: Marton Balint 
---
 libavformat/mov.c | 50 --
 1 file changed, 12 insertions(+), 38 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 1d0077e..7d9a3f3 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3172,10 +3172,10 @@ static int mov_read_keys(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 return 0;
 }
 
-static int mov_read_custom_2plus(MOVContext *c, AVIOContext *pb, int64_t size)
+static int mov_read_custom(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
-int64_t end = avio_tell(pb) + size;
-uint8_t *key = NULL, *val = NULL;
+int64_t end = avio_tell(pb) + atom.size;
+uint8_t *key = NULL, *val = NULL, *mean = NULL;
 int i;
 AVStream *st;
 MOVStreamContext *sc;
@@ -3185,7 +3185,7 @@ static int mov_read_custom_2plus(MOVContext *c, 
AVIOContext *pb, int64_t size)
 st = c->fc->streams[c->fc->nb_streams-1];
 sc = st->priv_data;
 
-for (i = 0; i < 2; i++) {
+for (i = 0; i < 3; i++) {
 uint8_t **p;
 uint32_t len, tag;
 int ret;
@@ -3201,7 +3201,9 @@ static int mov_read_custom_2plus(MOVContext *c, 
AVIOContext *pb, int64_t size)
 break;
 len -= 12;
 
-if (tag == MKTAG('n', 'a', 'm', 'e'))
+if (tag == MKTAG('m', 'e', 'a', 'n'))
+p = &mean;
+else if (tag == MKTAG('n', 'a', 'm', 'e'))
 p = &key;
 else if (tag == MKTAG('d', 'a', 't', 'a') && len > 4) {
 avio_skip(pb, 4);
@@ -3221,7 +3223,7 @@ static int mov_read_custom_2plus(MOVContext *c, 
AVIOContext *pb, int64_t size)
 (*p)[len] = 0;
 }
 
-if (key && val) {
+if (mean && key && val) {
 if (strcmp(key, "iTunSMPB") == 0) {
 int priming, remainder, samples;
 if(sscanf(val, "%*X %X %X %X", &priming, &remainder, &samples) == 
3){
@@ -3234,43 +3236,15 @@ static int mov_read_custom_2plus(MOVContext *c, 
AVIOContext *pb, int64_t size)
 AV_DICT_DONT_STRDUP_KEY | AV_DICT_DONT_STRDUP_VAL);
 key = val = NULL;
 }
+} else {
+av_log(c->fc, AV_LOG_VERBOSE,
+   "Unhandled or malformed custom metadata of size %"PRId64"\n", 
atom.size);
 }
 
 avio_seek(pb, end, SEEK_SET);
 av_freep(&key);
 av_freep(&val);
-return 0;
-}
-
-static int mov_read_custom(MOVContext *c, AVIOContext *pb, MOVAtom atom)
-{
-int64_t end = avio_tell(pb) + atom.size;
-uint32_t tag, len;
-
-if (atom.size < 8)
-goto fail;
-
-len = avio_rb32(pb);
-tag = avio_rl32(pb);
-
-if (len > atom.size)
-goto fail;
-
-if (tag == MKTAG('m', 'e', 'a', 'n') && len > 12) {
-uint8_t domain[128];
-int domain_len;
-
-avio_skip(pb, 4); // flags
-len -= 12;
-
-domain_len = avio_get_str(pb, len, domain, sizeof(domain));
-avio_skip(pb, len - domain_len);
-return mov_read_custom_2plus(c, pb, end - avio_tell(pb));
-}
-
-fail:
-av_log(c->fc, AV_LOG_VERBOSE,
-   "Unhandled or malformed custom metadata of size %"PRId64"\n", 
atom.size);
+av_freep(&mean);
 return 0;
 }
 
-- 
2.6.2

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

[FFmpeg-devel] [PATCH 2/2] avformat/mov: do not leak memory on ffio_read_size failure

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavformat/mov.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7d9a3f3..4150987 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3177,6 +3177,7 @@ static int mov_read_custom(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 int64_t end = avio_tell(pb) + atom.size;
 uint8_t *key = NULL, *val = NULL, *mean = NULL;
 int i;
+int ret = 0;
 AVStream *st;
 MOVStreamContext *sc;
 
@@ -3188,7 +3189,6 @@ static int mov_read_custom(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 for (i = 0; i < 3; i++) {
 uint8_t **p;
 uint32_t len, tag;
-int ret;
 
 if (end - avio_tell(pb) <= 12)
 break;
@@ -3218,7 +3218,7 @@ static int mov_read_custom(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 ret = ffio_read_size(pb, *p, len);
 if (ret < 0) {
 av_freep(p);
-return ret;
+break;
 }
 (*p)[len] = 0;
 }
@@ -3245,7 +3245,7 @@ static int mov_read_custom(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 av_freep(&key);
 av_freep(&val);
 av_freep(&mean);
-return 0;
+return ret;
 }
 
 static int mov_read_meta(MOVContext *c, AVIOContext *pb, MOVAtom atom)
-- 
2.6.2

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

Re: [FFmpeg-devel] [PATCH] vp9: add superframe merging bitstream filter.

[Michael Niedermayer]

On Fri, Feb 19, 2016 at 04:28:44PM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, Feb 19, 2016 at 3:48 PM, Michael Niedermayer  > wrote:
> 
> > On Fri, Feb 19, 2016 at 02:43:48PM -0500, Ronald S. Bultje wrote:
> > > Fixes ticket 4313.
> > > ---
> > >  ffmpeg.c|   3 +
> > >  libavcodec/Makefile |   1 +
> > >  libavcodec/allcodecs.c  |   1 +
> > >  libavcodec/vp9_superframe_bsf.c | 189
> > 
> > >  libavformat/ivfenc.c|  13 +++
> > >  libavformat/matroskaenc.c   |   5 +-
> > >  libavformat/mux.c   |  24 ++---
> > >  libavformat/utils.c |   5 ++
> > >  8 files changed, 229 insertions(+), 12 deletions(-)
> > >  create mode 100644 libavcodec/vp9_superframe_bsf.c
> >
> > breaks fate
> >
> > acodec-flac-exact-rice
> > TESTacodec-g723_1
> > TESTacodec-ra144
> > --- ./tests/ref/acodec/flac 2016-02-17 05:18:12.137817721 +0100
> > +++ tests/data/fate/acodec-flac 2016-02-19 21:47:18.898708417 +0100
> > @@ -1,4 +1,4 @@
> > -151eef9097f944726968bec48649f00a *tests/data/fate/acodec-flac.flac
> > +451ae98137ad04bf6c16c9fc6a862012 *tests/data/fate/acodec-flac.flac
> >  361582 tests/data/fate/acodec-flac.flac
> >  95e54b261530a1bcf6de6fe3b21dc5f6 *tests/data/fate/acodec-flac.out.wav
> >  stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:  1058400/  1058400
> > Test acodec-flac failed. Look at tests/data/fate/acodec-flac.err for
> > details.
> > make: *** [fate-acodec-flac] Error 1
> > make: *** Waiting for unfinished jobs
> > --- ./tests/ref/acodec/flac-exact-rice  2016-02-19 02:07:54.745217610 +0100
> > +++ tests/data/fate/acodec-flac-exact-rice  2016-02-19
> > 21:47:18.934708417 +0100
> > @@ -1,4 +1,4 @@
> > -aab144de213ae684ca008a3e0afe5e28
> > *tests/data/fate/acodec-flac-exact-rice.flac
> > +14f0ff901a80f1c27989187f981277f4
> > *tests/data/fate/acodec-flac-exact-rice.flac
> >  360454 tests/data/fate/acodec-flac-exact-rice.flac
> >  95e54b261530a1bcf6de6fe3b21dc5f6
> > *tests/data/fate/acodec-flac-exact-rice.out.wav
> >  stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:  1058400/  1058400
> 
> 
> Hm, OK, so flac abuses empty packets for extradata updates in raw flac as
> container. So I guess I need some novel way to signal "skip this packet" in
> bsfs. Any suggestions? I can come up with something else that's random and
> probably slightly hackish but if you have nicer ideas I can work towards
> that also.

Using the return code could work

checking size and side_data to be 0 could still skip packets which
arent intended to be skiped, this may or may not be a problem in
practice, it fixes the flac issue though

using AVPacket.flags should work but its not directly accessible
from the filter itself without some extension/changes

other hacks like data==NULL && return indicating realllocation
...
could be tried too 


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 4/4] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

[Mats Peterson]

Your favourite, Michael. I think the time might be ripe for this one 
now. There is still QuickTime left to fix, but that's another story...


--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From c2a8f5bcfbec4d6f2248cc324dee08732b28f341 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 19 Feb 2016 23:58:04 +0100
Subject: [PATCH v2 4/4] lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette

---
 libavcodec/rawdec.c |   19 ---
 1 file changed, 19 deletions(-)

diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 3a2fac3..eb9fe48 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -128,10 +128,6 @@ static av_cold int raw_init_decoder(AVCodecContext *avctx)
 avctx->pix_fmt   == AV_PIX_FMT_YUYV422)
 context->is_yuv2 = 1;
 
-/* Temporary solution until PAL8 is implemented in nut */
-if (context->is_pal8 && avctx->bits_per_coded_sample == 1)
-avctx->pix_fmt = AV_PIX_FMT_NONE;
-
 return 0;
 }
 
@@ -206,21 +202,6 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 return AVERROR_INVALIDDATA;
 }
 
-/* Temporary solution until PAL8 is implemented in nut */
-if (avctx->pix_fmt == AV_PIX_FMT_NONE &&
-avctx->bits_per_coded_sample == 1 &&
-avctx->frame_number == 0 &&
-context->palette &&
-AV_RB64(context->palette->data) == 0x
-) {
-const uint8_t *pal = av_packet_get_side_data(avpkt, AV_PKT_DATA_PALETTE, NULL);
-if (!pal) {
-avctx->pix_fmt = AV_PIX_FMT_MONOWHITE;
-context->is_pal8 = 0;
-context->is_mono = 1;
-} else
-avctx->pix_fmt = AV_PIX_FMT_PAL8;
-}
 desc = av_pix_fmt_desc_get(avctx->pix_fmt);
 
 if ((avctx->bits_per_coded_sample == 8 || avctx->bits_per_coded_sample == 4
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH v2 3/4] tests/ref/vsynth: Update 1 bpp files for pal8

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 9448c215acf99f2f304bcaf2afe21bfd950caa6b Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 19 Feb 2016 23:57:16 +0100
Subject: [PATCH v2 3/4] tests/ref/vsynth: Update 1 bpp files for pal8

---
 tests/ref/vsynth/vsynth1-bpp1 |8 
 tests/ref/vsynth/vsynth2-bpp1 |8 
 tests/ref/vsynth/vsynth3-bpp1 |8 
 tests/ref/vsynth/vsynth_lena-bpp1 |8 
 4 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/tests/ref/vsynth/vsynth1-bpp1 b/tests/ref/vsynth/vsynth1-bpp1
index 0bd1a77..92d5987 100644
--- a/tests/ref/vsynth/vsynth1-bpp1
+++ b/tests/ref/vsynth/vsynth1-bpp1
@@ -1,4 +1,4 @@
-611de0803ff6bd0ef385dde59964a105 *tests/data/fate/vsynth1-bpp1.avi
-640452 tests/data/fate/vsynth1-bpp1.avi
-576b690e8a8921c54d777463b63a8307 *tests/data/fate/vsynth1-bpp1.out.rawvideo
-stddev:   97.41 PSNR:  8.36 MAXDIFF:  238 bytes:  7603200/  7603200
+0fcba876d3e499c0bebf7bb32a7f83f2 *tests/data/fate/vsynth1-bpp1.avi
+640460 tests/data/fate/vsynth1-bpp1.avi
+cd1e1448d9895561347ceb66d0add34d *tests/data/fate/vsynth1-bpp1.out.rawvideo
+stddev:   84.48 PSNR:  9.60 MAXDIFF:  218 bytes:  7603200/  7603200
diff --git a/tests/ref/vsynth/vsynth2-bpp1 b/tests/ref/vsynth/vsynth2-bpp1
index d283d6c..2a2a63e 100644
--- a/tests/ref/vsynth/vsynth2-bpp1
+++ b/tests/ref/vsynth/vsynth2-bpp1
@@ -1,4 +1,4 @@
-b51ad49892eb8f8912c5a983718a17bb *tests/data/fate/vsynth2-bpp1.avi
-640452 tests/data/fate/vsynth2-bpp1.avi
-338fb9039a4564e471bf8179f0c48a95 *tests/data/fate/vsynth2-bpp1.out.rawvideo
-stddev:   80.40 PSNR: 10.02 MAXDIFF:  238 bytes:  7603200/  7603200
+af7eae5293b820493d1f4e6d258d8da0 *tests/data/fate/vsynth2-bpp1.avi
+640460 tests/data/fate/vsynth2-bpp1.avi
+f0dfc0e87e5d96bce29a5944b1bd7471 *tests/data/fate/vsynth2-bpp1.out.rawvideo
+stddev:   68.98 PSNR: 11.36 MAXDIFF:  218 bytes:  7603200/  7603200
diff --git a/tests/ref/vsynth/vsynth3-bpp1 b/tests/ref/vsynth/vsynth3-bpp1
index 39f27f3..b3b757c 100644
--- a/tests/ref/vsynth/vsynth3-bpp1
+++ b/tests/ref/vsynth/vsynth3-bpp1
@@ -1,4 +1,4 @@
-d5689d1f5c2d4c28a345d5964a6161a8 *tests/data/fate/vsynth3-bpp1.avi
-20452 tests/data/fate/vsynth3-bpp1.avi
-0b1ea21b69d384564dd3a978065443b2 *tests/data/fate/vsynth3-bpp1.out.rawvideo
-stddev:   97.64 PSNR:  8.34 MAXDIFF:  248 bytes:86700/86700
+01b0fbf35305b50b1c148c0a23f2cff4 *tests/data/fate/vsynth3-bpp1.avi
+20460 tests/data/fate/vsynth3-bpp1.avi
+52ae74ef7910e5b603c12288d425b9ae *tests/data/fate/vsynth3-bpp1.out.rawvideo
+stddev:   84.76 PSNR:  9.57 MAXDIFF:  232 bytes:86700/86700
diff --git a/tests/ref/vsynth/vsynth_lena-bpp1 b/tests/ref/vsynth/vsynth_lena-bpp1
index 63ab9e1..57219cc 100644
--- a/tests/ref/vsynth/vsynth_lena-bpp1
+++ b/tests/ref/vsynth/vsynth_lena-bpp1
@@ -1,4 +1,4 @@
-2859022fac452b59e49a1189c4fbb3ec *tests/data/fate/vsynth_lena-bpp1.avi
-640452 tests/data/fate/vsynth_lena-bpp1.avi
-3be3497f8ca548c9196dcecc5bc7cb2b *tests/data/fate/vsynth_lena-bpp1.out.rawvideo
-stddev:   96.52 PSNR:  8.44 MAXDIFF:  231 bytes:  7603200/  7603200
+930d019cbf8e06c67bdec58a3639c045 *tests/data/fate/vsynth_lena-bpp1.avi
+640460 tests/data/fate/vsynth_lena-bpp1.avi
+6183ba861d4e48d4aaefc514fde270e5 *tests/data/fate/vsynth_lena-bpp1.out.rawvideo
+stddev:   83.28 PSNR:  9.72 MAXDIFF:  215 bytes:  7603200/  7603200
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH v2 2/4] lavf/avienc: Write palette after BITMAPINFOHEADER in strf chunk

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From ace9b5d852e1da540927498989220c7b1e9e1c2b Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 19 Feb 2016 23:56:11 +0100
Subject: [PATCH v2 2/4] lavf/avienc: Write palette after BITMAPINFOHEADER in strf chunk

---
 libavformat/avienc.c |   28 
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 4e7bca4..13a74e8 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -73,6 +73,7 @@ typedef struct AVIStream {
 int entry;
 int max_size;
 int sample_requested;
+int hdr_pal_done;
 
 int64_t last_dts;
 
@@ -359,6 +360,12 @@ static int avi_write_header(AVFormatContext *s)
 && enc->pix_fmt == AV_PIX_FMT_RGB555LE
 && enc->bits_per_coded_sample == 15)
 enc->bits_per_coded_sample = 16;
+/* Use private data for palette offset */
+if (enc->bits_per_coded_sample >= 1 && enc->bits_per_coded_sample <= 8) {
+enc->priv_data = av_malloc(sizeof(int64_t));
+if (!enc->priv_data)
+return AVERROR(ENOMEM);
+}
 ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0);
 pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi,
   enc->bits_per_coded_sample);
@@ -652,6 +659,7 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 int size   = pkt->size;
 AVIOContext *pb = s->pb;
 AVCodecContext *enc = s->streams[stream_index]->codec;
+AVIStream *avist= s->streams[stream_index]->priv_data;
 int ret;
 
 if (enc->codec_id == AV_CODEC_ID_H264 && enc->codec_tag == MKTAG('H','2','6','4') && pkt->size) {
@@ -673,15 +681,27 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 if (ret) {
 if (ret == CONTAINS_PAL) {
 int pc_tag, i;
+int pal_size = 1 << enc->bits_per_coded_sample;
+if (!avist->hdr_pal_done) {
+int64_t cur_offset = avio_tell(pb);
+int64_t *pal_offset = (int64_t *)enc->priv_data;
+avio_seek(pb, *pal_offset, SEEK_SET);
+for (i = 0; i < pal_size; i++) {
+uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+avio_wl32(pb, v & 0xff);
+}
+avio_seek(pb, cur_offset, SEEK_SET);
+av_free(enc->priv_data);
+avist->hdr_pal_done++;
+}
 avi_stream2fourcc(tag, stream_index, enc->codec_type);
 tag[2] = 'p'; tag[3] = 'c';
-
 pc_tag = ff_start_tag(pb, tag);
 avio_w8(pb, 0);
-avio_w8(pb, 0);
+avio_w8(pb, pal_size);
 avio_wl16(pb, 0); // reserved
-for (i = 0; i<256; i++) {
-uint32_t v = AV_RL32(data + size - 1024 + 4*i);
+for (i = 0; i < pal_size; i++) {
+uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
 avio_wb32(pb, v<<8);
 }
 ff_end_tag(pb, pc_tag);
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH v2 1/4] lavf/riffenc: Write space for palette

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 41964552559234f19917a6ea40e71f0753a20ede Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 19 Feb 2016 23:55:25 +0100
Subject: [PATCH v2 1/4] lavf/riffenc: Write space for palette

---
 libavformat/riffenc.c |   23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index ceb27f2..c7bad74 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -210,6 +210,9 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
   !memcmp(enc->extradata + enc->extradata_size - 9, "BottomUp", 9);
 int extradata_size = enc->extradata_size - 9*keep_height;
 
+if (!enc->extradata_size && enc->bits_per_coded_sample >= 1 && enc->bits_per_coded_sample <= 8)
+extradata_size = 4 * (1 << enc->bits_per_coded_sample);
+
 /* size */
 avio_wl32(pb, 40 + (ignore_extradata ? 0 :extradata_size));
 avio_wl32(pb, enc->width);
@@ -228,10 +231,22 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
 avio_wl32(pb, 0);
 
 if (!ignore_extradata) {
-avio_write(pb, enc->extradata, extradata_size);
-
-if (!for_asf && extradata_size & 1)
-avio_w8(pb, 0);
+if (enc->extradata_size) {
+avio_write(pb, enc->extradata, extradata_size);
+if (!for_asf && extradata_size & 1)
+avio_w8(pb, 0);
+} else if (enc->bits_per_coded_sample >= 1 && enc->bits_per_coded_sample <= 8) {
+int i;
+int64_t *pal_offset = (int64_t *)enc->priv_data;
+*pal_offset = avio_tell(pb);
+for (i = 0; i < 1 << enc->bits_per_coded_sample; i++) {
+/* Initialize 1 bpp palette to black & white */
+if (!i && enc->bits_per_coded_sample == 1)
+avio_wl32(pb, 0xff);
+else
+avio_wl32(pb, 0);
+}
+}
 }
 }
 
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]lavc/libvpx: Fix high-bitrate colour spaces

[James Zern]

On Fri, Feb 19, 2016 at 12:17 PM, Carl Eugen Hoyos  wrote:
> Could you comment on ticket #3271 (is alpha possible in
> vp9?) and #4105?

I added some notes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FATE error on dnxhr-parse

[Mats Peterson]

On 02/19/2016 10:23 PM, James Almer wrote:

On 2/19/2016 6:09 PM, Mats Peterson wrote:

Just got this FATE error, Michael. Why? My changes can't possibly affect this 
part, can they?

--- ./tests/ref/fate/dnxhr-parse2016-02-19 17:36:39.051308004 +0100
+++ tests/data/fate/dnxhr-parse2016-02-19 22:03:11.715918354 +0100
@@ -0,0 +1,5 @@
+#tb 0: 1/25
+0,  0,  0,1, 16588800, 0x67ebfdb1
+0,  1,  1,1, 16588800, 0x7fa687e6
+0,  2,  2,1, 16588800, 0x4e13f5eb
+0,  3,  3,1, 16588800, 0x054a642d
Test dnxhr-parse failed. Look at tests/data/fate/dnxhr-parse.err for details.
make: *** [fate-dnxhr-parse] Error 1



Check with git that tests/ref/fate/dnxhr-parse is correct, because it would
seem that it's currently an empty file. It should contain what the test here
says it expected to find.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



It works now. Thanks.

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FATE error on dnxhr-parse

[Mats Peterson]

On 02/19/2016 11:14 PM, Mark Reid wrote:

On Feb 19, 2016 1:23 PM, "James Almer"  wrote:


On 2/19/2016 6:09 PM, Mats Peterson wrote:

Just got this FATE error, Michael. Why? My changes can't possibly

affect this part, can they?


--- ./tests/ref/fate/dnxhr-parse2016-02-19 17:36:39.051308004 +0100
+++ tests/data/fate/dnxhr-parse2016-02-19 22:03:11.715918354 +0100
@@ -0,0 +1,5 @@
+#tb 0: 1/25
+0,  0,  0,1, 16588800, 0x67ebfdb1
+0,  1,  1,1, 16588800, 0x7fa687e6
+0,  2,  2,1, 16588800, 0x4e13f5eb
+0,  3,  3,1, 16588800, 0x054a642d
Test dnxhr-parse failed. Look at tests/data/fate/dnxhr-parse.err for

details.

make: *** [fate-dnxhr-parse] Error 1





Did you run a make fate-rsync?
___



Yep, but it still failed at the first time. The second time it worked... 
thanks for the reply.


Mats

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: init input streams before opening encoders

[Marton Balint]

On Wed, 17 Feb 2016, Michael Niedermayer wrote:


On Wed, Feb 17, 2016 at 08:36:41PM +0100, Marton Balint wrote:

Codec options of streams detected during avformat_find_stream_info are not set
therefore without this patch we initialize the encoders with decoder info
based on decoders without options.

This cause problems for probed DVB teletext streams where
avctx->subtitle_header depend on the txt_format setting.

Signed-off-by: Marton Balint 
---
 ffmpeg.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)


i think this is ok but please wait for others to be able to
comment too



Got no further comments, so I applied this.

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

Re: [FFmpeg-devel] FATE error on dnxhr-parse

[Mark Reid]

On Feb 19, 2016 1:23 PM, "James Almer"  wrote:
>
> On 2/19/2016 6:09 PM, Mats Peterson wrote:
> > Just got this FATE error, Michael. Why? My changes can't possibly
affect this part, can they?
> >
> > --- ./tests/ref/fate/dnxhr-parse2016-02-19 17:36:39.051308004 +0100
> > +++ tests/data/fate/dnxhr-parse2016-02-19 22:03:11.715918354 +0100
> > @@ -0,0 +1,5 @@
> > +#tb 0: 1/25
> > +0,  0,  0,1, 16588800, 0x67ebfdb1
> > +0,  1,  1,1, 16588800, 0x7fa687e6
> > +0,  2,  2,1, 16588800, 0x4e13f5eb
> > +0,  3,  3,1, 16588800, 0x054a642d
> > Test dnxhr-parse failed. Look at tests/data/fate/dnxhr-parse.err for
details.
> > make: *** [fate-dnxhr-parse] Error 1
> >
>

Did you run a make fate-rsync?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCHv2 2/2] avcodec/libzvbi-teletextdec: use common functions for matching data_unit_id and data_identifier

[Marton Balint]

On Tue, 16 Feb 2016, Marton Balint wrote:


Signed-off-by: Marton Balint 
---
libavcodec/libzvbi-teletextdec.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)


Applied.

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

Re: [FFmpeg-devel] [PATCHv2 1/2] avformat/dvbtxt: add raw demuxer for dvb teletext probing

[Marton Balint]

On Tue, 16 Feb 2016, Marton Balint wrote:


Signed-off-by: Marton Balint 
---
libavcodec/dvbtxt.h  | 41 +++
libavformat/Makefile |  1 +
libavformat/allformats.c |  1 +
libavformat/dvbtxt.c | 50 
libavformat/utils.c  |  1 +
5 files changed, 94 insertions(+)
create mode 100644 libavcodec/dvbtxt.h
create mode 100644 libavformat/dvbtxt.c



Applied with version bump.

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

Re: [FFmpeg-devel] FFmpeg in Outreachy Round 12

[Marina Zhurakhinskaya]

- Original Message -
> From: "Michael Niedermayer" 
> To: "FFmpeg development discussions and patches" 
> Cc: "outreachy-admins" , o...@ffmpeg.org
> Sent: Wednesday, February 17, 2016 11:09:31 PM
> Subject: Re: [FFmpeg-devel] FFmpeg in Outreachy Round 12
> 
> On Tue, Feb 09, 2016 at 09:14:57PM -0500, Marina Zhurakhinskaya wrote:
> > Hi,
> > 
> > Glad FFmpeg will participate in this round! Thank you for making a decision
> > to allocate the funds for Outreachy!
> > 
> > We can credit all three of you as coordinators. Please be sure to
> > coordinate among yourselves on making decisions and/or having each one of
> > you empowered to make decisions.
> > 
> > What should the updated description be, given the project ideas you have
> > this round? Last year, it was "FFmpeg is the universal multimedia toolkit:
> > a complete, cross-platform solution to record, convert, filter and stream
> > audio and video. Available projects like FFv1 codecs frame support and
> > postprocessing optimization involve coding in C."
> 
> not sure anyone replied already but the postprocessing optimization should
> probably be removed.
> Its still available if someone really wants to work on it but its
> not so trivial, requiring good knowledge of x86 asm ...

Thanks! I added FFmpeg with the following description:

"FFmpeg is the universal multimedia toolkit: a complete, cross-platform 
solution to record, convert, filter and stream audio and video. Available 
projects like FFv1 codecs frame support, scaling improvement, and adding 
selftests involve coding in C. Another project involves creating a fuzzing 
testsuite and a web interface for it in Python or node.js."

Marina

> 
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> If you think the mosad wants you dead since a long time then you are either
> wrong or dead since a long time.
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vp9: add superframe merging bitstream filter.

[Ronald S. Bultje]

Hi,

On Fri, Feb 19, 2016 at 3:48 PM, Michael Niedermayer  wrote:

> On Fri, Feb 19, 2016 at 02:43:48PM -0500, Ronald S. Bultje wrote:
> > Fixes ticket 4313.
> > ---
> >  ffmpeg.c|   3 +
> >  libavcodec/Makefile |   1 +
> >  libavcodec/allcodecs.c  |   1 +
> >  libavcodec/vp9_superframe_bsf.c | 189
> 
> >  libavformat/ivfenc.c|  13 +++
> >  libavformat/matroskaenc.c   |   5 +-
> >  libavformat/mux.c   |  24 ++---
> >  libavformat/utils.c |   5 ++
> >  8 files changed, 229 insertions(+), 12 deletions(-)
> >  create mode 100644 libavcodec/vp9_superframe_bsf.c
>
> breaks fate
>
> acodec-flac-exact-rice
> TESTacodec-g723_1
> TESTacodec-ra144
> --- ./tests/ref/acodec/flac 2016-02-17 05:18:12.137817721 +0100
> +++ tests/data/fate/acodec-flac 2016-02-19 21:47:18.898708417 +0100
> @@ -1,4 +1,4 @@
> -151eef9097f944726968bec48649f00a *tests/data/fate/acodec-flac.flac
> +451ae98137ad04bf6c16c9fc6a862012 *tests/data/fate/acodec-flac.flac
>  361582 tests/data/fate/acodec-flac.flac
>  95e54b261530a1bcf6de6fe3b21dc5f6 *tests/data/fate/acodec-flac.out.wav
>  stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:  1058400/  1058400
> Test acodec-flac failed. Look at tests/data/fate/acodec-flac.err for
> details.
> make: *** [fate-acodec-flac] Error 1
> make: *** Waiting for unfinished jobs
> --- ./tests/ref/acodec/flac-exact-rice  2016-02-19 02:07:54.745217610 +0100
> +++ tests/data/fate/acodec-flac-exact-rice  2016-02-19
> 21:47:18.934708417 +0100
> @@ -1,4 +1,4 @@
> -aab144de213ae684ca008a3e0afe5e28
> *tests/data/fate/acodec-flac-exact-rice.flac
> +14f0ff901a80f1c27989187f981277f4
> *tests/data/fate/acodec-flac-exact-rice.flac
>  360454 tests/data/fate/acodec-flac-exact-rice.flac
>  95e54b261530a1bcf6de6fe3b21dc5f6
> *tests/data/fate/acodec-flac-exact-rice.out.wav
>  stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:  1058400/  1058400


Hm, OK, so flac abuses empty packets for extradata updates in raw flac as
container. So I guess I need some novel way to signal "skip this packet" in
bsfs. Any suggestions? I can come up with something else that's random and
probably slightly hackish but if you have nicer ideas I can work towards
that also.

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

Re: [FFmpeg-devel] FATE error on dnxhr-parse

[James Almer]

On 2/19/2016 6:09 PM, Mats Peterson wrote:
> Just got this FATE error, Michael. Why? My changes can't possibly affect this 
> part, can they?
> 
> --- ./tests/ref/fate/dnxhr-parse2016-02-19 17:36:39.051308004 +0100
> +++ tests/data/fate/dnxhr-parse2016-02-19 22:03:11.715918354 +0100
> @@ -0,0 +1,5 @@
> +#tb 0: 1/25
> +0,  0,  0,1, 16588800, 0x67ebfdb1
> +0,  1,  1,1, 16588800, 0x7fa687e6
> +0,  2,  2,1, 16588800, 0x4e13f5eb
> +0,  3,  3,1, 16588800, 0x054a642d
> Test dnxhr-parse failed. Look at tests/data/fate/dnxhr-parse.err for details.
> make: *** [fate-dnxhr-parse] Error 1
> 

Check with git that tests/ref/fate/dnxhr-parse is correct, because it would
seem that it's currently an empty file. It should contain what the test here
says it expected to find.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavf/avienc: Write palette after BITMAPINFOHEADER

[Mats Peterson]

On 02/19/2016 10:11 PM, Mats Peterson wrote:

On 02/19/2016 10:10 PM, Michael Niedermayer wrote:

On Fri, Feb 19, 2016 at 10:05:32PM +0100, Mats Peterson wrote:

On 02/19/2016 10:00 PM, Michael Niedermayer wrote:

-
  pc_tag = ff_start_tag(pb, tag);
  avio_w8(pb, 0);



  avio_w8(pb, 0);



  avio_wl16(pb, 0); // reserved
-for (i = 0; i<256; i++) {
+for (i = 0; i < pal_size; i++) {


this mismatches the stored size above


Mismatches what stored size?


the "avio_w8(pb, 0);" above



Right. I'll just set that one to 1 << bits_per_coded_sample then.
Funny that not even Media Player supports these palette change
chunks, by the way.


what does it do with files from other sources that contain such
chunks ?
maybe it supports them for only some vieo codecs but not rawvideo


I haven't the foggiest. Your assumption might be correct, though.

Mats


By the way, you were right regarding the RGB order. It's only in the 
palette after the BITMAPINFOHEADER in the strf chunk that the palette is 
in BGR (little endian) order. Sorry. I'll restore that.


Mats

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

Re: [FFmpeg-devel] [PATCH 2/3] lavf/avienc: Write palette after BITMAPINFOHEADER

[Mats Peterson]

On 02/19/2016 10:10 PM, Michael Niedermayer wrote:

On Fri, Feb 19, 2016 at 10:05:32PM +0100, Mats Peterson wrote:

On 02/19/2016 10:00 PM, Michael Niedermayer wrote:

-
  pc_tag = ff_start_tag(pb, tag);
  avio_w8(pb, 0);



  avio_w8(pb, 0);



  avio_wl16(pb, 0); // reserved
-for (i = 0; i<256; i++) {
+for (i = 0; i < pal_size; i++) {


this mismatches the stored size above


Mismatches what stored size?


the "avio_w8(pb, 0);" above



Right. I'll just set that one to 1 << bits_per_coded_sample then.
Funny that not even Media Player supports these palette change
chunks, by the way.


what does it do with files from other sources that contain such
chunks ?
maybe it supports them for only some vieo codecs but not rawvideo


I haven't the foggiest. Your assumption might be correct, though.

Mats

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

Re: [FFmpeg-devel] [PATCH 2/3] lavf/avienc: Write palette after BITMAPINFOHEADER

[Michael Niedermayer]

On Fri, Feb 19, 2016 at 10:05:32PM +0100, Mats Peterson wrote:
> On 02/19/2016 10:00 PM, Michael Niedermayer wrote:
> -
>   pc_tag = ff_start_tag(pb, tag);
>   avio_w8(pb, 0);
> >
>   avio_w8(pb, 0);
> >
>   avio_wl16(pb, 0); // reserved
> -for (i = 0; i<256; i++) {
> +for (i = 0; i < pal_size; i++) {
> >>>
> >>>this mismatches the stored size above
> >>
> >>Mismatches what stored size?
> >
> >the "avio_w8(pb, 0);" above
> >
> 
> Right. I'll just set that one to 1 << bits_per_coded_sample then.
> Funny that not even Media Player supports these palette change
> chunks, by the way.

what does it do with files from other sources that contain such
chunks ?
maybe it supports them for only some vieo codecs but not rawvideo

[...]
-- 
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

[FFmpeg-devel] FATE error on dnxhr-parse

[Mats Peterson]

Just got this FATE error, Michael. Why? My changes can't possibly affect 
this part, can they?


--- ./tests/ref/fate/dnxhr-parse2016-02-19 17:36:39.051308004 +0100
+++ tests/data/fate/dnxhr-parse 2016-02-19 22:03:11.715918354 +0100
@@ -0,0 +1,5 @@
+#tb 0: 1/25
+0,  0,  0,1, 16588800, 0x67ebfdb1
+0,  1,  1,1, 16588800, 0x7fa687e6
+0,  2,  2,1, 16588800, 0x4e13f5eb
+0,  3,  3,1, 16588800, 0x054a642d
Test dnxhr-parse failed. Look at tests/data/fate/dnxhr-parse.err for 
details.

make: *** [fate-dnxhr-parse] Error 1

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavf/avienc: Write palette after BITMAPINFOHEADER

[Mats Peterson]

On 02/19/2016 10:00 PM, Michael Niedermayer wrote:

-
  pc_tag = ff_start_tag(pb, tag);
  avio_w8(pb, 0);



  avio_w8(pb, 0);



  avio_wl16(pb, 0); // reserved
-for (i = 0; i<256; i++) {
+for (i = 0; i < pal_size; i++) {


this mismatches the stored size above


Mismatches what stored size?


the "avio_w8(pb, 0);" above



Right. I'll just set that one to 1 << bits_per_coded_sample then. Funny 
that not even Media Player supports these palette change chunks, by the way.


Mats

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

Re: [FFmpeg-devel] [PATCH 2/3] lavf/avienc: Write palette after BITMAPINFOHEADER

[Michael Niedermayer]

On Fri, Feb 19, 2016 at 09:22:45PM +0100, Mats Peterson wrote:
> On 02/19/2016 05:52 PM, Michael Niedermayer wrote:
> >On Fri, Feb 19, 2016 at 04:35:17PM +0100, Mats Peterson wrote:
> >>
> >>--
> >>Mats Peterson
> >>http://matsp888.no-ip.org/~mats/
> >
> >>  avienc.c |   31 +++
> >>  1 file changed, 27 insertions(+), 4 deletions(-)
> >>8d58e7c344ff8650d971483a80211a9eeb540d20  
> >>0002-lavf-avienc-Write-palette-after-BITMAPINFOHEADER.patch
> >> From 0294d37cd23f971376290be68dd681513740bb06 Mon Sep 17 00:00:00 2001
> >>From: Mats Peterson 
> >>Date: Fri, 19 Feb 2016 16:23:17 +0100
> >>Subject: [PATCH 2/3] lavf/avienc: Write palette after BITMAPINFOHEADER
> >>
> >>---
> >>  libavformat/avienc.c |   31 +++
> >>  1 file changed, 27 insertions(+), 4 deletions(-)
> >>
> >>diff --git a/libavformat/avienc.c b/libavformat/avienc.c
> >>index 4e7bca4..3c357a2 100644
> >>--- a/libavformat/avienc.c
> >>+++ b/libavformat/avienc.c
> >>@@ -79,6 +79,8 @@ typedef struct AVIStream {
> >>  AVIIndex indexes;
> >>  } AVIStream;
> >>
> >>+static int hdr_pal_done;
> >
> >this must be in the context, AVIStream
> >non constant statics would break if there are 2 avi muxers
> >
> 
> Alright.
> 
> 
> >
> >>+
> >>  static int avi_write_packet_internal(AVFormatContext *s, AVPacket *pkt);
> >>
> >>  static inline AVIIentry *avi_get_ientry(const AVIIndex *idx, int ent_id)
> >>@@ -211,6 +213,9 @@ static int avi_write_header(AVFormatContext *s)
> >>  return AVERROR(ENOMEM);
> >>  }
> >>
> >>+/* Palette after BITMAPINFOHEADER in strf chunk */
> >>+hdr_pal_done = 0;
> >>+
> >>  /* header list */
> >>  avi->riff_id = 0;
> >>  list1 = avi_start_new_riff(s, pb, "AVI ", "hdrl");
> >>@@ -359,6 +364,12 @@ static int avi_write_header(AVFormatContext *s)
> >>  && enc->pix_fmt == AV_PIX_FMT_RGB555LE
> >>  && enc->bits_per_coded_sample == 15)
> >>  enc->bits_per_coded_sample = 16;
> >>+/* Use private data for palette offset */
> >>+if (enc->bits_per_coded_sample <= 8) {
> >>+enc->priv_data = av_malloc(sizeof(int64_t));
> >>+if (!enc->priv_data)
> >>+return AVERROR(ENOMEM);
> >>+}
> >>  ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0);
> >>  pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi,
> >>enc->bits_per_coded_sample);
> >>@@ -673,16 +684,28 @@ static int avi_write_packet(AVFormatContext *s, 
> >>AVPacket *pkt)
> >>  if (ret) {
> >>  if (ret == CONTAINS_PAL) {
> >>  int pc_tag, i;
> >>+int pal_size = 1 << enc->bits_per_coded_sample;
> >>+if (!hdr_pal_done) {
> >>+int64_t cur_offset = avio_tell(pb);
> >>+int64_t *pal_offset = (int64_t *)enc->priv_data;
> >>+avio_seek(pb, *pal_offset, SEEK_SET);
> >>+for (i = 0; i < pal_size; i++) {
> >>+uint32_t v = AV_RL32(data + size - 4*pal_size + 
> >>4*i);
> >>+avio_wl32(pb, v & 0xff);
> >>+}
> >>+avio_seek(pb, cur_offset, SEEK_SET);
> >>+av_free(enc->priv_data);
> >>+hdr_pal_done++;
> >>+}
> >>  avi_stream2fourcc(tag, stream_index, enc->codec_type);
> >>  tag[2] = 'p'; tag[3] = 'c';
> >>-
> >>  pc_tag = ff_start_tag(pb, tag);
> >>  avio_w8(pb, 0);

> >>  avio_w8(pb, 0);

> >>  avio_wl16(pb, 0); // reserved
> >>-for (i = 0; i<256; i++) {
> >>+for (i = 0; i < pal_size; i++) {
> >
> >this mismatches the stored size above
> 
> Mismatches what stored size?

the "avio_w8(pb, 0);" above

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vp9: add superframe merging bitstream filter.

[Michael Niedermayer]

On Fri, Feb 19, 2016 at 02:43:48PM -0500, Ronald S. Bultje wrote:
> Fixes ticket 4313.
> ---
>  ffmpeg.c|   3 +
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/vp9_superframe_bsf.c | 189 
> 
>  libavformat/ivfenc.c|  13 +++
>  libavformat/matroskaenc.c   |   5 +-
>  libavformat/mux.c   |  24 ++---
>  libavformat/utils.c |   5 ++
>  8 files changed, 229 insertions(+), 12 deletions(-)
>  create mode 100644 libavcodec/vp9_superframe_bsf.c

breaks fate

acodec-flac-exact-rice
TESTacodec-g723_1
TESTacodec-ra144
--- ./tests/ref/acodec/flac 2016-02-17 05:18:12.137817721 +0100
+++ tests/data/fate/acodec-flac 2016-02-19 21:47:18.898708417 +0100
@@ -1,4 +1,4 @@
-151eef9097f944726968bec48649f00a *tests/data/fate/acodec-flac.flac
+451ae98137ad04bf6c16c9fc6a862012 *tests/data/fate/acodec-flac.flac
 361582 tests/data/fate/acodec-flac.flac
 95e54b261530a1bcf6de6fe3b21dc5f6 *tests/data/fate/acodec-flac.out.wav
 stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:  1058400/  1058400
Test acodec-flac failed. Look at tests/data/fate/acodec-flac.err for details.
make: *** [fate-acodec-flac] Error 1
make: *** Waiting for unfinished jobs
--- ./tests/ref/acodec/flac-exact-rice  2016-02-19 02:07:54.745217610 +0100
+++ tests/data/fate/acodec-flac-exact-rice  2016-02-19 21:47:18.934708417 
+0100
@@ -1,4 +1,4 @@
-aab144de213ae684ca008a3e0afe5e28 *tests/data/fate/acodec-flac-exact-rice.flac
+14f0ff901a80f1c27989187f981277f4 *tests/data/fate/acodec-flac-exact-rice.flac
 360454 tests/data/fate/acodec-flac-exact-rice.flac
 95e54b261530a1bcf6de6fe3b21dc5f6 
*tests/data/fate/acodec-flac-exact-rice.out.wav
 stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:  1058400/  1058400


[...]
-- 
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] Fixed issue #43 JACK indev support on OSX

[Josh de Kock]

---
 configure  | 13 ++---
 libavdevice/jack.c | 10 ++
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 287896f..78f9618 100755
--- a/configure
+++ b/configure
@@ -1732,6 +1732,7 @@ BUILTIN_LIST="
 mm_empty
 rdtsc
 sarestart
+sem_timedwait
 sync_val_compare_and_swap
 "
 HAVE_LIST_CMDLINE="
@@ -1753,6 +1754,7 @@ HEADERS_LIST="
 asm_types_h
 cdio_paranoia_h
 cdio_paranoia_paranoia_h
+dispatch_dispatch_h
 dev_bktr_ioctl_bt848_h
 dev_bktr_ioctl_meteor_h
 dev_ic_bt8xx_h
@@ -2757,7 +2759,7 @@ gdigrab_indev_deps="CreateDIBSection"
 gdigrab_indev_extralibs="-lgdi32"
 gdigrab_indev_select="bmp_decoder"
 iec61883_indev_deps="libiec61883"
-jack_indev_deps="jack_jack_h sem_timedwait"
+jack_indev_deps="jack_jack_h"
 lavfi_indev_deps="avfilter"
 libcdio_indev_deps="libcdio"
 libdc1394_indev_deps="libdc1394"
@@ -5266,6 +5268,7 @@ check_builtin atomic_compare_exchange "" "int *ptr, 
*oldval; int newval; __atomi
 check_builtin machine_rw_barrier mbarrier.h "__machine_rw_barrier()"
 check_builtin MemoryBarrier windows.h "MemoryBarrier()"
 check_builtin sarestart signal.h "SA_RESTART"
+check_builtin sem_timedwait semaphore.h "sem_t *s; sem_init(s,0,0); 
sem_timedwait(s,0); sem_destroy(s)" -lpthread
 check_builtin sync_val_compare_and_swap "" "int *ptr; int oldval, newval; 
__sync_val_compare_and_swap(ptr, oldval, newval)"
 check_builtin gmtime_r time.h "time_t *time; struct tm *tm; gmtime_r(time, tm)"
 check_builtin localtime_r time.h "time_t *time; struct tm *tm; 
localtime_r(time, tm)"
@@ -5330,6 +5333,7 @@ check_func_headers glob.h glob
 enabled xlib &&
 check_func_headers "X11/Xlib.h X11/extensions/Xvlib.h" XvGetPortAttribute 
-lXv -lX11 -lXext
 
+check_header dispatch/dispatch.h
 check_header direct.h
 check_header dirent.h
 check_header dlfcn.h
@@ -5702,8 +5706,11 @@ check_header soundcard.h
 enabled_any alsa_indev alsa_outdev &&
 check_lib2 alsa/asoundlib.h snd_pcm_htimestamp -lasound
 
-enabled jack_indev && check_lib2 jack/jack.h jack_client_open -ljack && 
check_func sem_timedwait &&
-check_func jack_port_get_latency_range -ljack
+enabled jack_indev &&
+ check_lib2 jack/jack.h jack_client_open -ljack &&
+ check_func jack_port_get_latency_range -ljack &&
+ enabled_any sem_timedwait dispatch_dispatch_h ||
+ disable jack_indev
 
 enabled_any sndio_indev sndio_outdev && check_lib2 sndio.h sio_open -lsndio
 
diff --git a/libavdevice/jack.c b/libavdevice/jack.c
index 9ecbf9e..5455484 100644
--- a/libavdevice/jack.c
+++ b/libavdevice/jack.c
@@ -35,6 +35,16 @@
 #include "timefilter.h"
 #include "avdevice.h"
 
+#if HAVE_DISPATCH_DISPATCH_H
+#include 
+#define sem_t dispatch_semaphore_t
+#define sem_init(psem,x,val)  *psem = dispatch_semaphore_create(val)
+#define sem_post(psem)dispatch_semaphore_signal(*psem)
+#define sem_wait(psem)dispatch_semaphore_wait(*psem, 
DISPATCH_TIME_FOREVER)
+#define sem_timedwait(psem, val)  dispatch_semaphore_wait(*psem, 
dispatch_walltime(val, 0))
+#define sem_destroy(psem) dispatch_release(*psem)
+#endif
+
 /**
  * Size of the internal FIFO buffers as a number of audio packets
  */
-- 
2.5.4 (Apple Git-61)

> this breaks build when libjack is not available
>
> for example on mingw64
> without explicitly enabling jack it fails with:
> ERROR: input device jack could not be enabled
For some reason I assumed that the JACK indev had to be manually enabled, and 
therefore if it would be an error if it's dependencies. However, looking at the 
other indevs, I found that none of them threw errors, making it likely that all 
the indevs were on by default, and turned off when they weren't available 
(which would make sense).

I've removed the die statement which, hopefully, will fix all remaining issues. 

Thanks for your patience,
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavf/avienc: Write palette after BITMAPINFOHEADER

[Mats Peterson]

On 02/19/2016 05:52 PM, Michael Niedermayer wrote:

On Fri, Feb 19, 2016 at 04:35:17PM +0100, Mats Peterson wrote:


--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  avienc.c |   31 +++
  1 file changed, 27 insertions(+), 4 deletions(-)
8d58e7c344ff8650d971483a80211a9eeb540d20  
0002-lavf-avienc-Write-palette-after-BITMAPINFOHEADER.patch
 From 0294d37cd23f971376290be68dd681513740bb06 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 19 Feb 2016 16:23:17 +0100
Subject: [PATCH 2/3] lavf/avienc: Write palette after BITMAPINFOHEADER

---
  libavformat/avienc.c |   31 +++
  1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 4e7bca4..3c357a2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -79,6 +79,8 @@ typedef struct AVIStream {
  AVIIndex indexes;
  } AVIStream;

+static int hdr_pal_done;


this must be in the context, AVIStream
non constant statics would break if there are 2 avi muxers



Alright.





+
  static int avi_write_packet_internal(AVFormatContext *s, AVPacket *pkt);

  static inline AVIIentry *avi_get_ientry(const AVIIndex *idx, int ent_id)
@@ -211,6 +213,9 @@ static int avi_write_header(AVFormatContext *s)
  return AVERROR(ENOMEM);
  }

+/* Palette after BITMAPINFOHEADER in strf chunk */
+hdr_pal_done = 0;
+
  /* header list */
  avi->riff_id = 0;
  list1 = avi_start_new_riff(s, pb, "AVI ", "hdrl");
@@ -359,6 +364,12 @@ static int avi_write_header(AVFormatContext *s)
  && enc->pix_fmt == AV_PIX_FMT_RGB555LE
  && enc->bits_per_coded_sample == 15)
  enc->bits_per_coded_sample = 16;
+/* Use private data for palette offset */
+if (enc->bits_per_coded_sample <= 8) {
+enc->priv_data = av_malloc(sizeof(int64_t));
+if (!enc->priv_data)
+return AVERROR(ENOMEM);
+}
  ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0);
  pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi,
enc->bits_per_coded_sample);
@@ -673,16 +684,28 @@ static int avi_write_packet(AVFormatContext *s, AVPacket 
*pkt)
  if (ret) {
  if (ret == CONTAINS_PAL) {
  int pc_tag, i;
+int pal_size = 1 << enc->bits_per_coded_sample;
+if (!hdr_pal_done) {
+int64_t cur_offset = avio_tell(pb);
+int64_t *pal_offset = (int64_t *)enc->priv_data;
+avio_seek(pb, *pal_offset, SEEK_SET);
+for (i = 0; i < pal_size; i++) {
+uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+avio_wl32(pb, v & 0xff);
+}
+avio_seek(pb, cur_offset, SEEK_SET);
+av_free(enc->priv_data);
+hdr_pal_done++;
+}
  avi_stream2fourcc(tag, stream_index, enc->codec_type);
  tag[2] = 'p'; tag[3] = 'c';
-
  pc_tag = ff_start_tag(pb, tag);
  avio_w8(pb, 0);
  avio_w8(pb, 0);
  avio_wl16(pb, 0); // reserved
-for (i = 0; i<256; i++) {
+for (i = 0; i < pal_size; i++) {


this mismatches the stored size above


Mismatches what stored size?






-uint32_t v = AV_RL32(data + size - 1024 + 4*i);
+uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);



-avio_wb32(pb, v<<8);
+avio_wl32(pb, v & 0xff);


it looked correct when i tested this before the patch



Yes, but it wasn't. It stored the palette in RGB order instead of BGR.

Mats

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

Re: [FFmpeg-devel] [PATCH] lavc/libvpx: fix support for RGB colorspace.

[Carl Eugen Hoyos]

Carl Eugen Hoyos  ag.or.at> writes:

> > >> +case AV_PIX_FMT_GBRP:
> > >> +ctx->vpx_cs = VPX_CS_SRGB;
> > >
> > > This is only available since libvpx 1.4.0, so you need to wrap all this
> > > new code inside some preprocessor checks. I think VPX_IMAGE_ABI_VERSION
> > > >= 3 should do it, but better wait for James Zern for confirmation.
> 
> Of course, new patch attached (depends on the BE fix).

Applied this patch and the reindentation.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavc/libvpx: Fix high-bitrate colour spaces

[Carl Eugen Hoyos]

James Zern  google.com> writes:

> >> I think his point is that the decoder always outputs LE,
> >> and this change is therefor incorrect?
> >
> > Don't you agree that this is highly unlikely?
> > (I mean by looking at the code, not because I claim it.)
> >
> 
> Yes, you're correct, I wasn't considering the high-bitdepth output
> properly. The decoder uses 16-bit values in their native endian
> format, so your patch is correct.

Thank you for the review!

Could you comment on ticket #3271 (is alpha possible in 
vp9?) and #4105?

Patch applied, Carl Eugen

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

Re: [FFmpeg-devel] [Cellar] [Matroska-devel] Colour Format proposal

[Dave Rice]

Hi all,

Working with the IETF Cellar Working Group, 
https://datatracker.ietf.org/wg/cellar/charter/, Frank Galligan has drafted a 
proposal for the management of metadata in Matroska to accommodate information 
on color, full/broadcast range, HDR metadata, chroma subsampling patterns and 
other information. I'm forwarding it to ffmpeg-devel and libav-devel to 
encourage any additional comments. The background discussion thus far is 
visible at 
https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&q=Colour+Format+proposal
 
.
 For context, the structure for Matroska element definitions is currently in 
draft here: 
https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown#ebml-schema-element-attributes
 
.

> Begin forwarded message:
> 
> From: Frank Galligan 
> Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal
> Date: February 18, 2016 at 2:50:27 PM EST
> To: Dave Rice 
> Cc: Jerome Martinez , Discussion about the current and 
> future development of Matroska , 
> cel...@ietf.org
> 
> Here is the current proposal, minus the reference to the 265 doc.
> 
> The parent element would be Video [E0].
> 
> 
> Element Name: Colour
> Level:4
> ID:   [55][B0]
> Mandatory:-
> Multiple: -
> Default:  -
> Type: m
> Description:  Settings describing the colour format.
> 
> 
> Element Name: MatrixCoefficients
> Level:5
> ID:   [55][B1]
> Mandatory:-
> Multiple: -
> Default:  2
> Type: u
> Description:  The Matrix Coefficients of the video used to derive luma and
>   chroma values from reg, green, and blue color primaries. For
>   clarity, the value and meanings for MatrixCoefficients are 
> adopted
>   from Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0:GBR, 1: BT709,
>   2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M,
>   7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance,
>   10: BT2020 Constant Luminance) 
> 
> 
> Element Name: BitsPerChannel
> Level:5
> ID:   [55][B2]
> Mandatory:-
> Multiple: -
> Default:  0
> Type: u
> Description:  Number of decoded bits per channel. A value of 0 indicates that
>   the BitsPerChannel is unspecified.
> 
> 
> Element Name: ChromaSubsamplingHorz
> Level:5
> ID:   [55][B3]
> Mandatory:-
> Multiple: -
> Default:  -
> Type: u
> Description:  The amount of pixels to remove in the Cr and Cb channels for 
> every
>   pixel not removed horizontally. Example: For video with 4:2:0
>   chroma subsampling, the ChromaSubsamplingHorz should be set to 
> 1.
> 
> 
> Element Name: ChromaSubsamplingVert
> Level:5
> ID:   [55][B4]
> Mandatory:-
> Multiple: -
> Default:  -
> Type: u
> Description:  The amount of pixels to remove in the Cr and Cb channels for 
> every
>   pixel not removed vertically. Example: For video with 4:2:0 
> chroma
>   subsampling, the ChromaSubsamplingVert should be set to 1.
> 
> Element Name: CbSubsamplingHorz
> Level:5
> ID:   [55][B5]
> Mandatory:-
> Multiple: -
> Default:  -
> Type: u
> Description:  The amount of pixels to remove in the Cb channel for every pixel
>   not removed horizontally. This is additive with
>   ChromaSubsamplingHorz. Example: For video with 4:2:1 chroma
>   subsampling, the ChromaSubsamplingHorz should be set to 1 and
>   CbSubsamplingHorz should be set to 1.
> 
> 
> Element Name: CbSubsamplingVert
> Level:5
> ID:   [55][B6]
> Mandatory:-
> Multiple: -
> Default:  -
> Type: u
> Description:  The amount of pixels to remove in the Cb channel for every pixel
>   not removed vertically. This is additive with
>   ChromaSubsamplingVert.
> 
> 
> Element Name: ChromaSitingHorz
> Level:5
> ID:   [55][B7]
> Mandatory:-
> Multiple: -
> Default:  0
> Type: u
> Description:  How Chroma is subsampled horizontally. (0: Unspecified, 1: Left 
>   collocated , 2: Half)
> 
> Element Name: ChromaSitingVert
> Level:5
> ID:   [55][B8]
> Mandatory:-
> Multiple: -
> Default:  0
> Type: u
> Description:  How Chroma is subsampled vertically. (0: Unspecified, 1: Top
>   collocated , 2: Half)
> 
> 
> Element Name: Range
> Level:5
> ID:   [55][B9]
> Mandatory:-
> Multiple: -
> Default:  0
> Type: u
> Description:  Clipping of the color ranges. (0: Unspecified, 1: Broadcast 
> range,
>   2: Full range (no clippi

Re: [FFmpeg-devel] [PATCH] Fixed issue #43 JACK indev support on OSX

[Michael Niedermayer]

On Fri, Feb 19, 2016 at 05:28:52PM +, Josh de Kock wrote:
> ---
>  configure  | 12 +---
>  libavdevice/jack.c | 10 ++
>  2 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/configure b/configure
> index 287896f..887384c 100755
> --- a/configure
> +++ b/configure
> @@ -1732,6 +1732,7 @@ BUILTIN_LIST="
>  mm_empty
>  rdtsc
>  sarestart
> +sem_timedwait
>  sync_val_compare_and_swap
>  "
>  HAVE_LIST_CMDLINE="
> @@ -1753,6 +1754,7 @@ HEADERS_LIST="
>  asm_types_h
>  cdio_paranoia_h
>  cdio_paranoia_paranoia_h
> +dispatch_dispatch_h
>  dev_bktr_ioctl_bt848_h
>  dev_bktr_ioctl_meteor_h
>  dev_ic_bt8xx_h
> @@ -2757,7 +2759,7 @@ gdigrab_indev_deps="CreateDIBSection"
>  gdigrab_indev_extralibs="-lgdi32"
>  gdigrab_indev_select="bmp_decoder"
>  iec61883_indev_deps="libiec61883"
> -jack_indev_deps="jack_jack_h sem_timedwait"
> +jack_indev_deps="jack_jack_h"
>  lavfi_indev_deps="avfilter"
>  libcdio_indev_deps="libcdio"
>  libdc1394_indev_deps="libdc1394"
> @@ -5266,6 +5268,7 @@ check_builtin atomic_compare_exchange "" "int *ptr, 
> *oldval; int newval; __atomi
>  check_builtin machine_rw_barrier mbarrier.h "__machine_rw_barrier()"
>  check_builtin MemoryBarrier windows.h "MemoryBarrier()"
>  check_builtin sarestart signal.h "SA_RESTART"
> +check_builtin sem_timedwait semaphore.h "sem_t *s; sem_init(s,0,0); 
> sem_timedwait(s,0); sem_destroy(s)" -lpthread
>  check_builtin sync_val_compare_and_swap "" "int *ptr; int oldval, newval; 
> __sync_val_compare_and_swap(ptr, oldval, newval)"
>  check_builtin gmtime_r time.h "time_t *time; struct tm *tm; gmtime_r(time, 
> tm)"
>  check_builtin localtime_r time.h "time_t *time; struct tm *tm; 
> localtime_r(time, tm)"
> @@ -5330,6 +5333,7 @@ check_func_headers glob.h glob
>  enabled xlib &&
>  check_func_headers "X11/Xlib.h X11/extensions/Xvlib.h" 
> XvGetPortAttribute -lXv -lX11 -lXext
>  
> +check_header dispatch/dispatch.h
>  check_header direct.h
>  check_header dirent.h
>  check_header dlfcn.h

> @@ -5702,8 +5706,10 @@ check_header soundcard.h
>  enabled_any alsa_indev alsa_outdev &&
>  check_lib2 alsa/asoundlib.h snd_pcm_htimestamp -lasound
>  
> -enabled jack_indev && check_lib2 jack/jack.h jack_client_open -ljack && 
> check_func sem_timedwait &&
> -check_func jack_port_get_latency_range -ljack
> +enabled jack_indev && check_lib2 jack/jack.h jack_client_open -ljack &&
> + check_func jack_port_get_latency_range -ljack &&
> + enabled_any sem_timedwait dispatch_dispatch_h ||
> + { disable jack_indev && die "ERROR: input device jack could not be 
> enabled"; }

this breaks build when libjack is not available

for example on mingw64
without explicitly enabling jack it fails with:
ERROR: input device jack could not be enabled

If you think configure made a mistake, make sure you are using the latest
version from Git.  If the latest version fails, report the problem to the
ffmpeg-u...@ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net.
Include the log file "config.log" produced by configure as this will help
solve the problem.


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill hundred thousands of
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

[FFmpeg-devel] [PATCH] vp9: add superframe merging bitstream filter.

[Ronald S. Bultje]

Fixes ticket 4313.
---
 ffmpeg.c|   3 +
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/vp9_superframe_bsf.c | 189 
 libavformat/ivfenc.c|  13 +++
 libavformat/matroskaenc.c   |   5 +-
 libavformat/mux.c   |  24 ++---
 libavformat/utils.c |   5 ++
 8 files changed, 229 insertions(+), 12 deletions(-)
 create mode 100644 libavcodec/vp9_superframe_bsf.c

diff --git a/ffmpeg.c b/ffmpeg.c
index a5ec3c3..04f873e 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -694,6 +694,8 @@ static void write_frame(AVFormatContext *s, AVPacket *pkt, 
OutputStream *ost)
 if (exit_on_error)
 exit_program(1);
 }
+if (pkt->size == 0)
+return;
 
 if (!(s->oformat->flags & AVFMT_NOTIMESTAMPS)) {
 if (pkt->dts != AV_NOPTS_VALUE &&
@@ -710,6 +712,7 @@ static void write_frame(AVFormatContext *s, AVPacket *pkt, 
OutputStream *ost)
  if(
 (avctx->codec_type == AVMEDIA_TYPE_AUDIO || avctx->codec_type == 
AVMEDIA_TYPE_VIDEO) &&
 pkt->dts != AV_NOPTS_VALUE &&
+!(avctx->codec_id == AV_CODEC_ID_VP9 && ost->stream_copy) &&
 ost->last_mux_dts != AV_NOPTS_VALUE) {
   int64_t max = ost->last_mux_dts + !(s->oformat->flags & 
AVFMT_TS_NONSTRICT);
   if (pkt->dts < max) {
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index f6a4fbb..041684d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -916,6 +916,7 @@ OBJS-$(CONFIG_MP3_HEADER_DECOMPRESS_BSF)  += 
mp3_header_decompress_bsf.o \
 OBJS-$(CONFIG_NOISE_BSF)  += noise_bsf.o
 OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF)   += remove_extradata_bsf.o
 OBJS-$(CONFIG_TEXT2MOVSUB_BSF)+= movsub_bsf.o
+OBJS-$(CONFIG_VP9_SUPERFRAME_BSF) += vp9_superframe_bsf.o
 
 # thread libraries
 OBJS-$(HAVE_LIBC_MSVCRT)   += file_open.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 2097db0..96f5c5c 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -666,4 +666,5 @@ void avcodec_register_all(void)
 REGISTER_BSF(NOISE, noise);
 REGISTER_BSF(REMOVE_EXTRADATA,  remove_extradata);
 REGISTER_BSF(TEXT2MOVSUB,   text2movsub);
+REGISTER_BSF(VP9_SUPERFRAME,vp9_superframe);
 }
diff --git a/libavcodec/vp9_superframe_bsf.c b/libavcodec/vp9_superframe_bsf.c
new file mode 100644
index 000..f991a80
--- /dev/null
+++ b/libavcodec/vp9_superframe_bsf.c
@@ -0,0 +1,189 @@
+/*
+ * Vp9 invisible (alt-ref) frame to superframe merge bitstream filter
+ * Copyright (c) 2016 Ronald S. Bultje 
+ *
+ * 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
+ */
+
+#include "libavutil/avassert.h"
+#include "avcodec.h"
+#include "get_bits.h"
+
+#define MAX_CACHE 8
+typedef struct VP9BSFContext {
+int n_cache;
+struct CachedBuf {
+uint8_t *data;
+int size;
+} cache[MAX_CACHE];
+} VP9BSFContext;
+
+static void stats(const struct CachedBuf *in, int n_in,
+  unsigned *_max, unsigned *_sum)
+{
+int n;
+unsigned max = 0, sum = 0;
+
+for (n = 0; n < n_in; n++) {
+unsigned sz = in[n].size;
+
+if (sz > max)
+max = sz;
+sum += sz;
+}
+
+*_max = max;
+*_sum = sum;
+}
+
+static int merge_superframe(const struct CachedBuf *in, int n_in,
+uint8_t **poutbuf, int *poutbuf_size)
+{
+unsigned max, sum, mag, marker, n, sz;
+uint8_t *ptr;
+
+stats(in, n_in, &max, &sum);
+mag = av_log2(max) >> 3;
+marker = 0xC0 + (mag << 3) + (n_in - 1);
+sz = *poutbuf_size = sum + 2 + (mag + 1) * n_in;
+ptr = *poutbuf = av_malloc(sz);
+if (!ptr)
+return AVERROR(ENOMEM);
+
+for (n = 0; n < n_in; n++) {
+memcpy(ptr, in[n].data, in[n].size);
+ptr += in[n].size;
+}
+
+#define wloop(mag, wr) \
+for (n = 0; n < n_in; n++) { \
+wr; \
+ptr += mag + 1; \
+}
+
+// write superframe with marker 110[mag:2][nframes:3]
+*ptr++ = marker;
+switch (mag) {
+case 0:
+wloop(mag, *ptr = in[n].size);
+break;
+case 1:
+wloop(mag, AV_WB16(ptr, in[n].size));
+break;
+  

Re: [FFmpeg-devel] [PATCH] checkasm: fix dependencies for vf_blend tests

[James Almer]

On 2/19/2016 6:30 AM, Paul B Mahol wrote:
> On 2/19/16, James Almer  wrote:
>> They will now compile if avcodec is disabled
>>
>> Signed-off-by: James Almer 
>> ---
>>  tests/checkasm/Makefile   | 6 +-
>>  tests/checkasm/checkasm.c | 8 +---
>>  2 files changed, 10 insertions(+), 4 deletions(-)
>>
> 
> ok

Pushed, thanks.

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

Re: [FFmpeg-devel] [PATCH]lavc/libvpx: Fix high-bitrate colour spaces

[James Zern]

On Fri, Feb 19, 2016 at 12:43 AM, Carl Eugen Hoyos  wrote:
> Hendrik Leppkes  gmail.com> writes:
>
>> On Fri, Feb 19, 2016 at 8:47 AM, James Zern wrote:
>> > On Thu, Feb 18, 2016 at 11:40 PM, Carl Eugen Hoyos wrote:
>> >> On Friday 19 February 2016 07:59:37 am James Zern wrote:
>> >>
>> >>> The decoder won't change when built on a big-endian
>> >>> platform, so I don't think this is correct.
>> >>
>> >> New patch attached.
>> >
>> > Sorry, I meant all of it, high bitdepth is no different.
>>
>> I think his point is that the decoder always outputs LE,
>> and this change is therefor incorrect?
>
> Don't you agree that this is highly unlikely?
> (I mean by looking at the code, not because I claim it.)
>

Yes, you're correct, I wasn't considering the high-bitdepth output
properly. The decoder uses 16-bit values in their native endian
format, so your patch is correct. Sorry for the churn.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vf_blend: Use integers for divide mode

[Martin Vignali]

Hello,

Is it necessary to clip value, if B == 0 ?


Martin

2016-02-19 18:47 GMT+01:00 Timothy Gu :

> On Sun, Feb 14, 2016 at 10:41:04AM +0100, Paul B Mahol wrote:
> >
> > ok
>
> Pushed (last week). Thanks.
>
> Timothy
> ___
> 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] vf_blend: Use integers for divide mode

[Timothy Gu]

On Sun, Feb 14, 2016 at 10:41:04AM +0100, Paul B Mahol wrote:
> 
> ok

Pushed (last week). Thanks.

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

[FFmpeg-devel] [PATCH] Fixed issue #43 JACK indev support on OSX

[Josh de Kock]

---
 configure  | 12 +---
 libavdevice/jack.c | 10 ++
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 287896f..887384c 100755
--- a/configure
+++ b/configure
@@ -1732,6 +1732,7 @@ BUILTIN_LIST="
 mm_empty
 rdtsc
 sarestart
+sem_timedwait
 sync_val_compare_and_swap
 "
 HAVE_LIST_CMDLINE="
@@ -1753,6 +1754,7 @@ HEADERS_LIST="
 asm_types_h
 cdio_paranoia_h
 cdio_paranoia_paranoia_h
+dispatch_dispatch_h
 dev_bktr_ioctl_bt848_h
 dev_bktr_ioctl_meteor_h
 dev_ic_bt8xx_h
@@ -2757,7 +2759,7 @@ gdigrab_indev_deps="CreateDIBSection"
 gdigrab_indev_extralibs="-lgdi32"
 gdigrab_indev_select="bmp_decoder"
 iec61883_indev_deps="libiec61883"
-jack_indev_deps="jack_jack_h sem_timedwait"
+jack_indev_deps="jack_jack_h"
 lavfi_indev_deps="avfilter"
 libcdio_indev_deps="libcdio"
 libdc1394_indev_deps="libdc1394"
@@ -5266,6 +5268,7 @@ check_builtin atomic_compare_exchange "" "int *ptr, 
*oldval; int newval; __atomi
 check_builtin machine_rw_barrier mbarrier.h "__machine_rw_barrier()"
 check_builtin MemoryBarrier windows.h "MemoryBarrier()"
 check_builtin sarestart signal.h "SA_RESTART"
+check_builtin sem_timedwait semaphore.h "sem_t *s; sem_init(s,0,0); 
sem_timedwait(s,0); sem_destroy(s)" -lpthread
 check_builtin sync_val_compare_and_swap "" "int *ptr; int oldval, newval; 
__sync_val_compare_and_swap(ptr, oldval, newval)"
 check_builtin gmtime_r time.h "time_t *time; struct tm *tm; gmtime_r(time, tm)"
 check_builtin localtime_r time.h "time_t *time; struct tm *tm; 
localtime_r(time, tm)"
@@ -5330,6 +5333,7 @@ check_func_headers glob.h glob
 enabled xlib &&
 check_func_headers "X11/Xlib.h X11/extensions/Xvlib.h" XvGetPortAttribute 
-lXv -lX11 -lXext
 
+check_header dispatch/dispatch.h
 check_header direct.h
 check_header dirent.h
 check_header dlfcn.h
@@ -5702,8 +5706,10 @@ check_header soundcard.h
 enabled_any alsa_indev alsa_outdev &&
 check_lib2 alsa/asoundlib.h snd_pcm_htimestamp -lasound
 
-enabled jack_indev && check_lib2 jack/jack.h jack_client_open -ljack && 
check_func sem_timedwait &&
-check_func jack_port_get_latency_range -ljack
+enabled jack_indev && check_lib2 jack/jack.h jack_client_open -ljack &&
+ check_func jack_port_get_latency_range -ljack &&
+ enabled_any sem_timedwait dispatch_dispatch_h ||
+ { disable jack_indev && die "ERROR: input device jack could not be 
enabled"; }
 
 enabled_any sndio_indev sndio_outdev && check_lib2 sndio.h sio_open -lsndio
 
diff --git a/libavdevice/jack.c b/libavdevice/jack.c
index 9ecbf9e..5455484 100644
--- a/libavdevice/jack.c
+++ b/libavdevice/jack.c
@@ -35,6 +35,16 @@
 #include "timefilter.h"
 #include "avdevice.h"
 
+#if HAVE_DISPATCH_DISPATCH_H
+#include 
+#define sem_t dispatch_semaphore_t
+#define sem_init(psem,x,val)  *psem = dispatch_semaphore_create(val)
+#define sem_post(psem)dispatch_semaphore_signal(*psem)
+#define sem_wait(psem)dispatch_semaphore_wait(*psem, 
DISPATCH_TIME_FOREVER)
+#define sem_timedwait(psem, val)  dispatch_semaphore_wait(*psem, 
dispatch_walltime(val, 0))
+#define sem_destroy(psem) dispatch_release(*psem)
+#endif
+
 /**
  * Size of the internal FIFO buffers as a number of audio packets
  */
-- 
2.5.4 (Apple Git-61)

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

Re: [FFmpeg-devel] [PATCH] lavf/md5enc: New streammd5 muxer

[Remko Tronçon]

Hi Nicolas,

Thanks for the comments.

On 19 February 2016 at 17:51, Nicolas George  wrote:

> but I am rather dubious about the
> usefulness of that: you could mux the streams independently to the md5
> muxer.
>

I did not find a way to do this without having to first probe each file to
get a list of all streams, and then do multiple invocations of ffmpeg and
mapping only a single stream. I'm not an expert, but I'm guessing you can
do it with one invocation by creating a filter graph, but that would still
require you to enumerate all the streams? Or am I completely wrong?

I regularly work on different files that I want to compare against each
other, which I know some streams are different and some not. What I wanted
was the ability to have a single command to dump all the hashes of the
streams in the file: I can quickly invoke this on a couple of files, and
compare the results with what i was expecting simply by looking at the
output (e.g. the video stream differs, but all the audio streams are
identical).

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

[FFmpeg-devel] [PATCH] vp9: add superframe merging bitstream filter.

[Ronald S. Bultje]

Fixes ticket 4313.

There is still an issue after this patch: it works when you use -bsf
vp9_superframe, but if you let the auto-bsf system work on its own,
ffmpeg.c triggers these warnings:

[ivf @ 0x7fc97a02fc00] Non-monotonous DTS in output stream 0:0;
previous: 900, current: 900; changing to 901. This may result in
incorrect timestamps in the output file.

This warning code lives in ffmpeg.c and I'm not entirely sure how to
prevent this from running. Suggestions welcome.
---
 ffmpeg.c|   2 +
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/vp9_superframe_bsf.c | 189 
 libavformat/ivfenc.c|  13 +++
 libavformat/matroskaenc.c   |   5 +-
 libavformat/mux.c   |   2 +
 libavformat/utils.c |   5 ++
 8 files changed, 217 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/vp9_superframe_bsf.c

diff --git a/ffmpeg.c b/ffmpeg.c
index a5ec3c3..bb7f138 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -694,6 +694,8 @@ static void write_frame(AVFormatContext *s, AVPacket *pkt, 
OutputStream *ost)
 if (exit_on_error)
 exit_program(1);
 }
+if (pkt->size == 0)
+return;
 
 if (!(s->oformat->flags & AVFMT_NOTIMESTAMPS)) {
 if (pkt->dts != AV_NOPTS_VALUE &&
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index f6a4fbb..041684d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -916,6 +916,7 @@ OBJS-$(CONFIG_MP3_HEADER_DECOMPRESS_BSF)  += 
mp3_header_decompress_bsf.o \
 OBJS-$(CONFIG_NOISE_BSF)  += noise_bsf.o
 OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF)   += remove_extradata_bsf.o
 OBJS-$(CONFIG_TEXT2MOVSUB_BSF)+= movsub_bsf.o
+OBJS-$(CONFIG_VP9_SUPERFRAME_BSF) += vp9_superframe_bsf.o
 
 # thread libraries
 OBJS-$(HAVE_LIBC_MSVCRT)   += file_open.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 2097db0..96f5c5c 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -666,4 +666,5 @@ void avcodec_register_all(void)
 REGISTER_BSF(NOISE, noise);
 REGISTER_BSF(REMOVE_EXTRADATA,  remove_extradata);
 REGISTER_BSF(TEXT2MOVSUB,   text2movsub);
+REGISTER_BSF(VP9_SUPERFRAME,vp9_superframe);
 }
diff --git a/libavcodec/vp9_superframe_bsf.c b/libavcodec/vp9_superframe_bsf.c
new file mode 100644
index 000..f991a80
--- /dev/null
+++ b/libavcodec/vp9_superframe_bsf.c
@@ -0,0 +1,189 @@
+/*
+ * Vp9 invisible (alt-ref) frame to superframe merge bitstream filter
+ * Copyright (c) 2016 Ronald S. Bultje 
+ *
+ * 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
+ */
+
+#include "libavutil/avassert.h"
+#include "avcodec.h"
+#include "get_bits.h"
+
+#define MAX_CACHE 8
+typedef struct VP9BSFContext {
+int n_cache;
+struct CachedBuf {
+uint8_t *data;
+int size;
+} cache[MAX_CACHE];
+} VP9BSFContext;
+
+static void stats(const struct CachedBuf *in, int n_in,
+  unsigned *_max, unsigned *_sum)
+{
+int n;
+unsigned max = 0, sum = 0;
+
+for (n = 0; n < n_in; n++) {
+unsigned sz = in[n].size;
+
+if (sz > max)
+max = sz;
+sum += sz;
+}
+
+*_max = max;
+*_sum = sum;
+}
+
+static int merge_superframe(const struct CachedBuf *in, int n_in,
+uint8_t **poutbuf, int *poutbuf_size)
+{
+unsigned max, sum, mag, marker, n, sz;
+uint8_t *ptr;
+
+stats(in, n_in, &max, &sum);
+mag = av_log2(max) >> 3;
+marker = 0xC0 + (mag << 3) + (n_in - 1);
+sz = *poutbuf_size = sum + 2 + (mag + 1) * n_in;
+ptr = *poutbuf = av_malloc(sz);
+if (!ptr)
+return AVERROR(ENOMEM);
+
+for (n = 0; n < n_in; n++) {
+memcpy(ptr, in[n].data, in[n].size);
+ptr += in[n].size;
+}
+
+#define wloop(mag, wr) \
+for (n = 0; n < n_in; n++) { \
+wr; \
+ptr += mag + 1; \
+}
+
+// write superframe with marker 110[mag:2][nframes:3]
+*ptr++ = marker;
+switch (mag) {
+case 0:
+wloop(mag, *ptr = in[n].size);
+break;
+case 1:
+wloop(mag, AV_WB16(ptr, in[n].size));
+break;
+case 2:
+wloo

Re: [FFmpeg-devel] [PATCH] avfilter: add firequalizer filter

[Muhammad Faiz]

On Fri, Feb 19, 2016 at 3:52 AM, Paul B Mahol  wrote:
>> +center = s->fir_len / 2;
>> +
>> +for (k = 0; k <= center; k++) {
>> +double u = k * (M_PI/center);
>> +double win;
>> +switch (s->wfunc) {
>> +case WFUNC_RECTANGULAR:
>> +win = 1.0;
>> +break;
>> +case WFUNC_HANN:
>> +win = 0.5 + 0.5 * cos(u);
>> +break;
>> +case WFUNC_HAMMING:
>> +win = 0.53836 + 0.46164 * cos(u);
>> +break;
>> +case WFUNC_BLACKMAN:
>> +win = 0.48 + 0.5 * cos(u) + 0.02 * cos(2*u);
>> +break;
>> +case WFUNC_NUTTALL3:
>> +win = 0.40897 + 0.5 * cos(u) + 0.09103 * cos(2*u);
>> +break;
>> +case WFUNC_MNUTTALL3:
>> +win = 0.4243801 + 0.4973406 * cos(u) + 0.0782793 * cos(2*u);
>> +break;
>> +case WFUNC_NUTTALL:
>> +win = 0.355768 + 0.487396 * cos(u) + 0.144232 * cos(2*u) + 
>> 0.012604 * cos(3*u);
>> +break;
>> +case WFUNC_BNUTTALL:
>> +win = 0.3635819 + 0.4891775 * cos(u) + 0.1365995 * cos(2*u) 
>> + 0.0106411 * cos(3*u);
>> +break;
>> +case WFUNC_BHARRIS:
>> +win = 0.35875 + 0.48829 * cos(u) + 0.14128 * cos(2*u) + 
>> 0.01168 * cos(3*u);
>> +break;
>
> What about using libavfilter/window_func.c ?

My version calculate half-length zero centered window. Incompatible
with ff_generate_window_func()

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

Re: [FFmpeg-devel] [PATCH 2/3] lavf/avienc: Write palette after BITMAPINFOHEADER

[Michael Niedermayer]

On Fri, Feb 19, 2016 at 04:35:17PM +0100, Mats Peterson wrote:
> 
> -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  avienc.c |   31 +++
>  1 file changed, 27 insertions(+), 4 deletions(-)
> 8d58e7c344ff8650d971483a80211a9eeb540d20  
> 0002-lavf-avienc-Write-palette-after-BITMAPINFOHEADER.patch
> From 0294d37cd23f971376290be68dd681513740bb06 Mon Sep 17 00:00:00 2001
> From: Mats Peterson 
> Date: Fri, 19 Feb 2016 16:23:17 +0100
> Subject: [PATCH 2/3] lavf/avienc: Write palette after BITMAPINFOHEADER
> 
> ---
>  libavformat/avienc.c |   31 +++
>  1 file changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/avienc.c b/libavformat/avienc.c
> index 4e7bca4..3c357a2 100644
> --- a/libavformat/avienc.c
> +++ b/libavformat/avienc.c
> @@ -79,6 +79,8 @@ typedef struct AVIStream {
>  AVIIndex indexes;
>  } AVIStream;
>  
> +static int hdr_pal_done;

this must be in the context, AVIStream
non constant statics would break if there are 2 avi muxers


> +
>  static int avi_write_packet_internal(AVFormatContext *s, AVPacket *pkt);
>  
>  static inline AVIIentry *avi_get_ientry(const AVIIndex *idx, int ent_id)
> @@ -211,6 +213,9 @@ static int avi_write_header(AVFormatContext *s)
>  return AVERROR(ENOMEM);
>  }
>  
> +/* Palette after BITMAPINFOHEADER in strf chunk */
> +hdr_pal_done = 0;
> +
>  /* header list */
>  avi->riff_id = 0;
>  list1 = avi_start_new_riff(s, pb, "AVI ", "hdrl");
> @@ -359,6 +364,12 @@ static int avi_write_header(AVFormatContext *s)
>  && enc->pix_fmt == AV_PIX_FMT_RGB555LE
>  && enc->bits_per_coded_sample == 15)
>  enc->bits_per_coded_sample = 16;
> +/* Use private data for palette offset */
> +if (enc->bits_per_coded_sample <= 8) {
> +enc->priv_data = av_malloc(sizeof(int64_t));
> +if (!enc->priv_data)
> +return AVERROR(ENOMEM);
> +}
>  ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0);
>  pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi,
>enc->bits_per_coded_sample);
> @@ -673,16 +684,28 @@ static int avi_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  if (ret) {
>  if (ret == CONTAINS_PAL) {
>  int pc_tag, i;
> +int pal_size = 1 << enc->bits_per_coded_sample;
> +if (!hdr_pal_done) {
> +int64_t cur_offset = avio_tell(pb);
> +int64_t *pal_offset = (int64_t *)enc->priv_data;
> +avio_seek(pb, *pal_offset, SEEK_SET);
> +for (i = 0; i < pal_size; i++) {
> +uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
> +avio_wl32(pb, v & 0xff);
> +}
> +avio_seek(pb, cur_offset, SEEK_SET);
> +av_free(enc->priv_data);
> +hdr_pal_done++;
> +}
>  avi_stream2fourcc(tag, stream_index, enc->codec_type);
>  tag[2] = 'p'; tag[3] = 'c';
> -
>  pc_tag = ff_start_tag(pb, tag);
>  avio_w8(pb, 0);
>  avio_w8(pb, 0);
>  avio_wl16(pb, 0); // reserved
> -for (i = 0; i<256; i++) {
> +for (i = 0; i < pal_size; i++) {

this mismatches the stored size above


> -uint32_t v = AV_RL32(data + size - 1024 + 4*i);
> +uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);

> -avio_wb32(pb, v<<8);
> +avio_wl32(pb, v & 0xff);

it looked correct when i tested this before the patch

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- 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] lavf/md5enc: New streammd5 muxer

[Nicolas George]

Le primidi 1er ventôse, an CCXXIV, Remko Tronçon a écrit :
> Signed-off-by: Remko Tronçon 
> ---
> This patch introduces a new 'streammd5' muxer.
> Similarly to the 'md5' and 'framemd5' muxer, it is used to compute
> the hash of media. However, I needed something in between both, to
> be able to quickly see which streams are identical across different
> files.
> 
> I did not add any tests yet, because I was not sure if there was
> general interest in this patch.

Thanks for the patch.

I have no objection theoretically, but I am rather dubious about the
usefulness of that: you could mux the streams independently to the md5
muxer. Can you share your exact use case in more details?

Below comments about the code:

> 
>  Changelog|  1 +
>  doc/muxers.texi  | 40 --
>  libavformat/Makefile |  1 +
>  libavformat/allformats.c |  1 +
>  libavformat/md5enc.c | 87 
> 
>  libavformat/version.h|  4 +--
>  6 files changed, 130 insertions(+), 4 deletions(-)
> 
> diff --git a/Changelog b/Changelog
> index 7d672fb..42ee96a 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -6,6 +6,7 @@ version :
>  - fieldhint filter
>  - loop video filter and aloop audio filter
>  - Bob Weaver deinterlacing filter

> +- streammd5 format

Changing the name of existing muxers is annoying, but for new features I
would like much better if we did not wave around the name of a hash function
that has known vulnerabilities since 20 years: "streamhash" would be an
obvious choice.

>  
>  
>  version 3.0:
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index f2ad7fe..1521f37 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -207,7 +207,7 @@ To print the information to stdout, use the command:
>  ffmpeg -i INPUT -f framemd5 -
>  @end example
>  
> -See also the @ref{md5} muxer.
> +See also the @ref{md5} and @ref{streammd5} muxers.
>  
>  @anchor{gif}
>  @section gif
> @@ -641,7 +641,7 @@ You can print the MD5 to stdout with the command:
>  ffmpeg -i INPUT -f md5 -
>  @end example
>  
> -See also the @ref{framemd5} muxer.
> +See also the @ref{framemd5} and @ref{streammd5} muxers.
>  
>  @section mov, mp4, ismv
>  
> @@ -1307,6 +1307,42 @@ Specify whether to remove all fragments when finished. 
> Default 0 (do not remove)
>  
>  @end table
>  
> +@anchor{streammd5}
> +@section streammd5
> +

> +Per-stream MD5 testing format.
> +
> +This muxer computes and prints the MD5 hash for each stream.
> +By default audio streams are converted to signed
> +16-bit raw audio and video streams to raw video before computing the
> +hash.

This was copied more or less as is from existing documentation, but it is
misleading. First, these muxers can compute any supported hash function.
Second, there is no default conversion in these muxers, just codecs chosen
by default by the command line tool.

> +
> +The output of the muxer consists of a line for each stream of the form:
> +@example
> +@var{stream_index}, @var{MD5}
> +@end example
> +
> +@var{MD5} is a hexadecimal number representing the computed MD5 hash
> +for the packet.
> +
> +@subsection Examples
> +
> +For example to compute the MD5 of all the audio and video streams in
> +@file{INPUT}, converted to raw audio and video packets, and store it
> +in the file @file{out.md5}:
> +@example
> +ffmpeg -i INPUT -f streammd5 out.md5
> +@end example
> +
> +To compute the MD5 of all the streams in @file{INPUT} without any
> +conversion, and print it to stdout:
> +@example
> +ffmpeg -i INPUT -f streammd5 -codec copy -map 0 -
> +@end example
> +
> +See also the @ref{md5} and @ref{framemd5} muxers.
> +
> +
>  @section tee
>  
>  The tee muxer can be used to write the same data to several files or any
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 001b3f1..fde64dc 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -430,6 +430,7 @@ OBJS-$(CONFIG_SRT_DEMUXER)   += srtdec.o 
> subtitles.o
>  OBJS-$(CONFIG_SRT_MUXER) += srtenc.o
>  OBJS-$(CONFIG_STL_DEMUXER)   += stldec.o subtitles.o
>  OBJS-$(CONFIG_STR_DEMUXER)   += psxstr.o
> +OBJS-$(CONFIG_STREAMMD5_MUXER)   += md5enc.o
>  OBJS-$(CONFIG_SUBVIEWER1_DEMUXER)+= subviewer1dec.o subtitles.o
>  OBJS-$(CONFIG_SUBVIEWER_DEMUXER) += subviewerdec.o subtitles.o
>  OBJS-$(CONFIG_SUP_DEMUXER)   += supdec.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 02bb16a..df4c8eb 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -295,6 +295,7 @@ void av_register_all(void)
>  REGISTER_MUXDEMUX(SPDIF,spdif);
>  REGISTER_MUXDEMUX(SRT,  srt);
>  REGISTER_DEMUXER (STR,  str);
> +REGISTER_MUXER   (STREAMMD5,streammd5);
>  REGISTER_DEMUXER (STL,  stl);
>  REGISTER_DEMUXER (SUBVIEWER1,   subviewer1);
>  REGISTER_DEMUXER (SUBVIEWER

[FFmpeg-devel] [PATCH] mpegts: pcr period option for variable bitrate multiplexing

[Predrag Filipovic]

PCR insertion with specified period is functional when muxrate
is also specified (contant bitrate) as required by DVB and ATSC
(and other) specifications. Feature was non-functional for
variable bitrate (muxrate not specified). Insertion timing
is based on video frame keys and frame period (dts) thus, in
this patch (work in progress), pcr period precision is limited
to +/- one video frame period

Signed-off-by: Predrag Filipovic 
---
 libavformat/mpegtsenc.c | 80 +
 1 file changed, 61 insertions(+), 19 deletions(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 7656720..8600ba6 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -105,6 +105,7 @@ typedef struct MpegTSWrite {
 int tables_version;
 double pat_period;
 double sdt_period;
+int64_t last_pcr_ts;
 int64_t last_pat_ts;
 int64_t last_sdt_ts;
 
@@ -903,6 +904,9 @@ static int mpegts_init(AVFormatContext *s)
 ts_st = pcr_st->priv_data;
 
 if (ts->mux_rate > 1) {
+if (ts->pcr_period >= INT_MAX/2) {
+ts->pcr_period = PCR_RETRANS_TIME;
+}
 service->pcr_packet_period = (int64_t)ts->mux_rate * ts->pcr_period /
  (TS_PACKET_SIZE * 8 * 1000);
 ts->sdt_packet_period  = (int64_t)ts->mux_rate * SDT_RETRANS_TIME /
@@ -931,10 +935,19 @@ static int mpegts_init(AVFormatContext *s)
 service->pcr_packet_period =
 ts_st->user_tb.den / (10 * ts_st->user_tb.num);
 }
-if (!service->pcr_packet_period)
+/* if pcr_period specified, mark pcr_packet_period as NA (=INT_MAX) */
+if (ts->pcr_period < INT_MAX/2) {
+service->pcr_packet_period = INT_MAX;
+} else {
+if (!service->pcr_packet_period) {
 service->pcr_packet_period = 1;
+} else if (service->pcr_packet_period == INT_MAX) {
+service->pcr_packet_period--;
+}
+}
 }
 
+ts->last_pcr_ts = AV_NOPTS_VALUE;
 ts->last_pat_ts = AV_NOPTS_VALUE;
 ts->last_sdt_ts = AV_NOPTS_VALUE;
 // The user specified a period, use only it
@@ -1032,10 +1045,9 @@ static void mpegts_insert_null_packet(AVFormatContext *s)
 avio_write(s->pb, buf, TS_PACKET_SIZE);
 }
 
-/* Write a single transport stream packet with a PCR and no payload */
-static void mpegts_insert_pcr_only(AVFormatContext *s, AVStream *st)
+/* Write a single transport stream packet with a PCR (value in arg) and no 
payload */
+static void mpegts_insert_pcr_only(AVFormatContext *s, AVStream *st, int64_t 
pcr)
 {
-MpegTSWrite *ts = s->priv_data;
 MpegTSWriteStream *ts_st = st->priv_data;
 uint8_t *q;
 uint8_t buf[TS_PACKET_SIZE];
@@ -1050,7 +1062,7 @@ static void mpegts_insert_pcr_only(AVFormatContext *s, 
AVStream *st)
 *q++ = 0x10;   /* Adaptation flags: PCR present */
 
 /* PCR coded into 6 bytes */
-q += write_pcr_bits(q, get_pcr(ts, s->pb));
+q += write_pcr_bits(q, pcr);
 
 /* stuffing bytes */
 memset(q, 0xFF, TS_PACKET_SIZE - (q - buf));
@@ -1109,6 +1121,9 @@ static uint8_t *get_ts_payload_start(uint8_t *pkt)
  * number of TS packets. The final TS packet is padded using an oversized
  * adaptation header to exactly fill the last TS packet.
  * NOTE: 'payload' contains a complete PES payload. */
+/* PCR insertion for VBR TS is based on video frames time and key frames
+ * which leaves non-video TS with PCR insertion at key frames only.
+ * NOTE: PCR period "precision" for VBR TS is +/- one video frame period. */
 static void mpegts_write_pes(AVFormatContext *s, AVStream *st,
  const uint8_t *payload, int payload_size,
  int64_t pts, int64_t dts, int key)
@@ -1135,26 +1150,53 @@ static void mpegts_write_pes(AVFormatContext *s, 
AVStream *st,
 
 write_pcr = 0;
 if (ts_st->pid == ts_st->service->pcr_pid) {
-if (ts->mux_rate > 1 || is_start) // VBR pcr period is based on 
frames
-ts_st->service->pcr_packet_count++;
+if (ts->mux_rate > 1 || is_start) 
+if (ts_st->service->pcr_packet_period != INT_MAX) 
ts_st->service->pcr_packet_count++;
 if (ts_st->service->pcr_packet_count >=
-ts_st->service->pcr_packet_period) {
+ts_st->service->pcr_packet_period) { /* case is NA for VBR TS 
with specified pcr period*/
 ts_st->service->pcr_packet_count = 0;
-write_pcr = 1;
+if (ts_st->service->pcr_packet_period != INT_MAX) write_pcr = 
1; 
 }
 }
 
+if (ts->mux_rate > 1) {
+pcr = get_pcr(ts, s->pb);
+} else {
+pcr = (dts - delay) * 300;
+}
+if (pcr < 0) {
+av_log(s, AV_LOG_WARNING, "calculated pcr < 0, TS is invalid\n");
+pcr = 0; 
+}
+
 if (ts->mux_rate > 1 &

Re: [FFmpeg-devel] [PATCH] vp9: add superframe merging bitstream filter.

[Carl Eugen Hoyos]

Ronald S. Bultje  gmail.com> writes:

>  if (st->codec->codec_id == AV_CODEC_ID_AAC)
>  if (pkt->size > 2 && (AV_RB16(pkt->data) & 0xfff0) == 0xfff0)
>  ret = ff_stream_add_bitstream_filter(st, "aac_adtstoasc", NULL);
> +else if (st->codec->codec_id == AV_CODEC_ID_VP9)
> +ret = ff_stream_add_bitstream_filter(st, "vp9_superframe", NULL);

Even if this is correct - I doubt it but what do I know - 
please add as many braces as possible.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 3/3] lavf/avidec: Fix endianness when reading the palette from 'xxpc' chunks

[Mats Peterson]

On 02/19/2016 04:36 PM, Mats Peterson wrote:




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



Forget this patch set, by the way. I should have checked with FATE 
first. I get numerous FATE errors. Sorry.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vp9: add superframe merging bitstream filter.

[Ronald S. Bultje]

Fixes ticket 4313.

There is still an issue after this patch: it works when you use -bsf
vp9_superframe, but if you let the auto-bsf system work on its own,
ffmpeg.c triggers these warnings:

[ivf @ 0x7fc97a02fc00] Non-monotonous DTS in output stream 0:0;
previous: 900, current: 900; changing to 901. This may result in
incorrect timestamps in the output file.

This warning code lives in ffmpeg.c and I'm not entirely sure how to
prevent this from running. Suggestions welcome.
---
 ffmpeg.c|   2 +
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/vp9_superframe_bsf.c | 189 
 libavformat/ivfenc.c|  13 +++
 libavformat/matroskaenc.c   |   2 +
 libavformat/mux.c   |   2 +
 libavformat/utils.c |   5 ++
 8 files changed, 215 insertions(+)
 create mode 100644 libavcodec/vp9_superframe_bsf.c

diff --git a/ffmpeg.c b/ffmpeg.c
index a5ec3c3..bb7f138 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -694,6 +694,8 @@ static void write_frame(AVFormatContext *s, AVPacket *pkt, 
OutputStream *ost)
 if (exit_on_error)
 exit_program(1);
 }
+if (pkt->size == 0)
+return;
 
 if (!(s->oformat->flags & AVFMT_NOTIMESTAMPS)) {
 if (pkt->dts != AV_NOPTS_VALUE &&
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index f6a4fbb..041684d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -916,6 +916,7 @@ OBJS-$(CONFIG_MP3_HEADER_DECOMPRESS_BSF)  += 
mp3_header_decompress_bsf.o \
 OBJS-$(CONFIG_NOISE_BSF)  += noise_bsf.o
 OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF)   += remove_extradata_bsf.o
 OBJS-$(CONFIG_TEXT2MOVSUB_BSF)+= movsub_bsf.o
+OBJS-$(CONFIG_VP9_SUPERFRAME_BSF) += vp9_superframe_bsf.o
 
 # thread libraries
 OBJS-$(HAVE_LIBC_MSVCRT)   += file_open.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 2097db0..96f5c5c 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -666,4 +666,5 @@ void avcodec_register_all(void)
 REGISTER_BSF(NOISE, noise);
 REGISTER_BSF(REMOVE_EXTRADATA,  remove_extradata);
 REGISTER_BSF(TEXT2MOVSUB,   text2movsub);
+REGISTER_BSF(VP9_SUPERFRAME,vp9_superframe);
 }
diff --git a/libavcodec/vp9_superframe_bsf.c b/libavcodec/vp9_superframe_bsf.c
new file mode 100644
index 000..f991a80
--- /dev/null
+++ b/libavcodec/vp9_superframe_bsf.c
@@ -0,0 +1,189 @@
+/*
+ * Vp9 invisible (alt-ref) frame to superframe merge bitstream filter
+ * Copyright (c) 2016 Ronald S. Bultje 
+ *
+ * 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
+ */
+
+#include "libavutil/avassert.h"
+#include "avcodec.h"
+#include "get_bits.h"
+
+#define MAX_CACHE 8
+typedef struct VP9BSFContext {
+int n_cache;
+struct CachedBuf {
+uint8_t *data;
+int size;
+} cache[MAX_CACHE];
+} VP9BSFContext;
+
+static void stats(const struct CachedBuf *in, int n_in,
+  unsigned *_max, unsigned *_sum)
+{
+int n;
+unsigned max = 0, sum = 0;
+
+for (n = 0; n < n_in; n++) {
+unsigned sz = in[n].size;
+
+if (sz > max)
+max = sz;
+sum += sz;
+}
+
+*_max = max;
+*_sum = sum;
+}
+
+static int merge_superframe(const struct CachedBuf *in, int n_in,
+uint8_t **poutbuf, int *poutbuf_size)
+{
+unsigned max, sum, mag, marker, n, sz;
+uint8_t *ptr;
+
+stats(in, n_in, &max, &sum);
+mag = av_log2(max) >> 3;
+marker = 0xC0 + (mag << 3) + (n_in - 1);
+sz = *poutbuf_size = sum + 2 + (mag + 1) * n_in;
+ptr = *poutbuf = av_malloc(sz);
+if (!ptr)
+return AVERROR(ENOMEM);
+
+for (n = 0; n < n_in; n++) {
+memcpy(ptr, in[n].data, in[n].size);
+ptr += in[n].size;
+}
+
+#define wloop(mag, wr) \
+for (n = 0; n < n_in; n++) { \
+wr; \
+ptr += mag + 1; \
+}
+
+// write superframe with marker 110[mag:2][nframes:3]
+*ptr++ = marker;
+switch (mag) {
+case 0:
+wloop(mag, *ptr = in[n].size);
+break;
+case 1:
+wloop(mag, AV_WB16(ptr, in[n].size));
+break;
+case 2:
+wloop(mag, AV_WB24(p

Re: [FFmpeg-devel] [PATCH 3/3] lavf/avidec: Fix endianness when reading the palette from 'xxpc' chunks

[Mats Peterson]

On 02/19/2016 04:35 PM, Mats Peterson wrote:




Forget this one. Forgot to attach the patch...

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vc2enc: add support for Haar wavelet transforms

[Rostislav Pehlivanov]

This commit adds support for the (simple, allowed in the spec, but
inferior in quality) Haar wavelet transforms.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/vc2enc.c |  6 --
 libavcodec/vc2enc_dwt.c | 46 ++
 2 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 0ca2195..c119322 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -1153,8 +1153,10 @@ static const AVOption vc2enc_options[] = {
 {"slice_height",  "Slice height", offsetof(VC2EncContext, slice_height), 
AV_OPT_TYPE_INT, {.i64 = 64}, 8, 1024, VC2ENC_FLAGS, "slice_height"},
 {"wavelet_depth", "Transform depth", offsetof(VC2EncContext, 
wavelet_depth), AV_OPT_TYPE_INT, {.i64 = 5}, 1, 5, VC2ENC_FLAGS, 
"wavelet_depth"},
 {"wavelet_type",  "Transform type",  offsetof(VC2EncContext, wavelet_idx), 
AV_OPT_TYPE_INT, {.i64 = VC2_TRANSFORM_9_7}, 0, VC2_TRANSFORMS_NB, 
VC2ENC_FLAGS, "wavelet_idx"},
-{"9_7",   "Deslauriers-Dubuc (9,7)", 0, AV_OPT_TYPE_CONST, {.i64 = 
VC2_TRANSFORM_9_7}, INT_MIN, INT_MAX, VC2ENC_FLAGS, "wavelet_idx"},
-{"5_3",   "LeGall (5,3)",0, AV_OPT_TYPE_CONST, {.i64 = 
VC2_TRANSFORM_5_3}, INT_MIN, INT_MAX, VC2ENC_FLAGS, "wavelet_idx"},
+{"9_7",  "Deslauriers-Dubuc (9,7)", 0, AV_OPT_TYPE_CONST, 
{.i64 = VC2_TRANSFORM_9_7},INT_MIN, INT_MAX, VC2ENC_FLAGS, "wavelet_idx"},
+{"5_3",  "LeGall (5,3)",0, AV_OPT_TYPE_CONST, 
{.i64 = VC2_TRANSFORM_5_3},INT_MIN, INT_MAX, VC2ENC_FLAGS, "wavelet_idx"},
+{"haar", "Haar (with shift)",   0, AV_OPT_TYPE_CONST, 
{.i64 = VC2_TRANSFORM_HAAR_S}, INT_MIN, INT_MAX, VC2ENC_FLAGS, "wavelet_idx"},
+{"haar_noshift", "Haar (without shift)",0, AV_OPT_TYPE_CONST, 
{.i64 = VC2_TRANSFORM_HAAR},   INT_MIN, INT_MAX, VC2ENC_FLAGS, "wavelet_idx"},
 {"qm", "Custom quantization matrix", offsetof(VC2EncContext, 
quant_matrix), AV_OPT_TYPE_INT, {.i64 = VC2_QM_DEF}, 0, VC2_QM_NB, 
VC2ENC_FLAGS, "quant_matrix"},
 {"default",   "Default from the specifications", 0, AV_OPT_TYPE_CONST, 
{.i64 = VC2_QM_DEF}, INT_MIN, INT_MAX, VC2ENC_FLAGS, "quant_matrix"},
 {"color", "Prevents low bitrate discoloration", 0, 
AV_OPT_TYPE_CONST, {.i64 = VC2_QM_COL}, INT_MIN, INT_MAX, VC2ENC_FLAGS, 
"quant_matrix"},
diff --git a/libavcodec/vc2enc_dwt.c b/libavcodec/vc2enc_dwt.c
index eb34168..c60b003 100644
--- a/libavcodec/vc2enc_dwt.c
+++ b/libavcodec/vc2enc_dwt.c
@@ -211,10 +211,56 @@ static void vc2_subband_dwt_53(VC2TransformContext *t, 
dwtcoef *data,
 deinterleave(data, stride, width, height, synth);
 }
 
+static av_always_inline void dwt_haar(VC2TransformContext *t, dwtcoef *data,
+  ptrdiff_t stride, int width, int height,
+  const int s)
+{
+int x, y;
+dwtcoef *synth = t->buffer, *synthl = synth, *datal = data;
+const ptrdiff_t synth_width  = width  << 1;
+const ptrdiff_t synth_height = height << 1;
+
+/* Horizontal synthesis. */
+for (y = 0; y < synth_height; y++) {
+for (x = 0; x < synth_width; x += 2) {
+synthl[y*synth_width + x + 1] = (datal[y*stride + x + 1] << s) -
+(datal[y*stride + x] << s);
+synthl[y*synth_width + x] = (datal[y*stride + x + 0] << s) +
+((synthl[y*synth_width + x + 1] + 1) 
>> 1);
+}
+}
+
+/* Vertical synthesis. */
+for (x = 0; x < synth_width; x++) {
+for (y = 0; y < synth_height; y += 2) {
+synthl[(y + 1)*synth_width + x] = synthl[(y + 1)*synth_width + x] -
+  synthl[y*synth_width + x];
+synthl[y*synth_width + x] = synthl[y*synth_width + x] +
+((synthl[(y + 1)*synth_width + x] + 1) 
>> 1);
+}
+}
+
+deinterleave(data, stride, width, height, synth);
+}
+
+static void vc2_subband_dwt_haar(VC2TransformContext *t, dwtcoef *data,
+ ptrdiff_t stride, int width, int height)
+{
+dwt_haar(t, data, stride, width, height, 0);
+}
+
+static void vc2_subband_dwt_haar_shift(VC2TransformContext *t, dwtcoef *data,
+   ptrdiff_t stride, int width, int height)
+{
+dwt_haar(t, data, stride, width, height, 1);
+}
+
 av_cold int ff_vc2enc_init_transforms(VC2TransformContext *s, int p_width, int 
p_height)
 {
 s->vc2_subband_dwt[VC2_TRANSFORM_9_7]= vc2_subband_dwt_97;
 s->vc2_subband_dwt[VC2_TRANSFORM_5_3]= vc2_subband_dwt_53;
+s->vc2_subband_dwt[VC2_TRANSFORM_HAAR]   = vc2_subband_dwt_haar;
+s->vc2_subband_dwt[VC2_TRANSFORM_HAAR_S] = vc2_subband_dwt_haar_shift;
 
 s->buffer = av_malloc(2*p_width*p_height*sizeof(dwtcoef));
 if (!s->buffer)
-- 
2.7.0

__

[FFmpeg-devel] [PATCH 3/3] lavf/avidec: Fix endianness when reading the palette from 'xxpc' chunks

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 13d7105fc299cae346340cf696844023c1888036 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 19 Feb 2016 16:24:05 +0100
Subject: [PATCH 3/3] lavf/avidec: Fix endianness when reading the palette from 'xxpc' chunks

---
 libavformat/avidec.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index 3859810..1f4a4d4 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -1266,7 +1266,7 @@ start_sync:
 
 // b + (g << 8) + (r << 16);
 for (; k <= last; k++)
-ast->pal[k] = 0xFFU<<24 | avio_rb32(pb)>>8;
+ast->pal[k] = 0xFFU<<24 | avio_rl32(pb);
 
 ast->has_pal = 1;
 goto start_sync;
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH 3/3] lavf/avidec: Fix endianness when reading the palette from 'xxpc' chunks

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/3] lavf/avienc: Write palette after BITMAPINFOHEADER

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 0294d37cd23f971376290be68dd681513740bb06 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 19 Feb 2016 16:23:17 +0100
Subject: [PATCH 2/3] lavf/avienc: Write palette after BITMAPINFOHEADER

---
 libavformat/avienc.c |   31 +++
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index 4e7bca4..3c357a2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -79,6 +79,8 @@ typedef struct AVIStream {
 AVIIndex indexes;
 } AVIStream;
 
+static int hdr_pal_done;
+
 static int avi_write_packet_internal(AVFormatContext *s, AVPacket *pkt);
 
 static inline AVIIentry *avi_get_ientry(const AVIIndex *idx, int ent_id)
@@ -211,6 +213,9 @@ static int avi_write_header(AVFormatContext *s)
 return AVERROR(ENOMEM);
 }
 
+/* Palette after BITMAPINFOHEADER in strf chunk */
+hdr_pal_done = 0;
+
 /* header list */
 avi->riff_id = 0;
 list1 = avi_start_new_riff(s, pb, "AVI ", "hdrl");
@@ -359,6 +364,12 @@ static int avi_write_header(AVFormatContext *s)
 && enc->pix_fmt == AV_PIX_FMT_RGB555LE
 && enc->bits_per_coded_sample == 15)
 enc->bits_per_coded_sample = 16;
+/* Use private data for palette offset */
+if (enc->bits_per_coded_sample <= 8) {
+enc->priv_data = av_malloc(sizeof(int64_t));
+if (!enc->priv_data)
+return AVERROR(ENOMEM);
+}
 ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0);
 pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi,
   enc->bits_per_coded_sample);
@@ -673,16 +684,28 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 if (ret) {
 if (ret == CONTAINS_PAL) {
 int pc_tag, i;
+int pal_size = 1 << enc->bits_per_coded_sample;
+if (!hdr_pal_done) {
+int64_t cur_offset = avio_tell(pb);
+int64_t *pal_offset = (int64_t *)enc->priv_data;
+avio_seek(pb, *pal_offset, SEEK_SET);
+for (i = 0; i < pal_size; i++) {
+uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+avio_wl32(pb, v & 0xff);
+}
+avio_seek(pb, cur_offset, SEEK_SET);
+av_free(enc->priv_data);
+hdr_pal_done++;
+}
 avi_stream2fourcc(tag, stream_index, enc->codec_type);
 tag[2] = 'p'; tag[3] = 'c';
-
 pc_tag = ff_start_tag(pb, tag);
 avio_w8(pb, 0);
 avio_w8(pb, 0);
 avio_wl16(pb, 0); // reserved
-for (i = 0; i<256; i++) {
-uint32_t v = AV_RL32(data + size - 1024 + 4*i);
-avio_wb32(pb, v<<8);
+for (i = 0; i < pal_size; i++) {
+uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+avio_wl32(pb, v & 0xff);
 }
 ff_end_tag(pb, pc_tag);
 }
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH 1/3] lavf/riffenc: Write space for palette

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 45624f6249703657bed9788bf1232289ee392f10 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 19 Feb 2016 16:22:35 +0100
Subject: [PATCH 1/3] lavf/riffenc: Write space for palette

---
 libavformat/riffenc.c |   23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index ceb27f2..2d12f13 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -210,6 +210,9 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
   !memcmp(enc->extradata + enc->extradata_size - 9, "BottomUp", 9);
 int extradata_size = enc->extradata_size - 9*keep_height;
 
+if (!enc->extradata_size && enc->bits_per_coded_sample <= 8)
+extradata_size = 4 * (1 << enc->bits_per_coded_sample);
+
 /* size */
 avio_wl32(pb, 40 + (ignore_extradata ? 0 :extradata_size));
 avio_wl32(pb, enc->width);
@@ -228,10 +231,22 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
 avio_wl32(pb, 0);
 
 if (!ignore_extradata) {
-avio_write(pb, enc->extradata, extradata_size);
-
-if (!for_asf && extradata_size & 1)
-avio_w8(pb, 0);
+if (enc->extradata_size) {
+avio_write(pb, enc->extradata, extradata_size);
+if (!for_asf && extradata_size & 1)
+avio_w8(pb, 0);
+} else if (enc->bits_per_coded_sample <= 8) {
+int i;
+int64_t *pal_offset = (int64_t *)enc->priv_data;
+*pal_offset = avio_tell(pb);
+for (i = 0; i < 1 << enc->bits_per_coded_sample; i++) {
+/* Initialize 1 bpp palette to black & white */
+if (!i && enc->bits_per_coded_sample == 1)
+avio_wl32(pb, 0xff);
+else
+avio_wl32(pb, 0);
+}
+}
 }
 }
 
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] avformat/avienc: Store pal8 palette

[Michael Niedermayer]

On Fri, Feb 19, 2016 at 02:15:01PM +0100, Mats Peterson wrote:
> On 02/19/2016 02:08 PM, Mats Peterson wrote:
> >On 02/19/2016 02:05 PM, Mats Peterson wrote:
> >>On 02/18/2016 11:07 PM, Mats Peterson wrote:
> >>>On 02/18/2016 11:04 PM, Michael Niedermayer wrote:
> On Thu, Feb 18, 2016 at 10:40:42PM +0100, Mats Peterson wrote:
> >On 02/18/2016 10:27 PM, Mats Peterson wrote:
> >>On 02/18/2016 09:14 PM, Michael Niedermayer wrote:
> >>>This can be made more efficient, but first and the main goal of this
> >>>change is to
> >>>store it at all
> >>Great, Michael. I'll try it out.
> >>
> >>Mats
> >>
> >
> >I notice that the palette inclusion is only made by using 'xxpc'
> >chunks in the video data so far. I'm not so sure if these in-data
> >palette changing chunks are widely supported. Therefore, first and
> >foremost, and the most widely supported way in my book, is to add an
> >"initial" palette after the BITMAPINFOHEADER in the strf chunk.
> >That's where I found it to be a bit tricky, but I'm sure you can
> >solve it in some way.
> 
> its quite easy to implement if you want to try
> just leave some space where the palette should go whe writing the
> headers and keep track of the location, then when the first
> packet comes in take its palette and store it there
> 
> >>>
> >>>I could try, yes. But not tonight, I'm a bit tired :) I'll look into it,
> >>>perhaps I can make it.
> >>>
> >>>Mats
> >>
> >>
> >>Will you apply your latest xxpc writing patches to the repository,
> >>Michael? I noticed you haven't done it yet.
> >>
> >>Mats
> >
> >The stuff with CONTAINS_PAL etc.
> >
> 
> I forgot that I had added them before starting to work on this. It
> would be nice if you could apply them "officially" before I
> continue, since they work well.

applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


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/avienc: Store pal8 palette

[Mats Peterson]

On 02/19/2016 03:46 PM, Michael Niedermayer wrote:


applied

thanks



Great, Michael. Thanks.

Mats

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

Re: [FFmpeg-devel] [PATCH] avformat/avienc: Store pal8 palette

[Michael Niedermayer]

On Thu, Feb 18, 2016 at 10:39:38PM +0100, Moritz Barsnick wrote:
> On Thu, Feb 18, 2016 at 21:14:55 +0100, Michael Niedermayer wrote:
> > + * no zerp if a new packet was allocated and ppkt has to be freed
> 
> "no zerp"? Cute. Probably "non-zero"

fixed
thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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/avienc: Store pal8 palette

[Mats Peterson]

On 02/19/2016 02:15 PM, Mats Peterson wrote:

On 02/19/2016 02:08 PM, Mats Peterson wrote:

On 02/19/2016 02:05 PM, Mats Peterson wrote:

On 02/18/2016 11:07 PM, Mats Peterson wrote:

On 02/18/2016 11:04 PM, Michael Niedermayer wrote:

On Thu, Feb 18, 2016 at 10:40:42PM +0100, Mats Peterson wrote:

On 02/18/2016 10:27 PM, Mats Peterson wrote:

On 02/18/2016 09:14 PM, Michael Niedermayer wrote:

This can be made more efficient, but first and the main goal of
this
change is to
store it at all

Great, Michael. I'll try it out.

Mats



I notice that the palette inclusion is only made by using 'xxpc'
chunks in the video data so far. I'm not so sure if these in-data
palette changing chunks are widely supported. Therefore, first and
foremost, and the most widely supported way in my book, is to add an
"initial" palette after the BITMAPINFOHEADER in the strf chunk.
That's where I found it to be a bit tricky, but I'm sure you can
solve it in some way.


its quite easy to implement if you want to try
just leave some space where the palette should go whe writing the
headers and keep track of the location, then when the first
packet comes in take its palette and store it there



I could try, yes. But not tonight, I'm a bit tired :) I'll look into
it,
perhaps I can make it.

Mats



Will you apply your latest xxpc writing patches to the repository,
Michael? I noticed you haven't done it yet.

Mats


The stuff with CONTAINS_PAL etc.



I forgot that I had added them before starting to work on this. It would
be nice if you could apply them "officially" before I continue, since
they work well.

Mats



Fairly well, that is. The palette is incorrectly written to the file in 
big endian RGB order, but it should be in little endian BGR order. But 
I'll fix that myself.


Mats

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

Re: [FFmpeg-devel] [PATCH] avformat/avienc: Store pal8 palette

[Mats Peterson]

On 02/19/2016 02:08 PM, Mats Peterson wrote:

On 02/19/2016 02:05 PM, Mats Peterson wrote:

On 02/18/2016 11:07 PM, Mats Peterson wrote:

On 02/18/2016 11:04 PM, Michael Niedermayer wrote:

On Thu, Feb 18, 2016 at 10:40:42PM +0100, Mats Peterson wrote:

On 02/18/2016 10:27 PM, Mats Peterson wrote:

On 02/18/2016 09:14 PM, Michael Niedermayer wrote:

This can be made more efficient, but first and the main goal of this
change is to
store it at all

Great, Michael. I'll try it out.

Mats



I notice that the palette inclusion is only made by using 'xxpc'
chunks in the video data so far. I'm not so sure if these in-data
palette changing chunks are widely supported. Therefore, first and
foremost, and the most widely supported way in my book, is to add an
"initial" palette after the BITMAPINFOHEADER in the strf chunk.
That's where I found it to be a bit tricky, but I'm sure you can
solve it in some way.


its quite easy to implement if you want to try
just leave some space where the palette should go whe writing the
headers and keep track of the location, then when the first
packet comes in take its palette and store it there



I could try, yes. But not tonight, I'm a bit tired :) I'll look into it,
perhaps I can make it.

Mats



Will you apply your latest xxpc writing patches to the repository,
Michael? I noticed you haven't done it yet.

Mats


The stuff with CONTAINS_PAL etc.



I forgot that I had added them before starting to work on this. It would 
be nice if you could apply them "officially" before I continue, since 
they work well.


Mats

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

Re: [FFmpeg-devel] [PATCH] avformat/avienc: Store pal8 palette

[Mats Peterson]

On 02/19/2016 02:05 PM, Mats Peterson wrote:

On 02/18/2016 11:07 PM, Mats Peterson wrote:

On 02/18/2016 11:04 PM, Michael Niedermayer wrote:

On Thu, Feb 18, 2016 at 10:40:42PM +0100, Mats Peterson wrote:

On 02/18/2016 10:27 PM, Mats Peterson wrote:

On 02/18/2016 09:14 PM, Michael Niedermayer wrote:

This can be made more efficient, but first and the main goal of this
change is to
store it at all

Great, Michael. I'll try it out.

Mats



I notice that the palette inclusion is only made by using 'xxpc'
chunks in the video data so far. I'm not so sure if these in-data
palette changing chunks are widely supported. Therefore, first and
foremost, and the most widely supported way in my book, is to add an
"initial" palette after the BITMAPINFOHEADER in the strf chunk.
That's where I found it to be a bit tricky, but I'm sure you can
solve it in some way.


its quite easy to implement if you want to try
just leave some space where the palette should go whe writing the
headers and keep track of the location, then when the first
packet comes in take its palette and store it there



I could try, yes. But not tonight, I'm a bit tired :) I'll look into it,
perhaps I can make it.

Mats



Will you apply your latest xxpc writing patches to the repository,
Michael? I noticed you haven't done it yet.

Mats


The stuff with CONTAINS_PAL etc.

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

Re: [FFmpeg-devel] [PATCH] avformat/avienc: Store pal8 palette

[Mats Peterson]

On 02/18/2016 11:07 PM, Mats Peterson wrote:

On 02/18/2016 11:04 PM, Michael Niedermayer wrote:

On Thu, Feb 18, 2016 at 10:40:42PM +0100, Mats Peterson wrote:

On 02/18/2016 10:27 PM, Mats Peterson wrote:

On 02/18/2016 09:14 PM, Michael Niedermayer wrote:

This can be made more efficient, but first and the main goal of this
change is to
store it at all

Great, Michael. I'll try it out.

Mats



I notice that the palette inclusion is only made by using 'xxpc'
chunks in the video data so far. I'm not so sure if these in-data
palette changing chunks are widely supported. Therefore, first and
foremost, and the most widely supported way in my book, is to add an
"initial" palette after the BITMAPINFOHEADER in the strf chunk.
That's where I found it to be a bit tricky, but I'm sure you can
solve it in some way.


its quite easy to implement if you want to try
just leave some space where the palette should go whe writing the
headers and keep track of the location, then when the first
packet comes in take its palette and store it there



I could try, yes. But not tonight, I'm a bit tired :) I'll look into it,
perhaps I can make it.

Mats



Will you apply your latest xxpc writing patches to the repository, 
Michael? I noticed you haven't done it yet.


Mats

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

Re: [FFmpeg-devel] Fwd: Fwd: libavformat/segment : add option to increment timecode

[Martin Vignali]

2016-02-15 2:35 GMT+01:00 Stefano Sabatini :

> On date Sunday 2016-02-14 15:41:05 +0100, Martin Vignali encoded:
> [...]
> > Hello,
> >
> > New patch attach, i move variable declaration at the top (for
> > AVDictionnaryEntry too).
> > I also remove the return err, in case of an error occured in the
> > av_timecode_init_from_string function.
> > Instead i put an AV Log Warning, and the timecode is not modified.
> >
> > Best regards
> >
> > Martin
>
> > From 5e162acdc9ec4602c3263796c07ca4226b314e14 Mon Sep 17 00:00:00 2001
> > From: Martin Vignali 
> > Date: Sun, 14 Feb 2016 15:32:27 +0100
> > Subject: [PATCH] lavf/segment: add increment timecode option
> >
> > for example you can split a file, keeping a continuous timecode between
> > each segment :
> >
> > ffmpeg -i src.mov -timecode 10:00:00:00 -vcodec copy -f segment \
> > -segment_time 2 -reset_timestamps 1 -increment_tc 1 target_%03d.mov
> > ---
> >  doc/muxers.texi   |  7 +++
> >  libavformat/segment.c | 31 +++
> >  2 files changed, 38 insertions(+)
> >
> > diff --git a/doc/muxers.texi b/doc/muxers.texi
> > index 2e6bb4c..21f3525 100644
> > --- a/doc/muxers.texi
> > +++ b/doc/muxers.texi
> > @@ -1017,6 +1017,13 @@ implementation for HLS segmentation.
> >  The segment muxer supports the following options:
> >
> >  @table @option
> > +
> > +@item increment_tc @var{1|0}
> > +if set to @code{1}, increment timecode between each segment
> > +If this is selected, the input need to have
> > +a timecode in the first video stream. Default value is
> > +@code{0}.
> > +
> >  @item reference_stream @var{specifier}
> >  Set the reference stream, as specified by the string @var{specifier}.
> >  If @var{specifier} is set to @code{auto}, the reference is chosen
> > diff --git a/libavformat/segment.c b/libavformat/segment.c
> > index dd3b092..00680b3 100644
> > --- a/libavformat/segment.c
> > +++ b/libavformat/segment.c
> > @@ -41,6 +41,7 @@
> >  #include "libavutil/parseutils.h"
> >  #include "libavutil/mathematics.h"
> >  #include "libavutil/time.h"
> > +#include "libavutil/timecode.h"
> >  #include "libavutil/time_internal.h"
> >  #include "libavutil/timestamp.h"
> >
> > @@ -95,6 +96,7 @@ typedef struct SegmentContext {
> >  char *time_str;///< segment duration specification string
> >  int64_t time;  ///< segment duration
> >  int use_strftime;  ///< flag to expand filename with strftime
> > +int increment_tc;  ///< flag to increment timecode if found
> >
> >  char *times_str;   ///< segment times specification string
> >  int64_t *times;///< list of segment interval specification
> > @@ -227,6 +229,34 @@ static int segment_start(AVFormatContext *s, int
> write_header)
> >  SegmentContext *seg = s->priv_data;
> >  AVFormatContext *oc = seg->avf;
> >  int err = 0;
> > +AVTimecode tc;
> > +AVRational rate;
> > +AVDictionaryEntry *tcr;
> > +char buf[AV_TIMECODE_STR_SIZE];
> > +int i;
> > +
> > +if (seg->increment_tc) {
> > +tcr = av_dict_get(s->metadata, "timecode", NULL, 0);
> > +if (tcr) {
> > +/* search the first video stream */
> > +for (i = 0; i < s->nb_streams; i++) {
> > +if (s->streams[i]->codec->codec_type ==
> AVMEDIA_TYPE_VIDEO) {
> > +rate = s->streams[i]->avg_frame_rate;/* Get fps
> from the video stream */
>
>
> > +err = av_timecode_init_from_string(&tc, rate,
> tcr->value, s);
> > +if (err < 0) {
> > +av_log(s, AV_LOG_WARNING, "Could not increment
> timecode, error occured during timecode creation.");
> > +break;
> > +}
>
> > +tc.start += (int)
> av_q2d(av_mul_q(av_make_q(seg->time, 100 ), rate));/* increment
> timecode */
>
> nit: 100_) => 100)
>
> Also, reading from the timecode.c code it looks like the increment
> must be expressed in fps units.
>

Sorry don't understand what's wrong now. In my tests, the timecode
incrementation is correct (but maybe i missed a special case)


>
> Finally, you are using the segment->time, which is different from the
> effective segment duration. Could you set the metadata in segment_end,
> where the exact duration is known?
>

Do you know how can i get the exact segment duration ?


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

Re: [FFmpeg-devel] [PATCH] Fixed issue #43 JACK indev support on OSX

[Michael Niedermayer]

On Thu, Feb 18, 2016 at 11:58:25PM +, Josh de Kock wrote:
> ---
>  configure  | 14 +++---
>  libavdevice/jack.c | 12 
>  2 files changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/configure b/configure
> index 287896f..f2f7c3d 100755
> --- a/configure
> +++ b/configure
> @@ -1732,6 +1732,7 @@ BUILTIN_LIST="
>  mm_empty
>  rdtsc
>  sarestart
> +sem_timedwait
>  sync_val_compare_and_swap
>  "
>  HAVE_LIST_CMDLINE="
> @@ -1758,6 +1759,7 @@ HEADERS_LIST="
>  dev_ic_bt8xx_h
>  dev_video_bktr_ioctl_bt848_h
>  dev_video_meteor_ioctl_meteor_h
> +dispatch_dispatch_h
>  direct_h
>  dirent_h
>  dlfcn_h
> @@ -2757,7 +2759,7 @@ gdigrab_indev_deps="CreateDIBSection"
>  gdigrab_indev_extralibs="-lgdi32"
>  gdigrab_indev_select="bmp_decoder"
>  iec61883_indev_deps="libiec61883"
> -jack_indev_deps="jack_jack_h sem_timedwait"
> +jack_indev_deps="jack_jack_h"
>  lavfi_indev_deps="avfilter"
>  libcdio_indev_deps="libcdio"
>  libdc1394_indev_deps="libdc1394"
> @@ -5303,6 +5305,7 @@ check_func  mprotect
>  check_func_headers time.h nanosleep || { check_func_headers time.h nanosleep 
> -lrt && add_extralibs -lrt && LIBRT="-lrt"; }
>  check_func  sched_getaffinity
>  check_func  setrlimit
> +check_func  sem_timedwait
>  check_struct "sys/stat.h" "struct stat" st_mtim.tv_nsec -D_BSD_SOURCE
>  check_func  strerror_r
>  check_func  sysconf
> @@ -5330,6 +5333,7 @@ check_func_headers glob.h glob
>  enabled xlib &&
>  check_func_headers "X11/Xlib.h X11/extensions/Xvlib.h" 
> XvGetPortAttribute -lXv -lX11 -lXext
>  
> +check_header dispatch/dispatch.h
>  check_header direct.h
>  check_header dirent.h
>  check_header dlfcn.h
> @@ -5702,8 +5706,12 @@ check_header soundcard.h
>  enabled_any alsa_indev alsa_outdev &&
>  check_lib2 alsa/asoundlib.h snd_pcm_htimestamp -lasound
>  
> -enabled jack_indev && check_lib2 jack/jack.h jack_client_open -ljack && 
> check_func sem_timedwait &&
> -check_func jack_port_get_latency_range -ljack
> +if enabled jack_indev; then
> +{ check_lib2 jack/jack.h jack_client_open -ljack &&
> +  check_func jack_port_get_latency_range -ljack &&
> +  enabled_any sem_timedwait dispatch_dispatch_h; } || 
> +disable jack_indev
> +fi

this causes jack to be disabled on ubuntu LTS 12.04

grep -i jack config.h
#define HAVE_JACK_PORT_GET_LATENCY_RANGE 1
#define CONFIG_JACK_INDEV 0

previously:
grep -i jack config.h
#define HAVE_JACK_PORT_GET_LATENCY_RANGE 1
#define CONFIG_JACK_INDEV 1


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

For every action, there is an equal and opposite reaction. -- Newton
For every man jailed for a minor crime, theres one person more that
will hate the government, some of them will become terrorists.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/md5enc: New streammd5 muxer

[Remko Tronçon]

Signed-off-by: Remko Tronçon 
---
This patch introduces a new 'streammd5' muxer.
Similarly to the 'md5' and 'framemd5' muxer, it is used to compute
the hash of media. However, I needed something in between both, to
be able to quickly see which streams are identical across different
files.

I did not add any tests yet, because I was not sure if there was
general interest in this patch.

 Changelog|  1 +
 doc/muxers.texi  | 40 --
 libavformat/Makefile |  1 +
 libavformat/allformats.c |  1 +
 libavformat/md5enc.c | 87 
 libavformat/version.h|  4 +--
 6 files changed, 130 insertions(+), 4 deletions(-)

diff --git a/Changelog b/Changelog
index 7d672fb..42ee96a 100644
--- a/Changelog
+++ b/Changelog
@@ -6,6 +6,7 @@ version :
 - fieldhint filter
 - loop video filter and aloop audio filter
 - Bob Weaver deinterlacing filter
+- streammd5 format
 
 
 version 3.0:
diff --git a/doc/muxers.texi b/doc/muxers.texi
index f2ad7fe..1521f37 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -207,7 +207,7 @@ To print the information to stdout, use the command:
 ffmpeg -i INPUT -f framemd5 -
 @end example
 
-See also the @ref{md5} muxer.
+See also the @ref{md5} and @ref{streammd5} muxers.
 
 @anchor{gif}
 @section gif
@@ -641,7 +641,7 @@ You can print the MD5 to stdout with the command:
 ffmpeg -i INPUT -f md5 -
 @end example
 
-See also the @ref{framemd5} muxer.
+See also the @ref{framemd5} and @ref{streammd5} muxers.
 
 @section mov, mp4, ismv
 
@@ -1307,6 +1307,42 @@ Specify whether to remove all fragments when finished. 
Default 0 (do not remove)
 
 @end table
 
+@anchor{streammd5}
+@section streammd5
+
+Per-stream MD5 testing format.
+
+This muxer computes and prints the MD5 hash for each stream.
+By default audio streams are converted to signed
+16-bit raw audio and video streams to raw video before computing the
+hash.
+
+The output of the muxer consists of a line for each stream of the form:
+@example
+@var{stream_index}, @var{MD5}
+@end example
+
+@var{MD5} is a hexadecimal number representing the computed MD5 hash
+for the packet.
+
+@subsection Examples
+
+For example to compute the MD5 of all the audio and video streams in
+@file{INPUT}, converted to raw audio and video packets, and store it
+in the file @file{out.md5}:
+@example
+ffmpeg -i INPUT -f streammd5 out.md5
+@end example
+
+To compute the MD5 of all the streams in @file{INPUT} without any
+conversion, and print it to stdout:
+@example
+ffmpeg -i INPUT -f streammd5 -codec copy -map 0 -
+@end example
+
+See also the @ref{md5} and @ref{framemd5} muxers.
+
+
 @section tee
 
 The tee muxer can be used to write the same data to several files or any
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 001b3f1..fde64dc 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -430,6 +430,7 @@ OBJS-$(CONFIG_SRT_DEMUXER)   += srtdec.o 
subtitles.o
 OBJS-$(CONFIG_SRT_MUXER) += srtenc.o
 OBJS-$(CONFIG_STL_DEMUXER)   += stldec.o subtitles.o
 OBJS-$(CONFIG_STR_DEMUXER)   += psxstr.o
+OBJS-$(CONFIG_STREAMMD5_MUXER)   += md5enc.o
 OBJS-$(CONFIG_SUBVIEWER1_DEMUXER)+= subviewer1dec.o subtitles.o
 OBJS-$(CONFIG_SUBVIEWER_DEMUXER) += subviewerdec.o subtitles.o
 OBJS-$(CONFIG_SUP_DEMUXER)   += supdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 02bb16a..df4c8eb 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -295,6 +295,7 @@ void av_register_all(void)
 REGISTER_MUXDEMUX(SPDIF,spdif);
 REGISTER_MUXDEMUX(SRT,  srt);
 REGISTER_DEMUXER (STR,  str);
+REGISTER_MUXER   (STREAMMD5,streammd5);
 REGISTER_DEMUXER (STL,  stl);
 REGISTER_DEMUXER (SUBVIEWER1,   subviewer1);
 REGISTER_DEMUXER (SUBVIEWER,subviewer);
diff --git a/libavformat/md5enc.c b/libavformat/md5enc.c
index 8433be4..b114a9b 100644
--- a/libavformat/md5enc.c
+++ b/libavformat/md5enc.c
@@ -169,3 +169,90 @@ AVOutputFormat ff_framemd5_muxer = {
 .priv_class= &framemd5_class,
 };
 #endif
+
+
+#if CONFIG_STREAMMD5_MUXER
+
+struct StreamMD5Context {
+const AVClass *avclass;
+struct AVHashContext** hashes;
+char *hash_name;
+int format_version;
+};
+
+static const AVClass streammd5enc_class = {
+.class_name = "stream hash encoder class",
+.item_name  = av_default_item_name,
+.option = hash_options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
+static int streammd5_write_header(struct AVFormatContext *s)
+{
+unsigned int i;
+struct StreamMD5Context *ctx = s->priv_data;
+ctx->hashes = av_calloc(s->nb_streams, sizeof(struct AVHashContext*));
+for (i = 0; i < s->nb_streams; ++i) {
+int res = av_hash_alloc(&ctx->hashes[i], ctx->hash_name);
+if (res < 0) {
+return res;
+}
+av_h

Re: [FFmpeg-devel] [PATCH]lavc/libvpx: Fix high-bitrate colour?spaces

[Michael Niedermayer]

On Fri, Feb 19, 2016 at 08:42:29AM +, Carl Eugen Hoyos wrote:
> James Zern  google.com> writes:
> 
> > On Fri, Feb 19, 2016 at 12:00 AM, Carl Eugen Hoyos wrote:
> > > James Zern  google.com> writes:
> > >
> > >> On Thu, Feb 18, 2016 at 11:40 PM, Carl Eugen Hoyos wrote:
> > >> > On Friday 19 February 2016 07:59:37 am James Zern wrote:
> > >> >
> > >> >> The decoder won't change when built on a big-endian
> > >> >> platform, so I don't think this is correct.
> > >> >
> > >> > New patch attached.
> > >>
> > >> Sorry, I meant all of it, high bitdepth is no different.
> > >
> > > I don't understand: Do you mean that the patch is incomplete
> > > and that further broken pix_fmts exist? Which ones?
> > 
> > I meant I didn't think LE was incorrect to begin with, 
> > am I missing something?
> 
> Difficult to say.
> 
> Short answer: How can I reproduce this?
> (The fact that it works fine on BE with 
> unpatched sources.)
> 
> Long answer:
> I was honestly very angry with myself when I saw this 
> code yesterday: I consider it an obvious bug that I (!) 
> should have seen whenever this patch was sent to the 
> mailing list.
> I spent some time yesterday to find BE hardware and to 

> compile there (and git.videolan was extremely slow at 
> the time and git pull tool ages) so I only tested very 

you can use https://github.com/FFmpeg/FFmpeg.git for pulling

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] lavc: add h264 mediacodec decoder

[Moritz Barsnick]

On Fri, Feb 19, 2016 at 10:07:06 +0100, Matthieu Bouron wrote:

IANAL, but:

> + * Copyright (c) Matthieu Bouron 

Every copyright notice within the ffmpeg source tree has a year (or a
set of years or a range) attached, until now.

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

Re: [FFmpeg-devel] [PATCH] checkasm: fix dependencies for vf_blend tests

[Paul B Mahol]

On 2/19/16, James Almer  wrote:
> They will now compile if avcodec is disabled
>
> Signed-off-by: James Almer 
> ---
>  tests/checkasm/Makefile   | 6 +-
>  tests/checkasm/checkasm.c | 8 +---
>  2 files changed, 10 insertions(+), 4 deletions(-)
>

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

Re: [FFmpeg-devel] [PATCH 5/5] lavc: add h264 mediacodec decoder

[Matthieu Bouron]

On Wed, Feb 17, 2016 at 06:39:46PM +0100, Matthieu Bouron wrote:
> On Mon, Feb 15, 2016 at 10:17:25PM +0100, Matthieu Bouron wrote:
> > On Mon, Feb 15, 2016 at 08:42:48PM +0100, Michael Niedermayer wrote:
> > > On Mon, Feb 15, 2016 at 06:52:30PM +0100, Matthieu Bouron wrote:
> > > > From: Matthieu Bouron 
> > > > 
> > > > ---
> > > >  configure   |5 +
> > > >  libavcodec/Makefile |3 +
> > > >  libavcodec/allcodecs.c  |1 +
> > > >  libavcodec/mediacodec_wrapper.c | 1522 
> > > > +++
> > > >  libavcodec/mediacodec_wrapper.h |  123 
> > > >  libavcodec/mediacodecdec.c  |  753 +++
> > > >  libavcodec/mediacodecdec.h  |   98 +++
> > > >  libavcodec/mediacodecdec_h264.c |  365 ++
> > > >  8 files changed, 2870 insertions(+)
> > > >  create mode 100644 libavcodec/mediacodec_wrapper.c
> > > >  create mode 100644 libavcodec/mediacodec_wrapper.h
> > > >  create mode 100644 libavcodec/mediacodecdec.c
> > > >  create mode 100644 libavcodec/mediacodecdec.h
> > > >  create mode 100644 libavcodec/mediacodecdec_h264.c
> > > 
> > > breaks fate:
> > > 
> > > vsynth1-dnxhd-1080i-10bit
> > > TESTvsynth1-dnxhd-1080i-colr
> > > TESTvsynth1-dv
> > > --- ./tests/ref/fate/source 2016-02-15 13:45:07.088605740 +0100
> > > +++ tests/data/fate/source  2016-02-15 20:24:16.205110282 +0100
> > > @@ -27,3 +27,4 @@
> > >  compat/avisynth/windowsPorts/windows2linux.h
> > >  compat/float/float.h
> > >  compat/float/limits.h
> > > +libavcodec/mediacodec_wrapper.h
> > > Test source failed. Look at tests/data/fate/source.err for details.
> > > make: *** [fate-source] Error 1
> > > make: *** Waiting for unfinished jobs
> > 
> > Thanks. Fixed locally by changing #define FF_MEDIACODEC_H to
> > AVCODEC_MEDIACODEC_WRAPPER_H in the relevant header.
> > 
> > Development branch updated.
> 
> Patch updated locally and development branch updated:
>   * add missing copyright notices
>   * correctly flush remaining frames when reaching end of stream.
> 
> I will send soon an updated version of the patch to the ml.
> 

Updated patch attached with the following differences from the first
patch:
  * add missing copyright notices
  * correctly flush remaining frames when reaching end of stream
  * properly set frame->pkt_pts

Matthieu
>From aeaa6f0b148c9068c79be52ff1250fcd780b55a3 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Thu, 21 Jan 2016 09:29:39 +0100
Subject: [PATCH] lavc: add h264 mediacodec decoder

---
 configure   |5 +
 libavcodec/Makefile |3 +
 libavcodec/allcodecs.c  |1 +
 libavcodec/mediacodec_wrapper.c | 1522 +++
 libavcodec/mediacodec_wrapper.h |  123 
 libavcodec/mediacodecdec.c  |  943 
 libavcodec/mediacodecdec.h  |   99 +++
 libavcodec/mediacodecdec_h264.c |  365 ++
 8 files changed, 3061 insertions(+)
 create mode 100644 libavcodec/mediacodec_wrapper.c
 create mode 100644 libavcodec/mediacodec_wrapper.h
 create mode 100644 libavcodec/mediacodecdec.c
 create mode 100644 libavcodec/mediacodecdec.h
 create mode 100644 libavcodec/mediacodecdec_h264.c

diff --git a/configure b/configure
index db4ebbc..1126f3a 100755
--- a/configure
+++ b/configure
@@ -275,6 +275,7 @@ External library support:
   --enable-libzvbi enable teletext support via libzvbi [no]
   --disable-lzma   disable lzma [autodetect]
   --enable-decklinkenable Blackmagic DeckLink I/O support [no]
+  --enable-mediacodec  enable Android MediaCodec support [no]
   --enable-mmalenable decoding via MMAL [no]
   --enable-netcdf  enable NetCDF, needed for sofalizer filter [no]
   --enable-nvenc   enable NVIDIA NVENC support [no]
@@ -1497,6 +1498,7 @@ EXTERNAL_LIBRARY_LIST="
 libzmq
 libzvbi
 lzma
+mediacodec
 mmal
 netcdf
 nvenc
@@ -2491,6 +2493,8 @@ h264_d3d11va_hwaccel_deps="d3d11va"
 h264_d3d11va_hwaccel_select="h264_decoder"
 h264_dxva2_hwaccel_deps="dxva2"
 h264_dxva2_hwaccel_select="h264_decoder"
+h264_mediacodec_decoder_deps="mediacodec"
+h264_mediacodec_decoder_select="h264_mp4toannexb_bsf h264_parser"
 h264_mmal_decoder_deps="mmal"
 h264_mmal_decoder_select="mmal"
 h264_mmal_hwaccel_deps="mmal"
@@ -5571,6 +5575,7 @@ enabled libzmq&& require_pkg_config libzmq zmq.h zmq_ctx_new
 enabled libzvbi   && require libzvbi libzvbi.h vbi_decoder_new -lzvbi &&
  { check_cpp_condition libzvbi.h "VBI_VERSION_MAJOR > 0 || VBI_VERSION_MINOR > 2 || VBI_VERSION_MINOR == 2 && VBI_VERSION_MICRO >= 28" ||
enabled gpl || die "ERROR: libzvbi requires version 0.2.28 or --enable-gpl."; }
+enabled mediacodec&& { enabled jni || die "ERROR: mediacodec requires --enable-jni"; }
 enabled mmal  && { check_lib interface/mmal/mmal.h mmal_port_conne

Re: [FFmpeg-devel] [PATCH] lavc/libvpx: fix support for RGB colorspace.

[Carl Eugen Hoyos]

Hendrik Leppkes  gmail.com> writes:

> Well that would be nice and all, but in many of those 
> cases the code is never re-indented afterwards

I am happy to fix them if you point me to them.

The only reason I did not reindent in the past 
was to make merges easier.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavc/libvpx: Fix high-bitrate colour spaces

[Carl Eugen Hoyos]

Hendrik Leppkes  gmail.com> writes:

> On Fri, Feb 19, 2016 at 8:47 AM, James Zern wrote:
> > On Thu, Feb 18, 2016 at 11:40 PM, Carl Eugen Hoyos wrote:
> >> On Friday 19 February 2016 07:59:37 am James Zern wrote:
> >>
> >>> The decoder won't change when built on a big-endian 
> >>> platform, so I don't think this is correct.
> >>
> >> New patch attached.
> >
> > Sorry, I meant all of it, high bitdepth is no different.
> 
> I think his point is that the decoder always outputs LE, 
> and this change is therefor incorrect?

Don't you agree that this is highly unlikely?
(I mean by looking at the code, not because I claim it.)

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavc/libvpx: Fix high-bitrate colour spaces

[Carl Eugen Hoyos]

James Zern  google.com> writes:

> On Fri, Feb 19, 2016 at 12:00 AM, Carl Eugen Hoyos wrote:
> > James Zern  google.com> writes:
> >
> >> On Thu, Feb 18, 2016 at 11:40 PM, Carl Eugen Hoyos wrote:
> >> > On Friday 19 February 2016 07:59:37 am James Zern wrote:
> >> >
> >> >> The decoder won't change when built on a big-endian
> >> >> platform, so I don't think this is correct.
> >> >
> >> > New patch attached.
> >>
> >> Sorry, I meant all of it, high bitdepth is no different.
> >
> > I don't understand: Do you mean that the patch is incomplete
> > and that further broken pix_fmts exist? Which ones?
> 
> I meant I didn't think LE was incorrect to begin with, 
> am I missing something?

Difficult to say.

Short answer: How can I reproduce this?
(The fact that it works fine on BE with 
unpatched sources.)

Long answer:
I was honestly very angry with myself when I saw this 
code yesterday: I consider it an obvious bug that I (!) 
should have seen whenever this patch was sent to the 
mailing list.
I spent some time yesterday to find BE hardware and to 
compile there (and git.videolan was extremely slow at 
the time and git pull tool ages) so I only tested very 
cursory but I did have the impression that my suspicion 
(that libvpx does not change the endianess of the input 
on BE which would not be a good idea performance-wise) 
is correct (for the one example I tested). So if you 
say now that it works fine for you, I probably made a 
mistake (and libvpx does something on be that makes it 
even slower). How I reproduce your findings?

Thank you, Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavc/libvpx: Fix high-bitrate colour spaces

[Carl Eugen Hoyos]

Nicolas George  nsup.org> writes:

> Le primidi 1er ventôse, an CCXXIV, Carl Eugen Hoyos a écrit :
> > Please comment, Carl Eugen
> 
> Just a quick nit: please be careful about hugh bitdepth vs. high bitrate.

I hopefully won't forget:
Thank you for pointing this out!

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

Re: [FFmpeg-devel] [PATCH] lavc/libvpx: fix support for RGB colorspace.

[Hendrik Leppkes]

On Fri, Feb 19, 2016 at 8:16 AM, James Zern  wrote:
> On Thu, Feb 18, 2016 at 3:02 PM, Hendrik Leppkes  wrote:
>> On Thu, Feb 18, 2016 at 11:59 PM, Carl Eugen Hoyos  wrote:
>>> On Thursday 18 February 2016 09:40:01 pm Nicolas George wrote:
 Initial patch by Carl Eugen Hoyos.

 Fix trac ticket #5249.
>>>
>>> Patch with (automatic) support for 8, 10 and 12 bit gbr attached.
>>>
>>> Please comment, Carl Eugen
>>
>> This lacks the appropriate changes in libvpx.c to the supported pixel
>> formats for the encoder.
>> Also, please re-indent appropriately. If its not in this patch, it'll
>> never get done.
>>
>
> There was a historical preference not to do that, the developer docs
> still say something to that effect [1]. If the preference has changed
> then I'm OK with it.
>
> [1] http://ffmpeg.org/developer.html#Development-Policy
> "8. We refuse source indentation and other cosmetic changes if they
> are mixed with functional changes, such commits will be rejected and
> removed."

Well that would be nice and all, but in many of those cases the code
is never re-indented afterwards, and leaves a unreadable mess in the
code, so thats even worse.
Any good diff viewer will highlight actual changes and ignore
whitespace, as well.

This should probably be reworded so it doesn't sound as strongly.

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

Re: [FFmpeg-devel] [PATCH]lavc/libvpx: Fix high-bitrate colour spaces

[James Zern]

On Fri, Feb 19, 2016 at 12:00 AM, Carl Eugen Hoyos  wrote:
> James Zern  google.com> writes:
>
>> On Thu, Feb 18, 2016 at 11:40 PM, Carl Eugen Hoyos > > On Friday 19 February 2016 07:59:37 am James Zern wrote:
>> >
>> >> The decoder won't change when built on a big-endian
>> >> platform, so I don't think this is correct.
>> >
>> > New patch attached.
>>
>> Sorry, I meant all of it, high bitdepth is no different.
>
> I don't understand: Do you mean that the patch is incomplete
> and that further broken pix_fmts exist? Which ones?
>

I meant I didn't think LE was incorrect to begin with, am I missing something?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/libvpx: Fix high-bitrate colour spaces

[Hendrik Leppkes]

On Fri, Feb 19, 2016 at 8:47 AM, James Zern  wrote:
> On Thu, Feb 18, 2016 at 11:40 PM, Carl Eugen Hoyos  wrote:
>> On Friday 19 February 2016 07:59:37 am James Zern wrote:
>>
>>> The decoder won't change when built on a big-endian platform, so I don't
>>> think this is correct.
>>
>> New patch attached.
>>
>
> Sorry, I meant all of it, high bitdepth is no different.

I think his point is that the decoder always outputs LE, and this
change is therefor incorrect?

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

Re: [FFmpeg-devel] [PATCH]lavc/libvpx: Fix high-bitrate colour spaces

[Nicolas George]

Le primidi 1er ventôse, an CCXXIV, Carl Eugen Hoyos a écrit :
> Please comment, Carl Eugen

Just a quick nit: please be careful about hugh bitdepth vs. high bitrate.

Regards,

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

Re: [FFmpeg-devel] [PATCH]lavc/libvpx: Fix high-bitrate colour spaces

[Carl Eugen Hoyos]

James Zern  google.com> writes:

> On Thu, Feb 18, 2016 at 11:40 PM, Carl Eugen Hoyos  > On Friday 19 February 2016 07:59:37 am James Zern wrote:
> >
> >> The decoder won't change when built on a big-endian 
> >> platform, so I don't think this is correct.
> >
> > New patch attached.
> 
> Sorry, I meant all of it, high bitdepth is no different.

I don't understand: Do you mean that the patch is incomplete 
and that further broken pix_fmts exist? Which ones?

Thank you, Carl Eugen

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