[FFmpeg-devel] [PATCH v2] avformat/hlsenc: deprecate hls_wrap option

[Steven Liu]

When user use the hls_wrap, there have many problem:
1. some platform refersh the old but usefull segment
2. CDN(Content Delivery Network) Deliver HLS not friendly

The hls_wrap is used to wrap segments for use little space,
now user can use hls_list_size and hls_flags delete_segments
instead it.

Signed-off-by: Steven Liu 
---
 doc/muxers.texi   |  5 ++---
 libavformat/hlsenc.c  | 24 
 libavformat/version.h |  4 
 3 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index cb875a4..c00e296 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -441,9 +441,8 @@ parameters. Values containing @code{:} special characters 
must be
 escaped.
 
 @item hls_wrap @var{wrap}
-Set the number after which the segment filename number (the number
-specified in each segment file) wraps. If set to 0 the number will be
-never wrapped. Default value is 0.
+This is a deprecated option, you can use @code {hls_list_size} 
+and @code{hls_flags delete_segments} instead it
 
 This option is useful to avoid to fill the disk with many segment
 files, and limits the maximum number of segment files written to disk
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 17d4fe4..736c949 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -101,7 +101,9 @@ typedef struct HLSContext {
 float time;// Set by a private option.
 float init_time;   // Set by a private option.
 int max_nb_segments;   // Set by a private option.
+#if FF_API_HLS_WRAP
 int  wrap; // Set by a private option.
+#endif
 uint32_t flags;// enum HLSFlags
 uint32_t pl_type;  // enum PlaylistType
 char *segment_filename;
@@ -566,7 +568,11 @@ static int hls_append_segment(struct AVFormatContext *s, 
HLSContext *hls, double
 hls->initial_prog_date_time += en->duration;
 hls->segments = en->next;
 if (en && hls->flags & HLS_DELETE_SEGMENTS &&
+#if FF_API_HLS_WRAP 
 !(hls->flags & HLS_SINGLE_FILE || hls->wrap)) {
+#else
+!(hls->flags & HLS_SINGLE_FILE)) {
+#endif
 en->next = hls->old_segments;
 hls->old_segments = en;
 if ((ret = hls_delete_old_segments(hls)) < 0)
@@ -834,7 +840,11 @@ static int hls_start(AVFormatContext *s)
   sizeof(vtt_oc->filename));
 } else if (c->max_seg_size > 0) {
 if (replace_int_data_in_filename(oc->filename, sizeof(oc->filename),
+#if FF_API_HLS_WRAP
 c->basename, 'd', c->wrap ? c->sequence % c->wrap : c->sequence) < 
1) {
+#else
+c->basename, 'd', c->sequence) < 1) {
+#endif
 av_log(oc, AV_LOG_ERROR, "Invalid segment filename template 
'%s', you can try to use -use_localtime 1 with it\n", c->basename);
 return AVERROR(EINVAL);
 }
@@ -853,7 +863,11 @@ static int hls_start(AVFormatContext *s)
 if (!filename)
 return AVERROR(ENOMEM);
 if (replace_int_data_in_filename(oc->filename, 
sizeof(oc->filename),
+#if FF_API_HLS_WRAP
 filename, 'd', c->wrap ? c->sequence % c->wrap : 
c->sequence) < 1) {
+#else
+filename, 'd', c->sequence) < 1) {
+#endif
 av_log(c, AV_LOG_ERROR,
"Invalid second level segment filename template 
'%s', "
 "you can try to remove second_level_segment_index 
flag\n",
@@ -910,13 +924,21 @@ static int hls_start(AVFormatContext *s)
 av_free(fn_copy);
 }
 } else if (replace_int_data_in_filename(oc->filename, 
sizeof(oc->filename),
+#if FF_API_HLS_WRAP
c->basename, 'd', c->wrap ? c->sequence % c->wrap : 
c->sequence) < 1) {
+#else
+   c->basename, 'd', c->sequence) < 1) {
+#endif
 av_log(oc, AV_LOG_ERROR, "Invalid segment filename template '%s' 
you can try to use -use_localtime 1 with it\n", c->basename);
 return AVERROR(EINVAL);
 }
 if( c->vtt_basename) {
 if (replace_int_data_in_filename(vtt_oc->filename, 
sizeof(vtt_oc->filename),
+#if FF_API_HLS_WRAP
 c->vtt_basename, 'd', c->wrap ? c->sequence % c->wrap : 
c->sequence) < 1) {
+#else
+c->vtt_basename, 'd', c->sequence) < 1) {
+#endif
 av_log(vtt_oc, AV_LOG_ERROR, "Invalid segment filename 
template '%s'\n", c->vtt_basename);
 return AVERROR(EINVAL);
 }
@@ -1421,7 +1443,9 @@ static const AVOption options[] = {
 {"hls_list_size", "set maximum number of playlist entries",  
OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0, INT_MAX, E},
 {"hls_ts_options","set hls mpegts list of options for the container format 
used for hls", OFFSET(format_options_str), AV_OPT_TYPE_STRING, {.str = NULL},  
0, 0,E},
 {"hls_vtt_options","set hls vtt 

Re: [FFmpeg-devel] [rfc] ffmpeg security issue mailing list

[wm4]

On Wed, 8 Feb 2017 22:07:24 +0100
Michael Niedermayer  wrote:

> Hi all
> 
> On Sat, Aug 08, 2015 at 03:51:11AM +0200, Michael Niedermayer wrote:
> > On Fri, Aug 07, 2015 at 07:46:55PM -0400, compn wrote:  
> > > hello,
> > > 
> > > some of you know that we have a list for security / CVE issues.
> > > some of you did not know this.
> > > 
> > > i think it is a private list due to not wanting people to make exploits
> > > before we have a chance to fix them. of course, if no one is subscribed
> > > to review/fix issues then they will never get fixed.
> > > 
> > > so if you are a regular developer who wants access to this list, please
> > > speak up.
> > > 
> > > i do not run nor admin the security email/list (nor do i know who does)
> > > so please dont ask me questions about it.  
> > 
> > I guess, i "de facto" admin the security "email/list".
> > if someone wants to help with security issues, mail me
> > 
> > but there are no open security issues and if there was one i very
> > likely would fix it ASAP  
> 
> A small update due to never? before seen interrest in ffmpeg-security
> in the recent weeks/months
> 
> How to get on the ffmpeg-security "list"
> 
> People working on security in FFmpeg, thats maybe fixing many coverity
> issues, backporingt fixes to releases, maintaining FFmpeg releases, ...
> have an obsession with fixing bugs about undefined behavior or bugs
> about crashes and race conditions on trac. Or an obsession with testing
> every bugfix and who want and need access to ffmpeg-security should
> be on ffmpeg-security
> In short people on ffmpeg-security should need to be on ffmpeg-security
> If you fall in this kind of category, please mail me
> 
> Or someone who reviews commits and obtains CVE#s for everything that
> could be exploitable ...
> 
> I dont think we should give access to ffmpeg-security to everyone who
> wants to be on the list. This is of course something the community
> has to decide and not me, iam just err-ing on the safe side and am very
> restrictive on who is added.
> 
> About the content i must warn you the list is really not very
> interresting as in trying to find together with debian someone at
> chromium who knows what the CVEs they registered about FFmpeg actually
> are about ... and then it embarassingly is a patch on ffmpeg-devel
> that is stuck in review and not applied and now i can redo the releases ...
> ... Where are the people caring about security ? why did they not
> pick these 2 public patches up, change what they felt needs changing
> and pushed them ?
> and there are the fuzz samples that need more than 20sec, these are
> the main type of reported issue recently after ive succeeded to stop
> the oom kind.
> 
> Also there are no open security(*) issues i know of, and if there would
> be i likely would fix them ASAP. Not saying that help is unwelcome
> or that its impossible for me to make a mistake or miss something ...
> 
> (*) I assume here that fuzz samples taking more than 20sec or integer
> overflows in DSP code arent security issues. Iam working on fixing
> these too but for this category there are open issues.
> 
> PS: If you want access to the oss-fuzz reports, they all seem
> automatically public 7 days after being fixed
> 
> [...]
> 

I'd like to get on the ffmpeg-security mailing list to review patches.

I've asked multiple times, but never received an answer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] cuvid: Always calculate second field PTS from frame rate

[wm4]

On Wed, 8 Feb 2017 23:31:54 +0100
Miroslav Slugeň  wrote:

> It is much more robust solution to always calculate second field (when 
> deinterlacing) PTS from frame rate, then relating on previous PTS, 
> because if there are B frames in input and some video frames are 
> corrupted (dropped) it will calculate wrong PTS for second field and 
> could hang on encoding in do_video_out.
> 
> 

Seems more like it'd make it less robust, because many files don't have
a useful framerate set.

I'm not sure why encoding is hanging (?), but that sounds like a
different problem.

Also, such reasoning should go into the commit message, instead of just
the mail.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Implement optimal huffman encoding for (M)JPEG.

[Michael Niedermayer]

On Thu, Feb 09, 2017 at 04:30:02AM +0100, Michael Niedermayer wrote:
> On Thu, Feb 09, 2017 at 03:17:23AM +, Rostislav Pehlivanov wrote:
> > On 9 February 2017 at 02:44, Michael Niedermayer 
> [...]
> > > i sadly dont have time to do a more complete review ATM (need sleep)
> > > but this patch doesnt look like it was ready for being pushed
> > >
> > 
> > Perhaps I was too hasty to review it
> > 
> > I'll take a look at fixing the 2 pass mode tomorrow if I have the time,
> > although if you have spare
> > time and know how to fix it go ahead.
> 
> its bad time for me, tomorrow is gsoc register deadline, and i also

i mean reynaldo already filled all out  (great thanks to him) so
we are good about that but i wanted to double check it all


> need to do new releases, i doubt ill be able to do all
> and that reminds me i should be sleeping
> 
> [...
> 
> -- 
> 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



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


-- 
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] Implement optimal huffman encoding for (M)JPEG.

[Michael Niedermayer]

On Thu, Feb 09, 2017 at 03:17:23AM +, Rostislav Pehlivanov wrote:
> On 9 February 2017 at 02:44, Michael Niedermayer 
[...]
> > i sadly dont have time to do a more complete review ATM (need sleep)
> > but this patch doesnt look like it was ready for being pushed
> >
> 
> Perhaps I was too hasty to review it
> 
> I'll take a look at fixing the 2 pass mode tomorrow if I have the time,
> although if you have spare
> time and know how to fix it go ahead.

its bad time for me, tomorrow is gsoc register deadline, and i also
need to do new releases, i doubt ill be able to do all
and that reminds me i should be sleeping

[...

-- 
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

Re: [FFmpeg-devel] [PATCH] Implement optimal huffman encoding for (M)JPEG.

[Rostislav Pehlivanov]

On 9 February 2017 at 02:44, Michael Niedermayer 
wrote:

>
> > +
> > +int ff_mjpeg_encode_mb(MpegEncContext *s, int16_t block[12][64])
> > +{
> > +int i, is_chroma_420;
> > +
> > +// Number of bits used depends on future data.
> > +// So, nothing that relies on encoding many times and taking the
> > +// one with the fewest bits will work properly here.
> > +if (s->i_tex_bits != MJPEG_HUFFMAN_EST_BITS_PER_CODE *
> > +s->mjpeg_ctx->huff_ncode) {
>
> > +av_log(NULL, AV_LOG_ERROR, "Unsupported encoding method\n");
>
> Missing context for av_log()
>

Fixed


>
> [...]
> > diff --git a/libavcodec/mjpegenc_common.h b/libavcodec/mjpegenc_common.h
> > index 6e51ca0..7d760f8 100644
> > --- a/libavcodec/mjpegenc_common.h
> > +++ b/libavcodec/mjpegenc_common.h
> > @@ -40,4 +40,6 @@ void ff_mjpeg_init_hvsample(AVCodecContext *avctx,
> int hsample[4], int vsample[4
> >  void ff_mjpeg_encode_dc(PutBitContext *pb, int val,
> >  uint8_t *huff_size, uint16_t *huff_code);
> >
> > +av_cold void init_uni_ac_vlc(const uint8_t huff_size_ac[256], uint8_t
> *uni_ac_vlc_len);
>
> missing ff/av prefix
>

Fixed


> [...]
> > +// Validate the computed lengths satisfy the JPEG restrictions and is
> optimal.
> > +static int check_lengths(int L, int expected_length,
> > + const int *probs, int nprobs)
> > +{
> > +HuffTable lengths[256];
> > +PTable val_counts[256];
> > +int actual_length = 0, i, j, k, prob, length;
> > +int ret = 0;
> > +double cantor_measure = 0;
>
> > +assert(nprobs <= 256);
>
> should be av_assert*()
>
>
Fixed


>
> [...]
> > +static const int probs_zeroes[] = {6, 6, 0, 0, 0};
> > +static const int probs_skewed[] = {2, 0, 0, 0, 0, 1, 0, 0, 20, 0, 2,
> > +0, 10, 5, 1, 1, 9, 1, 1, 6, 0, 5, 0, 1, 0, 7, 6, 1, 1, 5, 0, 0, 0,
> 0,
> > +11, 0, 0, 0, 51, 1, 0, 20, 0, 1, 0, 0, 0, 0, 6, 106, 1, 0, 1, 0, 2,
> 1,
> > +16, 0, 0, 5, 0, 0, 0, 4, 3, 15, 4, 4, 0, 0, 0, 3, 0, 0, 1, 0, 3, 0,
> 3,
> > +2, 2, 0, 0, 4, 3, 40, 1, 2, 0, 22, 0, 0, 0, 9, 0, 0, 0, 0, 1, 1, 0,
> 1,
> > +6, 11, 4, 10, 28, 6, 1, 0, 0, 9, 9, 4, 0, 0, 0, 0, 8, 33844, 2, 0,
> 2,
> > +1, 1, 5, 0, 0, 1, 9, 1, 0, 4, 14, 4, 0, 0, 3, 8, 0, 51, 9, 6, 1, 1,
> 2,
> > +2, 3, 1, 5, 5, 29, 0, 0, 0, 0, 14, 29, 6, 4, 13, 12, 2, 3, 1, 0, 5,
> 4,
> > +1, 1, 0, 0, 29, 1, 0, 0, 0, 0, 4, 0, 0, 1, 0, 1, 7, 0, 42, 0, 0, 0,
> 0,
> > +0, 2, 0, 3, 9, 0, 0, 0, 2, 1, 0, 0, 6, 5, 6, 1, 2, 3, 0, 0, 0, 3,
> 0, 0,
> > +28, 0, 2, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 1, 0, 0, 0, 0, 23, 0, 0, 0,
> 0,
> > +0, 21, 1, 0, 3, 24, 2, 0, 0, 7, 0, 0, 1, 5, 1, 2, 0, 5};
> > +static const int probs_sat[] = {74, 8, 14, 7, 9345, 40, 0, 2014, 2, 1,
> > +115, 0, 2, 1, 194, 388, 20, 0, 0, 2, 1, 121, 1, 1583, 0, 16, 21, 2,
> 132,
> > +2, 15, 9, 13, 1, 0, 2293, 2, 8, 5, 2, 30, 0, 0, 4, 54, 783, 4, 1,
> 2, 4,
> > +0, 22, 93, 1, 143, 19, 0, 36, 32, 4, 6, 33, 3, 45, 0, 8, 1, 0, 18,
> 17, 1,
> > +0, 1, 0, 0, 1, 1004, 38, 3, 8, 90, 23, 0, 2819, 3, 0, 970, 158, 9,
> 6, 4,
> > +48, 4, 0, 1, 0, 0, 60, 3, 62, 0, 2, 2, 2, 279, 66, 16, 1, 20, 0, 7,
> 9,
> > +32, 1411, 6, 3, 27, 1, 5, 49, 0, 0, 0, 0, 0, 2, 10, 1, 1, 2, 3,
> 801, 3,
> > +25, 5, 1, 1, 0, 632, 0, 14, 18, 5, 8, 200, 4, 4, 22, 12, 0, 4, 1,
> 0, 2,
> > +4, 9, 3, 16, 7, 2, 2, 213, 0, 2, 620, 39303, 0, 1, 0, 2, 1, 183781,
> 1,
> > +0, 0, 0, 94, 7, 3, 4, 0, 4, 306, 43, 352, 76, 34, 13, 11, 0, 51, 1,
> 13,
> > +19, 0, 26, 0, 7276, 4, 207, 31, 1, 2, 4, 6, 19, 8, 17, 4, 6, 0,
> 1085, 0,
> > +0, 0, 3, 489, 36, 1, 0, 1, 9420, 294, 28, 0, 57, 5, 0, 9, 2, 0, 1,
> 2, 2,
> > +0, 0, 9, 2, 29, 2, 2, 7, 0, 5, 490, 0, 7, 5, 0, 1, 8, 0, 0, 23255,
> 0, 1};
>
> vertical align
>
>
Fixed


>
> > +
>
> > +// Test the example given on @see
> > +// http://guru.multimedia.cx/small-tasks-for-ffmpeg/
> > +int main(int argc, char **argv)
> > +{
> > +int i, ret = 0;
> > +// Probabilities of symbols 0..4
> > +static PTable val_counts[] = {
>
> static isnt needed here this is main()
>
>
Fixed


> i sadly dont have time to do a more complete review ATM (need sleep)
> but this patch doesnt look like it was ready for being pushed
>

Perhaps I was too hasty to review it

I'll take a look at fixing the 2 pass mode tomorrow if I have the time,
although if you have spare
time and know how to fix it go ahead.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Implement optimal huffman encoding for (M)JPEG.

[Michael Niedermayer]

On Wed, Feb 01, 2017 at 11:23:04PM -0800, Jerry Jiang wrote:
> > seems to break
> > make fate-vsynth1-mjpeg-444
> 
> Fixed.
> 

Missing commit message


[...]
> -void ff_mjpeg_encode_mb(MpegEncContext *s, int16_t block[12][64])
> +// Possibly reallocate the huffman code buffer, assuming blocks_per_mb.
> +// Set s->mjpeg_ctx->error on ENOMEM.
> +static void realloc_huffman(MpegEncContext *s, int blocks_per_mb)
>  {
> -int i;
> +MJpegContext *m = s->mjpeg_ctx;
> +size_t num_mbs, num_blocks, num_codes;
> +MJpegHuffmanCode *new_buf;
> +if (m->error) return;
> +// Make sure we have enough space to hold this frame.
> +num_mbs = s->mb_width * s->mb_height;
> +num_blocks = num_mbs * blocks_per_mb;
> +av_assert0(m->huff_ncode <=
> +   (s->mb_y * s->mb_width + s->mb_x) * blocks_per_mb * 64);
> +num_codes = num_blocks * 64;
> +
> +new_buf = av_fast_realloc(m->huff_buffer, >huff_capacity,
> +  num_codes * sizeof(MJpegHuffmanCode));
> +if (!new_buf) {
> +m->error = AVERROR(ENOMEM);
> +} else {
> +m->huff_buffer = new_buf;
> +}
> +}

why is the macroblock loop calling a "framebuffer" reallocation
function?
the frame size does not change from one maroblock to the next


> +
> +int ff_mjpeg_encode_mb(MpegEncContext *s, int16_t block[12][64])
> +{
> +int i, is_chroma_420;
> +
> +// Number of bits used depends on future data.
> +// So, nothing that relies on encoding many times and taking the
> +// one with the fewest bits will work properly here.
> +if (s->i_tex_bits != MJPEG_HUFFMAN_EST_BITS_PER_CODE *
> +s->mjpeg_ctx->huff_ncode) {

> +av_log(NULL, AV_LOG_ERROR, "Unsupported encoding method\n");

Missing context for av_log()



> +return AVERROR(EINVAL);
> +}
> +
>  if (s->chroma_format == CHROMA_444) {
> +realloc_huffman(s, 12);
>  encode_block(s, block[0], 0);
>  encode_block(s, block[2], 2);
>  encode_block(s, block[4], 4);
> @@ -196,10 +302,12 @@ void ff_mjpeg_encode_mb(MpegEncContext *s, int16_t 
> block[12][64])
>  encode_block(s, block[11], 11);
>  }
>  } else {
> +is_chroma_420 = (s->chroma_format == CHROMA_420);
> +realloc_huffman(s, 5 + (is_chroma_420 ? 1 : 3));
>  for(i=0;i<5;i++) {
>  encode_block(s, block[i], i);
>  }
> -if (s->chroma_format == CHROMA_420) {
> +if (is_chroma_420) {
>  encode_block(s, block[5], 5);
>  } else {
>  encode_block(s, block[6], 6);
> @@ -207,8 +315,11 @@ void ff_mjpeg_encode_mb(MpegEncContext *s, int16_t 
> block[12][64])
>  encode_block(s, block[7], 7);
>  }
>  }
> +if (s->mjpeg_ctx->error)
> +return s->mjpeg_ctx->error;
>  
> -s->i_tex_bits += get_bits_diff(s);
> +s->i_tex_bits = MJPEG_HUFFMAN_EST_BITS_PER_CODE * 
> s->mjpeg_ctx->huff_ncode;
> +return 0;
>  }

this patch also breaks 2 pass rate control

./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -vcodec mjpeg -pass 1 -t 10 -an -b 
5000k test1.avi
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -vcodec mjpeg -pass 2 -t 10 -an -b 
5000k test2.avi



[...]
> diff --git a/libavcodec/mjpegenc_common.c b/libavcodec/mjpegenc_common.c
> index 7a6fe746..8ec3df9 100644
> --- a/libavcodec/mjpegenc_common.c
> +++ b/libavcodec/mjpegenc_common.c
> @@ -33,8 +33,35 @@
>  #include "put_bits.h"
>  #include "mjpegenc.h"
>  #include "mjpegenc_common.h"
> +#include "mjpegenc_huffman.h"
>  #include "mjpeg.h"
>  

> +av_cold void init_uni_ac_vlc(const uint8_t huff_size_ac[256], uint8_t 
> *uni_ac_vlc_len)
> +{
> +int i;
> +
> +for (i = 0; i < 128; i++) {
> +int level = i - 64;
> +int run;
> +if (!level)
> +continue;
> +for (run = 0; run < 64; run++) {
> +int len, code, nbits;
> +int alevel = FFABS(level);
> +
> +len = (run >> 4) * huff_size_ac[0xf0];
> +
> +nbits= av_log2_16bit(alevel) + 1;
> +code = ((15) << 4) | nbits;
> +
> +len += huff_size_ac[code] + nbits;
> +
> +uni_ac_vlc_len[UNI_AC_ENC_INDEX(run, i)] = len;
> +// We ignore EOB as its just a constant which does not change 
> generally
> +}
> +}
> +}

This code is moved, it should have been in a seperate cosmetic patch



[...]
> diff --git a/libavcodec/mjpegenc_common.h b/libavcodec/mjpegenc_common.h
> index 6e51ca0..7d760f8 100644
> --- a/libavcodec/mjpegenc_common.h
> +++ b/libavcodec/mjpegenc_common.h
> @@ -40,4 +40,6 @@ void ff_mjpeg_init_hvsample(AVCodecContext *avctx, int 
> hsample[4], int vsample[4
>  void ff_mjpeg_encode_dc(PutBitContext *pb, int val,
>  uint8_t *huff_size, uint16_t *huff_code);
>  
> +av_cold void init_uni_ac_vlc(const uint8_t huff_size_ac[256], uint8_t 
> *uni_ac_vlc_len);

missing ff/av prefix


[...]
> +// Validate the computed lengths 

Re: [FFmpeg-devel] [PATCH] Implement optimal huffman encoding for (M)JPEG.

[Michael Niedermayer]

On Wed, Feb 01, 2017 at 11:23:04PM -0800, Jerry Jiang wrote:
> > seems to break
> > make fate-vsynth1-mjpeg-444
> 
> Fixed.
> 
> ---
>  Changelog|   1 +
>  doc/encoders.texi|  21 ++
>  libavcodec/Makefile  |   8 +-
>  libavcodec/mjpegenc.c| 243 
> +--
>  libavcodec/mjpegenc.h|  68 ++-
>  libavcodec/mjpegenc_common.c | 166 +++-
>  libavcodec/mjpegenc_common.h |   2 +
>  libavcodec/mjpegenc_huffman.c| 195 ++
>  libavcodec/mjpegenc_huffman.h|  74 +++
>  libavcodec/mpegvideo.h   |   1 +
>  libavcodec/mpegvideo_enc.c   |  17 +-
>  libavcodec/tests/.gitignore  |   1 +
>  libavcodec/tests/mjpegenc_huffman.c  | 163 +++
>  tests/fate/libavcodec.mak|   6 +
>  tests/fate/vcodec.mak|  12 +-
>  tests/ref/vsynth/vsynth1-mjpeg-huffman   |   4 +
>  tests/ref/vsynth/vsynth1-mjpeg-trell-huffman |   4 +
>  tests/ref/vsynth/vsynth2-mjpeg-huffman   |   4 +
>  tests/ref/vsynth/vsynth2-mjpeg-trell-huffman |   4 +
>  tests/ref/vsynth/vsynth3-mjpeg-huffman   |   4 +
>  tests/ref/vsynth/vsynth3-mjpeg-trell-huffman |   4 +
>  tests/ref/vsynth/vsynth_lena-mjpeg-huffman   |   4 +
>  tests/ref/vsynth/vsynth_lena-mjpeg-trell-huffman |   4 +
>  23 files changed, 914 insertions(+), 96 deletions(-)
>  create mode 100644 libavcodec/mjpegenc_huffman.c
>  create mode 100644 libavcodec/mjpegenc_huffman.h
>  create mode 100644 libavcodec/tests/mjpegenc_huffman.c
>  create mode 100644 tests/ref/vsynth/vsynth1-mjpeg-huffman
>  create mode 100644 tests/ref/vsynth/vsynth1-mjpeg-trell-huffman
>  create mode 100644 tests/ref/vsynth/vsynth2-mjpeg-huffman
>  create mode 100644 tests/ref/vsynth/vsynth2-mjpeg-trell-huffman
>  create mode 100644 tests/ref/vsynth/vsynth3-mjpeg-huffman
>  create mode 100644 tests/ref/vsynth/vsynth3-mjpeg-trell-huffman
>  create mode 100644 tests/ref/vsynth/vsynth_lena-mjpeg-huffman
>  create mode 100644 tests/ref/vsynth/vsynth_lena-mjpeg-trell-huffman

i somehow must have missed this patch resubmission

this breaks *jpeg slice multithreading

./ffmpeg  -i lena.pnm -threads 4 -thread_type slice file.jpg

result is just a green image and errors

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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: deprecate hls_wrap option

[Michael Niedermayer]

On Wed, Feb 08, 2017 at 10:54:06AM +0800, Steven Liu wrote:
> When user use the hls_wrap, there have many problem:
> 1. some platform refersh the old but usefull segment
> 2. CDN(Content Delivery Network) Deliver HLS not friendly
> 
> The hls_wrap is used to wrap segments for use little space,
> now user can use hls_list_size and hls_flags delete_segments
> instead it.
> 
> Signed-off-by: Steven Liu 
> ---
>  doc/muxers.texi   |  5 ++---
>  libavformat/hlsenc.c  | 24 
>  libavformat/version.h |  4 
>  3 files changed, 30 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index cb875a4..c00e296 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -441,9 +441,8 @@ parameters. Values containing @code{:} special characters 
> must be
>  escaped.
>  
>  @item hls_wrap @var{wrap}
> -Set the number after which the segment filename number (the number
> -specified in each segment file) wraps. If set to 0 the number will be
> -never wrapped. Default value is 0.
> +This is a deprecated option, you can use @code {hls_list_size} 
> +and @code{hls_flags delete_segments} instead it
>  
>  This option is useful to avoid to fill the disk with many segment
>  files, and limits the maximum number of segment files written to disk
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 17d4fe4..736c949 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -101,7 +101,9 @@ typedef struct HLSContext {
>  float time;// Set by a private option.
>  float init_time;   // Set by a private option.
>  int max_nb_segments;   // Set by a private option.
> +#ifdef FF_API_HLS_WRAP

should all be #if not #ifdef

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

Re: [FFmpeg-devel] GSoC 2017

[Michael Niedermayer]

On Thu, Feb 09, 2017 at 01:03:06AM +0100, Michael Niedermayer wrote:
> On Wed, Feb 08, 2017 at 09:07:09PM -0200, Pedro Arthur wrote:
> > 2017-01-27 1:01 GMT-02:00 Michael Niedermayer :
> > 
> > > we need more (backup) mentors, so yes, i think its needed
> > >
> > > also if you want to be mentor for a swscale related project i would
> > > support that idea
> > 
> > 
> > Hi, sorry for the late reply.
> > I think  implementing a cascade-less swscale could be a good project.
> > If you think  it is doable for a GSOC project, I'm fine with it.
> 
> It depends on the student, it doesnt sound too complex but students
> abilities varies alot and its quite possible there will be noone
> interrested in any specific project 
> 
> 
> > I just doesn't know a good qualification task.
> 
> Something which shows that the student can work with the swscale
> codebase, not something that is just copy and paste work
> 
> Either way, this can be added later

also in absence of any other ideas, YCoCg support may be a
qualification task. Maybe not the best choice but certainly usefull
on its own

feel free to add the project to the wiki

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] [PATCH] lavc: Add device context field to AVCodecContext

[Mark Thompson]

For use by codec implementations which can allocate frames internally.
---
This seems to have reached agreement in libav.  If there are no more comments 
here, I will commit this to both tines soon.

Thanks,

- Mark


 doc/APIchanges   |  3 +++
 libavcodec/avcodec.h | 24 +++-
 libavcodec/utils.c   |  1 +
 libavcodec/version.h |  2 +-
 4 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 8bca71ef36..f7cf79e960 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2017-xx-xx - xxx - lavc 57.76.100 - avcodec.h
+  Add AVCodecContext.hw_device_ctx.
+
 2017-01-31 - xxx - lavu 55.46.100 / 55.20.0 - cpu.h
   Add AV_CPU_FLAG_SSSE3SLOW.
 
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 1e681e989b..3fc69ecc53 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3533,7 +3533,8 @@ typedef struct AVCodecContext {
 /**
  * A reference to the AVHWFramesContext describing the input (for encoding)
  * or output (decoding) frames. The reference is set by the caller and
- * afterwards owned (and freed) by libavcodec.
+ * afterwards owned (and freed) by libavcodec - it should never be read by
+ * the caller after being set.
  *
  * - decoding: This field should be set by the caller from the get_format()
  * callback. The previous reference (if any) will always be
@@ -3583,6 +3584,27 @@ typedef struct AVCodecContext {
  */
 int64_t max_pixels;
 
+/**
+ * A reference to the AVHWDeviceContext describing the device which will
+ * be used by a hardware encoder/decoder.  The reference is set by the
+ * caller and afterwards owned (and freed) by libavcodec.
+ *
+ * This should be used if either the codec device does not require
+ * hardware frames or any that are used are to be allocated internally by
+ * libavcodec.  If the user wishes to supply any of the frames used as
+ * encoder input or decoder output then hw_frames_ctx should be used
+ * instead.  When hw_frames_ctx is set in get_format() for a decoder, this
+ * field will be ignored while decoding the associated stream segment, but
+ * may again be used on a following one after another get_format() call.
+ *
+ * For both encoders and decoders this field should be set before
+ * avcodec_open2() is called and must not be written to thereafter.
+ *
+ * Note that some decoders may require this field to be set initially in
+ * order to support hw_frames_ctx at all - in that case, all frames
+ * contexts used must be created on the same device.
+ */
+AVBufferRef *hw_device_ctx;
 } AVCodecContext;
 
 AVRational av_codec_get_pkt_timebase (const AVCodecContext *avctx);
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 4ae752ff2f..43e0365033 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3065,6 +3065,7 @@ av_cold int avcodec_close(AVCodecContext *avctx)
 avctx->nb_coded_side_data = 0;
 
 av_buffer_unref(>hw_frames_ctx);
+av_buffer_unref(>hw_device_ctx);
 
 if (avctx->priv_data && avctx->codec && avctx->codec->priv_class)
 av_opt_free(avctx->priv_data);
diff --git a/libavcodec/version.h b/libavcodec/version.h
index c038e4b093..82a89f9c42 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -28,7 +28,7 @@
 #include "libavutil/version.h"
 
 #define LIBAVCODEC_VERSION_MAJOR  57
-#define LIBAVCODEC_VERSION_MINOR  75
+#define LIBAVCODEC_VERSION_MINOR  76
 #define LIBAVCODEC_VERSION_MICRO 100
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] mjpegenc_huffman: fix uninitialized variable usage

[Michael Niedermayer]

On Wed, Feb 08, 2017 at 11:19:22PM +, Rostislav Pehlivanov wrote:
> Happened when max_length == 0, in which case i wasn't set to 0 during
> the first run. i is supposed to already be at the maximum size when the
> max_length is 0.

when / for what is max_length = 0 used ?
maybe i misuderstand but doesnt max_length mean the longest code would
have 0 bits ?

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

[FFmpeg-devel] [PATCHv2 3/3] avfilter/f_setcmd: fix null pointer dereference on using dash as interval

[Marton Balint]

Fixes Coverity CID 1396259.

Signed-off-by: Marton Balint 
---
 libavfilter/f_sendcmd.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavfilter/f_sendcmd.c b/libavfilter/f_sendcmd.c
index fb30220..522d6ad 100644
--- a/libavfilter/f_sendcmd.c
+++ b/libavfilter/f_sendcmd.c
@@ -268,6 +268,13 @@ static int parse_interval(Interval *interval, int 
interval_count,
 char *start, *end;
 
 start = av_strtok(intervalstr, "-", );
+if (!start) {
+ret = AVERROR(EINVAL);
+av_log(log_ctx, AV_LOG_ERROR,
+   "Invalid interval specification '%s' in interval #%d\n",
+   intervalstr, interval_count);
+goto end;
+}
 if ((ret = av_parse_time(>start_ts, start, 1)) < 0) {
 av_log(log_ctx, AV_LOG_ERROR,
"Invalid start time specification '%s' in interval #%d\n",
-- 
2.10.2

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

[FFmpeg-devel] [PATCH] mjpegenc_huffman: fix uninitialized variable usage

[Rostislav Pehlivanov]

Happened when max_length == 0, in which case i wasn't set to 0 during
the first run. i is supposed to already be at the maximum size when the
max_length is 0.

Fixes CID1400146

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/mjpegenc_huffman.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mjpegenc_huffman.c b/libavcodec/mjpegenc_huffman.c
index a5d7d5365b..075473429c 100644
--- a/libavcodec/mjpegenc_huffman.c
+++ b/libavcodec/mjpegenc_huffman.c
@@ -81,7 +81,7 @@ void ff_mjpegenc_huffman_compute_bits(PTable *prob_table, 
HuffTable *distincts,
 {
 PackageMergerList list_a, list_b, *to = _a, *from = _b, *temp;
 
-int times, i, j, k;
+int times, i = size, j, k;
 
 int nbits[257] = {0};
 
-- 
2.11.0.483.g087da7b7c

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

[FFmpeg-devel] [PATCH 3/3] avfilter/f_setcmd: fix null pointer dereference on using dash as interval

[Marton Balint]

Fixes Coverity CID 1396259.

Signed-off-by: Marton Balint 
---
 libavfilter/f_sendcmd.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavfilter/f_sendcmd.c b/libavfilter/f_sendcmd.c
index fb30220..ce21369 100644
--- a/libavfilter/f_sendcmd.c
+++ b/libavfilter/f_sendcmd.c
@@ -268,6 +268,12 @@ static int parse_interval(Interval *interval, int 
interval_count,
 char *start, *end;
 
 start = av_strtok(intervalstr, "-", );
+if (!start) {
+av_log(log_ctx, AV_LOG_ERROR,
+   "Invalid interval specification '%s' in interval #%d\n",
+   intervalstr, interval_count);
+goto end;
+}
 if ((ret = av_parse_time(>start_ts, start, 1)) < 0) {
 av_log(log_ctx, AV_LOG_ERROR,
"Invalid start time specification '%s' in interval #%d\n",
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 2/3] avdevice/iec61883: free packet on buffer allocation error

[Marton Balint]

Fixes Coverity CID 1396416.

Signed-off-by: Marton Balint 
---
 libavdevice/iec61883.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavdevice/iec61883.c b/libavdevice/iec61883.c
index c45ae9a..721dca3 100644
--- a/libavdevice/iec61883.c
+++ b/libavdevice/iec61883.c
@@ -120,6 +120,7 @@ static int iec61883_callback(unsigned char *data, int 
length,
 
 packet->buf = av_malloc(length);
 if (!packet->buf) {
+av_free(packet);
 ret = -1;
 goto exit;
 }
-- 
2.10.2

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

[FFmpeg-devel] [PATCH 1/3] avformat/fifo: assert on disallowed message type and state combinations

[Marton Balint]

Fixes Coverity CID 1396277.

Signed-off-by: Marton Balint 
---
 libavformat/fifo.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index 8f525e5..2cbe5c5 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -19,6 +19,7 @@
  * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "libavutil/avassert.h"
 #include "libavutil/opt.h"
 #include "libavutil/time.h"
 #include "libavutil/thread.h"
@@ -207,7 +208,7 @@ static int fifo_thread_write_trailer(FifoThreadContext *ctx)
 
 static int fifo_thread_dispatch_message(FifoThreadContext *ctx, FifoMessage 
*msg)
 {
-int ret;
+int ret = AVERROR(EINVAL);
 
 if (!ctx->header_written) {
 ret = fifo_thread_write_header(ctx);
@@ -217,6 +218,7 @@ static int fifo_thread_dispatch_message(FifoThreadContext 
*ctx, FifoMessage *msg
 
 switch(msg->type) {
 case FIFO_WRITE_HEADER:
+av_assert0(ret >= 0);
 return ret;
 case FIFO_WRITE_PACKET:
 return fifo_thread_write_packet(ctx, >pkt);
@@ -224,6 +226,7 @@ static int fifo_thread_dispatch_message(FifoThreadContext 
*ctx, FifoMessage *msg
 return fifo_thread_flush_output(ctx);
 }
 
+av_assert0(0);
 return AVERROR(EINVAL);
 }
 
-- 
2.10.2

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

Re: [FFmpeg-devel] GSoC 2017

[Pedro Arthur]

2017-01-27 1:01 GMT-02:00 Michael Niedermayer :

> we need more (backup) mentors, so yes, i think its needed
>
> also if you want to be mentor for a swscale related project i would
> support that idea


Hi, sorry for the late reply.
I think  implementing a cascade-less swscale could be a good project.
If you think  it is doable for a GSOC project, I'm fine with it.
I just doesn't know a good qualification task.

Yet I can't dedicate much time to it until  March.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix chroma positioning for 4:2:0 pixel format

[Andy Furniss]

Andy Furniss wrote:


Another possible issue which I haven't fully investigated =

This doesn't obey setfield, which makes me think that maybe it's
only working by luck on tff input.


Ugh, ignore that bit as I don't think it should matter as long as
the filter always sees weaved frames.


A quick test with bff does seem wrong, but my bff sample may be to
blame and I don't have any "real" bff with the "right content" to test.


I guess the sample I looked at is flawed, will have to find more.



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

Re: [FFmpeg-devel] [PATCH] cuvid: Always calculate second field PTS from frame rate

[Carl Eugen Hoyos]

2017-02-08 23:31 GMT+01:00 Miroslav Slugeň :
> It is much more robust solution to always calculate second field
> (when deinterlacing) PTS from frame rate

Without looking at your patch, I would have guessed that not
every stream has a useful frame rate.
(It's 1000fps for asf input)

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

Re: [FFmpeg-devel] [PATCH] ffplay: change keyboard volume control to logarithmic

[Marton Balint]

On Sun, 5 Feb 2017, Marton Balint wrote:


The command line parameter remains linear.

Signed-off-by: Marton Balint 
---
ffplay.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/ffplay.c b/ffplay.c
index 1c9db73..cf138dc 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -73,8 +73,8 @@ const int program_birth_year = 2003;
/* Calculate actual buffer size keeping in mind not cause too frequent audio 
callbacks */
#define SDL_AUDIO_MAX_CALLBACKS_PER_SEC 30

-/* Step size for volume control */
-#define SDL_VOLUME_STEP (SDL_MIX_MAXVOLUME / 50)
+/* Step size for volume control in dB */
+#define SDL_VOLUME_STEP (0.75)

/* no AV sync correction is done if below the minimum AV sync threshold */
#define AV_SYNC_THRESHOLD_MIN 0.04
@@ -1450,9 +1450,11 @@ static void toggle_mute(VideoState *is)
is->muted = !is->muted;
}

-static void update_volume(VideoState *is, int sign, int step)
+static void update_volume(VideoState *is, int sign, double step)
{
-is->audio_volume = av_clip(is->audio_volume + sign * step, 0, 
SDL_MIX_MAXVOLUME);
+double volume_level = is->audio_volume ? (20 * log(is->audio_volume / 
(double)SDL_MIX_MAXVOLUME) / log(10)) : -1000.0;
+int new_volume = lrint(SDL_MIX_MAXVOLUME * pow(10.0, (volume_level + sign 
* step) / 20.0));
+is->audio_volume = av_clip(is->audio_volume == new_volume ? 
(is->audio_volume + sign) : new_volume, 0, SDL_MIX_MAXVOLUME);
}

static void step_to_next_frame(VideoState *is)
--


Pushed.

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

Re: [FFmpeg-devel] [rfc] ffmpeg security issue mailing list

[Michael Niedermayer]

Hi all

On Sat, Aug 08, 2015 at 03:51:11AM +0200, Michael Niedermayer wrote:
> On Fri, Aug 07, 2015 at 07:46:55PM -0400, compn wrote:
> > hello,
> > 
> > some of you know that we have a list for security / CVE issues.
> > some of you did not know this.
> > 
> > i think it is a private list due to not wanting people to make exploits
> > before we have a chance to fix them. of course, if no one is subscribed
> > to review/fix issues then they will never get fixed.
> > 
> > so if you are a regular developer who wants access to this list, please
> > speak up.
> > 
> > i do not run nor admin the security email/list (nor do i know who does)
> > so please dont ask me questions about it.
> 
> I guess, i "de facto" admin the security "email/list".
> if someone wants to help with security issues, mail me
> 
> but there are no open security issues and if there was one i very
> likely would fix it ASAP

A small update due to never? before seen interrest in ffmpeg-security
in the recent weeks/months

How to get on the ffmpeg-security "list"

People working on security in FFmpeg, thats maybe fixing many coverity
issues, backporingt fixes to releases, maintaining FFmpeg releases, ...
have an obsession with fixing bugs about undefined behavior or bugs
about crashes and race conditions on trac. Or an obsession with testing
every bugfix and who want and need access to ffmpeg-security should
be on ffmpeg-security
In short people on ffmpeg-security should need to be on ffmpeg-security
If you fall in this kind of category, please mail me

Or someone who reviews commits and obtains CVE#s for everything that
could be exploitable ...

I dont think we should give access to ffmpeg-security to everyone who
wants to be on the list. This is of course something the community
has to decide and not me, iam just err-ing on the safe side and am very
restrictive on who is added.

About the content i must warn you the list is really not very
interresting as in trying to find together with debian someone at
chromium who knows what the CVEs they registered about FFmpeg actually
are about ... and then it embarassingly is a patch on ffmpeg-devel
that is stuck in review and not applied and now i can redo the releases ...
... Where are the people caring about security ? why did they not
pick these 2 public patches up, change what they felt needs changing
and pushed them ?
and there are the fuzz samples that need more than 20sec, these are
the main type of reported issue recently after ive succeeded to stop
the oom kind.

Also there are no open security(*) issues i know of, and if there would
be i likely would fix them ASAP. Not saying that help is unwelcome
or that its impossible for me to make a mistake or miss something ...

(*) I assume here that fuzz samples taking more than 20sec or integer
overflows in DSP code arent security issues. Iam working on fixing
these too but for this category there are open issues.

PS: If you want access to the oss-fuzz reports, they all seem
automatically public 7 days after being fixed

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] Efficiently support several output pixel formats in Cinepak decoder

[u-9iep]

On Wed, Feb 08, 2017 at 09:02:44AM -0500, Ronald S. Bultje wrote:
> I encourage you to fork the code and publish the faster decoder so others
> with use cases like yours can use it. It's free software, you're allowed
> and encouraged to do that.

I considered this possibility. My scope of contribution is though "a
useful modification". Leading/maintaining a multimedia-tool-project is
a very different thing and not something I am interested in.

> I just don't think it belongs in upstream FFmpeg.

This depends of course on the idea of what FFmpeg is.
I am not qualified to make such a definition, given my limited
engagement here.

My expectation was "the Swiss Army Knife of multimedia" and "the most
efficient tool in its class". If either of those is not or no longer
relevant, not my thing to decide, then the patch is indeed wrongly
addressed.

> (Going back to the native format discussion, I looked at decode_codebook
> and it appears the native format is actually 8-bit/component YCgCo; it's

Not exactly, it is similar but Cinepak-specific, it is also optimized for
conversion to rgb.

> interesting that we chose rgb24 as output format, I'm guessing it's because

It is the natural target format of Cinepak's design.

> YCgCo support in FFmpeg is non-existent.)

Kind of.
(https://ffmpeg.org/pipermail/ffmpeg-devel/2013-February/138811.html)

This was fortunate, allowing to notice the gain associated with filling
the codebook with the converted data, compared to doing the conversion
on the resulting frame.

From the commit message Mon Feb 18 18:00:33 2013 +0100
"
old decoder + conversion to rgb: fps = 2618
old decoder, without converting to rgb:  fps = 4012

new decoder, producing rgb:  fps = 4502
"

Regards,
Rune

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

[FFmpeg-devel] [PATCH 2/2] avcodec/huffyuvencdsp: use an actual unsigned long constant

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/huffyuvencdsp.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavcodec/huffyuvencdsp.c b/libavcodec/huffyuvencdsp.c
index 7edcce872b..427d118be4 100644
--- a/libavcodec/huffyuvencdsp.c
+++ b/libavcodec/huffyuvencdsp.c
@@ -21,6 +21,9 @@
 #include "huffyuvencdsp.h"
 #include "mathops.h"
 
+// 0x00010001 or 0x0001000100010001 or whatever, depending on the cpu's native 
arithmetic size
+#define pw_1 (ULONG_MAX / UINT16_MAX)
+
 static void diff_int16_c(uint16_t *dst, const uint16_t *src1, const uint16_t 
*src2, unsigned mask, int w){
 long i;
 #if !HAVE_FAST_UNALIGNED
@@ -34,8 +37,8 @@ static void diff_int16_c(uint16_t *dst, const uint16_t *src1, 
const uint16_t *sr
 }else
 #endif
 {
-unsigned long pw_lsb = (mask >> 1) * 0x0001000100010001ULL;
-unsigned long pw_msb = pw_lsb +  0x0001000100010001ULL;
+unsigned long pw_lsb = (mask >> 1) * pw_1;
+unsigned long pw_msb = pw_lsb +  pw_1;
 
 for (i = 0; i <= w - (int)sizeof(long)/2; i += sizeof(long)/2) {
 long a = *(long*)(src1+i);
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 1/2] avcodec/huffyuvdsp: use an actual unsigned long constant

[James Almer]

Signed-off-by: James Almer 
---
Decent compilers are smart enough to truncate those ULL constants on targets
where long is 32 bits (and do things like shift+and/add instead of mul).
This is for those that are not.

 libavcodec/huffyuvdsp.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavcodec/huffyuvdsp.c b/libavcodec/huffyuvdsp.c
index 759ffda0b8..e770923bb2 100644
--- a/libavcodec/huffyuvdsp.c
+++ b/libavcodec/huffyuvdsp.c
@@ -23,10 +23,13 @@
 #include "mathops.h"
 #include "huffyuvdsp.h"
 
+// 0x00010001 or 0x0001000100010001 or whatever, depending on the cpu's native 
arithmetic size
+#define pw_1 (ULONG_MAX / UINT16_MAX)
+
 static void add_int16_c(uint16_t *dst, const uint16_t *src, unsigned mask, int 
w){
 long i;
-unsigned long pw_lsb = (mask >> 1) * 0x0001000100010001ULL;
-unsigned long pw_msb = pw_lsb +  0x0001000100010001ULL;
+unsigned long pw_lsb = (mask >> 1) * pw_1;
+unsigned long pw_msb = pw_lsb +  pw_1;
 for (i = 0; i <= w - (int)sizeof(long)/2; i += sizeof(long)/2) {
 long a = *(long*)(src+i);
 long b = *(long*)(dst+i);
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] mov, matroskadec : Allow matroskadec & mov to share spherical parsing logic.

[Vittorio Giovara]

On Wed, Feb 8, 2017 at 9:35 AM, James Almer  wrote:
> On 2/8/2017 10:47 AM, Vittorio Giovara wrote:
>> On Mon, Feb 6, 2017 at 4:59 PM, Aaron Colwell  wrote:
>>> - Extracts common spherical metadata parsing logic.
>>> - Adds checks to enforce that only non-tiled equirect & non-padded cubemaps
>>>   are accepted.
>>
>> Hi Aaron,
>> this patch basically ignores all my comments, so I'm not very happy with it.
>>
>> I believe the biggest complaint of mine is that this implementation
>> only works with the ffmpeg command line and leaves users in the dark,
>> in addition to everything I said in the other thread. There are other
>> cosmetics oddities (such as adding a *mov* dependency to the
>> *matroska* code
>
> The matroska elements contain the spherical data in the same structure
> as they are in mov files. Much like we're including oggdec.h or flac.h
> to parse vorbis comment and flac headers, including a new header to
> parse an specific kind of mov atom available in other formats should be
> ok.
>
> After all, the alternative would be duplicate the parsing code in two
> demuxers.

..which is what we do for most of the other places (replaygain,
stereo3d, mastering display and so on and on)..
Besides, that was just a cosmetic comment, if the code is to be shared
among formats (which I believe is totally unnecessary for _just two_
demuxers) dropping the 'mov' prefix from the file would do, in my
opinion.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mov, matroskadec : Allow matroskadec & mov to share spherical parsing logic.

[James Almer]

On 2/8/2017 10:47 AM, Vittorio Giovara wrote:
> On Mon, Feb 6, 2017 at 4:59 PM, Aaron Colwell  wrote:
>> - Extracts common spherical metadata parsing logic.
>> - Adds checks to enforce that only non-tiled equirect & non-padded cubemaps
>>   are accepted.
> 
> Hi Aaron,
> this patch basically ignores all my comments, so I'm not very happy with it.
> 
> I believe the biggest complaint of mine is that this implementation
> only works with the ffmpeg command line and leaves users in the dark,
> in addition to everything I said in the other thread. There are other
> cosmetics oddities (such as adding a *mov* dependency to the
> *matroska* code

The matroska elements contain the spherical data in the same structure
as they are in mov files. Much like we're including oggdec.h or flac.h
to parse vorbis comment and flac headers, including a new header to
parse an specific kind of mov atom available in other formats should be
ok.

After all, the alternative would be duplicate the parsing code in two
demuxers.

, or mixing code move with new functionality) which are
> practices that should be avoided.
> 
> If you don't mind, I'll try to work on something that should finally
> settle this and provide a patch.
> Cheers
> 

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

Re: [FFmpeg-devel] [PATCH] imgutils: Document av_image_get_buffer_size()

[Vittorio Giovara]

On Tue, Feb 7, 2017 at 5:30 PM, Michael Niedermayer
 wrote:
> and the forgotten-CC mail
>
> On Tue, Feb 07, 2017 at 11:28:21PM +0100, Michael Niedermayer wrote:
>> On Tue, Feb 07, 2017 at 10:01:52AM -0500, Vittorio Giovara wrote:
>> > ---
>> >  libavutil/imgutils.h | 7 ++-
>> >  1 file changed, 6 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/libavutil/imgutils.h b/libavutil/imgutils.h
>> > index 67063a2..ac1bcb8 100644
>> > --- a/libavutil/imgutils.h
>> > +++ b/libavutil/imgutils.h
>> > @@ -169,7 +169,12 @@ int av_image_fill_arrays(uint8_t *dst_data[4], int 
>> > dst_linesize[4],
>> >   * Return the size in bytes of the amount of data required to store an
>> >   * image with the given parameters.
>> >   *
>> > - * @param[in] align the assumed linesize alignment
>> > + * @param pix_fmt  the pixel format of the image
>> > + * @param widththe width of the image in pixels
>> > + * @param height   the height of the image in pixels
>> > + * @param alignthe assumed linesize alignment
>>
>> > + * @return the size in bytes required for src, a negative error code
>> > + * in case of failure
>>
>> There is no "src" in this function or its documentation

Oh good catch thanks.
I'll replace the @return line to

 * @return the buffer size in bytes, a negative error code in case of failure
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix chroma positioning for 4:2:0 pixel format

[Andy Furniss]

Andy Furniss wrote:

Michael Niedermayer wrote:

On Mon, Feb 06, 2017 at 05:14:14PM +0200, Maksym Veremeyenko wrote:

Hi,

Attached patch fixes chroma positioning during scaling interlaced 4:2:0.

On a first iteration default context value been overwritten by new
value and not been update on next iterations for fields. This mean
that vertical chroma position remain 128 for field#0 and field#1
instead of *64* and *192*.

Attached patch use local variable for storing this intermediate
value of chroma vertical position not modifying default context
value.

--
Maksym Veremeyenko




  vf_scale.c |9 +
  1 file changed, 5 insertions(+), 4 deletions(-)
6a3a3966939dd87c45a8e124b0364da30b02728b
0001-Fix-chroma-positioning-for-4-2-0-pixel-format.patch
 From 912ecf538b6b2f7a8df4afdfed2d34052162335c Mon Sep 17 00:00:00 2001
From: Maksym Veremeyenko 
Date: Mon, 6 Feb 2017 17:03:17 +0200
Subject: [PATCH] Fix chroma positioning for 4:2:0 pixel format


applied

thx


Nice, testing wise it raises a question to how swscale should work by
default with interl=1 and 420 to rgb (maybe other cases as well).

In summary this patch will appear to fail with a test like.

ffmpeg -i 420-interlaced.ts -ss 11.2 -vf scale=interl=1 -vframes 1 out.png

Will look just as broken as before the patch. The addition of -

-sws_flags +accurate_rnd

fixes it, adding +full_chroma_int looks better still.


Another possible issue which I haven't fully investigated =

This doesn't obey setfield, which makes me think that maybe it's
only working by luck on tff input.

A quick test with bff does seem wrong, but my bff sample may be to
blame and I don't have any "real" bff with the "right content" to test.

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

Re: [FFmpeg-devel] h264 bitstream corruption in videotoolbox encoder with a53cc=1

[Richard Kern]

On February 6, 2017 at 8:39:30 PM, Aman Gupta (ffm...@tmm1.net) wrote:

Last October, kernrj and I commited a series of patches to add a53cc
support to the videotoolbox encoder.

In using that feature over the past few months, I've discovered that the
generated streams can sometimes contain random/intermittent errors. This
only appears to occur on some Macs and not others.

These corrupted files cause errors when used with any of Apple's decoders,
including Safari, Quicktime, and mediastreamvalidator. The file can be
decoded with ffmpeg, although it prints out the following error when
encountering the corruption:

[NULL @ 0x7fbcce800600] sps_id 32 out of range
[h264 @ 0x7fbcd000] sps_id 32 out of range

Here are two sequential sample segments generated by the videotoolbox
encoder (when used with -f hls). They were generated one after the other
from the same source; the first is fine, but the second contains the
corruption.

https://s3.amazonaws.com/tmm1/stream57.ts
https://s3.amazonaws.com/tmm1/stream58.ts

I'd like to fix this bug, but have been stuck trying to narrow it down.
Hoping someone can point me in the right direction.

I’ll take a look this weekend.




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

Re: [FFmpeg-devel] [PATCH] Implement optimal huffman encoding for (M)JPEG.

[Rostislav Pehlivanov]

On 8 February 2017 at 07:09, Jerry Jiang  wrote:

> Hey is there an update on the status of the patch? Any other requested
> changes?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Hi, sorry I missed your last patch.
I've already okay'd it last month so pushed.

Thanks

Since it does so well it would be a good idea to enable it by default like
I said before.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Efficiently support several output pixel formats in Cinepak decoder

[wm4]

On Wed, 8 Feb 2017 09:02:44 -0500
"Ronald S. Bultje"  wrote:


> (Going back to the native format discussion, I looked at decode_codebook
> and it appears the native format is actually 8-bit/component YCgCo; it's
> interesting that we chose rgb24 as output format, I'm guessing it's because
> YCgCo support in FFmpeg is non-existent.)

Should work fine with the correct color space set. swscale doesn't
support it, I think, so you need to use libavcodec-using software that
supports ycgco.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Efficiently support several output pixel formats in Cinepak decoder

[Ronald S. Bultje]

Hi,

On Wed, Feb 8, 2017 at 2:45 AM,  wrote:

> This unfortunately can not come near an identical performance because
> it would have to work on several times more data (frame vs codebook).

[..]

> I value layered design as much as you do, but it introduces limitations.

[..]

> In certain aspects, by the original design, it is still superior to
> virtualy anything else at hand. With the proposed optimization we get the
> best out of its virtues. It would be a waste to ignore the possibility.


I encourage you to fork the code and publish the faster decoder so others
with use cases like yours can use it. It's free software, you're allowed
and encouraged to do that.

I just don't think it belongs in upstream FFmpeg.

(Going back to the native format discussion, I looked at decode_codebook
and it appears the native format is actually 8-bit/component YCgCo; it's
interesting that we chose rgb24 as output format, I'm guessing it's because
YCgCo support in FFmpeg is non-existent.)

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

Re: [FFmpeg-devel] [PATCH] mov, matroskadec : Allow matroskadec & mov to share spherical parsing logic.

[Vittorio Giovara]

On Mon, Feb 6, 2017 at 4:59 PM, Aaron Colwell  wrote:
> - Extracts common spherical metadata parsing logic.
> - Adds checks to enforce that only non-tiled equirect & non-padded cubemaps
>   are accepted.

Hi Aaron,
this patch basically ignores all my comments, so I'm not very happy with it.

I believe the biggest complaint of mine is that this implementation
only works with the ffmpeg command line and leaves users in the dark,
in addition to everything I said in the other thread. There are other
cosmetics oddities (such as adding a *mov* dependency to the
*matroska* code, or mixing code move with new functionality) which are
practices that should be avoided.

If you don't mind, I'll try to work on something that should finally
settle this and provide a patch.
Cheers
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v5] Added Turing codec interface for ffmpeg

[Mark Thompson]

On 08/02/17 08:41, Saverio Blasi wrote:
> - This patch contains the changes to interface the Turing codec 
> (http://turingcodec.org/) with ffmpeg. The patch was modified to address the 
> comments in the review as follows:
>   - Added a pkg-config file to list all dependencies required by libturing. 
> This should address the issue pointed out by Hendrik Leppkes on Fri 18/11/2016
>   - As per suggestions of wm4, two functions (add_option and 
> finalise_options) have been created. The former appends new options while the 
> latter sets up the argv array of pointers to char* accordingly. add_option 
> re-allocates the buffer for options using av_realloc
>   - Additionally, both these functions handle the errors in case the memory 
> wasn't allocated correctly
>   - malloc|free|realloc have been substituted with their corresponding 
> av_{malloc|free|realloc} version
>   - Check on bit-depth has been removed since the ffmpeg already casts the 
> right pix_fmt and bit depth
>   - pix_fmts is now set in ff_libturing_encoder as in h264dec.c.
>   - Added av_freep to release the allocated memory
>   - Added brackets to single-line operators
> ---
>  LICENSE.md |   1 +
>  configure  |   5 +
>  libavcodec/Makefile|   1 +
>  libavcodec/allcodecs.c |   1 +
>  libavcodec/libturing.c | 320 
> +
>  5 files changed, 328 insertions(+)
>  create mode 100644 libavcodec/libturing.c
> 
> diff --git a/LICENSE.md b/LICENSE.md
> index 640633c..86e5371 100644
> --- a/LICENSE.md
> +++ b/LICENSE.md
> @@ -85,6 +85,7 @@ The following libraries are under GPL:
>  - frei0r
>  - libcdio
>  - librubberband
> +- libturing
>  - libvidstab
>  - libx264
>  - libx265
> diff --git a/configure b/configure
> index 7154142..a27cb8b 100755
> --- a/configure
> +++ b/configure
> @@ -255,6 +255,7 @@ External library support:
>--enable-libssh  enable SFTP protocol via libssh [no]
>--enable-libtesseractenable Tesseract, needed for ocr filter [no]
>--enable-libtheora   enable Theora encoding via libtheora [no]
> +  --enable-libturing   enable H.265/HEVC encoding via libturing [no]
>--enable-libtwolame  enable MP2 encoding via libtwolame [no]
>--enable-libv4l2 enable libv4l2/v4l-utils [no]
>--enable-libvidstab  enable video stabilization using vid.stab [no]
> @@ -1562,6 +1563,7 @@ EXTERNAL_LIBRARY_LIST="
>  libssh
>  libtesseract
>  libtheora
> +libturing
>  libtwolame
>  libv4l2
>  libvidstab
> @@ -2858,6 +2860,7 @@ libspeex_decoder_deps="libspeex"
>  libspeex_encoder_deps="libspeex"
>  libspeex_encoder_select="audio_frame_queue"
>  libtheora_encoder_deps="libtheora"
> +libturing_encoder_deps="libturing"
>  libtwolame_encoder_deps="libtwolame"
>  libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
>  libvorbis_decoder_deps="libvorbis"
> @@ -5131,6 +5134,7 @@ die_license_disabled gpl frei0r
>  die_license_disabled gpl libcdio
>  die_license_disabled gpl librubberband
>  die_license_disabled gpl libsmbclient
> +die_license_disabled gpl libturing
>  die_license_disabled gpl libvidstab
>  die_license_disabled gpl libx264
>  die_license_disabled gpl libx265
> @@ -5789,6 +5793,7 @@ enabled libssh&& require_pkg_config libssh 
> libssh/sftp.h sftp_init
>  enabled libspeex  && require_pkg_config speex speex/speex.h 
> speex_decoder_init -lspeex
>  enabled libtesseract  && require_pkg_config tesseract tesseract/capi.h 
> TessBaseAPICreate
>  enabled libtheora && require libtheora theora/theoraenc.h 
> th_info_init -ltheoraenc -ltheoradec -logg
> +enabled libturing && require_pkg_config libturing turing.h 
> turing_version
>  enabled libtwolame&& require libtwolame twolame.h twolame_init 
> -ltwolame &&
>   { check_lib twolame.h 
> twolame_encode_buffer_float32_interleaved -ltwolame ||
> die "ERROR: libtwolame must be installed and 
> version must be >= 0.3.10"; }
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 43a6add..51a0662 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -884,6 +884,7 @@ OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
>  OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
>  OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
>  OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
> +OBJS-$(CONFIG_LIBTURING_ENCODER)  += libturing.o

'U' < 'W' (the ones above in configure get the order right).

>  OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
>  OBJS-$(CONFIG_LIBVORBIS_DECODER)  += libvorbisdec.o
>  OBJS-$(CONFIG_LIBVORBIS_ENCODER)  += libvorbisenc.o \
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index f92b2b7..18fc026 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -616,6 +616,7 @@ void avcodec_register_all(void)
>  

Re: [FFmpeg-devel] [PATCH] Fix chroma positioning for 4:2:0 pixel format

[Andy Furniss]

Michael Niedermayer wrote:

On Mon, Feb 06, 2017 at 05:14:14PM +0200, Maksym Veremeyenko wrote:

Hi,

Attached patch fixes chroma positioning during scaling interlaced 4:2:0.

On a first iteration default context value been overwritten by new
value and not been update on next iterations for fields. This mean
that vertical chroma position remain 128 for field#0 and field#1
instead of *64* and *192*.

Attached patch use local variable for storing this intermediate
value of chroma vertical position not modifying default context
value.

--
Maksym Veremeyenko




  vf_scale.c |9 +
  1 file changed, 5 insertions(+), 4 deletions(-)
6a3a3966939dd87c45a8e124b0364da30b02728b  
0001-Fix-chroma-positioning-for-4-2-0-pixel-format.patch
 From 912ecf538b6b2f7a8df4afdfed2d34052162335c Mon Sep 17 00:00:00 2001
From: Maksym Veremeyenko 
Date: Mon, 6 Feb 2017 17:03:17 +0200
Subject: [PATCH] Fix chroma positioning for 4:2:0 pixel format


applied

thx


Nice, testing wise it raises a question to how swscale should work by
default with interl=1 and 420 to rgb (maybe other cases as well).

In summary this patch will appear to fail with a test like.

ffmpeg -i 420-interlaced.ts -ss 11.2 -vf scale=interl=1 -vframes 1 out.png

Will look just as broken as before the patch. The addition of -

-sws_flags +accurate_rnd

fixes it, adding +full_chroma_int looks better still.


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

Re: [FFmpeg-devel] [PATCH] omx: Add support for specifying H.264 profile [v2']

[Moritz Barsnick]

On Wed, Feb 08, 2017 at 11:12:12 +0100, Moritz Barsnick wrote:
> Your switch/case no longer has a default. Is that intended? (Code
> linters will complain.) AFAICT, avctx->profile will be unset if an
> unknown s->profile is given. Is that okay? (It might be - I'm just
> wondering. I *do* understand that not using the "profile" option will
> default s->profile to FF_PROFILE_H264_HIGH.)

D'uh, sorry about that comment. I just figured out: Your option code
doesn't allow anything else (for the time being) than the three named
enums.

Remark withdrawn, though adding a default *might* be safer.

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

Re: [FFmpeg-devel] [PATCH] omx: Add support for specifying H.264 profile [v2']

[Moritz Barsnick]

On Tue, Feb 07, 2017 at 19:05:55 +0900, Takayuki 'January June' Suwa wrote:
> +switch (s->profile) {
> +case FF_PROFILE_H264_BASELINE:
> +avctx->profile = s->profile;
> +avc.eProfile = OMX_VIDEO_AVCProfileBaseline;
> +break;
> +case FF_PROFILE_H264_MAIN:
> +avctx->profile = s->profile;
> +avc.eProfile = OMX_VIDEO_AVCProfileMain;
> +break;
> +case FF_PROFILE_H264_HIGH:
> +avctx->profile = s->profile;
> +avc.eProfile = OMX_VIDEO_AVCProfileHigh;
> +break;
> +}

Your switch/case no longer has a default. Is that intended? (Code
linters will complain.) AFAICT, avctx->profile will be unset if an
unknown s->profile is given. Is that okay? (It might be - I'm just
wondering. I *do* understand that not using the "profile" option will
default s->profile to FF_PROFILE_H264_HIGH.)

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

Re: [FFmpeg-devel] [PATCH v5] Added Turing codec interface for ffmpeg

[wm4]

On Wed,  8 Feb 2017 08:41:56 +
Saverio Blasi  wrote:

> - This patch contains the changes to interface the Turing codec 
> (http://turingcodec.org/) with ffmpeg. The patch was modified to address the 
> comments in the review as follows:
>   - Added a pkg-config file to list all dependencies required by libturing. 
> This should address the issue pointed out by Hendrik Leppkes on Fri 18/11/2016
>   - As per suggestions of wm4, two functions (add_option and 
> finalise_options) have been created. The former appends new options while the 
> latter sets up the argv array of pointers to char* accordingly. add_option 
> re-allocates the buffer for options using av_realloc
>   - Additionally, both these functions handle the errors in case the memory 
> wasn't allocated correctly
>   - malloc|free|realloc have been substituted with their corresponding 
> av_{malloc|free|realloc} version
>   - Check on bit-depth has been removed since the ffmpeg already casts the 
> right pix_fmt and bit depth
>   - pix_fmts is now set in ff_libturing_encoder as in h264dec.c.
>   - Added av_freep to release the allocated memory
>   - Added brackets to single-line operators
> ---
>  LICENSE.md |   1 +
>  configure  |   5 +
>  libavcodec/Makefile|   1 +
>  libavcodec/allcodecs.c |   1 +
>  libavcodec/libturing.c | 320 
> +
>  5 files changed, 328 insertions(+)
>  create mode 100644 libavcodec/libturing.c

The patch seems mostly ok, some minor comments below.

> +static av_cold int add_option(const char* current_option, optionContext* 
> option_ctx)
> +{
> +int option_length = strlen(current_option);
> +char *temp_ptr;
> +if (option_ctx->buffer_filled + option_length + 1 > 
> option_ctx->options_buffer_size) {
> +option_ctx->options_buffer_size += option_length + 1;

You probably shouldn't update options_buffer_size before the
reallocation actually succeeded. (Probably doesn't matter with the
current code, but for robustness...)

> +temp_ptr = av_realloc(option_ctx->options, 
> option_ctx->options_buffer_size);
> +if (temp_ptr == NULL) {
> +return AVERROR(ENOMEM);
> +}
> +option_ctx->options = temp_ptr;
> +option_ctx->s = option_ctx->options + option_ctx->buffer_filled;
> +}
> +strcpy(option_ctx->s, current_option);
> +option_ctx->s += 1 + option_length;
> +option_ctx->options_added++;
> +option_ctx->buffer_filled += option_length + 1;
> +return 0;
> +}

Still not sure why there's at least 1 redundant field (s which is
redundant with buffer_filled).

Using memcpy might be slightly nicer than strcpy, because everyone
hates strcpy. But it looks correct anyway.

> +
> +static av_cold int finalise_options(optionContext* option_ctx)
> +{
> +if (option_ctx->options_added) {
> +char *p;
> +option_ctx->argv = av_malloc(option_ctx->options_added * 
> sizeof(char*));
> +if (option_ctx->argv == NULL) {
> +return AVERROR(ENOMEM);
> +}
> +p = option_ctx->options;
> +for(int option_idx=0; option_idxoptions_added; 
> option_idx++) {
> +option_ctx->argv[option_idx] = p;
> +p += strlen(p) + 1;
> +}
> +}
> +return 0;
> +}

Not sure why this isn't just done by add_option.

> +
> +static av_cold int libturing_encode_init(AVCodecContext *avctx)
> +{
> +libturingEncodeContext *ctx = avctx->priv_data;
> +const int bit_depth = av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].depth;
> +
> +optionContext encoder_options;
> +turing_encoder_settings settings;
> +char option_string[MAX_OPTION_LENGTH];
> +double frame_rate;
> +
> +frame_rate = (double)avctx->time_base.den / (avctx->time_base.num * 
> avctx->ticks_per_frame);
> +
> +encoder_options.buffer_filled = 0;
> +encoder_options.options_added = 0;
> +encoder_options.options_buffer_size =  strlen("turing") + 1;
> +encoder_options.options = av_malloc(encoder_options.options_buffer_size);
> +if(encoder_options.options == NULL) {
> +av_log(avctx, AV_LOG_ERROR, "Cannot allocate the memory for command 
> line options\n");
> +return AVERROR(ENOMEM);
> +}

Couldn't this extra initial allocation be dropped? It seems rather
redundant.

> +encoder_options.s = encoder_options.options;
> +encoder_options.argv = NULL;
> +
> +// Add baseline command line options
> +if (add_option("turing", _options)) {
> +goto optionfail;
> +}
> +
> +if (add_option("--frames=0", _options)) {
> +goto optionfail;
> +}
> +
> +snprintf(option_string, MAX_OPTION_LENGTH, "--input-res=%dx%d", 
> avctx->width, avctx->height);
> +if (add_option(option_string, _options)) {
> +goto optionfail;
> +}

Maybe add_option() could be a vararg function (like snprintf) to
minimize this code further. Also, {/} are generally not 

Re: [FFmpeg-devel] Can BSF delay packets?

[wm4]

On Wed, 8 Feb 2017 11:30:59 +0300
Aleksey M  wrote:

> Hi Ronald.
> 
> Probably I found the reason why my filter (and vp9_superframe_bsf too) is
> not working.
> 
> This code in "FFMPEG.C" just overwrites "ret" value, not handling EAGAIN at
> all (FFMPEG ver 3.1):

So try ffmpeg git master? Development happens only against git master
anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Efficiently support several output pixel formats in Cinepak decoder

[u-9iep]

On Tue, Feb 07, 2017 at 09:07:02PM -0700, Daniel Verkamp wrote:
> There is already a rgb24-to-rgb565 path, but it does not get used by
> default because of the needsDither check in ff_get_unscaled_swscale().
> If the scaling algorithm is set to fast_bilinear, needsDither is
> ignored and the RGB24 to RGB16 converter is used. (In either case, no
> actual scaling is performed, so the scaling algorithm is irrelevant
> aside from selecting dithering.) Looking at the mplayer docs, this is
> probably equivalent to '-sws 0'.
> 
> e.g.
>   ffmpeg -i  -f null -c rawvideo -pix_fmt rgb565le -sws_flags
> fast_bilinear /dev/null
> 
> Using matrixbench_mpeg2.mpg (720x567) encoded with ffmpeg into Cinepak
> using default settings, decoding on an i5 3570K, 3.4 GHz:
> 
> bicubic (default):  ~24x realtime
> fast_bilinear:  ~65x realtime
> patch w/rgb565 override:~154x realtime
> 
> As far as I can tell, this patch doesn't do any dithering for RGB565,
> so the fast_bilinear (non-dithering) swscale converter is a fair
> comparison.

Thanks Daniel.

Yes, the patch does accurate rounding, no dithering.

Rune

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

Re: [FFmpeg-devel] [PATCH 1/3] libavcodec/cinepakenc.c: comments cleanup (contents)

[u-9iep]

On Tue, Feb 07, 2017 at 10:50:42PM +0100, Michael Niedermayer wrote:
> There is no "Rl" in there
> 
> git removes that when applying with git am
> git am
> ...
> From: Rl 
> ...
> git show
> ...
> Author: addr-see-the-webs...@aetey.se 

Oh! :-/

> I dont know why git does that but it does, i retested this as it seemed
> rather unexpected and odd

Yes, this is odd.

> I can manually override this and force git to use Rl as name so i
> will do that, but this may be error prone if git fails to keep Rl
> even after there are commits in the tree with that name.

How much does it check the validity of the part inside <> ?
What about  ?
Currently this should not be possible to confuse with a valid mail
address.

Regards,
Rune

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

[FFmpeg-devel] [PATCH v5] Added Turing codec interface for ffmpeg

[Saverio Blasi]

- This patch contains the changes to interface the Turing codec 
(http://turingcodec.org/) with ffmpeg. The patch was modified to address the 
comments in the review as follows:
  - Added a pkg-config file to list all dependencies required by libturing. 
This should address the issue pointed out by Hendrik Leppkes on Fri 18/11/2016
  - As per suggestions of wm4, two functions (add_option and finalise_options) 
have been created. The former appends new options while the latter sets up the 
argv array of pointers to char* accordingly. add_option re-allocates the buffer 
for options using av_realloc
  - Additionally, both these functions handle the errors in case the memory 
wasn't allocated correctly
  - malloc|free|realloc have been substituted with their corresponding 
av_{malloc|free|realloc} version
  - Check on bit-depth has been removed since the ffmpeg already casts the 
right pix_fmt and bit depth
  - pix_fmts is now set in ff_libturing_encoder as in h264dec.c.
  - Added av_freep to release the allocated memory
  - Added brackets to single-line operators
---
 LICENSE.md |   1 +
 configure  |   5 +
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/libturing.c | 320 +
 5 files changed, 328 insertions(+)
 create mode 100644 libavcodec/libturing.c

diff --git a/LICENSE.md b/LICENSE.md
index 640633c..86e5371 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -85,6 +85,7 @@ The following libraries are under GPL:
 - frei0r
 - libcdio
 - librubberband
+- libturing
 - libvidstab
 - libx264
 - libx265
diff --git a/configure b/configure
index 7154142..a27cb8b 100755
--- a/configure
+++ b/configure
@@ -255,6 +255,7 @@ External library support:
   --enable-libssh  enable SFTP protocol via libssh [no]
   --enable-libtesseractenable Tesseract, needed for ocr filter [no]
   --enable-libtheora   enable Theora encoding via libtheora [no]
+  --enable-libturing   enable H.265/HEVC encoding via libturing [no]
   --enable-libtwolame  enable MP2 encoding via libtwolame [no]
   --enable-libv4l2 enable libv4l2/v4l-utils [no]
   --enable-libvidstab  enable video stabilization using vid.stab [no]
@@ -1562,6 +1563,7 @@ EXTERNAL_LIBRARY_LIST="
 libssh
 libtesseract
 libtheora
+libturing
 libtwolame
 libv4l2
 libvidstab
@@ -2858,6 +2860,7 @@ libspeex_decoder_deps="libspeex"
 libspeex_encoder_deps="libspeex"
 libspeex_encoder_select="audio_frame_queue"
 libtheora_encoder_deps="libtheora"
+libturing_encoder_deps="libturing"
 libtwolame_encoder_deps="libtwolame"
 libvo_amrwbenc_encoder_deps="libvo_amrwbenc"
 libvorbis_decoder_deps="libvorbis"
@@ -5131,6 +5134,7 @@ die_license_disabled gpl frei0r
 die_license_disabled gpl libcdio
 die_license_disabled gpl librubberband
 die_license_disabled gpl libsmbclient
+die_license_disabled gpl libturing
 die_license_disabled gpl libvidstab
 die_license_disabled gpl libx264
 die_license_disabled gpl libx265
@@ -5789,6 +5793,7 @@ enabled libssh&& require_pkg_config libssh 
libssh/sftp.h sftp_init
 enabled libspeex  && require_pkg_config speex speex/speex.h 
speex_decoder_init -lspeex
 enabled libtesseract  && require_pkg_config tesseract tesseract/capi.h 
TessBaseAPICreate
 enabled libtheora && require libtheora theora/theoraenc.h th_info_init 
-ltheoraenc -ltheoradec -logg
+enabled libturing && require_pkg_config libturing turing.h 
turing_version
 enabled libtwolame&& require libtwolame twolame.h twolame_init 
-ltwolame &&
  { check_lib twolame.h 
twolame_encode_buffer_float32_interleaved -ltwolame ||
die "ERROR: libtwolame must be installed and 
version must be >= 0.3.10"; }
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 43a6add..51a0662 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -884,6 +884,7 @@ OBJS-$(CONFIG_LIBSPEEX_DECODER)   += libspeexdec.o
 OBJS-$(CONFIG_LIBSPEEX_ENCODER)   += libspeexenc.o
 OBJS-$(CONFIG_LIBTHEORA_ENCODER)  += libtheoraenc.o
 OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o
+OBJS-$(CONFIG_LIBTURING_ENCODER)  += libturing.o
 OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o
 OBJS-$(CONFIG_LIBVORBIS_DECODER)  += libvorbisdec.o
 OBJS-$(CONFIG_LIBVORBIS_ENCODER)  += libvorbisenc.o \
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index f92b2b7..18fc026 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -616,6 +616,7 @@ void avcodec_register_all(void)
 REGISTER_ENCDEC (LIBSPEEX,  libspeex);
 REGISTER_ENCODER(LIBTHEORA, libtheora);
 REGISTER_ENCODER(LIBTWOLAME,libtwolame);
+REGISTER_ENCODER(LIBTURING, libturing);
 REGISTER_ENCODER(LIBVO_AMRWBENC,libvo_amrwbenc);
 REGISTER_ENCDEC (LIBVORBIS, libvorbis);
 

Re: [FFmpeg-devel] Can BSF delay packets?

[Aleksey M]

Hi Ronald.

Probably I found the reason why my filter (and vp9_superframe_bsf too) is
not working.

This code in "FFMPEG.C" just overwrites "ret" value, not handling EAGAIN at
all (FFMPEG ver 3.1):

ret = av_bsf_receive_packet(ost->bsf_ctx[idx - 1], pkt);
>
> /* HACK! - aac_adtstoasc updates extradata after filtering the
> first frame when
>  * the api states this shouldn't happen after init().
> Propagate it here to the
>  * muxer and to the next filters in the chain to workaround
> this.
>  * TODO/FIXME - Make aac_adtstoasc use new packet side data
> instead of changing
>  * par_out->extradata and adapt muxers accordingly to get rid
> of this. */
>
> if (!(ost->bsf_extradata_updated[idx - 1] & 1)) {
> ret = avcodec_parameters_copy(ost->st->codecpar,
> ost->bsf_ctx[idx - 1]->par_out);
> if (ret < 0)
> goto finish;
> ost->bsf_extradata_updated[idx - 1] |= 1;
> }
>
> if (ret == AVERROR(EAGAIN)) {
> ret = 0;
> idx--;
> continue;
>
> } else if (ret < 0)
>

But in the latest version (
http://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=ffmpeg.c;hb=dfc6e30cd4b9d1817b78579c11fc6881e40b9733
)
I see the bug is already corrected, that's why we couldn't understand each
other.


On Mon, Feb 6, 2017 at 8:41 PM, Ronald S. Bultje  wrote:

> Hi Aleksey,
>
> On Mon, Feb 6, 2017 at 12:14 PM, Aleksey M  wrote:
>
> > Ronald,
> >
> > I looked the vp9_superframe_bsf.c code, but it doesn't help: The only
> place
> > which returns EAGAIN does output packet unref and frees input packet.
> >
> > I tried memset zero on output packet, av_packet_unref, setting out->size
> =
> > 0 and out->side_data_elems = 0, tried to return EAGAIN or 0, nothing
> helps.
> > In any case, "timestamps are not set", "stream is malformed", like the
> > output packet is still used.
>
>
> As frustrating as this may sound, vp9_superframe_bsf does what you're
> asking for, so your best bet is to emulate what it's doing and figure out
> why your code does not invoke the same code path.
>
> Ronald
> ___
> 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] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[u-9iep]

Dear Henrik,

On Tue, Feb 07, 2017 at 07:21:39PM +0100, Hendrik Leppkes wrote:
> > Why not, if there will be a data consumer with this hypothetical format
> > and we will need speed? Why not? This _is_ efficient at the decoder,
> > it is just many of the developers ignored this fact until now.
> 
> If you don't understand why this is bad, then trying to explain it
> again is just wasted time.

Unfortunately this is my very impression, hard to explain "evident"
things because the other party is blinded by his/her own perspective.

> I'll give you a hint: What if every codec would do this? Surely that
> would be faster, but noone in their right mind would ever want to work
> on such an abonimation.

Let me return another hint :)
not every codec (but a small minority) is actually suited for such
optimizations, so your imagined hellish world would not be much faster.

Abomination or not is also a matter of personal taste. I do not feel that
Cinepak code (current one, which since long ago does format conversions :)
is more repulsive than the code of *264 :) but this is irrelevant!

What is relevant is how well they work in the long run.

> >> not a decoders job to convert from RGB to YUV.
> >
> > What is the criteria to choose where the job is to be done?
> > My point is efficiency. What is yours?
> 
> If you want effieciency above everything else, maybe you should write
> a very specific application tailored for your one specific use-case,

This is an example of being "blinded" by one's perspective.

You are positively/constructively trying to put yourself in my situation
and suggest a good solution, but this is highly unreliable. In this
particular case: I do not generally have the power over the applications.
Ther is also the plural "s" in applications.

> and not use a generic multimedia frame work like ffmpeg.

This would not help me a tiny bit. Ffmpeg is a very useful tool,
not being able to use it would be devastating! :) You should be proud.

> Anyway, you don't seem to be understanding our points at all, so the
> chances of this ever being commited are reaching zero.

Doing my best. :)

Unfortunately your position looks like "I know what is a right
solution. If somebody does not agree, s/he is not understanding".

This is because people (you and me included) tend to underestimate:

the invisible but huge limitations which our environment and perspective
put on our capacity to see each other's situation, needs, constraints
and criteria.

You assume a lot about why I am doing thing a certain way.
Many of your assumptions are unfounded.

I assume a lot about what are the developer's motivations and priorities.
Certainly many of these guesses are wrong.

Let's calm down and stop assuming at least one thing,
that the other party is stupid.

Regards,
Rune

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