[FFmpeg-devel] [PATCH v6 1/2] avformat/hlsenc: Modularized playlist creation to allow reuse

[Karthick J]

---
 libavformat/Makefile  |   2 +-
 libavformat/hlsenc.c  | 115 +++---
 libavformat/hlsplaylist.c | 138 ++
 libavformat/hlsplaylist.h |  51 +
 4 files changed, 211 insertions(+), 95 deletions(-)
 create mode 100644 libavformat/hlsplaylist.c
 create mode 100644 libavformat/hlsplaylist.h

diff --git a/libavformat/Makefile b/libavformat/Makefile
index b1e7b19..fd8b9f9 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -215,7 +215,7 @@ OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
 OBJS-$(CONFIG_HEVC_DEMUXER)  += hevcdec.o rawdec.o
 OBJS-$(CONFIG_HEVC_MUXER)+= rawenc.o
 OBJS-$(CONFIG_HLS_DEMUXER)   += hls.o
-OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o
+OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o hlsplaylist.o
 OBJS-$(CONFIG_HNM_DEMUXER)   += hnm.o
 OBJS-$(CONFIG_ICO_DEMUXER)   += icodec.o
 OBJS-$(CONFIG_ICO_MUXER) += icoenc.o
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index d5c732f..f63b08d 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -46,6 +46,7 @@
 #include "avformat.h"
 #include "avio_internal.h"
 #include "http.h"
+#include "hlsplaylist.h"
 #include "internal.h"
 #include "os_support.h"
 
@@ -97,13 +98,6 @@ typedef enum {
 SEGMENT_TYPE_FMP4,
 } SegmentType;
 
-typedef enum {
-PLAYLIST_TYPE_NONE,
-PLAYLIST_TYPE_EVENT,
-PLAYLIST_TYPE_VOD,
-PLAYLIST_TYPE_NB,
-} PlaylistType;
-
 typedef struct VariantStream {
 unsigned number;
 int64_t sequence;
@@ -1055,19 +1049,6 @@ static void hls_free_segments(HLSSegment *p)
 }
 }
 
-static void write_m3u8_head_block(HLSContext *hls, AVIOContext *out, int 
version,
-  int target_duration, int64_t sequence)
-{
-avio_printf(out, "#EXTM3U\n");
-avio_printf(out, "#EXT-X-VERSION:%d\n", version);
-if (hls->allowcache == 0 || hls->allowcache == 1) {
-avio_printf(out, "#EXT-X-ALLOW-CACHE:%s\n", hls->allowcache == 0 ? 
"NO" : "YES");
-}
-avio_printf(out, "#EXT-X-TARGETDURATION:%d\n", target_duration);
-avio_printf(out, "#EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", sequence);
-av_log(hls, AV_LOG_VERBOSE, "EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", sequence);
-}
-
 static void hls_rename_temp_file(AVFormatContext *s, AVFormatContext *oc)
 {
 size_t len = strlen(oc->filename);
@@ -1133,8 +1114,7 @@ static int create_master_playlist(AVFormatContext *s,
 goto fail;
 }
 
-avio_printf(master_pb, "#EXTM3U\n");
-avio_printf(master_pb, "#EXT-X-VERSION:%d\n", hls->version);
+ff_hls_write_playlist_version(master_pb, hls->version);
 
 /* For variant streams with video add #EXT-X-STREAM-INF tag with 
attributes*/
 for (i = 0; i < hls->nb_varstreams; i++) {
@@ -1175,18 +1155,7 @@ static int create_master_playlist(AVFormatContext *s,
 bandwidth += aud_st->codecpar->bit_rate;
 bandwidth += bandwidth / 10;
 
-if (!bandwidth) {
-av_log(NULL, AV_LOG_WARNING,
-"Bandwidth info not available, set audio and video 
bitrates\n");
-av_freep(&m3u8_rel_name);
-continue;
-}
-
-avio_printf(master_pb, "#EXT-X-STREAM-INF:BANDWIDTH=%d", bandwidth);
-if (vid_st && vid_st->codecpar->width > 0 && vid_st->codecpar->height 
> 0)
-avio_printf(master_pb, ",RESOLUTION=%dx%d", 
vid_st->codecpar->width,
-vid_st->codecpar->height);
-avio_printf(master_pb, "\n%s\n\n", m3u8_rel_name);
+ff_hls_write_stream_info(vid_st, master_pb, bandwidth, m3u8_rel_name);
 
 av_freep(&m3u8_rel_name);
 }
@@ -1215,6 +1184,7 @@ static int hls_window(AVFormatContext *s, int last, 
VariantStream *vs)
 char *iv_string = NULL;
 AVDictionary *options = NULL;
 double prog_date_time = vs->initial_prog_date_time;
+double *prog_date_time_p = (hls->flags & HLS_PROGRAM_DATE_TIME) ? 
&prog_date_time : NULL;
 int byterange_mode = (hls->flags & HLS_SINGLE_FILE) || (hls->max_seg_size 
> 0);
 
 hls->version = 3;
@@ -1245,12 +1215,8 @@ static int hls_window(AVFormatContext *s, int last, 
VariantStream *vs)
 }
 
 vs->discontinuity_set = 0;
-write_m3u8_head_block(hls, out, hls->version, target_duration, sequence);
-if (hls->pl_type == PLAYLIST_TYPE_EVENT) {
-avio_printf(out, "#EXT-X-PLAYLIST-TYPE:EVENT\n");
-} else if (hls->pl_type == PLAYLIST_TYPE_VOD) {
-avio_printf(out, "#EXT-X-PLAYLIST-TYPE:VOD\n");
-}
+ff_hls_write_playlist_header(out, hls->version, hls->allowcache,
+ target_duration, sequence, hls->pl_type);
 
 if((hls->flags & HLS_DISCONT_START) && sequence==hls->start_sequence && 
vs->discontinuity_set==0 ){
 avio_printf(out, "#EXT-X-DISCONTINUITY\n");
@@ -1270,74 +1236,35 @@ static int hls_window(AVFormatContext *s, in

Re: [FFmpeg-devel] [PATCH v5 1/2] avformat/hlsenc: Modularized playlist creation to allow reuse

[Jeyapal, Karthick]

On 11/25/17, 9:16 AM, "Karthick J"  wrote:

>---
> libavformat/Makefile  |   2 +-
> libavformat/hlsenc.c  | 115 +++---
> libavformat/hlsplaylist.c | 138 ++
> libavformat/hlsplaylist.h |  51 +
> 4 files changed, 211 insertions(+), 95 deletions(-)
> create mode 100644 libavformat/hlsplaylist.c
> create mode 100644 libavformat/hlsplaylist.h
[…]
This patch(v5) does not apply on latest master (merge conflicts).
Have rebased and sent a new patch v6.
-- 
1.9.1



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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mlpenc: fix undefined shift

[Paul B Mahol]

On 11/29/17, Rostislav Pehlivanov  wrote:
> On 28 November 2017 at 19:55, Paul B Mahol  wrote:
>
>> Decreases artifacts.
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/mlpenc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
>> index c588f5b904..eceb0ddbb2 100644
>> --- a/libavcodec/mlpenc.c
>> +++ b/libavcodec/mlpenc.c
>> @@ -466,7 +466,7 @@ static void default_decoding_params(MLPEncodeContext
>> *ctx,
>>   */
>>  static int inline number_sbits(int number)
>>  {
>> -if (number < 0)
>> +if (number <= 0)
>>  number++;
>>
>>  return av_log2(FFABS(number)) + 1 + !!number;
>> --
>> 2.11.0
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> Doesn't really seem to do anything to lossless check failures (not in 32
> bit mode either where most of the errors are, which is why its disabled).
> Which undefined shift does it fix?

result of this function can be 1 and it goes to be shifted as -1 in later calls.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/3] avformat/mxfenc: use track count to generate component instance uuid

[Tomas Härdin]

On 2017-11-29 05:11, Mark Reid wrote:

@@ -980,7 +980,7 @@ static void mxf_write_structural_component(AVFormatContext 
*s, AVStream *st, MXF
  
  // write uid

  mxf_write_local_tag(pb, 16, 0x3C0A);
-mxf_write_uuid(pb, package->type == MaterialPackage ? SourceClip: SourceClip 
+ TypeBottom, st->index);
+mxf_write_uuid(pb, SourceClip, mxf->track_uuid_offset);
  
  PRINT_KEY(s, "structural component uid", pb->buf_ptr - 16);

  mxf_write_common_fields(s, st);
@@ -1357,7 +1357,7 @@ static void mxf_write_package(AVFormatContext *s, 
MXFPackage *package)
  
  // write package umid

  mxf_write_local_tag(pb, 32, 0x4401);
-mxf_write_umid(s, package->type == SourcePackage);
+mxf_write_umid(s, package->instance);
  PRINT_KEY(s, "package umid second part", pb->buf_ptr - 16);
  
  // package name

@@ -1375,10 +1375,9 @@ static void mxf_write_package(AVFormatContext *s, 
MXFPackage *package)
  // write track refs
  mxf_write_local_tag(pb, track_count*16 + 8, 0x4403);
  mxf_write_refs_count(pb, track_count);
-mxf_write_uuid(pb, package->type == MaterialPackage ? Track :
-   Track + TypeBottom, -1); // timecode track
+mxf_write_uuid(pb, Track, mxf->track_uuid_offset); // timecode track
  for (i = 0; i < s->nb_streams; i++)
-mxf_write_uuid(pb, package->type == MaterialPackage ? Track : Track + 
TypeBottom, i);
+mxf_write_uuid(pb, Track,  mxf->track_uuid_offset + i + 1);


Do these refer to tracks that are about to be written? Seems so as best 
I can tell, so I guess it works. I'd be happier if the referencing was 
done more explicitly rather than implicitly


  
  // write user comment refs

  if (mxf->store_user_comments) {
@@ -1402,12 +1401,14 @@ static void mxf_write_package(AVFormatContext *s, 
MXFPackage *package)
  mxf_write_track(s, mxf->timecode_track, package);
  mxf_write_sequence(s, mxf->timecode_track, package);
  mxf_write_timecode_component(s, mxf->timecode_track, package);
+mxf->track_uuid_offset++;
  
  for (i = 0; i < s->nb_streams; i++) {

  AVStream *st = s->streams[i];
  mxf_write_track(s, st, package);
  mxf_write_sequence(s, st, package);
  mxf_write_structural_component(s, st, package);
+mxf->track_uuid_offset++;
  


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

Re: [FFmpeg-devel] [PATCH v2 2/3] avformat/mxfenc: write reel_name if metadata key is present

[Tomas Härdin]

On 2017-11-29 05:11, Mark Reid wrote:

---
  libavformat/mxf.h|  1 +
  libavformat/mxfenc.c | 42 +++---
  2 files changed, 36 insertions(+), 7 deletions(-)

diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index 2d5b44943b..ffcc429a8b 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@ -47,6 +47,7 @@ enum MXFMetadataSetType {
  EssenceContainerData,
  EssenceGroup,
  TaggedValue,
+TapeDescriptor,
  };
  
  enum MXFFrameLayout {

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index baaeb8c617..02192aa22b 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -105,6 +105,7 @@ typedef struct MXFPackage {
  char *name;
  enum MXFMetadataSetType type;
  int instance;
+struct MXFPackage *ref;
  } MXFPackage;
  
  enum ULIndex {

@@ -991,20 +992,33 @@ static void 
mxf_write_structural_component(AVFormatContext *s, AVStream *st, MXF
  
  // write source package uid, end of the reference

  mxf_write_local_tag(pb, 32, 0x1101);
-if (package->type == SourcePackage) {
+if (!package->ref) {
  for (i = 0; i < 4; i++)
  avio_wb64(pb, 0);
  } else
-mxf_write_umid(s, 1);
+mxf_write_umid(s, package->ref->instance);
  
  // write source track id

  mxf_write_local_tag(pb, 4, 0x1102);
-if (package->type == SourcePackage)
+if (package->type == SourcePackage && !package->ref)
  avio_wb32(pb, 0);
  else
  avio_wb32(pb, st->index+2);
  }
  
+static void mxf_write_tape_descriptor(AVFormatContext *s)

+{
+AVIOContext *pb = s->pb;
+
+mxf_write_metadata_key(pb, 0x012e00);
+PRINT_KEY(s, "tape descriptor key", pb->buf_ptr - 16);
+klv_encode_ber_length(pb, 20);
+mxf_write_local_tag(pb, 16, 0x3C0A);
+mxf_write_uuid(pb, TapeDescriptor, 0);
+PRINT_KEY(s, "tape_desc uid", pb->buf_ptr - 16);
+}
+
+
  static void mxf_write_multi_descriptor(AVFormatContext *s)
  {
  MXFContext *mxf = s->priv_data;
@@ -1388,13 +1402,17 @@ static void mxf_write_package(AVFormatContext *s, 
MXFPackage *package)
  }
  
  // write multiple descriptor reference

-if (package->type == SourcePackage) {
+if (package->type == SourcePackage && package->instance == 1) {
  mxf_write_local_tag(pb, 16, 0x4701);
  if (s->nb_streams > 1) {
  mxf_write_uuid(pb, MultipleDescriptor, 0);
  mxf_write_multi_descriptor(s);
  } else
  mxf_write_uuid(pb, SubDescriptor, 0);
+} else if (package->type == SourcePackage && package->instance == 2) {
+mxf_write_local_tag(pb, 16, 0x4701);
+mxf_write_uuid(pb, TapeDescriptor, 0);
+mxf_write_tape_descriptor(s);
  }
  
  // write timecode track

@@ -1410,7 +1428,7 @@ static void mxf_write_package(AVFormatContext *s, 
MXFPackage *package)
  mxf_write_structural_component(s, st, package);
  mxf->track_uuid_offset++;
  
-if (package->type == SourcePackage) {

+if (package->type == SourcePackage && package->instance == 1) {
  MXFStreamContext *sc = st->priv_data;
  mxf_essence_container_uls[sc->index].write_desc(s, st);
  }
@@ -1445,12 +1463,13 @@ static int 
mxf_write_header_metadata_sets(AVFormatContext *s)
  AVDictionaryEntry *entry = NULL;
  AVStream *st = NULL;
  int i;
-
-MXFPackage packages[2] = {};
+MXFPackage packages[3] = {};
  int package_count = 2;
  packages[0].type = MaterialPackage;
  packages[1].type = SourcePackage;
  packages[1].instance = 1;
+packages[0].ref = &packages[1];
+
  
  if (entry = av_dict_get(s->metadata, "material_package_name", NULL, 0))

 packages[0].name = entry->value;
@@ -1468,6 +1487,15 @@ static int 
mxf_write_header_metadata_sets(AVFormatContext *s)
  }
  }
  
+entry = av_dict_get(s->metadata, "reel_name", NULL, 0);

+if (entry) {
+packages[2].name = entry->value;
+packages[2].type = SourcePackage;
+packages[2].instance = 2;
+packages[1].ref = &packages[2];
+package_count = 3;
+}
+
  mxf_write_preface(s);
  mxf_write_identification(s);
  mxf_write_content_storage(s, packages, package_count);


Looks OK

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

Re: [FFmpeg-devel] [PATCH] avfilter: slice processing for geq

[Marc-Antoine ARNAUD]

Le mer. 22 nov. 2017 à 17:54, Michael Niedermayer 
a écrit :

> On Wed, Nov 22, 2017 at 10:24:30AM +, Marc-Antoine ARNAUD wrote:
> > New patch version which fixe the last remark.
> >
> >
> > Le ven. 10 nov. 2017 à 00:47, Michael Niedermayer  >
> > a écrit :
> >
> > > On Thu, Nov 09, 2017 at 10:22:23AM +, Marc-Antoine ARNAUD wrote:
> > > > Please find the merged patch in attachement.
> > > >
> > > > Thanks
> > > >
> > > > Le mer. 8 nov. 2017 à 17:12, Paul B Mahol  a
> écrit :
> > > >
> > > > > On 11/8/17, Marc-Antoine ARNAUD 
> wrote:
> > > > > > This patch will fix the stride issue.
> > > > > > Is it valid for you ?
> > > > > >
> > > > > > Does it required to merge these 2 patches ? (and remove base64
> > > encoding
> > > > > on
> > > > > > the first one)
> > > > >
> > > > > Please merge those two patches, base64 encoding should not be
> needed
> > > > > (it helps to faster review patches if they are not encoded).
> > > > > ___
> > > > > ffmpeg-devel mailing list
> > > > > ffmpeg-devel@ffmpeg.org
> > > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > > >
> > >
> > > >  vf_geq.c |  124
> > > +--
> > > >  1 file changed, 90 insertions(+), 34 deletions(-)
> > > > b41a90fffb5ddef553661007a38659c602f7ce56
> > > 0001-avfilter-slice-processing-for-geq.patch
> > > > From ac2a6322fa96835e02a24c31f014fb360e26561f Mon Sep 17 00:00:00
> 2001
> > > > From: Marc-Antoine Arnaud 
> > > > Date: Thu, 9 Nov 2017 11:19:43 +0100
> > > > Subject: [PATCH] avfilter: slice processing for geq
> > > > Content-Type: text/x-patch; charset="utf-8"
> > >
> > > crashes:
> > > ./ffmpeg_g -f lavfi -i
> > >
> 'nullsrc=s=200x200,format=yuv444p16,geq=X*Y/10:sin(X/10)*255:cos(Y/10)*255'
> > > -vframes 5 -y blah.avi
> > >
> > > ==24616== Thread 7:
> > > ==24616== Invalid write of size 2
> > > ==24616==at 0x4F3AAF: slice_geq_filter (vf_geq.c:289)
> > > ==24616==by 0x48E4C9: worker_func (pthread.c:50)
> > > ==24616==by 0x11DB932: run_jobs (slicethread.c:61)
> > > ==24616==by 0x11DBA04: thread_worker (slicethread.c:85)
> > > ==24616==by 0xC45D183: start_thread (pthread_create.c:312)
> > > ==24616==by 0xC770FFC: clone (clone.S:111)
> > > ==24616==  Address 0x1177143e is 93,214 bytes inside a block of size
> > > 93,215 alloc'd
> > > ==24616==at 0x4C2A6C5: memalign (vg_replace_malloc.c:727)
> > > ==24616==by 0x4C2A760: posix_memalign (vg_replace_malloc.c:876)
> > > ==24616==by 0x11B0C43: av_malloc (mem.c:87)
> > > ==24616==by 0x11987CC: av_buffer_alloc (buffer.c:72)
> > > ==24616==by 0x1198831: av_buffer_allocz (buffer.c:85)
> > > ==24616==by 0x1198F29: pool_alloc_buffer (buffer.c:312)
> > > ==24616==by 0x1199057: av_buffer_pool_get (buffer.c:349)
> > > ==24616==by 0x489D6D: ff_frame_pool_get (framepool.c:222)
> > > ==24616==by 0x58F6EB: ff_default_get_video_buffer (video.c:89)
> > > ==24616==by 0x58F768: ff_get_video_buffer (video.c:102)
> > > ==24616==by 0x4F3BF3: geq_filter_frame (vf_geq.c:312)
> > > ==24616==by 0x472FD0: ff_filter_frame_framed (avfilter.c:1104)
> > > ==24616==by 0x473800: ff_filter_frame_to_filter (avfilter.c:1252)
> > > ==24616==by 0x4739F8: ff_filter_activate_default (avfilter.c:1301)
> > > ==24616==by 0x473C12: ff_filter_activate (avfilter.c:1462)
> > > ==24616==by 0x478A4F: ff_filter_graph_run_once
> (avfiltergraph.c:1456)
> > > ==24616==by 0x478C72: get_frame_internal (buffersink.c:110)
> > > ==24616==by 0x478CCF: av_buffersink_get_frame_flags
> (buffersink.c:121)
> > > ==24616==by 0x441808: lavfi_read_packet (lavfi.c:410)
> > > ==24616==by 0x7AC315: ff_read_packet (utils.c:822)
> > > ==24616==
> > > --24616-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11
> (SIGSEGV)
> > > - exiting
> > > --24616-- si_code=80;  Faulting address: 0x0;  sp: 0x40a075db0
> > >
> > > [...]
> > >
> > > --
> > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> > >
> > > While the State exists there can be no freedom; when there is freedom
> there
> > > will be no State. -- Vladimir Lenin
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
>
> >  vf_geq.c |  130
> +++
> >  1 file changed, 90 insertions(+), 40 deletions(-)
> > abe75c0a0cf89605006905c0c58c0600d26fadb6
> 0001-avfilter-slice-processing-for-geq.patch
> > From 7ac2a8c41aaf69ec6cacf7460fa170fd4ca52d8f Mon Sep 17 00:00:00 2001
> > From: Marc-Antoine Arnaud 
> > Date: Wed, 22 Nov 2017 11:21:35 +0100
> > Subject: [PATCH 1/1] avfilter: slice processing for geq
> > Content-Type: text/x-patch; charset="utf-8"
> >
> > ---
> >  libavfilter/vf_geq.c | 130
> +++
> >  1 file changed, 90 insertions(+), 40 deletions(-)
>

Re: [FFmpeg-devel] [PATCH v6 1/2] avformat/hlsenc: Modularized playlist creation to allow reuse

[刘歧]

Where can i find the v6 2/2 ?
> 在 2017年11月29日，16:52，Karthick J  写道：
> 
> ---
> libavformat/Makefile  |   2 +-
> libavformat/hlsenc.c  | 115 +++---
> libavformat/hlsplaylist.c | 138 ++
> libavformat/hlsplaylist.h |  51 +
> 4 files changed, 211 insertions(+), 95 deletions(-)
> create mode 100644 libavformat/hlsplaylist.c
> create mode 100644 libavformat/hlsplaylist.h
> 
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index b1e7b19..fd8b9f9 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -215,7 +215,7 @@ OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
> OBJS-$(CONFIG_HEVC_DEMUXER)  += hevcdec.o rawdec.o
> OBJS-$(CONFIG_HEVC_MUXER)+= rawenc.o
> OBJS-$(CONFIG_HLS_DEMUXER)   += hls.o
> -OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o
> +OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o hlsplaylist.o
> OBJS-$(CONFIG_HNM_DEMUXER)   += hnm.o
> OBJS-$(CONFIG_ICO_DEMUXER)   += icodec.o
> OBJS-$(CONFIG_ICO_MUXER) += icoenc.o
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index d5c732f..f63b08d 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -46,6 +46,7 @@
> #include "avformat.h"
> #include "avio_internal.h"
> #include "http.h"
> +#include "hlsplaylist.h"
> #include "internal.h"
> #include "os_support.h"
> 
> @@ -97,13 +98,6 @@ typedef enum {
> SEGMENT_TYPE_FMP4,
> } SegmentType;
> 
> -typedef enum {
> -PLAYLIST_TYPE_NONE,
> -PLAYLIST_TYPE_EVENT,
> -PLAYLIST_TYPE_VOD,
> -PLAYLIST_TYPE_NB,
> -} PlaylistType;
> -
> typedef struct VariantStream {
> unsigned number;
> int64_t sequence;
> @@ -1055,19 +1049,6 @@ static void hls_free_segments(HLSSegment *p)
> }
> }
> 
> -static void write_m3u8_head_block(HLSContext *hls, AVIOContext *out, int 
> version,
> -  int target_duration, int64_t sequence)
> -{
> -avio_printf(out, "#EXTM3U\n");
> -avio_printf(out, "#EXT-X-VERSION:%d\n", version);
> -if (hls->allowcache == 0 || hls->allowcache == 1) {
> -avio_printf(out, "#EXT-X-ALLOW-CACHE:%s\n", hls->allowcache == 0 ? 
> "NO" : "YES");
> -}
> -avio_printf(out, "#EXT-X-TARGETDURATION:%d\n", target_duration);
> -avio_printf(out, "#EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", sequence);
> -av_log(hls, AV_LOG_VERBOSE, "EXT-X-MEDIA-SEQUENCE:%"PRId64"\n", 
> sequence);
> -}
> -
> static void hls_rename_temp_file(AVFormatContext *s, AVFormatContext *oc)
> {
> size_t len = strlen(oc->filename);
> @@ -1133,8 +1114,7 @@ static int create_master_playlist(AVFormatContext *s,
> goto fail;
> }
> 
> -avio_printf(master_pb, "#EXTM3U\n");
> -avio_printf(master_pb, "#EXT-X-VERSION:%d\n", hls->version);
> +ff_hls_write_playlist_version(master_pb, hls->version);
> 
> /* For variant streams with video add #EXT-X-STREAM-INF tag with 
> attributes*/
> for (i = 0; i < hls->nb_varstreams; i++) {
> @@ -1175,18 +1155,7 @@ static int create_master_playlist(AVFormatContext *s,
> bandwidth += aud_st->codecpar->bit_rate;
> bandwidth += bandwidth / 10;
> 
> -if (!bandwidth) {
> -av_log(NULL, AV_LOG_WARNING,
> -"Bandwidth info not available, set audio and video 
> bitrates\n");
> -av_freep(&m3u8_rel_name);
> -continue;
> -}
> -
> -avio_printf(master_pb, "#EXT-X-STREAM-INF:BANDWIDTH=%d", bandwidth);
> -if (vid_st && vid_st->codecpar->width > 0 && 
> vid_st->codecpar->height > 0)
> -avio_printf(master_pb, ",RESOLUTION=%dx%d", 
> vid_st->codecpar->width,
> -vid_st->codecpar->height);
> -avio_printf(master_pb, "\n%s\n\n", m3u8_rel_name);
> +ff_hls_write_stream_info(vid_st, master_pb, bandwidth, 
> m3u8_rel_name);
> 
> av_freep(&m3u8_rel_name);
> }
> @@ -1215,6 +1184,7 @@ static int hls_window(AVFormatContext *s, int last, 
> VariantStream *vs)
> char *iv_string = NULL;
> AVDictionary *options = NULL;
> double prog_date_time = vs->initial_prog_date_time;
> +double *prog_date_time_p = (hls->flags & HLS_PROGRAM_DATE_TIME) ? 
> &prog_date_time : NULL;
> int byterange_mode = (hls->flags & HLS_SINGLE_FILE) || (hls->max_seg_size 
> > 0);
> 
> hls->version = 3;
> @@ -1245,12 +1215,8 @@ static int hls_window(AVFormatContext *s, int last, 
> VariantStream *vs)
> }
> 
> vs->discontinuity_set = 0;
> -write_m3u8_head_block(hls, out, hls->version, target_duration, sequence);
> -if (hls->pl_type == PLAYLIST_TYPE_EVENT) {
> -avio_printf(out, "#EXT-X-PLAYLIST-TYPE:EVENT\n");
> -} else if (hls->pl_type == PLAYLIST_TYPE_VOD) {
> -avio_printf(out, "#EXT-X-PLAYLIST-TYPE:VOD\n");
> -}
> +ff_hls_write_playlist_header(out, hls->version, hls->allowcache,
> +   

Re: [FFmpeg-devel] [PATCH] examples/hw_decode: Use hw-config information to find pixfmt

[Moritz Barsnick]

On Wed, Nov 29, 2017 at 00:34:03 +, Mark Thompson wrote:
> +if (type == AV_HWDEVICE_TYPE_NONE) {
> +fprintf(stderr, "Device type %s is not supported.\n", argv[1]);
> +fprintf(stderr, "Available device types:");
> +type = AV_HWDEVICE_TYPE_NONE;
> +while((type = av_hwdevice_iterate_types(type)) != 
> AV_HWDEVICE_TYPE_NONE)
> +fprintf(stderr, " %s", av_hwdevice_get_type_name(type));

I see what you're trying to do with "type = AV_HWDEVICE_TYPE_NONE"
(initialize the iterator), but the assignment is redundant.

I guess if the compiler optimizes it away anyway, it may be good for
readability, especially since it's an example. *shrug*

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

Re: [FFmpeg-devel] [PATCH] examples/hw_decode: Use hw-config information to find pixfmt

[Timo Rothenpieler]

Am 29.11.2017 um 13:22 schrieb Moritz Barsnick:

On Wed, Nov 29, 2017 at 00:34:03 +, Mark Thompson wrote:

+if (type == AV_HWDEVICE_TYPE_NONE) {
+fprintf(stderr, "Device type %s is not supported.\n", argv[1]);
+fprintf(stderr, "Available device types:");
+type = AV_HWDEVICE_TYPE_NONE;
+while((type = av_hwdevice_iterate_types(type)) != 
AV_HWDEVICE_TYPE_NONE)
+fprintf(stderr, " %s", av_hwdevice_get_type_name(type));


I see what you're trying to do with "type = AV_HWDEVICE_TYPE_NONE"
(initialize the iterator), but the assignment is redundant.

I guess if the compiler optimizes it away anyway, it may be good for
readability, especially since it's an example. *shrug*


I fail to see how the assignment is redundant?
Without the assignment, that would be an infinite loop.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v6 1/2] avformat/hlsenc: Modularized playlist creation to allow reuse

[Jeyapal, Karthick]

On 11/29/17, 5:16 PM, "刘歧"  wrote:
>
>Where can i find the v6 2/2 ?
Patch 2/2 didn’t change since v4. 
So didn’t repost it. You have to use v4 2/2.

I am sorry. I was not sure what is the normal practice here. I didn’t repost 
it, so that the people don’t waste time in re-reviewing it.
Is it customary to repost the all patches(even if unchanged) in a patchset, 
when posting new versions of a particular patch?
Please advise. I will follow accordingly from next time onwards. 

Thanks and regards,
Karthick

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

[FFmpeg-devel] [PATCH v6 2/2] avformat/dashenc: Option to generate hls playlist as well

[Karthick J]

This is to take full advantage of Common Media Application Format.
Now server can generate one content and serve both HLS and DASH players.
---
 doc/muxers.texi   |   3 ++
 libavformat/Makefile  |   2 +-
 libavformat/dashenc.c | 103 --
 3 files changed, 103 insertions(+), 5 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 8ec48c2..3d0c7bf 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -249,6 +249,9 @@ DASH-templated name to used for the media segments. Default 
is "chunk-stream$Rep
 URL of the page that will return the UTC timestamp in ISO format. Example: 
"https://time.akamai.com/?iso";
 @item -http_user_agent @var{user_agent}
 Override User-Agent field in HTTP header. 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 -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/Makefile b/libavformat/Makefile
index fd8b9f9..4bffdf2 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -135,7 +135,7 @@ OBJS-$(CONFIG_CONCAT_DEMUXER)+= concatdec.o
 OBJS-$(CONFIG_CRC_MUXER) += crcenc.o
 OBJS-$(CONFIG_DATA_DEMUXER)  += rawdec.o
 OBJS-$(CONFIG_DATA_MUXER)+= rawenc.o
-OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o
+OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o hlsplaylist.o
 OBJS-$(CONFIG_DASH_DEMUXER)  += dash.o dashdec.o
 OBJS-$(CONFIG_DAUD_DEMUXER)  += dauddec.o
 OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 0fee3cd..ee9dc85 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -36,6 +36,7 @@
 #include "avc.h"
 #include "avformat.h"
 #include "avio_internal.h"
+#include "hlsplaylist.h"
 #include "internal.h"
 #include "isom.h"
 #include "os_support.h"
@@ -101,6 +102,8 @@ typedef struct DASHContext {
 const char *media_seg_name;
 const char *utc_timing_url;
 const char *user_agent;
+int hls_playlist;
+int master_playlist_created;
 } DASHContext;
 
 static struct codec_string {
@@ -217,6 +220,14 @@ static void set_http_options(AVDictionary **options, 
DASHContext *c)
 av_dict_set(options, "user_agent", c->user_agent, 0);
 }
 
+static void get_hls_playlist_name(char *playlist_name, int string_size,
+  const char *base_url, int id) {
+if (base_url)
+snprintf(playlist_name, string_size, "%smedia_%d.m3u8", base_url, id);
+else
+snprintf(playlist_name, string_size, "media_%d.m3u8", id);
+}
+
 static int flush_init_segment(AVFormatContext *s, OutputStream *os)
 {
 DASHContext *c = s->priv_data;
@@ -262,7 +273,8 @@ static void dash_free(AVFormatContext *s)
 av_freep(&c->streams);
 }
 
-static void output_segment_list(OutputStream *os, AVIOContext *out, 
DASHContext *c)
+static void output_segment_list(OutputStream *os, AVIOContext *out, 
DASHContext *c,
+int representation_id, int final)
 {
 int i, start_index = 0, start_number = 1;
 if (c->window_size) {
@@ -322,6 +334,55 @@ static void output_segment_list(OutputStream *os, 
AVIOContext *out, DASHContext
 }
 avio_printf(out, "\t\t\t\t\n");
 }
+if (c->hls_playlist && start_index < os->nb_segments)
+{
+int timescale = os->ctx->streams[0]->time_base.den;
+char temp_filename_hls[1024];
+char filename_hls[1024];
+AVIOContext *out_hls = NULL;
+AVDictionary *http_opts = NULL;
+int target_duration = 0;
+const char *proto = avio_find_protocol_name(c->dirname);
+int use_rename = proto && !strcmp(proto, "file");
+
+get_hls_playlist_name(filename_hls, sizeof(filename_hls),
+  c->dirname, representation_id);
+
+snprintf(temp_filename_hls, sizeof(temp_filename_hls), use_rename ? 
"%s.tmp" : "%s", filename_hls);
+
+set_http_options(&http_opts, c);
+avio_open2(&out_hls, temp_filename_hls, AVIO_FLAG_WRITE, NULL, 
&http_opts);
+av_dict_free(&http_opts);
+for (i = start_index; i < os->nb_segments; i++) {
+Segment *seg = os->segments[i];
+if (target_duration < seg->duration)
+target_duration = seg->duration;
+}
+target_duration = lrint((double) target_duration / timescale);
+
+ff_hls_write_playlist_header(out_hls, 6, -1, target_duration,
+ start_number, PLAYLIST_TYPE_NONE);
+
+ff_hls_wri

[FFmpeg-devel] [PATCH] avfilter: add fillborders filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  38 ++
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_fillborders.c | 277 +++
 4 files changed, 317 insertions(+)
 create mode 100644 libavfilter/vf_fillborders.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 4a4efc70c8..758591d087 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8674,6 +8674,44 @@ ffmpeg -i file.ts -vf 
find_rect=newref.pgm,cover_rect=cover.jpg:mode=cover new.m
 @end example
 @end itemize
 
+@section fillborders
+
+Fill borders of the input video.
+
+It accepts the following options:
+
+@table @option
+@item left
+Number of pixels to fill from left border.
+
+@item right
+Number of pixels to fill from right border.
+
+@item top
+Number of pixels to fill from top border.
+
+@item bottom
+Number of pixels to fill from bottom border.
+
+@item mode
+Set fill mode.
+
+It accepts the following values:
+@table @samp
+@item smear
+fill pixels using outermost pixels
+
+@item mirror
+fill pixels using mirroring
+
+@item blank
+fill blank pixels
+@end table
+
+@item color
+Set color for blank pixels. Defauls is @var{black}.
+@end table
+
 @section floodfill
 
 Flood area with values of same pixel components with another values.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 0b77d7a01f..f97394ebd5 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -193,6 +193,7 @@ OBJS-$(CONFIG_FIELDHINT_FILTER)  += 
vf_fieldhint.o
 OBJS-$(CONFIG_FIELDMATCH_FILTER) += vf_fieldmatch.o
 OBJS-$(CONFIG_FIELDORDER_FILTER) += vf_fieldorder.o
 OBJS-$(CONFIG_FIND_RECT_FILTER)  += vf_find_rect.o lavfutils.o
+OBJS-$(CONFIG_FILLBORDERS_FILTER)+= vf_fillborders.o
 OBJS-$(CONFIG_FLOODFILL_FILTER)  += vf_floodfill.o
 OBJS-$(CONFIG_FORMAT_FILTER) += vf_format.o
 OBJS-$(CONFIG_FPS_FILTER)+= vf_fps.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 4c834f7381..2479d511b5 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -203,6 +203,7 @@ static void register_all(void)
 REGISTER_FILTER(FIELDMATCH, fieldmatch, vf);
 REGISTER_FILTER(FIELDORDER, fieldorder, vf);
 REGISTER_FILTER(FIND_RECT,  find_rect,  vf);
+REGISTER_FILTER(FILLBORDERS,fillborders,vf);
 REGISTER_FILTER(FLOODFILL,  floodfill,  vf);
 REGISTER_FILTER(FORMAT, format, vf);
 REGISTER_FILTER(FPS,fps,vf);
diff --git a/libavfilter/vf_fillborders.c b/libavfilter/vf_fillborders.c
new file mode 100644
index 00..0396061400
--- /dev/null
+++ b/libavfilter/vf_fillborders.c
@@ -0,0 +1,277 @@
+/*
+ * Copyright (c) 2017 Paul B Mahol
+ *
+ * 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
+ */
+
+#include "libavutil/colorspace.h"
+#include "libavutil/common.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+enum { Y, U, V, A };
+enum { R, G, B };
+
+enum FillMode { FM_SMEAR, FM_MIRROR, FM_BLANK, FM_NB_MODES };
+
+typedef struct Borders {
+int left, right, top, bottom;
+} Borders;
+
+typedef struct FillBordersContext {
+const AVClass *class;
+int left, right, top, bottom;
+int mode;
+
+int nb_planes;
+Borders borders[4];
+int planewidth[4];
+int planeheight[4];
+uint8_t fill[4];
+uint8_t yuv_color[4];
+uint8_t rgba_color[4];
+
+void (*fillborders)(struct FillBordersContext *s, AVFrame *frame);
+} FillBordersContext;
+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat pix_fmts[] = {
+AV_PIX_FMT_YUV444P,  AV_PIX_FMT_YUV422P,  AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUV411P,  AV_PIX_FMT_YUV410P,
+AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P,
+AV_PIX_FMT_YUV440P,  AV_PIX_FMT_YUVJ440P,
+AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA444P,
+AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,
+AV_PIX_FMT_NONE
+};
+AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts);
+if (!

Re: [FFmpeg-devel] [PATCH] examples/hw_decode: Use hw-config information to find pixfmt

[Carl Eugen Hoyos]

2017-11-29 13:41 GMT+01:00 Timo Rothenpieler :
> Am 29.11.2017 um 13:22 schrieb Moritz Barsnick:
>>
>> On Wed, Nov 29, 2017 at 00:34:03 +, Mark Thompson wrote:
>>>
>>> +if (type == AV_HWDEVICE_TYPE_NONE) {
>>> +fprintf(stderr, "Device type %s is not supported.\n", argv[1]);
>>> +fprintf(stderr, "Available device types:");
>>> +type = AV_HWDEVICE_TYPE_NONE;
>>> +while((type = av_hwdevice_iterate_types(type)) !=
>>> AV_HWDEVICE_TYPE_NONE)
>>> +fprintf(stderr, " %s", av_hwdevice_get_type_name(type));
>>
>>
>> I see what you're trying to do with "type = AV_HWDEVICE_TYPE_NONE"
>> (initialize the iterator), but the assignment is redundant.
>>
>> I guess if the compiler optimizes it away anyway, it may be good for
>> readability, especially since it's an example. *shrug*
>
>
> I fail to see how the assignment is redundant?
> Without the assignment, that would be an infinite loop.

One assignment above...

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

[FFmpeg-devel] License question

[Werner Schindler]

Hello,

maybe this isn't the correct mail address.
We want to integrate ffmpeg.exe in our application to convert an MP4 to an low 
resolution MP4 and a view file in JPEG format.

On https://ffmpeg.org/legal.html we only find a License Compliance Check if we 
compile FFmpeg and bind against the DLL.
We want to use the downloadable windows executable and call the program for 
converting purpose.

So what must we do to be save against the License Compliance.


Best Regards
Werner Schindler
Software Architect

[cid:image001.jpg@01D3691C.1F5BB160]

fct AG
Hauptstrasse 30, 78315 Radolfzell, Germany
Fon+49 (0) 77 38 / 92 94-63
Fax +49 (0) 77 38 / 92 94-92
email schind...@fct.de
WEB  www.fct.de

Want to send me a file? Click here.

Board: Carl Pfeffer (CEO)
Chairwoman of the Supervisory Board: Prof. Sissi Closs
Registered office of the company: Radolfzell (Lake Constance)
Registry court of Freiburg under the number HRB 710573
Our General Terms and Conditions 
apply.

TIM & FrameMaker 
2017. Two new 
versions. Simple unique.

Follow us on: [cid:image002.jpg@01D3691C.1F5BB160] 

  [cid:image003.jpg@01D3691C.1F5BB160]   
[cid:image004.jpg@01D3691C.1F5BB160] 
  
[cid:image005.jpg@01D3691C.1F5BB160] 
   
[cid:image006.jpg@01D3691C.1F5BB160] 

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorised 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden. We use updated antivirus protection software. We do not accept any 
responsibility for damages caused anyhow by viruses transmitted via email.


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

Re: [FFmpeg-devel] License question

[Carl Eugen Hoyos]

2017-11-29 14:12 GMT+01:00 Werner Schindler :

> maybe this isn't the correct mail address.

There is a user mailing list for such questions.

If you do not distribute FFmpeg yourself, there
may be no issue (only distribution and warranty
are limited), in any case, ask your lawyer.

[...]

> This e-mail may contain confidential and/or privileged information.

Please remove this 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] avfilter: add fillborders filter

[Nicolas George]

Paul B Mahol (2017-11-29):
> +Fill borders of the input video.

Am I missing something or are you proposing 277 lines of code for
something that drawbox or crop+pad can already do?

Regards,

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

Re: [FFmpeg-devel] [PATCH 1/5] avformat/avc: return an error in ff_isom_write_avcc if the buffer lenght is too small

[Moritz Barsnick]

On Tue, Nov 28, 2017 at 22:42:59 -0300, James Almer wrote:
> Subject: avformat/avc: return an error in ff_isom_write_avcc if the buffer 
> lenght is too small
 ^ 
length

> -if (len > 6) {
> +if (len < 6)
> +return AVERROR_INVALIDDATA;

This changes behavior for len == 6, right? Does it matter?

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

Re: [FFmpeg-devel] [PATCH v6 2/2] avformat/dashenc: Option to generate hls playlist as well

[Steven Liu]

2017-11-29 22:05 GMT+08:00 Steven Liu :
> 2017-11-29 20:48 GMT+08:00 Karthick J :
>> This is to take full advantage of Common Media Application Format.
>> Now server can generate one content and serve both HLS and DASH players.
>> ---
>>  doc/muxers.texi   |   3 ++
>>  libavformat/Makefile  |   2 +-
>>  libavformat/dashenc.c | 103 
>> --
>>  3 files changed, 103 insertions(+), 5 deletions(-)
>>
>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>> index 8ec48c2..3d0c7bf 100644
>> --- a/doc/muxers.texi
>> +++ b/doc/muxers.texi
>> @@ -249,6 +249,9 @@ DASH-templated name to used for the media segments. 
>> Default is "chunk-stream$Rep
>>  URL of the page that will return the UTC timestamp in ISO format. Example: 
>> "https://time.akamai.com/?iso";
>>  @item -http_user_agent @var{user_agent}
>>  Override User-Agent field in HTTP header. 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 -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/Makefile b/libavformat/Makefile
>> index fd8b9f9..4bffdf2 100644
>> --- a/libavformat/Makefile
>> +++ b/libavformat/Makefile
>> @@ -135,7 +135,7 @@ OBJS-$(CONFIG_CONCAT_DEMUXER)+= concatdec.o
>>  OBJS-$(CONFIG_CRC_MUXER) += crcenc.o
>>  OBJS-$(CONFIG_DATA_DEMUXER)  += rawdec.o
>>  OBJS-$(CONFIG_DATA_MUXER)+= rawenc.o
>> -OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o
>> +OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o hlsplaylist.o
>>  OBJS-$(CONFIG_DASH_DEMUXER)  += dash.o dashdec.o
>>  OBJS-$(CONFIG_DAUD_DEMUXER)  += dauddec.o
>>  OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index 0fee3cd..ee9dc85 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -36,6 +36,7 @@
>>  #include "avc.h"
>>  #include "avformat.h"
>>  #include "avio_internal.h"
>> +#include "hlsplaylist.h"
>>  #include "internal.h"
>>  #include "isom.h"
>>  #include "os_support.h"
>> @@ -101,6 +102,8 @@ typedef struct DASHContext {
>>  const char *media_seg_name;
>>  const char *utc_timing_url;
>>  const char *user_agent;
>> +int hls_playlist;
>> +int master_playlist_created;
>>  } DASHContext;
>>
>>  static struct codec_string {
>> @@ -217,6 +220,14 @@ static void set_http_options(AVDictionary **options, 
>> DASHContext *c)
>>  av_dict_set(options, "user_agent", c->user_agent, 0);
>>  }
>>
>> +static void get_hls_playlist_name(char *playlist_name, int string_size,
>> +  const char *base_url, int id) {
>> +if (base_url)
>> +snprintf(playlist_name, string_size, "%smedia_%d.m3u8", base_url, 
>> id);
>> +else
>> +snprintf(playlist_name, string_size, "media_%d.m3u8", id);
>> +}
>> +
>>  static int flush_init_segment(AVFormatContext *s, OutputStream *os)
>>  {
>>  DASHContext *c = s->priv_data;
>> @@ -262,7 +273,8 @@ static void dash_free(AVFormatContext *s)
>>  av_freep(&c->streams);
>>  }
>>
>> -static void output_segment_list(OutputStream *os, AVIOContext *out, 
>> DASHContext *c)
>> +static void output_segment_list(OutputStream *os, AVIOContext *out, 
>> DASHContext *c,
>> +int representation_id, int final)
>>  {
>>  int i, start_index = 0, start_number = 1;
>>  if (c->window_size) {
>> @@ -322,6 +334,55 @@ static void output_segment_list(OutputStream *os, 
>> AVIOContext *out, DASHContext
>>  }
>>  avio_printf(out, "\t\t\t\t\n");
>>  }
>> +if (c->hls_playlist && start_index < os->nb_segments)
>> +{
>> +int timescale = os->ctx->streams[0]->time_base.den;
>> +char temp_filename_hls[1024];
>> +char filename_hls[1024];
>> +AVIOContext *out_hls = NULL;
>> +AVDictionary *http_opts = NULL;
>> +int target_duration = 0;
>> +const char *proto = avio_find_protocol_name(c->dirname);
>> +int use_rename = proto && !strcmp(proto, "file");
>> +
>> +get_hls_playlist_name(filename_hls, sizeof(filename_hls),
>> +  c->dirname, representation_id);
>> +
>> +snprintf(temp_filename_hls, sizeof(temp_filename_hls), use_rename ? 
>> "%s.tmp" : "%s", filename_hls);
>> +
>> +set_http_options(&http_opts, c);
>> +avio_open2(&out_hls, temp_filename_hls, AVIO_FLAG_WRITE, NULL, 
>> &http_opts);
>> +av_dict_free(&http_opts);
>> +for (i = s

Re: [FFmpeg-devel] [PATCH v6 2/2] avformat/dashenc: Option to generate hls playlist as well

[Steven Liu]

2017-11-29 20:48 GMT+08:00 Karthick J :
> This is to take full advantage of Common Media Application Format.
> Now server can generate one content and serve both HLS and DASH players.
> ---
>  doc/muxers.texi   |   3 ++
>  libavformat/Makefile  |   2 +-
>  libavformat/dashenc.c | 103 
> --
>  3 files changed, 103 insertions(+), 5 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 8ec48c2..3d0c7bf 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -249,6 +249,9 @@ DASH-templated name to used for the media segments. 
> Default is "chunk-stream$Rep
>  URL of the page that will return the UTC timestamp in ISO format. Example: 
> "https://time.akamai.com/?iso";
>  @item -http_user_agent @var{user_agent}
>  Override User-Agent field in HTTP header. 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 -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/Makefile b/libavformat/Makefile
> index fd8b9f9..4bffdf2 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -135,7 +135,7 @@ OBJS-$(CONFIG_CONCAT_DEMUXER)+= concatdec.o
>  OBJS-$(CONFIG_CRC_MUXER) += crcenc.o
>  OBJS-$(CONFIG_DATA_DEMUXER)  += rawdec.o
>  OBJS-$(CONFIG_DATA_MUXER)+= rawenc.o
> -OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o
> +OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o hlsplaylist.o
>  OBJS-$(CONFIG_DASH_DEMUXER)  += dash.o dashdec.o
>  OBJS-$(CONFIG_DAUD_DEMUXER)  += dauddec.o
>  OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 0fee3cd..ee9dc85 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -36,6 +36,7 @@
>  #include "avc.h"
>  #include "avformat.h"
>  #include "avio_internal.h"
> +#include "hlsplaylist.h"
>  #include "internal.h"
>  #include "isom.h"
>  #include "os_support.h"
> @@ -101,6 +102,8 @@ typedef struct DASHContext {
>  const char *media_seg_name;
>  const char *utc_timing_url;
>  const char *user_agent;
> +int hls_playlist;
> +int master_playlist_created;
>  } DASHContext;
>
>  static struct codec_string {
> @@ -217,6 +220,14 @@ static void set_http_options(AVDictionary **options, 
> DASHContext *c)
>  av_dict_set(options, "user_agent", c->user_agent, 0);
>  }
>
> +static void get_hls_playlist_name(char *playlist_name, int string_size,
> +  const char *base_url, int id) {
> +if (base_url)
> +snprintf(playlist_name, string_size, "%smedia_%d.m3u8", base_url, 
> id);
> +else
> +snprintf(playlist_name, string_size, "media_%d.m3u8", id);
> +}
> +
>  static int flush_init_segment(AVFormatContext *s, OutputStream *os)
>  {
>  DASHContext *c = s->priv_data;
> @@ -262,7 +273,8 @@ static void dash_free(AVFormatContext *s)
>  av_freep(&c->streams);
>  }
>
> -static void output_segment_list(OutputStream *os, AVIOContext *out, 
> DASHContext *c)
> +static void output_segment_list(OutputStream *os, AVIOContext *out, 
> DASHContext *c,
> +int representation_id, int final)
>  {
>  int i, start_index = 0, start_number = 1;
>  if (c->window_size) {
> @@ -322,6 +334,55 @@ static void output_segment_list(OutputStream *os, 
> AVIOContext *out, DASHContext
>  }
>  avio_printf(out, "\t\t\t\t\n");
>  }
> +if (c->hls_playlist && start_index < os->nb_segments)
> +{
> +int timescale = os->ctx->streams[0]->time_base.den;
> +char temp_filename_hls[1024];
> +char filename_hls[1024];
> +AVIOContext *out_hls = NULL;
> +AVDictionary *http_opts = NULL;
> +int target_duration = 0;
> +const char *proto = avio_find_protocol_name(c->dirname);
> +int use_rename = proto && !strcmp(proto, "file");
> +
> +get_hls_playlist_name(filename_hls, sizeof(filename_hls),
> +  c->dirname, representation_id);
> +
> +snprintf(temp_filename_hls, sizeof(temp_filename_hls), use_rename ? 
> "%s.tmp" : "%s", filename_hls);
> +
> +set_http_options(&http_opts, c);
> +avio_open2(&out_hls, temp_filename_hls, AVIO_FLAG_WRITE, NULL, 
> &http_opts);
> +av_dict_free(&http_opts);
> +for (i = start_index; i < os->nb_segments; i++) {
> +Segment *seg = os->segments[i];
> +if (target_duration < seg->duration)
> +tar

Re: [FFmpeg-devel] [PATCH v6 1/2] avformat/hlsenc: Modularized playlist creation to allow reuse

[Steven Liu]

2017-11-29 20:40 GMT+08:00 Jeyapal, Karthick :
> On 11/29/17, 5:16 PM, "刘歧"  wrote:
>>
>>Where can i find the v6 2/2 ?
> Patch 2/2 didn’t change since v4.
> So didn’t repost it. You have to use v4 2/2.
>
> I am sorry. I was not sure what is the normal practice here. I didn’t repost 
> it, so that the people don’t waste time in re-reviewing it.
> Is it customary to repost the all patches(even if unchanged) in a patchset, 
> when posting new versions of a particular patch?
> Please advise. I will follow accordingly from next time onwards.

I think you should sent a patchset, i usually sent patchset to
maillist, because the version indent maybe can make the reviewers and
maintainers clearly what this version do, and merge quickly, they need
not find the old version patches.


Thanks
>
> Thanks and regards,
> Karthick
>
> ___
> 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] examples/hw_decode: Use hw-config information to find pixfmt

[Moritz Barsnick]

On Wed, Nov 29, 2017 at 13:41:29 +0100, Timo Rothenpieler wrote:
> Am 29.11.2017 um 13:22 schrieb Moritz Barsnick:
> > On Wed, Nov 29, 2017 at 00:34:03 +, Mark Thompson wrote:
> >> +if (type == AV_HWDEVICE_TYPE_NONE) {
> >> +fprintf(stderr, "Device type %s is not supported.\n", argv[1]);
> >> +fprintf(stderr, "Available device types:");
> >> +type = AV_HWDEVICE_TYPE_NONE;
> >> +while((type = av_hwdevice_iterate_types(type)) != 
> >> AV_HWDEVICE_TYPE_NONE)
> >> +fprintf(stderr, " %s", av_hwdevice_get_type_name(type));
> > 
> > I see what you're trying to do with "type = AV_HWDEVICE_TYPE_NONE"
> > (initialize the iterator), but the assignment is redundant.
> [...]
> I fail to see how the assignment is redundant?
> Without the assignment, that would be an infinite loop.

if (type == AV_HWDEVICE_TYPE_NONE) {
// do something not affecting any variable
type = AV_HWDEVICE_TYPE_NONE;

Unless something else (what?) modifies the variable "type" in the
meantime, its value was already guaranteed to be AV_HWDEVICE_TYPE_NONE.

What am I missing?

(I didn't mean "(type = av_hwdevice_iterate_types(type)) !=
AV_HWDEVICE_TYPE_NONE", that's why I explicitly quoted the assignment I
meant.)

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

Re: [FFmpeg-devel] [PATCH 1/5] avformat/avc: return an error in ff_isom_write_avcc if the buffer lenght is too small

[James Almer]

On 11/29/2017 11:09 AM, Moritz Barsnick wrote:
> On Tue, Nov 28, 2017 at 22:42:59 -0300, James Almer wrote:
>> Subject: avformat/avc: return an error in ff_isom_write_avcc if the buffer 
>> lenght is too small
>  
> ^ length
> 
>> -if (len > 6) {
>> +if (len < 6)
>> +return AVERROR_INVALIDDATA;
> 
> This changes behavior for len == 6, right?

Yes. Wasn't my intention to, so fixed locally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add fillborders filter

[Moritz Barsnick]

On Wed, Nov 29, 2017 at 13:56:08 +0100, Paul B Mahol wrote:
> +@section fillborders
> +
> +Fill borders of the input video.

Nice, but isn't this something the drawbox filter could be enhanced to
do?

> +fill blank pixels

Does this mean "fill with blank pixels"? Does this imply transparency?
(Sorry, I couldn't figure that out from the code at first glance.)

> +Set color for blank pixels. Defauls is @var{black}.
   ^ Default

>  OBJS-$(CONFIG_FIND_RECT_FILTER)  += vf_find_rect.o lavfutils.o
> +OBJS-$(CONFIG_FILLBORDERS_FILTER)+= vf_fillborders.o
>  OBJS-$(CONFIG_FLOODFILL_FILTER)  += vf_floodfill.o

Alphabetical order. ;-)

>  REGISTER_FILTER(FIND_RECT,  find_rect,  vf);
> +REGISTER_FILTER(FILLBORDERS,fillborders,vf);
>  REGISTER_FILTER(FLOODFILL,  floodfill,  vf);

Ditto.

> +{ "left",   "set the left fill border",   OFFSET(left),   
> AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX,FLAGS },
> +{ "right",  "set the right fill border",  OFFSET(right),  
> AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX,FLAGS },
> +{ "top","set the top fill border",OFFSET(top),
> AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX,FLAGS },
> +{ "bottom", "set the bottom fill border", OFFSET(bottom), 
> AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX,FLAGS },

Could make that "... fill border width" or something (which may be
redundant - I'm not sure).

> +{ "mode",   "set the fill borders mode",  OFFSET(mode),   
> AV_OPT_TYPE_INT, {.i64=0}, 0, FM_NB_MODES-1, FLAGS, "mode" },
> +{ "smear",  NULL, 0, AV_OPT_TYPE_CONST, {.i64=FM_SMEAR},  0, 0, 
> FLAGS, "mode" },
> +{ "mirror", NULL, 0, AV_OPT_TYPE_CONST, {.i64=FM_MIRROR}, 0, 0, 
> FLAGS, "mode" },
> +{ "blank",  NULL, 0, AV_OPT_TYPE_CONST, {.i64=FM_BLANK},  0, 0, 
> FLAGS, "mode" },

The default mode ("{.i64=0}") should also be encoded with use of an
explicit macro.

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Add metadata to identify hardware backed codecs

[wm4]

On Mon, 27 Nov 2017 20:46:00 -0800
Philip Langdale  wrote:

> If hardware acceleration is implemented through an HWAccel, then it's
> easy to recognise, but some hardware implementations are best suited
> to implementation as full decoders, and these are not easy to identify.
> Clients typically need hardcoded lists of codecs, and usually need to
> rely on related codecs using a particular naming convention.
> 
> To make it easier to discover these codecs dynamically, we can
> introduce an explicit AV_CODEC_CAP_HARDWARE that indicates the codec
> is hardware-backed. We also introduce a 'provider' field into AVCodec
> that allows for an identifier to be attached to these codecs for
> simple matching. The provider could also be used to identify the
> use of an external software library.
> 
> Unfortunately, we know of at least one case where an external interface
> might silently end up using a separate software implementation (libmfx)
> and so we introduce AV_CODEC_CAP_MAYBE_NOT_HARDWARE so say that you
> can't trust it 100%. It's silly but what can you do?
> 
> The expected use-case here is allowing a client application to
> enumerate hardware decoding options for a given format and to allow
> a user to select one based on a recognisable identifier (the provider).
> 
> Signed-off-by: Philip Langdale 
> ---
>  Changelog|  1 +
>  doc/APIchanges   |  5 +
>  libavcodec/avcodec.h | 19 +++
>  3 files changed, 25 insertions(+)
> 
> diff --git a/Changelog b/Changelog
> index 76d6fad56b..a99edbf4b7 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -21,6 +21,7 @@ version :
>  - video mix filter
>  - video normalize filter
>  - audio lv2 wrapper filter
> +- Added codec metadata to identify hardware backed decoders
>  
>  
>  version 3.4:
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 44a740e51f..7856cb13a1 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,11 @@ libavutil: 2017-10-21
>  
>  API changes, most recent first:
>  
> +2017-12-xx - xxx - lavc 58.7.100 - avcodec.h
> +  Add AV_CODEC_CAP_HARDWARE
> +  Add AV_CODEC_CAP_MAYBE_NOT_HARDWARE
> +  Add AVCodec.provider
> +
>  2017-xx-xx - xxx - lavc 58.6.100 - avcodec.h
>Add const to AVCodecContext.hwaccel.
>  
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index c1e68b1d13..04cfa48665 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1036,6 +1036,16 @@ typedef struct RcOverride{
>   * choice for probing.
>   */
>  #define AV_CODEC_CAP_AVOID_PROBING   (1 << 17)
> +/**
> + * Codec is backed by a hardware implementation. Typically used to
> + * identify a non-hwaccel hardware decoder.
> + */
> +#define AV_CODEC_CAP_HARDWARE(1 << 18)
> +/**
> + * Codec is normally backed by a hardware implementation, but the
> + * external abstraction could be software backed.
> + */
> +#define AV_CODEC_CAP_MAYBE_NOT_HARDWARE  (1 << 19)

One could argue that every hw-backed decoder might fallback to software
fully or partially. For example, Intel is known to have hybrid drivers
(that sometimes even tend to be slower than libavcodec), and
videotoolbox has a software decoder (though we disable it). So I'm not
sure if this flag is really necessary, but I'm not opposed either.

>  /**
>   * Codec is intra only.
>   */
> @@ -3475,6 +3485,15 @@ typedef struct AVCodec {
>   * The user can only access this field via avcodec_get_hw_config().
>   */
>  const struct AVCodecHWConfigInternal **hw_configs;
> +
> +/**
> + * String that helps identify the external provider for the codec.
> + * For example, if some external hardware decoder provides support
> + * for a variety of codecs, they could each set the same provider
> + * value to signify their relationship. Could also be used to
> + * identify the use of an external software implementation.
> + */
> +   const char *provider;
>  } AVCodec;
>  
>  #if FF_API_CODEC_GET_SET

Generally LGTM. It's pretty useless if it doesn't land in libav,
though. Can you post it there too?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[wm4]

On Tue, 28 Nov 2017 00:43:25 +
Mark Thompson  wrote:

> ...
> 
> Ok; done, plus some trivial testing to make sure it works.  If you're happy 
> with this and noone else says anything then I'll push it tomorrow.
> 
> Relatedly: your name on patches does not match your full name - I've 
> preserved the patch one here, but was that intended?
> 
> Thanks,
> 
> - Mark
> 
> 
>  Changelog|   1 +
>  configure|  10 +
>  libavcodec/Makefile  |   4 +
>  libavcodec/allcodecs.c   |   2 +
>  libavcodec/amfenc.c  | 604 
> +++
>  libavcodec/amfenc.h  | 148 
>  libavcodec/amfenc_h264.c | 395 +++
>  libavcodec/amfenc_hevc.c | 326 +
>  8 files changed, 1490 insertions(+)
>  create mode 100644 libavcodec/amfenc.c
>  create mode 100644 libavcodec/amfenc.h
>  create mode 100644 libavcodec/amfenc_h264.c
>  create mode 100644 libavcodec/amfenc_hevc.c
> 
> diff --git a/Changelog b/Changelog
> index afead72f14..7a913bf7a7 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -21,6 +21,7 @@ version :
>  - video mix filter
>  - video normalize filter
>  - audio lv2 wrapper filter
> +- AMD AMF H.264 and HEVC encoders
>  
>  
>  version 3.4:
> diff --git a/configure b/configure
> index 6748ef8bc9..3036b69cab 100755
> --- a/configure
> +++ b/configure
> @@ -304,6 +304,7 @@ External library support:
>--disable-zlib   disable zlib [autodetect]
>  
>The following libraries provide various hardware acceleration features:
> +  --disable-amfdisable AMF video encoding code [autodetect]
>--disable-audiotoolbox   disable Apple AudioToolbox code [autodetect]
>--disable-cuda   disable dynamically linked Nvidia CUDA code 
> [autodetect]
>--enable-cuda-sdkenable CUDA features that require the CUDA SDK 
> [no]
> @@ -1639,6 +1640,7 @@ EXTERNAL_LIBRARY_LIST="
>  "
>  
>  HWACCEL_AUTODETECT_LIBRARY_LIST="
> +amf
>  audiotoolbox
>  crystalhd
>  cuda
> @@ -2782,12 +2784,14 @@ scale_npp_filter_deps="cuda libnpp"
>  scale_cuda_filter_deps="cuda_sdk"
>  thumbnail_cuda_filter_deps="cuda_sdk"
>  
> +amf_deps_any="libdl LoadLibrary"
>  nvenc_deps="cuda"
>  nvenc_deps_any="libdl LoadLibrary"
>  nvenc_encoder_deps="nvenc"
>  
>  h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m"
>  h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m"
> +h264_amf_encoder_deps="amf"
>  h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser"
>  h264_cuvid_decoder_deps="cuvid"
>  h264_cuvid_decoder_select="h264_mp4toannexb_bsf"
> @@ -2804,6 +2808,7 @@ 
> h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
>  h264_vaapi_encoder_select="cbs_h264 vaapi_encode"
>  h264_v4l2m2m_decoder_deps="v4l2_m2m h264_v4l2_m2m"
>  h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m"
> +hevc_amf_encoder_deps="amf"
>  hevc_cuvid_decoder_deps="cuvid"
>  hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf"
>  hevc_mediacodec_decoder_deps="mediacodec"
> @@ -6194,6 +6199,11 @@ void f(void) { struct { const GUID guid; } s[] = { { 
> NV_ENC_PRESET_HQ_GUID } };
>  int main(void) { return 0; }
>  EOF
>  
> +enabled amf &&
> +check_cpp_condition "AMF/core/Version.h" \
> +"(AMF_VERSION_MAJOR << 48 | AMF_VERSION_MINOR << 32 | 
> AMF_VERSION_RELEASE << 16 | AMF_VERSION_BUILD_NUM) >= 0x0001000400040001" ||
> +disable amf
> +
>  # Funny iconv installations are not unusual, so check it after all flags 
> have been set
>  if enabled libc_iconv; then
>  check_func_headers iconv.h iconv
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index a6203d424b..ab7893f560 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -55,6 +55,7 @@ OBJS = ac3_parser.o 
> \
>  OBJS-$(CONFIG_AANDCTTABLES)+= aandcttab.o
>  OBJS-$(CONFIG_AC3DSP)  += ac3dsp.o ac3.o ac3tab.o
>  OBJS-$(CONFIG_ADTS_HEADER) += adts_header.o mpeg4audio.o
> +OBJS-$(CONFIG_AMF) += amfenc.o
>  OBJS-$(CONFIG_AUDIO_FRAME_QUEUE)   += audio_frame_queue.o
>  OBJS-$(CONFIG_AUDIODSP)+= audiodsp.o
>  OBJS-$(CONFIG_BLOCKDSP)+= blockdsp.o
> @@ -337,6 +338,7 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o 
> h264_cabac.o h264_cavlc.o \
>h264_mb.o h264_picture.o \
>h264_refs.o h264_sei.o \
>h264_slice.o h264data.o
> +OBJS-$(CONFIG_H264_AMF_ENCODER)+= amfenc_h264.o
>  OBJS-$(CONFIG_H264_CUVID_DECODER)  += cuviddec.o
>  OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o
>  OBJS-$(CONFIG_H264_MMAL_DECODER)   += mmaldec.o
> @@ -356,6 +358,7 @@ OBJS-$(CONFIG_HAP_ENCODER) += hapenc.o hap.o
>  OBJS-$(CONFIG_HEVC_DECODER)+= hevcdec.o hevc_mvs.o \
>   

Re: [FFmpeg-devel] Policy on ffmpeg-devel list and contributions [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

[Compn]

On Mon, 27 Nov 2017 23:46:30 -0800, Jim DeLaHunt
 wrote:

> On 2017-11-27 15:00, Carl Eugen Hoyos wrote:
> > 2017-11-26 22:44 GMT+01:00 Jim DeLaHunt :
> >> So, how realistic is this concern about non-subscribers sending 
> >> patches to
> >> ffmpeg-devel?  Does it actually happen?
> > This is very realistic afair.
> OK, and Lou Logan corroborates Carl Eugen:
> On 2017-11-27 15:19, Lou Logan wrote:
> > A very rough guess is that there are usually at least several
> > patches from unsubscribed users a week (in fact there was one in the
> > queue minutes ago).
> 
> So I accept that welcoming non-subscribers sending patches to 
> ffmpeg-devel is a real concern. I was skeptical, but I was wrong.

Let me also echo Lou and Carl's concerns. I am one of the other ML
admins/mods and just 2 days ago approved submission to -devel a patch
that was stuck in the mod queue because the author was not subscribed.
i also auto-approved all future mails from that author.

Patches without subscription happens often, couple times per month? The
list traffic is immense (thousands of patches and discussions per
month) and most people just want to drop a patch and run. Most smaller
quick clear error fixing patches are accepted i would say, so this
situation works.

of course we are always looking for better practices, so we also have
patchwork installed:

https://patchwork.ffmpeg.org/project/ffmpeg/list/

unfortunately , we have also seen many distros and projects maintain
their own ffmpeg patches, sometimes for years. never submitting them
back to us. we are trying to improve this situation in any way that we
can.

i'm not trying to dogpile on you, just explaining the situation.

> Also, someone once observed that common sense is not very common. :-)

sure, but please remember the DOCS are already quite verbose, and
brevity is the soul of wit. so if you can say more with less verbiage
that would be great.

> -
> It is important to be subscribed to the
> @uref{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel, ffmpeg-devel}
> mailing list, because any non-trivial patch you contribute must be sent 
> there
> and reviewed by other developers. They may have comments about your
> contribution. We expect you see those comments, and to improve your 
> contribution
> if requested. (N.B. Experienced committers may sometimes skip review for 
> trivial fixes.)
> Also, this list is where bug fixes and ffmpeg improvements from other 
> developers
> are discussed. That may be helpful information as you write your 
> contribution. Finally, by being a list
> subscriber your contribution will be posted immediately to the list,
> without the moderation hold which messages from non-subscribers experience.
> 
> However, it is more important to the project that we receive your
> patch than that you be subscribed to the ffmpeg-devel list. If you
> have a patch, and don't want to subscribe and discuss the patch,
> then please do send it to the list.
> -

i think your additions are well meaning, but the above is repetitive and
can be made smaller. e.g. you use the words contribution, comments etc
multiple times. i could attempt a rephrasing if you want? i would have
done so in this mail but i am in a rush atm.

Also please note that most ffmpeg developers and patch authors are from
around the world , and english may not be their native language.


>I am trying to contribute patches to fix the most severe, easiest to fix bugs 
>in the docs.

no problem. thanks for contributing.

> I find it interesting that bug fixes and enhancements to the source code 
> of ffmpeg are approved so much more easily than this patch's bug fixes 
> and enhancements to the text of ffmpeg.org. This is not a smooth 
> documentation process.

haha! well let me please explain to you what situation you have gotten
yourself stuck into! :)

the development docs that you want to patch are actually the ffmpeg
project's written rules and policy that governs the whole shebang.

so these are the rules that all devs must agree to within the project.
sure, we bicker about the rules and not everyone follows every rule,
and we have many unwritten rules that we also abide by. which also
causes great strife sometimes when someone thinks a rule is official or
not... look i didnt say it was a good system, it is what we have
evolved into over the years.

the point is that changes to this specific part of the documentation
affects all devs, not just new contributors. so we are more interested
to changes of this document. especially large changes all in one patch.

what your v1 patch has unintentionally done is to change our long
standing ffmpeg policy about patch submission and review. i know this
was not your intention, but you have picked one of the core parts of the
project to modify on your first attempt. :)

hope this clears things up. feel free to ask me questions off list, or
we can be found on irc.freenode.net #ffmpeg-devel as well for real
time chat.

tl;dr my suggestions:
1. 

Re: [FFmpeg-devel] AMD external header

[wm4]

On Mon, 27 Nov 2017 02:15:12 +
"Mironov, Mikhail"  wrote:

> Hi,
> I would like to summarize thoughts on several threads on this forum related 
> to the issue of including AMD/AMF header file into FFmpeg source tree. 
> It looks like they reflect some policies formal or informal.
> Mark tried to create some policy regarding this issue but wasn't successful. 
> I believe a policy is always created to reach some goal. 
> So my summary will be in form of triad: 
> policy->goal->possible action
> I will skip all arguments, you already read them.
> #1
>policy: do not include external headers
>goal: minimize maintenance efforts and increase stability of the project
>action: remove NVidia headers
> #2
>policy: keep certain headers in the tree based on some criteria
>goal: provide certain level of convenience for ordinary users
>action: include AMD header
> #3
>   policy: do whatever is needed to achieve the goal
>   goal: achieve neutrality in relation to HW vendors
>   action: remove NVidia headers or add AMD header
> 
> Since these policies contradict each other, some priorities should be set 
> and I don't know how to do it. Personally I like #2 the most, but this is not 
> my call.
> But my point is that by keeping NVidia headers in the tree and not allowing 
> AMD header, 
> FFmpeg development team breaks all three policies and do not achieve any goal.
> If this is what you want maybe you should state this explicitly on the 
> "About" page 
> as Mark suggested: 
> "No external headers may be added to the ffmpeg tree, unless they are for 
> AviSynth or Nvidia"
> At least it will be clear for all users and developers. 
> You may say that you will include only headers hard to get. But does it mean 
> that AMD must 
> obscure access to the headers to be included? I hope not.

I'd definitely say adding the nvidia and AviSynth headers was a
mistake. Only headers for basic OS compatibility should be allowed. A
good example for such headers would the atomics emulation or msvcrt
compatibility. In general, the allowed external code/headers are
supposed to support things guaranteed by standards (like C or POSIX),
not third-party libraries like vendor-specific drivers or SDKs.

At this point, the nvidia and avisynth headers are probably considered
against the rules. But as the damage is done and removal would cause
problems to certain people, they're "grandfathered". Mark Thompson put
that into words by making them explicit exceptions to the rule.

(Though I think the avisynth headers should be removed because they're
far less useful than nvidia drivers.)

It also should be made clear that nvidia does not somehow receive
preferred treatment over other vendors. In fact, if someone were to
send a patch to move the nvidia headers to a separate repository, I'd
definitely give it a OK (though I have no special say in this and it
depends on other devs too.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[wm4]

On Tue, 28 Nov 2017 16:09:57 +
"Mironov, Mikhail"  wrote:

> > 
> > Pavel Koshevoy (2017-11-27):  
> > > That is unnecessarily un-diplomatic and will likely offend the
> > > contributors from nvidia and amd.  
> > 
> > Well, I find offensive that they benefit from my work yet make extra efforts
> > to make sure I cannot benefit from theirs. Maybe I should start putting my
> > contributions under GPL and not LGPL, what do you think?
> >   
> > > Personally, I would prefer if the bundled external headers were
> > > installed together with ffmpeg public headers (so nvenc/cuda/etc...
> > > weren't simply private headers within ffmpeg).  There are some nvenc
> > > APIs I need to query hardware capabilities to avoid setting nvenc
> > > codec parameters that would cause the codec to fail to initialize via
> > > ffmpeg apis.  Given that ffmpeg already includes the headers that
> > > declare those APIs I've been able to use them without installing nvenc
> > > SDK separately, but since they are private headers in the ffmpeg
> > > source tree it feels dirty to do that.  
> > 
> > I understand it is more convenient for you than what the vendors provide,
> > but why should the effort of making things more convenient be carried by
> > the FFmpeg developers?
> > 
> > It has a non-negligible cost: more testing required, git grep pollution, 
> > all the
> > while giving these companies an unfair advantage against the companies that
> > play by the rules of Libre software and inciting them to continue in that
> > direction.
> > 
> > I think the whole compat directory is misguided, but these headers for
> > external libraries are the worse of it.
> > 
> > Regards,
> > 
> > --
> >   Nicolas George  
> 
> I wanted to stay out of license issues and this forum is oriented more 
> towards 
> technical discussion but I can't resist putting my two cents: Yes, HW 
> manufactures
>  live out of HW sell. And yes, integration with products like ffmpeg should 
> benefit them (us).
> But they(us) do not sell software. The enablement of HW acceleration adds 
> features to ffmpeg project.  
> And we do it ourselves. We also intend to contribute more. So it is mutually 
> beneficial.  Isn't it?

Well, don't worry too much. People like him are, as some would say,
toxic members of the community. Frequent drama and flame wars happen.
(And here's where I wished ffmpeg were a properly managed project.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Carl Eugen Hoyos]

2017-11-29 15:58 GMT+01:00 wm4 :

> Well, don't worry too much. People like him are, as some would say,
> toxic members of the community. Frequent drama and flame wars happen.
> (And here's where I wished ffmpeg were a properly managed project.)

Look who's talking!

Given that you started a fork of FFmpeg repeating ancient lies
and stating you don't support FFmpeg anymore:
Why do you post here?

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

Re: [FFmpeg-devel] [PATCH] avfilter: add fillborders filter

[Paul B Mahol]

On 11/29/17, Nicolas George  wrote:
> Paul B Mahol (2017-11-29):
>> +Fill borders of the input video.
>
> Am I missing something or are you proposing 277 lines of code for
> something that drawbox or crop+pad can already do?

By careful patch examination, one can find out that filter provides
additional functionality: filling by smearing and mirroring - no
crop/drawbox/pad filter combinations can archieve this at all or if
it can in case of just blanking it comes with extra cost of copying
video frame.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add fillborders filter

[Paul B Mahol]

On 11/29/17, Moritz Barsnick  wrote:
> On Wed, Nov 29, 2017 at 13:56:08 +0100, Paul B Mahol wrote:
>> +@section fillborders
>> +
>> +Fill borders of the input video.
>
> Nice, but isn't this something the drawbox filter could be enhanced to
> do?

Nope.

>
>> +fill blank pixels
>
> Does this mean "fill with blank pixels"? Does this imply transparency?
> (Sorry, I couldn't figure that out from the code at first glance.)

Fill pixels of fixed value.

>
>> +Set color for blank pixels. Defauls is @var{black}.
>^ Default
>
>>  OBJS-$(CONFIG_FIND_RECT_FILTER)  += vf_find_rect.o
>> lavfutils.o
>> +OBJS-$(CONFIG_FILLBORDERS_FILTER)+= vf_fillborders.o
>>  OBJS-$(CONFIG_FLOODFILL_FILTER)  += vf_floodfill.o
>
> Alphabetical order. ;-)

Fixed.

>
>>  REGISTER_FILTER(FIND_RECT,  find_rect,  vf);
>> +REGISTER_FILTER(FILLBORDERS,fillborders,vf);
>>  REGISTER_FILTER(FLOODFILL,  floodfill,  vf);
>
> Ditto.

Fixed.

>
>> +{ "left",   "set the left fill border",   OFFSET(left),
>> AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX,FLAGS },
>> +{ "right",  "set the right fill border",  OFFSET(right),
>> AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX,FLAGS },
>> +{ "top","set the top fill border",OFFSET(top),
>> AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX,FLAGS },
>> +{ "bottom", "set the bottom fill border", OFFSET(bottom),
>> AV_OPT_TYPE_INT, {.i64=0}, 0, INT_MAX,FLAGS },
>
> Could make that "... fill border width" or something (which may be
> redundant - I'm not sure).

Better not.

>
>> +{ "mode",   "set the fill borders mode",  OFFSET(mode),
>> AV_OPT_TYPE_INT, {.i64=0}, 0, FM_NB_MODES-1, FLAGS, "mode" },
>> +{ "smear",  NULL, 0, AV_OPT_TYPE_CONST, {.i64=FM_SMEAR},  0, 0,
>> FLAGS, "mode" },
>> +{ "mirror", NULL, 0, AV_OPT_TYPE_CONST, {.i64=FM_MIRROR}, 0, 0,
>> FLAGS, "mode" },
>> +{ "blank",  NULL, 0, AV_OPT_TYPE_CONST, {.i64=FM_BLANK},  0, 0,
>> FLAGS, "mode" },
>
> The default mode ("{.i64=0}") should also be encoded with use of an
> explicit macro.

Fixed.

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

Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> 
> > +{ AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
> 
> Wut, really? It's not a typo? It looks tricky.
> 
> I assume AMF has D3D11 input, but then it'd still need to exclude P010.
> I don't think this is ever done, and sending a P010 frame probably
> crashes the thing?
> 
> > +};

There is a checking at initialization time of sw_format that will fail for P010.

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

Re: [FFmpeg-devel] AMD external header

[Paul B Mahol]

On 11/29/17, Carl Eugen Hoyos  wrote:
> 2017-11-29 15:58 GMT+01:00 wm4 :
>
>> Well, don't worry too much. People like him are, as some would say,
>> toxic members of the community. Frequent drama and flame wars happen.
>> (And here's where I wished ffmpeg were a properly managed project.)
>
> Look who's talking!
>
> Given that you started a fork of FFmpeg repeating ancient lies
> and stating you don't support FFmpeg anymore:
> Why do you post here?

Because he like to argue with toxic people like you.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avformat/dashenc: Option to generate hls playlist as well

[Karthick J]

This is to take full advantage of Common Media Application Format.
Now server can generate one content and serve both HLS and DASH players.
---
 doc/muxers.texi   |   3 ++
 libavformat/Makefile  |   2 +-
 libavformat/dashenc.c | 103 --
 3 files changed, 103 insertions(+), 5 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 8ec48c2..3d0c7bf 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -249,6 +249,9 @@ DASH-templated name to used for the media segments. Default 
is "chunk-stream$Rep
 URL of the page that will return the UTC timestamp in ISO format. Example: 
"https://time.akamai.com/?iso";
 @item -http_user_agent @var{user_agent}
 Override User-Agent field in HTTP header. 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 -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/Makefile b/libavformat/Makefile
index fd8b9f9..4bffdf2 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -135,7 +135,7 @@ OBJS-$(CONFIG_CONCAT_DEMUXER)+= concatdec.o
 OBJS-$(CONFIG_CRC_MUXER) += crcenc.o
 OBJS-$(CONFIG_DATA_DEMUXER)  += rawdec.o
 OBJS-$(CONFIG_DATA_MUXER)+= rawenc.o
-OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o
+OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o hlsplaylist.o
 OBJS-$(CONFIG_DASH_DEMUXER)  += dash.o dashdec.o
 OBJS-$(CONFIG_DAUD_DEMUXER)  += dauddec.o
 OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 0fee3cd..efc2012 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -36,6 +36,7 @@
 #include "avc.h"
 #include "avformat.h"
 #include "avio_internal.h"
+#include "hlsplaylist.h"
 #include "internal.h"
 #include "isom.h"
 #include "os_support.h"
@@ -101,6 +102,8 @@ typedef struct DASHContext {
 const char *media_seg_name;
 const char *utc_timing_url;
 const char *user_agent;
+int hls_playlist;
+int master_playlist_created;
 } DASHContext;
 
 static struct codec_string {
@@ -217,6 +220,14 @@ static void set_http_options(AVDictionary **options, 
DASHContext *c)
 av_dict_set(options, "user_agent", c->user_agent, 0);
 }
 
+static void get_hls_playlist_name(char *playlist_name, int string_size,
+  const char *base_url, int id) {
+if (base_url)
+snprintf(playlist_name, string_size, "%smedia_%d.m3u8", base_url, id);
+else
+snprintf(playlist_name, string_size, "media_%d.m3u8", id);
+}
+
 static int flush_init_segment(AVFormatContext *s, OutputStream *os)
 {
 DASHContext *c = s->priv_data;
@@ -262,7 +273,8 @@ static void dash_free(AVFormatContext *s)
 av_freep(&c->streams);
 }
 
-static void output_segment_list(OutputStream *os, AVIOContext *out, 
DASHContext *c)
+static void output_segment_list(OutputStream *os, AVIOContext *out, 
DASHContext *c,
+int representation_id, int final)
 {
 int i, start_index = 0, start_number = 1;
 if (c->window_size) {
@@ -322,6 +334,55 @@ static void output_segment_list(OutputStream *os, 
AVIOContext *out, DASHContext
 }
 avio_printf(out, "\t\t\t\t\n");
 }
+if (c->hls_playlist && start_index < os->nb_segments)
+{
+int timescale = os->ctx->streams[0]->time_base.den;
+char temp_filename_hls[1024];
+char filename_hls[1024];
+AVIOContext *out_hls = NULL;
+AVDictionary *http_opts = NULL;
+int target_duration = 0;
+const char *proto = avio_find_protocol_name(c->dirname);
+int use_rename = proto && !strcmp(proto, "file");
+
+get_hls_playlist_name(filename_hls, sizeof(filename_hls),
+  c->dirname, representation_id);
+
+snprintf(temp_filename_hls, sizeof(temp_filename_hls), use_rename ? 
"%s.tmp" : "%s", filename_hls);
+
+set_http_options(&http_opts, c);
+avio_open2(&out_hls, temp_filename_hls, AVIO_FLAG_WRITE, NULL, 
&http_opts);
+av_dict_free(&http_opts);
+for (i = start_index; i < os->nb_segments; i++) {
+Segment *seg = os->segments[i];
+double duration = (double) seg->duration / timescale;
+if (target_duration <= duration)
+target_duration = hls_get_int_from_double(duration);
+}
+
+ff_hls_write_playlist_header(out_hls, 6, -1, target_duration,
+ start_number, PLAYLIST_TYPE_NONE);
+
+   

[FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: Refactored 'get_int_from_double' function to allow reuse

[Karthick J]

From: Karthick Jeyapal 

---
 libavformat/hlsenc.c  | 7 +--
 libavformat/hlsplaylist.h | 5 +
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index f63b08d..cdfbf45 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -203,11 +203,6 @@ typedef struct HLSContext {
 int http_persistent;
 } HLSContext;
 
-static int get_int_from_double(double val)
-{
-return (int)((val - (int)val) >= 0.001) ? (int)(val + 1) : (int)val;
-}
-
 static int mkdir_p(const char *path) {
 int ret = 0;
 char *temp = av_strdup(path);
@@ -1211,7 +1206,7 @@ static int hls_window(AVFormatContext *s, int last, 
VariantStream *vs)
 
 for (en = vs->segments; en; en = en->next) {
 if (target_duration <= en->duration)
-target_duration = get_int_from_double(en->duration);
+target_duration = hls_get_int_from_double(en->duration);
 }
 
 vs->discontinuity_set = 0;
diff --git a/libavformat/hlsplaylist.h b/libavformat/hlsplaylist.h
index fd36c7e..68ef8d4 100644
--- a/libavformat/hlsplaylist.h
+++ b/libavformat/hlsplaylist.h
@@ -32,6 +32,11 @@ typedef enum {
 PLAYLIST_TYPE_NB,
 } PlaylistType;
 
+static inline int hls_get_int_from_double(double val)
+{
+return (int)((val - (int)val) >= 0.001) ? (int)(val + 1) : (int)val;
+}
+
 void ff_hls_write_playlist_version(AVIOContext *out, int version);
 void ff_hls_write_stream_info(AVStream *st, AVIOContext *out,
   int bandwidth, char *filename);
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH v6 2/2] avformat/dashenc: Option to generate hls playlist as well

[Jeyapal, Karthick]

On 11/29/17, 7:43 PM, "Steven Liu"  wrote:

>> +target_duration = lrint((double) target_duration / timescale);
>What value will set when the target_duration is 1.023 ? I think we
>have talk about the value and the specification describe the standard
>process way.
>You can move the function get_int_from_double to the common file and use that.

Thanks for reminding me. I have corrected it and sent a fresh patchset as you 
suggested.
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221317.html

regards,
Karthick 

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

Re: [FFmpeg-devel] AMD external header

[Compn]

On Wed, 29 Nov 2017 15:58:29 +0100, wm4  wrote:

> On Tue, 28 Nov 2017 16:09:57 +
> "Mironov, Mikhail"  wrote:
> > 
> > I wanted to stay out of license issues and this forum is oriented more 
> > towards 
> > technical discussion but I can't resist putting my two cents: Yes, HW 
> > manufactures
> >  live out of HW sell. And yes, integration with products like ffmpeg should 
> > benefit them (us).
> > But they(us) do not sell software. The enablement of HW acceleration adds 
> > features to ffmpeg project.  
> > And we do it ourselves. We also intend to contribute more. So it is 
> > mutually beneficial.  Isn't it?
> 
> Well, don't worry too much. 

as an mplayer user who had to go looking to find a bunch of sdk headers
and hope that the instructions written 2 years ago still point to a
working URL, i feel a lot of pain in this thread.

svn has svn externals, where a svn checkout would pull from other svn
repositories.

i am assuming git has the same thing? if so these headers could go in
an external repo, but a ffmpeg git pull would pull them down? are there
any objections to that ?

that would cut down on our objections and maintainership and git
history concerns... i think? so long as its easy for non amd users to
flip a config switch to disable pulling those amd headers down.

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

[FFmpeg-devel] [PATCH] vp9: use superframe split BSF

[wm4]

webm usually has invisible superframes merged with normal frames.
(vpxenc muxes them in this form, which is evidence enough that this is
the standard webm packet format. It's rather unclear whether ffmpeg is
even allowed to remux them with split packets.)

The vp9 decoder needs them to be in separate packets for multithreading
to work. Add the BSF to the decoder, so the conversion happens
automatically.

This contains the important part of fa1749dd34c55fb9, which
was apparently skipped in commit d417e95af76. This restores Libav API
compatibility.
---
 libavcodec/version.h | 2 +-
 libavcodec/vp9.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/version.h b/libavcodec/version.h
index 55bb5c5e01..d67b689142 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR  58
 #define LIBAVCODEC_VERSION_MINOR   6
-#define LIBAVCODEC_VERSION_MICRO 101
+#define LIBAVCODEC_VERSION_MICRO 102
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 1ea2869c4c..6241f01de1 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1795,6 +1795,7 @@ AVCodec ff_vp9_decoder = {
 .init_thread_copy  = 
ONLY_IF_THREADS_ENABLED(vp9_decode_init_thread_copy),
 .update_thread_context = 
ONLY_IF_THREADS_ENABLED(vp9_decode_update_thread_context),
 .profiles  = NULL_IF_CONFIG_SMALL(ff_vp9_profiles),
+.bsfs  = "vp9_superframe_split",
 .hw_configs= (const AVCodecHWConfigInternal*[]) {
 #if CONFIG_VP9_DXVA2_HWACCEL
HWACCEL_DXVA2(vp9),
-- 
2.15.0

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

Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[wm4]

On Wed, 29 Nov 2017 15:13:01 +
"Mironov, Mikhail"  wrote:

> >   
> > > +{ AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },  
> > 
> > Wut, really? It's not a typo? It looks tricky.
> > 
> > I assume AMF has D3D11 input, but then it'd still need to exclude P010.
> > I don't think this is ever done, and sending a P010 frame probably
> > crashes the thing?
> >   
> > > +};  
> 
> There is a checking at initialization time of sw_format that will fail for 
> P010.

Oops, missed that. Great then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[wm4]

On Wed, 29 Nov 2017 16:07:36 +0100
Carl Eugen Hoyos  wrote:

> 2017-11-29 15:58 GMT+01:00 wm4 :
> 
> > Well, don't worry too much. People like him are, as some would say,
> > toxic members of the community. Frequent drama and flame wars happen.
> > (And here's where I wished ffmpeg were a properly managed project.)  
> 
> Look who's talking!
> 
> Given that you started a fork of FFmpeg repeating ancient lies
> and stating you don't support FFmpeg anymore:
> Why do you post here?

You won't hear any lies from me. But it's well known that you twist the
truth whenever it fits you.

Anyway, this is the upstream project for ffmpeg-mpv, so why wouldn't I
post here?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vp9: use superframe split BSF

[James Almer]

On 11/29/2017 12:24 PM, wm4 wrote:
> webm usually has invisible superframes merged with normal frames.
> (vpxenc muxes them in this form, which is evidence enough that this is
> the standard webm packet format. It's rather unclear whether ffmpeg is
> even allowed to remux them with split packets.)

It is currently, since the vp9 parser splits them not just for the
decoder but for everything else as well. But by default, thanks to
autoinserted bsfs, libavformat muxers will try to merge them back
without the user explicitly asking for it.

That's why i sent a patch to make said autoinserted bsfs on muxers non
optional, but it's kinda hard to enforce without making the muxers abort
if the needed bsfs are not compiled in, since they are in a different
library.

> 
> The vp9 decoder needs them to be in separate packets for multithreading
> to work. Add the BSF to the decoder, so the conversion happens
> automatically.
> 
> This contains the important part of fa1749dd34c55fb9, which
> was apparently skipped in commit d417e95af76. This restores Libav API
> compatibility.

The parser currently handles this, but i agree that ideally that should
be done by the bsf and exclusively within the decoder, so no split
packets will find their way into muxers.

> ---
>  libavcodec/version.h | 2 +-
>  libavcodec/vp9.c | 1 +
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 55bb5c5e01..d67b689142 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -29,7 +29,7 @@
>  
>  #define LIBAVCODEC_VERSION_MAJOR  58
>  #define LIBAVCODEC_VERSION_MINOR   6
> -#define LIBAVCODEC_VERSION_MICRO 101
> +#define LIBAVCODEC_VERSION_MICRO 102
>  
>  #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> LIBAVCODEC_VERSION_MINOR, \
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index 1ea2869c4c..6241f01de1 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -1795,6 +1795,7 @@ AVCodec ff_vp9_decoder = {
>  .init_thread_copy  = 
> ONLY_IF_THREADS_ENABLED(vp9_decode_init_thread_copy),
>  .update_thread_context = 
> ONLY_IF_THREADS_ENABLED(vp9_decode_update_thread_context),
>  .profiles  = NULL_IF_CONFIG_SMALL(ff_vp9_profiles),
> +.bsfs  = "vp9_superframe_split",
>  .hw_configs= (const AVCodecHWConfigInternal*[]) {
>  #if CONFIG_VP9_DXVA2_HWACCEL
> HWACCEL_DXVA2(vp9),
> 

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

Re: [FFmpeg-devel] AMD external header

[wm4]

On Wed, 29 Nov 2017 10:23:54 -0500
Compn  wrote:

> On Wed, 29 Nov 2017 15:58:29 +0100, wm4  wrote:
> 
> > On Tue, 28 Nov 2017 16:09:57 +
> > "Mironov, Mikhail"  wrote:  
> > > 
> > > I wanted to stay out of license issues and this forum is oriented more 
> > > towards 
> > > technical discussion but I can't resist putting my two cents: Yes, HW 
> > > manufactures
> > >  live out of HW sell. And yes, integration with products like ffmpeg 
> > > should benefit them (us).
> > > But they(us) do not sell software. The enablement of HW acceleration adds 
> > > features to ffmpeg project.  
> > > And we do it ourselves. We also intend to contribute more. So it is 
> > > mutually beneficial.  Isn't it?  
> > 
> > Well, don't worry too much.   
> 
> as an mplayer user who had to go looking to find a bunch of sdk headers
> and hope that the instructions written 2 years ago still point to a
> working URL, i feel a lot of pain in this thread.
> 
> svn has svn externals, where a svn checkout would pull from other svn
> repositories.
> 
> i am assuming git has the same thing? if so these headers could go in
> an external repo, but a ffmpeg git pull would pull them down? are there
> any objections to that ?
> 
> that would cut down on our objections and maintainership and git
> history concerns... i think? so long as its easy for non amd users to
> flip a config switch to disable pulling those amd headers down.

The ffmpeg repository is for the ffmpeg code, it's not a meta build
system.

But anyone is free to propose a repository with a script that
automatically pulls in most dependencies and builds ffmpeg. There are
actually a lot of those around for various software, but if you feel
like having an "official" one would improve the situation, go ahead.

Regarding non-working URLs, that can happen with external repositories
too, of course. For important enough stuff we could host them alongside
the ffmpeg repository, and we could indeed create a "vendor-sdks" git
repository, that would contain AMD, nvidia, and avisynth headers.

The point is that none of this should clutter the ffmpeg repo itself.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Compn]

On Wed, 29 Nov 2017 16:16:12 +0100, Paul B Mahol 
wrote:

> On 11/29/17, Carl Eugen Hoyos  wrote:
> > 2017-11-29 15:58 GMT+01:00 wm4 :
> >
> >> Well, don't worry too much. People like him are, as some would say,
> >> toxic members of the community. Frequent drama and flame wars happen.
> >> (And here's where I wished ffmpeg were a properly managed project.)
> >
> > Look who's talking!
> >
> > Given that you started a fork of FFmpeg repeating ancient lies
> > and stating you don't support FFmpeg anymore:
> > Why do you post here?
> 
> Because he like to argue with toxic people like you.

carl, wm4 and paul please ignore flames. please?

no reason to continue these flames and not on the mailing list
for sure.

nicolas is entitled to his opinion and licensing choices. no single dev
speaks for the entire project.

wm4 is entitled to fork whatever open source project he wants, and hes
welcome to post here and review patches and be a developer.

carl you dont have to respond to every aggressive post. nor do you have
to attack people.

paul and wm4 please stop insulting developers and calling them names.

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

Re: [FFmpeg-devel] AMD external header

[Hendrik Leppkes]

On Wed, Nov 29, 2017 at 4:07 PM, Carl Eugen Hoyos  wrote:
> 2017-11-29 15:58 GMT+01:00 wm4 :
>
>> Well, don't worry too much. People like him are, as some would say,
>> toxic members of the community. Frequent drama and flame wars happen.
>> (And here's where I wished ffmpeg were a properly managed project.)
>
> Look who's talking!
>
> Given that you started a fork of FFmpeg [...] Why do you post here?

Forking is an integral part of open-source development. Everytime you
clone a repository and develop in it, you're already forking.
Claiming that this should exclude anyone from contributing back to the
upstream project goes against every fundamental concept that
open-source is all about.

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

[FFmpeg-devel] [PATCH v2 1/2] avformat/hlsenc: Refactored 'get_int_from_double' function to allow reuse

[Karthick J]

From: Karthick Jeyapal 

---
 libavformat/hlsenc.c  | 7 +--
 libavformat/hlsplaylist.h | 5 +
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index f63b08d..cdfbf45 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -203,11 +203,6 @@ typedef struct HLSContext {
 int http_persistent;
 } HLSContext;
 
-static int get_int_from_double(double val)
-{
-return (int)((val - (int)val) >= 0.001) ? (int)(val + 1) : (int)val;
-}
-
 static int mkdir_p(const char *path) {
 int ret = 0;
 char *temp = av_strdup(path);
@@ -1211,7 +1206,7 @@ static int hls_window(AVFormatContext *s, int last, 
VariantStream *vs)
 
 for (en = vs->segments; en; en = en->next) {
 if (target_duration <= en->duration)
-target_duration = get_int_from_double(en->duration);
+target_duration = hls_get_int_from_double(en->duration);
 }
 
 vs->discontinuity_set = 0;
diff --git a/libavformat/hlsplaylist.h b/libavformat/hlsplaylist.h
index fd36c7e..68ef8d4 100644
--- a/libavformat/hlsplaylist.h
+++ b/libavformat/hlsplaylist.h
@@ -32,6 +32,11 @@ typedef enum {
 PLAYLIST_TYPE_NB,
 } PlaylistType;
 
+static inline int hls_get_int_from_double(double val)
+{
+return (int)((val - (int)val) >= 0.001) ? (int)(val + 1) : (int)val;
+}
+
 void ff_hls_write_playlist_version(AVIOContext *out, int version);
 void ff_hls_write_stream_info(AVStream *st, AVIOContext *out,
   int bandwidth, char *filename);
-- 
1.9.1

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

[FFmpeg-devel] [PATCH v2 2/2] avformat/dashenc: Option to generate hls playlist as well

[Karthick J]

This is to take full advantage of Common Media Application Format.
Now server can generate one content and serve both HLS and DASH players.
---
 doc/muxers.texi   |   3 ++
 libavformat/Makefile  |   2 +-
 libavformat/dashenc.c | 110 +++---
 3 files changed, 108 insertions(+), 7 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 8ec48c2..3d0c7bf 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -249,6 +249,9 @@ DASH-templated name to used for the media segments. Default 
is "chunk-stream$Rep
 URL of the page that will return the UTC timestamp in ISO format. Example: 
"https://time.akamai.com/?iso";
 @item -http_user_agent @var{user_agent}
 Override User-Agent field in HTTP header. 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 -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/Makefile b/libavformat/Makefile
index fd8b9f9..4bffdf2 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -135,7 +135,7 @@ OBJS-$(CONFIG_CONCAT_DEMUXER)+= concatdec.o
 OBJS-$(CONFIG_CRC_MUXER) += crcenc.o
 OBJS-$(CONFIG_DATA_DEMUXER)  += rawdec.o
 OBJS-$(CONFIG_DATA_MUXER)+= rawenc.o
-OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o
+OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o hlsplaylist.o
 OBJS-$(CONFIG_DASH_DEMUXER)  += dash.o dashdec.o
 OBJS-$(CONFIG_DAUD_DEMUXER)  += dauddec.o
 OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 0fee3cd..1783675 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -36,6 +36,7 @@
 #include "avc.h"
 #include "avformat.h"
 #include "avio_internal.h"
+#include "hlsplaylist.h"
 #include "internal.h"
 #include "isom.h"
 #include "os_support.h"
@@ -101,6 +102,8 @@ typedef struct DASHContext {
 const char *media_seg_name;
 const char *utc_timing_url;
 const char *user_agent;
+int hls_playlist;
+int master_playlist_created;
 } DASHContext;
 
 static struct codec_string {
@@ -217,6 +220,14 @@ static void set_http_options(AVDictionary **options, 
DASHContext *c)
 av_dict_set(options, "user_agent", c->user_agent, 0);
 }
 
+static void get_hls_playlist_name(char *playlist_name, int string_size,
+  const char *base_url, int id) {
+if (base_url)
+snprintf(playlist_name, string_size, "%smedia_%d.m3u8", base_url, id);
+else
+snprintf(playlist_name, string_size, "media_%d.m3u8", id);
+}
+
 static int flush_init_segment(AVFormatContext *s, OutputStream *os)
 {
 DASHContext *c = s->priv_data;
@@ -262,7 +273,8 @@ static void dash_free(AVFormatContext *s)
 av_freep(&c->streams);
 }
 
-static void output_segment_list(OutputStream *os, AVIOContext *out, 
DASHContext *c)
+static void output_segment_list(OutputStream *os, AVIOContext *out, 
DASHContext *c,
+int representation_id, int final)
 {
 int i, start_index = 0, start_number = 1;
 if (c->window_size) {
@@ -322,6 +334,55 @@ static void output_segment_list(OutputStream *os, 
AVIOContext *out, DASHContext
 }
 avio_printf(out, "\t\t\t\t\n");
 }
+if (c->hls_playlist && start_index < os->nb_segments)
+{
+int timescale = os->ctx->streams[0]->time_base.den;
+char temp_filename_hls[1024];
+char filename_hls[1024];
+AVIOContext *out_hls = NULL;
+AVDictionary *http_opts = NULL;
+int target_duration = 0;
+const char *proto = avio_find_protocol_name(c->dirname);
+int use_rename = proto && !strcmp(proto, "file");
+
+get_hls_playlist_name(filename_hls, sizeof(filename_hls),
+  c->dirname, representation_id);
+
+snprintf(temp_filename_hls, sizeof(temp_filename_hls), use_rename ? 
"%s.tmp" : "%s", filename_hls);
+
+set_http_options(&http_opts, c);
+avio_open2(&out_hls, temp_filename_hls, AVIO_FLAG_WRITE, NULL, 
&http_opts);
+av_dict_free(&http_opts);
+for (i = start_index; i < os->nb_segments; i++) {
+Segment *seg = os->segments[i];
+double duration = (double) seg->duration / timescale;
+if (target_duration <= duration)
+target_duration = hls_get_int_from_double(duration);
+}
+
+ff_hls_write_playlist_header(out_hls, 6, -1, target_duration,
+ start_number, PLAYLIST_TYPE_NONE);
+
+   

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: November 29, 2017 10:16 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] AMD external header
> 
> On 11/29/17, Carl Eugen Hoyos  wrote:
> > 2017-11-29 15:58 GMT+01:00 wm4 :
> >
> >> Well, don't worry too much. People like him are, as some would say,
> >> toxic members of the community. Frequent drama and flame wars
> happen.
> >> (And here's where I wished ffmpeg were a properly managed project.)
> >
> > Look who's talking!
> >
> > Given that you started a fork of FFmpeg repeating ancient lies and
> > stating you don't support FFmpeg anymore:
> > Why do you post here?
> 
> Because he like to argue with toxic people like you.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Hi,
This conversation is very entertaining but leads us nowhere. 
May I suggest to go down to business of enabling HW encoders by default?
Yesterday Mark submitted the initial implementation and I really want 
to thank him for his mentoring and participation - it was very useful. 
The submission doesn't have AMD header so AMD encoder is off in any default 
build.
I counted responses to my posts and found six people are for the default 
enabling 
of HW blocks one way or another: by including headers or pulling them out 
automatically using git (I guess via submodules?). 
Two people want to remove external headers and disable default HW acceleration. 
Question is: how to move forward on practical terms? I really don’t know how 
this team makes such decisions.
Or maybe it is impasse case and  all want to keep things the way they are today?
Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/dashenc: Option to generate hls playlist as well

[Jeyapal, Karthick]

Please ignore the below patch and use v2.
Sorry for the inconvenience. 

Regards,
Karthick

On 11/29/17, 8:47 PM, "Karthick J"  wrote:

This is to take full advantage of Common Media Application Format.
Now server can generate one content and serve both HLS and DASH players.
---
 doc/muxers.texi   |   3 ++
 libavformat/Makefile  |   2 +-
 libavformat/dashenc.c | 103 --
 3 files changed, 103 insertions(+), 5 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 8ec48c2..3d0c7bf 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -249,6 +249,9 @@ DASH-templated name to used for the media segments. Default 
is "chunk-stream$Rep
 URL of the page that will return the UTC timestamp in ISO format. Example: 
"https://time.akamai.com/?iso";
 @item -http_user_agent @var{user_agent}
 Override User-Agent field in HTTP header. 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 -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/Makefile b/libavformat/Makefile
index fd8b9f9..4bffdf2 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -135,7 +135,7 @@ OBJS-$(CONFIG_CONCAT_DEMUXER)+= concatdec.o
 OBJS-$(CONFIG_CRC_MUXER) += crcenc.o
 OBJS-$(CONFIG_DATA_DEMUXER)  += rawdec.o
 OBJS-$(CONFIG_DATA_MUXER)+= rawenc.o
-OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o
+OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o hlsplaylist.o
 OBJS-$(CONFIG_DASH_DEMUXER)  += dash.o dashdec.o
 OBJS-$(CONFIG_DAUD_DEMUXER)  += dauddec.o
 OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 0fee3cd..efc2012 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -36,6 +36,7 @@
 #include "avc.h"
 #include "avformat.h"
 #include "avio_internal.h"
+#include "hlsplaylist.h"
 #include "internal.h"
 #include "isom.h"
 #include "os_support.h"
@@ -101,6 +102,8 @@ typedef struct DASHContext {
 const char *media_seg_name;
 const char *utc_timing_url;
 const char *user_agent;
+int hls_playlist;
+int master_playlist_created;
 } DASHContext;
 
 static struct codec_string {
@@ -217,6 +220,14 @@ static void set_http_options(AVDictionary **options, 
DASHContext *c)
 av_dict_set(options, "user_agent", c->user_agent, 0);
 }
 
+static void get_hls_playlist_name(char *playlist_name, int string_size,
+  const char *base_url, int id) {
+if (base_url)
+snprintf(playlist_name, string_size, "%smedia_%d.m3u8", base_url, id);
+else
+snprintf(playlist_name, string_size, "media_%d.m3u8", id);
+}
+
 static int flush_init_segment(AVFormatContext *s, OutputStream *os)
 {
 DASHContext *c = s->priv_data;
@@ -262,7 +273,8 @@ static void dash_free(AVFormatContext *s)
 av_freep(&c->streams);
 }
 
-static void output_segment_list(OutputStream *os, AVIOContext *out, 
DASHContext *c)
+static void output_segment_list(OutputStream *os, AVIOContext *out, 
DASHContext *c,
+int representation_id, int final)
 {
 int i, start_index = 0, start_number = 1;
 if (c->window_size) {
@@ -322,6 +334,55 @@ static void output_segment_list(OutputStream *os, 
AVIOContext *out, DASHContext
 }
 avio_printf(out, "\t\t\t\t\n");
 }
+if (c->hls_playlist && start_index < os->nb_segments)
+{
+int timescale = os->ctx->streams[0]->time_base.den;
+char temp_filename_hls[1024];
+char filename_hls[1024];
+AVIOContext *out_hls = NULL;
+AVDictionary *http_opts = NULL;
+int target_duration = 0;
+const char *proto = avio_find_protocol_name(c->dirname);
+int use_rename = proto && !strcmp(proto, "file");
+
+get_hls_playlist_name(filename_hls, sizeof(filename_hls),
+  c->dirname, representation_id);
+
+snprintf(temp_filename_hls, sizeof(temp_filename_hls), use_rename ? 
"%s.tmp" : "%s", filename_hls);
+
+set_http_options(&http_opts, c);
+avio_open2(&out_hls, temp_filename_hls, AVIO_FLAG_WRITE, NULL, 
&http_opts);
+av_dict_free(&http_opts);
+for (i = start_index; i < os->nb_segments; i++) {
+Segment *seg = os->segments[i];
+double duration = (double) seg->duration / timescale;
+if (target_duration <= duration)
+target_duration = hls_get_int_from_double(duration);
+}
+
+ff_hls_wr

Re: [FFmpeg-devel] AMD external header

[Compn]

On Wed, 29 Nov 2017 15:45:28 +, "Mironov, Mikhail"
 wrote:
> May I suggest to go down to business of enabling HW encoders by default?
> Yesterday Mark submitted the initial implementation and I really want 
> to thank him for his mentoring and participation - it was very useful. 
> Question is: how to move forward on practical terms? I really don’t know how 
> this team makes such decisions.
> Or maybe it is impasse case and  all want to keep things the way they are 
> today?

probably wait a few days until the maintainer of hwaccels can chime in,
possibly with some more reviews.

please be patient.

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

Re: [FFmpeg-devel] AMD external header

[wm4]

On Wed, 29 Nov 2017 15:45:28 +
"Mironov, Mikhail"  wrote:

> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Paul B Mahol
> > Sent: November 29, 2017 10:16 AM
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>  
> > Subject: Re: [FFmpeg-devel] AMD external header
> > 
> > On 11/29/17, Carl Eugen Hoyos  wrote:  
> > > 2017-11-29 15:58 GMT+01:00 wm4 :
> > >  
> > >> Well, don't worry too much. People like him are, as some would say,
> > >> toxic members of the community. Frequent drama and flame wars  
> > happen.  
> > >> (And here's where I wished ffmpeg were a properly managed project.)  
> > >
> > > Look who's talking!
> > >
> > > Given that you started a fork of FFmpeg repeating ancient lies and
> > > stating you don't support FFmpeg anymore:
> > > Why do you post here?  
> > 
> > Because he like to argue with toxic people like you.
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel  
> 
> Hi,
> This conversation is very entertaining but leads us nowhere. 
> May I suggest to go down to business of enabling HW encoders by default?
> Yesterday Mark submitted the initial implementation and I really want 
> to thank him for his mentoring and participation - it was very useful. 
> The submission doesn't have AMD header so AMD encoder is off in any default 
> build.
> I counted responses to my posts and found six people are for the default 
> enabling 
> of HW blocks one way or another: by including headers or pulling them out 
> automatically using git (I guess via submodules?). 
> Two people want to remove external headers and disable default HW 
> acceleration. 
> Question is: how to move forward on practical terms? I really don’t know how 
> this team makes such decisions.
> Or maybe it is impasse case and  all want to keep things the way they are 
> today?

We don't automatically check out git repos as part of the build
process. That means the user will have to get those headers to build
AMD support. AMD support could still be autodetected, and enabled if
the headers are available.

This is not different from how it works with Intel and vaapi/qsv, so I'd
say that's fair.

Do you agree with this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vp9_parser: don't split superframes into separate packets

[wm4]

We did this for the sake of the decoder. With the vp9 change, it's not
necessary anymore.
---
 libavcodec/vp9_parser.c   | 127 --
 libavformat/hlsplaylist.h |   4 +-
 2 files changed, 12 insertions(+), 119 deletions(-)

diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c
index 9900e7ab1f..9531f34a32 100644
--- a/libavcodec/vp9_parser.c
+++ b/libavcodec/vp9_parser.c
@@ -25,21 +25,19 @@
 #include "libavcodec/get_bits.h"
 #include "parser.h"
 
-typedef struct VP9ParseContext {
-int n_frames; // 1-8
-int size[8];
-int marker_size;
-int64_t pts;
-} VP9ParseContext;
-
-static int parse_frame(AVCodecParserContext *ctx, const uint8_t *buf, int size)
+static int parse(AVCodecParserContext *ctx,
+ AVCodecContext *avctx,
+ const uint8_t **out_data, int *out_size,
+ const uint8_t *data, int size)
 {
-VP9ParseContext *s = ctx->priv_data;
 GetBitContext gb;
-int res, profile, keyframe, invisible;
+int res, profile, keyframe;
 
-if ((res = init_get_bits8(&gb, buf, size)) < 0)
-return res;
+*out_data = data;
+*out_size = size;
+
+if ((res = init_get_bits8(&gb, data, size)) < 0)
+return size; // parsers can't return errors
 get_bits(&gb, 2); // frame marker
 profile  = get_bits1(&gb);
 profile |= get_bits1(&gb) << 1;
@@ -47,10 +45,8 @@ static int parse_frame(AVCodecParserContext *ctx, const 
uint8_t *buf, int size)
 
 if (get_bits1(&gb)) {
 keyframe = 0;
-invisible = 0;
 } else {
 keyframe  = !get_bits1(&gb);
-invisible = !get_bits1(&gb);
 }
 
 if (!keyframe) {
@@ -61,113 +57,10 @@ static int parse_frame(AVCodecParserContext *ctx, const 
uint8_t *buf, int size)
 ctx->key_frame = 1;
 }
 
-if (!invisible) {
-if (ctx->pts == AV_NOPTS_VALUE)
-ctx->pts = s->pts;
-s->pts = AV_NOPTS_VALUE;
-} else if (ctx->pts != AV_NOPTS_VALUE) {
-s->pts = ctx->pts;
-ctx->pts = AV_NOPTS_VALUE;
-}
-
-return 0;
-}
-
-static int parse(AVCodecParserContext *ctx,
- AVCodecContext *avctx,
- const uint8_t **out_data, int *out_size,
- const uint8_t *data, int size)
-{
-VP9ParseContext *s = ctx->priv_data;
-int full_size = size;
-int marker;
-
-if (size <= 0) {
-*out_size = 0;
-*out_data = data;
-
-return 0;
-}
-
-if (s->n_frames > 0) {
-int i;
-int size_sum = 0;
-
-for (i = 0; i < s->n_frames ;i++)
-size_sum += s->size[i];
-size_sum += s->marker_size;
-
-if (size_sum != size) {
-av_log(avctx, AV_LOG_ERROR, "Inconsistent input frame sizes %d 
%d\n",
-   size_sum, size);
-s->n_frames = 0;
-}
-}
-
-if (s->n_frames > 0) {
-*out_data = data;
-*out_size = s->size[--s->n_frames];
-parse_frame(ctx, *out_data, *out_size);
-
-return s->n_frames > 0 ? *out_size : size /* i.e. include idx tail */;
-}
-
-marker = data[size - 1];
-if ((marker & 0xe0) == 0xc0) {
-int nbytes = 1 + ((marker >> 3) & 0x3);
-int n_frames = 1 + (marker & 0x7), idx_sz = 2 + n_frames * nbytes;
-
-if (size >= idx_sz && data[size - idx_sz] == marker) {
-const uint8_t *idx = data + size + 1 - idx_sz;
-int first = 1;
-
-switch (nbytes) {
-#define case_n(a, rd) \
-case a: \
-while (n_frames--) { \
-unsigned sz = rd; \
-idx += a; \
-if (sz == 0 || sz > size) { \
-s->n_frames = 0; \
-*out_size = size; \
-*out_data = data; \
-av_log(avctx, AV_LOG_ERROR, \
-   "Invalid superframe packet size: %u frame size: 
%d\n", \
-   sz, size); \
-return full_size; \
-} \
-if (first) { \
-first = 0; \
-*out_data = data; \
-*out_size = sz; \
-s->n_frames = n_frames; \
-} else { \
-s->size[n_frames] = sz; \
-} \
-data += sz; \
-size -= sz; \
-} \
-s->marker_size = size; \
-parse_frame(ctx, *out_data, *out_size); \
-return s->n_frames > 0 ? *out_size : full_size
-
-case_n(1, *idx);
-case_n(2, AV_RL16(idx));
-case_n(3, AV_RL24(idx));
-case_n(4, AV_RL32(idx));
-}
-}
-}
-
-*out_data = data;
-*out_size = size;
-parse_frame(ctx, data, size);
-
 return size;
 }
 
 AVCo

Re: [FFmpeg-devel] AMD external header

[Pavel Koshevoy]

On Tue, Nov 28, 2017 at 12:47 AM, Tobias Rapp  wrote:
> On 27.11.2017 17:14, Pavel Koshevoy wrote:



>> Personally, I would prefer if the bundled external headers were
>> installed together with ffmpeg public headers (so nvenc/cuda/etc...
>> weren't simply private headers within ffmpeg).  There are some nvenc
>> APIs I need to query hardware capabilities to avoid setting nvenc
>> codec parameters that would cause the codec to fail to initialize via
>> ffmpeg apis.  Given that ffmpeg already includes the headers that
>> declare those APIs I've been able to use them without installing nvenc
>> SDK separately, but since they are private headers in the ffmpeg
>> source tree it feels dirty to do that.
>
>
> Your use-case looks like an argument for moving the external headers into
> some separate repository. Not that I personally care much about bundling or
> not bundling. To me the more important question seems to be whether to
> auto-enable the encoders/decoders that depend on the external headers and
> libraries or not.


Yeah, that would be cleaner, but it does bring up the maintenance
burden that Nicolas has mentioned.  As long as the headers are in the
ffmpeg tree -- the maintenance burden is on ffmpeg.  When the headers
are moved to an external repo it would not necessarily be an ffmpeg
projects maintenance burden, but then who should be maintaining it?
The vendor?

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

Re: [FFmpeg-devel] AMD external header

[wm4]

On Wed, 29 Nov 2017 09:09:14 -0700
Pavel Koshevoy  wrote:

> On Tue, Nov 28, 2017 at 12:47 AM, Tobias Rapp  wrote:
> > On 27.11.2017 17:14, Pavel Koshevoy wrote:  
> 
> 
> 
> >> Personally, I would prefer if the bundled external headers were
> >> installed together with ffmpeg public headers (so nvenc/cuda/etc...
> >> weren't simply private headers within ffmpeg).  There are some nvenc
> >> APIs I need to query hardware capabilities to avoid setting nvenc
> >> codec parameters that would cause the codec to fail to initialize via
> >> ffmpeg apis.  Given that ffmpeg already includes the headers that
> >> declare those APIs I've been able to use them without installing nvenc
> >> SDK separately, but since they are private headers in the ffmpeg
> >> source tree it feels dirty to do that.  
> >
> >
> > Your use-case looks like an argument for moving the external headers into
> > some separate repository. Not that I personally care much about bundling or
> > not bundling. To me the more important question seems to be whether to
> > auto-enable the encoders/decoders that depend on the external headers and
> > libraries or not.  
> 
> 
> Yeah, that would be cleaner, but it does bring up the maintenance
> burden that Nicolas has mentioned.  As long as the headers are in the
> ffmpeg tree -- the maintenance burden is on ffmpeg.  When the headers
> are moved to an external repo it would not necessarily be an ffmpeg
> projects maintenance burden, but then who should be maintaining it?
> The vendor?

Generally we should encourage the vendor to maintain such things.

I think what really needs to be discussed in a broader context are
patch-and-run code dumps. It can't be right that someone can get
complex patches merged and then disappear, and then _we_ have to put
lots of effort into not breaking it. That's true for all kinds of
contribution, including non-company ones.

What really irks me is that nvidia is not giving us any support for
supporting their stuff. AFAIK the current headers are the last MIT
licensed ones, and future headers are closed? And there's no API
documentation or help either. But most of that code written was done by
ffmpeg developers, who have some commitment to maintain it.

Seems to be getting quite offtopic though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vp9: use superframe split BSF

[wm4]

On Wed, 29 Nov 2017 16:24:42 +0100
wm4  wrote:

> webm usually has invisible superframes merged with normal frames.
> (vpxenc muxes them in this form, which is evidence enough that this is
> the standard webm packet format. It's rather unclear whether ffmpeg is
> even allowed to remux them with split packets.)
> 
> The vp9 decoder needs them to be in separate packets for multithreading
> to work. Add the BSF to the decoder, so the conversion happens
> automatically.
> 
> This contains the important part of fa1749dd34c55fb9, which
> was apparently skipped in commit d417e95af76. This restores Libav API
> compatibility.
> ---

Both patches approved on IRC, and pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Hendrik Leppkes]

On Wed, Nov 29, 2017 at 5:24 PM, wm4  wrote:
>
> What really irks me is that nvidia is not giving us any support for
> supporting their stuff. AFAIK the current headers are the last MIT
> licensed ones, and future headers are closed?

No, thats not how it is. They re-licensed the video related headers to
be usable some time ago, and there have been no signs of this changing
back again.
Only the actual CUDA headers are still closed, but we don't need them.

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

Re: [FFmpeg-devel] AMD external header

[wm4]

On Wed, 29 Nov 2017 17:27:01 +0100
Hendrik Leppkes  wrote:

> On Wed, Nov 29, 2017 at 5:24 PM, wm4  wrote:
> >
> > What really irks me is that nvidia is not giving us any support for
> > supporting their stuff. AFAIK the current headers are the last MIT
> > licensed ones, and future headers are closed?  
> 
> No, thats not how it is. They re-licensed the video related headers to
> be usable some time ago, and there have been no signs of this changing
> back again.
> Only the actual CUDA headers are still closed, but we don't need them.

Oh, great. Then why do we do that at all? We'd only need have some code
for dynamically loading actual functions, but this would be way less
code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] lavfi/avfilter: simplify filter registration

[Michael Niedermayer]

On Wed, Nov 29, 2017 at 03:51:34AM +, Rostislav Pehlivanov wrote:
> On 28 November 2017 at 20:23, Michael Niedermayer 
> wrote:
> 
> > On Mon, Nov 27, 2017 at 04:30:19AM +, Rostislav Pehlivanov wrote:
> > > Atomics were entirely pointless and did nothing but slow and complicate
> > > the process down. This could be improved further still but the main
> > > objective of this commit is to simplify.
> > >
> > > Signed-off-by: Rostislav Pehlivanov 
> > > ---
> > >  libavfilter/avfilter.c | 8 +---
> > >  1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > *_register() can be called by the user app in a unsyncronized way
> > for example from a module like vlc used AFAIK.
> > or from libs loaded by an application which use libavfilter or other
> > internally.
> >
> > These registration functions should stay thread safe
> >
> >
> > [...]
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Those who would give up essential Liberty, to purchase a little
> > temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> >
> What variable actually needs to be protected?

The linked list of registered "entities"
That is if the addition is not synchronized by some means, an atomic
exchange a mutex or something then a race can generally occur
and only one addition might succeed or something else might get
entangled

This is in practical terms a very unlikely event to occur of course

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

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] AMD external header

[Tobias Rapp]

On 28.11.2017 10:25, Timo Rothenpieler wrote:
Your use-case looks like an argument for moving the external headers 
into some separate repository. Not that I personally care much about 
bundling or not bundling. To me the more important question seems to 
be whether to auto-enable the encoders/decoders that depend on the 
external headers and libraries or not.


At least nvenc will stay as auto-enable even with out-of-tree headers, 
except that it will obviously check if it has the required headers 
available.


What confuses me is that libraries like libopus/libx264/... must be 
manually enabled while the library behind nvenc is auto-enabled.


Regards,
Tobias

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

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

Am 29.11.2017 um 17:40 schrieb wm4:

On Wed, 29 Nov 2017 17:27:01 +0100
Hendrik Leppkes  wrote:


On Wed, Nov 29, 2017 at 5:24 PM, wm4  wrote:


What really irks me is that nvidia is not giving us any support for
supporting their stuff. AFAIK the current headers are the last MIT
licensed ones, and future headers are closed?


No, thats not how it is. They re-licensed the video related headers to
be usable some time ago, and there have been no signs of this changing
back again.
Only the actual CUDA headers are still closed, but we don't need them.


Oh, great. Then why do we do that at all? We'd only need have some code
for dynamically loading actual functions, but this would be way less
code.


Because the headers are in an SDK you have to be an approved nvidia 
developer for to download it.
And they are also not useful without quite some modifications. The whole 
dynamic loading is made by me, not by nvidia.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[wm4]

On Wed, 29 Nov 2017 17:42:05 +0100
Timo Rothenpieler  wrote:

> Am 29.11.2017 um 17:40 schrieb wm4:
> > On Wed, 29 Nov 2017 17:27:01 +0100
> > Hendrik Leppkes  wrote:
> >   
> >> On Wed, Nov 29, 2017 at 5:24 PM, wm4  wrote:  
> >>>
> >>> What really irks me is that nvidia is not giving us any support for
> >>> supporting their stuff. AFAIK the current headers are the last MIT
> >>> licensed ones, and future headers are closed?  
> >>
> >> No, thats not how it is. They re-licensed the video related headers to
> >> be usable some time ago, and there have been no signs of this changing
> >> back again.
> >> Only the actual CUDA headers are still closed, but we don't need them.  
> > 
> > Oh, great. Then why do we do that at all? We'd only need have some code
> > for dynamically loading actual functions, but this would be way less
> > code.  
> 
> Because the headers are in an SDK you have to be an approved nvidia 
> developer for to download it.

Oh, how evil.

> And they are also not useful without quite some modifications. The whole 
> dynamic loading is made by me, not by nvidia.
> 

Yeah, I understand that. But the function loading should make only a
small part of it, and could just be a normal source file. (We do
ad-hoc function loading for a lot of other stuff too.)

Then we could depend on external, unmodified SDK headers, which someone
could extract to a git repo, to avoid going through nvidia's broken
procedures.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

Yeah, I understand that. But the function loading should make only a
small part of it, and could just be a normal source file. (We do
ad-hoc function loading for a lot of other stuff too.)

Then we could depend on external, unmodified SDK headers, which someone
could extract to a git repo, to avoid going through nvidia's broken
procedures.


The plain headers are also modified, because nvidia did not take a lot 
of care about a lot of compilers ffmpeg supports (I fixed various 
anonymous structs that failed to compile with for example older gcc).
It also uses types whose size varies between msvc and gcc, which I fixed 
to always use the right size on the right OS.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of wm4
> Sent: November 29, 2017 11:06 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] AMD external header
> 
> On Wed, 29 Nov 2017 15:45:28 +
> "Mironov, Mikhail"  wrote:
> 
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > Behalf Of Paul B Mahol
> > > Sent: November 29, 2017 10:16 AM
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] AMD external header
> > >
> > > On 11/29/17, Carl Eugen Hoyos  wrote:
> > > > 2017-11-29 15:58 GMT+01:00 wm4 :
> > > >
> > > >> Well, don't worry too much. People like him are, as some would
> > > >> say, toxic members of the community. Frequent drama and flame
> > > >> wars
> > > happen.
> > > >> (And here's where I wished ffmpeg were a properly managed
> > > >> project.)
> > > >
> > > > Look who's talking!
> > > >
> > > > Given that you started a fork of FFmpeg repeating ancient lies and
> > > > stating you don't support FFmpeg anymore:
> > > > Why do you post here?
> > >
> > > Because he like to argue with toxic people like you.
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > Hi,
> > This conversation is very entertaining but leads us nowhere.
> > May I suggest to go down to business of enabling HW encoders by default?
> > Yesterday Mark submitted the initial implementation and I really want
> > to thank him for his mentoring and participation - it was very useful.
> > The submission doesn't have AMD header so AMD encoder is off in any
> default build.
> > I counted responses to my posts and found six people are for the
> > default enabling of HW blocks one way or another: by including headers
> > or pulling them out automatically using git (I guess via submodules?).
> > Two people want to remove external headers and disable default HW
> acceleration.
> > Question is: how to move forward on practical terms? I really don’t know
> how this team makes such decisions.
> > Or maybe it is impasse case and  all want to keep things the way they are
> today?
> 
> We don't automatically check out git repos as part of the build process. That
> means the user will have to get those headers to build AMD support. AMD
> support could still be autodetected, and enabled if the headers are available.

This was a suggestion in one of the posts, not my idea. I personally would 
prefer to include headers.

> 
> This is not different from how it works with Intel and vaapi/qsv, so I'd say
> that's fair.
> 
> Do you agree with this?

If NVidia headers moved to a separate repo - yes.

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

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> 
> It also should be made clear that nvidia does not somehow receive preferred
> treatment over other vendors.

Respectfully, but it does by inaction.
Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add fillborders filter

[Nicolas George]

Paul B Mahol (2017-11-29):
> Nope.

Well, then learn how to write documentation.

Regards,

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

Re: [FFmpeg-devel] AMD external header

[wm4]

On Wed, 29 Nov 2017 18:10:49 +
"Mironov, Mikhail"  wrote:

> > 
> > It also should be made clear that nvidia does not somehow receive preferred
> > treatment over other vendors.  
> 
> Respectfully, but it does by inaction.
> Thanks,
> Mikhail

Not really. Intel has the best hardware transcoding support (on all
platforms) in ffmpeg. And they don't have any in-tree headers. These
are really different issues.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/vf_tile: add init_padding option

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi  |  4 
 libavfilter/vf_tile.c | 12 +++-
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 4a4efc70c8..4eb302448b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14637,6 +14637,10 @@ is "black".
 @item overlap
 Set the number of frames to overlap when tiling several successive frames 
together.
 The value must be between @code{0} and @var{nb_frames - 1}.
+
+@item init_padding
+Set the number of input frames to initially pad before displaying first output 
frame.
+The value must be between @code{0} and @var{nb_frames - 1}.
 @end table
 
 @subsection Examples
diff --git a/libavfilter/vf_tile.c b/libavfilter/vf_tile.c
index 7717ce12e7..c347939cce 100644
--- a/libavfilter/vf_tile.c
+++ b/libavfilter/vf_tile.c
@@ -38,6 +38,7 @@ typedef struct TileContext {
 unsigned margin;
 unsigned padding;
 unsigned overlap;
+unsigned init_padding;
 unsigned current;
 unsigned nb_frames;
 FFDrawContext draw;
@@ -62,6 +63,8 @@ static const AVOption tile_options[] = {
 { "color",   "set the color of the unused area", OFFSET(rgba_color), 
AV_OPT_TYPE_COLOR, {.str = "black"}, .flags = FLAGS },
 { "overlap", "set how many frames to overlap for each render", 
OFFSET(overlap),
 AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS },
+{ "init_padding", " set how many frames to initially pad", 
OFFSET(init_padding),
+AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS },
 { NULL }
 };
 
@@ -99,6 +102,12 @@ static av_cold int init(AVFilterContext *ctx)
 tile->overlap = tile->nb_frames - 1;
 }
 
+if (tile->init_padding >= tile->nb_frames) {
+av_log(ctx, AV_LOG_WARNING, "init_padding must be less than %d\n", 
tile->nb_frames);
+} else {
+tile->current = tile->init_padding;
+}
+
 return 0;
 }
 
@@ -201,7 +210,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*picref)
 tile->out_ref->height = outlink->h;
 
 /* fill surface once for margin/padding */
-if (tile->margin || tile->padding)
+if (tile->margin || tile->padding ||
+(tile->init_padding != 0 && !tile->prev_out_ref))
 ff_fill_rectangle(&tile->draw, &tile->blank,
   tile->out_ref->data,
   tile->out_ref->linesize,
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_tile: add init_padding option

[Nicolas George]

Paul B Mahol (2017-11-29):
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi  |  4 
>  libavfilter/vf_tile.c | 12 +++-
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 4a4efc70c8..4eb302448b 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -14637,6 +14637,10 @@ is "black".
>  @item overlap
>  Set the number of frames to overlap when tiling several successive frames 
> together.
>  The value must be between @code{0} and @var{nb_frames - 1}.
> +
> +@item init_padding

> +Set the number of input frames to initially pad before displaying first 
> output frame.

Even knowing what it is supposed to mean I cannot parse this sentence.

> +The value must be between @code{0} and @var{nb_frames - 1}.
>  @end table
>  
>  @subsection Examples
> diff --git a/libavfilter/vf_tile.c b/libavfilter/vf_tile.c
> index 7717ce12e7..c347939cce 100644
> --- a/libavfilter/vf_tile.c
> +++ b/libavfilter/vf_tile.c
> @@ -38,6 +38,7 @@ typedef struct TileContext {
>  unsigned margin;
>  unsigned padding;
>  unsigned overlap;
> +unsigned init_padding;
>  unsigned current;
>  unsigned nb_frames;
>  FFDrawContext draw;
> @@ -62,6 +63,8 @@ static const AVOption tile_options[] = {
>  { "color",   "set the color of the unused area", OFFSET(rgba_color), 
> AV_OPT_TYPE_COLOR, {.str = "black"}, .flags = FLAGS },
>  { "overlap", "set how many frames to overlap for each render", 
> OFFSET(overlap),
>  AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS },
> +{ "init_padding", " set how many frames to initially pad", 
> OFFSET(init_padding),
> +AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS },
>  { NULL }
>  };
>  
> @@ -99,6 +102,12 @@ static av_cold int init(AVFilterContext *ctx)
>  tile->overlap = tile->nb_frames - 1;
>  }
>  
> +if (tile->init_padding >= tile->nb_frames) {
> +av_log(ctx, AV_LOG_WARNING, "init_padding must be less than %d\n", 
> tile->nb_frames);
> +} else {
> +tile->current = tile->init_padding;
> +}
> +
>  return 0;
>  }
>  
> @@ -201,7 +210,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
> *picref)
>  tile->out_ref->height = outlink->h;
>  
>  /* fill surface once for margin/padding */
> -if (tile->margin || tile->padding)
> +if (tile->margin || tile->padding ||

> +(tile->init_padding != 0 && !tile->prev_out_ref))

Incorrect, prev_out_ref is only set if overlap is non-zero.

>  ff_fill_rectangle(&tile->draw, &tile->blank,
>tile->out_ref->data,
>tile->out_ref->linesize,

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] avfilter: add fillborders filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  40 +++
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_fillborders.c | 277 +++
 4 files changed, 319 insertions(+)
 create mode 100644 libavfilter/vf_fillborders.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 4a4efc70c8..1b115c2cb5 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8610,6 +8610,46 @@ framework.
 
 It does not take parameters.
 
+@section fillborders
+
+Fill borders of the input video, without changing video stream dimensions.
+Sometimes video can have garbage at the four edges and you may not want to
+crop video input to keep size multiple of some number.
+
+This filter accepts the following options:
+
+@table @option
+@item left
+Number of pixels to fill from left border.
+
+@item right
+Number of pixels to fill from right border.
+
+@item top
+Number of pixels to fill from top border.
+
+@item bottom
+Number of pixels to fill from bottom border.
+
+@item mode
+Set fill mode.
+
+It accepts the following values:
+@table @samp
+@item smear
+fill pixels using outermost pixels
+
+@item mirror
+fill pixels using mirroring
+
+@item fixed
+fill pixels with constant value
+@end table
+
+@item color
+Set color for pixels in fixed mode. Defauls is @var{black}.
+@end table
+
 @section find_rect
 
 Find a rectangular object
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 0b77d7a01f..1c0cc1da80 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -192,6 +192,7 @@ OBJS-$(CONFIG_FIELD_FILTER)  += vf_field.o
 OBJS-$(CONFIG_FIELDHINT_FILTER)  += vf_fieldhint.o
 OBJS-$(CONFIG_FIELDMATCH_FILTER) += vf_fieldmatch.o
 OBJS-$(CONFIG_FIELDORDER_FILTER) += vf_fieldorder.o
+OBJS-$(CONFIG_FILLBORDERS_FILTER)+= vf_fillborders.o
 OBJS-$(CONFIG_FIND_RECT_FILTER)  += vf_find_rect.o lavfutils.o
 OBJS-$(CONFIG_FLOODFILL_FILTER)  += vf_floodfill.o
 OBJS-$(CONFIG_FORMAT_FILTER) += vf_format.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 4c834f7381..fc212e58db 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -202,6 +202,7 @@ static void register_all(void)
 REGISTER_FILTER(FIELDHINT,  fieldhint,  vf);
 REGISTER_FILTER(FIELDMATCH, fieldmatch, vf);
 REGISTER_FILTER(FIELDORDER, fieldorder, vf);
+REGISTER_FILTER(FILLBORDERS,fillborders,vf);
 REGISTER_FILTER(FIND_RECT,  find_rect,  vf);
 REGISTER_FILTER(FLOODFILL,  floodfill,  vf);
 REGISTER_FILTER(FORMAT, format, vf);
diff --git a/libavfilter/vf_fillborders.c b/libavfilter/vf_fillborders.c
new file mode 100644
index 00..1254f2344b
--- /dev/null
+++ b/libavfilter/vf_fillborders.c
@@ -0,0 +1,277 @@
+/*
+ * Copyright (c) 2017 Paul B Mahol
+ *
+ * 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
+ */
+
+#include "libavutil/colorspace.h"
+#include "libavutil/common.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+enum { Y, U, V, A };
+enum { R, G, B };
+
+enum FillMode { FM_SMEAR, FM_MIRROR, FM_FIXED, FM_NB_MODES };
+
+typedef struct Borders {
+int left, right, top, bottom;
+} Borders;
+
+typedef struct FillBordersContext {
+const AVClass *class;
+int left, right, top, bottom;
+int mode;
+
+int nb_planes;
+Borders borders[4];
+int planewidth[4];
+int planeheight[4];
+uint8_t fill[4];
+uint8_t yuv_color[4];
+uint8_t rgba_color[4];
+
+void (*fillborders)(struct FillBordersContext *s, AVFrame *frame);
+} FillBordersContext;
+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat pix_fmts[] = {
+AV_PIX_FMT_YUV444P,  AV_PIX_FMT_YUV422P,  AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUV411P,  AV_PIX_FMT_YUV410P,
+AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P,
+AV_PIX_FMT_YUV440P,  AV_PIX_FMT_YUVJ440P,
+AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA444P,
+AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,
+AV

Re: [FFmpeg-devel] [PATCH 5/6] Add suppoort for using libklvanc from within decklink capture module

[Devin Heitmueller]

Hello Derek,

Comments inline.

>> 
>> +afd[0] = pkt->hdr.payload[0] >> 3;
>> +if (av_packet_add_side_data(cb_ctx->pkt, AV_PKT_DATA_AFD, afd, 1) < 0)
>> +av_free(afd);
> 
> Is there a reason we shouldn't fail hard here?

Not really.  The parser will log an error if the callback returns a nonzero 
value, but beyond the return value isn’t actively used.  That said, no 
objection to having it return -1 for clarity.
> 
>> +static struct klvanc_callbacks_s callbacks =
>> +{
>> +.afd   = cb_AFD,
>> +.eia_708b  = cb_EIA_708B,
>> +.eia_608   = NULL,
>> +.scte_104  = NULL,
>> +.all   = NULL,
>> +.kl_i64le_counter  = NULL,
>> +};
> 
> I thought C++ didn't have designated initializers? Maybe my C++ is rusty.

Clang didn’t complain, and g++ only complains if you put them in a non-default 
order (i.e. "non-trivial designated initializers not supported").  The 
designated initializers improve readability but aren’t required (since already 
put the items in the default order).  If there’s a portability concern then I 
can get rid of them.

> 
> Same for other occurrences.

I’m sorry, but what other occurrences?  I don’t see any other instances in this 
patch where designated initializers are used — or did I misunderstand your 
comment?
> 
>> +/* Convert the vanc line from V210 to CrCB422, then vanc parse it */
>> +
>> +/* We need two kinds of type pointers into the source vbi buffer */
>> +/* TODO: What the hell is this, two ptrs? */
>> +const uint32_t *src = (const uint32_t *)buf;
> 
> Is buf guaranteed to be properly aligned for this, or will cause aliasing 
> problems?

Hmm, good question.  The start of each line will always be aligned on a 48 byte 
boundary as a result of how the decklink module manages it’s buffers, but I 
agree that this block of code is a bit messy and needs some cleanup (hence the 
TODO).

I suspect the original routine was cribbed from OBE (with portions derived from 
ffmpeg’s v210dec), and the assembly version of the same function probably isn’t 
as forgiving (although libklvanc doesn’t provide an assembly implementation as 
this routine isn’t particularly performance sensitive).

> 
>> +vanc_ctx->callback_context = &cb_ctx;
>> +int ret = klvanc_packet_parse(vanc_ctx, lineNr, decoded_words, 
>> sizeof(decoded_words) / (sizeof(unsigned short)));
> 
> Nobody should be typing 'short' in any C/C++ code in 2017..

Will fix.

> 
>> +if (ret < 0) {
>> +/* No VANC on this line */
>> +}
> 
> Huh?

The parser takes in the complete VANC lines, but it’s possible that those lines 
are blank and don’t contain any actual VANC packets.  That said, you’re right - 
a negative return should be treated as an error and the comment in question 
should only occur if the return value is zero (a positive return value is the 
number of packets parsed).  Will fix.

> 
>> +#if CONFIG_LIBKLVANC
>> +klvanc_handle_line(avctx, ctx->vanc_ctx,
>> +   buf, videoFrame->GetWidth(), 
>> i, &pkt);
>> +#else
> 
> No error checking possible?

Will fix.

> 
>> }
>> +
>> vanc->Release();
> 
> Stray change.

Will fix.

> 
>> +#if CONFIG_LIBKLVANC
>> +if (klvanc_context_create(&ctx->vanc_ctx) < 0) {
>> +av_log(avctx, AV_LOG_ERROR, "Cannot create VANC library context\n");
>> +} else {
>> +ctx->vanc_ctx->verbose = 0;
>> +ctx->vanc_ctx->callbacks = &callbacks;
>> +}
>> +#endif
> 
> Should fail hard, no?

Will fix.

Thanks for reviewing,

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

Re: [FFmpeg-devel] AMD external header

[Compn]

On Wed, 29 Nov 2017 18:06:46 +, "Mironov, Mikhail"
 wrote:

> This was a suggestion in one of the posts, not my idea. I personally would 
> prefer to include headers.

i also prefer including headers into ffmpeg. only for the big 3 intel
amd and nvidia... unless something else comes along i have no problem
with this. but its also not my call, just my personal opinion.

to make it easier on users who dont have to go around looking for sdk
and extracting headers and all that baloney.

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

Re: [FFmpeg-devel] [PATCH 5/6] Add suppoort for using libklvanc from within decklink capture module

[Devin Heitmueller]

Hello James,

Thanks for reviewing.

>> +afd[0] = pkt->hdr.payload[0] >> 3;
>> +if (av_packet_add_side_data(cb_ctx->pkt, AV_PKT_DATA_AFD, afd, 1) < 0)
>> +av_free(afd);
> 
> For this, av_packet_new_side_data() seems more adequate than av_malloc()
> + av_packet_add_side_data().
> 
> Also, you should propagate the errors av_packet_{add,new}_side_data return.

Good catch.  Yes, I will move to using av_packet_new_side_data() and fix the 
return.

Thanks,

Devin

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

[FFmpeg-devel] [PATCH] avfilter/vf_tile: add init_padding option

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi  |  5 +
 libavfilter/vf_tile.c | 16 +++-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 4a4efc70c8..ec37b9dcb8 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14637,6 +14637,11 @@ is "black".
 @item overlap
 Set the number of frames to overlap when tiling several successive frames 
together.
 The value must be between @code{0} and @var{nb_frames - 1}.
+
+@item init_padding
+Set the number of frames to initially be empty before displaying first output 
frame.
+This controls how soon will one get first output frame.
+The value must be between @code{0} and @var{nb_frames - 1}.
 @end table
 
 @subsection Examples
diff --git a/libavfilter/vf_tile.c b/libavfilter/vf_tile.c
index 7717ce12e7..924cfe77bb 100644
--- a/libavfilter/vf_tile.c
+++ b/libavfilter/vf_tile.c
@@ -38,6 +38,8 @@ typedef struct TileContext {
 unsigned margin;
 unsigned padding;
 unsigned overlap;
+unsigned init_padding;
+unsigned first_frame;
 unsigned current;
 unsigned nb_frames;
 FFDrawContext draw;
@@ -62,6 +64,8 @@ static const AVOption tile_options[] = {
 { "color",   "set the color of the unused area", OFFSET(rgba_color), 
AV_OPT_TYPE_COLOR, {.str = "black"}, .flags = FLAGS },
 { "overlap", "set how many frames to overlap for each render", 
OFFSET(overlap),
 AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS },
+{ "init_padding", " set how many frames to initially pad", 
OFFSET(init_padding),
+AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, FLAGS },
 { NULL }
 };
 
@@ -99,6 +103,13 @@ static av_cold int init(AVFilterContext *ctx)
 tile->overlap = tile->nb_frames - 1;
 }
 
+if (tile->init_padding >= tile->nb_frames) {
+av_log(ctx, AV_LOG_WARNING, "init_padding must be less than %d\n", 
tile->nb_frames);
+} else {
+tile->current = tile->init_padding;
+}
+tile->first_frame = 1;
+
 return 0;
 }
 
@@ -201,11 +212,14 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*picref)
 tile->out_ref->height = outlink->h;
 
 /* fill surface once for margin/padding */
-if (tile->margin || tile->padding)
+if (tile->margin || tile->padding ||
+(tile->init_padding != 0 && tile->first_frame))
 ff_fill_rectangle(&tile->draw, &tile->blank,
   tile->out_ref->data,
   tile->out_ref->linesize,
   0, 0, outlink->w, outlink->h);
+if (tile->first_frame)
+tile->first_frame = 0;
 }
 
 if (tile->prev_out_ref) {
-- 
2.11.0

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

Re: [FFmpeg-devel] [ogg] Respect AVERROR codes returned by ogg header parsing.

[Dale Curtis]

On Tue, Nov 28, 2017 at 4:32 PM, Michael Niedermayer  wrote:
>
>
> This breaks converting of this:
> ./ffmpeg -i bgc.sub.dub.ogm -vf subtitles=bgc.sub.dub.ogm -an  file.avi
>
> https://samples.ffmpeg.org/ogg/bgc.sub.dub.ogm
>
>
That's due to the vorbis parser returning AVERROR_INVALIDDATA here, with
pkt_type == 5 and priv->packet[0] == priv_packet[1] == null.
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/oggparsevorbis.c;h=65b1998a02d92d0fcaeb740d8f4523641502dbea;hb=HEAD#l319


Which were added in 2010 here:
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=73c44cb2869bfdbea829942eb35efa6d4c4e2f91

It seems that file has invalid vorbis streams if the check is to be
believed. What do you want to do here? Restrict this error behind
AV_EF_EXPLODE?

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

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Compn
> Sent: November 29, 2017 2:17 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] AMD external header
> 
> On Wed, 29 Nov 2017 18:06:46 +, "Mironov, Mikhail"
>  wrote:
> 
> > This was a suggestion in one of the posts, not my idea. I personally would
> prefer to include headers.
> 
> i also prefer including headers into ffmpeg. only for the big 3 intel amd and
> nvidia... unless something else comes along i have no problem with this. but
> its also not my call, just my personal opinion.
> 
> to make it easier on users who dont have to go around looking for sdk and
> extracting headers and all that baloney.
> 
> -compn
> 

Now we have seven people not counting me 😊
Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Nicolas George]

Mironov, Mikhail (2017-11-29):
> Now we have seven people not counting me

I suggest we weight this based on how often people voicing an opinion
need to run git grep.

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 5/6] Add suppoort for using libklvanc from within decklink capture module

[Derek Buitenhuis]

On 11/29/2017 7:17 PM, Devin Heitmueller wrote:
>> Is there a reason we shouldn't fail hard here?
> 
> Not really.  The parser will log an error if the callback returns a nonzero 
> value, but beyond the return value isn’t actively used.  That said, no 
> objection to having it return -1 for clarity.

I have no strong feelings either way.

>> I thought C++ didn't have designated initializers? Maybe my C++ is rusty.
> 
> Clang didn’t complain, and g++ only complains if you put them in a 
> non-default order (i.e. "non-trivial designated initializers not supported"). 
>  The designated initializers improve readability but aren’t required (since 
> already put the items in the default order).  If there’s a portability 
> concern then I can get rid of them.

The internet seems to claim it's a GNU extension. Will this code ever possibly
be built with something that isn't GCC or Clang?

>> Same for other occurrences.
> 
> I’m sorry, but what other occurrences?  I don’t see any other instances in 
> this patch where designated initializers are used — or did I misunderstand 
> your comment?

My mail must have got mangled while I was editing it. Ignore this, I think.

>> Is buf guaranteed to be properly aligned for this, or will cause aliasing 
>> problems?
> 
> Hmm, good question.  The start of each line will always be aligned on a 48 
> byte boundary as a result of how the decklink module manages it’s buffers, 
> but I agree that this block of code is a bit messy and needs some cleanup 
> (hence the TODO).

Is this aligment a guarantee by the module?

> I suspect the original routine was cribbed from OBE (with portions derived 
> from ffmpeg’s v210dec), and the assembly version of the same function 
> probably isn’t as forgiving (although libklvanc doesn’t provide an assembly 
> implementation as this routine isn’t particularly performance sensitive).

[...]

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

[FFmpeg-devel] [PATCH 0/2] Add pkg-config checks for twolame, openal

[Stephen Hutchinson]

TwoLAME and OpenAL both provide .pc files, so
add checks to allow pkg-config/pkgconf to
handle that.

I tried to keep the existing checks in place
instead of replacing them with the pkg-config
version.  Hopefully I set it up correctly
so the old checks aren't unreachable now.

Stephen Hutchinson (2):
  configure: add pkg-config detection for twolame
  configure: add pkg-config check for openal

 configure | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

-- 
2.14.1

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

[FFmpeg-devel] [PATCH 1/2] configure: add pkg-config detection for twolame

[Stephen Hutchinson]

---
 configure | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 4e7254eaeb..3c08125da3 100755
--- a/configure
+++ b/configure
@@ -5888,7 +5888,9 @@ enabled libssh&& require_pkg_config libssh 
libssh libssh/sftp.h sftp
 enabled libspeex  && require_pkg_config libspeex speex speex/speex.h 
speex_decoder_init
 enabled libtesseract  && require_pkg_config libtesseract tesseract 
tesseract/capi.h TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
-enabled libtwolame&& require libtwolame twolame.h twolame_init 
-ltwolame &&
+enabled libtwolame&& { check_pkg_config libtwolame "twolame >= 0.3.10" 
twolame.h twolame_init ||
+   require libtwolame twolame.h twolame_init 
-ltwolame &&
+   warn "using libtwolame without pkg-config"; } &&
  { check_lib libtwolame twolame.h 
twolame_encode_buffer_float32_interleaved -ltwolame ||
die "ERROR: libtwolame must be installed and 
version must be >= 0.3.10"; }
 enabled libv4l2   && require_pkg_config libv4l2 libv4l2 libv4l2.h 
v4l2_ioctl
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 2/2] configure: add pkg-config check for openal

[Stephen Hutchinson]

---
 configure | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 3c08125da3..141c8b742f 100755
--- a/configure
+++ b/configure
@@ -5952,11 +5952,13 @@ enabled mmal  && { check_lib mmal 
interface/mmal/mmal.h mmal_port_co
  check_lib mmal interface/mmal/mmal.h 
mmal_port_connect -lmmal_core -lmmal_util -lmmal_vc_client -lbcm_host; } ||
die "ERROR: mmal not found" &&
check_func_headers interface/mmal/mmal.h 
"MMAL_PARAMETER_VIDEO_MAX_NUM_CALLBACKS"; }
-enabled openal&& { { for al_extralibs in "${OPENAL_LIBS}" 
"-lopenal" "-lOpenAL32"; do
-   check_lib openal 'AL/al.h' alGetError 
"${al_extralibs}" && break; done } ||
-   die "ERROR: openal not found"; } &&
- { check_cpp_condition "AL/al.h" 
"defined(AL_VERSION_1_1)" ||
-   die "ERROR: openal must be installed and 
version must be 1.1 or compatible"; }
+enabled openal&& { check_pkg_config openal openal AL/al.h 
alGetError ||
+   { { for al_extralibs in "${OPENAL_LIBS}" 
"-lopenal" "-lOpenAL32"; do
+ check_lib openal 'AL/al.h' alGetError 
"${al_extralibs}" && break; done } &&
+ warn "using openal without pkg-config"; ||
+ die "ERROR: openal not found"; } &&
+   { check_cpp_condition "AL/al.h" 
"defined(AL_VERSION_1_1)" ||
+ die "ERROR: openal must be installed and 
version must be 1.1 or compatible"; } }
 enabled opencl&& { check_lib opencl OpenCL/cl.h 
clEnqueueNDRangeKernel -Wl,-framework,OpenCL ||
check_lib opencl CL/cl.h clEnqueueNDRangeKernel 
-lOpenCL ||
die "ERROR: opencl not found"; } &&
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH v2 2/3] avformat/mxfenc: write reel_name if metadata key is present

[Matthias Troffaes]

Dear Mark,

On Wed, Nov 29, 2017 at 4:11 AM, Mark Reid  wrote:
> @@ -1445,12 +1463,13 @@ static int 
> mxf_write_header_metadata_sets(AVFormatContext *s)
>  AVDictionaryEntry *entry = NULL;
>  AVStream *st = NULL;
>  int i;
> -
> -MXFPackage packages[2] = {};
> +MXFPackage packages[3] = {};

Here, may I suggest

MXFPackage packages[3] = {0};

for C99 compliance? For instance, msvc does not support an empty
struct initializer. See for instance
https://stackoverflow.com/questions/17589533/is-an-empty-initializer-list-valid-c-code

Kind regards,
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] configure: add pkg-config check for openal

[Hendrik Leppkes]

On Wed, Nov 29, 2017 at 9:39 PM, Stephen Hutchinson  wrote:
> ---
>  configure | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/configure b/configure
> index 3c08125da3..141c8b742f 100755
> --- a/configure
> +++ b/configure
> @@ -5952,11 +5952,13 @@ enabled mmal  && { check_lib mmal 
> interface/mmal/mmal.h mmal_port_co
>   check_lib mmal interface/mmal/mmal.h 
> mmal_port_connect -lmmal_core -lmmal_util -lmmal_vc_client -lbcm_host; } ||
> die "ERROR: mmal not found" &&
> check_func_headers interface/mmal/mmal.h 
> "MMAL_PARAMETER_VIDEO_MAX_NUM_CALLBACKS"; }
> -enabled openal&& { { for al_extralibs in "${OPENAL_LIBS}" 
> "-lopenal" "-lOpenAL32"; do
> -   check_lib openal 'AL/al.h' alGetError 
> "${al_extralibs}" && break; done } ||
> -   die "ERROR: openal not found"; } &&
> - { check_cpp_condition "AL/al.h" 
> "defined(AL_VERSION_1_1)" ||
> -   die "ERROR: openal must be installed and 
> version must be 1.1 or compatible"; }
> +enabled openal&& { check_pkg_config openal openal AL/al.h 
> alGetError ||
> +   { { for al_extralibs in "${OPENAL_LIBS}" 
> "-lopenal" "-lOpenAL32"; do
> + check_lib openal 'AL/al.h' alGetError 
> "${al_extralibs}" && break; done } &&
> + warn "using openal without pkg-config"; ||
> + die "ERROR: openal not found"; } &&
> +   { check_cpp_condition "AL/al.h" 
> "defined(AL_VERSION_1_1)" ||
> + die "ERROR: openal must be installed and 
> version must be 1.1 or compatible"; } }


The same applies here as with twolame, we don't really want to
duplicate all sorts of checks, so if pkg-config has been available for
a sufficiently long time, then just use it always.

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

Re: [FFmpeg-devel] [PATCH 1/2] configure: add pkg-config detection for twolame

[Hendrik Leppkes]

On Wed, Nov 29, 2017 at 9:39 PM, Stephen Hutchinson  wrote:
> ---
>  configure | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 4e7254eaeb..3c08125da3 100755
> --- a/configure
> +++ b/configure
> @@ -5888,7 +5888,9 @@ enabled libssh&& require_pkg_config libssh 
> libssh libssh/sftp.h sftp
>  enabled libspeex  && require_pkg_config libspeex speex speex/speex.h 
> speex_decoder_init
>  enabled libtesseract  && require_pkg_config libtesseract tesseract 
> tesseract/capi.h TessBaseAPICreate
>  enabled libtheora && require libtheora theora/theoraenc.h 
> th_info_init -ltheoraenc -ltheoradec -logg
> -enabled libtwolame&& require libtwolame twolame.h twolame_init 
> -ltwolame &&
> +enabled libtwolame&& { check_pkg_config libtwolame "twolame >= 
> 0.3.10" twolame.h twolame_init ||
> +   require libtwolame twolame.h twolame_init 
> -ltwolame &&
> +   warn "using libtwolame without pkg-config"; } 
> &&
>   { check_lib libtwolame twolame.h 
> twolame_encode_buffer_float32_interleaved -ltwolame ||

If all supported versions of twolame have always had a pkg-config
file, then just replace it with require_pkg_config without the
fallback dance.

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

Re: [FFmpeg-devel] Policy on ffmpeg-devel list and contributions [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

[Jim DeLaHunt]

On 2017-11-29 06:53, Compn wrote:


[...]

Also, someone once observed that common sense is not very common. :-)

sure, but please remember the DOCS are already quite verbose, and
brevity is the soul of wit. so if you can say more with less verbiage
that would be great.
[...]
Also please note that most ffmpeg developers and patch authors are from
around the world , and english may not be their native language.
I'd be happy to work on better wording. I think the obstacle is more 
fundamental: there isn't agreement on what to say, or a consensus that 
it should be said at all.





I find it interesting that bug fixes and enhancements to the source code
of ffmpeg are approved so much more easily than this patch's bug fixes
and enhancements to the text of ffmpeg.org. This is not a smooth
documentation process.

haha! well let me please explain to you what situation you have gotten
yourself stuck into! :)

the development docs that you want to patch are actually the ffmpeg
project's written rules and policy that governs the whole shebang.

so these are the rules that all devs must agree to within the project.
sure, we bicker about the rules and not everyone follows every rule,
and we have many unwritten rules that we also abide by. which also
causes great strife sometimes when someone thinks a rule is official or
not... look i didnt say it was a good system, it is what we have
evolved into over the years.

the point is that changes to this specific part of the documentation
affects all devs, not just new contributors. so we are more interested
to changes of this document. especially large changes all in one patch.

what your v1 patch has unintentionally done is to change our long
standing ffmpeg policy about patch submission and review. i know this
was not your intention, but you have picked one of the core parts of the
project to modify on your first attempt. :)


What this says to me is that the problems I observe in 
ffmpeg.org/developer.html go deeper than wording.


There are architectural problems: this one page is supposed to serve as 
both the reference for the project's rules and as a tutorial for new 
contributors. The requirements for these two purposes differ.


There are governance problems: rules exist for important parts of the 
project, but they are not in writing. Exhibit 1 is that the ffmpeg-devel 
list is central to this project, but there is presently zero description 
of it in this web page. Exhibit 2 is that the actual practice of the 
ffmpeg-cvslog list by several senior developers clearly differs from the 
description of it in this page. Exhibit 3 is the absence in this whole 
discussion of any reference to any rule-making process and its 
decisions, when the patch appears to intrude on policy matters.


There are process problems: while I see lots of activity and appropriate 
process for improving the code of the ffmpeg executables, there is not 
similar activity or appropriate process for improving the documentation. 
I think this thread shows that the patch/review/reject or accept model 
used for code doesn't work so well for words.


And then there are the writing problems: broken links, all content under 
one @chapter, checklists but no instructions to use the checklists, 
missing content, unclear content, and so on.


I came here to try to fix the most severe, easiest to fix bugs in the 
docs. I am learning that nothing about ffmpeg.org/developer.html is 
going to be easy to fix.  I am skeptical that splitting the docs patch 
will help.



hope this clears things up. feel free to ask me questions off list, or
we can be found on irc.freenode.net #ffmpeg-devel as well for real
time chat.

tl;dr my suggestions:
1. split docs patch
2. less words, rephrase for brevity
3. welcome to open source team collaboration :)


I appreciate that offer. I will hop on to IRC and off-list email for a 
bit, and see if I can find a way forward. Maybe I won't find it.


In the meantime, I don't expect that I will get the cooperation needed 
to fix this patch. I think it has been defeated.


But I do appreciate the helpful explanation, and I do appreciate the 
welcome to the project. Thank you. Best regards,

   —Jim DeLaHunt

--
--Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/)
  multilingual websites consultant

  355-1027 Davie St, Vancouver BC V6E 4L2, Canada
 Canada mobile +1-604-376-8953

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

Re: [FFmpeg-devel] [PATCH 1/2] configure: add pkg-config detection for twolame

[James Almer]

On 11/29/2017 5:57 PM, Hendrik Leppkes wrote:
> On Wed, Nov 29, 2017 at 9:39 PM, Stephen Hutchinson  wrote:
>> ---
>>  configure | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/configure b/configure
>> index 4e7254eaeb..3c08125da3 100755
>> --- a/configure
>> +++ b/configure
>> @@ -5888,7 +5888,9 @@ enabled libssh&& require_pkg_config libssh 
>> libssh libssh/sftp.h sftp
>>  enabled libspeex  && require_pkg_config libspeex speex 
>> speex/speex.h speex_decoder_init
>>  enabled libtesseract  && require_pkg_config libtesseract tesseract 
>> tesseract/capi.h TessBaseAPICreate
>>  enabled libtheora && require libtheora theora/theoraenc.h 
>> th_info_init -ltheoraenc -ltheoradec -logg
>> -enabled libtwolame&& require libtwolame twolame.h twolame_init 
>> -ltwolame &&
>> +enabled libtwolame&& { check_pkg_config libtwolame "twolame >= 
>> 0.3.10" twolame.h twolame_init ||
>> +   require libtwolame twolame.h twolame_init 
>> -ltwolame &&
>> +   warn "using libtwolame without pkg-config"; 
>> } &&
>>   { check_lib libtwolame twolame.h 
>> twolame_encode_buffer_float32_interleaved -ltwolame ||
> 
> If all supported versions of twolame have always had a pkg-config
> file, then just replace it with require_pkg_config without the
> fallback dance.

Nope, only git head currently. https://github.com/njh/twolame/pull/72
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] configure: add pkg-config detection for twolame

[James Almer]

On 11/29/2017 6:11 PM, James Almer wrote:
> On 11/29/2017 5:57 PM, Hendrik Leppkes wrote:
>> On Wed, Nov 29, 2017 at 9:39 PM, Stephen Hutchinson  wrote:
>>> ---
>>>  configure | 4 +++-
>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/configure b/configure
>>> index 4e7254eaeb..3c08125da3 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -5888,7 +5888,9 @@ enabled libssh&& require_pkg_config 
>>> libssh libssh libssh/sftp.h sftp
>>>  enabled libspeex  && require_pkg_config libspeex speex 
>>> speex/speex.h speex_decoder_init
>>>  enabled libtesseract  && require_pkg_config libtesseract tesseract 
>>> tesseract/capi.h TessBaseAPICreate
>>>  enabled libtheora && require libtheora theora/theoraenc.h 
>>> th_info_init -ltheoraenc -ltheoradec -logg
>>> -enabled libtwolame&& require libtwolame twolame.h twolame_init 
>>> -ltwolame &&
>>> +enabled libtwolame&& { check_pkg_config libtwolame "twolame >= 
>>> 0.3.10" twolame.h twolame_init ||
>>> +   require libtwolame twolame.h twolame_init 
>>> -ltwolame &&
>>> +   warn "using libtwolame without pkg-config"; 
>>> } &&
>>>   { check_lib libtwolame twolame.h 
>>> twolame_encode_buffer_float32_interleaved -ltwolame ||
>>
>> If all supported versions of twolame have always had a pkg-config
>> file, then just replace it with require_pkg_config without the
>> fallback dance.
> 
> Nope, only git head currently. https://github.com/njh/twolame/pull/72

Oh nevermind, all releases seem to have it. I mistook this as having one
properly working for static builds.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-devel 1/1] avcodec/samidec: check av_strdup() return value

[Clément Bœsch]

On Mon, Nov 27, 2017 at 02:56:32PM +0800, Pan Bian wrote:
> In function sami_paragraph_to_ass(), the return value of av_strdup() is
> not checked. To avoid potential NULL dereference, the return value
> should be checked against NULL.
> 
> Signed-off-by: Pan Bian 
> ---
> V2: fix patcheck warnings
> ---
>  libavcodec/samidec.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavcodec/samidec.c b/libavcodec/samidec.c
> index 2620424..6a59806 100644
> --- a/libavcodec/samidec.c
> +++ b/libavcodec/samidec.c
> @@ -48,6 +48,9 @@ static int sami_paragraph_to_ass(AVCodecContext *avctx, 
> const char *src)
>  AVBPrint *dst_content = &sami->encoded_content;
>  AVBPrint *dst_source = &sami->encoded_source;
>  
> +if (!dupsrc)
> +return AVERROR(ENOMEM);
> +
>  av_bprint_clear(&sami->encoded_content);
>  av_bprint_clear(&sami->content);
>  av_bprint_clear(&sami->encoded_source);

Patch applied, thanks

-- 
Clément B.


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

[FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement auto detection by using frame side data

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi  |  4 
 libavfilter/vf_stereo3d.c | 35 ---
 2 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 4a4efc70c8..e8da5e21a6 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14057,6 +14057,10 @@ Set stereoscopic image format of input.
 
 Available values for input image formats are:
 @table @samp
+@item auto
+set input format using frame side data
+If such data is not available filter will return unchanged input.
+
 @item sbsl
 side by side parallel (left eye left, right eye right)
 
diff --git a/libavfilter/vf_stereo3d.c b/libavfilter/vf_stereo3d.c
index 8b22f880ca..a51fbeb75d 100644
--- a/libavfilter/vf_stereo3d.c
+++ b/libavfilter/vf_stereo3d.c
@@ -25,6 +25,7 @@
 #include "libavutil/opt.h"
 #include "libavutil/parseutils.h"
 #include "libavutil/pixdesc.h"
+#include "libavutil/stereo3d.h"
 #include "avfilter.h"
 #include "drawutils.h"
 #include "formats.h"
@@ -47,8 +48,8 @@ enum StereoCode {
 ANAGLYPH_YB_DUBOIS, // anaglyph yellow/blue dubois
 ANAGLYPH_RB_GRAY,   // anaglyph red/blue gray
 ANAGLYPH_RG_GRAY,   // anaglyph red/green gray
-MONO_L, // mono output for debugging (left eye only)
-MONO_R, // mono output for debugging (right eye only)
+MONO_L, // mono output (left eye only)
+MONO_R, // mono output (right eye only)
 INTERLEAVE_ROWS_LR, // row-interleave (left eye has top row)
 INTERLEAVE_ROWS_RL, // row-interleave (right eye has top row)
 SIDE_BY_SIDE_LR,// side by side parallel (left eye left, right eye 
right)
@@ -66,7 +67,8 @@ enum StereoCode {
 INTERLEAVE_COLS_LR, // column-interleave (left eye first, right eye second)
 INTERLEAVE_COLS_RL, // column-interleave (right eye first, left eye second)
 HDMI,   // HDMI frame pack (left eye first, right eye second)
-STEREO_CODE_COUNT   // TODO: needs autodetection
+AUTO,   // guess input format using frame's metadata.
+STEREO_CODE_COUNT
 };
 
 typedef struct StereoComponent {
@@ -173,6 +175,7 @@ static const AVOption stereo3d_options[] = {
 { "irr",   "interleave rows right first", 0, AV_OPT_TYPE_CONST, 
{.i64=INTERLEAVE_ROWS_RL}, 0, 0, FLAGS, "in" },
 { "icl",   "interleave columns left first",   0, AV_OPT_TYPE_CONST, 
{.i64=INTERLEAVE_COLS_LR}, 0, 0, FLAGS, "in" },
 { "icr",   "interleave columns right first",  0, AV_OPT_TYPE_CONST, 
{.i64=INTERLEAVE_COLS_RL}, 0, 0, FLAGS, "in" },
+{ "auto",  "guess using frame metadata",  0, AV_OPT_TYPE_CONST, 
{.i64=AUTO},   0, 0, FLAGS, "in" },
 { "out",   "set output format", OFFSET(out.format),  AV_OPT_TYPE_INT,   
{.i64=ANAGLYPH_RC_DUBOIS}, 0, STEREO_CODE_COUNT-1, FLAGS, "out"},
 { "ab2l",  "above below half height left first",  0, AV_OPT_TYPE_CONST, 
{.i64=ABOVE_BELOW_2_LR},   0, 0, FLAGS, "out" },
 { "ab2r",  "above below half height right first", 0, AV_OPT_TYPE_CONST, 
{.i64=ABOVE_BELOW_2_RL},   0, 0, FLAGS, "out" },
@@ -366,6 +369,9 @@ static int config_output(AVFilterLink *outlink)
 int ret;
 s->aspect = inlink->sample_aspect_ratio;
 
+if (s->in.format == AUTO || (s->in.format == s->out.format))
+return 0;
+
 switch (s->in.format) {
 case INTERLEAVE_COLS_LR:
 case INTERLEAVE_COLS_RL:
@@ -670,6 +676,29 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*inpicref)
 int out_off_left[4], out_off_right[4];
 int i, ret;
 
+if (s->in.format == AUTO) {
+AVFrameSideData *sd = av_frame_get_side_data(inpicref, 
AV_FRAME_DATA_STEREO3D);
+
+if (sd) {
+AVStereo3D *s3d = (AVStereo3D *)sd->data;
+
+switch (s3d->type) {
+case AV_STEREO3D_SIDEBYSIDE:  s->in.format = 
SIDE_BY_SIDE_LR;break;
+case AV_STEREO3D_SIDEBYSIDE_QUINCUNX: s->in.format = 
SIDE_BY_SIDE_LR;break;
+case AV_STEREO3D_TOPBOTTOM:   s->in.format = 
ABOVE_BELOW_LR; break;
+case AV_STEREO3D_CHECKERBOARD:s->in.format = 
CHECKERBOARD_LR;break;
+case AV_STEREO3D_FRAMESEQUENCE:   s->in.format = 
ALTERNATING_LR; break;
+case AV_STEREO3D_LINES:   s->in.format = 
INTERLEAVE_ROWS_LR; break;
+case AV_STEREO3D_COLUMNS: s->in.format = 
INTERLEAVE_COLS_LR; break;
+default:  s->in.format = s->out.format 
= MONO_L;
+};
+} else {
+s->in.format = s->out.format = MONO_L;
+}
+if ((ret = config_output(outlink)) < 0)
+return ret;
+}
+
 if (s->in.format == s->out.format)
 return ff_filter_frame(outlink, inpicref);
 
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_stereo3d: implement auto detection by using frame side data

[Paul B Mahol]

On 11/29/17, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi  |  4 
>  libavfilter/vf_stereo3d.c | 35 ---
>  2 files changed, 36 insertions(+), 3 deletions(-)
>

This breaks if one uses other filters right after this one.

Is there way how to overcome this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] vaapi_h264: Add named options for setting profile and level

[Mark Thompson]

---
 libavcodec/vaapi_encode_h264.c | 48 --
 1 file changed, 46 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 5fd0bf7796..6940823b8e 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -93,6 +93,8 @@ typedef struct VAAPIEncodeH264Options {
 int coder;
 int aud;
 int sei;
+int profile;
+int level;
 } VAAPIEncodeH264Options;
 
 
@@ -886,6 +888,11 @@ static av_cold int vaapi_encode_h264_init(AVCodecContext 
*avctx)
 
 ctx->codec = &vaapi_encode_type_h264;
 
+if (avctx->profile == FF_PROFILE_UNKNOWN)
+avctx->profile = opt->profile;
+if (avctx->level == FF_LEVEL_UNKNOWN)
+avctx->level = opt->level;
+
 switch (avctx->profile) {
 case FF_PROFILE_H264_BASELINE:
 av_log(avctx, AV_LOG_WARNING, "H.264 baseline profile is not "
@@ -1010,12 +1017,49 @@ static const AVOption vaapi_encode_h264_options[] = {
 { "recovery_point", "Include recovery points where appropriate",
   0, AV_OPT_TYPE_CONST, { .i64 = SEI_RECOVERY_POINT },
   INT_MIN, INT_MAX, FLAGS, "sei" },
+
+{ "profile", "Set profile (profile_idc and constraint_set*_flag)",
+  OFFSET(profile), AV_OPT_TYPE_INT,
+  { .i64 = FF_PROFILE_H264_HIGH }, 0x, 0x, FLAGS, "profile" },
+
+#define PROFILE(name, value)  name, NULL, 0, AV_OPT_TYPE_CONST, \
+  { .i64 = value }, 0, 0, FLAGS, "profile"
+{ PROFILE("constrained_baseline", FF_PROFILE_H264_CONSTRAINED_BASELINE) },
+{ PROFILE("main", FF_PROFILE_H264_MAIN) },
+{ PROFILE("high", FF_PROFILE_H264_HIGH) },
+#undef PROFILE
+
+{ "level", "Set level (level_idc)",
+  OFFSET(level), AV_OPT_TYPE_INT,
+  { .i64 = 51 }, 0x00, 0xff, FLAGS, "level" },
+
+#define LEVEL(name, value) name, NULL, 0, AV_OPT_TYPE_CONST, \
+  { .i64 = value }, 0, 0, FLAGS, "level"
+{ LEVEL("1",   10) },
+{ LEVEL("1.1", 11) },
+{ LEVEL("1.2", 12) },
+{ LEVEL("1.3", 13) },
+{ LEVEL("2",   20) },
+{ LEVEL("2.1", 21) },
+{ LEVEL("2.2", 22) },
+{ LEVEL("3",   30) },
+{ LEVEL("3.1", 31) },
+{ LEVEL("3.2", 32) },
+{ LEVEL("4",   40) },
+{ LEVEL("4.1", 41) },
+{ LEVEL("4.2", 42) },
+{ LEVEL("5",   50) },
+{ LEVEL("5.1", 51) },
+{ LEVEL("5.2", 52) },
+{ LEVEL("6",   60) },
+{ LEVEL("6.1", 61) },
+{ LEVEL("6.2", 62) },
+#undef LEVEL
+
 { NULL },
 };
 
 static const AVCodecDefault vaapi_encode_h264_defaults[] = {
-{ "profile","100" },
-{ "level",  "51"  },
 { "b",  "0"   },
 { "bf", "2"   },
 { "g",  "120" },
-- 
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] vaapi_h265: Add named options for setting profile and level

[Mark Thompson]

Also fixes the default, which previously contained a nonsense value.
---
On 29/11/17 03:51, Li, Zhong wrote:
>> On 28/11/17 07:46, Ruiling Song wrote:
>>> Signed-off-by: Ruiling Song 
>>> ---
>>>  libavcodec/vaapi_encode_h265.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/vaapi_encode_h265.c
>>> b/libavcodec/vaapi_encode_h265.c index 3ae92a7..32b8bc6 100644
>>> --- a/libavcodec/vaapi_encode_h265.c
>>> +++ b/libavcodec/vaapi_encode_h265.c
>>> @@ -219,7 +219,7 @@ static int
>> vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
>>>  .general_non_packed_constraint_flag = 1,
>>>  .general_frame_only_constraint_flag = 1,
>>>
>>> -.general_level_idc = avctx->level,
>>> +.general_level_idc = avctx->level * 3,
>>>  };
>>>
>>> vps->profile_tier_level.general_profile_compatibility_flag[avctx->prof
>>> ile & 31] = 1;
>>>
>>>
>> The documentation has always said "profile and level set the values of
>> general_profile_idc and general_level_idc respectively"
>> () - the code
>> disagreed for a while, but that was made consistent in
>> 00179664bccd1dd6fa0d1c40db453528757bf6f7.
>>
>> Why do you want to change it to be general_level_idc / 3 instead?
> 
> As HEVC spec, "general_level_idc and sub_layer_level_idc[ i ] shall be set 
> equal to a value of 30 times the level number specified in
> Table A.4."
> And use the tool "mediainfo" to check the encoded bitstream, it show the 
> level is 1.7 if set the option "-level" to be 51.
> 
> Maybe the documentation 
> (()) also needs to be 
> changed? 

Hmm, right - the default is wrong, so you get a nonsense value there.

How about we fix that and add named constants to make it clearer, like this?

Thanks,

- Mark



 libavcodec/vaapi_encode_h265.c | 44 +++---
 1 file changed, 41 insertions(+), 3 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 3ae92a7a09..8e98b0230d 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -63,6 +63,8 @@ typedef struct VAAPIEncodeH265Context {
 typedef struct VAAPIEncodeH265Options {
 int qp;
 int aud;
+int profile;
+int level;
 } VAAPIEncodeH265Options;
 
 
@@ -880,10 +882,17 @@ static const VAAPIEncodeType vaapi_encode_type_h265 = {
 
 static av_cold int vaapi_encode_h265_init(AVCodecContext *avctx)
 {
-VAAPIEncodeContext *ctx = avctx->priv_data;
+VAAPIEncodeContext *ctx = avctx->priv_data;
+VAAPIEncodeH265Options *opt =
+(VAAPIEncodeH265Options*)ctx->codec_options_data;
 
 ctx->codec = &vaapi_encode_type_h265;
 
+if (avctx->profile == FF_PROFILE_UNKNOWN)
+avctx->profile = opt->profile;
+if (avctx->level == FF_LEVEL_UNKNOWN)
+avctx->level = opt->level;
+
 switch (avctx->profile) {
 case FF_PROFILE_HEVC_MAIN:
 case FF_PROFILE_UNKNOWN:
@@ -946,12 +955,41 @@ static const AVOption vaapi_encode_h265_options[] = {
 { "aud", "Include AUD",
   OFFSET(aud), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, FLAGS },
 
+{ "profile", "Set profile (general_profile_idc)",
+  OFFSET(profile), AV_OPT_TYPE_INT,
+  { .i64 = FF_PROFILE_HEVC_MAIN }, 0x00, 0xff, FLAGS, "profile" },
+
+#define PROFILE(name, value)  name, NULL, 0, AV_OPT_TYPE_CONST, \
+  { .i64 = value }, 0, 0, FLAGS, "profile"
+{ PROFILE("main",   FF_PROFILE_HEVC_MAIN) },
+{ PROFILE("main10", FF_PROFILE_HEVC_MAIN_10) },
+#undef PROFILE
+
+{ "level", "Set level (general_level_idc)",
+  OFFSET(level), AV_OPT_TYPE_INT,
+  { .i64 = 153 }, 0x00, 0xff, FLAGS, "level" },
+
+#define LEVEL(name, value) name, NULL, 0, AV_OPT_TYPE_CONST, \
+  { .i64 = value }, 0, 0, FLAGS, "level"
+{ LEVEL("1",30) },
+{ LEVEL("2",60) },
+{ LEVEL("2.1",  63) },
+{ LEVEL("3",90) },
+{ LEVEL("3.1",  93) },
+{ LEVEL("4",   120) },
+{ LEVEL("4.1", 123) },
+{ LEVEL("5",   150) },
+{ LEVEL("5.1", 153) },
+{ LEVEL("5.2", 156) },
+{ LEVEL("6",   180) },
+{ LEVEL("6.1", 183) },
+{ LEVEL("6.2", 186) },
+#undef LEVEL
+
 { NULL },
 };
 
 static const AVCodecDefault vaapi_encode_h265_defaults[] = {
-{ "profile","1"   },
-{ "level",  "51"  },
 { "b",  "0"   },
 { "bf", "2"   },
 { "g",  "120" },
-- 
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] examples/hw_decode: Use hw-config information to find pixfmt

[Mark Thompson]

On 29/11/17 12:22, Moritz Barsnick wrote:
> On Wed, Nov 29, 2017 at 00:34:03 +, Mark Thompson wrote:
>> +if (type == AV_HWDEVICE_TYPE_NONE) {
>> +fprintf(stderr, "Device type %s is not supported.\n", argv[1]);
>> +fprintf(stderr, "Available device types:");
>> +type = AV_HWDEVICE_TYPE_NONE;
>> +while((type = av_hwdevice_iterate_types(type)) != 
>> AV_HWDEVICE_TYPE_NONE)
>> +fprintf(stderr, " %s", av_hwdevice_get_type_name(type));
> 
> I see what you're trying to do with "type = AV_HWDEVICE_TYPE_NONE"
> (initialize the iterator), but the assignment is redundant.
> 
> I guess if the compiler optimizes it away anyway, it may be good for
> readability, especially since it's an example. *shrug*

Huh, I didn't notice that.

I've removed it - the iterating over devices is just to make the error message 
nicer and mostly irrelevant for the example, so I think avoiding the redundancy 
wins.

Thanks,

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

[FFmpeg-devel] [PATCH V2] lavc/vp8: Fix HWAccel VP8 decoder can't support resolution change.

[Jun Zhao]

V2: fix the V1 lead to webp crash issue.
From b943c2814789288d09b4032fa6cdfbc3fd672a2b Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Wed, 29 Nov 2017 10:22:03 +0800
Subject: [PATCH V2] lavc/vp8: Fix HWAccel VP8 decoder can't support resolution
 change.

Use the following command to reproduce this issue:
make fate-vp8-size-change HWACCEL="vaapi -vaapi_device \
/dev/dri/renderD128 -hwaccel_output_format yuv420p"
SAMPLES=../fate-suite/.

At the same time, reconstruct the public logic as a function.

Signed-off-by: Yun Zhou 
Signed-off-by: Jun Zhao 
---
 libavcodec/vp8.c | 46 ++
 1 file changed, 34 insertions(+), 12 deletions(-)

diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index 471c0bb89e..d5cb7be7b3 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -167,6 +167,30 @@ static VP8Frame *vp8_find_free_buffer(VP8Context *s)
 return frame;
 }
 
+static enum AVPixelFormat get_pixel_format(VP8Context *s)
+{
+enum AVPixelFormat fmt;
+enum AVPixelFormat pix_fmts[] = {
+#if CONFIG_VP8_VAAPI_HWACCEL
+AV_PIX_FMT_VAAPI,
+#endif
+#if CONFIG_VP8_NVDEC_HWACCEL
+AV_PIX_FMT_CUDA,
+#endif
+AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_NONE,
+};
+
+fmt = ff_get_format(s->avctx, pix_fmts);
+if (fmt < 0) {
+fmt = AV_PIX_FMT_NONE;
+av_log(s->avctx, AV_LOG_ERROR,
+   "Can not support the format. \n");
+}
+
+return fmt;
+}
+
 static av_always_inline
 int update_dimensions(VP8Context *s, int width, int height, int is_vp7)
 {
@@ -182,6 +206,15 @@ int update_dimensions(VP8Context *s, int width, int 
height, int is_vp7)
 return ret;
 }
 
+if (!s->actually_webp && !is_vp7) {
+s->pix_fmt = get_pixel_format(s);
+if (s->pix_fmt < 0) {
+ret = AVERROR(EINVAL);
+return ret;
+}
+avctx->pix_fmt = s->pix_fmt;
+}
+
 s->mb_width  = (s->avctx->coded_width  + 15) / 16;
 s->mb_height = (s->avctx->coded_height + 15) / 16;
 
@@ -2598,18 +2631,7 @@ int vp78_decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 if (s->actually_webp) {
 // avctx->pix_fmt already set in caller.
 } else if (!is_vp7 && s->pix_fmt == AV_PIX_FMT_NONE) {
-enum AVPixelFormat pix_fmts[] = {
-#if CONFIG_VP8_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI,
-#endif
-#if CONFIG_VP8_NVDEC_HWACCEL
-AV_PIX_FMT_CUDA,
-#endif
-AV_PIX_FMT_YUV420P,
-AV_PIX_FMT_NONE,
-};
-
-s->pix_fmt = ff_get_format(s->avctx, pix_fmts);
+s->pix_fmt = get_pixel_format(s);
 if (s->pix_fmt < 0) {
 ret = AVERROR(EINVAL);
 goto err;
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH] examples/hw_decode: Use hw-config information to find pixfmt

[Mark Thompson]

On 29/11/17 00:48, Jun Zhao wrote:
> On 2017/11/29 8:34, Mark Thompson wrote:
>> This removes all remaining device-type specificity.
>> ---
>>  doc/examples/hw_decode.c | 55 
>> 
>>  1 file changed, 23 insertions(+), 32 deletions(-)
>>
>> diff --git a/doc/examples/hw_decode.c b/doc/examples/hw_decode.c
>> index 9c7adbf51a..8f48f3b706 100644
>> --- a/doc/examples/hw_decode.c
>> +++ b/doc/examples/hw_decode.c
>> @@ -44,34 +44,6 @@ static AVBufferRef *hw_device_ctx = NULL;
>>  static enum AVPixelFormat hw_pix_fmt;
>>  static FILE *output_file = NULL;
>>  
>> -static enum AVPixelFormat find_fmt_by_hw_type(const enum AVHWDeviceType 
>> type)
>> -{
>> -enum AVPixelFormat fmt;
>> -
>> -switch (type) {
>> -case AV_HWDEVICE_TYPE_VAAPI:
>> -fmt = AV_PIX_FMT_VAAPI;
>> -break;
>> -case AV_HWDEVICE_TYPE_DXVA2:
>> -fmt = AV_PIX_FMT_DXVA2_VLD;
>> -break;
>> -case AV_HWDEVICE_TYPE_D3D11VA:
>> -fmt = AV_PIX_FMT_D3D11;
>> -break;
>> -case AV_HWDEVICE_TYPE_VDPAU:
>> -fmt = AV_PIX_FMT_VDPAU;
>> -break;
>> -case AV_HWDEVICE_TYPE_VIDEOTOOLBOX:
>> -fmt = AV_PIX_FMT_VIDEOTOOLBOX;
>> -break;
>> -default:
>> -fmt = AV_PIX_FMT_NONE;
>> -break;
>> -}
>> -
>> -return fmt;
>> -}
>> -
>>  static int hw_decoder_init(AVCodecContext *ctx, const enum AVHWDeviceType 
>> type)
>>  {
>>  int err = 0;
>> @@ -184,18 +156,23 @@ int main(int argc, char *argv[])
>>  AVCodec *decoder = NULL;
>>  AVPacket packet;
>>  enum AVHWDeviceType type;
>> +int i;
>>  
>>  if (argc < 4) {
>> -fprintf(stderr, "Usage: %s   
>> \n", argv[0]);
>> +fprintf(stderr, "Usage: %s   > file>\n", argv[0]);
>>  return -1;
>>  }
>>  
>>  av_register_all();
>>  
>>  type = av_hwdevice_find_type_by_name(argv[1]);
>> -hw_pix_fmt = find_fmt_by_hw_type(type);
>> -if (hw_pix_fmt == -1) {
>> -fprintf(stderr, "Cannot support '%s' in this example.\n", argv[1]);
>> +if (type == AV_HWDEVICE_TYPE_NONE) {
>> +fprintf(stderr, "Device type %s is not supported.\n", argv[1]);
>> +fprintf(stderr, "Available device types:");
>> +type = AV_HWDEVICE_TYPE_NONE;
>> +while((type = av_hwdevice_iterate_types(type)) != 
>> AV_HWDEVICE_TYPE_NONE)
>> +fprintf(stderr, " %s", av_hwdevice_get_type_name(type));
>> +fprintf(stderr, "\n");
>>  return -1;
>>  }
>>  
>> @@ -218,6 +195,20 @@ int main(int argc, char *argv[])
>>  }
>>  video_stream = ret;
>>  
>> +for (i = 0;; i++) {
>> +const AVCodecHWConfig *config = avcodec_get_hw_config(decoder, i);
>> +if (!config) {
>> +fprintf(stderr, "Decoder %s does not support device type %s.\n",
>> +decoder->name, av_hwdevice_get_type_name(type));
>> +return -1;
>> +}
>> +if (config->methods & AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX &&
>> +config->device_type == type) {
>> +hw_pix_fmt = config->pix_fmt;
>> +break;
>> +}
>> +}
>> +
>>  if (!(decoder_ctx = avcodec_alloc_context3(decoder)))
>>  return AVERROR(ENOMEM);
>>  
> LGTM and tesed

Thanks!  Applied with the fixup from Moritz.

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

Re: [FFmpeg-devel] [PATCH] avfilter: slice processing for geq

[Michael Niedermayer]

On Wed, Nov 29, 2017 at 11:28:40AM +, Marc-Antoine ARNAUD wrote:
> Le mer. 22 nov. 2017 à 17:54, Michael Niedermayer 
> a écrit :
> 
> > On Wed, Nov 22, 2017 at 10:24:30AM +, Marc-Antoine ARNAUD wrote:
> > > New patch version which fixe the last remark.
> > >
> > >
> > > Le ven. 10 nov. 2017 à 00:47, Michael Niedermayer  > >
> > > a écrit :
> > >
> > > > On Thu, Nov 09, 2017 at 10:22:23AM +, Marc-Antoine ARNAUD wrote:
> > > > > Please find the merged patch in attachement.
> > > > >
> > > > > Thanks
> > > > >
> > > > > Le mer. 8 nov. 2017 à 17:12, Paul B Mahol  a
> > écrit :
> > > > >
> > > > > > On 11/8/17, Marc-Antoine ARNAUD 
> > wrote:
> > > > > > > This patch will fix the stride issue.
> > > > > > > Is it valid for you ?
> > > > > > >
> > > > > > > Does it required to merge these 2 patches ? (and remove base64
> > > > encoding
> > > > > > on
> > > > > > > the first one)
> > > > > >
> > > > > > Please merge those two patches, base64 encoding should not be
> > needed
> > > > > > (it helps to faster review patches if they are not encoded).
> > > > > > ___
> > > > > > ffmpeg-devel mailing list
> > > > > > ffmpeg-devel@ffmpeg.org
> > > > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > > > >
> > > >
> > > > >  vf_geq.c |  124
> > > > +--
> > > > >  1 file changed, 90 insertions(+), 34 deletions(-)
> > > > > b41a90fffb5ddef553661007a38659c602f7ce56
> > > > 0001-avfilter-slice-processing-for-geq.patch
> > > > > From ac2a6322fa96835e02a24c31f014fb360e26561f Mon Sep 17 00:00:00
> > 2001
> > > > > From: Marc-Antoine Arnaud 
> > > > > Date: Thu, 9 Nov 2017 11:19:43 +0100
> > > > > Subject: [PATCH] avfilter: slice processing for geq
> > > > > Content-Type: text/x-patch; charset="utf-8"
> > > >
> > > > crashes:
> > > > ./ffmpeg_g -f lavfi -i
> > > >
> > 'nullsrc=s=200x200,format=yuv444p16,geq=X*Y/10:sin(X/10)*255:cos(Y/10)*255'
> > > > -vframes 5 -y blah.avi
> > > >
> > > > ==24616== Thread 7:
> > > > ==24616== Invalid write of size 2
> > > > ==24616==at 0x4F3AAF: slice_geq_filter (vf_geq.c:289)
> > > > ==24616==by 0x48E4C9: worker_func (pthread.c:50)
> > > > ==24616==by 0x11DB932: run_jobs (slicethread.c:61)
> > > > ==24616==by 0x11DBA04: thread_worker (slicethread.c:85)
> > > > ==24616==by 0xC45D183: start_thread (pthread_create.c:312)
> > > > ==24616==by 0xC770FFC: clone (clone.S:111)
> > > > ==24616==  Address 0x1177143e is 93,214 bytes inside a block of size
> > > > 93,215 alloc'd
> > > > ==24616==at 0x4C2A6C5: memalign (vg_replace_malloc.c:727)
> > > > ==24616==by 0x4C2A760: posix_memalign (vg_replace_malloc.c:876)
> > > > ==24616==by 0x11B0C43: av_malloc (mem.c:87)
> > > > ==24616==by 0x11987CC: av_buffer_alloc (buffer.c:72)
> > > > ==24616==by 0x1198831: av_buffer_allocz (buffer.c:85)
> > > > ==24616==by 0x1198F29: pool_alloc_buffer (buffer.c:312)
> > > > ==24616==by 0x1199057: av_buffer_pool_get (buffer.c:349)
> > > > ==24616==by 0x489D6D: ff_frame_pool_get (framepool.c:222)
> > > > ==24616==by 0x58F6EB: ff_default_get_video_buffer (video.c:89)
> > > > ==24616==by 0x58F768: ff_get_video_buffer (video.c:102)
> > > > ==24616==by 0x4F3BF3: geq_filter_frame (vf_geq.c:312)
> > > > ==24616==by 0x472FD0: ff_filter_frame_framed (avfilter.c:1104)
> > > > ==24616==by 0x473800: ff_filter_frame_to_filter (avfilter.c:1252)
> > > > ==24616==by 0x4739F8: ff_filter_activate_default (avfilter.c:1301)
> > > > ==24616==by 0x473C12: ff_filter_activate (avfilter.c:1462)
> > > > ==24616==by 0x478A4F: ff_filter_graph_run_once
> > (avfiltergraph.c:1456)
> > > > ==24616==by 0x478C72: get_frame_internal (buffersink.c:110)
> > > > ==24616==by 0x478CCF: av_buffersink_get_frame_flags
> > (buffersink.c:121)
> > > > ==24616==by 0x441808: lavfi_read_packet (lavfi.c:410)
> > > > ==24616==by 0x7AC315: ff_read_packet (utils.c:822)
> > > > ==24616==
> > > > --24616-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11
> > (SIGSEGV)
> > > > - exiting
> > > > --24616-- si_code=80;  Faulting address: 0x0;  sp: 0x40a075db0
> > > >
> > > > [...]
> > > >
> > > > --
> > > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> > > >
> > > > While the State exists there can be no freedom; when there is freedom
> > there
> > > > will be no State. -- Vladimir Lenin
> > > > ___
> > > > ffmpeg-devel mailing list
> > > > ffmpeg-devel@ffmpeg.org
> > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > >
> >
> > >  vf_geq.c |  130
> > +++
> > >  1 file changed, 90 insertions(+), 40 deletions(-)
> > > abe75c0a0cf89605006905c0c58c0600d26fadb6
> > 0001-avfilter-slice-processing-for-geq.patch
> > > From 7ac2a8c41aaf69ec6cacf7460fa170fd4ca52d8f Mon Sep 17 00:00:00 2001
> > > From: Marc-Antoine Arnaud 
> > >

Re: [FFmpeg-devel] [PATCH 5/5] avformat/avc: support writting more than one sps/pps in ff_isom_write_avcc

[Michael Niedermayer]

On Tue, Nov 28, 2017 at 10:43:03PM -0300, James Almer wrote:
> Addresses ticket #6864
> 
> Signed-off-by: James Almer 
> ---
> I don't have the h264 in isobmff spec at hand, so i just looked at what
> the h264_mp4toannexb bsf does to handle more than one sps and pps and
> worked with that.
> If there's a pps limit it's not currently enforced, but adding it is
> trivial. The sps limit i added is arbitrarily 2^5-1, as that's the
> amount of bits available for it.

theres H264_MAX_PPS_COUNT and H264_MAX_SPS_COUNT


> 
>  libavformat/avc.c | 50 +-
>  1 file changed, 37 insertions(+), 13 deletions(-)

LGTM, someone should check it against the spec thhough


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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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

Re: [FFmpeg-devel] [PATCH 4/5] avformat/avc: free buffer in ff_isom_write_avcc on failure

[Michael Niedermayer]

On Tue, Nov 28, 2017 at 10:43:02PM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavformat/avc.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/avc.c b/libavformat/avc.c
> index 7542db684b..6ef6e08778 100644
> --- a/libavformat/avc.c
> +++ b/libavformat/avc.c
> @@ -145,8 +145,10 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t 
> *data, int len)
>  buf += size;
>  }
>  
> -if (!sps || !pps || sps_size < 4 || sps_size > UINT16_MAX || pps_size > 
> UINT16_MAX)
> -return AVERROR_INVALIDDATA;
> +if (!sps || !pps || sps_size < 4 || sps_size > UINT16_MAX || pps_size > 
> UINT16_MAX) {
> +ret = AVERROR_INVALIDDATA;
> +goto fail;
> +}
>  
>  avio_w8(pb, 1); /* version */
>  avio_w8(pb, sps[1]); /* profile */
> @@ -160,9 +162,11 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t 
> *data, int len)
>  avio_w8(pb, 1); /* number of pps */
>  avio_wb16(pb, pps_size);
>  avio_write(pb, pps, pps_size);
> +
> +fail:
>  av_free(start);

LGTM, but please set start = NULL at th top so "goto fail" is safe
at any point not just the current points

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

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] [PATCH 2/2] configure: add pkg-config check for openal

[Stephen Hutchinson]

On 11/29/2017 3:58 PM, Hendrik Leppkes wrote:

The same applies here as with twolame, we don't really want to
duplicate all sorts of checks, so if pkg-config has been available for
a sufficiently long time, then just use it always.



Ok.  TwoLAME is pretty clear-cut, but OpenAL raises more questions.

The configure check says 'OpenAL 1.1 or compatible'. If we're
assuming openal-soft rather than the really old Creative SDK,
then the git history of openal.pc.in its current location dates
back to version 1.11.753, in 2009 (the .pc.in file first appeared in
2008, which appears to be with version 1.5.304).

Practically, I think it's safe to assume users are going to fetch
a reasonably current version of openal-soft, but for precision's
sake should that mean we force a version check so that version
1.11.753 (or 1.12 for convenience?) or higher is required?
And at that point the description for --enable-openal would
probably need to change so that it explicitly states using
openal-soft.

I thought I remembered OpenAL coming up in a discussion on
ffmpeg-devel on pkg-config sometime a few months ago
(or maybe it was on Trac?), and there was something mentioned
about OS X or file paths not always leading to the correct .pc file,
and that using pkg-config couldn't always find it.  I can't seem to
find that now, though.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Carl Eugen Hoyos]

2017-11-29 16:42 GMT+01:00 Hendrik Leppkes :
> On Wed, Nov 29, 2017 at 4:07 PM, Carl Eugen Hoyos  wrote:
>> 2017-11-29 15:58 GMT+01:00 wm4 :
>>
>>> Well, don't worry too much. People like him are, as some would say,
>>> toxic members of the community. Frequent drama and flame wars happen.
>>> (And here's where I wished ffmpeg were a properly managed project.)
>>
>> Look who's talking!
>>
>> Given that you started a fork of FFmpeg [...] Why do you post here?
>
> Forking is an integral part of open-source development.

Of course and I never had an issue with anybody because of forking.

Please try not to edit my posts to fundamentally change their meaning!

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

Re: [FFmpeg-devel] [PATCH] avcodec/dnxhddec: Do not overwrite colorspace if the container has set it.

[Michael Niedermayer]

On Tue, Nov 28, 2017 at 04:49:46PM -0800, Steven Robertson wrote:
> The existing logic overrides container metadata even in cases where the
> container metadata must be trusted (e.g. HDR). The original spec had no
> provision for specifying color volume, so many files rely on the
> assumption of Rec. 709.
> 
> An update to the spec included a 'clv' field for explicitly signaling
> that the container should be trusted in an existing bitfield in the
> frame header, but the default of 0 from old encoders forces Rec. 709,
> which would break any HDR stream. Because there is no place in DNxHR for
> specifying a transfer function, DNxHR HDR files must include
> container-level color information.
> 
> This patch maintains the existing behavior of choosing the 709 over the
> 601 matrix when container-level information is missing, and allows
> container-level information to win if present.
> 
> Signed-off-by: Steven Robertson 
> ---
>  libavcodec/dnxhddec.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
> index f46e41a456..6f8c716412 100644
> --- a/libavcodec/dnxhddec.c
> +++ b/libavcodec/dnxhddec.c

will apply

thanks

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

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


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

Re: [FFmpeg-devel] AMD external header

[Carl Eugen Hoyos]

2017-11-29 16:30 GMT+01:00 wm4 :

> You won't hear any lies from me.

That's too good to be true;-(

> But it's well known that you twist the
> truth whenever it fits you.

I finally realize that you staying anonymous to get away
with defamation.

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