Re: [FFmpeg-devel] [PATCH v3 01/11] avformat/dashenc: replacing 'min_seg_duration' with 'seg_duration'

2018-04-11 Thread Dixit, Vishwanath


On 4/11/18 11:47 PM, Carl Eugen Hoyos wrote:
> 2018-04-11 9:00 GMT+02:00, vdi...@akamai.com :
>
>> +#if FF_API_DASH_MIN_SEG_DURATION
>> +{ "min_seg_duration", "minimum segment duration (in microseconds) (will
>> be deprecated)"
>
> "is deprecated"
> But since this is a user option added after the last release, you
> may also choose to simply delete it if this simplifies the code.
>
Thanks for your review inputs. Could you please clarify the comment? Do you 
mean, the option 'min_seg_duration' was added after the last stable release 
ffmpeg-3.4.2?
But, it looks like the option 'min_seg_duration' was added 4 years ago, much 
earlier than the couple of last stable releases. Please correct me if I am 
wrong.

> Otoh: Your commit message is missing an explanation why
> renaming this option is a good idea.
Sure. I will submit a new version of this patch with the explanation in the 
commit message.
>
> Carl Eugen

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


Re: [FFmpeg-devel] [PATCH v2 1/2] lavf: make overlay_qsv work based on framesync

2018-04-11 Thread Jun Zhao


On 2018/4/3 9:50, Ruiling Song wrote:
> The existing version which was cherry-picked from Libav does not work
> with FFmpeg framework, because ff_request_frame() was totally
> different between Libav (recursive) and FFmpeg (non-recursive).
> The existing overlay_qsv implementation depends on the recursive version
> of ff_request_frame to trigger immediate call to request_frame() on input pad.
> But this has been removed in FFmpeg since "lavfi: make request_frame() 
> non-recursive."
> Now that we have handy framesync support in FFmpeg, so I make it work
> based on framesync. Some other fixing which is also needed to make
> overlay_qsv work are put in a separate patch.
>
> v2:
> add .preinit field to initilize framesync options.
> export more options like vf_overlay.c
>
> Signed-off-by: Ruiling Song 
> ---
>  libavfilter/Makefile |   2 +-
>  libavfilter/vf_overlay_qsv.c | 213 
> ---
>  2 files changed, 78 insertions(+), 137 deletions(-)
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index a90ca30..7f2ad1f 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -267,7 +267,7 @@ OBJS-$(CONFIG_OSCILLOSCOPE_FILTER)   += 
> vf_datascope.o
>  OBJS-$(CONFIG_OVERLAY_FILTER)+= vf_overlay.o framesync.o
>  OBJS-$(CONFIG_OVERLAY_OPENCL_FILTER) += vf_overlay_opencl.o opencl.o 
> \
>  opencl/overlay.o framesync.o
> -OBJS-$(CONFIG_OVERLAY_QSV_FILTER)+= vf_overlay_qsv.o
> +OBJS-$(CONFIG_OVERLAY_QSV_FILTER)+= vf_overlay_qsv.o framesync.o
>  OBJS-$(CONFIG_OWDENOISE_FILTER)  += vf_owdenoise.o
>  OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
>  OBJS-$(CONFIG_PALETTEGEN_FILTER) += vf_palettegen.o
> diff --git a/libavfilter/vf_overlay_qsv.c b/libavfilter/vf_overlay_qsv.c
> index 6c3efdb..2087178 100644
> --- a/libavfilter/vf_overlay_qsv.c
> +++ b/libavfilter/vf_overlay_qsv.c
> @@ -36,6 +36,7 @@
>  #include "formats.h"
>  #include "video.h"
>  
> +#include "framesync.h"
>  #include "qsvvpp.h"
>  
>  #define MAIN0
> @@ -56,14 +57,10 @@ enum var_name {
>  VAR_VARS_NB
>  };
>  
> -enum EOFAction {
> -EOF_ACTION_REPEAT,
> -EOF_ACTION_ENDALL
> -};
> -
>  typedef struct QSVOverlayContext {
>  const AVClass  *class;
>  
> +FFFrameSync fs;
>  QSVVPPContext  *qsv;
>  QSVVPPParamqsv_param;
>  mfxExtVPPComposite comp_conf;
> @@ -72,10 +69,6 @@ typedef struct QSVOverlayContext {
>  char *overlay_ox, *overlay_oy, *overlay_ow, *overlay_oh;
>  uint16_t  overlay_alpha, overlay_pixel_alpha;
>  
> -enum EOFAction eof_action;  /* action to take on EOF from source */
> -
> -AVFrame *main;
> -AVFrame *over_prev, *over_next;
>  } QSVOverlayContext;
>  
>  static const char *const var_names[] = {
> @@ -90,20 +83,25 @@ static const char *const var_names[] = {
>  NULL
>  };
>  
> -static const AVOption options[] = {
> +static const AVOption overlay_qsv_options[] = {
>  { "x", "Overlay x position", OFFSET(overlay_ox), AV_OPT_TYPE_STRING, { 
> .str="0"}, 0, 255, .flags = FLAGS},
>  { "y", "Overlay y position", OFFSET(overlay_oy), AV_OPT_TYPE_STRING, { 
> .str="0"}, 0, 255, .flags = FLAGS},
>  { "w", "Overlay width",  OFFSET(overlay_ow), AV_OPT_TYPE_STRING, { 
> .str="overlay_iw"}, 0, 255, .flags = FLAGS},
>  { "h", "Overlay height", OFFSET(overlay_oh), AV_OPT_TYPE_STRING, { 
> .str="overlay_ih*w/overlay_iw"}, 0, 255, .flags = FLAGS},
>  { "alpha", "Overlay global alpha", OFFSET(overlay_alpha), 
> AV_OPT_TYPE_INT, { .i64 = 255}, 0, 255, .flags = FLAGS},
>  { "eof_action", "Action to take when encountering EOF from secondary 
> input ",
> -OFFSET(eof_action), AV_OPT_TYPE_INT, { .i64 = EOF_ACTION_REPEAT },
> -EOF_ACTION_REPEAT, EOF_ACTION_ENDALL, .flags = FLAGS, "eof_action" },
> -{ "repeat", "Repeat the previous frame.", 0, AV_OPT_TYPE_CONST, { 
> .i64 = EOF_ACTION_REPEAT }, .flags = FLAGS, "eof_action" },
> -{ "endall", "End both streams.",  0, AV_OPT_TYPE_CONST, { 
> .i64 = EOF_ACTION_ENDALL }, .flags = FLAGS, "eof_action" },
> +OFFSET(fs.opt_eof_action), AV_OPT_TYPE_INT, { .i64 = 
> EOF_ACTION_REPEAT },
> +EOF_ACTION_REPEAT, EOF_ACTION_PASS, .flags = FLAGS, "eof_action" },
> +{ "repeat", "Repeat the previous frame.",   0, AV_OPT_TYPE_CONST, { 
> .i64 = EOF_ACTION_REPEAT }, .flags = FLAGS, "eof_action" },
> +{ "endall", "End both streams.",0, AV_OPT_TYPE_CONST, { 
> .i64 = EOF_ACTION_ENDALL }, .flags = FLAGS, "eof_action" },
> +{ "pass",   "Pass through the main input.", 0, AV_OPT_TYPE_CONST, { 
> .i64 = EOF_ACTION_PASS },   .flags = FLAGS, "eof_action" },
> +{ "shortest", "force termination when the shortest input terminates", 
> OFFSET(fs.opt_shortest), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
> +{ 

Re: [FFmpeg-devel] [PATCH v2 1/2] lavf: make overlay_qsv work based on framesync

2018-04-11 Thread Song, Ruiling


> -Original Message-
> From: Li, Zhong
> Sent: Tuesday, April 10, 2018 11:39 AM
> To: FFmpeg development discussions and patches 
> Cc: Song, Ruiling 
> Subject: RE: [FFmpeg-devel] [PATCH v2 1/2] lavf: make overlay_qsv work based
> on framesync
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Ruiling Song
> > Sent: Tuesday, April 3, 2018 9:50 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Song, Ruiling 
> > Subject: [FFmpeg-devel] [PATCH v2 1/2] lavf: make overlay_qsv work based
> > on framesync
> >
> > The existing version which was cherry-picked from Libav does not work with
> > FFmpeg framework, because ff_request_frame() was totally different
> > between Libav (recursive) and FFmpeg (non-recursive).
> > The existing overlay_qsv implementation depends on the recursive version of
> > ff_request_frame to trigger immediate call to request_frame() on input pad.
> > But this has been removed in FFmpeg since "lavfi: make request_frame()
> > non-recursive."
> > Now that we have handy framesync support in FFmpeg, so I make it work
> > based on framesync. Some other fixing which is also needed to make
> > overlay_qsv work are put in a separate patch.
> >
> > v2:
> > add .preinit field to initilize framesync options.
> > export more options like vf_overlay.c
> 
> How about taking these options as a separated patch?
> It doesn't take obvious effect to make qsv overlay work.

Below are the options which I mainly mean here. Given that this is a new 
implementation,
I thought this minor change does not bring too much extra burden to the patch.
It just gives users more freedom to control the behavior of this filter.
But I am open to follow your comment if we think this is necessary to merge the 
patch.
I would like to wait if anybody else will give some comment on the overall 
patch.
Thanks for your review!

> > +{ "shortest", "force termination when the shortest input terminates",
> > OFFSET(fs.opt_shortest), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
> > +{ "repeatlast", "repeat overlay of the last overlay frame",
> > + OFFSET(fs.opt_repeatlast), AV_OPT_TYPE_BOOL, {.i64=1}, 0, 1, FLAGS },
> >  { NULL }


> >
> > -static const AVClass overlay_qsv_class = {
> > -.class_name = "overlay_qsv",
> > -.item_name  = av_default_item_name,
> > -.option = options,
> > -.version= LIBAVUTIL_VERSION_INT,
> > -};
> 
> Why remove it but keep ".priv_class"?
You can take a look at FRAMESYNC_DEFINE_CLASS macro definition. It already 
include this overlay_qsv_class definition.

> The reset LGTM.
> 

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


[FFmpeg-devel] [PATCH 1/2] avformat/utils: Fix integer overflow in end time calculation in update_stream_timings()

2018-04-11 Thread Michael Niedermayer
Fixes: crbug 829153

Reported-by: Matt Wolenetz 
Reviewed-by: Matt Wolenetz 
Signed-off-by: Michael Niedermayer 
---
 libavformat/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 3e482a3bbc..f958c073b0 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2648,7 +2648,7 @@ static void update_stream_timings(AVFormatContext *ic)
 else if (start_time > start_time_text)
 av_log(ic, AV_LOG_VERBOSE, "Ignoring outlier non primary stream 
starttime %f\n", start_time_text / (float)AV_TIME_BASE);
 
-if (end_time == INT64_MIN || (end_time < end_time_text && end_time_text - 
end_time < AV_TIME_BASE)) {
+if (end_time == INT64_MIN || (end_time < end_time_text && end_time_text - 
(uint64_t)end_time < AV_TIME_BASE)) {
 end_time = end_time_text;
 } else if (end_time < end_time_text) {
 av_log(ic, AV_LOG_VERBOSE, "Ignoring outlier non primary stream 
endtime %f\n", end_time_text / (float)AV_TIME_BASE);
-- 
2.17.0

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


[FFmpeg-devel] [PATCH 2/2] avcodec/utils: Enforce minimum width also for VP5/6

2018-04-11 Thread Michael Niedermayer
Fixes: out of array access
Fixes: poc_0411

Found-by: GwanYeong Kim 
Tested-by: GwanYeong Kim 
Signed-off-by: Michael Niedermayer 
---
 libavcodec/utils.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 8c7d056da6..59d41ccbb6 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -312,7 +312,10 @@ void avcodec_align_dimensions2(AVCodecContext *s, int 
*width, int *height,
 
 *width  = FFALIGN(*width, w_align);
 *height = FFALIGN(*height, h_align);
-if (s->codec_id == AV_CODEC_ID_H264 || s->lowres) {
+if (s->codec_id == AV_CODEC_ID_H264 || s->lowres ||
+s->codec_id == AV_CODEC_ID_VP5  || s->codec_id == AV_CODEC_ID_VP6 ||
+s->codec_id == AV_CODEC_ID_VP6F || s->codec_id == AV_CODEC_ID_VP6A
+) {
 // some of the optimized chroma MC reads one line too much
 // which is also done in mpeg decoders with lowres > 0
 *height += 2;
-- 
2.17.0

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


[FFmpeg-devel] [PATCH v2] avformat/hlsenc: add option hls_delete_threshold

2018-04-11 Thread Aman Gupta
From: Steven Liu 

When using hls_list_size with hls_flags delete_segments, currently
hls_list_size * 2 +- segments remain on disk. With this new option,
the amount of disk space used can be controlled by the user.

fix ticket: #7131

Signed-off-by: Steven Liu 
Signed-off-by: Aman Gupta 
---
 doc/muxers.texi  | 6 ++
 libavformat/hlsenc.c | 9 +
 2 files changed, 15 insertions(+)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index cb75c261c5..f288764a23 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -513,6 +513,12 @@ Segment will be cut on the next key frame after this time 
has passed.
 Set the maximum number of playlist entries. If set to 0 the list file
 will contain all the segments. Default value is 5.
 
+@item hls_delete_threshold @var{size}
+Set the number of unreferenced segments to keep on disk before @code{hls_flags 
delete_segments}
+deletes them. Increase this to allow continue clients to download segments 
which
+were recently referenced in the playlist. Default value is 1, meaning segments 
older than
+@code{hls_list_size+1} will be deleted.
+
 @item hls_ts_options @var{options_list}
 Set output format options using a :-separated list of key=value
 parameters. Values containing @code{:} special characters must be
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 8eb84212a0..1b4f84b653 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -173,6 +173,7 @@ typedef struct HLSContext {
 float time;// Set by a private option.
 float init_time;   // Set by a private option.
 int max_nb_segments;   // Set by a private option.
+int hls_delete_threshold; // Set by a private option.
 #if FF_API_HLS_WRAP
 int  wrap; // Set by a private option.
 #endif
@@ -445,6 +446,7 @@ static int hls_delete_old_segments(AVFormatContext *s, 
HLSContext *hls,
 HLSSegment *segment, *previous_segment = NULL;
 float playlist_duration = 0.0f;
 int ret = 0, path_size, sub_path_size;
+int segment_cnt = 0;
 char *dirname = NULL, *p, *sub_path;
 char *path = NULL;
 AVDictionary *options = NULL;
@@ -458,14 +460,20 @@ static int hls_delete_old_segments(AVFormatContext *s, 
HLSContext *hls,
 }
 
 segment = vs->old_segments;
+segment_cnt = 0;
 while (segment) {
 playlist_duration -= segment->duration;
 previous_segment = segment;
 segment = previous_segment->next;
+segment_cnt++;
 if (playlist_duration <= -previous_segment->duration) {
 previous_segment->next = NULL;
 break;
 }
+if (segment_cnt >= hls->hls_delete_threshold) {
+previous_segment->next = NULL;
+break;
+}
 }
 
 if (segment && !hls->use_localtime_mkdir) {
@@ -2799,6 +2807,7 @@ static const AVOption options[] = {
 {"hls_time",  "set segment length in seconds",   OFFSET(time), 
   AV_OPT_TYPE_FLOAT,  {.dbl = 2}, 0, FLT_MAX, E},
 {"hls_init_time", "set segment length in seconds at init list",   
OFFSET(init_time),AV_OPT_TYPE_FLOAT,  {.dbl = 0}, 0, FLT_MAX, E},
 {"hls_list_size", "set maximum number of playlist entries",  
OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0, INT_MAX, E},
+{"hls_delete_threshold", "set number of unreferenced segments to keep 
before deleting",  OFFSET(hls_delete_threshold),AV_OPT_TYPE_INT,{.i64 = 
1}, 1, INT_MAX, E},
 {"hls_ts_options","set hls mpegts list of options for the container format 
used for hls", OFFSET(format_options_str), AV_OPT_TYPE_STRING, {.str = NULL},  
0, 0,E},
 {"hls_vtt_options","set hls vtt list of options for the container format 
used for hls", OFFSET(vtt_format_options_str), AV_OPT_TYPE_STRING, {.str = 
NULL},  0, 0,E},
 #if FF_API_HLS_WRAP
-- 
2.14.2

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


Re: [FFmpeg-devel] [PATCH 1/4] lavf/aviobuf: add ff_get_chomp_line

2018-04-11 Thread Jun Zhao


On 2018/4/11 16:52, Marton Balint wrote:
>
>
> On Wed, 11 Apr 2018, Jun Zhao wrote:
>
>>
>>
>> On 2018/4/10 21:54, Marton Balint wrote:
>>>
>>>
>>> On Tue, 10 Apr 2018, Jun Zhao wrote:
>>>


>>>
>>> Maybe you should use ff_read_line_to_bprint instead? It already chops
>>> the trailing line endings, not any whitespace though. Generally I
>>> think we should deprecate ff_get_line, because line length limits
>>> always pop here or there...
>>>
>> ff_read_line_to_bprint usually use when we don't know the length limits
>> and need to the caller free the AVBPrint resource, in hls case, I think
>> this is a simple case, the other reason is I don't want to mix the
>> AVBPrint and c native char * in hls. Thanks.
>
> Since it's just factorization of existing code, then I guess it is OK.
Yes
>
> But new code should not use either that or ff_get_line. (MAX_URL_SIZE
> being 4096 does not even adhere to the RFC recommendation of
> supporting at least 8000 char length URLs)
I agree this part
>
> https://tools.ietf.org/html/rfc7230#section-3.1.1
I think HLS need to fix this issue when read URL. This is the other
patchset I think.
>
> Regards,
> Marton
> ___
> 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] libavformat/aac: Parse all ID3 tags present between ADTS frames

2018-04-11 Thread Michael Niedermayer
On Wed, Apr 11, 2018 at 12:42:07PM -0700, Richard Shaffer wrote:
> On Mon, Apr 9, 2018 at 1:05 AM, Mattias Amnefelt  wrote:
> 
> > On 2018-04-05 01:00, Mattias Amnefelt wrote:
> >
> >> On 2018-04-04 09:22, Mattias Amnefelt wrote:
> >>
> >>> On 2018-04-04 03:42, James Almer wrote:
> >>>
>  On 4/3/2018 10:40 PM, Carl Eugen Hoyos wrote:
> 
> > 2018-04-04 3:38 GMT+02:00, James Almer :
> >
> >> On 4/3/2018 10:33 PM, Carl Eugen Hoyos wrote:
> >>
> >>> The "-f aac" looks like a bad idea to me.
> >>> It's also true for the tests above, but that's still not reason to
> >>> add more.
> >>>
> >>> Please avoid top-posting here, Carl Eugen
> >>>
> >> At least in one of them it was added because the sample had too few
> >> frames and probing was detecting it with a score of 1, which seemed
> >> too
> >> fragile.
> >>
> > I believe that it is good to have a sample that is detected with
> > a small score as part of fate.
> >
> > Carl Eugen
> >
>  When i asked it was suggested to just force the demuxer. I have no
>  opinion one way or another, so feel free to change it.
> 
> >>> I have to admit I just copy-n-pasted the test above. I just
> >>> double-checked and all the id3 tag tests pass without -f aac now. I'm not
> >>> sure if anything has changed since the test was added or not. Do you want 
> >>> a
> >>> patch which removes it for all of them?
> >>>
> >>>
> >>> Here's an updated version of the patch without -f aac
> >>
> >> /mattiasa
> >>
> >
> > Did anyone have any options on the updated patch?
> >
> >
> > /mattiasa
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> This seems like a nice thing to have. If there are no other comments on
> Mattias' patch or test, would one of the maintainers be willing to merge it?

i dont think iam maintainer of aac/ac3 but will apply as this was laying
around for a while and is rather simple so shouldnt need that lomng for a
reply  thus it appears noone has a comment ...

thanks

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

No snowflake in an avalanche ever feels responsible. -- Voltaire


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


[FFmpeg-devel] [PATCH] lavf/http.c: Don't write chunked-transfer-trailer to listening server context.

2018-04-11 Thread Stephan Holljes
---
I found this bug while working on my qualification task. When closing
a listening HTTP AVIOContext http_shutdown() tries to write the
chunked-transfer-encoding trailer to the listening Context.

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

diff --git a/libavformat/http.c b/libavformat/http.c
index 983034f083..248fa085bf 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1623,7 +1623,7 @@ static int http_shutdown(URLContext *h, int flags)
 HTTPContext *s = h->priv_data;
 
 /* signal end of chunked encoding if used */
-if (((flags & AVIO_FLAG_WRITE) && s->chunked_post) ||
+if (((flags & AVIO_FLAG_WRITE) && s->chunked_post && !s->listen) ||
 ((flags & AVIO_FLAG_READ) && s->chunked_post && s->listen)) {
 ret = ffurl_write(s->hd, footer, sizeof(footer) - 1);
 ret = ret > 0 ? 0 : ret;
-- 
2.16.2

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


Re: [FFmpeg-devel] [PATCH v3] doc: update loglevel option documentation

2018-04-11 Thread Lou Logan
On Tue, Apr 10, 2018, at 11:11 PM, Tobias Rapp wrote:
>
> BTW: Is there some documentation on the generic flags syntax used in 
> FFmpeg for options like "-fflags" or "-cpuflags" and how to combine the 
> tokens with "+" or "-"? I couldn't find something on a quick scan.

Doesn't appear to be documented, but maybe I missed it.

On Tue, Apr 10, 2018, at 11:31 PM, Tobias Rapp wrote:
> Updates documentation after the changes to loglevel flag prefix parsing
> in 4b736bc921ed96ad6d312ce0cbe0de29b9e3fe81.
> 
> Signed-off-by: Tobias Rapp 
> ---
>  doc/fftools-common-opts.texi | 37 +
>  1 file changed, 29 insertions(+), 8 deletions(-)

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


Re: [FFmpeg-devel] [PATCH] avcodec/aac_ac3_parser: account for data already in the parsing buffer

2018-04-11 Thread Hendrik Leppkes
On Wed, Apr 11, 2018 at 8:07 PM, Carl Eugen Hoyos  wrote:
> 2018-04-11 13:40 GMT+02:00, Hendrik Leppkes :
>> If a frame starts very close to a packet boundary, the start code may
>> already have been added to the parsing buffer, indicated by a small
>> negative value of "i", while the header is still being tracked in the
>> "state" variable.
>
> Do you have a sample?
>

I do, but unless you can tell me how you can get ffmpeg to split
packets from a DVD VOB stream on a fixed arbitrary packet size (2048
bytes, iirc) to cause the issue to appear, I wouldn't know how to
reproduce it from CLI.

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


Re: [FFmpeg-devel] [PATCH v2] avcodec/mpegpicture: fix "stride changed" failures in gray mode

2018-04-11 Thread Michael Niedermayer
On Tue, Apr 10, 2018 at 03:53:36PM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> Before adding uvlinesize check, I was seeing failures decoding
> some video with ffmpeg compiled with --enable-gray and using 
> AV_CODEC_FLAG_GRAY.
> 
> [mpeg2video @ 0x7fa193818c00] get_buffer() failed (stride changed: 
> linesize=1280/1280 uvlinesize=0/640)
> [mpeg2video @ 0x7fa193818c00] get_buffer() failed (stride changed: 
> linesize=1280/1280 uvlinesize=0/640)
> ---
>  libavcodec/mpegpicture.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)

should be ok

thanks

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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


Re: [FFmpeg-devel] [PATCH] lavc/amfenc: device type AV_HWDEVICE_TYPE_DXVA2 support

2018-04-11 Thread Alexander Kravchenko
I am sorry, sending patch one more time. Outlook was wrapping text.
Sending patch in message body and in attachment

---
 libavcodec/amfenc.c | 123 +++-
 1 file changed, 102 insertions(+), 21 deletions(-)

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index b9418b6791..c1f65f909d 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -24,6 +24,9 @@
 #if CONFIG_D3D11VA
 #include "libavutil/hwcontext_d3d11va.h"
 #endif
+#if CONFIG_DXVA2
+#include "libavutil/hwcontext_dxva2.h"
+#endif
 #include "libavutil/mem.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/time.h"
@@ -50,6 +53,9 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
 AV_PIX_FMT_YUV420P,
 #if CONFIG_D3D11VA
 AV_PIX_FMT_D3D11,
+#endif
+#if CONFIG_DXVA2
+AV_PIX_FMT_DXVA2_VLD,
 #endif
 AV_PIX_FMT_NONE
 };
@@ -69,6 +75,7 @@ static const FormatMap format_map[] =
 { AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
 { AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
 { AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
+{ AV_PIX_FMT_DXVA2_VLD,  AMF_SURFACE_NV12 },
 };
 
 
@@ -152,6 +159,23 @@ static int amf_load_library(AVCodecContext *avctx)
 return 0;
 }
 
+static void get_dx9_device_from_devmgr(IDirect3DDeviceManager9 *devmgr, 
IDirect3DDevice9 **device, void *avcl)
+{
+HRESULT hr;
+HANDLE device_handle;
+
+if (SUCCEEDED(devmgr->lpVtbl->OpenDeviceHandle(devmgr, _handle))) {
+if (SUCCEEDED(devmgr->lpVtbl->LockDevice(devmgr, device_handle, 
device, FALSE))) {
+devmgr->lpVtbl->UnlockDevice(devmgr, device_handle, FALSE);
+} else {
+av_log(avcl, AV_LOG_INFO, "Failed to lock device handle for 
Direct3D9 device: %lx.\n", (unsigned long)hr);
+}
+devmgr->lpVtbl->CloseDeviceHandle(devmgr, device_handle);
+} else {
+av_log(avcl, AV_LOG_INFO, "Failed to open device handle for Direct3D9 
device: %lx.\n", (unsigned long)hr);
+}
+}
+
 static int amf_init_context(AVCodecContext *avctx)
 {
 AmfContext *ctx = avctx->priv_data;
@@ -177,34 +201,58 @@ static int amf_init_context(AVCodecContext *avctx)
 res = ctx->factory->pVtbl->CreateContext(ctx->factory, >context);
 AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "CreateContext() 
failed with error %d\n", res);
 // try to reuse existing DX device
-#if CONFIG_D3D11VA
 if (avctx->hw_frames_ctx) {
-AVHWFramesContext *device_ctx = 
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
-if (device_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA) {
-if (amf_av_to_amf_format(device_ctx->sw_format) != 
AMF_SURFACE_UNKNOWN) {
-if (device_ctx->device_ctx->hwctx) {
-AVD3D11VADeviceContext *device_d3d11 = 
(AVD3D11VADeviceContext *)device_ctx->device_ctx->hwctx;
+AVHWFramesContext *frames_ctx = 
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+if (amf_av_to_amf_format(frames_ctx->sw_format) != 
AMF_SURFACE_UNKNOWN) {
+if (frames_ctx->device_ctx->hwctx) {
+#if CONFIG_D3D11VA
+if (frames_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA) {
+AVD3D11VADeviceContext *device_d3d11 = 
(AVD3D11VADeviceContext *)frames_ctx->device_ctx->hwctx;
 res = ctx->context->pVtbl->InitDX11(ctx->context, 
device_d3d11->device, AMF_DX11_1);
 if (res == AMF_OK) {
 ctx->hw_frames_ctx = 
av_buffer_ref(avctx->hw_frames_ctx);
 if (!ctx->hw_frames_ctx) {
 return AVERROR(ENOMEM);
 }
-if (device_ctx->initial_pool_size > 0)
-ctx->hwsurfaces_in_queue_max = 
device_ctx->initial_pool_size - 1;
+if (frames_ctx->initial_pool_size > 0)
+ctx->hwsurfaces_in_queue_max = 
frames_ctx->initial_pool_size - 1;
 } else {
-if(res == AMF_NOT_SUPPORTED)
+if (res == AMF_NOT_SUPPORTED)
 av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx 
has D3D11 device which doesn't have D3D11VA interface, switching to default\n");
 else
 av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx 
has non-AMD device, switching to default\n");
 }
 }
-} else {
-av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx has format 
not uspported by AMF, switching to default\n");
+#endif
+#if CONFIG_DXVA2
+if (frames_ctx->device_ctx->type == AV_HWDEVICE_TYPE_DXVA2) {
+AVDXVA2DeviceContext *device_dxva2 = (AVDXVA2DeviceContext 
*)frames_ctx->device_ctx->hwctx;
+IDirect3DDevice9 *device_dx9 = NULL;
+get_dx9_device_from_devmgr(device_dxva2->devmgr, 
_dx9, avctx);
+  

Re: [FFmpeg-devel] [PATCH] avformat/utils: Stream specifier enhancement

2018-04-11 Thread Michael Niedermayer
On Wed, Apr 11, 2018 at 10:37:41PM +0200, Bodecs Bela wrote:
> fate test enclosed
> 
> 
> 2018.04.04. 10:39 keltezéssel, Bodecs Bela írta:
> >
> >
> >2018.04.04. 2:37 keltezéssel, Michael Niedermayer írta:
> >>On Sun, Apr 01, 2018 at 11:42:34PM +0200, Bodecs Bela wrote:
> >>>Dear All,
> >>>
> >>>currently when specifying the program id you can only decide to select
> >>>all stream of the specified program (e.g. p:103 will select all streams
> >>>of program 103) or narrow the selection to a specific stream sub index
> >>>(e.g. p:145:1 will select 2nd stream of program 145.) But you can not
> >>>specify like all audio streams of program 145 or 3rd video stream of
> >>>program 311.
> >>>In some case, mainly working with multiprogram mpeg-ts containers as
> >>>input, this feature would be handy.
> >>>This patch makes it possible to narrow the stream selection among
> >>>streams of the specified program by stream type and optionally its
> >>>index. Handled types: a, v, s, d.
> >>>Examples: p:601:a  will select all audio streams of program 601,
> >>>p:603:a:1 will select 2nd audio streams of program 603,
> >>>p:604:v:0 will select first video stream of program 604.
> >>>This syntax enhancement does not interfere in any way with
> >>>current/exiting syntax or working command lines
> >>I think this is a good idea.
> >>Can you also add fate test(s) for this ? (can be in a seperate patch
> >>later of course)
> >>
> >ok, I will try.
> >
> >bb
> >
> >>thx
> >>
> >>[...]
> >>
> >>
> >>
> >>___
> >>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
> 

>  mpegts.mak |6 ++
>  1 file changed, 6 insertions(+)
> da6c059eab100872d0f61d14e40e46012f031bfe  
> 0002-fate-to-test-program-sub-stream-selection-by-its-typ.patch
> From 093bdb47d1c5093cbd9427fbd2383a1c802464bb Mon Sep 17 00:00:00 2001
> From: Bela Bodecs 
> Date: Wed, 11 Apr 2018 22:33:02 +0200
> Subject: [PATCH] fate: to test program sub stream selection by its type in
>  mpegts
> 
> Signed-off-by: Bela Bodecs 
> ---
>  tests/fate/mpegts.mak | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tests/fate/mpegts.mak b/tests/fate/mpegts.mak
> index bb0d9d9..2b12849 100644
> --- a/tests/fate/mpegts.mak
> +++ b/tests/fate/mpegts.mak
> @@ -9,6 +9,12 @@ FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) += 
> fate-mpegts-probe-la
>  fate-mpegts-probe-latm: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
>  fate-mpegts-probe-latm: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i "$(SRC)"
>  
> +
> +FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) += 
> fate-mpegts-probe-program
> +fate-mpegts-probe-program: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
> +fate-mpegts-probe-program: CMD = run $(PROBE_CODEC_NAME_COMMAND) 
> -select_streams p:769:v:0 -i "$(SRC)"
> +
> +
>  FATE_SAMPLES_FFPROBE += $(FATE_MPEGTS_PROBE-yes)

missing reference file

reference file './tests/ref/fate/mpegts-probe-program' not found
./tests/fate-run.sh: 419: ./tests/fate-run.sh: cannot open 
tests/data/fate/mpegts-probe-program.diff: No such file
Test mpegts-probe-program failed. Look at 
tests/data/fate/mpegts-probe-program.err for details.
make: *** [fate-mpegts-probe-program] Error 1
make: *** Waiting for unfinished jobs

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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


Re: [FFmpeg-devel] [PATCH] lavc/amfenc: device type AV_HWDEVICE_TYPE_DXVA2 support

2018-04-11 Thread Alexander Kravchenko
Resending patch (mailer mangled the patch)

---
 libavcodec/amfenc.c | 123 +++-
 1 file changed, 102 insertions(+), 21 deletions(-)

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index b9418b6791..c1f65f909d 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -24,6 +24,9 @@
 #if CONFIG_D3D11VA
 #include "libavutil/hwcontext_d3d11va.h"
 #endif
+#if CONFIG_DXVA2
+#include "libavutil/hwcontext_dxva2.h"
+#endif
 #include "libavutil/mem.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/time.h"
@@ -50,6 +53,9 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
 AV_PIX_FMT_YUV420P,
 #if CONFIG_D3D11VA
 AV_PIX_FMT_D3D11,
+#endif
+#if CONFIG_DXVA2
+AV_PIX_FMT_DXVA2_VLD,
 #endif
 AV_PIX_FMT_NONE
 };
@@ -69,6 +75,7 @@ static const FormatMap format_map[] =
 { AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
 { AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
 { AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
+{ AV_PIX_FMT_DXVA2_VLD,  AMF_SURFACE_NV12 },
 };
 
 
@@ -152,6 +159,23 @@ static int amf_load_library(AVCodecContext *avctx)
 return 0;
 }
 
+static void get_dx9_device_from_devmgr(IDirect3DDeviceManager9 *devmgr, 
IDirect3DDevice9 **device, void *avcl)
+{
+HRESULT hr;
+HANDLE device_handle;
+
+if (SUCCEEDED(devmgr->lpVtbl->OpenDeviceHandle(devmgr, _handle))) {
+if (SUCCEEDED(devmgr->lpVtbl->LockDevice(devmgr, device_handle, 
device, FALSE))) {
+devmgr->lpVtbl->UnlockDevice(devmgr, device_handle, FALSE);
+} else {
+av_log(avcl, AV_LOG_INFO, "Failed to lock device handle for 
Direct3D9 device: %lx.\n", (unsigned long)hr);
+}
+devmgr->lpVtbl->CloseDeviceHandle(devmgr, device_handle);
+} else {
+av_log(avcl, AV_LOG_INFO, "Failed to open device handle for Direct3D9 
device: %lx.\n", (unsigned long)hr);
+}
+}
+
 static int amf_init_context(AVCodecContext *avctx)
 {
 AmfContext *ctx = avctx->priv_data;
@@ -177,34 +201,58 @@ static int amf_init_context(AVCodecContext *avctx)
 res = ctx->factory->pVtbl->CreateContext(ctx->factory, >context);
 AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "CreateContext() 
failed with error %d\n", res);
 // try to reuse existing DX device
-#if CONFIG_D3D11VA
 if (avctx->hw_frames_ctx) {
-AVHWFramesContext *device_ctx = 
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
-if (device_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA) {
-if (amf_av_to_amf_format(device_ctx->sw_format) != 
AMF_SURFACE_UNKNOWN) {
-if (device_ctx->device_ctx->hwctx) {
-AVD3D11VADeviceContext *device_d3d11 = 
(AVD3D11VADeviceContext *)device_ctx->device_ctx->hwctx;
+AVHWFramesContext *frames_ctx = 
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+if (amf_av_to_amf_format(frames_ctx->sw_format) != 
AMF_SURFACE_UNKNOWN) {
+if (frames_ctx->device_ctx->hwctx) {
+#if CONFIG_D3D11VA
+if (frames_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA) {
+AVD3D11VADeviceContext *device_d3d11 = 
(AVD3D11VADeviceContext *)frames_ctx->device_ctx->hwctx;
 res = ctx->context->pVtbl->InitDX11(ctx->context, 
device_d3d11->device, AMF_DX11_1);
 if (res == AMF_OK) {
 ctx->hw_frames_ctx = 
av_buffer_ref(avctx->hw_frames_ctx);
 if (!ctx->hw_frames_ctx) {
 return AVERROR(ENOMEM);
 }
-if (device_ctx->initial_pool_size > 0)
-ctx->hwsurfaces_in_queue_max = 
device_ctx->initial_pool_size - 1;
+if (frames_ctx->initial_pool_size > 0)
+ctx->hwsurfaces_in_queue_max = 
frames_ctx->initial_pool_size - 1;
 } else {
-if(res == AMF_NOT_SUPPORTED)
+if (res == AMF_NOT_SUPPORTED)
 av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx 
has D3D11 device which doesn't have D3D11VA interface,
switching to default\n");
 else
 av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx 
has non-AMD device, switching to default\n");
 }
 }
-} else {
-av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx has format 
not uspported by AMF, switching to default\n");
+#endif
+#if CONFIG_DXVA2
+if (frames_ctx->device_ctx->type == AV_HWDEVICE_TYPE_DXVA2) {
+AVDXVA2DeviceContext *device_dxva2 = (AVDXVA2DeviceContext 
*)frames_ctx->device_ctx->hwctx;
+IDirect3DDevice9 *device_dx9 = NULL;
+get_dx9_device_from_devmgr(device_dxva2->devmgr, 
_dx9, avctx);
+res = ctx->context->pVtbl->InitDX9(ctx->context, 
device_dx9);

[FFmpeg-devel] [PATCH] lavc/amfenc: device type AV_HWDEVICE_TYPE_DXVA2 support

2018-04-11 Thread Alexander Kravchenko

---
 libavcodec/amfenc.c | 123
+++-
 1 file changed, 102 insertions(+), 21 deletions(-)

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index b9418b6791..c1f65f909d 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -24,6 +24,9 @@
 #if CONFIG_D3D11VA
 #include "libavutil/hwcontext_d3d11va.h"
 #endif
+#if CONFIG_DXVA2
+#include "libavutil/hwcontext_dxva2.h"
+#endif
 #include "libavutil/mem.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/time.h"
@@ -50,6 +53,9 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
 AV_PIX_FMT_YUV420P,
 #if CONFIG_D3D11VA
 AV_PIX_FMT_D3D11,
+#endif
+#if CONFIG_DXVA2
+AV_PIX_FMT_DXVA2_VLD,
 #endif
 AV_PIX_FMT_NONE
 };
@@ -69,6 +75,7 @@ static const FormatMap format_map[] =
 { AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
 { AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
 { AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
+{ AV_PIX_FMT_DXVA2_VLD,  AMF_SURFACE_NV12 },
 };
 
 
@@ -152,6 +159,23 @@ static int amf_load_library(AVCodecContext *avctx)
 return 0;
 }
 
+static void get_dx9_device_from_devmgr(IDirect3DDeviceManager9 *devmgr,
IDirect3DDevice9 **device, void *avcl)
+{
+HRESULT hr;
+HANDLE device_handle;
+
+if (SUCCEEDED(devmgr->lpVtbl->OpenDeviceHandle(devmgr,
_handle))) {
+if (SUCCEEDED(devmgr->lpVtbl->LockDevice(devmgr, device_handle,
device, FALSE))) {
+devmgr->lpVtbl->UnlockDevice(devmgr, device_handle, FALSE);
+} else {
+av_log(avcl, AV_LOG_INFO, "Failed to lock device handle for
Direct3D9 device: %lx.\n", (unsigned long)hr);
+}
+devmgr->lpVtbl->CloseDeviceHandle(devmgr, device_handle);
+} else {
+av_log(avcl, AV_LOG_INFO, "Failed to open device handle for
Direct3D9 device: %lx.\n", (unsigned long)hr);
+}
+}
+
 static int amf_init_context(AVCodecContext *avctx)
 {
 AmfContext *ctx = avctx->priv_data;
@@ -177,34 +201,58 @@ static int amf_init_context(AVCodecContext *avctx)
 res = ctx->factory->pVtbl->CreateContext(ctx->factory, >context);
 AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN,
"CreateContext() failed with error %d\n", res);
 // try to reuse existing DX device
-#if CONFIG_D3D11VA
 if (avctx->hw_frames_ctx) {
-AVHWFramesContext *device_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
-if (device_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA) {
-if (amf_av_to_amf_format(device_ctx->sw_format) !=
AMF_SURFACE_UNKNOWN) {
-if (device_ctx->device_ctx->hwctx) {
-AVD3D11VADeviceContext *device_d3d11 =
(AVD3D11VADeviceContext *)device_ctx->device_ctx->hwctx;
+AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+if (amf_av_to_amf_format(frames_ctx->sw_format) !=
AMF_SURFACE_UNKNOWN) {
+if (frames_ctx->device_ctx->hwctx) {
+#if CONFIG_D3D11VA
+if (frames_ctx->device_ctx->type ==
AV_HWDEVICE_TYPE_D3D11VA) {
+AVD3D11VADeviceContext *device_d3d11 =
(AVD3D11VADeviceContext *)frames_ctx->device_ctx->hwctx;
 res = ctx->context->pVtbl->InitDX11(ctx->context,
device_d3d11->device, AMF_DX11_1);
 if (res == AMF_OK) {
 ctx->hw_frames_ctx =
av_buffer_ref(avctx->hw_frames_ctx);
 if (!ctx->hw_frames_ctx) {
 return AVERROR(ENOMEM);
 }
-if (device_ctx->initial_pool_size > 0)
-ctx->hwsurfaces_in_queue_max =
device_ctx->initial_pool_size - 1;
+if (frames_ctx->initial_pool_size > 0)
+ctx->hwsurfaces_in_queue_max =
frames_ctx->initial_pool_size - 1;
 } else {
-if(res == AMF_NOT_SUPPORTED)
+if (res == AMF_NOT_SUPPORTED)
 av_log(avctx, AV_LOG_INFO,
"avctx->hw_frames_ctx has D3D11 device which doesn't have D3D11VA interface,
switching to default\n");
 else
 av_log(avctx, AV_LOG_INFO,
"avctx->hw_frames_ctx has non-AMD device, switching to default\n");
 }
 }
-} else {
-av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx has format
not uspported by AMF, switching to default\n");
+#endif
+#if CONFIG_DXVA2
+if (frames_ctx->device_ctx->type == AV_HWDEVICE_TYPE_DXVA2)
{
+AVDXVA2DeviceContext *device_dxva2 =
(AVDXVA2DeviceContext *)frames_ctx->device_ctx->hwctx;
+IDirect3DDevice9 *device_dx9 = NULL;
+get_dx9_device_from_devmgr(device_dxva2->devmgr,
_dx9, avctx);
+res = ctx->context->pVtbl->InitDX9(ctx->context,
device_dx9);
+device_dx9->lpVtbl->Release(device_dx9);
+ 

Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding

2018-04-11 Thread Michael Niedermayer
On Wed, Apr 11, 2018 at 11:44:47AM +0200, Jerome Martinez wrote:
> On 11/04/2018 00:16, Lou Logan wrote:
> >On Tue, Apr 10, 2018, at 2:05 PM, Michael Niedermayer wrote:
> >>what do you mean by "Git and me are not good friends" ?
> >>If git hates you and sometimes does things that you didnt intend at all then
> >>that would be a problem with direct pushes as theres no way to undo.
> >>But maybe i misunderstand.
> 
> 
> Yes, that's right :), I think you also remarked that I am an expert of
> careless mistakes :(.
> I am still at the bottom of the Git learning curve, being more used to the
> GitHub PR things (which IMO avoids well to do a mess with upstream repo).
> Additionally, I think that it does not worth it to take risks (including the
> risk of compromised machine) about giving me write rights with the only few
> patches I send. It would be another story if I become more active on FFmpeg
> code in the future.
> 
> >>
> >>Also to get git write access, post a patch that adds yourself to the
> >>MAINTAINERs file. When noone objects then ill add your key and apply
> >>the MAINTAINER patch.
> >Also, if you're uncomfortable pushing to the repository that's fine too. It 
> >is not a problem, but you may have to prod and remind us, perhaps a few 
> >times (or more), to push stuff.
> 
> I kindly request a maintainer to push one (the latest one?) of the DPX

will apply

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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


Re: [FFmpeg-devel] [PATCH] avformat/utils: Stream specifier enhancement

2018-04-11 Thread Bodecs Bela

fate test enclosed


2018.04.04. 10:39 keltezéssel, Bodecs Bela írta:



2018.04.04. 2:37 keltezéssel, Michael Niedermayer írta:

On Sun, Apr 01, 2018 at 11:42:34PM +0200, Bodecs Bela wrote:

Dear All,

currently when specifying the program id you can only decide to select
all stream of the specified program (e.g. p:103 will select all streams
of program 103) or narrow the selection to a specific stream sub index
(e.g. p:145:1 will select 2nd stream of program 145.) But you can not
specify like all audio streams of program 145 or 3rd video stream of
program 311.
In some case, mainly working with multiprogram mpeg-ts containers as
input, this feature would be handy.
This patch makes it possible to narrow the stream selection among
streams of the specified program by stream type and optionally its
index. Handled types: a, v, s, d.
Examples: p:601:a  will select all audio streams of program 601,
p:603:a:1 will select 2nd audio streams of program 603,
p:604:v:0 will select first video stream of program 604.
This syntax enhancement does not interfere in any way with
current/exiting syntax or working command lines

I think this is a good idea.
Can you also add fate test(s) for this ? (can be in a seperate patch
later of course)


ok, I will try.

bb


thx

[...]



___
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


From 093bdb47d1c5093cbd9427fbd2383a1c802464bb Mon Sep 17 00:00:00 2001
From: Bela Bodecs 
Date: Wed, 11 Apr 2018 22:33:02 +0200
Subject: [PATCH] fate: to test program sub stream selection by its type in
 mpegts

Signed-off-by: Bela Bodecs 
---
 tests/fate/mpegts.mak | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tests/fate/mpegts.mak b/tests/fate/mpegts.mak
index bb0d9d9..2b12849 100644
--- a/tests/fate/mpegts.mak
+++ b/tests/fate/mpegts.mak
@@ -9,6 +9,12 @@ FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) += 
fate-mpegts-probe-la
 fate-mpegts-probe-latm: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
 fate-mpegts-probe-latm: CMD = run $(PROBE_CODEC_NAME_COMMAND) -i "$(SRC)"
 
+
+FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) += 
fate-mpegts-probe-program
+fate-mpegts-probe-program: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
+fate-mpegts-probe-program: CMD = run $(PROBE_CODEC_NAME_COMMAND) 
-select_streams p:769:v:0 -i "$(SRC)"
+
+
 FATE_SAMPLES_FFPROBE += $(FATE_MPEGTS_PROBE-yes)
 
 fate-mpegts: $(FATE_MPEGTS_PROBE-yes)
-- 
2.5.3.windows.1

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


Re: [FFmpeg-devel] [PATCH] libavformat/aac: Parse all ID3 tags present between ADTS frames

2018-04-11 Thread Richard Shaffer
On Mon, Apr 9, 2018 at 1:05 AM, Mattias Amnefelt  wrote:

> On 2018-04-05 01:00, Mattias Amnefelt wrote:
>
>> On 2018-04-04 09:22, Mattias Amnefelt wrote:
>>
>>> On 2018-04-04 03:42, James Almer wrote:
>>>
 On 4/3/2018 10:40 PM, Carl Eugen Hoyos wrote:

> 2018-04-04 3:38 GMT+02:00, James Almer :
>
>> On 4/3/2018 10:33 PM, Carl Eugen Hoyos wrote:
>>
>>> The "-f aac" looks like a bad idea to me.
>>> It's also true for the tests above, but that's still not reason to
>>> add more.
>>>
>>> Please avoid top-posting here, Carl Eugen
>>>
>> At least in one of them it was added because the sample had too few
>> frames and probing was detecting it with a score of 1, which seemed
>> too
>> fragile.
>>
> I believe that it is good to have a sample that is detected with
> a small score as part of fate.
>
> Carl Eugen
>
 When i asked it was suggested to just force the demuxer. I have no
 opinion one way or another, so feel free to change it.

>>> I have to admit I just copy-n-pasted the test above. I just
>>> double-checked and all the id3 tag tests pass without -f aac now. I'm not
>>> sure if anything has changed since the test was added or not. Do you want a
>>> patch which removes it for all of them?
>>>
>>>
>>> Here's an updated version of the patch without -f aac
>>
>> /mattiasa
>>
>
> Did anyone have any options on the updated patch?
>
>
> /mattiasa
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

This seems like a nice thing to have. If there are no other comments on
Mattias' patch or test, would one of the maintainers be willing to merge it?

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


Re: [FFmpeg-devel] [PATCH v3 01/11] avformat/dashenc: replacing 'min_seg_duration' with 'seg_duration'

2018-04-11 Thread Carl Eugen Hoyos
2018-04-11 9:00 GMT+02:00, vdi...@akamai.com :

> +#if FF_API_DASH_MIN_SEG_DURATION
> +{ "min_seg_duration", "minimum segment duration (in microseconds) (will
> be deprecated)"

"is deprecated"
But since this is a user option added after the last release, you
may also choose to simply delete it if this simplifies the code.

Otoh: Your commit message is missing an explanation why
renaming this option is a good idea.

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


Re: [FFmpeg-devel] [PATCH v1 1/2] codec: vrawdepay: add decoder for RFC4175

2018-04-11 Thread Carl Eugen Hoyos
2017-02-22 22:33 GMT+01:00, Rostislav Pehlivanov :
> On 22 February 2017 at 20:18, Damien Riegel <
> damien.rie...@savoirfairelinux.com> wrote:
>
>> On Fri, Feb 17, 2017 at 03:01:05PM -0500, Damien Riegel wrote:
>> > Hi,
>> >
>> > On Thu, Feb 16, 2017 at 06:19:00PM +, Rostislav Pehlivanov wrote:
>> > > >
>> > > > No, do this in libavfilter and do not introduce another useless
>> pseudo
>> > > > codec
>> > > >
>> > >
>> > > *libavformat, sorry
>> >
>> > The advantage of using a pseudo codec just to depack the stream is that
>> > the input and the codec are in separate threads in ffmpeg, so it can
>> > handle a heavier workload.
>>
>> Please find attached a v2, with the implementation in libavformat. Note
>> that I don't want to send it as a patch of its own because the
>> performance issue is not addressed.
>>
>> Basically, our test case is a raw input stream YUV 4:2:2 10 bits 1080p
>> at 60fps. With the pseudo-codec, we are able to transcode it to h264 and
>> dump it to a file. With unpacking done in the libavformat, the input
>> thread gets too busy and can't stand the load.
>>
>> In the implementation you made [1] unpacking was done in libavcodec, so
>> why is it not an acceptable solution for mainline?
>>
>>
> I now think it was ok to have a custom codec format because V210 is
> implemented in such a way in lavc.

(Since every time I stumble over "bitpacked" I wonder where this
came from...)

V210 exists in several multimedia containers, so adding a codec
was unavoidable.
I don't think this is true for bitpacked, or is it?

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


Re: [FFmpeg-devel] [PATCH] avcodec/aac_ac3_parser: account for data already in the parsing buffer

2018-04-11 Thread Carl Eugen Hoyos
2018-04-11 13:40 GMT+02:00, Hendrik Leppkes :
> If a frame starts very close to a packet boundary, the start code may
> already have been added to the parsing buffer, indicated by a small
> negative value of "i", while the header is still being tracked in the
> "state" variable.

Do you have a sample?

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


Re: [FFmpeg-devel] [PATCH 3/3] avformat/movenc: support writing iTunes cover image

2018-04-11 Thread Timo Teras
On Wed, 11 Apr 2018 14:25:15 +0100
Rostislav Pehlivanov  wrote:

> On 11 April 2018 at 06:22, Timo Teräs  wrote:
> 
> > Ping.
> >
> > Any comments on this?
> >
> > There was also recently the flacenc support for cover images, and
> > the question if some of this code should be moved to generic code
> > in mux.c so both can share it: e.g. storing the image packets to
> > attached_pic - or if that should be moved to the muxer private
> > structs.
>
> I think this could be done at a later stage as well, but if you or
> jamrial think it can be reused, sure, go ahead and submit a separate
> patch which puts it in some common code.

I agree that it might be easier done later. This way we get the commits
in with proper authors and have common code base to work on. Producing
a suitable framework interface might need additional discussions too.

Would there be other concerns or comments for my patch then, or could
it be considered to be committed?

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


Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself to documentation section

2018-04-11 Thread Lou Logan
On Wed, Apr 11, 2018, at 8:23 AM, Gyan Doshi wrote:
> As suggested by Lou Logan, this patch adds myself as a docs maintainer.

I suggested this because the documentation can always use more improvements, we 
need more active documentation maintainers, and he has previously shown 
interest in this. (I am referring to the cli tool docs.) Gyan has shown to be 
quite proficient with the cli tools, knows how to help users, and is becoming 
more familiar with the code. I believe he has sent enough patches to understand 
our workflow.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] MAINTAINERS: add myself to documentation section

2018-04-11 Thread Gyan Doshi

As suggested by Lou Logan, this patch adds myself as a docs maintainer.

Thanks,
Gyan
From b18cb5bfb7c8df130892f9ec9552287edac2b17a Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Wed, 11 Apr 2018 21:46:03 +0530
Subject: [PATCH] MAINTAINERS: add myself to documentation section

---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5c7bf4726f..b61856243c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -39,7 +39,7 @@ QuickTime faststart:
 Miscellaneous Areas
 ===
 
-documentation   Stefano Sabatini, Mike Melanson, 
Timothy Gu, Lou Logan
+documentation   Stefano Sabatini, Mike Melanson, 
Timothy Gu, Lou Logan, Gyan Doshi
 project server  Árpád Gereöffy, Michael Niedermayer, 
Reimar Doeffinger, Alexander Strasser, Nikolay Aleksandrov
 presets Robert Swain
 metadata subsystem  Aurelien Jacobs
-- 
2.12.2.windows.2___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/hevc: export chroma sample location

2018-04-11 Thread James Almer
On 4/11/2018 8:46 AM, Hendrik Leppkes wrote:
> ---
>  libavcodec/hevcdec.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index c8877626d2..e8227a510b 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -344,6 +344,17 @@ static void export_stream_params(AVCodecContext *avctx, 
> const HEVCParamSets *ps,
>  avctx->colorspace  = AVCOL_SPC_UNSPECIFIED;
>  }
>  
> +if (sps->chroma_format_idc == 1) {
> +if (sps->vui.chroma_loc_info_present_flag) {
> +if (sps->vui.chroma_sample_loc_type_top_field <= 5)
> +avctx->chroma_sample_location = 
> sps->vui.chroma_sample_loc_type_top_field + 1;
> +else
> +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
> +} else
> +avctx->chroma_sample_location = AVCHROMA_LOC_LEFT;
> +} else
> +avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
> +

Nit: It's probably cleaner to set it to AVCHROMA_LOC_UNSPECIFIED right
before doing thsee bitstream checks, instead of duplicating the else case.

>  if (vps->vps_timing_info_present_flag) {
>  num = vps->vps_num_units_in_tick;
>  den = vps->vps_time_scale;
> 

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


Re: [FFmpeg-devel] [PATCH] avcodec/nvdec_hevc: add support for new extended sps/pps flags from SDK 8.1

2018-04-11 Thread Philip Langdale
On Wed, 11 Apr 2018 13:48:59 +0200
t...@rothenpieler.org wrote:

> From: Timo Rothenpieler 
> 
> ---
>  libavcodec/hevc_ps.c| 5 ++---
>  libavcodec/hevc_ps.h| 1 +
>  libavcodec/nvdec_hevc.c | 6 ++
>  3 files changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index 1f18d0335b..f877fa572c 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -1100,7 +1100,6 @@ int ff_hevc_parse_sps(HEVCSPS *sps,
> GetBitContext *gb, unsigned int *sps_id, skip_bits(gb,
> 7); //sps_extension_7bits = get_bits(gb, 7); if
> (sps_extension_flag[0]) { int extended_precision_processing_flag;
> -int high_precision_offsets_enabled_flag;
>  int cabac_bypass_alignment_enabled_flag;
>  
>  sps->transform_skip_rotation_enabled_flag =
> get_bits1(gb); @@ -1115,8 +1114,8 @@ int ff_hevc_parse_sps(HEVCSPS
> *sps, GetBitContext *gb, unsigned int *sps_id,
> "extended_precision_processing_flag not yet implemented\n"); 
>  sps->intra_smoothing_disabled_flag   = get_bits1(gb);
> -high_precision_offsets_enabled_flag  = get_bits1(gb);
> -if (high_precision_offsets_enabled_flag)
> +sps->high_precision_offsets_enabled_flag = get_bits1(gb);
> +if (sps->high_precision_offsets_enabled_flag)
>  av_log(avctx, AV_LOG_WARNING,
> "high_precision_offsets_enabled_flag not yet
> implemented\n"); 
> diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
> index 9873754389..1fbda199e3 100644
> --- a/libavcodec/hevc_ps.h
> +++ b/libavcodec/hevc_ps.h
> @@ -289,6 +289,7 @@ typedef struct HEVCSPS {
>  int implicit_rdpcm_enabled_flag;
>  int explicit_rdpcm_enabled_flag;
>  int intra_smoothing_disabled_flag;
> +int high_precision_offsets_enabled_flag;
>  int persistent_rice_adaptation_enabled_flag;
>  
>  ///< coded frame dimension in various units
> diff --git a/libavcodec/nvdec_hevc.c b/libavcodec/nvdec_hevc.c
> index 58f3fa9b45..ba54d210e8 100644
> --- a/libavcodec/nvdec_hevc.c
> +++ b/libavcodec/nvdec_hevc.c
> @@ -107,6 +107,12 @@ static int nvdec_hevc_start_frame(AVCodecContext
> *avctx, .log2_diff_max_min_pcm_luma_coding_block_size =
> sps->pcm.log2_max_pcm_cb_size -
> sps->pcm.log2_min_pcm_cb_size, .pcm_sample_bit_depth_luma_minus1
> = sps->pcm_enabled_flag ? sps->pcm.bit_depth - 1 :
> 0, .pcm_sample_bit_depth_chroma_minus1   =
> sps->pcm_enabled_flag ? sps->pcm.bit_depth_chroma - 1 : 0, +#if
> defined(NVDECAPI_VERSION) && NVDECAPI_VERSION >= 0x0108
> +.log2_max_transform_skip_block_size_minus2=
> pps->log2_max_transform_skip_block_size - 2,
> +.log2_sao_offset_scale_luma   =
> pps->log2_sao_offset_scale_luma,
> +.log2_sao_offset_scale_chroma =
> pps->log2_sao_offset_scale_chroma,
> +.high_precision_offsets_enabled_flag  =
> sps->high_precision_offsets_enabled_flag, +#endif
>  .pcm_loop_filter_disabled_flag=
> sps->pcm.loop_filter_disable_flag, .strong_intra_smoothing_enabled_flag
> =
> sps->sps_strong_intra_smoothing_enable_flag, 
> .max_transform_hierarchy_depth_intra
> = sps->max_transform_hierarchy_depth_intra,

LGTM.


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


Re: [FFmpeg-devel] [PATCH 2/2] avcodec/vp9: add profile 2 10-bit DXVA2/D3D11 decoding support

2018-04-11 Thread James Almer
On 4/11/2018 9:06 AM, Hendrik Leppkes wrote:
> ---
>  libavcodec/vp9.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index 0fac638ec9..b1178c9c0c 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -188,6 +188,7 @@ static int update_size(AVCodecContext *avctx, int w, int 
> h)
>  
>  switch (s->pix_fmt) {
>  case AV_PIX_FMT_YUV420P:
> +case AV_PIX_FMT_YUV420P10:
>  #if CONFIG_VP9_DXVA2_HWACCEL
>  *fmtp++ = AV_PIX_FMT_DXVA2_VLD;
>  #endif
> @@ -202,7 +203,6 @@ static int update_size(AVCodecContext *avctx, int w, int 
> h)
>  *fmtp++ = AV_PIX_FMT_VAAPI;
>  #endif
>  break;
> -case AV_PIX_FMT_YUV420P10:
>  case AV_PIX_FMT_YUV420P12:
>  #if CONFIG_VP9_NVDEC_HWACCEL
>  *fmtp++ = AV_PIX_FMT_CUDA;
> 

Make sure to mention ticket #7099 in the commit message.

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


Re: [FFmpeg-devel] [PATCH 1/3] avcodec: add siren audio decoder

2018-04-11 Thread Rostislav Pehlivanov
On 4 April 2018 at 15:09, Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   8 +
>  libavcodec/siren.c  | 847 ++
> ++
>  5 files changed, 858 insertions(+)
>  create mode 100644 libavcodec/siren.c
>

You should wait until I submit my patch for even FFTs and MDCTs in lavu
before resubmitting. Sorry I'm holding it back.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 3/3] avformat/movenc: support writing iTunes cover image

2018-04-11 Thread Rostislav Pehlivanov
On 11 April 2018 at 06:22, Timo Teräs  wrote:

> Ping.
>
> Any comments on this?
>
> There was also recently the flacenc support for cover images, and the
> question if some of this code should be moved to generic code in mux.c so
> both can share it: e.g. storing the image packets to attached_pic - or if
> that should be moved to the muxer private structs.
>
>
I think this could be done at a later stage as well, but if you or jamrial
think it can be reused, sure, go ahead and submit a separate patch which
puts it in some common code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avcodec/mediacodecdec_common: make stride and slice-height non-mandatory fields

2018-04-11 Thread Matthieu Bouron
Fixes decoding on the Samsung Chromebook Pro which do not set the codec
output format stride and slice-height fields.
---
 libavcodec/mediacodecdec_common.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/mediacodecdec_common.c 
b/libavcodec/mediacodecdec_common.c
index e31adb487c..e59cf19aad 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@@ -385,10 +385,10 @@ static int mediacodec_dec_parse_format(AVCodecContext 
*avctx, MediaCodecDecConte
 AMEDIAFORMAT_GET_INT32(s->width,  "width", 1);
 AMEDIAFORMAT_GET_INT32(s->height, "height", 1);
 
-AMEDIAFORMAT_GET_INT32(s->stride, "stride", 1);
+AMEDIAFORMAT_GET_INT32(s->stride, "stride", 0);
 s->stride = s->stride > 0 ? s->stride : s->width;
 
-AMEDIAFORMAT_GET_INT32(s->slice_height, "slice-height", 1);
+AMEDIAFORMAT_GET_INT32(s->slice_height, "slice-height", 0);
 s->slice_height = s->slice_height > 0 ? s->slice_height : s->height;
 
 if (strstr(s->codec_name, "OMX.Nvidia.")) {
-- 
2.17.0

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


Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.

2018-04-11 Thread Rostislav Pehlivanov
On 28 March 2018 at 22:59, Drew Allen 
wrote:

> Hello all,
>
> My name is Andrew Allen and I'm a contributor to Opus, supporting new
> channel mappings 2 and 3 for ambisonics compression. I've attached a patch
> to support the new OpusProjectionEncoder and OpusProjectionDecoder APIs for
> handling the new channel mapping 3 in OPUS.
>
> Please let me know of any changes I should make or if there are any
> questions I can help answer.
>
> Cheers,
> Drew
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
You don't set the channel layout to anything. We have support for some
ambisonics formats. Use them. How else would users know what is what? Check
the number of channels?
Also what about mapping families 240(?) -> 254?
I thought they were reserved for ambisonics (very recently too, though they
don't define any specific layouts :/).

IMO this might need a new channel layout API with support for ambisonics
because things are messy there as-is.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v1 2/3] avcodec/bitpacked: add interlace support

2018-04-11 Thread Rostislav Pehlivanov
On 10 April 2018 at 22:21, Patrick Keroulas <
patrick.kerou...@savoirfairelinux.com> wrote:

> From: Damien Riegel 
>
> This codec is already capable of depacking some combinations of pixel
> formats and depth as defined in the RFC4175. The only difference between
> progressive and interlace is that either a packet will contain the whole
> frame, or only a field of the frame.
>
> As FFmpeg is not capable of handling fields only and recompose an
> interlaced frame from that, it has to be done by the codec. To achieve
> that, it must use two AVPacket: one for each field (top and bottom).
>
> Signed-off-by: Damien Riegel 
> Signed-off-by: Patrick Keroulas 
> ---
>  libavcodec/avcodec.h   |  4 +++
>  libavcodec/bitpacked.c | 76 ++
> 
>  2 files changed, 68 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index fb0c6fa..350e8d9 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1480,6 +1480,10 @@ typedef struct AVPacket {
>   */
>  #define AV_PKT_FLAG_DISPOSABLE 0x0010
>
> +/**
> + * The packet contains a top field.
> + */
> +#define AV_PKT_FLAG_TOP_FIELD  0x0010
>
>  enum AVSideDataParamChangeFlags {
>  AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT  = 0x0001,
> diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
> index 85d4bdd..d81703d 100644
> --- a/libavcodec/bitpacked.c
> +++ b/libavcodec/bitpacked.c
> @@ -33,15 +33,19 @@
>
>  struct BitpackedContext {
>  int (*decode)(AVCodecContext *avctx, AVFrame *frame,
> -  AVPacket *pkt);
> +  AVPacket *pkt, int top_field);
> +AVPacket *first_field_pkt;
>  };
>
>  /* For this format, it's a simple passthrough */
>  static int bitpacked_decode_uyvy422(AVCodecContext *avctx, AVFrame
> *frame,
> -AVPacket *avpkt)
> +AVPacket *avpkt, int top_field)
>  {
>  int ret;
>
> +if (frame->interlaced_frame)
> +return AVERROR_PATCHWELCOME;
> +
>  /* there is no need to copy as the data already match
>   * a known pixel format */
>  frame->buf[0] = av_buffer_ref(avpkt->buf);
> @@ -56,17 +60,22 @@ static int bitpacked_decode_uyvy422(AVCodecContext
> *avctx, AVFrame *frame,
>  }
>
>  static int bitpacked_decode_yuv422p10(AVCodecContext *avctx, AVFrame
> *frame,
> -  AVPacket *avpkt)
> +  AVPacket *avpkt, int top_field)
>  {
>  uint64_t frame_size = (uint64_t)avctx->width *
> (uint64_t)avctx->height * 20;
>  uint64_t packet_size = (uint64_t)avpkt->size * 8;
> +int interlaced = frame->interlaced_frame;
>  GetBitContext bc;
>  uint16_t *y, *u, *v;
>  int ret, i, j;
>
> -
> -if (frame_size > packet_size)
> +/* check packet size depending on the interlaced/progressive format */
> +if (interlaced) {
> +if ((frame_size >> 1) > packet_size)
> +return AVERROR_INVALIDDATA;
> +} else if (frame_size > packet_size) {
>  return AVERROR_INVALIDDATA;
> +}
>
>  if (avctx->width % 2)
>  return AVERROR_PATCHWELCOME;
> @@ -75,7 +84,18 @@ static int bitpacked_decode_yuv422p10(AVCodecContext
> *avctx, AVFrame *frame,
>  if (ret)
>  return ret;
>
> -for (i = 0; i < avctx->height; i++) {
> +/*
> + * if the frame is interlaced, the avpkt we are getting is either the
> top
> + * or the bottom field. If it's the bottom field, it contains all the
> odd
> + * lines of the recomposed frame, so we start at offset 1.
> + */
> +i = (interlaced && !top_field) ? 1 : 0;
> +
> +/*
> + * Packets from interlaced frames contain either even lines, or odd
> + * lines, so increment by two in that case.
> + */
> +for (; i < avctx->height; interlaced ? i += 2 : i++) {
>  y = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
>  u = (uint16_t*)(frame->data[1] + i * frame->linesize[1]);
>  v = (uint16_t*)(frame->data[2] + i * frame->linesize[2]);
> @@ -100,13 +120,20 @@ static av_cold int bitpacked_init_decoder(AVCodecContext
> *avctx)
>
>  if (avctx->codec_tag == MKTAG('U', 'Y', 'V', 'Y')) {
>  if (avctx->bits_per_coded_sample == 16 &&
> -avctx->pix_fmt == AV_PIX_FMT_UYVY422)
> +avctx->pix_fmt == AV_PIX_FMT_UYVY422) {
> +
> +if (avctx->field_order > AV_FIELD_PROGRESSIVE) {
> +av_log(avctx, AV_LOG_ERROR, "interlaced not yet supported
> for 8-bit\n");
> +return AVERROR_PATCHWELCOME;
> +}
> +
>  bc->decode = bitpacked_decode_uyvy422;
> -else if (avctx->bits_per_coded_sample == 20 &&
> - avctx->pix_fmt == AV_PIX_FMT_YUV422P10)
> +} else if (avctx->bits_per_coded_sample == 20 &&
> +

Re: [FFmpeg-devel] [PATCH v1 1/3] avcodec/bitpacked: move ff_get_buffer

2018-04-11 Thread Rostislav Pehlivanov
On 10 April 2018 at 22:21, Patrick Keroulas <
patrick.kerou...@savoirfairelinux.com> wrote:

> From: Damien Riegel 
>
> ff_get_buffer is used to allocate a buffer to hold frame's content. This
> function was called in the function in charge of decoding an AVPacket
> containing raw video with the yuv422 pixel format and a depth of 10-bit.
>
> RFC4175 supports both progressive and interlaced mode. But the
> interlaced mode doesn't consist of interlaced frames, only of fields.
> FFmpeg cannot handle fields on their own, so the codec has to recreate
> interlaced frames based on two consecutive fields.
>
> As the function `bitpacked_decode_yuv422p10` will need to be called
> twice to do that, it cannot be in charge of the buffer allocation, so
> move it into its caller.
>
> Signed-off-by: Damien Riegel 
> ---
>  libavcodec/bitpacked.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
> index f0b417d..85d4bdd 100644
> --- a/libavcodec/bitpacked.c
> +++ b/libavcodec/bitpacked.c
> @@ -64,9 +64,6 @@ static int bitpacked_decode_yuv422p10(AVCodecContext
> *avctx, AVFrame *frame,
>  uint16_t *y, *u, *v;
>  int ret, i, j;
>
> -ret = ff_get_buffer(avctx, frame, 0);
> -if (ret < 0)
> -return ret;
>
>  if (frame_size > packet_size)
>  return AVERROR_INVALIDDATA;
> @@ -128,6 +125,12 @@ static int bitpacked_decode(AVCodecContext *avctx,
> void *data, int *got_frame,
>  frame->pict_type = AV_PICTURE_TYPE_I;
>  frame->key_frame = 1;
>
> +if (avctx->pix_fmt == AV_PIX_FMT_YUV422P10) {
> +res = ff_get_buffer(avctx, frame, 0);
> +if (res < 0)
> +return res;
> +}
> +
>  res = bc->decode(avctx, frame, avpkt);
>  if (res)
>  return res;
> --
> 2.7.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

LGTM, will apply once your interlaced patch is okay.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v1 3/3] avformat/rtpdec_rfc4175: handle interlace format

2018-04-11 Thread Rostislav Pehlivanov
On 10 April 2018 at 22:21, Patrick Keroulas <
patrick.kerou...@savoirfairelinux.com> wrote:

> From: Damien Riegel 
>
> In order to handle the interlaced formats, the demuxer has only a few
> things to do:
>  - parse the SDP correctly and propagate the information
>  - check the field bit in the RFC4175 header, and pass that information
>to the decoder
>
> In interlaced mode, received data only consist of fields, and their
> heights are half of the frame size, so some adjustments must be done
> here and there to take that into account.
>
> Signed-off-by: Damien Riegel 
> ---
>  libavformat/rtpdec_rfc4175.c | 23 +--
>  1 file changed, 21 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
> index e9c62c1..55a36eb 100644
> --- a/libavformat/rtpdec_rfc4175.c
> +++ b/libavformat/rtpdec_rfc4175.c
> @@ -31,6 +31,8 @@ struct PayloadContext {
>  int depth;
>  int width;
>  int height;
> +int interlaced;
> +int field;
>
>  uint8_t *frame;
>  unsigned int frame_size;
> @@ -65,10 +67,18 @@ static int rfc4175_parse_format(AVStream *stream,
> PayloadContext *data)
>  return AVERROR_INVALIDDATA;
>  }
>
> +if (data->interlaced)
> +stream->codecpar->field_order = AV_FIELD_TT;
> +else
> +stream->codecpar->field_order = AV_FIELD_PROGRESSIVE;
> +
>  stream->codecpar->format = pixfmt;
>  stream->codecpar->codec_tag = tag;
>  stream->codecpar->bits_per_coded_sample = bits_per_sample;
> -data->frame_size = data->width * data->height * data->pgroup /
> data->xinc;
> +if (data->interlaced)
> +data->frame_size = data->width * (data->height / 2) *
> data->pgroup / data->xinc;
> +else
> +data->frame_size = data->width * data->height * data->pgroup /
> data->xinc;
>
>  return 0;
>  }
> @@ -85,6 +95,8 @@ static int rfc4175_parse_fmtp(AVFormatContext *s,
> AVStream *stream,
>  data->sampling = av_strdup(value);
>  else if (!strncmp(attr, "depth", 5))
>  data->depth = atoi(value);
> +else if (!strncmp(attr, "interlace", 9))
> +data->interlaced = 1;
>
>  return 0;
>  }
> @@ -131,7 +143,11 @@ static int rfc4175_finalize_packet(PayloadContext
> *data, AVPacket *pkt,
> av_freep(>frame);
> }
>
> +   /* In the packet header, the field is set to 0 for top field
> +* and 1 for bottom */
> +   pkt->flags |= data->field ? 0 : AV_PKT_FLAG_TOP_FIELD;
> data->frame = NULL;
> +   data->field = 0;
>
> return ret;
>  }
> @@ -141,7 +157,7 @@ static int rfc4175_handle_packet(AVFormatContext
> *ctx, PayloadContext *data,
>   const uint8_t * buf, int len,
>   uint16_t seq, int flags)
>  {
> -int length, line, offset, cont;
> +int length, line, offset, cont, field;
>  const uint8_t *headers = buf + 2; /* skip extended seqnum */
>  const uint8_t *payload = buf + 2;
>  int payload_len = len - 2;
> @@ -194,11 +210,14 @@ static int rfc4175_handle_packet(AVFormatContext
> *ctx, PayloadContext *data,
>  return AVERROR_INVALIDDATA;
>
>  length = (headers[0] << 8) | headers[1];
> +field = (headers[2] & 0x80);
>  line = ((headers[2] & 0x7f) << 8) | headers[3];
>  offset = ((headers[4] & 0x7f) << 8) | headers[5];
>  cont = headers[4] & 0x80;
>  headers += 6;
>
> +data->field = field;
> +
>  if (length % data->pgroup)
>  return AVERROR_INVALIDDATA;
>
> --
> 2.7.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


Needs to use the bottom field packet flag too.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v1 2/3] avcodec/bitpacked: add interlace support

2018-04-11 Thread Rostislav Pehlivanov
On 10 April 2018 at 22:21, Patrick Keroulas <
patrick.kerou...@savoirfairelinux.com> wrote:

> From: Damien Riegel 
>
> This codec is already capable of depacking some combinations of pixel
> formats and depth as defined in the RFC4175. The only difference between
> progressive and interlace is that either a packet will contain the whole
> frame, or only a field of the frame.
>
> As FFmpeg is not capable of handling fields only and recompose an
> interlaced frame from that, it has to be done by the codec. To achieve
> that, it must use two AVPacket: one for each field (top and bottom).
>
> Signed-off-by: Damien Riegel 
> Signed-off-by: Patrick Keroulas 
> ---
>  libavcodec/avcodec.h   |  4 +++
>  libavcodec/bitpacked.c | 76 ++
> 
>  2 files changed, 68 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index fb0c6fa..350e8d9 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1480,6 +1480,10 @@ typedef struct AVPacket {
>   */
>  #define AV_PKT_FLAG_DISPOSABLE 0x0010
>
> +/**
> + * The packet contains a top field.
> + */
> +#define AV_PKT_FLAG_TOP_FIELD  0x0010
>

You need a bottom field flag here as well. The decoder should not play with
heuristisc to figure out what's progressive, what's top or bottom. It
should also handle switching between interlaced and progressive at any
point.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 2/2] avcodec/vp9: add profile 2 10-bit DXVA2/D3D11 decoding support

2018-04-11 Thread Hendrik Leppkes
---
 libavcodec/vp9.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 0fac638ec9..b1178c9c0c 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -188,6 +188,7 @@ static int update_size(AVCodecContext *avctx, int w, int h)
 
 switch (s->pix_fmt) {
 case AV_PIX_FMT_YUV420P:
+case AV_PIX_FMT_YUV420P10:
 #if CONFIG_VP9_DXVA2_HWACCEL
 *fmtp++ = AV_PIX_FMT_DXVA2_VLD;
 #endif
@@ -202,7 +203,6 @@ static int update_size(AVCodecContext *avctx, int w, int h)
 *fmtp++ = AV_PIX_FMT_VAAPI;
 #endif
 break;
-case AV_PIX_FMT_YUV420P10:
 case AV_PIX_FMT_YUV420P12:
 #if CONFIG_VP9_NVDEC_HWACCEL
 *fmtp++ = AV_PIX_FMT_CUDA;
-- 
2.16.1.windows.4

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


[FFmpeg-devel] [PATCH 1/2] avcodec/dxva2: add VP9 10-bit Profile2 mode mappings

2018-04-11 Thread Hendrik Leppkes
---
 libavcodec/dxva2.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 6d831599af..32416112bf 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -44,6 +44,7 @@ DEFINE_GUID(ff_DXVA2_ModeVC1_D2010,  0x1b81beA4, 
0xa0c7,0x11d3,0xb9,0x84,0x0
 DEFINE_GUID(ff_DXVA2_ModeHEVC_VLD_Main,  0x5b11d51b, 
0x2f4c,0x4452,0xbc,0xc3,0x09,0xf2,0xa1,0x16,0x0c,0xc0);
 DEFINE_GUID(ff_DXVA2_ModeHEVC_VLD_Main10,0x107af0e0, 
0xef1a,0x4d19,0xab,0xa8,0x67,0xa1,0x63,0x07,0x3d,0x13);
 
DEFINE_GUID(ff_DXVA2_ModeVP9_VLD_Profile0,0x463707f8,0xa1d0,0x4585,0x87,0x6d,0x83,0xaa,0x6d,0x60,0xb8,0x9e);
+DEFINE_GUID(ff_DXVA2_ModeVP9_VLD_10bit_Profile2,0xa4c749ef,0x6ecf,0x48aa,0x84,0x48,0x50,0xa7,0xa1,0x16,0x5f,0xf7);
 DEFINE_GUID(ff_DXVA2_NoEncrypt,  0x1b81beD0, 
0xa0c7,0x11d3,0xb9,0x84,0x00,0xc0,0x4f,0x2e,0x73,0xc5);
 DEFINE_GUID(ff_GUID_NULL,0x, 
0x,0x,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00);
 DEFINE_GUID(ff_IID_IDirectXVideoDecoderService, 
0xfc51a551,0xd5e7,0x11d9,0xaf,0x55,0x00,0x05,0x4e,0x43,0xff,0x02);
@@ -67,6 +68,10 @@ static const int prof_hevc_main[]= {FF_PROFILE_HEVC_MAIN,
 FF_PROFILE_UNKNOWN};
 static const int prof_hevc_main10[]  = {FF_PROFILE_HEVC_MAIN_10,
 FF_PROFILE_UNKNOWN};
+static const int prof_vp9_profile0[] = {FF_PROFILE_VP9_0,
+FF_PROFILE_UNKNOWN};
+static const int prof_vp9_profile2[] = {FF_PROFILE_VP9_2,
+FF_PROFILE_UNKNOWN};
 
 static const dxva_mode dxva_modes[] = {
 /* MPEG-2 */
@@ -90,7 +95,8 @@ static const dxva_mode dxva_modes[] = {
 { _DXVA2_ModeHEVC_VLD_Main,   AV_CODEC_ID_HEVC, prof_hevc_main },
 
 /* VP8/9 */
-{ _DXVA2_ModeVP9_VLD_Profile0,AV_CODEC_ID_VP9 },
+{ _DXVA2_ModeVP9_VLD_Profile0,   AV_CODEC_ID_VP9, prof_vp9_profile0 
},
+{ _DXVA2_ModeVP9_VLD_10bit_Profile2, AV_CODEC_ID_VP9, prof_vp9_profile2 
},
 
 { NULL,  0 },
 };
-- 
2.16.1.windows.4

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


[FFmpeg-devel] [PATCH] avcodec/hevc: export chroma sample location

2018-04-11 Thread Hendrik Leppkes
---
 libavcodec/hevcdec.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index c8877626d2..e8227a510b 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -344,6 +344,17 @@ static void export_stream_params(AVCodecContext *avctx, 
const HEVCParamSets *ps,
 avctx->colorspace  = AVCOL_SPC_UNSPECIFIED;
 }
 
+if (sps->chroma_format_idc == 1) {
+if (sps->vui.chroma_loc_info_present_flag) {
+if (sps->vui.chroma_sample_loc_type_top_field <= 5)
+avctx->chroma_sample_location = 
sps->vui.chroma_sample_loc_type_top_field + 1;
+else
+avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
+} else
+avctx->chroma_sample_location = AVCHROMA_LOC_LEFT;
+} else
+avctx->chroma_sample_location = AVCHROMA_LOC_UNSPECIFIED;
+
 if (vps->vps_timing_info_present_flag) {
 num = vps->vps_num_units_in_tick;
 den = vps->vps_time_scale;
-- 
2.16.1.windows.4

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


[FFmpeg-devel] [PATCH] avcodec/aac_ac3_parser: account for data already in the parsing buffer

2018-04-11 Thread Hendrik Leppkes
If a frame starts very close to a packet boundary, the start code may
already have been added to the parsing buffer, indicated by a small
negative value of "i", while the header is still being tracked in the
"state" variable.

Reduce the remaining size accordingly, otherwise trying to find the next
frame could skip over the frame header and lump two frames together as
one.
---
 libavcodec/aac_ac3_parser.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
index 019074b0dd..7f20626285 100644
--- a/libavcodec/aac_ac3_parser.c
+++ b/libavcodec/aac_ac3_parser.c
@@ -60,6 +60,8 @@ get_next:
 s->remaining_size += i;
 goto get_next;
 }
+else if (i < 0)
+s->remaining_size += i;
 }
 }
 }
-- 
2.16.1.windows.4

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


[FFmpeg-devel] [PATCH] avcodec/nvdec_hevc: add support for new extended sps/pps flags from SDK 8.1

2018-04-11 Thread timo
From: Timo Rothenpieler 

---
 libavcodec/hevc_ps.c| 5 ++---
 libavcodec/hevc_ps.h| 1 +
 libavcodec/nvdec_hevc.c | 6 ++
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 1f18d0335b..f877fa572c 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -1100,7 +1100,6 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb, 
unsigned int *sps_id,
 skip_bits(gb, 7); //sps_extension_7bits = get_bits(gb, 7);
 if (sps_extension_flag[0]) {
 int extended_precision_processing_flag;
-int high_precision_offsets_enabled_flag;
 int cabac_bypass_alignment_enabled_flag;
 
 sps->transform_skip_rotation_enabled_flag = get_bits1(gb);
@@ -1115,8 +1114,8 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb, 
unsigned int *sps_id,
"extended_precision_processing_flag not yet implemented\n");
 
 sps->intra_smoothing_disabled_flag   = get_bits1(gb);
-high_precision_offsets_enabled_flag  = get_bits1(gb);
-if (high_precision_offsets_enabled_flag)
+sps->high_precision_offsets_enabled_flag = get_bits1(gb);
+if (sps->high_precision_offsets_enabled_flag)
 av_log(avctx, AV_LOG_WARNING,
"high_precision_offsets_enabled_flag not yet 
implemented\n");
 
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index 9873754389..1fbda199e3 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -289,6 +289,7 @@ typedef struct HEVCSPS {
 int implicit_rdpcm_enabled_flag;
 int explicit_rdpcm_enabled_flag;
 int intra_smoothing_disabled_flag;
+int high_precision_offsets_enabled_flag;
 int persistent_rice_adaptation_enabled_flag;
 
 ///< coded frame dimension in various units
diff --git a/libavcodec/nvdec_hevc.c b/libavcodec/nvdec_hevc.c
index 58f3fa9b45..ba54d210e8 100644
--- a/libavcodec/nvdec_hevc.c
+++ b/libavcodec/nvdec_hevc.c
@@ -107,6 +107,12 @@ static int nvdec_hevc_start_frame(AVCodecContext *avctx,
 .log2_diff_max_min_pcm_luma_coding_block_size = 
sps->pcm.log2_max_pcm_cb_size - sps->pcm.log2_min_pcm_cb_size,
 .pcm_sample_bit_depth_luma_minus1 = 
sps->pcm_enabled_flag ? sps->pcm.bit_depth - 1 : 0,
 .pcm_sample_bit_depth_chroma_minus1   = 
sps->pcm_enabled_flag ? sps->pcm.bit_depth_chroma - 1 : 0,
+#if defined(NVDECAPI_VERSION) && NVDECAPI_VERSION >= 0x0108
+.log2_max_transform_skip_block_size_minus2= 
pps->log2_max_transform_skip_block_size - 2,
+.log2_sao_offset_scale_luma   = 
pps->log2_sao_offset_scale_luma,
+.log2_sao_offset_scale_chroma = 
pps->log2_sao_offset_scale_chroma,
+.high_precision_offsets_enabled_flag  = 
sps->high_precision_offsets_enabled_flag,
+#endif
 .pcm_loop_filter_disabled_flag= 
sps->pcm.loop_filter_disable_flag,
 .strong_intra_smoothing_enabled_flag  = 
sps->sps_strong_intra_smoothing_enable_flag,
 .max_transform_hierarchy_depth_intra  = 
sps->max_transform_hierarchy_depth_intra,
-- 
2.16.1

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


Re: [FFmpeg-devel] [PATCH] avcodec/dpx: Support for RGB 12-bit packed decoding

2018-04-11 Thread Jerome Martinez

On 11/04/2018 00:16, Lou Logan wrote:

On Tue, Apr 10, 2018, at 2:05 PM, Michael Niedermayer wrote:

what do you mean by "Git and me are not good friends" ?
If git hates you and sometimes does things that you didnt intend at all then
that would be a problem with direct pushes as theres no way to undo.
But maybe i misunderstand.



Yes, that's right :), I think you also remarked that I am an expert of 
careless mistakes :(.
I am still at the bottom of the Git learning curve, being more used to 
the GitHub PR things (which IMO avoids well to do a mess with upstream 
repo).
Additionally, I think that it does not worth it to take risks (including 
the risk of compromised machine) about giving me write rights with the 
only few patches I send. It would be another story if I become more 
active on FFmpeg code in the future.




Also to get git write access, post a patch that adds yourself to the
MAINTAINERs file. When noone objects then ill add your key and apply
the MAINTAINER patch.

Also, if you're uncomfortable pushing to the repository that's fine too. It is 
not a problem, but you may have to prod and remind us, perhaps a few times (or 
more), to push stuff.


I kindly request a maintainer to push one (the latest one?) of the DPX 
patches in this thread (i.e. right I am uncomfortable pushing to FFmpeg 
repo directly, I would do it only if it is the only method for having my 
patches pushed upstream after review due to no current maintainer 
willing to push them), as well as reviewing then push (if they are fine) 
the ones related to FFV1 [1]


Jérôme

[1] https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226192.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] spdifenc: support ac3 core+eac3 dependent streams

2018-04-11 Thread Hendrik Leppkes
On Tue, Apr 3, 2018 at 4:06 PM, Anssi Hannula  wrote:
> Hi,
>
> Hendrik Leppkes kirjoitti 2018-04-03 13:35:
>>
>> Such streams are found on Blu-ray, and identified as EAC3 type in
>> avformat, while the bitstream of the core stream is actually a pure AC3
>> frame.
>>
>> Adjust the parsing accordingly, since AC3 frames always hold 6 blocks
>> and the numblkscod syntax element is not present.
>> ---
>>  libavformat/spdifenc.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/spdifenc.c b/libavformat/spdifenc.c
>> index 3a50aebbef..9514ff8e10 100644
>> --- a/libavformat/spdifenc.c
>> +++ b/libavformat/spdifenc.c
>> @@ -118,7 +118,8 @@ static int spdif_header_eac3(AVFormatContext *s,
>> AVPacket *pkt)
>>  static const uint8_t eac3_repeat[4] = {6, 3, 2, 1};
>>  int repeat = 1;
>>
>> -if ((pkt->data[4] & 0xc0) != 0xc0) /* fscod */
>> +int bsid = pkt->data[5] >> 3;
>> +if (bsid > 10 && (pkt->data[4] & 0xc0) != 0xc0) /* fscod */
>>  repeat = eac3_repeat[(pkt->data[4] & 0x30) >> 4]; /* numblkscod
>> */
>>
>>  ctx->hd_buf = av_fast_realloc(ctx->hd_buf, >hd_buf_size,
>> ctx->hd_buf_filled + pkt->size);
>
>
>
> Looks good to me.
>

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


Re: [FFmpeg-devel] avfilter/showvolume : add new options and minor clean

2018-04-11 Thread Martin Vignali
Hello,

Thanks for the comments.

New patchs in attach :

001 : Add display_scale volume
Change since prev patch :
- use enum for the value
- move the max_draw calc part to an inline func (avoid code duplication).

002 : Add Persistent max display
Change since prev patch
- Use only one param (dm_duration), if set to 0. (the default), disabled
display and calc
- move some part in inline func, to reduce code duplication
- offset line draw by 1 pixel (and use FFMAX to clip to 0). Fix display max
line, when max is 0db in horizontal mode
- add doc

Martin


0001-avfilter-showvolume-add-display-scale-option.patch
Description: Binary data


0002-avfilter-showvolume-add-persistent-max-display.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH][RFC] avcodec/dpxenc: add option to force color transfer characteristics

2018-04-11 Thread Hendrik Leppkes
On Wed, Apr 11, 2018 at 10:42 AM, Tobias Rapp  wrote:
> On 11.04.2018 10:23, Kieran O Leary wrote:
>>
>> Hi Carl,
>>
>> On Sat, Dec 16, 2017 at 2:31 PM, Carl Eugen Hoyos 
>> wrote:
>>>
>>> 2017-12-15 22:22 GMT+01:00 Tobias Rapp :
>>>
 +{ "dpx_color_trc",  "Transfer Characteristics", OFFSET(color_trc),
 AV_OPT_TYPE_INT, { .i64 = DPX_TRC_UNDEFINED }, DPX_TRC_UNDEFINED,
 DPX_TRC_NB-1, VE, "trc" },
>>>
>>>
>>> This seems wrong to me, we have colour characteristics in general code.
>>>
>>
>> There is a method in this patch that takes values from -color_trc, is
>> that not sufficient?
>>
>> [...]
>
>
> If I understand it correctly Carl wants to have the DPX_TRC_* enum values
> merged into AVCOL_TRC_*. My feeling is that I currently don't have enough
> knowledge about all those TRC specifications to properly sort them into the
> list, and did not find time to dig into the topic. Also I doubt the general
> usefulness of DPX_TRC_USER_DEFINED or DPX_TRC_UNSPECIFIED_VIDEO outside of
> DPX encoding.

All the AVColor* enums track the values from ISO/IEC 23001-8, which is
also the same numeric values most major codecs follow, any values not
defined in that standard should not get into those enums at this
point.

Somwhat related to that, the two 601 values probably have mappings in AVCOL_TRC.

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


Re: [FFmpeg-devel] [PATCH 1/4] lavf/aviobuf: add ff_get_chomp_line

2018-04-11 Thread Marton Balint



On Wed, 11 Apr 2018, Jun Zhao wrote:




On 2018/4/10 21:54, Marton Balint wrote:



On Tue, 10 Apr 2018, Jun Zhao wrote:






Maybe you should use ff_read_line_to_bprint instead? It already chops
the trailing line endings, not any whitespace though. Generally I
think we should deprecate ff_get_line, because line length limits
always pop here or there...


ff_read_line_to_bprint usually use when we don't know the length limits
and need to the caller free the AVBPrint resource, in hls case, I think
this is a simple case, the other reason is I don't want to mix the
AVBPrint and c native char * in hls. Thanks.


Since it's just factorization of existing code, then I guess it is OK.

But new code should not use either that or ff_get_line. (MAX_URL_SIZE 
being 4096 does not even adhere to the RFC recommendation of supporting at 
least 8000 char length URLs)


https://tools.ietf.org/html/rfc7230#section-3.1.1

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


Re: [FFmpeg-devel] [PATCH][RFC] avcodec/dpxenc: add option to force color transfer characteristics

2018-04-11 Thread Kieran O Leary
On Wed, Apr 11, 2018 at 9:42 AM, Tobias Rapp  wrote:
> On 11.04.2018 10:23, Kieran O Leary wrote:
>>
>> Hi Carl,
>>
>> On Sat, Dec 16, 2017 at 2:31 PM, Carl Eugen Hoyos 
>> wrote:
>>>
>>> 2017-12-15 22:22 GMT+01:00 Tobias Rapp :
>>>
 +{ "dpx_color_trc",  "Transfer Characteristics", OFFSET(color_trc),
 AV_OPT_TYPE_INT, { .i64 = DPX_TRC_UNDEFINED }, DPX_TRC_UNDEFINED,
 DPX_TRC_NB-1, VE, "trc" },
>>>
>>>
>>> This seems wrong to me, we have colour characteristics in general code.
>>>
>>
>> There is a method in this patch that takes values from -color_trc, is
>> that not sufficient?
>>
>> [...]
>
>
> If I understand it correctly Carl wants to have the DPX_TRC_* enum values
> merged into AVCOL_TRC_*. My feeling is that I currently don't have enough
> knowledge about all those TRC specifications to properly sort them into the
> list, and did not find time to dig into the topic. Also I doubt the general
> usefulness of DPX_TRC_USER_DEFINED or DPX_TRC_UNSPECIFIED_VIDEO outside of
> DPX encoding.
>

I also don't see the point of the DPX specific values to be used in
the general list. I'd include Printing Density in this as well.

Best,

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


Re: [FFmpeg-devel] [PATCH][RFC] avcodec/dpxenc: add option to force color transfer characteristics

2018-04-11 Thread Tobias Rapp

On 11.04.2018 10:23, Kieran O Leary wrote:

Hi Carl,

On Sat, Dec 16, 2017 at 2:31 PM, Carl Eugen Hoyos  wrote:

2017-12-15 22:22 GMT+01:00 Tobias Rapp :


+{ "dpx_color_trc",  "Transfer Characteristics", OFFSET(color_trc), AV_OPT_TYPE_INT, 
{ .i64 = DPX_TRC_UNDEFINED }, DPX_TRC_UNDEFINED, DPX_TRC_NB-1, VE, "trc" },


This seems wrong to me, we have colour characteristics in general code.



There is a method in this patch that takes values from -color_trc, is
that not sufficient?

[...]


If I understand it correctly Carl wants to have the DPX_TRC_* enum 
values merged into AVCOL_TRC_*. My feeling is that I currently don't 
have enough knowledge about all those TRC specifications to properly 
sort them into the list, and did not find time to dig into the topic. 
Also I doubt the general usefulness of DPX_TRC_USER_DEFINED or 
DPX_TRC_UNSPECIFIED_VIDEO outside of DPX encoding.


Regards,
Tobias

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


Re: [FFmpeg-devel] [PATCH][RFC] avcodec/dpxenc: add option to force color transfer characteristics

2018-04-11 Thread Kieran O Leary
Hi Carl,

On Sat, Dec 16, 2017 at 2:31 PM, Carl Eugen Hoyos  wrote:
> 2017-12-15 22:22 GMT+01:00 Tobias Rapp :
>
>> +{ "dpx_color_trc",  "Transfer Characteristics", OFFSET(color_trc), 
>> AV_OPT_TYPE_INT, { .i64 = DPX_TRC_UNDEFINED }, DPX_TRC_UNDEFINED, 
>> DPX_TRC_NB-1, VE, "trc" },
>
> This seems wrong to me, we have colour characteristics in general code.
>

There is a method in this patch that takes values from -color_trc, is
that not sufficient?

$ ./ffmpeg -f lavfi -i testsrc -color_trc bt709 -vframes 1 out.dpx &&
mediainfo out.dpx |tail -n 4

ffmpeg version N-90649-g9825f77 Copyright (c) 2000-2018 the FFmpeg developers

  built with Apple LLVM version 8.0.0 (clang-800.0.42.1)

  configuration:

  libavutil  56. 13.100 / 56. 13.100

  libavcodec 58. 17.100 / 58. 17.100

  libavformat58. 11.101 / 58. 11.101

  libavdevice58.  2.100 / 58.  2.100

  libavfilter 7. 14.100 /  7. 14.100

  libswscale  5.  0.102 /  5.  0.102

  libswresample   3.  0.101 /  3.  0.101

Input #0, lavfi, from 'testsrc':

  Duration: N/A, start: 0.00, bitrate: N/A

Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24,
320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc

File 'out.dpx' already exists. Overwrite ? [y/N] y

Stream mapping:

  Stream #0:0 -> #0:0 (rawvideo (native) -> dpx (native))

Press [q] to stop, [?] for help

Output #0, image2, to 'out.dpx':

  Metadata:

encoder : Lavf58.11.101

Stream #0:0: Video: dpx, rgb24(unknown/unknown/bt709), 320x240
[SAR 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc

Metadata:

  encoder : Lavc58.17.100 dpx

frame=1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A
speed=20.6x

video:227kB audio:0kB subtitle:0kB other streams:0kB global
headers:0kB muxing overhead: unknown

Color primaries  : BT.709

Transfer characteristics : BT.709


Best,

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


[FFmpeg-devel] [PATCH v3] doc: update loglevel option documentation

2018-04-11 Thread Tobias Rapp
Updates documentation after the changes to loglevel flag prefix parsing
in 4b736bc921ed96ad6d312ce0cbe0de29b9e3fe81.

Signed-off-by: Tobias Rapp 
---
 doc/fftools-common-opts.texi | 37 +
 1 file changed, 29 insertions(+), 8 deletions(-)

diff --git a/doc/fftools-common-opts.texi b/doc/fftools-common-opts.texi
index 185ec21..7787e11 100644
--- a/doc/fftools-common-opts.texi
+++ b/doc/fftools-common-opts.texi
@@ -168,14 +168,24 @@ The returned list cannot be assumed to be always complete.
 ffmpeg -sinks pulse,server=192.168.0.4
 @end example
 
-@item -loglevel [repeat+]@var{loglevel} | -v [repeat+]@var{loglevel}
-Set the logging level used by the library.
-Adding "repeat+" indicates that repeated log output should not be compressed
-to the first line and the "Last message repeated n times" line will be
-omitted. "repeat" can also be used alone.
-If "repeat" is used alone, and with no prior loglevel set, the default
-loglevel will be used. If multiple loglevel parameters are given, using
-'repeat' will not change the loglevel.
+@item -loglevel [@var{flags}+]@var{loglevel} | -v [@var{flags}+]@var{loglevel}
+Set logging level and flags used by the library.
+
+The optional @var{flags} prefix can consist of the following values:
+@table @samp
+@item repeat
+Indicates that repeated log output should not be compressed to the first line
+and the "Last message repeated n times" line will be omitted.
+@item level
+Indicates that log output should add a @code{[level]} prefix to each message
+line. This can be used as an alternative to log coloring, e.g. when dumping the
+log to file.
+@end table
+Flags can also be used alone by adding a '+'/'-' prefix to set/reset a single
+flag without affecting other @var{flags} or changing @var{loglevel}. When
+setting both @var{flags} and @var{loglevel}, a '+' separator is expected
+between the last @var{flags} value and before @var{loglevel}.
+
 @var{loglevel} is a string or a number containing one of the following values:
 @table @samp
 @item quiet, -8
@@ -201,6 +211,17 @@ Show everything, including debugging information.
 @item trace, 56
 @end table
 
+For example to enable repeated log output, add the @code{level} prefix, and set
+@var{loglevel} to @code{verbose}:
+@example
+ffmpeg -loglevel repeat+level+verbose -i input output
+@end example
+Another example that enables repeated log output without affecting current
+state of @code{level} prefix flag or @var{loglevel}:
+@example
+ffmpeg [...] -loglevel +repeat
+@end example
+
 By default the program logs to stderr. If coloring is supported by the
 terminal, colors are used to mark errors and warnings. Log coloring
 can be disabled setting the environment variable
-- 
2.7.4


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


Re: [FFmpeg-devel] [PATCH v2] doc: update loglevel option documentation

2018-04-11 Thread Tobias Rapp

On 10.04.2018 22:26, Lou Logan wrote:

On Mon, Apr 9, 2018, at 10:59 PM, Tobias Rapp wrote:


+For example to enable repeated log output and set @var{loglevel} to
+@code{verbose}:
+@example
+ffmpeg -loglevel repeat+verbose -i input output
+@end example


Just to show all current flags and the loglevel I prefer:

For example to enable repeated log output, add the @code{level} prefix, and set 
@var{loglevel} to
@code{verbose}:
@example
ffmpeg -loglevel repeat+level+verbose -i input output
@end example


OK, will change.


+Another example that disables the @code{level} prefix without affecting the
+current state of @code{repeat} flag or @var{loglevel}:
+@example
+ffmpeg [...] -loglevel -level
+@end example


I'm not sure how useful this example is. Sure, it displays how to use "-", but is there 
an actual use case for using "-loglevel -level" since the level prefix is not shown by 
default anyway?


Yeah I added this to show that incrementally updating the loglevel 
option and the "-" also works. Can change it to "+" if that is preferred.


BTW: Is there some documentation on the generic flags syntax used in 
FFmpeg for options like "-fflags" or "-cpuflags" and how to combine the 
tokens with "+" or "-"? I couldn't find something on a quick scan.


Regards,
Tobias

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


[FFmpeg-devel] [PATCH v3 10/11] avformat/dashenc: addition of muxer overhead for @bandwidth param in MPD

2018-04-11 Thread vdixit
From: Vishwanath Dixit 

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

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 6d06486..bf8698f 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -555,7 +555,7 @@ static int write_adaptation_set(AVFormatContext *s, 
AVIOContext *out, int as_ind
 
 if (os->bit_rate > 0)
 snprintf(bandwidth_str, sizeof(bandwidth_str), " bandwidth=\"%d\"",
- os->bit_rate);
+ os->bit_rate + os->muxer_overhead);
 
 if (as->media_type == AVMEDIA_TYPE_VIDEO) {
 AVStream *st = s->streams[i];
-- 
1.9.1

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


[FFmpeg-devel] [PATCH v3 11/11] avformat/dashenc: addition of segment index correction logic

2018-04-11 Thread vdixit
From: Vishwanath Dixit 

The logic is applicable only when use_template is enabled and use_timeline
is disabled. The logic monitors the flow of segment indexes. If a streams's
segment index value is not at the expected real time position, then
the logic corrects that index value.

Typically this logic is needed in live streaming use cases. The network
bandwidth fluctuations are common during long run streaming. Each
fluctuation can cause the segment indexes fall behind the expected real
time position. Without this logic, players will not be able to consume
the content, even after encoder's network condition comes back to
normal state.
---
 doc/muxers.texi   | 11 +++
 libavformat/dashenc.c | 31 ++-
 2 files changed, 37 insertions(+), 5 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index e1b..fa528b6 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -271,6 +271,17 @@ To map all video (or audio) streams to an AdaptationSet, 
"v" (or "a") can be use
 When no assignment is defined, this defaults to an AdaptationSet for each 
stream.
 @item -timeout @var{timeout}
 Set timeout for socket I/O operations. Applicable only for HTTP output.
+@item -index_correction @var{index_correction}
+Enable (1) or Disable (0) segment index correction logic. Applicable only when
+@var{use_template} is enabled and @var{use_timeline} is disabled.
+
+When enabled, the logic monitors the flow of segment indexes. If a streams's
+segment index value is not at the expected real time position, then the logic
+corrects that index value.
+
+Typically this logic is needed in live streaming use cases. The network 
bandwidth
+fluctuations are common during long run streaming. Each fluctuation can cause
+the segment indexes fall behind the expected real time position.
 @end table
 
 @anchor{framecrc}
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index bf8698f..9e72636 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -76,7 +76,7 @@ typedef struct OutputStream {
 int nb_segments, segments_size, segment_index;
 Segment **segments;
 int64_t first_pts, start_pts, max_pts;
-int64_t last_dts;
+int64_t last_dts, last_pts;
 int bit_rate;
 
 char codec_str[100];
@@ -123,6 +123,7 @@ typedef struct DASHContext {
 AVIOContext *m3u8_out;
 int streaming;
 int64_t timeout;
+int index_correction;
 } DASHContext;
 
 static struct codec_string {
@@ -1060,7 +1061,7 @@ static int dash_write_header(AVFormatContext *s)
 static int add_segment(OutputStream *os, const char *file,
int64_t time, int duration,
int64_t start_pos, int64_t range_length,
-   int64_t index_length)
+   int64_t index_length, int next_exp_index)
 {
 int err;
 Segment *seg;
@@ -1088,6 +1089,12 @@ static int add_segment(OutputStream *os, const char 
*file,
 seg->index_length = index_length;
 os->segments[os->nb_segments++] = seg;
 os->segment_index++;
+//correcting the segment index if it has fallen behind the expected value
+if (os->segment_index < next_exp_index) {
+av_log(NULL, AV_LOG_WARNING, "Correcting the segment index after file 
%s: current=%d corrected=%d\n",
+   file, os->segment_index, next_exp_index);
+os->segment_index = next_exp_index;
+}
 return 0;
 }
 
@@ -1177,10 +1184,22 @@ static int dash_flush(AVFormatContext *s, int final, 
int stream)
 const char *proto = avio_find_protocol_name(s->url);
 int use_rename = proto && !strcmp(proto, "file");
 
-int cur_flush_segment_index = 0;
-if (stream >= 0)
+int cur_flush_segment_index = 0, next_exp_index = -1;
+if (stream >= 0) {
 cur_flush_segment_index = c->streams[stream].segment_index;
 
+//finding the next segment's expected index, based on the current pts 
value
+if (c->use_template && !c->use_timeline && c->index_correction &&
+c->streams[stream].last_pts != AV_NOPTS_VALUE &&
+c->streams[stream].first_pts != AV_NOPTS_VALUE) {
+int64_t pts_diff = av_rescale_q(c->streams[stream].last_pts -
+c->streams[stream].first_pts,
+s->streams[stream]->time_base,
+AV_TIME_BASE_Q);
+next_exp_index = (pts_diff / c->seg_duration) + 1;
+}
+}
+
 for (i = 0; i < s->nb_streams; i++) {
 OutputStream *os = >streams[i];
 AVStream *st = s->streams[i];
@@ -1240,7 +1259,7 @@ static int dash_flush(AVFormatContext *s, int final, int 
stream)
 if (bitrate >= 0)
 os->bit_rate = bitrate;
 }
-add_segment(os, os->filename, os->start_pts, os->max_pts - 
os->start_pts, os->pos, range_length, index_length);
+add_segment(os, os->filename, os->start_pts, 

[FFmpeg-devel] [PATCH v3 08/11] avformat/dashenc: addition of muxer overhead in master playlist's bandwidth

2018-04-11 Thread vdixit
From: Vishwanath Dixit 

---
 libavformat/dashenc.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 9c29c05..1d34bb9 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -827,20 +827,23 @@ static int write_manifest(AVFormatContext *s, int final)
 for (i = 0; i < s->nb_streams; i++) {
 char playlist_file[64];
 AVStream *st = s->streams[i];
+OutputStream *os = >streams[i];
 if (st->codecpar->codec_type != AVMEDIA_TYPE_AUDIO)
 continue;
 get_hls_playlist_name(playlist_file, sizeof(playlist_file), NULL, 
i);
 ff_hls_write_audio_rendition(out, (char *)audio_group,
  playlist_file, i, is_default);
-max_audio_bitrate = FFMAX(st->codecpar->bit_rate, 
max_audio_bitrate);
+max_audio_bitrate = FFMAX(st->codecpar->bit_rate +
+  os->muxer_overhead, max_audio_bitrate);
 is_default = 0;
 }
 
 for (i = 0; i < s->nb_streams; i++) {
 char playlist_file[64];
 AVStream *st = s->streams[i];
+OutputStream *os = >streams[i];
 char *agroup = NULL;
-int stream_bitrate = st->codecpar->bit_rate;
+int stream_bitrate = st->codecpar->bit_rate + os->muxer_overhead;
 if ((st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) && 
max_audio_bitrate) {
 agroup = (char *)audio_group;
 stream_bitrate += max_audio_bitrate;
-- 
1.9.1

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


[FFmpeg-devel] [PATCH v3 09/11] avformat/dashenc: constructing MPD's bandwidth string locally

2018-04-11 Thread vdixit
From: Vishwanath Dixit 

---
 libavformat/dashenc.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 1d34bb9..6d06486 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -78,7 +78,6 @@ typedef struct OutputStream {
 int64_t first_pts, start_pts, max_pts;
 int64_t last_dts;
 int bit_rate;
-char bandwidth_str[64];
 
 char codec_str[100];
 int written_len;
@@ -549,20 +548,25 @@ static int write_adaptation_set(AVFormatContext *s, 
AVIOContext *out, int as_ind
 
 for (i = 0; i < s->nb_streams; i++) {
 OutputStream *os = >streams[i];
+char bandwidth_str[64] = {'\0'};
 
 if (os->as_idx - 1 != as_index)
 continue;
 
+if (os->bit_rate > 0)
+snprintf(bandwidth_str, sizeof(bandwidth_str), " bandwidth=\"%d\"",
+ os->bit_rate);
+
 if (as->media_type == AVMEDIA_TYPE_VIDEO) {
 AVStream *st = s->streams[i];
 avio_printf(out, "\t\t\tformat_name, os->codec_str, os->bandwidth_str, 
s->streams[i]->codecpar->width, s->streams[i]->codecpar->height);
+i, os->format_name, os->codec_str, bandwidth_str, 
s->streams[i]->codecpar->width, s->streams[i]->codecpar->height);
 if (st->avg_frame_rate.num)
 avio_printf(out, " frameRate=\"%d/%d\"", 
st->avg_frame_rate.num, st->avg_frame_rate.den);
 avio_printf(out, ">\n");
 } else {
 avio_printf(out, "\t\t\t\n",
-i, os->format_name, os->codec_str, os->bandwidth_str, 
s->streams[i]->codecpar->sample_rate);
+i, os->format_name, os->codec_str, bandwidth_str, 
s->streams[i]->codecpar->sample_rate);
 avio_printf(out, "\t\t\t\t\n",
 s->streams[i]->codecpar->channels);
 }
@@ -918,10 +922,7 @@ static int dash_init(AVFormatContext *s)
 char filename[1024];
 
 os->bit_rate = s->streams[i]->codecpar->bit_rate;
-if (os->bit_rate) {
-snprintf(os->bandwidth_str, sizeof(os->bandwidth_str),
- " bandwidth=\"%d\"", os->bit_rate);
-} else {
+if (!os->bit_rate) {
 int level = s->strict_std_compliance >= FF_COMPLIANCE_STRICT ?
 AV_LOG_ERROR : AV_LOG_WARNING;
 av_log(s, level, "No bit rate set for stream %d\n", i);
@@ -1236,11 +1237,8 @@ static int dash_flush(AVFormatContext *s, int final, int 
stream)
 int64_t bitrate = (int64_t) range_length * 8 * AV_TIME_BASE / 
av_rescale_q(os->max_pts - os->start_pts,

st->time_base,

AV_TIME_BASE_Q);
-if (bitrate >= 0) {
+if (bitrate >= 0)
 os->bit_rate = bitrate;
-snprintf(os->bandwidth_str, sizeof(os->bandwidth_str),
- " bandwidth=\"%d\"", os->bit_rate);
-}
 }
 add_segment(os, os->filename, os->start_pts, os->max_pts - 
os->start_pts, os->pos, range_length, index_length);
 av_log(s, AV_LOG_VERBOSE, "Representation %d media segment %d written 
to: %s\n", i, os->segment_index, os->full_path);
-- 
1.9.1

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


[FFmpeg-devel] [PATCH v3 06/11] avformat/dashenc: addition of @availabilityTimeOffset in MPD

2018-04-11 Thread vdixit
From: Vishwanath Dixit 

availability time of Nth segment = availabilityStartTime + (N*segment duration) 
- availabilityTimeOffset.
This field helps to reduce the latency by about a segment duration in streaming 
mode.
---
 libavformat/dashenc.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 5d5310d..70409e5 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -85,6 +85,7 @@ typedef struct OutputStream {
 char filename[1024];
 char full_path[1024];
 char temp_path[1024];
+double availability_time_offset;
 } OutputStream;
 
 typedef struct DASHContext {
@@ -346,8 +347,12 @@ static void output_segment_list(OutputStream *os, 
AVIOContext *out, AVFormatCont
 if (c->use_template) {
 int timescale = c->use_timeline ? os->ctx->streams[0]->time_base.den : 
AV_TIME_BASE;
 avio_printf(out, "\t\t\t\tuse_timeline)
+if (!c->use_timeline) {
 avio_printf(out, "duration=\"%"PRId64"\" ", c->seg_duration);
+if (c->streaming && os->availability_time_offset)
+avio_printf(out, "availabilityTimeOffset=\"%.3f\" ",
+os->availability_time_offset);
+}
 avio_printf(out, "initialization=\"%s\" media=\"%s\" 
startNumber=\"%d\">\n", c->init_seg_name, c->media_seg_name, c->use_timeline ? 
start_number : 1);
 if (c->use_timeline) {
 int64_t cur_time = 0;
@@ -1293,6 +1298,13 @@ static int dash_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 format_date_now(c->availability_start_time,
 sizeof(c->availability_start_time));
 
+if (!os->availability_time_offset && pkt->duration) {
+int64_t frame_duration = av_rescale_q(pkt->duration, st->time_base,
+  AV_TIME_BASE_Q);
+ os->availability_time_offset = ((double) c->seg_duration -
+ frame_duration) / AV_TIME_BASE;
+}
+
 if (c->use_template && !c->use_timeline) {
 elapsed_duration = pkt->pts - os->first_pts;
 seg_end_duration = (int64_t) os->segment_index * c->seg_duration;
-- 
1.9.1

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


[FFmpeg-devel] [PATCH v3 07/11] avformat/dashenc: logic to compute muxer overhead

2018-04-11 Thread vdixit
From: Vishwanath Dixit 

---
 libavformat/dashenc.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 70409e5..9c29c05 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -86,6 +86,8 @@ typedef struct OutputStream {
 char full_path[1024];
 char temp_path[1024];
 double availability_time_offset;
+int total_pkt_size;
+int muxer_overhead;
 } OutputStream;
 
 typedef struct DASHContext {
@@ -1219,6 +1221,13 @@ static int dash_flush(AVFormatContext *s, int final, int 
stream)
 }
 }
 
+if (!os->muxer_overhead)
+os->muxer_overhead = ((int64_t) (range_length - 
os->total_pkt_size) *
+  8 * AV_TIME_BASE) /
+ av_rescale_q(os->max_pts - os->start_pts,
+  st->time_base, AV_TIME_BASE_Q);
+os->total_pkt_size = 0;
+
 if (!os->bit_rate) {
 // calculate average bitrate of first segment
 int64_t bitrate = (int64_t) range_length * 8 * AV_TIME_BASE / 
av_rescale_q(os->max_pts - os->start_pts,
@@ -1353,6 +1362,7 @@ static int dash_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 else
 os->max_pts = FFMAX(os->max_pts, pkt->pts + pkt->duration);
 os->packets_written++;
+os->total_pkt_size += pkt->size;
 if ((ret = ff_write_chained(os->ctx, 0, pkt, s, 0)) < 0)
 return ret;
 
-- 
1.9.1

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


[FFmpeg-devel] [PATCH v3 05/11] avformat/dashenc: setting @availabilityStartTime when the first frame is ready

2018-04-11 Thread vdixit
From: Vishwanath Dixit 

@availabilityStartTime specifies the anchor for the computation of the earliest
availability time (in UTC) for any Segment in the Media Presentation.

As per this requirement, the @AvailabilityStartTime should be set to the
wallclock time at which the first frame of the first segment begins encoding.
But, it was getting set only when the first segment was completely ready. Making
the required correction in this patch. This correction is mainly needed to 
reduce
the latency in live streaming use cases.
---
 libavformat/dashenc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index bf06a7b..5d5310d 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -743,9 +743,6 @@ static int write_manifest(AVFormatContext *s, int final)
 update_period = 500;
 avio_printf(out, "\tminimumUpdatePeriod=\"PT%"PRId64"S\"\n", 
update_period);
 avio_printf(out, "\tsuggestedPresentationDelay=\"PT%"PRId64"S\"\n", 
c->last_duration / AV_TIME_BASE);
-if (!c->availability_start_time[0] && s->nb_streams > 0 && 
c->streams[0].nb_segments > 0) {
-format_date_now(c->availability_start_time, 
sizeof(c->availability_start_time));
-}
 if (c->availability_start_time[0])
 avio_printf(out, "\tavailabilityStartTime=\"%s\"\n", 
c->availability_start_time);
 format_date_now(now_str, sizeof(now_str));
@@ -1292,6 +1289,10 @@ static int dash_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 if (os->first_pts == AV_NOPTS_VALUE)
 os->first_pts = pkt->pts;
 
+if (!c->availability_start_time[0])
+format_date_now(c->availability_start_time,
+sizeof(c->availability_start_time));
+
 if (c->use_template && !c->use_timeline) {
 elapsed_duration = pkt->pts - os->first_pts;
 seg_end_duration = (int64_t) os->segment_index * c->seg_duration;
-- 
1.9.1

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


[FFmpeg-devel] [PATCH v3 04/11] avformat/dashenc: removed 'write_manifest' call from 'write_header'

2018-04-11 Thread vdixit
From: Vishwanath Dixit 

Calling 'write_manifest' from 'write_header' was causing creation of
first MPD with invalid values. Ex: zero @duration param value. Also,
the manifest files (MPD or M3U8s) should be created when at-least
one media frame is ready for consumption.
---
 libavformat/dashenc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 4c2e63c..bf06a7b 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1046,9 +1046,6 @@ static int dash_write_header(AVFormatContext *s)
 if ((ret = avformat_write_header(os->ctx, NULL)) < 0)
 return ret;
 }
-ret = write_manifest(s, 0);
-if (!ret)
-av_log(s, AV_LOG_VERBOSE, "Manifest written to: %s\n", s->url);
 return ret;
 }
 
-- 
1.9.1

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


[FFmpeg-devel] [PATCH v3 03/11] avformat/dashenc: writing average segment duration for @duration in template mode

2018-04-11 Thread vdixit
From: Vishwanath Dixit 

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

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index ad52730..4c2e63c 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -347,7 +347,7 @@ static void output_segment_list(OutputStream *os, 
AVIOContext *out, AVFormatCont
 int timescale = c->use_timeline ? os->ctx->streams[0]->time_base.den : 
AV_TIME_BASE;
 avio_printf(out, "\t\t\t\tuse_timeline)
-avio_printf(out, "duration=\"%"PRId64"\" ", c->last_duration);
+avio_printf(out, "duration=\"%"PRId64"\" ", c->seg_duration);
 avio_printf(out, "initialization=\"%s\" media=\"%s\" 
startNumber=\"%d\">\n", c->init_seg_name, c->media_seg_name, c->use_timeline ? 
start_number : 1);
 if (c->use_timeline) {
 int64_t cur_time = 0;
-- 
1.9.1

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


[FFmpeg-devel] [PATCH v3 02/11] avformat/dashenc: segmentation at the configured segment duration rate

2018-04-11 Thread vdixit
From: Vishwanath Dixit 

When use_template is enabled and use_timeline is disabled, typically
it is required to generate the segments at the configured segment duration
rate on an average. This commit is particularly needed to handle the
segmentation when video frame rates are fractional like 29.97 or 59.94 fps.
---
 doc/muxers.texi   |  5 -
 libavformat/dashenc.c | 13 +++--
 2 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 8dbfede..e1b 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -228,7 +228,10 @@ ffmpeg -re -i  -map 0 -map 0 -c:a libfdk_aac -c:v 
libx264
 @item -min_seg_duration @var{microseconds}
 This is a deprecated option to set the segment length in microseconds, use 
@var{seg_duration} instead.
 @item -seg_duration @var{duration}
-Set the segment length in seconds (fractional value can be set).
+Set the segment length in seconds (fractional value can be set). The value is
+treated as average segment duration when @var{use_template} is enabled and
+@var{use_timeline} is disabled and as minimum segment duration for all the 
other
+use cases.
 @item -window_size @var{size}
 Set the maximum number of segments kept in the manifest.
 @item -extra_window_size @var{size}
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 7169e11..ad52730 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1267,6 +1267,7 @@ static int dash_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 DASHContext *c = s->priv_data;
 AVStream *st = s->streams[pkt->stream_index];
 OutputStream *os = >streams[pkt->stream_index];
+int64_t seg_end_duration, elapsed_duration;
 int ret;
 
 ret = update_stream_extradata(s, os, st->codecpar);
@@ -1294,10 +1295,18 @@ static int dash_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 if (os->first_pts == AV_NOPTS_VALUE)
 os->first_pts = pkt->pts;
 
+if (c->use_template && !c->use_timeline) {
+elapsed_duration = pkt->pts - os->first_pts;
+seg_end_duration = (int64_t) os->segment_index * c->seg_duration;
+} else {
+elapsed_duration = pkt->pts - os->start_pts;
+seg_end_duration = c->seg_duration;
+}
+
 if ((!c->has_video || st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) &&
 pkt->flags & AV_PKT_FLAG_KEY && os->packets_written &&
-av_compare_ts(pkt->pts - os->start_pts, st->time_base,
-  c->seg_duration, AV_TIME_BASE_Q) >= 0) {
+av_compare_ts(elapsed_duration, st->time_base,
+  seg_end_duration, AV_TIME_BASE_Q) >= 0) {
 int64_t prev_duration = c->last_duration;
 
 c->last_duration = av_rescale_q(pkt->pts - os->start_pts,
-- 
1.9.1

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


[FFmpeg-devel] [PATCH v3 01/11] avformat/dashenc: replacing 'min_seg_duration' with 'seg_duration'

2018-04-11 Thread vdixit
From: Vishwanath Dixit 

---
 doc/muxers.texi   |  4 +++-
 libavformat/dashenc.c | 23 ++-
 libavformat/version.h |  3 +++
 3 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index cb75c26..8dbfede 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -226,7 +226,9 @@ ffmpeg -re -i  -map 0 -map 0 -c:a libfdk_aac -c:v 
libx264
 
 @table @option
 @item -min_seg_duration @var{microseconds}
-Set the segment length in microseconds.
+This is a deprecated option to set the segment length in microseconds, use 
@var{seg_duration} instead.
+@item -seg_duration @var{duration}
+Set the segment length in seconds (fractional value can be set).
 @item -window_size @var{size}
 Set the maximum number of segments kept in the manifest.
 @item -extra_window_size @var{size}
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index bdf8c8d..7169e11 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -94,7 +94,10 @@ typedef struct DASHContext {
 int nb_as;
 int window_size;
 int extra_window_size;
+#if FF_API_DASH_MIN_SEG_DURATION
 int min_seg_duration;
+#endif
+int64_t seg_duration;
 int remove_at_exit;
 int use_template;
 int use_timeline;
@@ -871,6 +874,13 @@ static int dash_init(AVFormatContext *s)
 if (c->single_file)
 c->use_template = 0;
 
+#if FF_API_DASH_MIN_SEG_DURATION
+if (c->min_seg_duration != 500) {
+av_log(s, AV_LOG_WARNING, "The min_seg_duration option is deprecated 
and will be removed. Please use the -seg_duration\n");
+c->seg_duration = c->min_seg_duration;
+}
+#endif
+
 av_strlcpy(c->dirname, s->url, sizeof(c->dirname));
 ptr = strrchr(c->dirname, '/');
 if (ptr) {
@@ -974,7 +984,7 @@ static int dash_init(AVFormatContext *s)
 else
 av_dict_set(, "movflags", "frag_custom+dash+delay_moov", 
0);
 } else {
-av_dict_set_int(, "cluster_time_limit", c->min_seg_duration / 
1000, 0);
+av_dict_set_int(, "cluster_time_limit", c->seg_duration / 
1000, 0);
 av_dict_set_int(, "cluster_size_limit", 5 * 1024 * 1024, 0); 
// set a large cluster size limit
 av_dict_set_int(, "dash", 1, 0);
 av_dict_set_int(, "dash_track_number", i + 1, 0);
@@ -1020,8 +1030,8 @@ static int dash_init(AVFormatContext *s)
 os->segment_index = 1;
 }
 
-if (!c->has_video && c->min_seg_duration <= 0) {
-av_log(s, AV_LOG_WARNING, "no video stream and no min seg duration 
set\n");
+if (!c->has_video && c->seg_duration <= 0) {
+av_log(s, AV_LOG_WARNING, "no video stream and no seg duration set\n");
 return AVERROR(EINVAL);
 }
 return 0;
@@ -1287,7 +1297,7 @@ static int dash_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 if ((!c->has_video || st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) &&
 pkt->flags & AV_PKT_FLAG_KEY && os->packets_written &&
 av_compare_ts(pkt->pts - os->start_pts, st->time_base,
-  c->min_seg_duration, AV_TIME_BASE_Q) >= 0) {
+  c->seg_duration, AV_TIME_BASE_Q) >= 0) {
 int64_t prev_duration = c->last_duration;
 
 c->last_duration = av_rescale_q(pkt->pts - os->start_pts,
@@ -1427,7 +1437,10 @@ static const AVOption options[] = {
 { "adaptation_sets", "Adaptation sets. Syntax: id=0,streams=0,1,2 
id=1,streams=3,4 and so on", OFFSET(adaptation_sets), AV_OPT_TYPE_STRING, { 0 
}, 0, 0, AV_OPT_FLAG_ENCODING_PARAM },
 { "window_size", "number of segments kept in the manifest", 
OFFSET(window_size), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, E },
 { "extra_window_size", "number of segments kept outside of the manifest 
before removing from disk", OFFSET(extra_window_size), AV_OPT_TYPE_INT, { .i64 
= 5 }, 0, INT_MAX, E },
-{ "min_seg_duration", "minimum segment duration (in microseconds)", 
OFFSET(min_seg_duration), AV_OPT_TYPE_INT, { .i64 = 500 }, 0, INT_MAX, E },
+#if FF_API_DASH_MIN_SEG_DURATION
+{ "min_seg_duration", "minimum segment duration (in microseconds) (will be 
deprecated)", OFFSET(min_seg_duration), AV_OPT_TYPE_INT, { .i64 = 500 }, 0, 
INT_MAX, E },
+#endif
+{ "seg_duration", "segment duration (in seconds, fractional value can be 
set)", OFFSET(seg_duration), AV_OPT_TYPE_DURATION, { .i64 = 500 }, 0, 
INT_MAX, E },
 { "remove_at_exit", "remove all segments when finished", 
OFFSET(remove_at_exit), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
 { "use_template", "Use SegmentTemplate instead of SegmentList", 
OFFSET(use_template), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, E },
 { "use_timeline", "Use SegmentTimeline in SegmentTemplate", 
OFFSET(use_timeline), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, E },
diff --git a/libavformat/version.h b/libavformat/version.h
index a96e13b..d02e17e 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -94,6 +94,9 @@
 #ifndef 

Re: [FFmpeg-devel] [PATCH v1 2/3] avcodec/bitpacked: add interlace support

2018-04-11 Thread Paul B Mahol
On 4/10/18, Patrick Keroulas  wrote:
> From: Damien Riegel 
>
> This codec is already capable of depacking some combinations of pixel
> formats and depth as defined in the RFC4175. The only difference between
> progressive and interlace is that either a packet will contain the whole
> frame, or only a field of the frame.
>
> As FFmpeg is not capable of handling fields only and recompose an
> interlaced frame from that, it has to be done by the codec. To achieve
> that, it must use two AVPacket: one for each field (top and bottom).

This is lie, FFmpeg handle fields only just fine.

>
> Signed-off-by: Damien Riegel 
> Signed-off-by: Patrick Keroulas 
> ---
>  libavcodec/avcodec.h   |  4 +++
>  libavcodec/bitpacked.c | 76
> ++
>  2 files changed, 68 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index fb0c6fa..350e8d9 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1480,6 +1480,10 @@ typedef struct AVPacket {
>   */
>  #define AV_PKT_FLAG_DISPOSABLE 0x0010
>
> +/**
> + * The packet contains a top field.
> + */
> +#define AV_PKT_FLAG_TOP_FIELD  0x0010
>
>  enum AVSideDataParamChangeFlags {
>  AV_SIDE_DATA_PARAM_CHANGE_CHANNEL_COUNT  = 0x0001,
> diff --git a/libavcodec/bitpacked.c b/libavcodec/bitpacked.c
> index 85d4bdd..d81703d 100644
> --- a/libavcodec/bitpacked.c
> +++ b/libavcodec/bitpacked.c
> @@ -33,15 +33,19 @@
>
>  struct BitpackedContext {
>  int (*decode)(AVCodecContext *avctx, AVFrame *frame,
> -  AVPacket *pkt);
> +  AVPacket *pkt, int top_field);
> +AVPacket *first_field_pkt;
>  };
>
>  /* For this format, it's a simple passthrough */
>  static int bitpacked_decode_uyvy422(AVCodecContext *avctx, AVFrame *frame,
> -AVPacket *avpkt)
> +AVPacket *avpkt, int top_field)
>  {
>  int ret;
>
> +if (frame->interlaced_frame)
> +return AVERROR_PATCHWELCOME;
> +
>  /* there is no need to copy as the data already match
>   * a known pixel format */
>  frame->buf[0] = av_buffer_ref(avpkt->buf);
> @@ -56,17 +60,22 @@ static int bitpacked_decode_uyvy422(AVCodecContext
> *avctx, AVFrame *frame,
>  }
>
>  static int bitpacked_decode_yuv422p10(AVCodecContext *avctx, AVFrame
> *frame,
> -  AVPacket *avpkt)
> +  AVPacket *avpkt, int top_field)
>  {
>  uint64_t frame_size = (uint64_t)avctx->width * (uint64_t)avctx->height
> * 20;
>  uint64_t packet_size = (uint64_t)avpkt->size * 8;
> +int interlaced = frame->interlaced_frame;
>  GetBitContext bc;
>  uint16_t *y, *u, *v;
>  int ret, i, j;
>
> -
> -if (frame_size > packet_size)
> +/* check packet size depending on the interlaced/progressive format */
> +if (interlaced) {
> +if ((frame_size >> 1) > packet_size)
> +return AVERROR_INVALIDDATA;
> +} else if (frame_size > packet_size) {
>  return AVERROR_INVALIDDATA;
> +}
>
>  if (avctx->width % 2)
>  return AVERROR_PATCHWELCOME;
> @@ -75,7 +84,18 @@ static int bitpacked_decode_yuv422p10(AVCodecContext
> *avctx, AVFrame *frame,
>  if (ret)
>  return ret;
>
> -for (i = 0; i < avctx->height; i++) {
> +/*
> + * if the frame is interlaced, the avpkt we are getting is either the
> top
> + * or the bottom field. If it's the bottom field, it contains all the
> odd
> + * lines of the recomposed frame, so we start at offset 1.
> + */
> +i = (interlaced && !top_field) ? 1 : 0;
> +
> +/*
> + * Packets from interlaced frames contain either even lines, or odd
> + * lines, so increment by two in that case.
> + */
> +for (; i < avctx->height; interlaced ? i += 2 : i++) {
>  y = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
>  u = (uint16_t*)(frame->data[1] + i * frame->linesize[1]);
>  v = (uint16_t*)(frame->data[2] + i * frame->linesize[2]);
> @@ -100,13 +120,20 @@ static av_cold int
> bitpacked_init_decoder(AVCodecContext *avctx)
>
>  if (avctx->codec_tag == MKTAG('U', 'Y', 'V', 'Y')) {
>  if (avctx->bits_per_coded_sample == 16 &&
> -avctx->pix_fmt == AV_PIX_FMT_UYVY422)
> +avctx->pix_fmt == AV_PIX_FMT_UYVY422) {
> +
> +if (avctx->field_order > AV_FIELD_PROGRESSIVE) {
> +av_log(avctx, AV_LOG_ERROR, "interlaced not yet supported
> for 8-bit\n");
> +return AVERROR_PATCHWELCOME;
> +}
> +
>  bc->decode = bitpacked_decode_uyvy422;
> -else if (avctx->bits_per_coded_sample == 20 &&
> - avctx->pix_fmt == AV_PIX_FMT_YUV422P10)
> +} else if