Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Thilo Borgmann]

Am 04.03.16 um 23:44 schrieb Timothy Gu:
> [...]
> So here I propose the following for the master branch:
> 
> n3.1-dev-N-78911-gf81c81c
>/  |  \  \
>  /|   \\
>   next  distinguish commits since  commit
> release from actual the start ofhash
>   release   time
> 
> For comparison, versions on the release branch are as follows:
> 
> n3.0-4-geb46065
>   /| \
>   /   \  \
> previous commits since  commit
> release  that releasehash
> [...]
> 
>: Current: New
> Master
> Full   : N-78911-gf81c81c   : n3.1-dev-N-78911-gf81c81c
> Shallow clone  : git-2016-03-04-f81c81c : n3.1-dev-gf81c81c
> Gitweb tarball : 3.0.git-f81c81c: n3.1-dev-gf81c81c
> Nothing: 3.0.git: n3.1-dev
> 
> Release branch
> Full   : n3.0-4-geb46065: n3.0.1-dev-4-geb46065
> Shallow clone  : eb46065: n3.0.1-dev-geb56065
> Nothing: 3.0: n3.0.1-dev
> 
> Release
> Full   : n3.0   : n3.0
> Shallow clone  : n3.0   : n3.0
> Nothing: 3.0: n3.0

I had loved to see something like this sooner, thanks!

I think in that form it is in all cases better than it is now.
No more objections from me.

-Thilo

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

[FFmpeg-devel] [PATCH v5 1/4 v6] lavf/avienc: Add support for palette side data

[Mats Peterson]

Only copy/compare enough bytes for the bit depth in question.

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 32eaa0889f7356524d785fa7432d48dd89c32376 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 5 Mar 2016 07:32:12 +0100
Subject: [PATCH v5 1/4 v6] lavf/avienc: Add support for palette side data

---
 libavformat/avienc.c |   79 --
 1 file changed, 50 insertions(+), 29 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ca505f4..98157fc 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -74,12 +74,14 @@ typedef struct AVIStream {
 int max_size;
 int sample_requested;
 
-int64_t pal_offset;
-int hdr_pal_done;
-
 int64_t last_dts;
 
 AVIIndex indexes;
+
+uint32_t palette[AVPALETTE_COUNT];
+uint32_t old_palette[AVPALETTE_COUNT];
+int64_t pal_offset;
+int pal_done;
 } AVIStream;
 
 static int avi_write_packet_internal(AVFormatContext *s, AVPacket *pkt);
@@ -362,7 +364,8 @@ 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;
-avist->pal_offset = avio_tell(pb) + 40;
+if (pb->seekable)
+avist->pal_offset = avio_tell(pb) + 40;
 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,11 +655,11 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 unsigned char tag[5];
 const int stream_index = pkt->stream_index;
-const uint8_t *data= pkt->data;
-int size   = pkt->size;
 AVIOContext *pb = s->pb;
 AVCodecContext *enc = s->streams[stream_index]->codec;
 AVIStream *avist= s->streams[stream_index]->priv_data;
+AVPacket *opkt = pkt;
+enum AVPixelFormat pix_fmt = enc->pix_fmt;
 int ret;
 
 if (enc->codec_id == AV_CODEC_ID_H264 && enc->codec_tag == MKTAG('H','2','6','4') && pkt->size) {
@@ -668,39 +671,57 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 if ((ret = write_skip_frames(s, stream_index, pkt->dts)) < 0)
 return ret;
 
-if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
-int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
-int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
-
-ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
-if (ret < 0)
-return ret;
-if (ret) {
-if (ret == CONTAINS_PAL) {
-int pc_tag, i;
+if (!pkt->size)
+return avi_write_packet_internal(s, pkt); /* Passthrough */
+
+if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
+int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
+int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
+ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
+if (ret < 0)
+return ret;
+} else
+ret = 0;
+if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
+pix_fmt = AV_PIX_FMT_MONOWHITE;
+if (pix_fmt == AV_PIX_FMT_PAL8 ||
+pix_fmt == AV_PIX_FMT_MONOWHITE ||
+pix_fmt == AV_PIX_FMT_MONOBLACK) {
+int ret2 = ff_get_packet_palette(s, opkt, ret, avist->palette);
+if (ret2 < 0)
+return ret2;
+if (ret2) {
 int pal_size = 1 << enc->bits_per_coded_sample;
-if (!avist->hdr_pal_done) {
+int pc_tag, i;
+if (pb->seekable && !avist->pal_done) {
 int64_t cur_offset = avio_tell(pb);
 avio_seek(pb, avist->pal_offset, SEEK_SET);
 for (i = 0; i < pal_size; i++) {
-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+uint32_t v = avist->palette[i];
 avio_wl32(pb, v & 0xff);
 }
 avio_seek(pb, cur_offset, SEEK_SET);
-avist->hdr_pal_done++;
+memcpy(avist->old_palette, avist->palette, pal_size * 4);
+avist->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, pal_size & 0xFF);
-avio_wl16(pb, 0); // reserved
-for (i = 0; i < pal_size; i++) {
-  

Re: [FFmpeg-devel] [PATCH v5 1/4 v6] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 07:33 AM, Mats Peterson wrote:

Only copy/compare enough bytes for the bit depth in question.



Enough bytes of the palette, that is.

Mats

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

Re: [FFmpeg-devel] [PATCH] avformat: Add a protocol blacklisting API

[Michael Niedermayer]

On Fri, Mar 04, 2016 at 01:34:55PM +, Derek Buitenhuis wrote:
> On 3/3/2016 7:50 PM, Michael Niedermayer wrote:
> > The io_open/close callbacks afterwards seem direct access IIUC
> > so its not possible to remove or add any fields prior
> > 
> > though maybe they have been added so recently that its ok to move
> > them above all "no direct access" fields
> > or maybe iam missing something
> 
> Crap. I must have screwed up when merging those callbacks. I can move
> the be blacklist entry under them, or I can break ABI and move both,
> since I don't think there is release.

i thought it was post 3.0 but it seems, it was in 3.0

git grep io_close release/3.0:libavformat/avformat.h
release/3.0:libavformat/avformat.h:#define AVFMT_FLAG_CUSTOM_IO0x0080 ///< 
The caller has supplied a custom AVIOContext, don't avio_close() it.
release/3.0:libavformat/avformat.h: * @deprecated Use io_open and io_close.
release/3.0:libavformat/avformat.h:void (*io_close)(struct AVFormatContext 
*s, AVIOContext *pb);



> 
> Which do people prefer? They're both kinda meh.
> 
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousands in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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

Re: [FFmpeg-devel] [PATCH v5 1/4 v5] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 04:48 AM, Mats Peterson wrote:

On 03/05/2016 04:43 AM, Mats Peterson wrote:




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



This one only adds an xxpc chunk if it's not identical to the previosly
used palette. Good enough?

Mats



I should add that 8bpp_129.avi is a bit of abomination, since it 
contains identical xxpc chunks for every frame. But it's a good test 
file for this purpose.


Mats

--
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] avcodec/cos_tablegen: extend table generation to 17bits

[James Almer]

On 3/5/2016 12:36 AM, Michael Niedermayer wrote:
> On Fri, Mar 04, 2016 at 11:52:50PM -0300, James Almer wrote:
>> Fixes compilation of fft with hardcoded tables
>>
>> Signed-off-by: James Almer 
>> ---
>> fate-fft tests only up to 12 bits, so i ran fft-test -n17 manually
>> and it didn't fail (It was also very slow).
>> This change also generates sine tables for 17bit which are currently
>> unused, so they kinda bloat the binary. Maybe someone wants to update
>> rdft like it was done for fft and give them purpose?
>>
>>  libavcodec/cos_tablegen.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> LGTM
> 
> thx

Pushed.

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

Re: [FFmpeg-devel] [PATCH v5 1/4 v5] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 04:43 AM, Mats Peterson wrote:




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



This one only adds an xxpc chunk if it's not identical to the previosly 
used palette. Good enough?


Mats

--
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 v5 1/4 v4] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 04:38 AM, Mats Peterson wrote:

Something like this? It stores the palette in avist->old_palette, and
compares every new palette chunk with it, and only adds an xxpc chunk if
it differs.

Mats



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



Ouch, sorry for those fprintf() lines. I will remove them.

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 v5 1/4 v4] lavf/avienc: Add support for palette side data

[Mats Peterson]

Something like this? It stores the palette in avist->old_palette, and 
compares every new palette chunk with it, and only adds an xxpc chunk if 
it differs.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From abc3c5e67b1064e64d12f15b43c8063f29fb06ef Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 5 Mar 2016 04:36:27 +0100
Subject: [PATCH v5 1/4 v4] lavf/avienc: Add support for palette side data

---
 libavformat/avienc.c |   80 --
 1 file changed, 51 insertions(+), 29 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ca505f4..61621ef 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -74,12 +74,14 @@ typedef struct AVIStream {
 int max_size;
 int sample_requested;
 
-int64_t pal_offset;
-int hdr_pal_done;
-
 int64_t last_dts;
 
 AVIIndex indexes;
+
+uint32_t palette[AVPALETTE_COUNT];
+uint32_t old_palette[AVPALETTE_COUNT];
+int64_t pal_offset;
+int pal_done;
 } AVIStream;
 
 static int avi_write_packet_internal(AVFormatContext *s, AVPacket *pkt);
@@ -362,7 +364,8 @@ 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;
-avist->pal_offset = avio_tell(pb) + 40;
+if (pb->seekable)
+avist->pal_offset = avio_tell(pb) + 40;
 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,11 +655,11 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 unsigned char tag[5];
 const int stream_index = pkt->stream_index;
-const uint8_t *data= pkt->data;
-int size   = pkt->size;
 AVIOContext *pb = s->pb;
 AVCodecContext *enc = s->streams[stream_index]->codec;
 AVIStream *avist= s->streams[stream_index]->priv_data;
+AVPacket *opkt = pkt;
+enum AVPixelFormat pix_fmt = enc->pix_fmt;
 int ret;
 
 if (enc->codec_id == AV_CODEC_ID_H264 && enc->codec_tag == MKTAG('H','2','6','4') && pkt->size) {
@@ -668,39 +671,58 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 if ((ret = write_skip_frames(s, stream_index, pkt->dts)) < 0)
 return ret;
 
-if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
-int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
-int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
-
-ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
-if (ret < 0)
-return ret;
-if (ret) {
-if (ret == CONTAINS_PAL) {
-int pc_tag, i;
+if (!pkt->size)
+return avi_write_packet_internal(s, pkt); /* Passthrough */
+
+if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
+int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
+int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
+ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
+if (ret < 0)
+return ret;
+} else
+ret = 0;
+if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
+pix_fmt = AV_PIX_FMT_MONOWHITE;
+if (pix_fmt == AV_PIX_FMT_PAL8 ||
+pix_fmt == AV_PIX_FMT_MONOWHITE ||
+pix_fmt == AV_PIX_FMT_MONOBLACK) {
+int ret2 = ff_get_packet_palette(s, opkt, ret, avist->palette);
+if (ret2 < 0)
+return ret2;
+if (ret2) {
 int pal_size = 1 << enc->bits_per_coded_sample;
-if (!avist->hdr_pal_done) {
+int pc_tag, i;
+if (pb->seekable && !avist->pal_done) {
 int64_t cur_offset = avio_tell(pb);
 avio_seek(pb, avist->pal_offset, SEEK_SET);
 for (i = 0; i < pal_size; i++) {
-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+uint32_t v = avist->palette[i];
 avio_wl32(pb, v & 0xff);
 }
 avio_seek(pb, cur_offset, SEEK_SET);
-avist->hdr_pal_done++;
+memcpy(avist->old_palette, avist->palette, AVPALETTE_SIZE);
+avist->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, pal_size & 0xFF);
-

Re: [FFmpeg-devel] [PATCH] avcodec/cos_tablegen: extend table generation to 17bits

[Michael Niedermayer]

On Fri, Mar 04, 2016 at 11:52:50PM -0300, James Almer wrote:
> Fixes compilation of fft with hardcoded tables
> 
> Signed-off-by: James Almer 
> ---
> fate-fft tests only up to 12 bits, so i ran fft-test -n17 manually
> and it didn't fail (It was also very slow).
> This change also generates sine tables for 17bit which are currently
> unused, so they kinda bloat the binary. Maybe someone wants to update
> rdft like it was done for fft and give them purpose?
> 
>  libavcodec/cos_tablegen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

thx

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

Re: [FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 04:19 AM, Mats Peterson wrote:

On 03/05/2016 01:08 AM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 10:12:41PM +0100, Mats Peterson wrote:

On 03/04/2016 10:02 PM, Mats Peterson wrote:

On 03/04/2016 09:52 PM, Mats Peterson wrote:

On 03/04/2016 08:44 PM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:

On 03/04/2016 05:59 AM, Mats Peterson wrote:

Removed some unused variables in AVIStream.




I would like to remind you of the fact that this patch (and the one
for riffenc.c) is needed for stream copying of Microsoft Video 1
(CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
possibly more codecs using a palette, but these are the ones I can
come up with at the moment.


i tried CRAM and MSRLE, but these already work when streamcopied
before, do you have a testcase that does not work



It works, but only so much. On stream copy, it will only write the
palette after BITMAPINFOHEADER to the destination file. It won't write
any xxpc palette switching chunks to the file.

Mats


The xxpc chunks come as palette side data.

Mats



Try ffmpeg -i 8bpp_129.avi -vcodec copy test.avi, with and without


where can i find that file ?



Thought you had it already?
https://drive.google.com/open?id=0B3_pEBoLs0faekxWUTdkVGNTTlk




the avienc.c and riffenc.c patch. The destination file will only
contain xxpc chunks with my patch applied.


pc chunks are only needed when the palette changes, if its the same
for the whole file and after BITMAPINFOHEADER then theres no need
for pc chunks


And what do you suggest in order to detect this? 1 kb more per frame
isn't that much. Nut uses it all the time.

You were the one who proposed to use a shared function, and the option
for a calling program to deliver the palette as side data. That's why I
wrote the function, to be shared by avienc, movenc and possibly more
muxers. It would be nice if you could apply these remaining patches now,
thank you.



Or rather, it was Reimar who was first complaining at the muxers lacking 
the ability to handle palette side data.


Mats

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

Re: [FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/05/2016 01:08 AM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 10:12:41PM +0100, Mats Peterson wrote:

On 03/04/2016 10:02 PM, Mats Peterson wrote:

On 03/04/2016 09:52 PM, Mats Peterson wrote:

On 03/04/2016 08:44 PM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:

On 03/04/2016 05:59 AM, Mats Peterson wrote:

Removed some unused variables in AVIStream.




I would like to remind you of the fact that this patch (and the one
for riffenc.c) is needed for stream copying of Microsoft Video 1
(CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
possibly more codecs using a palette, but these are the ones I can
come up with at the moment.


i tried CRAM and MSRLE, but these already work when streamcopied
before, do you have a testcase that does not work



It works, but only so much. On stream copy, it will only write the
palette after BITMAPINFOHEADER to the destination file. It won't write
any xxpc palette switching chunks to the file.

Mats


The xxpc chunks come as palette side data.

Mats



Try ffmpeg -i 8bpp_129.avi -vcodec copy test.avi, with and without


where can i find that file ?



Thought you had it already?
https://drive.google.com/open?id=0B3_pEBoLs0faekxWUTdkVGNTTlk




the avienc.c and riffenc.c patch. The destination file will only
contain xxpc chunks with my patch applied.


pc chunks are only needed when the palette changes, if its the same
for the whole file and after BITMAPINFOHEADER then theres no need
for pc chunks


And what do you suggest in order to detect this? 1 kb more per frame 
isn't that much. Nut uses it all the time.


You were the one who proposed to use a shared function, and the option 
for a calling program to deliver the palette as side data. That's why I 
wrote the function, to be shared by avienc, movenc and possibly more 
muxers. It would be nice if you could apply these remaining patches now, 
thank you.


Mats

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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[compn]

On Fri, 4 Mar 2016 14:44:28 -0800
Timothy Gu  wrote:

> So after all the email exchanges, I think there are certain things
> that our version SHOULD contain:
> 
> - The hash
> - The next release (i.e. n3.1)
> - A way to compare two versions
> 
> The date is considered to be "good" but perhaps not as necessary.

the problem i've seen when helping users when the date is inside the
version string (in mplayer) is that the idiot distros build an old
mplayer 1.1-2016-01-01 right? except mplayer 1.1 was released 3
years ago. in 2013.

they just built a 3 year old tarball two months ago and users install
it like it was new!

which is why ffmpeg and mplayer have the copyright year in the version
string to help. slightly. assuming distros dont mess with it.


> 
> Any objections?
> 

should put it up to a vote what devs and users want to see.

otherwise its just a few vocal devs on the list dictating it for
everyone :P


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

[FFmpeg-devel] [PATCH] avcodec/cos_tablegen: extend table generation to 17bits

[James Almer]

Fixes compilation of fft with hardcoded tables

Signed-off-by: James Almer 
---
fate-fft tests only up to 12 bits, so i ran fft-test -n17 manually
and it didn't fail (It was also very slow).
This change also generates sine tables for 17bit which are currently
unused, so they kinda bloat the binary. Maybe someone wants to update
rdft like it was done for fft and give them purpose?

 libavcodec/cos_tablegen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/cos_tablegen.c b/libavcodec/cos_tablegen.c
index dbd0cc0..7206aad 100644
--- a/libavcodec/cos_tablegen.c
+++ b/libavcodec/cos_tablegen.c
@@ -26,7 +26,7 @@
 
 #include "libavutil/mathematics.h"
 
-#define BITS 16
+#define BITS 17
 #define FLOATFMT "%.18e"
 #define FIXEDFMT "%6d"
 
-- 
2.7.2


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

Re: [FFmpeg-devel] [PATCH] Use matroska TrackNumber for populating AVStream::id

[Sergey Volk]

Ok, something like this for now, then?
I'm new to ffmpeg development. When is the next version bump going to happen?
---
 libavformat/matroskadec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index d20568c..4c3e53a 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1856,6 +1856,9 @@ static int matroska_parse_tracks(AVFormatContext *s)
 return AVERROR(ENOMEM);
 }

+if (track->num <= INT_MAX)
+  st->id = (int) track->num;
+
 if (key_id_base64) {
 /* export encryption key id as base64 metadata tag */
 av_dict_set(>metadata, "enc_key_id", key_id_base64, 0);
-- 
2.7.0.rc3.207.g0ac5344

On Thu, Mar 3, 2016 at 2:14 AM, Carl Eugen Hoyos  wrote:
> wm4  googlemail.com> writes:
>
>> > +st->id = (int) track->num;
>
>> Might be better after all not to set the id if it's out of range?
>
> Yes, please.
>
> While there, the id field could be changed to 64bit with the
> next version bump.
>
> Carl Eugen
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data

[Michael Niedermayer]

On Fri, Mar 04, 2016 at 10:12:41PM +0100, Mats Peterson wrote:
> On 03/04/2016 10:02 PM, Mats Peterson wrote:
> >On 03/04/2016 09:52 PM, Mats Peterson wrote:
> >>On 03/04/2016 08:44 PM, Michael Niedermayer wrote:
> >>>On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:
> On 03/04/2016 05:59 AM, Mats Peterson wrote:
> >Removed some unused variables in AVIStream.
> >
> 
> 
> I would like to remind you of the fact that this patch (and the one
> for riffenc.c) is needed for stream copying of Microsoft Video 1
> (CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
> possibly more codecs using a palette, but these are the ones I can
> come up with at the moment.
> >>>
> >>>i tried CRAM and MSRLE, but these already work when streamcopied
> >>>before, do you have a testcase that does not work
> >>>
> >>
> >>It works, but only so much. On stream copy, it will only write the
> >>palette after BITMAPINFOHEADER to the destination file. It won't write
> >>any xxpc palette switching chunks to the file.
> >>
> >>Mats
> >>
> >The xxpc chunks come as palette side data.
> >
> >Mats
> 
> 
> Try ffmpeg -i 8bpp_129.avi -vcodec copy test.avi, with and without

where can i find that file ?


> the avienc.c and riffenc.c patch. The destination file will only
> contain xxpc chunks with my patch applied.

pc chunks are only needed when the palette changes, if its the same
for the whole file and after BITMAPINFOHEADER then theres no need
for pc chunks
a testcase with changing palette would be ideal for fate

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousands in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 08:46:42PM +0100, Reimar Döffinger wrote:
> On 04.03.2016, at 11:24, Nicolas George  wrote:
> 
> > The Git (short) hash carries all the information by itself, so it should be
> > present. But extra, redundant, information can be added for the convenience
> > of users and "supporters".
> > 
> > Basically, the version could be something like
> > "g510046c:N78879-3.0master417-H20160303":
> 
> The formatting is rather ugly but I'd be in favour of something like that.
> An attempt to order the information in increasing detail might be:
> v3.0+417-D20160303-N78879-g510046c
> Note that I'm not convinced the git describe info/branch info/number of
> commits since release is all that useful, but the base release version
> number seems nice to have.

I agree.

> Particularly the branch name can easily be misleading as it can be anyone's
> master, not necessarily the one on ffmpeg.org.

Indeed.

->8--

So after all the email exchanges, I think there are certain things that our
version SHOULD contain:

- The hash
- The next release (i.e. n3.1)
- A way to compare two versions

The date is considered to be "good" but perhaps not as necessary.

So here I propose the following for the master branch:

n3.1-dev-N-78911-gf81c81c
   /  |  \  \
 /|   \\
  next  distinguish commits since  commit
release from actual the start ofhash
  release   time

For comparison, versions on the release branch are as follows:

n3.0-4-geb46065
/| \
  /   \  \
previous commits since  commit
release  that releasehash

A few reasons why I chose this style for master branch rather than some other:

- I want it to bear some resemblance to our original style
   - which also happens to satisfy Carl's perhaps unjustified dependency on it
- I want it to be somewhat consistent with our release branch version
- It should also be gitrevisions(7)-compatible

I would also like to raise an awareness of versioning when full Git metadata
is not available. version.sh tries its best to get information, and usually
ends up with one of the following circumstances. However, the format is wildly
inconsistent, and I want to fix this once and for all.

I can utilize the RELEASE file to provide information on our next release,
even when tags are unavailable.

   : Current: New
Master
Full   : N-78911-gf81c81c   : n3.1-dev-N-78911-gf81c81c
Shallow clone  : git-2016-03-04-f81c81c : n3.1-dev-gf81c81c
Gitweb tarball : 3.0.git-f81c81c: n3.1-dev-gf81c81c
Nothing: 3.0.git: n3.1-dev

Release branch
Full   : n3.0-4-geb46065: n3.0.1-dev-4-geb46065
Shallow clone  : eb46065: n3.0.1-dev-geb56065
Nothing: 3.0: n3.0.1-dev

Release
Full   : n3.0   : n3.0
Shallow clone  : n3.0   : n3.0
Nothing: 3.0: n3.0

Any objections?

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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Thilo Borgmann]

Am 04.03.16 um 22:50 schrieb Timothy Gu:
> On Fri, Mar 04, 2016 at 06:48:04PM +0100, Thilo Borgmann wrote:
>> Am 04.03.16 um 17:57 schrieb Timothy Gu:
>>> On Fri, Mar 04, 2016 at 10:55:42AM +0100, Thilo Borgmann wrote:
 Am 04.03.16 um 08:58 schrieb wm4:
>
> Being able to see the, well, version in the version output (instead of
> random numbers) sounds like a pretty convincing argument.

 Neither a good play on words nor elaborative; not even helpful.

 You say they are random numbers, CE says it is continuous. What is correct?
>>>
>>> It is continuous. But to the user's eye, N-71234 is no different from 
>>> N-41234,
>>> and hence "random."
>>
>> I assume that if there is no difference in the user's eye between
>> N-71234 and N-41234 then there is also no difference for that user
>> between dev-123 and dev-346.
> 
> That's not the point. ...

From here I really can't follow you...

> The point is that there is something before the dev
> part, and that's what makes the difference.

Do you mean the absolute anchor point for dev-123 (completely:
v3.0-dev123) which leads to "from release 3.0 go 123 steps further"?
If so, yes, it is different to N-12345 which leads to "go 12345 steps".
In that case, I would still prefer "absolute position" above "anchor +
relative position".


> When I said "no different," I meant except the fact that N-71234 is obviously
> newer. The fact that it fails to convey any additional information is the
> issue we are trying to attack.

With what I'm absolutely fine - I would like to see the release tag in
front. To determine how far away the build is from that release, I would
still prefer the absolute number (like said above).
Why? If I understand this correctly, the dev-123 tag version has a
certain disadvantage against N-tags.
Let's say there is v3.0-dev123.
Let's say there is v3.5-dev3.
Let's assume v3.5 was released right after 3.0 (3.1, 3.2, etc are not
existing)
Now, the question of interest is, how big is the difference between
v3.0-dev123 and v3.5-dev3?
This is the question this is all about, isn't it?
Since I do not know, how many commits there were at all for version 3.0,
I cannot answer the question. Maybe v3.0-dev142 was the last? Maybe
v3.0-dev897?
Let's assume there is v3.0-N-12345 and v3.5-N-12389... I can tell you
and estimate whatever 44 commits are worth estimating, no matter which
commit exactly raised version minor from 0 to 5.

But maybe I'm totally off-minded here.


 So what about the release tag? Well it is a quite useful extension because 
 of
 the already mentioned possibility of determining the existing features at 
 once.
 I'm pro adding it to the version string.

 The tag-tag? (devxy) I don't see it anywhere except in git and therefore 
 it is
 uselessly redundant to the existing hash tag in my eyes. Why add another 
 more
 roughly estimation of the users repo-state? I don't think this should be 
 added
 to the version string.
>>>
>>> Can you elaborate on this? I am not sure I understand everything you are
>>> saying. Specfically, what is "devxy"?
>>
>> The core concern about it is that is just redundant. I assume Timo to be
>> correct about:
>>
>> "A new dev tag is made every time a release is branched off, to indicate
>> development of the next ffmpeg version started there, ..."
>>
>> Then there is no gain of information in the dev-123 tag if there is
>> already the release number given. In that case "v4.5-gdeabdef" tells me
>> the very same as "v4.5-dev-123-gdeabdef" does. If Timo is correct, the
>> can never be a "4.5-dev-789-abcdefg" tag. v4.5 is just enough.
>>
>> Summing it all up for me, I think a release prefix would make perfect
>> sense. Thus, switching from
>>
>> N-12345-abcdefg
>>
>> to
>>
>> v4.5-N-12345-abcdefg
>>
>> should be done for the sake of the users. There is at least CE wanting
>> to stick with N-tags so why not? The only reason I can imagine for
>> getting rid of N-tags and/or including dev-123 tags would be that a
>> native git show command needs it to work properly as well as giving
>> better human readable information.
> 
> I see where you are coming from. I will address this issue in my reply to
> Reimar.

Eh... No - I don't understand. Maybe your reply to Raimar will explain...

-Thilo

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

Re: [FFmpeg-devel] [PATCH] lavf/dump.c: Print mastering display metadata

[wm4]

On Fri, 4 Mar 2016 23:15:52 +0100
Michael Niedermayer  wrote:

> On Mon, Feb 29, 2016 at 05:20:17PM -0800, Neil Birkbeck wrote:
> > Signed-off-by: Neil Birkbeck 
> > ---
> >  libavformat/dump.c | 21 +
> >  1 file changed, 21 insertions(+)  
> 
> applied
> 
> thanks
> 
> [...]

This should also go into ffprobe.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] tests/gapless: add gapless aac tests

[Michael Niedermayer]

On Fri, Mar 04, 2016 at 10:46:33PM +0100, Marton Balint wrote:
> 
> On Thu, 3 Mar 2016, Michael Niedermayer wrote:
> 
> >On Thu, Mar 03, 2016 at 02:27:52AM +0100, Marton Balint wrote:
> >>Signed-off-by: Marton Balint 
> >>---
> >> tests/fate/gapless.mak | 3 +++
> >> tests/ref/fate/gapless-aac | 5 +
> >> 2 files changed, 8 insertions(+)
> >> create mode 100644 tests/ref/fate/gapless-aac
> >
> >seems to fail on x86-32
> >
> >--- ffmpeg/tests/ref/fate/gapless-aac  2016-03-03 03:06:35.306048679 +0100
> >+++ tests/data/fate/gapless-aac 2016-03-03 03:11:56.286055441 +0100
> >@@ -1,5 +1,5 @@
> >9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-1
> >-d3c3c4ea121b3f3b8a346a168d2fec0e
> >+d00bed4d4a83ce1addb92c075b2fcaaf
> >9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-2
> >-d3c3c4ea121b3f3b8a346a168d2fec0e
> >+d00bed4d4a83ce1addb92c075b2fcaaf
> >63dd86b78c8fbd22a99bf88583256bfe *tests/data/fate/gapless-aac.out-3
> >Test gapless-aac failed. Look at tests/data/fate/gapless-aac.err for details.
> >make: *** [fate-gapless-aac] Error 1
> 
> Hmm, it seems there is a tiny difference in the 145th sample of the
> first decoded frame. I thought this is not supposed to happen with
> the fixed point decoder. Anybody has any ideas?

in absence of better ideas
1:pepper the code with printf()
  run on both x86-32 and 64
  and diff to find te first difference
if that explains the problem then you are done
else goto 1


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

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- 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] lavf/dump.c: Print mastering display metadata

[Michael Niedermayer]

On Mon, Feb 29, 2016 at 05:20:17PM -0800, Neil Birkbeck wrote:
> Signed-off-by: Neil Birkbeck 
> ---
>  libavformat/dump.c | 21 +
>  1 file changed, 21 insertions(+)

applied

thanks

[...]
-- 
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] [PATCH] lavf/matroskadec: Add early support for colour elements

[Michael Niedermayer]

On Thu, Mar 03, 2016 at 11:23:53PM -0800, Neil Birkbeck wrote:
> And yet another revision, where the syntax lists are actually terminated...

applied

thanks

[..]

-- 
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 v5 1/4 v3] lavf/avienc: Add support for palette side data

[Mats Peterson]

Mats Peterson  skrev: (4 mars 2016 22:12:41 
CET)
>On 03/04/2016 10:02 PM, Mats Peterson wrote:
>> On 03/04/2016 09:52 PM, Mats Peterson wrote:
>>> On 03/04/2016 08:44 PM, Michael Niedermayer wrote:
 On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:
> On 03/04/2016 05:59 AM, Mats Peterson wrote:
>> Removed some unused variables in AVIStream.
>>
>
>
> I would like to remind you of the fact that this patch (and the
>one
> for riffenc.c) is needed for stream copying of Microsoft Video 1
> (CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
> possibly more codecs using a palette, but these are the ones I can
> come up with at the moment.

 i tried CRAM and MSRLE, but these already work when streamcopied
 before, do you have a testcase that does not work

>>>
>>> It works, but only so much. On stream copy, it will only write the
>>> palette after BITMAPINFOHEADER to the destination file. It won't
>write
>>> any xxpc palette switching chunks to the file.
>>>
>>> Mats
>>>
>> The xxpc chunks come as palette side data.
>>
>> Mats
>
>
>Try ffmpeg -i 8bpp_129.avi -vcodec copy test.avi, with and without the 
>avienc.c and riffenc.c patch. The destination file will only contain 
>xxpc chunks with my patch applied.
>
>Mats
>
>
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

What's more, the whole idea with using a shared function for retrieval of the 
palette for a muxer was to enable a calling program to deliver it as side data, 
if desired.

Mats
-- 
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] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 06:48:04PM +0100, Thilo Borgmann wrote:
> Am 04.03.16 um 17:57 schrieb Timothy Gu:
> > On Fri, Mar 04, 2016 at 10:55:42AM +0100, Thilo Borgmann wrote:
> >> Am 04.03.16 um 08:58 schrieb wm4:
> >>>
> >>> Being able to see the, well, version in the version output (instead of
> >>> random numbers) sounds like a pretty convincing argument.
> >>
> >> Neither a good play on words nor elaborative; not even helpful.
> >>
> >> You say they are random numbers, CE says it is continuous. What is correct?
> > 
> > It is continuous. But to the user's eye, N-71234 is no different from 
> > N-41234,
> > and hence "random."
> 
> I assume that if there is no difference in the user's eye between
> N-71234 and N-41234 then there is also no difference for that user
> between dev-123 and dev-346.

That's not the point. The point is that there is something before the dev
part, and that's what makes the difference.

When I said "no different," I meant except the fact that N-71234 is obviously
newer. The fact that it fails to convey any additional information is the
issue we are trying to attack.

> 
> 
> >> So what about the release tag? Well it is a quite useful extension because 
> >> of
> >> the already mentioned possibility of determining the existing features at 
> >> once.
> >> I'm pro adding it to the version string.
> >>
> >> The tag-tag? (devxy) I don't see it anywhere except in git and therefore 
> >> it is
> >> uselessly redundant to the existing hash tag in my eyes. Why add another 
> >> more
> >> roughly estimation of the users repo-state? I don't think this should be 
> >> added
> >> to the version string.
> > 
> > Can you elaborate on this? I am not sure I understand everything you are
> > saying. Specfically, what is "devxy"?
> 
> The core concern about it is that is just redundant. I assume Timo to be
> correct about:
> 
> "A new dev tag is made every time a release is branched off, to indicate
> development of the next ffmpeg version started there, ..."
> 
> Then there is no gain of information in the dev-123 tag if there is
> already the release number given. In that case "v4.5-gdeabdef" tells me
> the very same as "v4.5-dev-123-gdeabdef" does. If Timo is correct, the
> can never be a "4.5-dev-789-abcdefg" tag. v4.5 is just enough.
> 
> Summing it all up for me, I think a release prefix would make perfect
> sense. Thus, switching from
> 
> N-12345-abcdefg
> 
> to
> 
> v4.5-N-12345-abcdefg
> 
> should be done for the sake of the users. There is at least CE wanting
> to stick with N-tags so why not? The only reason I can imagine for
> getting rid of N-tags and/or including dev-123 tags would be that a
> native git show command needs it to work properly as well as giving
> better human readable information.

I see where you are coming from. I will address this issue in my reply to
Reimar.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: allow subtitle text format to be ASS without timing

[Michael Niedermayer]

Now with ffmpeg-devel in CC

On Fri, Mar 04, 2016 at 04:37:41PM +0100, Clément Bœsch wrote:
> On Fri, Mar 04, 2016 at 04:22:44PM +0100, Michael Niedermayer wrote:
> > On Fri, Feb 26, 2016 at 10:01:51PM +0100, Clément Bœsch wrote:
> > > ffmpeg | branch: master | Clément Bœsch  | Wed Jan  6 
> > > 13:43:23 2016 +0100| [29412821241050c846dbceaad4b9752857659977] | 
> > > committer: Clément Bœsch
> > [...]
> > > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > > index 7a56899..d3e035a 100644
> > > --- a/libavcodec/avcodec.h
> > > +++ b/libavcodec/avcodec.h
> > > @@ -3285,6 +3285,10 @@ typedef struct AVCodecContext {
> > >  #define FF_SUB_CHARENC_MODE_AUTOMATIC0  ///< libavcodec will select 
> > > the mode itself
> > >  #define FF_SUB_CHARENC_MODE_PRE_DECODER  1  ///< the AVPacket data needs 
> > > to be recoded to UTF-8 before being fed to the decoder, requires iconv
> > >  
> > > +int sub_text_format;
> > > +#define FF_SUB_TEXT_FMT_ASS  0
> > > +#define FF_SUB_TEXT_FMT_ASS_WITH_TIMINGS 1
> > > +
> > >  /**
> > >   * Skip processing alpha if supported by codec.
> > >   * Note that if the format uses pre-multiplied alpha (common with 
> > > VP6,
> > 
> > doesnt this break ABI ?
> > 
> 
> Ah, mmmh... We're not that far away from the bottom, aren't all the
> following fields supposed to be accessed through AVoption or other
> accessors?
> 

> How to proceed here, should I just move it at the bottom of the struct
> since it was introduced recently?

moving it after all fields which can be directly accessed probably
unless i miss something
(fields not in 3.0 could be ignored as we just have to restore
 compatibility with 3.0)

i suspect thats more or less the same as "move it at the bottom "

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

Re: [FFmpeg-devel] [PATCH] tests/gapless: add gapless aac tests

[Marton Balint]

On Thu, 3 Mar 2016, Michael Niedermayer wrote:


On Thu, Mar 03, 2016 at 02:27:52AM +0100, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 tests/fate/gapless.mak | 3 +++
 tests/ref/fate/gapless-aac | 5 +
 2 files changed, 8 insertions(+)
 create mode 100644 tests/ref/fate/gapless-aac


seems to fail on x86-32

--- ffmpeg/tests/ref/fate/gapless-aac  2016-03-03 03:06:35.306048679 +0100
+++ tests/data/fate/gapless-aac 2016-03-03 03:11:56.286055441 +0100
@@ -1,5 +1,5 @@
9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-1
-d3c3c4ea121b3f3b8a346a168d2fec0e
+d00bed4d4a83ce1addb92c075b2fcaaf
9459e7dc74af1b451eb890686f04f262 *tests/data/fate/gapless-aac.out-2
-d3c3c4ea121b3f3b8a346a168d2fec0e
+d00bed4d4a83ce1addb92c075b2fcaaf
63dd86b78c8fbd22a99bf88583256bfe *tests/data/fate/gapless-aac.out-3
Test gapless-aac failed. Look at tests/data/fate/gapless-aac.err for details.
make: *** [fate-gapless-aac] Error 1


Hmm, it seems there is a tiny difference in the 145th sample of the first 
decoded frame. I thought this is not supposed to happen with the fixed 
point decoder. Anybody has any ideas?


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

Re: [FFmpeg-devel] [PATCH] configure: NVENC API version 6 is now required

[Michael Niedermayer]

On Fri, Mar 04, 2016 at 09:42:17PM +0100, Timo Rothenpieler wrote:
> ---
>  configure | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

LGTM

thx

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf: allow BSFs to drop packets.

[wm4]

On Fri, 4 Mar 2016 11:24:00 -0500
"Ronald S. Bultje"  wrote:

> Hi,
> 
> On Wed, Mar 2, 2016 at 4:11 PM, Ronald S. Bultje  wrote:
> 
> > Hi,
> >
> > On Wed, Mar 2, 2016 at 3:51 PM, wm4  wrote:
> >  
> >> On Wed, 2 Mar 2016 15:48:11 -0500
> >> "Ronald S. Bultje"  wrote:
> >>  
> >> > Hi,
> >> >
> >> > On Mon, Feb 29, 2016 at 10:32 AM, Ronald S. Bultje 
> >> > wrote:
> >> >  
> >> > > If pkt->size == 0 && pkt->side_data_elems == 0 after bsf->filter()
> >> > > returns, the packet is considered dropped.  
> >> >
> >> >
> >> > Ping?
> >> >  
> >>
> >> (Personally I'm not so fond of such subtle API changes, also doesn't
> >> Libav's glorious new BSF API cover this?)  
> >
> >
> > Possibly, but it's not in yet, is it?
> >
> > (We can revert this piece of code when their new API lands.)
> >  
> 
> Ping again?

I guess you can't wait for the Libav BSF change, but admittedly that
has an unknown time frame. But please add the changes in semantics to
apichanges.txt.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/04/2016 10:02 PM, Mats Peterson wrote:

On 03/04/2016 09:52 PM, Mats Peterson wrote:

On 03/04/2016 08:44 PM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:

On 03/04/2016 05:59 AM, Mats Peterson wrote:

Removed some unused variables in AVIStream.




I would like to remind you of the fact that this patch (and the one
for riffenc.c) is needed for stream copying of Microsoft Video 1
(CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
possibly more codecs using a palette, but these are the ones I can
come up with at the moment.


i tried CRAM and MSRLE, but these already work when streamcopied
before, do you have a testcase that does not work



It works, but only so much. On stream copy, it will only write the
palette after BITMAPINFOHEADER to the destination file. It won't write
any xxpc palette switching chunks to the file.

Mats


The xxpc chunks come as palette side data.

Mats



Try ffmpeg -i 8bpp_129.avi -vcodec copy test.avi, with and without the 
avienc.c and riffenc.c patch. The destination file will only contain 
xxpc chunks with my patch applied.


Mats


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

Re: [FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/04/2016 09:52 PM, Mats Peterson wrote:

On 03/04/2016 08:44 PM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:

On 03/04/2016 05:59 AM, Mats Peterson wrote:

Removed some unused variables in AVIStream.




I would like to remind you of the fact that this patch (and the one
for riffenc.c) is needed for stream copying of Microsoft Video 1
(CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
possibly more codecs using a palette, but these are the ones I can
come up with at the moment.


i tried CRAM and MSRLE, but these already work when streamcopied
before, do you have a testcase that does not work



It works, but only so much. On stream copy, it will only write the
palette after BITMAPINFOHEADER to the destination file. It won't write
any xxpc palette switching chunks to the file.

Mats


The xxpc chunks come as palette side data.

Mats

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf: allow BSFs to drop packets.

[Michael Niedermayer]

On Fri, Mar 04, 2016 at 11:24:00AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Mar 2, 2016 at 4:11 PM, Ronald S. Bultje  wrote:
> 
> > Hi,
> >
> > On Wed, Mar 2, 2016 at 3:51 PM, wm4  wrote:
> >
> >> On Wed, 2 Mar 2016 15:48:11 -0500
> >> "Ronald S. Bultje"  wrote:
> >>
> >> > Hi,
> >> >
> >> > On Mon, Feb 29, 2016 at 10:32 AM, Ronald S. Bultje 
> >> > wrote:
> >> >
> >> > > If pkt->size == 0 && pkt->side_data_elems == 0 after bsf->filter()
> >> > > returns, the packet is considered dropped.
> >> >
> >> >
> >> > Ping?
> >> >
> >>
> >> (Personally I'm not so fond of such subtle API changes, also doesn't
> >> Libav's glorious new BSF API cover this?)
> >
> >
> > Possibly, but it's not in yet, is it?
> >
> > (We can revert this piece of code when their new API lands.)
> >
> 
> Ping again?

the only thing on this patch set that gives me a slightly odd feeling
is that the droped case overlaps with a case that can be stored in
files, that is packets with size 0

otherwise patch LGTM

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

Re: [FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/04/2016 08:44 PM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:

On 03/04/2016 05:59 AM, Mats Peterson wrote:

Removed some unused variables in AVIStream.




I would like to remind you of the fact that this patch (and the one
for riffenc.c) is needed for stream copying of Microsoft Video 1
(CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
possibly more codecs using a palette, but these are the ones I can
come up with at the moment.


i tried CRAM and MSRLE, but these already work when streamcopied
before, do you have a testcase that does not work



It works, but only so much. On stream copy, it will only write the 
palette after BITMAPINFOHEADER to the destination file. It won't write 
any xxpc palette switching chunks to the file.


Mats

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

[FFmpeg-devel] [PATCH] configure: NVENC API version 6 is now required

[Timo Rothenpieler]

---
 configure | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 81769ee..9b56a4d 100755
--- a/configure
+++ b/configure
@@ -5681,8 +5681,8 @@ enabled mmal &&
 
 enabled netcdf&& require_pkg_config netcdf netcdf.h nc_inq_libvers
 enabled nvenc && { check_header nvEncodeAPI.h || die "ERROR: 
nvEncodeAPI.h not found."; } &&
- { check_cpp_condition nvEncodeAPI.h 
"NVENCAPI_MAJOR_VERSION >= 5" ||
-   die "ERROR: NVENC API version 4 or older is not 
supported"; } &&
+ { check_cpp_condition nvEncodeAPI.h 
"NVENCAPI_MAJOR_VERSION >= 6" ||
+   die "ERROR: NVENC API version 5 or older is not 
supported"; } &&
  { [ $target_os != cygwin ] || die "ERROR: NVENC 
is not supported on Cygwin currently."; }
 enabled openal&& { { for al_libs in "${OPENAL_LIBS}" "-lopenal" 
"-lOpenAL32"; do
check_lib 'AL/al.h' alGetError "${al_libs}" && 
break; done } ||
-- 
2.7.2

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

Re: [FFmpeg-devel] [PATCH] nvenc Fix H264 and HEVC vui info update

[Michael Niedermayer]

On Fri, Mar 04, 2016 at 05:08:07PM +0100, Timo Rothenpieler wrote:
> > breaks build here
> > 
> > libavcodec/nvenc.c: In function ‘nvenc_encode_init’:
> > libavcodec/nvenc.c:952:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> > ‘hevcVUIParameters’
> > libavcodec/nvenc.c:953:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> > ‘hevcVUIParameters’
> > libavcodec/nvenc.c:954:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> > ‘hevcVUIParameters’
> > libavcodec/nvenc.c:955:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> > ‘hevcVUIParameters’
> > libavcodec/nvenc.c:958:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> > ‘hevcVUIParameters’
> > libavcodec/nvenc.c:961:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> > ‘hevcVUIParameters’
> > libavcodec/nvenc.c:962:61: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> > ‘hevcVUIParameters’
> > libavcodec/nvenc.c:963:63: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> > ‘hevcVUIParameters’
> > libavcodec/nvenc.c:964:63: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> > ‘hevcVUIParameters’
> > CC  libavcodec/sbrdsp.o
> > 
> 
> Interesting, which SDK version is your nvEncodeApi.h?

i think the one used is:
#define NVENCAPI_MAJOR_VERSION 5
#define NVENCAPI_MINOR_VERSION 0


> I only tested this with version 6.0.1, maybe those fields aren't present
> in v5 headers?
> 
> If this is the case, I'd just bump the required SDK version.
> 



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


-- 
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] version.sh: Always use latest tag for generated version number

[Reimar Döffinger]

On 04.03.2016, at 11:24, Nicolas George  wrote:

> Le quintidi 15 ventôse, an CCXXIV, Thilo Borgmann a écrit :
>> Neither a good play on words nor elaborative; not even helpful.
>> 
>> You say they are random numbers, CE says it is continuous. What is correct?
>> 
>> Let's assume the N-tag is not random, then it is a useful extension of the
>> pinpointing short hash, since the hashes are not relative to each other (so 
>> to
>> speak random for the human eye) and therefore the N-tags are useful for
>> determining if the user is ahead or behind a certain commit. According to 
>> what
>> CE says, this helps for user support, Not? And if not, why would someone
>> spending most of the time helping users think otherwise?
>> Assuming my thoughts are not based on void assumptions, I'm against removing 
>> the
>> N-tag from the version string.
>> 
>> So what about the release tag? Well it is a quite useful extension because of
>> the already mentioned possibility of determining the existing features at 
>> once.
>> I'm pro adding it to the version string.
>> 
>> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it 
>> is
>> uselessly redundant to the existing hash tag in my eyes. Why add another more
>> roughly estimation of the users repo-state? I don't think this should be 
>> added
>> to the version string.
> 
> Replying here but not specifically to this mail.
> 
> We do not have to choose: there is no hard limit to the amount of
> information that can be encoded in the version, the version string can be
> arbitrarily long, as long as it is convenient.
> 
> The Git (short) hash carries all the information by itself, so it should be
> present. But extra, redundant, information can be added for the convenience
> of users and "supporters".
> 
> Basically, the version could be something like
> "g510046c:N78879-3.0master417-H20160303":

The formatting is rather ugly but I'd be in favour of something like that.
An attempt to order the information in increasing detail might be:
v3.0+417-D20160303-N78879-g510046c
Note that I'm not convinced the git describe info/branch info/number of commits 
since release is all that useful, but the base release version number seems 
nice to have.
Particularly the branch name can easily be misleading as it can be anyone's 
master, not necessarily the one on ffmpeg.org.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data

[Michael Niedermayer]

On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:
> On 03/04/2016 05:59 AM, Mats Peterson wrote:
> >Removed some unused variables in AVIStream.
> >
> 
> 
> I would like to remind you of the fact that this patch (and the one
> for riffenc.c) is needed for stream copying of Microsoft Video 1
> (CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
> possibly more codecs using a palette, but these are the ones I can
> come up with at the moment.

i tried CRAM and MSRLE, but these already work when streamcopied
before, do you have a testcase that does not work

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Nicolas George]

Le quintidi 15 ventôse, an CCXXIV, Timothy Gu a écrit :
> One object that can be raised against this is that the current versioning and
> the new versioning are both compatible with Git. Try
> 
> git show n3.1-dev-400-g3af71ac
> git show N-78863-g3af71ac

"git show 3af71ac" is enough. With my proposal, depending on the terminal
configuration, double-clicking on the hash would select it alone. Not having
the hash is of course not an option, I am sure we all agree on this point.

> But since the Git hash is already appended I don't see too much problem with
> that.

The thing is you have to think of convenience for everybody.

Think of users who do barely know what a command line is, let alone what Git
is: someone tells them to get a newer version of ffmpeg, they download it
from somewhere, they need to be able to know which one is more recent, and
by how much because upgrading from a three years old version to a two years
and a half one is a bit useless.

Think of advanced users replying on the mailing-lists, they have a Git tree
near at hand at home, but they want to trim their mail in the subway on
their phones.

Having as much information as possible directly at a glance is a benefit
(until it becomes too much information).

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Thilo Borgmann]

Am 04.03.16 um 17:57 schrieb Timothy Gu:
> On Fri, Mar 04, 2016 at 10:55:42AM +0100, Thilo Borgmann wrote:
>> Am 04.03.16 um 08:58 schrieb wm4:
>>>
>>> Being able to see the, well, version in the version output (instead of
>>> random numbers) sounds like a pretty convincing argument.
>>
>> Neither a good play on words nor elaborative; not even helpful.
>>
>> You say they are random numbers, CE says it is continuous. What is correct?
> 
> It is continuous. But to the user's eye, N-71234 is no different from N-41234,
> and hence "random."

I assume that if there is no difference in the user's eye between
N-71234 and N-41234 then there is also no difference for that user
between dev-123 and dev-346.


>> Let's assume the N-tag is not random, then it is a useful extension of the
>> pinpointing short hash, since the hashes are not relative to each other (so 
>> to
>> speak random for the human eye) and therefore the N-tags are useful for
>> determining if the user is ahead or behind a certain commit. According to 
>> what
>> CE says, this helps for user support, Not? And if not, why would someone
>> spending most of the time helping users think otherwise?
> 
> However, you miss the point that the new system allows one to do the same.
> 
> In the old system:
> 
> N-90001-gdeadbef
> N-9-gdeadbee
> N-8-gdeadbed
> 
> In the new system:
> 
> v4.5-dev-123-gdeadbef
> v4.5-dev-122-gdeadbee
> v4.0-dev-45-gdeadbed
> 
> As you can see, they are functionally equivalent: you can immediately tell
> that they are in descending order with both systems.
> 
>> Assuming my thoughts are not based on void assumptions, I'm against removing 
>> the
>> N-tag from the version string.
> 
> I hope I have demonstrated that your concern is mistaken.

Except for the benefit of dev-123 tags you have. Thank you!


>> So what about the release tag? Well it is a quite useful extension because of
>> the already mentioned possibility of determining the existing features at 
>> once.
>> I'm pro adding it to the version string.
>>
>> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it 
>> is
>> uselessly redundant to the existing hash tag in my eyes. Why add another more
>> roughly estimation of the users repo-state? I don't think this should be 
>> added
>> to the version string.
> 
> Can you elaborate on this? I am not sure I understand everything you are
> saying. Specfically, what is "devxy"?

The core concern about it is that is just redundant. I assume Timo to be
correct about:

"A new dev tag is made every time a release is branched off, to indicate
development of the next ffmpeg version started there, ..."

Then there is no gain of information in the dev-123 tag if there is
already the release number given. In that case "v4.5-gdeabdef" tells me
the very same as "v4.5-dev-123-gdeabdef" does. If Timo is correct, the
can never be a "4.5-dev-789-abcdefg" tag. v4.5 is just enough.

Summing it all up for me, I think a release prefix would make perfect
sense. Thus, switching from

N-12345-abcdefg

to

v4.5-N-12345-abcdefg

should be done for the sake of the users. There is at least CE wanting
to stick with N-tags so why not? The only reason I can imagine for
getting rid of N-tags and/or including dev-123 tags would be that a
native git show command needs it to work properly as well as giving
better human readable information.

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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 10:20:09AM +, Carl Eugen Hoyos wrote:
> Timo Rothenpieler  rothenpieler.org> writes:
> 
> > The current versioning scheme is indeed simple, but 
> > useless in almost all other aspects.
> 
> FFmpeg has a linear development scheme, how can you call 
> a continuous versioning scheme useless? It reflects 1:1 
> on how FFmpeg is developed.

1. FFmpeg does NOT have a linear development scheme. See `git log --merges`.
2. FFmpeg uses Git, which is inherently distributed and nonlinear.

Therefore your argument again is flawed.

> 
> > It gives no indication about what release it is close to
> 
> But the development here is not release-driven (note that 
> I am not saying it should or shouldn't be, I am just 
> describing how it does work for more than a decade), 
> just look at how the latest release was made: A random 
> snapshot was chosen, not even current known possible 
> security issues or regressions were relevant.

As I have said in my reply to your last mail, and as I will do so again,
whether or not release-driven FFmpeg is irrelevant to this conversation. The
versioning scheme is supposed to make people's life easier. It is NOT designed
to be the epitome of FFmpeg development policies.

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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 11:24:31AM +0100, Nicolas George wrote:
> Basically, the version could be something like
> "g510046c:N78879-3.0master417-H20160303":

One object that can be raised against this is that the current versioning and
the new versioning are both compatible with Git. Try

git show n3.1-dev-400-g3af71ac
git show N-78863-g3af71ac

But since the Git hash is already appended I don't see too much problem with
that.

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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 10:55:42AM +0100, Thilo Borgmann wrote:
> Am 04.03.16 um 08:58 schrieb wm4:
> > 
> > Being able to see the, well, version in the version output (instead of
> > random numbers) sounds like a pretty convincing argument.
> 
> Neither a good play on words nor elaborative; not even helpful.
> 
> You say they are random numbers, CE says it is continuous. What is correct?

It is continuous. But to the user's eye, N-71234 is no different from N-41234,
and hence "random."

> 
> Let's assume the N-tag is not random, then it is a useful extension of the
> pinpointing short hash, since the hashes are not relative to each other (so to
> speak random for the human eye) and therefore the N-tags are useful for
> determining if the user is ahead or behind a certain commit. According to what
> CE says, this helps for user support, Not? And if not, why would someone
> spending most of the time helping users think otherwise?

However, you miss the point that the new system allows one to do the same.

In the old system:

N-90001-gdeadbef
N-9-gdeadbee
N-8-gdeadbed

In the new system:

v4.5-dev-123-gdeadbef
v4.5-dev-122-gdeadbee
v4.0-dev-45-gdeadbed

As you can see, they are functionally equivalent: you can immediately tell
that they are in descending order with both systems.

> Assuming my thoughts are not based on void assumptions, I'm against removing 
> the
> N-tag from the version string.

I hope I have demonstrated that your concern is mistaken.

> So what about the release tag? Well it is a quite useful extension because of
> the already mentioned possibility of determining the existing features at 
> once.
> I'm pro adding it to the version string.
> 
> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it is
> uselessly redundant to the existing hash tag in my eyes. Why add another more
> roughly estimation of the users repo-state? I don't think this should be added
> to the version string.

Can you elaborate on this? I am not sure I understand everything you are
saying. Specfically, what is "devxy"?

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf: allow BSFs to drop packets.

[Ronald S. Bultje]

Hi,

On Wed, Mar 2, 2016 at 4:11 PM, Ronald S. Bultje  wrote:

> Hi,
>
> On Wed, Mar 2, 2016 at 3:51 PM, wm4  wrote:
>
>> On Wed, 2 Mar 2016 15:48:11 -0500
>> "Ronald S. Bultje"  wrote:
>>
>> > Hi,
>> >
>> > On Mon, Feb 29, 2016 at 10:32 AM, Ronald S. Bultje 
>> > wrote:
>> >
>> > > If pkt->size == 0 && pkt->side_data_elems == 0 after bsf->filter()
>> > > returns, the packet is considered dropped.
>> >
>> >
>> > Ping?
>> >
>>
>> (Personally I'm not so fond of such subtle API changes, also doesn't
>> Libav's glorious new BSF API cover this?)
>
>
> Possibly, but it's not in yet, is it?
>
> (We can revert this piece of code when their new API lands.)
>

Ping again?

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

Re: [FFmpeg-devel] [PATCH] avformat: Add a protocol blacklisting API

[Derek Buitenhuis]

On 3/4/2016 3:02 PM, James Almer wrote:
> ry to non break ABI just yet, leave it as last resort. We did it not even
> half a year ago, and we'd have to push every single scheduled deprecation.
> If this can be resolved moving only the new entries then that's preferable.

OK I did it this way.

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

Re: [FFmpeg-devel] [PATCH] nvenc Fix H264 and HEVC vui info update

[Timo Rothenpieler]

> breaks build here
> 
> libavcodec/nvenc.c: In function ‘nvenc_encode_init’:
> libavcodec/nvenc.c:952:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> ‘hevcVUIParameters’
> libavcodec/nvenc.c:953:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> ‘hevcVUIParameters’
> libavcodec/nvenc.c:954:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> ‘hevcVUIParameters’
> libavcodec/nvenc.c:955:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> ‘hevcVUIParameters’
> libavcodec/nvenc.c:958:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> ‘hevcVUIParameters’
> libavcodec/nvenc.c:961:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> ‘hevcVUIParameters’
> libavcodec/nvenc.c:962:61: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> ‘hevcVUIParameters’
> libavcodec/nvenc.c:963:63: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> ‘hevcVUIParameters’
> libavcodec/nvenc.c:964:63: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
> ‘hevcVUIParameters’
> CC  libavcodec/sbrdsp.o
> 

Interesting, which SDK version is your nvEncodeApi.h?
I only tested this with version 6.0.1, maybe those fields aren't present
in v5 headers?

If this is the case, I'd just bump the required SDK version.



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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: allow subtitle text format to be ASS without timing

[Clément Bœsch]

On Fri, Mar 04, 2016 at 04:22:44PM +0100, Michael Niedermayer wrote:
> On Fri, Feb 26, 2016 at 10:01:51PM +0100, Clément Bœsch wrote:
> > ffmpeg | branch: master | Clément Bœsch  | Wed Jan  6 13:43:23 
> > 2016 +0100| [29412821241050c846dbceaad4b9752857659977] | committer: Clément 
> > Bœsch
> [...]
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 7a56899..d3e035a 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -3285,6 +3285,10 @@ typedef struct AVCodecContext {
> >  #define FF_SUB_CHARENC_MODE_AUTOMATIC0  ///< libavcodec will select 
> > the mode itself
> >  #define FF_SUB_CHARENC_MODE_PRE_DECODER  1  ///< the AVPacket data needs 
> > to be recoded to UTF-8 before being fed to the decoder, requires iconv
> >  
> > +int sub_text_format;
> > +#define FF_SUB_TEXT_FMT_ASS  0
> > +#define FF_SUB_TEXT_FMT_ASS_WITH_TIMINGS 1
> > +
> >  /**
> >   * Skip processing alpha if supported by codec.
> >   * Note that if the format uses pre-multiplied alpha (common with VP6,
> 
> doesnt this break ABI ?
> 

Ah, mmmh... We're not that far away from the bottom, aren't all the
following fields supposed to be accessed through AVoption or other
accessors?

How to proceed here, should I just move it at the bottom of the struct
since it was introduced recently?

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] nvenc Fix H264 and HEVC vui info update

[Michael Niedermayer]

On Fri, Mar 04, 2016 at 10:51:10AM +0100, Timo Rothenpieler wrote:
> >>
> >> In case of the git send-email sends corrupted patch again, I attach the 
> >> original patch file.
> >>
> >> Agatha Hu
> >>
> > 
> > That's strange, does anyone received my patch sent at 17:22 GMT+8?
> > Looks like the first mail (sent by git sent-email, no attachment) was 
> > somehow blocked.
> > 
> > Agatha Hu
> 
> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/190764.html that one?
> 
> Also, applied.

breaks build here

libavcodec/nvenc.c: In function ‘nvenc_encode_init’:
libavcodec/nvenc.c:952:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
‘hevcVUIParameters’
libavcodec/nvenc.c:953:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
‘hevcVUIParameters’
libavcodec/nvenc.c:954:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
‘hevcVUIParameters’
libavcodec/nvenc.c:955:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
‘hevcVUIParameters’
libavcodec/nvenc.c:958:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
‘hevcVUIParameters’
libavcodec/nvenc.c:961:56: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
‘hevcVUIParameters’
libavcodec/nvenc.c:962:61: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
‘hevcVUIParameters’
libavcodec/nvenc.c:963:63: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
‘hevcVUIParameters’
libavcodec/nvenc.c:964:63: error: ‘NV_ENC_CONFIG_HEVC’ has no member named 
‘hevcVUIParameters’
CC  libavcodec/sbrdsp.o

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"


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: Add a protocol blacklisting API

[James Almer]

On 3/4/2016 10:34 AM, Derek Buitenhuis wrote:
> On 3/3/2016 7:50 PM, Michael Niedermayer wrote:
>> The io_open/close callbacks afterwards seem direct access IIUC
>> so its not possible to remove or add any fields prior
>>
>> though maybe they have been added so recently that its ok to move
>> them above all "no direct access" fields
>> or maybe iam missing something
> 
> Crap. I must have screwed up when merging those callbacks. I can move
> the be blacklist entry under them, or I can break ABI and move both,
> since I don't think there is release.

Try to non break ABI just yet, leave it as last resort. We did it not even
half a year ago, and we'd have to push every single scheduled deprecation.
If this can be resolved moving only the new entries then that's preferable.

> 
> Which do people prefer? They're both kinda meh.
> 
> - Derek
> ___
> 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] avcodec: Extend fft to size 2^17

[Ronald S. Bultje]

Hi,

On Fri, Mar 4, 2016 at 7:52 AM, Paul B Mahol  wrote:

> On 3/4/16, wm4  wrote:
> > On Fri, 4 Mar 2016 13:12:45 +0100
> > Paul B Mahol  wrote:
> >
> >> On 3/4/16, Michael Niedermayer  wrote:
> >> > On Fri, Mar 04, 2016 at 11:21:23AM +0100, Paul B Mahol wrote:
> >> >> On 3/4/16, Michael Niedermayer  wrote:
> >> >> > Hi
> >> >> >
> >> >> > patch to extend fft is attached (my git-send email atm doesnt work
> >> >> > thanks to my ISP)
> >> >> >
> >> >> > --
> >> >> > Michael GnuPG fingerprint:
> >> >> > 9FF2128B147EF6730BADF133611EC787040B0FAB
> >> >> >
> >> >> > I know you won't believe me, but the highest form of Human
> Excellence
> >> >> > is
> >> >> > to question oneself and others. -- Socrates
> >> >> >
> >> >>
> >> >> This crashes whenever I tried to use it with sofalizer/afftfilt:
> >> >
> >> > fixed with af_afftfilt and applied
> >> >
> >> >
> >> > sofalizer just crashes here even wthout any changes:
> >>
> >> That's their awful library.
> >
> > Oh really? Are you sure they allow passing a NULL filename to their
> > open function?
> >
>
> It allows here, but Michael version is older.


configure version check seems like a sane thing to add. Possibly even a
runtime check just to be sure. "ffmpeg crashed" never looks good.

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

Re: [FFmpeg-devel] [PATCH] avformat: Add a protocol blacklisting API

[Derek Buitenhuis]

On 3/3/2016 7:50 PM, Michael Niedermayer wrote:
> The io_open/close callbacks afterwards seem direct access IIUC
> so its not possible to remove or add any fields prior
> 
> though maybe they have been added so recently that its ok to move
> them above all "no direct access" fields
> or maybe iam missing something

Crap. I must have screwed up when merging those callbacks. I can move
the be blacklist entry under them, or I can break ABI and move both,
since I don't think there is release.

Which do people prefer? They're both kinda meh.

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

Re: [FFmpeg-devel] [PATCH] avcodec: Extend fft to size 2^17

[Paul B Mahol]

On 3/4/16, wm4  wrote:
> On Fri, 4 Mar 2016 13:12:45 +0100
> Paul B Mahol  wrote:
>
>> On 3/4/16, Michael Niedermayer  wrote:
>> > On Fri, Mar 04, 2016 at 11:21:23AM +0100, Paul B Mahol wrote:
>> >> On 3/4/16, Michael Niedermayer  wrote:
>> >> > Hi
>> >> >
>> >> > patch to extend fft is attached (my git-send email atm doesnt work
>> >> > thanks to my ISP)
>> >> >
>> >> > --
>> >> > Michael GnuPG fingerprint:
>> >> > 9FF2128B147EF6730BADF133611EC787040B0FAB
>> >> >
>> >> > I know you won't believe me, but the highest form of Human Excellence
>> >> > is
>> >> > to question oneself and others. -- Socrates
>> >> >
>> >>
>> >> This crashes whenever I tried to use it with sofalizer/afftfilt:
>> >
>> > fixed with af_afftfilt and applied
>> >
>> >
>> > sofalizer just crashes here even wthout any changes:
>>
>> That's their awful library.
>
> Oh really? Are you sure they allow passing a NULL filename to their
> open function?
>

It allows here, but Michael version is older.
___
> 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] avcodec: Extend fft to size 2^17

[wm4]

On Fri, 4 Mar 2016 13:12:45 +0100
Paul B Mahol  wrote:

> On 3/4/16, Michael Niedermayer  wrote:
> > On Fri, Mar 04, 2016 at 11:21:23AM +0100, Paul B Mahol wrote:  
> >> On 3/4/16, Michael Niedermayer  wrote:  
> >> > Hi
> >> >
> >> > patch to extend fft is attached (my git-send email atm doesnt work
> >> > thanks to my ISP)
> >> >
> >> > --
> >> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >> >
> >> > I know you won't believe me, but the highest form of Human Excellence
> >> > is
> >> > to question oneself and others. -- Socrates
> >> >  
> >>
> >> This crashes whenever I tried to use it with sofalizer/afftfilt:  
> >
> > fixed with af_afftfilt and applied
> >
> >
> > sofalizer just crashes here even wthout any changes:  
> 
> That's their awful library.

Oh really? Are you sure they allow passing a NULL filename to their
open function?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: Extend fft to size 2^17

[Paul B Mahol]

On 3/4/16, Michael Niedermayer  wrote:
> On Fri, Mar 04, 2016 at 11:21:23AM +0100, Paul B Mahol wrote:
>> On 3/4/16, Michael Niedermayer  wrote:
>> > Hi
>> >
>> > patch to extend fft is attached (my git-send email atm doesnt work
>> > thanks to my ISP)
>> >
>> > --
>> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>> >
>> > I know you won't believe me, but the highest form of Human Excellence
>> > is
>> > to question oneself and others. -- Socrates
>> >
>>
>> This crashes whenever I tried to use it with sofalizer/afftfilt:
>
> fixed with af_afftfilt and applied
>
>
> sofalizer just crashes here even wthout any changes:

That's their awful library.

> #0  0x750b447f in clearnccache () from /usr/lib/libnetcdf.so.6
> #1  0x750af68d in freeNCDRNO3 () from /usr/lib/libnetcdf.so.6
> #2  0x750c34f7 in nc4d_open_file () from /usr/lib/libnetcdf.so.6
> #3  0x75076d1f in nc_open () from /usr/lib/libnetcdf.so.6
> #4  0x0042cf91 in load_sofa (ctx=0x7fffd8008040, filename=0x0,
> samplingrate=0x7fffd8008148) at libavfilter/af_sofalizer.c:137
> #5  0x0042d8b4 in init (ctx=0x7fffd8008040) at
> libavfilter/af_sofalizer.c:936
> #6  0x004cb49b in avfilter_init_str (filter=0x7fffd8008040,
> args=) at libavfilter/avfilter.c:992
> #7  0x004d9052 in create_filter (filt_ctx=0x7fffddf8c6f0,
> ctx=0x7fffd8129840, index=, filt_name=,
> args=0x0, log_ctx=0x0) at libavfilter/graphparser.c:133
> #8  0x004da1d3 in parse_filter (log_ctx=0x0, index=0,
> graph=0x7fffd8129840, buf=0x7fffddf8c6c8, filt_ctx=0x7fffddf8c6f0) at
> libavfilter/graphparser.c:176
> #9  avfilter_graph_parse_ptr (graph=0x7fffd8129840, filters=0x1eda7c9 "",
> open_inputs_ptr=0x7fffddf8c758, open_outputs_ptr=0x7fffddf8c750,
> log_ctx=0x0) at libavfilter/graphparser.c:544
> #10 0x004a8a31 in configure_filtergraph (graph=0x7fffd8129840,
> filtergraph=0x1eda7c0 "sofalizer", source_ctx=,
> sink_ctx=) at ffplay.c:1884
> #11 0x004a8f2b in configure_audio_filters (is=0x7fffe1e8d040,
> afilters=0x1eda7c0 "sofalizer", force_output_format=0) at ffplay.c:2062
> #12 0x004ae4e7 in stream_component_open (is=0x7fffe1e8d040,
> stream_index=2) at ffplay.c:2729
> #13 0x004aef74 in read_thread (arg=0x7fffe1e8d040) at ffplay.c:2975
> #14 0x75e80055 in ?? () from
> /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
> #15 0x75ec3a89 in ?? () from
> /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
> #16 0x7fffecc40e9a in start_thread () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> #17 0x7fffec96e38d in clone () from /lib/x86_64-linux-gnu/libc.so.6
> #18 0x in ?? ()
>
>
>
>>
>> ==24326== Jump to the invalid address stated on the next line
>> ==24326==at 0xEF83490005E6E2B8: ???
>> ==24326==by 0x5F4BF5F: ff_fft_calc_avx (fft.asm:562)
>> ==24326==by 0x508AC34: filter_frame (af_afftfilt.c:242)
>> ==24326==by 0x50C422D: ff_filter_frame_framed (avfilter.c:1123)
>> ==24326==by 0x50C576D: ff_filter_frame (avfilter.c:1221)
>> ==24326==by 0x50C9D4A: request_frame (buffersrc.c:450)
>> ==24326==by 0x50C98A9: av_buffersrc_add_frame_internal
>> (buffersrc.c:239)
>> ==24326==by 0x50C9635: av_buffersrc_add_frame_flags (buffersrc.c:164)
>> ==24326==by 0x421F8B: decode_audio (ffmpeg.c:2046)
>> ==24326==by 0x421F8B: process_input_packet (ffmpeg.c:2325)
>> ==24326==by 0x41E047: process_input (ffmpeg.c:3998)
>> ==24326==by 0x41E047: transcode_step (ffmpeg.c:4086)
>> ==24326==by 0x41E047: transcode (ffmpeg.c:4140)
>> ==24326==by 0x419331: main (ffmpeg.c:4331)
>> ==24326==  Address 0xef83490005e6e2b8 is not stack'd, malloc'd or
>> (recently) free'd
>> ==24326==
>> ==24326==
>> ==24326== Process terminating with default action of signal 11 (SIGSEGV)
>> ==24326==  Bad permissions for mapped region at address
>> 0xEF83490005E6E2B8
>> ==24326==at 0xEF83490005E6E2B8: ???
>> ==24326==by 0x5F4BF5F: ff_fft_calc_avx (fft.asm:562)
>> ==24326==by 0x508AC34: filter_frame (af_afftfilt.c:242)
>> ==24326==by 0x50C422D: ff_filter_frame_framed (avfilter.c:1123)
>> ==24326==by 0x50C576D: ff_filter_frame (avfilter.c:1221)
>> ==24326==by 0x50C9D4A: request_frame (buffersrc.c:450)
>> ==24326==by 0x50C98A9: av_buffersrc_add_frame_internal
>> (buffersrc.c:239)
>> ==24326==by 0x50C9635: av_buffersrc_add_frame_flags (buffersrc.c:164)
>> ==24326==by 0x421F8B: decode_audio (ffmpeg.c:2046)
>> ==24326==by 0x421F8B: process_input_packet (ffmpeg.c:2325)
>> ==24326==by 0x41E047: process_input (ffmpeg.c:3998)
>> ==24326==by 0x41E047: transcode_step (ffmpeg.c:4086)
>> ==24326==by 0x41E047: transcode (ffmpeg.c:4140)
>> ==24326==by 0x419331: main (ffmpeg.c:4331)
>> ==24326==
>> ==24326== HEAP SUMMARY:
>> ==24326== in use at exit: 10,552,359 bytes in 2,983 blocks
>> ==24326==   total heap usage: 4,458 allocs, 1,475 frees, 11,530,798
>> 

Re: [FFmpeg-devel] [PATCH] avcodec: Extend fft to size 2^17

[Michael Niedermayer]

On Fri, Mar 04, 2016 at 11:21:23AM +0100, Paul B Mahol wrote:
> On 3/4/16, Michael Niedermayer  wrote:
> > Hi
> >
> > patch to extend fft is attached (my git-send email atm doesnt work
> > thanks to my ISP)
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > I know you won't believe me, but the highest form of Human Excellence is
> > to question oneself and others. -- Socrates
> >
> 
> This crashes whenever I tried to use it with sofalizer/afftfilt:

fixed with af_afftfilt and applied


sofalizer just crashes here even wthout any changes:
#0  0x750b447f in clearnccache () from /usr/lib/libnetcdf.so.6
#1  0x750af68d in freeNCDRNO3 () from /usr/lib/libnetcdf.so.6
#2  0x750c34f7 in nc4d_open_file () from /usr/lib/libnetcdf.so.6
#3  0x75076d1f in nc_open () from /usr/lib/libnetcdf.so.6
#4  0x0042cf91 in load_sofa (ctx=0x7fffd8008040, filename=0x0, 
samplingrate=0x7fffd8008148) at libavfilter/af_sofalizer.c:137
#5  0x0042d8b4 in init (ctx=0x7fffd8008040) at 
libavfilter/af_sofalizer.c:936
#6  0x004cb49b in avfilter_init_str (filter=0x7fffd8008040, 
args=) at libavfilter/avfilter.c:992
#7  0x004d9052 in create_filter (filt_ctx=0x7fffddf8c6f0, 
ctx=0x7fffd8129840, index=, filt_name=, args=0x0, 
log_ctx=0x0) at libavfilter/graphparser.c:133
#8  0x004da1d3 in parse_filter (log_ctx=0x0, index=0, 
graph=0x7fffd8129840, buf=0x7fffddf8c6c8, filt_ctx=0x7fffddf8c6f0) at 
libavfilter/graphparser.c:176
#9  avfilter_graph_parse_ptr (graph=0x7fffd8129840, filters=0x1eda7c9 "", 
open_inputs_ptr=0x7fffddf8c758, open_outputs_ptr=0x7fffddf8c750, log_ctx=0x0) 
at libavfilter/graphparser.c:544
#10 0x004a8a31 in configure_filtergraph (graph=0x7fffd8129840, 
filtergraph=0x1eda7c0 "sofalizer", source_ctx=, 
sink_ctx=) at ffplay.c:1884
#11 0x004a8f2b in configure_audio_filters (is=0x7fffe1e8d040, 
afilters=0x1eda7c0 "sofalizer", force_output_format=0) at ffplay.c:2062
#12 0x004ae4e7 in stream_component_open (is=0x7fffe1e8d040, 
stream_index=2) at ffplay.c:2729
#13 0x004aef74 in read_thread (arg=0x7fffe1e8d040) at ffplay.c:2975
#14 0x75e80055 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#15 0x75ec3a89 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
#16 0x7fffecc40e9a in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#17 0x7fffec96e38d in clone () from /lib/x86_64-linux-gnu/libc.so.6
#18 0x in ?? ()



> 
> ==24326== Jump to the invalid address stated on the next line
> ==24326==at 0xEF83490005E6E2B8: ???
> ==24326==by 0x5F4BF5F: ff_fft_calc_avx (fft.asm:562)
> ==24326==by 0x508AC34: filter_frame (af_afftfilt.c:242)
> ==24326==by 0x50C422D: ff_filter_frame_framed (avfilter.c:1123)
> ==24326==by 0x50C576D: ff_filter_frame (avfilter.c:1221)
> ==24326==by 0x50C9D4A: request_frame (buffersrc.c:450)
> ==24326==by 0x50C98A9: av_buffersrc_add_frame_internal (buffersrc.c:239)
> ==24326==by 0x50C9635: av_buffersrc_add_frame_flags (buffersrc.c:164)
> ==24326==by 0x421F8B: decode_audio (ffmpeg.c:2046)
> ==24326==by 0x421F8B: process_input_packet (ffmpeg.c:2325)
> ==24326==by 0x41E047: process_input (ffmpeg.c:3998)
> ==24326==by 0x41E047: transcode_step (ffmpeg.c:4086)
> ==24326==by 0x41E047: transcode (ffmpeg.c:4140)
> ==24326==by 0x419331: main (ffmpeg.c:4331)
> ==24326==  Address 0xef83490005e6e2b8 is not stack'd, malloc'd or
> (recently) free'd
> ==24326==
> ==24326==
> ==24326== Process terminating with default action of signal 11 (SIGSEGV)
> ==24326==  Bad permissions for mapped region at address 0xEF83490005E6E2B8
> ==24326==at 0xEF83490005E6E2B8: ???
> ==24326==by 0x5F4BF5F: ff_fft_calc_avx (fft.asm:562)
> ==24326==by 0x508AC34: filter_frame (af_afftfilt.c:242)
> ==24326==by 0x50C422D: ff_filter_frame_framed (avfilter.c:1123)
> ==24326==by 0x50C576D: ff_filter_frame (avfilter.c:1221)
> ==24326==by 0x50C9D4A: request_frame (buffersrc.c:450)
> ==24326==by 0x50C98A9: av_buffersrc_add_frame_internal (buffersrc.c:239)
> ==24326==by 0x50C9635: av_buffersrc_add_frame_flags (buffersrc.c:164)
> ==24326==by 0x421F8B: decode_audio (ffmpeg.c:2046)
> ==24326==by 0x421F8B: process_input_packet (ffmpeg.c:2325)
> ==24326==by 0x41E047: process_input (ffmpeg.c:3998)
> ==24326==by 0x41E047: transcode_step (ffmpeg.c:4086)
> ==24326==by 0x41E047: transcode (ffmpeg.c:4140)
> ==24326==by 0x419331: main (ffmpeg.c:4331)
> ==24326==
> ==24326== HEAP SUMMARY:
> ==24326== in use at exit: 10,552,359 bytes in 2,983 blocks
> ==24326==   total heap usage: 4,458 allocs, 1,475 frees, 11,530,798
> bytes allocated
> ==24326==
> ==24326== LEAK SUMMARY:
> ==24326==definitely lost: 0 bytes in 0 blocks
> ==24326==indirectly lost: 0 bytes in 0 blocks
> ==24326==  possibly lost: 1,680 bytes in 5 blocks
> ==24326==

Re: [FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/04/2016 05:59 AM, Mats Peterson wrote:

Removed some unused variables in AVIStream.




I would like to remind you of the fact that this patch (and the one for 
riffenc.c) is needed for stream copying of Microsoft Video 1 (CRAM) in 
8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are possibly more 
codecs using a palette, but these are the ones I can come up with at the 
moment.


Mats

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

Re: [FFmpeg-devel] Libavcodec consulting

[Eran Kornblau]

> 
> Thanks for that clarification. Unfortunately the http server is a third
> party camera that broadcasts a WiFi hotspot. Therefore we don't really
> have control over the underlying server. However, what I do know is
> that the ffmpeg command I quoted previously seems to be able to
> grab a chunk of a video anywhere in the file without downloading the
> whole thing. So I assume libav must also be capable.
>
The nginx module we develop https://github.com/kaltura/nginx-vod-module 
has the capability to efficiently clip MP4 files - 
1. It downloads the index (moov atom) whether it's in the beginning of the file 
or at its end
2. It generates a new 'clipped' index for the output video
3. It determines the relevant range of the video/audio frames in the original
file, and serves it to the client

In addition, this module has the ability to work in remote mode - it can pull 
the 
relevant sections of the file using HTTP range requests.
So, easiest solution, assuming you can set up some server (and you don't have 
to provide a client-only solution) would be to set up such a "clipping proxy"
and have the mobile app simply download the clip from the proxy (providing 
the clipping from/to offsets)
If a server solution is not option, you can still use our code as a reference 
for 
the implementation.

Btw, nginx has a built-in module for clipping MP4 files - 
http://nginx.org/en/docs/http/ngx_http_mp4_module.html 
But our module has several advantages compared to built-in version, incl:
1. Support for remote (HTTP) MP4 files
2. Support for MP4 files in which the index is at the end of the file

Hope this helps

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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Nicolas George]

Le quintidi 15 ventôse, an CCXXIV, Thilo Borgmann a écrit :
> Neither a good play on words nor elaborative; not even helpful.
> 
> You say they are random numbers, CE says it is continuous. What is correct?
> 
> Let's assume the N-tag is not random, then it is a useful extension of the
> pinpointing short hash, since the hashes are not relative to each other (so to
> speak random for the human eye) and therefore the N-tags are useful for
> determining if the user is ahead or behind a certain commit. According to what
> CE says, this helps for user support, Not? And if not, why would someone
> spending most of the time helping users think otherwise?
> Assuming my thoughts are not based on void assumptions, I'm against removing 
> the
> N-tag from the version string.
> 
> So what about the release tag? Well it is a quite useful extension because of
> the already mentioned possibility of determining the existing features at 
> once.
> I'm pro adding it to the version string.
> 
> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it is
> uselessly redundant to the existing hash tag in my eyes. Why add another more
> roughly estimation of the users repo-state? I don't think this should be added
> to the version string.

Replying here but not specifically to this mail.

We do not have to choose: there is no hard limit to the amount of
information that can be encoded in the version, the version string can be
arbitrarily long, as long as it is convenient.

The Git (short) hash carries all the information by itself, so it should be
present. But extra, redundant, information can be added for the convenience
of users and "supporters".

Basically, the version could be something like
"g510046c:N78879-3.0master417-H20160303":

- the Git hash is there;

- the strictly increasing count from the N tag is there, Carl Eugen is
  happy;

- 3.0dev417 means "on branch master, 417 commits since branch 3.0 was
  forked" (maybe a better syntax can be found), users who want an estimate
  of the relation between releases and Git snapshots are happy;

- H20160303 is the approximate timestamp of the head commit (preferably the
  CommitDate rather than the AuthorDate), users who want to know how old is
  their version are happy.

Also, we could have a parsing script in tools to translate that into
human-readable information, and possibly fill in the blanks if it has access
to a Git repository. Bonus point if a version of this script is available
online as a CGI.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Carl Eugen Hoyos]

Timo Rothenpieler  rothenpieler.org> writes:

> The current versioning scheme is indeed simple, but 
> useless in almost all other aspects.

FFmpeg has a linear development scheme, how can you call 
a continuous versioning scheme useless? It reflects 1:1 
on how FFmpeg is developed.

> It gives no indication about what release it is close to

But the development here is not release-driven (note that 
I am not saying it should or shouldn't be, I am just 
describing how it does work for more than a decade), 
just look at how the latest release was made: A random 
snapshot was chosen, not even current known possible 
security issues or regressions were relevant.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Thilo Borgmann]

You are skipping everything I think about N-tags you want to patch away... why?

Am 04.03.16 um 11:07 schrieb Timo Rothenpieler:
>> So what about the release tag? Well it is a quite useful extension because of
>> the already mentioned possibility of determining the existing features at 
>> once.
>> I'm pro adding it to the version string.
> 
> The release tags are not made in the master branch, so git describe
> won't pick them up.
> They also don't have a meaning for master, as there are distinct commits
> between the two.

The reason for the version tag is the user, not? The user does not care about
git describe, teh user wants teh release number in his version string.
If I read you correctly you are arguing in some way against your own change?
(not haveing the release tag?)


>> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it 
>> is
>> uselessly redundant to the existing hash tag in my eyes. Why add another more
>> roughly estimation of the users repo-state? I don't think this should be 
>> added
>> to the version string.
> 
> A new dev tag is made every time a release is branched off, to indicate
> development of the next ffmpeg version started there, so using it for
> the version number seems natural to me.

I still see no benefit in adding it. If there is the release tag, I don't need
this because they are redundant. If there is no release tag, the user would
manually find the release number for this tag, not?

-Thilo

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

Re: [FFmpeg-devel] [PATCH] avcodec: Extend fft to size 2^17

[Paul B Mahol]

On 3/4/16, Michael Niedermayer  wrote:
> Hi
>
> patch to extend fft is attached (my git-send email atm doesnt work
> thanks to my ISP)
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I know you won't believe me, but the highest form of Human Excellence is
> to question oneself and others. -- Socrates
>

This crashes whenever I tried to use it with sofalizer/afftfilt:

==24326== Jump to the invalid address stated on the next line
==24326==at 0xEF83490005E6E2B8: ???
==24326==by 0x5F4BF5F: ff_fft_calc_avx (fft.asm:562)
==24326==by 0x508AC34: filter_frame (af_afftfilt.c:242)
==24326==by 0x50C422D: ff_filter_frame_framed (avfilter.c:1123)
==24326==by 0x50C576D: ff_filter_frame (avfilter.c:1221)
==24326==by 0x50C9D4A: request_frame (buffersrc.c:450)
==24326==by 0x50C98A9: av_buffersrc_add_frame_internal (buffersrc.c:239)
==24326==by 0x50C9635: av_buffersrc_add_frame_flags (buffersrc.c:164)
==24326==by 0x421F8B: decode_audio (ffmpeg.c:2046)
==24326==by 0x421F8B: process_input_packet (ffmpeg.c:2325)
==24326==by 0x41E047: process_input (ffmpeg.c:3998)
==24326==by 0x41E047: transcode_step (ffmpeg.c:4086)
==24326==by 0x41E047: transcode (ffmpeg.c:4140)
==24326==by 0x419331: main (ffmpeg.c:4331)
==24326==  Address 0xef83490005e6e2b8 is not stack'd, malloc'd or
(recently) free'd
==24326==
==24326==
==24326== Process terminating with default action of signal 11 (SIGSEGV)
==24326==  Bad permissions for mapped region at address 0xEF83490005E6E2B8
==24326==at 0xEF83490005E6E2B8: ???
==24326==by 0x5F4BF5F: ff_fft_calc_avx (fft.asm:562)
==24326==by 0x508AC34: filter_frame (af_afftfilt.c:242)
==24326==by 0x50C422D: ff_filter_frame_framed (avfilter.c:1123)
==24326==by 0x50C576D: ff_filter_frame (avfilter.c:1221)
==24326==by 0x50C9D4A: request_frame (buffersrc.c:450)
==24326==by 0x50C98A9: av_buffersrc_add_frame_internal (buffersrc.c:239)
==24326==by 0x50C9635: av_buffersrc_add_frame_flags (buffersrc.c:164)
==24326==by 0x421F8B: decode_audio (ffmpeg.c:2046)
==24326==by 0x421F8B: process_input_packet (ffmpeg.c:2325)
==24326==by 0x41E047: process_input (ffmpeg.c:3998)
==24326==by 0x41E047: transcode_step (ffmpeg.c:4086)
==24326==by 0x41E047: transcode (ffmpeg.c:4140)
==24326==by 0x419331: main (ffmpeg.c:4331)
==24326==
==24326== HEAP SUMMARY:
==24326== in use at exit: 10,552,359 bytes in 2,983 blocks
==24326==   total heap usage: 4,458 allocs, 1,475 frees, 11,530,798
bytes allocated
==24326==
==24326== LEAK SUMMARY:
==24326==definitely lost: 0 bytes in 0 blocks
==24326==indirectly lost: 0 bytes in 0 blocks
==24326==  possibly lost: 1,680 bytes in 5 blocks
==24326==still reachable: 10,550,679 bytes in 2,978 blocks
==24326== suppressed: 0 bytes in 0 blocks
==24326== Rerun with --leak-check=full to see details of leaked memory
==24326==
==24326== For counts of detected and suppressed errors, rerun with: -v
==24326== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Killed

Setting cpuflags to 0 gives output with heavy artifacts.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Carl Eugen Hoyos]

wm4  googlemail.com> writes:

> Being able to see the, well, version in the version output 
> (instead of random numbers)

What is random about the version number using current FFmpeg?

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timo Rothenpieler]

> So what about the release tag? Well it is a quite useful extension because of
> the already mentioned possibility of determining the existing features at 
> once.
> I'm pro adding it to the version string.

The release tags are not made in the master branch, so git describe
won't pick them up.
They also don't have a meaning for master, as there are distinct commits
between the two.

> The tag-tag? (devxy) I don't see it anywhere except in git and therefore it is
> uselessly redundant to the existing hash tag in my eyes. Why add another more
> roughly estimation of the users repo-state? I don't think this should be added
> to the version string.

A new dev tag is made every time a release is branched off, to indicate
development of the next ffmpeg version started there, so using it for
the version number seems natural to me.



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

Re: [FFmpeg-devel] [PATCH] nvenc.c Fix H264 and HEVC vui info update

[Moritz Barsnick]

On Thu, Mar 03, 2016 at 22:50:10 -0800, Timothy Gu wrote:
> This patched is corrupted by your mail client. What's wrong with the first
> patch you sent (with git-send-email)?

While the first one was mail-technically okay (probably), the patch
contained apparent whitespace changes and trailing whitespace in the
new code...

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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timo Rothenpieler]

>> Of course, this argument operates on the premise that 
>> making things easier for users is of utmost concern 
>> for us. Please inspire me if this is not the case.
> 
> On the contrary, I believe while the current versioing 
> scheme is simple and understandable, the suggested one 
> is misleading, both for users and when reading user 
> questions.

The current versioning scheme is indeed simple, but useless in almost
all other aspects.
It gives no indication about what release it is close to, so the
ChangeLog becomes useless without digging through the git log first.
It's also counter-intuitive, as people are used to regular version numbers.

Also, releases are also continuously numbered, so I don't see what's
better about the always increasing number based on some old tag.


Will resend the patch without the fetch part, but still, on all of my 3
dev machines i had to manually issue a fetch for the latest tags to show up.



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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Thilo Borgmann]

Am 04.03.16 um 08:58 schrieb wm4:
> On Fri, 4 Mar 2016 08:47:14 +0100
> Thilo Borgmann  wrote:
> 
>> Am 04.03.16 um 08:23 schrieb wm4:
>>> On Fri, 4 Mar 2016 00:55:35 + (UTC)
>>> Carl Eugen Hoyos  wrote:
>>>   
 Timothy Gu  gmail.com> writes:
  
> Of course, this argument operates on the premise that 
> making things easier for users is of utmost concern 
> for us. Please inspire me if this is not the case.

 On the contrary, I believe while the current versioing 
 scheme is simple and understandable, the suggested one 
 is misleading, both for users and when reading user 
 questions.  
>>>
>>> Well, duh, everyone disagrees with you.  
>>
>> Not true. For what I've read, I can't see the benefit of the change.
>> However, changing it should require a real reason and I don't see it.
>>
>> So, what exactly is the benefit of the proposed versioning? Can anyone
>> please elaborate what the current state is and what exactly would make
>> the user's life happier with the new one?
> 
> Being able to see the, well, version in the version output (instead of
> random numbers) sounds like a pretty convincing argument.

Neither a good play on words nor elaborative; not even helpful.

You say they are random numbers, CE says it is continuous. What is correct?

Let's assume the N-tag is not random, then it is a useful extension of the
pinpointing short hash, since the hashes are not relative to each other (so to
speak random for the human eye) and therefore the N-tags are useful for
determining if the user is ahead or behind a certain commit. According to what
CE says, this helps for user support, Not? And if not, why would someone
spending most of the time helping users think otherwise?
Assuming my thoughts are not based on void assumptions, I'm against removing the
N-tag from the version string.

So what about the release tag? Well it is a quite useful extension because of
the already mentioned possibility of determining the existing features at once.
I'm pro adding it to the version string.

The tag-tag? (devxy) I don't see it anywhere except in git and therefore it is
uselessly redundant to the existing hash tag in my eyes. Why add another more
roughly estimation of the users repo-state? I don't think this should be added
to the version string.

-Thilo




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

Re: [FFmpeg-devel] [PATCH] nvenc Fix H264 and HEVC vui info update

[Timo Rothenpieler]

>>
>> In case of the git send-email sends corrupted patch again, I attach the 
>> original patch file.
>>
>> Agatha Hu
>>
> 
> That's strange, does anyone received my patch sent at 17:22 GMT+8?
> Looks like the first mail (sent by git sent-email, no attachment) was somehow 
> blocked.
> 
> Agatha Hu

http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/190764.html that one?

Also, applied.
Thanks



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

Re: [FFmpeg-devel] [PATCH] nvenc Fix H264 and HEVC vui info update

[ahu]

On 2016年03月04日 17:26, ahu wrote:
> 
> On 2016年03月04日 17:22, ahu wrote:
>> ---
>>  libavcodec/nvenc.c | 27 +++
>>  1 file changed, 23 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
>> index a3b02fa..5d78930 100644
>> --- a/libavcodec/nvenc.c
>> +++ b/libavcodec/nvenc.c
>  
>>
> 
> In case of the git send-email sends corrupted patch again, I attach the 
> original patch file.
> 
> Agatha Hu
> 

That's strange, does anyone received my patch sent at 17:22 GMT+8?
Looks like the first mail (sent by git sent-email, no attachment) was somehow 
blocked.

Agatha Hu
---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc Fix H264 and HEVC vui info update

[ahu]

On 2016年03月04日 17:22, ahu wrote:
> ---
>  libavcodec/nvenc.c | 27 +++
>  1 file changed, 23 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index a3b02fa..5d78930 100644
> --- a/libavcodec/nvenc.c
> +++ b/libavcodec/nvenc.c
 
> 

In case of the git send-email sends corrupted patch again, I attach the 
original patch file.

Agatha Hu
>From 3fddde4b7e3e3dab61c3ba03188ebf72e08db6cc Mon Sep 17 00:00:00 2001
From: Agatha Hu 
Date: Fri, 4 Mar 2016 17:00:48 +0800
Subject: [PATCH] nvenc Fix H264 and HEVC vui info update

---
 libavcodec/nvenc.c | 27 +++
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index a3b02fa..5d78930 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -868,14 +868,19 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
 
 switch (avctx->codec->id) {
 case AV_CODEC_ID_H264:
-ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag = 1;
-ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoSignalTypePresentFlag = 1;
-
 ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourMatrix = avctx->colorspace;
 ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourPrimaries = avctx->color_primaries;
 ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.transferCharacteristics = avctx->color_trc;
+ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag = (avctx->color_range == AVCOL_RANGE_JPEG
+|| avctx->pix_fmt == AV_PIX_FMT_YUVJ420P || avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == AV_PIX_FMT_YUVJ444P);
+
+ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag =
+(avctx->colorspace != 2 || avctx->color_primaries != 2 || avctx->color_trc != 2);
 
-ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag = avctx->color_range == AVCOL_RANGE_JPEG;
+ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoSignalTypePresentFlag =
+(ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag
+|| ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFormat != 5
+|| ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag != 0);
 
 ctx->encode_config.encodeCodecConfig.h264Config.sliceMode = 3;
 ctx->encode_config.encodeCodecConfig.h264Config.sliceModeData = 1;
@@ -944,6 +949,20 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
 
 break;
 case AV_CODEC_ID_H265:
+ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourMatrix = avctx->colorspace;
+ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourPrimaries = avctx->color_primaries;
+ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.transferCharacteristics = avctx->color_trc;
+ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFullRangeFlag = (avctx->color_range == AVCOL_RANGE_JPEG
+|| avctx->pix_fmt == AV_PIX_FMT_YUVJ420P || avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == AV_PIX_FMT_YUVJ444P);
+
+ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourDescriptionPresentFlag =
+(avctx->colorspace != 2 || avctx->color_primaries != 2 || avctx->color_trc != 2);
+
+ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoSignalTypePresentFlag =
+(ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourDescriptionPresentFlag
+|| ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFormat != 5
+|| ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFullRangeFlag != 0);
+
 ctx->encode_config.encodeCodecConfig.hevcConfig.sliceMode = 3;
 ctx->encode_config.encodeCodecConfig.hevcConfig.sliceModeData = 1;
 
-- 
1.9.1

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

[FFmpeg-devel] [PATCH] nvenc Fix H264 and HEVC vui info update

[ahu]

---
 libavcodec/nvenc.c | 27 +++
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index a3b02fa..5d78930 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -868,14 +868,19 @@ static av_cold int nvenc_encode_init(AVCodecContext 
*avctx)
 
 switch (avctx->codec->id) {
 case AV_CODEC_ID_H264:
-
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag
 = 1;
-
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoSignalTypePresentFlag
 = 1;
-
 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourMatrix 
= avctx->colorspace;
 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourPrimaries
 = avctx->color_primaries;
 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.transferCharacteristics
 = avctx->color_trc;
+
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag
 = (avctx->color_range == AVCOL_RANGE_JPEG
+|| avctx->pix_fmt == AV_PIX_FMT_YUVJ420P || avctx->pix_fmt == 
AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == AV_PIX_FMT_YUVJ444P);
+
+
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag
 =
+(avctx->colorspace != 2 || avctx->color_primaries != 2 || 
avctx->color_trc != 2);
 
-
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag
 = avctx->color_range == AVCOL_RANGE_JPEG;
+
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoSignalTypePresentFlag
 =
+
(ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag
+|| 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFormat 
!= 5
+|| 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag
 != 0);
 
 ctx->encode_config.encodeCodecConfig.h264Config.sliceMode = 3;
 ctx->encode_config.encodeCodecConfig.h264Config.sliceModeData = 1;
@@ -944,6 +949,20 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
 
 break;
 case AV_CODEC_ID_H265:
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourMatrix 
= avctx->colorspace;
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourPrimaries
 = avctx->color_primaries;
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.transferCharacteristics
 = avctx->color_trc;
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFullRangeFlag
 = (avctx->color_range == AVCOL_RANGE_JPEG
+|| avctx->pix_fmt == AV_PIX_FMT_YUVJ420P || avctx->pix_fmt == 
AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == AV_PIX_FMT_YUVJ444P);
+
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourDescriptionPresentFlag
 =
+(avctx->colorspace != 2 || avctx->color_primaries != 2 || 
avctx->color_trc != 2);
+
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoSignalTypePresentFlag
 =
+
(ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourDescriptionPresentFlag
+|| 
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFormat 
!= 5
+|| 
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFullRangeFlag
 != 0);
+
 ctx->encode_config.encodeCodecConfig.hevcConfig.sliceMode = 3;
 ctx->encode_config.encodeCodecConfig.hevcConfig.sliceModeData = 1;
 
-- 
1.9.1



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

Re: [FFmpeg-devel] Libavcodec consulting

[Jonathan Girven]

On Thu, Mar 3, 2016 at 11:28 PM, compn  wrote:
> the mp4 format can either have an index at the start of the file or
> at the end of the file. you cannot read (easily) an mp4 file without its
> index.
>
> http://wiki.multimedia.cx/index.php?title=MP4
>
> http servers can be made to support "request range" and thus allow
> seeking to the start or end of the mp4 file. existing mp4 files can be
> edited to have the index at the start or end.
>
> otherwise, mp4 cannot be streamed. by anyone, in any situation (well,
> without serious hacks). the current way mp4 is "streamed" is to
> split up mp4 files into a thousand smaller mp4 files and sent to a
> player using a playlist.
>
> mp4 cannot be streamed. it sucks.
> changing the http server would be easier than changing mp4 indexing.
> or using an intermediate format would be easier (mkv perhaps).

Thanks for that clarification. Unfortunately the http server is a third
party camera that broadcasts a WiFi hotspot. Therefore we don't really
have control over the underlying server. However, what I do know is
that the ffmpeg command I quoted previously seems to be able to
grab a chunk of a video anywhere in the file without downloading the
whole thing. So I assume libav must also be capable.

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