Re: [FFmpeg-devel] [PATCH] avutil/frame: fix av_frame_copy for unknown layouts
On Mon, Jan 30, 2017 at 8:40 AM, wm4 wrote: > On Mon, 30 Jan 2017 01:37:02 +0100 > Marton Balint wrote: > >> I wonder how unknown layouts ever worked without this? >> >> Signed-off-by: Marton Balint >> --- >> libavutil/frame.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavutil/frame.c b/libavutil/frame.c >> index c2f5509..a08e0c5 100644 >> --- a/libavutil/frame.c >> +++ b/libavutil/frame.c >> @@ -725,7 +725,7 @@ int av_frame_copy(AVFrame *dst, const AVFrame *src) >> >> if (dst->width > 0 && dst->height > 0) >> return frame_copy_video(dst, src); >> -else if (dst->nb_samples > 0 && dst->channel_layout) >> +else if (dst->nb_samples > 0 && dst->channels > 0) >> return frame_copy_audio(dst, src); >> >> return AVERROR(EINVAL); > > The original code was written with the assumption that only channel > layouts exist in the AVFrame. And the Libav API follows that. This > patch will probably break Libav API users (or those who want to stay > compatible to them) some more. The copying code would have failed anyway if channels was 0 and not copied anything, so it doesn't break anything that worked before - except that it returns an error code now properly indicating the failure. In any case, we've decide quite a while ago to forego any illusions of API or ABI compatibility, because its impossible to guarantee it anyway. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: fix av_frame_copy for unknown layouts
On Mon, 30 Jan 2017 01:37:02 +0100 Marton Balint wrote: > I wonder how unknown layouts ever worked without this? > > Signed-off-by: Marton Balint > --- > libavutil/frame.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavutil/frame.c b/libavutil/frame.c > index c2f5509..a08e0c5 100644 > --- a/libavutil/frame.c > +++ b/libavutil/frame.c > @@ -725,7 +725,7 @@ int av_frame_copy(AVFrame *dst, const AVFrame *src) > > if (dst->width > 0 && dst->height > 0) > return frame_copy_video(dst, src); > -else if (dst->nb_samples > 0 && dst->channel_layout) > +else if (dst->nb_samples > 0 && dst->channels > 0) > return frame_copy_audio(dst, src); > > return AVERROR(EINVAL); The original code was written with the assumption that only channel layouts exist in the AVFrame. And the Libav API follows that. This patch will probably break Libav API users (or those who want to stay compatible to them) some more. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Passing Data from AVFrame to AVPacket
On Sun, 29 Jan 2017 22:24:12 + (UTC) wrote: > Hello devs, > > I have a quick question about passing data from AVFrame to AVPacket. Assume > that we are encoding video and we have a custom metadata that needs to be > handled in a frame accurate manner. The AVFrame can refer to this using the > opaque pointer. However, due to the nature of video coding, the video packet > that we get back when we encode video is not the frame that we have just > pushed to a codec. In this case the packet and the AVFrame gets decoupled. > > What is the best practice to have a reliable flow of metadata from AVFrame to > AVPacket? > Cheers, Generally, side-data. Which needs to be part of the API. (There is no way to add user-defined side-data, unfortunately.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
On Sun, 29 Jan 2017 19:43:04 +0100 Nicolas George wrote: > Le decadi 10 pluviôse, an CCXXV, Michael Niedermayer a écrit : > > also we need a maintainer for the libavfilter core or a area covering > > avfilter.c and that person should then make a decission. > > I have more or less acted as the de-facto maintainer of all that has to > do with scheduling in the lavfi framework. I can take over the rest of > the work (that would have required, for example, giving more attention > to the frame pool patches) if people want. I intended to propose when my > work of overhauling the design would have been finished. > > I will not propose it officially myself right now, especially not as a > patch for the MAINTAINERS file, as it would look like escalating the > game of core-wars. But if somebody else pushes a corresponding patch I > will not object at all. > > > But id like to ask everyone to NOT escalate this further, iam > > sure that nothing good would come out of that. > > I fully agree. > > wm4 has threatened to push a patch that I have explicitly and > unambiguously rejected. Furthermore, Muhammad, the original author of > this patch, has approved an alternate solution for fixing the same > issue. > > Under these circumstances, pushing the patch would be a deliberate act > of escalation. Well, in the quoted paragraph below you write that you will probably push the discussed patch yourself. So for that reason and for the sake of deescalation, I won't push it. I'll probably bring the patch up in a few weeks or so to avoid that the patch gets lost. (Because it's a good change, even if somewhat minor and not really worth all this stupid drama.) > Note: I rejected the patch based on the main change it advertises, the > change in the function interface. The patch also contains changes making > the implementation simpler. These change are very worthy. If Muhammad > proposes them separately I will gladly approve and apply; and if not I > will eventually do it myself. So you agree with the patch, except you didn't say that, and instead publicly rejected it? There is no logic in this. I can only assume that you want ff_inlink_make_frame_writable to retain its current signature. I'd argue against that, but I'm not getting the chance to. > >as i do > > not want to take a side > > When witnessing a bullying situation, not taking a side amounts to > siding with the bully. I will leave the readers decide for themselves if > and how that statement applies to the current situation. You are the "bully" - I've witnessed it countless of times. > As for myself, I do not wish to have any further interactions at all > with wm4. Starting now, as far as I am concerned, for all intents and > purposes, they and their messages no longer exist. I will reconsider my > position if I learn they can go for a year without badmouthing the > project or mocking or disparaging any of its contributors. It doesn't work this way. This is an open source project. If you wish for me not to exist, you can either murder me (please don't), or start working on another project. If you want to stay, I promise I will try to avoid being insulting (if you're nice to me as well). If you push more patches while ignoring my reviews (which you already did once), then there's a problem. As you've put it so nicely, pushing patches under those circumstances would be deliberate acts of escalation. > Of course, that means that all their proposals on areas of code for > which I am responsible are silently rejected. If somebody else sponsors > such a change, I will discuss it as if it were their own with all the > good-will that I am capable of. I know you want to portray yourself as victim, but I'm sorry, with such clear-cut words under thinly veiled hostility and a barely working pretense of trying to appear reasonable, it just doesn't work. With that stance, you becoming the maintainer of anything in FFmpeg is clearly unacceptable. Hell, even your reviews could not be trusted at all, since you just reject patches because you're playing some shitty troll game, instead of staying technical. "Silent rejection" doesn't exist. It doesn't work that way - you can't make others to further your little war with me, just so you can pretend I don't exist. > If another member of the project considers this stance unacceptable, you > can take your responsibilities and kick me out. Well, one already did (see the other reply to this mail). I'm also a project member and find this unacceptable, but I know you won't count me for some reason. > For reference, I started the day in good spirits at the prospect of > having several unencumbered hours to work on framesync. Instead, I have > been so upset and disgusted by how this turned out that I was unable to > produce a single line of valuable code, be it for FFmpeg or my own > projects. And if you think that this is a paltry issue to be upset, > rememb
Re: [FFmpeg-devel] [PATCH] avutil/frame: fix av_frame_copy for unknown layouts
On Mon, Jan 30, 2017 at 1:37 AM, Marton Balint wrote: > I wonder how unknown layouts ever worked without this? > > Signed-off-by: Marton Balint > --- > libavutil/frame.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavutil/frame.c b/libavutil/frame.c > index c2f5509..a08e0c5 100644 > --- a/libavutil/frame.c > +++ b/libavutil/frame.c > @@ -725,7 +725,7 @@ int av_frame_copy(AVFrame *dst, const AVFrame *src) > > if (dst->width > 0 && dst->height > 0) > return frame_copy_video(dst, src); > -else if (dst->nb_samples > 0 && dst->channel_layout) > +else if (dst->nb_samples > 0 && dst->channels > 0) > return frame_copy_audio(dst, src); > > return AVERROR(EINVAL); > -- > 2.10.2 Looks good, the copy routine uses dst->channels for copying, not channel_layout, so that should also be whats checked. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/frame: fix av_frame_copy for unknown layouts
Le primidi 11 pluviôse, an CCXXV, Marton Balint a écrit : > I wonder how unknown layouts ever worked without this? > > Signed-off-by: Marton Balint > --- > libavutil/frame.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM, but I do not maintain that file. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
On Mon, 30 Jan 2017 01:09:27 +0100 (CET)
Marton Balint wrote:
> On Sat, 28 Jan 2017, Nicolas George wrote:
>
> > Le nonidi 9 pluviôse, an CCXXV, Muhammad Faiz a écrit :
> >> so the behavior will be similar to
> >> av_frame_make_writable().
> >
> > The point was to move away from that. Who copies a struct when you can
> > move a pointer?
> >
>
> By the way, why av_frame_make_writable copies the struct?
>
> As far as I see it can be implemented just like this:
>
> int av_frame_make_writable(AVFrame *frame)
> {
> int ret;
> int i;
>
> if (!frame->buf[0])
> return AVERROR(EINVAL);
>
> for (i = 0; i < FF_ARRAY_ELEMS(frame->buf); i++) {
> if (frame->buf[i]) {
> ret = av_buffer_make_writable(&frame->buf[i]);
> if (ret < 0)
> return ret;
> frame->data[i] = frame->buf[i]->data;
> }
> }
> for (i = 0; i < frame->nb_extended_buf; i++) {
> ret = av_buffer_make_writable(&frame->extended_buf[i]);
> if (ret < 0)
> return ret;
> frame->extended_data[i] = frame->extended_buf[i]->data;
> }
>
> return 0;
> }
>
> It even passes fate. What do I miss?
>
> Don't get me wrong, I know that this approach cannot be implemented
> directly into the filtering case, because of the custom get buffer
> callback and the frame pool, but for the generic frame function, is there
> any downside doing this?
data[i] doesn't have to point to the start of buf[i]. Also multiple
planes can be in the same buffer. I guess the function is implemented
this way because that's the simplest.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Implement optimal huffman encoding for (M)JPEG.
Hey everyone,
Sorry for the long wait, here's a new patch addressing the feedback. In
addition, we discovered that this current implementation of optimal huffman
encoding is not compatible with QP RD, so we chose to disable QP RD for
mjpeg or amv encoding. (Wondering if that's acceptable, since it appears
like QP RD is an underused feature.)
> You forgot to readjust the range on the huffman option, it should be 0, 1,
> not 1, 2.
Fixed.
> Couldn't the linked list be replaced with an array allocated during init (it
> should be okay, I don't think resolution is allowed to change during
> encoding)?
Done.
> missing \n before opening brace in functions
Done.
> use of ++var instead of var++. this is not a c++ project.
No more ++s anymore.
> use of sizeof(x)/sizeof(*x) instead of FF_ARRAY_ELEMS
No more of that either.
> a few "MJpegBuffer* x" instead of "MJpegBuffer *x"
Done.
> missing vertical align with the "(" in various places such prototypes or
> your fprintf calls
Done.
> add a NB_HUFFMAN_TABLE_OPTION or something at the end, which you can use
> in the options to define the range from 0 to NB-1
> btw, wrong indent.
Done.
> Wouldn't AV_QSORT() work just the same if you did return a-b?
Done.
> no camel case in variable names please
Done.
> not a fan of that html; would you mind just keeping the url? "@see http://...";
Done.
> static const HuffTable?
Done.
> i < FF_ARRAY_ELEMS(distincts)
Done.
> static const int
Done.
> ditto static const.
Done.
> wrong indent.
Done.
---
Changelog| 1 +
doc/encoders.texi| 21 ++
libavcodec/Makefile | 8 +-
libavcodec/mjpegenc.c| 241 +--
libavcodec/mjpegenc.h| 68 ++-
libavcodec/mjpegenc_common.c | 166 ++--
libavcodec/mjpegenc_common.h | 2 +
libavcodec/mjpegenc_huffman.c| 195 ++
libavcodec/mjpegenc_huffman.h| 73 +++
libavcodec/mpegvideo.h | 1 +
libavcodec/mpegvideo_enc.c | 17 +-
libavcodec/tests/.gitignore | 1 +
libavcodec/tests/mjpegenc_huffman.c | 162 +++
tests/fate/libavcodec.mak| 6 +
tests/fate/vcodec.mak| 14 +-
tests/ref/vsynth/vsynth1-mjpeg-444 | 8 +-
tests/ref/vsynth/vsynth1-mjpeg-huffman | 4 +
tests/ref/vsynth/vsynth1-mjpeg-trell-huffman | 4 +
tests/ref/vsynth/vsynth2-mjpeg-huffman | 4 +
tests/ref/vsynth/vsynth2-mjpeg-trell-huffman | 4 +
tests/ref/vsynth/vsynth3-mjpeg-huffman | 4 +
tests/ref/vsynth/vsynth3-mjpeg-trell-huffman | 4 +
tests/ref/vsynth/vsynth_lena-mjpeg-huffman | 4 +
tests/ref/vsynth/vsynth_lena-mjpeg-trell-huffman | 4 +
24 files changed, 916 insertions(+), 100 deletions(-)
create mode 100644 libavcodec/mjpegenc_huffman.c
create mode 100644 libavcodec/mjpegenc_huffman.h
create mode 100644 libavcodec/tests/mjpegenc_huffman.c
create mode 100644 tests/ref/vsynth/vsynth1-mjpeg-huffman
create mode 100644 tests/ref/vsynth/vsynth1-mjpeg-trell-huffman
create mode 100644 tests/ref/vsynth/vsynth2-mjpeg-huffman
create mode 100644 tests/ref/vsynth/vsynth2-mjpeg-trell-huffman
create mode 100644 tests/ref/vsynth/vsynth3-mjpeg-huffman
create mode 100644 tests/ref/vsynth/vsynth3-mjpeg-trell-huffman
create mode 100644 tests/ref/vsynth/vsynth_lena-mjpeg-huffman
create mode 100644 tests/ref/vsynth/vsynth_lena-mjpeg-trell-huffman
diff --git a/Changelog b/Changelog
index c256121..4d5daca 100644
--- a/Changelog
+++ b/Changelog
@@ -18,6 +18,7 @@ version :
- readeia608 filter
- Sample Dump eXchange demuxer
- abitscope multimedia filter
+- Optimal Huffman tables for (M)JPEG encoding
version 3.2:
- libopenmpt demuxer
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 8137465..2026a9f 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1200,6 +1200,27 @@ Same as @samp{3}, but with extra processing enabled.
@end table
@end table
+@anchor{mjpegenc}
+@section mjpeg
+
+Motion JPEG encoder.
+
+@subsection Options
+
+@table @option
+@item huffman
+Set the huffman encoding strategy. Possible values:
+
+@table @samp
+@item default
+Use the default huffman tables. This is the default strategy.
+
+@item optimal
+Compute and use optimal huffman tables.
+
+@end table
+@end table
+
@anchor{wavpackenc}
@section wavpack
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 43a6add..4765e9c 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -39,6 +39,7 @@ OBJS = allcodecs.o
\
mediacodec.o \
mpeg12framerate.o
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
On Sun, Jan 29, 2017 at 7:43 PM, Nicolas George wrote: > > As for myself, I do not wish to have any further interactions at all > with wm4. Starting now, as far as I am concerned, for all intents and > purposes, they and their messages no longer exist. I will reconsider my > position if I learn they can go for a year without badmouthing the > project or mocking or disparaging any of its contributors. > > Of course, that means that all their proposals on areas of code for > which I am responsible are silently rejected. If somebody else sponsors > such a change, I will discuss it as if it were their own with all the > good-will that I am capable of. > > If another member of the project considers this stance unacceptable, you > can take your responsibilities and kick me out. This stance is absolutely unacceptable. You don't get to reject patches or ignore feedback on some petty personal feud, or cherry-pick the feedback you want to honor and which to ignore or even dismiss. This behavior would go both against the code of conduct and our established patch review regulations. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/eval: add atan2 function
On Sun, Jan 29, 2017 at 01:53:22PM +0100, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > doc/utils.texi | 3 +++ > libavutil/eval.c | 4 +++- > 2 files changed, 6 insertions(+), 1 deletion(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] speedhq: make sure the block index is not negative
Fixes out-of-bounds writes. Signed-off-by: Andreas Cadhalpun --- libavcodec/speedhq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c index 385f779f83..6ae1e0f8df 100644 --- a/libavcodec/speedhq.c +++ b/libavcodec/speedhq.c @@ -198,7 +198,7 @@ static inline int decode_alpha_block(const SHQContext *s, GetBitContext *gb, uin if (run == 128) break; i += run; -if (i >= 128) +if (i < 0 || i >= 128) return AVERROR_INVALIDDATA; UPDATE_CACHE_LE(re, gb); -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
On 30 January 2017 at 00:09, Marton Balint wrote:
>
> On Sat, 28 Jan 2017, Nicolas George wrote:
>
> Le nonidi 9 pluviôse, an CCXXV, Muhammad Faiz a écrit :
>>
>>> so the behavior will be similar to
>>> av_frame_make_writable().
>>>
>>
>> The point was to move away from that. Who copies a struct when you can
>> move a pointer?
>>
>>
> By the way, why av_frame_make_writable copies the struct?
>
> As far as I see it can be implemented just like this:
>
> int av_frame_make_writable(AVFrame *frame)
> {
> int ret;
> int i;
>
> if (!frame->buf[0])
> return AVERROR(EINVAL);
>
> for (i = 0; i < FF_ARRAY_ELEMS(frame->buf); i++) {
> if (frame->buf[i]) {
> ret = av_buffer_make_writable(&frame->buf[i]);
> if (ret < 0)
> return ret;
> frame->data[i] = frame->buf[i]->data;
> }
> }
> for (i = 0; i < frame->nb_extended_buf; i++) {
> ret = av_buffer_make_writable(&frame->extended_buf[i]);
> if (ret < 0)
> return ret;
> frame->extended_data[i] = frame->extended_buf[i]->data;
> }
>
> return 0;
> }
>
> It even passes fate. What do I miss?
>
> Don't get me wrong, I know that this approach cannot be implemented
> directly into the filtering case, because of the custom get buffer callback
> and the frame pool, but for the generic frame function, is there any
> downside doing this?
>
> Thanks,
> Marton
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
The memory referenced by the AVFrame can be e.g. in hardware or used by
something else. It makes no sense to try to write to it, you'd just mess up
whatever else the user is using the data for.
So you allocate new buffers, make a copy of the data and unref the ref you
have.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] MAINTAINERS: Add myself for boadec.c
It seems ive written this thing though i cannot really remember Signed-off-by: Michael Niedermayer --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 981d71b195..80721e183d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -384,6 +384,7 @@ Muxers/Demuxers: avisynth.cStephen Hutchinson avr.c Paul B Mahol bink.cPeter Ross + boadec.c Michael Niedermayer brstm.c Paul B Mahol caf* Peter Ross cdxl.cPaul B Mahol -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 8/9] xvag: prevent overflow during block alignment calculation
On 29.01.2017 09:51, Paul B Mahol wrote: > On 1/29/17, Michael Niedermayer wrote: >> On Thu, Jan 26, 2017 at 02:13:48AM +0100, Andreas Cadhalpun wrote: >>> Signed-off-by: Andreas Cadhalpun >>> --- >>> libavformat/xvag.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> LGTM assuming the author/maintainer does not object > > ok Pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/9] genh: prevent overflow during block alignment calculation
On 29.01.2017 09:52, Paul B Mahol wrote: > On 1/29/17, Michael Niedermayer wrote: >> On Thu, Jan 26, 2017 at 02:11:54AM +0100, Andreas Cadhalpun wrote: >>> Signed-off-by: Andreas Cadhalpun >>> --- >>> libavformat/genh.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> LGTM assuming the author/maintainer does not object >> > > ok Pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 7/9] epafdec: prevent overflow during block alignment calculation
On 29.01.2017 09:51, Paul B Mahol wrote: > On 1/29/17, Michael Niedermayer wrote: >> On Thu, Jan 26, 2017 at 02:13:33AM +0100, Andreas Cadhalpun wrote: >>> Signed-off-by: Andreas Cadhalpun >>> --- >>> libavformat/epafdec.c | 3 ++- >>> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> LGTM assuming the author/maintainer does not object > > ok Pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/9] ircamdec: prevent overflow during block alignment calculation
On 29.01.2017 02:34, Michael Niedermayer wrote: > On Thu, Jan 26, 2017 at 02:12:19AM +0100, Andreas Cadhalpun wrote: >> Signed-off-by: Andreas Cadhalpun >> --- >> libavformat/ircamdec.c | 6 ++ >> 1 file changed, 6 insertions(+) > > LGTM assuming the author/maintainer does not object, maybe he > prefers this without the log message Attached is a variant without the log message. Best regards, Andreas >From bf03bedf16ee4659defdca1b82eb213448d00f59 Mon Sep 17 00:00:00 2001 From: Andreas Cadhalpun Date: Thu, 15 Dec 2016 02:14:45 +0100 Subject: [PATCH] ircamdec: prevent overflow during block alignment calculation Signed-off-by: Andreas Cadhalpun --- libavformat/ircamdec.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavformat/ircamdec.c b/libavformat/ircamdec.c index 59f3a49411..a6b7a280f3 100644 --- a/libavformat/ircamdec.c +++ b/libavformat/ircamdec.c @@ -20,6 +20,7 @@ */ #include "libavutil/intreadwrite.h" +#include "libavcodec/internal.h" #include "avformat.h" #include "internal.h" #include "pcm.h" @@ -87,6 +88,8 @@ static int ircam_read_header(AVFormatContext *s) st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO; st->codecpar->channels= channels; +if (st->codecpar->channels > FF_SANE_NB_CHANNELS) +return AVERROR(ENOSYS); st->codecpar->sample_rate = sample_rate; st->codecpar->codec_id = ff_codec_get_id(tags, tag); -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/9] nistspheredec: prevent overflow during block alignment calculation
On 29.01.2017 04:02, Marton Balint wrote:
>
> On Sun, 29 Jan 2017, Andreas Cadhalpun wrote:
>
>> On 28.01.2017 12:44, Marton Balint wrote:
>>> If we reduce the number of extra lines (not at any cost), I think that
>>> helps.
>>> There is also a solution which keeps the traditional C syntax, and is easy
>>> to undestand even at first glance.
>>>
>>> if (st->codecpar->channels > FF_SANE_NB_CHANNELS)
>>> return ff_elog(AVERROR(ENOSYS), s, "Too many channels %d > %d\n",
>>> st->codecpar->channels, FF_SANE_NB_CHANNELS);
>>
>> How would you define ff_elog for this to work?
>>
>
> static inline int ff_elog(int error, void *log_ctx, const char *fmt, ...) {
> if (!CONFIG_SMALL) {
> va_list vl;
> va_start(vl, fmt);
> av_vlog(log_ctx, AV_LOG_ERROR, fmt, vl);
> va_end(vl);
> }
> return error;
> }
OK. I'd be fine with using it, if people prefer this way.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avutil/frame: fix av_frame_copy for unknown layouts
I wonder how unknown layouts ever worked without this? Signed-off-by: Marton Balint --- libavutil/frame.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/frame.c b/libavutil/frame.c index c2f5509..a08e0c5 100644 --- a/libavutil/frame.c +++ b/libavutil/frame.c @@ -725,7 +725,7 @@ int av_frame_copy(AVFrame *dst, const AVFrame *src) if (dst->width > 0 && dst->height > 0) return frame_copy_video(dst, src); -else if (dst->nb_samples > 0 && dst->channel_layout) +else if (dst->nb_samples > 0 && dst->channels > 0) return frame_copy_audio(dst, src); return AVERROR(EINVAL); -- 2.10.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 9/9] boadec: prevent overflow during block alignment calculation
On 29.01.2017 04:46, Ronald S. Bultje wrote: > Hm ... So I guess I wasn't clear about this, but the reason I didn't reply > to other patches with log messages was not because I'm OK with, but simply > to keep the discussion contained in a single thread and not spam the list. > I'd prefer if the log msg disappeared from all fuzz-only checks... Being a "fuzz-only check" is not a well-defined concept. Anything a fuzzer does could in principle also happen due to file corruption. For header parsing such errors could also happen if a file gets misdetected and thus a wrong demuxer is used. So what do you mean with "fuzz-only check"? For example, would you consider the error check I quoted in the other thread [1] a "fuzz-only check"? It's clear that you prefer fewer log messages than I do, but in the absence of a general consensus about this topic, every author/maintainer can decide which log messages are wanted in their own code. Best regards, Andreas 1: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206312.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
On Sat, 28 Jan 2017, Nicolas George wrote:
Le nonidi 9 pluviôse, an CCXXV, Muhammad Faiz a écrit :
so the behavior will be similar to
av_frame_make_writable().
The point was to move away from that. Who copies a struct when you can
move a pointer?
By the way, why av_frame_make_writable copies the struct?
As far as I see it can be implemented just like this:
int av_frame_make_writable(AVFrame *frame)
{
int ret;
int i;
if (!frame->buf[0])
return AVERROR(EINVAL);
for (i = 0; i < FF_ARRAY_ELEMS(frame->buf); i++) {
if (frame->buf[i]) {
ret = av_buffer_make_writable(&frame->buf[i]);
if (ret < 0)
return ret;
frame->data[i] = frame->buf[i]->data;
}
}
for (i = 0; i < frame->nb_extended_buf; i++) {
ret = av_buffer_make_writable(&frame->extended_buf[i]);
if (ret < 0)
return ret;
frame->extended_data[i] = frame->extended_buf[i]->data;
}
return 0;
}
It even passes fate. What do I miss?
Don't get me wrong, I know that this approach cannot be implemented
directly into the filtering case, because of the custom get buffer
callback and the frame pool, but for the generic frame function, is there
any downside doing this?
Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Passing Data from AVFrame to AVPacket
Hello devs, I have a quick question about passing data from AVFrame to AVPacket. Assume that we are encoding video and we have a custom metadata that needs to be handled in a frame accurate manner. The AVFrame can refer to this using the opaque pointer. However, due to the nature of video coding, the video packet that we get back when we encode video is not the frame that we have just pushed to a codec. In this case the packet and the AVFrame gets decoupled. What is the best practice to have a reliable flow of metadata from AVFrame to AVPacket? Cheers, ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: hint next marker position in ff_mjpeg_find_marker
On Sat, Jan 28, 2017 at 10:40:18PM +0100, Michael Niedermayer wrote: > On Sat, Jan 28, 2017 at 01:59:10PM +0100, Matthieu Bouron wrote: > > On Sat, Jan 28, 2017 at 12:59:39PM +0100, Matthieu Bouron wrote: > > > On Sat, Jan 28, 2017 at 02:25:34AM +0100, Michael Niedermayer wrote: > > > > On Fri, Jan 27, 2017 at 09:47:18AM +0100, Matthieu Bouron wrote: > > > > > On Fri, Jan 27, 2017 at 02:30:40AM +0100, Michael Niedermayer wrote: > > > > > > On Thu, Jan 26, 2017 at 05:47:51PM +0100, Matthieu Bouron wrote: > > > > > > > Speeds up next marker search when a SOS marker is found. > > > > > > > > > > > > > > ff_mjpeg_find_marker goes from 54% to 30% under perf record > > > > > > > ffmpeg -i > > > > > > > sample_2992x4000.jpg > > > > > > > --- > > > > > > > libavcodec/mjpegdec.c | 31 +-- > > > > > > > libavcodec/mjpegdec.h | 2 +- > > > > > > > libavcodec/mxpegdec.c | 5 +++-- > > > > > > > 3 files changed, 29 insertions(+), 9 deletions(-) > > > > > > > > > > > > this breaks decoding multiple jpeg files > > > > > > for example tickets//856/nint.jpg > > > > > > > > > > New patch attached fixing the issue. > > > > > > > > > > [...] > > > > > > > > > mjpegdec.c | 31 +-- > > > > > mjpegdec.h |2 +- > > > > > mxpegdec.c |5 +++-- > > > > > 3 files changed, 29 insertions(+), 9 deletions(-) > > > > > 6ba49d73c189b197bdc1a983e26ccd49713c617c > > > > > 0001-lavc-mjpegdec-hint-next-marker-position-in-ff_mjpeg_.patch > > > > > From ebef63ebdc75872d52529d5b74b6d05254d4c0fd Mon Sep 17 00:00:00 2001 > > > > > From: Matthieu Bouron > > > > > Date: Thu, 26 Jan 2017 15:17:36 +0100 > > > > > Subject: [PATCH] lavc/mjpegdec: hint next marker position in > > > > > ff_mjpeg_find_marker > > > > > > > > > > Speeds up next marker search when a SOS marker is found. > > > > > > > > > > ff_mjpeg_find_marker goes from 54% to 30% under perf record ffmpeg -i > > > > > sample_2992x4000.jpg > > > > > > > > the patch seems to work but > > > > why is the "buf_ptr += (get_bits_count(&s->gb) + 7) / 8;" not > > > > already skiping all that what the buf_hint does ? > > > > is the difference the unescaping ? > > > > maybe the buf_hint stuff can be simplified by adjusting buf_ptr instead > > > > ? > > > > > > I've just realized that the SOS marker handling does not consume any byte > > > from the GetBitContext *only* when the frame is being discard (which > > > happens in avformat_find_stream_info). > > > > > > So I guess a better solution would be to consume all the bytes from the > > > GetBitContext while this marker is skipped and let the code already in > > > place handle that. > > > However, the buf_ptr won't directly be at the next marker position since > > > the sos data is unescaped. With the sample I use there is a difference of > > > 13774 bytes (thus iterations in find_marker) to find the next marker. It > > > reduces the function (according to perf) from 5,4% to 4.8% while the frame > > > is being decoded (ffmpeg -i sample_2999x4000.jpeg -f null -) but it seems > > > the performance gain is too little versus the code that the patch > > > introduces and the decoder will benefits more from having aarch64 simd > > > code for the various idct functions (something that i plan to do in the > > > upcoming days). > > you could keep track of the unescaped bytes ad add them too > > > > > > > > I'll send a new patch soon. > > > > Alternative patch attached. > > LGTM Pushed. Thanks. [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] swscale: add P016 input support
Signed-off-by: Philip Langdale
---
libswscale/input.c| 32
libswscale/swscale_unscaled.c | 4 +++-
libswscale/utils.c| 2 ++
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/libswscale/input.c b/libswscale/input.c
index 1f4ea18..8b5f348 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -719,6 +719,28 @@ static void p010BEToUV_c(uint8_t *dstU, uint8_t *dstV,
}
}
+static void p016LEToUV_c(uint8_t *dstU, uint8_t *dstV,
+ const uint8_t *unused0, const uint8_t *src1, const
uint8_t *src2,
+ int width, uint32_t *unused)
+{
+int i;
+for (i = 0; i < width; i++) {
+AV_WN16(dstU + i * 2, AV_RL16(src1 + i * 4 + 0));
+AV_WN16(dstV + i * 2, AV_RL16(src1 + i * 4 + 2));
+}
+}
+
+static void p016BEToUV_c(uint8_t *dstU, uint8_t *dstV,
+ const uint8_t *unused0, const uint8_t *src1, const
uint8_t *src2,
+ int width, uint32_t *unused)
+{
+int i;
+for (i = 0; i < width; i++) {
+AV_WN16(dstU + i * 2, AV_RB16(src1 + i * 4 + 0));
+AV_WN16(dstV + i * 2, AV_RB16(src1 + i * 4 + 2));
+}
+}
+
#define input_pixel(pos) (isBE(origin) ? AV_RB16(pos) : AV_RL16(pos))
static void bgr24ToY_c(uint8_t *_dst, const uint8_t *src, const uint8_t
*unused1, const uint8_t *unused2,
@@ -1085,6 +1107,12 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
case AV_PIX_FMT_P010BE:
c->chrToYV12 = p010BEToUV_c;
break;
+case AV_PIX_FMT_P016LE:
+c->chrToYV12 = p016LEToUV_c;
+break;
+case AV_PIX_FMT_P016BE:
+c->chrToYV12 = p016BEToUV_c;
+break;
}
if (c->chrSrcHSubSample) {
switch (srcFormat) {
@@ -1326,6 +1354,8 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
case AV_PIX_FMT_GRAY10LE:
case AV_PIX_FMT_GRAY12LE:
case AV_PIX_FMT_GRAY16LE:
+
+case AV_PIX_FMT_P016LE:
c->lumToYV12 = bswap16Y_c;
break;
case AV_PIX_FMT_YUVA444P9LE:
@@ -1362,6 +1392,8 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
case AV_PIX_FMT_GRAY10BE:
case AV_PIX_FMT_GRAY12BE:
case AV_PIX_FMT_GRAY16BE:
+
+case AV_PIX_FMT_P016BE:
c->lumToYV12 = bswap16Y_c;
break;
case AV_PIX_FMT_YUVA444P9BE:
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index b2bfc40..ba3d688 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -1878,8 +1878,10 @@ void ff_get_unscaled_swscale(SwsContext *c)
c->chrDstVSubSample == c->chrSrcVSubSample &&
dstFormat != AV_PIX_FMT_NV12 && dstFormat != AV_PIX_FMT_NV21 &&
dstFormat != AV_PIX_FMT_P010LE && dstFormat != AV_PIX_FMT_P010BE &&
+ dstFormat != AV_PIX_FMT_P016LE && dstFormat != AV_PIX_FMT_P016BE &&
srcFormat != AV_PIX_FMT_NV12 && srcFormat != AV_PIX_FMT_NV21 &&
- srcFormat != AV_PIX_FMT_P010LE && srcFormat != AV_PIX_FMT_P010BE))
+ srcFormat != AV_PIX_FMT_P010LE && srcFormat != AV_PIX_FMT_P010BE &&
+ srcFormat != AV_PIX_FMT_P016LE && srcFormat != AV_PIX_FMT_P016BE))
{
if (isPacked(c->srcFormat))
c->swscale = packedCopyWrapper;
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 60a8e55..caae63a 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -252,6 +252,8 @@ static const FormatEntry format_entries[AV_PIX_FMT_NB] = {
[AV_PIX_FMT_AYUV64LE]= { 1, 1},
[AV_PIX_FMT_P010LE] = { 1, 1 },
[AV_PIX_FMT_P010BE] = { 1, 1 },
+[AV_PIX_FMT_P016LE] = { 1, 0 },
+[AV_PIX_FMT_P016BE] = { 1, 0 },
};
int sws_isSupportedInput(enum AVPixelFormat pix_fmt)
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
Le decadi 10 pluviôse, an CCXXV, Michael Niedermayer a écrit : > also we need a maintainer for the libavfilter core or a area covering > avfilter.c and that person should then make a decission. I have more or less acted as the de-facto maintainer of all that has to do with scheduling in the lavfi framework. I can take over the rest of the work (that would have required, for example, giving more attention to the frame pool patches) if people want. I intended to propose when my work of overhauling the design would have been finished. I will not propose it officially myself right now, especially not as a patch for the MAINTAINERS file, as it would look like escalating the game of core-wars. But if somebody else pushes a corresponding patch I will not object at all. > But id like to ask everyone to NOT escalate this further, iam > sure that nothing good would come out of that. I fully agree. wm4 has threatened to push a patch that I have explicitly and unambiguously rejected. Furthermore, Muhammad, the original author of this patch, has approved an alternate solution for fixing the same issue. Under these circumstances, pushing the patch would be a deliberate act of escalation. Note: I rejected the patch based on the main change it advertises, the change in the function interface. The patch also contains changes making the implementation simpler. These change are very worthy. If Muhammad proposes them separately I will gladly approve and apply; and if not I will eventually do it myself. > as i do > not want to take a side When witnessing a bullying situation, not taking a side amounts to siding with the bully. I will leave the readers decide for themselves if and how that statement applies to the current situation. As for myself, I do not wish to have any further interactions at all with wm4. Starting now, as far as I am concerned, for all intents and purposes, they and their messages no longer exist. I will reconsider my position if I learn they can go for a year without badmouthing the project or mocking or disparaging any of its contributors. Of course, that means that all their proposals on areas of code for which I am responsible are silently rejected. If somebody else sponsors such a change, I will discuss it as if it were their own with all the good-will that I am capable of. If another member of the project considers this stance unacceptable, you can take your responsibilities and kick me out. For reference, I started the day in good spirits at the prospect of having several unencumbered hours to work on framesync. Instead, I have been so upset and disgusted by how this turned out that I was unable to produce a single line of valuable code, be it for FFmpeg or my own projects. And if you think that this is a paltry issue to be upset, remember that the straw that breaks the camel's back does not need to be heavy. That is all I have to say on the matter. If necessary, details would probably better be asked in private. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: make ff_framequeue_skip_samples() more useful.
Le decadi 10 pluviôse, an CCXXV, Muhammad Faiz a écrit : > LGTM Thanks, pushed. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] libavcodec/cinepak.c: fix a wrong (inverted) misleading comment
Attaching the new version. Regards, Rune >From f2041c0aaa5209e5d52649f741b6ee1dbc7e9021 Mon Sep 17 00:00:00 2001 From: Rl Date: Sun, 29 Jan 2017 18:28:25 +0100 Subject: [PATCH 3/3] libavcodec/cinepak.c: fix a wrong (inverted) misleading comment Make the comment message understandable and correct. --- libavcodec/cinepak.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c index 737462bd9c..d657e9c0c1 100644 --- a/libavcodec/cinepak.c +++ b/libavcodec/cinepak.c @@ -155,8 +155,8 @@ static int cinepak_decode_vectors (CinepakContext *s, cvid_strip *strip, } } } -/* to get the correct picture for not-multiple-of-4 cases let us fill - * each block from the bottom up, thus possibly overwriting the top line +/* to get the correct picture for not-multiple-of-4 cases let us fill each + * block from the bottom up, thus possibly overwriting the bottommost line * more than once but ending with the correct data in place * (instead of in-loop checking) */ -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] libavcodec/cinepakenc.c: comments style cleanup
Attaching the new version.
Regards,
Rune
>From e6719743b78862f897133d3f69a5e88a6a9a803e Mon Sep 17 00:00:00 2001
From: Rl
Date: Sun, 29 Jan 2017 18:14:19 +0100
Subject: [PATCH 2/3] libavcodec/cinepakenc.c: comments style cleanup
Avoid the present mixture of comment styles (C vs C++)
by converting to the traditional C style.
---
libavcodec/cinepakenc.c | 340 +++-
1 file changed, 192 insertions(+), 148 deletions(-)
diff --git a/libavcodec/cinepakenc.c b/libavcodec/cinepakenc.c
index a28f669070..8c27c2a1aa 100644
--- a/libavcodec/cinepakenc.c
+++ b/libavcodec/cinepakenc.c
@@ -80,22 +80,24 @@ OTHER DEALINGS IN THE SOFTWARE.
#define STRIP_HEADER_SIZE 12
#define CHUNK_HEADER_SIZE 4
-#define MB_SIZE 4 //4x4 MBs
+#define MB_SIZE 4 /* 4x4 MBs */
#define MB_AREA (MB_SIZE*MB_SIZE)
-#define VECTOR_MAX 6//six or four entries per vector depending on
format
-#define CODEBOOK_MAX 256//size of a codebook
+#define VECTOR_MAX 6/* six or four entries per vector depending on
format */
+#define CODEBOOK_MAX 256/* size of a codebook */
-#define MAX_STRIPS 32 //Note: having fewer choices regarding the number
of strips speeds up encoding (obviously)
-#define MIN_STRIPS 1 //Note: having more strips speeds up encoding the
frame (this is less obvious)
-// MAX_STRIPS limits the maximum quality you can reach
-//when you want high quality on high resolutions,
-// MIN_STRIPS limits the minimum efficiently encodable bit rate
-//on low resolutions
-// the numbers are only used for brute force optimization for the first frame,
-// for the following frames they are adaptively readjusted
-// NOTE the decoder in ffmpeg has its own arbitrary limitation on the number
-// of strips, currently 32
+#define MAX_STRIPS 32 /* Note: having fewer choices regarding the number
of strips speeds up encoding (obviously) */
+#define MIN_STRIPS 1 /* Note: having more strips speeds up encoding the
frame (this is less obvious) */
+/*
+ * MAX_STRIPS limits the maximum quality you can reach
+ *when you want high quality on high resolutions,
+ * MIN_STRIPS limits the minimum efficiently encodable bit rate
+ *on low resolutions
+ * the numbers are only used for brute force optimization for the first frame,
+ * for the following frames they are adaptively readjusted
+ * NOTE the decoder in ffmpeg has its own arbitrary limitation on the number
+ * of strips, currently 32
+ */
typedef enum {
MODE_V1_ONLY = 0,
@@ -114,12 +116,12 @@ typedef enum {
} mb_encoding;
typedef struct {
-int v1_vector; //index into v1 codebook
-int v1_error; //error when using V1 encoding
-int v4_vector[4]; //indices into v4 codebook
-int v4_error; //error when using V4 encoding
-int skip_error; //error when block is skipped (aka copied
from last frame)
-mb_encoding best_encoding; //last result from calculate_mode_score()
+int v1_vector; /* index into v1 codebook */
+int v1_error; /* error when using V1 encoding */
+int v4_vector[4]; /* indices into v4 codebook */
+int v4_error; /* error when using V4 encoding */
+int skip_error;/* error when block is skipped (aka copied
from last frame) */
+mb_encoding best_encoding; /* last result from calculate_mode_score()
*/
} mb_info;
typedef struct {
@@ -146,15 +148,15 @@ typedef struct {
uint64_t lambda;
int *codebook_input;
int *codebook_closest;
-mb_info *mb;//MB RD state
-int min_strips; //the current limit
-int max_strips; //the current limit
+mb_info *mb;/* MB RD state */
+int min_strips; /* the current limit */
+int max_strips; /* the current limit */
#ifdef CINEPAKENC_DEBUG
-mb_info *best_mb; //TODO: remove. only used for
printing stats
+mb_info *best_mb; /* TODO: remove. only used for
printing stats */
int num_v1_mode, num_v4_mode, num_mc_mode;
int num_v1_encs, num_v4_encs, num_skips;
#endif
-// options
+/* options */
int max_extra_cb_iterations;
int skip_empty_cb;
int min_min_strips;
@@ -219,10 +221,12 @@ static av_cold int cinepak_encode_init(AVCodecContext
*avctx)
mb_count = avctx->width * avctx->height / MB_AREA;
-//the largest possible chunk is 0x31 with all MBs encoded in V4 mode
-//and full codebooks being replaced in INTER mode,
-// which is 34 bits per MB
-//and 2*256 extra flag bits per strip
+/*
+ * the largest possible chunk is 0x31 with all MBs encoded in V4 mode
+ * and full codebooks being replaced in INTER mode,
+ * which is 34 bits per MB
+ * and 2
[FFmpeg-devel] [PATCH 1/3] libavcodec/cinepakenc.c: comments cleanup (contents)
Attaching the new version.
Regards,
Rune
>From f563e57f7609cd890b655cb9d140849f0917a6d3 Mon Sep 17 00:00:00 2001
From: Rl
Date: Sun, 29 Jan 2017 16:40:27 +0100
Subject: [PATCH 1/3] libavcodec/cinepakenc.c: comments cleanup (contents)
Change the encoding of the original developer name from ISO-8859-1 to UTF-8.
Remove the stale/completed TODO list.
Fix two small typos.
---
libavcodec/cinepakenc.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/libavcodec/cinepakenc.c b/libavcodec/cinepakenc.c
index 3670157dfc..a28f669070 100644
--- a/libavcodec/cinepakenc.c
+++ b/libavcodec/cinepakenc.c
@@ -1,5 +1,5 @@
/*
- * Cinepak encoder (c) 2011 Tomas H�rdin
+ * Cinepak encoder (c) 2011 Tomas Härdin
* http://titan.codemill.se/~tomhar/cinepakenc.patch
*
* Fixes and improvements, vintage decoders compatibility
@@ -23,9 +23,6 @@ OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
OTHERWISE,
ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.
- * TODO:
- * - optimize: color space conversion, ...
- * - implement options to set the min/max number of strips?
* MAYBE:
* - "optimally" split the frame into several non-regular areas
* using a separate codebook pair for each area and approximating
@@ -92,7 +89,7 @@ OTHER DEALINGS IN THE SOFTWARE.
#define MAX_STRIPS 32 //Note: having fewer choices regarding the number
of strips speeds up encoding (obviously)
#define MIN_STRIPS 1 //Note: having more strips speeds up encoding the
frame (this is less obvious)
// MAX_STRIPS limits the maximum quality you can reach
-//when you want hight quality on high resolutions,
+//when you want high quality on high resolutions,
// MIN_STRIPS limits the minimum efficiently encodable bit rate
//on low resolutions
// the numbers are only used for brute force optimization for the first frame,
@@ -119,7 +116,7 @@ typedef enum {
typedef struct {
int v1_vector; //index into v1 codebook
int v1_error; //error when using V1 encoding
-int v4_vector[4]; //indices into v4 codebooks
+int v4_vector[4]; //indices into v4 codebook
int v4_error; //error when using V4 encoding
int skip_error; //error when block is skipped (aka copied
from last frame)
mb_encoding best_encoding; //last result from calculate_mode_score()
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec: add ATRAC Advanced Lossless decoders
Only lossy part is decoded for now.
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile| 3 +
libavcodec/allcodecs.c | 2 +
libavcodec/atrac3.c| 77 +-
libavcodec/atrac3plusdec.c | 14 +++-
libavcodec/avcodec.h | 2 +
libavcodec/codec_desc.c| 14
libavformat/oma.c | 10 +--
libavformat/oma.h | 2 +
libavformat/omadec.c | 156 +++--
9 files changed, 239 insertions(+), 41 deletions(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 43a6add..c5505db 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -191,8 +191,11 @@ OBJS-$(CONFIG_ASV2_DECODER)+= asvdec.o asv.o
mpeg12data.o
OBJS-$(CONFIG_ASV2_ENCODER)+= asvenc.o asv.o mpeg12data.o
OBJS-$(CONFIG_ATRAC1_DECODER) += atrac1.o atrac.o
OBJS-$(CONFIG_ATRAC3_DECODER) += atrac3.o atrac.o
+OBJS-$(CONFIG_ATRAC3AL_DECODER)+= atrac3.o atrac.o
OBJS-$(CONFIG_ATRAC3P_DECODER) += atrac3plusdec.o atrac3plus.o \
atrac3plusdsp.o atrac.o
+OBJS-$(CONFIG_ATRAC3PAL_DECODER) += atrac3plusdec.o atrac3plus.o \
+ atrac3plusdsp.o atrac.o
OBJS-$(CONFIG_AURA_DECODER)+= cyuv.o
OBJS-$(CONFIG_AURA2_DECODER) += aura.o
OBJS-$(CONFIG_AVRN_DECODER)+= avrndec.o mjpegdec.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index f92b2b7..7220864 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -403,7 +403,9 @@ void avcodec_register_all(void)
REGISTER_DECODER(APE, ape);
REGISTER_DECODER(ATRAC1,atrac1);
REGISTER_DECODER(ATRAC3,atrac3);
+REGISTER_DECODER(ATRAC3AL, atrac3al);
REGISTER_DECODER(ATRAC3P, atrac3p);
+REGISTER_DECODER(ATRAC3PAL, atrac3pal);
REGISTER_DECODER(BINKAUDIO_DCT, binkaudio_dct);
REGISTER_DECODER(BINKAUDIO_RDFT,binkaudio_rdft);
REGISTER_DECODER(BMV_AUDIO, bmv_audio);
diff --git a/libavcodec/atrac3.c b/libavcodec/atrac3.c
index ffd93e4..ec1416f 100644
--- a/libavcodec/atrac3.c
+++ b/libavcodec/atrac3.c
@@ -731,6 +731,40 @@ static int decode_frame(AVCodecContext *avctx, const
uint8_t *databuf,
return 0;
}
+static int al_decode_frame(AVCodecContext *avctx, const uint8_t *databuf,
+ int size, float **out_samples)
+{
+ATRAC3Context *q = avctx->priv_data;
+int ret, i;
+
+/* Set the bitstream reader at the start of a channel sound unit. */
+init_get_bits(&q->gb, databuf, size * 8);
+/* single channels */
+/* Decode the channel sound units. */
+for (i = 0; i < avctx->channels; i++) {
+ret = decode_channel_sound_unit(q, &q->gb, &q->units[i],
+out_samples[i], i, q->coding_mode);
+if (ret != 0)
+return ret;
+while (i < avctx->channels && get_bits_left(&q->gb) > 6 &&
show_bits(&q->gb, 6) != 0x28) {
+skip_bits(&q->gb, 1);
+}
+}
+
+/* Apply the iQMF synthesis filter. */
+for (i = 0; i < avctx->channels; i++) {
+float *p1 = out_samples[i];
+float *p2 = p1 + 256;
+float *p3 = p2 + 256;
+float *p4 = p3 + 256;
+ff_atrac_iqmf(p1, p2, 256, p1, q->units[i].delay_buf1, q->temp_buf);
+ff_atrac_iqmf(p4, p3, 256, p3, q->units[i].delay_buf2, q->temp_buf);
+ff_atrac_iqmf(p1, p3, 512, p1, q->units[i].delay_buf3, q->temp_buf);
+}
+
+return 0;
+}
+
static int atrac3_decode_frame(AVCodecContext *avctx, void *data,
int *got_frame_ptr, AVPacket *avpkt)
{
@@ -771,6 +805,28 @@ static int atrac3_decode_frame(AVCodecContext *avctx, void
*data,
return avctx->block_align;
}
+static int atrac3al_decode_frame(AVCodecContext *avctx, void *data,
+ int *got_frame_ptr, AVPacket *avpkt)
+{
+AVFrame *frame = data;
+int ret;
+
+frame->nb_samples = SAMPLES_PER_FRAME;
+if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
+return ret;
+
+ret = al_decode_frame(avctx, avpkt->data, avpkt->size,
+ (float **)frame->extended_data);
+if (ret) {
+av_log(avctx, AV_LOG_ERROR, "Frame decoding error!\n");
+return ret;
+}
+
+*got_frame_ptr = 1;
+
+return avpkt->size;
+}
+
static av_cold void atrac3_init_static_data(void)
{
int i;
@@ -807,7 +863,12 @@ static av_cold int atrac3_decode_init(AVCodecContext
*avctx)
static_init_done = 1;
/* Take care of the codec-specific extradata. */
-if (avctx->extradata_size == 14) {
+if (avctx->codec_id == AV_CODEC_ID_ATRAC3AL) {
+version = 4;
+samples_per_frame = SAMPLES_PER_FRAME * avctx->channels;
+delay = 0x88E;
+q->coding_mode= SINGLE;
+} else i
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
Michael Niedermayer wrote: >But id like to ask everyone to NOT escalate this further, >iam sure that nothing good would come out of that. + ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
On Sat, Jan 28, 2017 at 10:23:53PM +0700, Muhammad Faiz wrote: > so the behavior will be similar to > av_frame_make_writable(). > > Also use av_frame_copy() replacing > av_image_copy()/av_samples_copy(). > > Needed for the next patch. > > Suggested-by: wm4 > Signed-off-by: Muhammad Faiz > --- > libavfilter/avfilter.c | 26 ++ > libavfilter/filters.h | 2 +- > 2 files changed, 7 insertions(+), 21 deletions(-) It seems this thread escalated a bit, iam replying here to the root mail which is unrelated and a reply to a unrelated developer as i do not want to take a side nor do i have any oppinion about the code change suggested. But id like to ask everyone to NOT escalate this further, iam sure that nothing good would come out of that. No matter if it would end in someone leaving or some votes which on all outcomes do us harm also we need a maintainer for the libavfilter core or a area covering avfilter.c and that person should then make a decission. ANY decission is better than a spiral of escalation. I mean, lets be honest neither solution for this really has a problem, they are all fine, but a fight that escalates and causes temporary or worse permanant alienation is really bad I guess my mail got longer than intended, just wanted to basically say love each other dont hate and fight at least not to the point were it turns harmfull [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/examples/decoder_targeted: move to tools/target_dec_fuzzer.c
On 29 January 2017 at 15:55, wm4 wrote: > On Sun, 29 Jan 2017 15:31:39 + > Rostislav Pehlivanov wrote: > > > Name and purpose are more appropriate there since the code isn't > > an ideal example. > > > > Signed-off-by: Rostislav Pehlivanov > > --- > > doc/examples/decoder_targeted.c => tools/target_dec_fuzzer.c | 0 > > 1 file changed, 0 insertions(+), 0 deletions(-) > > rename doc/examples/decoder_targeted.c => tools/target_dec_fuzzer.c > (100%) > > > > diff --git a/doc/examples/decoder_targeted.c b/tools/target_dec_fuzzer.c > > similarity index 100% > > rename from doc/examples/decoder_targeted.c > > rename to tools/target_dec_fuzzer.c > > +1 > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Pushed with updated instructions Thanks for the review ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/examples/decoder_targeted: move to tools/target_dec_fuzzer.c
On Sun, 29 Jan 2017 15:31:39 + Rostislav Pehlivanov wrote: > Name and purpose are more appropriate there since the code isn't > an ideal example. > > Signed-off-by: Rostislav Pehlivanov > --- > doc/examples/decoder_targeted.c => tools/target_dec_fuzzer.c | 0 > 1 file changed, 0 insertions(+), 0 deletions(-) > rename doc/examples/decoder_targeted.c => tools/target_dec_fuzzer.c (100%) > > diff --git a/doc/examples/decoder_targeted.c b/tools/target_dec_fuzzer.c > similarity index 100% > rename from doc/examples/decoder_targeted.c > rename to tools/target_dec_fuzzer.c +1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/examples/decoder_targeted: move to tools/target_dec_fuzzer.c
Name and purpose are more appropriate there since the code isn't an ideal example. Signed-off-by: Rostislav Pehlivanov --- doc/examples/decoder_targeted.c => tools/target_dec_fuzzer.c | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename doc/examples/decoder_targeted.c => tools/target_dec_fuzzer.c (100%) diff --git a/doc/examples/decoder_targeted.c b/tools/target_dec_fuzzer.c similarity index 100% rename from doc/examples/decoder_targeted.c rename to tools/target_dec_fuzzer.c -- 2.11.0.483.g087da7b7c ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/tls_openssl: Support building with LibreSSL
On Sun, 29 Jan 2017 22:35:12 +1100 Matt Oliver wrote: > Well perhaps making a tls_libressl implementation would be the better > way to go as the APIs are only going to diverge further. So perhaps > in order to support LibreSSL there should be a separate > implementation using LibreSSLs independent libtls instead of the > older openssl support interface. libtls is the recommended and > primarily supported interface when using LibreSSL so that should be > used going forward instead of further complication the opensll code. Yes, that would be the optimal solution, I think. But still, even if not considering LibreSSL, the currently proposed patch is probably a better way to check for BIO_meth_* calls in OpenSSL. That it also works with LibreSSL can be considered as a bonus. Maybe the commit message should be changed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: make ff_framequeue_skip_samples() more useful.
On 1/29/17, Nicolas George wrote: > Instead of just updating statistics, have it actually do the work > instead of leaving that job to the call site. > > Also: skip the samples by updating the frame data pointers > instead of moving the samples. More efficient and avoid writing > into shared frames. > Found-By: Muhammad Faiz > > Signed-off-by: Nicolas George > --- > libavfilter/avfilter.c | 8 +--- > libavfilter/framequeue.c | 27 +++ > libavfilter/framequeue.h | 11 +-- > 3 files changed, 33 insertions(+), 13 deletions(-) > LGTM Thank's ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avutil/eval: add atan2 function
Signed-off-by: Paul B Mahol
---
doc/utils.texi | 3 +++
libavutil/eval.c | 4 +++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/doc/utils.texi b/doc/utils.texi
index 30a962a..1734439 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -776,6 +776,9 @@ Compute arcsine of @var{x}.
@item atan(x)
Compute arctangent of @var{x}.
+@item atan2(x, y)
+Compute principal value of the arc tangent of @var{y}/@var{x}.
+
@item between(x, min, max)
Return 1 if @var{x} is greater than or equal to @var{min} and lesser than or
equal to @var{max}, 0 otherwise.
diff --git a/libavutil/eval.c b/libavutil/eval.c
index 2d49154..7e86615 100644
--- a/libavutil/eval.c
+++ b/libavutil/eval.c
@@ -155,7 +155,7 @@ struct AVExpr {
e_pow, e_mul, e_div, e_add,
e_last, e_st, e_while, e_taylor, e_root, e_floor, e_ceil, e_trunc,
e_sqrt, e_not, e_random, e_hypot, e_gcd,
-e_if, e_ifnot, e_print, e_bitand, e_bitor, e_between, e_clip
+e_if, e_ifnot, e_print, e_bitand, e_bitor, e_between, e_clip, e_atan2
} type;
double value; // is sign in other types
union {
@@ -306,6 +306,7 @@ static double eval_expr(Parser *p, AVExpr *e)
case e_last:return e->value * d2;
case e_st : return e->value * (p->var[av_clip(d, 0, VARS-1)]=
d2);
case e_hypot:return e->value * hypot(d, d2);
+case e_atan2:return e->value * atan2(d, d2);
case e_bitand: return isnan(d) || isnan(d2) ? NAN : e->value *
((long int)d & (long int)d2);
case e_bitor: return isnan(d) || isnan(d2) ? NAN : e->value *
((long int)d | (long int)d2);
}
@@ -452,6 +453,7 @@ static int parse_primary(AVExpr **e, Parser *p)
else if (strmatch(next, "bitor" )) d->type = e_bitor;
else if (strmatch(next, "between"))d->type = e_between;
else if (strmatch(next, "clip" )) d->type = e_clip;
+else if (strmatch(next, "atan2" )) d->type = e_atan2;
else {
for (i=0; p->func1_names && p->func1_names[i]; i++) {
if (strmatch(next, p->func1_names[i])) {
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
On Sun, 29 Jan 2017 13:20:29 +0100 Paul B Mahol wrote: > On 1/29/17, wm4 wrote: > > On Sun, 29 Jan 2017 13:06:13 +0100 > > Nicolas George wrote: > > > >> Le decadi 10 pluviose, an CCXXV, wm4 a ecrit : > >> > Then you should stop moving away from it. The av_frame_make_writable > >> > design is superior for multiple reasons, and was intentionally designed > >> > this way by an intelligent mind with a lot of API-foresight. > >> > > >> > If you "move away from it" just like this, you create a major > >> > inconsistency as well. > >> > > >> > I haven't heard a good argument as to why its API is supposed to be > >> > better than av_frame_make_writable. > >> > > >> > I one the other hand delivered a bunch of arguments to which you didn't > >> > reply. > >> > >> Rude again. > > > > No, it's not rude. > > > > Maybe you could get technical again, after you've sent only a bunch of > > cranky posts complaining about my supposedly bad behavior? > > I'm really sick of you two. I too would rather prefer having a technical discussion instead of shit-flinging. But that is apparently not possible. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
On Sun, 29 Jan 2017 13:06:13 +0100 Nicolas George wrote: > Le decadi 10 pluviôse, an CCXXV, wm4 a écrit : > > Then you should stop moving away from it. The av_frame_make_writable > > design is superior for multiple reasons, and was intentionally designed > > this way by an intelligent mind with a lot of API-foresight. > > > > If you "move away from it" just like this, you create a major > > inconsistency as well. > > > > I haven't heard a good argument as to why its API is supposed to be > > better than av_frame_make_writable. > > > > I one the other hand delivered a bunch of arguments to which you didn't > > reply. > > Rude again. Anyway, since you're unwilling to discuss the technical points of this patch, and seeing you're not maintainer of libavfilter or this file, I will push patch 1/2 tomorrow. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
On 1/29/17, wm4 wrote: > On Sun, 29 Jan 2017 13:06:13 +0100 > Nicolas George wrote: > >> Le decadi 10 pluviose, an CCXXV, wm4 a ecrit : >> > Then you should stop moving away from it. The av_frame_make_writable >> > design is superior for multiple reasons, and was intentionally designed >> > this way by an intelligent mind with a lot of API-foresight. >> > >> > If you "move away from it" just like this, you create a major >> > inconsistency as well. >> > >> > I haven't heard a good argument as to why its API is supposed to be >> > better than av_frame_make_writable. >> > >> > I one the other hand delivered a bunch of arguments to which you didn't >> > reply. >> >> Rude again. > > No, it's not rude. > > Maybe you could get technical again, after you've sent only a bunch of > cranky posts complaining about my supposedly bad behavior? I'm really sick of you two. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
On Sun, 29 Jan 2017 13:06:13 +0100 Nicolas George wrote: > Le decadi 10 pluviôse, an CCXXV, wm4 a écrit : > > Then you should stop moving away from it. The av_frame_make_writable > > design is superior for multiple reasons, and was intentionally designed > > this way by an intelligent mind with a lot of API-foresight. > > > > If you "move away from it" just like this, you create a major > > inconsistency as well. > > > > I haven't heard a good argument as to why its API is supposed to be > > better than av_frame_make_writable. > > > > I one the other hand delivered a bunch of arguments to which you didn't > > reply. > > Rude again. No, it's not rude. Maybe you could get technical again, after you've sent only a bunch of cranky posts complaining about my supposedly bad behavior? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
Le decadi 10 pluviôse, an CCXXV, wm4 a écrit : > Then you should stop moving away from it. The av_frame_make_writable > design is superior for multiple reasons, and was intentionally designed > this way by an intelligent mind with a lot of API-foresight. > > If you "move away from it" just like this, you create a major > inconsistency as well. > > I haven't heard a good argument as to why its API is supposed to be > better than av_frame_make_writable. > > I one the other hand delivered a bunch of arguments to which you didn't > reply. Rude again. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
On Sun, 29 Jan 2017 13:00:38 +0100 Nicolas George wrote: > Le decadi 10 pluviôse, an CCXXV, wm4 a écrit : > > His 1/2 patch was a strict improvement over the current internal API. > > In particular, it gets it into line with the current > > av_frame_make_writable() API. > > You purposefully ignore the fact, already stated, that moving away from > av_frame_make_writable() was intentional. Then you should stop moving away from it. The av_frame_make_writable design is superior for multiple reasons, and was intentionally designed this way by an intelligent mind with a lot of API-foresight. If you "move away from it" just like this, you create a major inconsistency as well. I haven't heard a good argument as to why its API is supposed to be better than av_frame_make_writable. I one the other hand delivered a bunch of arguments to which you didn't reply. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
Le decadi 10 pluviôse, an CCXXV, wm4 a écrit : > His 1/2 patch was a strict improvement over the current internal API. > In particular, it gets it into line with the current > av_frame_make_writable() API. You purposefully ignore the fact, already stated, that moving away from av_frame_make_writable() was intentional. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
On Sun, 29 Jan 2017 12:54:53 +0100 Nicolas George wrote: > Le decadi 10 pluviôse, an CCXXV, wm4 a écrit : > > You hadn't anything to say my convincing arguments. > > > > His 1/2 patch was a strict improvement over the current internal API. > > In particular, it gets it into line with the current > > av_frame_make_writable() API. There are other good arguments. Why > > reject it? Because you're so stubborn? > > I will not answer the contents of your messages unless you start > addressing me and the other persons on the list politely. OK: His 1/2 patch was a strict improvement over the current internal API. In particular, it gets it into line with the current av_frame_make_writable() API. There are other good arguments. Why reject it? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
Le decadi 10 pluviôse, an CCXXV, wm4 a écrit : > You hadn't anything to say my convincing arguments. > > His 1/2 patch was a strict improvement over the current internal API. > In particular, it gets it into line with the current > av_frame_make_writable() API. There are other good arguments. Why > reject it? Because you're so stubborn? I will not answer the contents of your messages unless you start addressing me and the other persons on the list politely. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
On Sun, 29 Jan 2017 12:47:16 +0100 Nicolas George wrote: > Le decadi 10 pluviôse, an CCXXV, wm4 a écrit : > > Please push this patch. It's a nice simplification. > > I rejected this patch. This message is unacceptable. You hadn't anything to say my convincing arguments. His 1/2 patch was a strict improvement over the current internal API. In particular, it gets it into line with the current av_frame_make_writable() API. There are other good arguments. Why reject it? Because you're so stubborn? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
Le decadi 10 pluviôse, an CCXXV, wm4 a écrit : > Please push this patch. It's a nice simplification. I rejected this patch. This message is unacceptable. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avfilter: change ff_inlink_make_frame_writable() to take AVFrame* argument
On Sat, 28 Jan 2017 22:23:53 +0700
Muhammad Faiz wrote:
> so the behavior will be similar to
> av_frame_make_writable().
>
> Also use av_frame_copy() replacing
> av_image_copy()/av_samples_copy().
>
> Needed for the next patch.
>
> Suggested-by: wm4
> Signed-off-by: Muhammad Faiz
> ---
> libavfilter/avfilter.c | 26 ++
> libavfilter/filters.h | 2 +-
> 2 files changed, 7 insertions(+), 21 deletions(-)
>
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index c12d491..c8dafd2 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -1104,7 +1104,7 @@ static int ff_filter_frame_framed(AVFilterLink *link,
> AVFrame *frame)
> filter_frame = default_filter_frame;
>
> if (dst->needs_writable) {
> -ret = ff_inlink_make_frame_writable(link, &frame);
> +ret = ff_inlink_make_frame_writable(link, frame);
> if (ret < 0)
> goto fail;
> }
> @@ -1556,9 +1556,8 @@ int ff_inlink_consume_samples(AVFilterLink *link,
> unsigned min, unsigned max,
> return 1;
> }
>
> -int ff_inlink_make_frame_writable(AVFilterLink *link, AVFrame **rframe)
> +int ff_inlink_make_frame_writable(AVFilterLink *link, AVFrame *frame)
> {
> -AVFrame *frame = *rframe;
> AVFrame *out;
> int ret;
>
> @@ -1585,23 +1584,10 @@ int ff_inlink_make_frame_writable(AVFilterLink *link,
> AVFrame **rframe)
> return ret;
> }
>
> -switch (link->type) {
> -case AVMEDIA_TYPE_VIDEO:
> -av_image_copy(out->data, out->linesize, (const uint8_t
> **)frame->data, frame->linesize,
> - frame->format, frame->width, frame->height);
> -break;
> -case AVMEDIA_TYPE_AUDIO:
> -av_samples_copy(out->extended_data, frame->extended_data,
> -0, 0, frame->nb_samples,
> -av_frame_get_channels(frame),
> -frame->format);
> -break;
> -default:
> -av_assert0(!"reached");
> -}
> -
> -av_frame_free(&frame);
> -*rframe = out;
> +av_frame_copy(out, frame);
> +av_frame_unref(frame);
> +av_frame_move_ref(frame, out);
> +av_frame_free(&out);
> return 0;
> }
>
> diff --git a/libavfilter/filters.h b/libavfilter/filters.h
> index 2c78d60..5d32403 100644
> --- a/libavfilter/filters.h
> +++ b/libavfilter/filters.h
> @@ -101,7 +101,7 @@ int ff_inlink_consume_samples(AVFilterLink *link,
> unsigned min, unsigned max,
> * This is similar to av_frame_make_writable() except it uses the link's
> * buffer allocation callback, and therefore allows direct rendering.
> */
> -int ff_inlink_make_frame_writable(AVFilterLink *link, AVFrame **rframe);
> +int ff_inlink_make_frame_writable(AVFilterLink *link, AVFrame *frame);
>
> /**
> * Test and acknowledge the change of status on the link.
Please push this patch. It's a nice simplification.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavf/tls_openssl: Support building with LibreSSL
On 29 January 2017 at 01:00, Marek Behun wrote:
> On Sat, 28 Jan 2017 14:07:45 +0100
> wm4 wrote:
>
> > On Sat, 28 Jan 2017 13:01:54 +
> > Mark Thompson wrote:
> >
> > > On 28/01/17 11:28, wm4 wrote:
> > > > On Fri, 27 Jan 2017 19:53:50 +
> > > > Mark Thompson wrote:
> > > >
> > > >> On 27/01/17 19:15, Marek Behun wrote:
> > > >>> On Fri, 27 Jan 2017 18:41:09 +
> > > >>> Mark Thompson wrote:
> > > >>>
> > > On 27/01/17 17:31, Marek Behún wrote:
> > > > Use the LIBRESSL_VERSION_NUMBER macro to determine if
> > > > building with LibreSSL instead of OpenSSL. This is pretty
> > > > straightforward, since it is enough to add this check to
> > > > existing #if macros.
> > > >
> > > > Signed-off-by: Marek Behun
> > > > ---
> > > > libavformat/tls_openssl.c | 12 ++--
> > > > 1 file changed, 6 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/libavformat/tls_openssl.c
> > > > b/libavformat/tls_openssl.c index 3d9768a..cf1a62e 100644
> > > > --- a/libavformat/tls_openssl.c
> > > > +++ b/libavformat/tls_openssl.c
> > > > @@ -43,7 +43,7 @@ typedef struct TLSContext {
> > > > TLSShared tls_shared;
> > > > SSL_CTX *ctx;
> > > > SSL *ssl;
> > > > -#if OPENSSL_VERSION_NUMBER >= 0x101fL
> > > > +#if OPENSSL_VERSION_NUMBER >= 0x101fL
> > > > && !defined(LIBRESSL_VERSION_NUMBER)
> > >
> > > I don't understand what this is trying to do.
> > >
> > > Does LibreSSL support the OpenSSL 1.1.0 API:
> > >
> > > If yes, why would the additional check be needed?
> > >
> > > If no, isn't this doing nothing because the first check would
> > > be false?
> > > >>>
> > > >>> LibreSSL defines OPENSSL_VERSION_NUMBER to >=0x200, thus
> > > >>> OPENSSL_VERSION_NUMBER is always greater than 0x101, but
> > > >>> LibreSSL does not support 1.1.0 API.
> > > >>
> > > >> Er, right, so it just lies and leaves it to user programs to
> > > >> sort it out. How nice.
> > > >>
> > > >> Looking back, I can see this has been discussed before:
> > > >> October/201960.html>
> > > >> December/203998.html>
> > > >>
> > > >> That (beyond the disapprobation towards libressl for being
> > > >> naughty) looks like people would prefer the test to be in
> > > >> configure rather than copying the nontrivial #if condition
> > > >> everywhere?
> > > >
> > > > Maybe LibreSSL should fix this upstream.
> > > >
> > > > They're doing an extreme disservice to everyone by breaking every
> > > > single downstream program.
> > > >
> > > > I'd even go as far as saying we shouldn't bother with LibreSSL if
> > > > trying to keep compatibility is going to be a mess this huge.
> > >
> > > If it becomes more inconvenient to do so, yes.
> >
> > > (At that point probably just clone tls_openssl.c to tls_libressl.c
> > > and let them diverge if support is still wanted.)
>
> The support would be wanted, for sure. FreeBSD, OpenBSD and Gentoo want
> to support LibreSSL:
> - OpenBSD already removed openssl completely, since the security flaws
> of openssl are unacceptable to them.
> - FreeBSD states that "Currently there are no binary distributions for
> LibreSSL-in-base but this is to change with the release of FreeBSD
> 11."
> - Gentoo has a USE flag for libressl and Gentoo bug #561854, which
> tracks LibreSSL incompatibilities, has majority of dependencies
> solved.
>
> My guess is that the OpenBSD guys want the world to get rid of openssl
> completely (see for example http://opensslrampage.org/), and breaking
> API compatibility with openssl is their "strategy". Well, this strategy
> maybe is inconveniet for others, but having seen the code of openssl, I
> would rather inconveniet myself with porting to LibreSSL than use
> OpenSSL.
>
Well perhaps making a tls_libressl implementation would be the better way
to go as the APIs are only going to diverge further. So perhaps in order to
support LibreSSL there should be a separate implementation using LibreSSLs
independent libtls instead of the older openssl support interface. libtls
is the recommended and primarily supported interface when using LibreSSL so
that should be used going forward instead of further complication the
opensll code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: do not write to unwritable frame
L'octidi 8 pluviôse, an CCXXV, Muhammad Faiz a écrit : > affect filters that set partial_buf_size > test-case > ffplay -i lavfi 'aevalsrc=sin(1000*t*t), aformat=sample_fmts=fltp, asplit > [a][b]; > [a] firequalizer=fixed=on, showcqt=s=1280x360 [a1]; > [b] firequalizer=fixed=on, showcqt=s=1280x360 [b1]; > [a1][b1] vstack' > > Signed-off-by: Muhammad Faiz > --- > libavfilter/avfilter.c | 17 + > 1 file changed, 17 insertions(+) Please have look at this patch: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206333.html https://patchwork.ffmpeg.org/patch/2355/ Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavfi: make ff_framequeue_skip_samples() more useful.
Instead of just updating statistics, have it actually do the work
instead of leaving that job to the call site.
Also: skip the samples by updating the frame data pointers
instead of moving the samples. More efficient and avoid writing
into shared frames.
Found-By: Muhammad Faiz
Signed-off-by: Nicolas George
---
libavfilter/avfilter.c | 8 +---
libavfilter/framequeue.c | 27 +++
libavfilter/framequeue.h | 11 +--
3 files changed, 33 insertions(+), 13 deletions(-)
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index c12d4912a8..b431990edc 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -1235,13 +1235,7 @@ static int take_samples(AVFilterLink *link, unsigned
min, unsigned max,
frame = ff_framequeue_peek(&link->fifo, 0);
av_samples_copy(buf->extended_data, frame->extended_data, p, 0, n,
link->channels, link->format);
-frame->nb_samples -= n;
-av_samples_copy(frame->extended_data, frame->extended_data, 0, n,
-frame->nb_samples, link->channels, link->format);
-if (frame->pts != AV_NOPTS_VALUE)
-frame->pts += av_rescale_q(n, av_make_q(1, link->sample_rate),
link->time_base);
-ff_framequeue_update_peeked(&link->fifo, 0);
-ff_framequeue_skip_samples(&link->fifo, n);
+ff_framequeue_skip_samples(&link->fifo, n, link->time_base);
}
*rframe = buf;
diff --git a/libavfilter/framequeue.c b/libavfilter/framequeue.c
index a4ffa86c95..26bfa49967 100644
--- a/libavfilter/framequeue.c
+++ b/libavfilter/framequeue.c
@@ -121,3 +121,30 @@ AVFrame *ff_framequeue_peek(FFFrameQueue *fq, size_t idx)
check_consistency(fq);
return b->frame;
}
+
+void ff_framequeue_skip_samples(FFFrameQueue *fq, size_t samples, AVRational
time_base)
+{
+FFFrameBucket *b;
+size_t bytes;
+int planar, planes, i;
+
+check_consistency(fq);
+av_assert1(fq->queued);
+b = bucket(fq, 0);
+av_assert1(samples < b->frame->nb_samples);
+planar = av_sample_fmt_is_planar(b->frame->format);
+planes = planar ? b->frame->channels : 1;
+bytes = samples * av_get_bytes_per_sample(b->frame->format);
+if (!planar)
+bytes *= b->frame->channels;
+if (b->frame->pts != AV_NOPTS_VALUE)
+b->frame->pts += av_rescale_q(samples, av_make_q(1,
b->frame->sample_rate), time_base);
+b->frame->nb_samples -= samples;
+b->frame->linesize[0] -= bytes;
+for (i = 0; i < planes; i++)
+b->frame->extended_data[i] += bytes;
+for (i = 0; i < planes && i < AV_NUM_DATA_POINTERS; i++)
+b->frame->data[i] = b->frame->extended_data[i];
+fq->total_samples_tail += samples;
+ff_framequeue_update_peeked(fq, 0);
+}
diff --git a/libavfilter/framequeue.h b/libavfilter/framequeue.h
index f5ef744638..5aa2c725a7 100644
--- a/libavfilter/framequeue.h
+++ b/libavfilter/framequeue.h
@@ -161,14 +161,13 @@ static inline void
ff_framequeue_update_peeked(FFFrameQueue *fq, size_t idx)
}
/**
- * Update the sample count in the queue.
+ * Skip samples from the first frame in the queue.
*
* This function must be used when the first frame was accessed using
- * ff_framequeue_peek() and samples were removed from it.
+ * ff_framequeue_peek() and samples were consumed from it.
+ * It adapts the data pointers and timestamps of the head frame to account
+ * for the skipped samples.
*/
-static inline void ff_framequeue_skip_samples(FFFrameQueue *fq, size_t n)
-{
-fq->total_samples_tail += n;
-}
+void ff_framequeue_skip_samples(FFFrameQueue *fq, size_t samples, AVRational
time_base);
#endif /* AVFILTER_FRAMEQUEUE_H */
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/9] genh: prevent overflow during block alignment calculation
On 1/29/17, Michael Niedermayer wrote: > On Thu, Jan 26, 2017 at 02:11:54AM +0100, Andreas Cadhalpun wrote: >> Signed-off-by: Andreas Cadhalpun >> --- >> libavformat/genh.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) > > LGTM assuming the author/maintainer does not object > ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 8/9] xvag: prevent overflow during block alignment calculation
On 1/29/17, Michael Niedermayer wrote: > On Thu, Jan 26, 2017 at 02:13:48AM +0100, Andreas Cadhalpun wrote: >> Signed-off-by: Andreas Cadhalpun >> --- >> libavformat/xvag.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) > > LGTM assuming the author/maintainer does not object ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 7/9] epafdec: prevent overflow during block alignment calculation
On 1/29/17, Michael Niedermayer wrote: > On Thu, Jan 26, 2017 at 02:13:33AM +0100, Andreas Cadhalpun wrote: >> Signed-off-by: Andreas Cadhalpun >> --- >> libavformat/epafdec.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) > > LGTM assuming the author/maintainer does not object ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
