Re: [FFmpeg-devel] [OPW] OPW Project Proposal

[Michael Niedermayer]

On Wed, Oct 05, 2016 at 11:23:11PM +0530, Pallavi Kumari wrote:
> I am looking for mentor(s). Kindly let me know if anyone interested.

iam interrested, i intend to mentor only one applicant though
iam also the mentor for "Improve Selftest coverage"
(hint  if someone wants to take mentoring that over for example ...)

Do you have a suggeted entry for
https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12
for this project ?

also, important, we need a qualification task which should be a small
part of the whole that shows that the applicant is qualified/able to
do the project, any suggestion ?


thx

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

[FFmpeg-devel] [PATCH] lavf/segment: decide whether to rename based on list URI

[Rodger Combs]

This fixes the case of writing segments to local files, but the list
over a network protocol.
---
 libavformat/segment.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index 33a5cf0..55dcaf0 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -709,7 +709,7 @@ static int seg_init(AVFormatContext *s)
 if ((ret = segment_list_open(s)) < 0)
 goto fail;
 } else {
-const char *proto = avio_find_protocol_name(s->filename);
+const char *proto = avio_find_protocol_name(seg->list);
 seg->use_rename = proto && !strcmp(proto, "file");
 }
 }
-- 
2.10.0

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

Re: [FFmpeg-devel] [PATCH] mov: Evaluate the movie display matrix

[Michael Niedermayer]

On Wed, Oct 05, 2016 at 05:25:33PM -0400, Vittorio Giovara wrote:
> This matrix needs to be applied after all others have (currently only
> display matrix from trak), but cannot be handled in movie box, since
> streams are not allocated yet.
> 
> So store it in main context and if not identity, apply it when appropriate,
> handling the case when trak display matrix is identity and when it is not.
> 
> Signed-off-by: Vittorio Giovara 
> ---
> Please keep my in CC.
> Vittorio
> 
>  libavformat/isom.h |  2 ++
>  libavformat/mov.c  | 63 
> +-
>  2 files changed, 55 insertions(+), 10 deletions(-)
> 
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index 2246fed..2aeb8fa 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -238,6 +238,8 @@ typedef struct MOVContext {
>  uint8_t *decryption_key;
>  int decryption_key_len;
>  int enable_drefs;
> +
> +int32_t movie_display_matrix[3][3]; ///< display matrix from mvhd
>  } MOVContext;
>  
>  int ff_mp4_read_descr_len(AVIOContext *pb);
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index a15c8d1..26b332c 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -1211,6 +1211,7 @@ static int mov_read_mdhd(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  
>  static int mov_read_mvhd(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>  {
> +int i;
>  int64_t creation_time;
>  int version = avio_r8(pb); /* version */
>  avio_rb24(pb); /* flags */
> @@ -1238,7 +1239,12 @@ static int mov_read_mvhd(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  
>  avio_skip(pb, 10); /* reserved */
>  
> -avio_skip(pb, 36); /* display matrix */
> +/* movie display matrix, store it in main context and use it later on */
> +for (i = 0; i < 3; i++) {
> +c->movie_display_matrix[i][0] = avio_rb32(pb); // 16.16 fixed point
> +c->movie_display_matrix[i][1] = avio_rb32(pb); // 16.16 fixed point
> +c->movie_display_matrix[i][2] = avio_rb32(pb); //  2.30 fixed point
> +}
>  
>  avio_rb32(pb); /* preview time */
>  avio_rb32(pb); /* preview duration */
> @@ -3798,9 +3804,24 @@ static int mov_read_meta(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  return 0;
>  }
>  
> +// return 0 when matrix is identity, 1 otherwise
> +#define IS_MATRIX_FULL(matrix)   \
> +(matrix[0][0] != (1 << 16) ||\
> + matrix[1][1] != (1 << 16) ||\
> + matrix[2][2] != (1 << 30) ||\
> + matrix[0][1] || matrix[0][2] || \
> + matrix[1][0] || matrix[1][2] || \
> + matrix[2][0] || matrix[2][1])
> +
> +// fixed point to double
> +#define CONV_FP(x, sh) ((double) (x)) / (1 << sh)
> +
> +// double to fixed point
> +#define CONV_DB(x, sh) (int32_t) ((x) * (1 << sh))
> +
>  static int mov_read_tkhd(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>  {
> -int i;
> +int i, j, e;
>  int width;
>  int height;
>  int display_matrix[3][3];
> @@ -3855,13 +3876,7 @@ static int mov_read_tkhd(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  
>  // save the matrix and add rotate metadata when it is not the default
>  // identity
> -if (display_matrix[0][0] != (1 << 16) ||
> -display_matrix[1][1] != (1 << 16) ||
> -display_matrix[2][2] != (1 << 30) ||
> -display_matrix[0][1] || display_matrix[0][2] ||
> -display_matrix[1][0] || display_matrix[1][2] ||
> -display_matrix[2][0] || display_matrix[2][1]) {
> -int i, j;
> +if (IS_MATRIX_FULL(display_matrix)) {
>  double rotate;
>  
>  av_freep(>display_matrix);
> @@ -3884,13 +3899,41 @@ static int mov_read_tkhd(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  }
>  }
>  
> +// if movie display matrix is not identity, and if this is a video track
> +if (IS_MATRIX_FULL(c->movie_display_matrix) && width && height) {
> +// if trak display matrix was identity, just copy the movie one
> +if (!sc->display_matrix) {
> +sc->display_matrix = av_malloc(sizeof(int32_t) * 9);
> +if (!sc->display_matrix)
> +return AVERROR(ENOMEM);
> +
> +for (i = 0; i < 3; i++)
> +for (j = 0; j < 3; j++)
> +sc->display_matrix[i * 3 + j] = 
> c->movie_display_matrix[i][j];
> +} else { // otherwise multiply the two and store the result
> +double val = 0;
> +for (i = 0; i < 3; i++) {
> +for (j = 0; j < 3; j++) {
> +int sh = j == 2 ? 30 : 16;
> +for (e = 0; e < 3; e++) {
> +val += CONV_FP(display_matrix[i][e], sh) *
> +   CONV_FP(c->movie_display_matrix[e][j], sh);
> +}
> +sc->display_matrix[i * 3 + j] = CONV_DB(val, sh);
> +val = 0;

the matrixes are 32bit the product of 

[FFmpeg-devel] [PATCH] libavformat/tee: Add fifo support for tee

[sebechlebskyjan]

From: Jan Sebechlebsky 

Signed-off-by: Jan Sebechlebsky 
---
This commit makes use of fifo muxer together with tee muxer
easier, fifo muxer does not have to be explicitly specified
for each slave. For the most simple use case it is sufficient
to turn fifo muxer on for all slaves by switching on use_fifo
option. Same options can be passed to all fifo muxer instances of
slaves by assigning them to fifo_options of tee. 
Both use_fifo option and individual fifo_options can be 
overriden per slave if needed.

 doc/muxers.texi   | 20 +
 libavformat/tee.c | 89 ++-
 2 files changed, 108 insertions(+), 1 deletion(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 9ec2e31..b88b83c 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1473,6 +1473,7 @@ Specify whether to remove all fragments when finished. 
Default 0 (do not remove)
 
 @end table
 
+@anchor{fifo}
 @section fifo
 
 The fifo pseudo-muxer allows the separation of encoding and muxing by using
@@ -1580,6 +1581,18 @@ with the tee muxer; encoding can be a very expensive 
process. It is not
 useful when using the libavformat API directly because it is then possible
 to feed the same packets to several muxers directly.
 
+@table @option
+
+@item use_fifo @var{bool}
+If set to 1, slave outputs will be processed in separate thread using 
@ref{fifo}
+muxer. This allows to compensate for different speed/latency/reliability of
+outputs and setup transparent recovery. By default this feature is turned off.
+
+@item fifo_options
+Options to pass to fifo pseudo-muxer instances. See @ref{fifo}.
+
+@end table
+
 The slave outputs are specified in the file name given to the muxer,
 separated by '|'. If any of the slave name contains the '|' separator,
 leading or trailing spaces or any special character, it must be
@@ -1601,6 +1614,13 @@ output name suffix.
 Specify a list of bitstream filters to apply to the specified
 output.
 
+@item use_fifo @var{bool}
+This allows to override tee muxer use_fifo option for individual slave muxer.
+
+@item fifo_options
+This allows to override tee muxer fifo_options for individual slave muxer.
+See @ref{fifo}.
+
 It is possible to specify to which streams a given bitstream filter
 applies, by appending a stream specifier to the option separated by
 @code{/}. @var{spec} must be a stream specifier (see @ref{Format
diff --git a/libavformat/tee.c b/libavformat/tee.c
index d59ad4d..764135d 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -40,6 +40,8 @@ typedef struct {
 AVBSFContext **bsfs; ///< bitstream filters per stream
 
 SlaveFailurePolicy on_fail;
+int use_fifo;
+AVDictionary *fifo_options;
 
 /** map from input to output streams indexes,
  * disabled output streams are set to -1 */
@@ -52,15 +54,28 @@ typedef struct TeeContext {
 unsigned nb_slaves;
 unsigned nb_alive;
 TeeSlave *slaves;
+int use_fifo;
+AVDictionary *fifo_options;
+char *fifo_options_str;
 } TeeContext;
 
 static const char *const slave_delim = "|";
 static const char *const slave_bsfs_spec_sep = "/";
 static const char *const slave_select_sep = ",";
 
+#define OFFSET(x) offsetof(TeeContext, x)
+static const AVOption options[] = {
+{"use_fifo", "Use fifo pseudo-muxer to separate actual muxers from 
encoder",
+ OFFSET(use_fifo), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, 
AV_OPT_FLAG_ENCODING_PARAM},
+{"fifo_options", "fifo pseudo-muxer options", OFFSET(fifo_options_str),
+ AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, AV_OPT_FLAG_ENCODING_PARAM},
+{NULL}
+};
+
 static const AVClass tee_muxer_class = {
 .class_name = "Tee muxer",
 .item_name  = av_default_item_name,
+.option = options,
 .version= LIBAVUTIL_VERSION_INT,
 };
 
@@ -81,6 +96,27 @@ static inline int parse_slave_failure_policy_option(const 
char *opt, TeeSlave *t
 return AVERROR(EINVAL);
 }
 
+static int parse_slave_fifo_options(const char * use_fifo,
+const char * fifo_options, TeeSlave * 
tee_slave)
+{
+int ret = 0;
+
+if (use_fifo) {
+if (av_match_name(use_fifo, "true,y,yes,enable,enabled,on,1")) {
+tee_slave->use_fifo = 1;
+} else if (av_match_name(use_fifo, 
"false,n,no,disable,disabled,off,0")) {
+tee_slave->use_fifo = 0;
+} else {
+return AVERROR(EINVAL);
+}
+}
+
+if (fifo_options)
+ret = av_dict_parse_string(_slave->fifo_options, fifo_options, 
"=", ":", 0);
+
+return ret;
+}
+
 static int close_slave(TeeSlave *tee_slave)
 {
 AVFormatContext *avf;
@@ -125,6 +161,7 @@ static int open_slave(AVFormatContext *avf, char *slave, 
TeeSlave *tee_slave)
 AVDictionaryEntry *entry;
 char *filename;
 char *format = NULL, *select = NULL, *on_fail = NULL;
+char *use_fifo = NULL, *fifo_options_str = NULL;
 AVFormatContext 

Re: [FFmpeg-devel] [PATCH] mov: Evaluate the movie display matrix

[compn]

On Thu, 6 Oct 2016 16:40:12 -0400
Vittorio Giovara  wrote:

> > what is the intended / correct SAR / DAR for this sample ?
> 
> without the patch Stream #0:0(und): Video: h264 (High) (avc1 /
> 0x31637661), yuv420p, 540x576 [SAR 1:1 DAR 15:16], 102 kb/s, 25 fps,
> 25 tbr, 12800 tbn, 50 tbc (default)
> 
> with the patch Stream #0:0(und): Video: h264 (High) (avc1 /
> 0x31637661), yuv420p, 540x576 [SAR 1:1 DAR 15:16], 102 kb/s, SAR
> 93207:65536 DAR 1016804:762601, 25 fps, 25 tbr, 12800 tbn, 50 tbc
> (default)
> 
> This last one is the intended and correct one.

why are SAR and DAR in the output twice now? it might be confusing to
users? or just me...

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

Re: [FFmpeg-devel] [PATCH 00/11] CRC32 support for Matroska muxer

[James Almer]

On 10/6/2016 6:10 PM, Dave Rice wrote:
> 
>> On Oct 6, 2016, at 4:33 PM, James Almer  wrote:
>>
>> On 10/6/2016 3:28 PM, Michael Niedermayer wrote:
>>> On Thu, Oct 06, 2016 at 11:27:08AM -0300, James Almer wrote:
 On 10/6/2016 7:29 AM, Michael Niedermayer wrote:
> On Mon, Oct 03, 2016 at 08:36:56PM -0300, James Almer wrote:
>> This patchsets implements the feature requested on ticket #4347.
>> The first three patches are preparation work. The first one isn't
>> strictly related to the implementation, but comes in handy
>> nonetheless.
>>
>> Patches 4 to 11 can be squashed into a single commit before pushing
>> if that's prefered, but for review purposes i split things as one
>> patch per Level 1 element being adapted to write a CRC32 element.
>>
>> Fate tests are updated as needed.
>
> some questions
> Does this reduce writing speed ? for example when remuxing high
> bitrate data like rawvideo ?

 The bulk of the CRC calculation is done once per level 1 element, so it
 shouldn't affect remuxing speed in a considerable way. But if preferred,
 i could see about adding an option to disable it.
>>>
>>> i guess such a option cant hurt
>>
>> Will add it.
> 
> Worth adding to the Changelog as well.

Added both the option and a Changelog entry.

> 
>>> thanks
>>>
>>> no furter comments from me about this patchset
>>
>> Pushed without squashing, so if problems arise bisect can more accurately
>> point where things went wrong.
>>
>> Thanks.
>>
>> ___
>> 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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavfi/metadata: fix metadata deletion if comparison returns false

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavfilter/f_metadata.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavfilter/f_metadata.c b/libavfilter/f_metadata.c
index f4a929c..f2c71d9 100644
--- a/libavfilter/f_metadata.c
+++ b/libavfilter/f_metadata.c
@@ -330,9 +330,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 case METADATA_DELETE:
 if (!s->key) {
 av_dict_free(metadata);
-} else if (e && e->value && s->value && s->compare(s, e->value, 
s->value)) {
-av_dict_set(metadata, s->key, NULL, 0);
-} else if (e && e->value) {
+} else if (e && e->value && (!s->value || s->compare(s, e->value, 
s->value))) {
 av_dict_set(metadata, s->key, NULL, 0);
 }
 return ff_filter_frame(outlink, frame);
-- 
2.6.6

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

[FFmpeg-devel] [PATCH] lavfi/sidedata: add filter for manipulating frame side data

[Marton Balint]

This is a similar filter to f_metadata, only it works on side data. Since
adding side data from a user provided arbitrary binary string is unsafe,
because current code assumes that a side data of a certain kind has the proper
size, this filter only implements selection and deletion. Also, no value
matching support is implemented yet, because there is no uniform way to specify
a side data textually.

Signed-off-by: Marton Balint 
---
 Changelog|   1 +
 doc/filters.texi |  30 
 libavfilter/Makefile |   2 +
 libavfilter/allfilters.c |   2 +
 libavfilter/f_sidedata.c | 181 +++
 libavfilter/version.h|   2 +-
 6 files changed, 217 insertions(+), 1 deletion(-)
 create mode 100644 libavfilter/f_sidedata.c

diff --git a/Changelog b/Changelog
index dc48882..5148712 100644
--- a/Changelog
+++ b/Changelog
@@ -35,6 +35,7 @@ version :
 - sdl1 output device and sdl1 support removed
 - extended mov edit list support
 - libfaac encoder removed
+- sidedata video and asidedata audio filter
 
 
 version 3.1:
diff --git a/doc/filters.texi b/doc/filters.texi
index 4b2f7bf..5516ae0 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -17568,6 +17568,36 @@ ffmpeg -i audio.flac -lavfi 
showwavespic=split_channels=1:s=1024x800 waveform.pn
 @end example
 @end itemize
 
+@section sidedata, asidedata
+
+Delete frame side data, or select frames based on it.
+
+This filter accepts the following options:
+
+@table @option
+@item mode
+Set mode of operation of the filter.
+
+Can be one of the following:
+
+@table @samp
+@item select
+Select every frame with side data of @code{type}.
+
+@item delete
+Delete side data of @code{type}. If @code{type} is not set, delete all side
+data in the frame.
+
+@end table
+
+@item type
+Set side data type used with all modes. Must be set for @code{select} mode. For
+the list of frame side data types, refer to the @code{AVFrameSideDataType} enum
+in @file{libavutil/frame.h}. For example, to choose
+@code{AV_FRAME_DATA_PANSCAN} side data, you must specify @code{PANSCAN}.
+
+@end table
+
 @section spectrumsynth
 
 Sythesize audio from 2 input video spectrums, first input stream represents
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 57a38d3..7ed4696 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -62,6 +62,7 @@ OBJS-$(CONFIG_ASETPTS_FILTER)+= setpts.o
 OBJS-$(CONFIG_ASETRATE_FILTER)   += af_asetrate.o
 OBJS-$(CONFIG_ASETTB_FILTER) += settb.o
 OBJS-$(CONFIG_ASHOWINFO_FILTER)  += af_ashowinfo.o
+OBJS-$(CONFIG_ASIDEDATA_FILTER)  += f_sidedata.o
 OBJS-$(CONFIG_ASPLIT_FILTER) += split.o
 OBJS-$(CONFIG_ASTATS_FILTER) += af_astats.o
 OBJS-$(CONFIG_ASTREAMSELECT_FILTER)  += f_streamselect.o
@@ -270,6 +271,7 @@ OBJS-$(CONFIG_SHOWINFO_FILTER)   += 
vf_showinfo.o
 OBJS-$(CONFIG_SHOWPALETTE_FILTER)+= vf_showpalette.o
 OBJS-$(CONFIG_SHUFFLEFRAMES_FILTER)  += vf_shuffleframes.o
 OBJS-$(CONFIG_SHUFFLEPLANES_FILTER)  += vf_shuffleplanes.o
+OBJS-$(CONFIG_SIDEDATA_FILTER)   += f_sidedata.o
 OBJS-$(CONFIG_SIGNALSTATS_FILTER)+= vf_signalstats.o
 OBJS-$(CONFIG_SMARTBLUR_FILTER)  += vf_smartblur.o
 OBJS-$(CONFIG_SOBEL_FILTER)  += vf_convolution.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 8f542fd..82a65ee 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -80,6 +80,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(ASETRATE,   asetrate,   af);
 REGISTER_FILTER(ASETTB, asettb, af);
 REGISTER_FILTER(ASHOWINFO,  ashowinfo,  af);
+REGISTER_FILTER(ASIDEDATA,  asidedata,  af);
 REGISTER_FILTER(ASPLIT, asplit, af);
 REGISTER_FILTER(ASTATS, astats, af);
 REGISTER_FILTER(ASTREAMSELECT,  astreamselect,  af);
@@ -286,6 +287,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(SHOWPALETTE,showpalette,vf);
 REGISTER_FILTER(SHUFFLEFRAMES,  shuffleframes,  vf);
 REGISTER_FILTER(SHUFFLEPLANES,  shuffleplanes,  vf);
+REGISTER_FILTER(SIDEDATA,   sidedata,   vf);
 REGISTER_FILTER(SIGNALSTATS,signalstats,vf);
 REGISTER_FILTER(SMARTBLUR,  smartblur,  vf);
 REGISTER_FILTER(SOBEL,  sobel,  vf);
diff --git a/libavfilter/f_sidedata.c b/libavfilter/f_sidedata.c
new file mode 100644
index 000..4863cc9
--- /dev/null
+++ b/libavfilter/f_sidedata.c
@@ -0,0 +1,181 @@
+/*
+ * 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 

Re: [FFmpeg-devel] [PATCH 00/11] CRC32 support for Matroska muxer

[Dave Rice]

> On Oct 6, 2016, at 4:33 PM, James Almer  wrote:
> 
> On 10/6/2016 3:28 PM, Michael Niedermayer wrote:
>> On Thu, Oct 06, 2016 at 11:27:08AM -0300, James Almer wrote:
>>> On 10/6/2016 7:29 AM, Michael Niedermayer wrote:
 On Mon, Oct 03, 2016 at 08:36:56PM -0300, James Almer wrote:
> This patchsets implements the feature requested on ticket #4347.
> The first three patches are preparation work. The first one isn't
> strictly related to the implementation, but comes in handy
> nonetheless.
> 
> Patches 4 to 11 can be squashed into a single commit before pushing
> if that's prefered, but for review purposes i split things as one
> patch per Level 1 element being adapted to write a CRC32 element.
> 
> Fate tests are updated as needed.
 
 some questions
 Does this reduce writing speed ? for example when remuxing high
 bitrate data like rawvideo ?
>>> 
>>> The bulk of the CRC calculation is done once per level 1 element, so it
>>> shouldn't affect remuxing speed in a considerable way. But if preferred,
>>> i could see about adding an option to disable it.
>> 
>> i guess such a option cant hurt
> 
> Will add it.

Worth adding to the Changelog as well.

>> thanks
>> 
>> no furter comments from me about this patchset
> 
> Pushed without squashing, so if problems arise bisect can more accurately
> point where things went wrong.
> 
> Thanks.
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 00/11] CRC32 support for Matroska muxer

[James Almer]

On 10/6/2016 3:28 PM, Michael Niedermayer wrote:
> On Thu, Oct 06, 2016 at 11:27:08AM -0300, James Almer wrote:
>> On 10/6/2016 7:29 AM, Michael Niedermayer wrote:
>>> On Mon, Oct 03, 2016 at 08:36:56PM -0300, James Almer wrote:
 This patchsets implements the feature requested on ticket #4347.
 The first three patches are preparation work. The first one isn't
 strictly related to the implementation, but comes in handy
 nonetheless.

 Patches 4 to 11 can be squashed into a single commit before pushing
 if that's prefered, but for review purposes i split things as one
 patch per Level 1 element being adapted to write a CRC32 element.

 Fate tests are updated as needed.
>>>
>>> some questions
>>> Does this reduce writing speed ? for example when remuxing high
>>> bitrate data like rawvideo ?
>>
>> The bulk of the CRC calculation is done once per level 1 element, so it
>> shouldn't affect remuxing speed in a considerable way. But if preferred,
>> i could see about adding an option to disable it.
> 
> i guess such a option cant hurt

Will add it.

> 
> thanks
> 
> no furter comments from me about this patchset

Pushed without squashing, so if problems arise bisect can more accurately
point where things went wrong.

Thanks.

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

Re: [FFmpeg-devel] [PATCH] mov: Evaluate the movie display matrix

[Michael Niedermayer]

On Thu, Oct 06, 2016 at 12:12:07AM -0400, Vittorio Giovara wrote:
> On Wed, Oct 5, 2016 at 10:07 PM, Michael Niedermayer
>  wrote:
> > On Wed, Oct 05, 2016 at 05:25:33PM -0400, Vittorio Giovara wrote:
> >> This matrix needs to be applied after all others have (currently only
> >> display matrix from trak), but cannot be handled in movie box, since
> >> streams are not allocated yet.
> >>
> >> So store it in main context and if not identity, apply it when appropriate,
> >> handling the case when trak display matrix is identity and when it is not.
> >
> > do you have a testcase for this which you can share ?
> >
> > thx
> >
> > [...]
> > --
> 
> I created one for the occasion
> https://www.dropbox.com/s/w2uu37o11rvoz1q/moviedispmat.mp4?dl=1

with ffplay before the patch the image looks round, after the patch
it looks quite squished, is that intended ?
what is the intended / correct SAR / DAR for this sample ?

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] Cherry-pick commit 6803a298f4338c19c3032d2417c6e857eb6d95be Support for MIPS cpu P6600

[Michael Niedermayer]

On Thu, Oct 06, 2016 at 10:46:57AM +0530, shivraj.pa...@imgtec.com wrote:
> From: Shivraj Patil 
> 
> Signed-off-by: Shivraj Patil 
> Signed-off-by: Michael Niedermayer 
> ---
>  configure |6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

6803a298f4338c19c3032d2417c6e857eb6d95be backported to releases where
it applied cleanly (3.0, 3.1)

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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

Re: [FFmpeg-devel] [PATCH] Cherry-pick commit id c1cc13cd2a9b8d6d2810ec42454f328a1a0d5efa avutil/mips/generic_macros_msa: rename macro variable which causes segfault for mips r6

[Michael Niedermayer]

On Thu, Oct 06, 2016 at 10:21:25AM +0530, shivraj.pa...@imgtec.com wrote:
> From: Shivraj Patil 
> 
> Signed-off-by: Shivraj Patil 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/mips/generic_macros_msa.h |   12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

commit locally backported

[...]
-- 
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

Re: [FFmpeg-devel] [PATCH 00/11] CRC32 support for Matroska muxer

[Michael Niedermayer]

On Thu, Oct 06, 2016 at 11:27:08AM -0300, James Almer wrote:
> On 10/6/2016 7:29 AM, Michael Niedermayer wrote:
> > On Mon, Oct 03, 2016 at 08:36:56PM -0300, James Almer wrote:
> >> This patchsets implements the feature requested on ticket #4347.
> >> The first three patches are preparation work. The first one isn't
> >> strictly related to the implementation, but comes in handy
> >> nonetheless.
> >>
> >> Patches 4 to 11 can be squashed into a single commit before pushing
> >> if that's prefered, but for review purposes i split things as one
> >> patch per Level 1 element being adapted to write a CRC32 element.
> >>
> >> Fate tests are updated as needed.
> > 
> > some questions
> > Does this reduce writing speed ? for example when remuxing high
> > bitrate data like rawvideo ?
> 
> The bulk of the CRC calculation is done once per level 1 element, so it
> shouldn't affect remuxing speed in a considerable way. But if preferred,
> i could see about adding an option to disable it.

i guess such a option cant hurt

thanks

no furter comments from me about this patchset

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] [PATCH] vf_fps: Don't flush a cached frame if it should have been dropped

[Nicolas George]

Le tridi 13 vendémiaire, an CCXXV, Derek Buitenhuis a écrit :
> This "break" may actually be more correct output, but I am not familiar enough
> with lavfi or vf_fps to say. Removing the last frame in case where it should 
> have
> been removed was the entire point of this patch.
> 
> Perhaps someone more familiar with the code here can comment? Nicholas, maybe?

If this is referring to me, sorry, the only thing I know about the fps
filter is that it is in need of a good cleanup. Hopefully, the patch series
I am struggling with right now will make it easier.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/matroskaenc: don't write an empty Colour master element

[James Almer]

On 10/2/2016 8:14 PM, James Almer wrote:
> On 9/27/2016 8:49 PM, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/matroskaenc.c | 53 
>> ++-
>>  1 file changed, 34 insertions(+), 19 deletions(-)
> 
> Ping for patchset.

Pushed.

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

[FFmpeg-devel] dh option in nnedi3

[Jon bae]

Hello All,
sorry for that question - I know is open source and we can add option by
ours self, but my knowledge is to limited for that.

Is it possible to integrate the dh (double high) option from vapoursynth
nnedi3 filter to the ffmpeg nnedi filter?

I have start copy parts from the sources, but I hang from line 709 on in
the ffmpeg version.

Regards

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

Re: [FFmpeg-devel] ffserver: current status and future plans

[Stephan Holljes]

On Fri, Sep 23, 2016 at 6:08 PM, Michael Niedermayer
 wrote:
> On Fri, Sep 23, 2016 at 05:46:06PM +0200, Michael Fritscher wrote:
>> Hello,
>>
>> as promised I started to work on ffserver. The focus of the first
>> week was to remake a fresh building environment - incl. FATE - and
>> get an overview what it is needed to be done.
>>
>> 1. FATE
>> There is already a test for ffserver, but out of FATE. This test
>> does not work for me, but this is a cygwin related problem (wget
>>  | dd bs=1 count=20k : wget isn't exited automatically if dd
>> exits, and because of that the test hangs) Does anybody know more
>> details of the warning
>>
>> "
>> Unfortunately ffserver is broken and therefore its regression test
>> fails randomly. Treat the results accordingly.
>> "
>> in the Makefile regarding this test?
>
> In the very distant past the tests gave not always the same results.
> I dont know why xactly that was that way or if it still is
> my gut feeling pointed to timing/race stuff but i dont remember that
> i debugged this to find the true cause
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No snowflake in an avalanche ever feels responsible. -- Voltaire
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Hi all,
this is a bit off-topic, but ubitux encouraged me to share this with
you since you are working on ffserver. I wrote a small application
"showcasing" how one could implement live streaming over http with the
ffmpeg libraries. Maybe it can serve as an inspiration of sorts:

https://github.com/klaxa/mkvserver_mk2

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

Re: [FFmpeg-devel] [PATCH 3/3] lavc/mediacodecdec: fix size variable shadowing in ff_mediacodec_dec_decode

[Matthieu Bouron]

On Thu, Oct 06, 2016 at 03:59:31PM +0200, Michael Niedermayer wrote:
> On Thu, Oct 06, 2016 at 02:31:57PM +0200, Matthieu Bouron wrote:
> > From: Matthieu Bouron 
> > 
> > Fixes incompatible pointer type warning on 64-bit systems.
> > ---
> >  libavcodec/mediacodecdec.c | 1 -
> >  1 file changed, 1 deletion(-)
> 
> LGTM

Pushed. Thanks.

Matthieu

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

Re: [FFmpeg-devel] [PATCH 00/11] CRC32 support for Matroska muxer

[James Almer]

On 10/6/2016 7:29 AM, Michael Niedermayer wrote:
> On Mon, Oct 03, 2016 at 08:36:56PM -0300, James Almer wrote:
>> This patchsets implements the feature requested on ticket #4347.
>> The first three patches are preparation work. The first one isn't
>> strictly related to the implementation, but comes in handy
>> nonetheless.
>>
>> Patches 4 to 11 can be squashed into a single commit before pushing
>> if that's prefered, but for review purposes i split things as one
>> patch per Level 1 element being adapted to write a CRC32 element.
>>
>> Fate tests are updated as needed.
> 
> some questions
> Does this reduce writing speed ? for example when remuxing high
> bitrate data like rawvideo ?

The bulk of the CRC calculation is done once per level 1 element, so it
shouldn't affect remuxing speed in a considerable way. But if preferred,
i could see about adding an option to disable it.

> 
> does this increase latency as in case of streaming ?
> it seemed not from reading the code but iam asking anyway to double
> check

The code mentions the output protocol is not seekable in the case of
streaming. CRC is not calculated and the clusters are written the same
way as before in such scenarios, so it wouldn't make a difference at
all.

> 
> are there any cases where this unreasonably increases memory
> consumption ? (thinking of OOM issues here not a few %)
> probably not but again asking to be sure, you know the code as
> author better ...

Technically, only if the user gives an unreasonable cluster_size_limit
or cluster_time_limit value. But not even then because there are other
checks in the codebase to start new clusters at for example every
keyframe, or when a block's relative timestamp can't be stored as a
signed 2 byte value in the block's header (commit 7923aa0f).

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

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: remove unused and errorneous AVFrame timestamp check

[Hendrik Leppkes]

On Tue, Oct 4, 2016 at 4:44 PM, James Almer  wrote:
> On 10/4/2016 11:35 AM, Hendrik Leppkes wrote:
>> On Tue, Oct 4, 2016 at 4:32 PM, wm4  wrote:
>>> On Tue, 4 Oct 2016 14:15:03 +0200
>>> Michael Niedermayer  wrote:
>>>
 On Tue, Oct 04, 2016 at 01:52:02PM +0200, Hendrik Leppkes wrote:
> On Tue, Oct 4, 2016 at 1:44 PM, Hendrik Leppkes  
> wrote:
>> On Tue, Oct 4, 2016 at 1:23 PM, Michael Niedermayer
>>  wrote:
>>> On Tue, Oct 04, 2016 at 08:41:42AM +0200, Hendrik Leppkes wrote:
 On Tue, Oct 4, 2016 at 4:05 AM, Michael Niedermayer
  wrote:
> On Sat, Oct 01, 2016 at 04:15:45PM +0200, Hendrik Leppkes wrote:
>> Decoders have previously not used AVFrame.pts, and with the upcoming
>> deprecation of pkt_pts (in favor of pts), this would lead to an 
>> errorneous
>> interpration of timestamps.
>
> I probably misunderstand the commit message but
> If code is changed in a user application that cannot really lift
> some blockage from changing a lib.
> a lib can only change in an incompaible way with (deprecation and)
> major version bump.
>

 The lib never did what this code suggests it did, not that I remember
 (so at least not for a long long time).
>>>
>>> release/2.0 with
>>>
>>> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>>> index 29d5492..57c8d50 100644
>>> --- a/libavcodec/utils.c
>>> +++ b/libavcodec/utils.c
>>> @@ -2008,7 +2008,7 @@ int attribute_align_arg 
>>> avcodec_decode_video2(AVCodecContext *avctx, AVFrame *pi
>>>  avci->to_free.extended_data = avci->to_free.data;
>>>  memset(picture->buf, 0, sizeof(picture->buf));
>>>  }
>>> -
>>> +av_assert0(picture->pts == 0 || picture->pts == AV_NOPTS_VALUE);
>>>  avctx->frame_number++;
>>>  av_frame_set_best_effort_timestamp(picture,
>>> guess_correct_pts(avctx,
>>>
>>> causes many tests to fail, indicating that AVFrame.pts was set for
>>> several video decoders, the ffmpeg code is audio decoder specific
>>> and i failed to find a case where it was triggered, i tried IIRC 3
>>> or so checkouts from the past
>>>
>>> so AVFrame.pts was maybe never set for decoding audio but it was set
>>> for video
>>
>> Can you extend the test to add "|| picture->pts == picture->pkt_pts"?
>> Because thats what it would be set to after the merge. A quick check
>> in the 2.0 code base looks like some decoders did set that, but to the
>> exact same value as pkt_pts (which is what the merge is proposing
>> right now as well)
>>
>
> And I found this (after 2.0):
> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=a1c5cc429d99216406170eac7e8352860076d3e8
>
> Which apparently set pts for mpeg4 to a number parsed from the
> bitstream, entirely uncorrelated to container or audio timestamps, so
> using them would have been rather impractical for any real use-cases.

 They can be usfull, some random examples:

 playing MPEG4-ES with timing stored from the bitstream (assuming there
   is no demuxer lib used that is capable to extract them)

 forensics, raw video stream could have its timing
   recovered, a video with manipulated container timestamps could be
   detected.

 error correction, if the container level timestamps are lost or
   corrupted the stream level ones can be used to recreate them

 There may be more, these are just some of the top of my head,
 not your mainstream multimedia player stuff maybe but they arent
 useless

 [...]

>>>
>>> They don't belong into the AVFrame.pts field, though.
>>
>> And they don't go in there anymore right now, so thats that.
>>
>> The real question is, what do we do about this merge now?
>> Can we set AVFrame.pts to the same value as AVFrame.pkt_pts safely,
>> considering it was unused in the current ABI/API, or would that be
>> considered an API break and we better delay this change until the next
>> major?
>>
>> - Hendrik
>
> Delaying it could result in further merges becoming technically wrong,
> or at least require extra manual changes for them to not misbehave in
> our tree.
>
> IMO merge it now, and if needed/preferred, we could make sure it
> doesn't make it to 3.2
>

Last call for any actual and clear objections to going forward with
this route. I would like to get merging a bunch over the weekend so we
get some progress here.

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

Re: [FFmpeg-devel] [PATCH 3/3] lavc/mediacodecdec: fix size variable shadowing in ff_mediacodec_dec_decode

[Michael Niedermayer]

On Thu, Oct 06, 2016 at 02:31:57PM +0200, Matthieu Bouron wrote:
> From: Matthieu Bouron 
> 
> Fixes incompatible pointer type warning on 64-bit systems.
> ---
>  libavcodec/mediacodecdec.c | 1 -
>  1 file changed, 1 deletion(-)

LGTM

thx

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [PATCH 3/4] lavc/utils: avcodec_string: dump field order when known

[Tobias Rapp]

On 04.10.2016 06:49, Rodger Combs wrote:

---
 libavcodec/utils.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 6f4df93..a0931c6 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3228,6 +3228,21 @@ void avcodec_string(char *buf, int buf_size, 
AVCodecContext *enc, int encode)
 av_get_colorspace_name(enc->colorspace));
 }

+if (enc->field_order != AV_FIELD_UNKNOWN) {
+const char *field_order = "progressive";
+if (enc->field_order == AV_FIELD_TT)
+field_order = "top first";
+else if (enc->field_order == AV_FIELD_BB)
+field_order = "bottom first";
+else if (enc->field_order == AV_FIELD_TB)
+field_order = "top coded first, swapped";
+else if (enc->field_order == AV_FIELD_BT)
+field_order = "bottom coded first, swapped";


In the list of comma-separated information tokens it might not be 
obvious to the user that ", swapped" semantically belongs to the 
preceding "top coded first". What about "top coded first (swapped)" and 
"bottom coded first (swapped)"?


Just my personal feeling.


+
+av_strlcatf(detail, sizeof(detail), "%s, ", field_order);
+}
+
+
 if (av_log_get_level() >= AV_LOG_DEBUG &&
 enc->chroma_sample_location != AVCHROMA_LOC_UNSPECIFIED)
 av_strlcatf(detail, sizeof(detail), "%s, ",



Regards,
Tobias

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

[FFmpeg-devel] [PATCH 2/3] lavc/mediacodecdec: rename dequeued_buffer_nb to output_buffer_count

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libavcodec/mediacodecdec.c | 6 +++---
 libavcodec/mediacodecdec.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 2ab173b..3d519ca 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -427,7 +427,7 @@ static int mediacodec_dec_flush_codec(AVCodecContext 
*avctx, MediaCodecDecContex
 FFAMediaCodec *codec = s->codec;
 int status;
 
-s->dequeued_buffer_nb = 0;
+s->output_buffer_count = 0;
 
 s->draining = 0;
 s->flushing = 0;
@@ -621,7 +621,7 @@ int ff_mediacodec_dec_decode(AVCodecContext *avctx, 
MediaCodecDecContext *s,
 /* If the codec is flushing or need to be flushed, block for a fair
  * amount of time to ensure we got a frame */
 output_dequeue_timeout_us = OUTPUT_DEQUEUE_BLOCK_TIMEOUT_US;
-} else if (s->dequeued_buffer_nb == 0) {
+} else if (s->output_buffer_count == 0) {
 /* If the codec hasn't produced any frames, do not block so we
  * can push data to it as fast as possible, and get the first
  * frame */
@@ -661,7 +661,7 @@ int ff_mediacodec_dec_decode(AVCodecContext *avctx, 
MediaCodecDecContext *s,
 }
 
 *got_frame = 1;
-s->dequeued_buffer_nb++;
+s->output_buffer_count++;
 } else {
 status = ff_AMediaCodec_releaseOutputBuffer(codec, index, 0);
 if (status < 0) {
diff --git a/libavcodec/mediacodecdec.h b/libavcodec/mediacodecdec.h
index 52c8bf1..7b0b7bb 100644
--- a/libavcodec/mediacodecdec.h
+++ b/libavcodec/mediacodecdec.h
@@ -59,7 +59,7 @@ typedef struct MediaCodecDecContext {
 int crop_left;
 int crop_right;
 
-uint64_t dequeued_buffer_nb;
+uint64_t output_buffer_count;
 
 } MediaCodecDecContext;
 
-- 
2.10.0

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

Re: [FFmpeg-devel] [PATCH 00/11] CRC32 support for Matroska muxer

[Jerome Martinez]

Le 06/10/2016 à 12:29, Michael Niedermayer a écrit :

Does this reduce writing speed ?


in the same manner as e.g. reducing FFV1 writing speed with default 
configuration, i.e. with CRC per slice (same kind of job).
On my machine (i7 from 2012), CRC computing takes less than 1% of the 
CPU when I decode FFV1, so I estimate the impact of CRC on both FFV1 
level and Matroska level to less than 2% in case FFV1 is used. I don't 
think it would be a more with e.g. AVC as frame byte size is smaller.



for example when remuxing high bitrate data like rawvideo ?


On my machine (i7 from 2012), with the "4 bytes at once" algorithm used 
by FFmpeg if I well understood FFmpeg code on this part, I benched CRC 
computing at 1 GB/s per core, so it should be more than enough also for 
rawvideo.


CRC element could be an option as it is for FFV1, but I argue for having 
it set by default, for the same reasons it is set by default with FFV1.



[...]


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

[FFmpeg-devel] [PATCH 1/3] lavc/mediacodecdec: remove first output buffer timing debug log

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libavcodec/mediacodecdec.c | 8 
 libavcodec/mediacodecdec.h | 3 ---
 2 files changed, 11 deletions(-)

diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 0faa4cf..2ab173b 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -439,9 +439,6 @@ static int mediacodec_dec_flush_codec(AVCodecContext 
*avctx, MediaCodecDecContex
 return AVERROR_EXTERNAL;
 }
 
-s->first_buffer = 0;
-s->first_buffer_at = av_gettime();
-
 return 0;
 }
 
@@ -458,7 +455,6 @@ int ff_mediacodec_dec_init(AVCodecContext *avctx, 
MediaCodecDecContext *s,
 AV_PIX_FMT_NONE,
 };
 
-s->first_buffer_at = av_gettime();
 s->refcount = 1;
 
 pix_fmt = ff_get_format(avctx, pix_fmts);
@@ -636,10 +632,6 @@ int ff_mediacodec_dec_decode(AVCodecContext *avctx, 
MediaCodecDecContext *s,
 if (index >= 0) {
 int ret;
 
-if (!s->first_buffer++) {
-av_log(avctx, AV_LOG_DEBUG, "Got first buffer after %fms\n", 
(av_gettime() - s->first_buffer_at) / 1000);
-}
-
 av_log(avctx, AV_LOG_DEBUG, "Got output buffer %zd"
 " offset=%" PRIi32 " size=%" PRIi32 " ts=%" PRIi64
 " flags=%" PRIu32 "\n", index, info.offset, info.size,
diff --git a/libavcodec/mediacodecdec.h b/libavcodec/mediacodecdec.h
index 8613352..52c8bf1 100644
--- a/libavcodec/mediacodecdec.h
+++ b/libavcodec/mediacodecdec.h
@@ -61,9 +61,6 @@ typedef struct MediaCodecDecContext {
 
 uint64_t dequeued_buffer_nb;
 
-int first_buffer;
-double first_buffer_at;
-
 } MediaCodecDecContext;
 
 int ff_mediacodec_dec_init(AVCodecContext *avctx,
-- 
2.10.0

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

[FFmpeg-devel] [PATCH 3/3] lavc/mediacodecdec: fix size variable shadowing in ff_mediacodec_dec_decode

[Matthieu Bouron]

From: Matthieu Bouron 

Fixes incompatible pointer type warning on 64-bit systems.
---
 libavcodec/mediacodecdec.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 3d519ca..126de17 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -561,7 +561,6 @@ int ff_mediacodec_dec_decode(AVCodecContext *avctx, 
MediaCodecDecContext *s,
 }
 
 while (offset < pkt->size || (need_draining && !s->draining)) {
-int size;
 
 index = ff_AMediaCodec_dequeueInputBuffer(codec, 
input_dequeue_timeout_us);
 if (ff_AMediaCodec_infoTryAgainLater(codec, index)) {
-- 
2.10.0

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

Re: [FFmpeg-devel] [PATCH] avcodec/qsvenc_h264: fix segfault when a53 SEI is not available

[Michael Niedermayer]

On Thu, Oct 06, 2016 at 03:08:18PM +0700, nablet developer wrote:
> 
> > 
> > you have set the author for your git to "Nablet Developer"
> > is this intended? Do you not want your name to be in the Author field ?
> > If you dont mind your name to be in the author field then please
> > resubmit the patch with correct Author
> > 
> 
> yes, it's intentional, please apply as is with git Author field set to 
> "Nablet Developer". thx.

ok, applied

thanks

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

Re: [FFmpeg-devel] [PATCH]lavu/hwaccel_vaapi: Add a fixme for the missing byte_order check

[wm4]

On Thu, 6 Oct 2016 10:34:35 +0100
Mark Thompson  wrote:

> On 06/10/16 09:05, Carl Eugen Hoyos wrote:
> > 2016-10-05 21:55 GMT+02:00 Mark Thompson :
> > 
> > What I meant is:
> > How can "LE" make sense for an 8bit planar format?  
> 
> It does not.  So, another reason to ignore that field.
> 
> > (And what does it tell us about the author?)
> > This of course assumes that "YV12" is planar, if it
> > isn't, I simply misunderstand the whole code.  
> 
> Yes, YV12 is planar: it is ffmpeg YUV420P with the two chroma planes swapped.
> 
> >> For example, I can do screen capture in X with:
> >>
> >> ffmpeg -y -vaapi_device /dev/dri/renderD128 -video_size 1920x1080 
> >> -framerate 30 -f x11grab -i :0 -vf 'hwupload,scale_vaapi=1920:1080:nv12' 
> >> -c:v h264_vaapi out.mp4
> >>
> >> which captures in bgr0, uploads it to the GPU, converts it to
> >> nv12 and encodes it as H.264 there.  Alternatively, I can add
> >> 'format=rgb0' at the start of the filter chain to convert and
> >> upload in a different RGB format, and that produces the
> >> correct output too.  
> > 
> > Thank you for confirming this.
> > 
> > Do you think vaapi's P010 should be mapped to FFmpeg's
> > P010LE instead of P010?  
> 
> P010 is defined as format with a 16-bit unit size, so the native format on a 
> BE
> system should be P010BE.  I admit that confusion is likely, though, given that
> the actual hardware may be a graphics card which normally works with an LE 
> host.
>  We may need to look somewhere else for the answer at that point (possibly the
> byte_order field, assuming the drivers manage to fill it correctly in such 
> cases).
> 
> I would prefer to only consider this problem once we have some working system 
> to
> test on.  On the other hand, if you wish to submit a patch changing it now I
> would not mind - it would have no effect on current use because the one system
> with working 10-bit support is LE-only.

Is it even theoretically possible to have hardware using vaapi on big
endian systems? vaapi is for modern Intel GPUs, which AFAIK are all
little endian.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 00/11] CRC32 support for Matroska muxer

[Michael Niedermayer]

On Mon, Oct 03, 2016 at 08:36:56PM -0300, James Almer wrote:
> This patchsets implements the feature requested on ticket #4347.
> The first three patches are preparation work. The first one isn't
> strictly related to the implementation, but comes in handy
> nonetheless.
> 
> Patches 4 to 11 can be squashed into a single commit before pushing
> if that's prefered, but for review purposes i split things as one
> patch per Level 1 element being adapted to write a CRC32 element.
> 
> Fate tests are updated as needed.

some questions
Does this reduce writing speed ? for example when remuxing high
bitrate data like rawvideo ?

does this increase latency as in case of streaming ?
it seemed not from reading the code but iam asking anyway to double
check

are there any cases where this unreasonably increases memory
consumption ? (thinking of OOM issues here not a few %)
probably not but again asking to be sure, you know the code as
author better ...

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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

Re: [FFmpeg-devel] [PATCH]lavu/hwaccel_vaapi: Add a fixme for the missing byte_order check

[Carl Eugen Hoyos]

2016-10-06 11:34 GMT+02:00 Mark Thompson :

>> Do you think vaapi's P010 should be mapped to FFmpeg's
>> P010LE instead of P010?

> I would prefer to only consider this problem once we have
> some working system to test on.

No objections.

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

Re: [FFmpeg-devel] [PATCH]lavu/hwaccel_vaapi: Add a fixme for the missing byte_order check

[Mark Thompson]

On 06/10/16 09:05, Carl Eugen Hoyos wrote:
> 2016-10-05 21:55 GMT+02:00 Mark Thompson :
> 
> What I meant is:
> How can "LE" make sense for an 8bit planar format?

It does not.  So, another reason to ignore that field.

> (And what does it tell us about the author?)
> This of course assumes that "YV12" is planar, if it
> isn't, I simply misunderstand the whole code.

Yes, YV12 is planar: it is ffmpeg YUV420P with the two chroma planes swapped.

>> For example, I can do screen capture in X with:
>>
>> ffmpeg -y -vaapi_device /dev/dri/renderD128 -video_size 1920x1080 -framerate 
>> 30 -f x11grab -i :0 -vf 'hwupload,scale_vaapi=1920:1080:nv12' -c:v 
>> h264_vaapi out.mp4
>>
>> which captures in bgr0, uploads it to the GPU, converts it to
>> nv12 and encodes it as H.264 there.  Alternatively, I can add
>> 'format=rgb0' at the start of the filter chain to convert and
>> upload in a different RGB format, and that produces the
>> correct output too.
> 
> Thank you for confirming this.
> 
> Do you think vaapi's P010 should be mapped to FFmpeg's
> P010LE instead of P010?

P010 is defined as format with a 16-bit unit size, so the native format on a BE
system should be P010BE.  I admit that confusion is likely, though, given that
the actual hardware may be a graphics card which normally works with an LE host.
 We may need to look somewhere else for the answer at that point (possibly the
byte_order field, assuming the drivers manage to fill it correctly in such 
cases).

I would prefer to only consider this problem once we have some working system to
test on.  On the other hand, if you wish to submit a patch changing it now I
would not mind - it would have no effect on current use because the one system
with working 10-bit support is LE-only.

Thanks,

- Mark

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

Re: [FFmpeg-devel] [PATCH]lavu/hwaccel_vaapi: Add a fixme for the missing byte_order check

[Carl Eugen Hoyos]

2016-10-05 21:55 GMT+02:00 Mark Thompson :
> On 05/10/16 19:02, Carl Eugen Hoyos wrote:
>> 2016-10-05 16:39 GMT+02:00 Mark Thompson :
>>> On 05/10/16 13:06, Carl Eugen Hoyos wrote:

 I cannot test here but afaict, the current implementation of
 vaapi_pix_fmt_from_fourcc() can't be correct.
>>
 +// FIXME: Take VAImageFormat->byte_order into account
  static struct {
  unsigned int fourcc;
  unsigned int rt_format;
>>
>>> Have you found / had reported to you some case which
>>> causes a problem here?  If so, please could you offer some
>>> more detail about it (especially the driver being used).
>>
>> No, I wouldn't even know how to use the code in question.
>>
>>> In the cases I know of, the VAImageFormat structures are
>>> are all hard-coded such that the fourcc is really the only
>>> meaningful information in them:
>>
>> So the byte_order field in VAImageFormat has no meaning
>> and is completely useless?
>
> Mostly yes, I think.

Interesting.

> As you observe in the links below, it is hard-coded in the two
> main drivers to be either undefined or VA_LSB_FIRST.

Google finds some occurrences of VA_MSB_FIRST.

>>> 
>>
>> This link was the reason for my mail.
>>
>>> * 
>>> 
>>
>> Not sure if this makes sense...
>
> Looking at 
> 
> at the same time might make the use of that table clearer.

What I meant is:
How can "LE" make sense for an 8bit planar format?
(And what does it tell us about the author?)
This of course assumes that "YV12" is planar, if it
isn't, I simply misunderstand the whole code.

>>> This is reflected by the use in hwcontext_vaapi.c, which only
>>> fetches the driver's version of the structure in order to pass
>>> it back in vaCreateImage() calls - the other fields are never
>>> touched at all.
>>
>> This sounds as if there is no mapping from VAImageFormat
>> to AVPixelFormat but I misunderstand this, no?
>
> The fourcc (which is VAImageFormat.fourcc) is the thing which
> is actually used for the mapping.  The other components do not
> add anything to the interpretation, so they are ignored.  Indeed,
> the fourcc by itself is used in most other places
> (vaCreateSurfaces(),  notably), while only vaCreateImage()
> takes the VAImageFormat argument.

I start to understand that for 8bpc rgb, the mapping is relevant
(not the byte order) and is reflected in the fourcc.

>>> So, I don't think this comment adds any value.
>>
>> Do I understand correctly that one of the RGB formats
>> work correctly on your (little-endian) system (and looks
>> ugly if you replace it with anything else)?
>
> I'm not sure what what you mean by this question?
> The mapping works correctly for all of the supported RGB
> formats in the table, though I agree that if I modified the
> code to be incorrect then the output would be wrong.
>
> For example, I can do screen capture in X with:
>
> ffmpeg -y -vaapi_device /dev/dri/renderD128 -video_size 1920x1080 -framerate 
> 30 -f x11grab -i :0 -vf 'hwupload,scale_vaapi=1920:1080:nv12' -c:v h264_vaapi 
> out.mp4
>
> which captures in bgr0, uploads it to the GPU, converts it to
> nv12 and encodes it as H.264 there.  Alternatively, I can add
> 'format=rgb0' at the start of the filter chain to convert and
> upload in a different RGB format, and that produces the
> correct output too.

Thank you for confirming this.

Do you think vaapi's P010 should be mapped to FFmpeg's
P010LE instead of P010?

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