[FFmpeg-devel] [PATCH 1/2] avcodec/v4l2: fix single plane decoding
---
libavcodec/v4l2_buffers.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index ef7d040..ba70c5d 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -244,13 +244,23 @@ static int v4l2_buf_to_bufref(V4L2Buffer *in, int plane,
AVBufferRef **buf)
static int v4l2_bufref_to_buf(V4L2Buffer *out, int plane, const uint8_t* data,
int size, AVBufferRef* bref)
{
+unsigned int bytesused, length;
+
if (plane >= out->num_planes)
return AVERROR(EINVAL);
+bytesused = FFMIN(size, out->plane_info[plane].length);
+length = out->plane_info[plane].length;
+
memcpy(out->plane_info[plane].mm_addr, data, FFMIN(size,
out->plane_info[plane].length));
-out->planes[plane].bytesused = FFMIN(size, out->plane_info[plane].length);
-out->planes[plane].length = out->plane_info[plane].length;
+if (V4L2_TYPE_IS_MULTIPLANAR(out->buf.type)) {
+out->planes[plane].bytesused = bytesused;
+out->planes[plane].length = length;
+} else {
+out->buf.bytesused = bytesused;
+out->buf.length = length;
+}
return 0;
}
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/v4l2: fix segmentation fault on codec exit
It occurs when the codec is closed while buffer references still
exist. This is a regression from the original patchset where support
for this use-case was implemented.
The regression occurred while cleaning the code for the last patchset
(decoding was tested only with ffplay which disposes of the buffer
straightaway hence the feature went in broken/untested)
---
libavcodec/v4l2_m2m.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
index bd96a6d..5e85bcb 100644
--- a/libavcodec/v4l2_m2m.c
+++ b/libavcodec/v4l2_m2m.c
@@ -331,8 +331,10 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
ff_v4l2_context_release(&s->output);
-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 leaving pending
buffers\n");
+return 0;
+}
ff_v4l2_context_release(&s->capture);
sem_destroy(&s->refsync);
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/avfilter.c: Correct guess_status_pts to account for differing link timebases.
Le quartidi 14 vendémiaire, an CCXXVI, Sasi Inguva a écrit :
> Signed-off-by: Sasi Inguva
> ---
> libavfilter/avfilter.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
You are right, this change is needed. Thanks for spotting it and the
patch.
>
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index 58917ed445..ec7dfc0bd3 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -427,19 +427,19 @@ int ff_request_frame(AVFilterLink *link)
> return 0;
> }
>
> -static int64_t guess_status_pts(AVFilterContext *ctx, int status)
> +static int64_t guess_status_pts_from_src(AVFilterLink *link, int status)
I would prefer if you just added a "AVRational time_base" parameter.
With this version, the code has "link->" indirections all over the
place, that lowers the readability.
> {
> unsigned i;
> int64_t r = INT64_MAX;
>
> -for (i = 0; i < ctx->nb_inputs; i++)
> -if (ctx->inputs[i]->status_out == status)
> -r = FFMIN(r, ctx->inputs[i]->current_pts);
> +for (i = 0; i < link->src->nb_inputs; i++)
> +if (link->src->inputs[i]->status_out == status)
> + r = FFMIN(r, av_rescale_q(link->src->inputs[i]->current_pts,
> link->src->inputs[i]->time_base, link->time_base));
> if (r < INT64_MAX)
> return r;
> -av_log(ctx, AV_LOG_WARNING, "EOF timestamp not reliable\n");
> -for (i = 0; i < ctx->nb_inputs; i++)
> -r = FFMIN(r, ctx->inputs[i]->status_in_pts);
> +av_log(link->src, AV_LOG_WARNING, "EOF timestamp not reliable\n");
> +for (i = 0; i < link->src->nb_inputs; i++)
> + r = FFMIN(r, av_rescale_q(link->src->inputs[i]->status_in_pts,
> link->src->inputs[i]->time_base, link->time_base));
> if (r < INT64_MAX)
> return r;
> return AV_NOPTS_VALUE;
> @@ -458,7 +458,7 @@ static int ff_request_frame_to_filter(AVFilterLink *link)
> ret = ff_request_frame(link->src->inputs[0]);
> if (ret < 0) {
> if (ret != AVERROR(EAGAIN) && ret != link->status_in)
> -ff_avfilter_link_set_in_status(link, ret,
> guess_status_pts(link->src, ret));
> +ff_avfilter_link_set_in_status(link, ret,
> guess_status_pts_from_src(link, ret));
> if (ret == AVERROR_EOF)
> ret = 0;
> }
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] avformat/srt: add Haivision SRT protocol
Le quintidi 15 vendémiaire, an CCXXVI, Nablet Developer a écrit : > > SRT is a subtitle format: a more specific name would be better. > Haivision suggested name "opensrt" - is it acceptable to distinguish with > SRT subtitile format? > if yes, I'll go ahead and submit new patch with name changed. That would be fine by me, at least. 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] udp: added option to ignore empty UDP packets
Le quartidi 14 vendémiaire, an CCXXVI, Carl Eugen Hoyos a écrit : > Just curious: Is it useful at all to exit on an empty packet? It is not useful at all, it is a bug. More specifically, when reading plain files, ret = 0 means EOF for plain files, just because there is nothing more to read (but if the file grows, more data is returned in a later read). This has been extended to pipes and stream socket, and some devices, but not all. In particular, ret = 0 means EOF neither for ttys nor for packet protocols. In FFmpeg, we have AVERROR_EOF and use it for EOF. For consistency and simplicity, it is better to have only one case, therefore ret = 0 should not be used to mean EOF. Stream protocols should never return 0. I agree that we have that mistake probably in a lot of places. Finding and fixing all of them would be a huge work. Fortunately, it is not absolutely necessary: fixing the cases that cause visible bugs for actual users is enough. And since empty packets are valid and can be used by applications (and are actually used by protocols out there), the workaround of dropping them is not acceptable. 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] udp: added option to ignore empty UDP packets
> And since empty packets are valid and can be used by applications (and > are actually used by protocols out there), the workaround of dropping > them is not acceptable. > I'm not sure if you mean this patch is unacceptable but if so, I want to note, that this patch is not the same as I submitted before: this one adds cmdlne option to ignore empty packets and it doesn't ignore them when not explicitly enabled. -- S pozdravom / Best regards Daniel Kucera. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 0/2] avdevice/decklink: 10-bit video out and sources/sinks support
On Thu, Oct 05, 2017 at 15:32:04 -0400, Devin Heitmueller wrote: > This patch series incorporates feedback provided from Marton Balint. > Note that patch 4 in the previous patch series was consolidated into > patch 3 per Marton's suggestion. There's no patch 3 in the series you sent. And you misspelled Marton's surname in both patches' commit messages. Just saying, ;-) Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/avfilter.c: Correct guess_status_pts to account for differing link timebases.
2017-10-06 4:49 GMT+02:00 Sasi Inguva :
> Signed-off-by: Sasi Inguva
> ---
> libavfilter/avfilter.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index 58917ed445..ec7dfc0bd3 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -427,19 +427,19 @@ int ff_request_frame(AVFilterLink *link)
> return 0;
> }
>
> -static int64_t guess_status_pts(AVFilterContext *ctx, int status)
> +static int64_t guess_status_pts_from_src(AVFilterLink *link, int status)
> {
> unsigned i;
> int64_t r = INT64_MAX;
>
> -for (i = 0; i < ctx->nb_inputs; i++)
> -if (ctx->inputs[i]->status_out == status)
> -r = FFMIN(r, ctx->inputs[i]->current_pts);
> +for (i = 0; i < link->src->nb_inputs; i++)
> +if (link->src->inputs[i]->status_out == status)
> + r = FFMIN(r, av_rescale_q(link->src->inputs[i]->current_pts,
> link->src->inputs[i]->time_base, link->time_base));
> if (r < INT64_MAX)
> return r;
> -av_log(ctx, AV_LOG_WARNING, "EOF timestamp not reliable\n");
> -for (i = 0; i < ctx->nb_inputs; i++)
> -r = FFMIN(r, ctx->inputs[i]->status_in_pts);
> +av_log(link->src, AV_LOG_WARNING, "EOF timestamp not reliable\n");
> +for (i = 0; i < link->src->nb_inputs; i++)
> + r = FFMIN(r, av_rescale_q(link->src->inputs[i]->status_in_pts,
> link->src->inputs[i]->time_base, link->time_base));
> if (r < INT64_MAX)
> return r;
> return AV_NOPTS_VALUE;
> @@ -458,7 +458,7 @@ static int ff_request_frame_to_filter(AVFilterLink
> *link)
> ret = ff_request_frame(link->src->inputs[0]);
> if (ret < 0) {
> if (ret != AVERROR(EAGAIN) && ret != link->status_in)
> -ff_avfilter_link_set_in_status(link, ret,
> guess_status_pts(link->src, ret));
> +ff_avfilter_link_set_in_status(link, ret,
> guess_status_pts_from_src(link, ret));
> if (ret == AVERROR_EOF)
> ret = 0;
> }
>
Thank you for this patch. Works fine for me.
Regards,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mpegtsenc add synchronous metadata
Add synchronous metadata to mpegtsenc
* Added AV_CODEC_ID_SYNCHRONOUS_METADATA
* PMT will have metadata_descriptor and metadata_std_descriptor
in accordance with MISB ST 1402.2
* stream_type will be 0x15 metadata carried in PES packets
* stream_id will be 0xfc metadata stream
Users must supply Metadata Access Unit to the packet before writing.
---
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 6 ++
libavformat/mpegtsenc.c | 22 ++
3 files changed, 29 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 52cc5b0..fb43182 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -683,6 +683,7 @@ enum AVCodecID {
AV_CODEC_ID_DVD_NAV,
AV_CODEC_ID_TIMED_ID3,
AV_CODEC_ID_BIN_DATA,
+AV_CODEC_ID_SYNCHRONOUS_METADATA,
AV_CODEC_ID_PROBE = 0x19000, ///< codec_id is not known (like AV_CODEC_ID_NONE) but lavf should attempt to identify it
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 6a13bbb..0ec6872 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -3114,6 +3114,12 @@ static const AVCodecDescriptor codec_descriptors[] = {
.name = "scte_35",
.long_name = NULL_IF_CONFIG_SMALL("SCTE 35 Message Queue"),
},
+{
+.id= AV_CODEC_ID_SYNCHRONOUS_METADATA,
+.type = AVMEDIA_TYPE_DATA,
+.name = "sync_metadata",
+.long_name = NULL_IF_CONFIG_SMALL("ISO/IEC 13818-1 Synchronous Metadata"),
+},
/* deprecated codec ids */
};
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index fdfa544..35907da 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -387,6 +387,7 @@ static int mpegts_write_pmt(AVFormatContext *s, MpegTSService *service)
stream_type = STREAM_TYPE_PRIVATE_DATA;
break;
case AV_CODEC_ID_TIMED_ID3:
+case AV_CODEC_ID_SYNCHRONOUS_METADATA:
stream_type = STREAM_TYPE_METADATA;
break;
default:
@@ -641,6 +642,27 @@ static int mpegts_write_pmt(AVFormatContext *s, MpegTSService *service)
*q++ = 'L';
*q++ = 'V';
*q++ = 'A';
+} else if (st->codecpar->codec_id == AV_CODEC_ID_SYNCHRONOUS_METADATA) {
+const char *tag = "KLVA";
+*q++ = 0x26; /* desctiptor_tag = metadata_descriptor */
+*q++ = 9; /* desctiptor_length */
+put16(&q, 0x0100);/* metadata application format */
+*q++ = 0xff; /* metadata format */
+putstr8(&q, tag, 0);
+*q++ = 0;/* metadata service ID */
+*q++ = 0xF; /* decoder_config_flags|DSM-CC flag|reserved */
+
+*q++ = 0x27; /* desctiptor_tag = metadata_std_descriptor */
+*q++ = 9; /* desctiptor_length */
+*q++ = 0xc0;
+*q++ = 0x00;
+*q++ = 0x00;
+*q++ = 0xc0;
+*q++ = 0x00;
+*q++ = 0x00;
+*q++ = 0xc0;
+*q++ = 0x00;
+*q++ = 0x00;
} else if (st->codecpar->codec_id == AV_CODEC_ID_TIMED_ID3) {
const char *tag = "ID3 ";
*q++ = 0x26; /* metadata descriptor */
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 0/2] avdevice/decklink: 10-bit video out and sources/sinks support
> On Oct 6, 2017, at 5:13 AM, Moritz Barsnick wrote: > > On Thu, Oct 05, 2017 at 15:32:04 -0400, Devin Heitmueller wrote: >> This patch series incorporates feedback provided from Marton Balint. >> Note that patch 4 in the previous patch series was consolidated into >> patch 3 per Marton's suggestion. > > There's no patch 3 in the series you sent. And you misspelled Marton's > surname in both patches' commit messages. The previous series had four patches. Patches 3/4 of that series were folded into one. Because Patch 1 of the original series had already been accepted it was not included in the new series. Hence patch 3/4 in the previous series became patch 2 in the new series. Yes, I apparently misspelled Marton’s name and then cut/pasted it to the second patch. Will resubmit. Devin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv3 0/2] avdevice/decklink: 10-bit video out and sources/sinks support
Hello all, Below please find several patches which adds support for 10-bit video on output and the "-sources" and"-sinks" argument when specified by ffmpeg.c. This patch series incorporates feedback provided from Marton Balint. Note that patch 4 in the v2 patch series was consolidated into patch 3 per Marton's suggestion. Patch series V3 corrects a misspelling in Marton's name in the commit. If you have any question/concerns, please don't hesitate to reply. Thanks, Devin Heitmueller Devin Heitmueller (2): libavdevice/decklink: add support for -sources and -sinks arguments libavdevice/decklink: add support for 10-bit output for Decklink SDI libavdevice/decklink_common.cpp | 89 +++-- libavdevice/decklink_common.h | 3 +- libavdevice/decklink_dec.cpp| 8 ++- libavdevice/decklink_dec.h | 1 + libavdevice/decklink_dec_c.c| 1 + libavdevice/decklink_enc.cpp| 122 ++-- libavdevice/decklink_enc.h | 1 + libavdevice/decklink_enc_c.c| 1 + 8 files changed, 187 insertions(+), 39 deletions(-) -- 2.13.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv3 2/2] libavdevice/decklink: add support for 10-bit output for Decklink SDI
Can be tested via the following command:
./ffmpeg -i foo.ts -f decklink -vcodec v210 'DeckLink Duo (1)'
Note that the 8-bit support works as it did before, and setting
the pix_fmt isn't required for 10-bit mode. The code defaults to
operating in 8-bit mode when no vcodec is specified, for backward
compatibility.
Updated to reflect feedback from Marton Balint
Signed-off-by: Devin Heitmueller
---
libavdevice/decklink_enc.cpp | 112 ---
1 file changed, 83 insertions(+), 29 deletions(-)
diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 0776741812..81df563b3b 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -44,20 +44,45 @@ extern "C" {
class decklink_frame : public IDeckLinkVideoFrame
{
public:
-decklink_frame(struct decklink_ctx *ctx, AVFrame *avframe) :
- _ctx(ctx), _avframe(avframe), _refs(1) { }
-
-virtual long STDMETHODCALLTYPE GetWidth (void) {
return _avframe->width; }
-virtual long STDMETHODCALLTYPE GetHeight (void) {
return _avframe->height; }
-virtual long STDMETHODCALLTYPE GetRowBytes (void) {
return _avframe->linesize[0] < 0 ? -_avframe->linesize[0] :
_avframe->linesize[0]; }
-virtual BMDPixelFormat STDMETHODCALLTYPE GetPixelFormat(void) {
return bmdFormat8BitYUV; }
-virtual BMDFrameFlags STDMETHODCALLTYPE GetFlags (void) {
return _avframe->linesize[0] < 0 ? bmdFrameFlagFlipVertical :
bmdFrameFlagDefault; }
-virtual HRESULTSTDMETHODCALLTYPE GetBytes (void **buffer)
+decklink_frame(struct decklink_ctx *ctx, AVFrame *avframe, AVCodecID
codec_id, int height, int width) :
+_ctx(ctx), _avframe(avframe), _avpacket(NULL), _codec_id(codec_id),
_height(height), _width(width), _refs(1) { }
+decklink_frame(struct decklink_ctx *ctx, AVPacket *avpacket, AVCodecID
codec_id, int height, int width) :
+_ctx(ctx), _avframe(NULL), _avpacket(avpacket), _codec_id(codec_id),
_height(height), _width(width), _refs(1) { }
+
+virtual long STDMETHODCALLTYPE GetWidth (void) {
return _width; }
+virtual long STDMETHODCALLTYPE GetHeight (void) {
return _height; }
+virtual long STDMETHODCALLTYPE GetRowBytes (void)
+{
+ if (_codec_id == AV_CODEC_ID_WRAPPED_AVFRAME)
+ return _avframe->linesize[0] < 0 ? -_avframe->linesize[0] :
_avframe->linesize[0];
+ else
+ return ((GetWidth() + 47) / 48) * 128;
+}
+virtual BMDPixelFormat STDMETHODCALLTYPE GetPixelFormat(void)
{
-if (_avframe->linesize[0] < 0)
-*buffer = (void *)(_avframe->data[0] + _avframe->linesize[0] *
(_avframe->height - 1));
+if (_codec_id == AV_CODEC_ID_WRAPPED_AVFRAME)
+return bmdFormat8BitYUV;
else
-*buffer = (void *)(_avframe->data[0]);
+return bmdFormat10BitYUV;
+}
+virtual BMDFrameFlags STDMETHODCALLTYPE GetFlags (void)
+{
+ if (_codec_id == AV_CODEC_ID_WRAPPED_AVFRAME)
+ return _avframe->linesize[0] < 0 ? bmdFrameFlagFlipVertical :
bmdFrameFlagDefault;
+ else
+ return bmdFrameFlagDefault;
+}
+
+virtual HRESULTSTDMETHODCALLTYPE GetBytes (void **buffer)
+{
+if (_codec_id == AV_CODEC_ID_WRAPPED_AVFRAME) {
+if (_avframe->linesize[0] < 0)
+*buffer = (void *)(_avframe->data[0] + _avframe->linesize[0] *
(_avframe->height - 1));
+else
+*buffer = (void *)(_avframe->data[0]);
+} else {
+*buffer = (void *)(_avpacket->data);
+}
return S_OK;
}
@@ -71,6 +96,7 @@ public:
int ret = --_refs;
if (!ret) {
av_frame_free(&_avframe);
+av_packet_free(&_avpacket);
delete this;
}
return ret;
@@ -78,6 +104,10 @@ public:
struct decklink_ctx *_ctx;
AVFrame *_avframe;
+AVPacket *_avpacket;
+AVCodecID _codec_id;
+int _height;
+int _width;
private:
std::atomic _refs;
@@ -90,9 +120,11 @@ public:
{
decklink_frame *frame = static_cast(_frame);
struct decklink_ctx *ctx = frame->_ctx;
-AVFrame *avframe = frame->_avframe;
-av_frame_unref(avframe);
+if (frame->_avframe)
+av_frame_unref(frame->_avframe);
+if (frame->_avpacket)
+av_packet_unref(frame->_avpacket);
pthread_mutex_lock(&ctx->mutex);
ctx->frames_buffer_available_spots++;
@@ -118,11 +150,18 @@ static int decklink_setup_video(AVFormatContext *avctx,
AVStream *st)
return -1;
}
-if (c->format != AV_PIX_FMT_UYVY422) {
-av_log(avctx, AV_LOG_ERROR, "Unsupported pixel format!"
- " Only AV_PIX_FMT_UYVY422 is supported.\n");
+if (c->cod
[FFmpeg-devel] [PATCHv3 1/2] libavdevice/decklink: add support for -sources and -sinks arguments
Add support for enumerating the sources/sinks via the ffmpeg
command line options, as opposed to having to create a real pipeline
and use the "-list_devices" option which does exit() after dumping
out the options.
Note that this patch preserves the existing "-list_devices" option,
but now shares common code for the actual enumeration.
Updated to reflect feedback from Marton Balint .
Signed-off-by: Devin Heitmueller
---
libavdevice/decklink_common.cpp | 89 ++---
libavdevice/decklink_common.h | 3 +-
libavdevice/decklink_dec.cpp| 8 +++-
libavdevice/decklink_dec.h | 1 +
libavdevice/decklink_dec_c.c| 1 +
libavdevice/decklink_enc.cpp| 10 -
libavdevice/decklink_enc.h | 1 +
libavdevice/decklink_enc_c.c| 1 +
8 files changed, 104 insertions(+), 10 deletions(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index c782171f2c..61d8ad86a9 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -37,6 +37,7 @@ extern "C" {
#include "libavutil/imgutils.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/bswap.h"
+#include "avdevice.h"
}
#include "decklink_common.h"
@@ -261,24 +262,100 @@ int ff_decklink_set_format(AVFormatContext *avctx,
decklink_direction_t directio
return ff_decklink_set_format(avctx, 0, 0, 0, 0, AV_FIELD_UNKNOWN,
direction, num);
}
-int ff_decklink_list_devices(AVFormatContext *avctx)
+int ff_decklink_list_devices(AVFormatContext *avctx,
+struct AVDeviceInfoList *device_list,
+int show_inputs, int show_outputs)
{
IDeckLink *dl = NULL;
IDeckLinkIterator *iter = CreateDeckLinkIteratorInstance();
+int ret = 0;
+
if (!iter) {
av_log(avctx, AV_LOG_ERROR, "Could not create DeckLink iterator\n");
return AVERROR(EIO);
}
-av_log(avctx, AV_LOG_INFO, "Blackmagic DeckLink devices:\n");
-while (iter->Next(&dl) == S_OK) {
+
+while (ret == 0 && iter->Next(&dl) == S_OK) {
+IDeckLinkOutput *output_config;
+IDeckLinkInput *input_config;
const char *displayName;
+AVDeviceInfo *new_device = NULL;
+int add = 0;
+
ff_decklink_get_display_name(dl, &displayName);
-av_log(avctx, AV_LOG_INFO, "\t'%s'\n", displayName);
-av_free((void *) displayName);
+
+if (show_outputs) {
+if (dl->QueryInterface(IID_IDeckLinkOutput, (void
**)&output_config) == S_OK) {
+output_config->Release();
+add = 1;
+}
+}
+
+if (show_inputs) {
+if (dl->QueryInterface(IID_IDeckLinkInput, (void **)&input_config)
== S_OK) {
+input_config->Release();
+add = 1;
+}
+}
+
+if (add == 1) {
+new_device = (AVDeviceInfo *) av_mallocz(sizeof(AVDeviceInfo));
+if (!new_device) {
+ret = AVERROR(ENOMEM);
+goto next;
+}
+new_device->device_name = av_strdup(displayName);
+if (!new_device->device_name) {
+ret = AVERROR(ENOMEM);
+goto next;
+}
+
+new_device->device_description = av_strdup(displayName);
+if (!new_device->device_description) {
+av_freep(&new_device->device_name);
+ret = AVERROR(ENOMEM);
+goto next;
+}
+
+if ((ret = av_dynarray_add_nofree(&device_list->devices,
+ &device_list->nb_devices,
new_device)) < 0) {
+av_freep(&new_device->device_name);
+av_freep(&new_device->device_description);
+av_freep(&new_device);
+goto next;
+}
+}
+
+next:
+av_freep(&displayName);
dl->Release();
}
iter->Release();
-return 0;
+return ret;
+}
+
+/* This is a wrapper around the ff_decklink_list_devices() which dumps the
+ output to av_log() and exits (for backward compatibility with the
+ "-list_devices" argument). */
+void ff_decklink_list_devices_legacy(AVFormatContext *avctx,
+ int show_inputs, int show_outputs)
+{
+struct AVDeviceInfoList *device_list = NULL;
+int ret;
+
+device_list = (struct AVDeviceInfoList *)
av_mallocz(sizeof(AVDeviceInfoList));
+if (!device_list)
+return;
+
+ret = ff_decklink_list_devices(avctx, device_list, show_inputs,
show_outputs);
+if (ret == 0) {
+av_log(avctx, AV_LOG_INFO, "Blackmagic DeckLink %s devices:\n",
+ show_inputs ? "input" : "output");
+for (int i = 0; i < device_list->nb_devices; i++) {
+av_log(avctx, AV_LOG_INFO, "\t'%s'\n",
device_list->devices[i]->device_name);
+}
+}
+avdevice_free_list_devices(&device_list);
}
int
Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter
Hi,
On Thu, Oct 5, 2017 at 7:52 PM, Michael Niedermayer
wrote:
> On Sat, Sep 30, 2017 at 03:51:41PM +, Ashish Singh wrote:
> > ffmpeg | branch: master | Ashish Singh | Sat Sep
> 16 02:35:58 2017 +0530| [148c8e88c43cfbabd6aee9f01ef30942cee9d359] |
> committer: Ronald S. Bultje
> >
> > avfilter: add vmafmotion filter
> >
> > Signed-off-by: Ashish Singh
> > Signed-off-by: Ronald S. Bultje
> >
> > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=
> 148c8e88c43cfbabd6aee9f01ef30942cee9d359
> > ---
> >
> > Changelog | 1 +
> > doc/filters.texi| 14 ++
> > libavfilter/Makefile| 1 +
> > libavfilter/allfilters.c| 1 +
> > libavfilter/vf_vmafmotion.c | 365 ++
> ++
> > libavfilter/vmaf_motion.h | 58 +++
> > 6 files changed, 440 insertions(+)
> [...]
> > +static av_cold int init(AVFilterContext *ctx)
> > +{
> > +VMAFMotionContext *s = ctx->priv;
> > +
> > +if (s->stats_file_str) {
> > +if (!strcmp(s->stats_file_str, "-")) {
>
> > +s->stats_file = stdout;
>
> Using stdout can interfere with the user application using the filter
>
>
> > +} else {
>
> > +s->stats_file = fopen(s->stats_file_str, "w");
>
> Opening a filter parameter provided string for writing is a dangerous
> way to output data. It allows one with access to the parameters to
> overwrite any writable file
>
> data should only be output in a safe way
>
The same mechanism is present in ssim/psnr filters. I'm open to any
alternative method you suggest. These are only settable using explicit user
interaction (and are disabled by default) so I don't particularly see the
problem.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] FFmpeg 3.4
Hi all if there are no objections i will branch release/3.4 in the next days and make the 3.4 release a few days after that If people prefer a specific name, suggest one now, otherwise i will pick a random one from past suggestions If there are features you want in, please push them to master before the release is branched if there are bug fixes you want in please ensure they end in release/3.4 (eiter via master before branching or backport after) Thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2 2/2] avfilter/vf_fps: add eof_action filter option
On 04.10.2017 23:34, Michael Niedermayer wrote: On Mon, Sep 25, 2017 at 01:31:19PM +0200, Tobias Rapp wrote: Allows to specify the action to be performed when reading the last frame from the internal FIFO buffer. By default the last frame is written to filter output depending on the timestamp rounding method. When using "pass" action the last frame is passed through if input duration has not been reached yet. Examples using an input file with 25Hz, 1.4sec duration: - "fps=fps=1:round=near" generates an output file of 1sec - "fps=fps=1:round=near:eof_action=pass" generates an output file of 2sec Signed-off-by: Tobias Rapp --- doc/filters.texi | 12 libavfilter/version.h | 2 +- libavfilter/vf_fps.c | 14 +- 3 files changed, 26 insertions(+), 2 deletions(-) ok with me assuming noone (maybe nicolas ?) has comments Pushed, thanks for the review. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: Add spherical_mapping command-line option.
Allows spherical mapping metadata to be injected into files.
From 6a86e9766708b9b74e4ae0ec6928a81df4041afc Mon Sep 17 00:00:00 2001
From: Aaron Colwell
Date: Fri, 6 Oct 2017 08:14:15 -0700
Subject: [PATCH] ffmpeg: Add spherical_mapping command-line option.
Allows spherical mapping metadata to be injected into files.
---
fftools/ffmpeg.c | 12 +++-
fftools/ffmpeg.h | 6 ++
fftools/ffmpeg_opt.c | 160 ++-
3 files changed, 176 insertions(+), 2 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 1d248bc269..8c35090b9e 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -3092,6 +3092,10 @@ static int init_output_stream_streamcopy(OutputStream *ost)
const AVPacketSideData *sd_src = &ist->st->side_data[i];
uint8_t *dst_data;
+if ((sd_src->type == AV_PKT_DATA_SPHERICAL && ost->spherical_mapping_overridden) ||
+(sd_src->type == AV_PKT_DATA_STEREO3D && ost->stereo3d_overridden))
+continue;
+
dst_data = av_stream_new_side_data(ost->st, sd_src->type, sd_src->size);
if (!dst_data)
return AVERROR(ENOMEM);
@@ -3528,7 +3532,13 @@ static int init_output_stream(OutputStream *ost, char *error, int error_len)
int i;
for (i = 0; i < ist->st->nb_side_data; i++) {
AVPacketSideData *sd = &ist->st->side_data[i];
-uint8_t *dst = av_stream_new_side_data(ost->st, sd->type, sd->size);
+uint8_t *dst;
+
+if ((sd->type == AV_PKT_DATA_SPHERICAL && ost->spherical_mapping_overridden) ||
+(sd->type == AV_PKT_DATA_STEREO3D && ost->stereo3d_overridden))
+continue;
+
+dst = av_stream_new_side_data(ost->st, sd->type, sd->size);
if (!dst)
return AVERROR(ENOMEM);
memcpy(dst, sd->data, sd->size);
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index f6c76bcc55..91ca6c2926 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -45,6 +45,8 @@
#include "libavutil/hwcontext.h"
#include "libavutil/pixfmt.h"
#include "libavutil/rational.h"
+#include "libavutil/spherical.h"
+#include "libavutil/stereo3d.h"
#include "libavutil/threadmessage.h"
#include "libswresample/swresample.h"
@@ -237,6 +239,8 @@ typedef struct OptionsContext {
intnb_time_bases;
SpecifierOpt *enc_time_bases;
intnb_enc_time_bases;
+SpecifierOpt *spherical_mappings;
+intnb_spherical_mappings;
} OptionsContext;
typedef struct InputFilter {
@@ -487,6 +491,8 @@ typedef struct OutputStream {
int top_field_first;
int rotate_overridden;
double rotate_override_value;
+int spherical_mapping_overridden;
+int stereo3d_overridden;
AVRational frame_aspect_ratio;
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 100fa76e46..4bc5104ce5 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -40,6 +40,8 @@
#include "libavutil/parseutils.h"
#include "libavutil/pixdesc.h"
#include "libavutil/pixfmt.h"
+#include "libavutil/spherical.h"
+#include "libavutil/stereo3d.h"
#define DEFAULT_PASS_LOGFILENAME_PREFIX "ffmpeg2pass"
@@ -1585,12 +1587,158 @@ static void check_streamcopy_filters(OptionsContext *o, AVFormatContext *oc,
}
}
+static int set_spherical_mapping(const char* opt, OutputStream *ost) {
+typedef struct {
+const AVClass* spherical_class;
+int projection;
+
+double yaw;
+double pitch;
+double roll;
+
+int64_t bound_left;
+int64_t bound_top;
+int64_t bound_right;
+int64_t bound_bottom;
+
+int64_t padding;
+
+int stereo_mode;
+} SphericalMappingContext;
+
+#define OFFSET(x) offsetof(SphericalMappingContext, x)
+#define FLAGS AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption opts[] = {
+{ "projection", "projection", OFFSET(projection), AV_OPT_TYPE_INT,
+{ .i64 = -1 }, -1, AV_SPHERICAL_EQUIRECTANGULAR_TILE, FLAGS, "projection" },
+{ "equirectangular", "equirectangular projection", 0, AV_OPT_TYPE_CONST,
+{ .i64 = AV_SPHERICAL_EQUIRECTANGULAR }, INT_MIN, INT_MAX, FLAGS, "projection" },
+{ "cubemap", "cubemap projection", 0, AV_OPT_TYPE_CONST,
+{ .i64 = AV_SPHERICAL_CUBEMAP }, INT_MIN, INT_MAX, FLAGS, "projection" },
+{ "equirectangular_tile", "tiled equirectangular projection", 0, AV_OPT_TYPE_CONST,
+{ .i64 = AV_SPHERICAL_EQUIRECTANGULAR_TILE }, INT_MIN, INT_MAX, FLAGS, "projection" },
+{ "yaw", "initial yaw orientation in degrees", OFFSET(yaw), AV_OPT_TYPE_DOUBLE,
+{ .dbl = 0.0 }, -180.0, 180.0, FLAGS },
+{ "pitch", "initial pitch orientation in degrees", OFFSET(pitch), AV_OPT_TYPE_DOUBLE,
+{ .dbl = 0.0 }, -90.0, 90.0, FLAGS },
+{ "roll", "initial roll orientati
[FFmpeg-devel] [PATCH] JPEG2000: SSE optimisation of DWT decoding
From: Maxime Taisant
---
libavcodec/jpeg2000dwt.c | 45 +-
libavcodec/jpeg2000dwt.h |5 +
libavcodec/x86/jpeg2000dsp.asm| 1339 +
libavcodec/x86/jpeg2000dsp_init.c | 119
tests/checkasm/jpeg2000dsp.c |1 +
5 files changed, 1496 insertions(+), 13 deletions(-)
diff --git a/libavcodec/jpeg2000dwt.c b/libavcodec/jpeg2000dwt.c
index 55dd5e89b5..1a0c3fc034 100644
--- a/libavcodec/jpeg2000dwt.c
+++ b/libavcodec/jpeg2000dwt.c
@@ -30,6 +30,7 @@
#include "libavutil/mem.h"
#include "jpeg2000dwt.h"
#include "internal.h"
+#include "libavutil/timer.h"
/* Defines for 9/7 DWT lifting parameters.
* Parameters are in float. */
@@ -558,7 +559,7 @@ int ff_jpeg2000_dwt_init(DWTContext *s, int border[2][2],
}
switch (type) {
case FF_DWT97:
-s->f_linebuf = av_malloc_array((maxlen + 12), sizeof(*s->f_linebuf));
+s->f_linebuf = av_malloc_array(4*(maxlen + 12), sizeof(*s->f_linebuf));
if (!s->f_linebuf)
return AVERROR(ENOMEM);
break;
@@ -575,6 +576,11 @@ int ff_jpeg2000_dwt_init(DWTContext *s, int border[2][2],
default:
return -1;
}
+
+s->sse = 0;
+if (ARCH_X86)
+ff_jpeg2000dwt_init_x86(s, type);
+
return 0;
}
@@ -601,18 +607,31 @@ int ff_dwt_decode(DWTContext *s, void *t)
if (s->ndeclevels == 0)
return 0;
-switch (s->type) {
-case FF_DWT97:
-dwt_decode97_float(s, t);
-break;
-case FF_DWT97_INT:
-dwt_decode97_int(s, t);
-break;
-case FF_DWT53:
-dwt_decode53(s, t);
-break;
-default:
-return -1;
+switch(s->type){
+case FF_DWT97:
+if (s->sse)
+//{
+//START_TIMER
+dwt_decode97_float_sse(s, t);
+//STOP_TIMER("dwt_decode97_float_sse");
+//}
+else
+//{
+//START_TIMER
+dwt_decode97_float(s, t);
+//STOP_TIMER("dwt_decode97_float");
+//}
+/*{
+START_TIMER
+STOP_TIMER("decode_NULL");
+}*/
+break;
+case FF_DWT97_INT:
+dwt_decode97_int(s, t); break;
+case FF_DWT53:
+dwt_decode53(s, t); break;
+default:
+return -1;
}
return 0;
}
diff --git a/libavcodec/jpeg2000dwt.h b/libavcodec/jpeg2000dwt.h
index 718d183ac1..622a404b79 100644
--- a/libavcodec/jpeg2000dwt.h
+++ b/libavcodec/jpeg2000dwt.h
@@ -48,6 +48,7 @@ typedef struct DWTContext {
uint8_t type;///< 0 for 9/7; 1 for 5/3
int32_t *i_linebuf; ///< int buffer used by transform
float *f_linebuf; ///< float buffer used by transform
+int sse;
} DWTContext;
/**
@@ -65,4 +66,8 @@ int ff_dwt_decode(DWTContext *s, void *t);
void ff_dwt_destroy(DWTContext *s);
+void dwt_decode97_float_sse(DWTContext *s, float *t);
+
+void ff_jpeg2000dwt_init_x86(DWTContext *s, int type);
+
#endif /* AVCODEC_JPEG2000DWT_H */
diff --git a/libavcodec/x86/jpeg2000dsp.asm b/libavcodec/x86/jpeg2000dsp.asm
index 56b5fbd606..b5d5b9a04b 100644
--- a/libavcodec/x86/jpeg2000dsp.asm
+++ b/libavcodec/x86/jpeg2000dsp.asm
@@ -2,6 +2,7 @@
;* SIMD-optimized JPEG2000 DSP functions
;* Copyright (c) 2014 Nicolas Bertrand
;* Copyright (c) 2015 James Almer
+;* Copyright (c) 2017 Maxime Taisant
;*
;* This file is part of FFmpeg.
;*
@@ -29,6 +30,16 @@ pf_ict1: times 8 dd 0.34413
pf_ict2: times 8 dd 0.71414
pf_ict3: times 8 dd 1.772
+F_LFTG_K: dd 1.230174104914001
+F_LFTG_X: dd 0.812893066115961
+
+F_LFTG_ALPHA: times 8 dd 1.586134342059924
+F_LFTG_BETA: times 8 dd 0.052980118572961
+F_LFTG_GAMMA: times 8 dd 0.882911075530934
+F_LFTG_DELTA: times 8 dd 0.443506852043971
+
+TWO: dd 2.0
+
SECTION .text
;***
@@ -142,3 +153,1331 @@ RCT_INT
INIT_YMM avx2
RCT_INT
%endif
+
+;***
+; ff_sr_ld97_float_(float *line, int i0, int i1)
+;***
+%macro SR1D97FLOAT 1
+cglobal sr_1d97_float, 3, 5, %1, line, i0, i1, j0, j1
+mov j0q, i0q
+mov j1q, i1q
+add j0q, 1
+cmp j1q, j0q
+jg %%extend
+sub j0q, 2
+jnz %%else
+movss m0, [lineq+4]
+movss m1, [F_LFTG_K]
+movss m2, [TWO]
+divss m1, m2
+mulss m0, m1
+movss [lineq+4], m0
+jmp %%end
+
+%%else:
+movss m0, [lineq]
+movss m1, [F_LFTG_X]
+mulss m0, m1
+movss [lineq], m0
+jmp %%end
+
+%%extend:
+shl i0d, 2
+shl i1d, 2
+mov j0q, i0q
+mov j1q, i1q
+movups m0, [lineq+j0q+4]
+shufps m0, m0, q0123
+movups [lineq+j0q-16], m0
+movups m0, [lineq+j1q-20]
+shufps m0, m0, q0123
+mo
[FFmpeg-devel] [PATCH] swscale: more accurate DITHER_COPY macro for full and limited range
Fixed DITHER_COPY macro (only C code), updated FATE tests.
PSNR in tests that needed update goes from 50 to 999.99 -- the quality is there.
Please review.
Mateusz
From d870ba10aa4b3520fc30215fbbd57565faa13df4 Mon Sep 17 00:00:00 2001
From: Mateusz
Date: Fri, 6 Oct 2017 16:49:54 +0200
Subject: [PATCH] swscale: more accurate DITHER_COPY macro for full and limited
range
---
libswscale/swscale_unscaled.c | 73 --
tests/ref/vsynth/vsynth1-ffvhuff420p12 | 4 +-
tests/ref/vsynth/vsynth1-vc2-420p10| 4 +-
tests/ref/vsynth/vsynth1-vc2-420p12| 4 +-
tests/ref/vsynth/vsynth2-ffvhuff420p12 | 4 +-
tests/ref/vsynth/vsynth2-vc2-420p10| 4 +-
tests/ref/vsynth/vsynth2-vc2-420p12| 4 +-
tests/ref/vsynth/vsynth3-ffvhuff420p12 | 4 +-
tests/ref/vsynth/vsynth_lena-ffvhuff420p12 | 4 +-
tests/ref/vsynth/vsynth_lena-vc2-420p10| 4 +-
tests/ref/vsynth/vsynth_lena-vc2-420p12| 4 +-
11 files changed, 58 insertions(+), 55 deletions(-)
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index ef36aec..5d81cd5 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -110,24 +110,6 @@ DECLARE_ALIGNED(8, static const uint8_t,
dithers)[8][8][8]={
{ 112, 16,104, 8,118, 22,110, 14,},
}};
-static const uint16_t dither_scale[15][16]={
-{2,3,3,5,5,5,5,5,5,5,5,5,
5,5,5,5,},
-{2,3,7,7, 13, 13, 25, 25, 25, 25, 25, 25,
25, 25, 25, 25,},
-{3,3,4, 15, 15, 29, 57, 57, 57, 113, 113, 113,
113, 113, 113, 113,},
-{3,4,4,5, 31, 31, 61, 121, 241, 241, 241, 241,
481, 481, 481, 481,},
-{3,4,5,5,6, 63, 63, 125, 249, 497, 993, 993,
993, 993, 993, 1985,},
-{3,5,6,6,6,7, 127, 127, 253, 505, 1009, 2017,
4033, 4033, 4033, 4033,},
-{3,5,6,7,7,7,8, 255, 255, 509, 1017, 2033,
4065, 8129,16257,16257,},
-{3,5,6,8,8,8,8,9, 511, 511, 1021, 2041,
4081, 8161,16321,32641,},
-{3,5,7,8,9,9,9,9, 10, 1023, 1023, 2045,
4089, 8177,16353,32705,},
-{3,5,7,8, 10, 10, 10, 10, 10, 11, 2047, 2047,
4093, 8185,16369,32737,},
-{3,5,7,8, 10, 11, 11, 11, 11, 11, 12, 4095,
4095, 8189,16377,32753,},
-{3,5,7,9, 10, 12, 12, 12, 12, 12, 12, 13,
8191, 8191,16381,32761,},
-{3,5,7,9, 10, 12, 13, 13, 13, 13, 13, 13,
14,16383,16383,32765,},
-{3,5,7,9, 10, 12, 14, 14, 14, 14, 14, 14,
14, 15,32767,32767,},
-{3,5,7,9, 11, 12, 14, 15, 15, 15, 15, 15,
15, 15, 16,65535,},
-};
-
static void fillPlane(uint8_t *plane, int stride, int width, int height, int y,
uint8_t val)
@@ -1502,24 +1484,45 @@ static int packedCopyWrapper(SwsContext *c, const
uint8_t *src[],
}
#define DITHER_COPY(dst, dstStride, src, srcStride, bswap, dbswap)\
-uint16_t scale= dither_scale[dst_depth-1][src_depth-1];\
-int shift= src_depth-dst_depth + dither_scale[src_depth-2][dst_depth-1];\
-for (i = 0; i < height; i++) {\
-const uint8_t *dither= dithers[src_depth-9][i&7];\
-for (j = 0; j < length-7; j+=8){\
-dst[j+0] = dbswap((bswap(src[j+0]) + dither[0])*scale>>shift);\
-dst[j+1] = dbswap((bswap(src[j+1]) + dither[1])*scale>>shift);\
-dst[j+2] = dbswap((bswap(src[j+2]) + dither[2])*scale>>shift);\
-dst[j+3] = dbswap((bswap(src[j+3]) + dither[3])*scale>>shift);\
-dst[j+4] = dbswap((bswap(src[j+4]) + dither[4])*scale>>shift);\
-dst[j+5] = dbswap((bswap(src[j+5]) + dither[5])*scale>>shift);\
-dst[j+6] = dbswap((bswap(src[j+6]) + dither[6])*scale>>shift);\
-dst[j+7] = dbswap((bswap(src[j+7]) + dither[7])*scale>>shift);\
+unsigned shift= src_depth-dst_depth, tmp;\
+if (shiftonly) {\
+for (i = 0; i < height; i++) {\
+const uint8_t *dither= dithers[shift-1][i&7];\
+for (j = 0; j < length-7; j+=8) {\
+tmp = (bswap(src[j+0]) + dither[0])>>shift; dst[j+0] =
dbswap(tmp - (tmp>>dst_depth));\
+tmp = (bswap(src[j+1]) + dither[1])>>shift; dst[j+1] =
dbswap(tmp - (tmp>>dst_depth));\
+tmp = (bswap(src[j+2]) + dither[2])>>shift; dst[j+2] =
dbswap(tmp - (tmp>>dst_depth));\
+tmp = (bswap(src[j+3]) + dither[3])>>shift; dst[j+3] =
dbswap(tmp - (tmp>>dst_depth));\
+tmp = (bswap(src[j+4]) + dither[4])>>shift; dst[j+4] =
dbswap(tmp - (tmp>>dst_depth));\
+tmp = (bswap(src[j+5]) + dither[5])>>shift; dst[j+5] =
dbswap(tmp - (tmp>>dst_depth));\
+tmp = (bswap(src[j+6]
Re: [FFmpeg-devel] [PATCH] ffmpeg: Add spherical_mapping command-line option.
On 06/10/17 16:19, Aaron Colwell wrote: > Allows spherical mapping metadata to be injected into files. > > From 6a86e9766708b9b74e4ae0ec6928a81df4041afc Mon Sep 17 00:00:00 2001 > From: Aaron Colwell > Date: Fri, 6 Oct 2017 08:14:15 -0700 > Subject: [PATCH] ffmpeg: Add spherical_mapping command-line option. > > Allows spherical mapping metadata to be injected into files. > --- > fftools/ffmpeg.c | 12 +++- > fftools/ffmpeg.h | 6 ++ > fftools/ffmpeg_opt.c | 160 > ++- > 3 files changed, 176 insertions(+), 2 deletions(-) Perhaps I'm missing something about this patch, but I'm not seeing why this should be added as a set of special options to ffmpeg.c. A bsf in libavcodec which edits or replaces the packet side data would seem to be a more generally useful way to achieve the same result. (E.g. it would also be usable in other applications, and it would be able to edit it on input as well as output.) - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Add spherical_mapping command-line option.
Hi Mark, You aren't missing anything. I haven't really used bsf's so it didn't occur to me to use them. I'll take a look. Thanks for the suggestion. Aaron On Fri, Oct 6, 2017 at 8:53 AM Mark Thompson wrote: > On 06/10/17 16:19, Aaron Colwell wrote: > > Allows spherical mapping metadata to be injected into files. > > > > From 6a86e9766708b9b74e4ae0ec6928a81df4041afc Mon Sep 17 00:00:00 2001 > > From: Aaron Colwell > > Date: Fri, 6 Oct 2017 08:14:15 -0700 > > Subject: [PATCH] ffmpeg: Add spherical_mapping command-line option. > > > > Allows spherical mapping metadata to be injected into files. > > --- > > fftools/ffmpeg.c | 12 +++- > > fftools/ffmpeg.h | 6 ++ > > fftools/ffmpeg_opt.c | 160 > ++- > > 3 files changed, 176 insertions(+), 2 deletions(-) > > Perhaps I'm missing something about this patch, but I'm not seeing why > this should be added as a set of special options to ffmpeg.c. A bsf in > libavcodec which edits or replaces the packet side data would seem to be a > more generally useful way to achieve the same result. (E.g. it would also > be usable in other applications, and it would be able to edit it on input > as well as output.) > > - Mark > ___ > 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] lavf: add more beep options to sine asrc
From: Michael Bradshaw
Signed-off-by: Michael Bradshaw
---
doc/filters.texi| 13 -
libavfilter/asrc_sine.c | 17 +
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 57189c77b0..ec1c335950 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4624,7 +4624,18 @@ Set the carrier frequency. Default is 440 Hz.
@item beep_factor, b
Enable a periodic beep every second with frequency @var{beep_factor} times
-the carrier frequency. Default is 0, meaning the beep is disabled.
+the carrier frequency. Default is 0, meaning the beep is disabled. If
+@var{frequency} is 0, this value is interpreted as the beep frequency (in
Hertz)
+(rather than a multiplier of the @var{frequency}).
+
+@item beep_delay
+The delay for the first beep, in seconds. Default is 0.
+
+@item beep_period
+The time beriod between two beeps, in seconds. Default is 1.
+
+@item beep_duration
+The duration of a beep, in seconds. Default is 0.04.
@item sample_rate, r
Specify the sample rate, default is 44100.
diff --git a/libavfilter/asrc_sine.c b/libavfilter/asrc_sine.c
index 3a87210b4b..643952792f 100644
--- a/libavfilter/asrc_sine.c
+++ b/libavfilter/asrc_sine.c
@@ -32,6 +32,9 @@ typedef struct SineContext {
const AVClass *class;
double frequency;
double beep_factor;
+double beep_delay;
+double beep_period_opt;
+double beep_duration;
char *samples_per_frame;
AVExpr *samples_per_frame_expr;
int sample_rate;
@@ -71,6 +74,9 @@ static const AVOption sine_options[] = {
OPT_DBL("f", frequency,440, 0, DBL_MAX, "set
the sine frequency",),
OPT_DBL("beep_factor", beep_factor,0, 0, DBL_MAX, "set
the beep frequency factor",),
OPT_DBL("b", beep_factor,0, 0, DBL_MAX, "set
the beep frequency factor",),
+OPT_DBL("beep_delay",beep_delay, 0, 0, DBL_MAX, "set
the delay for the first beep",),
+OPT_DBL("beep_period", beep_period_opt,1, DBL_MIN, DBL_MAX,
"set the gap between beeps",),
+OPT_DBL("beep_duration", beep_duration, 0.04, DBL_MIN, DBL_MAX,
"set the duration of a beep",),
OPT_INT("sample_rate", sample_rate,44100, 1, INT_MAX, "set
the sample rate",),
OPT_INT("r", sample_rate,44100, 1, INT_MAX, "set
the sample rate",),
OPT_DUR("duration", duration, 0, 0, INT64_MAX, "set
the audio duration",),
@@ -152,10 +158,13 @@ static av_cold int init(AVFilterContext *ctx)
make_sin_table(sine->sin);
if (sine->beep_factor) {
-sine->beep_period = sine->sample_rate;
-sine->beep_length = sine->beep_period / 25;
-sine->dphi_beep = ldexp(sine->beep_factor * sine->frequency, 32) /
- sine->sample_rate + 0.5;
+unsigned beep_start = sine->beep_delay * sine->sample_rate;
+double beep_frequency = (sine->frequency ? sine->frequency : 1.0) *
+sine->beep_factor;
+sine->beep_period = sine->beep_period_opt * sine->sample_rate;
+sine->beep_index = (sine->beep_period - beep_start) %
sine->beep_period;
+sine->beep_length = sine->beep_duration * sine->sample_rate;
+sine->dphi_beep = ldexp(beep_frequency, 32) / sine->sample_rate + 0.5;
}
ret = av_expr_parse(&sine->samples_per_frame_expr,
--
2.13.5 (Apple Git-94)
___
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
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). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Add spherical_mapping command-line option.
On 06/10/17 17:10, Aaron Colwell wrote: > On Fri, Oct 6, 2017 at 8:53 AM Mark Thompson wrote: >> On 06/10/17 16:19, Aaron Colwell wrote: >>> Allows spherical mapping metadata to be injected into files. >>> >>> From 6a86e9766708b9b74e4ae0ec6928a81df4041afc Mon Sep 17 00:00:00 2001 >>> From: Aaron Colwell >>> Date: Fri, 6 Oct 2017 08:14:15 -0700 >>> Subject: [PATCH] ffmpeg: Add spherical_mapping command-line option. >>> >>> Allows spherical mapping metadata to be injected into files. >>> --- >>> fftools/ffmpeg.c | 12 +++- >>> fftools/ffmpeg.h | 6 ++ >>> fftools/ffmpeg_opt.c | 160 >> ++- >>> 3 files changed, 176 insertions(+), 2 deletions(-) >> >> Perhaps I'm missing something about this patch, but I'm not seeing why >> this should be added as a set of special options to ffmpeg.c. A bsf in >> libavcodec which edits or replaces the packet side data would seem to be a >> more generally useful way to achieve the same result. (E.g. it would also >> be usable in other applications, and it would be able to edit it on input >> as well as output.) > > You aren't missing anything. I haven't really used bsf's so it didn't occur > to me to use them. I'll take a look. Thanks for the suggestion. Having looked a little further I suspect this doesn't quite work right now. The output BSFs do not run on the first packet before the header is written, and AVCodecParameters does not carry the global side data - that means the edited side data won't be available at the right moment for global headers (it would be available per-packet, but the actual formats need it per-stream). I'm not sure how hard that would be to fix. - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavfi/avfilter.c: Correct guess_status_pts to account for differing link timebases.
Signed-off-by: Sasi Inguva
---
libavfilter/avfilter.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index 58917ed445..f0f849b326 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -427,19 +427,19 @@ int ff_request_frame(AVFilterLink *link)
return 0;
}
-static int64_t guess_status_pts(AVFilterContext *ctx, int status)
+static int64_t guess_status_pts(AVFilterContext *ctx, int status, AVRational
link_time_base)
{
unsigned i;
int64_t r = INT64_MAX;
for (i = 0; i < ctx->nb_inputs; i++)
if (ctx->inputs[i]->status_out == status)
-r = FFMIN(r, ctx->inputs[i]->current_pts);
+r = FFMIN(r, av_rescale_q(ctx->inputs[i]->current_pts,
ctx->inputs[i]->time_base, link_time_base));
if (r < INT64_MAX)
return r;
av_log(ctx, AV_LOG_WARNING, "EOF timestamp not reliable\n");
for (i = 0; i < ctx->nb_inputs; i++)
-r = FFMIN(r, ctx->inputs[i]->status_in_pts);
+r = FFMIN(r, av_rescale_q(ctx->inputs[i]->status_in_pts,
ctx->inputs[i]->time_base, link_time_base));
if (r < INT64_MAX)
return r;
return AV_NOPTS_VALUE;
@@ -458,7 +458,7 @@ static int ff_request_frame_to_filter(AVFilterLink *link)
ret = ff_request_frame(link->src->inputs[0]);
if (ret < 0) {
if (ret != AVERROR(EAGAIN) && ret != link->status_in)
-ff_avfilter_link_set_in_status(link, ret,
guess_status_pts(link->src, ret));
+ff_avfilter_link_set_in_status(link, ret,
guess_status_pts(link->src, ret, link->time_base));
if (ret == AVERROR_EOF)
ret = 0;
}
--
2.14.2.920.gcf0c67979c-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/avfilter.c: Correct guess_status_pts to account for differing link timebases.
2017-10-06 10:01 GMT+02:00 Nicolas George :
> Le quartidi 14 vendémiaire, an CCXXVI, Sasi Inguva a écrit :
> > Signed-off-by: Sasi Inguva
> > ---
> > libavfilter/avfilter.c | 16
> > 1 file changed, 8 insertions(+), 8 deletions(-)
>
> You are right, this change is needed. Thanks for spotting it and the
> patch.
>
> >
> > diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> > index 58917ed445..ec7dfc0bd3 100644
> > --- a/libavfilter/avfilter.c
> > +++ b/libavfilter/avfilter.c
> > @@ -427,19 +427,19 @@ int ff_request_frame(AVFilterLink *link)
> > return 0;
> > }
> >
>
> > -static int64_t guess_status_pts(AVFilterContext *ctx, int status)
> > +static int64_t guess_status_pts_from_src(AVFilterLink *link, int
> status)
>
> I would prefer if you just added a "AVRational time_base" parameter.
> With this version, the code has "link->" indirections all over the
> place, that lowers the readability.
>
> > {
> > unsigned i;
> > int64_t r = INT64_MAX;
> >
> > -for (i = 0; i < ctx->nb_inputs; i++)
> > -if (ctx->inputs[i]->status_out == status)
> > -r = FFMIN(r, ctx->inputs[i]->current_pts);
> > +for (i = 0; i < link->src->nb_inputs; i++)
> > +if (link->src->inputs[i]->status_out == status)
> > + r = FFMIN(r, av_rescale_q(link->src->inputs[i]->current_pts,
> link->src->inputs[i]->time_base, link->time_base));
> > if (r < INT64_MAX)
> > return r;
> > -av_log(ctx, AV_LOG_WARNING, "EOF timestamp not reliable\n");
> > -for (i = 0; i < ctx->nb_inputs; i++)
> > -r = FFMIN(r, ctx->inputs[i]->status_in_pts);
> > +av_log(link->src, AV_LOG_WARNING, "EOF timestamp not reliable\n");
> > +for (i = 0; i < link->src->nb_inputs; i++)
> > + r = FFMIN(r, av_rescale_q(link->src->inputs[i]->status_in_pts,
> link->src->inputs[i]->time_base, link->time_base));
> > if (r < INT64_MAX)
> > return r;
> > return AV_NOPTS_VALUE;
> > @@ -458,7 +458,7 @@ static int ff_request_frame_to_filter(AVFilterLink
> *link)
> > ret = ff_request_frame(link->src->inputs[0]);
> > if (ret < 0) {
> > if (ret != AVERROR(EAGAIN) && ret != link->status_in)
> > -ff_avfilter_link_set_in_status(link, ret,
> guess_status_pts(link->src, ret));
> > +ff_avfilter_link_set_in_status(link, ret,
> guess_status_pts_from_src(link, ret));
> > if (ret == AVERROR_EOF)
> > ret = 0;
> > }
>
It would be great if this fix will find its way into FFmpeg 3.4.
Thank you,
Thomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI
From: Devin Heitmueller
Hook in libklvanc and use it for output of EIA-708 captions over
SDI. The bulk of this patch is just general support for ancillary
data for the Decklink SDI module - the real work for construction
of the EIA-708 CDP and VANC line construction is done by libklvanc.
Libklvanc can be found at: https://github.com/stoth68000/libklvanc
Signed-off-by: Devin Heitmueller
---
configure | 3 ++
libavcodec/v210enc.c | 8 +++
libavdevice/decklink_common.h | 1 +
libavdevice/decklink_enc.cpp | 113 +++---
4 files changed, 119 insertions(+), 6 deletions(-)
diff --git a/configure b/configure
index 391c141e7a..18647896b1 100755
--- a/configure
+++ b/configure
@@ -238,6 +238,7 @@ External library support:
--enable-libgsm enable GSM de/encoding via libgsm [no]
--enable-libiec61883 enable iec61883 via libiec61883 [no]
--enable-libilbc enable iLBC de/encoding via libilbc [no]
+ --enable-libklvanc enable Kernel Labs VANC processing [no]
--enable-libkvazaar enable HEVC encoding via libkvazaar [no]
--enable-libmodplug enable ModPlug via libmodplug [no]
--enable-libmp3lame enable MP3 encoding via libmp3lame [no]
@@ -1603,6 +1604,7 @@ EXTERNAL_LIBRARY_LIST="
libgsm
libiec61883
libilbc
+libklvanc
libkvazaar
libmodplug
libmp3lame
@@ -6027,6 +6029,7 @@ enabled libx264 && { use_pkg_config libx264
x264 "stdint.h x264.h" x26
enabled libx265 && require_pkg_config libx265 x265 x265.h
x265_api_get &&
require_cpp_condition x265.h "X265_BUILD >= 68"
enabled libxavs && require libxavs "stdint.h xavs.h"
xavs_encoder_encode -lxavs
+enabled libklvanc && require libklvanc libklvanc/vanc.h
vanc_context_create -lklvanc
enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore
enabled libzimg && require_pkg_config libzimg "zimg >= 2.3.0" zimg.h
zimg_get_api_version
enabled libzmq&& require_pkg_config libzmq libzmq zmq.h zmq_ctx_new
diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index a6afbbfc41..44cc3c5c81 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -123,6 +123,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
int aligned_width = ((avctx->width + 47) / 48) * 48;
int stride = aligned_width * 8 / 3;
int line_padding = stride - ((avctx->width * 8 + 11) / 12) * 4;
+AVFrameSideData *side_data = NULL;
int h, w, ret;
uint8_t *dst;
@@ -233,6 +234,13 @@ static int encode_frame(AVCodecContext *avctx, AVPacket
*pkt,
}
}
+side_data = av_frame_get_side_data(pic, AV_FRAME_DATA_A53_CC);
+if (side_data && side_data->size) {
+uint8_t* buf = av_packet_new_side_data(pkt, AV_PKT_DATA_A53_CC,
side_data->size);
+if (buf)
+memcpy(buf, side_data->data, side_data->size);
+}
+
pkt->flags |= AV_PKT_FLAG_KEY;
*got_packet = 1;
return 0;
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 6b2525fb53..285a244000 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -78,6 +78,7 @@ struct decklink_ctx {
AVStream *audio_st;
AVStream *video_st;
AVStream *teletext_st;
+uint16_t cdp_sequence_num;
/* Options */
int list_devices;
diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 81df563b3b..3049e936a9 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -38,16 +38,20 @@ extern "C" {
#include "decklink_common.h"
#include "decklink_enc.h"
-
+#if CONFIG_LIBKLVANC
+#include "libklvanc/vanc.h"
+#include "libklvanc/vanc-lines.h"
+#include "libklvanc/pixels.h"
+#endif
/* DeckLink callback class declaration */
class decklink_frame : public IDeckLinkVideoFrame
{
public:
decklink_frame(struct decklink_ctx *ctx, AVFrame *avframe, AVCodecID
codec_id, int height, int width) :
-_ctx(ctx), _avframe(avframe), _avpacket(NULL), _codec_id(codec_id),
_height(height), _width(width), _refs(1) { }
+_ctx(ctx), _avframe(avframe), _avpacket(NULL), _codec_id(codec_id),
_ancillary(NULL), _height(height), _width(width), _refs(1) { }
decklink_frame(struct decklink_ctx *ctx, AVPacket *avpacket, AVCodecID
codec_id, int height, int width) :
-_ctx(ctx), _avframe(NULL), _avpacket(avpacket), _codec_id(codec_id),
_height(height), _width(width), _refs(1) { }
+_ctx(ctx), _avframe(NULL), _avpacket(avpacket), _codec_id(codec_id),
_ancillary(NULL), _height(height), _width(width), _refs(1) { }
virtual long STDMETHODCALLTYPE GetWidth (void) {
return _width; }
virtual long STDMETHODCALLTYPE GetHeight (void) {
return _height; }
@@ -87,8 +91,13 @@ public:
}
virtual HRESULT STDMETHODCALLTYPE GetTimecode
Re: [FFmpeg-devel] [PATCH]lavc/h264:Only check x264_build if it was set
On Thu, Oct 5, 2017 at 8:31 AM, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes ticket #6717. > > Please comment, Carl Eugen Signed numbers are converted to unsigned when compared to unsigned numbers which means -1 becomes UINT_MAX so this patch shouldn't actually change anything. #6717 is probably unfixable without breaking something else. Old x264 versions produced non-spec-compliant output in the case of 4:4:4 + cabac + 8x8dct, and old libavcodec versions had the same bug on the decoder side which is now fixed to handle spec-compliant files. libavcodec supports decoding older broken files when it detects them in order to avoid breaking backwards-compatibility, but they can't be detected as such if someone removed the x264 SEI. tl;dr; #6717 is one of the reasons why messing with SEI messages is generally a bad idea unless you know what you're doing. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/h264:Only check x264_build if it was set
On Fri, Oct 6, 2017 at 6:54 PM, Henrik Gramner wrote: > On Thu, Oct 5, 2017 at 8:31 AM, Carl Eugen Hoyos wrote: >> Hi! >> >> Attached patch fixes ticket #6717. >> >> Please comment, Carl Eugen > > Signed numbers are converted to unsigned when compared to unsigned > numbers which means -1 becomes UINT_MAX so this patch shouldn't > actually change anything. > > #6717 is probably unfixable without breaking something else. Old x264 > versions produced non-spec-compliant output in the case of 4:4:4 + > cabac + 8x8dct, and old libavcodec versions had the same bug on the > decoder side which is now fixed to handle spec-compliant files. > > libavcodec supports decoding older broken files when it detects them > in order to avoid breaking backwards-compatibility, but they can't be > detected as such if someone removed the x264 SEI. > > tl;dr; #6717 is one of the reasons why messing with SEI messages is > generally a bad idea unless you know what you're doing. Its unfortunate that the CABAC change causes entire bitstream destruction. I don't suppose its in any way feasible to somehow detect the difference somehow, or re-try if it failed? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/wmaprodec: support multichannel XMA stream configurations
On 10/5/2017 7:29 PM, Banana M. wrote: > Here are samples of many stream configurations, generated with Microsoft's > encoder: > https://mega.nz/#!aQRUnTIT!gWUAfGNLIP62VKV2JEOGoyQ1jbVc3M7_qu7ChXQwb7w > > For real XMA used in games, I've only seen 2ch+..+2ch+1/2ch (usual, what > FFmpeg supported before) and 1ch+..+1ch (rare, what motivates this patch). > This adds support for all possible combinations though. > > I don't know enough about FATE to set up tests so I hope somebody could > help, as the learning curve seems steep. It's not hard. If you're already familiar with Makefile recipes it's a matter of adding a few targets using the already defined testing functions that better suit your needs (decoding, codec copy, etc). See the apng.mak file, which is as simple as it gets. It defines two targets, fate-apng-clock and fate-apng-osample, makes them be part of the list FATE_SAMPLES_FFMPEG and use the fate function framecrc() with the argument "-i INPUT_FILE". This, at the time of running the test, will expand into "ffmpeg -i INPUT_FILE -flags +bitexact -fflags +bitexact -f framecrc -". Command line convenience fate functions like framecrc() are not always needed, for that matter. You can call ffmpeg directly as well. In the case of tests that require decoding to float formats (most lossy decoders, including wmapro and xma1/2), since you can't test bitexactness you need to compare the decoded output during the test with a "known good" reference decoded output. This is what atrac.mak does with the pcm() command line function and the oneoff() comparison function. To create the reference output if it doesn't already exist, you simply run the test with GEN=1 from the command line, which will also place the reference files in the samples folder for you if they are decoded samples. For those, it's also best to create them using a x86_32 build of ffmpeg and running the test with CPUFLAGS=0. Keep in mind that raw pcm audio weighs a lot, so if possible, the total decoded frames should be no more than 3 or so, especially for multistream samples. You can do this with the -frames:a ffmpeg output option if the source files have several more frames. The available functions are in fate-run.sh. Some are command line (CMD) functions to run ffmpeg/ffprobe with specific arguments, like framecrc(), and others are to compare output (CMP), like oneoff(). But for your needs, copying what atrac.mak and the "lossy" set of tests from dca.mak do is enough. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/h264:Only check x264_build if it was set
2017-10-06 18:54 GMT+02:00 Henrik Gramner : > On Thu, Oct 5, 2017 at 8:31 AM, Carl Eugen Hoyos wrote: >> Hi! >> >> Attached patch fixes ticket #6717. >> >> Please comment, Carl Eugen > > Signed numbers are converted to unsigned when compared to unsigned > numbers which means -1 becomes UINT_MAX so this patch shouldn't > actually change anything. Thank you both for pointing this out! > #6717 is probably unfixable without breaking something else. I believe an option to force the work-around should at least be discussed. Do you already know how exactly the SEI was removed? Can this happen by accident? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: fix extracting luma
On Wed, 4 Oct 2017, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavdevice/decklink_dec.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index f496a58059..7ac04375d9 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -138,7 +138,7 @@ static int check_vanc_parity_checksum(uint16_t *buf, int
len, uint16_t checksum)
static void extract_luma_from_v210(uint16_t *dst, const uint8_t *src, int width)
{
int i;
-for (i = 0; i < width / 3; i += 3) {
+for (i = 0; i < width / 3; i++) {
*dst++ = (src[1] >> 2) + ((src[2] & 15) << 6);
*dst++ = src[4] + ((src[5] & 3) << 8);
*dst++ = (src[6] >> 4) + ((src[7] & 63) << 4);
Pushed.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: always init output stream before reaping filters
On Wed, 4 Oct 2017, Marton Balint wrote:
Otherwise the frame size of the codec is not set in the buffersink.
Fixes ticket #6603 and the following simpler case:
ffmpeg -c aac -filter_complex "sine=d=0.1,asetnsamples=1025" out.aac
Signed-off-by: Marton Balint
As this patch fixes a regression, this should also be in 3.4, so ping for
this.
Thanks,
Marton
---
fftools/ffmpeg.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 1d248bc269..5be8788ea8 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4528,6 +4528,15 @@ static int transcode_step(void)
}
if (ost->filter && ost->filter->graph->graph) {
+if (!ost->initialized) {
+char error[1024] = {0};
+ret = init_output_stream(ost, error, sizeof(error));
+if (ret < 0) {
+av_log(NULL, AV_LOG_ERROR, "Error initializing output stream %d:%d
-- %s\n",
+ ost->file_index, ost->index, error);
+exit_program(1);
+}
+}
if ((ret = transcode_from_filter(ost->filter->graph, &ist)) < 0)
return ret;
if (!ist)
--
2.13.5
___
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/2] avcodec/v4l2: fix single plane decoding
On 10/06/2017 09:51 AM, Jorge Ramirez-Ortiz wrote:
---
libavcodec/v4l2_buffers.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
bug fix. needed in 3.4
diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index ef7d040..ba70c5d 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -244,13 +244,23 @@ static int v4l2_buf_to_bufref(V4L2Buffer *in, int plane,
AVBufferRef **buf)
static int v4l2_bufref_to_buf(V4L2Buffer *out, int plane, const uint8_t* data, int size, AVBufferRef* bref)
{
+unsigned int bytesused, length;
+
if (plane >= out->num_planes)
return AVERROR(EINVAL);
+bytesused = FFMIN(size, out->plane_info[plane].length);
+length = out->plane_info[plane].length;
+
memcpy(out->plane_info[plane].mm_addr, data, FFMIN(size,
out->plane_info[plane].length));
-out->planes[plane].bytesused = FFMIN(size, out->plane_info[plane].length);
-out->planes[plane].length = out->plane_info[plane].length;
+if (V4L2_TYPE_IS_MULTIPLANAR(out->buf.type)) {
+out->planes[plane].bytesused = bytesused;
+out->planes[plane].length = length;
+} else {
+out->buf.bytesused = bytesused;
+out->buf.length = length;
+}
return 0;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/mp3enc: flush buffered packets if referencing fails
Signed-off-by: James Almer
---
libavformat/mp3enc.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
index 826878eca1..c63909393d 100644
--- a/libavformat/mp3enc.c
+++ b/libavformat/mp3enc.c
@@ -516,19 +516,14 @@ static int mp3_write_packet(AVFormatContext *s, AVPacket
*pkt)
/* buffer audio packets until we get all the pictures */
AVPacketList *pktl = av_mallocz(sizeof(*pktl));
int ret;
-if (!pktl) {
+if (!pktl || av_packet_ref(&pktl->pkt, pkt) < 0) {
+av_freep(&pktl);
av_log(s, AV_LOG_WARNING, "Not enough memory to buffer audio.
Skipping picture streams\n");
mp3->pics_to_write = 0;
mp3_queue_flush(s);
return mp3_write_audio_packet(s, pkt);
}
-ret = av_packet_ref(&pktl->pkt, pkt);
-if (ret < 0) {
-av_freep(&pktl);
-return ret;
-}
-
if (mp3->queue_end)
mp3->queue_end->next = pktl;
else
--
2.14.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/v4l2: fix segmentation fault on codec exit
On 10/06/2017 09:52 AM, Jorge Ramirez-Ortiz wrote:
It occurs when the codec is closed while buffer references still
exist. This is a regression from the original patchset where support
for this use-case was implemented.
The regression occurred while cleaning the code for the last patchset
(decoding was tested only with ffplay which disposes of the buffer
straightaway hence the feature went in broken/untested)
---
libavcodec/v4l2_m2m.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
bug fix. needed in 3.4
diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
index bd96a6d..5e85bcb 100644
--- a/libavcodec/v4l2_m2m.c
+++ b/libavcodec/v4l2_m2m.c
@@ -331,8 +331,10 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
ff_v4l2_context_release(&s->output);
-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 leaving pending
buffers\n");
+return 0;
+}
ff_v4l2_context_release(&s->capture);
sem_destroy(&s->refsync);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavd/decklink_dec: Do not claim to output transparency information
On Thu, 5 Oct 2017, Maksym Veremeyenko wrote: 29.09.2017 0:20, Carl Eugen Hoyos пише: Hi! I don't have decklink hardware but I assume it never outputs actual transparency. Or does it? it outputs or use internal keyer to put it over passthrow SDI signal. in external keyer mode it accept BGRA frame and output two SDI signals: one for *fill* another one for *key* That is true, but that is the feature of the decklink output device. Is the decklink *input* device capable of capturing in RGBA with useful alpha? I'd say, probably not. So I am more and more willing to accept the patch unless somebody has strong objections. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavd/decklink_dec: Do not claim to output transparency information
On Thu, 5 Oct 2017, Matthias Hunstock wrote: Am 02.10.2017 um 18:34 schrieb Marton Balint: Yeah, you can capture both at the same time, and one signal might be key, other might be fill, but as far as I know the driver will not merge these two signals behind the scenes to one single input with an alpha channel. Is there a video filter for splitting RGBA->key/fill or joining key/fill -> RGBA? Then an example in the docs would be helpful, though I'm not sure if the two streams will be perfectly synchronized. Both should be doable with extractplanes or mergeplanes filters. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/v4l2: fix single plane decoding
On 06/10/17 08:51, Jorge Ramirez-Ortiz wrote:
> ---
> libavcodec/v4l2_buffers.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
> index ef7d040..ba70c5d 100644
> --- a/libavcodec/v4l2_buffers.c
> +++ b/libavcodec/v4l2_buffers.c
> @@ -244,13 +244,23 @@ static int v4l2_buf_to_bufref(V4L2Buffer *in, int
> plane, AVBufferRef **buf)
>
> static int v4l2_bufref_to_buf(V4L2Buffer *out, int plane, const uint8_t*
> data, int size, AVBufferRef* bref)
> {
> +unsigned int bytesused, length;
> +
> if (plane >= out->num_planes)
> return AVERROR(EINVAL);
>
> +bytesused = FFMIN(size, out->plane_info[plane].length);
> +length = out->plane_info[plane].length;
> +
> memcpy(out->plane_info[plane].mm_addr, data, FFMIN(size,
> out->plane_info[plane].length));
>
> -out->planes[plane].bytesused = FFMIN(size,
> out->plane_info[plane].length);
> -out->planes[plane].length = out->plane_info[plane].length;
> +if (V4L2_TYPE_IS_MULTIPLANAR(out->buf.type)) {
> +out->planes[plane].bytesused = bytesused;
> +out->planes[plane].length = length;
> +} else {
> +out->buf.bytesused = bytesused;
> +out->buf.length = length;
> +}
>
> return 0;
> }
>
Can you clarify what devices are being fixed here? I believe there are two
modes (single-plane, multi-plane) - of the devices known to work, do we know
which modes they use?
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/v4l2: fix segmentation fault on codec exit
On 06/10/17 08:52, Jorge Ramirez-Ortiz wrote:
> It occurs when the codec is closed while buffer references still
> exist. This is a regression from the original patchset where support
> for this use-case was implemented.
>
> The regression occurred while cleaning the code for the last patchset
> (decoding was tested only with ffplay which disposes of the buffer
> straightaway hence the feature went in broken/untested)
> ---
> libavcodec/v4l2_m2m.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
> index bd96a6d..5e85bcb 100644
> --- a/libavcodec/v4l2_m2m.c
> +++ b/libavcodec/v4l2_m2m.c
> @@ -331,8 +331,10 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
>
> ff_v4l2_context_release(&s->output);
>
> -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 leaving pending
> buffers\n");
> +return 0;
> +}
>
> ff_v4l2_context_release(&s->capture);
> sem_destroy(&s->refsync);
>
Trying to test this, I segfault when decoding finishes with this patch applied
(exynos s5p-mfc):
(gdb) r
Starting program: /home/mrt/ffmpeg/v4l2/build/ffmpeg_g -threads 1 -v 55 -y -c:v
h264_v4l2m2m -i /home/mrt/bbb_1080_264.mp4 -an -frames:v 100 -f null -
...
Output file #0 (pipe:):
Output stream #0:0 (video): 100 frames encoded; 100 packets muxed (4
bytes);
Total: 100 packets (4 bytes) muxed
[h264_v4l2m2m @ 0x1403720] ff_v4l2m2m_codec_end leaving pending buffers
100 frames successfully decoded, 0 decoding errors
...
Thread 1 "ffmpeg_g" received signal SIGSEGV, Segmentation fault.
ff_v4l2_context_set_status (ctx=ctx@entry=0x10fc, cmd=1074026003) at
src/libavcodec/v4l2_context.c:489
489 int type = ctx->type;
(gdb) bt
#0 ff_v4l2_context_set_status (ctx=ctx@entry=0x10fc, cmd=1074026003) at
src/libavcodec/v4l2_context.c:489
#1 0x00798c24 in ff_v4l2_m2m_codec_end (avctx=0x1403720) at
src/libavcodec/v4l2_m2m.c:319
#2 0x00835aba in buffer_replace (src=0x0, dst=) at
src/libavutil/buffer.c:120
#3 av_buffer_unref (buf=buf@entry=0x14d8b2c) at src/libavutil/buffer.c:130
#4 0x008417ac in av_frame_unref (frame=frame@entry=0x14d8a30) at
src/libavutil/frame.c:515
#5 0x00841d58 in av_frame_unref (frame=) at
src/libavutil/frame.c:147
#6 av_frame_free (frame=frame@entry=0x1403d9c) at src/libavutil/frame.c:168
#7 0x00082bce in ffmpeg_cleanup (ret=0) at src/fftools/ffmpeg.c:541
#8 0x00079c42 in exit_program (ret=0) at src/fftools/cmdutils.c:138
#9 0x0006efba in main (argc=, argv=) at
src/fftools/ffmpeg.c:4793
(gdb) p ctx
$1 = (V4L2Context *) 0x10fc
(gdb) f 1
#1 0x00798c24 in ff_v4l2_m2m_codec_end (avctx=0x1403720) at
src/libavcodec/v4l2_m2m.c:319
319 ret = ff_v4l2_context_set_status(&s->output, VIDIOC_STREAMOFF);
(gdb) p s
$2 = (V4L2m2mContext *) 0x0
(gdb)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavd/decklink_dec: Do not claim to output transparency information
2017-10-06 21:10 GMT+02:00 Marton Balint : > Is the decklink *input* device capable of capturing in RGBA with useful > alpha? I'd say, probably not. > > So I am more and more willing to accept the patch unless > somebody has strong objections. I'll push on Sunday unless somebody objects. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/v4l2: fix segmentation fault on codec exit
On 06/10/17 20:53, Mark Thompson wrote:
> On 06/10/17 08:52, Jorge Ramirez-Ortiz wrote:
>> It occurs when the codec is closed while buffer references still
>> exist. This is a regression from the original patchset where support
>> for this use-case was implemented.
>>
>> The regression occurred while cleaning the code for the last patchset
>> (decoding was tested only with ffplay which disposes of the buffer
>> straightaway hence the feature went in broken/untested)
>> ---
>> libavcodec/v4l2_m2m.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
>> index bd96a6d..5e85bcb 100644
>> --- a/libavcodec/v4l2_m2m.c
>> +++ b/libavcodec/v4l2_m2m.c
>> @@ -331,8 +331,10 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
>>
>> ff_v4l2_context_release(&s->output);
>>
>> -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 leaving pending
>> buffers\n");
>> +return 0;
>> +}
>>
>> ff_v4l2_context_release(&s->capture);
>> sem_destroy(&s->refsync);
>>
>
> Trying to test this, I segfault when decoding finishes with this patch
> applied (exynos s5p-mfc):
>
> (gdb) r
> Starting program: /home/mrt/ffmpeg/v4l2/build/ffmpeg_g -threads 1 -v 55 -y
> -c:v h264_v4l2m2m -i /home/mrt/bbb_1080_264.mp4 -an -frames:v 100 -f null -
> ...
> Output file #0 (pipe:):
> Output stream #0:0 (video): 100 frames encoded; 100 packets muxed (4
> bytes);
> Total: 100 packets (4 bytes) muxed
> [h264_v4l2m2m @ 0x1403720] ff_v4l2m2m_codec_end leaving pending buffers
> 100 frames successfully decoded, 0 decoding errors
> ...
> Thread 1 "ffmpeg_g" received signal SIGSEGV, Segmentation fault.
> ff_v4l2_context_set_status (ctx=ctx@entry=0x10fc, cmd=1074026003) at
> src/libavcodec/v4l2_context.c:489
> 489 int type = ctx->type;
> (gdb) bt
> #0 ff_v4l2_context_set_status (ctx=ctx@entry=0x10fc, cmd=1074026003) at
> src/libavcodec/v4l2_context.c:489
> #1 0x00798c24 in ff_v4l2_m2m_codec_end (avctx=0x1403720) at
> src/libavcodec/v4l2_m2m.c:319
> #2 0x00835aba in buffer_replace (src=0x0, dst=) at
> src/libavutil/buffer.c:120
> #3 av_buffer_unref (buf=buf@entry=0x14d8b2c) at src/libavutil/buffer.c:130
> #4 0x008417ac in av_frame_unref (frame=frame@entry=0x14d8a30) at
> src/libavutil/frame.c:515
> #5 0x00841d58 in av_frame_unref (frame=) at
> src/libavutil/frame.c:147
> #6 av_frame_free (frame=frame@entry=0x1403d9c) at src/libavutil/frame.c:168
> #7 0x00082bce in ffmpeg_cleanup (ret=0) at src/fftools/ffmpeg.c:541
> #8 0x00079c42 in exit_program (ret=0) at src/fftools/cmdutils.c:138
> #9 0x0006efba in main (argc=, argv=) at
> src/fftools/ffmpeg.c:4793
> (gdb) p ctx
> $1 = (V4L2Context *) 0x10fc
> (gdb) f 1
> #1 0x00798c24 in ff_v4l2_m2m_codec_end (avctx=0x1403720) at
> src/libavcodec/v4l2_m2m.c:319
> 319 ret = ff_v4l2_context_set_status(&s->output, VIDIOC_STREAMOFF);
> (gdb) p s
> $2 = (V4L2m2mContext *) 0x0
> (gdb)
>
To clarify, it segfaults in the same way without the patch as well.
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: always use single threaded decoding for attached pictures
Since af1761f7b5b1b72197dc40934953b775c2d951cc ffmpeg waits for a frame in each
stream before writing the output header. If we are using threaded decoding for
attached pictures, we have to read till EOF to be able to finally flush the
decoder and output the decoded frame. This essentially makes ffmpeg buffer all
non-attached picture packets, which will cause a "Too many packets buffered for
output stream" eventually.
By forcing single threaded decoding, we get a frame from a single packet as
well and we can avoid the error.
Fixes part of ticket #6375:
ffmpeg -i 46564100.mp3 -acodec libmp3lame -ab 128k -ac 2 out.mp3
Signed-off-by: Marton Balint
---
fftools/ffmpeg.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 5be8788ea8..6eb7bf9d84 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2909,6 +2909,9 @@ static int init_input_stream(int ist_index, char *error,
int error_len)
if (!av_dict_get(ist->decoder_opts, "threads", NULL, 0))
av_dict_set(&ist->decoder_opts, "threads", "auto", 0);
+/* Attached pics are sparse, therefore we would not want to delay
their decoding till EOF. */
+if (ist->st->disposition & AV_DISPOSITION_ATTACHED_PIC)
+av_dict_set(&ist->decoder_opts, "threads", "1", 0);
ret = hw_device_setup_for_decode(ist);
if (ret < 0) {
--
2.13.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Makefile: generate stripped CLI tools directly instead of copying unstripped ones first
Signed-off-by: Marton Balint --- Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 4a1253a052..adb8330fa0 100644 --- a/Makefile +++ b/Makefile @@ -97,8 +97,7 @@ include $(SRC_PATH)/doc/examples/Makefile libavcodec/utils.o libavformat/utils.o libavdevice/avdevice.o libavfilter/avfilter.o libavutil/utils.o libpostproc/postprocess.o libswresample/swresample.o libswscale/utils.o : libavutil/ffversion.h $(PROGS): %$(PROGSSUF)$(EXESUF): %$(PROGSSUF)_g$(EXESUF) - $(CP) $< $@ - $(STRIP) $@ + $(STRIP) -o $@ $< %$(PROGSSUF)_g$(EXESUF): $(FF_DEP_LIBS) $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(OBJS-$*) $(FF_EXTRALIBS) -- 2.13.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter
On Fri, Oct 06, 2017 at 10:03:16AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Oct 5, 2017 at 7:52 PM, Michael Niedermayer
> wrote:
>
> > On Sat, Sep 30, 2017 at 03:51:41PM +, Ashish Singh wrote:
> > > ffmpeg | branch: master | Ashish Singh | Sat Sep
> > 16 02:35:58 2017 +0530| [148c8e88c43cfbabd6aee9f01ef30942cee9d359] |
> > committer: Ronald S. Bultje
> > >
> > > avfilter: add vmafmotion filter
> > >
> > > Signed-off-by: Ashish Singh
> > > Signed-off-by: Ronald S. Bultje
> > >
> > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=
> > 148c8e88c43cfbabd6aee9f01ef30942cee9d359
> > > ---
> > >
> > > Changelog | 1 +
> > > doc/filters.texi| 14 ++
> > > libavfilter/Makefile| 1 +
> > > libavfilter/allfilters.c| 1 +
> > > libavfilter/vf_vmafmotion.c | 365 ++
> > ++
> > > libavfilter/vmaf_motion.h | 58 +++
> > > 6 files changed, 440 insertions(+)
> > [...]
> > > +static av_cold int init(AVFilterContext *ctx)
> > > +{
> > > +VMAFMotionContext *s = ctx->priv;
> > > +
> > > +if (s->stats_file_str) {
> > > +if (!strcmp(s->stats_file_str, "-")) {
> >
> > > +s->stats_file = stdout;
> >
> > Using stdout can interfere with the user application using the filter
> >
> >
> > > +} else {
> >
> > > +s->stats_file = fopen(s->stats_file_str, "w");
> >
> > Opening a filter parameter provided string for writing is a dangerous
> > way to output data. It allows one with access to the parameters to
> > overwrite any writable file
> >
> > data should only be output in a safe way
> >
>
> The same mechanism is present in ssim/psnr filters. I'm open to any
> alternative method you suggest. These are only settable using explicit user
> interaction (and are disabled by default) so I don't particularly see the
> problem.
With this a filter graph can never be taken from an untrusted source
One filter that outputs statistics without writing to a user specified
filename is libavfilter/af_astats.c
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter
On 10/6/17, Michael Niedermayer wrote:
> On Fri, Oct 06, 2017 at 10:03:16AM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Thu, Oct 5, 2017 at 7:52 PM, Michael Niedermayer
>>
>> wrote:
>>
>> > On Sat, Sep 30, 2017 at 03:51:41PM +, Ashish Singh wrote:
>> > > ffmpeg | branch: master | Ashish Singh | Sat
>> > > Sep
>> > 16 02:35:58 2017 +0530| [148c8e88c43cfbabd6aee9f01ef30942cee9d359] |
>> > committer: Ronald S. Bultje
>> > >
>> > > avfilter: add vmafmotion filter
>> > >
>> > > Signed-off-by: Ashish Singh
>> > > Signed-off-by: Ronald S. Bultje
>> > >
>> > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=
>> > 148c8e88c43cfbabd6aee9f01ef30942cee9d359
>> > > ---
>> > >
>> > > Changelog | 1 +
>> > > doc/filters.texi| 14 ++
>> > > libavfilter/Makefile| 1 +
>> > > libavfilter/allfilters.c| 1 +
>> > > libavfilter/vf_vmafmotion.c | 365 ++
>> > ++
>> > > libavfilter/vmaf_motion.h | 58 +++
>> > > 6 files changed, 440 insertions(+)
>> > [...]
>> > > +static av_cold int init(AVFilterContext *ctx)
>> > > +{
>> > > +VMAFMotionContext *s = ctx->priv;
>> > > +
>> > > +if (s->stats_file_str) {
>> > > +if (!strcmp(s->stats_file_str, "-")) {
>> >
>> > > +s->stats_file = stdout;
>> >
>> > Using stdout can interfere with the user application using the filter
>> >
>> >
>> > > +} else {
>> >
>> > > +s->stats_file = fopen(s->stats_file_str, "w");
>> >
>> > Opening a filter parameter provided string for writing is a dangerous
>> > way to output data. It allows one with access to the parameters to
>> > overwrite any writable file
>> >
>> > data should only be output in a safe way
>> >
>>
>> The same mechanism is present in ssim/psnr filters. I'm open to any
>> alternative method you suggest. These are only settable using explicit
>> user
>> interaction (and are disabled by default) so I don't particularly see the
>> problem.
>
> With this a filter graph can never be taken from an untrusted source
>
> One filter that outputs statistics without writing to a user specified
> filename is libavfilter/af_astats.c
So what? Get over it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter
On 10/6/2017 5:44 PM, Paul B Mahol wrote:
> On 10/6/17, Michael Niedermayer wrote:
>> On Fri, Oct 06, 2017 at 10:03:16AM -0400, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Thu, Oct 5, 2017 at 7:52 PM, Michael Niedermayer
>>>
>>> wrote:
>>>
On Sat, Sep 30, 2017 at 03:51:41PM +, Ashish Singh wrote:
> ffmpeg | branch: master | Ashish Singh | Sat
> Sep
16 02:35:58 2017 +0530| [148c8e88c43cfbabd6aee9f01ef30942cee9d359] |
committer: Ronald S. Bultje
>
> avfilter: add vmafmotion filter
>
> Signed-off-by: Ashish Singh
> Signed-off-by: Ronald S. Bultje
>
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=
148c8e88c43cfbabd6aee9f01ef30942cee9d359
> ---
>
> Changelog | 1 +
> doc/filters.texi| 14 ++
> libavfilter/Makefile| 1 +
> libavfilter/allfilters.c| 1 +
> libavfilter/vf_vmafmotion.c | 365 ++
++
> libavfilter/vmaf_motion.h | 58 +++
> 6 files changed, 440 insertions(+)
[...]
> +static av_cold int init(AVFilterContext *ctx)
> +{
> +VMAFMotionContext *s = ctx->priv;
> +
> +if (s->stats_file_str) {
> +if (!strcmp(s->stats_file_str, "-")) {
> +s->stats_file = stdout;
Using stdout can interfere with the user application using the filter
> +} else {
> +s->stats_file = fopen(s->stats_file_str, "w");
Opening a filter parameter provided string for writing is a dangerous
way to output data. It allows one with access to the parameters to
overwrite any writable file
data should only be output in a safe way
>>>
>>> The same mechanism is present in ssim/psnr filters. I'm open to any
>>> alternative method you suggest. These are only settable using explicit
>>> user
>>> interaction (and are disabled by default) so I don't particularly see the
>>> problem.
>>
>> With this a filter graph can never be taken from an untrusted source
>>
>> One filter that outputs statistics without writing to a user specified
>> filename is libavfilter/af_astats.c
>
> So what? Get over it.
What kind of reply is this? What made you think it's justified?
He literally gave an example of an alternative method as Ronald requested.
Some of you people need to chill out already when discussing patches.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter
On Fri, Oct 6, 2017 at 10:21 PM, Michael Niedermayer wrote: > > With this a filter graph can never be taken from an untrusted source > > The same could be said for any ffmpeg CLI command line string, which people happily share on the web all the time, it can also contain multiple output files which can get overwritten without question even with the right commands. Should we remove support for writing those files as well? :) Ultimately, multimedia processing has to write files at some point. If people copy-paste commands without understanding them or even worse give people access to command lines without control, trhere is nothing we can really do to protect them. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI
2017-10-06 18:56 GMT+02:00 Devin Heitmueller : > From: Devin Heitmueller > > Hook in libklvanc and use it for output of EIA-708 captions over > SDI. The bulk of this patch is just general support for ancillary > data for the Decklink SDI module - the real work for construction > of the EIA-708 CDP and VANC line construction is done by libklvanc. Nothing except the decklink device could use VANC? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency
---
libavfilter/vf_paletteuse.c | 175
1 file changed, 112 insertions(+), 63 deletions(-)
diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
index ffd37bf1da..4203543843 100644
--- a/libavfilter/vf_paletteuse.c
+++ b/libavfilter/vf_paletteuse.c
@@ -56,7 +56,7 @@ enum diff_mode {
};
struct color_node {
-uint8_t val[3];
+uint8_t val[4];
uint8_t palette_id;
int split;
int left_id, right_id;
@@ -86,6 +86,7 @@ typedef struct PaletteUseContext {
struct cache_node cache[CACHE_SIZE];/* lookup cache */
struct color_node map[AVPALETTE_COUNT]; /* 3D-Tree (KD-Tree with K=3) for
reverse colormap */
uint32_t palette[AVPALETTE_COUNT];
+int transparency_index; /* index in the palette of transparency. -1 if
there isn't a transparency. */
int palette_loaded;
int dither;
int new;
@@ -108,6 +109,7 @@ typedef struct PaletteUseContext {
#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
static const AVOption paletteuse_options[] = {
{ "dither", "select dithering mode", OFFSET(dither), AV_OPT_TYPE_INT,
{.i64=DITHERING_SIERRA2_4A}, 0, NB_DITHERING-1, FLAGS, "dithering_mode" },
+{ "none","no dither",
0, AV_OPT_TYPE_CONST, {.i64=DITHERING_NONE},
INT_MIN, INT_MAX, FLAGS, "dithering_mode" },
{ "bayer", "ordered 8x8 bayer dithering (deterministic)",
0, AV_OPT_TYPE_CONST, {.i64=DITHERING_BAYER},
INT_MIN, INT_MAX, FLAGS, "dithering_mode" },
{ "heckbert","dithering as defined by Paul Heckbert in 1982
(simple error diffusion)", 0, AV_OPT_TYPE_CONST, {.i64=DITHERING_HECKBERT},
INT_MIN, INT_MAX, FLAGS, "dithering_mode" },
{ "floyd_steinberg", "Floyd and Steingberg dithering (error
diffusion)", 0, AV_OPT_TYPE_CONST,
{.i64=DITHERING_FLOYD_STEINBERG}, INT_MIN, INT_MAX, FLAGS, "dithering_mode" },
@@ -157,7 +159,8 @@ static int query_formats(AVFilterContext *ctx)
static av_always_inline int dither_color(uint32_t px, int er, int eg, int eb,
int scale, int shift)
{
-return av_clip_uint8((px >> 16 & 0xff) + ((er * scale) / (1<> 24 & 0xff) ) << 24
+ | av_clip_uint8((px >> 16 & 0xff) + ((er * scale) / (1<> 8 & 0xff) + ((eg * scale) / (1<>24 & 0xff,
palette[i]>>16 & 0xff,
palette[i]>> 8 & 0xff,
palette[i] & 0xff,
};
-const int d = diff(palrgb, rgb);
+const int d = diff(palargb, rgb);
if (d < min_dist) {
pal_id = i;
min_dist = d;
}
}
}
+
return pal_id;
}
@@ -325,14 +338,15 @@ end:
* Note: r, g, and b are the component of c but are passed as well to avoid
* recomputing them (they are generally computed by the caller for other uses).
*/
-static av_always_inline int color_get(struct cache_node *cache, uint32_t color,
- uint8_t r, uint8_t g, uint8_t b,
+static av_always_inline int color_get(struct cache_node *cache, uint32_t argb,
+ uint8_t a, uint8_t r, uint8_t g, uint8_t
b,
+ int transparency_index,
const struct color_node *map,
const uint32_t *palette,
const enum color_search_method
search_method)
{
int i;
-const uint8_t rgb[] = {r, g, b};
+const uint8_t argb_elts[] = {a, r, g, b};
const uint8_t rhash = r & ((1<= 0) {
+return transparency_index;
+}
+
for (i = 0; i < node->nb_entries; i++) {
e = &node->entries[i];
-if (e->color == color)
+if (e->color == argb)
return e->pal_entry;
}
@@ -350,21 +369,24 @@ static av_always_inline int color_get(struct cache_node
*cache, uint32_t color,
sizeof(*node->entries), NULL);
if (!e)
return AVERROR(ENOMEM);
-e->color = color;
-e->pal_entry = COLORMAP_NEAREST(search_method, palette, map, rgb);
+e->color = argb;
+e->pal_entry = COLORMAP_NEAREST(search_method, palette, map, argb_elts);
+
return e->pal_entry;
}
static av_always_inline int get_dst_color_err(struct cache_node *cache,
- uint32_t c, const struct
color_node *map,
+ uint32_t argb, const struct
color_node *map,
const uint32_t *palette,
+ int transparency_index,
int *er, int *eg, int *eb,
const enum color_search_method
search_method)
Re: [FFmpeg-devel] [PATCH] ffmpeg: always use single threaded decoding for attached pictures
On Fri, Oct 6, 2017 at 10:14 PM, Marton Balint wrote: > Since af1761f7b5b1b72197dc40934953b775c2d951cc ffmpeg waits for a frame in > each > stream before writing the output header. If we are using threaded decoding for > attached pictures, we have to read till EOF to be able to finally flush the > decoder and output the decoded frame. This essentially makes ffmpeg buffer all > non-attached picture packets, which will cause a "Too many packets buffered > for > output stream" eventually. > > By forcing single threaded decoding, we get a frame from a single packet as > well and we can avoid the error. > > Fixes part of ticket #6375: > ffmpeg -i 46564100.mp3 -acodec libmp3lame -ab 128k -ac 2 out.mp3 > > Signed-off-by: Marton Balint > --- > fftools/ffmpeg.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c > index 5be8788ea8..6eb7bf9d84 100644 > --- a/fftools/ffmpeg.c > +++ b/fftools/ffmpeg.c > @@ -2909,6 +2909,9 @@ static int init_input_stream(int ist_index, char > *error, int error_len) > > if (!av_dict_get(ist->decoder_opts, "threads", NULL, 0)) > av_dict_set(&ist->decoder_opts, "threads", "auto", 0); > +/* Attached pics are sparse, therefore we would not want to delay > their decoding till EOF. */ > +if (ist->st->disposition & AV_DISPOSITION_ATTACHED_PIC) > +av_dict_set(&ist->decoder_opts, "threads", "1", 0); > LGTM. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/h264:Only check x264_build if it was set
On Fri, Oct 06, 2017 at 08:19:43PM +0200, Carl Eugen Hoyos wrote: > 2017-10-06 18:54 GMT+02:00 Henrik Gramner : > > On Thu, Oct 5, 2017 at 8:31 AM, Carl Eugen Hoyos wrote: > >> Hi! > >> > >> Attached patch fixes ticket #6717. > >> > >> Please comment, Carl Eugen > > > > Signed numbers are converted to unsigned when compared to unsigned > > numbers which means -1 becomes UINT_MAX so this patch shouldn't > > actually change anything. > > Thank you both for pointing this out! > > > #6717 is probably unfixable without breaking something else. > > I believe an option to force the work-around should at least be > discussed. If theres need to add an option then a value in workaround_bugs can be added. This field is used in other decoders for the same purpose Or some option to set x264_build could be added. This may be better [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI
Hello Carl, > On Oct 6, 2017, at 5:07 PM, Carl Eugen Hoyos wrote: > > 2017-10-06 18:56 GMT+02:00 Devin Heitmueller : >> From: Devin Heitmueller >> >> Hook in libklvanc and use it for output of EIA-708 captions over >> SDI. The bulk of this patch is just general support for ancillary >> data for the Decklink SDI module - the real work for construction >> of the EIA-708 CDP and VANC line construction is done by libklvanc. > > Nothing except the decklink device could use VANC? You could absolutely have other SDI device types which can contain VANC. This was a key reason that we put all the business logic for VANC processing in a separate library. The goal behind developing libklvanc was to separate out VANC processing from device and application specific business logic. This allows us to have a single parser and implementation of popular VANC protocols in a single library that can be reused by VLC, OBE, and ffmpeg. It also allows the VANC processing to be shared across different device types, although admittedly there are not many vendors other than BlackMagic that are very popular. The point of the remark in the commit message though was to observe that most of the code in the patch implements the decklink specific glue for accessing VANC lines. The libklvanc library provides all the functions for parsing/generation of the VANC packets. Devin ___ 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
2017-10-06 22:59 GMT+02:00 Bjorn Roche : > libavfilter/vf_paletteuse.c | 175 Works fine for me, passes fate, needs a review from Clément. Do you think an option to set the value of the transparent colour to something else than 0xFF00 would make sense? And/or another default? You can use ffplay on an output png file to test if it's not clear what I mean. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/v4l2: fix single plane decoding
On 10/06/2017 09:47 PM, Mark Thompson wrote:
On 06/10/17 08:51, Jorge Ramirez-Ortiz wrote:
---
libavcodec/v4l2_buffers.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index ef7d040..ba70c5d 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -244,13 +244,23 @@ static int v4l2_buf_to_bufref(V4L2Buffer *in, int plane,
AVBufferRef **buf)
static int v4l2_bufref_to_buf(V4L2Buffer *out, int plane, const uint8_t* data, int size, AVBufferRef* bref)
{
+unsigned int bytesused, length;
+
if (plane >= out->num_planes)
return AVERROR(EINVAL);
+bytesused = FFMIN(size, out->plane_info[plane].length);
+length = out->plane_info[plane].length;
+
memcpy(out->plane_info[plane].mm_addr, data, FFMIN(size,
out->plane_info[plane].length));
-out->planes[plane].bytesused = FFMIN(size, out->plane_info[plane].length);
-out->planes[plane].length = out->plane_info[plane].length;
+if (V4L2_TYPE_IS_MULTIPLANAR(out->buf.type)) {
+out->planes[plane].bytesused = bytesused;
+out->planes[plane].length = length;
+} else {
+out->buf.bytesused = bytesused;
+out->buf.length = length;
+}
return 0;
}
Can you clarify what devices are being fixed here? I believe there are two
modes (single-plane, multi-plane) - of the devices known to work, do we know
which modes they use?
venus driver in Qualcomm SoC - 96Bords db410c[1] - > multiplanar
coda driver for Imx6 - cubox[2] -> single plane
[1] https://www.96boards.org/product/dragonboard410c/
[2] https://www.solid-run.com/freescale-imx6-family/cubox-i/
the patch above fixes single plan decoding
- Mark
___
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 RFC] libavdevice/decklink: Add support for EIA-708 output over SDI
2017-10-06 23:21 GMT+02:00 Devin Heitmueller : > Hello Carl, > >> On Oct 6, 2017, at 5:07 PM, Carl Eugen Hoyos wrote: >> >> 2017-10-06 18:56 GMT+02:00 Devin Heitmueller : >>> From: Devin Heitmueller >>> >>> Hook in libklvanc and use it for output of EIA-708 captions over >>> SDI. The bulk of this patch is just general support for ancillary >>> data for the Decklink SDI module - the real work for construction >>> of the EIA-708 CDP and VANC line construction is done by libklvanc. >> >> Nothing except the decklink device could use VANC? > > You could absolutely have other SDI device types which can contain VANC. Sorry, what I meant was: Nothing inside FFmpeg except the decklink device could use VANC? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI
> > Sorry, what I meant was: > Nothing inside FFmpeg except the decklink device could use > VANC? Ah, I understand now. Yes, the decklink device is currently the only SDI device which is supported by libavdevice. I’ve got a whole pile of patches coming which add support for a variety of protocols for both capture and output (e.g. EIA-708, SCTE-104, AFD, SMPTE 2038, etc). But today the decklink module is the only device supported. Would love to see more SDI devices supported and potentially interested in adding such support myself if we can find good candidates. The DVEO/linsys cards are largely obsolete and the AJA boards are significantly more expensive than any of BlackMagic’s cards. If anyone has good experiences with other vendors I would like to hear about it (and there may be an opportunity to extend libavdevice to support another SDI vendor). Devin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] JPEG2000: SSE optimisation of DWT decoding
2017-10-06 17:30 GMT+02:00 Nicolas Bertrand :
> From: Maxime Taisant
>
> ---
> libavcodec/jpeg2000dwt.c | 45 +-
> libavcodec/jpeg2000dwt.h |5 +
> libavcodec/x86/jpeg2000dsp.asm| 1339
> +
> libavcodec/x86/jpeg2000dsp_init.c | 119
> tests/checkasm/jpeg2000dsp.c |1 +
> 5 files changed, 1496 insertions(+), 13 deletions(-)
>
> diff --git a/libavcodec/jpeg2000dwt.c b/libavcodec/jpeg2000dwt.c
> index 55dd5e89b5..1a0c3fc034 100644
> --- a/libavcodec/jpeg2000dwt.c
> +++ b/libavcodec/jpeg2000dwt.c
> @@ -30,6 +30,7 @@
> #include "libavutil/mem.h"
> #include "jpeg2000dwt.h"
> #include "internal.h"
> +#include "libavutil/timer.h"
This include should not be part of the final patch, same
for the commented TIMER calls.
But the results of your performance tests should be
at least part of the email, can be part of the commit
message.
> +s->sse = 0;
I originally assumed this is a leftover but iiuc, you
need to add function_pointers to the the context
and replace every function call with a call to the
function in the context.
> -switch (s->type) {
> -case FF_DWT97:
> -dwt_decode97_float(s, t);
> -break;
> -case FF_DWT97_INT:
> -dwt_decode97_int(s, t);
> -break;
> -case FF_DWT53:
> -dwt_decode53(s, t);
> -break;
> -default:
> -return -1;
> +switch(s->type){
> +case FF_DWT97:
We like the indentation here as it is.
> +if (s->sse)
> +//{
Please keep the brackets in the final patch,
this variant is a very good example on why
they are useful;-)
> +//START_TIMER
But remove this.
Consider waiting for a review of the asm code.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter
On Fri, Oct 06, 2017 at 11:04:24PM +0200, Hendrik Leppkes wrote: > On Fri, Oct 6, 2017 at 10:21 PM, Michael Niedermayer > wrote: > > > > With this a filter graph can never be taken from an untrusted source > > > > > > The same could be said for any ffmpeg CLI command line string, which > people happily share on the web all the time, it can also contain > multiple output files which can get overwritten without question even > with the right commands. sure but if we had the ability to use untrusted strings saftely as filtergraph then this would allow new use cases. An example would be filterng videos via a web app Another example would be a recommanded filter embeded in a web page or a video that by default might be applied during playback in the client. That may be a filter to do deblock / post processing or some telecine related correction. One could go further and apply this not to a video but a whole webpage insane, yes, and whole lot of compatibility questions but my point is not the details here, just that theres alot more than a user copy and pasting a trojanized command line > Should we remove support for writing those files as well? :) no features should be removed but having more parts of the interface work with untrusted data would allow new things neither of us is thinking of ... > > Ultimately, multimedia processing has to write files at some point. If > people copy-paste commands without understanding them or even worse > give people access to command lines without control, trhere is nothing > we can really do to protect them. > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/v4l2: fix segmentation fault on codec exit
On 10/06/2017 10:01 PM, Mark Thompson wrote:
On 06/10/17 20:53, Mark Thompson wrote:
On 06/10/17 08:52, Jorge Ramirez-Ortiz wrote:
It occurs when the codec is closed while buffer references still
exist. This is a regression from the original patchset where support
for this use-case was implemented.
The regression occurred while cleaning the code for the last patchset
(decoding was tested only with ffplay which disposes of the buffer
straightaway hence the feature went in broken/untested)
---
libavcodec/v4l2_m2m.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
index bd96a6d..5e85bcb 100644
--- a/libavcodec/v4l2_m2m.c
+++ b/libavcodec/v4l2_m2m.c
@@ -331,8 +331,10 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
ff_v4l2_context_release(&s->output);
-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 leaving pending
buffers\n");
+return 0;
+}
ff_v4l2_context_release(&s->capture);
sem_destroy(&s->refsync);
Trying to test this, I segfault when decoding finishes with this patch applied
(exynos s5p-mfc):
(gdb) r
Starting program: /home/mrt/ffmpeg/v4l2/build/ffmpeg_g -threads 1 -v 55 -y -c:v
h264_v4l2m2m -i /home/mrt/bbb_1080_264.mp4 -an -frames:v 100 -f null -
...
Output file #0 (pipe:):
Output stream #0:0 (video): 100 frames encoded; 100 packets muxed (4
bytes);
Total: 100 packets (4 bytes) muxed
[h264_v4l2m2m @ 0x1403720] ff_v4l2m2m_codec_end leaving pending buffers
100 frames successfully decoded, 0 decoding errors
...
Thread 1 "ffmpeg_g" received signal SIGSEGV, Segmentation fault.
ff_v4l2_context_set_status (ctx=ctx@entry=0x10fc, cmd=1074026003) at
src/libavcodec/v4l2_context.c:489
489 int type = ctx->type;
(gdb) bt
#0 ff_v4l2_context_set_status (ctx=ctx@entry=0x10fc, cmd=1074026003) at
src/libavcodec/v4l2_context.c:489
#1 0x00798c24 in ff_v4l2_m2m_codec_end (avctx=0x1403720) at
src/libavcodec/v4l2_m2m.c:319
#2 0x00835aba in buffer_replace (src=0x0, dst=) at
src/libavutil/buffer.c:120
#3 av_buffer_unref (buf=buf@entry=0x14d8b2c) at src/libavutil/buffer.c:130
#4 0x008417ac in av_frame_unref (frame=frame@entry=0x14d8a30) at
src/libavutil/frame.c:515
#5 0x00841d58 in av_frame_unref (frame=) at
src/libavutil/frame.c:147
#6 av_frame_free (frame=frame@entry=0x1403d9c) at src/libavutil/frame.c:168
#7 0x00082bce in ffmpeg_cleanup (ret=0) at src/fftools/ffmpeg.c:541
#8 0x00079c42 in exit_program (ret=0) at src/fftools/cmdutils.c:138
#9 0x0006efba in main (argc=, argv=) at
src/fftools/ffmpeg.c:4793
(gdb) p ctx
$1 = (V4L2Context *) 0x10fc
(gdb) f 1
#1 0x00798c24 in ff_v4l2_m2m_codec_end (avctx=0x1403720) at
src/libavcodec/v4l2_m2m.c:319
319 ret = ff_v4l2_context_set_status(&s->output, VIDIOC_STREAMOFF);
(gdb) p s
$2 = (V4L2m2mContext *) 0x0
(gdb)
To clarify, it segfaults in the same way without the patch as well.
vow, very strange.
would you mind doing a clean build with the patch applied?
I am asking because that test works fine on my db410c and 820 (and hardware
shouldnt make a difference in this test)
also the team at Kodi also tested the fix on their imx6
- Mark
___
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
2017-10-06 18:26 GMT+02:00 Michael Bradshaw : > 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 I suggest you drop it after the release. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/v4l2: fix segmentation fault on codec exit
On 10/06/2017 11:38 PM, Jorge Ramirez-Ortiz wrote:
On 10/06/2017 10:01 PM, Mark Thompson wrote:
On 06/10/17 20:53, Mark Thompson wrote:
On 06/10/17 08:52, Jorge Ramirez-Ortiz wrote:
It occurs when the codec is closed while buffer references still
exist. This is a regression from the original patchset where support
for this use-case was implemented.
The regression occurred while cleaning the code for the last patchset
(decoding was tested only with ffplay which disposes of the buffer
straightaway hence the feature went in broken/untested)
---
libavcodec/v4l2_m2m.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v4l2_m2m.c b/libavcodec/v4l2_m2m.c
index bd96a6d..5e85bcb 100644
--- a/libavcodec/v4l2_m2m.c
+++ b/libavcodec/v4l2_m2m.c
@@ -331,8 +331,10 @@ int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
ff_v4l2_context_release(&s->output);
- 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 leaving pending
buffers\n");
+ return 0;
+ }
ff_v4l2_context_release(&s->capture);
sem_destroy(&s->refsync);
Trying to test this, I segfault when decoding finishes with this patch
applied (exynos s5p-mfc):
(gdb) r
Starting program: /home/mrt/ffmpeg/v4l2/build/ffmpeg_g -threads 1 -v 55 -y
-c:v h264_v4l2m2m -i /home/mrt/bbb_1080_264.mp4 -an -frames:v 100 -f null -
...
Output file #0 (pipe:):
Output stream #0:0 (video): 100 frames encoded; 100 packets muxed (4
bytes);
Total: 100 packets (4 bytes) muxed
[h264_v4l2m2m @ 0x1403720] ff_v4l2m2m_codec_end leaving pending buffers
100 frames successfully decoded, 0 decoding errors
...
Thread 1 "ffmpeg_g" received signal SIGSEGV, Segmentation fault.
ff_v4l2_context_set_status (ctx=ctx@entry=0x10fc, cmd=1074026003) at
src/libavcodec/v4l2_context.c:489
489 int type = ctx->type;
(gdb) bt
#0 ff_v4l2_context_set_status (ctx=ctx@entry=0x10fc, cmd=1074026003) at
src/libavcodec/v4l2_context.c:489
#1 0x00798c24 in ff_v4l2_m2m_codec_end (avctx=0x1403720) at
src/libavcodec/v4l2_m2m.c:319
#2 0x00835aba in buffer_replace (src=0x0, dst=) at
src/libavutil/buffer.c:120
#3 av_buffer_unref (buf=buf@entry=0x14d8b2c) at src/libavutil/buffer.c:130
#4 0x008417ac in av_frame_unref (frame=frame@entry=0x14d8a30) at
src/libavutil/frame.c:515
#5 0x00841d58 in av_frame_unref (frame=) at
src/libavutil/frame.c:147
#6 av_frame_free (frame=frame@entry=0x1403d9c) at src/libavutil/frame.c:168
#7 0x00082bce in ffmpeg_cleanup (ret=0) at src/fftools/ffmpeg.c:541
#8 0x00079c42 in exit_program (ret=0) at src/fftools/cmdutils.c:138
#9 0x0006efba in main (argc=, argv=) at
src/fftools/ffmpeg.c:4793
(gdb) p ctx
$1 = (V4L2Context *) 0x10fc
(gdb) f 1
#1 0x00798c24 in ff_v4l2_m2m_codec_end (avctx=0x1403720) at
src/libavcodec/v4l2_m2m.c:319
319 ret = ff_v4l2_context_set_status(&s->output, VIDIOC_STREAMOFF);
(gdb) p s
$2 = (V4L2m2mContext *) 0x0
(gdb)
To clarify, it segfaults in the same way without the patch as well.
vow, very strange.
would you mind doing a clean build with the patch applied?
I am asking because that test works fine on my db410c and 820 (and hardware
shouldnt make a difference in this test)
also the team at Kodi also tested the fix on their imx6
this is what I see when I run your command
linaro@db820 git.zoltan.ffmpeg (ffmpeg/master $)]$ ./ffmpeg_g -threads 1 -v 55
-y -c:v h264_v4l2m2m -i ~/Videos/h264.FVDO_Freeway_720p.264 -an -frames:v 100 -f
null -
[...]
[h264_v4l2m2m @ 0xdd3bbb50] capture: NV12 20 buffers initialized: 1280x0736,
sizeimage 01425408, bytesperline 1280
cur_dts is invalid (this is harmless if it occurs once at the start per stream)
Last message repeated 9 times
detected 4 logical cores
[graph 0 input from stream 0:0 @ 0xdd419680] Setting 'video_size' to value
'1280x720'
[graph 0 input from stream 0:0 @ 0xdd419680] Setting 'pix_fmt' to value '25'
[graph 0 input from stream 0:0 @ 0xdd419680] Setting 'time_base' to value
'1/120'
[graph 0 input from stream 0:0 @ 0xdd419680] Setting 'pixel_aspect' to value
'0/1'
[graph 0 input from stream 0:0 @ 0xdd419680] Setting 'sws_param' to value
'flags=2'
[graph 0 input from stream 0:0 @ 0xdd419680] Setting 'frame_rate' to value
'25/1'
[graph 0 input from stream 0:0 @ 0xdd419680] w:1280 h:720 pixfmt:nv12
tb:1/120 fr:25/1 sar:0/1 sws_param:flags=2
[AVFilterGraph @ 0xdd438530] query_formats: 3 queried, 2 merged, 0 already
done, 0 delayed
Output #0, null, to 'pipe:':
Metadata:
encoder : Lavf57.82.102
Stream #0:0, 0, 1/25: Video: wrapped_avframe, 1 reference frame,
nv12(left), 1280x720, 0/1, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc
Metadata:
encoder : Lavc57.106.104 wrapped_avframe
No more output streams to write to, finishing.:00.04 bitrate=
Re: [FFmpeg-devel] FFmpeg 3.4
On Fri, 6 Oct 2017 16:53:17 +0200 Michael Niedermayer wrote: > Hi all > > if there are no objections i will branch release/3.4 in the next days > and make the 3.4 release a few days after that > > If people prefer a specific name, suggest one now, otherwise i will > pick a random one from past suggestions > > If there are features you want in, please push them to > master before the release is branched > if there are bug fixes you want in please ensure they end in > release/3.4 (eiter via master before branching or backport after) I want hardware decoding things in that release (frame pool info, cuvid). I vote the release until this has happened. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Infrastructure: patchwork.ffmpeg.org SSL certificate
On Thu, Oct 05, 2017 at 01:37:27PM +0200, Matthias Hunstock wrote: > There is still a StartCom certificate in place, which is refused from > Chrome and soon other browsers. > > Any help appreciated to also move that machine to Let's Encrypt? I thought reimar would update it. I dont know the way by which the other servers update their certs. IIRC the method officially recommanded by lets encrypt basically puts a backdoor on the server which understandably reimar didnt like. (backdoor as in downloading and executing code in a cronjob) also patchwork uses nginx, the other boxes apache ... anyway iam cc-ing reimar [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter
On Fri, 6 Oct 2017 18:02:44 -0300
James Almer wrote:
> On 10/6/2017 5:44 PM, Paul B Mahol wrote:
> > On 10/6/17, Michael Niedermayer wrote:
> >> On Fri, Oct 06, 2017 at 10:03:16AM -0400, Ronald S. Bultje wrote:
> >>> Hi,
> >>>
> >>> On Thu, Oct 5, 2017 at 7:52 PM, Michael Niedermayer
> >>>
> >>> wrote:
> >>>
> On Sat, Sep 30, 2017 at 03:51:41PM +, Ashish Singh wrote:
> > ffmpeg | branch: master | Ashish Singh | Sat
> > Sep
> 16 02:35:58 2017 +0530| [148c8e88c43cfbabd6aee9f01ef30942cee9d359] |
> committer: Ronald S. Bultje
> >
> > avfilter: add vmafmotion filter
> >
> > Signed-off-by: Ashish Singh
> > Signed-off-by: Ronald S. Bultje
> >
> >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=
> 148c8e88c43cfbabd6aee9f01ef30942cee9d359
> > ---
> >
> > Changelog | 1 +
> > doc/filters.texi| 14 ++
> > libavfilter/Makefile| 1 +
> > libavfilter/allfilters.c| 1 +
> > libavfilter/vf_vmafmotion.c | 365 ++
> ++
> > libavfilter/vmaf_motion.h | 58 +++
> > 6 files changed, 440 insertions(+)
> [...]
> > +static av_cold int init(AVFilterContext *ctx)
> > +{
> > +VMAFMotionContext *s = ctx->priv;
> > +
> > +if (s->stats_file_str) {
> > +if (!strcmp(s->stats_file_str, "-")) {
>
> > +s->stats_file = stdout;
>
> Using stdout can interfere with the user application using the filter
>
>
> > +} else {
>
> > +s->stats_file = fopen(s->stats_file_str, "w");
>
> Opening a filter parameter provided string for writing is a dangerous
> way to output data. It allows one with access to the parameters to
> overwrite any writable file
>
> data should only be output in a safe way
>
> >>>
> >>> The same mechanism is present in ssim/psnr filters. I'm open to any
> >>> alternative method you suggest. These are only settable using explicit
> >>> user
> >>> interaction (and are disabled by default) so I don't particularly see the
> >>> problem.
> >>
> >> With this a filter graph can never be taken from an untrusted source
> >>
> >> One filter that outputs statistics without writing to a user specified
> >> filename is libavfilter/af_astats.c
> >
> > So what? Get over it.
>
> What kind of reply is this? What made you think it's justified?
> He literally gave an example of an alternative method as Ronald requested.
>
> Some of you people need to chill out already when discussing patches.
Michael apparently just comes up randomly with this stuff to block
patches...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.4
On 2017-10-06 10:53, Michael Niedermayer wrote: > If people prefer a specific name, suggest one now, otherwise i will > pick a random one from past suggestions What about Cantor? Has this name already been used? -- regards Helmut K. C. Tessarek KeyID 0xF7832007C11F128D Key fingerprint = 28A3 1666 4FE8 D72C CFD5 8B23 F783 2007 C11F 128D /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-cvslog] avfilter: add vmafmotion filter
On 10/6/2017 7:09 PM, wm4 wrote:
> On Fri, 6 Oct 2017 18:02:44 -0300
> James Almer wrote:
>
>> On 10/6/2017 5:44 PM, Paul B Mahol wrote:
>>> On 10/6/17, Michael Niedermayer wrote:
On Fri, Oct 06, 2017 at 10:03:16AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Oct 5, 2017 at 7:52 PM, Michael Niedermayer
>
> wrote:
>
>> On Sat, Sep 30, 2017 at 03:51:41PM +, Ashish Singh wrote:
>>> ffmpeg | branch: master | Ashish Singh | Sat
>>> Sep
>> 16 02:35:58 2017 +0530| [148c8e88c43cfbabd6aee9f01ef30942cee9d359] |
>> committer: Ronald S. Bultje
>>>
>>> avfilter: add vmafmotion filter
>>>
>>> Signed-off-by: Ashish Singh
>>> Signed-off-by: Ronald S. Bultje
>>>
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=
>> 148c8e88c43cfbabd6aee9f01ef30942cee9d359
>>> ---
>>>
>>> Changelog | 1 +
>>> doc/filters.texi| 14 ++
>>> libavfilter/Makefile| 1 +
>>> libavfilter/allfilters.c| 1 +
>>> libavfilter/vf_vmafmotion.c | 365 ++
>> ++
>>> libavfilter/vmaf_motion.h | 58 +++
>>> 6 files changed, 440 insertions(+)
>> [...]
>>> +static av_cold int init(AVFilterContext *ctx)
>>> +{
>>> +VMAFMotionContext *s = ctx->priv;
>>> +
>>> +if (s->stats_file_str) {
>>> +if (!strcmp(s->stats_file_str, "-")) {
>>
>>> +s->stats_file = stdout;
>>
>> Using stdout can interfere with the user application using the filter
>>
>>
>>> +} else {
>>
>>> +s->stats_file = fopen(s->stats_file_str, "w");
>>
>> Opening a filter parameter provided string for writing is a dangerous
>> way to output data. It allows one with access to the parameters to
>> overwrite any writable file
>>
>> data should only be output in a safe way
>>
>
> The same mechanism is present in ssim/psnr filters. I'm open to any
> alternative method you suggest. These are only settable using explicit
> user
> interaction (and are disabled by default) so I don't particularly see the
> problem.
With this a filter graph can never be taken from an untrusted source
One filter that outputs statistics without writing to a user specified
filename is libavfilter/af_astats.c
>>>
>>> So what? Get over it.
>>
>> What kind of reply is this? What made you think it's justified?
>> He literally gave an example of an alternative method as Ronald requested.
>>
>> Some of you people need to chill out already when discussing patches.
>
> Michael apparently just comes up randomly with this stuff to block
> patches...
Nobody comes up "randomly" with concerns. Especially not to block
patches for the sake of blocking, because if they were bullshit
arguments then they would be easy to counter and discard.
At this point you're just expressing frustration over having negative
reviews or blocking concerns on patches. Sure, it would be great to
finish writing something, sending it to the ML and always get a LGTM as
reply, but if it doesn't happen then you shouldn't chalk it up to
pedantry from the other side.
So again, chill out, and discuss/argue. Ask for other devs to chime in
if necessary to tip the scales. But please, stop heating up every single
thread.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/v4l2: fix single plane decoding
On 06/10/17 22:25, Jorge Ramirez-Ortiz wrote:
> On 10/06/2017 09:47 PM, Mark Thompson wrote:
>> On 06/10/17 08:51, Jorge Ramirez-Ortiz wrote:
>>> ---
>>> libavcodec/v4l2_buffers.c | 14 --
>>> 1 file changed, 12 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
>>> index ef7d040..ba70c5d 100644
>>> --- a/libavcodec/v4l2_buffers.c
>>> +++ b/libavcodec/v4l2_buffers.c
>>> @@ -244,13 +244,23 @@ static int v4l2_buf_to_bufref(V4L2Buffer *in, int
>>> plane, AVBufferRef **buf)
>>> static int v4l2_bufref_to_buf(V4L2Buffer *out, int plane, const
>>> uint8_t* data, int size, AVBufferRef* bref)
>>> {
>>> + unsigned int bytesused, length;
>>> +
>>> if (plane >= out->num_planes)
>>> return AVERROR(EINVAL);
>>> + bytesused = FFMIN(size, out->plane_info[plane].length);
>>> + length = out->plane_info[plane].length;
>>> +
>>> memcpy(out->plane_info[plane].mm_addr, data, FFMIN(size,
>>> out->plane_info[plane].length));
>>> - out->planes[plane].bytesused = FFMIN(size,
>>> out->plane_info[plane].length);
>>> - out->planes[plane].length = out->plane_info[plane].length;
>>> + if (V4L2_TYPE_IS_MULTIPLANAR(out->buf.type)) {
>>> + out->planes[plane].bytesused = bytesused;
>>> + out->planes[plane].length = length;
>>> + } else {
>>> + out->buf.bytesused = bytesused;
>>> + out->buf.length = length;
>>> + }
>>> return 0;
>>> }
>>>
>> Can you clarify what devices are being fixed here? I believe there are two
>> modes (single-plane, multi-plane) - of the devices known to work, do we know
>> which modes they use?
>
> venus driver in Qualcomm SoC - 96Bords db410c[1] - > multiplanar
> coda driver for Imx6 - cubox[2] -> single plane
>
> [1] https://www.96boards.org/product/dragonboard410c/
> [2] https://www.solid-run.com/freescale-imx6-family/cubox-i/
>
> the patch above fixes single plan decoding
Ok, good to know that this case is now tested. LGTM, and applied.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Makefile: generate stripped CLI tools directly instead of copying unstripped ones first
On 10/6/2017 5:20 PM, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > Makefile | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/Makefile b/Makefile > index 4a1253a052..adb8330fa0 100644 > --- a/Makefile > +++ b/Makefile > @@ -97,8 +97,7 @@ include $(SRC_PATH)/doc/examples/Makefile > libavcodec/utils.o libavformat/utils.o libavdevice/avdevice.o > libavfilter/avfilter.o libavutil/utils.o libpostproc/postprocess.o > libswresample/swresample.o libswscale/utils.o : libavutil/ffversion.h > > $(PROGS): %$(PROGSSUF)$(EXESUF): %$(PROGSSUF)_g$(EXESUF) > - $(CP) $< $@ > - $(STRIP) $@ > + $(STRIP) -o $@ $< LGTM. This is the best thing after stripping on install, which seems to be disliked. > > %$(PROGSSUF)_g$(EXESUF): $(FF_DEP_LIBS) > $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(OBJS-$*) $(FF_EXTRALIBS) > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] mov: fix decode of fragments that overlap in time
On Thu, Oct 05, 2017 at 02:38:48PM -0700, John Stebbins wrote: > On 10/05/2017 09:45 AM, John Stebbins wrote: > > On 10/04/2017 03:21 PM, Michael Niedermayer wrote: > >> On Wed, Oct 04, 2017 at 10:58:19AM -0700, John Stebbins wrote: > >>> On 10/04/2017 10:13 AM, Michael Niedermayer wrote: > On Wed, Oct 04, 2017 at 08:18:59AM -0700, John Stebbins wrote: > > On 10/04/2017 03:50 AM, Michael Niedermayer wrote: > >> On Fri, Sep 29, 2017 at 08:54:08AM -0700, John Stebbins wrote: > >>> When keyframe intervals of dash segments are not perfectly aligned, > >>> fragments in the stream can overlap in time. Append new "trun" index > >>> entries to the end of the index instead of sorting by timestamp. > >>> Sorting by timestamp causes packets to be read out of decode order and > >>> results in decode errors. > >>> --- > >>> libavformat/mov.c | 4 ++-- > >>> 1 file changed, 2 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/libavformat/mov.c b/libavformat/mov.c > >>> index 899690d920..c7422cd9ed 100644 > >>> --- a/libavformat/mov.c > >>> +++ b/libavformat/mov.c > >>> @@ -4340,8 +4340,8 @@ static int mov_read_trun(MOVContext *c, > >>> AVIOContext *pb, MOVAtom atom) > >>>MOV_FRAG_SAMPLE_FLAG_DEPENDS_YES)); > >>> if (keyframe) > >>> distance = 0; > >>> -ctts_index = av_add_index_entry(st, offset, dts, > >>> sample_size, distance, > >>> -keyframe ? AVINDEX_KEYFRAME > >>> : 0); > >>> +ctts_index = add_index_entry(st, offset, dts, sample_size, > >>> distance, > >>> + keyframe ? AVINDEX_KEYFRAME : > >>> 0); > >> can this lead to timestamps being out of order not just changing > >> from strictly monotone to monotone ? > >> > >> Maybe iam missing somehing but out of order could/would cause problems > >> with av_index_search_timestamp() and possibly others > >> > >> > > I'm not sure I understand the question. But I think I can answer. The > > new fragment can start before the last fragment > > ends. I'll make a concrete example. Lets say the new fragment's first > > DTS is 10 frames before the end of the previous > > fragment. So the first DTS of the new fragment is before the timestamp > > of 10 entries in the index from the previous > > fragment. av_add_index_entry searches the existing index and inserts > > the first sample of the new fragment in position > > nb_index_entries - 10 (and shifts the existing entries). The next 9 > > samples of the new fragment get intermixed with the > > remaining 9 samples of the previous fragment, sorted by DTS. When the > > samples are read out, you get samples from the > > last fragment and the new fragment interleaved together causing > > decoding errors. > > > > Using add_index_entry will result in the timestamps in the index going > > backwards by 10 frames at the fragment boundary > > in this example. In the other patch that accompanied this one, I've > > marked the samples from the new fragment that > > overlap previous samples with AVINDEX_DISCARD. > > ff_index_search_timestamp appears to be AVINDEX_DISCARD aware. So I > > think av_index_search_timestamp will do the right thing. > yes, that makes sense now. > Please correct me if iam wrong but then patch 1 would introduce a > issue that the 2nd fixes. So both patches should be merged to avoid > this > > But theres another problem, trun can be read out of order, when one > seeks around, so the next might have to be put elsewhere than after the > previous > > thanks > > >>> Hmm, can you describe the circumstances where this would happen. I > >>> looked at the seek code and can't see any way for it > >>> to seek to the middle somewhere without first reading previous trun. It > >>> looks to me like if avformat_seek_file or > >>> av_seek_frame fails to find the desired timestamp in the index it falls > >>> back to seek_frame_generic which seeks to the > >>> position of the last sample in the index and performs av_read_frame until > >>> it gets to the timestamp it wants. Is there a > >>> path I've missed where it can skip to the middle of the file somehow? > >> I used > >> -rw-r- 1 michael michael 66908195 Dec 11 2015 buck480p30_na.mp4 > >> ./ffplay buck480p30_na.mp4 > >> > >> (i can upload this if needed, i dont know where its from exactly) > >> > >> and when seeking around by using the right mouse buttonq it sometimes read > >> trun chunks with lower times than previous (seen from the av_logs in > >> there) > >> > >> I hope i made no mistake and would assume this happens with any file > >> with these chunks > >> > >> ... > >> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f3884000940] AV
[FFmpeg-devel] [PATCH] Fix signed integer overflow in mov_write_single_packet Detected with clang and -fsanitize=signed-integer-overflow
Signed-off-by: Vitaly Buka --- libavformat/movenc.c | 4 1 file changed, 4 insertions(+) diff --git a/libavformat/movenc.c b/libavformat/movenc.c index 2838286141..e70500ae2c 100644 --- a/libavformat/movenc.c +++ b/libavformat/movenc.c @@ -5354,6 +5354,10 @@ static int mov_write_single_packet(AVFormatContext *s, AVPacket *pkt) // duration, but only helps for this particular track, not // for the other ones that are flushed at the same time. trk->track_duration = pkt->dts - trk->start_dts; +if (trk->start_dts != AV_NOPTS_VALUE) +trk->track_duration = pkt->dts - trk->start_dts; +else +trk->track_duration = 0; if (pkt->pts != AV_NOPTS_VALUE) trk->end_pts = pkt->pts; else -- 2.14.2.920.gcf0c67979c-goog ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Makefile: generate stripped CLI tools directly instead of copying unstripped ones first
On 10/6/2017 8:20 PM, James Almer wrote: > On 10/6/2017 5:20 PM, Marton Balint wrote: >> Signed-off-by: Marton Balint >> --- >> Makefile | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/Makefile b/Makefile >> index 4a1253a052..adb8330fa0 100644 >> --- a/Makefile >> +++ b/Makefile >> @@ -97,8 +97,7 @@ include $(SRC_PATH)/doc/examples/Makefile >> libavcodec/utils.o libavformat/utils.o libavdevice/avdevice.o >> libavfilter/avfilter.o libavutil/utils.o libpostproc/postprocess.o >> libswresample/swresample.o libswscale/utils.o : libavutil/ffversion.h >> >> $(PROGS): %$(PROGSSUF)$(EXESUF): %$(PROGSSUF)_g$(EXESUF) >> -$(CP) $< $@ >> -$(STRIP) $@ >> +$(STRIP) -o $@ $< > > LGTM. This is the best thing after stripping on install, which seems to > be disliked. Actually, configure seems to consider cases where STRIP is something else than binutils' strip. I guess it's known and tested to work with the to-be-stripped binary as the only argument, but would -o work with every potential strip program, or for that matter binutils on every supported platform? I already got bitten by MacOS's install not accepting -T. > >> >> %$(PROGSSUF)_g$(EXESUF): $(FF_DEP_LIBS) >> $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(OBJS-$*) $(FF_EXTRALIBS) >> > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] JPEG2000: SSE optimisation of DWT decoding
On Fri, Oct 06, 2017 at 05:30:57PM +0200, Nicolas Bertrand wrote: > From: Maxime Taisant > > --- > libavcodec/jpeg2000dwt.c | 45 +- > libavcodec/jpeg2000dwt.h |5 + > libavcodec/x86/jpeg2000dsp.asm| 1339 > + > libavcodec/x86/jpeg2000dsp_init.c | 119 > tests/checkasm/jpeg2000dsp.c |1 + > 5 files changed, 1496 insertions(+), 13 deletions(-) This fails to build on x86-32 linux src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r7q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r10q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r10q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r11q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r11q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r11q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r11q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r11q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r11q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r10q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r11q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r9q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r9q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r9q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r8q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r8q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r8q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r9q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r8q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r8q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r8q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r9q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r9q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r10q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r11q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r8q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r8q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r9q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r8q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r10q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r11q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r9q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r8q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r10q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r8q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r9q' undefined src/libavcodec/x86/jpeg2000dsp.asm:938: error: symbol `r10q' undefined ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Take away the freedom of one citizen and you will be jailed, take away the freedom of all citizens and you will be congratulated by your peers in Parliament. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix signed integer overflow in mov_write_single_packet Detected with clang and -fsanitize=signed-integer-overflow
2017-10-07 1:20 GMT+02:00 Vitaly Buka : > Signed-off-by: Vitaly Buka > --- > libavformat/movenc.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/libavformat/movenc.c b/libavformat/movenc.c > index 2838286141..e70500ae2c 100644 > --- a/libavformat/movenc.c > +++ b/libavformat/movenc.c > @@ -5354,6 +5354,10 @@ static int mov_write_single_packet(AVFormatContext *s, > AVPacket *pkt) > // duration, but only helps for this particular track, not > // for the other ones that are flushed at the same time. > trk->track_duration = pkt->dts - trk->start_dts; > +if (trk->start_dts != AV_NOPTS_VALUE) > +trk->track_duration = pkt->dts - trk->start_dts; > +else > +trk->track_duration = 0; I suspect you wanted to remove the line immediately before the new lines, no? Please consider adding braces around the else. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mp3enc: flush buffered packets if referencing fails
On Fri, Oct 06, 2017 at 03:58:59PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > libavformat/mp3enc.c | 9 ++--- > 1 file changed, 2 insertions(+), 7 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpegtsenc add synchronous metadata
On Fri, Oct 06, 2017 at 01:37:40PM +0200, Mark Timmerman wrote: > Add synchronous metadata to mpegtsenc > * Added AV_CODEC_ID_SYNCHRONOUS_METADATA > * PMT will have metadata_descriptor and metadata_std_descriptor > in accordance with MISB ST 1402.2 > * stream_type will be 0x15 metadata carried in PES packets > * stream_id will be 0xfc metadata stream > > Users must supply Metadata Access Unit to the packet before writing. > libavcodec/avcodec.h|1 + > libavcodec/codec_desc.c |6 ++ > libavformat/mpegtsenc.c | 22 ++ > 3 files changed, 29 insertions(+) > adfd981b08a5133d7b4a0993153d13f037a03904 0001-synchronous-metadata.patch please add a fate test for this [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mp3enc: flush buffered packets if referencing fails
On 10/6/2017 9:42 PM, Michael Niedermayer wrote: > On Fri, Oct 06, 2017 at 03:58:59PM -0300, James Almer wrote: >> Signed-off-by: James Almer >> --- >> libavformat/mp3enc.c | 9 ++--- >> 1 file changed, 2 insertions(+), 7 deletions(-) > > LGTM > > thx Pushed, thanks. ___ 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
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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/img2dec: Auto-detect svg images
2017-10-02 11:42 GMT+02:00 Carl Eugen Hoyos :
> 2017-10-02 7:52 GMT+02:00 Clément Bœsch :
>> On Mon, Oct 02, 2017 at 01:20:15AM +0200, Carl Eugen Hoyos wrote:
>>> Hi!
>>>
>>> Attached patch implements auto-detection of svg images.
>>>
>>> Please review, Carl Eugen
>>
>>> From f06137f38f166740565e58d5c7c88777508f59ec Mon Sep 17 00:00:00 2001
>>> From: Carl Eugen Hoyos
>>> Date: Mon, 2 Oct 2017 01:13:29 +0200
>>> Subject: [PATCH] lavf/img2dec: Auto-detect svg images.
>>>
>>> ---
>>> libavformat/img2dec.c | 17 +++--
>>> 1 file changed, 15 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
>>> index 19cae87..468c820 100644
>>> --- a/libavformat/img2dec.c
>>> +++ b/libavformat/img2dec.c
>>> @@ -34,6 +34,7 @@
>>> #include "internal.h"
>>> #include "img2.h"
>>> #include "libavcodec/mjpeg.h"
>>> +#include "subtitles.h"
>>>
>>> #if HAVE_GLOB
>>> /* Locally define as 0 (bitwise-OR no-op) any missing glob options that
>>> @@ -875,8 +876,20 @@ static int sunrast_probe(AVProbeData *p)
>>>
>>> static int svg_probe(AVProbeData *p)
>>> {
>>> -if (av_match_ext(p->filename, "svg") || av_match_ext(p->filename,
>>> "svgz"))
>>> -return AVPROBE_SCORE_EXTENSION + 1;
>>> +const uint8_t *b = p->buf;
>>> +const uint8_t *end = p->buf + p->buf_size;
>>> +if (memcmp(p->buf, ">> +return 0;
>>> +while (b < end) {
>>> +b += ff_subtitles_next_line(b);
>>> +if (b >= end)
>>> +return 0;
>>
>>> +if (!strstr(b, ">> +continue;
>>
>> at least the svg from inkscape do not have a doctype
>
> Wrong check, thank you.
>
>>> +b += 9;
>>> +if (strstr(b, "svg"))
>>> +return AVPROBE_SCORE_MAX;
>>> +}
>>
>> don't you want to keep an extension fallback?
>
> That's done by the image2 demuxer.
>
>> also, I would guess strstr() is going to be slow, so maybe
>> just look for a line starting with "
> Done, thank you.
>
> New patch attached, Carl Eugen
Patch applied.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]configure: Add -Wno-main
2017-09-18 3:37 GMT+02:00 Carl Eugen Hoyos : > Hi! > > Attached patch fixes several warnings when compiling libavfilter with > current gcc. Ping. Should the warnings just stay? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/rtpenc: Add support for little-endian G.726
2017-08-26 11:55 GMT+02:00 Carl Eugen Hoyos : > Hi! > > Attached patch adds little-endian G.726 support to rtpenc, using the > MIME-type suggested by RFC 3551. Anybody? Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/sdp: Fix MIME-type for big-endian G.726 audio.
2017-08-26 11:53 GMT+02:00 Carl Eugen Hoyos : > Hi! > > Attached patch follows RFC 3551, a followup patch adds little-endian > G.726 with the old MIME-type. Same here: Please comment, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]configure: Add -Wno-main
On 10/6/2017 10:45 PM, Carl Eugen Hoyos wrote: > 2017-09-18 3:37 GMT+02:00 Carl Eugen Hoyos : >> Hi! >> >> Attached patch fixes several warnings when compiling libavfilter with >> current gcc. > > Ping. > > Should the warnings just stay? > > Thank you, Carl Eugen I'll change the name of the variables as mentioned elsewhere in the thread. What name should i use, though? I see AVFrame *main, *ref; and AVFrame *main, *second, *out; In all four filters raising the warning. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH RFC] libavdevice/decklink: Add support for EIA-708 output over SDI
On Fri, Oct 6, 2017 at 4:31 PM, Devin Heitmueller wrote: > > Ah, I understand now. > > Yes, the decklink device is currently the only SDI device which is supported > by libavdevice. I’ve got a whole pile of patches coming which add support > for a variety of protocols for both capture and output (e.g. EIA-708, > SCTE-104, AFD, SMPTE 2038, etc). But today the decklink module is the only > device supported. > > Would love to see more SDI devices supported and potentially interested in > adding such support myself if we can find good candidates. The DVEO/linsys > cards are largely obsolete and the AJA boards are significantly more > expensive than any of BlackMagic’s cards. If anyone has good experiences > with other vendors I would like to hear about it (and there may be an > opportunity to extend libavdevice to support another SDI vendor). Bluefish has some very nice ($$$) SDI cards with Linux support. I think their SDK also supports v4l2. Have never been able to get my hands on one though. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
