arker() call never
be called. Update the if statement to fix it.
Fixes: Ticket9843
Signed-off-by: Steinar H. Gunderson
---
libavformat/matroskaenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index e813ef86cf7..1dfcf7
On Wed, Jun 09, 2021 at 12:41:17PM +0200, Nicolas George wrote:
> (TCP_NODELAY is a terrible hack for a terrible API design. An explicit
> flush system call would have been a much better choice.)
If you want explicit flush, you can enable TCP_CORK (but it's Linux-only).
Disable for the flush.
/*
On Tue, May 04, 2021 at 06:38:41PM +0100, Derek Buitenhuis wrote:
> I will say that it is unclear enough to me what the goals and uses are of
> the patch that it came off a bit like upstreaming something purely for
> personal
> use, even if that wasn't intended. Apologies.
No offense taken. The b
On Tue, May 04, 2021 at 04:46:29PM +0100, Derek Buitenhuis wrote:
> Can this not be accomplished outside of FFmpeg, by registering your own I/O
> callbacks? That would seem to me to be the 'proper' way to do this. More
> work? Yes. But less hacky.
For a libavformat-using program that does its own
On Mon, May 03, 2021 at 10:51:43PM +0200, Marton Balint wrote:
> It is quite ugly that you are introducing this in *avio*. Why is this not an
> option of HTTP?
Two reasons:
- As the commit message says, it is desirable to have this on pipe output as
well (Cubemap would like to fork out to FFm
onsidered to be licensed under the LGPL 2.1, like
the rest of FFmpeg.
Signed-off-by: Steinar H. Gunderson
---
fftools/ffmpeg_opt.c| 6 ++-
libavformat/avformat.h | 1 +
libavformat/avio.h | 30 +++
libavformat/aviobuf.c | 103 +-
On Tue, Jul 21, 2020 at 02:41:16PM +0200, Nicolas George wrote:
>> Also it is new patch.
> All the more reason not to apply and wait for it to be reviewed and
> tested. Fortunately, there is somebody both competent and interested
> in the matter.
I don't intend to look more at this; Paul has made
On Mon, Jul 20, 2020 at 04:28:02PM -0400, Zachariah Brown wrote:
> Paul, no body attacked you in anyway personally. I don't know what happened
> in the past because I've only been here for a couple of months, but it was
> very clear that Steinar was being purely objective about your patch.
Like I
On Sun, Jul 19, 2020 at 09:02:30PM +0200, Paul B Mahol wrote:
>> Yes, this is the non-recursive version, which is O(n) in the number of
>> samples. This is why I recommended the recursive version, which is O(log n)
>> in the number of samples and thus avoids the problem with big lengths.
>> It is f
lzwenc stores a function pointer to either put_bits or put_bits_le;
however, after the recent change, the function pointer's prototype
would depend on BitBuf. BitBuf is defined in put_bits.h, whose
definition depends on whether BITSTREAM_WRITER_LE is #defined or not.
For safety, we set a boolean fl
On Sun, Jul 19, 2020 at 08:20:40PM +0200, Paul B Mahol wrote:
>> If you can explain what you mean the difference between radial and zoom blur
>> is, it would probably be possible to adapt the idea.
> That algorithm is very slow for big lengths, it takes ages to process
> single small image.
Yes, t
On Sun, Jul 19, 2020 at 07:48:47PM +0200, Andreas Rheinhardt wrote:
> The reason is probably that gif and tiff (the two users of this) use
> different endianness (gif uses LE). A scenario like
>
> #include "lzw.h"
> #define BITSTREAM_WRITER_LE
> #include "put_bits.h"
>
> would be silently broken
On Sun, Jul 19, 2020 at 08:07:27PM +0200, Steinar H. Gunderson wrote:
>> I officially request technical committee to give final decision on this
>> subject.
> I will reiterate that I do not intend to block this patch if you can get some
> other developer to approve it.
I
On Sun, Jul 19, 2020 at 07:32:18PM +0200, Paul B Mahol wrote:
> I see nothing wrong with that image.
Let me provide some zooms. First, center artifacts (the “flower” should not
be there):
http://storage.sesse.net/ffmpeg-radialblur3-zoom1.png
Then, staircase/uneven horizontal line near the edge
On Sun, Jul 19, 2020 at 07:37:15PM +0200, Paul B Mahol wrote:
> I officially request technical committee to give final decision on this
> subject.
I will reiterate that I do not intend to block this patch if you can get some
other developer to approve it.
/* Steinar */
--
Homepage: https://www.
On Sun, Jul 19, 2020 at 06:37:16PM +0200, Paul B Mahol wrote:
> About radial blur center issues, i think Steinar is confusing radial
> blur with zoom blur.
I must admit I don't know any such difference; this is one of many things
that would be useful to have in comments or the commit message (many
lzwenc stores a function pointer to either put_bits or put_bits_le.
Update the function pointer's prototype after the recent change.
---
libavcodec/lzw.h| 4 +++-
libavcodec/lzwenc.c | 4 ++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavcodec/lzw.h b/libavcodec/lzw.h
in
On Sun, Jul 19, 2020 at 03:58:32PM +0200, Nicolas George wrote:
>> Will apply.
> Certainly not before Steinar has had time to review it and tell us
> whether you addressed all the concerns.
The primary change that I see is the addition of bilinear filtering in the
polar to Cartesian step. This mak
On Sat, Jul 18, 2020 at 04:59:21PM +0200, Paul B Mahol wrote:
>> Is it good that it's slow? Or do you mean that the algorithm isn't actually
>> slow?
> It is pretty fast here.
Could you quantify what you mean by “pretty fast”? (Is it fast also measured
in CPU time, or only if you have a bunch of c
Change BitBuf into uint64_t on 64-bit x86. This means we need to flush the
buffer less often, which is a significant speed win. All other platforms,
including all 32-bit ones, are unchanged. Output bitstream is the same.
All API constraints are kept in place, e.g., you still cannot put_bits()
more
Preparatory patch for making the bit buffer different size on different
platforms; make a typedef and make all the hardcoded sizes into expressions
deriving from this size.
No functional change; generated assembler is near-identical.
---
libavcodec/mpegvideo_enc.c | 2 +-
libavcodec/put_bits.h
On Sat, Jul 18, 2020 at 01:34:55PM +0200, Michael Niedermayer wrote:
> this from libavcodec/mpegvideo_enc.c
> set_put_bits_buffer_size(&s->pb,
> FFMIN(s->thread_context[i]->pb.buf_end - s->pb.buf, INT_MAX/8-32));
> needs to be updated too
OK. Including in v3, sending shortly.
/* Ste
On Sat, Jul 18, 2020 at 01:53:36PM +0200, Carl Eugen Hoyos wrote:
>> +#if ARCH_AARCH64 || ARCH_IA64 || ARCH_MIPS64 || ARCH_SPARC64 || ARCH_X86_64
> I suggest to only do this for the platforms that you actually tested.
OK. If so, that's x86-64 only.
/* Steinar */
--
Homepage: https://www.sesse.ne
On Sat, Jul 18, 2020 at 01:31:49PM +0200, Paul B Mahol wrote:
>> In short, this patch has:
>>
>> - An unusually slow algorithm (sin, cos, atan, division; all per-pixel).
> This is actually good.
Is it good that it's slow? Or do you mean that the algorithm isn't actually
slow?
> Performance is no
On Sat, Jul 18, 2020 at 11:53:44AM +0200, Michael Niedermayer wrote:
>> +#if ARCH_AARCH64 || ARCH_IA64 || ARCH_MIPS64 || ARCH_SPARC64 || ARCH_X86_64
> this needs a #include "config.h" or something equivalent
Sounds right, will fix.
/* Steinar */
--
Homepage: https://www.sesse.net/
__
On Sat, Jul 18, 2020 at 12:53:18PM +0200, Paul B Mahol wrote:
> Nope, algorithm is just fine. You are interpreting results wrongly.
If you are not willing to tell me what is wrong with my interpretation
(outside “you are using the wrong parameters, and I won't tell you what the
right parameters ar
On Sat, Jul 18, 2020 at 11:06:17AM +0200, Paul B Mahol wrote:
The above picture pretty clearly shows otherwise...? Could you tell me
where my confusion would lie?
>>> The filter option amount/angle set is very small.
>> It's the default value. Could you recommend a command line?
> Unless
On Sat, Jul 18, 2020 at 10:28:21AM +0200, Paul B Mahol wrote:
>> The above picture pretty clearly shows otherwise...? Could you tell me where
>> my confusion would lie?
> The filter option amount/angle set is very small.
It's the default value. Could you recommend a command line?
/* Steinar */
--
On Sat, Jul 18, 2020 at 10:17:27AM +0200, Paul B Mahol wrote:
>> https://storage.sesse.net/ffmpeg-radialblur.png
> You are deeply confused, filters are working just fine.
The above picture pretty clearly shows otherwise...? Could you tell me where
my confusion would lie?
/* Steinar */
--
Homep
On Sun, Jul 12, 2020 at 01:01:07PM +0200, Paul B Mahol wrote:
> +@section rblur
> +Apply Radial blur filter.
I tried this; it looks very aliased and absolutely not like what I'd expect
from a
radial blur at all.
$ wget
https://upload.wikimedia.org/wikipedia/commons/thumb/c/c1/PM5644.svg/1000p
Change BitBuf into uint64_t on all supported 64-bit platforms.
This means we need to flush the buffer less often, which is a
significant speed win. 32-bit platforms are unchanged.
Output bitstream is the same.
All API constraints are kept in place, e.g., you still cannot put_bits()
more than 31 bi
Preparatory patch for making the bit buffer different size on different
platforms; make a typedef and make all the hardcoded sizes into expressions
deriving from this size.
No functional change; generated assembler is near-identical.
---
libavcodec/put_bits.h | 95 +++-
On Fri, Jul 17, 2020 at 09:48:42PM +0200, Paul B Mahol wrote:
> Missing magicyuv benchmark.
I didn't intend to do every single codec, but sure:
magicyuv 57.10 fps -> 63.29 fps (+10.8%)
/* Steinar */
--
Homepage: https://www.sesse.net/
_
Change BitBuf into uint64_t on all supported 64-bit platforms.
This means we need to flush the buffer less often, which is a
significant speed win. 32-bit platforms are unchanged.
Output bitstream is the same.
All API constraints are kept in place, e.g., you still cannot put_bits()
more than 31 bi
Preparatory patch for making the bit buffer different size on different
platforms; make a typedef and make all the hardcoded sizes into expressions
deriving from this size.
No functional change; generated assembler is near-identical.
---
libavcodec/put_bits.h | 95 +++-
On Fri, Jul 17, 2020 at 08:00:31PM +0200, Paul B Mahol wrote:
>>> But crucial info is missing. How one build vectors?
>> (point - center) * scale_factor + center
> And how to pick scale_factor,
It's a user parameter. scale_factor signifies how long the blur is.
1.0 is no blur, 2.0 means every poin
On Fri, Jul 17, 2020 at 06:54:40PM +0200, Paul B Mahol wrote:
> But crucial info is missing. How one build vectors?
(point - center) * scale_factor + center
> And what about circular blur?
I've never seen anyone try it, but one would assume it can be done by
blending rotations in a similar recur
On Fri, Jul 17, 2020 at 02:24:44PM +0200, Paul B Mahol wrote:
>> Do you have any benchmarks on this? Or image samples? It looks like you are
>> transforming to polar coordinates, doing a box blur and then transforming
>> back... how does this compare speed- and quality-wise to the more common
>> re
On Sun, Jul 12, 2020 at 01:01:07PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
Do you have any benchmarks on this? Or image samples? It looks like you are
transforming to polar coordinates, doing a box blur and then transforming
back... how does this compare speed- and quality-wise t
On Thu, Jul 16, 2020 at 06:34:31PM -0300, James Almer wrote:
>> static AVMutex codec_mutex = AV_MUTEX_INITIALIZER;
>> +static const uint8_t usa_country_code = 0xB5;
>> +static const uint16_t smpte_provider_code = 0x003C;
>> +static const uint16_t smpte2094_40_provider_oriented_code = 0x0001;
>> +s
On Tue, Jul 07, 2020 at 01:30:52PM +0200, Nicolas George wrote:
>> We don't live in a world of innocence. Enabling "less secure" applications
>> is trouble waiting to happen.
> Please don't believe that "less secure" applications are actually less
> secure. The only thing they are less secure for i
On Sun, Jul 05, 2020 at 11:42:19PM +, Soft Works wrote:
> When then reviewer would not have to look for code style and could
> assume that this is all right, he would be free to focus on the actual things.
FWIW: At work, we went to clang-format to simply automate away 90%
of these things compl
On Sun, Jul 05, 2020 at 10:50:14PM +0200, Michael Niedermayer wrote:
> At least for me the reason to not review a patch is often simply
> time.
> But i agree the amount of not reviewed patches is a problem.
>
> [...]
>
> The second thing is more reviews.
> That can happen by
> * More reviewers
> *
On Sun, Jul 05, 2020 at 08:13:25PM +0200, Manolis Stamatogiannakis wrote:
> As a fresh contributor, setting up git send-email was a hassle, but
> not an insurmountable obstacle.
Speaking only for myself, having sent a single-digit number of patches
to FFmpeg ever: Setting up git send-email was not
On Sun, Jul 05, 2020 at 03:42:34PM +0200, Manolis Stamatogiannakis wrote:
> Q2: In a patchset consisting of several commits, is each commit expected to
> be "standalone"? I.e. does it have to apply cleanly without depending on
> the previous commits in the patchset?
No, but it has to compile and w
On Fri, Jul 03, 2020 at 10:42:04PM +0200, Michael Niedermayer wrote:
> 230 v = av_be2ne16(((uint16_t *)s->bytestream)[j]);
Dereferencing an unaligned uint16_t* is UB, indeed. I've seen similar code
break on ARM, with no -ftree-vectorize.
/* Steinar */
--
Homepage: https://w
On Tue, Jun 30, 2020 at 12:00:24PM +0200, Paul B Mahol wrote:
> So we should suffer instead by applying this patch?
The thousands of projects that include FFmpeg from C++, directly or
indirectly, suggests that the amount of suffering on FFmpeg's part
by supporting inclusion from C++ is not going t
HEVC is left chroma like H.264, so add the proper location on init.
Signed-off-by: Steinar H. Gunderson
---
libavcodec/hevcdec.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index c9e28f5826..3306cf3702 100644
--- a/libavcodec/hevcdec.c
+++ b
On Fri, Jan 04, 2019 at 05:28:03PM +0100, Vittorio Giovara wrote:
> size_t really seems the right choice here
Out of curiosity; if it's important to support as large resolutions
as you can address in memory, what would you do with a 1bpp format
on a 32-bit system, where one could easily store more
On Wed, Jan 02, 2019 at 04:34:28PM +0100, Nicolas George wrote:
> This is not a leak, it is short-sightedness by leak detectors.
Most modern leak detectors distinguish between memory that's still reachable
(usually not a leak) and memory that's not (almost always a leak). This sounds
like an examp
On Wed, Dec 05, 2018 at 09:31:48AM +0100, Steinar H. Gunderson wrote:
>> We don't have a solution for that, and its really something the user
>> application currently has to solve.
> The user application doesn't feel like the right place for this. How would it
> be in a
On Sat, Dec 22, 2018 at 09:32:35PM +0100, Paul B Mahol wrote:
>> 2. Return YCC mislabeled as something else, which will look even more
>> wrong.
> 4. Leave user to do conversion as he wish.
That's essentially the same as #2, no?
/* Steinar */
--
Homepage: https://www.sesse.net/
__
On Sat, Dec 22, 2018 at 09:18:11PM +0100, Paul B Mahol wrote:
> Unacceptable, I'm not adding another yuv420p variant.
Well, if returning YCC as YCC is unacceptable, and converting YCC to RGB is
unacceptable, I believe your only choices are:
1. Try to convert YCC to Y'CbCr ignoring the gamma cur
On Sat, Dec 22, 2018 at 09:04:26PM +0100, Paul B Mahol wrote:
> I can not accept internal conversion to RGB. This is subsampled format
> after all.
Well, it's not Y'CbCr, so if so, you'd need to add a new AVPixelFormat value
(e.g. AV_PIX_FMT_YCC420P). I'm not sure what applications would do with i
On Sat, Dec 22, 2018 at 09:53:16AM +0100, Paul B Mahol wrote:
>> FFmpeg doesn't have a good understanding of gamma (it rarely actually
>> converts between different gamma ramps), but that's not a problem with
>> PhotoCD per se. I can't find a good reason why FFmpeg could not be
>> extended with con
On Fri, Dec 21, 2018 at 05:07:45PM +0100, Paul B Mahol wrote:
> The colors that PhotoCD uses predates color space definitions.
Really? It looks fairly well-defined to me, though esoteric
(the gamma ramp is basically like sRGB but with a much bigger constant,
and the 8-bit Y'CbCr scaling seems unus
On Wed, Dec 05, 2018 at 01:33:12AM +0100, Hendrik Leppkes wrote:
> The real problem is that its impossible to know which component to
> really trust. Why does a demuxer have more authority on the color
> format then a decoder? Or vice-versa?
You can make this arbitrarily complicated, of course, bu
On Wed, Dec 05, 2018 at 12:57:43AM +0100, Hendrik Leppkes wrote:
> These comments are not accurate. avformat does not fill these values,
> because outside of deprecated code it does not expose such a struct to
> the user.
Hm, I was asked on #ffmpeg-devel to update it :-) But I suppose maybe it set
On Wed, Dec 05, 2018 at 12:31:10AM +0100, Steinar H. Gunderson wrote:
> Some demuxers, like Matroska, allow for sending colorspace information
> that override MJPEG defaults when it comes to Y'CbCr coefficients or
> chroma location. Don't override such data if the demuxer a
Some demuxers, like Matroska, allow for sending colorspace information
that override MJPEG defaults when it comes to Y'CbCr coefficients or
chroma location. Don't override such data if the demuxer already has
set it; this allows decoding such MJPEG streams correctly.
Also document in avcodec.h tha
On Mon, Jun 04, 2018 at 01:57:36PM +0530, Robert Clove wrote:
> ohk, then what should i do to convert RTP packets to H.264.
> But what i know is if i do ffmpeg -i rtp://stream -an -vcodec copy
> stream.264 we get the output file as h.264 then why not ffmpeg will be able
> to convert packet from fil
On Tue, May 15, 2018 at 12:35:45AM +0200, Steinar H. Gunderson wrote:
> Whenever we detect a discontinuity in the incoming stream, ask libopus
> to make up intermediate frames based on the first one we actually have
> after the discontinuity. If the stream contains FEC data (basicall
On Wed, May 16, 2018 at 12:41:05PM +0200, Tomas Härdin wrote:
> This comes up every now and then, and I know there was great opposition
> to it previously from people who have since left the project. If you're
> willing to be the person officially dealing with all "C++-isms" in the
> headers then I
On Wed, May 16, 2018 at 11:41:23AM +0200, Tobias Rapp wrote:
> Yes, I am referring to usage of the libavutil headers in C. If the macro is
> only hidden for C++ and available in C, that would be OK for me. But if the
> static inline function variant would support both C and C++, this would look
> l
s in question?
Signed-off-by: Steinar H. Gunderson
---
libavcodec/libopusdec.c | 86 +++--
1 file changed, 75 insertions(+), 11 deletions(-)
diff --git a/libavcodec/libopusdec.c b/libavcodec/libopusdec.c
index 2a97811d18..40ee7b8fec 100644
--- a/libavcodec/lib
On Thu, Aug 03, 2017 at 08:21:09AM +0300, Maksym Veremeyenko wrote:
>> You should reject bottom field first formats, as NDI explicitly
>> disallows them.
> even if it disallowed, why to drop? may be warning message would be enough?
FWIW, the documentation may say that formats are always TFF, but o
On Thu, Aug 03, 2017 at 08:21:09AM +0300, Maksym Veremeyenko wrote:
>> You should reject bottom field first formats, as NDI explicitly
>> disallows them.
> even if it disallowed, why to drop? may be warning message would be enough?
FWIW, the documentation may say that formats are always TFF, but o
Also add simple FATE tests, based on output produced by the NDI SDK.
---
tests/Makefile | 1 +
tests/fate/speedhq.mak | 9 +
tests/ref/fate/speedhq-422 | 6 ++
tests/ref/fate/speedhq-422-singlefield | 6 ++
4 files changed, 22 ins
Niedermayer, Loren Merritt
sonic.c Alex Beregszaszi
+ speedhq.c Steinar H. Gunderson
srt* Aurelien Jacobs
sunrast.c Ivo van Poorten
svq3.c
The height convention for decoding frames with only a single field made sense
for compatibility with legacy decoders, but doesn't really match the convention
used by NDI, which is the primary (only?) user. Thus, change it to simply
assuming that if the two fields overlap, the frame is meant to be a
On Thu, Aug 03, 2017 at 02:24:17AM +0200, Michael Niedermayer wrote:
> doesnt work
> make -j12 fate-speedhq
> make: *** No rule to make target `fate-speedhq-422', needed by
> `fate-speedhq'. Stop.
>
> make fate-speedhq-422-singlefield
> make: *** No rule to make target `fate-speedhq-422-singlefi
The height convention for decoding frames with only a single field made sense
for compatibility with legacy decoders, but doesn't really match the convention
used by NDI, which is the primary (only?) user. Thus, change it to simply
assuming that if the two fields overlap, the frame is meant to be a
Niedermayer, Loren Merritt
sonic.c Alex Beregszaszi
+ speedhq.c Steinar H. Gunderson
srt* Aurelien Jacobs
sunrast.c Ivo van Poorten
svq3.c
Also add simple FATE tests, based on output produced by the NDI SDK.
---
tests/Makefile | 1 +
tests/fate/speedhq.mak | 7 +++
tests/ref/fate/speedhq-422 | 6 ++
tests/ref/fate/speedhq-422-singlefield | 6 ++
4 files changed, 20 inser
Niedermayer, Loren Merritt
sonic.c Alex Beregszaszi
+ speedhq.c Steinar H. Gunderson
srt* Aurelien Jacobs
sunrast.c Ivo van Poorten
svq3.c
Also add simple FATE tests, based on output produced by the NDI SDK.
---
tests/Makefile | 1 +
tests/fate/vcodec.mak | 2 ++
tests/ref/fate/speedhq-422 | 6 ++
tests/ref/fate/speedhq-422-singlefield | 6 ++
4 files changed, 15 insertions
The height convention for decoding frames with only a single field made sense
for compatibility with legacy decoders, but doesn't really match the convention
used by NDI, which is the primary (only?) user. Thus, change it to simply
assuming that if the two fields overlap, the frame is meant to be a
On Wed, Aug 02, 2017 at 03:18:49AM +0200, Michael Niedermayer wrote:
> This seems to break a full "make fate"
OK, removing the offending line and resending.
/* Steinar */
--
Homepage: https://www.sesse.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ff
On Wed, Aug 02, 2017 at 12:48:38AM +0200, Steinar H. Gunderson wrote:
> Also add simple FATE tests, based on output produced by the NDI SDK.
Here are the required samples. I couldn't find much documentation on how to
add tests to FATE, so everything has been done by cargo culting.
/*
odecs:
smvjpegdec.c Ash Hughes
snow* Michael Niedermayer, Loren Merritt
sonic.c Alex Beregszaszi
+ speedhq.c Steinar H. Gunderson
srt* Aurelien J
The height convention for decoding frames with only a single field made sense
for compatibility with legacy decoders, but doesn't really match the convention
used by NDI, which is the primary (only?) user. Thus, change it to simply
assuming that if the two fields overlap, the frame is meant to be a
The quantization table is stored in the natural order, but when we
access it, we use an index that's in zigzag order, causing us to read
the wrong value. This causes artifacts, especially in areas with
horizontal or vertical edges. The artifacts look a lot like the
DCT ringing artifacts you'd expec
mple.
Could you please try the attached patch?
/* Steinar */
--
Homepage: https://www.sesse.net/
>From d1c914f869edfc4326e86b1b0c161249196e6900 Mon Sep 17 00:00:00 2001
From: "Steinar H. Gunderson"
Date: Wed, 1 Feb 2017 17:19:18 +0100
Subject: [PATCH] speedhq: fix out-of-bounds wri
On Wed, Feb 01, 2017 at 02:17:05AM +0100, Andreas Cadhalpun wrote:
>> Would you mind sharing an input where this actually triggers? None of the
>> samples I have seem to trigger this, so I suppose it's some sort of fuzzed
>> input.
> Indeed it is. I've sent you a sample.
Thanks; I see what is happ
On Tue, Jan 31, 2017 at 01:57:31AM +0100, Andreas Cadhalpun wrote:
>> This sounds like a strangeness in constructing the table, which shouldn't be
>> papered over in the inner loop of the decoder.
> Maybe, I don't know what the contents of the table should be, but the
> following
> are {-1, 0}: 32
On Tue, Jan 31, 2017 at 12:49:56AM +0100, Andreas Cadhalpun wrote:
>> How can you get a negative run, which would be required for this to happen?
> Some values in ff_dc_alpha_run_vlc_le.table are negative, e.g.:
> ff_dc_alpha_run_vlc_le.table[32] = {-1, 0}
This sounds like a strangeness in constr
On Mon, Jan 30, 2017 at 02:31:08AM +0100, Andreas Cadhalpun wrote:
> Fixes out-of-bounds writes.
Hi,
How can you get a negative run, which would be required for this to happen?
/* Steinar */
--
Homepage: https://www.sesse.net/
___
ffmpeg-devel mailing
Seemingly ff_clear_block_sse assumed that the block array is aligned,
so make sure it is.
---
libavcodec/speedhq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
index 9c21c0b1be..30160dd3f2 100644
--- a/libavcodec/speedhq.c
+++ b/li
On Thu, Jan 12, 2017 at 04:59:33PM +, Andy Furniss wrote:
> I've seen plenty of "legal" shrinks looking at tcpdumps - usually the
> app is throttling it's read speed.
You're not really allowed to shrink by more than you've received, though,
are you? Typically the buffer going down is just that
On Sun, Jan 08, 2017 at 02:14:54PM +0100, Steinar H. Gunderson wrote:
> Allows more codecs than mpeg12video to make use of it.
> ---
48h ping. (I realize I should maybe have reset the commit date so that it
doesn't sort odd.) Is there anything else that I should do about thi
On Mon, Jan 09, 2017 at 09:44:42PM +0100, Michael Niedermayer wrote:
> anything that works and is thread safe is fine with me
> pick what you prefer from what people like
I did the ff_thread_once() variant. v4 coming up.
Fuzzing has been running for 22 hours now with no results at all (2.5B execs
ntext *gb, int component)
{
int code, diff;
diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
new file mode 100644
index 000000..83a95a02dd
--- /dev/null
+++ b/libavcodec/speedhq.c
@@ -0,0 +1,663 @@
+/*
+ * NewTek SpeedHQ codec
+ * Copyright 2017 Steinar H. Gunderson
+ *
+ * This f
Allows more codecs than mpeg12video to make use of it.
---
libavcodec/bitstream.c | 8
libavcodec/mathops.h | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/bitstream.c b/libavcodec/bitstream.c
index 6c8dca1d85..c26650099f 100644
--- a/libavcodec/b
On Mon, Jan 09, 2017 at 08:17:18PM +0100, Michael Niedermayer wrote:
>> +/* Reverse the AC VLC, because INIT_VLC_LE wants it in that order.
>> */
>> +for (i = 0; i < FF_ARRAY_ELEMS(speedhq_vlc); ++i) {
>> +speedhq_vlc[i][0] = reverse(speedhq_vlc[i][0],
>> speedhq_vlc[i
On Mon, Jan 09, 2017 at 06:47:12PM +0100, Paul B Mahol wrote:
> If get_vlc2 fails, and return negative number and this does not cause crash
> than patch LGTM.
There's no crash no matter what decode_dc_le() returns, just a bogus DC
coefficient.
/* Steinar */
--
Homepage: https://www.sesse.net/
__
On Mon, Jan 09, 2017 at 06:30:52PM +0100, Paul B Mahol wrote:
>> +/* AC codes: Very similar but not identical to MPEG-2. */
>> +static uint16_t speedhq_vlc[123][2] = {
> Can this be uint8_t too?
No, it goes into an RLTable, which expects an uint16_t*. Besides, after
bit-reversing, several elements
ntext *gb, int component)
{
int code, diff;
diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
new file mode 100644
index 000000..3c011e3862
--- /dev/null
+++ b/libavcodec/speedhq.c
@@ -0,0 +1,658 @@
+/*
+ * NewTek SpeedHQ codec
+ * Copyright 2017 Steinar H. Gunderson
+ *
+ * This f
Allows more codecs than mpeg12video to make use of it.
---
libavcodec/bitstream.c | 8
libavcodec/mathops.h | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/bitstream.c b/libavcodec/bitstream.c
index 6c8dca1d85..c26650099f 100644
--- a/libavcodec/b
On Sun, Jan 08, 2017 at 01:45:07PM +0100, Paul B Mahol wrote:
>> +memcpy(rbuf, buf, buf_size);
>> +memset(rbuf + buf_size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> Huh?!? Is this needed at all?
After some discussion on IRC: It turns out that avcodec_decode_video2()
requires the input AVPacket t
On Sun, Jan 08, 2017 at 11:01:14AM -0300, James Almer wrote:
> Disregard that part then. Just address the name of the function.
Will do. Waiting with sending of a new patch to see if there are more
comments coming that I can address in the same batch.
/* Steinar */
--
Homepage: https://www.sesse
1 - 100 of 108 matches
Mail list logo
