Re: [FFmpeg-devel] [PATCH] lavd: implement threaded NewTek NDI output
04.09.2017 17:10, Maksym Veremeyenko пише:
Hi,
attached patch implemented threaded NDI output - separate output thread
for each stream. it makes audio preview in my case more smooth.
updated patch allows running audio/video threads separately
please review
--
Maksym Veremeyenko
From 67ee166a5504d72294638125b210f58c88973a54 Mon Sep 17 00:00:00 2001
From: Maksym Veremeyenko
Date: Tue, 5 Sep 2017 03:04:11 -0400
Subject: [PATCH 1/3] lavd: implement threaded NewTek NDI output
---
configure | 2 +-
doc/outdevs.texi| 8 ++
libavdevice/libndi_newtek_enc.c | 171 +++-
3 files changed, 178 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
index d582705..7626901 100755
--- a/configure
+++ b/configure
@@ -3019,7 +3019,7 @@ decklink_outdev_deps="decklink threads"
decklink_outdev_extralibs="-lstdc++"
libndi_newtek_indev_deps="libndi_newtek"
libndi_newtek_indev_extralibs="-lndi"
-libndi_newtek_outdev_deps="libndi_newtek"
+libndi_newtek_outdev_deps="libndi_newtek threads"
libndi_newtek_outdev_extralibs="-lndi"
dshow_indev_deps="IBaseFilter"
dshow_indev_extralibs="-lpsapi -lole32 -lstrmiids -luuid -loleaut32 -lshlwapi"
diff --git a/doc/outdevs.texi b/doc/outdevs.texi
index 0012b0f..595864b 100644
--- a/doc/outdevs.texi
+++ b/doc/outdevs.texi
@@ -213,6 +213,14 @@ Defaults to @option{false}.
These specify whether audio "clock" themselves.
Defaults to @option{false}.
+@item video_queue
+Enable video packets output in separate thread. Specify video packets queue
length.
+Defaults to @option{0}.
+
+@item audio_queue
+Enable audio packets output in separate thread. Specify audio packets queue
length.
+Defaults to @option{0}.
+
@end table
@subsection Examples
diff --git a/libavdevice/libndi_newtek_enc.c b/libavdevice/libndi_newtek_enc.c
index 6ca6f41..f8af851 100644
--- a/libavdevice/libndi_newtek_enc.c
+++ b/libavdevice/libndi_newtek_enc.c
@@ -23,9 +23,16 @@
#include "libavformat/internal.h"
#include "libavutil/opt.h"
#include "libavutil/imgutils.h"
+#include "libavutil/threadmessage.h"
#include "libndi_newtek_common.h"
+#include
+
+#define THREAD_VIDEO0
+#define THREAD_AUDIO1
+#define THREAD_LAST 2
+
struct NDIContext {
const AVClass *cclass;
@@ -37,12 +44,104 @@ struct NDIContext {
NDIlib_audio_frame_interleaved_16s_t *audio;
NDIlib_send_instance_t ndi_send;
AVFrame *last_avframe;
+
+/* threaded operations */
+AVFormatContext *avctx;
+struct
+{
+int length;
+AVThreadMessageQueue *queue;
+pthread_t thread;
+} threads[THREAD_LAST];
};
+static int ndi_write_video_packet(AVFormatContext *avctx, AVStream *st,
AVPacket *pkt);
+static int ndi_write_audio_packet(AVFormatContext *avctx, AVStream *st,
AVPacket *pkt);
+
+static void* ndi_thread_audio(void* p)
+{
+int ret;
+AVPacket pkt;
+struct NDIContext *ctx = p;
+
+av_log(ctx->avctx, AV_LOG_DEBUG, "%s: entering\n", __func__);
+
+while (1) {
+ret = av_thread_message_queue_recv(ctx->threads[THREAD_AUDIO].queue,
&pkt, 0);
+if (ret < 0) {
+if (ret != AVERROR_EOF)
+av_log(ctx->avctx, AV_LOG_ERROR, "Failed
av_thread_message_queue_recv of audio queue.\n");
+break;
+}
+
+ret = ndi_write_audio_packet(ctx->avctx,
ctx->avctx->streams[pkt.stream_index], &pkt);
+av_packet_unref(&pkt);
+if (ret) {
+av_log(ctx->avctx, AV_LOG_ERROR, "Failed
ndi_write_audio_packet.\n");
+break;
+}
+}
+
+av_log(ctx->avctx, AV_LOG_DEBUG, "%s: exiting, ret=%d\n", __func__, ret);
+
+return NULL;
+}
+
+static void* ndi_thread_video(void* p)
+{
+int ret;
+AVPacket pkt;
+struct NDIContext *ctx = p;
+
+av_log(ctx->avctx, AV_LOG_DEBUG, "%s: entering\n", __func__);
+
+while (1) {
+ret = av_thread_message_queue_recv(ctx->threads[THREAD_VIDEO].queue,
&pkt, 0);
+if (ret < 0) {
+if (ret != AVERROR_EOF)
+av_log(ctx->avctx, AV_LOG_ERROR, "Failed
av_thread_message_queue_recv of video queue.\n");
+break;
+}
+
+ret = ndi_write_video_packet(ctx->avctx,
ctx->avctx->streams[pkt.stream_index], &pkt);
+av_packet_unref(&pkt);
+if (ret) {
+av_log(ctx->avctx, AV_LOG_ERROR, "Failed
ndi_write_video_packet.\n");
+break;
+}
+}
+
+av_log(ctx->avctx, AV_LOG_DEBUG, "%s: exiting, ret=%d\n", __func__, ret);
+
+return NULL;
+}
+
static int ndi_write_trailer(AVFormatContext *avctx)
{
+int i;
struct NDIContext *ctx = avctx->priv_data;
+for (i = 0; i < THREAD_LAST; i++)
+{
+AVPacket pkt;
+
+if (!ctx->threads[i].queue)
+continue;
+
+av_log(ctx->avctx, AV_LOG_DEBUG, "%s: freeing queue %d\n", __func__,
i);
+
+av_thread_message_queue_set_err_recv(ctx->threads[i].queue,
AVERROR_E
Re: [FFmpeg-devel] [PATCHv8] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 09/05/2017 12:16 AM, Mark Thompson wrote:
On 04/09/17 22:55, Jorge Ramirez wrote:
On 09/04/2017 11:29 PM, Mark Thompson wrote:
... stuff ...
So the sequence of calls is:
send_frame(frame 0) -> success
receive_packet() -> EAGAIN
send_frame(frame 1) -> success
receive_packet() -> EAGAIN
...
send_frame(frame 15) -> success
receive_packet() -> EAGAIN
send_frame(frame 16) -> success
receive_packet() -> packet 0
receive_packet() -> packet 1
...
receive_packet() -> packet 15
receive_packet() -> packet 16
receive_packet() -> blocks
This appears correct to me - since EAGAIN has not been returned by a
receive_packet() call, it can be called again repeatedly (as documented in
avcodec.h). Do you disagree?
I would have expected that after a packet is received, a new frame is enqueued
instead of executing again receive_packet (why do we that? what is the benefit?)
under these circumsntances I can't block in receive_packet blindly, I have to
track in user-space what the driver has in its guts and predict how much it
needs to keep workingI dont think it is a good idea.
Feel free to submit a patch to avcodec.h which changes the definition of the
API.
no, that is ok. I can work around it easily (maybe v4l2 has special
needs compared to the rest of ffmpeg)
I think that the problem is that you are only polling on the frame buffer queue when
blocking, so you don't see the packet buffers becoming free in the packet buffer
queue - if you did see and dequeue them, you would then return EAGAIN to indicate
that more input is needed. (See comments in
.)
I could manually track it that way with additional counters - so before
blocking I could see count many frames are enqueued in the input and if there
is not at least one I could just return EAGAIN.
but the behaviour differs from encoding.
The behaviour is identical. You return the output buffer if there is one
available on the output queue, otherwise you return EAGAIN if there is any
space on the input queue, otherwise you block waiting for either of those to
become possible.
but we must be talking about different things because what I observe in
decode it is 180 degrees away from identical
In the decode case the receive_frame API (a single call for input and
output) can implement a simple model [1]
- receive a packet,
- push it to the input queue (push till the input queue is full at init)
- block for data to be ready in the output queue.
static int v4l2m2m_receive_frame(AVCodecContext *avctx, AVFrame *frame)
{
V4L2m2mContext *s = avctx->priv_data;
V4L2Context *const capture = &s->capture;
V4L2Context *const output = &s->output;
AVPacket avpkt = {0};
int timeout = -1;/* block for capture ready */
int ret;
ret = ff_decode_get_packet(avctx, &avpkt);
if (ret < 0 && ret != AVERROR_EOF)
return ret;
if (s->draining)
goto dequeue;
ret = ff_v4l2_enqueue_packet(output, &avpkt);
if (ret < 0)
return ret;
if (avpkt.size) {
ret = try_start(avctx);
if (ret)
return 0;
}
if (!s->data_queued) {
if (output->ops.get_buffer(output))
return AVERROR(EAGAIN);
else s->data_queued = 1;
}
dequeue:
return ff_v4l2_dequeue_frame(capture, frame, timeout);
}
To sum up,. every time a packet is pushed to input, a frame can be dequeued.
However the encode API seems wrongly designed (heavy coupled) since
receive_frame has to check if there is space in the input queue.
Receive frame should only care about the output queue - otherwise what
is the reason for having two calls send_frame and receive_packet?
In my view, receive_packet should just block. And send_frame should be
called everytime a packet is received in receive_packet.
that way I can
1. fill the input pipe
2. start streaming always blocking for output.
in decoding I queue all buffers and then block in capture; everytime it
unblocks and returns a new frame back to ffmpeg, the next call just enqueues a
packet (it doesnt try to dequeue another frame) so the pipeline never stops.
I think the code should to be symmetrical for encoding and decoding...
Yes.
cool.
___
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] avcodec/snowdec: Check intra block dc differences.
On Mon, Sep 04, 2017 at 08:35:17PM +0200, wm4 wrote: [...] > > > > Can't we just remove this codec? It has no use other than causing > > > > potential security issues and maintenance. > > > > > > I agree about removing the encoder, but the decoder is needed for > > > existing streams. Unless everyone just argues it has no real world > > > samples for being an avcodec-only toy codec. > > > > > > If you send a patch removing the encoder without also trying to remove > > > all the things that currently depend on it (One or two filters i think) > > > then I'll +1 it. ffv1 and mpeg4 encoders are enough for any kind of > > > testing, fate or otherwise, that might require a native encoder. > > > > I find it a bit offensive that people suggest to remove the encoder i > > maintain. > > Can I add my own unused fringe codec with no users, as long as I > maintain it? Is there any reason to be so obsessed with snow? There are plenty of other "fringe" codecs in the codebase that only one person in the world cared about 10 years ago. Snow is one of the rare wavelet codecs, and as a result is much more valuable than many random basic game flavored codecs. And somehow, no one ever mention those. I don't personally care about game codecs or snow myself (probably nobody does), but I don't support this snow/swscale/whatever-michael-did killing circle jerk. This really feels like some form of constant harassment (I'm not even talking about IRC), and that's not acceptable. Please people, chill out. I understand the frustration when someone doesn't understand something that feel obvious to "everyone" and keep insisting on it, but that doesn't mean you should enter in some form of obsession and vengeance about anything he did/does/will do. ...aaand here I am, back in the "Insane people defending Michael all the time" category. Regards, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv8] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 09/05/2017 09:16 AM, Jorge Ramirez wrote: On 09/05/2017 12:16 AM, Mark Thompson wrote: On 04/09/17 22:55, Jorge Ramirez wrote: On 09/04/2017 11:29 PM, Mark Thompson wrote: ... stuff ... So the sequence of calls is: send_frame(frame 0) -> success receive_packet() -> EAGAIN send_frame(frame 1) -> success receive_packet() -> EAGAIN ... send_frame(frame 15) -> success receive_packet() -> EAGAIN send_frame(frame 16) -> success receive_packet() -> packet 0 receive_packet() -> packet 1 ... receive_packet() -> packet 15 receive_packet() -> packet 16 receive_packet() -> blocks This appears correct to me - since EAGAIN has not been returned by a receive_packet() call, it can be called again repeatedly (as documented in avcodec.h). Do you disagree? I would have expected that after a packet is received, a new frame is enqueued instead of executing again receive_packet (why do we that? what is the benefit?) under these circumsntances I can't block in receive_packet blindly, I have to track in user-space what the driver has in its guts and predict how much it needs to keep workingI dont think it is a good idea. Feel free to submit a patch to avcodec.h which changes the definition of the API. no, that is ok. I can work around it easily (maybe v4l2 has special needs compared to the rest of ffmpeg) I think that the problem is that you are only polling on the frame buffer queue when blocking, so you don't see the packet buffers becoming free in the packet buffer queue - if you did see and dequeue them, you would then return EAGAIN to indicate that more input is needed. (See comments in .) I could manually track it that way with additional counters - so before blocking I could see count many frames are enqueued in the input and if there is not at least one I could just return EAGAIN. but the behaviour differs from encoding. The behaviour is identical. You return the output buffer if there is one available on the output queue, otherwise you return EAGAIN if there is any space on the input queue, otherwise you block waiting for either of those to become possible. I made some modifications to the way I was dequeuing buffers so now it polls for both input and output queues. you were right, things work much smoother this way...thanks. having said that I still I find the encoding API wrongly defined (no need for two calls that are in fact highly couple to each other in my opinion) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] cpu: add a function for querying maximum required data alignment
On Mon, 4 Sep 2017 22:53:43 +0200
Michael Niedermayer wrote:
> On Mon, Sep 04, 2017 at 09:27:32PM +0200, wm4 wrote:
> > On Mon, 4 Sep 2017 21:18:35 +0200
> > Michael Niedermayer wrote:
> >
> > > On Sat, Sep 02, 2017 at 09:47:38PM -0300, James Almer wrote:
> > > > From: Anton Khirnov
> > > >
> > > > (cherry picked from commit e6bff23f1e11aefb16a2b5d6ee72bf7469c5a66e)
> > > > Signed-off-by: James Almer
> > > > ---
> > > > This is (afaics) the last API introduced to libav before the major bump.
> > > >
> > > > Now checking all the x86 flags that would require aligment of 16 bytes
> > > > or more.
> > > >
> > > > doc/APIchanges | 3 +++
> > > > libavutil/cpu.c | 35 +++
> > > > libavutil/cpu.h | 13 +
> > > > libavutil/version.h | 2 +-
> > > > 4 files changed, 52 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/doc/APIchanges b/doc/APIchanges
> > > > index 4effbf9364..6a57c210a9 100644
> > > > --- a/doc/APIchanges
> > > > +++ b/doc/APIchanges
> > > > @@ -15,6 +15,9 @@ libavutil: 2015-08-28
> > > >
> > > > API changes, most recent first:
> > > >
> > > > +2017-09-xx - xxx - lavu 55.75.100 / lavu 55.31.0 - cpu.h
> > > > + Add av_cpu_max_align() for querying maximum required data alignment.
> > > > +
> > > > 2017-09-01 - xxx - lavf 57.81.100 - avio.h
> > > >Add avio_read_partial().
> > > >
> > > > diff --git a/libavutil/cpu.c b/libavutil/cpu.c
> > > > index a22da0fa8c..4f04da2460 100644
> > > > --- a/libavutil/cpu.c
> > > > +++ b/libavutil/cpu.c
> > > > @@ -16,9 +16,11 @@
> > > > * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > > > 02110-1301 USA
> > > > */
> > > >
> > > > +#include
> > > > #include
> > > > #include
> > > >
> > > > +#include "attributes.h"
> > > > #include "cpu.h"
> > > > #include "cpu_internal.h"
> > > > #include "config.h"
> > > > @@ -299,3 +301,36 @@ int av_cpu_count(void)
> > > >
> > > > return nb_cpus;
> > > > }
> > > > +
> > > > +size_t av_cpu_max_align(void)
> > > > +{
> > > > +int av_unused flags = av_get_cpu_flags();
> > > > +
> > > > +#if ARCH_ARM || ARCH_AARCH64
> > > > +if (flags & AV_CPU_FLAG_NEON)
> > > > +return 16;
> > > > +#elif ARCH_PPC
> > > > +if (flags & AV_CPU_FLAG_ALTIVEC)
> > > > +return 16;
> > > > +#elif ARCH_X86
> > > > +if (flags & (AV_CPU_FLAG_AVX2 |
> > > > + AV_CPU_FLAG_AVX |
> > > > + AV_CPU_FLAG_FMA4 |
> > > > + AV_CPU_FLAG_FMA3))
> > > > +return 32;
> > > > +if (flags & (AV_CPU_FLAG_XOP |
> > > > + AV_CPU_FLAG_AESNI|
> > > > + AV_CPU_FLAG_SSE42|
> > > > + AV_CPU_FLAG_SSE4 |
> > > > + AV_CPU_FLAG_SSSE3|
> > > > + AV_CPU_FLAG_SSE3 |
> > > > + AV_CPU_FLAG_SSE2 |
> > > > + AV_CPU_FLAG_SSE |
> > > > + AV_CPU_FLAG_AVXSLOW |
> > > > + AV_CPU_FLAG_SSE3SLOW |
> > > > + AV_CPU_FLAG_SSE2SLOW))
> > > > +return 16;
> > > > +#endif
> > > > +
> > > > +return 8;
> > > > +}
> > > > diff --git a/libavutil/cpu.h b/libavutil/cpu.h
> > > > index de05593446..9e5d40affe 100644
> > > > --- a/libavutil/cpu.h
> > > > +++ b/libavutil/cpu.h
> > > > @@ -21,6 +21,8 @@
> > > > #ifndef AVUTIL_CPU_H
> > > > #define AVUTIL_CPU_H
> > > >
> > > > +#include
> > > > +
> > > > #include "attributes.h"
> > > >
> > > > #define AV_CPU_FLAG_FORCE0x8000 /* force usage of selected
> > > > flags (OR) */
> > >
> > >
> > > > @@ -113,4 +115,15 @@ int av_parse_cpu_caps(unsigned *flags, const char
> > > > *s);
> > > > */
> > > > int av_cpu_count(void);
> > > >
> > > > +/**
> > > > + * Get the maximum data alignment that may be required by FFmpeg.
> > > > + *
> > > > + * Note that this is affected by the build configuration and the CPU
> > > > flags mask,
> > > > + * so e.g. if the CPU supports AVX, but libavutil has been built with
> > > > + * --disable-avx or the AV_CPU_FLAG_AVX flag has been disabled through
> > > > + * av_set_cpu_flags_mask(), then this function will behave as if AVX
> > > > is not
> > > > + * present.
> > > > + */
> > > > +size_t av_cpu_max_align(void);
> > >
> > > This might interact badly with runtime cpu flags/mask changes
> > >
> > > If its used to choose the alignment for allocated frames and
> > > after some are allocated the cpu flags are changed there could be
> > > still frames in queues that may not have sufficient alignment for the
> > > new flags
> >
> > There's no such thing as runtime CPU flag changes.
>
> We even have an API to change the cpu flags at runtime.
>
> av_set_cpu_flags_mask() and av_force_cpu_flags()
>
> There is no restriction in the API on when they can be called.
>
> you can call av_force_cpu_flags(0) then open a decoder then call
> av_force_cpu_flags(AV_CPU_
Re: [FFmpeg-devel] [PATCHv8] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On Tue, 5 Sep 2017 10:03:49 +0200 Jorge Ramirez wrote: > On 09/05/2017 09:16 AM, Jorge Ramirez wrote: > > On 09/05/2017 12:16 AM, Mark Thompson wrote: > >> On 04/09/17 22:55, Jorge Ramirez wrote: > >>> On 09/04/2017 11:29 PM, Mark Thompson wrote: > > ... stuff ... > So the sequence of calls is: > > send_frame(frame 0) -> success > receive_packet() -> EAGAIN > send_frame(frame 1) -> success > receive_packet() -> EAGAIN > ... > send_frame(frame 15) -> success > receive_packet() -> EAGAIN > send_frame(frame 16) -> success > receive_packet() -> packet 0 > receive_packet() -> packet 1 > ... > receive_packet() -> packet 15 > receive_packet() -> packet 16 > receive_packet() -> blocks > > This appears correct to me - since EAGAIN has not been returned by > a receive_packet() call, it can be called again repeatedly (as > documented in avcodec.h). Do you disagree? > >>> I would have expected that after a packet is received, a new frame > >>> is enqueued instead of executing again receive_packet (why do we > >>> that? what is the benefit?) > >>> under these circumsntances I can't block in receive_packet blindly, > >>> I have to track in user-space what the driver has in its guts and > >>> predict how much it needs to keep workingI dont think it is a > >>> good idea. > >> Feel free to submit a patch to avcodec.h which changes the definition > >> of the API. > > > > no, that is ok. I can work around it easily (maybe v4l2 has special > > needs compared to the rest of ffmpeg) > > > >> > I think that the problem is that you are only polling on the frame > buffer queue when blocking, so you don't see the packet buffers > becoming free in the packet buffer queue - if you did see and > dequeue them, you would then return EAGAIN to indicate that more > input is needed. (See comments in > .) > >>> I could manually track it that way with additional counters - so > >>> before blocking I could see count many frames are enqueued in the > >>> input and if there is not at least one I could just return EAGAIN. > >>> but the behaviour differs from encoding. > >> The behaviour is identical. You return the output buffer if there is > >> one available on the output queue, otherwise you return EAGAIN if > >> there is any space on the input queue, otherwise you block waiting > >> for either of those to become possible. > > > > > I made some modifications to the way I was dequeuing buffers so now it > polls for both input and output queues. you were right, things work much > smoother this way...thanks. > > having said that I still I find the encoding API wrongly defined (no > need for two calls that are in fact highly couple to each other in my > opinion) The encoding API works exactly the same way as the decoding API, just that the decoding API has an helper internally that makes it easier to merge send/receive into 1 function. You could do the same on the encoding side. Other than that, the API is meant for single-threaded use, so we can't do things like randomly blocking calls and requiring reentrant calls from other threads to unblock them. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/snowdec: Check intra block dc differences.
On Tue, 5 Sep 2017 10:03:11 +0200 Clément Bœsch wrote: > On Mon, Sep 04, 2017 at 08:35:17PM +0200, wm4 wrote: > [...] > > > > > Can't we just remove this codec? It has no use other than causing > > > > > potential security issues and maintenance. > > > > > > > > I agree about removing the encoder, but the decoder is needed for > > > > existing streams. Unless everyone just argues it has no real world > > > > samples for being an avcodec-only toy codec. > > > > > > > > If you send a patch removing the encoder without also trying to remove > > > > all the things that currently depend on it (One or two filters i think) > > > > then I'll +1 it. ffv1 and mpeg4 encoders are enough for any kind of > > > > testing, fate or otherwise, that might require a native encoder. > > > > > > I find it a bit offensive that people suggest to remove the encoder i > > > maintain. > > > > Can I add my own unused fringe codec with no users, as long as I > > maintain it? > > Is there any reason to be so obsessed with snow? There are plenty of other > "fringe" codecs in the codebase that only one person in the world cared > about 10 years ago. Snow is one of the rare wavelet codecs, and as a > result is much more valuable than many random basic game flavored codecs. > And somehow, no one ever mention those. Those game codecs have actually some use. There are files in the wild that are available to many, and that aren't just demo/test files. But it's true that all these game codecs bloat the codebase, cause maintenance and security issues, and have little use. They barely have a justification to exist too. The only argument for snow is that it's a nice ideas. It might serve as some proof of concept. As a real codec, it appears to be unusable. > I don't personally care about game codecs or snow myself (probably nobody > does), but I don't support this snow/swscale/whatever-michael-did killing > circle jerk. This really feels like some form of constant harassment (I'm > not even talking about IRC), and that's not acceptable. Well, michael could just cut back on trying to force insane stuff. His obstinate attitude to force ridiculous patches and defending them like they're the only choice doesn't help. Even when we try to remove some of his sins, he'll defend it to death, no matter how crazy and stupid the code was (side data merging comes to mind). If you feel like what I'm doing is harassment, I can end my involvement with michael to avoid this - but only if you stop him from doing bad things. > Please people, chill out. I understand the frustration when someone > doesn't understand something that feel obvious to "everyone" and keep > insisting on it, but that doesn't mean you should enter in some form of > obsession and vengeance about anything he did/does/will do. > > ...aaand here I am, back in the "Insane people defending Michael all the > time" category. We don't really need more of that category. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/jpeg2000: Check that codsty->log2_prec_widths/heights has been initialized
On Tue, 5 Sep 2017 00:04:08 +0200
Michael Niedermayer wrote:
> Fixes: OOM
> Fixes: 2225/clusterfuzz-testcase-minimized-5505632079708160
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/jpeg2000.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/jpeg2000.c b/libavcodec/jpeg2000.c
> index 94efc94c4d..9e1bbc2ec4 100644
> --- a/libavcodec/jpeg2000.c
> +++ b/libavcodec/jpeg2000.c
> @@ -506,6 +506,10 @@ int ff_jpeg2000_init_component(Jpeg2000Component *comp,
> // update precincts size: 2^n value
> reslevel->log2_prec_width = codsty->log2_prec_widths[reslevelno];
> reslevel->log2_prec_height = codsty->log2_prec_heights[reslevelno];
> +if (!reslevel->log2_prec_width || !reslevel->log2_prec_height) {
> +av_log(avctx, AV_LOG_ERROR, "COD/COC is missing\n");
> +return AVERROR_INVALIDDATA;
> +}
>
> /* Number of bands for each resolution level */
> if (reslevelno == 0)
Just after we've _extensively_ discussed how such cryptic messages are
a bad idea, you're back with a new patch following exactly the same
pattern.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v23 1/2] avformat/dashdec: add dash demuxer base version
2017-09-01 18:26 GMT+08:00 Steven Liu :
> ffmpeg need a dash demuxer for demux the dash formats base on
> https://github.com/samsamsam-iptvplayer/exteplayer3/blob/master/tmp/ffmpeg/patches/3.2.2/01_add_dash_demux.patch
>
> TODO:
> 1. support multi bitrate dash.
>
> v2 fixed:
> 1. from autodetect to disabled
> 2. from camelCase code style to ffmpeg code style
> 3. from RepType to AVMediaType
> 4. fix variable typo
> 5. change time value from uint32_t to uint64_t
> 6. removed be used once API
> 7. change 'time(NULL)`, except it is not 2038-safe.' to av_gettime and
> av_timegm
> 8. merge complex free operation to free_fragment
> 9. use API from snprintf to av_asprintf
>
> v3 fixed:
> 1. fix typo from --enabled-xml2 to --enable-xml2
>
> v4 fixed:
> 1. from --enable-xml2 to --enable-libxml2
> 2. move system includes to top
> 3. remove nouse includes
> 4. rename enum name
> 5. add a trailing comma for the last entry enum
> 6. fix comment typo
> 7. add const to DASHContext class front
> 8. check sscanf if return arguments and give warning message when error
> 9. check validity before free seg->url and seg
> 10. check if the val is null, before use atoll
>
> v5 fixed:
> 1. fix typo from mainifest to manifest
>
> v6 fixed:
> 1. from realloc to av_realloc
> 2. from free to av_free
>
> v7 fixed:
> 1. remove the -lxml2 from configure when require_pkg_config
>
> v8 fixed:
> 1. fix replace filename template by av_asprintf secure problem
>
> v9 modified:
> 1. make manifest parser clearly
>
> v10 fixed:
> 1. fix function API name code style
> 2. remove redundant strreplace call
> 3. remove redundant memory operation and check return value from
> get_content_url()
> 4. add space between ) and {
> 5. remove no need to log the value for print
>
> v11 fixed:
> 1. from atoll to strtoll
> Suggested-by: Michael Niedermayer
>
> v12 fixed:
> 1. remove strreplace and instead by av_strreplace
> Suggested-by: Nicolas George
>
> v13 fixed:
> 1. fix bug: cannot play:
> http://dash.edgesuite.net/akamai/bbb_30fps/bbb_30fps.mpd
> Reported-by: Andy Furniss
>
> v14 fixed:
> 1. fix bug: TLS connection was non-properly terminated
> 2. fix bug: No trailing CRLF found in HTTP header
> Reported-by: Andy Furniss
>
> v15 fixed:
> 1. play youtube link: ffmpeg -i $(youtube-dl -J
> "https://www.youtube.com/watch?v=XmL19DOP_Ls"; | jq -r
> ".requested_formats[0].manifest_url")
> 2. code refine for timeline living stream
> Reported-by: Ricardo Constantino
>
> v16 fixed:
> 1. remove the snprintf and instead by get_segment_filename make safety
> 2. remove unnecessary loops
> 3. updated xmlStrcmp and xmlFree to av_* functions
> 4. merge code repeat into one function
> 5. add memory alloc faild check
> 6. update update_init_section and open_url
> 7. output safety error message when filename template not safe
> Suggested-by : wm4
>
> v17 fixed:
> 1. add memory alloc faild check
> 2. fix resource space error at free_representation
>
> v18 fixed:
> 1. add condition of template format
>
> v19 fixed:
> 1. fix typo of the option describe
>
> v20 fixed:
> 1. add the c->base_url alloc check
> 2. make the DASHTmplId same to dashenc
>
> v21 fixed:
> 1. remove get_repl_pattern_and_format and get_segment_filename
> 2. process use dashcomm APIs
>
> v22 fixed:
> 1. modify the include "dashcomm.h" to include "dash.h"
> 2. use internal API from dash_fill_tmpl_params to ff_dash_fill_tmpl_params
>
> Signed-off-by: Steven Liu
> Signed-off-by: samsamsam
> ---
> configure|4 +
> libavformat/Makefile |1 +
> libavformat/allformats.c |2 +-
> libavformat/dashdec.c| 1848
> ++
> 4 files changed, 1854 insertions(+), 1 deletion(-)
> create mode 100644 libavformat/dashdec.c
>
> diff --git a/configure b/configure
> index 4f1c172333..3f0d05a6f9 100755
> --- a/configure
> +++ b/configure
> @@ -272,6 +272,7 @@ External library support:
>--enable-libxcb-shapeenable X11 grabbing shape rendering [autodetect]
>--enable-libxvid enable Xvid encoding via xvidcore,
> native MPEG-4/Xvid encoder exists [no]
> + --enable-libxml2 enable XML parsing using the C library libxml2
> [no]
>--enable-libzimg enable z.lib, needed for zscale filter [no]
>--enable-libzmq enable message passing via libzmq [no]
>--enable-libzvbi enable teletext support via libzvbi [no]
> @@ -1578,6 +1579,7 @@ EXTERNAL_LIBRARY_LIST="
> libvpx
> libwavpack
> libwebp
> +libxml2
> libzimg
> libzmq
> libzvbi
> @@ -2939,6 +2941,7 @@ avi_muxer_select="riffenc"
> caf_demuxer_select="iso_media riffdec"
> caf_muxer_select="iso_media"
> dash_muxer_select="mp4_muxer"
> +dash_demuxer_deps="libxml2"
> dirac_demuxer_select="dirac_parser"
> dts_demuxer_select="dca_parser"
> dtshd_demuxer_select="dca_parser"
> @@ -6006,6 +6009,7 @@ enabled openssl && { use_pkg_config openssl
> openssl/ssl.h OPENSSL_init
>
Re: [FFmpeg-devel] [PATCH 1/4] avdevice/decklink_dec: Added VANC search for all resolutions
>On 9/3/17, 4:48 PM, "Marton Balint" mailto:c...@passwd.hu>> >wrote: >That may well be true, but SMPTE 334M recommands to use lines "from >the second line after the line specified for switching to the last line >preceding active video, inclusive", so I'd skip at least the lines up to >the switching line, in order not to decode stuff which in fact belongs to >another source... And since we already keeping track of VANC line >numbers for each mode, it's almost no extra code to do this properly. >Instead of all the getter functions, I think it is simpler to create >struct for a mode/field combination, and use an array to store the mode >line settings. Then you can loop through the array and find your settings. Hi Marton, Thanks for your comments. Please find the patch attached, incorporating both the above suggestions. Regards, Karthick 0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch Description: 0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] avdevice/decklink_dec: Extraction of luma from V210 VANC modularized
>On 9/3/17, 5:18 PM, "Marton Balint" mailto:c...@passwd.hu>> >wrote: > >I think we only have vanc numbers until resolution of 1920 width, so that >should be enough. Probably better to add an av_assert which checks if >frame width is less or equal to FF_ARRAY_ELEMS(luma_vanc). Done. Please find the patch attached. Have handled that 1920 limit, little different from your suggested method. Hope it is fine. Regards, Karthick 0002-avdevice-decklink_dec-Extraction-of-luma-from-V210-V.patch Description: 0002-avdevice-decklink_dec-Extraction-of-luma-from-V210-V.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/dv : read dv audio as BE
> breaks playback of > http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4671/dir1.tar.bz2 > ./ffplay -enable_drefs 1 -i dir1/movie2.mov Fixed. P.S. I'm surprised libavcodec has DVAUDIO codec id with decoder, encoder, that (also) doesn't use that old code from the muxer/demuxer ... I guess my tries are little bit meaningless in this case. Anyway this is fun (even if I didn't expect it will be SO funny). Also anyway, thanks for your attention. No, I'm not stopping. -- С уважением, Александр mailto:alexander.sloboden...@bramtech.ru ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/dv : read dv audio as BE
>> breaks playback of >> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4671/dir1.tar.bz2 >> ./ffplay -enable_drefs 1 -i dir1/movie2.mov Fixed. P.S. I'm surprised libavcodec has DVAUDIO codec id with decoder, encoder, that (also) doesn't use that old code from the muxer/demuxer ... I guess my tries are little bit meaningless in this case. Anyway this is fun (even if I didn't expect it will be SO funny). Also anyway, thanks for your attention. No, I'm not stopping. -- С уважением, Александр mailto:alexander.sloboden...@bramtech.ru 0001-libavformat-dv-change-dv-audio-type-to-BE.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/dv : read dv audio as BE
On 9/5/17, Aleksandr Slobodenyuk wrote: >> breaks playback of >> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4671/dir1.tar.bz2 > >> ./ffplay -enable_drefs 1 -i dir1/movie2.mov > > Fixed. > > P.S. I'm surprised libavcodec has DVAUDIO codec id with decoder, > encoder, that (also) doesn't use that old code from the > muxer/demuxer ... I guess my tries are little bit meaningless in this > case. Anyway this is fun (even if I didn't expect it will be SO > funny). Also anyway, thanks for your attention. No, I'm not stopping. > Where is patch? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/dv : read dv audio as BE
> Where is patch? -- С уважением, Александр mailto:alexander.sloboden...@bramtech.ru 0001-libavformat-dv-change-dv-audio-type-to-BE.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/jpeg2000: Check that codsty->log2_prec_widths/heights has been initialized
Hi
On Mon, Sep 04, 2017 at 06:45:02PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Sep 4, 2017 at 6:04 PM, Michael Niedermayer
> wrote:
>
> > Fixes: OOM
> > Fixes: 2225/clusterfuzz-testcase-minimized-5505632079708160
> >
> > Found-by: continuous fuzzing process https://github.com/google/oss-
> > fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/jpeg2000.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/libavcodec/jpeg2000.c b/libavcodec/jpeg2000.c
> > index 94efc94c4d..9e1bbc2ec4 100644
> > --- a/libavcodec/jpeg2000.c
> > +++ b/libavcodec/jpeg2000.c
> > @@ -506,6 +506,10 @@ int ff_jpeg2000_init_component(Jpeg2000Component
> > *comp,
> > // update precincts size: 2^n value
> > reslevel->log2_prec_width = codsty->log2_prec_widths[
> > reslevelno];
> > reslevel->log2_prec_height = codsty->log2_prec_heights[
> > reslevelno];
> > +if (!reslevel->log2_prec_width || !reslevel->log2_prec_height) {
> > +av_log(avctx, AV_LOG_ERROR, "COD/COC is missing\n");
> > +return AVERROR_INVALIDDATA;
> > +}
>
>
> Please change it to ff_tlog().
that would make the message unavailable to the user, so the user
would not know why a decoding failure occured.
It would also make it unavailable in bug reports as the message is
not in the compiled binary. Even at highest verbosity and debug levels
it would not show up not even with debug builds. Only in special trace
builds would it show up.
Users would not be able to find existing bug reports based on the error
message, would not be able to google it, would not be able to refer to
it in a specific way "a issue with missing COC/COD".
This is not a obscure detail of bitstream parsing, its a error in
the headers that will lead to the loss of a frame.
Lets also look at what other software does
picking lena converted to jpeg2000 and a damaged COD with a hex editor
j2k_to_image -i lena-noco.jp2 -o image.pgm
[ERROR] Error decoding component 0.
The number of resolutions is too big: 256 vs max= 33. Truncating.
[ERROR] Error decoding component 1.
The number of resolutions is too big: 256 vs max= 33. Truncating.
[ERROR] Error decoding component 2.
The number of resolutions is too big: 256 vs max= 33. Truncating.
[ERROR] Failed to decode J2K image
ERROR -> j2k_to_image: failed to decode image!
You can see openjpeg shows detailed error messages
Lets try the clusterfuzz testcase directly:
j2k_to_image -i clusterfuzz-testcase-minimized-5505632079708160.jp2 -o
image.pnm
[ERROR] Integer overflow in box->length
[ERROR] Failed to read boxhdr
[ERROR] Failed to decode jp2 structure
ERROR -> j2k_to_image: failed to decode image!
again, a detailed error message
lets try jasper
jasper --input lena-noco.jp2 --output file.pnm
cannot get marker segment
error: cannot decode code stream
error: cannot load image data
and the testcase directly:
jasper --input clusterfuzz-testcase-minimized-5505632079708160 --output
image.pnm
cannot get marker segment
error: cannot load image data
and jasper also shows more than just a generic error
Thats by default. no debug build, no trace build, no verbosity, no
debug options.
just for completeness lets run jasper with debug level 99
jasper --debug-level 99 --input
clusterfuzz-testcase-minimized-5505632079708160.jp2 --output image.pnm
type = 0xff4f (SOC);
type = 0xff51 (SIZ); len = 41;caps = 0x2020;
width = 25632; height = 32; xoff = 0; yoff = 0;
tilewidth = 538976288; tileheight = 538976288; tilexoff = 0; tileyoff = 0;
prec[0] = 8; sgnd[0] = 0; hsamp[0] = 1; vsamp[0] = 1
type = 0xff52 (COD); len = 13;csty = 0x01;
numdlvls = 0; qmfbid = 0; mctrans = 0
prg = 32; numlyrs = 8224;
cblkwidthval = 32; cblkheightval = 32; cblksty = 0x20;
prcwidth[0] = 0, prcheight[0] = 0
type = 0xff90 (SOT); len = 10;tileno = 0; len = 0; partno = 0; numparts = 32
cannot get marker segment
error: cannot load image data
You can again see, theres lots of details, which may be critically
important in a bug report.
More so users may have bug report samples that are not sharable
for all kinds of contractual reasons. Having detailed information
available is the only chance to debug such issues.
Requiring the user to build his own binary FFmpeg with custom build
flags is a large hurdle for reporting a bug
Thanks
[...]
--
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/
Re: [FFmpeg-devel] [PATCH] avcodec/snowdec: Check intra block dc differences.
Hi,
On Mon, Sep 4, 2017 at 10:11 PM, James Almer wrote:
> On 9/4/2017 11:00 PM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Mon, Sep 4, 2017 at 12:11 PM, Michael Niedermayer
> >> wrote:
> >
> >> if(type){
> >> +int ld, cbd, crd;
> >> pred_mv(s, &mx, &my, 0, left, top, tr);
> >> -l += get_symbol(&s->c, &s->block_state[32], 1);
> >> +ld = get_symbol(&s->c, &s->block_state[32], 1);
> >> +if (ld < -255 || ld > 255) {
> >> +av_log(s->avctx, AV_LOG_ERROR, "Invalid (Out of range)
> >> intra luma block DC difference %d\n", ld);
> >> +return AVERROR_INVALIDDATA;
> >> +}
> >> +l += ld;
> >> if (s->nb_planes > 2) {
> >> -cb+= get_symbol(&s->c, &s->block_state[64], 1);
> >> -cr+= get_symbol(&s->c, &s->block_state[96], 1);
> >> +cbd = get_symbol(&s->c, &s->block_state[64], 1);
> >> +crd = get_symbol(&s->c, &s->block_state[96], 1);
> >> +if (cbd < -255 || cbd > 255 || crd < -255 || crd >
> 255) {
> >> +av_log(s->avctx, AV_LOG_ERROR, "Invalid (Out of
> >> range) intra chroma block DC difference %d, %d\n", cbd, crd);
> >> +return AVERROR_INVALIDDATA;
> >> +}
> >> +cb += cbd;
> >> +cr += crd;
> >> }
> >
> >
> > I recognize the great improvements in your messages. They are much better
> > than before. They are still not appropriate for display to end users.
> > Please use ff_tlog(), as was suggested in the original thread.
>
> Now that i looked at ff_tlog() closely it's only enabled if -DTRACE is
> used during compilation, and then it prints stuff at the trace log
> level, which is even lower than debug and used to print a bunch of
> assorted values that are not error log messages.
You're right, ff_dlog() seems better (see libavcodec/internal.h).
I also agree with y'all, let's stop discussing this further, we're all
working on real, actually important stuff, this particular issue really
isn't worth our time...
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/jpeg2000: Check that codsty->log2_prec_widths/heights has been initialized
On 9/5/17, Michael Niedermayer wrote:
> Hi
>
> On Mon, Sep 04, 2017 at 06:45:02PM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Mon, Sep 4, 2017 at 6:04 PM, Michael Niedermayer
>>
>> wrote:
>>
>> > Fixes: OOM
>> > Fixes: 2225/clusterfuzz-testcase-minimized-5505632079708160
>> >
>> > Found-by: continuous fuzzing process https://github.com/google/oss-
>> > fuzz/tree/master/projects/ffmpeg
>> > Signed-off-by: Michael Niedermayer
>> > ---
>> > libavcodec/jpeg2000.c | 4
>> > 1 file changed, 4 insertions(+)
>> >
>> > diff --git a/libavcodec/jpeg2000.c b/libavcodec/jpeg2000.c
>> > index 94efc94c4d..9e1bbc2ec4 100644
>> > --- a/libavcodec/jpeg2000.c
>> > +++ b/libavcodec/jpeg2000.c
>> > @@ -506,6 +506,10 @@ int ff_jpeg2000_init_component(Jpeg2000Component
>> > *comp,
>> > // update precincts size: 2^n value
>> > reslevel->log2_prec_width = codsty->log2_prec_widths[
>> > reslevelno];
>> > reslevel->log2_prec_height = codsty->log2_prec_heights[
>> > reslevelno];
>> > +if (!reslevel->log2_prec_width || !reslevel->log2_prec_height)
>> > {
>> > +av_log(avctx, AV_LOG_ERROR, "COD/COC is missing\n");
>> > +return AVERROR_INVALIDDATA;
>> > +}
>>
>>
>> Please change it to ff_tlog().
>
> that would make the message unavailable to the user, so the user
> would not know why a decoding failure occured.
>
> It would also make it unavailable in bug reports as the message is
> not in the compiled binary. Even at highest verbosity and debug levels
> it would not show up not even with debug builds. Only in special trace
> builds would it show up.
>
> Users would not be able to find existing bug reports based on the error
> message, would not be able to google it, would not be able to refer to
> it in a specific way "a issue with missing COC/COD".
>
> This is not a obscure detail of bitstream parsing, its a error in
> the headers that will lead to the loss of a frame.
>
> Lets also look at what other software does
> picking lena converted to jpeg2000 and a damaged COD with a hex editor
>
> j2k_to_image -i lena-noco.jp2 -o image.pgm
>
> [ERROR] Error decoding component 0.
> The number of resolutions is too big: 256 vs max= 33. Truncating.
>
> [ERROR] Error decoding component 1.
> The number of resolutions is too big: 256 vs max= 33. Truncating.
>
> [ERROR] Error decoding component 2.
> The number of resolutions is too big: 256 vs max= 33. Truncating.
>
> [ERROR] Failed to decode J2K image
> ERROR -> j2k_to_image: failed to decode image!
>
> You can see openjpeg shows detailed error messages
> Lets try the clusterfuzz testcase directly:
>
> j2k_to_image -i clusterfuzz-testcase-minimized-5505632079708160.jp2 -o
> image.pnm
>
> [ERROR] Integer overflow in box->length
> [ERROR] Failed to read boxhdr
> [ERROR] Failed to decode jp2 structure
> ERROR -> j2k_to_image: failed to decode image!
>
> again, a detailed error message
>
> lets try jasper
>
> jasper --input lena-noco.jp2 --output file.pnm
> cannot get marker segment
> error: cannot decode code stream
> error: cannot load image data
>
> and the testcase directly:
> jasper --input clusterfuzz-testcase-minimized-5505632079708160 --output
> image.pnm
> cannot get marker segment
> error: cannot load image data
>
> and jasper also shows more than just a generic error
>
> Thats by default. no debug build, no trace build, no verbosity, no
> debug options.
>
> just for completeness lets run jasper with debug level 99
> jasper --debug-level 99 --input
> clusterfuzz-testcase-minimized-5505632079708160.jp2 --output image.pnm
> type = 0xff4f (SOC);
> type = 0xff51 (SIZ); len = 41;caps = 0x2020;
> width = 25632; height = 32; xoff = 0; yoff = 0;
> tilewidth = 538976288; tileheight = 538976288; tilexoff = 0; tileyoff =
> 0;
> prec[0] = 8; sgnd[0] = 0; hsamp[0] = 1; vsamp[0] = 1
> type = 0xff52 (COD); len = 13;csty = 0x01;
> numdlvls = 0; qmfbid = 0; mctrans = 0
> prg = 32; numlyrs = 8224;
> cblkwidthval = 32; cblkheightval = 32; cblksty = 0x20;
> prcwidth[0] = 0, prcheight[0] = 0
> type = 0xff90 (SOT); len = 10;tileno = 0; len = 0; partno = 0; numparts
> = 32
> cannot get marker segment
> error: cannot load image data
>
> You can again see, theres lots of details, which may be critically
> important in a bug report.
>
> More so users may have bug report samples that are not sharable
> for all kinds of contractual reasons. Having detailed information
> available is the only chance to debug such issues.
> Requiring the user to build his own binary FFmpeg with custom build
> flags is a large hurdle for reporting a bug
FFmpeg is not meant to have every log for every error return.
COD/COC sounds funny.
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/jpeg2000: Check that codsty->log2_prec_widths/heights has been initialized
Hi, This really isn't worth our time. Really, it isn't. On Tue, Sep 5, 2017 at 7:04 AM, Michael Niedermayer wrote: > > Please change it to ff_tlog(). > > that would make the message unavailable to the user, so the user > would not know why a decoding failure occured. > It is intentional to not make it available to the end user. That is by design. The message is inappropriate for end users. For example, it doesn't tell in a human-readable form what's going on or how to solve it or where to go for more information. It isn't helpful at all. I don't know a single end user who even knows what a COD is, they probably think it's a video game (try Googling it). > Lets also look at what other software does > "Mommy, he did it first." > You can again see, theres lots of details, which may be critically > important in a bug report. There are no bug reports related to this issue, otherwise we would have fixed this security issue long ago. This is a fuzz-only issue. That makes it all the more important to not waste precious bytes in our binaries on it, or lines on our commandline terminals. When I get 1000s of lines of debug output, I ignore them all unless I grep'ed for something specific to not make it 1000s. When I get 10, I might actually read the first 2. Please change the message to ff_dlog() if you really, really insist on something else than ff_tlog(). That way, our precious end users don't need to see it. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/jpeg2000: Check that codsty->log2_prec_widths/heights has been initialized
On Tue, Sep 05, 2017 at 01:16:22PM +0200, Paul B Mahol wrote:
> On 9/5/17, Michael Niedermayer wrote:
> > Hi
> >
> > On Mon, Sep 04, 2017 at 06:45:02PM -0400, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Mon, Sep 4, 2017 at 6:04 PM, Michael Niedermayer
> >>
> >> wrote:
> >>
> >> > Fixes: OOM
> >> > Fixes: 2225/clusterfuzz-testcase-minimized-5505632079708160
> >> >
> >> > Found-by: continuous fuzzing process https://github.com/google/oss-
> >> > fuzz/tree/master/projects/ffmpeg
> >> > Signed-off-by: Michael Niedermayer
> >> > ---
> >> > libavcodec/jpeg2000.c | 4
> >> > 1 file changed, 4 insertions(+)
> >> >
> >> > diff --git a/libavcodec/jpeg2000.c b/libavcodec/jpeg2000.c
> >> > index 94efc94c4d..9e1bbc2ec4 100644
> >> > --- a/libavcodec/jpeg2000.c
> >> > +++ b/libavcodec/jpeg2000.c
> >> > @@ -506,6 +506,10 @@ int ff_jpeg2000_init_component(Jpeg2000Component
> >> > *comp,
> >> > // update precincts size: 2^n value
> >> > reslevel->log2_prec_width = codsty->log2_prec_widths[
> >> > reslevelno];
> >> > reslevel->log2_prec_height = codsty->log2_prec_heights[
> >> > reslevelno];
> >> > +if (!reslevel->log2_prec_width || !reslevel->log2_prec_height)
> >> > {
> >> > +av_log(avctx, AV_LOG_ERROR, "COD/COC is missing\n");
> >> > +return AVERROR_INVALIDDATA;
> >> > +}
> >>
> >>
> >> Please change it to ff_tlog().
> >
> > that would make the message unavailable to the user, so the user
> > would not know why a decoding failure occured.
> >
> > It would also make it unavailable in bug reports as the message is
> > not in the compiled binary. Even at highest verbosity and debug levels
> > it would not show up not even with debug builds. Only in special trace
> > builds would it show up.
> >
> > Users would not be able to find existing bug reports based on the error
> > message, would not be able to google it, would not be able to refer to
> > it in a specific way "a issue with missing COC/COD".
> >
> > This is not a obscure detail of bitstream parsing, its a error in
> > the headers that will lead to the loss of a frame.
> >
> > Lets also look at what other software does
> > picking lena converted to jpeg2000 and a damaged COD with a hex editor
> >
> > j2k_to_image -i lena-noco.jp2 -o image.pgm
> >
> > [ERROR] Error decoding component 0.
> > The number of resolutions is too big: 256 vs max= 33. Truncating.
> >
> > [ERROR] Error decoding component 1.
> > The number of resolutions is too big: 256 vs max= 33. Truncating.
> >
> > [ERROR] Error decoding component 2.
> > The number of resolutions is too big: 256 vs max= 33. Truncating.
> >
> > [ERROR] Failed to decode J2K image
> > ERROR -> j2k_to_image: failed to decode image!
> >
> > You can see openjpeg shows detailed error messages
> > Lets try the clusterfuzz testcase directly:
> >
> > j2k_to_image -i clusterfuzz-testcase-minimized-5505632079708160.jp2 -o
> > image.pnm
> >
> > [ERROR] Integer overflow in box->length
> > [ERROR] Failed to read boxhdr
> > [ERROR] Failed to decode jp2 structure
> > ERROR -> j2k_to_image: failed to decode image!
> >
> > again, a detailed error message
> >
> > lets try jasper
> >
> > jasper --input lena-noco.jp2 --output file.pnm
> > cannot get marker segment
> > error: cannot decode code stream
> > error: cannot load image data
> >
> > and the testcase directly:
> > jasper --input clusterfuzz-testcase-minimized-5505632079708160 --output
> > image.pnm
> > cannot get marker segment
> > error: cannot load image data
> >
> > and jasper also shows more than just a generic error
> >
> > Thats by default. no debug build, no trace build, no verbosity, no
> > debug options.
> >
> > just for completeness lets run jasper with debug level 99
> > jasper --debug-level 99 --input
> > clusterfuzz-testcase-minimized-5505632079708160.jp2 --output image.pnm
> > type = 0xff4f (SOC);
> > type = 0xff51 (SIZ); len = 41;caps = 0x2020;
> > width = 25632; height = 32; xoff = 0; yoff = 0;
> > tilewidth = 538976288; tileheight = 538976288; tilexoff = 0; tileyoff =
> > 0;
> > prec[0] = 8; sgnd[0] = 0; hsamp[0] = 1; vsamp[0] = 1
> > type = 0xff52 (COD); len = 13;csty = 0x01;
> > numdlvls = 0; qmfbid = 0; mctrans = 0
> > prg = 32; numlyrs = 8224;
> > cblkwidthval = 32; cblkheightval = 32; cblksty = 0x20;
> > prcwidth[0] = 0, prcheight[0] = 0
> > type = 0xff90 (SOT); len = 10;tileno = 0; len = 0; partno = 0; numparts
> > = 32
> > cannot get marker segment
> > error: cannot load image data
> >
> > You can again see, theres lots of details, which may be critically
> > important in a bug report.
> >
> > More so users may have bug report samples that are not sharable
> > for all kinds of contractual reasons. Having detailed information
> > available is the only chance to debug such issues.
> > Requiring the user to build his own binary FFmpeg with custom build
> >
Re: [FFmpeg-devel] [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from VANC
>On 9/3/17, 8:19 PM, "Marton Balint" mailto:c...@passwd.hu>> >wrote: >Why don't use you simply use uint16_t here as well? I think we typically >try to avoid unsigned as a type. Done. Changed it to uint16_t. >This VANC parser does not seem right. VANC header can appear multiple >times, you seem to parse only the first DID. Also, you should simply >ignore unknown DID-s, ffmpeg will not be able to parse all types there >are, there is no need to warn. Thanks for pointing it out. Have handled it now. Also changed the warning log to debug log. Please find the patch attached. Regards, Marton 0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch Description: 0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [WARNING! RECEIVED FROM EXTERNAL SENDER] Re: [PATCH 1/4] avdevice/decklink_dec: Added VANC search for all resolutions
Overlooked a “signed vs unsigned comparison” compilation warning in the previous patch. Sorry about that. Please use this updated patch(attached) for review. Regards, Karthick 0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch Description: 0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avdevice/decklink_dec: Added VANC search for all resolutions
Overlooked a “signed vs unsigned comparison” compilation warning in the previous patch. Sorry about that. Please use this updated patch(attached) for review. Regards, Karthick P.S : I had sent the same reply sometime back, but a new thread got created. Please ignore that. I am using Outlook on Mac as my mail client and it doesn’t really work along with mailing lists, with extra corporate-level securities in our mail servers. Hope this reply doesn’t create a new thread again :) 0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch Description: 0001-avdevice-decklink_dec-Added-VANC-search-for-all-reso.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add support for RockChip Media Process Platform
From: LongChair
This adds hardware decoding for h264 / HEVC / VP8 using MPP Rockchip API.
Will return frames holding an AVDRMFrameDescriptor struct in buf[0] that allows
drm / dmabuf usage.
Was tested on RK3288 (TinkerBoard) and RK3328.
---
Changelog | 1 +
configure | 15 +-
libavcodec/Makefile| 3 +
libavcodec/allcodecs.c | 3 +
libavcodec/rkmppdec.c | 567 +
5 files changed, 588 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/rkmppdec.c
diff --git a/Changelog b/Changelog
index 1dfb8b5..622e5d0 100644
--- a/Changelog
+++ b/Changelog
@@ -35,6 +35,7 @@ version :
- pseudocolor video filter
- raw G.726 muxer and demuxer, left- and right-justified
- NewTek NDI input/output device
+- Addition of Rockchip MPP hardware decoding
version 3.3:
- CrystalHD decoder moved to new decode API
diff --git a/configure b/configure
index ebd561d..1df5763 100755
--- a/configure
+++ b/configure
@@ -307,6 +307,7 @@ External library support:
--disable-nvenc disable Nvidia video encoding code [autodetect]
--enable-omx enable OpenMAX IL code [no]
--enable-omx-rpi enable OpenMAX IL code for Raspberry Pi [no]
+ --enable-rkmpp enable Rockchip Media Process Platform code [no]
--disable-vaapi disable Video Acceleration API (mainly Unix/Intel)
code [autodetect]
--disable-vdadisable Apple Video Decode Acceleration code
[autodetect]
--disable-vdpau disable Nvidia Video Decode and Presentation API
for Unix code [autodetect]
@@ -1520,6 +1521,7 @@ EXTERNAL_LIBRARY_VERSION3_LIST="
libopencore_amrnb
libopencore_amrwb
libvo_amrwbenc
+rkmpp
"
EXTERNAL_LIBRARY_GPLV3_LIST="
@@ -2757,6 +2759,8 @@ h264_qsv_decoder_deps="libmfx"
h264_qsv_decoder_select="h264_mp4toannexb_bsf h264_parser qsvdec
h264_qsv_hwaccel"
h264_qsv_encoder_deps="libmfx"
h264_qsv_encoder_select="qsvenc"
+h264_rkmpp_decoder_deps="rkmpp"
+h264_rkmpp_decoder_select="h264_mp4toannexb_bsf"
h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
h264_vaapi_encoder_select="vaapi_encode golomb"
h264_vda_decoder_deps="vda"
@@ -2772,6 +2776,8 @@ hevc_qsv_decoder_deps="libmfx"
hevc_qsv_decoder_select="hevc_mp4toannexb_bsf hevc_parser qsvdec
hevc_qsv_hwaccel"
hevc_qsv_encoder_deps="libmfx"
hevc_qsv_encoder_select="hevcparse qsvenc"
+hevc_rkmpp_decoder_deps="rkmpp"
+hevc_rkmpp_decoder_select="hevc_mp4toannexb_bsf"
hevc_vaapi_encoder_deps="VAEncPictureParameterBufferHEVC"
hevc_vaapi_encoder_select="vaapi_encode golomb"
mjpeg_cuvid_decoder_deps="cuda cuvid"
@@ -2811,6 +2817,8 @@ vp8_cuvid_decoder_deps="cuda cuvid"
vp8_mediacodec_decoder_deps="mediacodec"
vp8_qsv_decoder_deps="libmfx"
vp8_qsv_decoder_select="qsvdec vp8_qsv_hwaccel vp8_parser"
+vp8_rkmpp_decoder_deps="rkmpp"
+vp8_rkmpp_decoder_select="rkmpp"
vp8_vaapi_encoder_deps="VAEncPictureParameterBufferVP8"
vp8_vaapi_encoder_select="vaapi_encode"
vp9_cuvid_decoder_deps="cuda cuvid"
@@ -6008,7 +6016,12 @@ enabled openssl && { use_pkg_config openssl
openssl/ssl.h OPENSSL_init
check_lib openssl openssl/ssl.h
SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 ||
die "ERROR: openssl not found"; }
enabled qtkit_indev && { check_header_objcc QTKit/QTKit.h || disable
qtkit_indev; }
-
+enabled rkmpp && { { require_pkg_config rockchip_mpp
rockchip/rk_mpi.h mpp_create ||
+ die "ERROR : Rockchip MPP was not found."; }
&&
+ { check_func_headers rockchip/rk_mpi_cmd.h
"MPP_DEC_GET_FREE_PACKET_SLOT_COUNT" ||
+ die "ERROR: Rockchip MPP is outdated, please
get a more recent one."; } &&
+ { enabled libdrm || die "ERROR: rkmpp requires
--enable-libdrm"; }
+ }
if enabled gcrypt; then
GCRYPT_CONFIG="${cross_prefix}libgcrypt-config"
if "${GCRYPT_CONFIG}" --version > /dev/null 2>&1; then
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 982d7f5..b75912f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -336,6 +336,7 @@ OBJS-$(CONFIG_H264_VDA_DECODER)+= vda_h264_dec.o
OBJS-$(CONFIG_H264_OMX_ENCODER)+= omx.o
OBJS-$(CONFIG_H264_QSV_DECODER)+= qsvdec_h2645.o
OBJS-$(CONFIG_H264_QSV_ENCODER)+= qsvenc_h264.o
+OBJS-$(CONFIG_H264_RKMPP_DECODER) += rkmppdec.o
OBJS-$(CONFIG_H264_VAAPI_ENCODER) += vaapi_encode_h264.o
vaapi_encode_h26x.o
OBJS-$(CONFIG_H264_VIDEOTOOLBOX_ENCODER) += videotoolboxenc.o
OBJS-$(CONFIG_HAP_DECODER) += hapdec.o hap.o
@@ -350,6 +351,7 @@ OBJS-$(CONFIG_NVENC_HEVC_ENCODER) += nvenc_hevc.o
OBJS-$(CONFIG_HEVC_QSV_DECODER)+= qsvdec_h2645.o
OBJS-$(CONFIG_HEVC_QSV_ENCODER)+= qsvenc_hevc.o hevc_ps_enc.o \
hevc_
[FFmpeg-devel] [PATCHv9] libavcodec: v4l2: add support for v4l2 mem2mem codecs
This patchset enhances Alexis Ballier's original patch and validates it using Qualcomm's Venus hardware (driver recently landed upstream [1]). This has been tested on Qualcomm's DragonBoard 410c and 820c Configure/make scripts have been validated on Ubuntu 10.04 and 16.04. Tested decoders: - h264 - h263 - mpeg4 - vp8 - vp9 - hevc Tested encoders: - h264 - h263 - mpeg4 Tested transcoding (concurrent encoding/decoding) Some of the changes introduced: - v4l2: code cleanup and abstractions added - v4l2: follow the new encode/decode api. - v4l2: fix display size for NV12 output pool. - v4l2: handle EOS. - v4l2: vp8 and mpeg4 decoding and encoding. - v4l2: hevc and vp9 support. - v4l2: generate EOF on dequeue errors. - v4l2: h264_mp4toannexb filtering. - v4l2: fixed make install and fate issues. - v4l2: codecs enabled/disabled depending on pixfmt defined - v4l2: pass timebase/framerate to the context - v4l2: runtime decoder reconfiguration. - v4l2: add more frame information - v4l2: free hardware resources on last reference being released - v4l2: encoding: disable b-frames for upstreaming (patch required) [1] https://lwn.net/Articles/697956/ Reviewed-by: Jorge Ramirez Reviewed-by: Alexis Ballier Tested-by: Jorge Ramirez --- Changelog | 1 + configure | 28 ++ libavcodec/Makefile | 15 + libavcodec/allcodecs.c| 9 + libavcodec/v4l2_buffers.c | 951 ++ libavcodec/v4l2_buffers.h | 234 +++ libavcodec/v4l2_fmt.c | 182 libavcodec/v4l2_fmt.h | 34 ++ libavcodec/v4l2_m2m.c | 479 + libavcodec/v4l2_m2m.h | 70 libavcodec/v4l2_m2m_avcodec.h | 32 ++ libavcodec/v4l2_m2m_dec.c | 232 +++ libavcodec/v4l2_m2m_enc.c | 354 13 files changed, 2621 insertions(+) create mode 100644 libavcodec/v4l2_buffers.c create mode 100644 libavcodec/v4l2_buffers.h create mode 100644 libavcodec/v4l2_fmt.c create mode 100644 libavcodec/v4l2_fmt.h create mode 100644 libavcodec/v4l2_m2m.c create mode 100644 libavcodec/v4l2_m2m.h create mode 100644 libavcodec/v4l2_m2m_avcodec.h create mode 100644 libavcodec/v4l2_m2m_dec.c create mode 100644 libavcodec/v4l2_m2m_enc.c diff --git a/Changelog b/Changelog index cae5254..95f70f0 100644 --- a/Changelog +++ b/Changelog @@ -43,6 +43,7 @@ version : - add --disable-autodetect build switch - drop deprecated qtkit input device (use avfoundation instead) - despill video filter +- V4L2 mem2mem HW assisted codecs version 3.3: - CrystalHD decoder moved to new decode API diff --git a/configure b/configure index f7558f6..5a41698 100755 --- a/configure +++ b/configure @@ -185,6 +185,7 @@ Individual component options: --enable-filter=NAME enable filter NAME --disable-filter=NAMEdisable filter NAME --disable-filtersdisable all filters + --disable-v4l2_m2m disable V4L2 mem2mem code [autodetect] External library support: @@ -1604,6 +1605,7 @@ HWACCEL_AUTODETECT_LIBRARY_LIST=" vda vdpau videotoolbox_hwaccel +v4l2_m2m xvmc " @@ -2735,6 +2737,7 @@ omx_rpi_select="omx" qsvdec_select="qsv" qsvenc_select="qsv" vaapi_encode_deps="vaapi" +v4l2_m2m_deps_any="linux_videodev2_h" hwupload_cuda_filter_deps="cuda" scale_npp_filter_deps="cuda libnpp" @@ -2744,6 +2747,8 @@ nvenc_deps="cuda" nvenc_deps_any="dlopen LoadLibrary" nvenc_encoder_deps="nvenc" +h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m" +h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m" h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser" h264_cuvid_decoder_deps="cuda cuvid" h264_cuvid_decoder_select="h264_mp4toannexb_bsf" @@ -2762,6 +2767,8 @@ h264_vda_decoder_deps="vda" h264_vda_decoder_select="h264_decoder" h264_vdpau_decoder_deps="vdpau" h264_vdpau_decoder_select="h264_decoder" +h264_v4l2m2m_decoder_deps="v4l2_m2m h264_v4l2_m2m" +h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m" hevc_cuvid_decoder_deps="cuda cuvid" hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf" hevc_mediacodec_decoder_deps="mediacodec" @@ -2773,12 +2780,15 @@ hevc_qsv_encoder_deps="libmfx" hevc_qsv_encoder_select="hevcparse qsvenc" hevc_vaapi_encoder_deps="VAEncPictureParameterBufferHEVC" hevc_vaapi_encoder_select="vaapi_encode golomb" +hevc_v4l2m2m_decoder_deps="v4l2_m2m hevc_v4l2_m2m" +hevc_v4l2m2m_encoder_deps="v4l2_m2m hevc_v4l2_m2m" mjpeg_cuvid_decoder_deps="cuda cuvid" mjpeg_vaapi_encoder_deps="VAEncPictureParameterBufferJPEG" mjpeg_vaapi_encoder_select="vaapi_encode jpegtables" mpeg1_cuvid_decoder_deps="cuda cuvid" mpeg1_vdpau_decoder_deps="vdpau" mpeg1_vdpau_
Re: [FFmpeg-devel] [PATCHv8] libavcodec: v4l2: add support for v4l2 mem2mem codecs
On 09/05/2017 10:27 AM, wm4 wrote: On Tue, 5 Sep 2017 10:03:49 +0200 Jorge Ramirez wrote: On 09/05/2017 09:16 AM, Jorge Ramirez wrote: On 09/05/2017 12:16 AM, Mark Thompson wrote: On 04/09/17 22:55, Jorge Ramirez wrote: On 09/04/2017 11:29 PM, Mark Thompson wrote: ... stuff ... So the sequence of calls is: send_frame(frame 0) -> success receive_packet() -> EAGAIN send_frame(frame 1) -> success receive_packet() -> EAGAIN ... send_frame(frame 15) -> success receive_packet() -> EAGAIN send_frame(frame 16) -> success receive_packet() -> packet 0 receive_packet() -> packet 1 ... receive_packet() -> packet 15 receive_packet() -> packet 16 receive_packet() -> blocks This appears correct to me - since EAGAIN has not been returned by a receive_packet() call, it can be called again repeatedly (as documented in avcodec.h). Do you disagree? I would have expected that after a packet is received, a new frame is enqueued instead of executing again receive_packet (why do we that? what is the benefit?) under these circumsntances I can't block in receive_packet blindly, I have to track in user-space what the driver has in its guts and predict how much it needs to keep workingI dont think it is a good idea. Feel free to submit a patch to avcodec.h which changes the definition of the API. no, that is ok. I can work around it easily (maybe v4l2 has special needs compared to the rest of ffmpeg) I think that the problem is that you are only polling on the frame buffer queue when blocking, so you don't see the packet buffers becoming free in the packet buffer queue - if you did see and dequeue them, you would then return EAGAIN to indicate that more input is needed. (See comments in .) I could manually track it that way with additional counters - so before blocking I could see count many frames are enqueued in the input and if there is not at least one I could just return EAGAIN. but the behaviour differs from encoding. The behaviour is identical. You return the output buffer if there is one available on the output queue, otherwise you return EAGAIN if there is any space on the input queue, otherwise you block waiting for either of those to become possible. I made some modifications to the way I was dequeuing buffers so now it polls for both input and output queues. you were right, things work much smoother this way...thanks. having said that I still I find the encoding API wrongly defined (no need for two calls that are in fact highly couple to each other in my opinion) The encoding API works exactly the same way as the decoding API, just that the decoding API has an helper internally that makes it easier to merge send/receive into 1 function. You could do the same on the encoding side. I see. But doesnt the helper makes the API confusing? I quite liked the way Mark described the operation: " You return the output buffer if there is one available on the output queue, otherwise you return EAGAIN if there is any space on the input queue, otherwise you block waiting for either of those to become possible." I now think that having a single function "muds" the behavioral definition above since we can just queue many packets on input and then be sure that on each dequeue we will be given the chance to enqueue again _even_ if there is another processed buffer ready to be read. Other than that, the API is meant for single-threaded use, so we can't do things like randomly blocking calls and requiring reentrant calls from other threads to unblock them. ok, understood. ___ 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 v2] ffprobe: use consistent string for unspecified color_range value
On 29.08.2017 16:07, Tobias Rapp wrote: Makes the handling of unspecified/unknown color_range values on stream level consistent to the value used on frame level. Signed-off-by: Tobias Rapp --- ffprobe.c | 8 tests/ref/fate/ffprobe_compact | 4 ++-- tests/ref/fate/ffprobe_csv | 4 ++-- tests/ref/fate/ffprobe_default | 4 ++-- tests/ref/fate/ffprobe_flat| 4 ++-- tests/ref/fate/ffprobe_ini | 4 ++-- tests/ref/fate/mxf-probe-dnxhd | 2 +- tests/ref/fate/mxf-probe-dv25 | 2 +- 8 files changed, 16 insertions(+), 16 deletions(-) [...] I'd like to push this if there are no objections within the next two days. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fate: add test for asetnsamples filter with padding disabled
Adds another test for asetnsamples filter where padding of the last
frame is switched off. Renames the existing test to make the difference
obvious.
Signed-off-by: Tobias Rapp
---
tests/fate/filter-audio.mak | 13 +
.../fate/{filter-asetnsamples => filter-asetnsamples-nopad} | 2 +-
.../fate/{filter-asetnsamples => filter-asetnsamples-pad} | 0
3 files changed, 10 insertions(+), 5 deletions(-)
copy tests/ref/fate/{filter-asetnsamples => filter-asetnsamples-nopad} (99%)
rename tests/ref/fate/{filter-asetnsamples => filter-asetnsamples-pad} (100%)
diff --git a/tests/fate/filter-audio.mak b/tests/fate/filter-audio.mak
index 5035e8f..35ad0f8 100644
--- a/tests/fate/filter-audio.mak
+++ b/tests/fate/filter-audio.mak
@@ -84,10 +84,15 @@ fate-filter-anequalizer: tests/data/filtergraphs/anequalizer
fate-filter-anequalizer: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
fate-filter-anequalizer: CMD = framecrc -i $(SRC) -filter_complex_script
$(TARGET_PATH)/tests/data/filtergraphs/anequalizer
-FATE_AFILTER-$(call FILTERDEMDECENCMUX, ASETNSAMPLES, WAV, PCM_S16LE,
PCM_S16LE, WAV) += fate-filter-asetnsamples
-fate-filter-asetnsamples: tests/data/asynth-44100-2.wav
-fate-filter-asetnsamples: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav
-fate-filter-asetnsamples: CMD = framecrc -i $(SRC) -af asetnsamples=512:p=1
+FATE_AFILTER-$(call FILTERDEMDECENCMUX, ASETNSAMPLES, WAV, PCM_S16LE,
PCM_S16LE, WAV) += fate-filter-asetnsamples-pad
+fate-filter-asetnsamples-pad: tests/data/asynth-44100-2.wav
+fate-filter-asetnsamples-pad: SRC =
$(TARGET_PATH)/tests/data/asynth-44100-2.wav
+fate-filter-asetnsamples-pad: CMD = framecrc -i $(SRC) -af asetnsamples=512:p=1
+
+FATE_AFILTER-$(call FILTERDEMDECENCMUX, ASETNSAMPLES, WAV, PCM_S16LE,
PCM_S16LE, WAV) += fate-filter-asetnsamples-nopad
+fate-filter-asetnsamples-nopad: tests/data/asynth-44100-2.wav
+fate-filter-asetnsamples-nopad: SRC =
$(TARGET_PATH)/tests/data/asynth-44100-2.wav
+fate-filter-asetnsamples-nopad: CMD = framecrc -i $(SRC) -af
asetnsamples=512:p=0
FATE_AFILTER-$(call FILTERDEMDECENCMUX, ASETRATE, WAV, PCM_S16LE, PCM_S16LE,
WAV) += fate-filter-asetrate
fate-filter-asetrate: tests/data/asynth-44100-2.wav
diff --git a/tests/ref/fate/filter-asetnsamples
b/tests/ref/fate/filter-asetnsamples-nopad
similarity index 99%
copy from tests/ref/fate/filter-asetnsamples
copy to tests/ref/fate/filter-asetnsamples-nopad
index 23cf11b..c1cc01a 100644
--- a/tests/ref/fate/filter-asetnsamples
+++ b/tests/ref/fate/filter-asetnsamples-nopad
@@ -520,4 +520,4 @@
0, 262656, 262656, 512, 2048, 0xb881fa44
0, 263168, 263168, 512, 2048, 0xb7cdf1f3
0, 263680, 263680, 512, 2048, 0x1e9b17b5
-0, 264192, 264192, 512, 2048, 0xfd82313e
+0, 264192, 264192, 408, 1632, 0xf412313e
diff --git a/tests/ref/fate/filter-asetnsamples
b/tests/ref/fate/filter-asetnsamples-pad
similarity index 100%
rename from tests/ref/fate/filter-asetnsamples
rename to tests/ref/fate/filter-asetnsamples-pad
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_overlay: Restore shorthand option order
On Wed, Aug 30, 2017 at 10:52:41AM +0200, Marton Balint wrote: > > On Wed, 30 Aug 2017, Michael Niedermayer wrote: > > >Signed-off-by: Michael Niedermayer > >--- > >libavfilter/framesync2.c | 6 -- > >libavfilter/framesync2.h | 6 ++ > >libavfilter/vf_overlay.c | 8 > >3 files changed, 14 insertions(+), 6 deletions(-) > > If this is really this simple then maybe I was wrong to afraid of > it. The docs need restoring as well, the text for the options should > reference the common framesync options section. will send a new patch that updates the docs as well thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_overlay: Restore shorthand option order
Signed-off-by: Michael Niedermayer
---
doc/filters.texi | 9 +
libavfilter/framesync2.c | 6 --
libavfilter/framesync2.h | 6 ++
libavfilter/vf_overlay.c | 8
4 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index afcb99d876..3641fe18de 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10895,6 +10895,9 @@ on the main video. Default value is "0" for both
expressions. In case
the expression is invalid, it is set to a huge value (meaning that the
overlay will not be displayed within the output visible area).
+@item eof_action
+See @ref{framesync}.
+
@item eval
Set when the expressions for @option{x}, and @option{y} are evaluated.
@@ -10910,6 +10913,9 @@ evaluate expressions for each incoming frame
Default value is @samp{frame}.
+@item shortest
+See @ref{framesync}.
+
@item format
Set the format for the output video.
@@ -10935,6 +10941,9 @@ automatically pick format
@end table
Default value is @samp{yuv420}.
+
+@item repeatlast
+See @ref{framesync}.
@end table
The @option{x}, and @option{y} expressions can contain the following
diff --git a/libavfilter/framesync2.c b/libavfilter/framesync2.c
index fae06aa1f5..aea9937ce9 100644
--- a/libavfilter/framesync2.c
+++ b/libavfilter/framesync2.c
@@ -28,12 +28,6 @@
#define OFFSET(member) offsetof(FFFrameSync, member)
#define FLAGS AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM
-enum EOFAction {
-EOF_ACTION_REPEAT,
-EOF_ACTION_ENDALL,
-EOF_ACTION_PASS
-};
-
static const char *framesync_name(void *ptr)
{
return "framesync";
diff --git a/libavfilter/framesync2.h b/libavfilter/framesync2.h
index 745e896bc8..63a0eabbeb 100644
--- a/libavfilter/framesync2.h
+++ b/libavfilter/framesync2.h
@@ -23,6 +23,12 @@
#include "bufferqueue.h"
+enum EOFAction {
+EOF_ACTION_REPEAT,
+EOF_ACTION_ENDALL,
+EOF_ACTION_PASS
+};
+
/*
* TODO
* Export convenient options.
diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c
index 4166e7c095..619a5a6354 100644
--- a/libavfilter/vf_overlay.c
+++ b/libavfilter/vf_overlay.c
@@ -817,9 +817,16 @@ static int activate(AVFilterContext *ctx)
static const AVOption overlay_options[] = {
{ "x", "set the x expression", OFFSET(x_expr), AV_OPT_TYPE_STRING, {.str =
"0"}, CHAR_MIN, CHAR_MAX, FLAGS },
{ "y", "set the y expression", OFFSET(y_expr), AV_OPT_TYPE_STRING, {.str =
"0"}, CHAR_MIN, CHAR_MAX, FLAGS },
+{ "eof_action", "Action to take when encountering EOF from secondary input
",
+OFFSET(fs.opt_eof_action), AV_OPT_TYPE_INT, { .i64 = EOF_ACTION_REPEAT
},
+EOF_ACTION_REPEAT, EOF_ACTION_PASS, .flags = FLAGS, "eof_action" },
+{ "repeat", "Repeat the previous frame.", 0, AV_OPT_TYPE_CONST, {
.i64 = EOF_ACTION_REPEAT }, .flags = FLAGS, "eof_action" },
+{ "endall", "End both streams.",0, AV_OPT_TYPE_CONST, {
.i64 = EOF_ACTION_ENDALL }, .flags = FLAGS, "eof_action" },
+{ "pass", "Pass through the main input.", 0, AV_OPT_TYPE_CONST, {
.i64 = EOF_ACTION_PASS }, .flags = FLAGS, "eof_action" },
{ "eval", "specify when to evaluate expressions", OFFSET(eval_mode),
AV_OPT_TYPE_INT, {.i64 = EVAL_MODE_FRAME}, 0, EVAL_MODE_NB-1, FLAGS, "eval" },
{ "init", "eval expressions once during initialization", 0,
AV_OPT_TYPE_CONST, {.i64=EVAL_MODE_INIT}, .flags = FLAGS, .unit = "eval" },
{ "frame", "eval expressions per-frame", 0,
AV_OPT_TYPE_CONST, {.i64=EVAL_MODE_FRAME}, .flags = FLAGS, .unit = "eval" },
+{ "shortest", "force termination when the shortest input terminates",
OFFSET(fs.opt_shortest), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
{ "format", "set output format", OFFSET(format), AV_OPT_TYPE_INT,
{.i64=OVERLAY_FORMAT_YUV420}, 0, OVERLAY_FORMAT_NB-1, FLAGS, "format" },
{ "yuv420", "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_YUV420},
.flags = FLAGS, .unit = "format" },
{ "yuv422", "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_YUV422},
.flags = FLAGS, .unit = "format" },
@@ -827,6 +834,7 @@ static const AVOption overlay_options[] = {
{ "rgb","", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_RGB},
.flags = FLAGS, .unit = "format" },
{ "gbrp", "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_GBRP},
.flags = FLAGS, .unit = "format" },
{ "auto", "", 0, AV_OPT_TYPE_CONST, {.i64=OVERLAY_FORMAT_AUTO},
.flags = FLAGS, .unit = "format" },
+{ "repeatlast", "repeat overlay of the last overlay frame",
OFFSET(fs.opt_repeatlast), AV_OPT_TYPE_BOOL, {.i64=1}, 0, 1, FLAGS },
{ NULL }
};
--
2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] ffprobe: use consistent string for unspecified color_range value
On 9/5/17, Tobias Rapp wrote: > On 29.08.2017 16:07, Tobias Rapp wrote: >> Makes the handling of unspecified/unknown color_range values on stream >> level consistent to the value used on frame level. >> >> Signed-off-by: Tobias Rapp >> --- >> ffprobe.c | 8 >> tests/ref/fate/ffprobe_compact | 4 ++-- >> tests/ref/fate/ffprobe_csv | 4 ++-- >> tests/ref/fate/ffprobe_default | 4 ++-- >> tests/ref/fate/ffprobe_flat| 4 ++-- >> tests/ref/fate/ffprobe_ini | 4 ++-- >> tests/ref/fate/mxf-probe-dnxhd | 2 +- >> tests/ref/fate/mxf-probe-dv25 | 2 +- >> 8 files changed, 16 insertions(+), 16 deletions(-) >> [...] > > I'd like to push this if there are no objections within the next two days. > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libswscale/swscale_unscaled: fix DITHER_COPY macro
On Mon, Sep 04, 2017 at 09:33:34AM +0200, Mateusz wrote: > If ffmpeg reduces bit-depth to 8-bit or more, it uses DITHER_COPY macro. > The problem is DITHER_COPY macro make images darker (on all planes). > > In x265 project there is issue #365 which is caused by this DITHER_COPY bug. > I think it is time to fix -- there are more and more high bit-depth sources. > > Please review. > > libswscale/swscale_unscaled.c | 44 > +-- > 1 file changed, 13 insertions(+), 31 deletions(-) please provide a git compatible patch with with commit message as produced by git format-patch or git send-email this mail is not accepted as is by git Applying: libswscale/swscale_unscaled: fix DITHER_COPY macro error: corrupt patch at line 6 error: could not build fake ancestor Patch failed at 0001 libswscale/swscale_unscaled: fix DITHER_COPY macro [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Added configuration to override HTTP User-Agent
On Mon, Sep 04, 2017 at 08:16:53AM +, Jeyapal, Karthick wrote: > >On 9/4/17, 1:36 PM, "Steven Liu" > >mailto:lingjiujia...@gmail.com>> wrote: > >+if (c->user_agent) > >+av_dict_set(options, "user-agent", c->user_agent, 0); > > > >should be > >av_dict_set(options, "user_agent", c->user_agent, 0); > > Oh! OK Got it. Sorry for the confusion. Have attached the patch with > user_agent being set. > > Thanks, > Karthick > doc/muxers.texi |4 > libavformat/hlsenc.c |5 + > libavformat/version.h |2 +- > 3 files changed, 10 insertions(+), 1 deletion(-) > 012d43c19fc3e01262158cd9becb63ce582f02f9 > 0001-avformat-hlsenc-Added-configuration-to-override-HTTP.patch > From 7edb12511ec72ada156af86cc8b23c9410695117 Mon Sep 17 00:00:00 2001 > From: Karthick J > Date: Fri, 1 Sep 2017 15:55:48 +0530 > Subject: [PATCH 1/1] avformat/hlsenc: Added configuration to override HTTP > User-Agent > > Signed-off-by: Karthick J > --- > doc/muxers.texi | 4 > libavformat/hlsenc.c | 5 + > libavformat/version.h | 2 +- > 3 files changed, 10 insertions(+), 1 deletion(-) doesnt apply automatically Applying: avformat/hlsenc: Added configuration to override HTTP User-Agent error: sha1 information is lacking or useless (libavformat/hlsenc.c). error: could not build fake ancestor Patch failed at 0001 avformat/hlsenc: Added configuration to override HTTP User-Agent The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "You are 36 times more likely to die in a bathtub than at the hands of a terrorist. Also, you are 2.5 times more likely to become a president and 2 times more likely to become an astronaut, than to die in a terrorist attack." -- Thoughty2 signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/mips: Improve avc idct8 msa function
On Mon, Jul 31, 2017 at 10:13:08AM +, Manojkumar Bhosale wrote: > LGTM will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] RFC: drop VDA
From: Clément Bœsch
I'm reworking the Apple Framework dependencies in the build system, and
unfortunately I can't test VDA (because OSX doesn't have it anymore).
I'll either break it badly without being able to fix it, or won't be
able to do any the rework in the build system.
---
MAINTAINERS | 1 -
Makefile| 3 -
configure | 15 +-
ffmpeg.h| 2 -
ffmpeg_opt.c| 6 +-
ffmpeg_videotoolbox.c | 45 +--
libavcodec/Makefile | 7 +-
libavcodec/allcodecs.c | 3 -
libavcodec/h264_slice.c | 5 -
libavcodec/vda.c| 84 -
libavcodec/vda.h| 230 -
libavcodec/vda_h264.c | 425
libavcodec/vda_h264_dec.c | 263 ---
libavcodec/videotoolbox.c | 10 +-
libavcodec/{vda_vt_internal.h => vt_internal.h} | 15 +-
libavutil/pixdesc.c | 10 -
libavutil/pixfmt.h | 4 +-
17 files changed, 15 insertions(+), 1113 deletions(-)
delete mode 100644 libavcodec/vda.c
delete mode 100644 libavcodec/vda.h
delete mode 100644 libavcodec/vda_h264.c
delete mode 100644 libavcodec/vda_h264_dec.c
rename libavcodec/{vda_vt_internal.h => vt_internal.h} (81%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 8a6ac9840f..7c34912ee6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -244,7 +244,6 @@ Codecs:
txd.c Ivo van Poorten
vc2* Rostislav Pehlivanov
vcr1.cMichael Niedermayer
- vda_h264_dec.cXidorn Quan
videotoolboxenc.c Rick Kern
vima.cPaul B Mahol
vorbisdec.c Denes Balatoni, David Conrad
diff --git a/Makefile b/Makefile
index 29870d7710..4e287b15d6 100644
--- a/Makefile
+++ b/Makefile
@@ -34,9 +34,6 @@ $(foreach prog,$(AVBASENAMES),$(eval
OBJS-$(prog)-$(CONFIG_OPENCL) += cmdutils_o
OBJS-ffmpeg += ffmpeg_opt.o ffmpeg_filter.o ffmpeg_hw.o
OBJS-ffmpeg-$(CONFIG_VIDEOTOOLBOX) += ffmpeg_videotoolbox.o
OBJS-ffmpeg-$(CONFIG_LIBMFX) += ffmpeg_qsv.o
-ifndef CONFIG_VIDEOTOOLBOX
-OBJS-ffmpeg-$(CONFIG_VDA) += ffmpeg_videotoolbox.o
-endif
OBJS-ffmpeg-$(CONFIG_CUVID) += ffmpeg_cuvid.o
OBJS-ffserver += ffserver_config.o
diff --git a/configure b/configure
index 2f3fa2ba3d..087fbd89b0 100755
--- a/configure
+++ b/configure
@@ -311,7 +311,6 @@ External library support:
--enable-omx enable OpenMAX IL code [no]
--enable-omx-rpi enable OpenMAX IL code for Raspberry Pi [no]
--disable-vaapi disable Video Acceleration API (mainly Unix/Intel)
code [autodetect]
- --disable-vdadisable Apple Video Decode Acceleration code
[autodetect]
--disable-vdpau disable Nvidia Video Decode and Presentation API
for Unix code [autodetect]
--disable-videotoolbox disable VideoToolbox code [autodetect]
@@ -1606,7 +1605,6 @@ HWACCEL_AUTODETECT_LIBRARY_LIST="
dxva2
nvenc
vaapi
-vda
vdpau
videotoolbox_hwaccel
xvmc
@@ -2608,10 +2606,6 @@ cuvid_deps="cuda"
d3d11va_deps="d3d11_h dxva_h ID3D11VideoDecoder ID3D11VideoContext"
dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode ole32"
dxva2_extralibs="-luser32"
-vda_framework_deps="VideoDecodeAcceleration_VDADecoder_h blocks_extension"
-vda_framework_extralibs="-framework VideoDecodeAcceleration"
-vda_deps="vda_framework pthreads"
-vda_extralibs="-framework CoreFoundation -framework QuartzCore"
videotoolbox_hwaccel_deps="videotoolbox pthreads"
videotoolbox_hwaccel_extralibs="-framework QuartzCore"
xvmc_deps="X11_extensions_XvMClib_h"
@@ -2633,10 +2627,6 @@ h264_mmal_hwaccel_deps="mmal"
h264_qsv_hwaccel_deps="libmfx"
h264_vaapi_hwaccel_deps="vaapi"
h264_vaapi_hwaccel_select="h264_decoder"
-h264_vda_hwaccel_deps="vda"
-h264_vda_hwaccel_select="h264_decoder"
-h264_vda_old_hwaccel_deps="vda"
-h264_vda_old_hwaccel_select="h264_decoder"
h264_vdpau_hwaccel_deps="vdpau"
h264_vdpau_hwaccel_select="h264_decoder"
h264_videotoolbox_hwaccel_deps="videotoolbox"
@@ -2763,8 +2753,6 @@ h264_qsv_encoder_deps="libmfx"
h264_qsv_encoder_select="qsvenc"
h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
h264_vaapi_encoder_select="vaapi_encode golomb"
-h264_vda_decoder_deps="vda"
-h264_vda_decoder_select="h264_decoder"
h264_vdpau_decoder_deps="vdpau"
h264_vdpau_decoder_select="h264_decoder"
hevc_cuvid_decoder_deps="cuda cuvid"
@@ -2930,7 +2918,7 @@ libzvbi_teletext_decoder_deps="libzvbi"
videotoolbox_deps="VideoToolbox_VideoToolbox_h"
video
Re: [FFmpeg-devel] [PATCH] RFC: drop VDA
On Tue, 5 Sep 2017 15:57:23 +0200 Clément Bœsch wrote: > From: Clément Bœsch > > I'm reworking the Apple Framework dependencies in the build system, and > unfortunately I can't test VDA (because OSX doesn't have it anymore). > I'll either break it badly without being able to fix it, or won't be > able to do any the rework in the build system. > --- +1 If anyone wants to keep using it for ancient OSX versions, that someone can use older ffmpeg releases. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libswscale/swscale_unscaled: fix DITHER_COPY macro
W dniu 2017-09-05 o 15:40, Michael Niedermayer pisze:
> On Mon, Sep 04, 2017 at 09:33:34AM +0200, Mateusz wrote:
>> If ffmpeg reduces bit-depth to 8-bit or more, it uses DITHER_COPY macro.
>> The problem is DITHER_COPY macro make images darker (on all planes).
>>
>> In x265 project there is issue #365 which is caused by this DITHER_COPY bug.
>> I think it is time to fix -- there are more and more high bit-depth sources.
>>
>> Please review.
>>
>> libswscale/swscale_unscaled.c | 44
>> +--
>> 1 file changed, 13 insertions(+), 31 deletions(-)
>
> please provide a git compatible patch with with commit message as produced
> by git format-patch or git send-email
>
> this mail is not accepted as is by git
> Applying: libswscale/swscale_unscaled: fix DITHER_COPY macro
> error: corrupt patch at line 6
> error: could not build fake ancestor
> Patch failed at 0001 libswscale/swscale_unscaled: fix DITHER_COPY macro
>
> [...]
I've attached the result of git format-patch command.
Sorry for 1 private e-mail (I clicked wrong button).
Mateusz
From 9b96d612fef46ccec7e148cd7f8e8666b4e7a4cd Mon Sep 17 00:00:00 2001
From: Mateusz
Date: Tue, 5 Sep 2017 16:09:28 +0200
Subject: [PATCH] fix DITHER_COPY macro to avoid make images darker
---
libswscale/swscale_unscaled.c | 44 +--
1 file changed, 13 insertions(+), 31 deletions(-)
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index ef36aec..3b7a5a9 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,22 +1484,22 @@ 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];\
+unsigned shift= src_depth-dst_depth, tmp;\
for (i = 0; i < height; i++) {\
-const uint8_t *dither= dithers[src_depth-9][i&7];\
+const uint8_t *dither= dithers[shift-1][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);\
+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));\
Re: [FFmpeg-devel] [PATCH] RFC: drop VDA
2017-09-05 21:57 GMT+08:00 Clément Bœsch : > From: Clément Bœsch > > I'm reworking the Apple Framework dependencies in the build system, and > unfortunately I can't test VDA (because OSX doesn't have it anymore). > I'll either break it badly without being able to fix it, or won't be > able to do any the rework in the build system +1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Added configuration to override HTTP User-Agent
2017-09-05 21:45 GMT+08:00 Michael Niedermayer : > On Mon, Sep 04, 2017 at 08:16:53AM +, Jeyapal, Karthick wrote: >> >On 9/4/17, 1:36 PM, "Steven Liu" >> >mailto:lingjiujia...@gmail.com>> wrote: >> >+if (c->user_agent) >> >+av_dict_set(options, "user-agent", c->user_agent, 0); >> > >> >should be >> >av_dict_set(options, "user_agent", c->user_agent, 0); >> >> Oh! OK Got it. Sorry for the confusion. Have attached the patch with >> user_agent being set. >> >> Thanks, >> Karthick > >> doc/muxers.texi |4 >> libavformat/hlsenc.c |5 + >> libavformat/version.h |2 +- >> 3 files changed, 10 insertions(+), 1 deletion(-) >> 012d43c19fc3e01262158cd9becb63ce582f02f9 >> 0001-avformat-hlsenc-Added-configuration-to-override-HTTP.patch >> From 7edb12511ec72ada156af86cc8b23c9410695117 Mon Sep 17 00:00:00 2001 >> From: Karthick J >> Date: Fri, 1 Sep 2017 15:55:48 +0530 >> Subject: [PATCH 1/1] avformat/hlsenc: Added configuration to override HTTP >> User-Agent >> >> Signed-off-by: Karthick J >> --- >> doc/muxers.texi | 4 >> libavformat/hlsenc.c | 5 + >> libavformat/version.h | 2 +- >> 3 files changed, 10 insertions(+), 1 deletion(-) > > doesnt apply automatically > > Applying: avformat/hlsenc: Added configuration to override HTTP User-Agent > error: sha1 information is lacking or useless (libavformat/hlsenc.c). > error: could not build fake ancestor > Patch failed at 0001 avformat/hlsenc: Added configuration to override HTTP > User-Agent > The copy of the patch that failed is found in: .git/rebase-apply/patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". > > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > "You are 36 times more likely to die in a bathtub than at the hands of a > terrorist. Also, you are 2.5 times more likely to become a president and > 2 times more likely to become an astronaut, than to die in a terrorist > attack." -- Thoughty2 > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Modify fixed apply error and applied. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] lavfi/coreimage: reduce dependency scope from QuartzCore to CoreImage
From: Clément Bœsch
What is required by the filter is CoreImage, there is no QuartzCore
usage. QuartzCore/CoreImage.h is simply an include to
CoreImage/CoreImage.h.
---
configure | 8
libavfilter/vf_coreimage.m | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/configure b/configure
index 54fe846fea..442ef606e0 100755
--- a/configure
+++ b/configure
@@ -5588,8 +5588,8 @@ frei0r_filter_extralibs='$ldl'
frei0r_src_filter_extralibs='$ldl'
ladspa_filter_extralibs='$ldl'
nvenc_extralibs='$ldl'
-coreimage_filter_extralibs="-framework QuartzCore -framework AppKit -framework
OpenGL"
-coreimagesrc_filter_extralibs="-framework QuartzCore -framework AppKit
-framework OpenGL"
+coreimage_filter_extralibs="-framework CoreImage -framework AppKit -framework
OpenGL"
+coreimagesrc_filter_extralibs="-framework CoreImage -framework AppKit
-framework OpenGL"
if ! disabled network; then
check_func getaddrinfo $network_extralibs
@@ -5837,8 +5837,8 @@ enabled cuda_sdk && require cuda_sdk cuda.h
cuCtxCreate -lcuda
enabled cuvid && { enabled cuda ||
die "ERROR: CUVID requires CUDA"; }
enabled chromaprint && require chromaprint chromaprint.h
chromaprint_get_version -lchromaprint
-enabled coreimage_filter && { check_header_objcc QuartzCore/CoreImage.h ||
disable coreimage_filter; }
-enabled coreimagesrc_filter && { check_header_objcc QuartzCore/CoreImage.h ||
disable coreimagesrc_filter; }
+enabled coreimage_filter && { check_header_objcc CoreImage/CoreImage.h ||
disable coreimage_filter; }
+enabled coreimagesrc_filter && { check_header_objcc CoreImage/CoreImage.h ||
disable coreimagesrc_filter; }
enabled decklink && { { check_header DeckLinkAPI.h || die "ERROR:
DeckLinkAPI.h header not found"; } &&
{ check_cpp_condition DeckLinkAPIVersion.h
"BLACKMAGIC_DECKLINK_API_VERSION >= 0x0a060100" || die "ERROR: Decklink API
version must be >= 10.6.1."; } }
enabled libndi_newtek && { check_header Processing.NDI.Lib.h || die
"ERROR: Processing.NDI.Lib.h header not found"; }
diff --git a/libavfilter/vf_coreimage.m b/libavfilter/vf_coreimage.m
index 9c8db02858..323a28caa1 100644
--- a/libavfilter/vf_coreimage.m
+++ b/libavfilter/vf_coreimage.m
@@ -23,7 +23,7 @@
* Video processing based on Apple's CoreImage API
*/
-#import
+#import
#import
#include "avfilter.h"
--
2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] build: fix objcc header check
From: Clément Bœsch
Currently, when checking for AVFoundation/AVFoundation.h, the actual
enabled header is math.h.
Similarly, when testing for QuartzCore/CoreImage.h, the actual enabled
header is CoreGraphics/CoreGraphics.h.
This is completely broken and may be the reason why these checks are
made in random places.
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 2f3fa2ba3d..54fe846fea 100755
--- a/configure
+++ b/configure
@@ -1117,7 +1117,7 @@ check_header_objcc(){
{
echo "#include <$header>"
echo "int main(void) { return 0; }"
-} | check_objcc && check_stat "$TMPO" && enable_safe $headers
+} | check_objcc && check_stat "$TMPO" && enable_safe $header
}
check_func(){
--
2.14.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] flvdec: Check the avio_seek return value after reading a metadata packet
COPY FROM libav Martin Storsjö
If the metadata packet is corrupted, flv_read_metabody can accidentally
read past the start of the next packet. If the start of the next packet
had been flushed out of the IO buffer, we would be unable to seek to
the right position (on a nonseekable stream).
Prefer to clearly error out instead of silently trying to read from a
desynced stream which will only be interpreted as garbage.
Signed-off-by: Steven Liu
---
libavformat/flvdec.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 2e70352c53..2d89bef15f 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -1015,7 +1015,13 @@ retry:
"Skipping flv packet: type %d, size %d, flags %d.\n",
type, size, flags);
skip:
-avio_seek(s->pb, next, SEEK_SET);
+if (avio_seek(s->pb, next, SEEK_SET) != next) {
+ // This can happen if flv_read_metabody above read past
+ // next, on a non-seekable input, and the preceding data has
+ // been flushed out from the IO buffer.
+ av_log(s, AV_LOG_ERROR, "Unable to seek to the next
packet\n");
+ return AVERROR_INVALIDDATA;
+}
ret = FFERROR_REDO;
goto leave;
}
--
2.11.0 (Apple Git-81)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/lavfutils: remove usage of AVStream->codec
On 9/4/2017 11:18 AM, James Almer wrote: > On 9/4/2017 6:36 AM, wm4 wrote: >> On Mon, 4 Sep 2017 00:04:36 -0300 >> James Almer wrote: >> >>> On 8/30/2017 2:14 AM, James Almer wrote: Signed-off-by: James Almer --- libavfilter/lavfutils.c | 20 +--- 1 file changed, 17 insertions(+), 3 deletions(-) >>> >>> Ping. >> >> Just push it. > > Was waiting for some libavfilter savvy users/devs like Paul and Nicolas > to comment, but seeing Paul just agreed with you I'll push it later > today or tomorrow. Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add support for RockChip Media Process Platform
On 05/09/17 12:44, LongChair . wrote:
> From: LongChair
>
> This adds hardware decoding for h264 / HEVC / VP8 using MPP Rockchip API.
> Will return frames holding an AVDRMFrameDescriptor struct in buf[0] that
> allows drm / dmabuf usage.
> Was tested on RK3288 (TinkerBoard) and RK3328.
> ---
> Changelog | 1 +
> configure | 15 +-
> libavcodec/Makefile| 3 +
> libavcodec/allcodecs.c | 3 +
> libavcodec/rkmppdec.c | 567
> +
> 5 files changed, 588 insertions(+), 1 deletion(-)
> create mode 100644 libavcodec/rkmppdec.c
>
> diff --git a/Changelog b/Changelog
> index 1dfb8b5..622e5d0 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -35,6 +35,7 @@ version :
> - pseudocolor video filter
> - raw G.726 muxer and demuxer, left- and right-justified
> - NewTek NDI input/output device
> +- Addition of Rockchip MPP hardware decoding
Use the same style as other entries, so just state what has been added; i.e. "-
Rockchip MPP hardware decoder".
> version 3.3:
> - CrystalHD decoder moved to new decode API
> diff --git a/configure b/configure
> index ebd561d..1df5763 100755
> --- a/configure
> +++ b/configure
> @@ -307,6 +307,7 @@ External library support:
>--disable-nvenc disable Nvidia video encoding code [autodetect]
>--enable-omx enable OpenMAX IL code [no]
>--enable-omx-rpi enable OpenMAX IL code for Raspberry Pi [no]
> + --enable-rkmpp enable Rockchip Media Process Platform code [no]
>--disable-vaapi disable Video Acceleration API (mainly
> Unix/Intel) code [autodetect]
>--disable-vdadisable Apple Video Decode Acceleration code
> [autodetect]
>--disable-vdpau disable Nvidia Video Decode and Presentation API
> for Unix code [autodetect]
> @@ -1520,6 +1521,7 @@ EXTERNAL_LIBRARY_VERSION3_LIST="
> libopencore_amrnb
> libopencore_amrwb
> libvo_amrwbenc
> +rkmpp
> "
>
> EXTERNAL_LIBRARY_GPLV3_LIST="
> @@ -2757,6 +2759,8 @@ h264_qsv_decoder_deps="libmfx"
> h264_qsv_decoder_select="h264_mp4toannexb_bsf h264_parser qsvdec
> h264_qsv_hwaccel"
> h264_qsv_encoder_deps="libmfx"
> h264_qsv_encoder_select="qsvenc"
> +h264_rkmpp_decoder_deps="rkmpp"
> +h264_rkmpp_decoder_select="h264_mp4toannexb_bsf"
> h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
> h264_vaapi_encoder_select="vaapi_encode golomb"
> h264_vda_decoder_deps="vda"
> @@ -2772,6 +2776,8 @@ hevc_qsv_decoder_deps="libmfx"
> hevc_qsv_decoder_select="hevc_mp4toannexb_bsf hevc_parser qsvdec
> hevc_qsv_hwaccel"
> hevc_qsv_encoder_deps="libmfx"
> hevc_qsv_encoder_select="hevcparse qsvenc"
> +hevc_rkmpp_decoder_deps="rkmpp"
> +hevc_rkmpp_decoder_select="hevc_mp4toannexb_bsf"
> hevc_vaapi_encoder_deps="VAEncPictureParameterBufferHEVC"
> hevc_vaapi_encoder_select="vaapi_encode golomb"
> mjpeg_cuvid_decoder_deps="cuda cuvid"
> @@ -2811,6 +2817,8 @@ vp8_cuvid_decoder_deps="cuda cuvid"
> vp8_mediacodec_decoder_deps="mediacodec"
> vp8_qsv_decoder_deps="libmfx"
> vp8_qsv_decoder_select="qsvdec vp8_qsv_hwaccel vp8_parser"
> +vp8_rkmpp_decoder_deps="rkmpp"
> +vp8_rkmpp_decoder_select="rkmpp"
I think this line isn't wanted?
> vp8_vaapi_encoder_deps="VAEncPictureParameterBufferVP8"
> vp8_vaapi_encoder_select="vaapi_encode"
> vp9_cuvid_decoder_deps="cuda cuvid"
> @@ -6008,7 +6016,12 @@ enabled openssl && { use_pkg_config openssl
> openssl/ssl.h OPENSSL_init
> check_lib openssl openssl/ssl.h
> SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 ||
> die "ERROR: openssl not found"; }
> enabled qtkit_indev && { check_header_objcc QTKit/QTKit.h || disable
> qtkit_indev; }
> -
> +enabled rkmpp && { { require_pkg_config rockchip_mpp
> rockchip/rk_mpi.h mpp_create ||
> + die "ERROR : Rockchip MPP was not found.";
> } &&
> + { check_func_headers rockchip/rk_mpi_cmd.h
> "MPP_DEC_GET_FREE_PACKET_SLOT_COUNT" ||
> + die "ERROR: Rockchip MPP is outdated,
> please get a more recent one."; } &&
> + { enabled libdrm || die "ERROR: rkmpp
> requires --enable-libdrm"; }
> + }
Keep the blank line after the list of normal checks and before the more complex
cases below.
Also needs a rebase - qtkit_indev was removed.
> if enabled gcrypt; then
> GCRYPT_CONFIG="${cross_prefix}libgcrypt-config"
> if "${GCRYPT_CONFIG}" --version > /dev/null 2>&1; then
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 982d7f5..b75912f 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -336,6 +336,7 @@ OBJS-$(CONFIG_H264_VDA_DECODER)+= vda_h264_dec.o
> OBJS-$(CONFIG_H264_OMX_ENCODER)+= omx.o
> OBJS-$(CONFIG_H264_QSV_DECODER)+= qsvdec_h2645.o
> OBJS-$(CONFIG_H264_QSV_ENCO
[FFmpeg-devel] Consulting request
Hello there,
As stated here: https://www.ffmpeg.org/consulting.html, I take the
opportunity and I'm asking for anyone available for a specific consulting.
I have a working solution based on ffmpeg cli, but cpu only, and I would
like to leverage nvdec and nvenc for faster production.
I have the budget for some days, so if intereste, please feel free to
contact me.
Regards
--
var contact = {
name: 'Xavier Seignard',
phone: '+33 6 83 03 73 74',
website: 'http://drangies.fr',
twitter: 'https://twitter.com/xavier_seignard'
};
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] ffmpeg: reverse logic for interlaced field ordering heuristic
On Fri, 1 Sep 2017, Timo Rothenpieler wrote: When re-encoding for example interlaced h264 from mkv into mkv, the field ordering type switches from TT to TB, confusing some players. Same happens on a lot of other cases as well. I have no idea if this is the correct fix for it, but something is definitely going wrong. Before applying fixes in the field order code, I think we should first decide if we should apply the patch in https://patchwork.ffmpeg.org/patch/4699/ Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/aacdec: don't immediately abort if an ADTS frame is not found
On Sun, 3 Sep 2017, James Almer wrote: Skip the invalid data in an attempt to find one instead, and continue decoding from there. Fixes ticket #6634 If you skipped some broken ADTS frames, which were previously reported errnous, then can you signal that somehow? (E.g. by setting AVFrame->decode_error_flags on the next frame, or adding AV_FRAME_FLAG_CORRUPT flag to the next returned frame?) Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add support for RockChip Media Process Platform
Le 05/09/2017 à 19:19, Mark Thompson a écrit :
> On 05/09/17 12:44, LongChair . wrote:
>> From: LongChair
>>
>> This adds hardware decoding for h264 / HEVC / VP8 using MPP Rockchip API.
>> Will return frames holding an AVDRMFrameDescriptor struct in buf[0] that
>> allows drm / dmabuf usage.
>> Was tested on RK3288 (TinkerBoard) and RK3328.
>> ---
>> Changelog | 1 +
>> configure | 15 +-
>> libavcodec/Makefile| 3 +
>> libavcodec/allcodecs.c | 3 +
>> libavcodec/rkmppdec.c | 567
>> +
>> 5 files changed, 588 insertions(+), 1 deletion(-)
>> create mode 100644 libavcodec/rkmppdec.c
>>
>> diff --git a/Changelog b/Changelog
>> index 1dfb8b5..622e5d0 100644
>> --- a/Changelog
>> +++ b/Changelog
>> @@ -35,6 +35,7 @@ version :
>> - pseudocolor video filter
>> - raw G.726 muxer and demuxer, left- and right-justified
>> - NewTek NDI input/output device
>> +- Addition of Rockchip MPP hardware decoding
> Use the same style as other entries, so just state what has been added; i.e.
> "- Rockchip MPP hardware decoder".
Ok no problem.
>> version 3.3:
>> - CrystalHD decoder moved to new decode API
>> diff --git a/configure b/configure
>> index ebd561d..1df5763 100755
>> --- a/configure
>> +++ b/configure
>> @@ -307,6 +307,7 @@ External library support:
>> --disable-nvenc disable Nvidia video encoding code [autodetect]
>> --enable-omx enable OpenMAX IL code [no]
>> --enable-omx-rpi enable OpenMAX IL code for Raspberry Pi [no]
>> + --enable-rkmpp enable Rockchip Media Process Platform code [no]
>> --disable-vaapi disable Video Acceleration API (mainly
>> Unix/Intel) code [autodetect]
>> --disable-vdadisable Apple Video Decode Acceleration code
>> [autodetect]
>> --disable-vdpau disable Nvidia Video Decode and Presentation
>> API for Unix code [autodetect]
>> @@ -1520,6 +1521,7 @@ EXTERNAL_LIBRARY_VERSION3_LIST="
>> libopencore_amrnb
>> libopencore_amrwb
>> libvo_amrwbenc
>> +rkmpp
>> "
>>
>> EXTERNAL_LIBRARY_GPLV3_LIST="
>> @@ -2757,6 +2759,8 @@ h264_qsv_decoder_deps="libmfx"
>> h264_qsv_decoder_select="h264_mp4toannexb_bsf h264_parser qsvdec
>> h264_qsv_hwaccel"
>> h264_qsv_encoder_deps="libmfx"
>> h264_qsv_encoder_select="qsvenc"
>> +h264_rkmpp_decoder_deps="rkmpp"
>> +h264_rkmpp_decoder_select="h264_mp4toannexb_bsf"
>> h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
>> h264_vaapi_encoder_select="vaapi_encode golomb"
>> h264_vda_decoder_deps="vda"
>> @@ -2772,6 +2776,8 @@ hevc_qsv_decoder_deps="libmfx"
>> hevc_qsv_decoder_select="hevc_mp4toannexb_bsf hevc_parser qsvdec
>> hevc_qsv_hwaccel"
>> hevc_qsv_encoder_deps="libmfx"
>> hevc_qsv_encoder_select="hevcparse qsvenc"
>> +hevc_rkmpp_decoder_deps="rkmpp"
>> +hevc_rkmpp_decoder_select="hevc_mp4toannexb_bsf"
>> hevc_vaapi_encoder_deps="VAEncPictureParameterBufferHEVC"
>> hevc_vaapi_encoder_select="vaapi_encode golomb"
>> mjpeg_cuvid_decoder_deps="cuda cuvid"
>> @@ -2811,6 +2817,8 @@ vp8_cuvid_decoder_deps="cuda cuvid"
>> vp8_mediacodec_decoder_deps="mediacodec"
>> vp8_qsv_decoder_deps="libmfx"
>> vp8_qsv_decoder_select="qsvdec vp8_qsv_hwaccel vp8_parser"
>> +vp8_rkmpp_decoder_deps="rkmpp"
>> +vp8_rkmpp_decoder_select="rkmpp"
> I think this line isn't wanted?
Yeah, missed that one :)
>
>> vp8_vaapi_encoder_deps="VAEncPictureParameterBufferVP8"
>> vp8_vaapi_encoder_select="vaapi_encode"
>> vp9_cuvid_decoder_deps="cuda cuvid"
>> @@ -6008,7 +6016,12 @@ enabled openssl && { use_pkg_config openssl
>> openssl/ssl.h OPENSSL_init
>> check_lib openssl openssl/ssl.h
>> SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 ||
>> die "ERROR: openssl not found"; }
>> enabled qtkit_indev && { check_header_objcc QTKit/QTKit.h || disable
>> qtkit_indev; }
>> -
>> +enabled rkmpp && { { require_pkg_config rockchip_mpp
>> rockchip/rk_mpi.h mpp_create ||
>> + die "ERROR : Rockchip MPP was not found.";
>> } &&
>> + { check_func_headers rockchip/rk_mpi_cmd.h
>> "MPP_DEC_GET_FREE_PACKET_SLOT_COUNT" ||
>> + die "ERROR: Rockchip MPP is outdated,
>> please get a more recent one."; } &&
>> + { enabled libdrm || die "ERROR: rkmpp
>> requires --enable-libdrm"; }
>> + }
> Keep the blank line after the list of normal checks and before the more
> complex cases below.
i Hope something like this makes it more readable :
enabled rkmpp && {
{ require_pkg_config rockchip_mpp
rockchip/rk_mpi.h mpp_create ||
die "ERROR : Rockchip MPP was not found."; }
&& { check_func_headers r
Re: [FFmpeg-devel] [RFC] ffmpeg: reverse logic for interlaced field ordering heuristic
On 9/5/2017 3:49 PM, Marton Balint wrote: > > On Fri, 1 Sep 2017, Timo Rothenpieler wrote: > >> When re-encoding for example interlaced h264 from mkv into mkv, the >> field ordering type switches from TT to TB, confusing some players. >> Same happens on a lot of other cases as well. >> >> I have no idea if this is the correct fix for it, but something is >> definitely going wrong. > > Before applying fixes in the field order code, I think we should first > decide if we should apply the patch in Or alternatively, consider the suggestion from Jerome Martinez. > > https://patchwork.ffmpeg.org/patch/4699/ > > Regards, > Marton > ___ > 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 2/2] lavfi/atempo: Avoid false triggering an assertion failure
On Sun, 3 Sep 2017, pkoshe...@gmail.com wrote:
From: Pavel Koshevoy
Steps to reproduce:
1. revert 4240e5b047379b29c33dd3f4438bc4e610527b83
2. ./ffmpeg -f lavfi -i sine=d=1 -af aselect=e=0,atempo=0.5 -y atempo.wav
---
libavfilter/af_atempo.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index 9eee8a63a8..41c8c0382a 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -914,6 +914,11 @@ static int yae_flush(ATempoContext *atempo,
atempo->state = YAE_FLUSH_OUTPUT;
+if (!atempo->nfrag) {
+ // there is nothing to flush:
+ return 0;
+}
+
if (atempo->position[0] == frag->position[0] + frag->nsamples &&
atempo->position[1] == frag->position[1] + frag->nsamples) {
// the current fragment is already flushed:
Thanks, this does the trick. Will apply in 1-2 days.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add support for RockChip Media Process Platform
On 05/09/17 19:55, LongChair . wrote:> Le 05/09/2017 à 19:19, Mark Thompson a
écrit :
>> On 05/09/17 12:44, LongChair . wrote:
>>> From: LongChair
>>>
>>> This adds hardware decoding for h264 / HEVC / VP8 using MPP Rockchip API.
>>> Will return frames holding an AVDRMFrameDescriptor struct in buf[0] that
>>> allows drm / dmabuf usage.
>>> Was tested on RK3288 (TinkerBoard) and RK3328.
>>> ---
>>> Changelog | 1 +
>>> configure | 15 +-
>>> libavcodec/Makefile| 3 +
>>> libavcodec/allcodecs.c | 3 +
>>> libavcodec/rkmppdec.c | 567
>>> +
>>> 5 files changed, 588 insertions(+), 1 deletion(-)
>>> create mode 100644 libavcodec/rkmppdec.c
>>>
>>> ...
>>> @@ -6008,7 +6016,12 @@ enabled openssl && { use_pkg_config
>>> openssl openssl/ssl.h OPENSSL_init
>>> check_lib openssl openssl/ssl.h
>>> SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 ||
>>> die "ERROR: openssl not found"; }
>>> enabled qtkit_indev && { check_header_objcc QTKit/QTKit.h || disable
>>> qtkit_indev; }
>>> -
Oops, sorry, that wasn't very clear. I meant leave this ^ blank line, and put
your check above it. The form of it in the patch is fine.
>>> +enabled rkmpp && { { require_pkg_config rockchip_mpp
>>> rockchip/rk_mpi.h mpp_create ||
>>> + die "ERROR : Rockchip MPP was not
>>> found."; } &&
>>> + { check_func_headers rockchip/rk_mpi_cmd.h
>>> "MPP_DEC_GET_FREE_PACKET_SLOT_COUNT" ||
>>> + die "ERROR: Rockchip MPP is outdated,
>>> please get a more recent one."; } &&
>>> + { enabled libdrm || die "ERROR: rkmpp
>>> requires --enable-libdrm"; }
>>> + }
>> Keep the blank line after the list of normal checks and before the more
>> complex cases below.
> i Hope something like this makes it more readable :
>
> enabled rkmpp && {
>
> { require_pkg_config rockchip_mpp
> rockchip/rk_mpi.h mpp_create ||
>
> die "ERROR : Rockchip MPP was not found."; }
>
>&& { check_func_headers rockchip/rk_mpi_cmd.h
> "MPP_DEC_GET_FREE_PACKET_SLOT_COUNT" ||
>
> die "ERROR: Rockchip MPP is outdated,
> please get a more recent one."; }
>
>&& { enabled libdrm ||
>
> die "ERROR: rkmpp requires
> --enable-libdrm"; }
>
> }
>
>> Also needs a rebase - qtkit_indev was removed.
> Will rebase
>>> ...
>>> +
>>> +// setup general frame fields
>>> +frame->format = AV_PIX_FMT_DRM_PRIME;
>>> +frame->width= mpp_frame_get_width(mppframe);
>>> +frame->height = mpp_frame_get_height(mppframe);
>>> +frame->pts = mpp_frame_get_pts(mppframe);
>> Can you get other frame metadata here? (SAR, all of the colour stuff?)
> well there are a few other functions that i didn't use that seem to be
> colorspace related here
> https://github.com/rockchip-linux/mpp/blob/30032ae303956788bd5b709c9bc70867b0ea95d6/inc/mpp_frame.h#L242-L253
> I never looked into those yet, but if you feel like some would be
> helpful and important I could have another looks there.
>> Does anything sensible happen with interlaced streams?
> there are flags defined for this in the MPP headers, but i don't know if
> they are effectively used in MppFrame. Would need to check further.
> https://github.com/rockchip-linux/mpp/blob/30032ae303956788bd5b709c9bc70867b0ea95d6/inc/mpp_frame.h#L28-L43
Yes, exactly those - all five of the colour-related functions. (I see the
point made earlier that this file is oddly reminiscent of libavutil/pixfmt.h
(including the comments), so you can probably just put the values directly into
the AVFrame fields...)
>>> ...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add support for RockChip Media Process Platform
On Tue, 5 Sep 2017 20:19:09 +0100
Mark Thompson wrote:
> On 05/09/17 19:55, LongChair . wrote:> Le 05/09/2017 à 19:19, Mark Thompson a
> écrit :
> >> On 05/09/17 12:44, LongChair . wrote:
> >>> From: LongChair
> >>>
> >>> This adds hardware decoding for h264 / HEVC / VP8 using MPP Rockchip API.
> >>> Will return frames holding an AVDRMFrameDescriptor struct in buf[0] that
> >>> allows drm / dmabuf usage.
> >>> Was tested on RK3288 (TinkerBoard) and RK3328.
> >>> ---
> >>> Changelog | 1 +
> >>> configure | 15 +-
> >>> libavcodec/Makefile| 3 +
> >>> libavcodec/allcodecs.c | 3 +
> >>> libavcodec/rkmppdec.c | 567
> >>> +
> >>> 5 files changed, 588 insertions(+), 1 deletion(-)
> >>> create mode 100644 libavcodec/rkmppdec.c
> >>>
> >>> ...
> >>> @@ -6008,7 +6016,12 @@ enabled openssl && { use_pkg_config
> >>> openssl openssl/ssl.h OPENSSL_init
> >>> check_lib openssl openssl/ssl.h
> >>> SSL_library_init -lssl -lcrypto -lws2_32 -lgdi32 ||
> >>> die "ERROR: openssl not found"; }
> >>> enabled qtkit_indev && { check_header_objcc QTKit/QTKit.h ||
> >>> disable qtkit_indev; }
> >>> -
>
> Oops, sorry, that wasn't very clear. I meant leave this ^ blank line, and
> put your check above it. The form of it in the patch is fine.
>
> >>> +enabled rkmpp && { { require_pkg_config rockchip_mpp
> >>> rockchip/rk_mpi.h mpp_create ||
> >>> + die "ERROR : Rockchip MPP was not
> >>> found."; } &&
> >>> + { check_func_headers
> >>> rockchip/rk_mpi_cmd.h "MPP_DEC_GET_FREE_PACKET_SLOT_COUNT" ||
> >>> + die "ERROR: Rockchip MPP is outdated,
> >>> please get a more recent one."; } &&
> >>> + { enabled libdrm || die "ERROR: rkmpp
> >>> requires --enable-libdrm"; }
> >>> + }
> >> Keep the blank line after the list of normal checks and before the more
> >> complex cases below.
> > i Hope something like this makes it more readable :
> >
> > enabled rkmpp && {
> >
> > { require_pkg_config rockchip_mpp
> > rockchip/rk_mpi.h mpp_create ||
> >
> > die "ERROR : Rockchip MPP was not
> > found."; }
> >
> >&& { check_func_headers rockchip/rk_mpi_cmd.h
> > "MPP_DEC_GET_FREE_PACKET_SLOT_COUNT" ||
> >
> > die "ERROR: Rockchip MPP is outdated,
> > please get a more recent one."; }
> >
> >&& { enabled libdrm ||
> >
> > die "ERROR: rkmpp requires
> > --enable-libdrm"; }
> >
> > }
> >
> >> Also needs a rebase - qtkit_indev was removed.
> > Will rebase
> >>> ...
> >>> +
> >>> +// setup general frame fields
> >>> +frame->format = AV_PIX_FMT_DRM_PRIME;
> >>> +frame->width= mpp_frame_get_width(mppframe);
> >>> +frame->height = mpp_frame_get_height(mppframe);
> >>> +frame->pts = mpp_frame_get_pts(mppframe);
> >> Can you get other frame metadata here? (SAR, all of the colour stuff?)
> > well there are a few other functions that i didn't use that seem to be
> > colorspace related here
> > https://github.com/rockchip-linux/mpp/blob/30032ae303956788bd5b709c9bc70867b0ea95d6/inc/mpp_frame.h#L242-L253
> > I never looked into those yet, but if you feel like some would be
> > helpful and important I could have another looks there.
> >> Does anything sensible happen with interlaced streams?
> > there are flags defined for this in the MPP headers, but i don't know if
> > they are effectively used in MppFrame. Would need to check further.
> > https://github.com/rockchip-linux/mpp/blob/30032ae303956788bd5b709c9bc70867b0ea95d6/inc/mpp_frame.h#L28-L43
> >
>
> Yes, exactly those - all five of the colour-related functions. (I see the
> point made earlier that this file is oddly reminiscent of libavutil/pixfmt.h
> (including the comments), so you can probably just put the values directly
> into the AVFrame fields...)
Well, in both cases, they're probably just the bitstream values.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/aacdec: don't immediately abort if an ADTS frame is not found
On 9/5/2017 3:52 PM, Marton Balint wrote: > > On Sun, 3 Sep 2017, James Almer wrote: > >> Skip the invalid data in an attempt to find one instead, and continue >> decoding from there. >> >> Fixes ticket #6634 > > If you skipped some broken ADTS frames, which were previously reported > errnous, then can you signal that somehow? (E.g. by setting > AVFrame->decode_error_flags on the next frame, or adding > AV_FRAME_FLAG_CORRUPT flag to the next returned frame?) The entire point of the custom packet reading function instead of using the raw one was to avoid propagating any kind of data that's not an ADTS frame. This could for example be an id3v1 or APE tag at the end. fate-adts-id3v1-demux tests this (The demuxer skips both garbage at the beginning of the file and the id3v1 tag at the end). If a file has an incomplete ADTS frame but with an intact header we afaics have no way to know it from the demuxer side. We read the amount of bytes the ADTS header reports and propagate it inside a packet. By the time the demuxer tries to read the next frame, if it finds out there's no ADTS header right after the reported end of the previous frame then the only thing it can do is bail out, or skip data until EOF or an ADTS header shows up. Before this patch, the former behavior is what happens. After this patch the demuxer will skip data until either EOF, an arbitrary amount of bytes were read, or an ADTS header shows up. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/decklink: new options 'list_pixelformats' and 'pixelformat_code' to allow pixelformat selection by code
On Mon, 4 Sep 2017, Gildas Fargeas wrote:
Thanks for the feedback. Here are the changes:
- renamed pixelformat_option in raw_format
- restored bm_v210 options (if set, it overrides the raw_format option)
- removed list_pixelformats and only mention supported raw codes in help.
- restore previous handling of output
Regarding the special handling of ARGB; the DeckLink API declares the ARGB enum
with a value of 32 which cannot be casted to the string ARGB.
(refer to DeckLinkAPIModes.h:132 v10.9.5)
It is not ideal but that seemed to be an appropriate way to map the value. Let
me know if you have something better in mind.
Actually I was thinking of making raw_format an integer, and using named
constants for modes. E.g.:
{ "raw_format", "set raw_format" , OFFSET(raw_format), AV_OPT_TYPE_INT, { .i64 =
MKTAG('2','v','u','y')}, 0, UINT_MAX, DEC, "raw_format" },
{ "uyvy422", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MKTAG('2','v','u','y') }, 0,
0, DEC, "raw_format"},
{ "yuv422p10", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MKTAG('v','2','1','0') }, 0,
0, DEC, "raw_format"},
{ "argb", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 32 }, 0,
0, DEC, "raw_format"},
{ "bgra", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MKTAG('B','G','R','A') }, 0,
0, DEC, "raw_format"},
{ "rgb48", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MKTAG('r','2','1','0') }, 0,
0, DEC, "raw_format"},
Since you need additional code to support a format, therefore, unlike
format_code, there is no benefit in allowing the user to specify any
fourcc.
This way the user can use more self-explanatory names. Also please add a
documentation for the raw_format option, and increase libavdevice micro
version.
Signed-off-by: Gildas Fargeas
---
libavdevice/decklink_common.cpp | 17 -
libavdevice/decklink_common.h | 1 +
libavdevice/decklink_common_c.h | 1 +
libavdevice/decklink_dec.cpp| 40
libavdevice/decklink_dec_c.c| 1 +
5 files changed, 51 insertions(+), 9 deletions(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index cbb591ce64..d0a80c1897 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -203,6 +203,21 @@ int ff_decklink_set_format(AVFormatContext *avctx,
if (cctx->format_code)
memcpy(format_buf, cctx->format_code, FFMIN(strlen(cctx->format_code),
sizeof(format_buf)));
BMDDisplayMode target_mode = (BMDDisplayMode)AV_RB32(format_buf);
+
+char pixel_buf[] = "";
+ctx->bmd_pixel= bmdFormat8BitYUV;
+if (!strcmp(cctx->raw_format, "ARGB")) {
+/* DeckLink API value (32) for this one cannot be casted back into the
string ARGB. */
+ctx->bmd_pixel = bmdFormat8BitARGB;
+} else {
+memcpy(pixel_buf, cctx->raw_format, FFMIN(strlen(cctx->raw_format),
sizeof(pixel_buf)));
+ctx->bmd_pixel = (BMDPixelFormat)AV_RB32(pixel_buf);
+}
If you are using named constants, then this code is probably uneeded.
+
+if (cctx->v210) {
+ctx->bmd_pixel = bmdFormat10BitYUV;
You should show a deprecation warning here and advise the user to use
-raw_format instead.
+}
+
AVRational target_tb = av_make_q(tb_num, tb_den);
ctx->bmd_mode = bmdModeUnknown;
while ((ctx->bmd_mode == bmdModeUnknown) && itermode->Next(&mode) == S_OK) {
@@ -241,7 +256,7 @@ int ff_decklink_set_format(AVFormatContext *avctx,
if (ctx->bmd_mode == bmdModeUnknown)
return -1;
if (direction == DIRECTION_IN) {
-if (ctx->dli->DoesSupportVideoMode(ctx->bmd_mode, bmdFormat8BitYUV,
+if (ctx->dli->DoesSupportVideoMode(ctx->bmd_mode, ctx->bmd_pixel,
bmdVideoOutputFlagDefault,
&support, NULL) != S_OK)
return -1;
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 749eb0f8b8..770888a00b 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -56,6 +56,7 @@ struct decklink_ctx {
BMDTimeValue bmd_tb_den;
BMDTimeValue bmd_tb_num;
BMDDisplayMode bmd_mode;
+BMDPixelFormat bmd_pixel;
BMDVideoConnection video_input;
BMDAudioConnection audio_input;
int bmd_width;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index e263480474..a1eb225fbd 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -49,6 +49,7 @@ struct decklink_cctx {
int video_input;
int draw_bars;
char *format_code;
+char *raw_format;
int64_t queue_size;
};
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index c271ff3639..df12d41050 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -680,8 +680,8 @@ av_cold int ff_decklink_read_header(AVFormatContext *avctx)
if (mode_num > 0 || cctx->format_code) {
if (ff_deckli
Re: [FFmpeg-devel] [PATCH] avformat/aacdec: don't immediately abort if an ADTS frame is not found
On Tue, 5 Sep 2017, James Almer wrote: On 9/5/2017 3:52 PM, Marton Balint wrote: On Sun, 3 Sep 2017, James Almer wrote: Skip the invalid data in an attempt to find one instead, and continue decoding from there. Fixes ticket #6634 If you skipped some broken ADTS frames, which were previously reported errnous, then can you signal that somehow? (E.g. by setting AVFrame->decode_error_flags on the next frame, or adding AV_FRAME_FLAG_CORRUPT flag to the next returned frame?) The entire point of the custom packet reading function instead of using the raw one was to avoid propagating any kind of data that's not an ADTS frame. This could for example be an id3v1 or APE tag at the end. fate-adts-id3v1-demux tests this (The demuxer skips both garbage at the beginning of the file and the id3v1 tag at the end). If a file has an incomplete ADTS frame but with an intact header we afaics have no way to know it from the demuxer side. We read the amount of bytes the ADTS header reports and propagate it inside a packet. By the time the demuxer tries to read the next frame, if it finds out there's no ADTS header right after the reported end of the previous frame then the only thing it can do is bail out, or skip data until EOF or an ADTS header shows up. Before this patch, the former behavior is what happens. After this patch the demuxer will skip data until either EOF, an arbitrary amount of bytes were read, or an ADTS header shows up. I kind of confused this with the aac decoder, sorry. Thanks for explaining, I guess it is OK then. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/aacdec: don't immediately abort if an ADTS frame is not found
On Mon, Sep 4, 2017 at 4:47 AM, James Almer wrote:
> Skip the invalid data in an attempt to find one instead, and continue
> decoding from there.
>
> Fixes ticket #6634
>
> Signed-off-by: James Almer
> ---
> libavformat/aacdec.c | 41 +
> 1 file changed, 29 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
> index 364b33404f..7aacc88560 100644
> --- a/libavformat/aacdec.c
> +++ b/libavformat/aacdec.c
> @@ -77,10 +77,29 @@ static int adts_aac_probe(AVProbeData *p)
> return 0;
> }
>
> +static int resync(AVFormatContext *s)
> +{
> +uint16_t state;
> +
> +state = avio_r8(s->pb);
> +while (!avio_feof(s->pb) && avio_tell(s->pb) < s->probesize) {
> +state = (state << 8) | avio_r8(s->pb);
> +if ((state >> 4) != 0xFFF)
> +continue;
> +avio_seek(s->pb, -2, SEEK_CUR);
> +break;
> +}
> +
The ADTS sync code isn't that much of a sync code, maybe it might be
more resilient if you try to read the frame size and check if after
that the next frame also starts with a valid code?
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd: implement threaded NewTek NDI output
On Tue, 5 Sep 2017, Maksym Veremeyenko wrote: 04.09.2017 17:10, Maksym Veremeyenko пише: Hi, attached patch implemented threaded NDI output - separate output thread for each stream. it makes audio preview in my case more smooth. updated patch allows running audio/video threads separately If I get this correctly, this patch is needed because you can only schedule 1 frame to the NDI API, therefore especially for shorter audio frames the buffer may underrun, right?. If that is the case, then I'd describe this in a bit more detail in the docs and/or the commit message. Also, decklink uses a concept called preroll for a similar purpose, it is specified in time, and the video buffer is capable of storing preroll*2 amount of video. (Also, at the start of the stream the code only starts draining the buffer after preroll amount of video is received, there comes the name, preroll. This way the buffer won't underrun even at the start of the stream). I just mentioned this because you may want to support a similar concept, or specify buffer sizes in time, instead of in frames. But if not, that is fine as well. As for the actual code - I see a lot of code duplications :), maybe you can factorize audio_thread and video_thread to use the same function, and also the code which creates these threads. But in general the code looks fine. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_overlay: Restore shorthand option order
On Tue, 5 Sep 2017, Michael Niedermayer wrote: Signed-off-by: Michael Niedermayer --- doc/filters.texi | 9 + libavfilter/framesync2.c | 6 -- libavfilter/framesync2.h | 6 ++ libavfilter/vf_overlay.c | 8 4 files changed, 23 insertions(+), 6 deletions(-) No more comments from me, thanks. Do you plan to do a similar fix for blend/tblend as well? Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/aacdec: don't immediately abort if an ADTS frame is not found
On 9/5/2017 5:30 PM, Hendrik Leppkes wrote:
> On Mon, Sep 4, 2017 at 4:47 AM, James Almer wrote:
>> Skip the invalid data in an attempt to find one instead, and continue
>> decoding from there.
>>
>> Fixes ticket #6634
>>
>> Signed-off-by: James Almer
>> ---
>> libavformat/aacdec.c | 41 +
>> 1 file changed, 29 insertions(+), 12 deletions(-)
>>
>> diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
>> index 364b33404f..7aacc88560 100644
>> --- a/libavformat/aacdec.c
>> +++ b/libavformat/aacdec.c
>> @@ -77,10 +77,29 @@ static int adts_aac_probe(AVProbeData *p)
>> return 0;
>> }
>>
>> +static int resync(AVFormatContext *s)
>> +{
>> +uint16_t state;
>> +
>> +state = avio_r8(s->pb);
>> +while (!avio_feof(s->pb) && avio_tell(s->pb) < s->probesize) {
>> +state = (state << 8) | avio_r8(s->pb);
>> +if ((state >> 4) != 0xFFF)
>> +continue;
>> +avio_seek(s->pb, -2, SEEK_CUR);
>> +break;
>> +}
>> +
>
> The ADTS sync code isn't that much of a sync code, maybe it might be
> more resilient if you try to read the frame size and check if after
> that the next frame also starts with a valid code?
That will only let me know if at the end of the frame is another frame,
and not if the frame I'm reading is complete or not.
Maybe it's complete and right after it there's an id3v1 tag. Maybe it's
complete and right after it there's garbage. Maybe it's incomplete
because another ADTS frame started suddenly in the middle of the one i
tried to read because the source is some weird stream (sample in the
ticket this fixes), and after reading the reported size of the intended
frame the demuxer will find itself in the middle of the new one but
unable to know that's the case.
Really, at the demuxer level i can't do much more than read an ADTS
header, make sure it's at least seven bytes long and that the reported
size of the entire frame is bigger than the header size, then make a
packet out of that. The decoder/parser will handle things from there,
knowing that at very least for the first few bytes what reaches them is
an ADTS frame.
>
> - Hendrik
> ___
> 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] avfilter/vf_overlay: Restore shorthand option order
On 9/5/17, Marton Balint wrote: > > On Tue, 5 Sep 2017, Michael Niedermayer wrote: > >> Signed-off-by: Michael Niedermayer >> --- >> doc/filters.texi | 9 + >> libavfilter/framesync2.c | 6 -- >> libavfilter/framesync2.h | 6 ++ >> libavfilter/vf_overlay.c | 8 >> 4 files changed, 23 insertions(+), 6 deletions(-) > > No more comments from me, thanks. Do you plan to do a similar fix for > blend/tblend as well? Please NO leave blend from this mess. tblend does not use framesync. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libswscale/swscale_unscaled: fix DITHER_COPY macro
On Tue, Sep 05, 2017 at 04:42:06PM +0200, Mateusz wrote:
> W dniu 2017-09-05 o 15:40, Michael Niedermayer pisze:
> > On Mon, Sep 04, 2017 at 09:33:34AM +0200, Mateusz wrote:
> >> If ffmpeg reduces bit-depth to 8-bit or more, it uses DITHER_COPY macro.
> >> The problem is DITHER_COPY macro make images darker (on all planes).
> >>
> >> In x265 project there is issue #365 which is caused by this DITHER_COPY
> >> bug.
> >> I think it is time to fix -- there are more and more high bit-depth
> >> sources.
> >>
> >> Please review.
> >>
> >> libswscale/swscale_unscaled.c | 44
> >> +--
> >> 1 file changed, 13 insertions(+), 31 deletions(-)
> >
> > please provide a git compatible patch with with commit message as produced
> > by git format-patch or git send-email
> >
> > this mail is not accepted as is by git
> > Applying: libswscale/swscale_unscaled: fix DITHER_COPY macro
> > error: corrupt patch at line 6
> > error: could not build fake ancestor
> > Patch failed at 0001 libswscale/swscale_unscaled: fix DITHER_COPY macro
> >
> > [...]
>
> I've attached the result of git format-patch command.
>
> Sorry for 1 private e-mail (I clicked wrong button).
>
> Mateusz
> swscale_unscaled.c | 44 +---
> 1 file changed, 13 insertions(+), 31 deletions(-)
> 9973b13b3f74319abe9c97302ee87b2b3468b3b6
> 0001-fix-DITHER_COPY-macro-to-avoid-make-images-darker.patch
> From 9b96d612fef46ccec7e148cd7f8e8666b4e7a4cd Mon Sep 17 00:00:00 2001
> From: Mateusz
> Date: Tue, 5 Sep 2017 16:09:28 +0200
> Subject: [PATCH] fix DITHER_COPY macro to avoid make images darker
>
> ---
> libswscale/swscale_unscaled.c | 44
> +--
> 1 file changed, 13 insertions(+), 31 deletions(-)
>
> diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
> index ef36aec..3b7a5a9 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,22 +1484,22 @@ 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];\
> +unsigned shift= src_depth-dst_depth, tmp;\
> for (i = 0; i < height; i++) {\
> -const uint8_t *dither= dithers[src_depth-9][i&7];\
> +const uint8_t *dither= dithers[shift-1][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+
Re: [FFmpeg-devel] [PATCH] avfilter/vf_overlay: Restore shorthand option order
On Tue, Sep 05, 2017 at 11:11:00PM +0200, Marton Balint wrote: > > On Tue, 5 Sep 2017, Michael Niedermayer wrote: > > >Signed-off-by: Michael Niedermayer > >--- > >doc/filters.texi | 9 + > >libavfilter/framesync2.c | 6 -- > >libavfilter/framesync2.h | 6 ++ > >libavfilter/vf_overlay.c | 8 > >4 files changed, 23 insertions(+), 6 deletions(-) > > No more comments from me, thanks. will apply > Do you plan to do a similar fix > for blend/tblend as well? I did run into the issue in overlay so thats the one i wanted to fix primarely. I can change the others too but only if the people maintaining them want this. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus 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/aacdec: don't immediately abort if an ADTS frame is not found
On Tue, Sep 5, 2017 at 11:20 PM, James Almer wrote:
> On 9/5/2017 5:30 PM, Hendrik Leppkes wrote:
>> On Mon, Sep 4, 2017 at 4:47 AM, James Almer wrote:
>>> Skip the invalid data in an attempt to find one instead, and continue
>>> decoding from there.
>>>
>>> Fixes ticket #6634
>>>
>>> Signed-off-by: James Almer
>>> ---
>>> libavformat/aacdec.c | 41 +
>>> 1 file changed, 29 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
>>> index 364b33404f..7aacc88560 100644
>>> --- a/libavformat/aacdec.c
>>> +++ b/libavformat/aacdec.c
>>> @@ -77,10 +77,29 @@ static int adts_aac_probe(AVProbeData *p)
>>> return 0;
>>> }
>>>
>>> +static int resync(AVFormatContext *s)
>>> +{
>>> +uint16_t state;
>>> +
>>> +state = avio_r8(s->pb);
>>> +while (!avio_feof(s->pb) && avio_tell(s->pb) < s->probesize) {
>>> +state = (state << 8) | avio_r8(s->pb);
>>> +if ((state >> 4) != 0xFFF)
>>> +continue;
>>> +avio_seek(s->pb, -2, SEEK_CUR);
>>> +break;
>>> +}
>>> +
>>
>> The ADTS sync code isn't that much of a sync code, maybe it might be
>> more resilient if you try to read the frame size and check if after
>> that the next frame also starts with a valid code?
>
> That will only let me know if at the end of the frame is another frame,
> and not if the frame I'm reading is complete or not.
> Maybe it's complete and right after it there's an id3v1 tag. Maybe it's
> complete and right after it there's garbage. Maybe it's incomplete
> because another ADTS frame started suddenly in the middle of the one i
> tried to read because the source is some weird stream (sample in the
> ticket this fixes), and after reading the reported size of the intended
> frame the demuxer will find itself in the middle of the new one but
> unable to know that's the case.
>
> Really, at the demuxer level i can't do much more than read an ADTS
> header, make sure it's at least seven bytes long and that the reported
> size of the entire frame is bigger than the header size, then make a
> packet out of that. The decoder/parser will handle things from there,
> knowing that at very least for the first few bytes what reaches them is
> an ADTS frame.
>
We're not talking about validating the ADTS frame, but just making
sure you really "resync" to the start of a frame, and not some
arbitrary random position that just happens to be 0xFFF, because that
code isn't very long or very special.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/aacdec: don't immediately abort if an ADTS frame is not found
On 9/5/2017 7:12 PM, Hendrik Leppkes wrote:
> On Tue, Sep 5, 2017 at 11:20 PM, James Almer wrote:
>> On 9/5/2017 5:30 PM, Hendrik Leppkes wrote:
>>> On Mon, Sep 4, 2017 at 4:47 AM, James Almer wrote:
Skip the invalid data in an attempt to find one instead, and continue
decoding from there.
Fixes ticket #6634
Signed-off-by: James Almer
---
libavformat/aacdec.c | 41 +
1 file changed, 29 insertions(+), 12 deletions(-)
diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
index 364b33404f..7aacc88560 100644
--- a/libavformat/aacdec.c
+++ b/libavformat/aacdec.c
@@ -77,10 +77,29 @@ static int adts_aac_probe(AVProbeData *p)
return 0;
}
+static int resync(AVFormatContext *s)
+{
+uint16_t state;
+
+state = avio_r8(s->pb);
+while (!avio_feof(s->pb) && avio_tell(s->pb) < s->probesize) {
+state = (state << 8) | avio_r8(s->pb);
+if ((state >> 4) != 0xFFF)
+continue;
+avio_seek(s->pb, -2, SEEK_CUR);
+break;
+}
+
>>>
>>> The ADTS sync code isn't that much of a sync code, maybe it might be
>>> more resilient if you try to read the frame size and check if after
>>> that the next frame also starts with a valid code?
>>
>> That will only let me know if at the end of the frame is another frame,
>> and not if the frame I'm reading is complete or not.
>> Maybe it's complete and right after it there's an id3v1 tag. Maybe it's
>> complete and right after it there's garbage. Maybe it's incomplete
>> because another ADTS frame started suddenly in the middle of the one i
>> tried to read because the source is some weird stream (sample in the
>> ticket this fixes), and after reading the reported size of the intended
>> frame the demuxer will find itself in the middle of the new one but
>> unable to know that's the case.
>>
>> Really, at the demuxer level i can't do much more than read an ADTS
>> header, make sure it's at least seven bytes long and that the reported
>> size of the entire frame is bigger than the header size, then make a
>> packet out of that. The decoder/parser will handle things from there,
>> knowing that at very least for the first few bytes what reaches them is
>> an ADTS frame.
>>
>
> We're not talking about validating the ADTS frame, but just making
> sure you really "resync" to the start of a frame, and not some
> arbitrary random position that just happens to be 0xFFF, because that
> code isn't very long or very special.
Again, what if there's no new ADTS frame after the supposed end of the
one we're reading? How do we interpret that? That the one we read was
wrong or that it was right and there simply is no new ADTS frame right
after it? How does that help us decide if we propagate it or not?
If anything, i could maybe use avpriv_aac_parse_header(). Barely more
resilient than just looking for a sync code and the size field being >
7, but it's something i guess.
>
> - Hendrik
> ___
> 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] [PATCHv10] libavcodec: v4l2: add support for v4l2 mem2mem codecs
Apologies for sending v10 right after having sent v9 just a few hours ago but I think it makes sense to improve the overall readability while saving some memory. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv10] libavcodec: v4l2: add support for v4l2 mem2mem codecs
This patchset enhances Alexis Ballier's original patch and validates it using Qualcomm's Venus hardware (driver recently landed upstream [1]). This has been tested on Qualcomm's DragonBoard 410c and 820c Configure/make scripts have been validated on Ubuntu 10.04 and 16.04. Tested decoders: - h264 - h263 - mpeg4 - vp8 - vp9 - hevc Tested encoders: - h264 - h263 - mpeg4 Tested transcoding (concurrent encoding/decoding) Some of the changes introduced: - v4l2: code cleanup and abstractions added - v4l2: follow the new encode/decode api. - v4l2: fix display size for NV12 output pool. - v4l2: handle EOS. - v4l2: vp8 and mpeg4 decoding and encoding. - v4l2: hevc and vp9 support. - v4l2: generate EOF on dequeue errors. - v4l2: h264_mp4toannexb filtering. - v4l2: fixed make install and fate issues. - v4l2: codecs enabled/disabled depending on pixfmt defined - v4l2: pass timebase/framerate to the context - v4l2: runtime decoder reconfiguration. - v4l2: add more frame information - v4l2: free hardware resources on last reference being released - v4l2: encoding: disable b-frames for upstreaming (patch required) [1] https://lwn.net/Articles/697956/ Reviewed-by: Jorge Ramirez Reviewed-by: Alexis Ballier Tested-by: Jorge Ramirez --- Changelog |1 + configure | 28 ++ libavcodec/Makefile | 15 + libavcodec/allcodecs.c|9 + libavcodec/v4l2_buffers.c | 1002 + libavcodec/v4l2_buffers.h | 196 libavcodec/v4l2_fmt.c | 182 libavcodec/v4l2_fmt.h | 34 ++ libavcodec/v4l2_m2m.c | 479 libavcodec/v4l2_m2m.h | 69 +++ libavcodec/v4l2_m2m_avcodec.h | 32 ++ libavcodec/v4l2_m2m_dec.c | 235 ++ libavcodec/v4l2_m2m_enc.c | 354 +++ 13 files changed, 2636 insertions(+) create mode 100644 libavcodec/v4l2_buffers.c create mode 100644 libavcodec/v4l2_buffers.h create mode 100644 libavcodec/v4l2_fmt.c create mode 100644 libavcodec/v4l2_fmt.h create mode 100644 libavcodec/v4l2_m2m.c create mode 100644 libavcodec/v4l2_m2m.h create mode 100644 libavcodec/v4l2_m2m_avcodec.h create mode 100644 libavcodec/v4l2_m2m_dec.c create mode 100644 libavcodec/v4l2_m2m_enc.c diff --git a/Changelog b/Changelog index cae5254..95f70f0 100644 --- a/Changelog +++ b/Changelog @@ -43,6 +43,7 @@ version : - add --disable-autodetect build switch - drop deprecated qtkit input device (use avfoundation instead) - despill video filter +- V4L2 mem2mem HW assisted codecs version 3.3: - CrystalHD decoder moved to new decode API diff --git a/configure b/configure index f7558f6..5a41698 100755 --- a/configure +++ b/configure @@ -185,6 +185,7 @@ Individual component options: --enable-filter=NAME enable filter NAME --disable-filter=NAMEdisable filter NAME --disable-filtersdisable all filters + --disable-v4l2_m2m disable V4L2 mem2mem code [autodetect] External library support: @@ -1604,6 +1605,7 @@ HWACCEL_AUTODETECT_LIBRARY_LIST=" vda vdpau videotoolbox_hwaccel +v4l2_m2m xvmc " @@ -2735,6 +2737,7 @@ omx_rpi_select="omx" qsvdec_select="qsv" qsvenc_select="qsv" vaapi_encode_deps="vaapi" +v4l2_m2m_deps_any="linux_videodev2_h" hwupload_cuda_filter_deps="cuda" scale_npp_filter_deps="cuda libnpp" @@ -2744,6 +2747,8 @@ nvenc_deps="cuda" nvenc_deps_any="dlopen LoadLibrary" nvenc_encoder_deps="nvenc" +h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m" +h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m" h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser" h264_cuvid_decoder_deps="cuda cuvid" h264_cuvid_decoder_select="h264_mp4toannexb_bsf" @@ -2762,6 +2767,8 @@ h264_vda_decoder_deps="vda" h264_vda_decoder_select="h264_decoder" h264_vdpau_decoder_deps="vdpau" h264_vdpau_decoder_select="h264_decoder" +h264_v4l2m2m_decoder_deps="v4l2_m2m h264_v4l2_m2m" +h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m" hevc_cuvid_decoder_deps="cuda cuvid" hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf" hevc_mediacodec_decoder_deps="mediacodec" @@ -2773,12 +2780,15 @@ hevc_qsv_encoder_deps="libmfx" hevc_qsv_encoder_select="hevcparse qsvenc" hevc_vaapi_encoder_deps="VAEncPictureParameterBufferHEVC" hevc_vaapi_encoder_select="vaapi_encode golomb" +hevc_v4l2m2m_decoder_deps="v4l2_m2m hevc_v4l2_m2m" +hevc_v4l2m2m_encoder_deps="v4l2_m2m hevc_v4l2_m2m" mjpeg_cuvid_decoder_deps="cuda cuvid" mjpeg_vaapi_encoder_deps="VAEncPictureParameterBufferJPEG" mjpeg_vaapi_encoder_select="vaapi_encode jpegtables" mpeg1_cuvid_decoder_deps="cuda cuvid" mpeg1_vdpau_decoder_deps="vdpau" mpeg1_v
Re: [FFmpeg-devel] [PATCH] libswscale/swscale_unscaled: fix DITHER_COPY macro
W dniu 2017-09-05 o 23:37, Michael Niedermayer pisze:
> On Tue, Sep 05, 2017 at 04:42:06PM +0200, Mateusz wrote:
>> W dniu 2017-09-05 o 15:40, Michael Niedermayer pisze:
>>> On Mon, Sep 04, 2017 at 09:33:34AM +0200, Mateusz wrote:
If ffmpeg reduces bit-depth to 8-bit or more, it uses DITHER_COPY macro.
The problem is DITHER_COPY macro make images darker (on all planes).
In x265 project there is issue #365 which is caused by this DITHER_COPY
bug.
I think it is time to fix -- there are more and more high bit-depth
sources.
Please review.
libswscale/swscale_unscaled.c | 44
+--
1 file changed, 13 insertions(+), 31 deletions(-)
>>>
>>> please provide a git compatible patch with with commit message as produced
>>> by git format-patch or git send-email
>>>
>>> this mail is not accepted as is by git
>>> Applying: libswscale/swscale_unscaled: fix DITHER_COPY macro
>>> error: corrupt patch at line 6
>>> error: could not build fake ancestor
>>> Patch failed at 0001 libswscale/swscale_unscaled: fix DITHER_COPY macro
>>>
>>> [...]
>>
>> I've attached the result of git format-patch command.
>>
>> Sorry for 1 private e-mail (I clicked wrong button).
>>
>> Mateusz
>
>> swscale_unscaled.c | 44 +---
>> 1 file changed, 13 insertions(+), 31 deletions(-)
>> 9973b13b3f74319abe9c97302ee87b2b3468b3b6
>> 0001-fix-DITHER_COPY-macro-to-avoid-make-images-darker.patch
>> From 9b96d612fef46ccec7e148cd7f8e8666b4e7a4cd Mon Sep 17 00:00:00 2001
>> From: Mateusz
>> Date: Tue, 5 Sep 2017 16:09:28 +0200
>> Subject: [PATCH] fix DITHER_COPY macro to avoid make images darker
>>
>> ---
>> libswscale/swscale_unscaled.c | 44
>> +--
>> 1 file changed, 13 insertions(+), 31 deletions(-)
>>
>> diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
>> index ef36aec..3b7a5a9 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,22 +1484,22 @@ 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];\
>> +unsigned shift= src_depth-dst_depth, tmp;\
>> for (i = 0; i < height; i++) {\
>> -const uint8_t *dither= dithers[src_depth-9][i&7];\
>> +const uint8_t *dither= dithers[shift-1][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])*sca
Re: [FFmpeg-devel] [PATCH] avformat/aacdec: don't immediately abort if an ADTS frame is not found
On Wed, Sep 6, 2017 at 12:32 AM, James Almer wrote:
> On 9/5/2017 7:12 PM, Hendrik Leppkes wrote:
>> On Tue, Sep 5, 2017 at 11:20 PM, James Almer wrote:
>>> On 9/5/2017 5:30 PM, Hendrik Leppkes wrote:
On Mon, Sep 4, 2017 at 4:47 AM, James Almer wrote:
> Skip the invalid data in an attempt to find one instead, and continue
> decoding from there.
>
> Fixes ticket #6634
>
> Signed-off-by: James Almer
> ---
> libavformat/aacdec.c | 41 +
> 1 file changed, 29 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
> index 364b33404f..7aacc88560 100644
> --- a/libavformat/aacdec.c
> +++ b/libavformat/aacdec.c
> @@ -77,10 +77,29 @@ static int adts_aac_probe(AVProbeData *p)
> return 0;
> }
>
> +static int resync(AVFormatContext *s)
> +{
> +uint16_t state;
> +
> +state = avio_r8(s->pb);
> +while (!avio_feof(s->pb) && avio_tell(s->pb) < s->probesize) {
> +state = (state << 8) | avio_r8(s->pb);
> +if ((state >> 4) != 0xFFF)
> +continue;
> +avio_seek(s->pb, -2, SEEK_CUR);
> +break;
> +}
> +
The ADTS sync code isn't that much of a sync code, maybe it might be
more resilient if you try to read the frame size and check if after
that the next frame also starts with a valid code?
>>>
>>> That will only let me know if at the end of the frame is another frame,
>>> and not if the frame I'm reading is complete or not.
>>> Maybe it's complete and right after it there's an id3v1 tag. Maybe it's
>>> complete and right after it there's garbage. Maybe it's incomplete
>>> because another ADTS frame started suddenly in the middle of the one i
>>> tried to read because the source is some weird stream (sample in the
>>> ticket this fixes), and after reading the reported size of the intended
>>> frame the demuxer will find itself in the middle of the new one but
>>> unable to know that's the case.
>>>
>>> Really, at the demuxer level i can't do much more than read an ADTS
>>> header, make sure it's at least seven bytes long and that the reported
>>> size of the entire frame is bigger than the header size, then make a
>>> packet out of that. The decoder/parser will handle things from there,
>>> knowing that at very least for the first few bytes what reaches them is
>>> an ADTS frame.
>>>
>>
>> We're not talking about validating the ADTS frame, but just making
>> sure you really "resync" to the start of a frame, and not some
>> arbitrary random position that just happens to be 0xFFF, because that
>> code isn't very long or very special.
>
> Again, what if there's no new ADTS frame after the supposed end of the
> one we're reading? How do we interpret that? That the one we read was
> wrong or that it was right and there simply is no new ADTS frame right
> after it? How does that help us decide if we propagate it or not?
>
> If anything, i could maybe use avpriv_aac_parse_header(). Barely more
> resilient than just looking for a sync code and the size field being >
> 7, but it's something i guess.
If there is no two consecutive ADTS frames to be found, just stop sending data.
I don't see the problem. We use this kind of resync in all sorts of
demuxers, because a 12-bit magic number that happens to be all 1's
isn't all that safe from being aliased in other data.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/snowdec: Check intra block dc differences.
On Tue, Sep 05, 2017 at 07:13:00AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Sep 4, 2017 at 10:11 PM, James Almer wrote:
>
> > On 9/4/2017 11:00 PM, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Mon, Sep 4, 2017 at 12:11 PM, Michael Niedermayer
> > > >> wrote:
> > >
> > >> if(type){
> > >> +int ld, cbd, crd;
> > >> pred_mv(s, &mx, &my, 0, left, top, tr);
> > >> -l += get_symbol(&s->c, &s->block_state[32], 1);
> > >> +ld = get_symbol(&s->c, &s->block_state[32], 1);
> > >> +if (ld < -255 || ld > 255) {
> > >> +av_log(s->avctx, AV_LOG_ERROR, "Invalid (Out of range)
> > >> intra luma block DC difference %d\n", ld);
> > >> +return AVERROR_INVALIDDATA;
> > >> +}
> > >> +l += ld;
> > >> if (s->nb_planes > 2) {
> > >> -cb+= get_symbol(&s->c, &s->block_state[64], 1);
> > >> -cr+= get_symbol(&s->c, &s->block_state[96], 1);
> > >> +cbd = get_symbol(&s->c, &s->block_state[64], 1);
> > >> +crd = get_symbol(&s->c, &s->block_state[96], 1);
> > >> +if (cbd < -255 || cbd > 255 || crd < -255 || crd >
> > 255) {
> > >> +av_log(s->avctx, AV_LOG_ERROR, "Invalid (Out of
> > >> range) intra chroma block DC difference %d, %d\n", cbd, crd);
> > >> +return AVERROR_INVALIDDATA;
> > >> +}
> > >> +cb += cbd;
> > >> +cr += crd;
> > >> }
> > >
> > >
> > > I recognize the great improvements in your messages. They are much better
> > > than before. They are still not appropriate for display to end users.
> > > Please use ff_tlog(), as was suggested in the original thread.
> >
> > Now that i looked at ff_tlog() closely it's only enabled if -DTRACE is
> > used during compilation, and then it prints stuff at the trace log
> > level, which is even lower than debug and used to print a bunch of
> > assorted values that are not error log messages.
>
>
> You're right, ff_dlog() seems better (see libavcodec/internal.h).
ff_dlog() is not part of a user build so a users bug report will not
contain it at any verbose / debug level.
If that is what the community wants, we can of course go that way.
My oppinion is that its a bad idea for the future maintainability
of the project to use ff_dlog() widely for error details.
But its the communities project and neither mine nor yours.
Its also the community that will have to live with the resulting
codebase and set of bug reports ...
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- Aristotle
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/snowdec: Check intra block dc differences.
Hi, On Tue, Sep 5, 2017 at 7:47 PM, Michael Niedermayer wrote: > ff_dlog() is not part of a user build so a users bug report will not > contain it at any verbose / debug level. > That is intentional. The messages are not meant for end users, since they are not helpful or informative for them. Bug reports always ask for files, and therefore it will be trivial for us as experienced developers to reproduce the bugs (which we do anyway) with a debug build and -v debug to get the appropriate level of technical verbosity that results in information appropriate for developers while debugging such issues. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2 1/2] avcodec: add execute3() api to utilize the main function of avpriv_slicethread_create().
Signed-off-by: Ilia Valiakhmetov
---
libavcodec/avcodec.h | 7 ++-
libavcodec/options.c | 1 +
libavcodec/pthread_slice.c | 26 --
libavcodec/utils.c | 14 ++
4 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 650..712f40c 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1089,6 +1089,10 @@ typedef struct RcOverride{
*/
#define AV_CODEC_CAP_AVOID_PROBING (1 << 17)
/**
+ * Codec initializes slice-based threading with a main function
+ */
+#define AV_CODEC_SLICE_THREAD_HAS_MF (1 << 18)
+/**
* Codec is intra only.
*/
#define AV_CODEC_CAP_INTRA_ONLY 0x4000
@@ -3233,7 +3237,7 @@ typedef struct AVCodecContext {
* - decoding: Set by libavcodec, user can override.
*/
int (*execute2)(struct AVCodecContext *c, int (*func)(struct
AVCodecContext *c2, void *arg, int jobnr, int threadnr), void *arg2, int *ret,
int count);
-
+int (*execute3)(struct AVCodecContext *c, int (*func)(struct
AVCodecContext *c2, void *arg, int jobnr, int threadnr), int (*m_func)(struct
AVCodecContext *c3), void *arg2, int *ret, int count);
/**
* noise vs. sse weight for the nsse comparison function
* - encoding: Set by user.
@@ -5774,6 +5778,7 @@ const char *avcodec_profile_name(enum AVCodecID codec_id,
int profile);
int avcodec_default_execute(AVCodecContext *c, int (*func)(AVCodecContext *c2,
void *arg2),void *arg, int *ret, int count, int size);
int avcodec_default_execute2(AVCodecContext *c, int (*func)(AVCodecContext
*c2, void *arg2, int, int),void *arg, int *ret, int count);
+int avcodec_default_execute3(AVCodecContext *c, int (*func)(AVCodecContext
*c2, void *arg2, int jobnr, int threadnr), int (*m_func)(struct AVCodecContext
*c3), void *arg, int *ret, int count);
//FIXME func typedef
/**
diff --git a/libavcodec/options.c b/libavcodec/options.c
index 82e1217..6d63bdb 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -117,6 +117,7 @@ static int init_context_defaults(AVCodecContext *s, const
AVCodec *codec)
s->get_format = avcodec_default_get_format;
s->execute = avcodec_default_execute;
s->execute2= avcodec_default_execute2;
+s->execute3= avcodec_default_execute3;
s->sample_aspect_ratio = (AVRational){0,1};
s->pix_fmt = AV_PIX_FMT_NONE;
s->sw_pix_fmt = AV_PIX_FMT_NONE;
diff --git a/libavcodec/pthread_slice.c b/libavcodec/pthread_slice.c
index c781d35..3aff816 100644
--- a/libavcodec/pthread_slice.c
+++ b/libavcodec/pthread_slice.c
@@ -38,11 +38,13 @@
typedef int (action_func)(AVCodecContext *c, void *arg);
typedef int (action_func2)(AVCodecContext *c, void *arg, int jobnr, int
threadnr);
+typedef int (main_func)(AVCodecContext *c);
typedef struct SliceThreadContext {
AVSliceThread *thread;
action_func *func;
action_func2 *func2;
+main_func *m_func;
void *args;
int *rets;
int job_size;
@@ -54,6 +56,12 @@ typedef struct SliceThreadContext {
pthread_mutex_t *progress_mutex;
} SliceThreadContext;
+static void main_function(void *priv) {
+AVCodecContext *avctx = priv;
+SliceThreadContext *c = avctx->internal->thread_ctx;
+c->m_func(avctx);
+}
+
static void worker_func(void *priv, int jobnr, int threadnr, int nb_jobs, int
nb_threads)
{
AVCodecContext *avctx = priv;
@@ -99,7 +107,8 @@ static int thread_execute(AVCodecContext *avctx,
action_func* func, void *arg, i
c->func = func;
c->rets = ret;
-avpriv_slicethread_execute(c->thread, job_count, 0);
+avpriv_slicethread_execute(c->thread, job_count, !!c->m_func);
+
return 0;
}
@@ -110,10 +119,20 @@ static int thread_execute2(AVCodecContext *avctx,
action_func2* func2, void *arg
return thread_execute(avctx, NULL, arg, ret, job_count, 0);
}
+static int thread_execute3(AVCodecContext *avctx, action_func2* func2,
main_func* m_func, void *arg, int *ret, int job_count)
+{
+SliceThreadContext *c = avctx->internal->thread_ctx;
+c->func2 = func2;
+c->m_func = m_func;
+return thread_execute(avctx, NULL, arg, ret, job_count, 0);
+}
+
+
int ff_slice_thread_init(AVCodecContext *avctx)
{
SliceThreadContext *c;
int thread_count = avctx->thread_count;
+static void (*m_f)(void *);
#if HAVE_W32THREADS
w32thread_init();
@@ -142,7 +161,9 @@ int ff_slice_thread_init(AVCodecContext *avctx)
}
avctx->internal->thread_ctx = c = av_mallocz(sizeof(*c));
-if (!c || (thread_count = avpriv_slicethread_create(&c->thread, avctx,
worker_func, NULL, thread_count)) <= 1) {
+m_f = avctx->codec->capabilities & AV_CODEC_SLICE_THREAD_HAS_MF ?
&main_function : NULL;
+
+if (!c || (thread_count = avpriv_slicethread_create(&c->thread, avctx,
worker_func, m_f, thread_count)) <= 1) {
if (c)
avpriv_slicethread_
Re: [FFmpeg-devel] [PATCH] libswscale/swscale_unscaled: fix DITHER_COPY macro
On Wed, Sep 06, 2017 at 01:25:45AM +0200, Mateusz wrote:
> W dniu 2017-09-05 o 23:37, Michael Niedermayer pisze:
> > On Tue, Sep 05, 2017 at 04:42:06PM +0200, Mateusz wrote:
> >> W dniu 2017-09-05 o 15:40, Michael Niedermayer pisze:
> >>> On Mon, Sep 04, 2017 at 09:33:34AM +0200, Mateusz wrote:
> If ffmpeg reduces bit-depth to 8-bit or more, it uses DITHER_COPY macro.
> The problem is DITHER_COPY macro make images darker (on all planes).
>
> In x265 project there is issue #365 which is caused by this DITHER_COPY
> bug.
> I think it is time to fix -- there are more and more high bit-depth
> sources.
>
> Please review.
>
> libswscale/swscale_unscaled.c | 44
> +--
> 1 file changed, 13 insertions(+), 31 deletions(-)
> >>>
> >>> please provide a git compatible patch with with commit message as produced
> >>> by git format-patch or git send-email
> >>>
> >>> this mail is not accepted as is by git
> >>> Applying: libswscale/swscale_unscaled: fix DITHER_COPY macro
> >>> error: corrupt patch at line 6
> >>> error: could not build fake ancestor
> >>> Patch failed at 0001 libswscale/swscale_unscaled: fix DITHER_COPY macro
> >>>
> >>> [...]
> >>
> >> I've attached the result of git format-patch command.
> >>
> >> Sorry for 1 private e-mail (I clicked wrong button).
> >>
> >> Mateusz
> >
> >> swscale_unscaled.c | 44 +---
> >> 1 file changed, 13 insertions(+), 31 deletions(-)
> >> 9973b13b3f74319abe9c97302ee87b2b3468b3b6
> >> 0001-fix-DITHER_COPY-macro-to-avoid-make-images-darker.patch
> >> From 9b96d612fef46ccec7e148cd7f8e8666b4e7a4cd Mon Sep 17 00:00:00 2001
> >> From: Mateusz
> >> Date: Tue, 5 Sep 2017 16:09:28 +0200
> >> Subject: [PATCH] fix DITHER_COPY macro to avoid make images darker
> >>
> >> ---
> >> libswscale/swscale_unscaled.c | 44
> >> +--
> >> 1 file changed, 13 insertions(+), 31 deletions(-)
> >>
> >> diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
> >> index ef36aec..3b7a5a9 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,22 +1484,22 @@ 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];\
> >> +unsigned shift= src_depth-dst_depth, tmp;\
> >> for (i = 0; i < height; i++) {\
> >> -const uint8_t *dither= dithers[src_depth-9][i&7];\
> >> +const uint8_t *dither= dithers[shift-1][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]
Re: [FFmpeg-devel] [PATCH] avformat/aacdec: don't immediately abort if an ADTS frame is not found
On 9/5/2017 8:47 PM, Hendrik Leppkes wrote:
> On Wed, Sep 6, 2017 at 12:32 AM, James Almer wrote:
>> On 9/5/2017 7:12 PM, Hendrik Leppkes wrote:
>>> On Tue, Sep 5, 2017 at 11:20 PM, James Almer wrote:
On 9/5/2017 5:30 PM, Hendrik Leppkes wrote:
> On Mon, Sep 4, 2017 at 4:47 AM, James Almer wrote:
>> Skip the invalid data in an attempt to find one instead, and continue
>> decoding from there.
>>
>> Fixes ticket #6634
>>
>> Signed-off-by: James Almer
>> ---
>> libavformat/aacdec.c | 41 +
>> 1 file changed, 29 insertions(+), 12 deletions(-)
>>
>> diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
>> index 364b33404f..7aacc88560 100644
>> --- a/libavformat/aacdec.c
>> +++ b/libavformat/aacdec.c
>> @@ -77,10 +77,29 @@ static int adts_aac_probe(AVProbeData *p)
>> return 0;
>> }
>>
>> +static int resync(AVFormatContext *s)
>> +{
>> +uint16_t state;
>> +
>> +state = avio_r8(s->pb);
>> +while (!avio_feof(s->pb) && avio_tell(s->pb) < s->probesize) {
>> +state = (state << 8) | avio_r8(s->pb);
>> +if ((state >> 4) != 0xFFF)
>> +continue;
>> +avio_seek(s->pb, -2, SEEK_CUR);
>> +break;
>> +}
>> +
>
> The ADTS sync code isn't that much of a sync code, maybe it might be
> more resilient if you try to read the frame size and check if after
> that the next frame also starts with a valid code?
That will only let me know if at the end of the frame is another frame,
and not if the frame I'm reading is complete or not.
Maybe it's complete and right after it there's an id3v1 tag. Maybe it's
complete and right after it there's garbage. Maybe it's incomplete
because another ADTS frame started suddenly in the middle of the one i
tried to read because the source is some weird stream (sample in the
ticket this fixes), and after reading the reported size of the intended
frame the demuxer will find itself in the middle of the new one but
unable to know that's the case.
Really, at the demuxer level i can't do much more than read an ADTS
header, make sure it's at least seven bytes long and that the reported
size of the entire frame is bigger than the header size, then make a
packet out of that. The decoder/parser will handle things from there,
knowing that at very least for the first few bytes what reaches them is
an ADTS frame.
>>>
>>> We're not talking about validating the ADTS frame, but just making
>>> sure you really "resync" to the start of a frame, and not some
>>> arbitrary random position that just happens to be 0xFFF, because that
>>> code isn't very long or very special.
>>
>> Again, what if there's no new ADTS frame after the supposed end of the
>> one we're reading? How do we interpret that? That the one we read was
>> wrong or that it was right and there simply is no new ADTS frame right
>> after it? How does that help us decide if we propagate it or not?
>>
>> If anything, i could maybe use avpriv_aac_parse_header(). Barely more
>> resilient than just looking for a sync code and the size field being >
>> 7, but it's something i guess.
>
> If there is no two consecutive ADTS frames to be found, just stop sending
> data.
We're doing exactly that right now. The point of this patch is to not do
it any longer.
> I don't see the problem.
This patch loses its meaning. I have the feeling you're not getting what
I'm trying to do here.
The sample this fixes has several ADTS frames cut at the middle where
another was injected (Seems to be a raw stream dump). At the reported
end of the cut frame there isn't a new sync header, there's data from
the middle of the new unexpected frame. By stopping there, we're barely
decoding 2 seconds of audio, when there's about 19 that can get decoded
if we instead move forward trying to find the start of a new frame.
Before the commit that put us in our current situation the demuxer would
just send everything and let the parser combine data into hopefully
valid frames. This resulted in things that weren't audio frames being
propagated, like id3v1 or APE tags, or just garbage.
We use this kind of resync in all sorts of
> demuxers, because a 12-bit magic number that happens to be all 1's
> isn't all that safe from being aliased in other data.
I'll send an updated patch to do a couple extra checks.
>
> - Hendrik
> ___
> 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] [PATCHv6 2/2] avcodec/vp9: Add tile threading support
Hi, On Tue, Sep 5, 2017 at 7:59 PM, Ilia Valiakhmetov wrote: > Signed-off-by: Ilia Valiakhmetov > > v6 with changes from Ronald(BBB): > --- > libavcodec/vp9.c | 664 ++ > - > libavcodec/vp9_mc_template.c | 202 ++--- > libavcodec/vp9block.c| 522 -- > libavcodec/vp9dec.h | 103 --- > libavcodec/vp9mvs.c | 97 --- > libavcodec/vp9prob.c | 64 ++--- > libavcodec/vp9recon.c| 153 +- > 7 files changed, 1050 insertions(+), 755 deletions(-) I don't have any further comments, all my comments were addressed in this patch (make cross-thread signaling functions static, some fixed to prevent a race condition, some memory usage reductions). I've tested a fair bit and I don't think there's any speed/memory regressions with frame threading (or w/o threading), and the new tile threading seems stable and race-free. I'll leave this out for review for other people if anyone wants, and if there's no other responses by tomorrow, I'll push it. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/snowdec: Check intra block dc differences.
On Tue, Sep 05, 2017 at 07:53:49PM -0400, Ronald S. Bultje wrote: > Hi, > > On Tue, Sep 5, 2017 at 7:47 PM, Michael Niedermayer > wrote: > > > ff_dlog() is not part of a user build so a users bug report will not > > contain it at any verbose / debug level. > > > > That is intentional. The messages are not meant for end users, since they > are not helpful or informative for them. I think the only point we agree on is that we disagree. > > Bug reports always ask for files, and therefore it will be trivial for us > as experienced developers to reproduce the bugs (which we do anyway) with a > debug build and -v debug to get the appropriate level of technical > verbosity that results in information appropriate for developers while > debugging such issues. thanks for volunteering [...] -- 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] avcodec/snowdec: Check intra block dc differences.
On 9/5/2017 5:38 AM, wm4 wrote: > On Tue, 5 Sep 2017 10:03:11 +0200 > Clément Bœsch wrote: > >> On Mon, Sep 04, 2017 at 08:35:17PM +0200, wm4 wrote: >> [...] >> Can't we just remove this codec? It has no use other than causing >> potential security issues and maintenance. > > I agree about removing the encoder, but the decoder is needed for > existing streams. Unless everyone just argues it has no real world > samples for being an avcodec-only toy codec. > > If you send a patch removing the encoder without also trying to remove > all the things that currently depend on it (One or two filters i think) > then I'll +1 it. ffv1 and mpeg4 encoders are enough for any kind of > testing, fate or otherwise, that might require a native encoder. I find it a bit offensive that people suggest to remove the encoder i maintain. >>> >>> Can I add my own unused fringe codec with no users, as long as I >>> maintain it? >> >> Is there any reason to be so obsessed with snow? There are plenty of other >> "fringe" codecs in the codebase that only one person in the world cared >> about 10 years ago. Snow is one of the rare wavelet codecs, and as a >> result is much more valuable than many random basic game flavored codecs. >> And somehow, no one ever mention those. > > Those game codecs have actually some use. There are files in the wild > that are available to many, and that aren't just demo/test files. But > it's true that all these game codecs bloat the codebase, cause > maintenance and security issues, and have little use. They barely have > a justification to exist too. Don't be one of those that go "h264/aac/mov is all ffmpeg should care about". > > The only argument for snow is that it's a nice ideas. It might serve as > some proof of concept. As a real codec, it appears to be unusable. > >> I don't personally care about game codecs or snow myself (probably nobody >> does), but I don't support this snow/swscale/whatever-michael-did killing >> circle jerk. This really feels like some form of constant harassment (I'm >> not even talking about IRC), and that's not acceptable. > > Well, michael could just cut back on trying to force insane stuff. His > obstinate attitude to force ridiculous patches and defending them like > they're the only choice doesn't help. Even when we try to remove some > of his sins, he'll defend it to death, no matter how crazy and stupid > the code was (side data merging comes to mind). Seeing that stuff is effectively deprecated, i don't think he defended it to death. Everyone argued it was a pointless feature, and he ultimately conceded. > > If you feel like what I'm doing is harassment, I can end my involvement > with michael to avoid this - but only if you stop him from doing bad > things. You're very critical of all his patches. In many cases you give a detailed technical explanation of why you disagree, but most times you just make a snarky comment or are otherwise kinda rude. Even when you were proven wrong (the runtime cpu flag stuff) you answer was "Then go and rewrite the entire dsp initialization infrastructure". What made you think that was a good reply? If anything, that's what whoever is trying to introduce the faulty behavior should do, not him that reported why it's faulty. I tried to find a common ground regarding the error messages in this thread an the other and almost got it. But then i fucked up by agreeing with you about removing snowenc which started this stupid branch of the discussion. So please, like Clement said, chill out. We gain nothing with all this and lose plenty. > >> Please people, chill out. I understand the frustration when someone >> doesn't understand something that feel obvious to "everyone" and keep >> insisting on it, but that doesn't mean you should enter in some form of >> obsession and vengeance about anything he did/does/will do. >> >> ...aaand here I am, back in the "Insane people defending Michael all the >> time" category. > > We don't really need more of that category. > ___ > 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] [V5 1/4] lavc/vaapi_encode: Change the slice/parameter buffers to dynamic alloc.
On 2017/8/28 20:28, Mark Thompson wrote:
> On 24/08/17 02:13, Jun Zhao wrote:
>> V5: - In h265_vaapi encoder, when setting slice number > max slice number
>> supported by driver, report error and return. Same as h264_vaapi.
>> - Clean the logic when setting first_slice_segment_in_pic_flags
>> V4: - Change the array malloc function.
>> - Clean the pointless condition check when free the memory.
>>
>> V3: - Making pic->slices be VAAPIEncodeSlice* instead of
>> VAAPIEncodeSlice**. - Fix resource (vaBuffer) lead when realloc
>> pic->param_buffers fail. - Adjust max_slices location in
>> VAAPIEncodeContext. - Re-work distributing the macro-blocks for
>> multi-slices function. V2: - Change the slice/parameter buffers to
>> dynamic alloc and split the mutil-slice support for AVC/HEVC.
>>
>>
>> From a1078385915d53ec94559ed897eb253e537d1f65 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao
>> Date: Mon, 31 Jul 2017 22:46:23 -0400
>> Subject: [V5 1/4] lavc/vaapi_encode: Change the slice/parameter buffers to
>> dynamic alloc.
>>
>> Change the slice/parameter buffers to be allocated dynamically.
>>
>> Signed-off-by: Wang, Yi A
>> Signed-off-by: Jun Zhao
>> ---
>> libavcodec/vaapi_encode.c | 44
>> libavcodec/vaapi_encode.h | 6 ++
>> 2 files changed, 34 insertions(+), 16 deletions(-)
>>
>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>> index 22114bedbe..f49e0e3b91 100644
>> --- a/libavcodec/vaapi_encode.c
>> +++ b/libavcodec/vaapi_encode.c
>> @@ -36,13 +36,18 @@ static int
>> vaapi_encode_make_packed_header(AVCodecContext *avctx,
>> VAAPIEncodeContext *ctx = avctx->priv_data;
>> VAStatus vas;
>> VABufferID param_buffer, data_buffer;
>> +VABufferID *tmp;
>> VAEncPackedHeaderParameterBuffer params = {
>> .type = type,
>> .bit_length = bit_len,
>> .has_emulation_bytes = 1,
>> };
>>
>> -av_assert0(pic->nb_param_buffers + 2 <= MAX_PARAM_BUFFERS);
>> +tmp = av_realloc_array(pic->param_buffers, sizeof(*tmp),
>> pic->nb_param_buffers + 2);
>> +if (!tmp) {
>> +return AVERROR(ENOMEM);
>> +}
>> +pic->param_buffers = tmp;
>>
>> vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
>> VAEncPackedHeaderParameterBufferType,
>> @@ -77,9 +82,14 @@ static int vaapi_encode_make_param_buffer(AVCodecContext
>> *avctx,
>> {
>> VAAPIEncodeContext *ctx = avctx->priv_data;
>> VAStatus vas;
>> +VABufferID *tmp;
>> VABufferID buffer;
>>
>> -av_assert0(pic->nb_param_buffers + 1 <= MAX_PARAM_BUFFERS);
>> +tmp = av_realloc_array(pic->param_buffers, sizeof(*tmp),
>> pic->nb_param_buffers + 1);
>> +if (!tmp) {
>> +return AVERROR(ENOMEM);
>> +}
>> +pic->param_buffers = tmp;
>>
>> vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
>> type, len, 1, data, &buffer);
>> @@ -313,15 +323,14 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
>> }
>> }
>>
>> -av_assert0(pic->nb_slices <= MAX_PICTURE_SLICES);
>> +pic->slices = av_mallocz_array(pic->nb_slices, sizeof(*pic->slices));
>> +if (!pic->slices) {
>> +err = AVERROR(ENOMEM);
>> +goto fail;
>> +}
>> for (i = 0; i < pic->nb_slices; i++) {
>> -slice = av_mallocz(sizeof(*slice));
>> -if (!slice) {
>> -err = AVERROR(ENOMEM);
>> -goto fail;
>> -}
>> +slice = &pic->slices[i];
>> slice->index = i;
>> -pic->slices[i] = slice;
>>
>> if (ctx->codec->slice_params_size > 0) {
>> slice->codec_slice_params =
>> av_mallocz(ctx->codec->slice_params_size);
>> @@ -425,8 +434,16 @@ fail_with_picture:
>> fail:
>> for(i = 0; i < pic->nb_param_buffers; i++)
>> vaDestroyBuffer(ctx->hwctx->display, pic->param_buffers[i]);
>> +for (i = 0; i < pic->nb_slices; i++) {
>> +if (pic->slices) {
>> +av_freep(&pic->slices[i].priv_data);
>> +av_freep(&pic->slices[i].codec_slice_params);
>> +}
>> +}
>> fail_at_end:
>> av_freep(&pic->codec_picture_params);
>> +av_freep(&pic->param_buffers);
>> +av_freep(&pic->slices);
>> av_frame_free(&pic->recon_image);
>> av_buffer_unref(&pic->output_buffer_ref);
>> pic->output_buffer = VA_INVALID_ID;
>> @@ -535,15 +552,18 @@ static int vaapi_encode_free(AVCodecContext *avctx,
>> vaapi_encode_discard(avctx, pic);
>>
>> for (i = 0; i < pic->nb_slices; i++) {
>> -av_freep(&pic->slices[i]->priv_data);
>> -av_freep(&pic->slices[i]->codec_slice_params);
>> -av_freep(&pic->slices[i]);
>> +if (pic->slices) {
>> +av_freep(&pic->slices[i].priv_data);
>> +av_freep(&pic->slices[i].codec_slice_params);
>> +}
>> }
>> av_freep(&pic->codec_picture_params);
>>
>> av_frame_free(&pi
[FFmpeg-devel] [PATCH] lavc/vaapi_encode_mpeg2: fix frame rate calc error when use, time_base.
From a6f3aaa9c1ff6d35d19eef587a49c04916fceca1 Mon Sep 17 00:00:00 2001 From: Jun Zhao Date: Tue, 5 Sep 2017 23:07:15 -0400 Subject: [PATCH] lavc/vaapi_encode_mpeg2: fix frame rate calc error when use time_base. fix frame rate calc error when use time_base. Signed-off-by: Yun Zhou Signed-off-by: Jun Zhao --- libavcodec/vaapi_encode_mpeg2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/vaapi_encode_mpeg2.c b/libavcodec/vaapi_encode_mpeg2.c index fbddfa5d5a..dc918884e8 100644 --- a/libavcodec/vaapi_encode_mpeg2.c +++ b/libavcodec/vaapi_encode_mpeg2.c @@ -208,7 +208,7 @@ static int vaapi_encode_mpeg2_init_sequence_params(AVCodecContext *avctx) if (avctx->framerate.num > 0 && avctx->framerate.den > 0) vseq->frame_rate = (float)avctx->framerate.num / avctx->framerate.den; else -vseq->frame_rate = (float)avctx->time_base.num / avctx->time_base.den; +vseq->frame_rate = (float)avctx->time_base.den / avctx->time_base.num; vseq->aspect_ratio_information = 1; vseq->vbv_buffer_size = avctx->rc_buffer_size / (16 * 1024); -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 1/2] avcodec: add execute3() api to utilize the main function of avpriv_slicethread_create().
On 9/5/2017 8:57 PM, Ilia Valiakhmetov wrote:
> Signed-off-by: Ilia Valiakhmetov
> ---
> libavcodec/avcodec.h | 7 ++-
> libavcodec/options.c | 1 +
> libavcodec/pthread_slice.c | 26 --
> libavcodec/utils.c | 14 ++
> 4 files changed, 45 insertions(+), 3 deletions(-)
Missing APIChanges entry and version bump for the new API.
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 650..712f40c 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1089,6 +1089,10 @@ typedef struct RcOverride{
> */
> #define AV_CODEC_CAP_AVOID_PROBING (1 << 17)
> /**
> + * Codec initializes slice-based threading with a main function
> + */
> +#define AV_CODEC_SLICE_THREAD_HAS_MF (1 << 18)
Prefix should be AV_CODEC_CAP_ like other flags.
Does this need to be a public capability flag, for that matter? Maybe it
could be instead an internal FF_CODEC_CAP_ one.
See AVCodec->caps_internal.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] avformat/aacdec: don't immediately abort if an ADTS frame is not found
Instead, skip the invalid data in an attempt to find an ADTS frame, and
continue decoding from there.
Fixes ticket #6634
Signed-off-by: James Almer
---
New in v2:
- avpriv_aac_parse_header() used to validate ADTS headers more thoroughly.
- Removed the usage of avio_tell(s->pb) in resync() and replaced it with a
local counter.
libavformat/aacdec.c | 77 +++-
1 file changed, 58 insertions(+), 19 deletions(-)
diff --git a/libavformat/aacdec.c b/libavformat/aacdec.c
index 364b33404f..e744a9f40d 100644
--- a/libavformat/aacdec.c
+++ b/libavformat/aacdec.c
@@ -21,6 +21,7 @@
*/
#include "libavutil/intreadwrite.h"
+#include "libavcodec/aacadtsdec.h"
#include "avformat.h"
#include "internal.h"
#include "id3v1.h"
@@ -77,10 +78,52 @@ static int adts_aac_probe(AVProbeData *p)
return 0;
}
+static int resync(AVFormatContext *s)
+{
+AACADTSHeaderInfo hdr;
+GetBitContext gbc;
+uint8_t buf[AAC_ADTS_HEADER_SIZE];
+uint16_t state;
+int64_t cnt = 1;
+
+state = avio_r8(s->pb);
+while (!avio_feof(s->pb) && cnt++ < s->probesize) {
+int fsize, ret;
+
+state = ((state << 8) | avio_r8(s->pb));
+if ((state >> 4) != 0xFFF)
+continue;
+
+avio_seek(s->pb, -2, SEEK_CUR);
+ret = avio_read(s->pb, buf, sizeof(buf));
+if (ret < 0)
+return ret;
+if (ret < AAC_ADTS_HEADER_SIZE)
+return AVERROR(EIO);
+
+init_get_bits8(&gbc, buf, sizeof(buf));
+fsize = avpriv_aac_parse_header(&gbc, &hdr);
+if (fsize < 0) {
+// not a valid frame. Seek back to the "state" offset and continue.
+avio_seek(s->pb, -5, SEEK_CUR);
+continue;
+}
+
+// likely to be a valid frame. Seek back to the start and return.
+avio_seek(s->pb, -ret, SEEK_CUR);
+break;
+}
+
+if ((state >> 4) != 0xFFF)
+return avio_feof(s->pb) ? AVERROR_EOF : AVERROR_INVALIDDATA;
+
+return 0;
+}
+
static int adts_aac_read_header(AVFormatContext *s)
{
AVStream *st;
-uint16_t state;
+int ret;
st = avformat_new_stream(s, NULL);
if (!st)
@@ -99,16 +142,9 @@ static int adts_aac_read_header(AVFormatContext *s)
}
// skip data until the first ADTS frame is found
-state = avio_r8(s->pb);
-while (!avio_feof(s->pb) && avio_tell(s->pb) < s->probesize) {
-state = (state << 8) | avio_r8(s->pb);
-if ((state >> 4) != 0xFFF)
-continue;
-avio_seek(s->pb, -2, SEEK_CUR);
-break;
-}
-if ((state >> 4) != 0xFFF)
-return AVERROR_INVALIDDATA;
+ret = resync(s);
+if (ret < 0)
+return ret;
// LCM of all possible ADTS sample rates
avpriv_set_pts_info(st, 64, 1, 28224000);
@@ -118,6 +154,8 @@ static int adts_aac_read_header(AVFormatContext *s)
static int adts_aac_read_packet(AVFormatContext *s, AVPacket *pkt)
{
+AACADTSHeaderInfo hdr;
+GetBitContext gbc;
int ret, fsize;
ret = av_get_packet(s->pb, pkt, ADTS_HEADER_SIZE);
@@ -128,15 +166,16 @@ static int adts_aac_read_packet(AVFormatContext *s,
AVPacket *pkt)
return AVERROR(EIO);
}
-if ((AV_RB16(pkt->data) >> 4) != 0xfff) {
-av_packet_unref(pkt);
-return AVERROR_INVALIDDATA;
-}
-
-fsize = (AV_RB32(pkt->data + 3) >> 13) & 0x1FFF;
-if (fsize < ADTS_HEADER_SIZE) {
+init_get_bits8(&gbc, pkt->data, AAC_ADTS_HEADER_SIZE);
+fsize = avpriv_aac_parse_header(&gbc, &hdr);
+if (fsize < 0) {
+// skip data in an attempt to find an ADTS frame.
av_packet_unref(pkt);
-return AVERROR_INVALIDDATA;
+avio_seek(s->pb, -ret, SEEK_CUR);
+ret = resync(s);
+if (ret < 0)
+return ret;
+return adts_aac_read_packet(s, pkt);
}
return av_append_packet(s->pb, pkt, fsize - ADTS_HEADER_SIZE);
--
2.13.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Added configuration to override HTTP User-Agent
Thanks. Regards, Karthick ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] avformat/hlsenc: Fix target duration computation when 'round_durations' is enabled
Hi Steven, I am restarting this discussion, just to conclude this thread one way or the other. Maybe I am not thinking correctly. Here is detailed thinking, on why I think this patch will not violate HLS spec. >if (target_duration <= en->duration) >target_duration = (hls->flags & HLS_ROUND_DURATIONS) ? >lrint(en->duration) : get_int_from_double(en->duration); As per the above code, target duration will be maximum of all lrint(en->duration) when HLS_ROUND_DURATIONS is set. >if (hls->flags & HLS_ROUND_DURATIONS) >avio_printf(out, "#EXTINF:%ld,\n", lrint(en->duration)); >else >avio_printf(out, "#EXTINF:%f,\n", en->duration); As per this code #EXTINF duration will be lrint(en->duration) when HLS_ROUND_DURATIONS is set. >https://tools.ietf.org/html/draft-pantos-http-live-streaming-23#section-4.3.3.1 > >4.3.3.1. EXT-X-TARGETDURATION > > The EXT-X-TARGETDURATION tag specifies the maximum Media Segment > duration. The EXTINF duration of each Media Segment in the Playlist > file, when rounded to the nearest integer, MUST be less than or equal > to the target duration; longer segments can trigger playback stalls > or other errors. It applies to the entire Playlist file. Its format > is: > > #EXT-X-TARGETDURATION: > > where s is a decimal-integer indicating the target duration in > seconds. The EXT-X-TARGETDURATION tag is REQUIRED. As rightly pointed by you, spec says “The EXTINF duration of each Media Segment in the Playlist file, when rounded to the nearest integer, MUST be less than or equal to the target duration”. With this patch this is always true, and hence there is no violation of spec. Maybe I misunderstood and missing out something very obvious. Could you let me know the situation in which this code will generate target duration lesser than the EXTINF duration? Thanks for your help. Regards, Karthick ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
