Re: [FFmpeg-devel] [PATCH 2/7] avformat: add url field to AVFormatContext

[Bang He]

On Sun, Jan 7, 2018 at 4:50 AM, Marton Balint  wrote:

> This will replace the 1024 character limited filename field. Compatiblity
> for
> output contexts are provided by copying filename field to URL if URL is
> unset
> and by providing an internal function for muxers to set both url and
> filename
> at once.
>
> Signed-off-by: Marton Balint 
> ---
>  doc/APIchanges |  3 +++
>  libavformat/avformat.h | 15 +++
>  libavformat/internal.h |  7 +++
>  libavformat/mux.c  | 11 ++-
>  libavformat/utils.c| 14 ++
>  libavformat/version.h  |  2 +-
>  6 files changed, 50 insertions(+), 2 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index d66c842521..4a91b7460a 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
>  API changes, most recent first:
>
> +2018-xx-xx - xxx - lavf 58.4.100 - avformat.h
> +  Add url field to AVFormatContext and add ff_format_set_url helper
> function.
> +
>  2018-01-xx - xxx - lavfi 7.11.101 - avfilter.h
>Deprecate avfilter_link_get_channels(). Use
> av_buffersink_get_channels().
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 4f2798a871..9fa25abd90 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1391,6 +1391,21 @@ typedef struct AVFormatContext {
>  char filename[1024];
>
>  /**
> + * input or output URL. Unlike the old filename field, this field has
> no
> + * length restriction.
> + *
> + * - demuxing: set by avformat_open_input(), initialized to an empty
> + * string if url parameter was NULL in
> avformat_open_input().
> + * - muxing: may be set by the caller before calling
> avformat_write_header()
> + *   (or avformat_init_output() if that is called first) to a
> string
> + *   which is freeable by av_free(). Set to an empty string
> if it
> + *   was NULL in avformat_init_output().
> + *
> + * Freed by libavformat in avformat_free_context().
> + */
> +char *url;
> +
> +/**
>   * Position of the first frame of the component, in
>   * AV_TIME_BASE fractional seconds. NEVER set this value directly:
>   * It is deduced from the AVStream values.
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index 0cd0556dc7..1e2a3e05a1 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -696,4 +696,11 @@ int ff_interleaved_peek(AVFormatContext *s, int
> stream,
>  int ff_lock_avformat(void);
>  int ff_unlock_avformat(void);
>
> +/**
> + * Set AVFormatContext url field to the provided pointer. The pointer must
> + * point to a valid string. The existing url field is freed if necessary.
> Also
> + * set the legacy filename field to the same string which was provided in
> url.
> + */
> +void ff_format_set_url(AVFormatContext *s, char *url);
> +
>  #endif /* AVFORMAT_INTERNAL_H */
> diff --git a/libavformat/mux.c b/libavformat/mux.c
> index ea9f13fdf5..de63f2ca25 100644
> --- a/libavformat/mux.c
> +++ b/libavformat/mux.c
> @@ -186,8 +186,12 @@ int avformat_alloc_output_context2(AVFormatContext
> **avctx, AVOutputFormat *ofor
>  } else
>  s->priv_data = NULL;
>
> -if (filename)
> +if (filename) {
>  av_strlcpy(s->filename, filename, sizeof(s->filename));
> +if (!(s->url = av_strdup(filename)))
> +goto nomem;
> +
> +}
>  *avctx = s;
>  return 0;
>  nomem:
> @@ -251,6 +255,11 @@ static int init_muxer(AVFormatContext *s,
> AVDictionary **options)
>  (ret = av_opt_set_dict2(s->priv_data, ,
> AV_OPT_SEARCH_CHILDREN)) < 0)
>  goto fail;
>
> +if (!s->url && !(s->url = av_strdup(s->filename))) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
> +
>  #if FF_API_LAVF_AVCTX
>  FF_DISABLE_DEPRECATION_WARNINGS
>  if (s->nb_streams && s->streams[0]->codec->flags &
> AV_CODEC_FLAG_BITEXACT) {
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 2185a6f05b..fdfd3a088d 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -551,6 +551,11 @@ int avformat_open_input(AVFormatContext **ps, const
> char *filename,
>  if ((ret = av_opt_set_dict(s, )) < 0)
>  goto fail;
>
> +if (!(s->url = av_strdup(filename ? filename : ""))) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> +}
> +
>  av_strlcpy(s->filename, filename ? filename : "",
> sizeof(s->filename));
>  if ((ret = init_input(s, filename, )) < 0)
>  goto fail;
> @@ -4357,6 +4362,7 @@ void avformat_free_context(AVFormatContext *s)
>  av_freep(>streams);
>  flush_packet_queue(s);
>  av_freep(>internal);
> +av_freep(>url);
>  av_free(s);
>  }
>
> @@ -5624,3 +5630,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  return st->internal->avctx->time_base;
>  #endif
>  }
> +
> +void ff_format_set_url(AVFormatContext *s, char *url)
> +{
> +  

[FFmpeg-devel] [PATCH 1/2] avdevice/decklink: addition of copyts option

[vdixit]

From: Vishwanath Dixit 

---
 doc/indevs.texi |  5 +
 libavdevice/decklink_common_c.h |  1 +
 libavdevice/decklink_dec.cpp| 18 +++---
 libavdevice/decklink_dec_c.c|  1 +
 4 files changed, 18 insertions(+), 7 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index 56066bf..36aef49 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -317,6 +317,11 @@ Defaults to @samp{1073741824}.
 Sets the audio sample bit depth. Must be @samp{16} or @samp{32}.
 Defaults to @samp{16}.
 
+@item decklink_copyts
+If set to @option{true}, timestamps are forwarded as they are without removing
+the initial offset.
+Defaults to @option{false}.
+
 @end table
 
 @subsection Examples
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index 368ac25..ac6563a 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -52,6 +52,7 @@ struct decklink_cctx {
 char *format_code;
 int raw_format;
 int64_t queue_size;
+int copyts;
 };
 
 #endif /* AVDEVICE_DECKLINK_COMMON_C_H */
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 94dae26..1fd40ca 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -586,7 +586,8 @@ static int64_t get_pkt_pts(IDeckLinkVideoInputFrame 
*videoFrame,
IDeckLinkAudioInputPacket *audioFrame,
int64_t wallclock,
DecklinkPtsSource pts_src,
-   AVRational time_base, int64_t *initial_pts)
+   AVRational time_base, int64_t *initial_pts,
+   int copyts)
 {
 int64_t pts = AV_NOPTS_VALUE;
 BMDTimeValue bmd_pts;
@@ -619,10 +620,12 @@ static int64_t get_pkt_pts(IDeckLinkVideoInputFrame 
*videoFrame,
 if (res == S_OK)
 pts = bmd_pts / time_base.num;
 
-if (pts != AV_NOPTS_VALUE && *initial_pts == AV_NOPTS_VALUE)
-*initial_pts = pts;
-if (*initial_pts != AV_NOPTS_VALUE)
-pts -= *initial_pts;
+if (!copyts) {
+if (pts != AV_NOPTS_VALUE && *initial_pts == AV_NOPTS_VALUE)
+*initial_pts = pts;
+if (*initial_pts != AV_NOPTS_VALUE)
+pts -= *initial_pts;
+}
 
 return pts;
 }
@@ -635,6 +638,7 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 BMDTimeValue frameTime;
 BMDTimeValue frameDuration;
 int64_t wallclock = 0;
+struct decklink_cctx *cctx = (struct decklink_cctx *) avctx->priv_data;
 
 if (ctx->autodetect) {
 if (videoFrame && !(videoFrame->GetFlags() & bmdFrameHasNoInputSource) 
&&
@@ -694,7 +698,7 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 no_video = 0;
 }
 
-pkt.pts = get_pkt_pts(videoFrame, audioFrame, wallclock, 
ctx->video_pts_source, ctx->video_st->time_base, _video_pts);
+pkt.pts = get_pkt_pts(videoFrame, audioFrame, wallclock, 
ctx->video_pts_source, ctx->video_st->time_base, _video_pts, 
cctx->copyts);
 pkt.dts = pkt.pts;
 
 pkt.duration = frameDuration;
@@ -785,7 +789,7 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 pkt.size = audioFrame->GetSampleFrameCount() * 
ctx->audio_st->codecpar->channels * (ctx->audio_depth / 8);
 audioFrame->GetBytes();
 audioFrame->GetPacketTime(_pts, ctx->audio_st->time_base.den);
-pkt.pts = get_pkt_pts(videoFrame, audioFrame, wallclock, 
ctx->audio_pts_source, ctx->audio_st->time_base, _audio_pts);
+pkt.pts = get_pkt_pts(videoFrame, audioFrame, wallclock, 
ctx->audio_pts_source, ctx->audio_st->time_base, _audio_pts, 
cctx->copyts);
 pkt.dts = pkt.pts;
 
 //fprintf(stderr,"Audio Frame size %d ts %d\n", pkt.size, pkt.pts);
diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
index 1c6d826..6fb5ffe 100644
--- a/libavdevice/decklink_dec_c.c
+++ b/libavdevice/decklink_dec_c.c
@@ -73,6 +73,7 @@ static const AVOption options[] = {
 { "draw_bars", "draw bars on signal loss" , OFFSET(draw_bars),
AV_OPT_TYPE_BOOL,  { .i64 = 1}, 0, 1, DEC },
 { "queue_size","input queue buffer size",   OFFSET(queue_size),   
AV_OPT_TYPE_INT64, { .i64 = (1024 * 1024 * 1024)}, 0, INT64_MAX, DEC },
 { "audio_depth",   "audio bitdepth (16 or 32)", OFFSET(audio_depth),  
AV_OPT_TYPE_INT,   { .i64 = 16}, 16, 32, DEC },
+{ "decklink_copyts", "copy timestamps, do not remove the initial offset", 
OFFSET(copyts), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, DEC },
 { NULL },
 };
 
-- 
1.9.1

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

[FFmpeg-devel] [PATCH 2/2] avdevice/decklink: addition of absolute wallclock option for pts source

[vdixit]

From: Vishwanath Dixit 

---
 doc/indevs.texi | 6 --
 libavdevice/decklink_common_c.h | 1 +
 libavdevice/decklink_dec.cpp| 3 +++
 libavdevice/decklink_dec_c.c| 5 +++--
 4 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/doc/indevs.texi b/doc/indevs.texi
index 36aef49..0bc8e6a 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -298,11 +298,13 @@ Sets the audio input source. Must be @samp{unset}, 
@samp{embedded},
 
 @item video_pts
 Sets the video packet timestamp source. Must be @samp{video}, @samp{audio},
-@samp{reference} or @samp{wallclock}. Defaults to @samp{video}.
+@samp{reference}, @samp{wallclock} or @samp{abs_wallclock}.
+Defaults to @samp{video}.
 
 @item audio_pts
 Sets the audio packet timestamp source. Must be @samp{video}, @samp{audio},
-@samp{reference} or @samp{wallclock}. Defaults to @samp{audio}.
+@samp{reference}, @samp{wallclock} or @samp{abs_wallclock}.
+Defaults to @samp{audio}.
 
 @item draw_bars
 If set to @samp{true}, color bars are drawn in the event of a signal loss.
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index ac6563a..d726190 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -28,6 +28,7 @@ typedef enum DecklinkPtsSource {
 PTS_SRC_VIDEO = 2,
 PTS_SRC_REFERENCE = 3,
 PTS_SRC_WALLCLOCK = 4,
+PTS_SRC_ABS_WALLCLOCK = 5,
 } DecklinkPtsSource;
 
 struct decklink_cctx {
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 1fd40ca..6bbfe62 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -607,6 +607,7 @@ static int64_t get_pkt_pts(IDeckLinkVideoInputFrame 
*videoFrame,
 res = videoFrame->GetHardwareReferenceTimestamp(time_base.den, 
_pts, _duration);
 break;
 case PTS_SRC_WALLCLOCK:
+case PTS_SRC_ABS_WALLCLOCK:
 {
 /* MSVC does not support compound literals like AV_TIME_BASE_Q
  * in C++ code (compiler error C4576) */
@@ -652,6 +653,8 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 ctx->frameCount++;
 if (ctx->audio_pts_source == PTS_SRC_WALLCLOCK || ctx->video_pts_source == 
PTS_SRC_WALLCLOCK)
 wallclock = av_gettime_relative();
+else if(ctx->audio_pts_source == PTS_SRC_ABS_WALLCLOCK || 
ctx->video_pts_source == PTS_SRC_ABS_WALLCLOCK)
+wallclock = av_gettime();
 
 // Handle Video Frame
 if (videoFrame) {
diff --git a/libavdevice/decklink_dec_c.c b/libavdevice/decklink_dec_c.c
index 6fb5ffe..c8f6f35 100644
--- a/libavdevice/decklink_dec_c.c
+++ b/libavdevice/decklink_dec_c.c
@@ -64,12 +64,13 @@ static const AVOption options[] = {
 { "analog_xlr",NULL,  0,  
AV_OPT_TYPE_CONST, { .i64 = 4}, 0, 0,DEC, "audio_input"},
 { "analog_rca",NULL,  0,  
AV_OPT_TYPE_CONST, { .i64 = 5}, 0, 0,DEC, "audio_input"},
 { "microphone",NULL,  0,  
AV_OPT_TYPE_CONST, { .i64 = 6}, 0, 0,DEC, "audio_input"},
-{ "audio_pts", "audio pts source",   OFFSET(audio_pts_source),
AV_OPT_TYPE_INT,   { .i64 = PTS_SRC_AUDIO}, 1, 4, DEC, "pts_source"},
-{ "video_pts", "video pts source",   OFFSET(video_pts_source),
AV_OPT_TYPE_INT,   { .i64 = PTS_SRC_VIDEO}, 1, 4, DEC, "pts_source"},
+{ "audio_pts", "audio pts source",   OFFSET(audio_pts_source),
AV_OPT_TYPE_INT,   { .i64 = PTS_SRC_AUDIO}, 1, 5, DEC, "pts_source"},
+{ "video_pts", "video pts source",   OFFSET(video_pts_source),
AV_OPT_TYPE_INT,   { .i64 = PTS_SRC_VIDEO}, 1, 5, DEC, "pts_source"},
 { "audio", NULL,  0,  
AV_OPT_TYPE_CONST, { .i64 = PTS_SRC_AUDIO}, 0, 0, DEC, "pts_source"},
 { "video", NULL,  0,  
AV_OPT_TYPE_CONST, { .i64 = PTS_SRC_VIDEO}, 0, 0, DEC, "pts_source"},
 { "reference", NULL,  0,  
AV_OPT_TYPE_CONST, { .i64 = PTS_SRC_REFERENCE}, 0, 0, DEC, "pts_source"},
 { "wallclock", NULL,  0,  
AV_OPT_TYPE_CONST, { .i64 = PTS_SRC_WALLCLOCK}, 0, 0, DEC, "pts_source"},
+{ "abs_wallclock", NULL,  0,  
AV_OPT_TYPE_CONST, { .i64 = PTS_SRC_ABS_WALLCLOCK}, 0, 0, DEC, "pts_source"},
 { "draw_bars", "draw bars on signal loss" , OFFSET(draw_bars),
AV_OPT_TYPE_BOOL,  { .i64 = 1}, 0, 1, DEC },
 { "queue_size","input queue buffer size",   OFFSET(queue_size),   
AV_OPT_TYPE_INT64, { .i64 = (1024 * 1024 * 1024)}, 0, INT64_MAX, DEC },
 { "audio_depth",   "audio bitdepth (16 or 32)", OFFSET(audio_depth),  
AV_OPT_TYPE_INT,   { .i64 = 16}, 16, 32, DEC },
-- 
1.9.1

___
ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH] fate/filter-video: fix 12 bit framerate filter tests on big endian targets

[James Almer]

On 1/8/2018 12:05 AM, Michael Niedermayer wrote:
> On Sun, Jan 07, 2018 at 12:29:36AM -0300, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>>  tests/fate/filter-video.mak | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> seems to work on mips qemu
> 
> thx

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

Re: [FFmpeg-devel] [PATCH] avcodec: increase AV_INPUT_BUFFER_PADDING_SIZE to 64

[Michael Niedermayer]

On Sun, Jan 07, 2018 at 11:42:25PM -0300, James Almer wrote:
> On 1/7/2018 11:06 PM, Michael Niedermayer wrote:
> > On Sun, Jan 07, 2018 at 01:22:38AM -0300, James Almer wrote:
> >> AVX-512 support has been introduced, and even if no functions currently
> >> use zmm registers (able to load as much as 64 bytes of consecutive data
> >> per instruction), they will be added eventually.
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >> Same rationale as when it was increased to 32 back in commit
> >> 67d29da4bd23057a1f646568442a77b844cb2d1b.
> >>
> >>  libavcodec/avcodec.h  | 2 +-
> >>  libavcodec/x86/hevc_sao.asm   | 2 +-
> >>  libavcodec/x86/hevc_sao_10bit.asm | 2 +-
> >>  3 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > causes assertion failure:
> > ./ffmpeg -i bgc.sub.dub.ogm x.webm
> > 
> > Assertion 64 <= 52 failed at libavformat/oggparseogm.c:109
> > Aborted (core dumped)
> 
> How do you say this should be fixed? Why should
> AV_INPUT_BUFFER_PADDING_SIZE be lower or equal to 52?
> 
> I have no idea about OGM, so i could use some help.

cc-ing reimar, maybe he remembers, the assert seems to come from:

commit 7c8d477299c9b5e89fc30ed22f9e42b50761342c
Author: Reimar Döffinger 
Date:   Mon Feb 6 22:04:46 2012 +0100

Make AAC in Ogg (ogm) work.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] fate/filter-video: fix 12 bit framerate filter tests on big endian targets

[Michael Niedermayer]

On Sun, Jan 07, 2018 at 12:29:36AM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  tests/fate/filter-video.mak | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

seems to work on mips qemu

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

Re: [FFmpeg-devel] [PATCH 6/6] dashdec: Support SegmentTemplate inside Period

[刘歧]

> On 8 Jan 2018, at 02:46, Stefan _  wrote:
> 
> <0006-dashdec-Support-SegmentTemplate-inside-Period.patch>

>From 89b42dc60156f1e030a30e13636651db41e9f34b Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Fri, 5 Jan 2018 15:32:23 +0100
Subject: [PATCH 6/6] dashdec: Support SegmentTemplate inside Period

---
 libavformat/dashdec.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index af8ab5f2f..ac1080b62 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -646,6 +646,7 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
  xmlNodePtr adaptionset_node,
  xmlNodePtr mpd_baseurl_node,
  xmlNodePtr period_baseurl_node,
+ xmlNodePtr 
period_segmenttemplate_node,
  xmlNodePtr fragment_template_node,
  xmlNodePtr content_component_node,
  xmlNodePtr adaptionset_baseurl_node,
@@ -662,7 +663,7 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
 xmlNodePtr representation_segmentlist_node = NULL;
 xmlNodePtr segmentlists_tab[2];
 xmlNodePtr fragment_timeline_node = NULL;
-xmlNodePtr fragment_templates_tab[3];
+xmlNodePtr fragment_templates_tab[4];
 char *duration_val = NULL;
 char *presentation_timeoffset_val = NULL;
 char *startnumber_val = NULL;
@@ -702,18 +703,19 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
 baseurl_nodes[2] = adaptionset_baseurl_node;
 baseurl_nodes[3] = representation_baseurl_node;
 
-if (representation_segmenttemplate_node || fragment_template_node) {
+if (representation_segmenttemplate_node || fragment_template_node || 
period_segmenttemplate_node) {
 fragment_timeline_node = NULL;
 fragment_templates_tab[0] = representation_segmenttemplate_node;
 fragment_templates_tab[1] = adaptionset_segmentlist_node;
 fragment_templates_tab[2] = fragment_template_node;
+fragment_templates_tab[3] = period_segmenttemplate_node;
 
-presentation_timeoffset_val = 
get_val_from_nodes_tab(fragment_templates_tab, 3, "presentationTimeOffset");
-duration_val = get_val_from_nodes_tab(fragment_templates_tab, 3, 
"duration");
-startnumber_val = get_val_from_nodes_tab(fragment_templates_tab, 
3, "startNumber");
-timescale_val = get_val_from_nodes_tab(fragment_templates_tab, 3, 
"timescale");
-initialization_val = 
get_val_from_nodes_tab(fragment_templates_tab, 3, "initialization");
-media_val = get_val_from_nodes_tab(fragment_templates_tab, 3, 
"media");
+presentation_timeoffset_val = 
get_val_from_nodes_tab(fragment_templates_tab, 4, "presentationTimeOffset");
+duration_val = get_val_from_nodes_tab(fragment_templates_tab, 4, 
"duration");
+startnumber_val = get_val_from_nodes_tab(fragment_templates_tab, 
4, "startNumber");
+timescale_val = get_val_from_nodes_tab(fragment_templates_tab, 4, 
"timescale");
+initialization_val = 
get_val_from_nodes_tab(fragment_templates_tab, 4, "initialization");
+media_val = get_val_from_nodes_tab(fragment_templates_tab, 4, 
"media");
 
 if (initialization_val) {
 rep->init_section = av_mallocz(sizeof(struct fragment));
@@ -866,7 +868,8 @@ end:
 static int parse_manifest_adaptationset(AVFormatContext *s, const char *url,
 xmlNodePtr adaptionset_node,
 xmlNodePtr mpd_baseurl_node,
-xmlNodePtr period_baseurl_node)
+xmlNodePtr period_baseurl_node,
+xmlNodePtr period_segmenttemplate_node)
 {
 int ret = 0;
 xmlNodePtr fragment_template_node = NULL;
@@ -890,6 +893,7 @@ static int parse_manifest_adaptationset(AVFormatContext *s, 
const char *url,
 adaptionset_node,
 mpd_baseurl_node,
 period_baseurl_node,
+period_segmenttemplate_node,
 fragment_template_node,
 content_component_node,
 adaptionset_baseurl_node,
@@ -918,6 +922,7 @@ static int parse_manifest(AVFormatContext *s, const char 
*url, AVIOContext *in)
 xmlNodePtr period_node = NULL;
 xmlNodePtr 

Re: [FFmpeg-devel] [PATCH 5/6] dashdec: Avoid trying to read any segments beyond the last

[刘歧]

> On 8 Jan 2018, at 02:46, Stefan _  wrote:
> 
> 
> <0005-dashdec-Avoid-trying-to-read-any-segments-beyond-the.patch>___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

>From 277c710159849816bff4e4f5ccd1139348518620 Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Fri, 5 Jan 2018 14:19:25 +0100
Subject: [PATCH 5/6] dashdec: Avoid trying to read any segments beyond the
 last

---
 libavformat/dashdec.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 1252d4156..af8ab5f2f 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1505,9 +1505,11 @@ restart:
 if (ret > 0)
 goto end;
 
-if (!v->is_restart_needed)
-v->cur_seq_no++;
-v->is_restart_needed = 1;
+if (c->is_live || v->cur_seq_no < v->last_seq_no) {
+   if (!v->is_restart_needed)
+   v->cur_seq_no++;
+   v->is_restart_needed = 1;
+}
 
 end:
 return ret;
-- 
2.15.1



LGTM

Thanks

Steven

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

Re: [FFmpeg-devel] [PATCH 4/6] dashdec: Correct seeking behaviour

[刘歧]

> On 8 Jan 2018, at 02:46, Stefan _  wrote:
> 
> 
> <0004-dashdec-Correct-seeking-behaviour.patch>___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

>From bdf3557a400620fce66ca0237f1ff172c227609b Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Fri, 5 Jan 2018 00:51:32 +0100
Subject: [PATCH 4/6] dashdec: Correct seeking behaviour

dash_read_seek() is called only once to issue a seek
of *all* streams to the specified timestamp. But to
avoid reopening each stream, do a "dry run" for streams
that are in a discarded state.
---
 libavformat/dashdec.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index ac0e6c6f9..1252d4156 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1828,19 +1828,22 @@ static int dash_close(AVFormatContext *s)
 return 0;
 }
 
-static int dash_seek(AVFormatContext *s, struct representation *pls, int64_t 
seek_pos_msec, int flags)
+static int dash_seek(AVFormatContext *s, struct representation *pls, int64_t 
seek_pos_msec, int flags, int dry_run)
 {
 int ret = 0;
 int i = 0;
 int j = 0;
 int64_t duration = 0;
 
-av_log(pls->parent, AV_LOG_VERBOSE, "DASH seek pos[%"PRId64"ms], playlist 
%d\n", seek_pos_msec, pls->rep_idx);
+av_log(pls->parent, AV_LOG_VERBOSE, "DASH seek pos[%"PRId64"ms], playlist 
%d%s\n",
+seek_pos_msec, pls->rep_idx, dry_run ? " (dry)" : "");
 
 // single fragment mode
 if (pls->n_fragments == 1) {
 pls->cur_timestamp = 0;
 pls->cur_seg_offset = 0;
+if (dry_run)
+return 0;
 ff_read_frame_flush(pls->ctx);
 return av_seek_frame(pls->ctx, -1, seek_pos_msec * 1000, flags);
 }
@@ -1885,14 +1888,14 @@ set_seq_num:
 pls->cur_timestamp = 0;
 pls->cur_seg_offset = 0;
 pls->init_sec_buf_read_offset = 0;
-ret = reopen_demux_for_component(s, pls);
+ret = dry_run ? 0 : reopen_demux_for_component(s, pls);
 
 return ret;
 }
 
 static int dash_read_seek(AVFormatContext *s, int stream_index, int64_t 
timestamp, int flags)
 {
-int ret, i;
+int ret = 0, i;
 DASHContext *c = s->priv_data;
 int64_t seek_pos_msec = av_rescale_rnd(timestamp, 1000,

s->streams[stream_index]->time_base.den,
@@ -1901,16 +1904,14 @@ static int dash_read_seek(AVFormatContext *s, int 
stream_index, int64_t timestam
 if ((flags & AVSEEK_FLAG_BYTE) || c->is_live)
 return AVERROR(ENOSYS);
 
-ret = AVERROR_EOF;
+/* Seek in discarded streams with dry_run=1 to avoid reopening them */
 for (i = 0; i < c->n_videos; i++) {
-if (c->videos[i]->stream_index == stream_index) {
-ret = dash_seek(s, c->videos[i], seek_pos_msec, flags);
-}
+if (!ret)
+ret = dash_seek(s, c->videos[i], seek_pos_msec, flags, 
!c->videos[i]->ctx);
 }
 for (i = 0; i < c->n_audios; i++) {
-if (c->audios[i]->stream_index == stream_index) {
-ret = dash_seek(s, c->audios[i], seek_pos_msec, flags);
-}
+if (!ret)
+ret = dash_seek(s, c->audios[i], seek_pos_msec, flags, 
!c->audios[i]->ctx);
 }
 
 return ret;
-- 
2.15.1




LGTM

Thanks

Steven

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

Re: [FFmpeg-devel] [PATCH 3/6] dashdec: Search for segment timeline inside AdaptionSets too

[刘歧]

> On 8 Jan 2018, at 02:46, Stefan _  wrote:
> 
> 
> <0003-dashdec-Search-for-segment-timeline-inside-AdaptionS.patch>___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

>From c06d6cbcdc9092428d3764a969604d1f22725e56 Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Fri, 5 Jan 2018 00:19:53 +0100
Subject: [PATCH 3/6] dashdec: Search for segment timeline inside AdaptionSets
 too

---
 libavformat/dashdec.c | 40 +++-
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 676979638..ac0e6c6f9 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -648,7 +648,8 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
  xmlNodePtr period_baseurl_node,
  xmlNodePtr fragment_template_node,
  xmlNodePtr content_component_node,
- xmlNodePtr adaptionset_baseurl_node)
+ xmlNodePtr adaptionset_baseurl_node,
+ xmlNodePtr 
adaptionset_segmentlist_node)
 {
 int32_t ret = 0;
 int32_t audio_rep_idx = 0;
@@ -659,8 +660,9 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
 xmlNodePtr representation_segmenttemplate_node = NULL;
 xmlNodePtr representation_baseurl_node = NULL;
 xmlNodePtr representation_segmentlist_node = NULL;
+xmlNodePtr segmentlists_tab[2];
 xmlNodePtr fragment_timeline_node = NULL;
-xmlNodePtr fragment_templates_tab[2];
+xmlNodePtr fragment_templates_tab[3];
 char *duration_val = NULL;
 char *presentation_timeoffset_val = NULL;
 char *startnumber_val = NULL;
@@ -703,14 +705,15 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
 if (representation_segmenttemplate_node || fragment_template_node) {
 fragment_timeline_node = NULL;
 fragment_templates_tab[0] = representation_segmenttemplate_node;
-fragment_templates_tab[1] = fragment_template_node;
+fragment_templates_tab[1] = adaptionset_segmentlist_node;
+fragment_templates_tab[2] = fragment_template_node;
 
-presentation_timeoffset_val = 
get_val_from_nodes_tab(fragment_templates_tab, 2, "presentationTimeOffset");
-duration_val = get_val_from_nodes_tab(fragment_templates_tab, 2, 
"duration");
-startnumber_val = get_val_from_nodes_tab(fragment_templates_tab, 
2, "startNumber");
-timescale_val = get_val_from_nodes_tab(fragment_templates_tab, 2, 
"timescale");
-initialization_val = 
get_val_from_nodes_tab(fragment_templates_tab, 2, "initialization");
-media_val = get_val_from_nodes_tab(fragment_templates_tab, 2, 
"media");
+presentation_timeoffset_val = 
get_val_from_nodes_tab(fragment_templates_tab, 3, "presentationTimeOffset");
+duration_val = get_val_from_nodes_tab(fragment_templates_tab, 3, 
"duration");
+startnumber_val = get_val_from_nodes_tab(fragment_templates_tab, 
3, "startNumber");
+timescale_val = get_val_from_nodes_tab(fragment_templates_tab, 3, 
"timescale");
+initialization_val = 
get_val_from_nodes_tab(fragment_templates_tab, 3, "initialization");
+media_val = get_val_from_nodes_tab(fragment_templates_tab, 3, 
"media");
 
 if (initialization_val) {
 rep->init_section = av_mallocz(sizeof(struct fragment));
@@ -756,6 +759,8 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
 
 if (!fragment_timeline_node)
 fragment_timeline_node = 
find_child_node_by_name(fragment_template_node, "SegmentTimeline");
+if (!fragment_timeline_node)
+fragment_timeline_node = 
find_child_node_by_name(adaptionset_segmentlist_node, "SegmentTimeline");
 if (fragment_timeline_node) {
 fragment_timeline_node = 
xmlFirstElementChild(fragment_timeline_node);
 while (fragment_timeline_node) {
@@ -784,8 +789,11 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
 // TODO: 
https://www.brendanlong.com/the-structure-of-an-mpeg-dash-mpd.html
 // 
http://www-itec.uni-klu.ac.at/dash/ddash/mpdGenerator.php?fragmentlength=15=full
 xmlNodePtr fragmenturl_node = NULL;
-duration_val = xmlGetProp(representation_segmentlist_node, 
"duration");
-timescale_val = xmlGetProp(representation_segmentlist_node, 
"timescale");
+segmentlists_tab[0] = representation_segmentlist_node;
+segmentlists_tab[1] = 

Re: [FFmpeg-devel] [PATCH 1/6] dashdec: Expose bandwidth and representation ID as metadata

[刘歧]

> On 8 Jan 2018, at 02:46, Stefan _  wrote:
> 
> <0001-dashdec-Expose-bandwidth-and-representation-ID-as-me.patch>

>From ba640900c260f8b5b1919c4274b2c2e3e57e2546 Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Thu, 4 Jan 2018 23:45:26 +0100
Subject: [PATCH 1/6] dashdec: Expose bandwidth and representation ID as
 metadata

---
 libavformat/dashdec.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 0e3afd2a3..1a18ab021 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -84,6 +84,8 @@ struct representation {
 int stream_index;
 
 enum AVMediaType type;
+char id[20];
+int bandwidth;
 
 int n_fragments;
 struct fragment **fragments; /* VOD list of fragment for profile */
@@ -801,6 +803,8 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
 if (rep) {
 if (rep->fragment_duration > 0 && !rep->fragment_timescale)
 rep->fragment_timescale = 1;
+rep->bandwidth = rep_bandwidth_val ? atoi(rep_bandwidth_val) : 0;
+strncpy(rep->id, rep_id_val ? rep_id_val : "", sizeof(rep->id));
 if (type == AVMEDIA_TYPE_VIDEO) {
 rep->rep_idx = video_rep_idx;
 c->cur_video = rep;
@@ -1650,10 +1654,20 @@ static int dash_read_header(AVFormatContext *s)
 }
 
 if (c->cur_video) {
-av_program_add_stream_index(s, 0, c->cur_video->stream_index);
+int stream_index = c->cur_video->stream_index;
+av_program_add_stream_index(s, 0, stream_index);
+if (c->cur_video->bandwidth > 0)
+av_dict_set_int(>streams[stream_index]->metadata, 
"variant_bitrate", c->cur_video->bandwidth, 0);
+if (c->cur_video->id[0])
+av_dict_set(>streams[stream_index]->metadata, "id", 
c->cur_video->id, 0);
 }
 if (c->cur_audio) {
-av_program_add_stream_index(s, 0, c->cur_audio->stream_index);
+int stream_index = c->cur_audio->stream_index;
+av_program_add_stream_index(s, 0, stream_index);
+if (c->cur_audio->bandwidth > 0)
+av_dict_set_int(>streams[stream_index]->metadata, 
"variant_bitrate", c->cur_audio->bandwidth, 0);
+if (c->cur_audio->id[0])
+av_dict_set(>streams[stream_index]->metadata, "id", 
c->cur_audio->id, 0);
 }
 }
 
-- 
2.15.1





LGTM


Thanks
Steven

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

Re: [FFmpeg-devel] [PATCH] avcodec: increase AV_INPUT_BUFFER_PADDING_SIZE to 64

[James Almer]

On 1/7/2018 11:06 PM, Michael Niedermayer wrote:
> On Sun, Jan 07, 2018 at 01:22:38AM -0300, James Almer wrote:
>> AVX-512 support has been introduced, and even if no functions currently
>> use zmm registers (able to load as much as 64 bytes of consecutive data
>> per instruction), they will be added eventually.
>>
>> Signed-off-by: James Almer 
>> ---
>> Same rationale as when it was increased to 32 back in commit
>> 67d29da4bd23057a1f646568442a77b844cb2d1b.
>>
>>  libavcodec/avcodec.h  | 2 +-
>>  libavcodec/x86/hevc_sao.asm   | 2 +-
>>  libavcodec/x86/hevc_sao_10bit.asm | 2 +-
>>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> causes assertion failure:
> ./ffmpeg -i bgc.sub.dub.ogm x.webm
> 
> Assertion 64 <= 52 failed at libavformat/oggparseogm.c:109
> Aborted (core dumped)

How do you say this should be fixed? Why should
AV_INPUT_BUFFER_PADDING_SIZE be lower or equal to 52?

I have no idea about OGM, so i could use some help.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: increase AV_INPUT_BUFFER_PADDING_SIZE to 64

[Michael Niedermayer]

On Sun, Jan 07, 2018 at 01:22:38AM -0300, James Almer wrote:
> AVX-512 support has been introduced, and even if no functions currently
> use zmm registers (able to load as much as 64 bytes of consecutive data
> per instruction), they will be added eventually.
> 
> Signed-off-by: James Almer 
> ---
> Same rationale as when it was increased to 32 back in commit
> 67d29da4bd23057a1f646568442a77b844cb2d1b.
> 
>  libavcodec/avcodec.h  | 2 +-
>  libavcodec/x86/hevc_sao.asm   | 2 +-
>  libavcodec/x86/hevc_sao_10bit.asm | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)

causes assertion failure:
./ffmpeg -i bgc.sub.dub.ogm x.webm

Assertion 64 <= 52 failed at libavformat/oggparseogm.c:109
Aborted (core dumped)

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

No great genius has ever existed without some touch of madness. -- 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 4/5] aptx: implement the aptX HD bluetooth codec

[Compn]

On Mon, 8 Jan 2018 00:38:19 +, Rostislav Pehlivanov
 wrote:
> > > No, don't add a new codec ID for what is very obviously a profile.
> > Anyway, I do understand how I could use a profile instead of a new codec
> > ID, but I really don't understand what advantage it would bring ?
> > itself to any profile, that makes a lot of sense. But for aptX and
> > aptX HD it doesn't make any sense to me.

in ffmpeg we generally try not to create new original internal fourcc /
isom tags. because then people think our tag is the real spec tag, and
then bad things happen.

if another software uses the tag or the sample of that tag is in the
wild then we use it.

i dont know enough about aptx / aptx hd to make an opinion. 

some codecs make different tags for stupid things, like sony hdcam
has different tags for different fps. we support these tags because
other software uses them and samples exist in the wild.

not sure if i've helped here.

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

[FFmpeg-devel] dumpwave audio filter

[dmitry . gumenyuk]

Let me introduce dumpwave waveform audio filter – dumps RMS amplitude to JSON 
file just like SoundCloud does
As there is no duration knowledge, samples count should be precalculated
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [Cellar] [PATCH] FFV1: make RGB48 support as non-experimental

[Compn]

On Sun, 7 Jan 2018 21:20:15 +0100, Jerome Martinez
 wrote:

> - I have an early (not yet public, for testing the spec only for the 
> moment) version of an encoder conforming to the spec for all bit depths 
> up to 30-bit per component.
> - I have heard about other FFV1 encoders able to encode RGB48

i am curious what are the names of the other ffv1 encoders? 


> I confirm that RGB48 files are already in the wild, as it is needed 

please upload or link to one of these RGB48 samples and ffmpeg will
support it.

i think i can clear up the confusion between you and michael.

michael does not want to add in a defined way to do other bitdepths
without the spec people agreeing on a spec for this.

michael does want to support your higher bitdepth ffv1 samples. 

the confusion was because he thought you wanted to modify the spec /
encoder and not just the ability to decode such files.

hope this helps.

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

Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

[Rostislav Pehlivanov]

On 7 January 2018 at 22:54, Aurelien Jacobs  wrote:

> On Sun, Jan 07, 2018 at 05:23:24PM +, Rostislav Pehlivanov wrote:
> > On 6 January 2018 at 16:48, Aurelien Jacobs  wrote:
> >
> > > ---
> > >  Changelog   |   2 +-
> > >  configure   |   2 +
> > >  libavcodec/Makefile |   2 +
> > >  libavcodec/allcodecs.c  |   1 +
> > >  libavcodec/aptx.c   | 352 ++
> > > ++
> > >  libavcodec/avcodec.h|   1 +
> > >  libavcodec/codec_desc.c |   7 +
> > >  7 files changed, 339 insertions(+), 28 deletions(-)
> >
> >
> > No, don't add a new codec ID for what is very obviously a profile.
> >
> > Here's what you need to do:
> >
> > 1.) Add FF_PROFILE_APTX_HD to libavcodec/avcodec.h
> > 2.) During parsing set par->profile to FF_PROFILE_APTX_HD
>
> Parsing ? Do you mean demuxer ?
> There is no aptx parser for now.
>

Sorry, I meant demuxer.



> > 3.) During decoding init set s->hd to avctx->profile ==
> FF_PROFILE_APTX_HD
> >  - or better yet don't add a bool variable but do this check every
> time
> > something is different
>
> The bool variable makes things easier because the avctx is not
> accessible to functions using it.
>

That's okay, I don't mind.



> Anyway, I do understand how I could use a profile instead of a new codec
> ID, but I really don't understand what advantage it would bring ?
>
> For a codec known with one name, but supporting a lot of different
> profiles with flags in the bitstream so that the decoder can adapt
> itself to any profile, that makes a lot of sense. But for aptX and
> aptX HD it doesn't make any sense to me.
>

It makes sense - HD is just a flavor of aptx. You can't call this a brand
new codec - it just changes some tables and the way codewords are written
(1 function). The only people who would call that brand new are in
marketing and they're wrong. This is just changes the tables and the way
codewords are written in order to optimize the codec for a different
bitrate. That's all, not a new codec, its too small a change. Its a profile.



> I don't think it would make the code simpler.
> The decoder itself has no flag in the bitstream to adapt to the correct
> "profile".
>
And I think it would be confusing for end user. aptX HD is publicly know
> as a different codec than aptX. A user looking at the list of supported
> codec would probably conclude that aptX is supported but not aptX HD.
>
> Also, the closest thing I can think as a standard container for aptX
> is the bluetooth A2DP protocol. And in this protocol, aptX and aptX HD
> are differentiated with a different codec ID, just the same way they
> are differentiated from SBC or LDAC.
>
> So in the end, using different codec ID seems pretty natural, while
> using different profiles seems akward and doesn't seem to bring any
> advantage.
>
> Can you give any technical reason why think using profile would be
> better ?
>

Yes, a big one - we don't bloat the already humongous API. You might say:
"Well, we have hundreds of codec IDs, what's one more?". If we had a new
codec ID for every flavor of every codec, we'd have thousands. The profile
system saves us a decent dozen for when there are differences besides the
"there's one extra block of bits/there's some reordering" - which remain
hidden by the decoder. In that case, as far as the user is concerned
they're not decoding a Chinese Y528 codec, an H264 variant with 1 extra bit
of padding found in one province's TV broadcast to region lock, they're
decoding regular H264.
The profile systems allows us to discern between actually marketed variants
of one codec with the same name, for example AAC-LC with AAC-LTP. The LTP
profile of AAC is quite similar in what it aims to do compared to aptx HD -
its just the same baseline codec with some changes to make it work better
for a particular bitrate.



> > Could you do this for sbc as well so we can get that merged finally?
>
> I already replied to this in the SBC thread, and the discussion should
> probably continue there, but in the case of SBC, using profile is
> even more problematic as SBC and mSBC don't support the same samplerate,
> and having a single codec prevent to have too different samplerate
> lists and prevent ffmpeg to automatically convert input audio to the
> only samplerate supported by mSBC.
>

That's okay - for encoding switch the profile depending on both the
avctx->profile setting and the samplerate and list all supported
samplerates for all profiles in the AVCodec structure. We do something
similar in the AAC encoder where we pick different settings depending on
the profile and change the profile depending on the settings listed.
If there's an overlap, pick a sane default unless the user forces a profile
using profile:a. If forced and the samplerate isn't supported - error out
and let the user know.
For decoding set the profile via the demuxer. There doesn't have to be just
one demuxer for a codec. 

[FFmpeg-devel] [PATCH] avfilter: add dumpwave filter.

[dmitry . gumenyuk]

From: Dmytro Humeniuk 

Signed-off-by: Dmytro Humeniuk 
---
 Changelog  |   1 +
 libavfilter/Makefile   |   1 +
 libavfilter/af_dumpwave.c  | 273 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/version.h  |   4 +-
 tests/fate/filter-audio.mak|   5 +
 tests/ref/fate/filter-dumpwave |   1 +
 7 files changed, 284 insertions(+), 2 deletions(-)
 create mode 100644 libavfilter/af_dumpwave.c
 create mode 100644 tests/ref/fate/filter-dumpwave

diff --git a/Changelog b/Changelog
index 61075b3392..40fd624449 100644
--- a/Changelog
+++ b/Changelog
@@ -38,6 +38,7 @@ version :
 - Removed the ffserver program
 - Removed the ffmenc and ffmdec muxer and demuxer
 - VideoToolbox HEVC encoder and hwaccel
+- dumpwave audio filter
 
 
 version 3.4:
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 256dfabd66..020d90ee01 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -122,6 +122,7 @@ OBJS-$(CONFIG_TREMOLO_FILTER)+= af_tremolo.o
 OBJS-$(CONFIG_VIBRATO_FILTER)+= af_vibrato.o 
generate_wave_table.o
 OBJS-$(CONFIG_VOLUME_FILTER) += af_volume.o
 OBJS-$(CONFIG_VOLUMEDETECT_FILTER)   += af_volumedetect.o
+OBJS-$(CONFIG_DUMPWAVE_FILTER)   += af_dumpwave.o
 
 OBJS-$(CONFIG_AEVALSRC_FILTER)   += aeval.o
 OBJS-$(CONFIG_ANOISESRC_FILTER)  += asrc_anoisesrc.o
diff --git a/libavfilter/af_dumpwave.c b/libavfilter/af_dumpwave.c
new file mode 100644
index 00..493b5b7ff2
--- /dev/null
+++ b/libavfilter/af_dumpwave.c
@@ -0,0 +1,273 @@
+/*
+ * Copyright (c) 2017 Dmytro Humeniuk
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * waveform audio filter – dumps RMS amplitude to JSON file like SoundCloud 
does
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/opt.h"
+#include "libavutil/parseutils.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "audio.h"
+#include "internal.h"
+
+typedef struct DumpWaveContext {
+const AVClass *class;
+int w, h;
+AVRational rate;
+int col;
+char *json;
+char *str;
+double *values;
+int64_t c, n, max_samples;
+double sum; /* sum of the squared samples per segment */
+} DumpWaveContext;
+
+#define OFFSET(x) offsetof(DumpWaveContext, x)
+#define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption dumpwave_options[] = {
+{ "s","set dump size", OFFSET(w), AV_OPT_TYPE_IMAGE_SIZE, {.str = 
"600x240"}, 0, 0, FLAGS },
+{ "c", "set number of samples per item",  OFFSET(c), AV_OPT_TYPE_INT64,  
{.i64 = 0}, 0, INT64_MAX, FLAGS },
+{ "json", "set dump file", OFFSET(json), AV_OPT_TYPE_STRING, { .str = NULL 
}, 0, 0, FLAGS },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(dumpwave);
+
+static int config_output(AVFilterLink *outlink)
+{
+DumpWaveContext *dumpwave = outlink->src->priv;
+const int ch_width = dumpwave->w;
+dumpwave->values = av_malloc(ch_width * sizeof(double));
+dumpwave->str = av_malloc(ch_width*sizeof(int));
+dumpwave->max_samples = dumpwave->c * outlink->channels;
+
+return 0;
+}
+
+static av_cold void uninit(AVFilterContext *ctx)
+{
+DumpWaveContext *dumpwave = ctx->priv;
+const int ch_height = dumpwave->h;
+const int ch_width = dumpwave->w;
+char *result = dumpwave->str;
+FILE *dump_fp = NULL;
+
+if (dumpwave->json && !(dump_fp = av_fopen_utf8(dumpwave->json, "w")))
+av_log(ctx, AV_LOG_WARNING, "dump failed.\n");
+
+if (dump_fp) {
+fprintf(dump_fp, "{\"width\":%d,\"height\":%d,\"samples\":[%s]}", 
ch_width, ch_height, result);
+fclose(dump_fp);
+}
+av_freep(>str);
+av_freep(>values);
+}
+
+static int dumpwave_request_frame(AVFilterLink *outlink)
+{
+AVFilterContext *ctx = outlink->src;
+DumpWaveContext *dumpwave = ctx->priv;
+const int ch_height = dumpwave->h;
+const int ch_width = dumpwave->w;
+const double *values = dumpwave->values;
+char *result = dumpwave->str;
+
+AVFilterLink *inlink = ctx->inputs[0];
+int 

Re: [FFmpeg-devel] [PATCH 1/2] kavcodec/jpeg2000dsp: Fix integer overflows in ict_int()

[Michael Niedermayer]

On Sun, Jan 07, 2018 at 04:16:34AM +0100, Carl Eugen Hoyos wrote:
> 2018-01-07 4:12 GMT+01:00 Michael Niedermayer :
> > Fixes: signed integer overflow: 46802 * -71230 cannot be represented in 
> > type 'int'
> > Fixes: 4756/clusterfuzz-testcase-minimized-4812495563784192
> 
> First letter of commit message...

thx, will push with that fixed

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

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


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

Re: [FFmpeg-devel] [PATCH 4/4] avformat/libopenmpt: Probe file format from file data if possible

[Carl Eugen Hoyos]

2018-01-07 15:40 GMT+01:00 Jörn Heusipp :
>
> On 01/06/2018 04:10 PM, Carl Eugen Hoyos wrote:
>>
>> 2018-01-06 11:07 GMT+01:00 Jörn Heusipp
>> :
>
>
>>> libopenmpt file header probing is tested regularly against the FATE
>>> suite and other diverse file collections by libopenmpt upstream in
>>> order to avoid false positives.
>>
>>
>> You could also test tools/probetest
>
>
> I was not aware of that tool. Thanks for the suggestion.
>
> It currently lists a failure related to libopenmpt:
> Failure of libopenmpt probing code with score=76 type=0 p=FDC size=1024

I did not look at this closely but I suspect libopenmpt should return a
smaller score in this case.

A solution could be to never return a high value for the FFmpeg
probe function.

> Looking at tools/probetest.c, that would be a file with very few bits set.
> libopenmpt detects the random data in question as M15 .MOD files (original
> Amiga 15 samples .mod files), and there is sadly not much that can be done
> about that. There are perfectly valid real-world M15 .MOD files with only 73
> bits set in the first 600 bytes (untouchables-station.mod,
> ).
> The following up to 64*4*4*63 bytes could even be completely 0 (empty
> pattern data) for valid files (even without the file being totally silent).
> The generated random data that tools/probetest complains about here contains
> 46 bits set to 1 in the first 600 bytes. What follows are various other
> examples with up to 96 bits set to 1. Completely loading a file like that
> would very likely reject it (in particular, libopenmpt can deduce the
> expected file size from the sample headers and, with some slack to account
> for corrupted real-world examples, reject files with non-matching size),
> however, that is not possible when only probing the file header.
> The libopenmpt API allows for the file header probing functions to return
> false-positives, however false-negatives are not allowed.
>
> Performance numbers shown by tools/probetest are what I had expected
> (measured on an AMD A4-5000, during normal Xorg session (i.e. not 100%
> idle)):
>
>   1110194971 cycles,   aa
>  24986722468 cycles,  aac
>  26418545168 cycles,  ac3
>   1484717267 cycles,  acm
>   1627888281 cycles,  act
>   2109884646 cycles,  adp
>   2316235992 cycles,  ads
>   1244706028 cycles,  adx
>   1132390431 cycles,  aea
>   1729241354 cycles, aiff
>   1728288238 cycles,  aix
>   2662531158 cycles,  amr
>  16189546067 cycles,amrnb
>  10342883200 cycles,amrwb
>   1487752343 cycles,  anm
>   2268900502 cycles,  apc
>   1140814303 cycles,  ape
>   2181170710 cycles, apng
>  18698762054 cycles,  aqtitle
>   2656908730 cycles,  asf
>   2402762967 cycles,asf_o
>  18148196647 cycles,  ass
>   1392503829 cycles,  ast
>   1774264703 cycles,   au
>   1807159562 cycles,  avi
>   1745391230 cycles,  avr
>   1370939762 cycles,  avs
>   1555620708 cycles,  bethsoftvid
>   1459171160 cycles,  bfi
>   2640635742 cycles, bink
>   2022320986 cycles,  bit
>   1664933324 cycles,bfstm
>   1588023172 cycles,brstm
>   1769430536 cycles,  boa
>   2294286860 cycles,  c93
>   1022646071 cycles,  caf
>   9063207678 cycles,cavsvideo
>   1898790300 cycles, cdxl
>   1037718383 cycles, cine
>   3358938768 cycles,   concat
>   2367399953 cycles,dcstr
>   1795803759 cycles,  dfa
>   1454750468 cycles,dirac
>   1167905836 cycles,dnxhd
>   2076678208 cycles,  dsf
>   1226761232 cycles,   dsicin
>   1157816261 cycles,  dss
>  31466350564 cycles,  dts
>   1357475606 cycles,dtshd
>  15626181281 cycles,   dv
>  12227021709 cycles,   dvbsub
>   1747998309 cycles,   dvbtxt
>   1941371107 cycles,  dxa
>   1988122049 cycles,   ea
>   1395161162 cycles, ea_cdata
>  21013119067 cycles, eac3
>   1282697126 cycles, epaf
>   1658521102 cycles,  ffm
>   2919787300 cycles,   ffmetadata
>   3786264941 cycles, fits
>   2700385826 cycles, flac
>   1840776863 cycles, flic
>   1317695853 cycles,  flv
>   1511756606 cycles, live_flv
>   1135064427 cycles,  4xm
>   1830871233 cycles,  frm
>   3011403748 cycles,  fsb
>   1462985803 cycles,  gdv
>   1708440935 cycles, genh
>   3480430744 cycles,  gif
>   2533542048 cycles,  gsm
>   2412598563 cycles,  gxf
>  21637989787 cycles, h261
>  22268834035 cycles, h263
>  22135718754 cycles, h264
>  13939886275 cycles, hevc
>   1979375582 cycles, hls,applehttp

Re: [FFmpeg-devel] [PATCH 3/4] avformat/libopenmpt: Update file extensions list for libopenmpt 0.3

[Carl Eugen Hoyos]

2018-01-07 15:40 GMT+01:00 Jörn Heusipp :
>
> On 01/06/2018 04:06 PM, Carl Eugen Hoyos wrote:
>>
>> 2018-01-06 11:07 GMT+01:00 Jörn Heusipp
>> :

>>> -.extensions =
>>> "669,amf,ams,dbm,digi,dmf,dsm,far,gdm,imf,it,j2b,m15,mdl,med,mmcmp,mms,mo3,mod,mptm,mt2,mtm,nst,okt,plm,ppm,psm,pt36,ptm,s3m,sfx,sfx2,stk,stm,ult,umx,wow,xm,xpk",
>>> +#if OPENMPT_API_VERSION_AT_LEAST(0,3,0)
>>> +.extensions =
>>> "669,amf,ams,dbm,digi,dmf,dsm,dtm,far,gdm,ice,imf,it,j2b,m15,mdl,med,mmcmp,mms,mo3,mod,mptm,mt2,mtm,nst,okt,plm,ppm,psm,pt36,ptm,s3m,sfx,sfx2,st26,stk,stm,stp,ult,umx,wow,xm,xpk",
>>> +#else
>>> +.extensions =
>>> "669,amf,ams,dbm,digi,dmf,dsm,far,gdm,ice,imf,it,j2b,m15,mdl,med,mmcmp,mms,mo3,mod,mptm,mt2,mtm,nst,okt,plm,ppm,psm,pt36,ptm,s3m,sfx,sfx2,st26,stk,stm,ult,umx,wow,xm,xpk",
>>> +#endif
>>
>>
>> I believe this change can be made without the version check.
>
> Why would that be better?

Only because of the simplification:
Other parts of FFmpeg will not support the files anyway, and I am sure
we can find a real-world files that have one of above extensions but are
not supported by libopenmpt (because they are completely different
files).

Can't libopenmpt be configured to support only some of above file
types?

But feel free to ignore my suggestion.

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

Re: [FFmpeg-devel] [Cellar] [PATCH] FFV1: make RGB48 support as non-experimental

[Michael Niedermayer]

On Sun, Jan 07, 2018 at 09:20:15PM +0100, Jerome Martinez wrote:
> On 07/01/2018 20:08, Michael Niedermayer wrote:
> >[...]
> >This is correct but i think misleading a bit
> >the 17bit case this is about uses a seperate codepath.
> 
> For your (FFmpeg) encoder and decoder. Not mine (same code path is used for
> 8/10/12/16/... bit RGB and YUV with my encoder and decoder).
> Again, we mix up bitstream specification and FFmpeg implementation.

The seperation of 16bit and >16bit results out of the data type size
fitting or not fitting in "int16".

A space/cache efficient implementation, possibly one using SIMD would
use seperate codepaths for 16 and > 16 on a normal architecture thats based on
8bit bytes.

Its part of spec design what "an efficient implementation" would/could do


[...]
> >
> >If we change the bitstream in a future version, which i belive we
> >should consider. Then we have an additional "old" version of the 17bit path
> >that needs to be supported in implementations.
> 
> question: How would you detect old version, from all encoders (not only
> FFmpeg)? there is nothing permitting that in the bitstream AFAIK (for v1: no
> micro_version; for v3: micro version >4 must be compatible with v4 as v4 is
> flagged stable).
> So it is "bitstream is in stone" now, for at least versions 0, 1, 3. Reason
> I speak about R with version 4 bitstream (I don't speak about FFmpeg),
> which is still flagged as experimental for all files.

very simple, the lowest version that we can make that change in without
causing any pain to people using ffv1 and without breaking the spec.


[...]
> >
> >But it wasnt intended as a "bitstream is in stone, encoder might mismatch
> >the spec" at the time.
> 
> I disagree: the idea behind CELLAR is that all encoders **must** match the

you disagree what i mean in a years old commit in ffmpeg i authored ?


> spec, or there is misunderstanding to clarify. Else everyone does his own
> version of FFV1, and we can not work together on an unique lossless
> compression format. The spec is expected to be the reference (for versions
> 0, 1, 3 for the moment) and encoders are expected to match the spec.

you make no sense
This code was intended to be used for developing the next version, that didnt
happen. If it did happen the code in the implementation would have changed
and once it was looking optimal a suggestion with test results would have
been posted to CELLAR to update the draft/spec. If that update did happen
then once its "stable" the check would have been removed from the encoder
implementation so people could use it.


[...]

> 
> >There is no question that with a unlimited bitdepth, real implementations
> >will never support some depths
> 
> Whatever is the support from the encoders you know, you can not know what
> was created by others based on the bitstream specification. so the bitstream
> is specified (for versions 0, 1, 3) for all bit depths and we can not change
> that now, as it is written for a long time in spec that the spec is flagged
> stable for these versions.

I can know what is possible with real implementations build by others because
they are constrained by the same physical laws and space and matter available
in the observable universe.


> 
> The question is not what is the support from decoder x, the question is that
> if there is a plan to break the compatibility between current version of
> FFV1 draft and future versions of this document.

I think its more like a circular reference
The draft/spec intended to describe the existing status quo
and while in the implementation something was marked experimental this 
detail was lost in the spec 


[...]

> I confirm that RGB48 files are already in the wild, as it is needed by some
> archives, and I confirm that they rely on MediaConch for testing the
> conformance compared to the specification.

Thanks, then its probably best if we support this format in en and decoder
implementations. As its out there already

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

Re: [FFmpeg-devel] dumpwave audio filter

[Carl Eugen Hoyos]

2018-01-07 23:38 GMT+01:00 Humeniuk, Dmytro :

> Let me introduce dumpwave waveform audio filter – dumps RMS amplitude
> to JSON file just like SoundCloud does. As there is no duration knowledge,
> samples count should be precalculated

Did you forget to attach your patch made with "git format-patch"?

> CONFIDENTIALITY CAUTION AND DISCLAIMER

Please remove the disclaimer from emails sent to a public
mailing list.

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

Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

[Aurelien Jacobs]

On Sun, Jan 07, 2018 at 05:23:24PM +, Rostislav Pehlivanov wrote:
> On 6 January 2018 at 16:48, Aurelien Jacobs  wrote:
> 
> > ---
> >  Changelog   |   2 +-
> >  configure   |   2 +
> >  libavcodec/Makefile |   2 +
> >  libavcodec/allcodecs.c  |   1 +
> >  libavcodec/aptx.c   | 352 ++
> > ++
> >  libavcodec/avcodec.h|   1 +
> >  libavcodec/codec_desc.c |   7 +
> >  7 files changed, 339 insertions(+), 28 deletions(-)
> >
> > diff --git a/Changelog b/Changelog
> > index 3d966c202b..9349bf1e8d 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -11,7 +11,7 @@ version :
> >  - TiVo ty/ty+ demuxer
> >  - Intel QSV-accelerated MJPEG encoding
> >  - PCE support for extended channel layouts in the AAC encoder
> > -- native aptX encoder and decoder
> > +- native aptX and aptX HD encoder and decoder
> >  - Raw aptX muxer and demuxer
> >  - NVIDIA NVDEC-accelerated H.264, HEVC, MPEG-1/2/4, VC1, VP8/9 hwaccel
> > decoding
> >  - Intel QSV-accelerated overlay filter
> > diff --git a/configure b/configure
> > index 1d2fffa132..c496346a06 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2459,6 +2459,8 @@ apng_encoder_deps="zlib"
> >  apng_encoder_select="llvidencdsp"
> >  aptx_decoder_select="audio_frame_queue"
> >  aptx_encoder_select="audio_frame_queue"
> > +aptx_hd_decoder_select="audio_frame_queue"
> > +aptx_hd_encoder_select="audio_frame_queue"
> >  asv1_decoder_select="blockdsp bswapdsp idctdsp"
> >  asv1_encoder_select="bswapdsp fdctdsp pixblockdsp"
> >  asv2_decoder_select="blockdsp bswapdsp idctdsp"
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index cfacd6b70c..a9ecf7ea5e 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -190,6 +190,8 @@ OBJS-$(CONFIG_ANSI_DECODER)+= ansi.o
> > cga_data.o
> >  OBJS-$(CONFIG_APE_DECODER) += apedec.o
> >  OBJS-$(CONFIG_APTX_DECODER)+= aptx.o
> >  OBJS-$(CONFIG_APTX_ENCODER)+= aptx.o
> > +OBJS-$(CONFIG_APTX_HD_DECODER) += aptx.o
> > +OBJS-$(CONFIG_APTX_HD_ENCODER) += aptx.o
> >  OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
> >  OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
> >  OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o
> > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> > index ed1e7ab06e..93d31f8688 100644
> > --- a/libavcodec/allcodecs.c
> > +++ b/libavcodec/allcodecs.c
> > [...]
> > @@ -844,6 +1105,24 @@ AVCodec ff_aptx_decoder = {
> >  };
> >  #endif
> >
> > +#if CONFIG_APTX_HD_DECODER
> > +AVCodec ff_aptx_hd_decoder = {
> > +.name  = "aptx_hd",
> > +.long_name = NULL_IF_CONFIG_SMALL("aptX HD (Audio
> > Processing Technology for Bluetooth)"),
> > +.type  = AVMEDIA_TYPE_AUDIO,
> > +.id= AV_CODEC_ID_APTX_HD,
> > +.priv_data_size= sizeof(AptXContext),
> > +.init  = aptx_init,
> > +.decode= aptx_decode_frame,
> > +.close = aptx_close,
> > +.capabilities  = AV_CODEC_CAP_DR1,
> > +.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
> > +.channel_layouts   = (const uint64_t[]) { AV_CH_LAYOUT_STEREO, 0},
> > +.sample_fmts   = (const enum AVSampleFormat[]) {
> > AV_SAMPLE_FMT_S32P,
> > +
> >  AV_SAMPLE_FMT_NONE },
> > +};
> > +#endif
> > +
> >  #if CONFIG_APTX_ENCODER
> >  AVCodec ff_aptx_encoder = {
> >  .name  = "aptx",
> > @@ -862,3 +1141,22 @@ AVCodec ff_aptx_encoder = {
> >  .supported_samplerates = (const int[]) {8000, 16000, 24000, 32000,
> > 44100, 48000, 0},
> >  };
> >  #endif
> > +
> > +#if CONFIG_APTX_HD_ENCODER
> > +AVCodec ff_aptx_hd_encoder = {
> > +.name  = "aptx_hd",
> > +.long_name = NULL_IF_CONFIG_SMALL("aptX HD (Audio
> > Processing Technology for Bluetooth)"),
> > +.type  = AVMEDIA_TYPE_AUDIO,
> > +.id= AV_CODEC_ID_APTX_HD,
> > +.priv_data_size= sizeof(AptXContext),
> > +.init  = aptx_init,
> > +.encode2   = aptx_encode_frame,
> > +.close = aptx_close,
> > +.capabilities  = AV_CODEC_CAP_SMALL_LAST_FRAME,
> > +.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE,
> > +.channel_layouts   = (const uint64_t[]) { AV_CH_LAYOUT_STEREO, 0},
> > +.sample_fmts   = (const enum AVSampleFormat[]) {
> > AV_SAMPLE_FMT_S32P,
> > +
> >  AV_SAMPLE_FMT_NONE },
> > +.supported_samplerates = (const int[]) {8000, 16000, 24000, 32000,
> > 44100, 48000, 0},
> > +};
> > +#endif
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index c13deb599f..95d164abc1 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -634,6 +634,7 @@ enum AVCodecID {
> >  AV_CODEC_ID_ATRAC3PAL,
> >  

[FFmpeg-devel] dumpwave audio filter

[Humeniuk, Dmytro]

Hi guys

Let me introduce dumpwave waveform audio filter – dumps RMS amplitude to JSON 
file just like SoundCloud does
As there is no duration knowledge, samples count should be precalculated


 

DMYTRO HUMENIUK
Software Engineer
 
Office: +48 12 881 10 05 x 25087    Email: 
dmytro_humen...@epam.com 
Krakow, Poland   epam.com 
 
CONFIDENTIALITY CAUTION AND DISCLAIMER
This message is intended only for the use of the individual(s) or entity(ies) 
to which it is addressed and contains information that is legally privileged 
and confidential.




smime.p7s
Description: S/MIME cryptographic signature
E-MAIL DISCLAIMER
This e-mail and any files and attachments transmitted with it
are confidential and may be legally privileged. They are intended
solely for the use of the intended recipient. Any views and
opinions expressed are those of the individual author/sender
and are not necessarily shared or endorsed by Ryanair Holdings plc
or any associated or related company. In particular e-mail
transmissions are not binding for the purposes of forming
a contract to sell airline seats, directly or via promotions,
and do not form a contractual obligation of any type.
Such contracts can only be formed in writing by post or fax,
duly signed by a senior company executive, subject to approval
by the Board of Directors.

The content of this e-mail or any file or attachment transmitted
with it may have been changed or altered without the consent
of the author. If you are not the intended recipient of this e-mail,
you are hereby notified that any review, dissemination, disclosure,
alteration, printing, circulation or transmission of, or any
action taken or omitted in reliance on this e-mail or any file
or attachment transmitted with it is prohibited and may be unlawful.

If you have received this e-mail in error
please notify Ryanair Holdings plc by contacting
Ryanair Holdings plc (Company No. 249885) / Ryanair DAC. (Company No. 104547).
Registered in the Republic Of Ireland. Airside Business Park, Swords, Co 
Dublin, Ireland.


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

[FFmpeg-devel] [PATCH 2/2] avcodec/dirac_dwt: Fix overflows in COMPOSE_HAARiH0/COMPOSE_HAARiL0

[Michael Niedermayer]

Fixes: 4830/clusterfuzz-testcase-minimized-5255392054476800
Fixes: signed integer overflow: 2147483646 - -7 cannot be represented in type 
'int'

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/dirac_dwt.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/dirac_dwt.h b/libavcodec/dirac_dwt.h
index f9828d95a4..1af41e0702 100644
--- a/libavcodec/dirac_dwt.h
+++ b/libavcodec/dirac_dwt.h
@@ -105,10 +105,10 @@ void ff_spatial_idwt_slice2(DWTContext *d, int y);
 (int)(((unsigned)(b2) - ((int)(-b0 + 9U*b1 + 9U*b3 - b4 + 16) >> 5)))
 
 #define COMPOSE_HAARiL0(b0, b1)\
-(b0 - ((b1 + 1) >> 1))
+((int)(b0 - (unsigned)((int)(b1 + 1U) >> 1)))
 
 #define COMPOSE_HAARiH0(b0, b1)\
-(b0 + b1)
+((int)(b0 + (unsigned)(b1)))
 
 #define COMPOSE_FIDELITYiL0(b0, b1, b2, b3, b4, b5, b6, b7, b8)\
 ((unsigned)b4 - ((int)(-8*(b0+(unsigned)b8) + 21*(b1+(unsigned)b7) - 
46*(b2+(unsigned)b6) + 161*(b3+(unsigned)b5) + 128) >> 8))
-- 
2.15.1

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

[FFmpeg-devel] [PATCH 1/2] avcodec/diracdec: Fix integer overflow with quant

[Michael Niedermayer]

Fixes: signed integer overflow: 2 + 2147483646 cannot be represented in type 
'int'
Fixes: 4792/clusterfuzz-testcase-minimized-6322450775146496

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg

Signed-off-by: Michael Niedermayer 
---
 libavcodec/diracdec.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index 7157357d59..530e1c6ffd 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -509,16 +509,16 @@ static inline void codeblock(DiracContext *s, SubBand *b,
 }
 
 if (s->codeblock_mode && !(s->old_delta_quant && blockcnt_one)) {
-int quant = b->quant;
+int quant;
 if (is_arith)
-quant += dirac_get_arith_int(c, CTX_DELTA_Q_F, CTX_DELTA_Q_DATA);
+quant = dirac_get_arith_int(c, CTX_DELTA_Q_F, CTX_DELTA_Q_DATA);
 else
-quant += dirac_get_se_golomb(gb);
-if (quant < 0) {
+quant = dirac_get_se_golomb(gb);
+if (quant > INT_MAX - b->quant || b->quant + quant < 0) {
 av_log(s->avctx, AV_LOG_ERROR, "Invalid quant\n");
 return;
 }
-b->quant = quant;
+b->quant += quant;
 }
 
 if (b->quant > (DIRAC_MAX_QUANT_INDEX - 1)) {
-- 
2.15.1

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

[FFmpeg-devel] [PATCH] configure: don't use SDL.h in check_func_headers when checking for SDL2

[James Almer]

check_func_headers() defines a main() function, which clashes with a
redefinition done by said SDL header. Check for SDL_PollEvent using
SDL_events.h only instead, where the redefinition doesn't happen.

Fixes a regression since d03c39b46b21c893d6549a532289b7fb9935b3fc.

Tested-by: RiCON
Signed-off-by: James Almer 
---
 configure | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index ab05b9c7f3..1aea18d300 100755
--- a/configure
+++ b/configure
@@ -6008,15 +6008,13 @@ fi
 
 if enabled sdl2; then
 SDL2_CONFIG="${cross_prefix}sdl2-config"
-if test_pkg_config sdl2 "sdl2 >= 2.0.1 sdl2 < 2.1.0" SDL_events.h 
SDL_PollEvent; then
-check_func_headers SDL.h SDL_Init $sdl2_extralibs $sdl2_cflags ||
-disable sdl2
-elif "${SDL2_CONFIG}" --version > /dev/null 2>&1; then
+test_pkg_config sdl2 "sdl2 >= 2.0.1 sdl2 < 2.1.0" SDL_events.h 
SDL_PollEvent
+if disabled sdl2 && "${SDL2_CONFIG}" --version > /dev/null 2>&1; then
 sdl2_cflags=$("${SDL2_CONFIG}" --cflags)
 sdl2_extralibs=$("${SDL2_CONFIG}" --libs)
 check_cpp_condition SDL.h "(SDL_MAJOR_VERSION<<16 | 
SDL_MINOR_VERSION<<8 | SDL_PATCHLEVEL) >= 0x020001" $sdl2_cflags &&
 check_cpp_condition SDL.h "(SDL_MAJOR_VERSION<<16 | 
SDL_MINOR_VERSION<<8 | SDL_PATCHLEVEL) < 0x020100" $sdl2_cflags &&
-check_func_headers SDL.h SDL_Init $sdl2_extralibs $sdl2_cflags &&
+check_func_headers SDL_events.h SDL_PollEvent $sdl2_extralibs 
$sdl2_cflags &&
 enable sdl2
 fi
 if test $target_os = "mingw32"; then
-- 
2.15.0

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

Re: [FFmpeg-devel] [Cellar] [PATCH] FFV1: make RGB48 support as non-experimental

[Jerome Martinez]

On 07/01/2018 20:08, Michael Niedermayer wrote:

[...]
This is correct but i think misleading a bit
the 17bit case this is about uses a seperate codepath.


For your (FFmpeg) encoder and decoder. Not mine (same code path is used 
for 8/10/12/16/... bit RGB and YUV with my encoder and decoder).

Again, we mix up bitstream specification and FFmpeg implementation.
In the bitstream specifications, there is currently only one path 
(except for handling files in the wild which are not conform to the 
unique path, we take care of them for historical reasons).



  So if its enabled
we generate new files that have never been generated before in some sense
AFAIK


- MediaConch conformance checker can check files up to 30 bits per 
component, and already implements the way it is written in spec for all 
supported bit depths, because the spec was flagged as stable whatever is 
the bit depth for a long time, without having anyone saying that 16 or 
17-bit for RGB (reminder: it is already set as "stable" for YCbCr 
16-bit) may have a different paths later for versions 0, 1, 3. If you 
change the bitstream of RGB48 or any stream with bitdepth <=30, you 
break it despite the fact it is validating correctly and would be a 
major issue for this tool (breaking trust about the tool or FFV1, as 
there would be 2 variants of FFV1 RGB48).
- I have an early (not yet public, for testing the spec only for the 
moment) version of an encoder conforming to the spec for all bit depths 
up to 30-bit per component.

- I have heard about other FFV1 encoders able to encode RGB48



If we change the bitstream in a future version, which i belive we
should consider. Then we have an additional "old" version of the 17bit path
that needs to be supported in implementations.


question: How would you detect old version, from all encoders (not only 
FFmpeg)? there is nothing permitting that in the bitstream AFAIK (for 
v1: no micro_version; for v3: micro version >4 must be compatible with 
v4 as v4 is flagged stable).
So it is "bitstream is in stone" now, for at least versions 0, 1, 3. 
Reason I speak about R with version 4 bitstream (I don't speak about 
FFmpeg), which is still flagged as experimental for all files.






FFmpeg experimental flag is for the status of the encoder, not for the
status of the bitstream (the bitstream for versions 0, 1, 3 is already
considered stable for RGB48 and others)

I think i added the flag check. The reason behind the check was so that the
bitstream syntax can be changed without the need to support every iteration
of the bitstream.
I had hoped someone would fund research and testing of further improvments
to the various fine details of higher bit depth encoding beyond 8bit.
IIRC No further funding was provided, Noone worked on it as a volunteer,
No changes where proposed  ...


This is planned on my side after FFV1 versions 0, 1, 3 are finalized. 
With version 4 (the experimental version).
but it is possible only if we all are in sync and don't do something 
against the consensus, and as far I as I understand the consensus is 
that versions 0, 1, 3 are "bitstream is in stone" now (and actually from 
the beginning of CELLAR) based on the draft of FFV1 specifications, 
which is detailed before going to IETF but not changed. All the 
communication, at IETF and conferences, around FFV1 versions 0, 1, 3 is 
that the bitstream specification is stable, and discussing about 
breaking this consensus may harm FFV1 spread.




But it wasnt intended as a "bitstream is in stone, encoder might mismatch
the spec" at the time.


I disagree: the idea behind CELLAR is that all encoders **must** match 
the spec, or there is misunderstanding to clarify. Else everyone does 
his own version of FFV1, and we can not work together on an unique 
lossless compression format. The spec is expected to be the reference 
(for versions 0, 1, 3 for the moment) and encoders are expected to match 
the spec.




We have a draft spec now that does not limit bitdepth in any way, this may
have been a mistakke but i dont see this as a big problem honestly. I do not
propose to change this. But i would not oppose it if people want to change it

If someone creates a 19bit per sample file based on the draft spec it also
will not decode with most real world implementations.


It will with my conformance checker. You can not know what is "real 
world", as a couple of encoders may be in house only.

we still mix up bitstream specification and one implementation.
The idea behind CELLAR is to have FFV1 a standardized video format, so 
we can not decide for 1 encoder to change the bitstream. We need to find 
a consensus on CELLAR mailing-list first. The consensus is what is 
written in the draft and there was no post on CELLAR mailing-list for 
limiting to some bit depths.



There is no question that with a unlimited bitdepth, real implementations
will never support some depths


Whatever is the support from the encoders you know, you can not know 
what was 

Re: [FFmpeg-devel] [Cellar] [PATCH] FFV1: make RGB48 support as non-experimental

[Michael Niedermayer]

Hi

On Sun, Jan 07, 2018 at 06:39:34PM +0100, Jerome Martinez wrote:
> On 06/01/2018 23:21, Michael Niedermayer wrote:
> >On Sat, Jan 06, 2018 at 04:54:18PM +0100, Jerome Martinez wrote:
> >>On 06/01/2018 02:05, Michael Niedermayer wrote:
>   ffv1enc.c |4 
>   1 file changed, 4 deletions(-)
> acfc60c913b311b148f2eeef2d2d6ea9e37afcf7  
> 0001-avcodec-ffv1enc-mark-RGB48-support-as-non-experiment.patch
>  From 303f63fb7e6172fdb7de66da1f8a4006b79a535f Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
> Date: Fri, 5 Jan 2018 11:09:01 +0100
> Subject: [PATCH] avcodec/ffv1enc: mark RGB48 support as non-experimental
> 
> Resulting bitstream was tested with a conformance checker
> using the last draft of FFV1 specifications.
> >>>But has the way this is stored been optimized ?
> >>>
> >>>Once its marked as non exerimental all future decoders must support the 
> >>>exact
> >>>way.
> >>Although this is considered experimental in the encoder, the implementation
> >>adheres to the description in the specification. The bitstream specification
> >>does not provide a bitdepth limit so with the current draft of the
> >>specification, another FFV1 encoder could already encode 16-bit (and more)
> >>content. The work on the specification has been careful to not break
> >>compatibility with former drafts and at this point the FFV1 bitstream
> >>specification for versions 0, 1, and 3 should be considered already
> >>non-experimental for all bit depths. All current decoders should already
> >>support the exact way it is currently specified.
> >>
> >>To make a change in the specification at this point would have cascading
> >>consequences as we’d have to retract the part of the specification which
> >>states that micro_version 4 of version 3 is the first stable variant. Worse,
> >>it is impossible to indicate a bitstream change in FFV1 version 1, which
> >>permits RGB 16-bit content too, so it would be difficult for a decoder to
> >>detect a bitstream not conforming to the bitstream created by the current
> >>version of FFmpeg encoder.
> >Are you not making this look alot more complex than it is ?
> >Or maybe we talk about slightly different things here
> >
> >with the next version we can introduce any method of storing 16bit or 9-15 
> >bit
> >and we certainly do not support in the implementation all possible bit depths
> >
> > From what i remember I had always wanted to improve the way that
> >more than 8bit is handled, not just 16. Although 16 is a bit special
> >
> >Consider this:
> >If we improve get_context() in the next version for >8bit
> >we still have to support 9-15 bit with the old definition
> >if we now declare 16bit non experimental then we also must support that with
> >an old get_context() in the decoder.
> >the 16bit path is seperate from the lower bit depth. So this is an Additional
> >codepath that we have to carry in the future
> >
> >isnt it smarter now that if we want to improve get_context() that we
> >dont now extend what can be generated with the current get_context ?
> >
> >or are such current get_context() style files already widespread ?
> >if so then its probably best to accept it and keep supporting it
> 
> I am lost.
> Looks like we talk about 2 different subjects: FFV1 bitstream specifications
> and FFmpeg implementation.
> Let separate subjects:
> 

[...]

> FFmpeg implementation:
> FFV1 YCbCr 16-bit is already flagged as non experimental, so there is
> already some non experimental 16-bit support in FFmpeg FFV1 encoder. 16-bit
> is not new and for RGB48 the actual encoding after RGB to YCbCr
> transformation is just 1 bit more (17-bit).

This is correct but i think misleading a bit
the 17bit case this is about uses a seperate codepath. So if its enabled
we generate new files that have never been generated before in some sense
AFAIK

If we change the bitstream in a future version, which i belive we 
should consider. Then we have an additional "old" version of the 17bit path
that needs to be supported in implementations.


> FFmpeg experimental flag is for the status of the encoder, not for the
> status of the bitstream (the bitstream for versions 0, 1, 3 is already
> considered stable for RGB48 and others)

I think i added the flag check. The reason behind the check was so that the
bitstream syntax can be changed without the need to support every iteration
of the bitstream.
I had hoped someone would fund research and testing of further improvments 
to the various fine details of higher bit depth encoding beyond 8bit.
IIRC No further funding was provided, Noone worked on it as a volunteer,
No changes where proposed  ...

But it wasnt intended as a "bitstream is in stone, encoder might mismatch
the spec" at the time.

We have a draft spec now that does not limit bitdepth in any way, this may
have been a mistakke but i dont see this as a big problem honestly. I do not
propose to change this. But i 

[FFmpeg-devel] [PATCH 4/6] dashdec: Correct seeking behaviour

[Stefan _]

>From bdf3557a400620fce66ca0237f1ff172c227609b Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Fri, 5 Jan 2018 00:51:32 +0100
Subject: [PATCH 4/6] dashdec: Correct seeking behaviour

dash_read_seek() is called only once to issue a seek
of *all* streams to the specified timestamp. But to
avoid reopening each stream, do a "dry run" for streams
that are in a discarded state.
---
 libavformat/dashdec.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index ac0e6c6f9..1252d4156 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1828,19 +1828,22 @@ static int dash_close(AVFormatContext *s)
 return 0;
 }
 
-static int dash_seek(AVFormatContext *s, struct representation *pls, int64_t seek_pos_msec, int flags)
+static int dash_seek(AVFormatContext *s, struct representation *pls, int64_t seek_pos_msec, int flags, int dry_run)
 {
 int ret = 0;
 int i = 0;
 int j = 0;
 int64_t duration = 0;
 
-av_log(pls->parent, AV_LOG_VERBOSE, "DASH seek pos[%"PRId64"ms], playlist %d\n", seek_pos_msec, pls->rep_idx);
+av_log(pls->parent, AV_LOG_VERBOSE, "DASH seek pos[%"PRId64"ms], playlist %d%s\n",
+seek_pos_msec, pls->rep_idx, dry_run ? " (dry)" : "");
 
 // single fragment mode
 if (pls->n_fragments == 1) {
 pls->cur_timestamp = 0;
 pls->cur_seg_offset = 0;
+if (dry_run)
+return 0;
 ff_read_frame_flush(pls->ctx);
 return av_seek_frame(pls->ctx, -1, seek_pos_msec * 1000, flags);
 }
@@ -1885,14 +1888,14 @@ set_seq_num:
 pls->cur_timestamp = 0;
 pls->cur_seg_offset = 0;
 pls->init_sec_buf_read_offset = 0;
-ret = reopen_demux_for_component(s, pls);
+ret = dry_run ? 0 : reopen_demux_for_component(s, pls);
 
 return ret;
 }
 
 static int dash_read_seek(AVFormatContext *s, int stream_index, int64_t timestamp, int flags)
 {
-int ret, i;
+int ret = 0, i;
 DASHContext *c = s->priv_data;
 int64_t seek_pos_msec = av_rescale_rnd(timestamp, 1000,
s->streams[stream_index]->time_base.den,
@@ -1901,16 +1904,14 @@ static int dash_read_seek(AVFormatContext *s, int stream_index, int64_t timestam
 if ((flags & AVSEEK_FLAG_BYTE) || c->is_live)
 return AVERROR(ENOSYS);
 
-ret = AVERROR_EOF;
+/* Seek in discarded streams with dry_run=1 to avoid reopening them */
 for (i = 0; i < c->n_videos; i++) {
-if (c->videos[i]->stream_index == stream_index) {
-ret = dash_seek(s, c->videos[i], seek_pos_msec, flags);
-}
+if (!ret)
+ret = dash_seek(s, c->videos[i], seek_pos_msec, flags, !c->videos[i]->ctx);
 }
 for (i = 0; i < c->n_audios; i++) {
-if (c->audios[i]->stream_index == stream_index) {
-ret = dash_seek(s, c->audios[i], seek_pos_msec, flags);
-}
+if (!ret)
+ret = dash_seek(s, c->audios[i], seek_pos_msec, flags, !c->audios[i]->ctx);
 }
 
 return ret;
-- 
2.15.1

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

[FFmpeg-devel] [PATCH 5/6] dashdec: Avoid trying to read any segments beyond the last

[Stefan _]

>From 277c710159849816bff4e4f5ccd1139348518620 Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Fri, 5 Jan 2018 14:19:25 +0100
Subject: [PATCH 5/6] dashdec: Avoid trying to read any segments beyond the
 last

---
 libavformat/dashdec.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 1252d4156..af8ab5f2f 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1505,9 +1505,11 @@ restart:
 if (ret > 0)
 goto end;
 
-if (!v->is_restart_needed)
-v->cur_seq_no++;
-v->is_restart_needed = 1;
+if (c->is_live || v->cur_seq_no < v->last_seq_no) {
+	if (!v->is_restart_needed)
+	v->cur_seq_no++;
+	v->is_restart_needed = 1;
+}
 
 end:
 return ret;
-- 
2.15.1

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

[FFmpeg-devel] [PATCH 6/6] dashdec: Support SegmentTemplate inside Period

[Stefan _]

>From 89b42dc60156f1e030a30e13636651db41e9f34b Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Fri, 5 Jan 2018 15:32:23 +0100
Subject: [PATCH 6/6] dashdec: Support SegmentTemplate inside Period

---
 libavformat/dashdec.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index af8ab5f2f..ac1080b62 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -646,6 +646,7 @@ static int parse_manifest_representation(AVFormatContext *s, const char *url,
  xmlNodePtr adaptionset_node,
  xmlNodePtr mpd_baseurl_node,
  xmlNodePtr period_baseurl_node,
+ xmlNodePtr period_segmenttemplate_node,
  xmlNodePtr fragment_template_node,
  xmlNodePtr content_component_node,
  xmlNodePtr adaptionset_baseurl_node,
@@ -662,7 +663,7 @@ static int parse_manifest_representation(AVFormatContext *s, const char *url,
 xmlNodePtr representation_segmentlist_node = NULL;
 xmlNodePtr segmentlists_tab[2];
 xmlNodePtr fragment_timeline_node = NULL;
-xmlNodePtr fragment_templates_tab[3];
+xmlNodePtr fragment_templates_tab[4];
 char *duration_val = NULL;
 char *presentation_timeoffset_val = NULL;
 char *startnumber_val = NULL;
@@ -702,18 +703,19 @@ static int parse_manifest_representation(AVFormatContext *s, const char *url,
 baseurl_nodes[2] = adaptionset_baseurl_node;
 baseurl_nodes[3] = representation_baseurl_node;
 
-if (representation_segmenttemplate_node || fragment_template_node) {
+if (representation_segmenttemplate_node || fragment_template_node || period_segmenttemplate_node) {
 fragment_timeline_node = NULL;
 fragment_templates_tab[0] = representation_segmenttemplate_node;
 fragment_templates_tab[1] = adaptionset_segmentlist_node;
 fragment_templates_tab[2] = fragment_template_node;
+fragment_templates_tab[3] = period_segmenttemplate_node;
 
-presentation_timeoffset_val = get_val_from_nodes_tab(fragment_templates_tab, 3, "presentationTimeOffset");
-duration_val = get_val_from_nodes_tab(fragment_templates_tab, 3, "duration");
-startnumber_val = get_val_from_nodes_tab(fragment_templates_tab, 3, "startNumber");
-timescale_val = get_val_from_nodes_tab(fragment_templates_tab, 3, "timescale");
-initialization_val = get_val_from_nodes_tab(fragment_templates_tab, 3, "initialization");
-media_val = get_val_from_nodes_tab(fragment_templates_tab, 3, "media");
+presentation_timeoffset_val = get_val_from_nodes_tab(fragment_templates_tab, 4, "presentationTimeOffset");
+duration_val = get_val_from_nodes_tab(fragment_templates_tab, 4, "duration");
+startnumber_val = get_val_from_nodes_tab(fragment_templates_tab, 4, "startNumber");
+timescale_val = get_val_from_nodes_tab(fragment_templates_tab, 4, "timescale");
+initialization_val = get_val_from_nodes_tab(fragment_templates_tab, 4, "initialization");
+media_val = get_val_from_nodes_tab(fragment_templates_tab, 4, "media");
 
 if (initialization_val) {
 rep->init_section = av_mallocz(sizeof(struct fragment));
@@ -866,7 +868,8 @@ end:
 static int parse_manifest_adaptationset(AVFormatContext *s, const char *url,
 xmlNodePtr adaptionset_node,
 xmlNodePtr mpd_baseurl_node,
-xmlNodePtr period_baseurl_node)
+xmlNodePtr period_baseurl_node,
+xmlNodePtr period_segmenttemplate_node)
 {
 int ret = 0;
 xmlNodePtr fragment_template_node = NULL;
@@ -890,6 +893,7 @@ static int parse_manifest_adaptationset(AVFormatContext *s, const char *url,
 adaptionset_node,
 mpd_baseurl_node,
 period_baseurl_node,
+period_segmenttemplate_node,
 fragment_template_node,
 content_component_node,
 adaptionset_baseurl_node,
@@ -918,6 +922,7 @@ static int parse_manifest(AVFormatContext *s, const char *url, AVIOContext *in)
 xmlNodePtr period_node = NULL;
 xmlNodePtr mpd_baseurl_node = NULL;
 xmlNodePtr period_baseurl_node = NULL;
+xmlNodePtr period_segmenttemplate_node = NULL;
 xmlNodePtr 

[FFmpeg-devel] [PATCH 1/6] dashdec: Expose bandwidth and representation ID as metadata

[Stefan _]

Hi,

I did some work on the DASH demuxer.

The primary goal was making it viable to play YouTube/Vimeo/... videos 
using the native demuxer, since mpv currently uses a workaround in form 
of Edit Decision Lists (EDL).


Implemented features:

* Exposing id / bitrate as stream metadata (similar to the HLS demuxer)

* Support for multiple video and audio streams

* A few minor parts of the specification that are in use at YouTube


>From ba640900c260f8b5b1919c4274b2c2e3e57e2546 Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Thu, 4 Jan 2018 23:45:26 +0100
Subject: [PATCH 1/6] dashdec: Expose bandwidth and representation ID as
 metadata

---
 libavformat/dashdec.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 0e3afd2a3..1a18ab021 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -84,6 +84,8 @@ struct representation {
 int stream_index;
 
 enum AVMediaType type;
+char id[20];
+int bandwidth;
 
 int n_fragments;
 struct fragment **fragments; /* VOD list of fragment for profile */
@@ -801,6 +803,8 @@ static int parse_manifest_representation(AVFormatContext *s, const char *url,
 if (rep) {
 if (rep->fragment_duration > 0 && !rep->fragment_timescale)
 rep->fragment_timescale = 1;
+rep->bandwidth = rep_bandwidth_val ? atoi(rep_bandwidth_val) : 0;
+strncpy(rep->id, rep_id_val ? rep_id_val : "", sizeof(rep->id));
 if (type == AVMEDIA_TYPE_VIDEO) {
 rep->rep_idx = video_rep_idx;
 c->cur_video = rep;
@@ -1650,10 +1654,20 @@ static int dash_read_header(AVFormatContext *s)
 }
 
 if (c->cur_video) {
-av_program_add_stream_index(s, 0, c->cur_video->stream_index);
+int stream_index = c->cur_video->stream_index;
+av_program_add_stream_index(s, 0, stream_index);
+if (c->cur_video->bandwidth > 0)
+av_dict_set_int(>streams[stream_index]->metadata, "variant_bitrate", c->cur_video->bandwidth, 0);
+if (c->cur_video->id[0])
+av_dict_set(>streams[stream_index]->metadata, "id", c->cur_video->id, 0);
 }
 if (c->cur_audio) {
-av_program_add_stream_index(s, 0, c->cur_audio->stream_index);
+int stream_index = c->cur_audio->stream_index;
+av_program_add_stream_index(s, 0, stream_index);
+if (c->cur_audio->bandwidth > 0)
+av_dict_set_int(>streams[stream_index]->metadata, "variant_bitrate", c->cur_audio->bandwidth, 0);
+if (c->cur_audio->id[0])
+av_dict_set(>streams[stream_index]->metadata, "id", c->cur_audio->id, 0);
 }
 }
 
-- 
2.15.1

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

[FFmpeg-devel] [PATCH 2/6] dashdec: Support for multiple video/audio streams

[Stefan _]

>From 857da994ba1f3466cd6a3b28d025a95301577ad2 Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Fri, 5 Jan 2018 00:03:06 +0100
Subject: [PATCH 2/6] dashdec: Support for multiple video/audio streams

---
 doc/demuxers.texi |  10 ++
 libavformat/dashdec.c | 344 +++---
 2 files changed, 225 insertions(+), 129 deletions(-)

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 608016723..e7c2abce5 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -244,6 +244,16 @@ file subdir/file-2.wav
 @end example
 @end itemize
 
+@section dash
+
+Dynamic Adaptive Streaming over HTTP demuxer.
+
+This demuxer presents all AVStreams found in the manifest.
+By setting the discard flags on AVStreams the caller can decide
+which streams to actually receive.
+Each stream mirrors the @code{id} and @code{bandwidth} properties from the
+@code{} as metadata keys named "id" and "variant_bitrate" respectively.
+
 @section flv, live_flv
 
 Adobe Flash Video Format demuxer.
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 1a18ab021..676979638 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -86,6 +86,7 @@ struct representation {
 enum AVMediaType type;
 char id[20];
 int bandwidth;
+AVStream *assoc_stream; /* demuxer stream associated with this representation */
 
 int n_fragments;
 struct fragment **fragments; /* VOD list of fragment for profile */
@@ -120,8 +121,11 @@ struct representation {
 typedef struct DASHContext {
 const AVClass *class;
 char *base_url;
-struct representation *cur_video;
-struct representation *cur_audio;
+
+int n_videos;
+struct representation **videos;
+int n_audios;
+struct representation **audios;
 
 /* MediaPresentationDescription Attribute */
 uint64_t media_presentation_duration;
@@ -333,6 +337,28 @@ static void free_representation(struct representation *pls)
 av_freep();
 }
 
+static void free_video_list(DASHContext *c)
+{
+int i;
+for (i = 0; i < c->n_videos; i++) {
+struct representation *pls = c->videos[i];
+free_representation(pls);
+}
+av_freep(>videos);
+c->n_videos = 0;
+}
+
+static void free_audio_list(DASHContext *c)
+{
+int i;
+for (i = 0; i < c->n_audios; i++) {
+struct representation *pls = c->audios[i];
+free_representation(pls);
+}
+av_freep(>audios);
+c->n_audios = 0;
+}
+
 static void set_httpheader_options(DASHContext *c, AVDictionary **opts)
 {
 // broker prior HTTP options that should be consistent across requests
@@ -658,7 +684,7 @@ static int parse_manifest_representation(AVFormatContext *s, const char *url,
 type = get_content_type(adaptionset_node);
 if (type == AVMEDIA_TYPE_UNKNOWN) {
 av_log(s, AV_LOG_VERBOSE, "Parsing '%s' - skipp not supported representation type\n", url);
-} else if ((type == AVMEDIA_TYPE_VIDEO && !c->cur_video) || (type == AVMEDIA_TYPE_AUDIO && !c->cur_audio)) {
+} else if (type == AVMEDIA_TYPE_VIDEO || type == AVMEDIA_TYPE_AUDIO) {
 // convert selected representation to our internal struct
 rep = av_mallocz(sizeof(struct representation));
 if (!rep) {
@@ -807,10 +833,10 @@ static int parse_manifest_representation(AVFormatContext *s, const char *url,
 strncpy(rep->id, rep_id_val ? rep_id_val : "", sizeof(rep->id));
 if (type == AVMEDIA_TYPE_VIDEO) {
 rep->rep_idx = video_rep_idx;
-c->cur_video = rep;
+dynarray_add(>videos, >n_videos, rep);
 } else {
 rep->rep_idx = audio_rep_idx;
-c->cur_audio = rep;
+dynarray_add(>audios, >n_audios, rep);
 }
 }
 }
@@ -883,8 +909,6 @@ static int parse_manifest(AVFormatContext *s, const char *url, AVIOContext *in)
 char *val  = NULL;
 uint32_t perdiod_duration_sec = 0;
 uint32_t perdiod_start_sec = 0;
-int32_t audio_rep_idx = 0;
-int32_t video_rep_idx = 0;
 
 if (!in) {
 close_in = 1;
@@ -1014,14 +1038,6 @@ static int parse_manifest(AVFormatContext *s, const char *url, AVIOContext *in)
 }
 adaptionset_node = xmlNextElementSibling(adaptionset_node);
 }
-if (c->cur_video) {
-c->cur_video->rep_count = video_rep_idx;
-av_log(s, AV_LOG_VERBOSE, "rep_idx[%d]\n", (int)c->cur_video->rep_idx);
-av_log(s, AV_LOG_VERBOSE, "rep_count[%d]\n", (int)video_rep_idx);
-}
-if (c->cur_audio) {
-c->cur_audio->rep_count = audio_rep_idx;
-}
 cleanup:
 /*free the document */
 xmlFreeDoc(doc);
@@ -1139,48 +1155,71 @@ static void move_segments(struct representation *rep_src, struct representation
 static int refresh_manifest(AVFormatContext *s)
 {
 
-int ret = 0;
+int ret = 0, i;
 DASHContext *c = s->priv_data;
 
 // save current 

[FFmpeg-devel] [PATCH 3/6] dashdec: Search for segment timeline inside AdaptionSets too

[Stefan _]

>From c06d6cbcdc9092428d3764a969604d1f22725e56 Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Fri, 5 Jan 2018 00:19:53 +0100
Subject: [PATCH 3/6] dashdec: Search for segment timeline inside AdaptionSets
 too

---
 libavformat/dashdec.c | 40 +++-
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 676979638..ac0e6c6f9 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -648,7 +648,8 @@ static int parse_manifest_representation(AVFormatContext *s, const char *url,
  xmlNodePtr period_baseurl_node,
  xmlNodePtr fragment_template_node,
  xmlNodePtr content_component_node,
- xmlNodePtr adaptionset_baseurl_node)
+ xmlNodePtr adaptionset_baseurl_node,
+ xmlNodePtr adaptionset_segmentlist_node)
 {
 int32_t ret = 0;
 int32_t audio_rep_idx = 0;
@@ -659,8 +660,9 @@ static int parse_manifest_representation(AVFormatContext *s, const char *url,
 xmlNodePtr representation_segmenttemplate_node = NULL;
 xmlNodePtr representation_baseurl_node = NULL;
 xmlNodePtr representation_segmentlist_node = NULL;
+xmlNodePtr segmentlists_tab[2];
 xmlNodePtr fragment_timeline_node = NULL;
-xmlNodePtr fragment_templates_tab[2];
+xmlNodePtr fragment_templates_tab[3];
 char *duration_val = NULL;
 char *presentation_timeoffset_val = NULL;
 char *startnumber_val = NULL;
@@ -703,14 +705,15 @@ static int parse_manifest_representation(AVFormatContext *s, const char *url,
 if (representation_segmenttemplate_node || fragment_template_node) {
 fragment_timeline_node = NULL;
 fragment_templates_tab[0] = representation_segmenttemplate_node;
-fragment_templates_tab[1] = fragment_template_node;
+fragment_templates_tab[1] = adaptionset_segmentlist_node;
+fragment_templates_tab[2] = fragment_template_node;
 
-presentation_timeoffset_val = get_val_from_nodes_tab(fragment_templates_tab, 2, "presentationTimeOffset");
-duration_val = get_val_from_nodes_tab(fragment_templates_tab, 2, "duration");
-startnumber_val = get_val_from_nodes_tab(fragment_templates_tab, 2, "startNumber");
-timescale_val = get_val_from_nodes_tab(fragment_templates_tab, 2, "timescale");
-initialization_val = get_val_from_nodes_tab(fragment_templates_tab, 2, "initialization");
-media_val = get_val_from_nodes_tab(fragment_templates_tab, 2, "media");
+presentation_timeoffset_val = get_val_from_nodes_tab(fragment_templates_tab, 3, "presentationTimeOffset");
+duration_val = get_val_from_nodes_tab(fragment_templates_tab, 3, "duration");
+startnumber_val = get_val_from_nodes_tab(fragment_templates_tab, 3, "startNumber");
+timescale_val = get_val_from_nodes_tab(fragment_templates_tab, 3, "timescale");
+initialization_val = get_val_from_nodes_tab(fragment_templates_tab, 3, "initialization");
+media_val = get_val_from_nodes_tab(fragment_templates_tab, 3, "media");
 
 if (initialization_val) {
 rep->init_section = av_mallocz(sizeof(struct fragment));
@@ -756,6 +759,8 @@ static int parse_manifest_representation(AVFormatContext *s, const char *url,
 
 if (!fragment_timeline_node)
 fragment_timeline_node = find_child_node_by_name(fragment_template_node, "SegmentTimeline");
+if (!fragment_timeline_node)
+fragment_timeline_node = find_child_node_by_name(adaptionset_segmentlist_node, "SegmentTimeline");
 if (fragment_timeline_node) {
 fragment_timeline_node = xmlFirstElementChild(fragment_timeline_node);
 while (fragment_timeline_node) {
@@ -784,8 +789,11 @@ static int parse_manifest_representation(AVFormatContext *s, const char *url,
 // TODO: https://www.brendanlong.com/the-structure-of-an-mpeg-dash-mpd.html
 // http://www-itec.uni-klu.ac.at/dash/ddash/mpdGenerator.php?fragmentlength=15=full
 xmlNodePtr fragmenturl_node = NULL;
-duration_val = xmlGetProp(representation_segmentlist_node, "duration");
-timescale_val = xmlGetProp(representation_segmentlist_node, "timescale");
+segmentlists_tab[0] = representation_segmentlist_node;
+segmentlists_tab[1] = adaptionset_segmentlist_node;
+
+duration_val = get_val_from_nodes_tab(segmentlists_tab, 2, "duration");
+timescale_val = get_val_from_nodes_tab(segmentlists_tab, 2, "timescale");
 if (duration_val) {
 rep->fragment_duration = (int64_t) strtoll(duration_val, NULL, 10);
   

Re: [FFmpeg-devel] [PATCH] avcodec: increase AV_INPUT_BUFFER_PADDING_SIZE to 64

[Rostislav Pehlivanov]

On 7 January 2018 at 04:22, James Almer  wrote:

> AVX-512 support has been introduced, and even if no functions currently
> use zmm registers (able to load as much as 64 bytes of consecutive data
> per instruction), they will be added eventually.
>
> Signed-off-by: James Almer 
> ---
> Same rationale as when it was increased to 32 back in commit
> 67d29da4bd23057a1f646568442a77b844cb2d1b.
>
>  libavcodec/avcodec.h  | 2 +-
>  libavcodec/x86/hevc_sao.asm   | 2 +-
>  libavcodec/x86/hevc_sao_10bit.asm | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index c13deb599f..8fbbc798a2 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -767,7 +767,7 @@ typedef struct AVCodecDescriptor {
>   * Note: If the first 23 bits of the additional bytes are not 0, then
> damaged
>   * MPEG bitstreams could cause overread and segfault.
>   */
> -#define AV_INPUT_BUFFER_PADDING_SIZE 32
> +#define AV_INPUT_BUFFER_PADDING_SIZE 64
>
>  /**
>   * @ingroup lavc_encoding
> diff --git a/libavcodec/x86/hevc_sao.asm b/libavcodec/x86/hevc_sao.asm
> index 888a28afa7..756adfee57 100644
> --- a/libavcodec/x86/hevc_sao.asm
> +++ b/libavcodec/x86/hevc_sao.asm
> @@ -198,7 +198,7 @@ HEVC_SAO_BAND_FILTER 64, 2
>  ;***
> ***
>
>  %define MAX_PB_SIZE  64
> -%define PADDING_SIZE 32 ; AV_INPUT_BUFFER_PADDING_SIZE
> +%define PADDING_SIZE 64 ; AV_INPUT_BUFFER_PADDING_SIZE
>  %define EDGE_SRCSTRIDE 2 * MAX_PB_SIZE + PADDING_SIZE
>
>  %macro HEVC_SAO_EDGE_FILTER_INIT 0
> diff --git a/libavcodec/x86/hevc_sao_10bit.asm b/libavcodec/x86/hevc_sao_
> 10bit.asm
> index f81e2d5033..b30583dd2f 100644
> --- a/libavcodec/x86/hevc_sao_10bit.asm
> +++ b/libavcodec/x86/hevc_sao_10bit.asm
> @@ -190,7 +190,7 @@ HEVC_SAO_BAND_FILTER 12, 64, 4
>  ;***
> ***
>
>  %define MAX_PB_SIZE  64
> -%define PADDING_SIZE 32 ; AV_INPUT_BUFFER_PADDING_SIZE
> +%define PADDING_SIZE 64 ; AV_INPUT_BUFFER_PADDING_SIZE
>  %define EDGE_SRCSTRIDE 2 * MAX_PB_SIZE + PADDING_SIZE
>
>  %macro PMINUW 4
> --
> 2.15.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Looks good to me
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] FFV1: make RGB48 support as non-experimental

[Jerome Martinez]

On 06/01/2018 23:21, Michael Niedermayer wrote:

On Sat, Jan 06, 2018 at 04:54:18PM +0100, Jerome Martinez wrote:

On 06/01/2018 02:05, Michael Niedermayer wrote:

  ffv1enc.c |4 
  1 file changed, 4 deletions(-)
acfc60c913b311b148f2eeef2d2d6ea9e37afcf7  
0001-avcodec-ffv1enc-mark-RGB48-support-as-non-experiment.patch
 From 303f63fb7e6172fdb7de66da1f8a4006b79a535f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Fri, 5 Jan 2018 11:09:01 +0100
Subject: [PATCH] avcodec/ffv1enc: mark RGB48 support as non-experimental

Resulting bitstream was tested with a conformance checker
using the last draft of FFV1 specifications.

But has the way this is stored been optimized ?

Once its marked as non exerimental all future decoders must support the exact
way.

Although this is considered experimental in the encoder, the implementation
adheres to the description in the specification. The bitstream specification
does not provide a bitdepth limit so with the current draft of the
specification, another FFV1 encoder could already encode 16-bit (and more)
content. The work on the specification has been careful to not break
compatibility with former drafts and at this point the FFV1 bitstream
specification for versions 0, 1, and 3 should be considered already
non-experimental for all bit depths. All current decoders should already
support the exact way it is currently specified.

To make a change in the specification at this point would have cascading
consequences as we’d have to retract the part of the specification which
states that micro_version 4 of version 3 is the first stable variant. Worse,
it is impossible to indicate a bitstream change in FFV1 version 1, which
permits RGB 16-bit content too, so it would be difficult for a decoder to
detect a bitstream not conforming to the bitstream created by the current
version of FFmpeg encoder.

Are you not making this look alot more complex than it is ?
Or maybe we talk about slightly different things here

with the next version we can introduce any method of storing 16bit or 9-15 bit
and we certainly do not support in the implementation all possible bit depths

 From what i remember I had always wanted to improve the way that
more than 8bit is handled, not just 16. Although 16 is a bit special

Consider this:
If we improve get_context() in the next version for >8bit
we still have to support 9-15 bit with the old definition
if we now declare 16bit non experimental then we also must support that with
an old get_context() in the decoder.
the 16bit path is seperate from the lower bit depth. So this is an Additional
codepath that we have to carry in the future

isnt it smarter now that if we want to improve get_context() that we
dont now extend what can be generated with the current get_context ?

or are such current get_context() style files already widespread ?
if so then its probably best to accept it and keep supporting it


I am lost.
Looks like we talk about 2 different subjects: FFV1 bitstream 
specifications and FFmpeg implementation.

Let separate subjects:

FFV1 bitstream specifications:
Since at least 2012 [1] get_context (in the bitstream) is defined and 
flagged as stable for **all** bit depths for versions 0, 1, 3.

It is still the case today [2].
There was a consensus on discussing about FFV1 bitstream on CELLAR 
mailing list
There was a consensus for not changing the bitstream for version 0, 1, 3 
so we can standardize it ASAP without breaking current implementations 
(reason we document bugs in the main encoder, but the idea is not to 
accept more changes)
If the FFV1 bitstream for version 0, 1, or 3 must be changed in current 
stable version, it would be a major break in the consensus and it should 
be discussed on CELLAR list (in copy as they are concerned), but I doubt 
the consensus would be for breaking the bitstream compatibility as the 
discussion from day 0 on CELLAR is to document current bitstream without 
changing it for versions 0, 1, 3. The fact that there was no (publicly 
available) RGB48 encoder in the wild is not an excuse for breaking the 
compatibility with current draft of specifications. Same if someone 
decides to do an encoder for e.g. RGB3000.
It is possible to change the bitstream with version 4 (experimental 
version), and it is a good place for changing get_context for 16-bit 
content (whatever is the color space, BTW).


FFmpeg implementation:
FFV1 YCbCr 16-bit is already flagged as non experimental, so there is 
already some non experimental 16-bit support in FFmpeg FFV1 encoder. 
16-bit is not new and for RGB48 the actual encoding after RGB to YCbCr 
transformation is just 1 bit more (17-bit).
FFmpeg experimental flag is for the status of the encoder, not for the 
status of the bitstream (the bitstream for versions 0, 1, 3 is already 
considered stable for RGB48 and others)

FFV1 RGB48 support in FFmpeg is conform to FFV1 bitstream specifications.
Optimizing FFmpeg for better 

Re: [FFmpeg-devel] [PATCH 4/5] aptx: implement the aptX HD bluetooth codec

[Rostislav Pehlivanov]

On 6 January 2018 at 16:48, Aurelien Jacobs  wrote:

> ---
>  Changelog   |   2 +-
>  configure   |   2 +
>  libavcodec/Makefile |   2 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/aptx.c   | 352 ++
> ++
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 +
>  7 files changed, 339 insertions(+), 28 deletions(-)
>
> diff --git a/Changelog b/Changelog
> index 3d966c202b..9349bf1e8d 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -11,7 +11,7 @@ version :
>  - TiVo ty/ty+ demuxer
>  - Intel QSV-accelerated MJPEG encoding
>  - PCE support for extended channel layouts in the AAC encoder
> -- native aptX encoder and decoder
> +- native aptX and aptX HD encoder and decoder
>  - Raw aptX muxer and demuxer
>  - NVIDIA NVDEC-accelerated H.264, HEVC, MPEG-1/2/4, VC1, VP8/9 hwaccel
> decoding
>  - Intel QSV-accelerated overlay filter
> diff --git a/configure b/configure
> index 1d2fffa132..c496346a06 100755
> --- a/configure
> +++ b/configure
> @@ -2459,6 +2459,8 @@ apng_encoder_deps="zlib"
>  apng_encoder_select="llvidencdsp"
>  aptx_decoder_select="audio_frame_queue"
>  aptx_encoder_select="audio_frame_queue"
> +aptx_hd_decoder_select="audio_frame_queue"
> +aptx_hd_encoder_select="audio_frame_queue"
>  asv1_decoder_select="blockdsp bswapdsp idctdsp"
>  asv1_encoder_select="bswapdsp fdctdsp pixblockdsp"
>  asv2_decoder_select="blockdsp bswapdsp idctdsp"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index cfacd6b70c..a9ecf7ea5e 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -190,6 +190,8 @@ OBJS-$(CONFIG_ANSI_DECODER)+= ansi.o
> cga_data.o
>  OBJS-$(CONFIG_APE_DECODER) += apedec.o
>  OBJS-$(CONFIG_APTX_DECODER)+= aptx.o
>  OBJS-$(CONFIG_APTX_ENCODER)+= aptx.o
> +OBJS-$(CONFIG_APTX_HD_DECODER) += aptx.o
> +OBJS-$(CONFIG_APTX_HD_ENCODER) += aptx.o
>  OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
>  OBJS-$(CONFIG_APNG_ENCODER)+= png.o pngenc.o
>  OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index ed1e7ab06e..93d31f8688 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -333,6 +333,7 @@ static void register_all(void)
>  REGISTER_DECODER(AMRWB, amrwb);
>  REGISTER_DECODER(APE,   ape);
>  REGISTER_ENCDEC (APTX,  aptx);
> +REGISTER_ENCDEC (APTX_HD,   aptx_hd);
>  REGISTER_DECODER(ATRAC1,atrac1);
>  REGISTER_DECODER(ATRAC3,atrac3);
>  REGISTER_DECODER(ATRAC3AL,  atrac3al);
> diff --git a/libavcodec/aptx.c b/libavcodec/aptx.c
> index 4173402d03..6c0f3d35a9 100644
> --- a/libavcodec/aptx.c
> +++ b/libavcodec/aptx.c
> @@ -89,6 +89,8 @@ typedef struct {
>  } Channel;
>
>  typedef struct {
> +int hd;
> +int block_size;
>  int32_t sync_idx;
>  Channel channels[NB_CHANNELS];
>  AudioFrameQueue afq;
> @@ -182,6 +184,205 @@ static const int16_t quantize_factor_select_offset_HF[5]
> = {
>  0, -8, 33, 95, 262,
>  };
>
> +
> +static const int32_t hd_quantize_intervals_LF[257] = {
> +  -2436,2436,7308,   12180,   17054,   21930,   26806,
>  31686,
> +  36566,   41450,   46338,   51230,   56124,   61024,   65928,
>  70836,
> +  75750,   80670,   85598,   90530,   95470,  100418,  105372,
> 110336,
> + 115308,  120288,  125278,  130276,  135286,  140304,  145334,
> 150374,
> + 155426,  160490,  165566,  170654,  175756,  180870,  185998,
> 191138,
> + 196294,  201466,  206650,  211850,  217068,  222300,  227548,
> 232814,
> + 238096,  243396,  248714,  254050,  259406,  264778,  270172,
> 275584,
> + 281018,  286470,  291944,  297440,  302956,  308496,  314056,
> 319640,
> + 325248,  330878,  336532,  342212,  347916,  353644,  359398,
> 365178,
> + 370986,  376820,  382680,  388568,  394486,  400430,  406404,
> 412408,
> + 418442,  424506,  430600,  436726,  442884,  449074,  455298,
> 461554,
> + 467844,  474168,  480528,  486922,  493354,  499820,  506324,
> 512866,
> + 519446,  526064,  532722,  539420,  546160,  552940,  559760,
> 566624,
> + 573532,  580482,  587478,  594520,  601606,  608740,  615920,
> 623148,
> + 630426,  637754,  645132,  652560,  660042,  667576,  675164,
> 682808,
> + 690506,  698262,  706074,  713946,  721876,  729868,  737920,
> 746036,
> + 754216,  762460,  770770,  779148,  787594,  796108,  804694,
> 813354,
> + 822086,  830892,  839774,  848736,  857776,  866896,  876100,
> 885386,
> + 894758,  904218,  913766,  923406,  933138,  942964,  952886,
> 962908,
> + 973030,  983254,  993582, 1004020, 1014566, 1025224, 1035996,
> 1046886,
> +1057894, 1069026, 1080284, 1091670, 1103186, 1114838, 1126628,
> 1138558,
> +1150634, 1162858, 1175236, 1187768, 

Re: [FFmpeg-devel] [PATCH 5/5] aptx: add raw muxer and demuxer for aptX HD

[Aurelien Jacobs]

On Sun, Jan 07, 2018 at 12:53:27AM +0100, Michael Niedermayer wrote:
> On Sat, Jan 06, 2018 at 05:48:08PM +0100, Aurelien Jacobs wrote:
> > ---
> >  Changelog|  2 +-
> >  libavformat/Makefile |  2 ++
> >  libavformat/allformats.c |  1 +
> >  libavformat/aptxdec.c| 51 
> > 
> >  libavformat/rawenc.c | 13 
> >  5 files changed, 64 insertions(+), 5 deletions(-)
> [...]
> > @@ -66,6 +94,7 @@ static const AVClass aptx_demuxer_class = {
> >  .version= LIBAVUTIL_VERSION_INT,
> >  };
> >  
> > +#if CONFIG_APTX_MUXER
> >  AVInputFormat ff_aptx_demuxer = {
> >  .name   = "aptx",
> >  .long_name  = NULL_IF_CONFIG_SMALL("raw aptX"),
> > @@ -76,3 +105,17 @@ AVInputFormat ff_aptx_demuxer = {
> >  .flags  = AVFMT_GENERIC_INDEX,
> 
> >  .priv_class = _demuxer_class,
> [...]
> > +.priv_class = _demuxer_class,
> 
> this cause the code (for example fate) to infinite loop

Oh, indeed, it seems 2 demuxers can't share the same priv_class.
Here is an updated patch.
>From 319e203fc6ec9ae7b17d28ac63b658a63c933176 Mon Sep 17 00:00:00 2001
From: Aurelien Jacobs 
Date: Sat, 6 Jan 2018 17:33:01 +0100
Subject: [PATCH 5/5] aptx: add raw muxer and demuxer for aptX HD

---
 Changelog|  2 +-
 libavformat/Makefile |  2 ++
 libavformat/allformats.c |  1 +
 libavformat/aptxdec.c| 58 
 libavformat/rawenc.c | 13 +++
 5 files changed, 71 insertions(+), 5 deletions(-)

diff --git a/Changelog b/Changelog
index 9349bf1e8d..3a97b0b02e 100644
--- a/Changelog
+++ b/Changelog
@@ -12,7 +12,7 @@ version :
 - Intel QSV-accelerated MJPEG encoding
 - PCE support for extended channel layouts in the AAC encoder
 - native aptX and aptX HD encoder and decoder
-- Raw aptX muxer and demuxer
+- Raw aptX and aptX HD muxer and demuxer
 - NVIDIA NVDEC-accelerated H.264, HEVC, MPEG-1/2/4, VC1, VP8/9 hwaccel decoding
 - Intel QSV-accelerated overlay filter
 - mcompand audio filter
diff --git a/libavformat/Makefile b/libavformat/Makefile
index cb70eac920..dbe2890297 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -96,6 +96,8 @@ OBJS-$(CONFIG_APNG_DEMUXER)  += apngdec.o
 OBJS-$(CONFIG_APNG_MUXER)+= apngenc.o
 OBJS-$(CONFIG_APTX_DEMUXER)  += aptxdec.o rawdec.o
 OBJS-$(CONFIG_APTX_MUXER)+= rawenc.o
+OBJS-$(CONFIG_APTX_HD_DEMUXER)   += aptxdec.o rawdec.o
+OBJS-$(CONFIG_APTX_HD_MUXER) += rawenc.o
 OBJS-$(CONFIG_AQTITLE_DEMUXER)   += aqtitledec.o subtitles.o
 OBJS-$(CONFIG_ASF_DEMUXER)   += asfdec_f.o asf.o asfcrypt.o \
 avlanguage.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 6a9b9883c9..b70b7463b9 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -70,6 +70,7 @@ static void register_all(void)
 REGISTER_DEMUXER (APE,  ape);
 REGISTER_MUXDEMUX(APNG, apng);
 REGISTER_MUXDEMUX(APTX, aptx);
+REGISTER_MUXDEMUX(APTX_HD,  aptx_hd);
 REGISTER_DEMUXER (AQTITLE,  aqtitle);
 REGISTER_MUXDEMUX(ASF,  asf);
 REGISTER_DEMUXER (ASF_O,asf_o);
diff --git a/libavformat/aptxdec.c b/libavformat/aptxdec.c
index 3b8fae1b55..467bc3fd5a 100644
--- a/libavformat/aptxdec.c
+++ b/libavformat/aptxdec.c
@@ -26,26 +26,49 @@
 #define APTX_BLOCK_SIZE   4
 #define APTX_PACKET_SIZE  (256*APTX_BLOCK_SIZE)
 
+#define APTX_HD_BLOCK_SIZE   6
+#define APTX_HD_PACKET_SIZE  (256*APTX_HD_BLOCK_SIZE)
+
 typedef struct AptXDemuxerContext {
 AVClass *class;
 int sample_rate;
 } AptXDemuxerContext;
 
-static int aptx_read_header(AVFormatContext *s)
+static AVStream *aptx_read_header_common(AVFormatContext *s)
 {
 AptXDemuxerContext *s1 = s->priv_data;
 AVStream *st = avformat_new_stream(s, NULL);
 if (!st)
-return AVERROR(ENOMEM);
+return NULL;
 st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
-st->codecpar->codec_id = AV_CODEC_ID_APTX;
 st->codecpar->format = AV_SAMPLE_FMT_S32P;
 st->codecpar->channels = 2;
 st->codecpar->sample_rate = s1->sample_rate;
+st->start_time = 0;
+return st;
+}
+
+static int aptx_read_header(AVFormatContext *s)
+{
+AVStream *st = aptx_read_header_common(s);
+if (!st)
+return AVERROR(ENOMEM);
+st->codecpar->codec_id = AV_CODEC_ID_APTX;
 st->codecpar->bits_per_coded_sample = 4;
 st->codecpar->block_align = APTX_BLOCK_SIZE;
 st->codecpar->frame_size = APTX_PACKET_SIZE;
-st->start_time = 0;
+return 0;
+}
+
+static int aptx_hd_read_header(AVFormatContext *s)
+{
+AVStream *st = aptx_read_header_common(s);
+if (!st)
+return AVERROR(ENOMEM);
+st->codecpar->codec_id = AV_CODEC_ID_APTX_HD;
+st->codecpar->bits_per_coded_sample = 6;
+

Re: [FFmpeg-devel] [PATCH 4/4] avformat/libopenmpt: Probe file format from file data if possible

[Jörn Heusipp]

On 01/06/2018 04:10 PM, Carl Eugen Hoyos wrote:

2018-01-06 11:07 GMT+01:00 Jörn Heusipp :



libopenmpt file header probing is tested regularly against the FATE
suite and other diverse file collections by libopenmpt upstream in
order to avoid false positives.


You could also test tools/probetest


I was not aware of that tool. Thanks for the suggestion.

It currently lists a failure related to libopenmpt:
Failure of libopenmpt probing code with score=76 type=0 p=FDC size=1024

Looking at tools/probetest.c, that would be a file with very few bits 
set. libopenmpt detects the random data in question as M15 .MOD files 
(original Amiga 15 samples .mod files), and there is sadly not much that 
can be done about that. There are perfectly valid real-world M15 .MOD 
files with only 73 bits set in the first 600 bytes 
(untouchables-station.mod, 
). 
The following up to 64*4*4*63 bytes could even be completely 0 (empty 
pattern data) for valid files (even without the file being totally 
silent). The generated random data that tools/probetest complains about 
here contains 46 bits set to 1 in the first 600 bytes. What follows are 
various other examples with up to 96 bits set to 1. Completely loading a 
file like that would very likely reject it (in particular, libopenmpt 
can deduce the expected file size from the sample headers and, with some 
slack to account for corrupted real-world examples, reject files with 
non-matching size), however, that is not possible when only probing the 
file header.
The libopenmpt API allows for the file header probing functions to 
return false-positives, however false-negatives are not allowed.


Performance numbers shown by tools/probetest are what I had expected 
(measured on an AMD A4-5000, during normal Xorg session (i.e. not 100% 
idle)):


  1110194971 cycles,   aa
 24986722468 cycles,  aac
 26418545168 cycles,  ac3
  1484717267 cycles,  acm
  1627888281 cycles,  act
  2109884646 cycles,  adp
  2316235992 cycles,  ads
  1244706028 cycles,  adx
  1132390431 cycles,  aea
  1729241354 cycles, aiff
  1728288238 cycles,  aix
  2662531158 cycles,  amr
 16189546067 cycles,amrnb
 10342883200 cycles,amrwb
  1487752343 cycles,  anm
  2268900502 cycles,  apc
  1140814303 cycles,  ape
  2181170710 cycles, apng
 18698762054 cycles,  aqtitle
  2656908730 cycles,  asf
  2402762967 cycles,asf_o
 18148196647 cycles,  ass
  1392503829 cycles,  ast
  1774264703 cycles,   au
  1807159562 cycles,  avi
  1745391230 cycles,  avr
  1370939762 cycles,  avs
  1555620708 cycles,  bethsoftvid
  1459171160 cycles,  bfi
  2640635742 cycles, bink
  2022320986 cycles,  bit
  1664933324 cycles,bfstm
  1588023172 cycles,brstm
  1769430536 cycles,  boa
  2294286860 cycles,  c93
  1022646071 cycles,  caf
  9063207678 cycles,cavsvideo
  1898790300 cycles, cdxl
  1037718383 cycles, cine
  3358938768 cycles,   concat
  2367399953 cycles,dcstr
  1795803759 cycles,  dfa
  1454750468 cycles,dirac
  1167905836 cycles,dnxhd
  2076678208 cycles,  dsf
  1226761232 cycles,   dsicin
  1157816261 cycles,  dss
 31466350564 cycles,  dts
  1357475606 cycles,dtshd
 15626181281 cycles,   dv
 12227021709 cycles,   dvbsub
  1747998309 cycles,   dvbtxt
  1941371107 cycles,  dxa
  1988122049 cycles,   ea
  1395161162 cycles, ea_cdata
 21013119067 cycles, eac3
  1282697126 cycles, epaf
  1658521102 cycles,  ffm
  2919787300 cycles,   ffmetadata
  3786264941 cycles, fits
  2700385826 cycles, flac
  1840776863 cycles, flic
  1317695853 cycles,  flv
  1511756606 cycles, live_flv
  1135064427 cycles,  4xm
  1830871233 cycles,  frm
  3011403748 cycles,  fsb
  1462985803 cycles,  gdv
  1708440935 cycles, genh
  3480430744 cycles,  gif
  2533542048 cycles,  gsm
  2412598563 cycles,  gxf
 21637989787 cycles, h261
 22268834035 cycles, h263
 22135718754 cycles, h264
 13939886275 cycles, hevc
  1979375582 cycles, hls,applehttp
  1658646375 cycles,  hnm
  1507634977 cycles,  ico
  2534774499 cycles,idcin
  1684324336 cycles,  idf
  1353664382 cycles,  iff
  2978779893 cycles, ilbc
  1892353081 cycles,alias_pix
  2456259645 cycles,  brender_pix
  2077466815 cycles,ingenient
 11281657144 cycles,  ipmovie
  1840789384 cycles,ircam
  2455541614 cycles,  iss
  1114518907 cycles,  iv8
  1750327098 cycles,  

Re: [FFmpeg-devel] [PATCH 3/4] avformat/libopenmpt: Update file extensions list for libopenmpt 0.3

[Jörn Heusipp]

On 01/06/2018 04:06 PM, Carl Eugen Hoyos wrote:

2018-01-06 11:07 GMT+01:00 Jörn Heusipp :

Signed-off-by: Jörn Heusipp 
---
  libavformat/libopenmpt.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
index 30c3d6e..5efbdc4 100644
--- a/libavformat/libopenmpt.c
+++ b/libavformat/libopenmpt.c
@@ -234,5 +234,9 @@ AVInputFormat ff_libopenmpt_demuxer = {
  .read_close = read_close_openmpt,
  .read_seek  = read_seek_openmpt,
  .priv_class = _openmpt,
-.extensions = 
"669,amf,ams,dbm,digi,dmf,dsm,far,gdm,imf,it,j2b,m15,mdl,med,mmcmp,mms,mo3,mod,mptm,mt2,mtm,nst,okt,plm,ppm,psm,pt36,ptm,s3m,sfx,sfx2,stk,stm,ult,umx,wow,xm,xpk",
+#if OPENMPT_API_VERSION_AT_LEAST(0,3,0)
+.extensions = 
"669,amf,ams,dbm,digi,dmf,dsm,dtm,far,gdm,ice,imf,it,j2b,m15,mdl,med,mmcmp,mms,mo3,mod,mptm,mt2,mtm,nst,okt,plm,ppm,psm,pt36,ptm,s3m,sfx,sfx2,st26,stk,stm,stp,ult,umx,wow,xm,xpk",
+#else
+.extensions = 
"669,amf,ams,dbm,digi,dmf,dsm,far,gdm,ice,imf,it,j2b,m15,mdl,med,mmcmp,mms,mo3,mod,mptm,mt2,mtm,nst,okt,plm,ppm,psm,pt36,ptm,s3m,sfx,sfx2,st26,stk,stm,ult,umx,wow,xm,xpk",
+#endif


I believe this change can be made without the version check.


Why would that be better? I cannot see much use in listing file 
extensions that are not supported by the libopenmpt version ffmpeg 
builds against.
If you prefer to have that changed, I'll do so. I would merely like to 
understand the reasons why.


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