[FFmpeg-devel] [PATCH] fix-build-wihout-dashenc

[satbaby]

 

fix build wihout dashenc

 From 52e82884fade468470d5dda5469a0908f66ccb80 Mon Sep 17 00:00:00 2001
From: Jacek Jendrzej 
Date: Thu, 5 Oct 2017 10:34:43 +0200
Subject: [PATCH] fix build wihout dashenc

---
 libavformat/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index df709c29dd..d955a8b12a 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -133,7 +133,7 @@ OBJS-$(CONFIG_CRC_MUXER) += crcenc.o
 OBJS-$(CONFIG_DATA_DEMUXER)  += rawdec.o
 OBJS-$(CONFIG_DATA_MUXER)+= rawenc.o
 OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o
-OBJS-$(CONFIG_DASH_DEMUXER)  += dashdec.o
+OBJS-$(CONFIG_DASH_DEMUXER)  += dash.o dashdec.o
 OBJS-$(CONFIG_DAUD_DEMUXER)  += dauddec.o
 OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
 OBJS-$(CONFIG_DCSTR_DEMUXER) += dcstr.o
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH] configure: add libm ldflags globally

[Jörn Heusipp]

On 10/17/2017 03:04 AM, Carl Eugen Hoyos wrote:

2017-10-16 23:02 GMT+02:00 James Almer :

and by hardcoding a -lstdc++ ldflag in configure checks we're
apparently breaking detection on systems where the compiler
uses libc++, like it seems to be the case with Clang on MacOS.


Did you test this?
I ask because I was never able to reproduce (it
was claimed here before).


My FreeBSD (10.3, rather minimal install) system does not have any 
libstdc++. "-lstdc++" thus simply fails to link and clearly is the wrong 
thing to do.


I cannot test on macOS.

Regards,
Jörn (libopenmpt maintainer)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: add libm ldflags globally

[Jörn Heusipp]

On 10/17/2017 12:13 AM, Jan Ekstrom wrote:

On Tue, Oct 17, 2017 at 12:38 AM, Hendrik Leppkes  wrote:

Perhaps such libraries shouldn't hardcode -lstdc++ in there, but
dynamically put whichever C++ library they built against in there
instead?
Its not like you can actually use a static library build with another
C++ library, that *may* randomly work, but its not something anyone
should be doing.

- Hendrik


Yup,

The project should know which C++ runtime it is built against and put
that into the .pc file's Libs.private. If the project doesn't have an
idea on how to automate this, a solution like the one utilized by zimg
is valid as well:

* Check for an environment variable during configuration and set the
default to `-lstdc++`
(https://github.com/sekrit-twc/zimg/blob/ae673e02c8e934915e05daeb120c7cb1b500a0a4/configure.ac#L55..L56)
* Set that value in your pkg-config template
(https://github.com/sekrit-twc/zimg/blob/ae673e02c8e934915e05daeb120c7cb1b500a0a4/zimg.pc.in#L13)


As already explained in another mail, I actually have no idea how to 
reliably determine the name of the C++ standard library. (see 
https://lists.freedesktop.org/archives/pkg-config/2016-August/001055.html 
on the pkg-config mailing list for a similar discussion).


Do you happen to know of any other libraries that do exactly that (use 
of STL_LIBS variable)? If this is somewhat common practice I could add 
support for that variable to libopenmpt.
If it is not, I am considering adding a configure option to libopenmpt, 
something like "--pkgconfig-static-cxxstdlib=-lstdc++" (and also add 
proper documentation about this issue with static linking).
However I do not like defaulting it to some guess (libstdc++), as a 
wrong value here is worse than no value (additional libs can be added 
easily by libraries or programs that use libopenmpt, removing/ignoring 
wrong libs from the .pc file is harder and will cause even more trouble).


For reference: https://bugs.openmpt.org/view.php?id=1045 (libopenmpt issue)

Regards,
Jörn (libopenmpt maintainer)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: add libm ldflags globally

[Jörn Heusipp]

On 10/16/2017 11:38 PM, Hendrik Leppkes wrote:

On Mon, Oct 16, 2017 at 11:02 PM, James Almer  wrote:



The remaining issue after this patchset is applied is linking to the C++
standard library with some external deps. According to Jörn Heusipp, the
libopenmpt maintainer, it's not something that can be safely included in
a pkg-config file, and by hardcoding a -lstdc++ ldflag in configure
checks we're apparently breaking detection on systems where the compiler
uses libc++, like it seems to be the case with Clang on MacOS.



Perhaps such libraries shouldn't hardcode -lstdc++ in there, but
dynamically put whichever C++ library they built against in there
instead?


The problem here is, that we (libopenmpt) do not actually know what the 
name of the standard library is. It is chosen basically by the toolchain 
and there is no standard way to ask it what it uses. There is also no 
standard autoconf check which determines it (but the more I think about 
the issue, the more I think there actually needs to be one).



Its not like you can actually use a static library build with another
C++ library, that *may* randomly work, but its not something anyone
should be doing.


Correct, mismatching C++ standard libraries will not work.

Regards,
Jörn (libopenmpt maintainer)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

[Daniel Kucera]

transfer_func variable passed to retry_transfer_wrapper
are h->prot->url_read and h->prot->url_write functions.
These need to return EOF or other error properly.
In case of returning >= 0, url_read/url_write is retried
until error is returned.

Signed-off-by: Daniel Kucera 
---
 libavformat/avio.c|  6 --
 libavformat/aviobuf.c | 20 
 libavformat/cache.c   |  4 ++--
 libavformat/concat.c  |  9 +
 libavformat/http.c|  5 -
 5 files changed, 27 insertions(+), 17 deletions(-)

diff --git a/libavformat/avio.c b/libavformat/avio.c
index 64248e098b..4718753b7b 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -391,8 +391,10 @@ static inline int retry_transfer_wrapper(URLContext *h, 
uint8_t *buf,
 }
 av_usleep(1000);
 }
-} else if (ret < 1)
-return (ret < 0 && ret != AVERROR_EOF) ? ret : len;
+} else if (ret == AVERROR_EOF)
+return (len > 0) ? len : AVERROR_EOF;
+else if (ret < 0)
+return ret;
 if (ret) {
 fast_retries = FFMAX(fast_retries, 2);
 wait_since = 0;
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 636cb46161..0d4eb051e1 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -572,13 +572,14 @@ static void fill_buffer(AVIOContext *s)
 if (s->read_packet)
 len = s->read_packet(s->opaque, dst, len);
 else
-len = 0;
-if (len <= 0) {
+len = AVERROR_EOF;
+if (len == AVERROR_EOF) {
 /* do not modify buffer if EOF reached so that a seek back can
be done without rereading data */
 s->eof_reached = 1;
-if (len < 0)
-s->error = len;
+} else if (len < 0) {
+s->eof_reached = 1;
+s->error= len;
 } else {
 s->pos += len;
 s->buf_ptr = dst;
@@ -646,13 +647,16 @@ int avio_read(AVIOContext *s, unsigned char *buf, int 
size)
 // bypass the buffer and read data directly into buf
 if(s->read_packet)
 len = s->read_packet(s->opaque, buf, size);
-
-if (len <= 0) {
+else
+len = AVERROR_EOF;
+if (len == AVERROR_EOF) {
 /* do not modify buffer if EOF reached so that a seek back 
can
 be done without rereading data */
 s->eof_reached = 1;
-if(len<0)
-s->error= len;
+break;
+} else if (len < 0) {
+s->eof_reached = 1;
+s->error= len;
 break;
 } else {
 s->pos += len;
diff --git a/libavformat/cache.c b/libavformat/cache.c
index 6aabca2e78..66bbbf54c9 100644
--- a/libavformat/cache.c
+++ b/libavformat/cache.c
@@ -201,7 +201,7 @@ static int cache_read(URLContext *h, unsigned char *buf, 
int size)
 }
 
 r = ffurl_read(c->inner, buf, size);
-if (r == 0 && size>0) {
+if (r == AVERROR_EOF && size>0) {
 c->is_true_eof = 1;
 av_assert0(c->end >= c->logical_pos);
 }
@@ -263,7 +263,7 @@ resolve_eof:
 if (whence == SEEK_SET)
 size = FFMIN(sizeof(tmp), pos - c->logical_pos);
 ret = cache_read(h, tmp, size);
-if (ret == 0 && whence == SEEK_END) {
+if (ret == AVERROR_EOF && whence == SEEK_END) {
 av_assert0(c->is_true_eof);
 goto resolve_eof;
 }
diff --git a/libavformat/concat.c b/libavformat/concat.c
index 46b520fe80..19c83c309a 100644
--- a/libavformat/concat.c
+++ b/libavformat/concat.c
@@ -135,19 +135,20 @@ static int concat_read(URLContext *h, unsigned char *buf, 
int size)
 
 while (size > 0) {
 result = ffurl_read(nodes[i].uc, buf, size);
-if (result < 0)
-return total ? total : result;
-if (!result) {
+if (result == AVERROR_EOF) {
 if (i + 1 == data->length ||
 ffurl_seek(nodes[++i].uc, 0, SEEK_SET) < 0)
 break;
+result = 0;
 }
+if (result < 0)
+return total ? total : result;
 total += result;
 buf   += result;
 size  -= result;
 }
 data->current = i;
-return total;
+return total ? total : result;
 }
 
 static int64_t concat_seek(URLContext *h, int64_t pos, int whence)
diff --git a/libavformat/http.c b/libavformat/http.c
index 668cd51986..bd9148f45d 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1296,8 +1296,11 @@ static int http_buf_read(URLContext *h, uint8_t *buf, 
int size)
"Chunked encoding data size: %"PRIu64"'\n",
 s->chunksize);
 
-if (!s->chunksize)
+if (!s->chunksize) {
+av_log(h, AV_LOG_DEBUG, "Last chunk r

Re: [FFmpeg-devel] [PATCH 1/7] Revert "Revert "lavfi/buffersrc: push the frame deeper if requested.""

[Tobias Rapp]

On 17.07.2017 16:19, Nicolas George wrote:

This reverts commit 04aa09c4bcf2d5a634a35da3a3ae3fc1abe30ef8.

The fate-ffm change is caused by field_order now being set
on the output format because the first frame arrives earlier.
The fate-mxf change is assumed to be the same.

Signed-off-by: Nicolas George 
---
  libavfilter/buffersrc.c | 25 +
  tests/ref/lavf/ffm  |  2 +-
  tests/ref/lavf/mxf  |  6 +++---
  3 files changed, 29 insertions(+), 4 deletions(-)

[...]
This commit seems to break transcoding of some input files on machines 
with a lot of CPU cores. See attached script that reproduces the problem 
("-threads 32" is used to simulate the situation of a multi-core CPU).


Sorry for noticing late but it took me some time to track down the 
problem and git bisecting it. The issue seems to be triggered by the 
high number of audio packets in the input file (~375 packets per 
second). Input files that have a lower audio packet rate work fine.


Regards,
Tobias
#!/bin/bash

# =
# Configuration

BASE_PATH="./debug"
INPUT_FILE="$BASE_PATH/ffmpeg-test-input.avi"
OUTPUT_FILE="$BASE_PATH/ffmpeg-test-output.avi"
TEMP_FILE="$BASE_PATH/ffmpeg-test-temp.wav"

FFMPEG_PATH="."
FFMPEG_BIN="$FFMPEG_PATH/build-linux/ffmpeg-dbg"

# =
# Create Input Files

mkdir -p "$BASE_PATH"

$FFMPEG_BIN \
  -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact \
  -f lavfi -graph 
"aevalsrc=sin(440*2*PI*t):sample_rate=48000:channel_layout=7.1" -i dummy1 \
  -f wav -codec:a pcm_f32le -t 30.0 -y "$TEMP_FILE"

$FFMPEG_BIN \
  -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact \
  -f lavfi -graph 
"testsrc2=size=720x576:rate=25:sar=16/15,noise=alls=40:allf=t+u" -i dummy1 \
  -i "$TEMP_FILE" \
  -f avi -codec:v ffvhuff -pix_fmt yuv422p -codec:a pcm_s24le -t 30.0 -y 
"$INPUT_FILE"

# =
# Create Output File

$FFMPEG_BIN \
  -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact \
  -threads 32 -probesize 50M -ss 3.0 -i "$INPUT_FILE" \
  -f avi -map 0:v -map 0:a -codec:v ffvhuff -pix_fmt yuv422p \
  -codec:a pcm_s24le -loglevel repeat+verbose -xerror \
  -y "$OUTPUT_FILE"

if [ $? -eq 0 ]; then
  echo "=== TEST SUCCEEDED ===";
else
  echo "=== TEST FAILED ===";
fi
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fix-build-wihout-dashenc

[James Almer]

On 10/17/2017 4:21 AM, satb...@kawaii.com wrote:
>  
> 
> fix build wihout dashenc
> 
>  
> 
> 
> 0001-fix-build-wihout-dashenc.patch
> 
> 
> From 52e82884fade468470d5dda5469a0908f66ccb80 Mon Sep 17 00:00:00 2001
> From: Jacek Jendrzej 
> Date: Thu, 5 Oct 2017 10:34:43 +0200
> Subject: [PATCH] fix build wihout dashenc
> 
> ---
>  libavformat/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index df709c29dd..d955a8b12a 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -133,7 +133,7 @@ OBJS-$(CONFIG_CRC_MUXER) += crcenc.o
>  OBJS-$(CONFIG_DATA_DEMUXER)  += rawdec.o
>  OBJS-$(CONFIG_DATA_MUXER)+= rawenc.o
>  OBJS-$(CONFIG_DASH_MUXER)+= dash.o dashenc.o
> -OBJS-$(CONFIG_DASH_DEMUXER)  += dashdec.o
> +OBJS-$(CONFIG_DASH_DEMUXER)  += dash.o dashdec.o
>  OBJS-$(CONFIG_DAUD_DEMUXER)  += dauddec.o
>  OBJS-$(CONFIG_DAUD_MUXER)+= daudenc.o
>  OBJS-$(CONFIG_DCSTR_DEMUXER) += dcstr.o
> -- 2.14.2

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

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support

[Dave Rice]

Hi Paul,

> On Oct 16, 2017, at 3:56 PM, Paul B Mahol  wrote:
> 
> On 10/16/17, Dave Rice mailto:d...@dericed.com>> wrote:
>> Hi,
>> 
>> I tested this with my Ultrastudio Express and confirmed that I'm getting
>> higher bit depth recordings with the abitscope filter. This patch adds an
>> option to get 32 bit audio as an input with the decklink device (beforehand
>> only 16 bit audio was supported). This resolves
>> http://trac.ffmpeg.org/ticket/6708 and is partly based upon Georg
>> Lippitisch's earlier draft at
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167649.html.
>> 
>> 
>> From fbf2bd40471c8fa35374bb1a51c51a3f4f36b992 Mon Sep 17 00:00:00 2001
>> From: Dave Rice 
>> Date: Thu, 12 Oct 2017 13:40:59 -0400
>> Subject: [PATCH] libavdevice/decklink: 32 bit audio support
>> 
>> Partially based upon Georg Lippitsch's patch at
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-January/167649.html.
>> ---
>> libavdevice/decklink_common.h   |  1 +
>> libavdevice/decklink_common_c.h |  1 +
>> libavdevice/decklink_dec.cpp| 17 ++---
>> libavdevice/decklink_dec_c.c|  1 +
>> 4 files changed, 17 insertions(+), 3 deletions(-)
>> 
>> diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
>> index 6b2525fb53..b6acb01bb9 100644
>> --- a/libavdevice/decklink_common.h
>> +++ b/libavdevice/decklink_common.h
>> @@ -97,6 +97,7 @@ struct decklink_ctx {
>> int frames_buffer_available_spots;
>> 
>> int channels;
>> +int audio_depth;
>> };
>> 
>> typedef enum { DIRECTION_IN, DIRECTION_OUT} decklink_direction_t;
>> diff --git a/libavdevice/decklink_common_c.h
>> b/libavdevice/decklink_common_c.h
>> index 5616ab32f9..368ac259e4 100644
>> --- a/libavdevice/decklink_common_c.h
>> +++ b/libavdevice/decklink_common_c.h
>> @@ -42,6 +42,7 @@ struct decklink_cctx {
>> double preroll;
>> int v210;
>> int audio_channels;
>> +int audio_depth;
>> int duplex_mode;
>> DecklinkPtsSource audio_pts_source;
>> DecklinkPtsSource video_pts_source;
>> diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
>> index d9ac01ac91..7e97d5f064 100644
>> --- a/libavdevice/decklink_dec.cpp
>> +++ b/libavdevice/decklink_dec.cpp
>> @@ -771,7 +771,7 @@ HRESULT
>> decklink_input_callback::VideoInputFrameArrived(
>> av_init_packet(&pkt);
>> 
>> //hack among hacks
>> -pkt.size = audioFrame->GetSampleFrameCount() *
>> ctx->audio_st->codecpar->channels * (16 / 8);
>> +pkt.size = audioFrame->GetSampleFrameCount() *
>> ctx->audio_st->codecpar->channels * (ctx->audio_depth / 8);
>> audioFrame->GetBytes(&audioFrameBytes);
>> audioFrame->GetPacketTime(&audio_pts,
>> ctx->audio_st->time_base.den);
>> pkt.pts = get_pkt_pts(videoFrame, audioFrame, wallclock,
>> ctx->audio_pts_source, ctx->audio_st->time_base, &initial_audio_pts);
>> @@ -854,6 +854,7 @@ av_cold int ff_decklink_read_header(AVFormatContext
>> *avctx)
>> ctx->audio_pts_source = cctx->audio_pts_source;
>> ctx->video_pts_source = cctx->video_pts_source;
>> ctx->draw_bars = cctx->draw_bars;
>> +ctx->audio_depth = cctx->audio_depth;
>> cctx->ctx = ctx;
>> 
>> /* Check audio channel option for valid values: 2, 8 or 16 */
>> @@ -866,6 +867,16 @@ av_cold int ff_decklink_read_header(AVFormatContext
>> *avctx)
>> av_log(avctx, AV_LOG_ERROR, "Value of channels option must be
>> one of 2, 8 or 16\n");
>> return AVERROR(EINVAL);
>> }
>> +
>> +/* Check audio bit depth option for valid values: 16 or 32 */
>> +switch (cctx->audio_depth) {
>> +case 16:
>> +case 32:
>> +break;
>> +default:
>> +av_log(avctx, AV_LOG_ERROR, "Value for audio bit depth option
>> must be either 16 or 32\n");
>> +return AVERROR(EINVAL);
> 
> This message is redundant with AVOptions, User should be able to
> select only 16 or 32,
> see bellow.
> 
>> +}
>> 
>> /* List available devices. */
>> if (ctx->list_devices) {
>> @@ -930,7 +941,7 @@ av_cold int ff_decklink_read_header(AVFormatContext
>> *avctx)
>> goto error;
>> }
>> st->codecpar->codec_type  = AVMEDIA_TYPE_AUDIO;
>> -st->codecpar->codec_id= AV_CODEC_ID_PCM_S16LE;
>> +st->codecpar->codec_id= cctx->audio_depth == 32 ?
>> AV_CODEC_ID_PCM_S32LE : AV_CODEC_ID_PCM_S16LE;
>> st->codecpar->sample_rate = bmdAudioSampleRate48kHz;
>> st->codecpar->channels= cctx->audio_channels;
>> avpriv_set_pts_info(st, 64, 1, 100);  /* 64 bits pts in us */
>> @@ -1021,7 +1032,7 @@ av_cold int ff_decklink_read_header(AVFormatContext
>> *avctx)
>> }
>> 
>> av_log(avctx, AV_LOG_VERBOSE, "Using %d input audio channels\n",
>> ctx->audio_st->codecpar->channels);
>> -result = ctx->dli->EnableAudioInput(bmdAudioSampleRate48kHz,
>> bmdAudioSampleType16bitInteger, ctx->audio_st->codecpar->channels);
>> +result = ctx->dli->EnableAudioInput(bmdAudioSampleRate48kHz,
>> cctx

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

[Bjorn Roche]

On Mon, Oct 16, 2017 at 9:16 PM, Carl Eugen Hoyos 
wrote:

> 2017-10-10 23:41 GMT+02:00 Bjorn Roche :
>
> > +{ "trans_threshold", "set the threshold for alpha values avoce
> which they are considered completely opaque", OFFSET(trans_thresh),
> AV_OPT_TYPE_INT, {.i64=128}, 0, 255, },
>
> I wonder if "threshold" is enough.
>

That would be fine with me. I can submit another patch if I get any further
feedback.

bjorn

-- 


Bjorn Roche

Sr. Video Pipeline Engineer

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

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support

[Moritz Barsnick]

On Tue, Oct 17, 2017 at 09:22:27 -0400, Dave Rice wrote:
> >> --- a/libavdevice/decklink_dec_c.c
> >> +++ b/libavdevice/decklink_dec_c.c
> >> @@ -72,6 +72,7 @@ static const AVOption options[] = {
> >> { "wallclock", NULL,  0,
> >> AV_OPT_TYPE_CONST, { .i64 = PTS_SRC_WALLCLOCK}, 0, 0, DEC, "pts_source"},
> >> { "draw_bars", "draw bars on signal loss" , OFFSET(draw_bars),
> >> AV_OPT_TYPE_BOOL,  { .i64 = 1}, 0, 1, DEC },
> >> { "queue_size","input queue buffer size",   OFFSET(queue_size),
> >> AV_OPT_TYPE_INT64, { .i64 = (1024 * 1024 * 1024)}, 0, INT64_MAX, DEC },
> >> +{ "audio_depth",   "audio bitdepth (16 or 32)", OFFSET(audio_depth),
> >> AV_OPT_TYPE_INT,   { .i64 = 16}, 16, 32, DEC },
> > 
> > Use AV_OPT_ ENUM instead.
> 
> I don't see there to be an AV_OPT_TYPE_ENUM. Could you point out how this 
> works from an example? Alternatively since the decklink sdk only supports 2 
> bit depths (16 and 32), I could use a boolean here if that makes more sense.

I would guess Paul means:

enum audio_bitdepths {
AUDIO_BITDEPTH_16,
AUDIO_BITDEPTH_32,
AUDIO_BITDEPTH_NB
};

{ "audio_depth","audio bitdepth", OFFSET(audio_depth), AV_OPT_TYPE_INT, 
  { .i64 = AUDIO_BITDEPTH_16 }, 0, AUDIO_BITDEPTH_NB-1, DEC, "audio_depth" },
{ "16", "16 bits",  0, 
AV_OPT_TYPE_CONST, { .i64 = AUDIO_BITDEPTH_16 }, 0, 0,   DEC, 
"audio_depth" },
{ "32", "32 bits",  0, 
AV_OPT_TYPE_CONST, { .i64 = AUDIO_BITDEPTH_32 }, 0, 0,   DEC, 
"audio_depth" },

I'm not sure pure digits are accepted as an option strin ("16", "32"), but, why 
shouldn't they.

It may seem like a bit of overkill for two values, but take into
consideration that you can skip the check "Check audio bit depth option
for valid values: 16 or 32", but need to map the enums to values
instead. Or you pre-assign the enums values (AUDIO_BITDEPTH_16 = 16,
...), but use some other trick to define the lowest possible value.[*]
And you can easily add 8 bit or 24 bit support. ;-)

Cheers,
Moritz

[*]
enum audio_bitdepths {
AUDIO_BITDEPTH_LOWEST = 16,
AUDIO_BITDEPTH_16 = 16,
AUDIO_BITDEPTH_32 = 32,
AUDIO_BITDEPTH_NB
};

{ "audio_depth","audio bitdepth", OFFSET(audio_depth), AV_OPT_TYPE_INT, 
  { .i64 = AUDIO_BITDEPTH_16 }, AUDIO_BITDEPTH_LOWEST, AUDIO_BITDEPTH_NB-1, 
DEC, "audio_depth" },
{ "16", "16 bits",  0, 
AV_OPT_TYPE_CONST, { .i64 = AUDIO_BITDEPTH_16 }, 0, 0, DEC, "audio_depth" },
{ "32", "32 bits",  0, 
AV_OPT_TYPE_CONST, { .i64 = AUDIO_BITDEPTH_32 }, 0, 0, DEC, "audio_depth" },
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/filters: Add note on Flite thread safety and update URL

[Moritz Barsnick]

On Mon, Oct 09, 2017 at 11:19:45 +0530, Gyan Doshi wrote:
> Version 2 of Flite, a speech synthesis library, was released towards the 
> end of 2014. Among the notes at the project site: "Thread safe (really 
> this time)".

BTW, I have a patch flying around for support of flite 1.3. ffmpeg
currently requires >= 1.4, but RedHat/Fedora/EPEL still distribute 1.3
for some stupid reason. They could thereby gain support.

Is this too niche to even consider? (I think I can test, though I
updated my flite locally.)

Sorry for hijacking,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support

[Dave Rice]

Hi Moritz,

> On Oct 17, 2017, at 10:40 AM, Moritz Barsnick  wrote:
> 
> On Tue, Oct 17, 2017 at 09:22:27 -0400, Dave Rice wrote:
 --- a/libavdevice/decklink_dec_c.c
 +++ b/libavdevice/decklink_dec_c.c
 @@ -72,6 +72,7 @@ static const AVOption options[] = {
{ "wallclock", NULL,  0,
 AV_OPT_TYPE_CONST, { .i64 = PTS_SRC_WALLCLOCK}, 0, 0, DEC, "pts_source"},
{ "draw_bars", "draw bars on signal loss" , OFFSET(draw_bars),
 AV_OPT_TYPE_BOOL,  { .i64 = 1}, 0, 1, DEC },
{ "queue_size","input queue buffer size",   OFFSET(queue_size),
 AV_OPT_TYPE_INT64, { .i64 = (1024 * 1024 * 1024)}, 0, INT64_MAX, DEC },
 +{ "audio_depth",   "audio bitdepth (16 or 32)", OFFSET(audio_depth),
 AV_OPT_TYPE_INT,   { .i64 = 16}, 16, 32, DEC },
>>> 
>>> Use AV_OPT_ ENUM instead.
>> 
>> I don't see there to be an AV_OPT_TYPE_ENUM. Could you point out how this 
>> works from an example? Alternatively since the decklink sdk only supports 2 
>> bit depths (16 and 32), I could use a boolean here if that makes more sense.
> 
> I would guess Paul means:
> 
> enum audio_bitdepths {
>AUDIO_BITDEPTH_16,
>AUDIO_BITDEPTH_32,
>AUDIO_BITDEPTH_NB
> };
> 
>{ "audio_depth","audio bitdepth", OFFSET(audio_depth), 
> AV_OPT_TYPE_INT,   { .i64 = AUDIO_BITDEPTH_16 }, 0, AUDIO_BITDEPTH_NB-1, DEC, 
> "audio_depth" },
>{ "16", "16 bits",  0, 
> AV_OPT_TYPE_CONST, { .i64 = AUDIO_BITDEPTH_16 }, 0, 0,   DEC, 
> "audio_depth" },
>{ "32", "32 bits",  0, 
> AV_OPT_TYPE_CONST, { .i64 = AUDIO_BITDEPTH_32 }, 0, 0,   DEC, 
> "audio_depth" },
> 
> I'm not sure pure digits are accepted as an option strin ("16", "32"), but, 
> why shouldn't they.
> 
> It may seem like a bit of overkill for two values, but take into
> consideration that you can skip the check "Check audio bit depth option
> for valid values: 16 or 32", but need to map the enums to values
> instead. Or you pre-assign the enums values (AUDIO_BITDEPTH_16 = 16,
> ...), but use some other trick to define the lowest possible value.[*]
> And you can easily add 8 bit or 24 bit support. ;-)
> 
> Cheers,
> Moritz
> 
> [*]
> enum audio_bitdepths {
>AUDIO_BITDEPTH_LOWEST = 16,
>AUDIO_BITDEPTH_16 = 16,
>AUDIO_BITDEPTH_32 = 32,
>AUDIO_BITDEPTH_NB
> };
> 
>{ "audio_depth","audio bitdepth", OFFSET(audio_depth), 
> AV_OPT_TYPE_INT,   { .i64 = AUDIO_BITDEPTH_16 }, AUDIO_BITDEPTH_LOWEST, 
> AUDIO_BITDEPTH_NB-1, DEC, "audio_depth" },
>{ "16", "16 bits",  0, 
> AV_OPT_TYPE_CONST, { .i64 = AUDIO_BITDEPTH_16 }, 0, 0, DEC, "audio_depth" },
>{ "32", "32 bits",  0, 
> AV_OPT_TYPE_CONST, { .i64 = AUDIO_BITDEPTH_32 }, 0, 0, DEC, "audio_depth" },
> ___

Thanks for pointing me in the right direction. I am attaching an updated patch 
below; however, after removing my 16/32 and using the enumeration method (with 
the patch below), it accepts any value between AUDIO_BITDEPTH_LOWEST and 
AUDIO_BITDEPTH_NB-1 (16 and 32). When I enter any value from 17 through 31 then 
the output is still in pcm_s16le, however the resulting audio is slow and 
choppy (I'm guessing from the pkt.size line). Am I missing some method to say 
that the enumeration list is restrictive?


From 10f3003e8b690bba1a722b615481d80644cdb2c1 Mon Sep 17 00:00:00 2001
From: Dave Rice 
Date: Tue, 17 Oct 2017 10:52:10 -0400
Subject: [PATCH] libavdevice/decklink: 32 bit audio support

---
 libavdevice/decklink_common.h   | 1 +
 libavdevice/decklink_common_c.h | 8 
 libavdevice/decklink_dec.cpp| 7 ---
 libavdevice/decklink_dec_c.c| 3 +++
 4 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 6b2525fb53..b6acb01bb9 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -97,6 +97,7 @@ struct decklink_ctx {
 int frames_buffer_available_spots;
 
 int channels;
+int audio_depth;
 };
 
 typedef enum { DIRECTION_IN, DIRECTION_OUT} decklink_direction_t;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index 5616ab32f9..cf534c1413 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -30,6 +30,13 @@ typedef enum DecklinkPtsSource {
 PTS_SRC_WALLCLOCK = 4,
 } DecklinkPtsSource;
 
+typedef enum audio_bitdepths {
+   AUDIO_BITDEPTH_LOWEST = 16,
+   AUDIO_BITDEPTH_16 = 16,
+   AUDIO_BITDEPTH_32 = 32,
+   AUDIO_BITDEPTH_NB
+} audio_bitdepths;
+
 struct decklink_cctx {
 const AVClass *cclass;
 
@@ -42,6 +49,7 @@ struct decklink_cctx {
 double preroll;
 int v210;
 int audio_channels;
+int audio_depth;
 int duplex_mode;
 DecklinkPtsSource audio_pts_source;
 DecklinkPtsS

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support

[Moritz Barsnick]

On Tue, Oct 17, 2017 at 11:12:46 -0400, Dave Rice wrote:

> Thanks for pointing me in the right direction. I am attaching an
> updated patch below; however, after removing my 16/32 and using the
> enumeration method (with the patch below), it accepts any value
> between AUDIO_BITDEPTH_LOWEST and AUDIO_BITDEPTH_NB-1 (16 and 32).
> When I enter any value from 17 through 31 then the output is still in
> pcm_s16le, however the resulting audio is slow and choppy (I'm
> guessing from the pkt.size line). Am I missing some method to say
> that the enumeration list is restrictive?

Yes, that was exactly the oversight I had. The const'ified option now
takes those strings, but also numbers within the range. So the option
value "16" will be either "16" (string) or 16 (or integer), "17" will
be interpreted as integer 17 (and still valid thanks to the range), and
so on. My bad.

So I guess it's stupid to use a string enum to represent a number
value. You could properly restrict its use to the enumerated values if
they were subsequent (i.e. 0, 1), and perhaps strings with letters for
the enumerated options. But that's totally unintuitive. It would result
in (auto doc):

  -audio_depth   .D.. audio bitdepth (from 0 to 1) 
(default 16bits)
 16bits   .D..
 32bits   .D..

and you could use it with either
  -audio_depth 0 # 16 bits
  -audio_depth 1 # 32 bits
  -audio_depth 16bits # 16 bits
  -audio_depth 32bits # 16 bits
but not
  -audio_depth 16

Horrible!

Your original version was most intuitive, IMHO. Sorry for explaining
the concept. ;-) It fits well for anything representable by strings,
not numbers.

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

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support

[Paul B Mahol]

On 10/17/17, Moritz Barsnick  wrote:
> On Tue, Oct 17, 2017 at 11:12:46 -0400, Dave Rice wrote:
>
>> Thanks for pointing me in the right direction. I am attaching an
>> updated patch below; however, after removing my 16/32 and using the
>> enumeration method (with the patch below), it accepts any value
>> between AUDIO_BITDEPTH_LOWEST and AUDIO_BITDEPTH_NB-1 (16 and 32).
>> When I enter any value from 17 through 31 then the output is still in
>> pcm_s16le, however the resulting audio is slow and choppy (I'm
>> guessing from the pkt.size line). Am I missing some method to say
>> that the enumeration list is restrictive?
>
> Yes, that was exactly the oversight I had. The const'ified option now
> takes those strings, but also numbers within the range. So the option
> value "16" will be either "16" (string) or 16 (or integer), "17" will
> be interpreted as integer 17 (and still valid thanks to the range), and
> so on. My bad.
>
> So I guess it's stupid to use a string enum to represent a number
> value. You could properly restrict its use to the enumerated values if
> they were subsequent (i.e. 0, 1), and perhaps strings with letters for
> the enumerated options. But that's totally unintuitive. It would result
> in (auto doc):
>
>   -audio_depth   .D.. audio bitdepth (from 0 to 1)
> (default 16bits)
>  16bits   .D..
>  32bits   .D..
>
> and you could use it with either
>   -audio_depth 0 # 16 bits
>   -audio_depth 1 # 32 bits
>   -audio_depth 16bits # 16 bits
>   -audio_depth 32bits # 16 bits
> but not
>   -audio_depth 16
>
> Horrible!
>
> Your original version was most intuitive, IMHO. Sorry for explaining
> the concept. ;-) It fits well for anything representable by strings,
> not numbers.

Hmm, first patch might be enough.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support

[Dave Rice]

> On Oct 17, 2017, at 11:48 AM, Paul B Mahol  wrote:
> 
> On 10/17/17, Moritz Barsnick  wrote:
>> On Tue, Oct 17, 2017 at 11:12:46 -0400, Dave Rice wrote:
>> 
>>> Thanks for pointing me in the right direction. I am attaching an
>>> updated patch below; however, after removing my 16/32 and using the
>>> enumeration method (with the patch below), it accepts any value
>>> between AUDIO_BITDEPTH_LOWEST and AUDIO_BITDEPTH_NB-1 (16 and 32).
>>> When I enter any value from 17 through 31 then the output is still in
>>> pcm_s16le, however the resulting audio is slow and choppy (I'm
>>> guessing from the pkt.size line). Am I missing some method to say
>>> that the enumeration list is restrictive?
>> 
>> Yes, that was exactly the oversight I had. The const'ified option now
>> takes those strings, but also numbers within the range. So the option
>> value "16" will be either "16" (string) or 16 (or integer), "17" will
>> be interpreted as integer 17 (and still valid thanks to the range), and
>> so on. My bad.
>> 
>> So I guess it's stupid to use a string enum to represent a number
>> value. You could properly restrict its use to the enumerated values if
>> they were subsequent (i.e. 0, 1), and perhaps strings with letters for
>> the enumerated options. But that's totally unintuitive. It would result
>> in (auto doc):
>> 
>>  -audio_depth   .D.. audio bitdepth (from 0 to 1)
>> (default 16bits)
>> 16bits   .D..
>> 32bits   .D..
>> 
>> and you could use it with either
>>  -audio_depth 0 # 16 bits
>>  -audio_depth 1 # 32 bits
>>  -audio_depth 16bits # 16 bits
>>  -audio_depth 32bits # 16 bits
>> but not
>>  -audio_depth 16
>> 
>> Horrible!
>> 
>> Your original version was most intuitive, IMHO. Sorry for explaining
>> the concept. ;-) It fits well for anything representable by strings,
>> not numbers.
> 
> Hmm, first patch might be enough.

Sounds good to me. Unless anyone prefers "-audio_depth thirtytwo" :-D
Dave Rice


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

[FFmpeg-devel] [PATCH] fateserver/log: clean chars in slot, time and log

[Michael Niedermayer]

Fixes: Directory Traversal

Found-by: Pankaj Jadhav 
Signed-off-by: Michael Niedermayer 
---
 log.cgi | 4 
 1 file changed, 4 insertions(+)

diff --git a/log.cgi b/log.cgi
index d5d2abb..8767e3a 100755
--- a/log.cgi
+++ b/log.cgi
@@ -22,7 +22,11 @@ use FATE;
 
 my $req_slot = param 'slot';
 my $req_time = param 'time';
+$req_slot =~ s/[^-._A-Za-z0-9 ]*//g;
+$req_time =~ s/[^0-9]*//g;
 my ($req_log, $req_diff) = param('log') =~ m!([^/]+)(?:/([^/]+))?!;
+$req_log  =~ s/[^a-z]*//g;
+$req_diff =~ s/[^0-9]*//g;
 
 my $repdir = "$fatedir/$req_slot/$req_time";
 my $log = "$repdir/$req_log.log.gz";
-- 
2.14.2

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

[FFmpeg-devel] [PATCH] avformat/http: use assignment of structure instead of memcpy

[Zhao Zhili]

---
 libavformat/http.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index 668cd51986..63dfd51117 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -173,12 +173,10 @@ static int http_read_header(URLContext *h, int 
*new_location);
 
 void ff_http_init_auth_state(URLContext *dest, const URLContext *src)
 {
-memcpy(&((HTTPContext *)dest->priv_data)->auth_state,
-   &((HTTPContext *)src->priv_data)->auth_state,
-   sizeof(HTTPAuthState));
-memcpy(&((HTTPContext *)dest->priv_data)->proxy_auth_state,
-   &((HTTPContext *)src->priv_data)->proxy_auth_state,
-   sizeof(HTTPAuthState));
+HTTPContext *d = dest->priv_data;
+HTTPContext *s = src->priv_data;
+d->auth_state = s->auth_state;
+d->proxy_auth_state = s->proxy_auth_state;
 }
 
 static int http_open_cnx_internal(URLContext *h, AVDictionary **options)
-- 
2.14.2

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

[FFmpeg-devel] [PATCH] avcodec/v4l2: fix access to priv_data after codec close.

[Jorge Ramirez-Ortiz]

A user can close the codec while keeping references to some of the
capture buffers. When the codec is closed, the structure that keeps
the contexts, state and the driver file descriptor is freed.

Since access to some of the elements in that structure is required to
properly release the memory during the buffer unref callbacks, the
following commit makes sure the unref callback accesses valid memory.

This commit was tested with valgrind:

$ valgrind ffmpeg_g -report -threads 1 -v 55  -y -c:v h264_v4l2m2m \
  -i video.h264 -an -frames:v 100 -f null -
---
 libavcodec/v4l2_buffers.c | 17 -
 libavcodec/v4l2_buffers.h |  6 ++
 libavcodec/v4l2_m2m.c | 29 -
 libavcodec/v4l2_m2m_dec.c |  2 +-
 4 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index ba70c5d..80e65ca 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -205,9 +205,24 @@ static enum AVColorTransferCharacteristic 
v4l2_get_color_trc(V4L2Buffer *buf)
 static void v4l2_free_buffer(void *opaque, uint8_t *unused)
 {
 V4L2Buffer* avbuf = opaque;
-V4L2m2mContext *s = buf_to_m2mctx(avbuf);
+V4L2m2mContext *s = avbuf->m2m ? avbuf->m2m : buf_to_m2mctx(avbuf);
 
 atomic_fetch_sub_explicit(&s->refcount, 1, memory_order_acq_rel);
+
+if (avbuf->m2m) {
+if (!atomic_load(&s->refcount)) {
+/* unmmap and free the associated buffers */
+ff_v4l2_context_release(&s->capture);
+
+/* close the v4l2 driver */
+close(s->fd);
+
+/* release the duplicated m2m context */
+av_freep(&s);
+}
+return;
+}
+
 if (s->reinit) {
 if (!atomic_load(&s->refcount))
 sem_post(&s->refsync);
diff --git a/libavcodec/v4l2_buffers.h b/libavcodec/v4l2_buffers.h
index e28a4a6..d774480 100644
--- a/libavcodec/v4l2_buffers.h
+++ b/libavcodec/v4l2_buffers.h
@@ -41,6 +41,12 @@ typedef struct V4L2Buffer {
 /* each buffer needs to have a reference to its context */
 struct V4L2Context *context;
 
+/* when the codec is closed while the user has buffer references we
+ * still need access to context data (this is a pointer to a duplicated
+ * m2m context created during the codec close function).
+ */
+struct V4L2m2mContext *m2m;
+
 /* keep track of the mmap address and mmap length */
 struct V4L2Plane_info {
 int bytesperline;
diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
index 1d7a852..91b1bbb 100644
--- a/libavcodec/v4l2_m2m.c
+++ b/libavcodec/v4l2_m2m.c
@@ -313,8 +313,8 @@ error:
 
 int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
 {
-V4L2m2mContext* s = avctx->priv_data;
-int ret;
+V4L2m2mContext *m2m, *s = avctx->priv_data;
+int i, ret;
 
 ret = ff_v4l2_context_set_status(&s->output, VIDIOC_STREAMOFF);
 if (ret)
@@ -325,12 +325,31 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
 av_log(avctx, AV_LOG_ERROR, "VIDIOC_STREAMOFF %s\n", s->capture.name);
 
 ff_v4l2_context_release(&s->output);
+sem_destroy(&s->refsync);
 
-if (atomic_load(&s->refcount))
-av_log(avctx, AV_LOG_ERROR, "ff_v4l2m2m_codec_end leaving pending 
buffers\n");
+if (atomic_load(&s->refcount)) {
+av_log(avctx, AV_LOG_DEBUG, "ff_v4l2m2m_codec_end, referenced buffers 
%d\n", atomic_load(&s->refcount));
+
+/* We are about to free the private data while the user still has 
references to the buffers.
+ * This means that when the user releases those buffers, the 
v4l2_free_buffer callback will be pointing to free'd memory.
+ * Duplicate the m2m context and update the buffers.
+ */
+m2m = av_mallocz(sizeof(*m2m));
+if (m2m) {
+memcpy(m2m, s, sizeof(V4L2m2mContext));
+for (i = 0; i < s->capture.num_buffers; i++)
+s->capture.buffers[i].m2m = m2m;
+
+return 0;
+}
+
+/* on ENOMEM let's at least close the v4l2 driver and release the 
capture memory
+ * so the driver is left in a healthy state.
+ */
+av_log(avctx, AV_LOG_ERROR, "ff_v4l2m2m_codec_end, referenced buffers 
not accessible\n");
+}
 
 ff_v4l2_context_release(&s->capture);
-sem_destroy(&s->refsync);
 
 /* release the hardware */
 if (close(s->fd) < 0 )
diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index 958cdc5..f88f819 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -38,7 +38,7 @@ static int v4l2_try_start(AVCodecContext *avctx)
 V4L2m2mContext *s = avctx->priv_data;
 V4L2Context *const capture = &s->capture;
 V4L2Context *const output = &s->output;
-struct v4l2_selection selection;
+struct v4l2_selection selection = { 0 };
 int ret;
 
 /* 1. start the output process */
-- 
2.7.4

___
ffmpeg-devel mailing list
ff

[FFmpeg-devel] [PATCH] avformat/dv : change audio format endianess to BE

[Александр Слободенюк]

Hello again!

I  have checked (updated and fixed) the patch on BE machine (qemu-mips with BE 
linux kernel, lscpu shows big endian): the CRCs of the sound are the
same:

(first link was get directly from 
http://www.mediafire.com/file/8agcdgs2f9kqlbi/submarine.dv)
wget 
http://download1643.mediafireuserdownload.com/h3we3e4t26tg/8agcdgs2f9kqlbi/submarine.dv
wget https://trac.ffmpeg.org/raw-attachment/ticket/1589/A1590.dv

./ffmpeg -i submarine.dv audio-submarine.wav
./ffmpeg -i A1589.dv audio-12bit.wav

(I  had  to  extract the audio out because with video CRCs are not the
same on BE and LE machines on master version of ffmpeg)

./ffmpeg -i audio-submarine.wav -f crc - 2>/dev/null
CRC=0x96b2ce8c

./ffmpeg -i audio-12bit.wav -f crc - 2>/dev/null
CRC=0x01c9318a

--
So, this CRCs are the same for all of the variants:

- not patched ffmpeg on LE machine
- patched ffmpeg on LE machine
- not patched ffmpeg on BE machine
- patched ffmpeg on BE machine
--

Attaching the updated to current master patch.

0001-avformat-dv-change-audio-format-endianess-to-BE.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 03/20] lavc: Add coded bitstream read/write API

[Michael Niedermayer]

On Sun, Oct 15, 2017 at 04:04:30PM +0100, Mark Thompson wrote:
> (cherry picked from commit 18f1706f331bf5dd565774eae680508c8d3a97ad)
> (cherry picked from commit 44cde38c8acbef7d5250e6d1b52b1020871e093b)
> ---
>  configure |   1 +
>  libavcodec/Makefile   |   1 +
>  libavcodec/cbs.c  | 482 
> ++
>  libavcodec/cbs.h  | 308 +
>  libavcodec/cbs_internal.h |  86 +
>  5 files changed, 878 insertions(+)
>  create mode 100644 libavcodec/cbs.c
>  create mode 100644 libavcodec/cbs.h
>  create mode 100644 libavcodec/cbs_internal.h

LGTM

thanks

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

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott



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/7] Revert "Revert "lavfi/buffersrc: push the frame deeper if requested.""

[Nicolas George]

Le sextidi 26 vendémiaire, an CCXXVI, Tobias Rapp a écrit :
> This commit seems to break transcoding of some input files on machines with
> a lot of CPU cores. See attached script that reproduces the problem
> ("-threads 32" is used to simulate the situation of a multi-core CPU).
> 
> Sorry for noticing late but it took me some time to track down the problem
> and git bisecting it. The issue seems to be triggered by the high number of
> audio packets in the input file (~375 packets per second). Input files that
> have a lower audio packet rate work fine.

Thanks for reporting. I fear this will be tricky to debug.

I think the change you  have tracked cannot be the cause of the issue,
since it does not touch anything related to threading.

What this change does, on the other hand, is increase the efficiency of
the scheduling in lavfi. That can cause more work for filters that do
use threading, and reveal a race condition there.

I do not have access to a 32-core system. Can the problem be reproduced
with your script with just "-threads 32" without such a system? How
ofter does it manifest?

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 2/7] decode: add a method for attaching lavc-internal data to frames

[Thilo Borgmann]

Am 17.10.17 um 06:49 schrieb wm4:
> I have realized that your veto is actually not valid:
> - it's a Libav merge
> - it has been for months in the Libav repo and you didn't specifically
>   care, nor did you make an attempt to merge the commit in a "fixed" way
> - this patch would have been merged normally, and you wouldn't have
>   cared at all about it
> 
> So unless you intend to make a better, working proposal, I will _not_
> allow you to make this "my" problem. I will psuh this in 3 hours. After
> that, you're free to to reimplement this in a different way or whatever
> as a merge cleanup.

Can you please stop this and just find a reasonable way to find consensus on 
the issues you're facing?

Is it really of such importance that you want to push this although there are 
still concerns about what you want to do? Is this at all in any way relevant 
for security so that time would be at all a factor? I don't see any of your 
arguments mentioned above to be a valid reason to overrule someone else's 
opinion.

And no, I do not have the slightest clue about what you folks are discussing 
about but this should not even matter - I just criticize the way you are going 
to take here...

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

Re: [FFmpeg-devel] [PATCH] avcodec/v4l2: fix access to priv_data after codec close.

[wm4]

On Tue, 17 Oct 2017 19:20:50 +0200
Jorge Ramirez-Ortiz  wrote:

> A user can close the codec while keeping references to some of the
> capture buffers. When the codec is closed, the structure that keeps
> the contexts, state and the driver file descriptor is freed.
> 
> Since access to some of the elements in that structure is required to
> properly release the memory during the buffer unref callbacks, the
> following commit makes sure the unref callback accesses valid memory.
> 
> This commit was tested with valgrind:
> 
> $ valgrind ffmpeg_g -report -threads 1 -v 55  -y -c:v h264_v4l2m2m \
>   -i video.h264 -an -frames:v 100 -f null -
> ---
>  libavcodec/v4l2_buffers.c | 17 -
>  libavcodec/v4l2_buffers.h |  6 ++
>  libavcodec/v4l2_m2m.c | 29 -
>  libavcodec/v4l2_m2m_dec.c |  2 +-
>  4 files changed, 47 insertions(+), 7 deletions(-)
> 
> diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
> index ba70c5d..80e65ca 100644
> --- a/libavcodec/v4l2_buffers.c
> +++ b/libavcodec/v4l2_buffers.c
> @@ -205,9 +205,24 @@ static enum AVColorTransferCharacteristic 
> v4l2_get_color_trc(V4L2Buffer *buf)
>  static void v4l2_free_buffer(void *opaque, uint8_t *unused)
>  {
>  V4L2Buffer* avbuf = opaque;
> -V4L2m2mContext *s = buf_to_m2mctx(avbuf);
> +V4L2m2mContext *s = avbuf->m2m ? avbuf->m2m : buf_to_m2mctx(avbuf);
>  
>  atomic_fetch_sub_explicit(&s->refcount, 1, memory_order_acq_rel);
> +
> +if (avbuf->m2m) {
> +if (!atomic_load(&s->refcount)) {
> +/* unmmap and free the associated buffers */
> +ff_v4l2_context_release(&s->capture);
> +
> +/* close the v4l2 driver */
> +close(s->fd);
> +
> +/* release the duplicated m2m context */
> +av_freep(&s);
> +}
> +return;
> +}
> +
>  if (s->reinit) {
>  if (!atomic_load(&s->refcount))
>  sem_post(&s->refsync);
> diff --git a/libavcodec/v4l2_buffers.h b/libavcodec/v4l2_buffers.h
> index e28a4a6..d774480 100644
> --- a/libavcodec/v4l2_buffers.h
> +++ b/libavcodec/v4l2_buffers.h
> @@ -41,6 +41,12 @@ typedef struct V4L2Buffer {
>  /* each buffer needs to have a reference to its context */
>  struct V4L2Context *context;
>  
> +/* when the codec is closed while the user has buffer references we
> + * still need access to context data (this is a pointer to a duplicated
> + * m2m context created during the codec close function).
> + */
> +struct V4L2m2mContext *m2m;
> +
>  /* keep track of the mmap address and mmap length */
>  struct V4L2Plane_info {
>  int bytesperline;
> diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
> index 1d7a852..91b1bbb 100644
> --- a/libavcodec/v4l2_m2m.c
> +++ b/libavcodec/v4l2_m2m.c
> @@ -313,8 +313,8 @@ error:
>  
>  int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
>  {
> -V4L2m2mContext* s = avctx->priv_data;
> -int ret;
> +V4L2m2mContext *m2m, *s = avctx->priv_data;
> +int i, ret;
>  
>  ret = ff_v4l2_context_set_status(&s->output, VIDIOC_STREAMOFF);
>  if (ret)
> @@ -325,12 +325,31 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
>  av_log(avctx, AV_LOG_ERROR, "VIDIOC_STREAMOFF %s\n", 
> s->capture.name);
>  
>  ff_v4l2_context_release(&s->output);
> +sem_destroy(&s->refsync);
>  
> -if (atomic_load(&s->refcount))
> -av_log(avctx, AV_LOG_ERROR, "ff_v4l2m2m_codec_end leaving pending 
> buffers\n");
> +if (atomic_load(&s->refcount)) {
> +av_log(avctx, AV_LOG_DEBUG, "ff_v4l2m2m_codec_end, referenced 
> buffers %d\n", atomic_load(&s->refcount));
> +
> +/* We are about to free the private data while the user still has 
> references to the buffers.
> + * This means that when the user releases those buffers, the 
> v4l2_free_buffer callback will be pointing to free'd memory.
> + * Duplicate the m2m context and update the buffers.
> + */
> +m2m = av_mallocz(sizeof(*m2m));
> +if (m2m) {
> +memcpy(m2m, s, sizeof(V4L2m2mContext));
> +for (i = 0; i < s->capture.num_buffers; i++)
> +s->capture.buffers[i].m2m = m2m;
> +
> +return 0;
> +}
> +
> +/* on ENOMEM let's at least close the v4l2 driver and release the 
> capture memory
> + * so the driver is left in a healthy state.
> + */
> +av_log(avctx, AV_LOG_ERROR, "ff_v4l2m2m_codec_end, referenced 
> buffers not accessible\n");
> +}
>  

This is getting pretty messy. The better way to handle this would be
moving all state into a separate struct, and refcounting it with
AVBufferRefs. No more atomics, no more semaphores, no more blowing up
on OOM.

(Actually the hwcontext stuff (AVHWFramesContext etc.) provides an
infrastructure for this, and all hwaccels use it to avoid such issues.)

Anyway, not blocking this patch...

>  ff_v4l2_context_release(&

Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

[wm4]

On Tue, 17 Oct 2017 20:23:25 +0200
Thilo Borgmann  wrote:

> Am 17.10.17 um 06:49 schrieb wm4:
> > I have realized that your veto is actually not valid:
> > - it's a Libav merge
> > - it has been for months in the Libav repo and you didn't specifically
> >   care, nor did you make an attempt to merge the commit in a "fixed" way
> > - this patch would have been merged normally, and you wouldn't have
> >   cared at all about it
> > 
> > So unless you intend to make a better, working proposal, I will _not_
> > allow you to make this "my" problem. I will psuh this in 3 hours. After
> > that, you're free to to reimplement this in a different way or whatever
> > as a merge cleanup.  
> 
> Can you please stop this and just find a reasonable way to find consensus on 
> the issues you're facing?
> 
> Is it really of such importance that you want to push this although there are 
> still concerns about what you want to do? Is this at all in any way relevant 
> for security so that time would be at all a factor? I don't see any of your 
> arguments mentioned above to be a valid reason to overrule someone else's 
> opinion.

I don't want trivial things getting blocked by pure bullshit that's
probably politically and not technically motivated.

The best part about this dumb shit is that I could probably send
patches for cuvid/videotoolbox that use dumb workarounds (i.e. uglier
and shittier hacks) than the discussed patch, and NOBODY WOULD FUCKING
CARE.

I'm pretty fed up with this shit.

Please keep out of this discussion if you can't contribute anything too.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

[Thilo Borgmann]

Am 17.10.17 um 20:27 schrieb wm4:
> On Tue, 17 Oct 2017 20:23:25 +0200
> Thilo Borgmann  wrote:
> 
>> Am 17.10.17 um 06:49 schrieb wm4:
>>> I have realized that your veto is actually not valid:
>>> - it's a Libav merge
>>> - it has been for months in the Libav repo and you didn't specifically
>>>   care, nor did you make an attempt to merge the commit in a "fixed" way
>>> - this patch would have been merged normally, and you wouldn't have
>>>   cared at all about it
>>>
>>> So unless you intend to make a better, working proposal, I will _not_
>>> allow you to make this "my" problem. I will psuh this in 3 hours. After
>>> that, you're free to to reimplement this in a different way or whatever
>>> as a merge cleanup.  
>>
>> Can you please stop this and just find a reasonable way to find consensus on 
>> the issues you're facing?
>>
>> Is it really of such importance that you want to push this although there 
>> are still concerns about what you want to do? Is this at all in any way 
>> relevant for security so that time would be at all a factor? I don't see any 
>> of your arguments mentioned above to be a valid reason to overrule someone 
>> else's opinion.
> 
> I don't want trivial things getting blocked by pure bullshit that's
> probably politically and not technically motivated.
> 
> The best part about this dumb shit is that I could probably send
> patches for cuvid/videotoolbox that use dumb workarounds (i.e. uglier
> and shittier hacks) than the discussed patch, and NOBODY WOULD FUCKING
> CARE.
> 
> I'm pretty fed up with this shit.
> 
> Please keep out of this discussion if you can't contribute anything too.

I do care because I am delaying my work on some other cuvid related thing 
because of this.

I would prefer not to dive into this topic any further because it seems rather 
"not so important" to my task. And just another cook in the kitchen would also 
more likely avoid conensus here.

All I ask for is for you to find a reasonable to argue about your issues.

I hope you see my point why I am raising my voice. Thanks!

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

Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

[Thilo Borgmann]

Am 17.10.17 um 20:37 schrieb Thilo Borgmann:
> Am 17.10.17 um 20:27 schrieb wm4:
>> On Tue, 17 Oct 2017 20:23:25 +0200
>> Thilo Borgmann  wrote:
>>
>>> Am 17.10.17 um 06:49 schrieb wm4:
 I have realized that your veto is actually not valid:
 - it's a Libav merge
 - it has been for months in the Libav repo and you didn't specifically
   care, nor did you make an attempt to merge the commit in a "fixed" way
 - this patch would have been merged normally, and you wouldn't have
   cared at all about it

 So unless you intend to make a better, working proposal, I will _not_
 allow you to make this "my" problem. I will psuh this in 3 hours. After
 that, you're free to to reimplement this in a different way or whatever
 as a merge cleanup.  
>>>
>>> Can you please stop this and just find a reasonable way to find consensus 
>>> on the issues you're facing?
>>>
>>> Is it really of such importance that you want to push this although there 
>>> are still concerns about what you want to do? Is this at all in any way 
>>> relevant for security so that time would be at all a factor? I don't see 
>>> any of your arguments mentioned above to be a valid reason to overrule 
>>> someone else's opinion.
>>
>> I don't want trivial things getting blocked by pure bullshit that's
>> probably politically and not technically motivated.
>>
>> The best part about this dumb shit is that I could probably send
>> patches for cuvid/videotoolbox that use dumb workarounds (i.e. uglier
>> and shittier hacks) than the discussed patch, and NOBODY WOULD FUCKING
>> CARE.
>>
>> I'm pretty fed up with this shit.
>>
>> Please keep out of this discussion if you can't contribute anything too.
> 
> I do care because I am delaying my work on some other cuvid related thing 
> because of this.
> 
> I would prefer not to dive into this topic any further because it seems 
> rather "not so important" to my task. And just another cook in the kitchen 
> would also more likely avoid conensus here.
> 
> All I ask for is for you to find a reasonable to argue about your issues.
   ^
  way


> I hope you see my point why I am raising my voice. Thanks!
> 
> -Thilo

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

Re: [FFmpeg-devel] [PATCH] avcodec/v4l2: fix access to priv_data after codec close.

[Jorge Ramirez]

On 10/17/2017 08:25 PM, wm4 wrote:

On Tue, 17 Oct 2017 19:20:50 +0200
Jorge Ramirez-Ortiz  wrote:


A user can close the codec while keeping references to some of the
capture buffers. When the codec is closed, the structure that keeps
the contexts, state and the driver file descriptor is freed.

Since access to some of the elements in that structure is required to
properly release the memory during the buffer unref callbacks, the
following commit makes sure the unref callback accesses valid memory.

This commit was tested with valgrind:

$ valgrind ffmpeg_g -report -threads 1 -v 55  -y -c:v h264_v4l2m2m \
   -i video.h264 -an -frames:v 100 -f null -
---
  libavcodec/v4l2_buffers.c | 17 -
  libavcodec/v4l2_buffers.h |  6 ++
  libavcodec/v4l2_m2m.c | 29 -
  libavcodec/v4l2_m2m_dec.c |  2 +-
  4 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index ba70c5d..80e65ca 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -205,9 +205,24 @@ static enum AVColorTransferCharacteristic 
v4l2_get_color_trc(V4L2Buffer *buf)
  static void v4l2_free_buffer(void *opaque, uint8_t *unused)
  {
  V4L2Buffer* avbuf = opaque;
-V4L2m2mContext *s = buf_to_m2mctx(avbuf);
+V4L2m2mContext *s = avbuf->m2m ? avbuf->m2m : buf_to_m2mctx(avbuf);
  
  atomic_fetch_sub_explicit(&s->refcount, 1, memory_order_acq_rel);

+
+if (avbuf->m2m) {
+if (!atomic_load(&s->refcount)) {
+/* unmmap and free the associated buffers */
+ff_v4l2_context_release(&s->capture);
+
+/* close the v4l2 driver */
+close(s->fd);
+
+/* release the duplicated m2m context */
+av_freep(&s);
+}
+return;
+}
+
  if (s->reinit) {
  if (!atomic_load(&s->refcount))
  sem_post(&s->refsync);
diff --git a/libavcodec/v4l2_buffers.h b/libavcodec/v4l2_buffers.h
index e28a4a6..d774480 100644
--- a/libavcodec/v4l2_buffers.h
+++ b/libavcodec/v4l2_buffers.h
@@ -41,6 +41,12 @@ typedef struct V4L2Buffer {
  /* each buffer needs to have a reference to its context */
  struct V4L2Context *context;
  
+/* when the codec is closed while the user has buffer references we

+ * still need access to context data (this is a pointer to a duplicated
+ * m2m context created during the codec close function).
+ */
+struct V4L2m2mContext *m2m;
+
  /* keep track of the mmap address and mmap length */
  struct V4L2Plane_info {
  int bytesperline;
diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
index 1d7a852..91b1bbb 100644
--- a/libavcodec/v4l2_m2m.c
+++ b/libavcodec/v4l2_m2m.c
@@ -313,8 +313,8 @@ error:
  
  int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)

  {
-V4L2m2mContext* s = avctx->priv_data;
-int ret;
+V4L2m2mContext *m2m, *s = avctx->priv_data;
+int i, ret;
  
  ret = ff_v4l2_context_set_status(&s->output, VIDIOC_STREAMOFF);

  if (ret)
@@ -325,12 +325,31 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
  av_log(avctx, AV_LOG_ERROR, "VIDIOC_STREAMOFF %s\n", s->capture.name);
  
  ff_v4l2_context_release(&s->output);

+sem_destroy(&s->refsync);
  
-if (atomic_load(&s->refcount))

-av_log(avctx, AV_LOG_ERROR, "ff_v4l2m2m_codec_end leaving pending 
buffers\n");
+if (atomic_load(&s->refcount)) {
+av_log(avctx, AV_LOG_DEBUG, "ff_v4l2m2m_codec_end, referenced buffers %d\n", 
atomic_load(&s->refcount));
+
+/* We are about to free the private data while the user still has 
references to the buffers.
+ * This means that when the user releases those buffers, the 
v4l2_free_buffer callback will be pointing to free'd memory.
+ * Duplicate the m2m context and update the buffers.
+ */
+m2m = av_mallocz(sizeof(*m2m));
+if (m2m) {
+memcpy(m2m, s, sizeof(V4L2m2mContext));
+for (i = 0; i < s->capture.num_buffers; i++)
+s->capture.buffers[i].m2m = m2m;
+
+return 0;
+}
+
+/* on ENOMEM let's at least close the v4l2 driver and release the 
capture memory
+ * so the driver is left in a healthy state.
+ */
+av_log(avctx, AV_LOG_ERROR, "ff_v4l2m2m_codec_end, referenced buffers not 
accessible\n");
+}
  

This is getting pretty messy. The better way to handle this would be
moving all state into a separate struct, and refcounting it with
AVBufferRefs. No more atomics, no more semaphores, no more blowing up
on OOM.


I am still trying to figure out how to do this - it is not straight 
forward but I'll get to it.




(Actually the hwcontext stuff (AVHWFramesContext etc.) provides an
infrastructure for this, and all hwaccels use it to avoid such issues.)


yes I plan to move all this to take advantage of the drm stuff that 
comes with the HWFrames.
Just wanted to fix the SIGSEGV asap

Re: [FFmpeg-devel] [PATCH 2/7] decode: add a method for attaching lavc-internal data to frames

[Timo Rothenpieler]

Am 17.10.2017 um 20:37 schrieb Thilo Borgmann:

Am 17.10.17 um 20:27 schrieb wm4:

On Tue, 17 Oct 2017 20:23:25 +0200
Thilo Borgmann  wrote:


Am 17.10.17 um 06:49 schrieb wm4:

I have realized that your veto is actually not valid:
- it's a Libav merge
- it has been for months in the Libav repo and you didn't specifically
   care, nor did you make an attempt to merge the commit in a "fixed" way
- this patch would have been merged normally, and you wouldn't have
   cared at all about it

So unless you intend to make a better, working proposal, I will _not_
allow you to make this "my" problem. I will psuh this in 3 hours. After
that, you're free to to reimplement this in a different way or whatever
as a merge cleanup.


Can you please stop this and just find a reasonable way to find consensus on 
the issues you're facing?

Is it really of such importance that you want to push this although there are 
still concerns about what you want to do? Is this at all in any way relevant 
for security so that time would be at all a factor? I don't see any of your 
arguments mentioned above to be a valid reason to overrule someone else's 
opinion.


I don't want trivial things getting blocked by pure bullshit that's
probably politically and not technically motivated.

The best part about this dumb shit is that I could probably send
patches for cuvid/videotoolbox that use dumb workarounds (i.e. uglier
and shittier hacks) than the discussed patch, and NOBODY WOULD FUCKING
CARE.

I'm pretty fed up with this shit.

Please keep out of this discussion if you can't contribute anything too.


I do care because I am delaying my work on some other cuvid related thing 
because of this.

I would prefer not to dive into this topic any further because it seems rather "not 
so important" to my task. And just another cook in the kitchen would also more 
likely avoid conensus here.

All I ask for is for you to find a reasonable to argue about your issues.

I hope you see my point why I am raising my voice. Thanks!

-Thilo
I second this. The exact way this is implemented is entirely 
unimportant. But this pointless fighting leads nowhere.
While I agree that this patch is technically correct and does not 
violate API in any way, I also kind of dislike using opaque_ref for 
this, and would welcome coming up with a nicer solution, that's ideally 
compatible with libavs approach without too much work on every patch 
that touches it.




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

Re: [FFmpeg-devel] decklink 24/32 bit question

[Moritz Barsnick]

Hi Doug,

On Tue, Oct 03, 2017 at 20:39:49 -0700, Douglas Marsh wrote:
> After digging around in places, made the following changes:
[...]
> It doesn't work (the audio capture is close but wrong), but believe it 
> is a step in the correct direction. Anybody have a clue? Saw several 
> names in cpp,c,h files including: Ramiro Polla, Luca Barbato, Deti 
> Fliegl, Rafaël Carré and Akamai Technologies Inc.

Did you check out Dave Rice's recent patch (on this list)? It touches
code in a few more places, and adds an option to select 16 vs. 32 bits.
Please test, if you can.

Is your subject indicating that 24 bits depth could also be supported?
If so, Dave perhaps should expand his patch to cover that.

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

Re: [FFmpeg-devel] decklink 24/32 bit question

[Dave Rice]

> On Oct 17, 2017, at 2:59 PM, Moritz Barsnick  wrote:
> 
> Hi Doug,
> 
> On Tue, Oct 03, 2017 at 20:39:49 -0700, Douglas Marsh wrote:
>> After digging around in places, made the following changes:
> [...]
>> It doesn't work (the audio capture is close but wrong), but believe it 
>> is a step in the correct direction. Anybody have a clue? Saw several 
>> names in cpp,c,h files including: Ramiro Polla, Luca Barbato, Deti 
>> Fliegl, Rafaël Carré and Akamai Technologies Inc.
> 
> Did you check out Dave Rice's recent patch (on this list)? It touches
> code in a few more places, and adds an option to select 16 vs. 32 bits.
> Please test, if you can.
> 
> Is your subject indicating that 24 bits depth could also be supported?
> If so, Dave perhaps should expand his patch to cover that.

The decklink sdk only defines two BMDAudioSampleType values: 
bmdAudioSampleType16bitInteger and bmdAudioSampleType32bitInteger. I don't 
think there's an easy way to support a 24 bit input here. Generally in this 
case I've used bmdAudioSampleType32bitInteger and then encode it at pcm_s24le.
Dave Rice

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

Re: [FFmpeg-devel] decklink 24/32 bit question

[Douglas Marsh]

On 2017-10-17 11:59, Moritz Barsnick wrote:


Did you check out Dave Rice's recent patch (on this list)? It touches
code in a few more places, and adds an option to select 16 vs. 32 bits.
Please test, if you can.

Is your subject indicating that 24 bits depth could also be supported?
If so, Dave perhaps should expand his patch to cover that.



I did see it!

Been busy, trying to get a video project done and under the belt before 
I start tinkering with dependent things. I *WILL* report back my 
experiences (positive or negative). I was hacking the source before that 
patch and see the two areas that I missed. But his patch added command 
line parameters for selecting (which I prefer). Was going to try it out 
and change the default to 32-bit as well.


I am guessing that some capture hardware may not support higher than 16 
bit depths? If all support higher depths, then why should the default 
not be higher and then let FFMPEG convert the input stream to the 
correct output stream (it might be 16 bits)? Is truncating CPU 
intensive? Dithering be applied? What does the DAC do in hardware when 
outputting 16-bits (truncate or dither)?


Also from what I understand word/sample size is 32-bits but the DAC is 
24 (assuming 8-bits are padded) -- hence why I said 24/32. I only see in 
the SDK 16-bits and 32-bits, but know the documentation for the card I 
have (Studio 4K) states 24-bits. Do others have cards that state 
anything additional over 16 and 32?


--Doug (dx9s)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support

[Douglas Marsh]

On 2017-10-17 06:22, Dave Rice wrote:


I don't see there to be an AV_OPT_TYPE_ENUM. Could you point out how
this works from an example? Alternatively since the decklink sdk only
supports 2 bit depths (16 and 32), I could use a boolean here if that
makes more sense.
Dave Rice



I am unsure about the AV_OPT_TYPE_ENUM as well so can't answer that. I 
would not use a boolean, even tho the audio word/sample sizes will 
probably never change from those two offerings. As stated in previous 
recent message/thread, from what I know about my card, it only has a 
24-bit ADC/DAC for audio and the 16-bit modes are either truncated or 
dithered in hardware or drivers. They might come out with higher end 
hardware that captures 32-bits PCM at some later date, they will have an 
additional defined constant which would require converting the boolean 
back into an int what your patch currently has (int I believe it was).


I will try the patch out when I can as it is something I want for two 
reasons (higher quality and see if it solves an audio glitch that 
occasionally pops up during capture, difficult to reproduce -- happens 
with their reference capture software under Linux as well so think it is 
hardware issue with HDMI splitter I have).


--Doug (dx9s)


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

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support

[Douglas Marsh]

On 2017-10-17 09:10, Dave Rice wrote:



 -audio_depth   .D.. audio bitdepth (from 0 to 
1)

(default 16bits)
16bits   .D..




Hmm, first patch might be enough.


Sounds good to me. Unless anyone prefers "-audio_depth thirtytwo" :-D
Dave Rice



Yeah that works.. so if they have any other depths, can go 0, 1 or 2 
(2=some new bit depth yet to be created)


And for clarification: yes 32-bits (PCM_S32LE) -- I was just pointing 
out the ADC/DAC's are 24-bit (8-bits padded).


--Doug (dx9s)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat: not treat 0 as EOF

[Michael Niedermayer]

On Tue, Oct 17, 2017 at 10:29:30AM +0200, Daniel Kucera wrote:
> transfer_func variable passed to retry_transfer_wrapper
> are h->prot->url_read and h->prot->url_write functions.
> These need to return EOF or other error properly.
> In case of returning >= 0, url_read/url_write is retried
> until error is returned.
> 
> Signed-off-by: Daniel Kucera 
> ---
>  libavformat/avio.c|  6 --
>  libavformat/aviobuf.c | 20 
>  libavformat/cache.c   |  4 ++--
>  libavformat/concat.c  |  9 +
>  libavformat/http.c|  5 -
>  5 files changed, 27 insertions(+), 17 deletions(-)

Seems to work, no more comments from me

thanks


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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

Re: [FFmpeg-devel] decklink 24/32 bit question

[Devin Heitmueller]

> 
> The decklink sdk only defines two BMDAudioSampleType values: 
> bmdAudioSampleType16bitInteger and bmdAudioSampleType32bitInteger. I don't 
> think there's an easy way to support a 24 bit input here. Generally in this 
> case I've used bmdAudioSampleType32bitInteger and then encode it at pcm_s24le.
> Dave Rice

For what it’s worth, I’ve got deinterleaving code in the works to handle 
capture of multiple pairs of audio (i.e. break 16 channels into 8 pairs and 
announce them as separate S16LE streams).  If we really thought 24-bit was 
desirable, that code could be adjusted accordingly (the hardware would still 
capture 32-bit, but the deinterleaver would put out S24LE).

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

Re: [FFmpeg-devel] [PATCH 00/20] Coded bitstream editing (v4)

[Mark Thompson]

On 15/10/17 16:04, Mark Thompson wrote:
> Incorporating fixes since the last full set:
> * SEI user data added in the first access unit whether or not it contains 
> parameter sets.
> * Fix crash when closing uninitialised cbs instance.
> * Miscellaneous documentation changes.

And applied.

Thank you to everyone who commented on this series!  (On IRC, in person, and on 
both MLs.)

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/cafenc: Allow muxing opus.

[James Almer]

> ffmpeg | branch: master | Carl Eugen Hoyos  > | Tue Oct 17 21:35:28 
> 2017 +0200| [a3accd0c3768933f15422c9dec596da0f436d786] | committer: Carl 
> Eugen Hoyos
>
> lavf/cafenc: Allow muxing opus.
>
> QuickTime does not require the (unknown) kuki chunk for decoding.

This at the very least requires limiting muxing to mono and stereo
streams (The only kind of streams that work without channel mapping
information in extradata), and a check for -strict experimental.

Also, I'd have rather waited for Apple to update their docs about Opus
in CAF. Quicktime seemingly playing such files isn't reason enough to
risk creating potentially non-spec compliant files.

>
> >/http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=a3accd0c3768933f15422c9dec596da0f436d786
> /---
>
>  libavformat/cafenc.c  | 3 ++-
>  libavformat/version.h | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/cafenc.c b/libavformat/cafenc.c
> index f550cd965a..211b046563 100644
> --- a/libavformat/cafenc.c
> +++ b/libavformat/cafenc.c
> @@ -81,6 +81,8 @@ static uint32_t samples_per_packet(enum AVCodecID codec_id, 
> int channels, int bl
>  return 320;
>  case AV_CODEC_ID_MP1:
>  return 384;
> +case AV_CODEC_ID_OPUS:
> +return 960;
>  case AV_CODEC_ID_MP2:
>  case AV_CODEC_ID_MP3:
>  return 1152;
> @@ -117,7 +119,6 @@ static int caf_write_header(AVFormatContext *s)
>  
>  switch (par->codec_id) {
>  case AV_CODEC_ID_AAC:
> -case AV_CODEC_ID_OPUS:
>  av_log(s, AV_LOG_ERROR, "muxing codec currently unsupported\n");
>  return AVERROR_PATCHWELCOME;
>  }
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 828be14b20..22f82a37f7 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -33,7 +33,7 @@
>  // Also please add any ticket numbers that you believe might be affected here
>  #define LIBAVFORMAT_VERSION_MAJOR  57
>  #define LIBAVFORMAT_VERSION_MINOR  84
> -#define LIBAVFORMAT_VERSION_MICRO 100
> +#define LIBAVFORMAT_VERSION_MICRO 101
>  
>  #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> LIBAVFORMAT_VERSION_MINOR, \

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

[FFmpeg-devel] [PATCH 3/9] gif: Add missing error check

[Mark Thompson]

---
 libavformat/gif.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavformat/gif.c b/libavformat/gif.c
index 01d98a27b0..3336152c06 100644
--- a/libavformat/gif.c
+++ b/libavformat/gif.c
@@ -174,8 +174,12 @@ static int flush_packet(AVFormatContext *s, AVPacket *new)
 avio_write(pb, pkt->data, pkt->size);
 
 av_packet_unref(gif->prev_pkt);
-if (new)
-av_packet_ref(gif->prev_pkt, new);
+if (new) {
+int ret;
+ret = av_packet_ref(gif->prev_pkt, new);
+if (ret < 0)
+return ret;
+}
 
 return 0;
 }
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 5/9] wtvenc: Add missing error check

[Mark Thompson]

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

diff --git a/libavformat/wtvenc.c b/libavformat/wtvenc.c
index 4a68b8133f..d4a08dda61 100644
--- a/libavformat/wtvenc.c
+++ b/libavformat/wtvenc.c
@@ -462,12 +462,15 @@ static int write_packet(AVFormatContext *s, AVPacket *pkt)
 AVIOContext *pb = s->pb;
 WtvContext  *wctx = s->priv_data;
 AVStream*st   = s->streams[pkt->stream_index];
+int ret;
 
 if (st->codecpar->codec_id == AV_CODEC_ID_MJPEG && !wctx->thumbnail.size) {
-av_packet_ref(&wctx->thumbnail, pkt);
+ret = av_packet_ref(&wctx->thumbnail, pkt);
+if (ret < 0)
+return ret;
 return 0;
 } else if (st->codecpar->codec_id == AV_CODEC_ID_H264) {
-int ret = ff_check_h264_startcode(s, st, pkt);
+ret = ff_check_h264_startcode(s, st, pkt);
 if (ret < 0)
 return ret;
 }
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 6/9] opusenc: Fix double-declaration of variable

[Mark Thompson]

---
 libavcodec/opusenc_psy.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/opusenc_psy.c b/libavcodec/opusenc_psy.c
index b446d41f75..1b108ecb87 100644
--- a/libavcodec/opusenc_psy.c
+++ b/libavcodec/opusenc_psy.c
@@ -370,7 +370,6 @@ static int celt_search_for_tf(OpusPsyContext *s, 
OpusPsyStep **start, CeltFrame
 for (cway = 0; cway < 2; cway++) {
 int mag[2];
 int base = f->transient ? 120 : 960;
-int i;
 
 for (i = 0; i < 2; i++) {
 int c = ff_celt_tf_select[f->size][f->transient][cway][i];
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 7/9] hevc: Fix aligned array declarations

[Mark Thompson]

(cherry picked from commit d41e10c1485ec34aa342f7bc2e5bf4f9b6e66414)
---
This and the following patches were found with the TI ARM compiler.


 libavcodec/hevcdsp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/hevcdsp.c b/libavcodec/hevcdsp.c
index 76ae72b6d4..e432aa3cf9 100644
--- a/libavcodec/hevcdsp.c
+++ b/libavcodec/hevcdsp.c
@@ -91,7 +91,7 @@ static const int8_t transform[32][32] = {
   90, -90,  88, -85,  82, -78,  73, -67,  61, -54,  46, -38,  31, -22,  
13,  -4 },
 };
 
-DECLARE_ALIGNED(16, const int8_t, ff_hevc_epel_filters[7][4]) = {
+DECLARE_ALIGNED(16, const int8_t, ff_hevc_epel_filters)[7][4] = {
 { -2, 58, 10, -2},
 { -4, 54, 16, -2},
 { -6, 46, 28, -4},
@@ -101,7 +101,7 @@ DECLARE_ALIGNED(16, const int8_t, 
ff_hevc_epel_filters[7][4]) = {
 { -2, 10, 58, -2},
 };
 
-DECLARE_ALIGNED(16, const int8_t, ff_hevc_qpel_filters[3][16]) = {
+DECLARE_ALIGNED(16, const int8_t, ff_hevc_qpel_filters)[3][16] = {
 { -1,  4,-10, 58, 17, -5,  1,  0, -1,  4,-10, 58, 17, -5,  1,  0},
 { -1,  4,-11, 40, 40,-11,  4, -1, -1,  4,-11, 40, 40,-11,  4, -1},
 {  0,  1, -5, 17, 58,-10,  4, -1,  0,  1, -5, 17, 58,-10,  4, -1}
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 2/9] apngenc: Add missing error check

[Mark Thompson]

---
 libavformat/apngenc.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavformat/apngenc.c b/libavformat/apngenc.c
index 77c1c916c2..16ead54cc8 100644
--- a/libavformat/apngenc.c
+++ b/libavformat/apngenc.c
@@ -217,8 +217,12 @@ static int flush_packet(AVFormatContext *format_context, 
AVPacket *packet)
 ++apng->frame_number;
 
 av_packet_unref(apng->prev_packet);
-if (packet)
-av_packet_ref(apng->prev_packet, packet);
+if (packet) {
+int ret;
+ret = av_packet_ref(apng->prev_packet, packet);
+if (ret < 0)
+return ret;
+}
 return 0;
 }
 
@@ -232,7 +236,9 @@ static int apng_write_packet(AVFormatContext 
*format_context, AVPacket *packet)
 if (!apng->prev_packet)
 return AVERROR(ENOMEM);
 
-av_packet_ref(apng->prev_packet, packet);
+ret = av_packet_ref(apng->prev_packet, packet);
+if (ret < 0)
+return ret;
 } else {
 ret = flush_packet(format_context, packet);
 if (ret < 0)
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 8/9] cinepakenc: Move declaration out of for initialisation statement

[Mark Thompson]

(cherry picked from commit 92f0aceb36c6e4412d4cf346e70dc74b5a4069e9)
---
 libavcodec/cinepakenc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/cinepakenc.c b/libavcodec/cinepakenc.c
index a28f669070..330c8827d1 100644
--- a/libavcodec/cinepakenc.c
+++ b/libavcodec/cinepakenc.c
@@ -994,8 +994,9 @@ static int rd_strip(CinepakEncContext *s, int y, int h, int 
keyframe,
 #define SMALLEST_CODEBOOK 1
 for(v1enough = 0, v1_size = SMALLEST_CODEBOOK; v1_size <= CODEBOOK_MAX && 
!v1enough; v1_size <<= 2) {
 for(v4enough = 0, v4_size = 0; v4_size <= v1_size && !v4enough; 
v4_size = v4_size ? v4_size << 2 : v1_size >= SMALLEST_CODEBOOK << 2 ? v1_size 
>> 2 : SMALLEST_CODEBOOK) {
+CinepakMode mode;
 //try all modes
-for(CinepakMode mode = 0; mode < MODE_COUNT; mode++) {
+for(mode = 0; mode < MODE_COUNT; mode++) {
 //don't allow MODE_MC in intra frames
 if(keyframe && mode == MODE_MC)
 continue;
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 9/9] movtextdec: Move declaration out of for initialisation statement

[Mark Thompson]

---
 libavcodec/movtextdec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/movtextdec.c b/libavcodec/movtextdec.c
index fb5085c3e8..bd19577724 100644
--- a/libavcodec/movtextdec.c
+++ b/libavcodec/movtextdec.c
@@ -436,6 +436,7 @@ static int mov_text_decode_frame(AVCodecContext *avctx,
 int text_length, tsmb_type, ret_tsmb;
 uint64_t tsmb_size;
 const uint8_t *tsmb;
+size_t i;
 
 if (!ptr || avpkt->size < 2)
 return AVERROR_INVALIDDATA;
@@ -495,7 +496,7 @@ static int mov_text_decode_frame(AVCodecContext *avctx,
 if (tsmb_size > avpkt->size - m->tracksize)
 break;
 
-for (size_t i = 0; i < box_count; i++) {
+for (i = 0; i < box_count; i++) {
 if (tsmb_type == box_types[i].type) {
 if (m->tracksize + m->size_var + box_types[i].base_size > 
avpkt->size)
 break;
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 1/9] lavc: Mark functions where ignoring returned error code is always wrong

[Mark Thompson]

---
 libavcodec/avcodec.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 18c3e3ea1e..8fc2f6920e 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -4492,6 +4492,7 @@ int avcodec_parameters_to_context(AVCodecContext *codec,
  * @see avcodec_alloc_context3(), avcodec_find_decoder(), 
avcodec_find_encoder(),
  *  av_dict_set(), av_opt_find().
  */
+av_warn_unused_result
 int avcodec_open2(AVCodecContext *avctx, const AVCodec *codec, AVDictionary 
**options);
 
 /**
@@ -4577,6 +4578,7 @@ void av_init_packet(AVPacket *pkt);
  * @param size wanted payload size
  * @return 0 if OK, AVERROR_xxx otherwise
  */
+av_warn_unused_result
 int av_new_packet(AVPacket *pkt, int size);
 
 /**
@@ -4593,6 +4595,7 @@ void av_shrink_packet(AVPacket *pkt, int size);
  * @param pkt packet
  * @param grow_by number of bytes by which to increase the size of the packet
  */
+av_warn_unused_result
 int av_grow_packet(AVPacket *pkt, int grow_by);
 
 /**
@@ -4751,6 +4754,7 @@ void av_packet_free_side_data(AVPacket *pkt);
  *
  * @return 0 on success, a negative AVERROR on error.
  */
+av_warn_unused_result
 int av_packet_ref(AVPacket *dst, const AVPacket *src);
 
 /**
@@ -4829,6 +4833,7 @@ AVCodec *avcodec_find_decoder_by_name(const char *name);
  * it can be called by custom get_buffer2() implementations for decoders 
without
  * AV_CODEC_CAP_DR1 set.
  */
+av_warn_unused_result
 int avcodec_default_get_buffer2(AVCodecContext *s, AVFrame *frame, int flags);
 
 #if FF_API_EMU_EDGE
@@ -5095,6 +5100,7 @@ int avcodec_send_packet(AVCodecContext *avctx, const 
AVPacket *avpkt);
  *  AVERROR(EINVAL):   codec not opened, or it is an encoder
  *  other negative values: legitimate decoding errors
  */
+av_warn_unused_result
 int avcodec_receive_frame(AVCodecContext *avctx, AVFrame *frame);
 
 /**
@@ -5149,6 +5155,7 @@ int avcodec_send_frame(AVCodecContext *avctx, const 
AVFrame *frame);
  *  AVERROR(EINVAL):   codec not opened, or it is an encoder
  *  other errors: legitimate decoding errors
  */
+av_warn_unused_result
 int avcodec_receive_packet(AVCodecContext *avctx, AVPacket *avpkt);
 
 
@@ -6106,12 +6113,14 @@ const AVBitStreamFilter *av_bsf_next(void **opaque);
  *
  * @return 0 on success, a negative AVERROR code on failure
  */
+av_warn_unused_result
 int av_bsf_alloc(const AVBitStreamFilter *filter, AVBSFContext **ctx);
 
 /**
  * Prepare the filter for use, after all the parameters and options have been
  * set.
  */
+av_warn_unused_result
 int av_bsf_init(AVBSFContext *ctx);
 
 /**
@@ -6155,6 +6164,7 @@ int av_bsf_send_packet(AVBSFContext *ctx, AVPacket *pkt);
  * output fewer packets than were sent to it, so this function may return
  * AVERROR(EAGAIN) immediately after a successful av_bsf_send_packet() call.
  */
+av_warn_unused_result
 int av_bsf_receive_packet(AVBSFContext *ctx, AVPacket *pkt);
 
 /**
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 4/9] webpenc: Add missing error check

[Mark Thompson]

---
 libavformat/webpenc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavformat/webpenc.c b/libavformat/webpenc.c
index 9fb472257d..d1ebb5fbe5 100644
--- a/libavformat/webpenc.c
+++ b/libavformat/webpenc.c
@@ -158,7 +158,9 @@ static int webp_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 int ret;
 if ((ret = flush(s, 0, pkt->pts)) < 0)
 return ret;
-av_packet_ref(&w->last_pkt, pkt);
+ret = av_packet_ref(&w->last_pkt, pkt);
+if (ret < 0)
+return ret;
 }
 ++w->frame_count;
 
-- 
2.11.0

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/cafenc: Allow muxing opus.

[Carl Eugen Hoyos]

2017-10-17 22:20 GMT+02:00 James Almer :
>> ffmpeg | branch: master | Carl Eugen Hoyos > > | Tue Oct 17 21:35:28 
>> 2017 +0200| [a3accd0c3768933f15422c9dec596da0f436d786] | committer: Carl 
>> Eugen Hoyos
>>
>> lavf/cafenc: Allow muxing opus.
>>
>> QuickTime does not require the (unknown) kuki chunk for decoding.
>
> This at the very least requires limiting muxing to mono and stereo
> streams (The only kind of streams that work without channel mapping
> information in extradata),

Done, thank you!

> and a check for -strict experimental.

Why?

> Also, I'd have rather waited for Apple to update their docs about Opus
> in CAF.

As in: Until Godot arrives?

Sorry, I don't think it makes much sense to wait for a
specification that to best of our knowledge may never
appear.

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

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

[Carl Eugen Hoyos]

2017-10-17 3:16 GMT+02:00 Carl Eugen Hoyos :
> 2017-10-10 23:41 GMT+02:00 Bjorn Roche :
>
>> +{ "trans_threshold", "set the threshold for alpha values avoce which 
>> they are considered completely opaque", OFFSET(trans_thresh), 
>> AV_OPT_TYPE_INT, {.i64=128}, 0, 255, },
>
> I wonder if "threshold" is enough.
>
> No more comments from me, thank you!

Remaining comment is:
The paletteuse filter does not work correctly on big-endian
(my guess is the code makes wrong assumptions about the
palette colour-space), I don't think this should delay this
patch though.

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

[FFmpeg-devel] [PATCH]lavfi/palettegen: Allow setting the background colour

[Carl Eugen Hoyos]

Hi!

Attached patch is useful in combination with the transparency patch
for paletteuse.

Please comment, Carl Eugen
From fc1c562748b2f7bb518df9feaa91482757ae9625 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Tue, 17 Oct 2017 23:39:59 +0200
Subject: [PATCH] lavfi/palettegen: Allow setting the background colour.

---
 libavfilter/vf_palettegen.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_palettegen.c b/libavfilter/vf_palettegen.c
index 03de317..0c74af6 100644
--- a/libavfilter/vf_palettegen.c
+++ b/libavfilter/vf_palettegen.c
@@ -27,6 +27,7 @@
 #include "libavutil/internal.h"
 #include "libavutil/opt.h"
 #include "libavutil/qsort.h"
+#include "libavutil/intreadwrite.h"
 #include "avfilter.h"
 #include "internal.h"
 
@@ -74,6 +75,7 @@ typedef struct PaletteGenContext {
 struct range_box boxes[256];// define the segmentation of the colorspace (the final palette)
 int nb_boxes;   // number of boxes (increase will segmenting them)
 int palette_pushed; // if the palette frame is pushed into the outlink or not
+uint32_t background;// background color for transparency
 } PaletteGenContext;
 
 #define OFFSET(x) offsetof(PaletteGenContext, x)
@@ -81,6 +83,7 @@ typedef struct PaletteGenContext {
 static const AVOption palettegen_options[] = {
 { "max_colors", "set the maximum number of colors to use in the palette", OFFSET(max_colors), AV_OPT_TYPE_INT, {.i64=256}, 4, 256, FLAGS },
 { "reserve_transparent", "reserve a palette entry for transparency", OFFSET(reserve_transparent), AV_OPT_TYPE_BOOL, {.i64=1}, 0, 1, FLAGS },
+{ "background", "set a background color for transparency", OFFSET(background), AV_OPT_TYPE_COLOR, {.str="white"}, CHAR_MIN, CHAR_MAX, FLAGS },
 { "stats_mode", "set statistics mode", OFFSET(stats_mode), AV_OPT_TYPE_INT, {.i64=STATS_MODE_ALL_FRAMES}, 0, NB_STATS_MODE-1, FLAGS, "mode" },
 { "full", "compute full frame histograms", 0, AV_OPT_TYPE_CONST, {.i64=STATS_MODE_ALL_FRAMES}, INT_MIN, INT_MAX, FLAGS, "mode" },
 { "diff", "compute histograms only for the part that differs from previous frame", 0, AV_OPT_TYPE_CONST, {.i64=STATS_MODE_DIFF_FRAMES}, INT_MIN, INT_MAX, FLAGS, "mode" },
@@ -250,7 +253,7 @@ static void write_palette(AVFilterContext *ctx, AVFrame *out)
 
 if (s->reserve_transparent) {
 av_assert0(s->nb_boxes < 256);
-pal[out->width - pal_linesize - 1] = 0xff00; // add a green transparent color
+pal[out->width - pal_linesize - 1] = AV_RB32(&s->background) >> 8;
 }
 }
 
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/cafenc: Allow muxing opus.

[James Almer]

On 10/17/2017 6:20 PM, Carl Eugen Hoyos wrote:
> 2017-10-17 22:20 GMT+02:00 James Almer :
>>> ffmpeg | branch: master | Carl Eugen Hoyos >> > | Tue Oct 17 21:35:28 
>>> 2017 +0200| [a3accd0c3768933f15422c9dec596da0f436d786] | committer: Carl 
>>> Eugen Hoyos
>>>
>>> lavf/cafenc: Allow muxing opus.
>>>
>>> QuickTime does not require the (unknown) kuki chunk for decoding.
>>
>> This at the very least requires limiting muxing to mono and stereo
>> streams (The only kind of streams that work without channel mapping
>> information in extradata),
> 
> Done, thank you!
> 
>> and a check for -strict experimental.
> 
> Why?

Because we're creating these files blindly, without a proper RE attempt
or following any kind of encapsulation spec. And considering the
official encoder/muxer adds a codec specific chunk we don't, the more
reason to consider a muxing as barebones as this as something
potentially non-compliant.

> 
>> Also, I'd have rather waited for Apple to update their docs about Opus
>> in CAF.
> 
> As in: Until Godot arrives?
> 
> Sorry, I don't think it makes much sense to wait for a
> specification that to best of our knowledge may never
> appear.

Apple published the spec for CAF, detailing encapsulation details for
the codecs it supports, including the contents of the kuki chunk for
most of them. It's to be expected that eventually they'll update it for
Opus.
While I'm not asking you to revert this addition, I'd prefer if you keep
the muxing code under the experimental check until we're 100% sure it's
correct, or until enough time has passed without the spec being updated.
See how VP9 in Mov was under such a check until the encapsulation spec
was frozen and made official.

PS: Maintainers lists Peter Ross as the CAF maintainer, but that seems
to refer to the demuxer seeing you're the author of the muxer. So
assuming you're maintaining it, could you list yourself there?

> 
> Thank you, Carl Eugen
> ___
> 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 1/7] vf_cover_rect: Fix repeated condition

[Mark Thompson]

Fixes #6741.
---
 libavfilter/vf_cover_rect.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_cover_rect.c b/libavfilter/vf_cover_rect.c
index f7f61038e3..41cd1a12b9 100644
--- a/libavfilter/vf_cover_rect.c
+++ b/libavfilter/vf_cover_rect.c
@@ -152,7 +152,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 }
 
 if (!xendptr || *xendptr || !yendptr || *yendptr ||
-!wendptr || *wendptr || !hendptr || !hendptr
+!wendptr || *wendptr || !hendptr || *hendptr
 ) {
 return ff_filter_frame(ctx->outputs[0], in);
 }
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 2/7] nutdec: Fix repeated condition

[Mark Thompson]

Fixes #6742.
---
 libavformat/nutdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
index 27440c88d4..9910ffe936 100644
--- a/libavformat/nutdec.c
+++ b/libavformat/nutdec.c
@@ -582,7 +582,7 @@ static int decode_info_header(NUTContext *nut)
 if (stream_id_plus1 && !strcmp(name, "r_frame_rate")) {
 sscanf(str_value, "%d/%d", &st->r_frame_rate.num, 
&st->r_frame_rate.den);
 if (st->r_frame_rate.num >= 1000LL*st->r_frame_rate.den ||
-st->r_frame_rate.num < 0 || st->r_frame_rate.num < 0)
+st->r_frame_rate.num < 0 || st->r_frame_rate.den < 0)
 st->r_frame_rate.num = st->r_frame_rate.den = 0;
 continue;
 }
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 3/7] vorbis: Reorder conditions to avoid possible overread

[Mark Thompson]

This can trigger a single-byte overread if the codebook has the maximum
number of entries.

Fixes #6743.
---
 libavcodec/vorbis.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vorbis.c b/libavcodec/vorbis.c
index 399020eec5..ce23b947f0 100644
--- a/libavcodec/vorbis.c
+++ b/libavcodec/vorbis.c
@@ -58,7 +58,7 @@ int ff_vorbis_len2vlc(uint8_t *bits, uint32_t *codes, 
unsigned num)
 uint32_t exit_at_level[33] = { 404 };
 unsigned i, j, p, code;
 
-for (p = 0; (bits[p] == 0) && (p < num); ++p)
+for (p = 0; (p < num) && (bits[p] == 0); ++p)
 ;
 if (p == num)
 return 0;
@@ -71,7 +71,7 @@ int ff_vorbis_len2vlc(uint8_t *bits, uint32_t *codes, 
unsigned num)
 
 ++p;
 
-for (i = p; (bits[i] == 0) && (i < num); ++i)
+for (i = p; (i < num) && (bits[i] == 0); ++i)
 ;
 if (i == num)
 return 0;
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 5/7] mxfdec: Fix return value check

[Mark Thompson]

Move the assignment out of the condition, because that was hiding the error.

Fixes #6750.
---
 libavformat/mxfdec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 118e3e40b4..e4019ac0a7 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2311,7 +2311,8 @@ static int64_t mxf_timestamp_to_int64(uint64_t timestamp)
 
 #define SET_TS_METADATA(pb, name, var, str) do { \
 var = avio_rb64(pb); \
-if ((ret = avpriv_dict_set_timestamp(&s->metadata, name, 
mxf_timestamp_to_int64(var)) < 0)) \
+ret = avpriv_dict_set_timestamp(&s->metadata, name, 
mxf_timestamp_to_int64(var)); \
+if (ret < 0) \
 return ret; \
 } while (0)
 
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 4/7] xfacedec: Fix possible overread

[Mark Thompson]

Fixes #6745.
---
 libavcodec/xfacedec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/xfacedec.c b/libavcodec/xfacedec.c
index d045cb6ef4..ab4c0823f5 100644
--- a/libavcodec/xfacedec.c
+++ b/libavcodec/xfacedec.c
@@ -123,7 +123,7 @@ static int xface_decode_frame(AVCodecContext *avctx,
 if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
 return ret;
 
-for (i = 0, k = 0; avpkt->data[i] && i < avpkt->size; i++) {
+for (i = 0, k = 0; i < avpkt->size && avpkt->data[i]; i++) {
 c = avpkt->data[i];
 
 /* ignore invalid digits */
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 6/7] hlsenc: Fix creation of final directory in path

[Mark Thompson]

Fixes #6752.
---
 libavformat/hlsenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 418f153c6f..eba3aef567 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -207,7 +207,7 @@ static int mkdir_p(const char *path) {
 }
 }
 
-if ((*(pos - 1) != '/') || (*(pos - 1) != '\\')) {
+if ((*(pos - 1) != '/') && (*(pos - 1) != '\\')) {
 ret = mkdir(temp, 0755);
 }
 
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 7/7] signature_lookup: Fix operator precedence error

[Mark Thompson]

Fixes #6754.
---
This looks like it was rather broken before if the condition is ever meant to 
be false?


 libavfilter/signature_lookup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/signature_lookup.c b/libavfilter/signature_lookup.c
index 272c717c77..85e879d224 100644
--- a/libavfilter/signature_lookup.c
+++ b/libavfilter/signature_lookup.c
@@ -491,7 +491,7 @@ static MatchingInfo evaluate_parameters(AVFilterContext 
*ctx, SignatureContext *
 meandist = (double) goodfcount / (double) distsum;
 
 if (meandist < minmeandist ||
-status == STATUS_END_REACHED | STATUS_BEGIN_REACHED ||
+status == (STATUS_END_REACHED | STATUS_BEGIN_REACHED) ||
 mode == MODE_FAST){
 minmeandist = meandist;
 /* bestcandidate in this iteration */
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

[Bjorn Roche]

On Tue, Oct 17, 2017 at 5:27 PM, Carl Eugen Hoyos 
wrote:

> 2017-10-17 3:16 GMT+02:00 Carl Eugen Hoyos :
> > 2017-10-10 23:41 GMT+02:00 Bjorn Roche :
> >
> >> +{ "trans_threshold", "set the threshold for alpha values avoce
> which they are considered completely opaque", OFFSET(trans_thresh),
> AV_OPT_TYPE_INT, {.i64=128}, 0, 255, },
>

Looks like I somehow spelled "above" "avoce".


> > I wonder if "threshold" is enough.
> >
> > No more comments from me, thank you!
>
> Remaining comment is:
> The paletteuse filter does not work correctly on big-endian
> (my guess is the code makes wrong assumptions about the
> palette colour-space), I don't think this should delay this
> patch though.


Is this due to the patch, or was this a problem prior to the patch as well?
If it's due to the patch, I can try to gain access to a big-endian machine
and see if I can fix it.

bjorn

-- 


Bjorn Roche

Sr. Video Pipeline Engineer

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

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

[Carl Eugen Hoyos]

2017-10-18 0:20 GMT+02:00 Bjorn Roche :
> On Tue, Oct 17, 2017 at 5:27 PM, Carl Eugen Hoyos
>  wrote:

>> Remaining comment is:
>> The paletteuse filter does not work correctly on big-endian
>> (my guess is the code makes wrong assumptions about the
>> palette colour-space), I don't think this should delay this
>> patch though.
>
>
> Is this due to the patch, or was this a problem prior to the patch as well?

It is already a problem with the current code.

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

Re: [FFmpeg-devel] [PATCH] avcodec/v4l2: fix access to priv_data after codec close.

[Mark Thompson]

On 17/10/17 18:20, Jorge Ramirez-Ortiz wrote:
> A user can close the codec while keeping references to some of the
> capture buffers. When the codec is closed, the structure that keeps
> the contexts, state and the driver file descriptor is freed.
> 
> Since access to some of the elements in that structure is required to
> properly release the memory during the buffer unref callbacks, the
> following commit makes sure the unref callback accesses valid memory.
> 
> This commit was tested with valgrind:
> 
> $ valgrind ffmpeg_g -report -threads 1 -v 55  -y -c:v h264_v4l2m2m \
>   -i video.h264 -an -frames:v 100 -f null -
> ---
>  libavcodec/v4l2_buffers.c | 17 -
>  libavcodec/v4l2_buffers.h |  6 ++
>  libavcodec/v4l2_m2m.c | 29 -
>  libavcodec/v4l2_m2m_dec.c |  2 +-
>  4 files changed, 47 insertions(+), 7 deletions(-)
> 
> diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
> index ba70c5d..80e65ca 100644
> --- a/libavcodec/v4l2_buffers.c
> +++ b/libavcodec/v4l2_buffers.c
> @@ -205,9 +205,24 @@ static enum AVColorTransferCharacteristic 
> v4l2_get_color_trc(V4L2Buffer *buf)
>  static void v4l2_free_buffer(void *opaque, uint8_t *unused)
>  {
>  V4L2Buffer* avbuf = opaque;
> -V4L2m2mContext *s = buf_to_m2mctx(avbuf);
> +V4L2m2mContext *s = avbuf->m2m ? avbuf->m2m : buf_to_m2mctx(avbuf);
>  
>  atomic_fetch_sub_explicit(&s->refcount, 1, memory_order_acq_rel);
> +
> +if (avbuf->m2m) {
> +if (!atomic_load(&s->refcount)) {
> +/* unmmap and free the associated buffers */
> +ff_v4l2_context_release(&s->capture);
> +
> +/* close the v4l2 driver */
> +close(s->fd);
> +
> +/* release the duplicated m2m context */
> +av_freep(&s);
> +}
> +return;
> +}
> +
>  if (s->reinit) {
>  if (!atomic_load(&s->refcount))
>  sem_post(&s->refsync);
> diff --git a/libavcodec/v4l2_buffers.h b/libavcodec/v4l2_buffers.h
> index e28a4a6..d774480 100644
> --- a/libavcodec/v4l2_buffers.h
> +++ b/libavcodec/v4l2_buffers.h
> @@ -41,6 +41,12 @@ typedef struct V4L2Buffer {
>  /* each buffer needs to have a reference to its context */
>  struct V4L2Context *context;
>  
> +/* when the codec is closed while the user has buffer references we
> + * still need access to context data (this is a pointer to a duplicated
> + * m2m context created during the codec close function).
> + */
> +struct V4L2m2mContext *m2m;
> +
>  /* keep track of the mmap address and mmap length */
>  struct V4L2Plane_info {
>  int bytesperline;
> diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
> index 1d7a852..91b1bbb 100644
> --- a/libavcodec/v4l2_m2m.c
> +++ b/libavcodec/v4l2_m2m.c
> @@ -313,8 +313,8 @@ error:
>  
>  int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
>  {
> -V4L2m2mContext* s = avctx->priv_data;
> -int ret;
> +V4L2m2mContext *m2m, *s = avctx->priv_data;
> +int i, ret;
>  
>  ret = ff_v4l2_context_set_status(&s->output, VIDIOC_STREAMOFF);
>  if (ret)
> @@ -325,12 +325,31 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
>  av_log(avctx, AV_LOG_ERROR, "VIDIOC_STREAMOFF %s\n", 
> s->capture.name);
>  
>  ff_v4l2_context_release(&s->output);
> +sem_destroy(&s->refsync);
>  
> -if (atomic_load(&s->refcount))
> -av_log(avctx, AV_LOG_ERROR, "ff_v4l2m2m_codec_end leaving pending 
> buffers\n");
> +if (atomic_load(&s->refcount)) {
> +av_log(avctx, AV_LOG_DEBUG, "ff_v4l2m2m_codec_end, referenced 
> buffers %d\n", atomic_load(&s->refcount));
> +
> +/* We are about to free the private data while the user still has 
> references to the buffers.
> + * This means that when the user releases those buffers, the 
> v4l2_free_buffer callback will be pointing to free'd memory.
> + * Duplicate the m2m context and update the buffers.
> + */
> +m2m = av_mallocz(sizeof(*m2m));
> +if (m2m) {
> +memcpy(m2m, s, sizeof(V4L2m2mContext));
> +for (i = 0; i < s->capture.num_buffers; i++)
> +s->capture.buffers[i].m2m = m2m;
> +
> +return 0;
> +}

No.

The user can call av_buffer_unref() and therefore v4l2_free_buffer() 
asynchronously on another thread while this manoeuvre is in progress.

> +
> +/* on ENOMEM let's at least close the v4l2 driver and release the 
> capture memory
> + * so the driver is left in a healthy state.
> + */
> +av_log(avctx, AV_LOG_ERROR, "ff_v4l2m2m_codec_end, referenced 
> buffers not accessible\n");
> +}
>  
>  ff_v4l2_context_release(&s->capture);
> -sem_destroy(&s->refsync);
>  
>  /* release the hardware */
>  if (close(s->fd) < 0 )
> diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
> index 958cdc5..f88f819 100644
> --- a/libavcodec/v4l2_m2m_dec.c
> +++ b/liba

Re: [FFmpeg-devel] [PATCH 3/7] vorbis: Reorder conditions to avoid possible overread

[Rostislav Pehlivanov]

On 17 October 2017 at 23:11, Mark Thompson  wrote:

> This can trigger a single-byte overread if the codebook has the maximum
> number of entries.
>
> Fixes #6743.
> ---
>  libavcodec/vorbis.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vorbis.c b/libavcodec/vorbis.c
> index 399020eec5..ce23b947f0 100644
> --- a/libavcodec/vorbis.c
> +++ b/libavcodec/vorbis.c
> @@ -58,7 +58,7 @@ int ff_vorbis_len2vlc(uint8_t *bits, uint32_t *codes,
> unsigned num)
>  uint32_t exit_at_level[33] = { 404 };
>  unsigned i, j, p, code;
>
> -for (p = 0; (bits[p] == 0) && (p < num); ++p)
> +for (p = 0; (p < num) && (bits[p] == 0); ++p)
>  ;
>  if (p == num)
>  return 0;
> @@ -71,7 +71,7 @@ int ff_vorbis_len2vlc(uint8_t *bits, uint32_t *codes,
> unsigned num)
>
>  ++p;
>
> -for (i = p; (bits[i] == 0) && (i < num); ++i)
> +for (i = p; (i < num) && (bits[i] == 0); ++i)
>  ;
>  if (i == num)
>  return 0;
> --
> 2.11.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

LGTM
I'll get around to merging the psy stuff one of these days
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] frame: add an av_frame_new_side_data_from_buf function

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 libavutil/frame.c | 38 --
 libavutil/frame.h | 13 +
 2 files changed, 33 insertions(+), 18 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index d5fd2932e3..b5a2b2f842 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -26,11 +26,6 @@
 #include "mem.h"
 #include "samplefmt.h"
 
-
-static AVFrameSideData *frame_new_side_data(AVFrame *frame,
-enum AVFrameSideDataType type,
-AVBufferRef *buf);
-
 MAKE_ACCESSORS(AVFrame, frame, int64_t, best_effort_timestamp)
 MAKE_ACCESSORS(AVFrame, frame, int64_t, pkt_duration)
 MAKE_ACCESSORS(AVFrame, frame, int64_t, pkt_pos)
@@ -356,8 +351,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 memcpy(sd_dst->data, sd_src->data, sd_src->size);
 } else {
-sd_dst = frame_new_side_data(dst, sd_src->type, 
av_buffer_ref(sd_src->buf));
+AVBufferRef *buf = av_buffer_ref(sd_src->buf);
+sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, buf);
 if (!sd_dst) {
+av_buffer_unref(&buf);
 wipe_side_data(dst);
 return AVERROR(ENOMEM);
 }
@@ -636,9 +633,9 @@ AVBufferRef *av_frame_get_plane_buffer(AVFrame *frame, int 
plane)
 return NULL;
 }
 
-static AVFrameSideData *frame_new_side_data(AVFrame *frame,
-enum AVFrameSideDataType type,
-AVBufferRef *buf)
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf)
 {
 AVFrameSideData *ret, **tmp;
 
@@ -646,7 +643,11 @@ static AVFrameSideData *frame_new_side_data(AVFrame *frame,
 return NULL;
 
 if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
-goto fail;
+return NULL;
+
+ret = av_mallocz(sizeof(*ret));
+if (!ret)
+return NULL;
 
 tmp = av_realloc(frame->side_data,
  (frame->nb_side_data + 1) * sizeof(*frame->side_data));
@@ -654,10 +655,6 @@ static AVFrameSideData *frame_new_side_data(AVFrame *frame,
 goto fail;
 frame->side_data = tmp;
 
-ret = av_mallocz(sizeof(*ret));
-if (!ret)
-goto fail;
-
 ret->buf = buf;
 ret->data = ret->buf->data;
 ret->size = buf->size;
@@ -666,17 +663,22 @@ static AVFrameSideData *frame_new_side_data(AVFrame 
*frame,
 frame->side_data[frame->nb_side_data++] = ret;
 
 return ret;
-fail:
-av_buffer_unref(&buf);
-return NULL;
 }
 
 AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 int size)
 {
+AVBufferRef *buf = av_buffer_alloc(size);
+if (!buf)
+return NULL;
 
-return frame_new_side_data(frame, type, av_buffer_alloc(size));
+AVFrameSideData *ret = av_frame_new_side_data_from_buf(frame, type, buf);
+if (!ref) {
+av_buffer_unref(&buf);
+return NULL;
+}
+return ret;
 }
 
 AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
diff --git a/libavutil/frame.h b/libavutil/frame.h
index abe4f4fd17..bc01b4f0dd 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -762,6 +762,19 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 enum AVFrameSideDataType type,
 int size);
 
+/**
+ * Add a new side data to a frame from an existing AVBufferRef
+ *
+ * @param frame a frame to which the side data should be added
+ * @param type type of the added side data
+ * @param buf the AVBufferRef to add as side data
+ *
+ * @return newly added side data on success, NULL on error
+ */
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf);
+
 /**
  * @return a pointer to the side data of a given type on success, NULL if there
  * is no side data with such type in this frame.
-- 
2.15.0.rc1.287.g2b38de12cc

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

Re: [FFmpeg-devel] [PATCH 6/9] opusenc: Fix double-declaration of variable

[Rostislav Pehlivanov]

On 17 October 2017 at 22:12, Mark Thompson  wrote:

> ---
>  libavcodec/opusenc_psy.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/libavcodec/opusenc_psy.c b/libavcodec/opusenc_psy.c
> index b446d41f75..1b108ecb87 100644
> --- a/libavcodec/opusenc_psy.c
> +++ b/libavcodec/opusenc_psy.c
> @@ -370,7 +370,6 @@ static int celt_search_for_tf(OpusPsyContext *s,
> OpusPsyStep **start, CeltFrame
>  for (cway = 0; cway < 2; cway++) {
>  int mag[2];
>  int base = f->transient ? 120 : 960;
> -int i;
>
>  for (i = 0; i < 2; i++) {
>  int c = ff_celt_tf_select[f->size][f->transient][cway][i];
> --
> 2.11.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH] doc/filters: Add note on Flite thread safety and update URL

[Michael Niedermayer]

On Mon, Oct 09, 2017 at 11:19:45AM +0530, Gyan Doshi wrote:
> Version 2 of Flite, a speech synthesis library, was released towards
> the end of 2014. Among the notes at the project site: "Thread safe
> (really this time)".
> 
> Docs and project URL updated accordingly.

>  filters.texi |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> ad3b82f7e79cb0efcab25820492a86b67d1b5fa3  
> 0001-doc-filters-add-note-on-flite-thread-safety-and-upda.patch
> From 8f0de211aaa9e100cbec2b12b4a1668541a76217 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Mon, 9 Oct 2017 11:06:10 +0530
> Subject: [PATCH] doc/filters: add note on flite thread safety and update URL
> 
> Signed-off-by: Gyan Doshi 
> ---
>  doc/filters.texi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

will apply

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

Re: [FFmpeg-devel] [mov] When both edit list and start padding present, take maximum.

[Michael Niedermayer]

On Mon, Oct 16, 2017 at 02:22:45PM -0700, Dale Curtis wrote:
> Previously the start padding was used to blindly overwrite any skip samples
> which may have come from an edit list. Instead take the maximum of the two.
> 
> A new fate test is added, fate-mov-440hz-10ms, to ensure this is handled
> correctly.
> 
> The sample can be downloaded and added to the fate-suite from
> 

> https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/webaudio/resources/media/440hz-10ms.m4a

sample uploaded to fatesamples

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] [PATCH] avcodec/cfhd: support cropped height tag

[James Almer]

Ported from libav. Authored by one of the following:

Anton Khirnov 
Diego Biurrun 
Vittorio Giovara 

Signed-off-by: James Almer 
---
 libavcodec/cfhd.c | 6 ++
 libavcodec/cfhd.h | 1 +
 2 files changed, 7 insertions(+)

diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 5646ee8271..fd834b 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -73,6 +73,7 @@ static void init_frame_defaults(CFHDContext *s)
 {
 s->coded_width   = 0;
 s->coded_height  = 0;
+s->cropped_height= 0;
 s->bpc   = 10;
 s->channel_cnt   = 4;
 s->subband_cnt   = SUBBAND_COUNT;
@@ -455,6 +456,9 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 break;
 }
 planes = av_pix_fmt_count_planes(s->coded_format);
+} else if (tag == -85) {
+av_log(avctx, AV_LOG_DEBUG, "Cropped height %"PRIu16"\n", data);
+s->cropped_height = data;
 } else
 av_log(avctx, AV_LOG_DEBUG,  "Unknown tag %i data %x\n", tag, 
data);
 
@@ -472,6 +476,8 @@ static int cfhd_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 ret = ff_set_dimensions(avctx, s->coded_width, s->coded_height);
 if (ret < 0)
 return ret;
+if (s->cropped_height)
+avctx->height = s->cropped_height;
 frame.f->width =
 frame.f->height = 0;
 
diff --git a/libavcodec/cfhd.h b/libavcodec/cfhd.h
index b0a52088aa..2573e750a6 100644
--- a/libavcodec/cfhd.h
+++ b/libavcodec/cfhd.h
@@ -81,6 +81,7 @@ typedef struct CFHDContext {
 
 int coded_width;
 int coded_height;
+int cropped_height;
 enum AVPixelFormat coded_format;
 
 int a_width;
-- 
2.14.2

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/cafenc: Allow muxing opus.

[Carl Eugen Hoyos]

2017-10-17 23:48 GMT+02:00 James Almer :
> On 10/17/2017 6:20 PM, Carl Eugen Hoyos wrote:
>> 2017-10-17 22:20 GMT+02:00 James Almer :
 ffmpeg | branch: master | Carl Eugen Hoyos >>> > | Tue Oct 17 21:35:28 
 2017 +0200| [a3accd0c3768933f15422c9dec596da0f436d786] | committer: Carl 
 Eugen Hoyos

 lavf/cafenc: Allow muxing opus.

 QuickTime does not require the (unknown) kuki chunk for decoding.
>>>
>>> This at the very least requires limiting muxing to mono and stereo
>>> streams (The only kind of streams that work without channel mapping
>>> information in extradata),
>>
>> Done, thank you!
>>
>>> and a check for -strict experimental.
>>
>> Why?
>
> Because we're creating these files blindly

This is not correct (and offending, no matter the issue
with the original patch).

> without a proper RE attempt

How do you know?

> or following any kind of encapsulation spec. And considering the
> official encoder/muxer adds a codec specific chunk we don't, the more
> reason to consider a muxing as barebones as this as something
> potentially non-compliant.

Imo, this is not a helpful approach:
The "official" demuxer/decoder accept the files, how does
it make sense to argue they are potentially non-compliant?

>>> Also, I'd have rather waited for Apple to update their docs about Opus
>>> in CAF.
>>
>> As in: Until Godot arrives?
>>
>> Sorry, I don't think it makes much sense to wait for a
>> specification that to best of our knowledge may never
>> appear.
>
> Apple published the spec for CAF

> detailing encapsulation details for the codecs it supports

Depending on the definition of "detailing":
Yes.
(For most codecs, the encapsulation details had to be
guessed.)

> including the contents of the kuki chunk for most of them.

Could you elaborate? This is not how I remember it.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/cafenc: Allow muxing opus.

[James Almer]

On 10/17/2017 10:10 PM, Carl Eugen Hoyos wrote:
> 2017-10-17 23:48 GMT+02:00 James Almer :
>> On 10/17/2017 6:20 PM, Carl Eugen Hoyos wrote:
>>> 2017-10-17 22:20 GMT+02:00 James Almer :
> ffmpeg | branch: master | Carl Eugen Hoyos  > | Tue Oct 17 21:35:28 
> 2017 +0200| [a3accd0c3768933f15422c9dec596da0f436d786] | committer: Carl 
> Eugen Hoyos
>
> lavf/cafenc: Allow muxing opus.
>
> QuickTime does not require the (unknown) kuki chunk for decoding.

 This at the very least requires limiting muxing to mono and stereo
 streams (The only kind of streams that work without channel mapping
 information in extradata),
>>>
>>> Done, thank you!
>>>
 and a check for -strict experimental.
>>>
>>> Why?
>>
>> Because we're creating these files blindly
> 
> This is not correct (and offending, no matter the issue
> with the original patch).

I don't see how it can be offending. But in any case, would "without
understanding all the encapsulation details" instead of blindly be less
offensive?

> 
>> without a proper RE attempt
> 
> How do you know?

You specifically called the contents of the kuki chunk "unknown" in the
commit message. That pretty much implies there has been no concrete
attempt to RE it. Not to mention you'd have added support for it otherwise.

> 
>> or following any kind of encapsulation spec. And considering the
>> official encoder/muxer adds a codec specific chunk we don't, the more
>> reason to consider a muxing as barebones as this as something
>> potentially non-compliant.
> 
> Imo, this is not a helpful approach:
> The "official" demuxer/decoder accept the files, how does
> it make sense to argue they are potentially non-compliant?

It happening to work or be accepted isn't the same as being spec
compliant. Some specs can be very pedantic in the most silly of ways
with small details and declare something that pretty much any
implementation accepts as non-compliant. See things like MPEG/WebM DASH.

In this case, the spec says "If the audio data format contained in a CAF
file requires magic cookie data, the file must have this chunk", which
is apparently followed by the official muxer application, but not by
Quicktime since according to your tests it ignores its absence.

> 
 Also, I'd have rather waited for Apple to update their docs about Opus
 in CAF.
>>>
>>> As in: Until Godot arrives?
>>>
>>> Sorry, I don't think it makes much sense to wait for a
>>> specification that to best of our knowledge may never
>>> appear.
>>
>> Apple published the spec for CAF
> 
>> detailing encapsulation details for the codecs it supports
> 
> Depending on the definition of "detailing":
> Yes.
> (For most codecs, the encapsulation details had to be
> guessed.)
> 
>> including the contents of the kuki chunk for most of them.
> 
> Could you elaborate? This is not how I remember it.

The spec mentions that for AAC, the kuki chunk contains the same data as
the esds atom in ISOBMFF. And then there's
https://github.com/macosforge/alac/blob/master/ALACMagicCookieDescription.txt
for ALAC. So at least the two most important ones.

I want to believe the same will be done for Opus, if anything by Xiph
(like they did with ISOBMFF).

> 
> Carl Eugen
> ___
> 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 1/1] lavc: add support for OpenJPEG 2.3.0

[James Almer]

On 10/6/2017 10:26 PM, James Almer wrote:
> On 10/6/2017 1:26 PM, Michael Bradshaw wrote:
>> On Thu, Oct 5, 2017 at 9:55 AM, James Almer  wrote:
>>
>>> On 10/5/2017 10:45 AM, Michael Bradshaw wrote:
 From: Michael Bradshaw 

 Signed-off-by: Michael Bradshaw 
 ---
  configure   |  5 -
  libavcodec/libopenjpegdec.c |  8 +---
  libavcodec/libopenjpegenc.c | 10 ++
  3 files changed, 15 insertions(+), 8 deletions(-)

 diff --git a/configure b/configure
 index 391c141e7a..77c9a18c3c 100755
 --- a/configure
 +++ b/configure
 @@ -1930,6 +1930,7 @@ HEADERS_LIST="
  machine_ioctl_meteor_h
  malloc_h
  opencv2_core_core_c_h
 +openjpeg_2_3_openjpeg_h
>>>
>>> Is there a reason OpenJPEG uses a different folder to store the header
>>> with each release from the 2.x family? It's really bloating both
>>> configure and the wrappers.
>>
>>
>> Yeah, it's really annoying. Once we drop support for 1.x versions we'll be
>> able to clean up the majority of this garbage (though not all of it,
>> unfortunately). I'd personally like to drop support for OpenJPEG 1.x
>> immediately; the only place where it's still used is in package managers
>> for LTS Linux distros, and I have no qualms about telling users to manually
>> build/install a more recent version of OpenJPEG (especially since there are
>> so many bug fixes in recent OpenJPEG versions, many of which are security
>> related).
> 
> As Carl said, since we're a few days away from a new release it'll be
> best to do it after it's branched off master. But for now, apply this
> patch so the new release can use OpenJPEG 2.3
> 
> I see OpenJPEG2 ships a pkg-config file, which would let us drop all the
> extra configure checks for each different include folder. That will
> clear all the current configure bloat and prevent new checks to be added
> in the future.

The 3.4 release has been tagged. Can you look into removing the OpenJPEG
1.x support and switching the checks to pkg-config to finally clean up
the configure and wrappers' bloat?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel