Re: [FFmpeg-devel] dash encoder. Correct generated manifest for MPEG-DASH MPD Validator and calculate current bandwidth for eath chunk. Now works correctly with dash.sj

[Reuben Martin]

On Tuesday, September 6, 2016 1:56:57 PM CDT Ligverd Haer wrote:
> В письме от вторник, 6 сентября 2016 г. 12:26:49 MSK пользователь Carl Eugen
> 
> Attributes
> 
> profiles
> width
> height
> sar
> frameRate
> audioSamplingRate
> mimeType
> segmentProfiles
> codecs
> maximumSAPPeriod
> startWithSAP
> maxPlayoutRate
> codingDependency
> scanType
> 
> Common attributes for AdaptationSet and Representation shall either be in
> one of the elements but not in both.
> 
> in particular, the attribute frameRate is duplicated in the node
> Representation

There is a bug report outstanding for this:
https://trac.ffmpeg.org/ticket/5087

-Reuben

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: implement initial_offset

[Steven Liu]

2016-09-08 9:47 GMT+08:00 Aman Gupta :

> From: Aman Gupta 
>
> ---
>  doc/muxers.texi  |  4 
>  libavformat/hlsenc.c | 13 +++--
>  2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index fd7ee50..e88dbf8 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -389,6 +389,10 @@ to @var{wrap}.
>  Start the playlist sequence number from @var{number}. Default value is
>  0.
>
> +@item initial_offset @var{offset}
> +Specify timestamp offset to apply to the output packet timestamps. The
> +argument must be a time duration specification, and defaults to 0.
> +
>  @item hls_allow_cache @var{allowcache}
>  Explicitly set whether the client MAY (1) or MUST NOT (0) cache media
> segments.
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 1846d9d..be58db8 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -90,6 +90,7 @@ typedef struct HLSContext {
>  uint32_t pl_type;  // enum PlaylistType
>  char *segment_filename;
>
> +int64_t initial_offset; ///< initial timestamps offset, expressed in
> microseconds
>  int use_localtime;  ///< flag to expand filename with localtime
>  int use_localtime_mkdir;///< flag to mkdir dirname in timebased
> filename
>  int allowcache;
> @@ -795,7 +796,7 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
>  HLSContext *hls = s->priv_data;
>  AVFormatContext *oc = NULL;
>  AVStream *st = s->streams[pkt->stream_index];
> -int64_t end_pts = hls->recording_time * hls->number;
> +int64_t end_pts = hls->recording_time * hls->number, offset;
>  int is_ref_pkt = 1;
>  int ret, can_split = 1;
>  int stream_index = 0;
> @@ -871,7 +872,14 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
>  return ret;
>  }
>
> -ret = ff_write_chained(oc, stream_index, pkt, s, 0);
> +/* compute new timestamps */
> +offset = av_rescale_q(hls->initial_offset, AV_TIME_BASE_Q,
> st->time_base);
> +if (pkt->pts != AV_NOPTS_VALUE)
> +pkt->pts += offset;
> +if (pkt->dts != AV_NOPTS_VALUE)
> +pkt->dts += offset;
> +
> +ret = ff_write_chained(oc, stream_index, pkt, s, hls->initial_offset
> ? 1 : 0);
>
>  return ret;
>  }
> @@ -939,6 +947,7 @@ static const AVOption options[] = {
>  {"event", "EVENT playlist", 0, AV_OPT_TYPE_CONST, {.i64 =
> PLAYLIST_TYPE_EVENT }, INT_MIN, INT_MAX, E, "pl_type" },
>  {"vod", "VOD playlist", 0, AV_OPT_TYPE_CONST, {.i64 =
> PLAYLIST_TYPE_VOD }, INT_MIN, INT_MAX, E, "pl_type" },
>  {"method", "set the HTTP method", OFFSET(method), AV_OPT_TYPE_STRING,
> {.str = NULL},  0, 0,E},
> +{"initial_offset", "set initial timestamp offset",
> OFFSET(initial_offset), AV_OPT_TYPE_DURATION, {.i64 = 0}, -INT64_MAX,
> INT64_MAX, E },
>
>  { NULL },
>  };
> --
> 2.8.1
>
>
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/hlsenc: implement initial_offset

[Aman Gupta]

From: Aman Gupta 

---
 doc/muxers.texi  |  4 
 libavformat/hlsenc.c | 13 +++--
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index fd7ee50..e88dbf8 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -389,6 +389,10 @@ to @var{wrap}.
 Start the playlist sequence number from @var{number}. Default value is
 0.
 
+@item initial_offset @var{offset}
+Specify timestamp offset to apply to the output packet timestamps. The
+argument must be a time duration specification, and defaults to 0.
+
 @item hls_allow_cache @var{allowcache}
 Explicitly set whether the client MAY (1) or MUST NOT (0) cache media segments.
 
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 1846d9d..be58db8 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -90,6 +90,7 @@ typedef struct HLSContext {
 uint32_t pl_type;  // enum PlaylistType
 char *segment_filename;
 
+int64_t initial_offset; ///< initial timestamps offset, expressed in 
microseconds
 int use_localtime;  ///< flag to expand filename with localtime
 int use_localtime_mkdir;///< flag to mkdir dirname in timebased filename
 int allowcache;
@@ -795,7 +796,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 HLSContext *hls = s->priv_data;
 AVFormatContext *oc = NULL;
 AVStream *st = s->streams[pkt->stream_index];
-int64_t end_pts = hls->recording_time * hls->number;
+int64_t end_pts = hls->recording_time * hls->number, offset;
 int is_ref_pkt = 1;
 int ret, can_split = 1;
 int stream_index = 0;
@@ -871,7 +872,14 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 return ret;
 }
 
-ret = ff_write_chained(oc, stream_index, pkt, s, 0);
+/* compute new timestamps */
+offset = av_rescale_q(hls->initial_offset, AV_TIME_BASE_Q, st->time_base);
+if (pkt->pts != AV_NOPTS_VALUE)
+pkt->pts += offset;
+if (pkt->dts != AV_NOPTS_VALUE)
+pkt->dts += offset;
+
+ret = ff_write_chained(oc, stream_index, pkt, s, hls->initial_offset ? 1 : 
0);
 
 return ret;
 }
@@ -939,6 +947,7 @@ static const AVOption options[] = {
 {"event", "EVENT playlist", 0, AV_OPT_TYPE_CONST, {.i64 = 
PLAYLIST_TYPE_EVENT }, INT_MIN, INT_MAX, E, "pl_type" },
 {"vod", "VOD playlist", 0, AV_OPT_TYPE_CONST, {.i64 = PLAYLIST_TYPE_VOD }, 
INT_MIN, INT_MAX, E, "pl_type" },
 {"method", "set the HTTP method", OFFSET(method), AV_OPT_TYPE_STRING, 
{.str = NULL},  0, 0,E},
+{"initial_offset", "set initial timestamp offset", OFFSET(initial_offset), 
AV_OPT_TYPE_DURATION, {.i64 = 0}, -INT64_MAX, INT64_MAX, E },
 
 { NULL },
 };
-- 
2.8.1

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[James Almer]

On 9/7/2016 6:14 AM, Michael Niedermayer wrote:
>>  libavformat/utils.c  |4 +++-
>> >  tests/ref/fate/copy-trac4914 |4 ++--
>> >  tests/ref/fate/copy-trac4914-avi |4 ++--
>> >  3 files changed, 7 insertions(+), 5 deletions(-)
>> > 2dc146e807cbdbdbca653a22d827920e8c05b3c8  
>> > 0001-avformat-Export-ticks_per_frame-in-st-codec.patch
>> > From ae128325081392610475b62d0c20165e0cb9536f Mon Sep 17 00:00:00 2001
>> > From: Michael Niedermayer 
>> > Date: Tue, 6 Sep 2016 18:10:41 +0200
>> > Subject: [PATCH] avformat: Export ticks_per_frame in st->codec
>> > 
>> > Suggested-by: Hendrik Leppkes
>> > Signed-off-by: Michael Niedermayer 
> applied
> 
> with this we have restored the functionality to prior bug/regression
> so it should serve better as a reference.

Should be backported to the 3.1 branch.

Regarding this whole time_base/ticks_per_frame issue, couldn't we maybe
add both fields (merged or as is) to codecpar as Clément suggested, but
as internal/hack/nonpublic instead at least until we find a proper way
to solve the stream copy case?
I know adding private-but-not-really fields suck, but so does being stuck
here because AVI is a crappy format.

Alternatively, since until now ffmpeg.c's stream copy has been using the
initialized AVCodecContext from AVStream, can't we alloc, initialize and
use a separate one, much like it's done for actual transcoding? Would
that be enough for the decoder to set the two fields?

I'm throwing shit at the wall to see what sticks, because i barely know
half of what this whole problem entails. But i do know that the more we
bikeshed the less chances it will be resolved in a timely and adequate
manner.

For that matter, libav clearly didn't have this issue. Does that means
avconv is creating broken files in these specific cases with stream copy?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] ffmpeg: don't reconfigure terminal if we're not taking input from stdin

[Rodger Combs]

---
 ffmpeg.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index d858407..1d793fe 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -366,7 +366,7 @@ static BOOL WINAPI CtrlHandler(DWORD fdwCtrlType)
 void term_init(void)
 {
 #if HAVE_TERMIOS_H
-if(!run_as_daemon){
+if (!run_as_daemon && stdin_interaction) {
 struct termios tty;
 if (tcgetattr (0, ) == 0) {
 oldtty = tty;
@@ -4328,6 +4328,10 @@ int main(int argc, char **argv)
 
 show_banner(argc, argv, options);
 
+ret = locate_option(argc, argv, options, "stdin");
+if (ret && !strcmp(argv[ret], "-nostdin"))
+stdin_interaction = 0;
+
 term_init();
 
 /* parse options and open all input/output files */
-- 
2.9.3

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

[FFmpeg-devel] [PATCH 2/2] tests: add -nostdin flag when calling ffmpeg

[Rodger Combs]

This fixes a long-standing issue where running FATE in parallel could result
in the terminal being left misconfigured, particularly if a test failed or
was canceled wtih ^C.
---
 tests/fate/vpx.mak| 10 +-
 tests/regression-funcs.sh |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/tests/fate/vpx.mak b/tests/fate/vpx.mak
index 3750561..46658ec 100644
--- a/tests/fate/vpx.mak
+++ b/tests/fate/vpx.mak
@@ -56,19 +56,19 @@ FATE_VP8-$(CONFIG_MATROSKA_DEMUXER) += fate-vp8-alpha
 fate-vp8-alpha: CMD = framecrc -i 
$(TARGET_SAMPLES)/vp8_alpha/vp8_video_with_alpha.webm -vcodec copy
 
 FATE_VP8-$(CONFIG_WEBM_DASH_MANIFEST_DEMUXER) += fate-webm-dash-manifest
-fate-webm-dash-manifest: CMD = run $(FFMPEG) -f webm_dash_manifest -i 
$(TARGET_SAMPLES)/vp8/dash_video1.webm -f webm_dash_manifest -i 
$(TARGET_SAMPLES)/vp8/dash_video2.webm -f webm_dash_manifest -i 
$(TARGET_SAMPLES)/vp8/dash_audio1.webm -f webm_dash_manifest -i 
$(TARGET_SAMPLES)/vp8/dash_audio2.webm -c copy -map 0 -map 1 -map 2 -map 3 -f 
webm_dash_manifest -adaptation_sets "id=0,streams=0,1 id=1,streams=2,3" -
+fate-webm-dash-manifest: CMD = run $(FFMPEG) -nostdin -f webm_dash_manifest -i 
$(TARGET_SAMPLES)/vp8/dash_video1.webm -f webm_dash_manifest -i 
$(TARGET_SAMPLES)/vp8/dash_video2.webm -f webm_dash_manifest -i 
$(TARGET_SAMPLES)/vp8/dash_audio1.webm -f webm_dash_manifest -i 
$(TARGET_SAMPLES)/vp8/dash_audio2.webm -c copy -map 0 -map 1 -map 2 -map 3 -f 
webm_dash_manifest -adaptation_sets "id=0,streams=0,1 id=1,streams=2,3" -
 
 FATE_VP8-$(CONFIG_WEBM_DASH_MANIFEST_DEMUXER) += 
fate-webm-dash-manifest-unaligned-video-streams
-fate-webm-dash-manifest-unaligned-video-streams: CMD = run $(FFMPEG) -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_video1.webm -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_video3.webm -c copy -map 0 
-map 1 -f webm_dash_manifest -adaptation_sets "id=0,streams=0,1" -
+fate-webm-dash-manifest-unaligned-video-streams: CMD = run $(FFMPEG) -nostdin 
-f webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_video1.webm -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_video3.webm -c copy -map 0 
-map 1 -f webm_dash_manifest -adaptation_sets "id=0,streams=0,1" -
 
 FATE_VP8-$(CONFIG_WEBM_DASH_MANIFEST_DEMUXER) += 
fate-webm-dash-manifest-unaligned-audio-streams
-fate-webm-dash-manifest-unaligned-audio-streams: CMD = run $(FFMPEG) -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_audio1.webm -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_audio3.webm -c copy -map 0 
-map 1 -f webm_dash_manifest -adaptation_sets "id=0,streams=0,1" -
+fate-webm-dash-manifest-unaligned-audio-streams: CMD = run $(FFMPEG) -nostdin 
-f webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_audio1.webm -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_audio3.webm -c copy -map 0 
-map 1 -f webm_dash_manifest -adaptation_sets "id=0,streams=0,1" -
 
 FATE_VP8-$(CONFIG_WEBM_DASH_MANIFEST_DEMUXER) += 
fate-webm-dash-manifest-representations
-fate-webm-dash-manifest-representations: CMD = run $(FFMPEG) -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_video1.webm -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_video4.webm -c copy -map 0 
-map 1 -f webm_dash_manifest -adaptation_sets "id=0,streams=0,1" -
+fate-webm-dash-manifest-representations: CMD = run $(FFMPEG) -nostdin -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_video1.webm -f 
webm_dash_manifest -i $(TARGET_SAMPLES)/vp8/dash_video4.webm -c copy -map 0 
-map 1 -f webm_dash_manifest -adaptation_sets "id=0,streams=0,1" -
 
 FATE_VP8-$(CONFIG_WEBM_DASH_MANIFEST_DEMUXER) += fate-webm-dash-manifest-live
-fate-webm-dash-manifest-live: CMD = run $(FFMPEG) -f webm_dash_manifest -live 
1 -i $(TARGET_SAMPLES)/vp8/dash_live_video_360.hdr -f webm_dash_manifest -live 
1 -i $(TARGET_SAMPLES)/vp8/dash_live_audio_171.hdr -c copy -map 0 -map 1 -f 
webm_dash_manifest -live 1 -adaptation_sets "id=0,streams=0 id=1,streams=1" 
-chunk_start_index 1 -chunk_duration_ms 5000 -time_shift_buffer_depth 7200 
-minimum_update_period 60 -debug_mode 1 -
+fate-webm-dash-manifest-live: CMD = run $(FFMPEG) -nostdin -f 
webm_dash_manifest -live 1 -i $(TARGET_SAMPLES)/vp8/dash_live_video_360.hdr -f 
webm_dash_manifest -live 1 -i $(TARGET_SAMPLES)/vp8/dash_live_audio_171.hdr -c 
copy -map 0 -map 1 -f webm_dash_manifest -live 1 -adaptation_sets 
"id=0,streams=0 id=1,streams=1" -chunk_start_index 1 -chunk_duration_ms 5000 
-time_shift_buffer_depth 7200 -minimum_update_period 60 -debug_mode 1 -
 
 FATE_VP8-$(call DEMDEC, MATROSKA, VP8) += fate-vp8-2451
 fate-vp8-2451: CMD = framecrc -flags +bitexact -i 
$(TARGET_SAMPLES)/vp8/RRSF49-short.webm -vsync cfr -an
diff --git a/tests/regression-funcs.sh b/tests/regression-funcs.sh
index 19bceca..0c7d34b 100755
--- a/tests/regression-funcs.sh
+++ b/tests/regression-funcs.sh
@@ -43,7 +43,7 @@ echov(){
 
 . $(dirname $0)/md5.sh
 
-AVCONV_OPTS="-nostats -y -cpuflags $cpuflags"
+AVCONV_OPTS="-nostdin -nostats -y -cpuflags $cpuflags"
 

Re: [FFmpeg-devel] Possible incomplete commit "avcodec/nvenc: support RGB input"

[Sven C. Dack]

On 08/09/16 00:57, Hendrik Leppkes wrote:

The image copying code was refactored in an earlier patch to be
generic and not rely on hard-coding format info, hence the second part
is not needed anymore.



This is not quite accurate. It doesn't explain the seg. fault. This didn't 
happen in my patch and I am currently using my own version of nvenc.c where it's 
working fine and without the re-factoring. I will not make a second patch, but 
see Timo being in charge of this as he is the one who signed it off. I am going 
to "do the Pope" and have a little faith.


Sven

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: implement program_date_time

[Michael Niedermayer]

On Thu, Sep 08, 2016 at 06:38:03AM +0800, Steven Liu wrote:
> 2016-09-08 3:34 GMT+08:00 Michael Niedermayer :
> 
> > TODO: docs, version bump
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/hlsenc.c | 23 +++
> >  1 file changed, 23 insertions(+)
> >
> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > index c0b5ef2..a376312 100644
> > --- a/libavformat/hlsenc.c
> > +++ b/libavformat/hlsenc.c
> > @@ -64,6 +64,7 @@ typedef enum HLSFlags {
> >  HLS_OMIT_ENDLIST = (1 << 4),
> >  HLS_SPLIT_BY_TIME = (1 << 5),
> >  HLS_APPEND_LIST = (1 << 6),
> > +HLS_PROGRAM_DATE_TIME = (1 << 7),
> >  } HLSFlags;
> >
> >  typedef enum {
> > @@ -128,6 +129,7 @@ typedef struct HLSContext {
> >
> >  char *method;
> >
> > +double initial_prog_date_time;
> >  } HLSContext;
> >
> >  static int hls_delete_old_segments(HLSContext *hls) {
> > @@ -481,6 +483,7 @@ static int hls_window(AVFormatContext *s, int last)
> >  char *key_uri = NULL;
> >  char *iv_string = NULL;
> >  AVDictionary *options = NULL;
> > +double prog_date_time = hls->initial_prog_date_time;
> >
> >  if (!use_rename && !warned_non_file++)
> >  av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol,
> > this may lead to races and temporarly partial files\n");
> > @@ -533,6 +536,19 @@ static int hls_window(AVFormatContext *s, int last)
> >  if (hls->flags & HLS_SINGLE_FILE)
> >   avio_printf(out, "#EXT-X-BYTERANGE:%"PRIi64"@%"PRIi64"\n",
> >   en->size, en->pos);
> > +if (hls->flags & HLS_PROGRAM_DATE_TIME) {
> > +time_t tt;
> > +int milli;
> > +struct tm *tm, tmpbuf;
> > +char buf0[128], buf1[128];
> > +tt = (int64_t)prog_date_time;
> > +milli = av_clip(lrint(1000*(prog_date_time - tt)), 0, 999);
> > +tm = localtime_r(, );
> > +strftime(buf0, sizeof(buf0), "%FT%T", tm);
> > +strftime(buf1, sizeof(buf1), "%z", tm);
> > +avio_printf(out, "#EXT-X-PROGRAM-DATE-TIME:%s.%03d%s\n",
> > buf0, milli, buf1);
> > +prog_date_time += en->duration;
> > +}
> >  if (hls->baseurl)
> >  avio_printf(out, "%s", hls->baseurl);
> >  avio_printf(out, "%s\n", en->filename);
> > @@ -710,6 +726,12 @@ static int hls_write_header(AVFormatContext *s)
> >  hls->recording_time = (hls->init_time ? hls->init_time : hls->time) *
> > AV_TIME_BASE;
> >  hls->start_pts  = AV_NOPTS_VALUE;
> >
> > +if (hls->flags & HLS_PROGRAM_DATE_TIME) {
> > +time_t now0;
> > +time();
> > +hls->initial_prog_date_time = now0;
> > +}
> > +
> >  if (hls->format_options_str) {
> >  ret = av_dict_parse_string(>format_options,
> > hls->format_options_str, "=", ":", 0);
> >  if (ret < 0) {
> > @@ -1005,6 +1027,7 @@ static const AVOption options[] = {
> >  {"omit_endlist", "Do not append an endlist when ending stream", 0,
> > AV_OPT_TYPE_CONST, {.i64 = HLS_OMIT_ENDLIST }, 0, UINT_MAX,   E, "flags"},
> >  {"split_by_time", "split the hls segment by time which user set by
> > hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX,
> >  E, "flags"},
> >  {"append_list", "append the new segments into old hls segment list",
> > 0, AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX,   E, "flags"},
> > +{"program_date_time", "add EXT-X-PROGRAM-DATE-TIME", 0,
> > AV_OPT_TYPE_CONST, {.i64 = HLS_PROGRAM_DATE_TIME }, 0, UINT_MAX,   E,
> > "flags"},
> >  {"use_localtime", "set filename expansion with strftime at segment
> > creation", OFFSET(use_localtime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
> >  {"use_localtime_mkdir", "create last directory component in
> > strftime-generated filename", OFFSET(use_localtime_mkdir),
> > AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
> >  {"hls_playlist_type", "set the HLS playlist type", OFFSET(pl_type),
> > AV_OPT_TYPE_INT, {.i64 = PLAYLIST_TYPE_NONE }, 0, PLAYLIST_TYPE_NB-1, E,
> > "pl_type" },
> > --
> > 2.9.3
> >
> LGTM

applied

thanks

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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

Re: [FFmpeg-devel] [PATCH v5 5/5] avformat/tee: Use BSF list API

[Jan Sebechlebsky]

On 09/05/2016 05:42 PM, Jan Sebechlebsky wrote:


On 09/01/2016 09:42 PM, sebechlebsky...@gmail.com wrote:


From: Jan Sebechlebsky 

Signed-off-by: Jan Sebechlebsky 
---
  Changes since the last version of the patch:
  - added check for  avcodec_parameters_copy return value
  - fixed stray space
  - rewritten cycle receiving packets from bsf so case when 
av_interleaved_write_frame

returns EAGAIN is treated as error.

  libavformat/tee.c | 137 
--

  1 file changed, 70 insertions(+), 67 deletions(-)


Can I push this?

Regards,
Jan

If noone objects, I'll push this in few days.

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

Re: [FFmpeg-devel] Possible incomplete commit "avcodec/nvenc: support RGB input"

[Hendrik Leppkes]

On Wed, Sep 7, 2016 at 7:35 PM, Zoran Turalija  wrote:
> Today, new commit landed in git [1], but third part of submitted patch is
> missing in that commit. Same part is missing in patchwork [2], too. Maybe
> committer redacted patch, and threw out unneeded third part. It looks like
> patchwork was unable to recognize handmade patch sent to ML. Patch author
> was pointed on how to submit patches in future [3], but it seems future was
> faster than present.
>
> OTOH, I may be confused and all is well. If so, sorry for the noise.

The image copying code was refactored in an earlier patch to be
generic and not rely on hard-coding format info, hence the second part
is not needed anymore.

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

Re: [FFmpeg-devel] [RFC] marking non developer tickets

[Michael Niedermayer]

On Wed, Sep 07, 2016 at 10:24:15PM +0100, Josh de Kock wrote:
> On 07/09/2016 18:48, Lou Logan wrote:
> >If you want to use "task" for this then that would be fine with me.
> >
> >Alternatively, a wiki page could be setup similar to:
> >
> 
> Are all these on the trac?

probably not
carl is the one who can probably judge quickest how many of these
are missing and still relevant


> It might be worth adding a 'small'
> keyword to help people find easier coding tasks on trac (also
> keeping it central).

agree

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

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


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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: implement program_date_time

[Steven Liu]

2016-09-08 3:34 GMT+08:00 Michael Niedermayer :

> TODO: docs, version bump
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/hlsenc.c | 23 +++
>  1 file changed, 23 insertions(+)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index c0b5ef2..a376312 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -64,6 +64,7 @@ typedef enum HLSFlags {
>  HLS_OMIT_ENDLIST = (1 << 4),
>  HLS_SPLIT_BY_TIME = (1 << 5),
>  HLS_APPEND_LIST = (1 << 6),
> +HLS_PROGRAM_DATE_TIME = (1 << 7),
>  } HLSFlags;
>
>  typedef enum {
> @@ -128,6 +129,7 @@ typedef struct HLSContext {
>
>  char *method;
>
> +double initial_prog_date_time;
>  } HLSContext;
>
>  static int hls_delete_old_segments(HLSContext *hls) {
> @@ -481,6 +483,7 @@ static int hls_window(AVFormatContext *s, int last)
>  char *key_uri = NULL;
>  char *iv_string = NULL;
>  AVDictionary *options = NULL;
> +double prog_date_time = hls->initial_prog_date_time;
>
>  if (!use_rename && !warned_non_file++)
>  av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol,
> this may lead to races and temporarly partial files\n");
> @@ -533,6 +536,19 @@ static int hls_window(AVFormatContext *s, int last)
>  if (hls->flags & HLS_SINGLE_FILE)
>   avio_printf(out, "#EXT-X-BYTERANGE:%"PRIi64"@%"PRIi64"\n",
>   en->size, en->pos);
> +if (hls->flags & HLS_PROGRAM_DATE_TIME) {
> +time_t tt;
> +int milli;
> +struct tm *tm, tmpbuf;
> +char buf0[128], buf1[128];
> +tt = (int64_t)prog_date_time;
> +milli = av_clip(lrint(1000*(prog_date_time - tt)), 0, 999);
> +tm = localtime_r(, );
> +strftime(buf0, sizeof(buf0), "%FT%T", tm);
> +strftime(buf1, sizeof(buf1), "%z", tm);
> +avio_printf(out, "#EXT-X-PROGRAM-DATE-TIME:%s.%03d%s\n",
> buf0, milli, buf1);
> +prog_date_time += en->duration;
> +}
>  if (hls->baseurl)
>  avio_printf(out, "%s", hls->baseurl);
>  avio_printf(out, "%s\n", en->filename);
> @@ -710,6 +726,12 @@ static int hls_write_header(AVFormatContext *s)
>  hls->recording_time = (hls->init_time ? hls->init_time : hls->time) *
> AV_TIME_BASE;
>  hls->start_pts  = AV_NOPTS_VALUE;
>
> +if (hls->flags & HLS_PROGRAM_DATE_TIME) {
> +time_t now0;
> +time();
> +hls->initial_prog_date_time = now0;
> +}
> +
>  if (hls->format_options_str) {
>  ret = av_dict_parse_string(>format_options,
> hls->format_options_str, "=", ":", 0);
>  if (ret < 0) {
> @@ -1005,6 +1027,7 @@ static const AVOption options[] = {
>  {"omit_endlist", "Do not append an endlist when ending stream", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_OMIT_ENDLIST }, 0, UINT_MAX,   E, "flags"},
>  {"split_by_time", "split the hls segment by time which user set by
> hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX,
>  E, "flags"},
>  {"append_list", "append the new segments into old hls segment list",
> 0, AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX,   E, "flags"},
> +{"program_date_time", "add EXT-X-PROGRAM-DATE-TIME", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_PROGRAM_DATE_TIME }, 0, UINT_MAX,   E,
> "flags"},
>  {"use_localtime", "set filename expansion with strftime at segment
> creation", OFFSET(use_localtime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
>  {"use_localtime_mkdir", "create last directory component in
> strftime-generated filename", OFFSET(use_localtime_mkdir),
> AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
>  {"hls_playlist_type", "set the HLS playlist type", OFFSET(pl_type),
> AV_OPT_TYPE_INT, {.i64 = PLAYLIST_TYPE_NONE }, 0, PLAYLIST_TYPE_NB-1, E,
> "pl_type" },
> --
> 2.9.3
>
LGTM

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Pedro Arthur]

Your patch was truncated before being applied [1], someone needs to revert
and apply it properly.
[1] - http://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199079.html
​
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix potential integer overflow in mov_read_keys

[Sergey Volk]

I just realized that count+1 itself might overflow if count==UINT_MAX, so I
guess it's better to subtract 1 from the right-hand side. Attached updated
patch.

On Wed, Sep 7, 2016 at 2:21 PM, Sergey Volk  wrote:

> Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so
> we need to check that (count + 1) won't cause overflow.
>
>
From 87a7a2e202ebb63362715054773a89ce1fc71743 Mon Sep 17 00:00:00 2001
From: Sergey Volk 
Date: Wed, 7 Sep 2016 14:05:35 -0700
Subject: [PATCH] Fix potential integer overflow in mov_read_keys

Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so
we need to check that (count + 1) won't cause overflow.
---
 libavformat/mov.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index f499906..a7595c5 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3278,7 +3278,7 @@ static int mov_read_keys(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 
 avio_skip(pb, 4);
 count = avio_rb32(pb);
-if (count > UINT_MAX / sizeof(*c->meta_keys)) {
+if (count > UINT_MAX / sizeof(*c->meta_keys) - 1) {
 av_log(c->fc, AV_LOG_ERROR,
"The 'keys' atom with the invalid key count: %d\n", count);
 return AVERROR_INVALIDDATA;
-- 
2.8.0.rc3.226.g39d4020

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

[FFmpeg-devel] [PATCH] Fix potential integer overflow in mov_read_keys

[Sergey Volk]

Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so
we need to check that (count + 1) won't cause overflow.
From cfc0f5a099284c95476d5c020dca05fb743ff5ae Mon Sep 17 00:00:00 2001
From: Sergey Volk 
Date: Wed, 7 Sep 2016 14:05:35 -0700
Subject: [PATCH] Fix potential integer overflow in mov_read_keys

Actual allocation size is computed as (count + 1)*sizeof(meta_keys), so
we need to check that (count + 1) won't cause overflow.
---
 libavformat/mov.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index f499906..ea7d051 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3278,7 +3278,7 @@ static int mov_read_keys(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 
 avio_skip(pb, 4);
 count = avio_rb32(pb);
-if (count > UINT_MAX / sizeof(*c->meta_keys)) {
+if (count + 1 > UINT_MAX / sizeof(*c->meta_keys)) {
 av_log(c->fc, AV_LOG_ERROR,
"The 'keys' atom with the invalid key count: %d\n", count);
 return AVERROR_INVALIDDATA;
-- 
2.8.0.rc3.226.g39d4020

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

Re: [FFmpeg-devel] [RFC] marking non developer tickets

[Josh de Kock]

On 07/09/2016 18:48, Lou Logan wrote:

If you want to use "task" for this then that would be fine with me.

Alternatively, a wiki page could be setup similar to:



Are all these on the trac? It might be worth adding a 'small' keyword to 
help people find easier coding tasks on trac (also keeping it central).


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

Re: [FFmpeg-devel] [RFC] marking non developer tickets

[Michael Niedermayer]

On Wed, Sep 07, 2016 at 09:43:26PM +0200, Michael Niedermayer wrote:
> On Wed, Sep 07, 2016 at 09:48:55AM -0800, Lou Logan wrote:
> > On Wed, 7 Sep 2016 13:31:37 +0200, Michael Niedermayer wrote:
> > 
> > > Hi
> > > 
> > > Most of the tickets on trac are about ffmpeg code. I belive this makes
> > > it hard for non developers to find things to contribute to, yet at the
> > > same time there are quite a few non devel tasks that need to be done
> > > and that arent done ...
> > 
> > Do you have some examples of current tickets that you consider to be
> > non-developer candidates?
> 
> see link below
> 
> 
> > 
> > > Can type = task be used for non devel tasks or should a key word
> > > be added (which keyword?) or something else ?
> > 
> > If you want to use "task" for this then that would be fine with me.
> 
> ok
> 
> 
> > 
> > Alternatively, a wiki page could be setup similar to:
> > 
> > 
> > Keeping it up-to-date of course could be problematic.
> 
> yep, i think we should use tickets for this, that way a page like
> https://trac.ffmpeg.org/query?status=new=open=reopened=task=id=summary=status=type=priority=component=version=priority
> stays magically up to date

shorter URL created:
https://trac.ffmpeg.org/report/15

also link added to wiki so people can find it

if anyone has a non developer task, just open a ticket and set its
type to task

[...]

-- 
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] [RFC] marking non developer tickets

[Michael Niedermayer]

On Wed, Sep 07, 2016 at 09:48:55AM -0800, Lou Logan wrote:
> On Wed, 7 Sep 2016 13:31:37 +0200, Michael Niedermayer wrote:
> 
> > Hi
> > 
> > Most of the tickets on trac are about ffmpeg code. I belive this makes
> > it hard for non developers to find things to contribute to, yet at the
> > same time there are quite a few non devel tasks that need to be done
> > and that arent done ...
> 
> Do you have some examples of current tickets that you consider to be
> non-developer candidates?

see link below


> 
> > Can type = task be used for non devel tasks or should a key word
> > be added (which keyword?) or something else ?
> 
> If you want to use "task" for this then that would be fine with me.

ok


> 
> Alternatively, a wiki page could be setup similar to:
> 
> 
> Keeping it up-to-date of course could be problematic.

yep, i think we should use tickets for this, that way a page like
https://trac.ffmpeg.org/query?status=new=open=reopened=task=id=summary=status=type=priority=component=version=priority
stays magically up to date

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

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


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

[FFmpeg-devel] [PATCH] avformat/hlsenc: implement program_date_time

[Michael Niedermayer]

TODO: docs, version bump

Signed-off-by: Michael Niedermayer 
---
 libavformat/hlsenc.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index c0b5ef2..a376312 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -64,6 +64,7 @@ typedef enum HLSFlags {
 HLS_OMIT_ENDLIST = (1 << 4),
 HLS_SPLIT_BY_TIME = (1 << 5),
 HLS_APPEND_LIST = (1 << 6),
+HLS_PROGRAM_DATE_TIME = (1 << 7),
 } HLSFlags;
 
 typedef enum {
@@ -128,6 +129,7 @@ typedef struct HLSContext {
 
 char *method;
 
+double initial_prog_date_time;
 } HLSContext;
 
 static int hls_delete_old_segments(HLSContext *hls) {
@@ -481,6 +483,7 @@ static int hls_window(AVFormatContext *s, int last)
 char *key_uri = NULL;
 char *iv_string = NULL;
 AVDictionary *options = NULL;
+double prog_date_time = hls->initial_prog_date_time;
 
 if (!use_rename && !warned_non_file++)
 av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, this 
may lead to races and temporarly partial files\n");
@@ -533,6 +536,19 @@ static int hls_window(AVFormatContext *s, int last)
 if (hls->flags & HLS_SINGLE_FILE)
  avio_printf(out, "#EXT-X-BYTERANGE:%"PRIi64"@%"PRIi64"\n",
  en->size, en->pos);
+if (hls->flags & HLS_PROGRAM_DATE_TIME) {
+time_t tt;
+int milli;
+struct tm *tm, tmpbuf;
+char buf0[128], buf1[128];
+tt = (int64_t)prog_date_time;
+milli = av_clip(lrint(1000*(prog_date_time - tt)), 0, 999);
+tm = localtime_r(, );
+strftime(buf0, sizeof(buf0), "%FT%T", tm);
+strftime(buf1, sizeof(buf1), "%z", tm);
+avio_printf(out, "#EXT-X-PROGRAM-DATE-TIME:%s.%03d%s\n", buf0, 
milli, buf1);
+prog_date_time += en->duration;
+}
 if (hls->baseurl)
 avio_printf(out, "%s", hls->baseurl);
 avio_printf(out, "%s\n", en->filename);
@@ -710,6 +726,12 @@ static int hls_write_header(AVFormatContext *s)
 hls->recording_time = (hls->init_time ? hls->init_time : hls->time) * 
AV_TIME_BASE;
 hls->start_pts  = AV_NOPTS_VALUE;
 
+if (hls->flags & HLS_PROGRAM_DATE_TIME) {
+time_t now0;
+time();
+hls->initial_prog_date_time = now0;
+}
+
 if (hls->format_options_str) {
 ret = av_dict_parse_string(>format_options, 
hls->format_options_str, "=", ":", 0);
 if (ret < 0) {
@@ -1005,6 +1027,7 @@ static const AVOption options[] = {
 {"omit_endlist", "Do not append an endlist when ending stream", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_OMIT_ENDLIST }, 0, UINT_MAX,   E, "flags"},
 {"split_by_time", "split the hls segment by time which user set by 
hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX,   E, 
"flags"},
 {"append_list", "append the new segments into old hls segment list", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX,   E, "flags"},
+{"program_date_time", "add EXT-X-PROGRAM-DATE-TIME", 0, AV_OPT_TYPE_CONST, 
{.i64 = HLS_PROGRAM_DATE_TIME }, 0, UINT_MAX,   E, "flags"},
 {"use_localtime", "set filename expansion with strftime at segment 
creation", OFFSET(use_localtime), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
 {"use_localtime_mkdir", "create last directory component in 
strftime-generated filename", OFFSET(use_localtime_mkdir), AV_OPT_TYPE_BOOL, 
{.i64 = 0 }, 0, 1, E },
 {"hls_playlist_type", "set the HLS playlist type", OFFSET(pl_type), 
AV_OPT_TYPE_INT, {.i64 = PLAYLIST_TYPE_NONE }, 0, PLAYLIST_TYPE_NB-1, E, 
"pl_type" },
-- 
2.9.3

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/mediacodecdec_h264: use h264_parse.h instead of h264dec.h

[Matthieu Bouron]

On Wed, Sep 07, 2016 at 08:19:15PM +0200, Thomas Volkert wrote:
> 
> On 07.09.2016 15:38, Matthieu Bouron wrote:
> > On Mon, Sep 05, 2016 at 03:57:54PM +0200, Matthieu Bouron wrote:
> > > From: Matthieu Bouron 
> > > 
> > > ff_h264_decode_extradata is referenced by h264_parse.h and not
> > > h264dec.h.
> > > ---
> > >   libavcodec/mediacodecdec_h264.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/libavcodec/mediacodecdec_h264.c 
> > > b/libavcodec/mediacodecdec_h264.c
> > > index 9b71561..a141174 100644
> > > --- a/libavcodec/mediacodecdec_h264.c
> > > +++ b/libavcodec/mediacodecdec_h264.c
> > > @@ -32,7 +32,7 @@
> > >   #include "libavutil/atomic.h"
> > >   #include "avcodec.h"
> > > -#include "h264dec.h"
> > > +#include "h264_parse.h"
> > >   #include "internal.h"
> > >   #include "mediacodecdec.h"
> > >   #include "mediacodec_wrapper.h"
> > I will apply the patchset in a few hours if there is no objection.
> > 
> 
> Okay.

Pushed. Thanks.

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/mediacodecdec_h264: use h264_parse.h instead of h264dec.h

[Elijah Tully]

sounds good thanks

On Wed, Sep 7, 2016 at 2:19 PM, Thomas Volkert  wrote:

>
> On 07.09.2016 15:38, Matthieu Bouron wrote:
>
>> On Mon, Sep 05, 2016 at 03:57:54PM +0200, Matthieu Bouron wrote:
>>
>>> From: Matthieu Bouron 
>>>
>>> ff_h264_decode_extradata is referenced by h264_parse.h and not
>>> h264dec.h.
>>> ---
>>>   libavcodec/mediacodecdec_h264.c | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/mediacodecdec_h264.c
>>> b/libavcodec/mediacodecdec_h264.c
>>> index 9b71561..a141174 100644
>>> --- a/libavcodec/mediacodecdec_h264.c
>>> +++ b/libavcodec/mediacodecdec_h264.c
>>> @@ -32,7 +32,7 @@
>>>   #include "libavutil/atomic.h"
>>> #include "avcodec.h"
>>> -#include "h264dec.h"
>>> +#include "h264_parse.h"
>>>   #include "internal.h"
>>>   #include "mediacodecdec.h"
>>>   #include "mediacodec_wrapper.h"
>>>
>> I will apply the patchset in a few hours if there is no objection.
>>
>>
> Okay.
>
> Best regards,
> Thomas.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] requested feature

[Elijah Tully]

Hello just wondering if you guys would mind adding the ability to encode to
gamecube adp format soon. thanks in advance for any help :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavc/mediacodecdec_h264: use h264_parse.h instead of h264dec.h

[Thomas Volkert]

On 07.09.2016 15:38, Matthieu Bouron wrote:

On Mon, Sep 05, 2016 at 03:57:54PM +0200, Matthieu Bouron wrote:

From: Matthieu Bouron 

ff_h264_decode_extradata is referenced by h264_parse.h and not
h264dec.h.
---
  libavcodec/mediacodecdec_h264.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
index 9b71561..a141174 100644
--- a/libavcodec/mediacodecdec_h264.c
+++ b/libavcodec/mediacodecdec_h264.c
@@ -32,7 +32,7 @@
  #include "libavutil/atomic.h"
  
  #include "avcodec.h"

-#include "h264dec.h"
+#include "h264_parse.h"
  #include "internal.h"
  #include "mediacodecdec.h"
  #include "mediacodec_wrapper.h"

I will apply the patchset in a few hours if there is no objection.



Okay.

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

[FFmpeg-devel] Possible incomplete commit "avcodec/nvenc: support RGB input"

[Zoran Turalija]

Today, new commit landed in git [1], but third part of submitted patch is
missing in that commit. Same part is missing in patchwork [2], too. Maybe
committer redacted patch, and threw out unneeded third part. It looks like
patchwork was unable to recognize handmade patch sent to ML. Patch author
was pointed on how to submit patches in future [3], but it seems future was
faster than present.

OTOH, I may be confused and all is well. If so, sorry for the noise.

PS. I'm not subscribed to this ML, so I could not reply to correct thread.

[1] 
https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/4aeb7a88ec69aff6490e7f94f5987f7525b7eab7
[2] https://patchwork.ffmpeg.org/patch/464/
[3] https://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199051.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] ffmpeg-memory leak

[lium...@fsmeeting.com]

hello，Maybe I find a bug about the memory leak，I try to use  the 
function“avformat_open_input”to open the file， after that，I  use the function 
“avformat_close_input”，My memroy will increase several hundred KB，even several  
MB, if My media file's resolution is bigger, the memory leak will be bigger

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

Re: [FFmpeg-devel] [RFC] marking non developer tickets

[Lou Logan]

On Wed, 7 Sep 2016 13:31:37 +0200, Michael Niedermayer wrote:

> Hi
> 
> Most of the tickets on trac are about ffmpeg code. I belive this makes
> it hard for non developers to find things to contribute to, yet at the
> same time there are quite a few non devel tasks that need to be done
> and that arent done ...

Do you have some examples of current tickets that you consider to be
non-developer candidates?

> Can type = task be used for non devel tasks or should a key word
> be added (which keyword?) or something else ?

If you want to use "task" for this then that would be fine with me.

Alternatively, a wiki page could be setup similar to:


Keeping it up-to-date of course could be problematic.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Timo Rothenpieler]

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

Re: [FFmpeg-devel] [PATCH]ffmpeg_opt: Suggest to use "file:..." if a protocol was not found

[Carl Eugen Hoyos]

2016-09-06 12:57 GMT+02:00 Michael Niedermayer :
>> Subject: [PATCH] ffmpeg_opt: Suggest to use "file:..." if a
>> protocol was not found.
>>
>> Fixes Debian bug 785690.
>> ---
>>  ffmpeg_opt.c |2 ++
>>  1 file changed, 2 insertions(+)
>
> LGTM
>
> please give others a day to comment before applying

Patch applied.

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

Re: [FFmpeg-devel] [PATCH 1/2] tests/fate:Add FATE for hls_flags append option

[Steven Liu]

2016-09-08 0:41 GMT+08:00 Michael Niedermayer :

> On Wed, Sep 07, 2016 at 11:10:48PM +0800, Steven Liu wrote:
> > 2016-08-30 2:07 GMT+08:00 Michael Niedermayer :
> >
> > > On Mon, Aug 29, 2016 at 11:17:25PM +0800, Steven Liu wrote:
> > > > 2016-08-29 22:18 GMT+08:00 Michael Niedermayer
> :
> > > >
> > > > > On Mon, Aug 29, 2016 at 07:52:23PM +0800, Steven Liu wrote:
> > > > > > 2016-08-26 0:11 GMT+08:00 Michael Niedermayer
>  > > >:
> > > > > >
> > > > > > > On Thu, Aug 25, 2016 at 09:04:43PM +0800, Steven Liu wrote:
> > > > > > > >  Tested passed at :
> > > > > > > > 1. OSX
> > > > > > > > 2. Linux
> > > > > > > > 3. Windows
> > > > > > >
> > > > > > > > 4. Ubuntu+wine+MinGW
> > > > > > >
> > > > > > > confirmed it works
> > > > > > > but
> > > > > > > doesnt work on qemu-mips
> > > > > > > ../configure --target-exec='.../qemu-mips -cpu 74Kf -L
> > > > > > > /usr/mips-linux-gnu/' \
> > > > > > > --samples=... --enable-gpl --cross-prefix=/usr/mips-
> linux-gnu/bin/
> > > \
> > > > > > > --cc='ccache mips-linux-gnu-gcc-4.4' --arch=mips
> --target-os=linux
> > > > > > > --enable-cross-compile --disable-pthreads --disable-mipsfpu
> > > > > --disable-iconv
> > > > > > >
> > > > > > > make distclean ; ./c-qemu  && make -j12 fate-filter-hls-append
> > > > > > > first it fails with
> > > > > > > GEN tests/data/hls-list-append.m3u8
> > > > > > > make: *** [tests/data/hls-list-append.m3u8] Error 255
> > > > > > >
> > > > > > > reruning make -j12 fate-filter-hls-append
> > > > > > > results in:
> > > > > > >
> > > > > > > --- tests/ref/fate/filter-hls-append2016-08-25
> > > 17:43:18.565618034
> > > > > > > +0200
> > > > > > > +++ tests/data/fate/filter-hls-append   2016-08-25
> > > 17:47:18.681623092
> > > > > > > +0200
> > > > > > > @@ -3,1154 +3,770 @@
> > > > > > >  #codec_id 0: pcm_s16le
> > > > > > >  #sample_rate 0: 44100
> > > > > > >  #channel_layout 0: 4
> > > > > > > -0,  0,  0, 1152, 2304, 0x593ea430
> > > > > > > -0,   1152,   1152, 1152, 2304, 0xde328304
> > > > > > > -0,   2304,   2304, 1152, 2304, 0x12f673c9
> > > > > > > -0,   3456,   3456, 1152, 2304, 0x4c7672a1
> > > > > > > -0,   4608,   4608, 1152, 2304, 0xd38577f4
> > > > > > > -0,   5760,   5760, 1152, 2304, 0xc9d677cc
> > > > > > > -0,   6912,   6912, 1152, 2304, 0xc97e882a
> > > > > > > -0,   8064,   8064, 1152, 2304, 0xaacf67ec
> > > > > > > -0,   9216,   9216, 1152, 2304, 0x3a9b7ea5
> > > > > > > -0,  10368,  10368, 1152, 2304, 0x30258348
> > > > > > > -0,  11520,  11520, 1152, 2304, 0x08da8783
> > > > > > > -0,  12672,  12672, 1152, 2304, 0x4830619e
> > > > > > > -0,  13824,  13824, 1152, 2304, 0xcf476f69
> > > > > > > -0,  14976,  14976, 1152, 2304, 0x377e7ce5
> > > > > > > -0,  16128,  16128, 1152, 2304, 0x00a27fad
> > > > > > > -0,  17280,  17280, 1152, 2304, 0xe4a46de3
> > > > > > > -0,  18432,  18432, 1152, 2304, 0x938c8751
> > > > > > > -0,  19584,  19584, 1152, 2304, 0x239982b5
> > > > > > > -0,  20736,  20736, 1152, 2304, 0x9a0d7655
> > > > > > > -0,  21888,  21888, 1152, 2304, 0x4adf7fbf
> > > > > > > -0,  23040,  23040, 1152, 2304, 0xdb8b7b16
> > > > > > > -0,  24192,  24192, 1152, 2304, 0x25908560
> > > > > > > -0,  25344,  25344, 1152, 2304, 0xb5dd7be7
> > > > > > > -0,  26496,  26496, 1152, 2304, 0x4368796d
> > > > > > > -0,  27648,  27648, 1152, 2304, 0xba3a7fd0
> > > > > > > ...
> > > > > > > make: *** [fate-filter-hls-append] Error 1
> > > > > > >
> > > > > > > [...]
> > > > > > >
> > > > > > >
> > > > > > > Is this base on Ubuntu? What's the Ubuntu version?
> > > > >
> > > > > the build environment was from emdebian, i am still using it as it
> > > > > still works flawless, mips qemu was built from source long ago, i
> would
> > > > > expect the qemu from ubuntu to work fine.
> > > > >
> > > > > Does it work for you with whatever version is easily available to
> you?
> > > > >
> > > > > :D Because i'm not a debian and ubuntu user,
> > > > I usually using CentOS and OSX on x86,
> > > > So i'm learning how to use ubuntu and mips arm for FATE :D
> > >
> > > if you have a cross build env for mips in centos and qemu that
> > > should give similar results
> > > i would be surprised if the exact linux distro woul make a difference
> > >
> > > --
> > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
> 87040B0FAB
> > >
> > > I do not agree with what you have to say, but I'll defend to the death
> your
> > > right to say it. -- Voltaire
> > >
> >
> >
> > Patch update!
> >
> > That's ok on qemu+mips , Linux , 

Re: [FFmpeg-devel] [PATCH]lavc/avcodec: Improve av_parser_parse() documentation

[Carl Eugen Hoyos]

2016-09-04 22:41 GMT+02:00 Michael Niedermayer :

>> Fixes ticket #5809.
>> ---
>>  libavcodec/avcodec.h |5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> LGTM, but please wait a day or 2 to allow others to comment

Patch applied.

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

Re: [FFmpeg-devel] [PATCH 1/2] tests/fate:Add FATE for hls_flags append option

[Michael Niedermayer]

On Wed, Sep 07, 2016 at 11:10:48PM +0800, Steven Liu wrote:
> 2016-08-30 2:07 GMT+08:00 Michael Niedermayer :
> 
> > On Mon, Aug 29, 2016 at 11:17:25PM +0800, Steven Liu wrote:
> > > 2016-08-29 22:18 GMT+08:00 Michael Niedermayer :
> > >
> > > > On Mon, Aug 29, 2016 at 07:52:23PM +0800, Steven Liu wrote:
> > > > > 2016-08-26 0:11 GMT+08:00 Michael Niedermayer  > >:
> > > > >
> > > > > > On Thu, Aug 25, 2016 at 09:04:43PM +0800, Steven Liu wrote:
> > > > > > >  Tested passed at :
> > > > > > > 1. OSX
> > > > > > > 2. Linux
> > > > > > > 3. Windows
> > > > > >
> > > > > > > 4. Ubuntu+wine+MinGW
> > > > > >
> > > > > > confirmed it works
> > > > > > but
> > > > > > doesnt work on qemu-mips
> > > > > > ../configure --target-exec='.../qemu-mips -cpu 74Kf -L
> > > > > > /usr/mips-linux-gnu/' \
> > > > > > --samples=... --enable-gpl --cross-prefix=/usr/mips-linux-gnu/bin/
> > \
> > > > > > --cc='ccache mips-linux-gnu-gcc-4.4' --arch=mips --target-os=linux
> > > > > > --enable-cross-compile --disable-pthreads --disable-mipsfpu
> > > > --disable-iconv
> > > > > >
> > > > > > make distclean ; ./c-qemu  && make -j12 fate-filter-hls-append
> > > > > > first it fails with
> > > > > > GEN tests/data/hls-list-append.m3u8
> > > > > > make: *** [tests/data/hls-list-append.m3u8] Error 255
> > > > > >
> > > > > > reruning make -j12 fate-filter-hls-append
> > > > > > results in:
> > > > > >
> > > > > > --- tests/ref/fate/filter-hls-append2016-08-25
> > 17:43:18.565618034
> > > > > > +0200
> > > > > > +++ tests/data/fate/filter-hls-append   2016-08-25
> > 17:47:18.681623092
> > > > > > +0200
> > > > > > @@ -3,1154 +3,770 @@
> > > > > >  #codec_id 0: pcm_s16le
> > > > > >  #sample_rate 0: 44100
> > > > > >  #channel_layout 0: 4
> > > > > > -0,  0,  0, 1152, 2304, 0x593ea430
> > > > > > -0,   1152,   1152, 1152, 2304, 0xde328304
> > > > > > -0,   2304,   2304, 1152, 2304, 0x12f673c9
> > > > > > -0,   3456,   3456, 1152, 2304, 0x4c7672a1
> > > > > > -0,   4608,   4608, 1152, 2304, 0xd38577f4
> > > > > > -0,   5760,   5760, 1152, 2304, 0xc9d677cc
> > > > > > -0,   6912,   6912, 1152, 2304, 0xc97e882a
> > > > > > -0,   8064,   8064, 1152, 2304, 0xaacf67ec
> > > > > > -0,   9216,   9216, 1152, 2304, 0x3a9b7ea5
> > > > > > -0,  10368,  10368, 1152, 2304, 0x30258348
> > > > > > -0,  11520,  11520, 1152, 2304, 0x08da8783
> > > > > > -0,  12672,  12672, 1152, 2304, 0x4830619e
> > > > > > -0,  13824,  13824, 1152, 2304, 0xcf476f69
> > > > > > -0,  14976,  14976, 1152, 2304, 0x377e7ce5
> > > > > > -0,  16128,  16128, 1152, 2304, 0x00a27fad
> > > > > > -0,  17280,  17280, 1152, 2304, 0xe4a46de3
> > > > > > -0,  18432,  18432, 1152, 2304, 0x938c8751
> > > > > > -0,  19584,  19584, 1152, 2304, 0x239982b5
> > > > > > -0,  20736,  20736, 1152, 2304, 0x9a0d7655
> > > > > > -0,  21888,  21888, 1152, 2304, 0x4adf7fbf
> > > > > > -0,  23040,  23040, 1152, 2304, 0xdb8b7b16
> > > > > > -0,  24192,  24192, 1152, 2304, 0x25908560
> > > > > > -0,  25344,  25344, 1152, 2304, 0xb5dd7be7
> > > > > > -0,  26496,  26496, 1152, 2304, 0x4368796d
> > > > > > -0,  27648,  27648, 1152, 2304, 0xba3a7fd0
> > > > > > ...
> > > > > > make: *** [fate-filter-hls-append] Error 1
> > > > > >
> > > > > > [...]
> > > > > >
> > > > > >
> > > > > > Is this base on Ubuntu? What's the Ubuntu version?
> > > >
> > > > the build environment was from emdebian, i am still using it as it
> > > > still works flawless, mips qemu was built from source long ago, i would
> > > > expect the qemu from ubuntu to work fine.
> > > >
> > > > Does it work for you with whatever version is easily available to you?
> > > >
> > > > :D Because i'm not a debian and ubuntu user,
> > > I usually using CentOS and OSX on x86,
> > > So i'm learning how to use ubuntu and mips arm for FATE :D
> >
> > if you have a cross build env for mips in centos and qemu that
> > should give similar results
> > i would be surprised if the exact linux distro woul make a difference
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > I do not agree with what you have to say, but I'll defend to the death your
> > right to say it. -- Voltaire
> >
> 
> 
> Patch update!
> 
> That's ok on qemu+mips , Linux , wine+MinGW, OSX now.
> 
> 
> QEMU+MIPS:
> 
> lq@ubuntu:~/ffmpeg/mips$ make fate-filter-hls-append
> HOSTCC tests/base64.o
> HOSTLD tests/base64
> HOSTCC tests/tiny_psnr.o
> HOSTLD tests/tiny_psnr
> HOSTCC tests/tiny_ssim.o
> HOSTLD tests/tiny_ssim
> HOSTCC tests/audiomatch.o
> HOSTLD tests/audiomatch

Re: [FFmpeg-devel] [PATCH 2/5] af_hdcd: hdcd_analyze_gen() using int instead of float

[Burt P.]

applied

as is for now.

Thanks for the comment. I will look into a faster way of doing it.
I only needed to change from the float version because it was giving
different results for i686 than for amd64.
I don't know why, exactly, but I do know that this version gives
bit-perfect results everywhere I've tried it.

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

Re: [FFmpeg-devel] [PATCH 1/5] af_hdcd: some types renamed to remove _t

[Burt P.]

applied

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

Re: [FFmpeg-devel] [PATCH 3/5] af_hdcd: fix possible integer overflow

[Burt P.]

applied

with fix:
uint64_t sustain_reset = (uint64_t)cdt_ms * rate / 1000;

Thank you, Michael.

-- 
Burt

On Tue, Sep 6, 2016 at 5:00 PM, Michael Niedermayer
 wrote:
> On Mon, Sep 05, 2016 at 06:18:43AM -0500, Burt P wrote:
>> Signed-off-by: Burt P 
>> ---
>>  libavfilter/af_hdcd.c | 9 -
>>  1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
>> index c8bda82..c249589 100644
>> --- a/libavfilter/af_hdcd.c
>> +++ b/libavfilter/af_hdcd.c
>> @@ -1004,16 +1004,15 @@ AVFILTER_DEFINE_CLASS(hdcd);
>>  static void hdcd_reset(hdcd_state *state, unsigned rate, unsigned cdt_ms)
>>  {
>>  int i;
>> +uint64_t sustain_reset = cdt_ms * rate / 1000;
>
> this can still overflow
> cdt_ms and rate are 32bit their product is 32bit divided by 1000
> its around 22 bit, the 64bit is too late
>
>
>>
>>  state->window = 0;
>>  state->readahead = 32;
>>  state->arg = 0;
>>  state->control = 0;
>> -
>>  state->running_gain = 0;
>> -
>> +state->sustain_reset = sustain_reset;
>>  state->sustain = 0;
>> -state->sustain_reset = cdt_ms*rate/1000;
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The worst form of inequality is to try to make unequal things equal.
> -- Aristotle
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>



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

Re: [FFmpeg-devel] [PATCH 4/5] af_hdcd: move decoding setup from init to config_input

[Burt P.]

applied

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

Re: [FFmpeg-devel] [PATCH 5/5] af_hdcd: tweak hdcd_analyze_prepare() a bit

[Burt P.]

applied

On Mon, Sep 5, 2016 at 6:18 AM, Burt P  wrote:
> * use the actual sample rate
> * use a more sensible frequency for the tone
> * update fate test result
>
> Signed-off-by: Burt P 
> ---
>  libavfilter/af_hdcd.c   | 9 ++---
>  tests/fate/filter-audio.mak | 2 +-
>  2 files changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
> index 1487a0b..fde6b7b 100644
> --- a/libavfilter/af_hdcd.c
> +++ b/libavfilter/af_hdcd.c
> @@ -871,6 +871,7 @@ typedef struct {
>   *  a code. -1 for timer never set. */
>  int count_sustain_expired;
>
> +int rate;   /**< sampling rate */
>  int _ana_snb;   /**< used in the analyze mode tone generator 
> */
>  } hdcd_state;
>
> @@ -1026,6 +1027,7 @@ static void hdcd_reset(hdcd_state *state, unsigned 
> rate, unsigned cdt_ms)
>  state->max_gain = 0;
>  state->count_sustain_expired = -1;
>
> +state->rate = rate;
>  state->_ana_snb = 0;
>  }
>
> @@ -1297,7 +1299,8 @@ static int hdcd_scan_stereo(HDCDContext *ctx, const 
> int32_t *samples, int max)
>
>  /** replace audio with solid tone, but save LSBs */
>  static void hdcd_analyze_prepare(hdcd_state *state, int32_t *samples, int 
> count, int stride) {
> -int n;
> +int n, f = 300;
> +int so = state->rate / f;
>  for (n = 0; n < count * stride; n += stride) {
>  /* in analyze mode, the audio is replaced by a solid tone, and
>   * amplitude is changed to signal when the specified feature is
> @@ -1306,9 +1309,9 @@ static void hdcd_analyze_prepare(hdcd_state *state, 
> int32_t *samples, int count,
>   * bit 1: Original sample was above PE level */
>  int32_t save = (abs(samples[n]) - PEAK_EXT_LEVEL >= 0) ? 2 : 0; /* 
> above PE level */
>  save |= samples[n] & 1;  /* save LSB for HDCD 
> packets */
> -samples[n] = TONEGEN16(state->_ana_snb, 277.18, 44100, 0.1);
> +samples[n] = TONEGEN16(state->_ana_snb, f, state->rate, 0.1);
>  samples[n] = (samples[n] | 3) ^ ((~save) & 3);
> -if (++state->_ana_snb > 0x3fff) state->_ana_snb = 0;
> +if (++state->_ana_snb > so) state->_ana_snb = 0;
>  }
>  }
>
> diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
> index 2066fa9..cf92ef6 100644
> --- a/tests/fate/filter-audio.mak
> +++ b/tests/fate/filter-audio.mak
> @@ -242,7 +242,7 @@ FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, 
> FLAC, FLAC, PCM_S24LE, PCM
>  fate-filter-hdcd-analyze: SRC = $(TARGET_SAMPLES)/filter/hdcd.flac
>  fate-filter-hdcd-analyze: CMD = md5 -i $(SRC) -af hdcd=analyze_mode=pe -f 
> s24le
>  fate-filter-hdcd-analyze: CMP = oneline
> -fate-filter-hdcd-analyze: REF = 81a4f00f85a585bc0198e9a0670a8cde
> +fate-filter-hdcd-analyze: REF = 6e39dc4629c1e84321c0d8bc069b42f6
>
>  FATE_AFILTER_SAMPLES-$(call FILTERDEMDECENCMUX, HDCD, FLAC, FLAC, PCM_S24LE, 
> PCM_S24LE) += fate-filter-hdcd-false-positive
>  fate-filter-hdcd-false-positive: SRC = 
> $(TARGET_SAMPLES)/filter/hdcd-false-positive.flac
> --
> 2.7.4
>



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

Re: [FFmpeg-devel] [PATCH 1/2] tests/fate:Add FATE for hls_flags append option

[Steven Liu]

2016-08-30 2:07 GMT+08:00 Michael Niedermayer :

> On Mon, Aug 29, 2016 at 11:17:25PM +0800, Steven Liu wrote:
> > 2016-08-29 22:18 GMT+08:00 Michael Niedermayer :
> >
> > > On Mon, Aug 29, 2016 at 07:52:23PM +0800, Steven Liu wrote:
> > > > 2016-08-26 0:11 GMT+08:00 Michael Niedermayer  >:
> > > >
> > > > > On Thu, Aug 25, 2016 at 09:04:43PM +0800, Steven Liu wrote:
> > > > > >  Tested passed at :
> > > > > > 1. OSX
> > > > > > 2. Linux
> > > > > > 3. Windows
> > > > >
> > > > > > 4. Ubuntu+wine+MinGW
> > > > >
> > > > > confirmed it works
> > > > > but
> > > > > doesnt work on qemu-mips
> > > > > ../configure --target-exec='.../qemu-mips -cpu 74Kf -L
> > > > > /usr/mips-linux-gnu/' \
> > > > > --samples=... --enable-gpl --cross-prefix=/usr/mips-linux-gnu/bin/
> \
> > > > > --cc='ccache mips-linux-gnu-gcc-4.4' --arch=mips --target-os=linux
> > > > > --enable-cross-compile --disable-pthreads --disable-mipsfpu
> > > --disable-iconv
> > > > >
> > > > > make distclean ; ./c-qemu  && make -j12 fate-filter-hls-append
> > > > > first it fails with
> > > > > GEN tests/data/hls-list-append.m3u8
> > > > > make: *** [tests/data/hls-list-append.m3u8] Error 255
> > > > >
> > > > > reruning make -j12 fate-filter-hls-append
> > > > > results in:
> > > > >
> > > > > --- tests/ref/fate/filter-hls-append2016-08-25
> 17:43:18.565618034
> > > > > +0200
> > > > > +++ tests/data/fate/filter-hls-append   2016-08-25
> 17:47:18.681623092
> > > > > +0200
> > > > > @@ -3,1154 +3,770 @@
> > > > >  #codec_id 0: pcm_s16le
> > > > >  #sample_rate 0: 44100
> > > > >  #channel_layout 0: 4
> > > > > -0,  0,  0, 1152, 2304, 0x593ea430
> > > > > -0,   1152,   1152, 1152, 2304, 0xde328304
> > > > > -0,   2304,   2304, 1152, 2304, 0x12f673c9
> > > > > -0,   3456,   3456, 1152, 2304, 0x4c7672a1
> > > > > -0,   4608,   4608, 1152, 2304, 0xd38577f4
> > > > > -0,   5760,   5760, 1152, 2304, 0xc9d677cc
> > > > > -0,   6912,   6912, 1152, 2304, 0xc97e882a
> > > > > -0,   8064,   8064, 1152, 2304, 0xaacf67ec
> > > > > -0,   9216,   9216, 1152, 2304, 0x3a9b7ea5
> > > > > -0,  10368,  10368, 1152, 2304, 0x30258348
> > > > > -0,  11520,  11520, 1152, 2304, 0x08da8783
> > > > > -0,  12672,  12672, 1152, 2304, 0x4830619e
> > > > > -0,  13824,  13824, 1152, 2304, 0xcf476f69
> > > > > -0,  14976,  14976, 1152, 2304, 0x377e7ce5
> > > > > -0,  16128,  16128, 1152, 2304, 0x00a27fad
> > > > > -0,  17280,  17280, 1152, 2304, 0xe4a46de3
> > > > > -0,  18432,  18432, 1152, 2304, 0x938c8751
> > > > > -0,  19584,  19584, 1152, 2304, 0x239982b5
> > > > > -0,  20736,  20736, 1152, 2304, 0x9a0d7655
> > > > > -0,  21888,  21888, 1152, 2304, 0x4adf7fbf
> > > > > -0,  23040,  23040, 1152, 2304, 0xdb8b7b16
> > > > > -0,  24192,  24192, 1152, 2304, 0x25908560
> > > > > -0,  25344,  25344, 1152, 2304, 0xb5dd7be7
> > > > > -0,  26496,  26496, 1152, 2304, 0x4368796d
> > > > > -0,  27648,  27648, 1152, 2304, 0xba3a7fd0
> > > > > ...
> > > > > make: *** [fate-filter-hls-append] Error 1
> > > > >
> > > > > [...]
> > > > >
> > > > >
> > > > > Is this base on Ubuntu? What's the Ubuntu version?
> > >
> > > the build environment was from emdebian, i am still using it as it
> > > still works flawless, mips qemu was built from source long ago, i would
> > > expect the qemu from ubuntu to work fine.
> > >
> > > Does it work for you with whatever version is easily available to you?
> > >
> > > :D Because i'm not a debian and ubuntu user,
> > I usually using CentOS and OSX on x86,
> > So i'm learning how to use ubuntu and mips arm for FATE :D
>
> if you have a cross build env for mips in centos and qemu that
> should give similar results
> i would be surprised if the exact linux distro woul make a difference
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I do not agree with what you have to say, but I'll defend to the death your
> right to say it. -- Voltaire
>


Patch update!

That's ok on qemu+mips , Linux , wine+MinGW, OSX now.


QEMU+MIPS:

lq@ubuntu:~/ffmpeg/mips$ make fate-filter-hls-append
HOSTCC tests/base64.o
HOSTLD tests/base64
HOSTCC tests/tiny_psnr.o
HOSTLD tests/tiny_psnr
HOSTCC tests/tiny_ssim.o
HOSTLD tests/tiny_ssim
HOSTCC tests/audiomatch.o
HOSTLD tests/audiomatch
GEN tests/data/hls-list-append.m3u8
TESTfilter-hls-append
lq@ubuntu:~/ffmpeg/mips$ uname -a
Linux ubuntu 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux
lq@ubuntu:~/ffmpeg/mips$ file ./ffmpeg
./ffmpeg: ELF 32-bit MSB executable, MIPS, MIPS32 

Re: [FFmpeg-devel] [PATCH] doc/developer: Add patchwork mentioning to "patch submission checklist"

[Michael Niedermayer]

On Wed, Sep 07, 2016 at 04:44:54PM +0200, Michael Niedermayer wrote:
> On Wed, Sep 07, 2016 at 04:39:54PM +0200, Michael Niedermayer wrote:
> > On Wed, Sep 07, 2016 at 07:19:00AM -0700, Jonathan Campbell wrote:
> > > On 09/07/2016 04:51 AM, Michael Niedermayer wrote:
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  doc/developer.texi | 6 ++
> > > >  1 file changed, 6 insertions(+)
> > > > 
> > > > diff --git a/doc/developer.texi b/doc/developer.texi
> > > > index 4d3a7ae..51e3da7 100644
> > > > --- a/doc/developer.texi
> > > > +++ b/doc/developer.texi
> > > > @@ -641,6 +641,12 @@ are notoriously left unchecked, which is a serious 
> > > > problem.
> > > >  @item
> > > >  Test your code with valgrind and or Address Sanitizer to ensure it's 
> > > > free
> > > >  of leaks, out of array accesses, etc.
> > > > +
> > > > +@item
> > > > +Check that your submitted patch shows up on 
> > > > @url{https://patchwork.ffmpeg.org}.
> > > > +Also make sure its status is updated, you can create an account and 
> > > > update it.
> > > > +If your patch is incorrectly or not listed in patchwork then it might 
> > > > be
> > > > +missed by developers using patchwork to find patches needing review or 
> > > > pushing.
> > > >  @end enumerate
> > > >  
> > > >  @section Patch review process
> > > > 
> > > 
> > > I only see one of the 4 patches for AC-3 consistent noise generation (the 
> > > libavutil version bump) on the patchwork site. Can I assume the other 
> > > three will make their way into the patchwork list when the time is right, 
> > > or did I submit the patch wrong?
> > 
> > all 4 patches are there:
> > https://patchwork.ffmpeg.org/project/ffmpeg/list/?submitter=82=%2A=both
> 
> in fact thats the 4 mails not the 4 patches from the last mail
> patchwork does not support multiple patches per mail AFAIK

and MUAs cant keep properly track of multiple patches per mail either
a mail is either read or unread or otherwise flagged somehow, so
patchwork is in fact not really worse than using a MUA here


[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

Re: [FFmpeg-devel] [PATCH] doc/developer: Add patchwork mentioning to "patch submission checklist"

[Michael Niedermayer]

On Wed, Sep 07, 2016 at 02:27:07PM +0200, Michael Niedermayer wrote:
> On Wed, Sep 07, 2016 at 08:03:20AM -0400, Ronald S. Bultje wrote:
> > Hi,
> > 
> > On Wed, Sep 7, 2016 at 7:51 AM, Michael Niedermayer 
> > wrote:
> > 
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  doc/developer.texi | 6 ++
> > >  1 file changed, 6 insertions(+)
> > >
> > > diff --git a/doc/developer.texi b/doc/developer.texi
> > > index 4d3a7ae..51e3da7 100644
> > > --- a/doc/developer.texi
> > > +++ b/doc/developer.texi
> > > @@ -641,6 +641,12 @@ are notoriously left unchecked, which is a serious
> > > problem.
> > >  @item
> > >  Test your code with valgrind and or Address Sanitizer to ensure it's free
> > >  of leaks, out of array accesses, etc.
> > > +
> > > +@item
> > > +Check that your submitted patch shows up on @url{
> > > https://patchwork.ffmpeg.org}.
> > > +Also make sure its status is updated, you can create an account and
> > > update it.
> > > +If your patch is incorrectly or not listed in patchwork then it might be
> > > +missed by developers using patchwork to find patches needing review or
> > > pushing.
> > >  @end enumerate
> > 
> > 
> > I don't think we should require developers to use (or check, or update, or
> > create-an-account-on) patchwork. Wasn't the whole point of patchwork that
> > you can use it if you care, and you can ignore it if you don't care?
> 
> yes one can ignore it but its alot more usefull if people keep in
> mind that theres patchwork.
> 
> For example, if you reply with LGTM or Acked-by: or Reviewed-by:
> or Tested-by:
> patchwork will pick that up, OTOH if you write "that works well,
> i tested it" patchwork will not pick that up, nor will it "dude that
> looks fine, please push it" nor does it "I dont like that change"
> 
> the result of that is that if everyone ignores patchwork it will
> contain most submited patches (some odd non standard attachmets are
> missed)

also due to this, people using patchwork to find patches that need a
review will miss patches that patchwork didnt pick up. So its useful
if such not picked up patches are 0
Iam one of the people using patchwork to keep track of patches still
needing review or application if i dont review them immedeatly.
Using my MUA for this has become too painfull and
inefficient and noone else knows whats marked as unread (needing review)
in my MUA, anyone knows what still needs a review in patchwork as its
vissible to the world

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"


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

[FFmpeg-devel] [PATCH 2/2] lavc: add hevc mediacodec decoder

[Matthieu Bouron]

From: Matthieu Bouron 

---
 configure  |   3 +
 libavcodec/Makefile|   3 +-
 libavcodec/allcodecs.c |   2 +
 libavcodec/hevc_parse.c| 134 ++
 libavcodec/hevc_parse.h|  33 
 libavcodec/mediacodecdec.c |   7 +
 ...{mediacodecdec_h264.c => mediacodecdec_h2645.c} | 198 ++---
 7 files changed, 351 insertions(+), 29 deletions(-)
 create mode 100644 libavcodec/hevc_parse.c
 create mode 100644 libavcodec/hevc_parse.h
 rename libavcodec/{mediacodecdec_h264.c => mediacodecdec_h2645.c} (68%)

diff --git a/configure b/configure
index b11ca7f..af3fbf4 100755
--- a/configure
+++ b/configure
@@ -2585,6 +2585,9 @@ h264_videotoolbox_hwaccel_select="h264_decoder"
 hevc_cuvid_hwaccel_deps="cuda cuvid CUVIDHEVCPICPARAMS"
 hevc_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_HEVC"
 hevc_d3d11va_hwaccel_select="hevc_decoder"
+hevc_mediacodec_decoder_deps="mediacodec"
+hevc_mediacodec_hwaccel_deps="mediacodec"
+hevc_mediacodec_decoder_select="hevc_mp4toannexb_bsf hevc_parser"
 hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC"
 hevc_dxva2_hwaccel_select="hevc_decoder"
 hevc_qsv_hwaccel_deps="libmfx"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 7396468..71420fb 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -316,7 +316,7 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o 
h264_cabac.o h264_cavlc.o \
   h264_slice.o h264data.o h264_parse.o 
\
   h2645_parse.o
 OBJS-$(CONFIG_H264_CUVID_DECODER)  += cuvid.o
-OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec_h264.o
+OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec_h2645.o
 OBJS-$(CONFIG_H264_MMAL_DECODER)   += mmaldec.o
 OBJS-$(CONFIG_H264_NVENC_ENCODER)  += nvenc_h264.o
 OBJS-$(CONFIG_NVENC_ENCODER)   += nvenc_h264.o
@@ -333,6 +333,7 @@ OBJS-$(CONFIG_HEVC_DECODER)+= hevc.o hevc_mvs.o 
hevc_ps.o hevc_sei.o
   hevc_cabac.o hevc_refs.o hevcpred.o  
  \
   hevcdsp.o hevc_filter.o 
h2645_parse.o hevc_data.o
 OBJS-$(CONFIG_HEVC_CUVID_DECODER)  += cuvid.o
+OBJS-$(CONFIG_HEVC_MEDIACODEC_DECODER) += mediacodecdec_h2645.o hevc_parse.o
 OBJS-$(CONFIG_HEVC_NVENC_ENCODER)  += nvenc_hevc.o
 OBJS-$(CONFIG_NVENC_HEVC_ENCODER)  += nvenc_hevc.o
 OBJS-$(CONFIG_HEVC_QSV_DECODER)+= qsvdec_h2645.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index a26a80e..142ccba 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -84,6 +84,7 @@ void avcodec_register_all(void)
 REGISTER_HWACCEL(HEVC_CUVID,hevc_cuvid);
 REGISTER_HWACCEL(HEVC_D3D11VA,  hevc_d3d11va);
 REGISTER_HWACCEL(HEVC_DXVA2,hevc_dxva2);
+REGISTER_HWACCEL(HEVC_MEDIACODEC,   hevc_mediacodec);
 REGISTER_HWACCEL(HEVC_QSV,  hevc_qsv);
 REGISTER_HWACCEL(HEVC_VAAPI,hevc_vaapi);
 REGISTER_HWACCEL(HEVC_VDPAU,hevc_vdpau);
@@ -644,6 +645,7 @@ void avcodec_register_all(void)
 REGISTER_ENCODER(NVENC_HEVC,nvenc_hevc);
 #endif
 REGISTER_DECODER(HEVC_CUVID,hevc_cuvid);
+REGISTER_DECODER(HEVC_MEDIACODEC,   hevc_mediacodec);
 REGISTER_ENCODER(HEVC_NVENC,hevc_nvenc);
 REGISTER_ENCODER(HEVC_QSV,  hevc_qsv);
 REGISTER_ENCODER(HEVC_VAAPI,hevc_vaapi);
diff --git a/libavcodec/hevc_parse.c b/libavcodec/hevc_parse.c
new file mode 100644
index 000..cf04bc2
--- /dev/null
+++ b/libavcodec/hevc_parse.c
@@ -0,0 +1,134 @@
+/*
+ * 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 "bytestream.h"
+#include "h2645_parse.h"
+#include "hevc.h"
+#include "hevc_parse.h"
+
+static int hevc_decode_nal_units(const uint8_t *buf, int buf_size, 
HEVCParamSets *ps,
+ int is_nalff, int nal_length_size, void 
*logctx)
+{
+int i;
+int ret = 0;
+H2645Packet pkt = { 0 };
+
+ret = ff_h2645_packet_split(, buf, buf_size, logctx, is_nalff, 
nal_length_size, AV_CODEC_ID_HEVC, 

[FFmpeg-devel] [PATCH 1/2] lavc/hevc: store VPS/SPS/PPS data

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libavcodec/hevc.h|  9 +
 libavcodec/hevc_ps.c | 27 +++
 2 files changed, 36 insertions(+)

diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
index be91010..6a3c750 100644
--- a/libavcodec/hevc.h
+++ b/libavcodec/hevc.h
@@ -387,6 +387,9 @@ typedef struct HEVCVPS {
 uint8_t vps_poc_proportional_to_timing_flag;
 int vps_num_ticks_poc_diff_one; ///< vps_num_ticks_poc_diff_one_minus1 + 1
 int vps_num_hrd_parameters;
+
+uint8_t data[4096];
+int data_size;
 } HEVCVPS;
 
 typedef struct ScalingList {
@@ -483,6 +486,9 @@ typedef struct HEVCSPS {
 int vshift[3];
 
 int qp_bd_offset;
+
+uint8_t data[4096];
+int data_size;
 } HEVCSPS;
 
 typedef struct HEVCPPS {
@@ -557,6 +563,9 @@ typedef struct HEVCPPS {
 int *tile_pos_rs;   ///< TilePosRS
 int *min_tb_addr_zs;///< MinTbAddrZS
 int *min_tb_addr_zs_tab;///< MinTbAddrZS
+
+uint8_t data[4096];
+int data_size;
 } HEVCPPS;
 
 typedef struct HEVCParamSets {
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 83f2ec2..629e454 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -408,6 +408,15 @@ int ff_hevc_decode_nal_vps(GetBitContext *gb, 
AVCodecContext *avctx,
 
 av_log(avctx, AV_LOG_DEBUG, "Decoding VPS\n");
 
+vps->data_size = gb->buffer_end - gb->buffer;
+if (vps->data_size > sizeof(vps->data)) {
+av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized VPS "
+   "(%"SIZE_SPECIFIER" > %"SIZE_SPECIFIER")\n",
+   vps->data_size, sizeof(vps->data));
+vps->data_size = sizeof(vps->data);
+}
+memcpy(vps->data, gb->buffer, vps->data_size);
+
 vps_id = get_bits(gb, 4);
 if (vps_id >= MAX_VPS_COUNT) {
 av_log(avctx, AV_LOG_ERROR, "VPS id out of range: %d\n", vps_id);
@@ -1184,6 +1193,15 @@ int ff_hevc_decode_nal_sps(GetBitContext *gb, 
AVCodecContext *avctx,
 
 av_log(avctx, AV_LOG_DEBUG, "Decoding SPS\n");
 
+sps->data_size = gb->buffer_end - gb->buffer;
+if (sps->data_size > sizeof(sps->data)) {
+av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized SPS "
+   "(%"SIZE_SPECIFIER" > %"SIZE_SPECIFIER")\n",
+   sps->data_size, sizeof(sps->data));
+sps->data_size = sizeof(sps->data);
+}
+memcpy(sps->data, gb->buffer, sps->data_size);
+
 ret = ff_hevc_parse_sps(sps, gb, _id,
 apply_defdispwin,
 ps->vps_list, avctx);
@@ -1423,6 +1441,15 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb, 
AVCodecContext *avctx,
 
 av_log(avctx, AV_LOG_DEBUG, "Decoding PPS\n");
 
+pps->data_size = gb->buffer_end - gb->buffer;
+if (pps->data_size > sizeof(pps->data)) {
+av_log(avctx, AV_LOG_WARNING, "Truncating likely oversized PPS "
+   "(%"SIZE_SPECIFIER" > %"SIZE_SPECIFIER")\n",
+   pps->data_size, sizeof(pps->data));
+pps->data_size = sizeof(pps->data);
+}
+memcpy(pps->data, gb->buffer, pps->data_size);
+
 // Default values
 pps->loop_filter_across_tiles_enabled_flag = 1;
 pps->num_tile_columns  = 1;
-- 
2.9.3

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

[FFmpeg-devel] lavc/mediacodec: add hevc decoder

[Matthieu Bouron]

Hello,

The following patchset add support for hevc mediacodec decoding. The patchset
applies on top of:
* lavc/mediacodecdec_h264: move bsf variable declaration at the top of the 
function
* lavc/mediacodecdec_h264: use h264_parse.h instead of h264dec.h
which are going to be pushed in one hour or so (if there is no objection).

A development branch can be found at:
https://github.com/mbouron/FFmpeg/tree/feature/mediacodec-hevc-v2

[PATCH 1/2] lavc/hevc: store VPS/SPS/PPS data

This commit stores the original sodb vps/sps/pps data to their respective
structures defined in hevc.h. The data will be used later on by the MediaCodec
decoder which requires the extradata to be vps+sps+pps.
Note: the H264 decoder stores the original sodb sps/pps the same way in the 
PPS/SPS
structures.

[PATCH 2/2] lavc: add hevc mediacodec decoder

This commit adds the hevc mediacodec decoder as well as an hevc extradata
parsing function (ff_hevc_decode_extradata) which matches the api of
ff_h264_decode_extradata.

The code of ff_hevc_decode_extradata is taken from hevc.c (and adapted to not
rely on the HEVCContext structure).
The code of hevc_decode_nal_units is taken from the simple version of
parse_nal_units from hevc_parser.c. The function has been adapted to not rely
on the AVCodecParserContext and to not call hevc_parse_slice_header which is
not relevant when parsing extradata.

Obviously there is work to do here (like for h264) to unify all the hevc
extradata parsing functions as there are:
* hevc_decode_extradata (hevc.c)
* two variants of parse_nal_units (hevc_parser.c), one variant is chosen
over the other depending on the presence of the hevc decoder
* and now ff_hevc_decode_extradata (hevc_parse.c)

The patch lacks a minor bump in libavcodec/version.h and a changelog entry
(which are going to be added in another revision of the patch).

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

Re: [FFmpeg-devel] [PATCH] doc/developer: Add patchwork mentioning to "patch submission checklist"

[Michael Niedermayer]

On Wed, Sep 07, 2016 at 04:39:54PM +0200, Michael Niedermayer wrote:
> On Wed, Sep 07, 2016 at 07:19:00AM -0700, Jonathan Campbell wrote:
> > On 09/07/2016 04:51 AM, Michael Niedermayer wrote:
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  doc/developer.texi | 6 ++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/doc/developer.texi b/doc/developer.texi
> > > index 4d3a7ae..51e3da7 100644
> > > --- a/doc/developer.texi
> > > +++ b/doc/developer.texi
> > > @@ -641,6 +641,12 @@ are notoriously left unchecked, which is a serious 
> > > problem.
> > >  @item
> > >  Test your code with valgrind and or Address Sanitizer to ensure it's free
> > >  of leaks, out of array accesses, etc.
> > > +
> > > +@item
> > > +Check that your submitted patch shows up on 
> > > @url{https://patchwork.ffmpeg.org}.
> > > +Also make sure its status is updated, you can create an account and 
> > > update it.
> > > +If your patch is incorrectly or not listed in patchwork then it might be
> > > +missed by developers using patchwork to find patches needing review or 
> > > pushing.
> > >  @end enumerate
> > >  
> > >  @section Patch review process
> > > 
> > 
> > I only see one of the 4 patches for AC-3 consistent noise generation (the 
> > libavutil version bump) on the patchwork site. Can I assume the other three 
> > will make their way into the patchwork list when the time is right, or did 
> > I submit the patch wrong?
> 
> all 4 patches are there:
> https://patchwork.ffmpeg.org/project/ffmpeg/list/?submitter=82=%2A=both

in fact thats the 4 mails not the 4 patches from the last mail
patchwork does not support multiple patches per mail AFAIK

[...]

-- 
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] doc/developer: Add patchwork mentioning to "patch submission checklist"

[Michael Niedermayer]

On Wed, Sep 07, 2016 at 07:19:00AM -0700, Jonathan Campbell wrote:
> On 09/07/2016 04:51 AM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  doc/developer.texi | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/doc/developer.texi b/doc/developer.texi
> > index 4d3a7ae..51e3da7 100644
> > --- a/doc/developer.texi
> > +++ b/doc/developer.texi
> > @@ -641,6 +641,12 @@ are notoriously left unchecked, which is a serious 
> > problem.
> >  @item
> >  Test your code with valgrind and or Address Sanitizer to ensure it's free
> >  of leaks, out of array accesses, etc.
> > +
> > +@item
> > +Check that your submitted patch shows up on 
> > @url{https://patchwork.ffmpeg.org}.
> > +Also make sure its status is updated, you can create an account and update 
> > it.
> > +If your patch is incorrectly or not listed in patchwork then it might be
> > +missed by developers using patchwork to find patches needing review or 
> > pushing.
> >  @end enumerate
> >  
> >  @section Patch review process
> > 
> 
> I only see one of the 4 patches for AC-3 consistent noise generation (the 
> libavutil version bump) on the patchwork site. Can I assume the other three 
> will make their way into the patchwork list when the time is right, or did I 
> submit the patch wrong?

all 4 patches are there:
https://patchwork.ffmpeg.org/project/ffmpeg/list/?submitter=82=%2A=both

patches which arent there will not appear later unless the
mails from the mailing list are stuck

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

Re: [FFmpeg-devel] [PATCH] doc/developer: Add patchwork mentioning to "patch submission checklist"

[Jonathan Campbell]

On 09/07/2016 04:51 AM, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/developer.texi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 4d3a7ae..51e3da7 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -641,6 +641,12 @@ are notoriously left unchecked, which is a serious 
> problem.
>  @item
>  Test your code with valgrind and or Address Sanitizer to ensure it's free
>  of leaks, out of array accesses, etc.
> +
> +@item
> +Check that your submitted patch shows up on 
> @url{https://patchwork.ffmpeg.org}.
> +Also make sure its status is updated, you can create an account and update 
> it.
> +If your patch is incorrectly or not listed in patchwork then it might be
> +missed by developers using patchwork to find patches needing review or 
> pushing.
>  @end enumerate
>  
>  @section Patch review process
> 

I only see one of the 4 patches for AC-3 consistent noise generation (the 
libavutil version bump) on the patchwork site. Can I assume the other three 
will make their way into the patchwork list when the time is right, or did I 
submit the patch wrong?

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Sven C. Dack]

On 07/09/16 15:01, Sven C. Dack wrote:

On 07/09/16 14:33, Timo Rothenpieler wrote:

0RGB/0BGR does not mean the alpha bits are zeroed.
It means they are undefined, so you convert from ARGB to 0RGB by doing
nothing. There is no performance to gain by supporting a format that
falsely advertises support for an alpha channel.

Also, the correct formats to use are AV_PIX_FMT_0RGB32, which
corresponds to NV_ENC_BUFFER_FORMAT_ARGB, and AV_PIX_FMT_0BGR32 for ABGR.
Thanks for finally explaining it. I also tested it with 0RGB32 and it does 
work with those, too.


Sven 


Last patch I've send had a twist in it. Here is the correct patch:

--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -81,6 +81,8 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
 AV_PIX_FMT_P010,
 AV_PIX_FMT_YUV444P,
 AV_PIX_FMT_YUV444P16,
+AV_PIX_FMT_0RGB32,
+AV_PIX_FMT_0BGR32,
 #if CONFIG_CUDA
 AV_PIX_FMT_CUDA,
 #endif
@@ -1032,6 +1034,14 @@ static av_cold int nvenc_alloc_surface(AVCodecContext 
*avctx, int idx)

 ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_YUV444_10BIT;
 break;

+case AV_PIX_FMT_0RGB32:
+ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_ARGB;
+break;
+
+case AV_PIX_FMT_0BGR32:
+ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_ABGR;
+break;
+
 default:
 av_log(avctx, AV_LOG_FATAL, "Invalid input pixel format\n");
 return AVERROR(EINVAL);
@@ -1350,6 +1360,10 @@ static int nvenc_copy_frame(AVCodecContext *avctx, 
NvencSurface *inSurf,

 av_image_copy_plane(buf, lockBufferParams->pitch,
 frame->data[2], frame->linesize[2],
 avctx->width << 1, avctx->height);
+} else if (frame->format == AV_PIX_FMT_0RGB32 || frame->format == 
AV_PIX_FMT_0BGR32) {

+  av_image_copy_plane(buf, lockBufferParams->pitch,
+   frame->data[0], frame->linesize[0],
+   avctx->width << 2, avctx->height);
 } else {
 av_log(avctx, AV_LOG_FATAL, "Invalid pixel format!\n");
 return AVERROR(EINVAL);

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Sven C. Dack]

On 07/09/16 14:33, Timo Rothenpieler wrote:

0RGB/0BGR does not mean the alpha bits are zeroed.
It means they are undefined, so you convert from ARGB to 0RGB by doing
nothing. There is no performance to gain by supporting a format that
falsely advertises support for an alpha channel.

Also, the correct formats to use are AV_PIX_FMT_0RGB32, which
corresponds to NV_ENC_BUFFER_FORMAT_ARGB, and AV_PIX_FMT_0BGR32 for ABGR.
Thanks for finally explaining it. I also tested it with 0RGB32 and it does work 
with those, too.


Sven

--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -81,6 +81,8 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
 AV_PIX_FMT_P010,
 AV_PIX_FMT_YUV444P,
 AV_PIX_FMT_YUV444P16,
+AV_PIX_FMT_0RGB32,
+AV_PIX_FMT_0BGR32,
 #if CONFIG_CUDA
 AV_PIX_FMT_CUDA,
 #endif
@@ -1032,6 +1034,14 @@ static av_cold int nvenc_alloc_surface(AVCodecContext 
*avctx, int idx)

 ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_YUV444_10BIT;
 break;

+case AV_PIX_FMT_0RGB32:
+ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_ABGR;
+break;
+
+case AV_PIX_FMT_0BGR32:
+ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_ARGB;
+break;
+
 default:
 av_log(avctx, AV_LOG_FATAL, "Invalid input pixel format\n");
 return AVERROR(EINVAL);
@@ -1350,6 +1360,10 @@ static int nvenc_copy_frame(AVCodecContext *avctx, 
NvencSurface *inSurf,

 av_image_copy_plane(buf, lockBufferParams->pitch,
 frame->data[2], frame->linesize[2],
 avctx->width << 1, avctx->height);
+} else if (frame->format == AV_PIX_FMT_0RGB32 || frame->format == 
AV_PIX_FMT_0BGR32) {

+  av_image_copy_plane(buf, lockBufferParams->pitch,
+   frame->data[0], frame->linesize[0],
+   avctx->width << 2, avctx->height);
 } else {
 av_log(avctx, AV_LOG_FATAL, "Invalid pixel format!\n");
 return AVERROR(EINVAL);

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/mediacodecdec_h264: use h264_parse.h instead of h264dec.h

[Matthieu Bouron]

On Mon, Sep 05, 2016 at 03:57:54PM +0200, Matthieu Bouron wrote:
> From: Matthieu Bouron 
> 
> ff_h264_decode_extradata is referenced by h264_parse.h and not
> h264dec.h.
> ---
>  libavcodec/mediacodecdec_h264.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
> index 9b71561..a141174 100644
> --- a/libavcodec/mediacodecdec_h264.c
> +++ b/libavcodec/mediacodecdec_h264.c
> @@ -32,7 +32,7 @@
>  #include "libavutil/atomic.h"
>  
>  #include "avcodec.h"
> -#include "h264dec.h"
> +#include "h264_parse.h"
>  #include "internal.h"
>  #include "mediacodecdec.h"
>  #include "mediacodec_wrapper.h"

I will apply the patchset in a few hours if there is no objection.

Matthieu

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

Re: [FFmpeg-devel] [PATCH] lavc/mediacodecdec_h264: fix SODB escaping

[Matthieu Bouron]

On Wed, Sep 07, 2016 at 02:50:18PM +0200, Benoit Fouet wrote:
> Hi,
> 
> 
> On 06/09/2016 16:53, Matthieu Bouron wrote:
> > From: Matthieu Bouron 
> > 
> > Fixes escaping of consecutive 0x00, 0x00, 0x0{0-3} sequences.
> > ---
> >   libavcodec/mediacodecdec_h264.c | 6 +++---
> >   1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/libavcodec/mediacodecdec_h264.c 
> > b/libavcodec/mediacodecdec_h264.c
> > index a141174..4f9d737 100644
> > --- a/libavcodec/mediacodecdec_h264.c
> > +++ b/libavcodec/mediacodecdec_h264.c
> > @@ -104,9 +104,9 @@ static int h264_ps_to_nalu(const uint8_t *src, int 
> > src_size, uint8_t **out, int
> >   }
> >   *out = p = new;
> > -i = i + 3;
> > -memmove(p + i, p + i - 1, *out_size - i);
> > -p[i - 1] = 0x03;
> > +i = i + 2;
> > +memmove(p + i + 1, p + i, *out_size - (i + 1));
> > +p[i] = 0x03;
> 
> LGTM

Pushed. Thanks for the review.

Matthieu

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Timo Rothenpieler]

Am 07.09.2016 um 15:26 schrieb Sven C. Dack:
> On 07/09/16 12:40, Timo Rothenpieler wrote:
>> libavutil/pixfmt.h defines AV_PIX_FMT_RGB0 and the other ones like this:
>>
>> packed RGB 8:8:8, 32bpp, XRGBXRGB...   X=unused/undefined
>>
>> So I would expect the Alpha-Channel to be anything, and converting from
>> RGBA to RGB0 to be a no-op "conversion".
> 
> It is not an issue. x11grab produces BGR0 and nvenc can handle it with
> the patch. It's giving me 100fp/s (up from 47fp/s) with a 1920x1080
> monitor. I'd imagine people with 4K displays will be happy, too,
> although they will have to live with lower speeds of perhaps 30 fp/s.
> Would be interesting to know how it performs on 4K though.
> 
> If there is really an RGBA/BGRA input then it needs to be convert to
> RGB0/BGR0. Until then is it a theoretical issue. Might be the module
> producing RGBA/BGRA can produce RGB0/BGR0, too.

0RGB/0BGR does not mean the alpha bits are zeroed.
It means they are undefined, so you convert from ARGB to 0RGB by doing
nothing. There is no performance to gain by supporting a format that
falsely advertises support for an alpha channel.

Also, the correct formats to use are AV_PIX_FMT_0RGB32, which
corresponds to NV_ENC_BUFFER_FORMAT_ARGB, and AV_PIX_FMT_0BGR32 for ABGR.

Will apply with those.

For the future, please use git format-patch, and ideally also git
send-email for your patches.
Attaching the patches is just fine though, preferably only one per mail
for patchwork to pick it up cleanly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Sven C. Dack]

On 07/09/16 12:40, Timo Rothenpieler wrote:

libavutil/pixfmt.h defines AV_PIX_FMT_RGB0 and the other ones like this:

packed RGB 8:8:8, 32bpp, XRGBXRGB...   X=unused/undefined

So I would expect the Alpha-Channel to be anything, and converting from
RGBA to RGB0 to be a no-op "conversion".


It is not an issue. x11grab produces BGR0 and nvenc can handle it with the 
patch. It's giving me 100fp/s (up from 47fp/s) with a 1920x1080 monitor. I'd 
imagine people with 4K displays will be happy, too, although they will have to 
live with lower speeds of perhaps 30 fp/s. Would be interesting to know how it 
performs on 4K though.


If there is really an RGBA/BGRA input then it needs to be convert to RGB0/BGR0. 
Until then is it a theoretical issue. Might be the module producing RGBA/BGRA 
can produce RGB0/BGR0, too.


Sven

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

Re: [FFmpeg-devel] [PATCH] lavc/mediacodecdec_h264: fix SODB escaping

[Benoit Fouet]

Hi,


On 06/09/2016 16:53, Matthieu Bouron wrote:

From: Matthieu Bouron 

Fixes escaping of consecutive 0x00, 0x00, 0x0{0-3} sequences.
---
  libavcodec/mediacodecdec_h264.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/mediacodecdec_h264.c b/libavcodec/mediacodecdec_h264.c
index a141174..4f9d737 100644
--- a/libavcodec/mediacodecdec_h264.c
+++ b/libavcodec/mediacodecdec_h264.c
@@ -104,9 +104,9 @@ static int h264_ps_to_nalu(const uint8_t *src, int 
src_size, uint8_t **out, int
  }
  *out = p = new;
  
-i = i + 3;

-memmove(p + i, p + i - 1, *out_size - i);
-p[i - 1] = 0x03;
+i = i + 2;
+memmove(p + i + 1, p + i, *out_size - (i + 1));
+p[i] = 0x03;


LGTM

--
Ben

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

Re: [FFmpeg-devel] [PATCH] doc/developer: Add patchwork mentioning to "patch submission checklist"

[Michael Niedermayer]

On Wed, Sep 07, 2016 at 08:03:20AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Sep 7, 2016 at 7:51 AM, Michael Niedermayer 
> wrote:
> 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  doc/developer.texi | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/doc/developer.texi b/doc/developer.texi
> > index 4d3a7ae..51e3da7 100644
> > --- a/doc/developer.texi
> > +++ b/doc/developer.texi
> > @@ -641,6 +641,12 @@ are notoriously left unchecked, which is a serious
> > problem.
> >  @item
> >  Test your code with valgrind and or Address Sanitizer to ensure it's free
> >  of leaks, out of array accesses, etc.
> > +
> > +@item
> > +Check that your submitted patch shows up on @url{
> > https://patchwork.ffmpeg.org}.
> > +Also make sure its status is updated, you can create an account and
> > update it.
> > +If your patch is incorrectly or not listed in patchwork then it might be
> > +missed by developers using patchwork to find patches needing review or
> > pushing.
> >  @end enumerate
> 
> 
> I don't think we should require developers to use (or check, or update, or
> create-an-account-on) patchwork. Wasn't the whole point of patchwork that
> you can use it if you care, and you can ignore it if you don't care?

yes one can ignore it but its alot more usefull if people keep in
mind that theres patchwork.

For example, if you reply with LGTM or Acked-by: or Reviewed-by:
or Tested-by:
patchwork will pick that up, OTOH if you write "that works well,
i tested it" patchwork will not pick that up, nor will it "dude that
looks fine, please push it" nor does it "I dont like that change"

the result of that is that if everyone ignores patchwork it will
contain most submited patches (some odd non standard attachmets are
missed)
it would pick up most but not all applied patches (change the patch
before push and it will quite potentially not realize its the same)
it wont on its own detect superseded patches nor would it know if a
patch is forgotten or dropped
it also picks the fate output up as patch as it is techinically a patch

ive writte a script to automate this a bit further so fate output gets
marked as not applicable, so that more applied patches are detected and
so that most superseeded patches are detected as such

but people keeping an eye on patchwork and updating status where it
just cannot figure it out or improving its automation or making sure
they reply with keywords it understands or update it so it picks up
the used keywords would all be a good idea. And it would improve
the usefulness of patchwork, finding out which patches need a review
needs all applied, superseeded an droped patches to be marked
accordingly. Also patchwork supports keeping track of delegation so
if someone is working on a patch review or whatever patchwork can be
told about that and people would then know not to push the patch before
the reviewer is done. Thats not automatic though either, it requires
developers to have an account and set the status of the patch by hand
AFAIK

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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

Re: [FFmpeg-devel] [PATCH] doc/developer: Add patchwork mentioning to "patch submission checklist"

[Ronald S. Bultje]

Hi,

On Wed, Sep 7, 2016 at 7:51 AM, Michael Niedermayer 
wrote:

> Signed-off-by: Michael Niedermayer 
> ---
>  doc/developer.texi | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 4d3a7ae..51e3da7 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -641,6 +641,12 @@ are notoriously left unchecked, which is a serious
> problem.
>  @item
>  Test your code with valgrind and or Address Sanitizer to ensure it's free
>  of leaks, out of array accesses, etc.
> +
> +@item
> +Check that your submitted patch shows up on @url{
> https://patchwork.ffmpeg.org}.
> +Also make sure its status is updated, you can create an account and
> update it.
> +If your patch is incorrectly or not listed in patchwork then it might be
> +missed by developers using patchwork to find patches needing review or
> pushing.
>  @end enumerate


I don't think we should require developers to use (or check, or update, or
create-an-account-on) patchwork. Wasn't the whole point of patchwork that
you can use it if you care, and you can ignore it if you don't care?

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

[FFmpeg-devel] [PATCH] doc/developer: Add patchwork mentioning to "patch submission checklist"

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 doc/developer.texi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/developer.texi b/doc/developer.texi
index 4d3a7ae..51e3da7 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -641,6 +641,12 @@ are notoriously left unchecked, which is a serious problem.
 @item
 Test your code with valgrind and or Address Sanitizer to ensure it's free
 of leaks, out of array accesses, etc.
+
+@item
+Check that your submitted patch shows up on @url{https://patchwork.ffmpeg.org}.
+Also make sure its status is updated, you can create an account and update it.
+If your patch is incorrectly or not listed in patchwork then it might be
+missed by developers using patchwork to find patches needing review or pushing.
 @end enumerate
 
 @section Patch review process
-- 
2.9.3

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

Re: [FFmpeg-devel] [PATCH] avformat/mov: Enable stream parsing for VP9.

[Ronald S. Bultje]

Hi,

On Tue, Sep 6, 2016 at 10:39 PM, Matthew Gregan  wrote:

> At 2016-09-06T22:18:18-0400, Ronald S. Bultje wrote:
> > I think the patch is fine, but I wonder if it should set it to _FULL (the
> > parser ignores the option, but it is semantically more correct).
>
> Good point, thanks for the feedback.  Updated (simpler!) patch attached.


LGTM.

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Sven C. Dack]

On 07/09/16 12:27, Carl Eugen Hoyos wrote:

If your patch adds "RGBA" as supported colour space,
the encoder (by definition) announces that it supports
transparency.
nvenc does not support transparency (if it would, it would
be a - grave - bug to use "RGB0" in the patch). So please
do not add it.


Done and tested.

Now please explain to me what RGB0/BGR0 exactly means in FFmpeg terms. It says 
in the headers "0" stands for undefined. Does this mean anything can be present 
in the "0"-field or can one rely on the "0"-field to always contain 0x00?


Sven


--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -81,6 +81,8 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
 AV_PIX_FMT_P010,
 AV_PIX_FMT_YUV444P,
 AV_PIX_FMT_YUV444P16,
+AV_PIX_FMT_RGB0,
+AV_PIX_FMT_BGR0,
 #if CONFIG_CUDA
 AV_PIX_FMT_CUDA,
 #endif
@@ -1032,6 +1034,14 @@ static av_cold int nvenc_alloc_surface(AVCodecContext 
*avctx, int idx)

 ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_YUV444_10BIT;
 break;

+case AV_PIX_FMT_RGB0:
+ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_ABGR;
+break;
+
+case AV_PIX_FMT_BGR0:
+ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_ARGB;
+break;
+
 default:
 av_log(avctx, AV_LOG_FATAL, "Invalid input pixel format\n");
 return AVERROR(EINVAL);
@@ -1350,6 +1360,10 @@ static int nvenc_copy_frame(AVCodecContext *avctx, 
NvencSurface *inSurf,

 av_image_copy_plane(buf, lockBufferParams->pitch,
 frame->data[2], frame->linesize[2],
 avctx->width << 1, avctx->height);
+} else if (frame->format == AV_PIX_FMT_RGB0 || frame->format == 
AV_PIX_FMT_BGR0) {

+  av_image_copy_plane(buf, lockBufferParams->pitch,
+   frame->data[0], frame->linesize[0],
+   avctx->width << 2, avctx->height);
 } else {
 av_log(avctx, AV_LOG_FATAL, "Invalid pixel format!\n");
 return AVERROR(EINVAL);

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Timo Rothenpieler]

Am 07.09.2016 um 13:27 schrieb Carl Eugen Hoyos:
> 2016-09-07 12:50 GMT+02:00 Sven C. Dack :
>> On 07/09/16 11:25, Carl Eugen Hoyos wrote:
>>>
 Am 07.09.2016 um 11:40 schrieb "Sven C. Dack" :

 On 07/09/16 09:23, Timo Rothenpieler wrote:
 Otherwise will RGBA/BGRA have to
 be converted into RGB0/BGR0
 and you will again get a performance penalty.
>>>
>>> What makes you think so?
>>
>> I have tested it. What makes you think it wouldn't?
> 
> This is a bug that should be fixed independently.

libavutil/pixfmt.h defines AV_PIX_FMT_RGB0 and the other ones like this:

packed RGB 8:8:8, 32bpp, XRGBXRGB...   X=unused/undefined

So I would expect the Alpha-Channel to be anything, and converting from
RGBA to RGB0 to be a no-op "conversion".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [RFC] marking non developer tickets

[Michael Niedermayer]

Hi

Most of the tickets on trac are about ffmpeg code. I belive this makes
it hard for non developers to find things to contribute to, yet at the
same time there are quite a few non devel tasks that need to be done
and that arent done ...

Can type = task be used for non devel tasks or should a key word
be added (which keyword?) or something else ?



-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Carl Eugen Hoyos]

2016-09-07 12:50 GMT+02:00 Sven C. Dack :
> On 07/09/16 11:25, Carl Eugen Hoyos wrote:
>>
>>> Am 07.09.2016 um 11:40 schrieb "Sven C. Dack" :
>>>
>>> On 07/09/16 09:23, Timo Rothenpieler wrote:
>>> Otherwise will RGBA/BGRA have to
>>> be converted into RGB0/BGR0
>>> and you will again get a performance penalty.
>>
>> What makes you think so?
>
> I have tested it. What makes you think it wouldn't?

This is a bug that should be fixed independently.

>> (The problem is that your encoder now reports "I support
>> transparency" and this will lead to funny effects depending
>> in the colour space of your input file.)
>
> No, it doesn't.

If your patch adds "RGBA" as supported colour space,
the encoder (by definition) announces that it supports
transparency.
nvenc does not support transparency (if it would, it would
be a - grave - bug to use "RGB0" in the patch). So please
do not add it.

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Sven C. Dack]

On 07/09/16 11:25, Carl Eugen Hoyos wrote:

Hi!


Am 07.09.2016 um 11:40 schrieb "Sven C. Dack" :

On 07/09/16 09:23, Timo Rothenpieler wrote:
Otherwise will RGBA/BGRA have to
be converted into RGB0/BGR0
and you will again get a performance penalty.

What makes you think so?


I have tested it. What makes you think it wouldn't?


(The problem is that your encoder now reports "I support transparency" and this 
will lead to funny effects depending in the colour space of your input file.)


No, it doesn't. The encoder does deal with transparency. It effectively ignores 
it. So it is save to pass it on without FFmpeg needing to set the value to 0 but 
let the encoder do it.




Please also implement my other suggestion to make documentation and 
implementation match (and to match existing and new colour spaces, there is 
already an endianness-depending pix_fmt).


I have no idea what you are talking about. If you want to implement a new pixel 
format and colour space for what seems to be a mere twist in Nvidia's 
documentation then you are welcome to do so. I won't.


Sven

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Carl Eugen Hoyos]

Hi!

> Am 07.09.2016 um 11:40 schrieb "Sven C. Dack" :
> 
> On 07/09/16 09:23, Timo Rothenpieler wrote:

> Otherwise will RGBA/BGRA have to 
> be converted into RGB0/BGR0 

> and you will again get a performance penalty.

What makes you think so?
(The problem is that your encoder now reports "I support transparency" and this 
will lead to funny effects depending in the colour space of your input file.)

Please also implement my other suggestion to make documentation and 
implementation match (and to match existing and new colour spaces, there is 
already an endianness-depending pix_fmt).

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Carl Eugen Hoyos]

Hi!

> Am 07.09.2016 um 11:36 schrieb Paul B Mahol :
> 
>> On 9/7/16, Carl Eugen Hoyos  wrote:
>> Hi!
>> 
>> 2016-09-07 2:23 GMT+02:00 Sven C. Dack :
 On 07/09/16 01:08, Sven C. Dack wrote:
 
> On 07/09/16 00:43, Carl Eugen Hoyos wrote:
> 
> Should be AV_PIX_FMT_RGB0...
>> 
>> As pointed out by Timo, this should be AV_PIX_FMT_0BGR32...
>> 
> ... and AV_PIX_FMT_BGR0
>> 
>> ... and this AV_PIX_FMT_0RGB32: It makes no difference on
>> little-endian, but matches the documentation.
>> Sorry for not realizing this yesterday!
>> 
>>> +AV_PIX_FMT_RGB0,
>>> +AV_PIX_FMT_BGR0,
>> 
>>> +AV_PIX_FMT_RGBA,
>>> +AV_PIX_FMT_BGRA,
>> 
>> In any case, please remove AV_PIX_FMT_RGBA and AV_PIX_FMT_BGRA,
>> the encoder cannot deal with transparency.
> 
> And how do you know that?

If the encoder would deal with transparency (which it does not) RGB0 would be 
wrong but it seems everybody agrees it is correct.

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Timo Rothenpieler]

>> Also, why is the twist from AV_PIX_FMT_RGBA to NV_ENC_BUFFER_FORMAT_ABGR
>> necessary?
>>
>> The nvenc header describes it as "8 bit Packed A8B8G8R8", so did they
>> mess it up?
> 
> It is necessary in order to make it work. The twist here is intentional
> as I pointed out earlier. If you do it the other way around as described
> in the documentation then you get false and missing colours.

Carl already pointed you to the correct, native-endian pixel formats,
which match with the nvenc documentation:

https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/pixfmt.h#L320

> I'd like to keep in the transparency channel unless you know there is an
> actual problem with it. The encoder may not use it, but it is no reason
> not to pass it on. Otherwise will RGBA/BGRA have to be converted into
> RGB0/BGR0 and you will again get a performance penalty.

NVENC itself lists the alpha channel. So keeping it should be fine and
save a conversion.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Sven C. Dack]

On 07/09/16 10:40, Sven C. Dack wrote:


It is necessary in order to make it work. The twist here is intentional as I 
pointed out earlier. If you do it the other way around as described in the 
documentation then you get false and missing colours.


I'd like to keep in the transparency channel unless you know there is an 
actual problem with it. The encoder may not use it, but it is no reason not to 
pass it on. Otherwise will RGBA/BGRA have to be converted into RGB0/BGR0 and 
you will again get a performance penalty.


Sven



--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -81,6 +81,10 @@ const enum AVPixelFormat ff_nvenc_pix_fmts[] = {
 AV_PIX_FMT_P010,
 AV_PIX_FMT_YUV444P,
 AV_PIX_FMT_YUV444P16,
+AV_PIX_FMT_RGB0,
+AV_PIX_FMT_BGR0,
+AV_PIX_FMT_RGBA,
+AV_PIX_FMT_BGRA,
 #if CONFIG_CUDA
 AV_PIX_FMT_CUDA,
 #endif
@@ -1032,6 +1036,16 @@ static av_cold int nvenc_alloc_surface(AVCodecContext 
*avctx, int idx)

 ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_YUV444_10BIT;
 break;

+case AV_PIX_FMT_RGB0:
+case AV_PIX_FMT_RGBA:
+ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_ABGR;
+break;
+
+case AV_PIX_FMT_BGR0:
+case AV_PIX_FMT_BGRA:
+ctx->surfaces[idx].format = NV_ENC_BUFFER_FORMAT_ARGB;
+break;
+
 default:
 av_log(avctx, AV_LOG_FATAL, "Invalid input pixel format\n");
 return AVERROR(EINVAL);
@@ -1350,6 +1364,11 @@ static int nvenc_copy_frame(AVCodecContext *avctx, 
NvencSurface *inSurf,

 av_image_copy_plane(buf, lockBufferParams->pitch,
 frame->data[2], frame->linesize[2],
 avctx->width << 1, avctx->height);
+} else if (frame->format == AV_PIX_FMT_RGBA || frame->format == 
AV_PIX_FMT_RGB0 ||
+  frame->format == AV_PIX_FMT_BGRA || frame->format == 
AV_PIX_FMT_BGR0) {

+  av_image_copy_plane(buf, lockBufferParams->pitch,
+   frame->data[0], frame->linesize[0],
+   avctx->width << 2, avctx->height);
 } else {
 av_log(avctx, AV_LOG_FATAL, "Invalid pixel format!\n");
 return AVERROR(EINVAL);

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Sven C. Dack]

On 07/09/16 09:23, Timo Rothenpieler wrote:

  avctx->width << 1, avctx->height);
+} else if (frame->format == AV_PIX_FMT_RGBA || frame->format ==
AV_PIX_FMT_RGB0) {
+  av_image_copy_plane(buf, lockBufferParams->pitch,
+   frame->data[0], frame->linesize[0],
+   avctx->width << 2, avctx->height);
+} else if (frame->format == AV_PIX_FMT_BGRA || frame->format ==
AV_PIX_FMT_BGR0) {
+  av_image_copy_plane(buf, lockBufferParams->pitch,
+   frame->data[0], frame->linesize[0],
+   avctx->width << 2, avctx->height);
  } else {

These are identical, so please put them into one if.

Also, why is the twist from AV_PIX_FMT_RGBA to NV_ENC_BUFFER_FORMAT_ABGR
necessary?

The nvenc header describes it as "8 bit Packed A8B8G8R8", so did they
mess it up?


It is necessary in order to make it work. The twist here is intentional as I 
pointed out earlier. If you do it the other way around as described in the 
documentation then you get false and missing colours.


I'd like to keep in the transparency channel unless you know there is an actual 
problem with it. The encoder may not use it, but it is no reason not to pass it 
on. Otherwise will RGBA/BGRA have to be converted into RGB0/BGR0 and you will 
again get a performance penalty.


Sven

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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Paul B Mahol]

On 9/7/16, Carl Eugen Hoyos  wrote:
> Hi!
>
> 2016-09-07 2:23 GMT+02:00 Sven C. Dack :
>> On 07/09/16 01:08, Sven C. Dack wrote:
>>>
>>> On 07/09/16 00:43, Carl Eugen Hoyos wrote:

 Should be AV_PIX_FMT_RGB0...
>
> As pointed out by Timo, this should be AV_PIX_FMT_0BGR32...
>
 ... and AV_PIX_FMT_BGR0
>
> ... and this AV_PIX_FMT_0RGB32: It makes no difference on
> little-endian, but matches the documentation.
> Sorry for not realizing this yesterday!
>
>> +AV_PIX_FMT_RGB0,
>> +AV_PIX_FMT_BGR0,
>
>> +AV_PIX_FMT_RGBA,
>> +AV_PIX_FMT_BGRA,
>
> In any case, please remove AV_PIX_FMT_RGBA and AV_PIX_FMT_BGRA,
> the encoder cannot deal with transparency.

And how do you know that?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: drop format specific stream copy heuristics

[Michael Niedermayer]

On Tue, Sep 06, 2016 at 06:26:59PM +0200, Michael Niedermayer wrote:
> On Tue, Sep 06, 2016 at 05:45:46PM +0200, Hendrik Leppkes wrote:
> > On Tue, Sep 6, 2016 at 5:10 PM, Michael Niedermayer
> >  wrote:
> > > On Tue, Sep 06, 2016 at 02:39:11PM +0200, Hendrik Leppkes wrote:
> > >> On Tue, Sep 6, 2016 at 2:21 PM, Michael Niedermayer
> > >>  wrote:
> > >> > On Tue, Sep 06, 2016 at 02:18:35PM +0200, Michael Niedermayer wrote:
> > >> >> On Tue, Sep 06, 2016 at 04:57:06AM +0200, Michael Niedermayer wrote:
> > >> >> > On Mon, Sep 05, 2016 at 10:04:35PM -0300, James Almer wrote:
> > >> >> > > On 9/5/2016 12:41 PM, Michael Niedermayer wrote:
> > >> >> > > > On Mon, Sep 05, 2016 at 04:41:52PM +0200, Clément Bœsch wrote:
> > >> >> > > >> From: Clément Bœsch 
> > >> >> > > >>
> > >> >> > > >> These adjusted codec fields do not seem to be in use anymore 
> > >> >> > > >> and prevent
> > >> >> > > >> the convert of ffmpeg*.c to codecpar.
> > >> >> > > >
> > >> >> > > >  ./ffmpeg  -i ~/tickets/4914/xdcam8mp2-1s_small.ts -c:v copy 
> > >> >> > > > out.mxf
> > >> >> > > > fails, no output anymore
> > >> >> > > >
> > >> >> > > > ./ffmpeg -i matrixbench_mpeg2.mpg -c:v copy -t 1 test.avi
> > >> >> > > > the output now has 600fps
> > >> >> > >
> > >> >> > > Even with this code in place the resulting stream in the avi is 
> > >> >> > > reported
> > >> >> > > as 100 fps.
> > >> >> >
> > >> >> > that seems to be a regression since
> > >> >> > 6f69f7a8bf6a0d013985578df2ef42ee6b1c7994
> > >> >> >
> > >> >> > IIRC the intended timebase is 1/50 for this kind of content
> > >> >> > (allowing the support of interlaced and field duplicated content to
> > >> >> >  appear later)
> > >> >> >
> > >> >> >
> > >> >> > > And with or without the code, the resulting files play the
> > >> >> > > same with the players i tried.
> > >> >> >
> > >> >> > Higher framerates / finer timebases need noticably more space to
> > >> >> > be stored in avi, thats not the case for other formats and thats
> > >> >> > one reason why avi is treated as a special case.
> > >> >> >
> > >> >> > ill try to look tomorrow why its 100fps since the previous
> > >> >> > codecpar patches. Though 100fps is not nearly as bad as 600fps
> > >> >> > 600 has ~6 times the overhead
> > >> >>
> > >> >> This regression is caused by ticks_per_frame beiing incorrect
> > >> >>
> > >> >> Ill send a patch to fix this
> > >> >
> > >> > patch attached
> > >> >
> > >>
> > >> We don't have time_base in codecpar, so why do we need ticks per frame 
> > >> in it?
> > >
> > > We need both in some form probably
> > > For this regression ticks_per_frame ATM is enough.
> > > For time_base theres code to copy/access it bypassing codecpar
> > >
> > > The way it seems to be currently is that there are fields which
> > > are needed and either they are
> > > in codecpar or
> > > theres some tricks to access them from code sheduled to be removed
> > >  (which will work only as long as the code isnt removed)
> > > or things just dont work.
> > >
> > >
> > >>
> > >> Which time_base does it modify the interpretation of? The field should
> > >> be bundled with that, then.
> > >
> > > the AVCodecContext one, ticks_per_frame is already in AVCodecContext
> > > the AVCodecContext ticks_per_frame though is not exported after codecpar
> > > while the codec timebase still is just not vissibly through codecpar
> > >
> > 
> > Maybe that part should be fixed then, wherever we export that to
> > AVCodecContext, also set its ticks_per_frame properly?
> > It just feels bad to export a property here that standing alone
> > doesn't mean anything.
> > 
> > So fix the export of ticks_per_frame for AVCodecContext, and if later
> > on we decide we really do need time_base in AVCodecParameters, and
> > can't fix whatever needs it differently, we can then include both in
> > there.
> 
> attached
> 
> [...]
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Dictatorship naturally arises out of democracy, and the most aggravated
> form of tyranny and slavery out of the most extreme liberty. -- Plato

>  libavformat/utils.c  |4 +++-
>  tests/ref/fate/copy-trac4914 |4 ++--
>  tests/ref/fate/copy-trac4914-avi |4 ++--
>  3 files changed, 7 insertions(+), 5 deletions(-)
> 2dc146e807cbdbdbca653a22d827920e8c05b3c8  
> 0001-avformat-Export-ticks_per_frame-in-st-codec.patch
> From ae128325081392610475b62d0c20165e0cb9536f Mon Sep 17 00:00:00 2001
> From: Michael Niedermayer 
> Date: Tue, 6 Sep 2016 18:10:41 +0200
> Subject: [PATCH] avformat: Export ticks_per_frame in st->codec
> 
> Suggested-by: Hendrik Leppkes
> Signed-off-by: Michael Niedermayer 

applied

with this we have restored the functionality to prior bug/regression
so it should serve better as a reference.


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop 

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

[Timo Rothenpieler]

>  avctx->width << 1, avctx->height);
> +} else if (frame->format == AV_PIX_FMT_RGBA || frame->format ==
> AV_PIX_FMT_RGB0) {
> +  av_image_copy_plane(buf, lockBufferParams->pitch,
> +   frame->data[0], frame->linesize[0],
> +   avctx->width << 2, avctx->height);
> +} else if (frame->format == AV_PIX_FMT_BGRA || frame->format ==
> AV_PIX_FMT_BGR0) {
> +  av_image_copy_plane(buf, lockBufferParams->pitch,
> +   frame->data[0], frame->linesize[0],
> +   avctx->width << 2, avctx->height);
>  } else {

These are identical, so please put them into one if.

Also, why is the twist from AV_PIX_FMT_RGBA to NV_ENC_BUFFER_FORMAT_ABGR
necessary?

The nvenc header describes it as "8 bit Packed A8B8G8R8", so did they
mess it up?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 04/18] avformat/movenc: deal with AVMEDIA_TYPE_DATA by using AV_CODEC_ID_META

[Erkki Seppälä]

On 09/06/2016 09:26 PM, Carl Eugen Hoyos wrote:

2016-09-06 15:07 GMT+02:00 Erkki Seppälä :


Would it be even better to not copy the data tracks at
all by default, so not set the .data_codec field for any
format?


This was my original question for which I do not know
the answer: If you feel it doesn't hurt not to copy the
track I am all for not changing behaviour.


I will then opt for not changing the behavior. If the behavior is deemed 
change-worthy in the future, it can be in its own patch.


Thanks.

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