Re: [FFmpeg-devel] Building FFmpeg dylibs for OSX

2018-02-23 Thread Helmut K. C. Tessarek 
On 2018-02-24 01:22, livinginlosange...@mac.com wrote:
> I can successfully compile ffmpeg info lgpl compliant dylibs which I can link 
> to from /usr/local. I specify /usr/local during my ./configure phase. All OK. 
> I want to be able to include them as dylibs in my OSX app package. The app 
> wants to see dylibs which are built using @rpath like @rpath/libavutil.dylib 
> when inspecting the dylib using otool. Would anyone have any recommendations 
> on how to accomplish this? I must include ffmpeg dylibs in my app.

You can have a look at how the VLC project does it. All of their libs
are dynamic libs which are located in one sub directory of the app.

So you have to set the rpath relative to your binary that makes the calls.

Cheers,
  K. C.

-- 
regards Helmut K. C. Tessarek  KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/*
   Thou shalt not follow the NULL pointer for chaos and madness
   await thee at its end.
*/



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

[FFmpeg-devel] [PATCH] avformat/dashenc: Removed usage of deprecated 'filename' variable

2018-02-23 Thread Karthick J 
From: Karthick Jeyapal 

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

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index d6474f3..ebff3c5 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1307,7 +1307,7 @@ static int dash_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 //open the output context when the first frame of a segment is ready
 if (!c->single_file && !os->out) {
 AVDictionary *opts = NULL;
-const char *proto = avio_find_protocol_name(s->filename);
+const char *proto = avio_find_protocol_name(s->url);
 int use_rename = proto && !strcmp(proto, "file");
 os->filename[0] = os->full_path[0] = os->temp_path[0] = '\0';
 ff_dash_fill_tmpl_params(os->filename, sizeof(os->filename),
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH 3/3] avformat/dashenc: chunk streaming support for low latency use cases

2018-02-23 Thread Jeyapal, Karthick 


On 2/19/18 11:25 AM, vdi...@akamai.com wrote:
> From: Vishwanath Dixit 
>
> ---
>  doc/muxers.texi   |  3 +++
>  libavformat/dashenc.c | 26 +++---
>  2 files changed, 26 insertions(+), 3 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index d9a5cc0..c156ec0 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -254,6 +254,9 @@ Use persistent HTTP connections. Applicable only for HTTP 
> output.
>  @item -hls_playlist @var{hls_playlist}
>  Generate HLS playlist files as well. The master playlist is generated with 
> the filename master.m3u8.
>  One media playlist file is generated for each stream with filenames 
> media_0.m3u8, media_1.m3u8, etc.
> +@item -streaming @var{streaming}
> +Enable (1) or disable (0) chunk streaming mode of output. In chunk streaming
> +mode, each frame will be a moof fragment which forms a chunk.
>  @item -adaptation_sets @var{adaptation_sets}
>  Assign streams to AdaptationSets. Syntax is "id=x,streams=a,b,c 
> id=y,streams=d,e" with x and y being the IDs
>  of the adaptation sets and a,b,c,d and e are the indices of the mapped 
> streams.
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 0eb4b25..d6474f3 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -81,6 +81,7 @@ typedef struct OutputStream {
>  char bandwidth_str[64];
>  
>  char codec_str[100];
> +int written_len;
>  char filename[1024];
>  char full_path[1024];
>  char temp_path[1024];
> @@ -114,6 +115,7 @@ typedef struct DASHContext {
>  int master_playlist_created;
>  AVIOContext *mpd_out;
>  AVIOContext *m3u8_out;
> +int streaming;
>  } DASHContext;
>  
>  static struct codec_string {
> @@ -250,7 +252,8 @@ static int flush_dynbuf(OutputStream *os, int 
> *range_length)
>  // write out to file
>  *range_length = avio_close_dyn_buf(os->ctx->pb, );
>  os->ctx->pb = NULL;
> -avio_write(os->out, buffer, *range_length);
> +avio_write(os->out, buffer + os->written_len, *range_length - 
> os->written_len);
> +os->written_len = 0;
>  av_free(buffer);
>  
>  // re-open buffer
> @@ -960,7 +963,10 @@ static int dash_init(AVFormatContext *s)
>  os->init_start_pos = 0;
>  
>  if (!strcmp(os->format_name, "mp4")) {
> -av_dict_set(, "movflags", "frag_custom+dash+delay_moov", 0);
> +if (c->streaming)
> +av_dict_set(, "movflags", 
> "frag_every_frame+dash+delay_moov", 0);
> +else
> +av_dict_set(, "movflags", 
> "frag_custom+dash+delay_moov", 0);
>  } else {
>  av_dict_set_int(, "cluster_time_limit", c->min_seg_duration 
> / 1000, 0);
>  av_dict_set_int(, "cluster_size_limit", 5 * 1024 * 1024, 
> 0); // set a large cluster size limit
> @@ -1155,7 +1161,7 @@ static int dash_flush(AVFormatContext *s, int final, 
> int stream)
>  }
>  
>  if (!c->single_file) {
> -if (!strcmp(os->format_name, "mp4"))
> +if (!strcmp(os->format_name, "mp4") && !os->written_len)
>  write_styp(os->ctx->pb);
>  } else {
>  snprintf(os->full_path, sizeof(os->full_path), "%s%s", 
> c->dirname, os->initfile);
> @@ -1318,6 +1324,19 @@ static int dash_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  av_dict_free();
>  }
>  
> +//write out the data immediately in streaming mode
> +if (c->streaming && !strcmp(os->format_name, "mp4")) {
> +int len = 0;
> +uint8_t *buf = NULL;
> +if (!os->written_len)
> +write_styp(os->ctx->pb);
> +avio_flush(os->ctx->pb);
> +len = avio_get_dyn_buf (os->ctx->pb, );
> +avio_write(os->out, buf + os->written_len, len - os->written_len);
> +os->written_len = len;
> +avio_flush(os->out);
> +}
> +
>  return ret;
>  }
>  
> @@ -1394,6 +1413,7 @@ static const AVOption options[] = {
>  { "http_user_agent", "override User-Agent field in HTTP header", 
> OFFSET(user_agent), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E},
>  { "http_persistent", "Use persistent HTTP connections", 
> OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
>  { "hls_playlist", "Generate HLS playlist files(master.m3u8, 
> media_%d.m3u8)", OFFSET(hls_playlist), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, 
> E },
> +{ "streaming", "Enable/Disable streaming mode of output. Each frame will 
> be moof fragment", OFFSET(streaming), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E 
> },
>  { NULL },
>  };
>  
Patchset pushed.

Regards,
Karthick


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

[FFmpeg-devel] Building FFmpeg dylibs for OSX

2018-02-23 Thread livinginlosangeles 
I can successfully compile ffmpeg info lgpl compliant dylibs which I can link 
to from /usr/local. I specify /usr/local during my ./configure phase. All OK. I 
want to be able to include them as dylibs in my OSX app package. The app wants 
to see dylibs which are built using @rpath like @rpath/libavutil.dylib when 
inspecting the dylib using otool. Would anyone have any recommendations on how 
to accomplish this? I must include ffmpeg dylibs in my app.

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

Re: [FFmpeg-devel] [PATCH] DASH muxer: add option to change HTTP method

2018-02-23 Thread Jeyapal, Karthick 


On 2/23/18 3:30 PM, Serhii Marchuk wrote:
> ---
>  libavformat/dashenc.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 0f6f4f22fa..28ff288fca 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -105,6 +105,7 @@ typedef struct DASHContext {
>  const char *init_seg_name;
>  const char *media_seg_name;
>  const char *utc_timing_url;
> +const char *method;
>  const char *user_agent;
>  int hls_playlist;
>  int http_persistent;
> @@ -256,6 +257,8 @@ static int flush_dynbuf(OutputStream *os, int 
> *range_length)
>  
>  static void set_http_options(AVDictionary **options, DASHContext *c)
>  {
> +if (c->method)
> +av_dict_set(options, "method", c->method, 0);
>  if (c->user_agent)
>  av_dict_set(options, "user_agent", c->user_agent, 0);
>  if (c->http_persistent)
> @@ -1376,6 +1379,7 @@ static const AVOption options[] = {
>  { "init_seg_name", "DASH-templated name to used for the initialization 
> segment", OFFSET(init_seg_name), AV_OPT_TYPE_STRING, {.str = 
> "init-stream$RepresentationID$.m4s"}, 0, 0, E },
>  { "media_seg_name", "DASH-templated name to used for the media 
> segments", OFFSET(media_seg_name), AV_OPT_TYPE_STRING, {.str = 
> "chunk-stream$RepresentationID$-$Number%05d$.m4s"}, 0, 0, E },
>  { "utc_timing_url", "URL of the page that will return the UTC timestamp 
> in ISO format", OFFSET(utc_timing_url), AV_OPT_TYPE_STRING, { 0 }, 0, 0, E },
> +{ "method", "set the HTTP method", OFFSET(method), AV_OPT_TYPE_STRING, 
> {.str = NULL}, 0, 0, E },
>  { "http_user_agent", "override User-Agent field in HTTP header", 
> OFFSET(user_agent), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E},
>  { "http_persistent", "Use persistent HTTP connections", 
> OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
>  { "hls_playlist", "Generate HLS playlist files(master.m3u8, 
> media_%d.m3u8)", OFFSET(hls_playlist), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, 
> E },

Thanks for sending the patch. The patch looks fine. 
But, please change the commit message’s prefix from “DASH muxer” to 
“avformat/dashenc”, in order to maintain the uniformity with other commit 
messages.

Regards,
Karthick

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

Re: [FFmpeg-devel] [PATCH] avformat/hevc: zero initialize the nal buffers past the last written byte

2018-02-23 Thread James Almer 
On 2/23/2018 11:42 PM, Michael Niedermayer wrote:
> On Fri, Feb 23, 2018 at 12:05:54AM -0300, James Almer wrote:
>> Prevents use of uninitialized values.
>>
>> Fixes ticket #7038.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/hevc.c | 2 ++
>>  1 file changed, 2 insertions(+)
> 
> probably ok
> 
> thx

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

Re: [FFmpeg-devel] [PATCH 2/2] doc/bitstream_filters: documents delete_filler option.

2018-02-23 Thread Michael Niedermayer 
On Fri, Feb 23, 2018 at 03:12:42PM +0800, Jun Zhao wrote:
> 

>  bitstream_filters.texi |3 +++
>  1 file changed, 3 insertions(+)
> 938bac08c9db9bbec9181417952755dba107554c  
> 0002-doc-bitstream_filters-documents-delete_filler-option.patch
> From 9567abf90857ed1401cf041079635c0f688865cc Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Fri, 23 Feb 2018 15:02:29 +0800
> Subject: [PATCH 2/2] doc/bitstream_filters: documents delete_filler option.
> 
> documents delete_filler option for bsf h264_metadata.
> 
> Signed-off-by: Jun Zhao 
> ---
>  doc/bitstream_filters.texi | 3 +++
>  1 file changed, 3 insertions(+)

will apply

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

Re: [FFmpeg-devel] [PATCH] avcodec/smc: Check input packet size

2018-02-23 Thread Michael Niedermayer 
On Fri, Feb 23, 2018 at 05:15:20AM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 
> 6261/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SMC_fuzzer-5811309653262336
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/smc.c | 4 
>  1 file changed, 4 insertions(+)

will apply

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: fix max_error_rate help info display issue.

2018-02-23 Thread Michael Niedermayer 
On Fri, Feb 23, 2018 at 04:08:09PM +0800, Jun Zhao wrote:
> 

>  ffmpeg_opt.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> eb647d9949ae4d3da7b93630bc527653d4ebeb46  
> 0001-ffmpeg_opt-fix-max_error_rate-help-info-display-issu.patch
> From 5272bc77ec1834f767277f1cdf8ac13727a19319 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Fri, 23 Feb 2018 15:58:10 +0800
> Subject: [PATCH] ffmpeg_opt: fix max_error_rate help info display issue.
> 
> ffmpeg -h display "max_error_rate" option help information have
> been cut off, the root cause is used a wrong initial order.
> 
> Signed-off-by: Jun Zhao 
> ---
>  fftools/ffmpeg_opt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

thanks

[...]

-- 
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] [mpegaudio_parser] Skip trailing junk data when flushing parser.

2018-02-23 Thread Michael Niedermayer 
On Fri, Feb 23, 2018 at 11:15:09AM -0800, Dale Curtis wrote:
> Whoops, that version spams on every flush; changed to only print when
> buf_size > 0.
> 
> - dale
> 
> On Fri, Feb 23, 2018 at 10:37 AM, Dale Curtis 
> wrote:
> 
> > After some deeper testing it looks like this mechanism can actually fully
> > replace the existing ID3 and APE tag skips; so I've simplified the patch to
> > do so.
> >
> > - dale
> >
> >
> > On Thu, Feb 22, 2018 at 4:46 PM, Dale Curtis 
> > wrote:
> >
> >> The parser should only return valid mpeg audio packets; it generally
> >> does so, but in the case of flush, it returns whatever happens to
> >> be in the buffer instead of ensuring its first a valid mpeg packet.
> >>
> >> The fix is to check whether a valid frame size has been parsed and
> >> if not discard the packet when flushing.
> >>
> >> This should fix all sorts of mp3 files with trailing garbage.
> >>
> >> Signed-off-by: Dale Curtis 
> >>
> >>
> >

>  mpegaudio_parser.c |   11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 91db6134e5c81519dd88289c8956851015183515  fix_trailing_garbage_mp3_v3.patch
> From b81ec4a9a3907e21cc4c4abcf5502778be94076a Mon Sep 17 00:00:00 2001
> From: Dale Curtis 
> Date: Thu, 22 Feb 2018 16:43:37 -0800
> Subject: [PATCH] [mpegaudio_parser] Skip trailing junk data when flushing
>  parser.
> 
> The parser should only return valid mpeg audio packets; it generally
> does so, but in the case of flush, it returns whatever happens to
> be in the buffer instead of ensuring its first a valid mpeg packet.

this goes the wrong direction.
Parsers should not discard data by default. The code we have for tags is a hack.
There are many better ways to handle this.
Something similar to a AV_PKT_FLAG_CORRUPT set be the parser would be an
example. This could then optionally be discarded


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] avformat/hevc: zero initialize the nal buffers past the last written byte

2018-02-23 Thread Michael Niedermayer 
On Fri, Feb 23, 2018 at 12:05:54AM -0300, James Almer wrote:
> Prevents use of uninitialized values.
> 
> Fixes ticket #7038.
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/hevc.c | 2 ++
>  1 file changed, 2 insertions(+)

probably ok

thx

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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

Re: [FFmpeg-devel] Fix memset size on ctts_data in mov_read_trun()

2018-02-23 Thread 王消寒 
Michael: Dale and I dig into history a bit more and we don't understand why
the code is changed to the current state around memset. This new patch
reverted the change back to the previous state which we felt is much
cleaner. Please see the CL description for details and take a look at the
new patch. Thanks!

On Wed, Feb 21, 2018 at 1:14 PM, Xiaohan Wang (王消寒) 
wrote:

> jstebbins: kindly ping!
>
> On Fri, Feb 16, 2018 at 2:42 PM, Xiaohan Wang (王消寒) 
> wrote:
>
>> +jstebbins@ who wrote that code.
>>
>> On Fri, Feb 16, 2018 at 12:30 PM, Michael Niedermayer <
>> mich...@niedermayer.cc> wrote:
>>
>>> On Thu, Feb 15, 2018 at 12:10:33PM -0800, Xiaohan Wang (王消寒) wrote:
>>> >
>>>
>>> >  mov.c |3 ++-
>>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>>> > 5597d0b095f8b15eb11503010a51c2bc2c022413
>>> 0001-ffmpeg-Fix-memset-size-on-ctts_data-in-mov_read_trun.patch
>>> > From 7c1e6b50ebe35b2a38c4f1d0a988e31eccbd0ead Mon Sep 17 00:00:00 2001
>>> > From: Xiaohan Wang 
>>> > Date: Thu, 15 Feb 2018 12:05:53 -0800
>>> > Subject: [PATCH] ffmpeg: Fix memset size on ctts_data in
>>> mov_read_trun()
>>> >
>>> > The allocated size of sc->ctts_data is
>>> > (st->nb_index_entries + entries) * sizeof(*sc->ctts_data).
>>> >
>>> > The size to memset at offset sc->ctts_data + sc->ctts_count should be
>>> > (st->nb_index_entries + entries - sc->ctts_count) *
>>> sizeof(*sc->ctts_data))
>>> >
>>> > The current code missed |entries| I believe.
>>>
>>> shouldnt "entries" be read by this function later and so shouldnt need a
>>> memset?
>>> I didnt write this, but it looks a bit to me as if it was intended to
>>> only
>>> clear the area that would not be read later
>>>
>>
>> I thought we only had sc->ctts_count entries before av_fast_realloc, so
>> memset everything starting from sc->ctts_data + sc->ctts_count couldn't
>> go wrong. But I am not familiar with this code and that could totally be
>> wrong. I added jstebbins@ who wrote the code and hopefully we can get
>> expert opinion there.
>>
>>
>>> [...]
>>> --
>>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>>
>>> No great genius has ever existed without some touch of madness. --
>>> Aristotle
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>>
>>
>
From f34b35ec5749c17b21f80665a0b8859bce3e84ab Mon Sep 17 00:00:00 2001
From: Xiaohan Wang 
Date: Fri, 23 Feb 2018 10:51:30 -0800
Subject: [PATCH] Fix memset size on ctts_data in mov_read_trun() (round 2)

The allocated size of sc->ctts_data is
(st->nb_index_entries + entries) * sizeof(*sc->ctts_data).

The size to memset at offset sc->ctts_data + sc->ctts_count should be
(st->nb_index_entries + entries - sc->ctts_count) *
sizeof(*sc->ctts_data))

The current code missed |entries| I believe, which was introduced in
https://patchwork.ffmpeg.org/patch/5541/.

However, after offline discussion, it seems the original code is much
more clear to read (before https://patchwork.ffmpeg.org/patch/5541/).

Hence this CL revert the memset logic to it's previous state by
remembering the |old_ctts_allocated_size|, and only memset the newly
allocated entries.
---
 libavformat/mov.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index a3725692a7..f8d79c7b02 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4713,6 +4713,7 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 st->index_entries= new_entries;
 
 requested_size = (st->nb_index_entries + entries) * sizeof(*sc->ctts_data);
+unsigned int old_ctts_allocated_size = sc->ctts_allocated_size;
 ctts_data = av_fast_realloc(sc->ctts_data, >ctts_allocated_size,
 requested_size);
 if (!ctts_data)
@@ -4722,8 +4723,8 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 // In case there were samples without ctts entries, ensure they get
 // zero valued entries. This ensures clips which mix boxes with and
 // without ctts entries don't pickup uninitialized data.
-memset(sc->ctts_data + sc->ctts_count, 0,
-   (st->nb_index_entries - sc->ctts_count) * sizeof(*sc->ctts_data));
+memset((uint8_t*)(sc->ctts_data) + old_ctts_allocated_size, 0,
+   sc->ctts_allocated_size - old_ctts_allocated_size);
 
 if (index_entry_pos < st->nb_index_entries) {
 // Make hole in index_entries and ctts_data for new samples
-- 
2.16.1.291.g4437f3f132-goog

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: pass the correct AVCodecContext to av_parser_change()

2018-02-23 Thread Michael Niedermayer 
On Fri, Feb 23, 2018 at 11:15:50AM -0300, James Almer wrote:
> On 2/23/2018 4:35 AM, Hendrik Leppkes wrote:
> > On Fri, Feb 23, 2018 at 1:28 AM, James Almer  wrote:
> >> On 2/22/2018 8:52 PM, Hendrik Leppkes wrote:
> >>> On Fri, Feb 23, 2018 at 12:37 AM, James Almer  wrote:
>  On 2/22/2018 8:34 PM, Hendrik Leppkes wrote:
> > On Fri, Feb 23, 2018 at 12:20 AM, James Almer  wrote:
> >> av_parser_change() is effectively a noop if the avctx passed it to
> >> doesn't have the global header or local header flags set, and
> >> initializing a custom AVCodecContext as a copy of an
> >> AVCodecParameters results in the flags and flags2 fields being zero.
> >> Use instead the existing custom AVCodecContext with the required
> >> flags set in ffmpeg_opt.c new_output_stream() among other places.
> >>
> >> The fate test change is the result of the hevc sps/pps/vps being
> >> removed from frames when copying into a format that explicitly
> >> states it uses global header.
> >>
> >
> > Deleting inband headers is not necessarily a good idea, and likely
> > also why its being skipped for h264.
> 
>  Well, I'd argue it is when the user and/or the output format request it.
> 
> >>>
> >>> Unless there is an explicit option to request that, thats not exactly the 
> >>> case.
> >>>
> >>> - Hendrik
> >>
> >> The AVCodecContext global_header flag, which is what av_parser_change()
> >> looks at. It's either set with an AVOption (With the CLI that's using
> >> -flags +global_header) when encoding, or force enabled in
> >>
> >> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=fftools/ffmpeg_opt.c;h=997d53838108c2c3deb7fa3d3f395712738dad86;hb=HEAD#l1495
> >>
> >> as mentioned in the commit message, depending on the constant
> >> flag/capability set by the muxer.
> > 
> > Thats not what I mean, I know about that flag - and it controls AnnexB
> > vs MP4, but it does not explicitly say "remove inband headers as
> > well".
> > If anything I think HEVC should follow the H264 example for consistency.
> > 
> > There are plenty cases where removing the in-band headers results in 
> > problems.
> 
> So, if removing in-band headers is not desired, what exactly was the
> point/benefit of this entire chunk of code? I'm not sure the
> local_header portion of av_parser_change (to dump out of band headers at
> every keyframe) can be triggered currently. Neither -flags
> +global_header or -flags2 +local_header seem to work for codec copy,
> seeing the former is ignored and the latter gives an error.
> 
> Who wrote it, for that matter? It's been dead code for years.
> Maybe it should be removed altogether. Nobody missed it all this time,
> and skipping hevc as well would leave mpeg4 only.

I suspect (but someone would have to check the various specs to confirm)
that the in band headers are not really correct in the cases where a place
for global headers exist for these headers. Even if they are correct they 
are a waste of space as they must be repeated at _every_ point where 
seeking can bring one to.

The "correct" thing to do is to collect all the in band headers, put them
ALL in the global header spot of the container and update the index in band
to refer to them. Or use other higher level features to switch between global
headers where the container supports this. 

This is much harder than just leaving the headers in place in band of course


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] h264 and opus in .mp4 container

2018-02-23 Thread Lou Logan 
On Thu, Feb 22, 2018, at 9:00 PM, Vittalprasad wrote:
> Hi All,
> From below link i saw that mp4 container can have h264 as video codec and
> opus as audio codec. so i tried  both codecs in to mp4 using ffmpeg, but
> external player like mplayer, vlc and kmp are failing to decode voice . i.e
> while playing mp4 file there is only video no voice.
> https://en.wikipedia.org/wiki/Comparison_of_video_container_formats
> 
> Procedure followed using ffmpeg:
> 1. From sample mp4 file, i have separated audio(aac codec) and video(h264)
> in to different files .
> 2. aac trans-coded to opus
> 3. tried to merge video and audio(opus) in to single mp4
> 
> 
> please let me know
> 1. whether ffmpeg support above codecs in single mp4 file or issue with
> external player .
> 
> If anyone has  mp4 file with h264 and opus codecs please provide me along
> with procedure to convert.
> 
> 
> Thanks & Regards
> Vittal Prasad B R

Wrong mailing list. ffmpeg-devel is only for patch submissions and discussions 
related to the development of FFmpeg. Usage questions involving the FFmpeg cli 
tools should be asked at the ffmpeg-user mailing list.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] DASH muxer: add option to change HTTP method

2018-02-23 Thread Serhii Marchuk 
---
 libavformat/dashenc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 0f6f4f22fa..28ff288fca 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -105,6 +105,7 @@ typedef struct DASHContext {
 const char *init_seg_name;
 const char *media_seg_name;
 const char *utc_timing_url;
+const char *method;
 const char *user_agent;
 int hls_playlist;
 int http_persistent;
@@ -256,6 +257,8 @@ static int flush_dynbuf(OutputStream *os, int *range_length)
 
 static void set_http_options(AVDictionary **options, DASHContext *c)
 {
+if (c->method)
+av_dict_set(options, "method", c->method, 0);
 if (c->user_agent)
 av_dict_set(options, "user_agent", c->user_agent, 0);
 if (c->http_persistent)
@@ -1376,6 +1379,7 @@ static const AVOption options[] = {
 { "init_seg_name", "DASH-templated name to used for the initialization 
segment", OFFSET(init_seg_name), AV_OPT_TYPE_STRING, {.str = 
"init-stream$RepresentationID$.m4s"}, 0, 0, E },
 { "media_seg_name", "DASH-templated name to used for the media segments", 
OFFSET(media_seg_name), AV_OPT_TYPE_STRING, {.str = 
"chunk-stream$RepresentationID$-$Number%05d$.m4s"}, 0, 0, E },
 { "utc_timing_url", "URL of the page that will return the UTC timestamp in 
ISO format", OFFSET(utc_timing_url), AV_OPT_TYPE_STRING, { 0 }, 0, 0, E },
+{ "method", "set the HTTP method", OFFSET(method), AV_OPT_TYPE_STRING, 
{.str = NULL}, 0, 0, E },
 { "http_user_agent", "override User-Agent field in HTTP header", 
OFFSET(user_agent), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E},
 { "http_persistent", "Use persistent HTTP connections", 
OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
 { "hls_playlist", "Generate HLS playlist files(master.m3u8, 
media_%d.m3u8)", OFFSET(hls_playlist), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E 
},
-- 
2.14.1

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

Re: [FFmpeg-devel] [mpegaudio_parser] Skip trailing junk data when flushing parser.

2018-02-23 Thread Dale Curtis 
Whoops, that version spams on every flush; changed to only print when
buf_size > 0.

- dale

On Fri, Feb 23, 2018 at 10:37 AM, Dale Curtis 
wrote:

> After some deeper testing it looks like this mechanism can actually fully
> replace the existing ID3 and APE tag skips; so I've simplified the patch to
> do so.
>
> - dale
>
>
> On Thu, Feb 22, 2018 at 4:46 PM, Dale Curtis 
> wrote:
>
>> The parser should only return valid mpeg audio packets; it generally
>> does so, but in the case of flush, it returns whatever happens to
>> be in the buffer instead of ensuring its first a valid mpeg packet.
>>
>> The fix is to check whether a valid frame size has been parsed and
>> if not discard the packet when flushing.
>>
>> This should fix all sorts of mp3 files with trailing garbage.
>>
>> Signed-off-by: Dale Curtis 
>>
>>
>
From b81ec4a9a3907e21cc4c4abcf5502778be94076a Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Thu, 22 Feb 2018 16:43:37 -0800
Subject: [PATCH] [mpegaudio_parser] Skip trailing junk data when flushing
 parser.

The parser should only return valid mpeg audio packets; it generally
does so, but in the case of flush, it returns whatever happens to
be in the buffer instead of ensuring its first a valid mpeg packet.

The fix is to check whether a valid frame size has been parsed and
if not discard the packet when flushing.

This should fix all sorts of mp3 files with trailing garbage.

Signed-off-by: Dale Curtis 
---
 libavcodec/mpegaudio_parser.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/libavcodec/mpegaudio_parser.c b/libavcodec/mpegaudio_parser.c
index 244281b56f..87365a2c75 100644
--- a/libavcodec/mpegaudio_parser.c
+++ b/libavcodec/mpegaudio_parser.c
@@ -23,8 +23,6 @@
 #include "parser.h"
 #include "mpegaudiodecheader.h"
 #include "libavutil/common.h"
-#include "libavformat/apetag.h" // for APE tag.
-#include "libavformat/id3v1.h" // for ID3v1_TAG_SIZE
 
 typedef struct MpegAudioParseContext {
 ParseContext pc;
@@ -115,13 +113,8 @@ static int mpegaudio_parse(AVCodecParserContext *s1,
 return buf_size;
 }
 
-if (flush && buf_size >= ID3v1_TAG_SIZE && memcmp(buf, "TAG", 3) == 0) {
-*poutbuf = NULL;
-*poutbuf_size = 0;
-return next;
-}
-
-if (flush && buf_size >= APE_TAG_FOOTER_BYTES && memcmp(buf, APE_TAG_PREAMBLE, 8) == 0) {
+if (flush && buf_size && !s->frame_size) {
+av_log(avctx, AV_LOG_WARNING, "Discarding invalid trailing data from mpeg audio stream.\n");
 *poutbuf = NULL;
 *poutbuf_size = 0;
 return next;
-- 
2.16.1.291.g4437f3f132-goog

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

Re: [FFmpeg-devel] [mpegaudio_parser] Skip trailing junk data when flushing parser.

2018-02-23 Thread Dale Curtis 
After some deeper testing it looks like this mechanism can actually fully
replace the existing ID3 and APE tag skips; so I've simplified the patch to
do so.

- dale

On Thu, Feb 22, 2018 at 4:46 PM, Dale Curtis 
wrote:

> The parser should only return valid mpeg audio packets; it generally
> does so, but in the case of flush, it returns whatever happens to
> be in the buffer instead of ensuring its first a valid mpeg packet.
>
> The fix is to check whether a valid frame size has been parsed and
> if not discard the packet when flushing.
>
> This should fix all sorts of mp3 files with trailing garbage.
>
> Signed-off-by: Dale Curtis 
>
>
From f911dcfcb059e4d439a7ba74417fcb92a4079ae9 Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Thu, 22 Feb 2018 16:43:37 -0800
Subject: [PATCH] [mpegaudio_parser] Skip trailing junk data when flushing
 parser.

The parser should only return valid mpeg audio packets; it generally
does so, but in the case of flush, it returns whatever happens to
be in the buffer instead of ensuring its first a valid mpeg packet.

The fix is to check whether a valid frame size has been parsed and
if not discard the packet when flushing.

This should fix all sorts of mp3 files with trailing garbage.

Signed-off-by: Dale Curtis 
---
 libavcodec/mpegaudio_parser.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/libavcodec/mpegaudio_parser.c b/libavcodec/mpegaudio_parser.c
index 244281b56f..f68b26d238 100644
--- a/libavcodec/mpegaudio_parser.c
+++ b/libavcodec/mpegaudio_parser.c
@@ -23,8 +23,6 @@
 #include "parser.h"
 #include "mpegaudiodecheader.h"
 #include "libavutil/common.h"
-#include "libavformat/apetag.h" // for APE tag.
-#include "libavformat/id3v1.h" // for ID3v1_TAG_SIZE
 
 typedef struct MpegAudioParseContext {
 ParseContext pc;
@@ -115,13 +113,8 @@ static int mpegaudio_parse(AVCodecParserContext *s1,
 return buf_size;
 }
 
-if (flush && buf_size >= ID3v1_TAG_SIZE && memcmp(buf, "TAG", 3) == 0) {
-*poutbuf = NULL;
-*poutbuf_size = 0;
-return next;
-}
-
-if (flush && buf_size >= APE_TAG_FOOTER_BYTES && memcmp(buf, APE_TAG_PREAMBLE, 8) == 0) {
+if (flush && !s->frame_size) {
+av_log(avctx, AV_LOG_WARNING, "Discarding invalid trailing data from mpeg audio stream.\n");
 *poutbuf = NULL;
 *poutbuf_size = 0;
 return next;
-- 
2.16.1.291.g4437f3f132-goog

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

[FFmpeg-devel] [PATCH 2/2] avcodec/vc2enc: do not reset the last_parse_code variable every frame

2018-02-23 Thread James Darnley 
It should be kept between frames so that the encoder can actually know
whether the previous parse_code was an End Sequence.
---
 libavcodec/vc2enc.c | 1 -
 tests/ref/vsynth/vsynth1-vc2-420p   | 2 +-
 tests/ref/vsynth/vsynth1-vc2-420p10 | 2 +-
 tests/ref/vsynth/vsynth1-vc2-420p12 | 2 +-
 tests/ref/vsynth/vsynth1-vc2-422p   | 2 +-
 tests/ref/vsynth/vsynth1-vc2-422p10 | 2 +-
 tests/ref/vsynth/vsynth1-vc2-422p12 | 2 +-
 tests/ref/vsynth/vsynth1-vc2-444p   | 2 +-
 tests/ref/vsynth/vsynth1-vc2-444p10 | 2 +-
 tests/ref/vsynth/vsynth1-vc2-444p12 | 2 +-
 tests/ref/vsynth/vsynth2-vc2-420p   | 2 +-
 tests/ref/vsynth/vsynth2-vc2-420p10 | 2 +-
 tests/ref/vsynth/vsynth2-vc2-420p12 | 2 +-
 tests/ref/vsynth/vsynth2-vc2-422p   | 2 +-
 tests/ref/vsynth/vsynth2-vc2-422p10 | 2 +-
 tests/ref/vsynth/vsynth2-vc2-422p12 | 2 +-
 tests/ref/vsynth/vsynth2-vc2-444p   | 2 +-
 tests/ref/vsynth/vsynth2-vc2-444p10 | 2 +-
 tests/ref/vsynth/vsynth2-vc2-444p12 | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-420p   | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-420p10 | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-420p12 | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-422p   | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-422p10 | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-422p12 | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-444p   | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-444p10 | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-444p12 | 2 +-
 28 files changed, 27 insertions(+), 28 deletions(-)

diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 9a5a4765c8..a1385b35dd 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -1014,7 +1014,6 @@ static av_cold int vc2_encode_frame(AVCodecContext 
*avctx, AVPacket *avpkt,
 s->avctx = avctx;
 s->size_scaler = 2;
 s->prefix_bytes = 0;
-s->last_parse_code = 0;
 s->next_parse_offset = 0;
 
 /* Rate control */
diff --git a/tests/ref/vsynth/vsynth1-vc2-420p 
b/tests/ref/vsynth/vsynth1-vc2-420p
index e925c53bae..1aa0619619 100644
--- a/tests/ref/vsynth/vsynth1-vc2-420p
+++ b/tests/ref/vsynth/vsynth1-vc2-420p
@@ -1,4 +1,4 @@
-fb8fffcfc17558c87dd11a67ccb0f615 *tests/data/fate/vsynth1-vc2-420p.mov
+44d2025ac6d02444cca65c346507717a *tests/data/fate/vsynth1-vc2-420p.mov
 1155415 tests/data/fate/vsynth1-vc2-420p.mov
 387696707c79cf1a6c9aeff4024226b9 *tests/data/fate/vsynth1-vc2-420p.out.rawvideo
 stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:  7603200/   760320
diff --git a/tests/ref/vsynth/vsynth1-vc2-420p10 
b/tests/ref/vsynth/vsynth1-vc2-420p10
index 025a1cc779..b4283ddfe8 100644
--- a/tests/ref/vsynth/vsynth1-vc2-420p10
+++ b/tests/ref/vsynth/vsynth1-vc2-420p10
@@ -1,4 +1,4 @@
-1365742985b6315f6796c765aa17f39e *tests/data/fate/vsynth1-vc2-420p10.mov
+2911bf2acd9cafda663c01b2de0c5717 *tests/data/fate/vsynth1-vc2-420p10.mov
 1417047 tests/data/fate/vsynth1-vc2-420p10.mov
 387696707c79cf1a6c9aeff4024226b9 
*tests/data/fate/vsynth1-vc2-420p10.out.rawvideo
 stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:  7603200/   760320
diff --git a/tests/ref/vsynth/vsynth1-vc2-420p12 
b/tests/ref/vsynth/vsynth1-vc2-420p12
index 719f0d5f37..11bd33431f 100644
--- a/tests/ref/vsynth/vsynth1-vc2-420p12
+++ b/tests/ref/vsynth/vsynth1-vc2-420p12
@@ -1,4 +1,4 @@
-08a844d17940cd612da269fb08430628 *tests/data/fate/vsynth1-vc2-420p12.mov
+54dc2b5951cc3cdfef1aef3e7086b0f5 *tests/data/fate/vsynth1-vc2-420p12.mov
 1746007 tests/data/fate/vsynth1-vc2-420p12.mov
 387696707c79cf1a6c9aeff4024226b9 
*tests/data/fate/vsynth1-vc2-420p12.out.rawvideo
 stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:  7603200/   760320
diff --git a/tests/ref/vsynth/vsynth1-vc2-422p 
b/tests/ref/vsynth/vsynth1-vc2-422p
index 8fc61887d7..d6854d4772 100644
--- a/tests/ref/vsynth/vsynth1-vc2-422p
+++ b/tests/ref/vsynth/vsynth1-vc2-422p
@@ -1,4 +1,4 @@
-19f01a985e87e14664e0e5d14c02d046 *tests/data/fate/vsynth1-vc2-422p.mov
+7cf3de9f657f21050a61507b38c1dd03 *tests/data/fate/vsynth1-vc2-422p.mov
 1229783 tests/data/fate/vsynth1-vc2-422p.mov
 57a7f41235e7f9f094aa7ba5bdc82f02 *tests/data/fate/vsynth1-vc2-422p.out.rawvideo
 stddev:1.89 PSNR: 42.58 MAXDIFF:   23 bytes:  7603200/   760320
diff --git a/tests/ref/vsynth/vsynth1-vc2-422p10 
b/tests/ref/vsynth/vsynth1-vc2-422p10
index ac1072f3d1..d4a27b9bb1 100644
--- a/tests/ref/vsynth/vsynth1-vc2-422p10
+++ b/tests/ref/vsynth/vsynth1-vc2-422p10
@@ -1,4 +1,4 @@
-88e3488e4689cf06e75959c71e2f9d96 *tests/data/fate/vsynth1-vc2-422p10.mov
+21b48fa33cc4b0da1e723f17e729f5e9 *tests/data/fate/vsynth1-vc2-422p10.mov
 1684055 tests/data/fate/vsynth1-vc2-422p10.mov
 f35dd1c1df4726bb1d75d95e321b0698 
*tests/data/fate/vsynth1-vc2-422p10.out.rawvideo
 stddev:1.88 PSNR: 42.61 MAXDIFF:   23 bytes:  7603200/   760320
diff --git a/tests/ref/vsynth/vsynth1-vc2-422p12 
b/tests/ref/vsynth/vsynth1-vc2-422p12
index 0ad4798e6b..b1d2bb932f 100644
--- a/tests/ref/vsynth/vsynth1-vc2-422p12
+++ b/tests/ref/vsynth/vsynth1-vc2-422p12
@@ -1,4 +1,4 @@

[FFmpeg-devel] [PATCH 0/2] two small vc2enc fixes

2018-02-23 Thread James Darnley 
James Darnley (2):
  avcodec/vc2enc: do not write an End Sequence after the first field of
field-separated pictures
  avcodec/vc2enc: do not reset the last_parse_code variable every frame

 libavcodec/vc2enc.c | 9 +++--
 tests/ref/vsynth/vsynth1-vc2-420p   | 2 +-
 tests/ref/vsynth/vsynth1-vc2-420p10 | 2 +-
 tests/ref/vsynth/vsynth1-vc2-420p12 | 2 +-
 tests/ref/vsynth/vsynth1-vc2-422p   | 2 +-
 tests/ref/vsynth/vsynth1-vc2-422p10 | 2 +-
 tests/ref/vsynth/vsynth1-vc2-422p12 | 2 +-
 tests/ref/vsynth/vsynth1-vc2-444p   | 2 +-
 tests/ref/vsynth/vsynth1-vc2-444p10 | 2 +-
 tests/ref/vsynth/vsynth1-vc2-444p12 | 2 +-
 tests/ref/vsynth/vsynth2-vc2-420p   | 2 +-
 tests/ref/vsynth/vsynth2-vc2-420p10 | 2 +-
 tests/ref/vsynth/vsynth2-vc2-420p12 | 2 +-
 tests/ref/vsynth/vsynth2-vc2-422p   | 2 +-
 tests/ref/vsynth/vsynth2-vc2-422p10 | 2 +-
 tests/ref/vsynth/vsynth2-vc2-422p12 | 2 +-
 tests/ref/vsynth/vsynth2-vc2-444p   | 2 +-
 tests/ref/vsynth/vsynth2-vc2-444p10 | 2 +-
 tests/ref/vsynth/vsynth2-vc2-444p12 | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-420p   | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-420p10 | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-420p12 | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-422p   | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-422p10 | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-422p12 | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-444p   | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-444p10 | 2 +-
 tests/ref/vsynth/vsynth_lena-vc2-444p12 | 2 +-
 28 files changed, 34 insertions(+), 29 deletions(-)

-- 
2.16.1

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

[FFmpeg-devel] [PATCH 1/2] avcodec/vc2enc: do not write an End Sequence after the first field of field-separated pictures

2018-02-23 Thread James Darnley 
A lax or tolerant decoder may support an End Sequence between fields of the same
frame but the spec. says this is not allowed.

2012 spec. 10.3.2, 2017 spec. 10.4.3:
Where pictures are fields, a sequence shall comprise a whole number of
frames (i.e., an even number of fields) and shall begin and end with a
whole frame/field-pair.
---
 libavcodec/vc2enc.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index b7adcd3d36..9a5a4765c8 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -988,7 +988,13 @@ static int encode_frame(VC2EncContext *s, AVPacket *avpkt, 
const AVFrame *frame,
 encode_slices(s);
 
 /* End sequence */
-encode_parse_info(s, DIRAC_PCODE_END_SEQ);
+/* 2012 spec. 10.3.2, 2017 spec. 10.4.3:
+ * Where pictures are fields, a sequence shall comprise a whole number of
+ * frames (i.e., an even number of fields) and shall begin and end with a
+ * whole frame/field-pair. */
+if (field != 1) {
+encode_parse_info(s, DIRAC_PCODE_END_SEQ);
+}
 
 return 0;
 }
-- 
2.16.1

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

[FFmpeg-devel] CINEFORM GSOC PARTICIPATION

2018-02-23 Thread sunsingh 
Hello, my name is Gagandeep Singh and I am a sophomore at Indian Institute
of Technology, Kanpur (IITK). I am interested in applying for the CINEFORM
DECODER DEVELOPMENT FOR FFMPEG in GSOC.

I am writing this mail to introduce myself to the community. If anyone has
any suggestions regarding the development of cineform for ffmpeg, i would
love to read about them, discuss them and add them to the application.

Also, my exams are over now in the institute and i will be starting to
actively participate in gsoc. I have to accomplish the qualification tasks
for the cineform decoder bugs and so also, anyone having the suggestions
regarding them, again i would love to read them.

Since, this is my first time at an open source project, i apologize for
any statements in the mail that come of as rude.

Gagandeep Singh
IRC NICK:
gagandeep
gagandeep_
gagandeep__

have joined the #ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v3] lavf/mpegts: add supplementary audio descriptor

2018-02-23 Thread Aman Gupta 
On Tue, Feb 20, 2018 at 9:15 AM, Stefan Pöschel  wrote:

> The supplementary audio descriptor is defined in ETSI EN 300 468 and
> provides more details regarding accessibility audio tracks, especially
> the normative annex J contains a detailed description of its use.
>
> Its language code (if present) overrides the language code of an also
> present ISO 639 language descriptor.
>
> Note that this also changes the priority of multiple descriptors with
> language from "the last descriptor with language within the ES loop" to
> "specific descriptor over general ISO 639 descriptor".
> ---
>  libavformat/mpegts.c | 37 -
>  1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 0a3ad05..bca7a7a 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -1840,7 +1840,9 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc,
> AVStream *st, int stream_type
>  }
>  if (i && language[0]) {
>  language[i - 1] = 0;
> -av_dict_set(>metadata, "language", language, 0);
> +/* don't overwrite language, as it may already have been set
> by
> + * another, more specific descriptor (e.g. supplementary
> audio) */
> +av_dict_set(>metadata, "language", language,
> AV_DICT_DONT_OVERWRITE);
>  }
>  break;
>  case 0x05: /* registration descriptor */
> @@ -1895,6 +1897,39 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc,
> AVStream *st, int stream_type
>  st->internal->need_context_update = 1;
>  }
>  }
> +if (ext_desc_tag == 0x06) { /* supplementary audio descriptor */
> +int flags;
> +
> +if (desc_len < 1)
> +return AVERROR_INVALIDDATA;
> +flags = get8(pp, desc_end);
> +
> +switch ((flags >> 2) & 0x1F) { /* editorial_classification */
> +case 0x01:
> +st->disposition |= AV_DISPOSITION_VISUAL_IMPAIRED;
> +break;
> +case 0x02:
> +st->disposition |= AV_DISPOSITION_HEARING_IMPAIRED;
> +break;
> +case 0x03:
> +st->disposition |= AV_DISPOSITION_VISUAL_IMPAIRED;
> +break;
> +}
> +
> +if (flags & 0x01) { /* language_code_present */
> +if (desc_len < 4)
> +return AVERROR_INVALIDDATA;
> +language[0] = get8(pp, desc_end);
> +language[1] = get8(pp, desc_end);
> +language[2] = get8(pp, desc_end);
> +language[3] = 0;
> +
> +/* This language always has to override a possible
> + * ISO 639 language descriptor language */
> +if (language[0])
> +av_dict_set(>metadata, "language", language, 0);
> +}
> +}
>  break;
>  default:
>  break;
>

Patch applied. Thanks for your contribution.

Aman


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

Re: [FFmpeg-devel] [PATCH] ffmpeg: pass the correct AVCodecContext to av_parser_change()

2018-02-23 Thread James Almer 
On 2/23/2018 4:35 AM, Hendrik Leppkes wrote:
> On Fri, Feb 23, 2018 at 1:28 AM, James Almer  wrote:
>> On 2/22/2018 8:52 PM, Hendrik Leppkes wrote:
>>> On Fri, Feb 23, 2018 at 12:37 AM, James Almer  wrote:
 On 2/22/2018 8:34 PM, Hendrik Leppkes wrote:
> On Fri, Feb 23, 2018 at 12:20 AM, James Almer  wrote:
>> av_parser_change() is effectively a noop if the avctx passed it to
>> doesn't have the global header or local header flags set, and
>> initializing a custom AVCodecContext as a copy of an
>> AVCodecParameters results in the flags and flags2 fields being zero.
>> Use instead the existing custom AVCodecContext with the required
>> flags set in ffmpeg_opt.c new_output_stream() among other places.
>>
>> The fate test change is the result of the hevc sps/pps/vps being
>> removed from frames when copying into a format that explicitly
>> states it uses global header.
>>
>
> Deleting inband headers is not necessarily a good idea, and likely
> also why its being skipped for h264.

 Well, I'd argue it is when the user and/or the output format request it.

>>>
>>> Unless there is an explicit option to request that, thats not exactly the 
>>> case.
>>>
>>> - Hendrik
>>
>> The AVCodecContext global_header flag, which is what av_parser_change()
>> looks at. It's either set with an AVOption (With the CLI that's using
>> -flags +global_header) when encoding, or force enabled in
>>
>> https://git.videolan.org/?p=ffmpeg.git;a=blob;f=fftools/ffmpeg_opt.c;h=997d53838108c2c3deb7fa3d3f395712738dad86;hb=HEAD#l1495
>>
>> as mentioned in the commit message, depending on the constant
>> flag/capability set by the muxer.
> 
> Thats not what I mean, I know about that flag - and it controls AnnexB
> vs MP4, but it does not explicitly say "remove inband headers as
> well".
> If anything I think HEVC should follow the H264 example for consistency.
> 
> There are plenty cases where removing the in-band headers results in problems.

So, if removing in-band headers is not desired, what exactly was the
point/benefit of this entire chunk of code? I'm not sure the
local_header portion of av_parser_change (to dump out of band headers at
every keyframe) can be triggered currently. Neither -flags
+global_header or -flags2 +local_header seem to work for codec copy,
seeing the former is ignored and the latter gives an error.

Who wrote it, for that matter? It's been dead code for years.
Maybe it should be removed altogether. Nobody missed it all this time,
and skipping hevc as well would leave mpeg4 only.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] hlsenc: Fixing HLS_TEMP_FILE usage with, HLS_SECOND_LEVEL_SEGMENT_... flags

2018-02-23 Thread Liu Steven 

> 在 2018年2月22日，下午3:34，Liu Steven  写道：
> 
>> 
>> 在 2018年2月20日，上午5:00，Bodecs Bela  写道：
>> 
>> Dear All,
>> 
>> Currently using HLS_TEMP together with HLS_SECOND_LEVEL_SEGMENT_DURATION
>> and/or HLS_SECOND_LEVEL_SEGMENT_SIZE gives error at end of each segment
>> writing and the final segment file names do not contain the desired
>> data. This patch fixes this bug by delaying the initilization of
>> original segment filename until end of actual temp file renaming.
>> This will skip the interfering.
>> 
>> Please review this bug fix. Thank you in advance.
>> 
>> 
>> best regards,
>> 
>> Bela Bodecs
>> 
>> <0001-hlsenc-Fixing-HLS_TEMP_FILE-usage-with-HLS_SECOND_LE.patch>
> 
> LGTM
> 
Pushed
> 
> Thanks
> Steven



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

Re: [FFmpeg-devel] [PATCH 2/2] Implement dynamic loading of NewTek NDI library

2018-02-23 Thread Hendrik Leppkes 
On Fri, Feb 23, 2018 at 11:47 AM, Nicolas George  wrote:
>
>>  - dynamic loading alone has some pros (e.g. not needing the SDK
>>on every machine where you use your built ffmpeg)
>
> Sorry, you are wrong, this is not how dynamic loading works. You need
> the shared library (and possibly supporting data files), whether you
> load it through dlopen() or through NEEDED.
>
>

When you use dlopen, you can write code that gracefully fails when the
library is not present, instead of failing to load ffmpeg/avdevice
entirely. This is obviously what is meant here.

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

Re: [FFmpeg-devel] [PATCH 2/2] Implement dynamic loading of NewTek NDI library

2018-02-23 Thread Ricardo Constantino 
On 22 February 2018 at 22:53, Marton Balint  wrote:

>
>
> On Thu, 22 Feb 2018, Ricardo Constantino wrote:
>
> On 22 February 2018 at 22:22, Carl Eugen Hoyos  wrote:
>>
>> 2018-02-22 20:26 GMT+01:00 Marton Balint :
>>> >
>>> > On Wed, 21 Feb 2018, Nicolas George wrote:
>>> >
>>> >> Marton Balint (2018-02-20):
>>> >>>
>>> >>> The patch might has merits even if the library remains in the NONFREE
>>> >>> section, no?
>>> >>
>>> >> I see more code and easier circumvention of the GPL, but no merit.
>>> >> Please be more specific.
>>> >
>>> > I guess the biggest advantage of dynamic loading is that it can use the
>>> > environment variable for finding the library, this approach is
>>> documented /
>>> > encouraged in the NDI SDK.
>>>
>>> This doesn't sound convincing imo: Does the company distribute
>>> the dynamic library with different names?
>>>
>>>
>> Yes, different names for each OS.
>>
>
> I think what CE ment was static v.s. dynamic lib names, but what you write
> is true as well, the library has different names on different OS-es/archs,
> I am not even sure NDI stuff builds for windows, I always tested linux only.
>
> With dynamic loading we can rely on the library name defined in the NDI
> SDK headers which should be the proper one for each OS/arch.
>

Except non-MSVC compilers for Windows, which Newtek seems to think is the
exclusive way to compile for Windows.


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

Re: [FFmpeg-devel] [PATCH 2/2] Implement dynamic loading of NewTek NDI library

2018-02-23 Thread Nicolas George 
Marton Balint (2018-02-23):
> The environment variable contains the directory to the library, not the
> library name itself.

So it reinvents LD_LIBRARY_PATH. Probably badly.

> LD_LIBRARY_PATH, LD_PRELOAD is an environment variable as well, so I don't
> see why it is different from security standpoint.

It is not different in concept, but the details were designed by very
competent hackers. Yet, over the years, numerous security issues related
to these features have been found and fixed.

> And it's not unprecedented, there is FREI0R_PATH, or LADSPA_PATH for
> example. Okay, these are plugins, so not entirely the same thing, yet the
> approach is similar.

I had not yet thought of it. This is worrisome.

> I'd rather say that we should add 100+ lines of code because:
>  - it fixes some portability issues with the library names

So, in order to fix the portability issues of this library, any
application that uses it is supposed to implement these 100+ lines of
code.

I say: let them fix their crap.

>  - dynamic loading alone has some pros (e.g. not needing the SDK
>on every machine where you use your built ffmpeg)

Sorry, you are wrong, this is not how dynamic loading works. You need
the shared library (and possibly supporting data files), whether you
load it through dlopen() or through NEEDED.

>  - we can use the SDK suggested way to find the library using an
>environment variable

Let them fix their crap.

>  - the author who is the de facto maintainer prefers it this way

Let them fix their tastes.

> I also tried to help making the code "less ugly" in my review.

Les ugly is still ugly.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

2018-02-23 Thread wm4 
On Fri, 23 Feb 2018 01:21:52 +0100
Michael Niedermayer  wrote:

> On Thu, Feb 22, 2018 at 07:31:27PM +0100, wm4 wrote:
> > On Thu, 22 Feb 2018 16:28:56 +0100
> > Michael Niedermayer  wrote:
> >   
> > > On Wed, Feb 21, 2018 at 09:02:40PM +0100, wm4 wrote:  
> > > > On Wed, 21 Feb 2018 19:14:59 +0100
> > > > Michael Niedermayer  wrote:
> > > > 
> > > > > On Wed, Feb 21, 2018 at 09:27:02AM +0100, wm4 wrote:
> > > > > > On Tue, 20 Feb 2018 21:45:12 +0100
> > > > > > Michael Niedermayer  wrote:
> > > > > >   
> > > > > > > On Tue, Feb 20, 2018 at 06:28:20PM +0100, wm4 wrote:  
> > > > > > > > On Tue, 20 Feb 2018 17:30:32 +0100
> > > > > > > > Michael Niedermayer  wrote:
> > > > > > > > 
> > > > > > > > > On Tue, Feb 20, 2018 at 10:17:02AM -0300, James Almer wrote:  
> > > > > > > > >   
> > > > > > > > > > On 2/20/2018 9:21 AM, wm4 wrote:  
> > > > > > > > > > > On Tue, 20 Feb 2018 08:47:51 -0300
> > > > > > > > > > > James Almer  wrote:  
> > > > > [...]
> > > > > > > > And for the 100th time: the new API is completely orthogonal to
> > > > > > > > allowing user-registered components. Since nobody could 
> > > > > > > > actually use
> > > > > > > > the API before, it's no problem to drop the old APIs now, and 
> > > > > > > > to add
> > > > > > > > actually working API once the other, much much much bigger 
> > > > > > > > problems are
> > > > > > > > solved.
> > > > > > > > 
> > > > > > > > Even if you argue that keeping the linked list is absolutely 
> > > > > > > > necessary,
> > > > > > > > the new API could support a linked list too.
> > > > > > > > 
> > > > > > > > > is it the ff_* symbols you are thinking of ?
> > > > > > > > 
> > > > > > > > ff_ symbols are private.
> > > > > > > > 
> > > > > > > > > This is a problem for an existing API it is not a problem for 
> > > > > > > > > a new API as
> > > > > > > > > we can change the symbols if they are intended to be used for 
> > > > > > > > > individual
> > > > > > > > > component registration.
> > > > > > > > > The whole discussion is about designing a new API. So any 
> > > > > > > > > limitation of
> > > > > > > > > an existing API can be changed.
> > > > > > > > > 
> > > > > > > > > There also should be no need to call register_all in the 
> > > > > > > > > existing API,
> > > > > > > > > and there cannot be such a problem in a new design because it 
> > > > > > > > > would be
> > > > > > > > > a new design you wouldnt design it to "not work".
> > > > > > > > 
> > > > > > > > You're just being contradictory all across the board here. In 
> > > > > > > > other
> > > > > > > > places you're claiming this register mechanism is needed for
> > > > > > > > security or to make it possible to eliminate unused components 
> > > > > > > > when
> > > > > > > > static linking. But if all components are already registered 
> > > > > > > > without
> > > > > > > > doing anything, how is that supposed to work?
> > > > > > > 
> > > > > > > If an application wants to register all, it calls the 
> > > > > > > register_all()
> > > > > > > function
> > > > > > > If an application wants to register a subset it registers just 
> > > > > > > that
> > > > > > > subset and does not call register_all  
> > > > > > 
> > > > > > But you just said on your mail "There also should be no need to call
> > > > > > register_all in the existing API,". How is that supposed to mesh 
> > > > > > with 
> > > > > > "If an application wants to register a subset it registers just that
> > > > > > subset and does not call register_all".  
> > > > > 
> > > > > I see no contradiction between what you quote, if that is what you 
> > > > > meant:
> > > > > "There also should be no need to call register_all in the existing 
> > > > > API,"
> > > > > and
> > > > > "If an application wants to register a subset it registers just that 
> > > > > subset and does not call register_all"
> > > > 
> > > > If there's no contradiction, it implies that either the first register
> > > > call will implicitly unregister all "automatically" registered
> > > > components, or the code has to explicitly unregister components. but in
> > > > both cases this would still require linking all components even if you
> > > > use static linking.
> > > > 
> > > > So you have the following possibilities:
> > > > - register_all needs to be called
> > > >   - contradicts your claim it doesn't need to be called
> > >   
> > > > - register_all needs not to be called
> > > >   - all components are already registered implicitly
> > > 
> > > why would not calling register_all(), register all components implicitly 
> > > ?  
> > 
> > So what did you mean by "There also should be no need to call
> > register_all in the existing API,"?  
> 
> That as documented the user app should be able to

[FFmpeg-devel] [PATCH] ffmpeg_opt: fix max_error_rate help info display issue.

2018-02-23 Thread Jun Zhao 

From 5272bc77ec1834f767277f1cdf8ac13727a19319 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Fri, 23 Feb 2018 15:58:10 +0800
Subject: [PATCH] ffmpeg_opt: fix max_error_rate help info display issue.

ffmpeg -h display "max_error_rate" option help information have
been cut off, the root cause is used a wrong initial order.

Signed-off-by: Jun Zhao 
---
 fftools/ffmpeg_opt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 997d538381..1b591d9695 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -3457,7 +3457,7 @@ const OptionDef options[] = {
 { "debug_ts",   OPT_BOOL | OPT_EXPERT,   { 
_ts },
 "print timestamp debugging info" },
 { "max_error_rate",  HAS_ARG | OPT_FLOAT,{ 
_error_rate },
-"maximum error rate", "ratio of errors (0.0: no errors, 1.0: 100% 
errors) above which ffmpeg returns an error instead of success." },
+"ratio of errors (0.0: no errors, 1.0: 100% errors) above which ffmpeg 
returns an error instead of success.", "maximum error rate" },
 { "discard",OPT_STRING | HAS_ARG | OPT_SPEC |
 OPT_INPUT,   { .off = 
OFFSET(discard) },
 "discard", "" },
-- 
2.14.1

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