Re: [FFmpeg-devel] Removing DCE

[Matt Oliver]

On 23 December 2016 at 19:40, Nicolas George  wrote:

> Le primidi 1er nivôse, an CCXXV, Michael Niedermayer a écrit :
> > how hard would it be to write a preprocessor like tool to convert
> > all if (ARCH/HAVE/CONFIG_SYMBOL ...)
> > to
> > #if
> > ?
>
> For a very general case, quite hard, but we do not need it.
>
> If we stick to a few reasonable cosmetic conventions on the affected
> blocks (at a guess: correct indentation of the braces, balanced
> parentheses in the condition; we want to do that anyway), then it should
> be quite easy to write a preprocessor like that.
>
> I do not know how to integrate that in the build system, though. That is
> the annoying part IMHO.
>

Looking at the code there are a couple (only small number admittedly) of
complex sections of code using DCE that would make a preprocessor tool
potentially rather complex and difficult to handle. I wouldn't like to
attempt to do it thats for sure.

I wouldn't mind a patch which did that, even if it meant adding a line for
> every file which did that.
> I'm not a preprocessor wizard but couldn't you hide all that in a macro,
> like:
>
> INIT_ARCH_CODEPATH(ARCH_X86, ff_aac_dsp_init_x86(s)))
>
> if you define the macro in config.h somehow such that the preprocessor
> doesn't evaluate whether ARCH_X86 is defined?


I think it would be possible to write a macro similar to that that can be
used to replace all the existing occurrences of things like:
if (ARCH_X86)
ff_aac_dsp_init_x86(s);

with
SELECT_DCE(ARCH_X86, ff_aac_dsp_init_x86(s));

although all those occurrences can just be easily replaced with:
#if ARCH_X86
ff_aac_dsp_init_x86(s);
#endif

Which one is chosen is simply a matter of preference, either one works fine
for me.

Its mainly for the more complicated sections of code where DCE is actually
used to test whether the code at least compiles correctly that a simple
macro wont suffice if you intend to wrap the whole block. However it is
only the function calls that cause errors so the rest of the code can be
left intact and only the function calls themselves get wrapped in some sort
of macro like above.

So any existing function call that causes linker errors can be wrapped in a
macro like SELECT_DCE (or whatever name you wish to give it) which would
fix all the current issues.

I have the time coming up to replace all the problem functions calls with
something like the above, so let me know whether that would be an
acceptable approach.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] hevc: Mark as having threadsafe init

[wm4]

On Tue, 10 Jan 2017 18:24:27 +
Derek Buitenhuis  wrote:

> Signed-off-by: Derek Buitenhuis 
> ---
> It looks like it already is threadsafe, amazingly? I don't
> see any table inits, somehow.
> ---
>  libavcodec/hevc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
> index 7c563a3..607a8da 100644
> --- a/libavcodec/hevc.c
> +++ b/libavcodec/hevc.c
> @@ -3416,5 +3416,6 @@ AVCodec ff_hevc_decoder = {
>  .init_thread_copy  = hevc_init_thread_copy,
>  .capabilities  = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
>   AV_CODEC_CAP_SLICE_THREADS | 
> AV_CODEC_CAP_FRAME_THREADS,
> +.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
>  .profiles  = NULL_IF_CONFIG_SMALL(ff_hevc_profiles),
>  };

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

Re: [FFmpeg-devel] [PATCH 01/13] aarch64: vp9: use alternative returns in the core loop filter function

[Michael Niedermayer]

On Tue, Jan 10, 2017 at 12:15:07AM +0200, Martin Storsjö wrote:

fate on qemu-arm (32bit) passes fine with the whole patchset

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

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


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

Re: [FFmpeg-devel] [PATCH 3/3] avfilter/vf_libopencv: fix resource leak in read_shape_frame_filter

[Steven Liu]

2017-01-10 19:45 GMT+08:00 Steven Liu :

> CID: 1324298
> add a label when error goto the label to release resource
>
> Signed-off-by: Steven Liu 
> ---
>  libavfilter/vf_libopencv.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/libavfilter/vf_libopencv.c b/libavfilter/vf_libopencv.c
> index f8ae9d5..8128030 100644
> --- a/libavfilter/vf_libopencv.c
> +++ b/libavfilter/vf_libopencv.c
> @@ -157,7 +157,8 @@ static int read_shape_from_file(int *cols, int *rows,
> int **values, const char *
>  if (buf[i] == '\n') {
>  if (*rows == INT_MAX) {
>  av_log(log_ctx, AV_LOG_ERROR, "Overflow on the number of
> rows in the file\n");
> -return AVERROR_INVALIDDATA;
> +ret = AVERROR_INVALIDDATA;
> +goto end;
>  }
>  ++(*rows);
>  *cols = FFMAX(*cols, w);
> @@ -171,10 +172,13 @@ static int read_shape_from_file(int *cols, int
> *rows, int **values, const char *
>  if (*rows > (SIZE_MAX / sizeof(int) / *cols)) {
>  av_log(log_ctx, AV_LOG_ERROR, "File with size %dx%d is too big\n",
> *rows, *cols);
> -return AVERROR_INVALIDDATA;
> +ret = AVERROR_INVALIDDATA;
> +goto end;
> +}
> +if (!(*values = av_mallocz_array(sizeof(int) * *rows, *cols))) {
> +ret = AVERROR(ENOMEM);
> +goto end;
>  }
> -if (!(*values = av_mallocz_array(sizeof(int) * *rows, *cols)))
> -return AVERROR(ENOMEM);
>
>  /* fill *values */
>  p= buf;
> @@ -188,6 +192,8 @@ static int read_shape_from_file(int *cols, int *rows,
> int **values, const char *
>  (*values)[*cols*i + j] = !!av_isgraph(*(p++));
>  }
>  }
> +
> +end:
>  av_file_unmap(buf, size);
>
>  #ifdef DEBUG
> --
> 2.10.1.382.ga23ca1b.dirty
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

applied!



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

[FFmpeg-devel] Favor como desvincularme para que no me lleguen los correos

[Nicolas Carvajal]

??  ??  ??
??  ??  ??
??  ??  ??
??  ??  ??
??  ??  ??

Nicolas 
Carvajal.[http://www.palermoviejo.com/palermoviejo/gifs/bonus7/148.gif=3]

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

Re: [FFmpeg-devel] [PATCH]lavc/psd: Interpret duotone as grayscale

[Martin Vignali]

>
> Feel free to look at my 32bit patch attached to ticket #6045, perhaps
> you know how to fix it.
>
>
I think 32bit in psd are for float data,
maybe something like the float to 16i used inside exr.

Doesn't tested, and i will not have time to take a better look soon.

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

Re: [FFmpeg-devel] [PATCH]lavc/psd: Interpret duotone as grayscale

[Carl Eugen Hoyos]

2017-01-10 23:57 GMT+01:00 Martin Vignali :
> I don't have a strong opinion about duo tone (i never use it)
>
>> Seems not the best way to manage this kind of file
>>
>> Not sure if I understand:
>> What is the alternative? Do you know how to interpret
>> the duotone specification?
>>
>
> I think it's better to have the real color :-)
> But i don't know how to interpret the DuoTone information
>
>>
>> > Doesn't know the general rules of this project, about that :
>> > Is it better to not support a file
>>
>> > or wrongly interpret it ?
>>
>> What is wrong about following the specification?
>
> Sorry didn't see this part of the spec :
> "Other applications that read Photoshop files can treat a duotone image as
> a gray image, and just preserve the contents of the duotone information
> when reading and writing the file."
>
> So probably ok in that case, but maybe with a warning, so the user can
> know, that the file is not correctly decode.

Pushed with a warning.

Feel free to look at my 32bit patch attached to ticket #6045, perhaps
you know how to fix it.

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

Re: [FFmpeg-devel] [PATCH]lavc/psd: Support 1bpp images

[Martin Vignali]

>
> Please move the uncompressed calculation
> below the color_mode switch and commit.
>
> In attach new patch.

Martin
From db1ca3645624fe8fac29f09cef3ef89dd013fef6 Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Wed, 11 Jan 2017 00:18:29 +0100
Subject: [PATCH] libavcodec/psd : add support for psd bitmap mode

Ticket 6044

Based on patch by Carl Eugen Hoyos
---
 libavcodec/psd.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/libavcodec/psd.c b/libavcodec/psd.c
index 7587ed9..c79f72a 100644
--- a/libavcodec/psd.c
+++ b/libavcodec/psd.c
@@ -316,9 +316,12 @@ static int decode_frame(AVCodecContext *avctx, void *data,
 
 s->pixel_size = s->channel_depth >> 3;/* in byte */
 s->line_size = s->width * s->pixel_size;
-s->uncompressed_size = s->line_size * s->height * s->channel_count;
 
 switch (s->color_mode) {
+case PSD_BITMAP:
+s->line_size = s->width + 7 >> 3;
+avctx->pix_fmt = AV_PIX_FMT_MONOWHITE;
+break;
 case PSD_INDEXED:
 if (s->channel_depth != 8 || s->channel_count != 1) {
 av_log(s->avctx, AV_LOG_ERROR,
@@ -381,6 +384,8 @@ static int decode_frame(AVCodecContext *avctx, void *data,
 return AVERROR_PATCHWELCOME;
 }
 
+s->uncompressed_size = s->line_size * s->height * s->channel_count;
+
 if ((ret = ff_get_buffer(avctx, picture, 0)) < 0)
 return ret;
 
@@ -428,9 +433,9 @@ static int decode_frame(AVCodecContext *avctx, void *data,
 plane_number = eq_channel[c];
 ptr = picture->data[plane_number];/* get the right plane */
 for (y = 0; y < s->height; y++) {
-memcpy(ptr, ptr_data, s->width * s->pixel_size);
+memcpy(ptr, ptr_data, s->line_size);
 ptr += picture->linesize[plane_number];
-ptr_data += s->width * s->pixel_size;
+ptr_data += s->line_size;
 }
 }
 }
-- 
1.9.3 (Apple Git-50)

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

Re: [FFmpeg-devel] [PATCH]lavc/psd: Support 1bpp images

[Carl Eugen Hoyos]

2017-01-11 0:07 GMT+01:00 Martin Vignali :
> 2017-01-10 23:56 GMT+01:00 Carl Eugen Hoyos :
>
>> 2017-01-10 23:53 GMT+01:00 Martin Vignali :
>> >> > But maybe you can put the Store data code inside the planar part
>> >> > (it's very similar)
>> >>
>> >> That means I have to remove the pixel_size context variable:
>> >> Do you want me to do that?
>> >
>> > No i don't think you need to remove it.
>>
>> Then I don't know how to do it, please send a patch.
>> (Please mention the ticket.)
>
> I though about something like the patch in attach.
>
> I just quickly test this patch, pass fate test, and decode a test sample.

Please move the uncompressed calculation
below the color_mode switch and commit.

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

Re: [FFmpeg-devel] [PATCH]lavc/psd: Support 1bpp images

[Carl Eugen Hoyos]

2017-01-10 23:53 GMT+01:00 Martin Vignali :
>> > But maybe you can put the Store data code inside the planar part
>> > (it's very similar)
>>
>> That means I have to remove the pixel_size context variable:
>> Do you want me to do that?
>
> No i don't think you need to remove it.

Then I don't know how to do it, please send a patch.
(Please mention the ticket.)

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

Re: [FFmpeg-devel] [PATCH]lavc/psd: Support 1bpp images

[Carl Eugen Hoyos]

2017-01-10 23:42 GMT+01:00 Martin Vignali :
> 2017-01-10 20:00 GMT+01:00 Carl Eugen Hoyos :
>
>> 2017-01-10 19:45 GMT+01:00 Gonzalo Garramuño :
>> >
>> >
>> > El 10/01/2017 a las 10:21, Carl Eugen Hoyos escribió:
>> >>
>> >>   }
>> >> +} else if (avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) {
>> >> +ptr = picture->data[0];
>> >> +for (y = 0; y < s->height; y++) {
>> >> +memcpy(ptr, ptr_data, s->width + 7 >> 3);
>> >> +ptr_data += s->width + 7 >> 3;
>> >> +ptr += picture->linesize[0];
>> >> +}
>> >
>> > Just a nitpick.  I would put s->width + 7 >> 3 in a variable outside the
>> > loop and use it in memcpy and in the ptr_data.
>>
>> Fixed locally.
>>
> Tested on some sample, seems to work.
>
> But maybe you can put the Store data code inside the planar part (it's very
> similar)

That means I have to remove the pixel_size context variable:
Do you want me to do that?

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

Re: [FFmpeg-devel] [PATCH]lavc/psd: Interpret duotone as grayscale

[Carl Eugen Hoyos]

2017-01-10 23:23 GMT+01:00 Martin Vignali :
>> > Seems strange, that duotone is interpreted like grayscale
>>
>> It's what gimp, ImageMagick and FreeImage do and what Adobe recommends.
>
> Seems to be also the case of Apple Preview.
>
> Seems not the best way to manage this kind of file

Not sure if I understand:
What is the alternative? Do you know how to interpret
the duotone specification?

> Doesn't know the general rules of this project, about that :
> Is it better to not support a file

> or wrongly interpret it ?

What is wrong about following the specification?

Did you see the BITMAP patch?

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

Re: [FFmpeg-devel] [PATCHv2 3/3] avfilter/formats: do not allow unknown layouts in ff_parse_channel_layout if nret is not set

[Marton Balint]

On Mon, 2 Jan 2017, Marton Balint wrote:


Current code returned the number of channels as channel layout in that case,
and if nret is not set then unknown layouts are typically not supported.

Also use the common parsing code. Use a temporary workaround to parse an
unknown channel layout such as '13c', after a 1 year grace period only '13C'
will work.

Signed-off-by: Marton Balint 
---
libavfilter/formats.c | 26 +++---
libavfilter/tests/formats.c   |  3 +++
tests/ref/fate/filter-formats |  3 +++
3 files changed, 21 insertions(+), 11 deletions(-)

diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index 840780d..d4de862 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -664,22 +664,26 @@ int ff_parse_channel_layout(int64_t *ret, int *nret, 
const char *arg,
{
char *tail;
int64_t chlayout;
-
-chlayout = av_get_channel_layout(arg);
-if (chlayout == 0) {
-chlayout = strtol(arg, , 10);
-if (!(*tail == '\0' || *tail == 'c' && *(tail + 1) == '\0') || chlayout 
<= 0 || chlayout > 63) {
+int nb_channels;
+
+if (av_get_extended_channel_layout(arg, , _channels) < 0) {
+/* [TEMPORARY 2016-12 -> 2017-12]*/
+nb_channels = strtol(arg, , 10);
+if (!errno && *tail == 'c' && *(tail + 1) == '\0' && nb_channels > 0 && 
nb_channels < 64) {
+chlayout = 0;
+av_log(log_ctx, AV_LOG_WARNING, "Deprecated channel count specification 
'%s'. This will stop working in releases made in 2018 and after.\n", arg);
+} else {
av_log(log_ctx, AV_LOG_ERROR, "Invalid channel layout '%s'\n", arg);
return AVERROR(EINVAL);
}
-if (nret) {
-*nret = chlayout;
-*ret = 0;
-return 0;
-}
+}
+if (!chlayout && !nret) {
+av_log(log_ctx, AV_LOG_ERROR, "Unknown channel layout '%s' is not 
supported.\n", arg);
+return AVERROR(EINVAL);
}
*ret = chlayout;
if (nret)
-*nret = av_get_channel_layout_nb_channels(chlayout);
+*nret = nb_channels;
+
return 0;
}
diff --git a/libavfilter/tests/formats.c b/libavfilter/tests/formats.c
index 0e8ba4a..5450742 100644
--- a/libavfilter/tests/formats.c
+++ b/libavfilter/tests/formats.c
@@ -39,6 +39,9 @@ int main(void)
"-1c",
"60c",
"65c",
+"2C",
+"60C",
+"65C",
"5.1",
"stereo",
"1+1+1+1",
diff --git a/tests/ref/fate/filter-formats b/tests/ref/fate/filter-formats
index 4c303d8..ea85eed 100644
--- a/tests/ref/fate/filter-formats
+++ b/tests/ref/fate/filter-formats
@@ -77,6 +77,9 @@ quad(side)
-1 = ff_parse_channel_layout(, -1, -1c);
0 = ff_parse_channel_layout(, 60, 60c);
-1 = ff_parse_channel_layout(, -1, 65c);
+0 = ff_parse_channel_layout(,  2, 2C);
+0 = ff_parse_channel_layout(, 60, 60C);
+-1 = ff_parse_channel_layout(, -1, 65C);
0 = ff_parse_channel_layout(003F,  6, 5.1);
0 = ff_parse_channel_layout(0003,  2, stereo);
0 = ff_parse_channel_layout(0001,  1, 1+1+1+1);


Ping...

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

Re: [FFmpeg-devel] [PATCH]lavc/psd: Support 1bpp images

[Martin Vignali]

2017-01-10 20:00 GMT+01:00 Carl Eugen Hoyos :

> 2017-01-10 19:45 GMT+01:00 Gonzalo Garramuño :
> >
> >
> > El 10/01/2017 a las 10:21, Carl Eugen Hoyos escribió:
> >>
> >>   }
> >> +} else if (avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) {
> >> +ptr = picture->data[0];
> >> +for (y = 0; y < s->height; y++) {
> >> +memcpy(ptr, ptr_data, s->width + 7 >> 3);
> >> +ptr_data += s->width + 7 >> 3;
> >> +ptr += picture->linesize[0];
> >> +}
> >
> > Just a nitpick.  I would put s->width + 7 >> 3 in a variable outside the
> > loop and use it in memcpy and in the ptr_data.
>
> Fixed locally.
>
>
Tested on some sample, seems to work.

But maybe you can put the Store data code inside the planar part (it's very
similar)

Something like that
---
 s->uncompressed_size = s->line_size * s->height * s->channel_count;

 switch (s->color_mode) {
+case PSD_BITMAP:

Overwrite here the linesize :

s->line_size = s->width + 7 >> 3;

+avctx->pix_fmt = AV_PIX_FMT_MONOWHITE;
+break;
 case PSD_INDEXED:
 if (s->channel_depth != 8 || s->channel_count != 1) {
 av_log(s->avctx, AV_LOG_ERROR,
@@ -420,6 +423,13 @@ static int decode_frame(AVCodecContext *avctx, void
*data,
 }
 }
 }




This special case can be delete :

+} else if (avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) {
+ptr = picture->data[0];
+for (y = 0; y < s->height; y++) {
+memcpy(ptr, ptr_data, s->width + 7 >> 3);
+ptr_data += s->width + 7 >> 3;
+ptr += picture->linesize[0];
+}

and the planar part, can use s->line_size instead of s->width *
s->pixel_size;

so will work for both i think

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

Re: [FFmpeg-devel] [PATCH]lavc/psd: Interpret duotone as grayscale

[Martin Vignali]

> > Seems strange, that duotone is interpreted like grayscale
>
> It's what gimp, ImageMagick and FreeImage do and what Adobe recommends.
>
>
> Seems to be also the case of Apple Preview.

Seems not the best way to manage this kind of file

Doesn't know the general rules of this project, about that :
Is it better to not support a file, or wrongly interpret it ?

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options

[Moritz Barsnick]

On Tue, Jan 10, 2017 at 16:02:34 +0100, Bodecs Bela wrote:
> > Missing documentation in doc/muxers.texi.
> my patch included the muxers.texi also.

D'uh, sorry! ;)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options

[Bodecs Bela]

2017.01.10. 16:40 keltezéssel, Steven Liu írta:

2017-01-10 23:22 GMT+08:00 Bodecs Bela :



2017.01.10. 12:10 keltezéssel, Steven Liu írta:


2017-01-10 17:42 GMT+08:00 Bodecs Bela :



2017.01.10. 6:53 keltezéssel, Steven Liu írta:

2017-01-08 8:22 GMT+08:00 Steven Liu :


2017-01-08 1:37 GMT+08:00 Bodecs Bela :


2017.01.07. 0:32 keltezéssel, Steven Liu írta:

2017-01-07 0:47 GMT+08:00 Bodecs Bela :


2017.01.06. 17:33 keltezéssel, Steven Liu írta:


2017-01-07 0:22 GMT+08:00 Bodecs Bela :

2017.01.06. 16:50 keltezéssel, Steven Liu írta:

2017-01-06 22:07 GMT+08:00 Bodecs Bela :

Dear All,


in avformat/hlsenc the start_number option starts the playlist

sequence

number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless
hls_flags
single_file is set, it also specifies starting sequence numbers
of
segment and subtitle filenames. Sometimes it is usefull to have
unique
starting numbers at each run, but currently it is only
achiveable
by
setting this parameter manually.
This patch enables to set start_number parameter automatically
for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01
00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.


thank you,

Bela Bodecs


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


Two question:

1. char b[21];   Why this is 21 ?

you are right, 15 is enough.

2. +{"start_number",  "set first number in the sequence",


   OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0},
  -2,


INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation,
for
example
-2 mean -1 mean  0 mean, and default value.

yes, I have altered now but I have written verbosly into the doc

(muxers.texi), here:


+If set to -1, then the start number will be the seconds since
epoch
(1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current
date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0.

___

ffmpeg-devel mailing list

ffmpeg-devel@ffmpeg.org

http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I have enclosed a fixed version. A have changed some code, where
greater

than 32 bit long sequence numbers were not handled correctly.


(av_get_frame_filename2)

thank you.
Bela Bodecs


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


+{"start_number",  "set first number in the sequence, 0 is
default,

-1:


second since epoch, -2: current datetime as MMDDhhmmss, actual
value
otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0},
 -2,
INT64_MAX, E},

I have check this option, i think add flag to control the
start_number
maybe better,
for example:
hls_flags
hls_playlist_type

maybe add a start_number_flags is better, What about you think?

Using hls_flags is not enough to specify different values for them.

NO, i am not mean use hls_flags, i mean you can creat a new flags,

start_number_flags

 generic
 epoch
 datetime

Ok, I see it. May I implement it?


yes, of course ;-)


I thought that there should be 3 options beside this start_number

option.

hls_start_number_playlist, hls_start_number_segment and


hls_start_number_vtt
Using start_number and any of the new 3 ones would be mutualy
exlusive.

This way anybody could use the old option (start_number) and it
won't
break the current behaviour.
But those who want to have finer control, they may use the new
options.

of course -start_number x  has the same effect as using
-hls_start_number_playlist x -hls_start_number_segment x
-hls_start_number_vtt x



___

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

___

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


Hi Bodecs,

 If you don't have enough time, i think i can do it together
with
you;)

here it is.

___


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



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix the bug when the largest segment duration pointer right value is 0

[Steven Liu]

2017-01-10 23:28 GMT+08:00 Steven Liu :

> when the segments largest duration value is look like 4.00, the
> EXT-X-TARGETDURATION value should equ 4.
> it's wrong when hlsenc use ceil, so fix it.
>
> Signed-off-by: Steven Liu 
> ---
>  libavformat/hlsenc.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 3d2d41a..a2c606c 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -141,6 +141,11 @@ typedef struct HLSContext {
>  char current_segment_final_filename_fmt[1024]; // when renaming
> segments
>  } HLSContext;
>
> +static int get_int_from_double(double val)
> +{
> +return (int)((val - (int)val) >= 0.001) ? (int)(val + 1) : (int)val;
> +}
> +
>  static int mkdir_p(const char *path) {
>  int ret = 0;
>  char *temp = av_strdup(path);
> @@ -668,8 +673,8 @@ static int hls_window(AVFormatContext *s, int last)
>  goto fail;
>
>  for (en = hls->segments; en; en = en->next) {
> -if (target_duration < en->duration)
> -target_duration = ceil(en->duration);
> +if (target_duration <= en->duration)
> +target_duration = get_int_from_double(en->duration);
>  }
>
>  hls->discontinuity_set = 0;
> --
> 2.10.1 (Apple Git-78)
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

applied!



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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix hls start and tail segment duration problem

[Steven Liu]

2017-01-10 8:05 GMT+08:00 Steven Liu :

>
>
> 2017-01-10 1:06 GMT+08:00 Steven Liu :
>
>> fix ticket: #6067
>>
>> Signed-off-by: Steven Liu 
>> ---
>>  libavformat/hlsenc.c | 16 
>>  1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index eeb450a..0fcb699 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -103,6 +103,7 @@ typedef struct HLSContext {
>>  int64_t recording_time;
>>  int has_video;
>>  int has_subtitle;
>> +double dpp;   // duration per packet
>>  int64_t start_pts;
>>  int64_t end_pts;
>>  double duration;  // last segment duration computed so far, in
>> seconds
>> @@ -1216,10 +1217,16 @@ static int hls_write_packet(AVFormatContext *s,
>> AVPacket *pkt)
>>  if (pkt->pts == AV_NOPTS_VALUE)
>>  is_ref_pkt = can_split = 0;
>>
>> -if (is_ref_pkt)
>> -hls->duration = (double)(pkt->pts - hls->end_pts)
>> -   * st->time_base.num /
>> st->time_base.den;
>> +if (is_ref_pkt) {
>> +if (!hls->start_pos) {
>> +hls->duration = (double)(pkt->pts - hls->end_pts)
>> +   * st->time_base.num /
>> st->time_base.den;
>> +hls->dpp = (double)(pkt->duration) * st->time_base.num /
>> st->time_base.den;
>> +} else {
>> +hls->duration += (double)(pkt->duration) * st->time_base.num
>> / st->time_base.den;
>> +}
>>
>> +}
>>  if (can_split && av_compare_ts(pkt->pts - hls->start_pts,
>> st->time_base,
>> end_pts, AV_TIME_BASE_Q) >= 0) {
>>  int64_t new_start_pos;
>> @@ -1289,7 +1296,8 @@ static int hls_write_trailer(struct AVFormatContext
>> *s)
>>  if (oc->pb) {
>>  hls->size = avio_tell(hls->avf->pb) - hls->start_pos;
>>  ff_format_io_close(s, >pb);
>> -hls_append_segment(s, hls, hls->duration, hls->start_pos,
>> hls->size);
>> +/* after av_write_trailer, then duration + 1 duration per packet
>> */
>> +hls_append_segment(s, hls, hls->duration + hls->dpp,
>> hls->start_pos, hls->size);
>>  }
>>
>>  if (vtt_oc) {
>> --
>> 2.10.1.382.ga23ca1b.dirty
>>
>>
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> update patch.
>
>
fix ticket: #6067

Tested-by: Pero
Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index eeb450a..3d2d41a 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -103,6 +103,8 @@ typedef struct HLSContext {
 int64_t recording_time;
 int has_video;
 int has_subtitle;
+int new_start;
+double dpp;   // duration per packet
 int64_t start_pts;
 int64_t end_pts;
 double duration;  // last segment duration computed so far, in
seconds
@@ -418,6 +420,7 @@ static int hls_mux_init(AVFormatContext *s)
 st->time_base = s->streams[i]->time_base;
 }
 hls->start_pos = 0;
+hls->new_start = 1;

 return 0;
 }
@@ -1216,10 +1219,18 @@ static int hls_write_packet(AVFormatContext *s,
AVPacket *pkt)
 if (pkt->pts == AV_NOPTS_VALUE)
 is_ref_pkt = can_split = 0;

-if (is_ref_pkt)
-hls->duration = (double)(pkt->pts - hls->end_pts)
-   * st->time_base.num / st->time_base.den;
+if (is_ref_pkt) {
+if (hls->new_start) {
+hls->new_start = 0;
+hls->duration = (double)(pkt->pts - hls->end_pts)
+   * st->time_base.num /
st->time_base.den;
+hls->dpp = (double)(pkt->duration) * st->time_base.num /
st->time_base.den;
+av_log(s, AV_LOG_ERROR, "hls->dpp = [%lf]\n", hls->dpp);
+} else {
+hls->duration += (double)(pkt->duration) * st->time_base.num /
st->time_base.den;
+}

+}
 if (can_split && av_compare_ts(pkt->pts - hls->start_pts,
st->time_base,
end_pts, AV_TIME_BASE_Q) >= 0) {
 int64_t new_start_pos;
@@ -1289,7 +1300,8 @@ static int hls_write_trailer(struct AVFormatContext
*s)
 if (oc->pb) {
 hls->size = avio_tell(hls->avf->pb) - hls->start_pos;
 ff_format_io_close(s, >pb);
-hls_append_segment(s, hls, hls->duration, hls->start_pos,
hls->size);
+/* after av_write_trailer, then duration + 1 duration per packet */
+hls_append_segment(s, hls, hls->duration + hls->dpp,
hls->start_pos, hls->size);
 }

 if (vtt_oc) {
-- 
2.10.1.382.ga23ca1b.dirty




applied!

Thanks！
___
ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH v2] avcodec/bsf: fix resource leak in av_bsf_list_parse_str

[Steven Liu]

2017-01-11 4:04 GMT+08:00 James Almer :

> On 1/10/2017 4:56 PM, Steven Liu wrote:
> > cid: 1396268
> > when av_strdup(str) error, the lst need release
> >
> > Signed-off-by: Steven Liu 
> > ---
> >  libavcodec/bsf.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
> > index ac2024b..c984526 100644
> > --- a/libavcodec/bsf.c
> > +++ b/libavcodec/bsf.c
> > @@ -514,8 +514,10 @@ int av_bsf_list_parse_str(const char *str,
> AVBSFContext **bsf_lst)
> >  if (!lst)
> >  return AVERROR(ENOMEM);
> >
> > -if (!(dup = buf = av_strdup(str)))
> > -return AVERROR(ENOMEM);
> > +if (!(dup = buf = av_strdup(str))) {
> > +ret = AVERROR(ENOMEM);
> > +goto end;
> > +}
> >
> >  while (1) {
> >  bsf_str = av_strtok(buf, ",", );
> >
>
> LGTM.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

applied!




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

Re: [FFmpeg-devel] [PATCH v2] avcodec/bsf: fix resource leak in av_bsf_list_parse_str

[James Almer]

On 1/10/2017 4:56 PM, Steven Liu wrote:
> cid: 1396268
> when av_strdup(str) error, the lst need release
> 
> Signed-off-by: Steven Liu 
> ---
>  libavcodec/bsf.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
> index ac2024b..c984526 100644
> --- a/libavcodec/bsf.c
> +++ b/libavcodec/bsf.c
> @@ -514,8 +514,10 @@ int av_bsf_list_parse_str(const char *str, AVBSFContext 
> **bsf_lst)
>  if (!lst)
>  return AVERROR(ENOMEM);
>  
> -if (!(dup = buf = av_strdup(str)))
> -return AVERROR(ENOMEM);
> +if (!(dup = buf = av_strdup(str))) {
> +ret = AVERROR(ENOMEM);
> +goto end;
> +}
>  
>  while (1) {
>  bsf_str = av_strtok(buf, ",", );
> 

LGTM.

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

[FFmpeg-devel] [PATCH v2] avcodec/bsf: fix resource leak in av_bsf_list_parse_str

[Steven Liu]

cid: 1396268
when av_strdup(str) error, the lst need release

Signed-off-by: Steven Liu 
---
 libavcodec/bsf.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
index ac2024b..c984526 100644
--- a/libavcodec/bsf.c
+++ b/libavcodec/bsf.c
@@ -514,8 +514,10 @@ int av_bsf_list_parse_str(const char *str, AVBSFContext 
**bsf_lst)
 if (!lst)
 return AVERROR(ENOMEM);
 
-if (!(dup = buf = av_strdup(str)))
-return AVERROR(ENOMEM);
+if (!(dup = buf = av_strdup(str))) {
+ret = AVERROR(ENOMEM);
+goto end;
+}
 
 while (1) {
 bsf_str = av_strtok(buf, ",", );
-- 
2.10.1.382.ga23ca1b.dirty



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

Re: [FFmpeg-devel] [PATCH]lavc/psd: Support 1bpp images

[Carl Eugen Hoyos]

2017-01-10 19:45 GMT+01:00 Gonzalo Garramuño :
>
>
> El 10/01/2017 a las 10:21, Carl Eugen Hoyos escribió:
>>
>>   }
>> +} else if (avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) {
>> +ptr = picture->data[0];
>> +for (y = 0; y < s->height; y++) {
>> +memcpy(ptr, ptr_data, s->width + 7 >> 3);
>> +ptr_data += s->width + 7 >> 3;
>> +ptr += picture->linesize[0];
>> +}
>
> Just a nitpick.  I would put s->width + 7 >> 3 in a variable outside the
> loop and use it in memcpy and in the ptr_data.

Fixed locally.

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

Re: [FFmpeg-devel] [PATCH]lavc/psd: Interpret duotone as grayscale

[Carl Eugen Hoyos]

2017-01-10 18:42 GMT+01:00 Martin Vignali :

> Seems strange, that duotone is interpreted like grayscale

It's what gimp, ImageMagick and FreeImage do and what Adobe recommends.

Did you see the BITMAP patch?

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

Re: [FFmpeg-devel] [PATCH]lavc/psd: Support 1bpp images

[Gonzalo Garramuño]

El 10/01/2017 a las 10:21, Carl Eugen Hoyos escribió:

  }
+} else if (avctx->pix_fmt == AV_PIX_FMT_MONOWHITE) {
+ptr = picture->data[0];
+for (y = 0; y < s->height; y++) {
+memcpy(ptr, ptr_data, s->width + 7 >> 3);
+ptr_data += s->width + 7 >> 3;
+ptr += picture->linesize[0];
+}
Just a nitpick.  I would put s->width + 7 >> 3 in a variable outside the 
loop and use it in memcpy and in the ptr_data.

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

[FFmpeg-devel] [PATCH] hevc: Mark as having threadsafe init

[Derek Buitenhuis]

Signed-off-by: Derek Buitenhuis 
---
It looks like it already is threadsafe, amazingly? I don't
see any table inits, somehow.
---
 libavcodec/hevc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index 7c563a3..607a8da 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -3416,5 +3416,6 @@ AVCodec ff_hevc_decoder = {
 .init_thread_copy  = hevc_init_thread_copy,
 .capabilities  = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY |
  AV_CODEC_CAP_SLICE_THREADS | 
AV_CODEC_CAP_FRAME_THREADS,
+.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
 .profiles  = NULL_IF_CONFIG_SMALL(ff_hevc_profiles),
 };
-- 
1.8.3.1

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

Re: [FFmpeg-devel] [PATCH]lavc/psd: Interpret duotone as grayscale

[Martin Vignali]

Hello,

Seems strange, that duotone is interpreted like grayscale
(i doesn't test yet your patch)

You can find a sample here (and an rgb png of the result in photoshop), for
a duotone file with color
https://we.tl/mbvMt5bytk

I think, duotone, need to be interpreted using information in Image
Ressource

I never use Duotone before, so i can't really help to the right way to
interpret this kind of file

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

[FFmpeg-devel] [PATCH] avformat/hlsenc: fix the bug when the largest segment duration pointer right value is 0

[Steven Liu]

when the segments largest duration value is look like 4.00, the
EXT-X-TARGETDURATION value should equ 4.
it's wrong when hlsenc use ceil, so fix it.

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 3d2d41a..a2c606c 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -141,6 +141,11 @@ typedef struct HLSContext {
 char current_segment_final_filename_fmt[1024]; // when renaming segments
 } HLSContext;
 
+static int get_int_from_double(double val)
+{
+return (int)((val - (int)val) >= 0.001) ? (int)(val + 1) : (int)val;
+}
+
 static int mkdir_p(const char *path) {
 int ret = 0;
 char *temp = av_strdup(path);
@@ -668,8 +673,8 @@ static int hls_window(AVFormatContext *s, int last)
 goto fail;
 
 for (en = hls->segments; en; en = en->next) {
-if (target_duration < en->duration)
-target_duration = ceil(en->duration);
+if (target_duration <= en->duration)
+target_duration = get_int_from_double(en->duration);
 }
 
 hls->discontinuity_set = 0;
-- 
2.10.1 (Apple Git-78)



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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options

[Bodecs Bela]

2017.01.10. 12:10 keltezéssel, Steven Liu írta:

2017-01-10 17:42 GMT+08:00 Bodecs Bela :



2017.01.10. 6:53 keltezéssel, Steven Liu írta:


2017-01-08 8:22 GMT+08:00 Steven Liu :



2017-01-08 1:37 GMT+08:00 Bodecs Bela :



2017.01.07. 0:32 keltezéssel, Steven Liu írta:

2017-01-07 0:47 GMT+08:00 Bodecs Bela :


2017.01.06. 17:33 keltezéssel, Steven Liu írta:

2017-01-07 0:22 GMT+08:00 Bodecs Bela :


2017.01.06. 16:50 keltezéssel, Steven Liu írta:


2017-01-06 22:07 GMT+08:00 Bodecs Bela :

Dear All,

in avformat/hlsenc the start_number option starts the playlist


sequence
number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless
hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have
unique
starting numbers at each run, but currently it is only achiveable
by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01
00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.


thank you,

Bela Bodecs


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


Two question:

1. char b[21];   Why this is 21 ?


you are right, 15 is enough.

2. +{"start_number",  "set first number in the sequence",

  OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0}, -2,

INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation, for
example
-2 mean -1 mean  0 mean, and default value.

yes, I have altered now but I have written verbosly into the doc

(muxers.texi), here:

+If set to -1, then the start number will be the seconds since epoch
(1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current
date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0.

___

ffmpeg-devel mailing list


ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I have enclosed a fixed version. A have changed some code, where
greater

than 32 bit long sequence numbers were not handled correctly.

(av_get_frame_filename2)

thank you.
Bela Bodecs


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


+{"start_number",  "set first number in the sequence, 0 is
default,

-1:

second since epoch, -2: current datetime as MMDDhhmmss, actual
value
otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0},
-2,
INT64_MAX, E},

I have check this option, i think add flag to control the
start_number
maybe better,
for example:
hls_flags
hls_playlist_type

maybe add a start_number_flags is better, What about you think?

Using hls_flags is not enough to specify different values for them.


NO, i am not mean use hls_flags, i mean you can creat a new flags,


start_number_flags
generic
epoch
datetime

Ok, I see it. May I implement it?


yes, of course ;-)



I thought that there should be 3 options beside this start_number

option.

hls_start_number_playlist, hls_start_number_segment and

hls_start_number_vtt
Using start_number and any of the new 3 ones would be mutualy
exlusive.

This way anybody could use the old option (start_number) and it won't
break the current behaviour.
But those who want to have finer control, they may use the new
options.

of course -start_number x  has the same effect as using
-hls_start_number_playlist x -hls_start_number_segment x
-hls_start_number_vtt x



___

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

___


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



Hi Bodecs,

If you don't have enough time, i think i can do it together  with
you;)


here it is.

___

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



+typedef enum {
+  HLS_START_SEQUNCE_AS_START_NUMBER = 0,
+  

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options

[Bodecs Bela]

2017.01.10. 12:10 keltezéssel, Steven Liu írta:

2017-01-10 17:42 GMT+08:00 Bodecs Bela :



2017.01.10. 6:53 keltezéssel, Steven Liu írta:


2017-01-08 8:22 GMT+08:00 Steven Liu :



2017-01-08 1:37 GMT+08:00 Bodecs Bela :



2017.01.07. 0:32 keltezéssel, Steven Liu írta:

2017-01-07 0:47 GMT+08:00 Bodecs Bela :


2017.01.06. 17:33 keltezéssel, Steven Liu írta:

2017-01-07 0:22 GMT+08:00 Bodecs Bela :


2017.01.06. 16:50 keltezéssel, Steven Liu írta:


2017-01-06 22:07 GMT+08:00 Bodecs Bela :

Dear All,

in avformat/hlsenc the start_number option starts the playlist


sequence
number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless
hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have
unique
starting numbers at each run, but currently it is only achiveable
by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01
00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.


thank you,

Bela Bodecs


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


Two question:

1. char b[21];   Why this is 21 ?


you are right, 15 is enough.

2. +{"start_number",  "set first number in the sequence",

  OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0}, -2,

INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation, for
example
-2 mean -1 mean  0 mean, and default value.

yes, I have altered now but I have written verbosly into the doc

(muxers.texi), here:

+If set to -1, then the start number will be the seconds since epoch
(1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current
date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0.

___

ffmpeg-devel mailing list


ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I have enclosed a fixed version. A have changed some code, where
greater

than 32 bit long sequence numbers were not handled correctly.

(av_get_frame_filename2)

thank you.
Bela Bodecs


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


+{"start_number",  "set first number in the sequence, 0 is
default,

-1:

second since epoch, -2: current datetime as MMDDhhmmss, actual
value
otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0},
-2,
INT64_MAX, E},

I have check this option, i think add flag to control the
start_number
maybe better,
for example:
hls_flags
hls_playlist_type

maybe add a start_number_flags is better, What about you think?

Using hls_flags is not enough to specify different values for them.


NO, i am not mean use hls_flags, i mean you can creat a new flags,


start_number_flags
generic
epoch
datetime

Ok, I see it. May I implement it?


yes, of course ;-)



I thought that there should be 3 options beside this start_number

option.

hls_start_number_playlist, hls_start_number_segment and

hls_start_number_vtt
Using start_number and any of the new 3 ones would be mutualy
exlusive.

This way anybody could use the old option (start_number) and it won't
break the current behaviour.
But those who want to have finer control, they may use the new
options.

of course -start_number x  has the same effect as using
-hls_start_number_playlist x -hls_start_number_segment x
-hls_start_number_vtt x



___

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

___


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



Hi Bodecs,

If you don't have enough time, i think i can do it together  with
you;)


here it is.

___

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



+typedef enum {
+  HLS_START_SEQUNCE_AS_START_NUMBER = 0,
+  

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options

[Bodecs Bela]

2017.01.10. 13:02 keltezéssel, Moritz Barsnick írta:

On Tue, Jan 10, 2017 at 10:42:21 +0100, Bodecs Bela wrote:

Hls speficication allow 64 bit integers as sequence numbers. This patch

   ^ specification allows


+typedef enum {
+  HLS_START_SEQUNCE_AS_START_NUMBER,
+  HLS_START_SEQUNCE_AS_SECONDS_SINCE_EPOCH,
+  HLS_START_SEQUNCE_AS_FORMATTED_DATETIME,  // MMDDhhmmss

^ correct spelling would be SEQUENCE :)

Otherwise, grammar looks okay to me.

Missing documentation in doc/muxers.texi.

my patch included the muxers.texi also.


Moritz
___
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] fate/psd : add test for 256 color psd file

[Michael Niedermayer]

On Mon, Jan 09, 2017 at 11:08:00PM +0100, Martin Vignali wrote:
> Hello,
> 
> Sample can be found here :
> https://we.tl/CX9svvyEdI

file uploaded

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] avformat: Add rtp_mpegtsraw (MPEG-TS RAW Stream output)

[Michael Niedermayer]

On Mon, Jan 09, 2017 at 02:59:37PM -0500, Andreas Håkon wrote:
> Hi,
> 
> This patch adds a new MUXER named "rtp_mpegtsraw". This new muxer works with
> the "mpegtsraw" input demuxer. The objective is enable direct bitstream
> input-output of MPEG-TS for RTP+FEC. Using the recent support for Pro-MPEG CoP
> FEC protocol, you can now use FFmpeg for streaming any UDP/RTP MPEG-TS stream.
> 
> Example:
> 
> ffmpeg -f mpegtsraw -i udp://239.8.8.8:12345 -map 0 -c copy -f rtp_mpegtsraw 
> -fec prompeg=l=8:d=8 rtp://239.9.9.9:1
> 
> In this example FFmpeg reads from the network one stream in UDP o RTP format
> from the multicast address 239.8.8.8:12345 and re-encapsulates it without
> remuxing to the multicast address 239.9.9.9 using RTP+FEC
> (ports 1 & 10001 are for the base RTP, port 10002 are for "row" and 10004
> are for "column").
> 
> If you ever have had the need to do use FFmpeg in plain "bitstream" mode
> with MPEG-TS streams, you have luck: know you can!
> 
> Please comment,
> Andreas Håkon
> 
> 
> Signed-off-by: Andreas Håkon 
> ---
> ffmpeg.c | 1 +
> libavformat/allformats.c | 1 +
> libavformat/mpegts.c | 2 +-
> libavformat/rtpenc.c | 6 ++
> libavformat/rtpenc_mpegts.c | 48 +
> 5 files changed, 57 insertions(+), 1 deletion(-)
> 
> diff --git a/ffmpeg.c b/ffmpeg.c
> index b85c314..838f4d2 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -3228,6 +3228,7 @@ static int init_output_stream_encode(OutputStream *ost)
> }
> break;
> case AVMEDIA_TYPE_DATA:
> + av_log(NULL, AV_LOG_TRACE, "Using bitstream with codec %s\n", 
> avcodec_get_name(enc_ctx->codec_id));
> break;
> default:
> abort();
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 6a79b75..b58e178 100644

patch seems corrupted:

Applying: avformat: Add rtp_mpegtsraw (MPEG-TS RAW Stream output)
error: corrupt patch at line 14
error: could not build fake ancestor
Patch failed at 0001 avformat: Add rtp_mpegtsraw (MPEG-TS RAW Stream output)
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


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

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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

Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle given video parameters

[Timo Rothenpieler]

> The real problem I am trying to solve -- I need to find the "best"
> decoder for the incoming stream, or file.  There are multiple decoders
> available for H264 ... Selecting based on supported output pixel
> formats would eliminate some.  Selecting based on AVCodecParameters
> would allow to eliminate those decoders that can't handle given
> parameters, although that appears to be insufficient.  Perhaps
> selecting based on given codec extradata (PPS/SPS) would be more
> robust.  extradata is usually part of the bitstream... is there an API
> to feed extradata to the decoder to see if it likes it?

At least cuvid does just that on init:
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/cuvid.c;h=8fc713d08166617696b3dcf86d0f1dbe9d3bd41d;hb=HEAD#l839

I have never seen it fail because of it.
You can send random garbage and it doesn't ever fail.
Never tried a valid but unsupported set of headers though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options

[Moritz Barsnick]

On Tue, Jan 10, 2017 at 10:42:21 +0100, Bodecs Bela wrote:
> Hls speficication allow 64 bit integers as sequence numbers. This patch
  ^ specification allows

> +typedef enum {
> +  HLS_START_SEQUNCE_AS_START_NUMBER,
> +  HLS_START_SEQUNCE_AS_SECONDS_SINCE_EPOCH,
> +  HLS_START_SEQUNCE_AS_FORMATTED_DATETIME,  // MMDDhhmmss
   ^ correct spelling would be SEQUENCE :)

Otherwise, grammar looks okay to me.

Missing documentation in doc/muxers.texi.

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

[FFmpeg-devel] [PATCH 1/3] cmdutils_opencl: fix resource_leak cid 1396852

[Steven Liu]

CID: 1396852
check the devices_list alloc status,
and release the devices_list when alloc devices error

Signed-off-by: Steven Liu 
---
 cmdutils_opencl.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/cmdutils_opencl.c b/cmdutils_opencl.c
index dd21344..5bbc8dc 100644
--- a/cmdutils_opencl.c
+++ b/cmdutils_opencl.c
@@ -220,15 +220,20 @@ int opt_opencl_bench(void *optctx, const char *opt, const 
char *arg)
 OpenCLDeviceBenchmark *devices = NULL;
 cl_platform_id platform;
 
-av_opencl_get_device_list(_list);
+if (av_opencl_get_device_list(_list) < 0) {
+return AVERROR(ENOMEM);
+}
+
 for (i = 0; i < device_list->platform_num; i++)
 nb_devices += device_list->platform_node[i]->device_num;
 if (!nb_devices) {
 av_log(NULL, AV_LOG_ERROR, "No OpenCL device detected!\n");
+av_opencl_free_device_list(_list);
 return AVERROR(EINVAL);
 }
 if (!(devices = av_malloc_array(nb_devices, 
sizeof(OpenCLDeviceBenchmark {
 av_log(NULL, AV_LOG_ERROR, "Could not allocate buffer\n");
+av_opencl_free_device_list(_list);
 return AVERROR(ENOMEM);
 }
 
-- 
2.10.1.382.ga23ca1b.dirty



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

[FFmpeg-devel] [PATCH 2/3] avcodec/bsf: fix resource leak in av_bsf_list_parse_str

[Steven Liu]

cid: 1396268
when av_strdup(str) error, the lst need release

Signed-off-by: Steven Liu 
---
 libavcodec/bsf.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
index ac2024b..c9b1df2 100644
--- a/libavcodec/bsf.c
+++ b/libavcodec/bsf.c
@@ -514,8 +514,10 @@ int av_bsf_list_parse_str(const char *str, AVBSFContext 
**bsf_lst)
 if (!lst)
 return AVERROR(ENOMEM);
 
-if (!(dup = buf = av_strdup(str)))
-return AVERROR(ENOMEM);
+if (!(dup = buf = av_strdup(str))) {
+ret = AVERROR(ENOMEM);
+goto free_lst;
+}
 
 while (1) {
 bsf_str = av_strtok(buf, ",", );
@@ -524,16 +526,17 @@ int av_bsf_list_parse_str(const char *str, AVBSFContext 
**bsf_lst)
 
 ret = bsf_parse_single(bsf_str, lst);
 if (ret < 0)
-goto end;
+goto free_all;
 
 buf = NULL;
 }
 
 ret = av_bsf_list_finalize(, bsf_lst);
-end:
+free_all:
+av_free(dup);
+free_lst:
 if (ret < 0)
 av_bsf_list_free();
-av_free(dup);
 return ret;
 }
 
-- 
2.10.1.382.ga23ca1b.dirty



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

[FFmpeg-devel] [PATCH 3/3] avfilter/vf_libopencv: fix resource leak in read_shape_frame_filter

[Steven Liu]

CID: 1324298
add a label when error goto the label to release resource

Signed-off-by: Steven Liu 
---
 libavfilter/vf_libopencv.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_libopencv.c b/libavfilter/vf_libopencv.c
index f8ae9d5..8128030 100644
--- a/libavfilter/vf_libopencv.c
+++ b/libavfilter/vf_libopencv.c
@@ -157,7 +157,8 @@ static int read_shape_from_file(int *cols, int *rows, int 
**values, const char *
 if (buf[i] == '\n') {
 if (*rows == INT_MAX) {
 av_log(log_ctx, AV_LOG_ERROR, "Overflow on the number of rows 
in the file\n");
-return AVERROR_INVALIDDATA;
+ret = AVERROR_INVALIDDATA;
+goto end;
 }
 ++(*rows);
 *cols = FFMAX(*cols, w);
@@ -171,10 +172,13 @@ static int read_shape_from_file(int *cols, int *rows, int 
**values, const char *
 if (*rows > (SIZE_MAX / sizeof(int) / *cols)) {
 av_log(log_ctx, AV_LOG_ERROR, "File with size %dx%d is too big\n",
*rows, *cols);
-return AVERROR_INVALIDDATA;
+ret = AVERROR_INVALIDDATA;
+goto end;
+}
+if (!(*values = av_mallocz_array(sizeof(int) * *rows, *cols))) {
+ret = AVERROR(ENOMEM);
+goto end;
 }
-if (!(*values = av_mallocz_array(sizeof(int) * *rows, *cols)))
-return AVERROR(ENOMEM);
 
 /* fill *values */
 p= buf;
@@ -188,6 +192,8 @@ static int read_shape_from_file(int *cols, int *rows, int 
**values, const char *
 (*values)[*cols*i + j] = !!av_isgraph(*(p++));
 }
 }
+
+end:
 av_file_unmap(buf, size);
 
 #ifdef DEBUG
-- 
2.10.1.382.ga23ca1b.dirty



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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options

[Steven Liu]

2017-01-10 17:42 GMT+08:00 Bodecs Bela :

>
>
> 2017.01.10. 6:53 keltezéssel, Steven Liu írta:
>
>> 2017-01-08 8:22 GMT+08:00 Steven Liu :
>>
>>
>>> 2017-01-08 1:37 GMT+08:00 Bodecs Bela :
>>>
>>>
 2017.01.07. 0:32 keltezéssel, Steven Liu írta:

 2017-01-07 0:47 GMT+08:00 Bodecs Bela :
>
>
> 2017.01.06. 17:33 keltezéssel, Steven Liu írta:
>>
>> 2017-01-07 0:22 GMT+08:00 Bodecs Bela :
>>
>>>
>>> 2017.01.06. 16:50 keltezéssel, Steven Liu írta:
>>>
 2017-01-06 22:07 GMT+08:00 Bodecs Bela :

 Dear All,
>
> in avformat/hlsenc the start_number option starts the playlist
>
>> sequence
>> number
>> (#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless
>> hls_flags
>> single_file is set, it also specifies starting sequence numbers of
>> segment and subtitle filenames. Sometimes it is usefull to have
>> unique
>> starting numbers at each run, but currently it is only achiveable
>> by
>> setting this parameter manually.
>> This patch enables to set start_number parameter automatically for
>> practically unique numbers. If start_number is set to -1, then
>> the start number will be the seconds since epoch (1970-01-01
>> 00:00:00).
>> If set to -2, then the start number will be based on the current
>> date/time value as mmddHHMMSS. e.g. 20161231235659.
>>
>>
>> thank you,
>>
>> Bela Bodecs
>>
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>>
>> Two question:
>>
>> 1. char b[21];   Why this is 21 ?
>>
> you are right, 15 is enough.
>
> 2. +{"start_number",  "set first number in the sequence",

  OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0}, -2,
> INT64_MAX,
> E},
> Why is this -2 and the help message maybe need more infomation, for
> example
> -2 mean -1 mean  0 mean, and default value.
>
> yes, I have altered now but I have written verbosly into the doc
>
> (muxers.texi), here:

 +If set to -1, then the start number will be the seconds since epoch
 (1970-01-01 00:00:00).
 +If set to -2, then the start number will be based on the current
 date/time as mmddHHMMSS. e.g. 20161231235759.
 +Default value is 0.

 ___

 ffmpeg-devel mailing list

> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> I have enclosed a fixed version. A have changed some code, where
> greater
>
> than 32 bit long sequence numbers were not handled correctly.
 (av_get_frame_filename2)

 thank you.
 Bela Bodecs


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


 +{"start_number",  "set first number in the sequence, 0 is
 default,

 -1:
>>> second since epoch, -2: current datetime as MMDDhhmmss, actual
>>> value
>>> otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0},
>>>-2,
>>> INT64_MAX, E},
>>>
>>> I have check this option, i think add flag to control the
>>> start_number
>>> maybe better,
>>> for example:
>>> hls_flags
>>> hls_playlist_type
>>>
>>> maybe add a start_number_flags is better, What about you think?
>>>
>>> Using hls_flags is not enough to specify different values for them.
>>>
>> NO, i am not mean use hls_flags, i mean you can creat a new flags,
>>
> start_number_flags
>generic
>epoch
>datetime
>
> Ok, I see it. May I implement it?


 yes, of course ;-)
>>>
>>>
 I thought that there should be 3 options beside this start_number
> option.
>
> hls_start_number_playlist, hls_start_number_segment and
>> hls_start_number_vtt
>> Using start_number and any of the new 3 ones would be mutualy
>> exlusive.
>>
>> This way anybody could use the old option (start_number) and it won't
>> break the current behaviour.
>> But those who want to have finer control, they may use the new
>> options.
>>
>> of course -start_number x  has the same effect as using
>> 

Re: [FFmpeg-devel] [PATCH 2/4] dxva2: use a single macro to test if the DXVA context is valid

[Steve Lhomme]

This was not rejected and has been merged in libav.
3/4 and 4/4 seem to be valid too and pending on both sides. I just
need to send an update of 4/4 as the libavcodec version has changed.

On Wed, Jan 4, 2017 at 2:36 PM, Steve Lhomme  wrote:
> ---
>  libavcodec/dxva2_h264.c | 4 +---
>  libavcodec/dxva2_hevc.c | 4 +---
>  libavcodec/dxva2_internal.h | 5 +
>  libavcodec/dxva2_mpeg2.c| 4 +---
>  libavcodec/dxva2_vc1.c  | 4 +---
>  libavcodec/dxva2_vp9.c  | 4 +---
>  6 files changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/libavcodec/dxva2_h264.c b/libavcodec/dxva2_h264.c
> index 82a772d..59fa5e3 100644
> --- a/libavcodec/dxva2_h264.c
> +++ b/libavcodec/dxva2_h264.c
> @@ -450,9 +450,7 @@ static int dxva2_h264_start_frame(AVCodecContext *avctx,
>  AVDXVAContext *ctx = avctx->hwaccel_context;
>  struct dxva2_picture_context *ctx_pic = 
> h->cur_pic_ptr->hwaccel_picture_private;
>
> -if (DXVA_CONTEXT_DECODER(avctx, ctx) == NULL ||
> -DXVA_CONTEXT_CFG(avctx, ctx) == NULL ||
> -DXVA_CONTEXT_COUNT(avctx, ctx) <= 0)
> +if (!DXVA_CONTEXT_VALID(avctx, ctx))
>  return -1;
>  assert(ctx_pic);
>
> diff --git a/libavcodec/dxva2_hevc.c b/libavcodec/dxva2_hevc.c
> index 5a312ea..981c888 100644
> --- a/libavcodec/dxva2_hevc.c
> +++ b/libavcodec/dxva2_hevc.c
> @@ -364,9 +364,7 @@ static int dxva2_hevc_start_frame(AVCodecContext *avctx,
>  AVDXVAContext *ctx = avctx->hwaccel_context;
>  struct hevc_dxva2_picture_context *ctx_pic = 
> h->ref->hwaccel_picture_private;
>
> -if (DXVA_CONTEXT_DECODER(avctx, ctx) == NULL ||
> -DXVA_CONTEXT_CFG(avctx, ctx) == NULL ||
> -DXVA_CONTEXT_COUNT(avctx, ctx) <= 0)
> +if (!DXVA_CONTEXT_VALID(avctx, ctx))
>  return -1;
>  av_assert0(ctx_pic);
>
> diff --git a/libavcodec/dxva2_internal.h b/libavcodec/dxva2_internal.h
> index c962810..e5322ef 100644
> --- a/libavcodec/dxva2_internal.h
> +++ b/libavcodec/dxva2_internal.h
> @@ -76,6 +76,9 @@ typedef union {
>  #define DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx)  (avctx->pix_fmt == 
> AV_PIX_FMT_D3D11VA_VLD ? ctx->d3d11va.cfg->ConfigBitstreamRaw : 
> ctx->dxva2.cfg->ConfigBitstreamRaw)
>  #define DXVA_CONTEXT_CFG_INTRARESID(avctx, ctx) (avctx->pix_fmt == 
> AV_PIX_FMT_D3D11VA_VLD ? ctx->d3d11va.cfg->ConfigIntraResidUnsigned : 
> ctx->dxva2.cfg->ConfigIntraResidUnsigned)
>  #define DXVA_CONTEXT_CFG_RESIDACCEL(avctx, ctx) (avctx->pix_fmt == 
> AV_PIX_FMT_D3D11VA_VLD ? ctx->d3d11va.cfg->ConfigResidDiffAccelerator : 
> ctx->dxva2.cfg->ConfigResidDiffAccelerator)
> +#define DXVA_CONTEXT_VALID(avctx, ctx)  (DXVA_CONTEXT_DECODER(avctx, 
> ctx) && \
> + DXVA_CONTEXT_CFG(avctx, 
> ctx) && \
> + DXVA_CONTEXT_COUNT(avctx, 
> ctx))
>  #elif CONFIG_DXVA2
>  #define DXVA_CONTEXT_WORKAROUND(avctx, ctx) (ctx->dxva2.workaround)
>  #define DXVA_CONTEXT_COUNT(avctx, ctx)  (ctx->dxva2.surface_count)
> @@ -85,6 +88,7 @@ typedef union {
>  #define DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx)  
> (ctx->dxva2.cfg->ConfigBitstreamRaw)
>  #define DXVA_CONTEXT_CFG_INTRARESID(avctx, ctx) 
> (ctx->dxva2.cfg->ConfigIntraResidUnsigned)
>  #define DXVA_CONTEXT_CFG_RESIDACCEL(avctx, ctx) 
> (ctx->dxva2.cfg->ConfigResidDiffAccelerator)
> +#define DXVA_CONTEXT_VALID(avctx, ctx)  (ctx->dxva2.decoder && 
> ctx->dxva2.cfg && ctx->dxva2.surface_count)
>  #elif CONFIG_D3D11VA
>  #define DXVA_CONTEXT_WORKAROUND(avctx, ctx) (ctx->d3d11va.workaround)
>  #define DXVA_CONTEXT_COUNT(avctx, ctx)  (ctx->d3d11va.surface_count)
> @@ -94,6 +98,7 @@ typedef union {
>  #define DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx)  
> (ctx->d3d11va.cfg->ConfigBitstreamRaw)
>  #define DXVA_CONTEXT_CFG_INTRARESID(avctx, ctx) 
> (ctx->d3d11va.cfg->ConfigIntraResidUnsigned)
>  #define DXVA_CONTEXT_CFG_RESIDACCEL(avctx, ctx) 
> (ctx->d3d11va.cfg->ConfigResidDiffAccelerator)
> +#define DXVA_CONTEXT_VALID(avctx, ctx)  (ctx->d3d11va.decoder && 
> ctx->d3d11va.cfg && ctx->d3d11va.surface_count)
>  #endif
>
>  unsigned ff_dxva2_get_surface_index(const AVCodecContext *avctx,
> diff --git a/libavcodec/dxva2_mpeg2.c b/libavcodec/dxva2_mpeg2.c
> index c2f0b58..14ac48f 100644
> --- a/libavcodec/dxva2_mpeg2.c
> +++ b/libavcodec/dxva2_mpeg2.c
> @@ -262,9 +262,7 @@ static int dxva2_mpeg2_start_frame(AVCodecContext *avctx,
>  struct dxva2_picture_context *ctx_pic =
>  s->current_picture_ptr->hwaccel_picture_private;
>
> -if (DXVA_CONTEXT_DECODER(avctx, ctx) == NULL ||
> -DXVA_CONTEXT_CFG(avctx, ctx) == NULL ||
> -DXVA_CONTEXT_COUNT(avctx, ctx) <= 0)
> +if (!DXVA_CONTEXT_VALID(avctx, ctx))
>  return -1;
>  assert(ctx_pic);
>
> diff --git a/libavcodec/dxva2_vc1.c b/libavcodec/dxva2_vc1.c
> index 36bf1ba..cc97d7b 100644
> --- a/libavcodec/dxva2_vc1.c
> +++ b/libavcodec/dxva2_vc1.c
> @@ -317,9 +317,7 @@ static int 

[FFmpeg-devel] [PATCH 4/4] dxva2: allow an empty array of ID3D11VideoDecoderOutputView

[Steve Lhomme]

We can pick the correct slice index directly from the 
ID3D11VideoDecoderOutputView
casted from data[3].
---
 libavcodec/dxva2_internal.h | 4 ++--
 libavcodec/version.h| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/dxva2_internal.h b/libavcodec/dxva2_internal.h
index e5322ef..dfff4d6 100644
--- a/libavcodec/dxva2_internal.h
+++ b/libavcodec/dxva2_internal.h
@@ -78,7 +78,7 @@ typedef union {
 #define DXVA_CONTEXT_CFG_RESIDACCEL(avctx, ctx) (avctx->pix_fmt == 
AV_PIX_FMT_D3D11VA_VLD ? ctx->d3d11va.cfg->ConfigResidDiffAccelerator : 
ctx->dxva2.cfg->ConfigResidDiffAccelerator)
 #define DXVA_CONTEXT_VALID(avctx, ctx)  (DXVA_CONTEXT_DECODER(avctx, 
ctx) && \
  DXVA_CONTEXT_CFG(avctx, ctx) 
&& \
- DXVA_CONTEXT_COUNT(avctx, 
ctx))
+ (avctx->pix_fmt == 
AV_PIX_FMT_D3D11VA_VLD || ctx->dxva2.surface_count))
 #elif CONFIG_DXVA2
 #define DXVA_CONTEXT_WORKAROUND(avctx, ctx) (ctx->dxva2.workaround)
 #define DXVA_CONTEXT_COUNT(avctx, ctx)  (ctx->dxva2.surface_count)
@@ -98,7 +98,7 @@ typedef union {
 #define DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx)  
(ctx->d3d11va.cfg->ConfigBitstreamRaw)
 #define DXVA_CONTEXT_CFG_INTRARESID(avctx, ctx) 
(ctx->d3d11va.cfg->ConfigIntraResidUnsigned)
 #define DXVA_CONTEXT_CFG_RESIDACCEL(avctx, ctx) 
(ctx->d3d11va.cfg->ConfigResidDiffAccelerator)
-#define DXVA_CONTEXT_VALID(avctx, ctx)  (ctx->d3d11va.decoder && 
ctx->d3d11va.cfg && ctx->d3d11va.surface_count)
+#define DXVA_CONTEXT_VALID(avctx, ctx)  (ctx->d3d11va.decoder && 
ctx->d3d11va.cfg)
 #endif
 
 unsigned ff_dxva2_get_surface_index(const AVCodecContext *avctx,
diff --git a/libavcodec/version.h b/libavcodec/version.h
index c5a8f55..7f1b0a4 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR  57
 #define LIBAVCODEC_VERSION_MINOR  71
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
-- 
2.10.1.windows.1

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options

[Bodecs Bela]

2017.01.10. 6:53 keltezéssel, Steven Liu írta:

2017-01-08 8:22 GMT+08:00 Steven Liu :



2017-01-08 1:37 GMT+08:00 Bodecs Bela :



2017.01.07. 0:32 keltezéssel, Steven Liu írta:


2017-01-07 0:47 GMT+08:00 Bodecs Bela :



2017.01.06. 17:33 keltezéssel, Steven Liu írta:

2017-01-07 0:22 GMT+08:00 Bodecs Bela :


2017.01.06. 16:50 keltezéssel, Steven Liu írta:

2017-01-06 22:07 GMT+08:00 Bodecs Bela :


Dear All,

in avformat/hlsenc the start_number option starts the playlist

sequence
number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have
unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01
00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.


thank you,

Bela Bodecs


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


Two question:

1. char b[21];   Why this is 21 ?

you are right, 15 is enough.


2. +{"start_number",  "set first number in the sequence",


 OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0}, -2,
INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation, for
example
-2 mean -1 mean  0 mean, and default value.

yes, I have altered now but I have written verbosly into the doc


(muxers.texi), here:

+If set to -1, then the start number will be the seconds since epoch
(1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current
date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0.

___

ffmpeg-devel mailing list

ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I have enclosed a fixed version. A have changed some code, where
greater


than 32 bit long sequence numbers were not handled correctly.
(av_get_frame_filename2)

thank you.
Bela Bodecs


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


+{"start_number",  "set first number in the sequence, 0 is
default,


-1:
second since epoch, -2: current datetime as MMDDhhmmss, actual
value
otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0},
   -2,
INT64_MAX, E},

I have check this option, i think add flag to control the start_number
maybe better,
for example:
hls_flags
hls_playlist_type

maybe add a start_number_flags is better, What about you think?

Using hls_flags is not enough to specify different values for them.

NO, i am not mean use hls_flags, i mean you can creat a new flags,

start_number_flags
   generic
   epoch
   datetime


Ok, I see it. May I implement it?



yes, of course ;-)




I thought that there should be 3 options beside this start_number option.


hls_start_number_playlist, hls_start_number_segment and
hls_start_number_vtt
Using start_number and any of the new 3 ones would be mutualy exlusive.

This way anybody could use the old option (start_number) and it won't
break the current behaviour.
But those who want to have finer control, they may use the new options.

of course -start_number x  has the same effect as using
-hls_start_number_playlist x -hls_start_number_segment x
-hls_start_number_vtt x



___


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

___

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




Hi Bodecs,

   If you don't have enough time, i think i can do it together  with
you;)

here it is.

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


>From 5222dc3bb369186a7a185c4a133503b1ea694885 Mon Sep 17 00:00:00 2001
From: Bela Bodecs 
Date: Fri, 6 Jan 2017 14:52:08 +0100
Subject: [PATCH] avformat/hlsenc: hls_start_number_source and start_number

start_number option starts the playlist sequence number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags

Re: [FFmpeg-devel] [PATCH 2/3] avformat/avienc: add reserve_index_space option

[Tobias Rapp]

On 10.01.2017 00:15, Michael Niedermayer wrote:

On Mon, Jan 09, 2017 at 09:56:51AM +0100, Tobias Rapp wrote:

Allows the user to reserve space for the ODML master index. A sufficient
sized master index in the AVI header avoids storing follow-up master
indexes within the 'movi' data later.

Signed-off-by: Tobias Rapp 
---
 libavformat/avi.h |  1 -
 libavformat/avienc.c  | 36 +---
 libavformat/version.h |  2 +-
 3 files changed, 30 insertions(+), 9 deletions(-)


iam not against this but as the only way to write strictly spec
compiant files >= 256g, i think this is not very user friendly

FFmpeg should work out of the box not requireing the user to tune
options


I took the "reserve_index_space" option of matroskaenc.c as an 
inspiration. But I see that for Matroska it is "just" a matter of 
optimization while for AVI it means compliance + optimization.



Here are some random ideas:

Enlarge the default index depending on expected bitrate, a high res
rawvideo input should by default get a bigger reserved index space


Yes, this would be a low-hanging fruit.


Use the input file duration (aka pass it to the muxer) and use it as
a guess on duration, enlarge the space accordingly


You mean guessing and setting the AVStream->duration field in ffmpeg.c 
as a hint to the AVI muxer? Will take a look on how this could be done.



Or, do the hard but correct and just enlarge it
As in when you hit some SIZE1 like lets say 1GB leave 1mb space
(which at this filesize is a insignificant 0.1%)
and when writing the trailer and the file exceeded 256G go back and
move the first 1gb forward to make space for a larger master index.
(this at that point just moves 0.5% of the file)
You can also use the 1mb space for holding a 2nd master index prior
to writing the trailer. Either way the file should ideally be partially
indexed while it is being written so a 2nd process could read and mostly
seek in it


Moving the first 1GB forward also means updating each entry within the 
legacy "idx1" index structure plus the base offset of each ODML standard 
stream index. Further as the ODML master index of each stream has to be 
enlarged also parts of the file header need to be moved.


In my opinion this would be a complex and fragile process. It seems more 
safe to either warn the user to re-mux with adapted options (if he/she 
cares for strict compliance) or fail, as discussed in the other thread 
of this patch series.


Regards,
Tobias

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

Re: [FFmpeg-devel] swresample/aarch64: add s16 and fltp neon resampling functions

[Matthieu Bouron]

On Mon, Jan 09, 2017 at 05:45:29PM +0100, Matthieu Bouron wrote:
> Hello,
> 
> The following patch is a port of 6d82b52712af87c7831872c27fd2abfd18b04f88 to
> the aarch64 platform.

Correct reference is f6265a5cbcfb94c34e233a47930ec50495b176de.

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options

[Bodecs Bela]

2017.01.10. 6:53 keltezéssel, Steven Liu írta:

2017-01-08 8:22 GMT+08:00 Steven Liu :



2017-01-08 1:37 GMT+08:00 Bodecs Bela :



2017.01.07. 0:32 keltezéssel, Steven Liu írta:


2017-01-07 0:47 GMT+08:00 Bodecs Bela :



2017.01.06. 17:33 keltezéssel, Steven Liu írta:

2017-01-07 0:22 GMT+08:00 Bodecs Bela :


2017.01.06. 16:50 keltezéssel, Steven Liu írta:

2017-01-06 22:07 GMT+08:00 Bodecs Bela :


Dear All,

in avformat/hlsenc the start_number option starts the playlist

sequence
number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have
unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01
00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.


thank you,

Bela Bodecs


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


Two question:

1. char b[21];   Why this is 21 ?

you are right, 15 is enough.


2. +{"start_number",  "set first number in the sequence",


 OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0}, -2,
INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation, for
example
-2 mean -1 mean  0 mean, and default value.

yes, I have altered now but I have written verbosly into the doc


(muxers.texi), here:

+If set to -1, then the start number will be the seconds since epoch
(1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current
date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0.

___

ffmpeg-devel mailing list

ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

I have enclosed a fixed version. A have changed some code, where
greater


than 32 bit long sequence numbers were not handled correctly.
(av_get_frame_filename2)

thank you.
Bela Bodecs


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


+{"start_number",  "set first number in the sequence, 0 is
default,


-1:
second since epoch, -2: current datetime as MMDDhhmmss, actual
value
otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64,  {.i64 = 0},
   -2,
INT64_MAX, E},

I have check this option, i think add flag to control the start_number
maybe better,
for example:
hls_flags
hls_playlist_type

maybe add a start_number_flags is better, What about you think?

Using hls_flags is not enough to specify different values for them.

NO, i am not mean use hls_flags, i mean you can creat a new flags,

start_number_flags
   generic
   epoch
   datetime


Ok, I see it. May I implement it?



yes, of course ;-)




I thought that there should be 3 options beside this start_number option.


hls_start_number_playlist, hls_start_number_segment and
hls_start_number_vtt
Using start_number and any of the new 3 ones would be mutualy exlusive.

This way anybody could use the old option (start_number) and it won't
break the current behaviour.
But those who want to have finer control, they may use the new options.

of course -start_number x  has the same effect as using
-hls_start_number_playlist x -hls_start_number_segment x
-hls_start_number_vtt x



___


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

___

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




Hi Bodecs,

   If you don't have enough time, i think i can do it together  with
you;)

I have done it yesterday. I will send it very soon.

___
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 1/3] avformat/avienc: write chained master index only if std_compliance is normal or below

[Tobias Rapp]

On 10.01.2017 00:19, Michael Niedermayer wrote:

On Mon, Jan 09, 2017 at 09:56:50AM +0100, Tobias Rapp wrote:

OpenDML specification v1.02 states that entries of a master index chunk
shall point to standard or field index chunks.

Changed incorrect duration of last master index entry to -1 in case it
points to another master index.

Propagate error when index write fails.

Signed-off-by: Tobias Rapp 
---
 libavformat/avienc.c | 30 +++---
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index fd16fff..5d5c02a 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -524,7 +524,13 @@ static int avi_write_header(AVFormatContext *s)
 return 0;
 }

-static void update_odml_entry(AVFormatContext *s, int stream_index, int64_t 
ix, int size)
+/* Index entry points to standard index */
+#define AVI_UPDATE_ODML_ENTRY_DEFAULT   0x
+
+/* Index entry points to another master index */
+#define AVI_UPDATE_ODML_ENTRY_MASTER0x0001
+
+static void update_odml_entry(AVFormatContext *s, int stream_index, int64_t 
ix, int size, int flags)
 {
 AVIOContext *pb = s->pb;
 AVIContext *avi = s->priv_data;
@@ -544,7 +550,10 @@ static void update_odml_entry(AVFormatContext *s, int 
stream_index, int64_t ix,
 avio_wl64(pb, ix);/* qwOffset */
 avio_wl32(pb, size);  /* dwSize */
 ff_parse_specific_params(s->streams[stream_index], _byterate, _ssize, 
_scale);
-if (s->streams[stream_index]->codecpar->codec_type == AVMEDIA_TYPE_AUDIO && 
au_ssize > 0) {
+if (flags & AVI_UPDATE_ODML_ENTRY_MASTER) {
+av_assert0(s->strict_std_compliance <= FF_COMPLIANCE_NORMAL);
+avio_wl32(pb, -1);  /* dwDuration (undefined) */
+} else if (s->streams[stream_index]->codecpar->codec_type == AVMEDIA_TYPE_AUDIO 
&& au_ssize > 0) {
 uint32_t audio_segm_size = (avist->audio_strm_length - 
avist->indexes.audio_strm_offset);
 if ((audio_segm_size % au_ssize > 0) && !avist->sample_requested) {
 avpriv_request_sample(s, "OpenDML index duration for audio packets with 
partial frames");



@@ -567,6 +576,12 @@ static int avi_write_ix(AVFormatContext *s)

 av_assert0(pb->seekable);

+if (avi->riff_id >= AVI_MASTER_INDEX_SIZE && s->strict_std_compliance > 
FF_COMPLIANCE_NORMAL) {
+av_log(s, AV_LOG_ERROR, "Invalid riff index %d >= %d\n",
+   avi->riff_id, AVI_MASTER_INDEX_SIZE);
+return AVERROR(EINVAL);
+}


isnt it better to warn the user and inform him at the end what size
of reserved space would have been needed?

not saying iam against this, i do see how it is formally correct to
fail hard but it feels painfull to me to fail
muxing at 256gb hard when we can perfectly fine just continue and
the user can just remux the file with bigger reserved master index
to fix it


But then adding "-strict strict" just enables a warning message and a 
non-compliant file is written still? Or do you mean that additionally a 
warning message could be written in case std_compliance is <= normal?


Background story: I'm working on an application that fetches some AVI 
file byte range from tape storage and restores the file header. The 
header restoration requires the ODML master index in the header to be 
complete. Thus I'd like to ensure that all AVI files put into the 
archive have a compliant/compatible index structure.


For such automated processes failing hard is more safe than continuing 
with a warning message, checking for log messages in the host 
application and possibly re-running the transcoding with adapted options.


Regards,
Tobias

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