[FFmpeg-devel] [PATCH 2/2] tests/api/api-h264-test: Add AV_NOPTS_VALUE check for AVFrame.pkt_dts

2019-02-09 Thread Jun Zhao
Add AV_NOPTS_VALUE check for AVFrame.pkt_dts to avoid print the
pkt_dts as negative number like:
"0,3616613, -9223372036854775808, 1001,  3110400, 0x75e37a65"

Signed-off-by: Jun Zhao 
---
 tests/api/api-h264-test.c |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/tests/api/api-h264-test.c b/tests/api/api-h264-test.c
index 9fa..351d622 100644
--- a/tests/api/api-h264-test.c
+++ b/tests/api/api-h264-test.c
@@ -131,9 +131,15 @@ static int video_decode_example(const char *input_filename)
 av_log(NULL, AV_LOG_ERROR, "Can't copy image to buffer\n");
 return number_of_written_bytes;
 }
-printf("%d, %10"PRId64", %10"PRId64", %8"PRId64", %8d, 
0x%08lx\n", video_stream,
-fr->pts, fr->pkt_dts, fr->pkt_duration,
-number_of_written_bytes, av_adler32_update(0, (const 
uint8_t*)byte_buffer, number_of_written_bytes));
+
+if (fr->pkt_dts == AV_NOPTS_VALUE)
+printf("%d, %10"PRId64", %s, %8"PRId64", %8d, 0x%08lx\n", 
video_stream,
+   fr->pts, "N/A", fr->pkt_duration,
+   number_of_written_bytes, av_adler32_update(0, 
(const uint8_t*)byte_buffer, number_of_written_bytes));
+else
+printf("%d, %10"PRId64", %10"PRId64", %8"PRId64", %8d, 
0x%08lx\n", video_stream,
+   fr->pts, fr->pkt_dts, fr->pkt_duration,
+   number_of_written_bytes, av_adler32_update(0, 
(const uint8_t*)byte_buffer, number_of_written_bytes));
 }
 av_packet_unref();
 av_init_packet();
-- 
1.7.1

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


[FFmpeg-devel] [PATCH 1/2] avfilter/tests/integral: Fix build warning after adjust the location

2019-02-09 Thread Jun Zhao
Fix build warning like "warning: ISO C90 forbids mixed declarations
and code" after adjust the location for malloc fail check.

Signed-off-by: Jun Zhao 
---
 libavfilter/tests/integral.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/libavfilter/tests/integral.c b/libavfilter/tests/integral.c
index 361bfd5..093ed39 100644
--- a/libavfilter/tests/integral.c
+++ b/libavfilter/tests/integral.c
@@ -33,6 +33,9 @@ static void display_integral(const uint32_t *ii, int w, int 
h, int lz_32)
 int main(void)
 {
 int ret = 0, xoff, yoff;
+uint32_t *ii_start;
+uint32_t *ii_start2;
+NLMeansDSPContext dsp = {0};
 
 // arbitrary test source of size 6x4 and linesize=8
 const int w = 6, h = 5, lz = 8;
@@ -57,10 +60,8 @@ int main(void)
 if (!ii || !ii2)
 return -1;
 
-uint32_t *ii_start  = ii  + ii_lz_32 + 1; // skip top 0-line and left 
0-column
-uint32_t *ii_start2 = ii2 + ii_lz_32 + 1; // skip top 0-line and left 
0-column
-
-NLMeansDSPContext dsp = {0};
+ii_start  = ii  + ii_lz_32 + 1; // skip top 0-line and left 0-column
+ii_start2 = ii2 + ii_lz_32 + 1; // skip top 0-line and left 0-column
 
 ff_nlmeans_init();
 
-- 
1.7.1

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


Re: [FFmpeg-devel] [PATCH] doc/filters: fix typos

2019-02-09 Thread Gyan



On 10-02-2019 11:37 AM, Reto Kromer wrote:

Should fix a few nits in man. Best regards, Reto


Removed trailing whitespace from patch and pushed as 
d20902fd2399ae04cbd5c02e83fbd90c68592555 with a couple of corrections added.


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


Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix fmp4_init_filename file name with %v problem

2019-02-09 Thread Steven Liu


> On Feb 10, 2019, at 12:45, Gyan  wrote:
> 
> 
> 
> On 19-01-2019 12:33 PM, Steven Liu wrote:
>> when set option fmp4_init_filename to init_%v.mp4
>> before patch:
>> the init file will be init_%v_0.mp4, init_%v_1.mp4
>> after patch:
>> the init file will be init_0.mp4, init_1.mp4
>> 
>> Reported-By: Gyan Doshi 
>> Signed-off-by: Steven Liu 
>> ---
>>  libavformat/hlsenc.c | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>> 
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index ca57694e9e..d98d52a332 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -2715,7 +2715,11 @@ static int hls_init(AVFormatContext *s)
>>  av_strlcpy(vs->fmp4_init_filename, hls->fmp4_init_filename,
>> fmp4_init_filename_len);
>>  if (hls->nb_varstreams > 1) {
>> -ret = append_postfix(vs->fmp4_init_filename, 
>> fmp4_init_filename_len, i);
>> +if (av_stristr(vs->fmp4_init_filename, "%v")) {
>> +format_name(vs->fmp4_init_filename, 
>> fmp4_init_filename_len, i);
>> +} else {
>> +ret = append_postfix(vs->fmp4_init_filename, 
>> fmp4_init_filename_len, i);
>> +}
>>  if (ret < 0)
>>  goto fail;
>>  }
> 
> Steven, ping.

Pushed

Sorry for the delay, these days are Chinese Spring Festival.
> 
> Gyan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks
Steven





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


[FFmpeg-devel] [PATCH] doc/filters: fix typos

2019-02-09 Thread Reto Kromer

Should fix a few nits in man. Best regards, Reto

0001-doc-filters-fix-typos.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avfilter/tests/integral: Check malloc fail before using it

2019-02-09 Thread Jun Zhao
Need to check malloc fail before using it, so adjust the location
in the code.

Signed-off-by: Jun Zhao 
---
 libavfilter/tests/integral.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavfilter/tests/integral.c b/libavfilter/tests/integral.c
index 2a8e8ff..361bfd5 100644
--- a/libavfilter/tests/integral.c
+++ b/libavfilter/tests/integral.c
@@ -54,6 +54,9 @@ int main(void)
 uint32_t *ii  = av_mallocz_array(ii_h + 1, ii_lz_32 * sizeof(*ii));
 uint32_t *ii2 = av_mallocz_array(ii_h + 1, ii_lz_32 * sizeof(*ii2));
 
+if (!ii || !ii2)
+return -1;
+
 uint32_t *ii_start  = ii  + ii_lz_32 + 1; // skip top 0-line and left 
0-column
 uint32_t *ii_start2 = ii2 + ii_lz_32 + 1; // skip top 0-line and left 
0-column
 
@@ -61,9 +64,6 @@ int main(void)
 
 ff_nlmeans_init();
 
-if (!ii || !ii2)
-return -1;
-
 for (yoff = -e; yoff <= e; yoff++) {
 for (xoff = -e; xoff <= e; xoff++) {
 printf("xoff=%d yoff=%d\n", xoff, yoff);
-- 
1.7.1

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


[FFmpeg-devel] [PATCH] avformat/mov: fix sidx loading issues in fragmented files.

2019-02-09 Thread agrecascino123
From: mptcultist  

fixed issue where if sidx was after another sidx and happened to point to the 
same media, it wouldn't be read.
this is done by counting the sidx atoms before they're read. for #7572
---
 libavformat/isom.h |  2 ++
 libavformat/mov.c  | 45 +++--
 2 files changed, 45 insertions(+), 2 deletions(-)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index 69452cae8e..cc3067d2c0 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -288,6 +288,8 @@ typedef struct MOVContext {
 int decryption_key_len;
 int enable_drefs;
 int32_t movie_display_matrix[3][3]; ///< display matrix from mvhd
+int sidx_count;
+int cur_sidx;
 } MOVContext;
 
 int ff_mp4_read_descr_len(AVIOContext *pb);
diff --git a/libavformat/mov.c b/libavformat/mov.c
index cc91beb7f9..a59c893274 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4961,6 +4961,8 @@ static int mov_read_sidx(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 MOVStreamContext *sc, *ref_sc = NULL;
 AVRational timescale;
 
+c->cur_sidx++;
+
 version = avio_r8(pb);
 if (version > 1) {
 avpriv_request_sample(c->fc, "sidx version %u", version);
@@ -5027,7 +5029,8 @@ static int mov_read_sidx(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 sc->has_sidx = 1;
 
-if (offset == avio_size(pb)) {
+if ((!(pb->seekable & AVIO_SEEKABLE_NORMAL) && (offset == avio_size(pb))) 
||
+ ((pb->seekable & AVIO_SEEKABLE_NORMAL) && (c->sidx_count == 
c->cur_sidx))  ) {
 // Find first entry in fragment index that came from an sidx.
 // This will pretty much always be the first entry.
 for (i = 0; i < c->frag_index.nb_items; i++) {
@@ -6779,6 +6782,43 @@ static const MOVParseTableEntry 
mov_default_parse_table[] = {
 { 0, NULL }
 };
 
+static int mov_count_sidx(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+int64_t total_size = 0;
+MOVAtom a;
+int si = 0;
+
+if (atom.size < 0)
+atom.size = INT64_MAX;
+while (total_size <= atom.size - 8 && !avio_feof(pb)) {
+a.size = atom.size;
+a.type=0;
+if (atom.size >= 8) {
+a.size = avio_rb32(pb);
+a.type = avio_rl32(pb);
+if (a.type == MKTAG('s','i','d','x')) {
+si++;
+}
+total_size += 8;
+if (a.size == 1 && total_size + 8 <= atom.size) { /* 64 bit 
extended size */
+a.size = avio_rb64(pb) - 8;
+total_size += 8;
+}
+}
+if (a.size == 0) {
+a.size = atom.size - total_size + 8;
+}
+a.size -= 8;
+if (a.size < 0)
+break;
+a.size = FFMIN(a.size, atom.size - total_size);
+avio_skip(pb, a.size);
+total_size += a.size;
+}
+avio_seek(pb, 0, SEEK_SET);
+return si;
+}
+
 static int mov_read_default(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
 int64_t total_size = 0;
@@ -7401,7 +7441,8 @@ static int mov_read_header(AVFormatContext *s)
 atom.size = avio_size(pb);
 else
 atom.size = INT64_MAX;
-
+if (pb->seekable & AVIO_SEEKABLE_NORMAL)
+mov->sidx_count = mov_count_sidx(mov, pb, atom);
 /* check MOV header */
 do {
 if (mov->moov_retry)
-- 
2.20.1

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


Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix fmp4_init_filename file name with %v problem

2019-02-09 Thread Gyan



On 19-01-2019 12:33 PM, Steven Liu wrote:

when set option fmp4_init_filename to init_%v.mp4
before patch:
the init file will be init_%v_0.mp4, init_%v_1.mp4
after patch:
the init file will be init_0.mp4, init_1.mp4

Reported-By: Gyan Doshi 
Signed-off-by: Steven Liu 
---
  libavformat/hlsenc.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index ca57694e9e..d98d52a332 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2715,7 +2715,11 @@ static int hls_init(AVFormatContext *s)
  av_strlcpy(vs->fmp4_init_filename, hls->fmp4_init_filename,
 fmp4_init_filename_len);
  if (hls->nb_varstreams > 1) {
-ret = append_postfix(vs->fmp4_init_filename, 
fmp4_init_filename_len, i);
+if (av_stristr(vs->fmp4_init_filename, "%v")) {
+format_name(vs->fmp4_init_filename, 
fmp4_init_filename_len, i);
+} else {
+ret = append_postfix(vs->fmp4_init_filename, 
fmp4_init_filename_len, i);
+}
  if (ret < 0)
  goto fail;
  }


Steven, ping.

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


Re: [FFmpeg-devel] lavc/libvpxenc: Deprecate lossless option

2019-02-09 Thread Gyan



On 09-02-2019 04:45 PM, Carl Eugen Hoyos wrote:

2019-02-09 7:49 GMT+01:00, Gyan :


On 09-02-2019 02:26 AM, Carl Eugen Hoyos wrote:

2019-02-08 6:08 GMT+01:00, Gyan :

On 08-02-2019 03:31 AM, Carl Eugen Hoyos wrote:

.
No strong opinion here, I hadn't realized that -crf 0 only works with
newer versions.

Can you explain why crf alone has no effect and needs -b:v 0?
Isn't this a bug both with libvpx and libaom?


With crf present but VBV params absent, VPX operates using a constrained
Q RC mode , where the target bitrate acts as a ceiling. Since acvodec
has a non-zero default -b of 200 kbps, this produces undesirable
effects. If set to 0, VPX switches to constant quality.

Yes.
This looks like a bug to me.

If there's a bug, it's in libav, in that, we can't signal when a value
is assigned by the user or via user-initiated logic, versus being
assigned as a default fallback. So it's a design conflict, and the
workaround has been long documented.

Maybe just before the next major bump, a new field should be
introduced in AVOptions which registers if the field was
populated at the behest of the user.

We could set the default for "b" to "0" without a major bump.
Do you mean just the defaults in the vpx wrapper? Ok.  Changing the lib 
default will affect encoders which make use the bitrate value, like mjpeg.



Is it expected that constant crf with vp8 leads to broken output?
Not broken, simply unexpected for those used to  how x264/5 handle it in 
ffmpeg.



I do see this block though,

   if (avctx->codec_id == AV_CODEC_ID_VP9 && ctx->lossless == 1) {
   enccfg.rc_min_quantizer =
   enccfg.rc_max_quantizer = 0;
   } else {
   if (avctx->qmin >= 0)
   enccfg.rc_min_quantizer = avctx->qmin;
   if (avctx->qmax >= 0)
   enccfg.rc_max_quantizer = avctx->qmax;
   }


Looks like the quantizer range is disabled only by using the deprecated
option, or has this changed?

Is your question "Isn't 'lossless 1' necessary for lossless encoding"?

Yes. A quick glance at vpx HEAD indicates it is, although
-qmin & -qmax 0 should also work.



Also, with libvpx v1.7.0-1758, I get different results for -crf 0 -b:v
0  vs only -lossless 1, with the latter producing a slightly larger
file, and its result showing a slightly larger SSIM score. Although
neither produces a SSIM of 1, like libx264. Not truly lossless?

Please provide your input sample.

I can reproduce the difference in result with
fate-suite/h264-conformance/src19td.IBP.264

Yes, this returns a few non-lossless frames.

Is the encoder meant to be used for actual encoding?
Or does -crf 0 have several meanings depending on specific options
and vp8 is just bad?

We're talking about VP9. VP8 has no lossless mode. Yes, this is a 
production encoder - Youtube uses it to generate VP9 streams for 
uploaded videos.


Like I mentioned earlier, CRF +  bitrate triggers constrained quality. 
If the rate ceiling is high enough, the result is equivalent to 
unclamped CRF, which is what the wrapper does when avctx bitrate is 0, 
set its own bitrate target to 1 Gbps.


In any case, -lossless shouldn't be deprecated unless the workaround 
produces identical results.


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


Re: [FFmpeg-devel] [PATCH 0/2] ARIB STD-B24 caption decoding using libaribb24

2019-02-09 Thread Jan Ekström
On Fri, Feb 8, 2019 at 2:38 AM Jan Ekström  wrote:
>
> On Sat, Feb 2, 2019 at 3:31 PM Jan Ekström  wrote:
> >
> > A decoder wrapper for the libaribb24 library found in various
> > distributions and currently utilized by VLC.
> >
> > Requires GPLv3 with the current most recent release, but as the
> > current library master is LGPLv3, any newer releases will require
> > only LGPLv3.
> >
> > If the library is not found in your distribution, it is available at:
> > https://github.com/nkoriyama/aribb24
> >
> > A test sample can be found at:
> > https://kuroko.fushizen.eu/samples/arib_captions_colors_positioning_ruby_subpics.ts
> >
> > An example of how the decoded output currently looks can be found at:
> > https://megumin.fushizen.eu/screenshots/arib_subs/mpv-shot0004.png
> >
> > I will proceed to making a FATE test as soon as I figure out the simplest
> > way to limit an MPEG-TS stream to some PIDs without doing full remuxing.
> > (I think dvblast has something like this so I might take a look at that)
> >
> > The decoded subtitles might or might not have durations set, so with
> > ffmpeg.c `-fix_sub_duration` is required.
> >
> > Regarding positioning:
> >
> > I have an initial version of positioning implemented, but unfortunately
> > it requires multiple subtitle lines per AVSubtitle, and many applications
> > seem to fail at handling them, including the encoding portions of
> > libavformat/libavcodec (all lines end up concatenated into a single line, 
> > even
> > though that is 100% invalid as there is a header included).
> >
> > Thus I have decided to post the first version out now, as when the ruby
> > blocks are not included as a distraction, single-line output seems to be
> > fine and readable/enjoyable.
> >
> > Best regards,
> > Jan
> >
> > Jan Ekström (2):
> >   add libaribb24 ARIB STD-B24 caption decoder
> >   lavf/mpegts: add reading of ARIB data coding descriptor
> >
> >  Changelog   |   1 +
> >  configure   |   7 +
> >  doc/decoders.texi   |  25 +++
> >  libavcodec/Makefile |   1 +
> >  libavcodec/allcodecs.c  |   1 +
> >  libavcodec/avcodec.h|   4 +
> >  libavcodec/codec_desc.c |   9 +-
> >  libavcodec/libaribb24.c | 378 
> >  libavcodec/profiles.c   |   6 +
> >  libavcodec/profiles.h   |   1 +
> >  libavcodec/version.h|   2 +-
> >  libavformat/mpegts.c|  47 +
> >  libavformat/version.h   |   2 +-
> >  13 files changed, 481 insertions(+), 3 deletions(-)
> >  create mode 100644 libavcodec/libaribb24.c
> >
> > --
> > 2.20.1
> >
>
> I really don't like to do this because I really like consensus... But
> now that I know that the disagreement that was had about this patch
> set was not a blocking one, I would like to move forward with my
> ARIB-related work (of which this was part 1). As I have addressed all
> the technical comments that I have received regarding the patches in
> this set, if any more doesn't come within the next 24 or so hours or
> so I would like to start pushing this in as a "reference" decoder for
> this format against which a future internal implementation can be
> compared against.
>

As there have been no further objections, I will be pushing this patch
set and enabling demuxing of ARIB captions with FFmpeg, as well as
decoding with libaribb24 (until an internal decoder is implemented). I
tried to call out for comments to see if anyone had *something* to say
about this patch set during the past two days - but none were
negative.

As another positive sign, the author of this library has recently
re-activated, so while it is likely that the library might move under
the VideoLAN umbrella in the longer term, we should be able to receive
clarification regarding some things.

Thank you,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lavf/img2dec: Split img2 and img2pipe options

2019-02-09 Thread Jan Ekström
On Sat, Feb 9, 2019 at 2:58 PM Carl Eugen Hoyos  wrote:
>
> Hi!
>
> Currently if the "loop" option gets specified for -f image2pipe, there is
> no indication for the user that the option will not work, patch attached.
>
> Please comment, Carl Eugen

Seems like a good idea.

The reason for the pipe version's AVOption structure to be outside of
the if is the IMAGEAUTO_DEMUXER macro, so I guess unless we like
really long #ifs then this is as good as it gets.

Quickly checked and it seems like generally the separation of options
seems correct... but I'm not sure about "ts_from_file" . The filename
variable will probably be full of \0s at the point where stat() is
called, as it's only set to something else under "!s->is_pipe" branch
in the beginning of the function if I'm seeing correctly - thus making
this option effectively unusable under the _pipe demuxers?

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


[FFmpeg-devel] [PATCH]lavf/http: Print metadata updates with loglevel verbose

2019-02-09 Thread Carl Eugen Hoyos
Hi!

Attached patch simplifies the debugging of icy metadata, required to
answer the tickets of one regular reporter.

Please comment, Carl Eugen
From 170f6bcf79b4486adf1121f7e5f01b6617fd1e79 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sun, 10 Feb 2019 00:59:30 +0100
Subject: [PATCH] lavf/http: Print metadata updates with -loglevel verbose.

Simplifies metadata debugging.
---
 libavformat/http.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index a0a0636..ee3ac23 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1504,12 +1504,13 @@ static int http_read_stream_all(URLContext *h, uint8_t *buf, int size)
 return pos;
 }
 
-static void update_metadata(HTTPContext *s, char *data)
+static void update_metadata(URLContext *h, char *data)
 {
 char *key;
 char *val;
 char *end;
 char *next = data;
+HTTPContext *s = h->priv_data;
 
 while (*next) {
 key = next;
@@ -1525,6 +1526,7 @@ static void update_metadata(HTTPContext *s, char *data)
 val += 2;
 
 av_dict_set(>metadata, key, val, 0);
+av_log(h, AV_LOG_VERBOSE, "Metadata update for %s: %s\n", key, val);
 
 next = end + 2;
 }
@@ -1559,7 +1561,7 @@ static int store_icy(URLContext *h, int size)
 data[len + 1] = 0;
 if ((ret = av_opt_set(s, "icy_metadata_packet", data, 0)) < 0)
 return ret;
-update_metadata(s, data);
+update_metadata(h, data);
 }
 s->icy_data_read = 0;
 remaining= s->icy_metaint;
-- 
1.7.10.4

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


Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Convert service name and service provider to utf-8

2019-02-09 Thread Carl Eugen Hoyos
2019-02-10 0:23 GMT+01:00, Marton Balint :
>
> On Sat, 9 Feb 2019, Carl Eugen Hoyos wrote:
>
>> 2019-02-09 23:14 GMT+01:00, Marton Balint :

>>> Instead of ISO-10646 you probably should use UCS-2BE, VLC
>>> is also doing this and the specs refer to the basic multilingual
>>> plane. ISO-10646 alone is UCS-4 which uses 4 byte encoding,
>>> probably not what we want here.
>>
>> (Not "BIG-5"?)
>
> No, see this VLC ticket:
>
> https://trac.videolan.org/vlc/ticket/8235

Thank you!

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


Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Convert service name and service provider to utf-8

2019-02-09 Thread Marton Balint



On Sat, 9 Feb 2019, Carl Eugen Hoyos wrote:


2019-02-09 23:14 GMT+01:00, Marton Balint :



On Sat, 9 Feb 2019, Carl Eugen Hoyos wrote:

+#if CONFIG_ICONV
+if (len && *p < 0x20) {

+const char *encodings[] = {
+"ISO6937", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7",
"ISO-8859-8",
+"ISO-8859-9", "ISO-8859-10", "ISO-8859-11", "",
"ISO-8859-13",
+"ISO-8859-14", "ISO-8859-15", "", "", "", "",
+"", "ISO-10646", "KSC_5601", "GB2312", "ISO-10646", "UTF-8",
"",
+"", "", "", "", "", "", "", "", ""


Instead of ISO-10646 you probably should use UCS-2BE, VLC
is also doing this and the specs refer to the basic multilingual
plane. ISO-10646 alone is UCS-4 which uses 4 byte encoding,
probably not what we want here.


(Not "BIG-5"?)


No, see this VLC ticket:

https://trac.videolan.org/vlc/ticket/8235

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


[FFmpeg-devel] [PATCH] avformat/mov: don't rescale mastering display values from the SmDm atom

2019-02-09 Thread James Almer
Simplifies code.

Signed-off-by: James Almer 
---
 libavformat/mov.c | 21 -
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 9b9739f788..986c54e74e 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5268,9 +5268,7 @@ static int mov_read_vpcc(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 static int mov_read_smdm(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
 MOVStreamContext *sc;
-const int chroma_den = 5;
-const int luma_den = 1;
-int i, j, version;
+int i, version;
 
 if (c->fc->nb_streams < 1)
 return AVERROR_INVALIDDATA;
@@ -5293,17 +5291,14 @@ static int mov_read_smdm(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 if (!sc->mastering)
 return AVERROR(ENOMEM);
 
-for (i = 0; i < 3; i++)
-for (j = 0; j < 2; j++)
-sc->mastering->display_primaries[i][j] =
-av_make_q(lrint(((double)avio_rb16(pb) / (1 << 16)) * 
chroma_den), chroma_den);
+for (i = 0; i < 3; i++) {
+sc->mastering->display_primaries[i][0] = av_make_q(avio_rb16(pb), 1 << 
16);
+sc->mastering->display_primaries[i][1] = av_make_q(avio_rb16(pb), 1 << 
16);
+}
 for (i = 0; i < 2; i++)
-sc->mastering->white_point[i] =
-av_make_q(lrint(((double)avio_rb16(pb) / (1 << 16)) * chroma_den), 
chroma_den);
-sc->mastering->max_luminance =
-av_make_q(lrint(((double)avio_rb32(pb) / (1 <<  8)) * luma_den), 
luma_den);
-sc->mastering->min_luminance =
-av_make_q(lrint(((double)avio_rb32(pb) / (1 << 14)) * luma_den), 
luma_den);
+sc->mastering->white_point[i] = av_make_q(avio_rb16(pb), 1 << 16);
+sc->mastering->max_luminance = av_make_q(avio_rb32(pb), 1 << 8);
+sc->mastering->min_luminance = av_make_q(avio_rb32(pb), 1 << 14);
 
 sc->mastering->has_primaries = 1;
 sc->mastering->has_luminance = 1;
-- 
2.20.1

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


Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Convert service name and service provider to utf-8

2019-02-09 Thread Jan Ekström
On Sat, Feb 9, 2019 at 7:39 PM Carl Eugen Hoyos  wrote:
>
> 2019-02-09 17:42 GMT+01:00, Marton Balint :
> > On Sat, 9 Feb 2019, Carl Eugen Hoyos wrote:
> >
> >> From 9033f0a18727a7a576c4cc06b9985d6d922d46ad Mon Sep 17 00:00:00 2001
> >> From: Carl Eugen Hoyos 
> >> Date: Sat, 9 Feb 2019 00:49:51 +0100
> >> Subject: [PATCH] lavf/mpegts: Convert service_name and service_provider to
> >>  utf-8.
> >>
> >> Fixes ticket #6320.
> >> ---
> >>  libavformat/mpegts.c |   48
> >> 
> >>  1 file changed, 48 insertions(+)
> >>
> >> Diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> >> Index b04fd7b..1e27500 100644
> >> --- a/libavformat/mpegts.c
> >> +++ b/libavformat/mpegts.c
> >> @@ -37,6 +37,9 @@
> >>  #include "avio_internal.h"
> >>  #include "mpeg.h"
> >>  #include "isom.h"
> >> +#if CONFIG_ICONV
> >> +#include 
> >> +#endif
> >>
> >>  /* maximum size in which we look for synchronization if
> >>   * synchronization is lost */
> >> @@ -674,6 +677,51 @@ static char *getstr8(const uint8_t **pp, const
> >> uint8_t *p_end)
> >>  return NULL;
> >>  if (len > p_end - p)
> >>  return NULL;
> >> +#if CONFIG_ICONV
> >> +if (len && *p < 0x20) {
> >> +char iso8859[] = "ISO-8859-00";
> >> +const char *encodings[] = {
> >> +"ISO6937", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7",
> >> "ISO-8859-8",
> >> +"ISO-8859-9", "ISO-8859-10", "ISO-8859-11", "",
> >> "ISO-8859-13",
> >> +"ISO-8859-14", "ISO-8859-15", "", "", "", "",
> >> +"", "ISO-10646", "KSC_5601", "GB2312", "ISO-10646", "UTF-8",
> >> "",
> >> +"", "", "", "", "", "", "", "", ""
> >> +};
> >> +iconv_t cd;
> >> +char *in, *out;
> >> +size_t inlen = len - 1, outlen = inlen * 6 + 1;
> >> +if (len >= 3 && p[0] == 0x10 && !p[1] && p[2] && p[2] <= 0xf &&
> >> p[2] != 0xc) {
> >> +if (p[2] < 10) {
> >> +iso8859[9] += p[2];
> >> +iso8859[10] = 0;
> >> +} else {
> >> +iso8859[9]++;
> >> +iso8859[10] += p[2] - 10;
> >> +}
> >
> > I think this would be much more readable:
> >
> > char iso8859[16];
> > snprintf(iso8859, sizeof(iso8859), "ISO-8859-%d", p[2]);
>
> Definitely, new patch attached.
>

Idea-wise I like this. We generally try to promise that our metadata
is UTF-8, but with broadcast things we've not held up to that promise
too much :) . This fixes quite a bit of that, which is nice.

Checked that this doesn't seem to be breaking my future integration of
ARIB STD-B24 text decoding into UTF-8 looking at my set of samples on
hand. Just changes the place I'll have to integrate to as to not do a
double conversion.

In other words, good work.

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


Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-09 Thread Jean-Baptiste Kempf
On Sat, 9 Feb 2019, at 11:59, Werner Robitza wrote:
> You could print an even more obvious warning message when these
> options are used.
> If that is a big concern, it can be easily dealt with.
> 
> > And yes, I strongly advise against the project advertising those non-free 
> > options.
> 
> Then the only consequence can be to remove these options or support
> for these libraries altogether, because you'll find plenty of guides
> and recommendations on how to build ffmpeg with non-free libs on the
> Internet – even supplied by members who are very active in the FFmpeg
> community. It is certainly your prerogative to be against explicit
> advertising, but where do you draw the line? Has there been any
> precedent with this, or is this going to be decided on a case-by-case
> basis?
> 
> The only consequence would be a formula that is not owned and
> controlled by FFmpeg, and people will continue to build non-free
> binaries.

But then, it is not the project, doing it, but someone else.

To come back to the main topic, you can have a full FFmpeg in homebrew with all 
the libraries activated by default, if you want, without any issue.
I therefore  do not see at all the need for options.

Those options are just for non-free cases, and to be honest, I don't see why 
FFmpeg should advertise those.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Convert service name and service provider to utf-8

2019-02-09 Thread Carl Eugen Hoyos
2019-02-09 23:14 GMT+01:00, Marton Balint :
>
>
> On Sat, 9 Feb 2019, Carl Eugen Hoyos wrote:
>
> +#if CONFIG_ICONV
> +if (len && *p < 0x20) {
>> +const char *encodings[] = {
>> +"ISO6937", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7",
>> "ISO-8859-8",
>> +"ISO-8859-9", "ISO-8859-10", "ISO-8859-11", "",
>> "ISO-8859-13",
>> +"ISO-8859-14", "ISO-8859-15", "", "", "", "",
>> +"", "ISO-10646", "KSC_5601", "GB2312", "ISO-10646", "UTF-8",
>> "",
>> +"", "", "", "", "", "", "", "", ""
>
> Instead of ISO-10646 you probably should use UCS-2BE, VLC
> is also doing this and the specs refer to the basic multilingual
> plane. ISO-10646 alone is UCS-4 which uses 4 byte encoding,
> probably not what we want here.

(Not "BIG-5"?)

> Otherwise LGTM, thanks.

Changed and pushed.

Thank you for the review, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lavf:Constify AVProbeData* in av_probe_input_format()

2019-02-09 Thread Carl Eugen Hoyos
2019-02-09 23:26 GMT+01:00, Carl Eugen Hoyos :
> Hi!
>
> Attached patch constifies a few pointers at the next version bump.

And the patch.

Carl Eugen
From cb2afc8b7e28b476d908daf1ae693bd007fb2abc Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 9 Feb 2019 23:22:59 +0100
Subject: [PATCH] lavf: Constify AVProbeData* in av_probe_input_format().

---
 libavformat/avformat.h |   11 ---
 libavformat/format.c   |6 +++---
 libavformat/version.h  |3 +++
 3 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index fdaffa5..c6e1e97 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2231,7 +2231,12 @@ AVInputFormat *av_find_input_format(const char *short_name);
  * @param is_opened Whether the file is already opened; determines whether
  *  demuxers with or without AVFMT_NOFILE are probed.
  */
-AVInputFormat *av_probe_input_format(AVProbeData *pd, int is_opened);
+#if FF_API_AVIOFORMAT
+#define av_const59
+#else
+#define av_const59 const
+#endif
+AVInputFormat *av_probe_input_format(av_const59 AVProbeData *pd, int is_opened);
 
 /**
  * Guess the file format.
@@ -2245,7 +2250,7 @@ AVInputFormat *av_probe_input_format(AVProbeData *pd, int is_opened);
  *  If the score is <= AVPROBE_SCORE_MAX / 4 it is recommended
  *  to retry with a larger probe buffer.
  */
-AVInputFormat *av_probe_input_format2(AVProbeData *pd, int is_opened, int *score_max);
+AVInputFormat *av_probe_input_format2(av_const59 AVProbeData *pd, int is_opened, int *score_max);
 
 /**
  * Guess the file format.
@@ -2254,7 +2259,7 @@ AVInputFormat *av_probe_input_format2(AVProbeData *pd, int is_opened, int *score
  *  demuxers with or without AVFMT_NOFILE are probed.
  * @param score_ret The score of the best detection.
  */
-AVInputFormat *av_probe_input_format3(AVProbeData *pd, int is_opened, int *score_ret);
+AVInputFormat *av_probe_input_format3(av_const59 AVProbeData *pd, int is_opened, int *score_ret);
 
 /**
  * Probe a bytestream to determine the input format. Each time a probe returns
diff --git a/libavformat/format.c b/libavformat/format.c
index 2c4c895..1ad8252 100644
--- a/libavformat/format.c
+++ b/libavformat/format.c
@@ -125,7 +125,7 @@ AVInputFormat *av_find_input_format(const char *short_name)
 return NULL;
 }
 
-AVInputFormat *av_probe_input_format3(AVProbeData *pd, int is_opened,
+AVInputFormat *av_probe_input_format3(av_const59 AVProbeData *pd, int is_opened,
   int *score_ret)
 {
 AVProbeData lpd = *pd;
@@ -202,7 +202,7 @@ AVInputFormat *av_probe_input_format3(AVProbeData *pd, int is_opened,
 return fmt;
 }
 
-AVInputFormat *av_probe_input_format2(AVProbeData *pd, int is_opened, int *score_max)
+AVInputFormat *av_probe_input_format2(av_const59 AVProbeData *pd, int is_opened, int *score_max)
 {
 int score_ret;
 AVInputFormat *fmt = av_probe_input_format3(pd, is_opened, _ret);
@@ -213,7 +213,7 @@ AVInputFormat *av_probe_input_format2(AVProbeData *pd, int is_opened, int *score
 return NULL;
 }
 
-AVInputFormat *av_probe_input_format(AVProbeData *pd, int is_opened)
+AVInputFormat *av_probe_input_format(av_const59 AVProbeData *pd, int is_opened)
 {
 int score = 0;
 return av_probe_input_format2(pd, is_opened, );
diff --git a/libavformat/version.h b/libavformat/version.h
index 4408eca..f189984 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -103,6 +103,9 @@
 #ifndef FF_API_LAVF_MP4A_LATM
 #define FF_API_LAVF_MP4A_LATM   (LIBAVFORMAT_VERSION_MAJOR < 59)
 #endif
+#ifndef FF_API_AVIOFORMAT
+#define FF_API_AVIOFORMAT   (LIBAVFORMAT_VERSION_MAJOR < 59)
+#endif
 
 
 #ifndef FF_API_R_FRAME_RATE
-- 
1.7.10.4

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


[FFmpeg-devel] [PATCH]lavf:Constify AVProbeData* in av_probe_input_format()

2019-02-09 Thread Carl Eugen Hoyos
Hi!

Attached patch constifies a few pointers at the next version bump.

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


Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Convert service name and service provider to utf-8

2019-02-09 Thread Marton Balint



On Sat, 9 Feb 2019, Carl Eugen Hoyos wrote:

+#if CONFIG_ICONV
+if (len && *p < 0x20) {

+const char *encodings[] = {
+"ISO6937", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7", "ISO-8859-8",
+"ISO-8859-9", "ISO-8859-10", "ISO-8859-11", "", "ISO-8859-13",
+"ISO-8859-14", "ISO-8859-15", "", "", "", "",
+"", "ISO-10646", "KSC_5601", "GB2312", "ISO-10646", "UTF-8", "",
+"", "", "", "", "", "", "", "", ""


Instead of ISO-10646 you probably should use UCS-2BE, VLC is also doing this
and the specs refer to the basic multilingual plane. ISO-10646 alone is UCS-4
which uses 4 byte encoding, probably not what we want here.

Otherwise LGTM, thanks.

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


Re: [FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

2019-02-09 Thread Paul B Mahol
On 2/9/19, Carl Eugen Hoyos  wrote:
> 2019-01-30 14:47 GMT+01:00, Carl Eugen Hoyos :
>> 2019-01-29 22:47 GMT+01:00, Carl Eugen Hoyos :
>>> Hi!
>>>
>>> Attached patch fixes decoding NO_DATA amr-wb frames.
>>
>> Now with patch.
>
> Ping.
>
> This patch is supposed to fix the duration of files with NO_DATA
> frames.
>

I guess if its not broken that its ok.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

2019-02-09 Thread Carl Eugen Hoyos
2019-01-30 14:47 GMT+01:00, Carl Eugen Hoyos :
> 2019-01-29 22:47 GMT+01:00, Carl Eugen Hoyos :
>> Hi!
>>
>> Attached patch fixes decoding NO_DATA amr-wb frames.
>
> Now with patch.

Ping.

This patch is supposed to fix the duration of files with NO_DATA
frames.

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


Re: [FFmpeg-devel] [PATCH] ffprobe: fix typo and update URL in man

2019-02-09 Thread Carl Eugen Hoyos
2019-02-09 19:25 GMT+01:00, Reto Kromer :

> The attached patch should fix nits in the doc.

Patch applied.

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


[FFmpeg-devel] avcodec/proresenc_aw : add interlace encoding support

2019-02-09 Thread Martin Vignali
Hello,

Patchs in attach add interlace encoding support to prores aw encoding

Use +ildct flag to switch between progressive and interlace encoding

Use AVFrame flag to switch between tff and bff frame organization.
If AVFrame->interlaced value is not set to 1, but +ildct is set (interlace
encoding of progressive frame), define field order to top (most common case
for prores file)

user can still use setparams filter, to force bff for progressive input if
need.

Pass fate test for me (x86_64, mac os x)

Martin


0003-avcodec-proresenc_aw-move-scantable-to-prores-contex.patch
Description: Binary data


0001-avcodec-proresenc_aw-simplify-frame-flags.patch
Description: Binary data


0004-avcodec-proresenc_aw-merge-funcs-subimage_with_fill-.patch
Description: Binary data


0002-avcodec-proresenc_aw-move-picture-encoding-after-fra.patch
Description: Binary data


0005-avcodec-proresenc_aw-add-interlace-encoding.patch
Description: Binary data


0006-avcodec-proresenc_aw-indent-after-prev-commit.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Convert service name and service provider to utf-8

2019-02-09 Thread Carl Eugen Hoyos
2019-02-09 17:42 GMT+01:00, Marton Balint :
> On Sat, 9 Feb 2019, Carl Eugen Hoyos wrote:
>
>> From 9033f0a18727a7a576c4cc06b9985d6d922d46ad Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sat, 9 Feb 2019 00:49:51 +0100
>> Subject: [PATCH] lavf/mpegts: Convert service_name and service_provider to
>>  utf-8.
>>
>> Fixes ticket #6320.
>> ---
>>  libavformat/mpegts.c |   48
>> 
>>  1 file changed, 48 insertions(+)
>>
>> Diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
>> Index b04fd7b..1e27500 100644
>> --- a/libavformat/mpegts.c
>> +++ b/libavformat/mpegts.c
>> @@ -37,6 +37,9 @@
>>  #include "avio_internal.h"
>>  #include "mpeg.h"
>>  #include "isom.h"
>> +#if CONFIG_ICONV
>> +#include 
>> +#endif
>>
>>  /* maximum size in which we look for synchronization if
>>   * synchronization is lost */
>> @@ -674,6 +677,51 @@ static char *getstr8(const uint8_t **pp, const
>> uint8_t *p_end)
>>  return NULL;
>>  if (len > p_end - p)
>>  return NULL;
>> +#if CONFIG_ICONV
>> +if (len && *p < 0x20) {
>> +char iso8859[] = "ISO-8859-00";
>> +const char *encodings[] = {
>> +"ISO6937", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7",
>> "ISO-8859-8",
>> +"ISO-8859-9", "ISO-8859-10", "ISO-8859-11", "",
>> "ISO-8859-13",
>> +"ISO-8859-14", "ISO-8859-15", "", "", "", "",
>> +"", "ISO-10646", "KSC_5601", "GB2312", "ISO-10646", "UTF-8",
>> "",
>> +"", "", "", "", "", "", "", "", ""
>> +};
>> +iconv_t cd;
>> +char *in, *out;
>> +size_t inlen = len - 1, outlen = inlen * 6 + 1;
>> +if (len >= 3 && p[0] == 0x10 && !p[1] && p[2] && p[2] <= 0xf &&
>> p[2] != 0xc) {
>> +if (p[2] < 10) {
>> +iso8859[9] += p[2];
>> +iso8859[10] = 0;
>> +} else {
>> +iso8859[9]++;
>> +iso8859[10] += p[2] - 10;
>> +}
>
> I think this would be much more readable:
>
> char iso8859[16];
> snprintf(iso8859, sizeof(iso8859), "ISO-8859-%d", p[2]);

Definitely, new patch attached.

Thank you, Carl Eugen
From 8ef77f9fb36c85247a9514fe18f4b48fd23f405c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 9 Feb 2019 18:38:13 +0100
Subject: [PATCH] lavf/mpegts: Convert service_name and service_provider to
 utf-8.

Fixes ticket #6320.
---
 libavformat/mpegts.c |   44 
 1 file changed, 44 insertions(+)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b04fd7b..108514c 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -37,6 +37,9 @@
 #include "avio_internal.h"
 #include "mpeg.h"
 #include "isom.h"
+#if CONFIG_ICONV
+#include 
+#endif
 
 /* maximum size in which we look for synchronization if
  * synchronization is lost */
@@ -674,6 +677,47 @@ static char *getstr8(const uint8_t **pp, const uint8_t *p_end)
 return NULL;
 if (len > p_end - p)
 return NULL;
+#if CONFIG_ICONV
+if (len && *p < 0x20) {
+const char *encodings[] = {
+"ISO6937", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7", "ISO-8859-8",
+"ISO-8859-9", "ISO-8859-10", "ISO-8859-11", "", "ISO-8859-13",
+"ISO-8859-14", "ISO-8859-15", "", "", "", "",
+"", "ISO-10646", "KSC_5601", "GB2312", "ISO-10646", "UTF-8", "",
+"", "", "", "", "", "", "", "", ""
+};
+iconv_t cd;
+char *in, *out;
+size_t inlen = len - 1, outlen = inlen * 6 + 1;
+if (len >= 3 && p[0] == 0x10 && !p[1] && p[2] && p[2] <= 0xf && p[2] != 0xc) {
+char iso8859[12];
+snprintf(iso8859, sizeof(iso8859), "ISO-8859-%d", p[2]);
+inlen -= 2;
+in = (char *)p + 3;
+cd = iconv_open("UTF-8", iso8859);
+} else {
+in = (char *)p + 1;
+cd = iconv_open("UTF-8", encodings[*p]);
+}
+if (cd == (iconv_t)-1)
+goto no_iconv;
+str = out = av_malloc(outlen);
+if (!str) {
+iconv_close(cd);
+return NULL;
+}
+if (iconv(cd, , , , ) == -1) {
+iconv_close(cd);
+av_freep();
+goto no_iconv;
+}
+iconv_close(cd);
+*out = 0;
+*pp = p + len;
+return str;
+}
+no_iconv:
+#endif
 str = av_malloc(len + 1);
 if (!str)
 return NULL;
-- 
1.7.10.4

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


Re: [FFmpeg-devel] [PATCH]lavf/mpegts: Convert service name and service provider to utf-8

2019-02-09 Thread Marton Balint

On Sat, 9 Feb 2019, Carl Eugen Hoyos wrote:


From 9033f0a18727a7a576c4cc06b9985d6d922d46ad Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 9 Feb 2019 00:49:51 +0100
Subject: [PATCH] lavf/mpegts: Convert service_name and service_provider to
 utf-8.

Fixes ticket #6320.
---
 libavformat/mpegts.c |   48 
 1 file changed, 48 insertions(+)

Diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
Index b04fd7b..1e27500 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -37,6 +37,9 @@
 #include "avio_internal.h"
 #include "mpeg.h"
 #include "isom.h"
+#if CONFIG_ICONV
+#include 
+#endif

 /* maximum size in which we look for synchronization if
  * synchronization is lost */
@@ -674,6 +677,51 @@ static char *getstr8(const uint8_t **pp, const uint8_t 
*p_end)
 return NULL;
 if (len > p_end - p)
 return NULL;
+#if CONFIG_ICONV
+if (len && *p < 0x20) {
+char iso8859[] = "ISO-8859-00";
+const char *encodings[] = {
+"ISO6937", "ISO-8859-5", "ISO-8859-6", "ISO-8859-7", "ISO-8859-8",
+"ISO-8859-9", "ISO-8859-10", "ISO-8859-11", "", "ISO-8859-13",
+"ISO-8859-14", "ISO-8859-15", "", "", "", "",
+"", "ISO-10646", "KSC_5601", "GB2312", "ISO-10646", "UTF-8", "",
+"", "", "", "", "", "", "", "", ""
+};
+iconv_t cd;
+char *in, *out;
+size_t inlen = len - 1, outlen = inlen * 6 + 1;
+if (len >= 3 && p[0] == 0x10 && !p[1] && p[2] && p[2] <= 0xf && p[2] 
!= 0xc) {
+if (p[2] < 10) {
+iso8859[9] += p[2];
+iso8859[10] = 0;
+} else {
+iso8859[9]++;
+iso8859[10] += p[2] - 10;
+}


I think this would be much more readable:

char iso8859[16];
snprintf(iso8859, sizeof(iso8859), "ISO-8859-%d", p[2]);

Also inlen should be len - 3 here, no?


+in = (char *)p + 3;
+cd = iconv_open("UTF-8", iso8859);
+} else {
+in = (char *)p + 1;
+cd = iconv_open("UTF-8", encodings[*p]);
+}
+if (cd == (iconv_t)-1)
+goto no_iconv;
+str = out = av_malloc(outlen);
+if (!str) {
+iconv_close(cd);
+return NULL;
+}
+if (iconv(cd, , , , ) == -1) {
+iconv_close(cd);


You are leaking str here.


+goto no_iconv;
+}
+iconv_close(cd);
+*out = 0;
+*pp = p + len;
+return str;
+}
+no_iconv:
+#endif
 str = av_malloc(len + 1);
 if (!str)
 return NULL;
--
1.7.10.4


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


Re: [FFmpeg-devel] [PATCH] libavcodec: vp8 neon optimizations for aarch64

2019-02-09 Thread Carl Eugen Hoyos
2019-02-09 16:46 GMT+01:00, Wang Bin :
>>
>> 2019-02-05 0:59 GMT+01:00, James Almer :
>> > On 1/31/2019 4:23 PM, Carl Eugen Hoyos wrote:
>> >> 2019-01-31 17:04 GMT+01:00, Magnus Röös :
>> >>> Partial port of the ARM Neon for aarch64.
>> >>
>> >> Reproduced a >20% speedup for fate-vp8 and applied.
>> >>
>> >> Thank you, Carl Eugen
>> >
>> > This seems to have broken builds with Clang on aarch64. GCC seems fine.
>> >
>> >
>> http://fate.ffmpeg.org/report.cgi?time=20190204212326=armv8-linux-clang-7
>>
>> Yes.
>>
>> Do you know if Martin plans to push his patch?
>> I can do it but I cannot test MS.
>>
>
> This breaks android(clang), ios and msvc.

Please test Martin's patches or "--extra-cflags=-fno-integrated-as",
see ticket #7728.

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


Re: [FFmpeg-devel] [PATCH] libavcodec: vp8 neon optimizations for aarch64

2019-02-09 Thread Wang Bin
>
> 2019-02-05 0:59 GMT+01:00, James Almer :
> > On 1/31/2019 4:23 PM, Carl Eugen Hoyos wrote:
> >> 2019-01-31 17:04 GMT+01:00, Magnus Röös :
> >>> Partial port of the ARM Neon for aarch64.
> >>
> >> Reproduced a >20% speedup for fate-vp8 and applied.
> >>
> >> Thank you, Carl Eugen
> >
> > This seems to have broken builds with Clang on aarch64. GCC seems fine.
> >
> >
> http://fate.ffmpeg.org/report.cgi?time=20190204212326=armv8-linux-clang-7
>
> Yes.
>
> Do you know if Martin plans to push his patch?
> I can do it but I cannot test MS.
>

This breaks android(clang), ios and msvc.
msvc:
https://ci.appveyor.com/project/wang-bin/avbuild/builds/22246378/job/swwuj2t4djg2pec7
ios: https://travis-ci.org/wang-bin/avbuild/jobs/490977431
android: https://travis-ci.org/wang-bin/avbuild/jobs/490977437
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lavf:Constify AVInputFormat pointer

2019-02-09 Thread Carl Eugen Hoyos
2019-02-09 14:37 GMT+01:00, Carl Eugen Hoyos :
> 2019-02-01 1:13 GMT+01:00, Michael Niedermayer :
>> On Thu, Jan 31, 2019 at 09:54:14PM +0100, Carl Eugen Hoyos wrote:
>>> 2019-01-31 21:43 GMT+01:00, Carl Eugen Hoyos :
>>> > Hi!
>>> >
>>> > Attached patch persistently uses "const" for AVInputFormat pointer
>>> > after the next version bump.
>>>
>>> Now with an actually working version.
>>>
>>> Please comment, Carl Eugen
>>
>>>  allformats.c |6 +-
>>>  avformat.h   |   32 +++-
>>>  dashdec.c|3 +++
>>>  format.c |   32 ++--
>>>  hls.c|3 +++
>>>  img2dec.c|2 +-
>>>  mpeg.c   |3 +++
>>>  rtpdec_asf.c |3 +++
>>>  sapdec.c |3 +++
>>>  utils.c  |   11 ---
>>>  version.h|3 +++
>>>  11 files changed, 93 insertions(+), 8 deletions(-)
>>> d3aece2f0b9a9c3ff8b2a187ceccdc744ea40de2
>>> 0001-lavf-Constify-AVInputFormat-pointer.patch
>>> From f383a7f914b2c7240378b404d529a7d73c68941b Mon Sep 17 00:00:00 2001
>>> From: Carl Eugen Hoyos 
>>> Date: Thu, 31 Jan 2019 21:51:56 +0100
>>> Subject: [PATCH] lavf: Constify AVInputFormat pointer.
>>>
>>> ---
>>>  libavformat/allformats.c |6 +-
>>>  libavformat/avformat.h   |   32 +++-
>>>  libavformat/dashdec.c|3 +++
>>>  libavformat/format.c |   32 ++--
>>>  libavformat/hls.c|3 +++
>>>  libavformat/img2dec.c|2 +-
>>>  libavformat/mpeg.c   |3 +++
>>>  libavformat/rtpdec_asf.c |3 +++
>>>  libavformat/sapdec.c |3 +++
>>>  libavformat/utils.c  |   11 ---
>>>  libavformat/version.h|3 +++
>>>  11 files changed, 93 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
>>> index 0684498..01c4c14 100644
>>> --- a/libavformat/allformats.c
>>> +++ b/libavformat/allformats.c
>>> @@ -583,7 +583,11 @@ AVInputFormat *av_iformat_next(const AVInputFormat
>>> *f)
>>>  ff_thread_once(_format_next_init, av_format_init_next);
>>>
>>>  if (f)
>>> -return f->next;
>>> +return
>>> +#if !FF_API_AVINPUTFORMAT
>>> +   (AVInputFormat *)
>>> +#endif
>>> + f->next;
>>>  else {
>>>  void *opaque = NULL;
>>>  return (AVInputFormat *)av_demuxer_iterate();
>>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>> index fdaffa5..7c4ec8f 100644
>>> --- a/libavformat/avformat.h
>>> +++ b/libavformat/avformat.h
>>> @@ -676,7 +676,10 @@ typedef struct AVInputFormat {
>>>   * New public fields should be added right above.
>>>   *
>>>   */
>>> -struct AVInputFormat *next;
>>> +#if !FF_API_AVINPUTFORMAT
>>> +const
>>> +#endif
>>> +struct AVInputFormat *next;
>>
>> some av_const59 which is defined to nothing until version 59
>> should avoid the repeated #if/endif
>> it would require an eventual update to change it to const at some
>> point but it would avoid most preprocessor comands
>
> New patch attached.

Now with correct condition.

Carl Eugen
From 7ab30f3dbc869ad9641d9b791bb9e3cd97a432fa Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 9 Feb 2019 14:36:07 +0100
Subject: [PATCH] lavf: Constify AVInputFormat pointer.

---
 libavformat/allformats.c |4 
 libavformat/avformat.h   |   23 ++-
 libavformat/avidec.c |2 +-
 libavformat/dashdec.c|2 +-
 libavformat/format.c |   16 
 libavformat/hls.c|2 +-
 libavformat/img2dec.c|2 +-
 libavformat/mpeg.c   |2 +-
 libavformat/rtpdec_asf.c |2 +-
 libavformat/sapdec.c |2 +-
 libavformat/utils.c  |6 +++---
 libavformat/version.h|3 +++
 12 files changed, 39 insertions(+), 27 deletions(-)

diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0684498..242edc3 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -583,7 +583,11 @@ AVInputFormat *av_iformat_next(const AVInputFormat *f)
 ff_thread_once(_format_next_init, av_format_init_next);
 
 if (f)
+#if FF_API_AVIOFORMAT
 return f->next;
+#else
+return (AVInputFormat *) f->next;
+#endif
 else {
 void *opaque = NULL;
 return (AVInputFormat *)av_demuxer_iterate();
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index fdaffa5..a866c33 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -676,7 +676,12 @@ typedef struct AVInputFormat {
  * New public fields should be added right above.
  *
  */
-struct AVInputFormat *next;
+#if FF_API_AVIOFORMAT
+#define av_const59
+#else
+#define av_const59 const
+#endif
+av_const59 struct AVInputFormat *next;
 
 /**
  * Raw demuxers store their codec ID here.
@@ -1346,7 +1351,7 @@ typedef 

Re: [FFmpeg-devel] [PATCH]lavf:Constify AVOutputFormat pointer

2019-02-09 Thread Carl Eugen Hoyos
2019-02-09 15:44 GMT+01:00, Carl Eugen Hoyos :
> 2019-02-09 15:42 GMT+01:00, James Almer :
>> On 2/9/2019 11:23 AM, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> Attached patch is supposed to constify all occurrences of
>>> AVOutputFormat in libavformat.
>>>
>>> Please comment, Carl Eugen
>>>
>>>
>>> 0001-lavf-Constify-AVOutputFormat-pointer.patch
>>>
>>> From ba32f41824df07b7a6cb45964ef912c5fc05b276 Mon Sep 17 00:00:00 2001
>>> From: Carl Eugen Hoyos 
>>> Date: Sat, 9 Feb 2019 15:21:17 +0100
>>> Subject: [PATCH] lavf: Constify AVOutputFormat pointer.
>>>
>>> ---
>>>  libavformat/allformats.c |4 
>>>  libavformat/avformat.h   |   15 ++-
>>>  libavformat/fifo.c   |4 ++--
>>>  libavformat/format.c |6 +++---
>>>  libavformat/hdsenc.c |2 +-
>>>  libavformat/hlsenc.c |4 ++--
>>>  libavformat/mux.c|4 ++--
>>>  libavformat/rtp.c|2 +-
>>>  libavformat/rtpenc_chain.c   |2 +-
>>>  libavformat/rtpenc_mpegts.c  |4 ++--
>>>  libavformat/segment.c|2 +-
>>>  libavformat/smoothstreamingenc.c |2 +-
>>>  libavformat/version.h|3 +++
>>>  libavformat/webm_chunk.c |2 +-
>>>  14 files changed, 34 insertions(+), 22 deletions(-)
>>>
>>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
>>> index 0684498..64d0f02 100644
>>> --- a/libavformat/allformats.c
>>> +++ b/libavformat/allformats.c
>>> @@ -595,7 +595,11 @@ AVOutputFormat *av_oformat_next(const
>>> AVOutputFormat
>>> *f)
>>>  ff_thread_once(_format_next_init, av_format_init_next);
>>>
>>>  if (f)
>>> +#if FF_API_AVIOFORMAT
>>> +return (AVOutputFormat *) f->next;
>>> +#else
>>>  return f->next;
>>> +#endif
>>>  else {
>>>  void *opaque = NULL;
>>>  return (AVOutputFormat *)av_muxer_iterate();
>>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>>> index fdaffa5..52922c0 100644
>>> --- a/libavformat/avformat.h
>>> +++ b/libavformat/avformat.h
>>> @@ -532,7 +532,12 @@ typedef struct AVOutputFormat {
>>>   * New public fields should be added right above.
>>>   *
>>>   */
>>> -struct AVOutputFormat *next;
>>> +#if FF_API_AVIOFORMAT
>>> +#define av_const59 const
>>> +#else
>>> +#define av_const59
>>> +#endif
>>
>> Shouldn't it be the other way around? FF_API_AVIOFORMAT
>> evaluates to 1 when major is < 59.
>
> Yes, I had realized this in the meantime, new patch attached.

And with the correct version in version.h

Carl Eugen
From 12857febacc9786c591d6d4c464bba1e4f4d7548 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 9 Feb 2019 15:43:42 +0100
Subject: [PATCH] lavf: Constify AVOutputFormat pointer.

---
 libavformat/allformats.c |4 
 libavformat/avformat.h   |   15 ++-
 libavformat/fifo.c   |4 ++--
 libavformat/format.c |6 +++---
 libavformat/hdsenc.c |2 +-
 libavformat/hlsenc.c |4 ++--
 libavformat/mux.c|4 ++--
 libavformat/rtp.c|2 +-
 libavformat/rtpenc_chain.c   |2 +-
 libavformat/rtpenc_mpegts.c  |4 ++--
 libavformat/segment.c|2 +-
 libavformat/smoothstreamingenc.c |2 +-
 libavformat/version.h|3 +++
 libavformat/webm_chunk.c |2 +-
 14 files changed, 34 insertions(+), 22 deletions(-)

diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0684498..411cfe7 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -595,7 +595,11 @@ AVOutputFormat *av_oformat_next(const AVOutputFormat *f)
 ff_thread_once(_format_next_init, av_format_init_next);
 
 if (f)
+#if FF_API_AVIOFORMAT
 return f->next;
+#else
+return (AVOutputFormat *) f->next;
+#endif
 else {
 void *opaque = NULL;
 return (AVOutputFormat *)av_muxer_iterate();
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index fdaffa5..c8dfe88 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -532,7 +532,12 @@ typedef struct AVOutputFormat {
  * New public fields should be added right above.
  *
  */
-struct AVOutputFormat *next;
+#if FF_API_AVIOFORMAT
+#define av_const59
+#else
+#define av_const59 const
+#endif
+av_const59 struct AVOutputFormat *next;
 /**
  * size of private data so that it can be allocated in the wrapper
  */
@@ -1353,7 +1358,7 @@ typedef struct AVFormatContext {
  *
  * Muxing only, must be set by the caller before avformat_write_header().
  */
-struct AVOutputFormat *oformat;
+av_const59 struct AVOutputFormat *oformat;
 
 /**
  * Format private data. This is an AVOptions-enabled struct
@@ -2211,7 +2216,7 @@ AVProgram 

Re: [FFmpeg-devel] [PATCH]lavf:Constify AVOutputFormat pointer

2019-02-09 Thread Carl Eugen Hoyos
2019-02-09 15:42 GMT+01:00, James Almer :
> On 2/9/2019 11:23 AM, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch is supposed to constify all occurrences of
>> AVOutputFormat in libavformat.
>>
>> Please comment, Carl Eugen
>>
>>
>> 0001-lavf-Constify-AVOutputFormat-pointer.patch
>>
>> From ba32f41824df07b7a6cb45964ef912c5fc05b276 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sat, 9 Feb 2019 15:21:17 +0100
>> Subject: [PATCH] lavf: Constify AVOutputFormat pointer.
>>
>> ---
>>  libavformat/allformats.c |4 
>>  libavformat/avformat.h   |   15 ++-
>>  libavformat/fifo.c   |4 ++--
>>  libavformat/format.c |6 +++---
>>  libavformat/hdsenc.c |2 +-
>>  libavformat/hlsenc.c |4 ++--
>>  libavformat/mux.c|4 ++--
>>  libavformat/rtp.c|2 +-
>>  libavformat/rtpenc_chain.c   |2 +-
>>  libavformat/rtpenc_mpegts.c  |4 ++--
>>  libavformat/segment.c|2 +-
>>  libavformat/smoothstreamingenc.c |2 +-
>>  libavformat/version.h|3 +++
>>  libavformat/webm_chunk.c |2 +-
>>  14 files changed, 34 insertions(+), 22 deletions(-)
>>
>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
>> index 0684498..64d0f02 100644
>> --- a/libavformat/allformats.c
>> +++ b/libavformat/allformats.c
>> @@ -595,7 +595,11 @@ AVOutputFormat *av_oformat_next(const AVOutputFormat
>> *f)
>>  ff_thread_once(_format_next_init, av_format_init_next);
>>
>>  if (f)
>> +#if FF_API_AVIOFORMAT
>> +return (AVOutputFormat *) f->next;
>> +#else
>>  return f->next;
>> +#endif
>>  else {
>>  void *opaque = NULL;
>>  return (AVOutputFormat *)av_muxer_iterate();
>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>> index fdaffa5..52922c0 100644
>> --- a/libavformat/avformat.h
>> +++ b/libavformat/avformat.h
>> @@ -532,7 +532,12 @@ typedef struct AVOutputFormat {
>>   * New public fields should be added right above.
>>   *
>>   */
>> -struct AVOutputFormat *next;
>> +#if FF_API_AVIOFORMAT
>> +#define av_const59 const
>> +#else
>> +#define av_const59
>> +#endif
>
> Shouldn't it be the other way around? FF_API_AVIOFORMAT
> evaluates to 1 when major is < 59.

Yes, I had realized this in the meantime, new patch attached.

Please comment, Carl Eugen
From 12857febacc9786c591d6d4c464bba1e4f4d7548 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 9 Feb 2019 15:43:42 +0100
Subject: [PATCH] lavf: Constify AVOutputFormat pointer.

---
 libavformat/allformats.c |4 
 libavformat/avformat.h   |   15 ++-
 libavformat/fifo.c   |4 ++--
 libavformat/format.c |6 +++---
 libavformat/hdsenc.c |2 +-
 libavformat/hlsenc.c |4 ++--
 libavformat/mux.c|4 ++--
 libavformat/rtp.c|2 +-
 libavformat/rtpenc_chain.c   |2 +-
 libavformat/rtpenc_mpegts.c  |4 ++--
 libavformat/segment.c|2 +-
 libavformat/smoothstreamingenc.c |2 +-
 libavformat/version.h|3 +++
 libavformat/webm_chunk.c |2 +-
 14 files changed, 34 insertions(+), 22 deletions(-)

diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0684498..411cfe7 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -595,7 +595,11 @@ AVOutputFormat *av_oformat_next(const AVOutputFormat *f)
 ff_thread_once(_format_next_init, av_format_init_next);
 
 if (f)
+#if FF_API_AVIOFORMAT
 return f->next;
+#else
+return (AVOutputFormat *) f->next;
+#endif
 else {
 void *opaque = NULL;
 return (AVOutputFormat *)av_muxer_iterate();
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index fdaffa5..c8dfe88 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -532,7 +532,12 @@ typedef struct AVOutputFormat {
  * New public fields should be added right above.
  *
  */
-struct AVOutputFormat *next;
+#if FF_API_AVIOFORMAT
+#define av_const59
+#else
+#define av_const59 const
+#endif
+av_const59 struct AVOutputFormat *next;
 /**
  * size of private data so that it can be allocated in the wrapper
  */
@@ -1353,7 +1358,7 @@ typedef struct AVFormatContext {
  *
  * Muxing only, must be set by the caller before avformat_write_header().
  */
-struct AVOutputFormat *oformat;
+av_const59 struct AVOutputFormat *oformat;
 
 /**
  * Format private data. This is an AVOptions-enabled struct
@@ -2211,7 +2216,7 @@ AVProgram *av_new_program(AVFormatContext *s, int id);
  * @return >= 0 in case of success, a negative AVERROR code in case of
  * failure
  */
-int 

Re: [FFmpeg-devel] [PATCH]lavf:Constify AVOutputFormat pointer

2019-02-09 Thread James Almer
On 2/9/2019 11:23 AM, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch is supposed to constify all occurrences of
> AVOutputFormat in libavformat.
> 
> Please comment, Carl Eugen
> 
> 
> 0001-lavf-Constify-AVOutputFormat-pointer.patch
> 
> From ba32f41824df07b7a6cb45964ef912c5fc05b276 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sat, 9 Feb 2019 15:21:17 +0100
> Subject: [PATCH] lavf: Constify AVOutputFormat pointer.
> 
> ---
>  libavformat/allformats.c |4 
>  libavformat/avformat.h   |   15 ++-
>  libavformat/fifo.c   |4 ++--
>  libavformat/format.c |6 +++---
>  libavformat/hdsenc.c |2 +-
>  libavformat/hlsenc.c |4 ++--
>  libavformat/mux.c|4 ++--
>  libavformat/rtp.c|2 +-
>  libavformat/rtpenc_chain.c   |2 +-
>  libavformat/rtpenc_mpegts.c  |4 ++--
>  libavformat/segment.c|2 +-
>  libavformat/smoothstreamingenc.c |2 +-
>  libavformat/version.h|3 +++
>  libavformat/webm_chunk.c |2 +-
>  14 files changed, 34 insertions(+), 22 deletions(-)
> 
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 0684498..64d0f02 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -595,7 +595,11 @@ AVOutputFormat *av_oformat_next(const AVOutputFormat *f)
>  ff_thread_once(_format_next_init, av_format_init_next);
>  
>  if (f)
> +#if FF_API_AVIOFORMAT
> +return (AVOutputFormat *) f->next;
> +#else
>  return f->next;
> +#endif
>  else {
>  void *opaque = NULL;
>  return (AVOutputFormat *)av_muxer_iterate();
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index fdaffa5..52922c0 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -532,7 +532,12 @@ typedef struct AVOutputFormat {
>   * New public fields should be added right above.
>   *
>   */
> -struct AVOutputFormat *next;
> +#if FF_API_AVIOFORMAT
> +#define av_const59 const
> +#else
> +#define av_const59
> +#endif

Shouldn't it be the other way around? FF_API_AVIOFORMAT evaluates to 1
when major is < 59.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH]lavf:Constify AVOutputFormat pointer

2019-02-09 Thread Carl Eugen Hoyos
Hi!

Attached patch is supposed to constify all occurrences of
AVOutputFormat in libavformat.

Please comment, Carl Eugen
From ba32f41824df07b7a6cb45964ef912c5fc05b276 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 9 Feb 2019 15:21:17 +0100
Subject: [PATCH] lavf: Constify AVOutputFormat pointer.

---
 libavformat/allformats.c |4 
 libavformat/avformat.h   |   15 ++-
 libavformat/fifo.c   |4 ++--
 libavformat/format.c |6 +++---
 libavformat/hdsenc.c |2 +-
 libavformat/hlsenc.c |4 ++--
 libavformat/mux.c|4 ++--
 libavformat/rtp.c|2 +-
 libavformat/rtpenc_chain.c   |2 +-
 libavformat/rtpenc_mpegts.c  |4 ++--
 libavformat/segment.c|2 +-
 libavformat/smoothstreamingenc.c |2 +-
 libavformat/version.h|3 +++
 libavformat/webm_chunk.c |2 +-
 14 files changed, 34 insertions(+), 22 deletions(-)

diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0684498..64d0f02 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -595,7 +595,11 @@ AVOutputFormat *av_oformat_next(const AVOutputFormat *f)
 ff_thread_once(_format_next_init, av_format_init_next);
 
 if (f)
+#if FF_API_AVIOFORMAT
+return (AVOutputFormat *) f->next;
+#else
 return f->next;
+#endif
 else {
 void *opaque = NULL;
 return (AVOutputFormat *)av_muxer_iterate();
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index fdaffa5..52922c0 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -532,7 +532,12 @@ typedef struct AVOutputFormat {
  * New public fields should be added right above.
  *
  */
-struct AVOutputFormat *next;
+#if FF_API_AVIOFORMAT
+#define av_const59 const
+#else
+#define av_const59
+#endif
+av_const59 struct AVOutputFormat *next;
 /**
  * size of private data so that it can be allocated in the wrapper
  */
@@ -1353,7 +1358,7 @@ typedef struct AVFormatContext {
  *
  * Muxing only, must be set by the caller before avformat_write_header().
  */
-struct AVOutputFormat *oformat;
+av_const59 struct AVOutputFormat *oformat;
 
 /**
  * Format private data. This is an AVOptions-enabled struct
@@ -2211,7 +2216,7 @@ AVProgram *av_new_program(AVFormatContext *s, int id);
  * @return >= 0 in case of success, a negative AVERROR code in case of
  * failure
  */
-int avformat_alloc_output_context2(AVFormatContext **ctx, AVOutputFormat *oformat,
+int avformat_alloc_output_context2(AVFormatContext **ctx, av_const59 AVOutputFormat *oformat,
const char *format_name, const char *filename);
 
 /**
@@ -2687,14 +2692,14 @@ int av_write_trailer(AVFormatContext *s);
  * @param mime_type if non-NULL checks if mime_type matches with the
  * MIME type of the registered formats
  */
-AVOutputFormat *av_guess_format(const char *short_name,
+av_const59 AVOutputFormat *av_guess_format(const char *short_name,
 const char *filename,
 const char *mime_type);
 
 /**
  * Guess the codec ID based upon muxer and filename.
  */
-enum AVCodecID av_guess_codec(AVOutputFormat *fmt, const char *short_name,
+enum AVCodecID av_guess_codec(av_const59 AVOutputFormat *fmt, const char *short_name,
 const char *filename, const char *mime_type,
 enum AVMediaType type);
 
diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index 145e2e2..72efe4f 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -442,7 +442,7 @@ static void *fifo_consumer_thread(void *data)
 return NULL;
 }
 
-static int fifo_mux_init(AVFormatContext *avf, AVOutputFormat *oformat,
+static int fifo_mux_init(AVFormatContext *avf, const AVOutputFormat *oformat,
  const char *filename)
 {
 FifoContext *fifo = avf->priv_data;
@@ -481,7 +481,7 @@ static int fifo_mux_init(AVFormatContext *avf, AVOutputFormat *oformat,
 static int fifo_init(AVFormatContext *avf)
 {
 FifoContext *fifo = avf->priv_data;
-AVOutputFormat *oformat;
+const AVOutputFormat *oformat;
 int ret = 0;
 
 if (fifo->recovery_wait_streamtime && !fifo->drop_pkts_on_overflow) {
diff --git a/libavformat/format.c b/libavformat/format.c
index 2c4c895..220e3a0 100644
--- a/libavformat/format.c
+++ b/libavformat/format.c
@@ -48,7 +48,7 @@ int av_match_ext(const char *filename, const char *extensions)
 return 0;
 }
 
-AVOutputFormat *av_guess_format(const char *short_name, const char *filename,
+av_const59 AVOutputFormat *av_guess_format(const char *short_name, const char *filename,
 const char *mime_type)
 {
 const AVOutputFormat *fmt = NULL;
@@ -84,12 +84,12 @@ AVOutputFormat 

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/sbrdsp_fixed.c: remove input value limit for sbr_sum_square_c()

2019-02-09 Thread Michael Niedermayer
On Wed, Feb 06, 2019 at 08:23:15PM +0100, Carl Eugen Hoyos wrote:
> 2019-02-06 20:17 GMT+01:00, Michael Niedermayer :
> > On Wed, Feb 06, 2019 at 01:57:37PM +0100, Carl Eugen Hoyos wrote:
> >> 2019-02-03 18:21 GMT+01:00, Michael Niedermayer :
> >> > Fixes: 1377/clusterfuzz-testcase-minimized-5487049807233024
> >> > Fixes: assertion failure in sbr_sum_square_c()
> >>
> >> This changes the output, no?
> >
> > in normal cases, no it should not
> > It may be that one can construct a case thats not yet in the range
> > where the old code was undefined, the new code is defined by
> > 1 in a Quintillion differently and then the decoder output which is
> > not 64bit integers still has a off by 1 difference.
> > That could be, or it might be not, i dont know
> >
> > You can certainly have a differenceof the old code crashing with
> > assertion failure though if thst is considered "different"
> >
> >> Why are the asm implementations not affected?
> >
> > Please correct me if iam wrong but
> > i think only the float but not the integer version
> > of this have been optimized.
> 
> Thank you for the explanation!

will apply patchset

thanks

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

Elect your leaders based on what they did after the last election, not
based on what they say before an election.



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


Re: [FFmpeg-devel] [PATCH]lavf:Constify AVInputFormat pointer

2019-02-09 Thread Carl Eugen Hoyos
2019-02-01 1:13 GMT+01:00, Michael Niedermayer :
> On Thu, Jan 31, 2019 at 09:54:14PM +0100, Carl Eugen Hoyos wrote:
>> 2019-01-31 21:43 GMT+01:00, Carl Eugen Hoyos :
>> > Hi!
>> >
>> > Attached patch persistently uses "const" for AVInputFormat pointer
>> > after the next version bump.
>>
>> Now with an actually working version.
>>
>> Please comment, Carl Eugen
>
>>  allformats.c |6 +-
>>  avformat.h   |   32 +++-
>>  dashdec.c|3 +++
>>  format.c |   32 ++--
>>  hls.c|3 +++
>>  img2dec.c|2 +-
>>  mpeg.c   |3 +++
>>  rtpdec_asf.c |3 +++
>>  sapdec.c |3 +++
>>  utils.c  |   11 ---
>>  version.h|3 +++
>>  11 files changed, 93 insertions(+), 8 deletions(-)
>> d3aece2f0b9a9c3ff8b2a187ceccdc744ea40de2
>> 0001-lavf-Constify-AVInputFormat-pointer.patch
>> From f383a7f914b2c7240378b404d529a7d73c68941b Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Thu, 31 Jan 2019 21:51:56 +0100
>> Subject: [PATCH] lavf: Constify AVInputFormat pointer.
>>
>> ---
>>  libavformat/allformats.c |6 +-
>>  libavformat/avformat.h   |   32 +++-
>>  libavformat/dashdec.c|3 +++
>>  libavformat/format.c |   32 ++--
>>  libavformat/hls.c|3 +++
>>  libavformat/img2dec.c|2 +-
>>  libavformat/mpeg.c   |3 +++
>>  libavformat/rtpdec_asf.c |3 +++
>>  libavformat/sapdec.c |3 +++
>>  libavformat/utils.c  |   11 ---
>>  libavformat/version.h|3 +++
>>  11 files changed, 93 insertions(+), 8 deletions(-)
>>
>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
>> index 0684498..01c4c14 100644
>> --- a/libavformat/allformats.c
>> +++ b/libavformat/allformats.c
>> @@ -583,7 +583,11 @@ AVInputFormat *av_iformat_next(const AVInputFormat
>> *f)
>>  ff_thread_once(_format_next_init, av_format_init_next);
>>
>>  if (f)
>> -return f->next;
>> +return
>> +#if !FF_API_AVINPUTFORMAT
>> +   (AVInputFormat *)
>> +#endif
>> + f->next;
>>  else {
>>  void *opaque = NULL;
>>  return (AVInputFormat *)av_demuxer_iterate();
>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>> index fdaffa5..7c4ec8f 100644
>> --- a/libavformat/avformat.h
>> +++ b/libavformat/avformat.h
>> @@ -676,7 +676,10 @@ typedef struct AVInputFormat {
>>   * New public fields should be added right above.
>>   *
>>   */
>> -struct AVInputFormat *next;
>> +#if !FF_API_AVINPUTFORMAT
>> +const
>> +#endif
>> +struct AVInputFormat *next;
>
> some av_const59 which is defined to nothing until version 59
> should avoid the repeated #if/endif
> it would require an eventual update to change it to const at some
> point but it would avoid most preprocessor comands

New patch attached.

Please comment, Carl Eugen
From 7ab30f3dbc869ad9641d9b791bb9e3cd97a432fa Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 9 Feb 2019 14:36:07 +0100
Subject: [PATCH] lavf: Constify AVInputFormat pointer.

---
 libavformat/allformats.c |4 
 libavformat/avformat.h   |   23 ++-
 libavformat/avidec.c |2 +-
 libavformat/dashdec.c|2 +-
 libavformat/format.c |   16 
 libavformat/hls.c|2 +-
 libavformat/img2dec.c|2 +-
 libavformat/mpeg.c   |2 +-
 libavformat/rtpdec_asf.c |2 +-
 libavformat/sapdec.c |2 +-
 libavformat/utils.c  |6 +++---
 libavformat/version.h|3 +++
 12 files changed, 39 insertions(+), 27 deletions(-)

diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0684498..242edc3 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -583,7 +583,11 @@ AVInputFormat *av_iformat_next(const AVInputFormat *f)
 ff_thread_once(_format_next_init, av_format_init_next);
 
 if (f)
+#if FF_API_AVIOFORMAT
+return (AVInputFormat *) f->next;
+#else
 return f->next;
+#endif
 else {
 void *opaque = NULL;
 return (AVInputFormat *)av_demuxer_iterate();
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index fdaffa5..a866c33 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -676,7 +676,12 @@ typedef struct AVInputFormat {
  * New public fields should be added right above.
  *
  */
-struct AVInputFormat *next;
+#if FF_API_AVIOFORMAT
+#define av_const59 const
+#else
+#define av_const59
+#endif
+av_const59 struct AVInputFormat *next;
 
 /**
  * Raw demuxers store their codec ID here.
@@ -1346,7 +1351,7 @@ typedef struct AVFormatContext {
  *
  * Demuxing only, set by avformat_open_input().
  */
-struct AVInputFormat *iformat;
+av_const59 

[FFmpeg-devel] [PATCH 1/2] libavcodec/zmbvenc: block scoring improvements/bug fixes

2019-02-09 Thread Matthew Fearnley
- Improve block choices by counting 0-bytes in the entropy score
- Make histogram use uint16_t type, to allow byte counts from 16*16
(current block size) up to 255*255 (maximum allowed 8bpp block size)
- Make sure score table is big enough for a full block's worth of bytes
- Calculate *xored without using code in inner loop
---
 libavcodec/zmbvenc.c | 22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/libavcodec/zmbvenc.c b/libavcodec/zmbvenc.c
index 4d9147657d..3df6e724c8 100644
--- a/libavcodec/zmbvenc.c
+++ b/libavcodec/zmbvenc.c
@@ -55,7 +55,7 @@ typedef struct ZmbvEncContext {
 int keyint, curfrm;
 z_stream zstream;
 
-int score_tab[256];
+int score_tab[ZMBV_BLOCK * ZMBV_BLOCK + 1];
 } ZmbvEncContext;
 
 
@@ -69,20 +69,26 @@ static inline int block_cmp(ZmbvEncContext *c, uint8_t 
*src, int stride,
 {
 int sum = 0;
 int i, j;
-uint8_t histogram[256] = {0};
+uint16_t histogram[256] = {0};
 
-*xored = 0;
+/* Build frequency histogram of byte values for src[] ^ src2[] */
 for(j = 0; j < bh; j++){
 for(i = 0; i < bw; i++){
 int t = src[i] ^ src2[i];
 histogram[t]++;
-*xored |= t;
 }
 src += stride;
 src2 += stride2;
 }
 
-for(i = 1; i < 256; i++)
+/* If not all the xored values were 0, then the blocks are different */
+*xored = (histogram[0] < bw * bh);
+
+/* Exit early if blocks are equal */
+if (!*xored) return 0;
+
+/* Sum the entropy of all values */
+for(i = 0; i < 256; i++)
 sum += c->score_tab[histogram[i]];
 
 return sum;
@@ -278,7 +284,11 @@ static av_cold int encode_init(AVCodecContext *avctx)
 int i;
 int lvl = 9;
 
-for(i=1; i<256; i++)
+/* Entropy-based score tables for comparing blocks.
+ * Suitable for blocks up to (ZMBV_BLOCK * ZMBV_BLOCK) bytes.
+ * Scores are nonnegative, lower is better.
+ */
+for(i = 1; i <= ZMBV_BLOCK * ZMBV_BLOCK; i++)
 c->score_tab[i] = -i * log2(i / (double)(ZMBV_BLOCK * ZMBV_BLOCK)) * 
256;
 
 c->avctx = avctx;
-- 
2.17.1

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


[FFmpeg-devel] [PATCH 2/2] libavcodec/zmbvenc: motion estimation improvements/bug fixes:

2019-02-09 Thread Matthew Fearnley
- Clamp ME range to -64..63 (prevents corruption when me_range is too high)
- Allow MV's up to *and including* the positive range limit
- Allow out-of-edge ME by padding the prev buffer with a border of 0's
- Try previous MV before checking the rest (improves speed in some cases)
- More robust logic in code - ensure *mx,*my,*xored are updated together
---
 libavcodec/zmbvenc.c | 64 +++-
 1 file changed, 46 insertions(+), 18 deletions(-)

diff --git a/libavcodec/zmbvenc.c b/libavcodec/zmbvenc.c
index 3df6e724c8..e92193478b 100644
--- a/libavcodec/zmbvenc.c
+++ b/libavcodec/zmbvenc.c
@@ -45,11 +45,11 @@
 typedef struct ZmbvEncContext {
 AVCodecContext *avctx;
 
-int range;
+int lrange, urange;
 uint8_t *comp_buf, *work_buf;
 uint8_t pal[768];
 uint32_t pal2[256]; //for quick comparisons
-uint8_t *prev;
+uint8_t *prev, *prev_buf;
 int pstride;
 int comp_size;
 int keyint, curfrm;
@@ -61,7 +61,6 @@ typedef struct ZmbvEncContext {
 
 /** Block comparing function
  * XXX should be optimized and moved to DSPContext
- * TODO handle out of edge ME
  */
 static inline int block_cmp(ZmbvEncContext *c, uint8_t *src, int stride,
 uint8_t *src2, int stride2, int bw, int bh,
@@ -100,23 +99,42 @@ static inline int block_cmp(ZmbvEncContext *c, uint8_t 
*src, int stride,
 static int zmbv_me(ZmbvEncContext *c, uint8_t *src, int sstride, uint8_t *prev,
int pstride, int x, int y, int *mx, int *my, int *xored)
 {
-int dx, dy, tx, ty, tv, bv, bw, bh;
+int dx, dy, txored, tv, bv, bw, bh;
+int mx0, my0;
 
-*mx = *my = 0;
+mx0 = *mx;
+my0 = *my;
 bw = FFMIN(ZMBV_BLOCK, c->avctx->width - x);
 bh = FFMIN(ZMBV_BLOCK, c->avctx->height - y);
+
+/* Try (0,0) */
 bv = block_cmp(c, src, sstride, prev, pstride, bw, bh, xored);
+*mx = *my = 0;
 if(!bv) return 0;
-for(ty = FFMAX(y - c->range, 0); ty < FFMIN(y + c->range, c->avctx->height 
- bh); ty++){
-for(tx = FFMAX(x - c->range, 0); tx < FFMIN(x + c->range, 
c->avctx->width - bw); tx++){
-if(tx == x && ty == y) continue; // we already tested this block
-dx = tx - x;
-dy = ty - y;
-tv = block_cmp(c, src, sstride, prev + dx + dy * pstride, pstride, 
bw, bh, xored);
+
+/* Try previous block's MV (if not 0,0) */
+if (mx0 || my0){
+tv = block_cmp(c, src, sstride, prev + mx0 + my0 * pstride, pstride, 
bw, bh, );
+if(tv < bv){
+bv = tv;
+*mx = mx0;
+*my = my0;
+*xored = txored;
+if(!bv) return 0;
+}
+}
+
+/* Try other MVs from top-to-bottom, left-to-right */
+for(dy = -c->lrange; dy <= c->urange; dy++){
+for(dx = -c->lrange; dx <= c->urange; dx++){
+if(!dx && !dy) continue; // we already tested this block
+if(dx == mx0 && dy == my0) continue; // this one too
+tv = block_cmp(c, src, sstride, prev + dx + dy * pstride, pstride, 
bw, bh, );
 if(tv < bv){
  bv = tv;
  *mx = dx;
  *my = dy;
+ *xored = txored;
  if(!bv) return 0;
  }
  }
@@ -181,7 +199,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 int x, y, bh2, bw2, xored;
 uint8_t *tsrc, *tprev;
 uint8_t *mv;
-int mx, my;
+int mx = 0, my = 0;
 
 bw = (avctx->width + ZMBV_BLOCK - 1) / ZMBV_BLOCK;
 bh = (avctx->height + ZMBV_BLOCK - 1) / ZMBV_BLOCK;
@@ -269,7 +287,7 @@ static av_cold int encode_end(AVCodecContext *avctx)
 av_freep(>work_buf);
 
 deflateEnd(>zstream);
-av_freep(>prev);
+av_freep(>prev_buf);
 
 return 0;
 }
@@ -283,6 +301,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
 int zret; // Zlib return code
 int i;
 int lvl = 9;
+int prev_size, prev_offset;
 
 /* Entropy-based score tables for comparing blocks.
  * Suitable for blocks up to (ZMBV_BLOCK * ZMBV_BLOCK) bytes.
@@ -295,9 +314,13 @@ static av_cold int encode_init(AVCodecContext *avctx)
 
 c->curfrm = 0;
 c->keyint = avctx->keyint_min;
-c->range = 8;
-if(avctx->me_range > 0)
-c->range = FFMIN(avctx->me_range, 127);
+
+/* Motion estimation range: maximum distance is -64..63 */
+c->lrange = c->urange = 8;
+if(avctx->me_range > 0){
+c->lrange = FFMIN(avctx->me_range, 64);
+c->urange = FFMIN(avctx->me_range, 63);
+}
 
 if(avctx->compression_level >= 0)
 lvl = avctx->compression_level;
@@ -323,11 +346,16 @@ static av_cold int encode_init(AVCodecContext *avctx)
 av_log(avctx, AV_LOG_ERROR, "Can't allocate compression buffer.\n");
 return AVERROR(ENOMEM);
 }
-c->pstride = FFALIGN(avctx->width, 16);
-if (!(c->prev = av_malloc(c->pstride * avctx->height))) {
+
+/* Allocate prev buffer - leave border around 

Re: [FFmpeg-devel] [PATCH]lavu/parseutils: Allow to parse >100 hours

2019-02-09 Thread Carl Eugen Hoyos
2019-02-09 13:27 GMT+01:00, Michael Niedermayer :
> On Sat, Feb 09, 2019 at 01:24:35AM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes ticket #7721 for the reporter.
>>
>> Please comment, Carl Eugen
>
>>  parseutils.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 9771b8afcf3e4d4a5fe55cd63f60a03cc25a117a
>> 0001-lavu-parseutils-Allow-to-parse-100-hours.patch
>> From ba6abc57d563bcc22607ff5d9f77fdce76000bf6 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Sat, 9 Feb 2019 01:20:43 +0100
>> Subject: [PATCH] lavu/parseutils: Allow to parse >= 100 hours.
>>
>> Reported and tested by gamnark.
>> Fixes ticket #7721.
>> ---
>>  libavutil/parseutils.c |2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavutil/parseutils.c b/libavutil/parseutils.c
>> index 59bec6c..167e822 100644
>> --- a/libavutil/parseutils.c
>> +++ b/libavutil/parseutils.c
>> @@ -504,7 +504,7 @@ char *av_small_strptime(const char *p, const char
>> *fmt, struct tm *dt)
>>  switch(c) {
>>  case 'H':
>>  case 'J':
>> -val = date_get_num(, 0, c == 'H' ? 23 : INT_MAX, 2);
>> +val = date_get_num(, 0, c == 'H' ? 23 : INT_MAX, c == 'H' ?
>> 2 : 4);
>
> LGTM until someone needs more than a bit over a year duration

:-)
Patch applied.

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


[FFmpeg-devel] [PATCH]lavf/img2dec: Split img2 and img2pipe options

2019-02-09 Thread Carl Eugen Hoyos
Hi!

Currently if the "loop" option gets specified for -f image2pipe, there is
no indication for the user that the option will not work, patch attached.

Please comment, Carl Eugen
From 21b11da9af5166e4bda7398a471a1e1a49352ac3 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 9 Feb 2019 13:49:51 +0100
Subject: [PATCH] lavf/img2dec: Split img2 and img2pipe options.

---
 libavformat/img2dec.c |   33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index e82b1df..c1568c1 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -564,29 +564,29 @@ static int img_read_seek(AVFormatContext *s, int stream_index, int64_t timestamp
 
 #define OFFSET(x) offsetof(VideoDemuxData, x)
 #define DEC AV_OPT_FLAG_DECODING_PARAM
+#define COMMON_OPTIONS \
+{ "framerate","set the video framerate", OFFSET(framerate),AV_OPT_TYPE_VIDEO_RATE, {.str = "25"}, 0, INT_MAX, DEC }, \
+{ "pixel_format", "set video pixel format",  OFFSET(pixel_format), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0,   DEC }, \
+{ "video_size",   "set video size",  OFFSET(width),AV_OPT_TYPE_IMAGE_SIZE, {.str = NULL}, 0, 0,   DEC }, \
+{ "ts_from_file", "set frame timestamp from file's one", OFFSET(ts_from_file), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 2, DEC, "ts_type" }, \
+{ "none", "none",   0, AV_OPT_TYPE_CONST,{.i64 = 0   }, 0, 2,   DEC, "ts_type" }, \
+{ "sec",  "second precision",   0, AV_OPT_TYPE_CONST,{.i64 = 1   }, 0, 2,   DEC, "ts_type" }, \
+{ "ns",   "nano second precision",  0, AV_OPT_TYPE_CONST,{.i64 = 2   }, 0, 2,   DEC, "ts_type" },
+
+#if CONFIG_IMAGE2_DEMUXER
 const AVOption ff_img_options[] = {
-{ "framerate","set the video framerate", OFFSET(framerate),AV_OPT_TYPE_VIDEO_RATE, {.str = "25"}, 0, INT_MAX,   DEC },
+COMMON_OPTIONS
 { "loop", "force loop over input file sequence", OFFSET(loop), AV_OPT_TYPE_BOOL,   {.i64 = 0   }, 0, 1,   DEC },
-
 { "pattern_type", "set pattern type",OFFSET(pattern_type), AV_OPT_TYPE_INT,{.i64=PT_DEFAULT}, 0,   INT_MAX, DEC, "pattern_type"},
 { "glob_sequence","select glob/sequence pattern type",   0, AV_OPT_TYPE_CONST,  {.i64=PT_GLOB_SEQUENCE}, INT_MIN, INT_MAX, DEC, "pattern_type" },
 { "glob", "select glob pattern type",0, AV_OPT_TYPE_CONST,  {.i64=PT_GLOB }, INT_MIN, INT_MAX, DEC, "pattern_type" },
 { "sequence", "select sequence pattern type",0, AV_OPT_TYPE_CONST,  {.i64=PT_SEQUENCE }, INT_MIN, INT_MAX, DEC, "pattern_type" },
 { "none", "disable pattern matching",0, AV_OPT_TYPE_CONST,  {.i64=PT_NONE }, INT_MIN, INT_MAX, DEC, "pattern_type" },
-
-{ "pixel_format", "set video pixel format",  OFFSET(pixel_format), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0,   DEC },
 { "start_number", "set first number in the sequence",OFFSET(start_number), AV_OPT_TYPE_INT,{.i64 = 0   }, INT_MIN, INT_MAX, DEC },
 { "start_number_range", "set range for looking at the first sequence number", OFFSET(start_number_range), AV_OPT_TYPE_INT, {.i64 = 5}, 1, INT_MAX, DEC },
-{ "video_size",   "set video size",  OFFSET(width),AV_OPT_TYPE_IMAGE_SIZE, {.str = NULL}, 0, 0,   DEC },
-{ "frame_size",   "force frame size in bytes",   OFFSET(frame_size),   AV_OPT_TYPE_INT,{.i64 = 0   }, 0, INT_MAX, DEC },
-{ "ts_from_file", "set frame timestamp from file's one", OFFSET(ts_from_file), AV_OPT_TYPE_INT,{.i64 = 0   }, 0, 2,   DEC, "ts_type" },
-{ "none", "none",   0, AV_OPT_TYPE_CONST,{.i64 = 0   }, 0, 2,   DEC, "ts_type" },
-{ "sec",  "second precision",   0, AV_OPT_TYPE_CONST,{.i64 = 1   }, 0, 2,   DEC, "ts_type" },
-{ "ns",   "nano second precision",  0, AV_OPT_TYPE_CONST,{.i64 = 2   }, 0, 2,   DEC, "ts_type" },
 { NULL },
 };
 
-#if CONFIG_IMAGE2_DEMUXER
 static const AVClass img2_class = {
 .class_name = "image2 demuxer",
 .item_name  = av_default_item_name,
@@ -606,11 +606,18 @@ AVInputFormat ff_image2_demuxer = {
 .priv_class = _class,
 };
 #endif
+
+const AVOption ff_img2pipe_options[] = {
+COMMON_OPTIONS
+{ "frame_size", "force frame size in bytes", OFFSET(frame_size), AV_OPT_TYPE_INT, {.i64 = 0 }, 0, INT_MAX, DEC },
+{ NULL },
+};
+
 #if CONFIG_IMAGE2PIPE_DEMUXER
 static const AVClass img2pipe_class = {
 .class_name = "image2pipe demuxer",
 .item_name  = av_default_item_name,
-.option = ff_img_options,
+.option = ff_img2pipe_options,
 .version= LIBAVUTIL_VERSION_INT,
 };
 AVInputFormat ff_image2pipe_demuxer = {
@@ -1023,7 +1030,7 @@ static int gif_probe(AVProbeData *p)
 static const AVClass imgname ## _class = {\
 .class_name = 

Re: [FFmpeg-devel] [PATCH]lavu/parseutils: Allow to parse >100 hours

2019-02-09 Thread Michael Niedermayer
On Sat, Feb 09, 2019 at 01:24:35AM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes ticket #7721 for the reporter.
> 
> Please comment, Carl Eugen

>  parseutils.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 9771b8afcf3e4d4a5fe55cd63f60a03cc25a117a  
> 0001-lavu-parseutils-Allow-to-parse-100-hours.patch
> From ba6abc57d563bcc22607ff5d9f77fdce76000bf6 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sat, 9 Feb 2019 01:20:43 +0100
> Subject: [PATCH] lavu/parseutils: Allow to parse >= 100 hours.
> 
> Reported and tested by gamnark.
> Fixes ticket #7721.
> ---
>  libavutil/parseutils.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavutil/parseutils.c b/libavutil/parseutils.c
> index 59bec6c..167e822 100644
> --- a/libavutil/parseutils.c
> +++ b/libavutil/parseutils.c
> @@ -504,7 +504,7 @@ char *av_small_strptime(const char *p, const char *fmt, 
> struct tm *dt)
>  switch(c) {
>  case 'H':
>  case 'J':
> -val = date_get_num(, 0, c == 'H' ? 23 : INT_MAX, 2);
> +val = date_get_num(, 0, c == 'H' ? 23 : INT_MAX, c == 'H' ? 2 
> : 4);

LGTM until someone needs more than a bit over a year duration



[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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


Re: [FFmpeg-devel] lavc/libvpxenc: Deprecate lossless option

2019-02-09 Thread Carl Eugen Hoyos
2019-02-09 7:49 GMT+01:00, Gyan :
>
>
> On 09-02-2019 02:26 AM, Carl Eugen Hoyos wrote:
>> 2019-02-08 6:08 GMT+01:00, Gyan :
>>>
>>> On 08-02-2019 03:31 AM, Carl Eugen Hoyos wrote:
 .
 No strong opinion here, I hadn't realized that -crf 0 only works with
 newer versions.

 Can you explain why crf alone has no effect and needs -b:v 0?
 Isn't this a bug both with libvpx and libaom?

>>> With crf present but VBV params absent, VPX operates using a constrained
>>> Q RC mode , where the target bitrate acts as a ceiling. Since acvodec
>>> has a non-zero default -b of 200 kbps, this produces undesirable
>>> effects. If set to 0, VPX switches to constant quality.
>> Yes.
>> This looks like a bug to me.
>
> If there's a bug, it's in libav, in that, we can't signal when a value
> is assigned by the user or via user-initiated logic, versus being
> assigned as a default fallback. So it's a design conflict, and the
> workaround has been long documented.
>
> Maybe just before the next major bump, a new field should be
> introduced in AVOptions which registers if the field was
> populated at the behest of the user.

We could set the default for "b" to "0" without a major bump.

Is it expected that constant crf with vp8 leads to broken output?

>>> I do see this block though,
>>>
>>>   if (avctx->codec_id == AV_CODEC_ID_VP9 && ctx->lossless == 1) {
>>>   enccfg.rc_min_quantizer =
>>>   enccfg.rc_max_quantizer = 0;
>>>   } else {
>>>   if (avctx->qmin >= 0)
>>>   enccfg.rc_min_quantizer = avctx->qmin;
>>>   if (avctx->qmax >= 0)
>>>   enccfg.rc_max_quantizer = avctx->qmax;
>>>   }
>>>
>>>
>>> Looks like the quantizer range is disabled only by using the deprecated
>>> option, or has this changed?
>> Is your question "Isn't 'lossless 1' necessary for lossless encoding"?
>
> Yes. A quick glance at vpx HEAD indicates it is, although
> -qmin & -qmax 0 should also work.

Given that it works for most frames, I wonder what the technical
background is...

>>> Also, with libvpx v1.7.0-1758, I get different results for -crf 0 -b:v
>>> 0  vs only -lossless 1, with the latter producing a slightly larger
>>> file, and its result showing a slightly larger SSIM score. Although
>>> neither produces a SSIM of 1, like libx264. Not truly lossless?
>> Please provide your input sample.
>
> I can reproduce the difference in result with
> fate-suite/h264-conformance/src19td.IBP.264

Yes, this returns a few non-lossless frames.

Is the encoder meant to be used for actual encoding?
Or does -crf 0 have several meanings depending on specific options
and vp8 is just bad?

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


Re: [FFmpeg-devel] Proposal: Homebrew tap for FFmpeg

2019-02-09 Thread Werner Robitza
On Fri, Feb 8, 2019 at 10:18 PM Jean-Baptiste Kempf  wrote:
>
> On Fri, 8 Feb 2019, at 22:08, Lou Logan wrote:
> > On Fri, Feb 8, 2019, at 11:27 AM, Jean-Baptiste Kempf wrote:
> > >
> > > Also, the AUR recipe does not push for non-free packages.
> >
> > The proposed homebrew formulae will not push for non-free packages. It
> > will simply provide the options for the user to enable two non-free
> > components (openssh and fdk-aac currently) if they desire. They have to
> > be explicitly enabled by the user by manually including the appropriate
> > option, such as "--with-fdk-aac".
>
> Yes, and this is exactly what I am objecting against.
> It silently enables non-free, when you ask either. See L 146 and following.

You could print an even more obvious warning message when these
options are used.
If that is a big concern, it can be easily dealt with.

> And yes, I strongly advise against the project advertising those non-free 
> options.

Then the only consequence can be to remove these options or support
for these libraries altogether, because you'll find plenty of guides
and recommendations on how to build ffmpeg with non-free libs on the
Internet – even supplied by members who are very active in the FFmpeg
community. It is certainly your prerogative to be against explicit
advertising, but where do you draw the line? Has there been any
precedent with this, or is this going to be decided on a case-by-case
basis?

The only consequence would be a formula that is not owned and
controlled by FFmpeg, and people will continue to build non-free
binaries.

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