On 8/24/2017 9:04 PM, Derek Buitenhuis wrote:
> From: Derek Buitenhuis <derek.buitenh...@gmail.com>
>
> Fixes:
>
> libswscale/utils.c:1632:5: warning: macro expansion producing 'defined'
> has undefined behavior [-Wexpansion-to-defined]
> #if USE_MMAP
&
From: Derek Buitenhuis <derek.buitenh...@gmail.com>
Fixes:
libswscale/utils.c:1632:5: warning: macro expansion producing 'defined' has
undefined behavior [-Wexpansion-to-defined]
#if USE_MMAP
^
libswscale/utils.c:1577:49: note: expanded from macro 'USE_MMAP'
#
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
Circa November 2015.
---
libavcodec/aasc.c | 1 +
libavcodec/aic.c | 1 +
libavcodec/anm.c | 1 +
libavcodec/ansi.c | 1 +
libavcodec/aura.c | 1 +
libavcodec/avs.c
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
libavcodec/hevcdec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 700b5f09a0..48045fb11b 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -3091,5 +
Sample is here:
https://trac.ffmpeg.org/attachment/ticket/5458/nondeterministic_cut.h264
Can be reproduced using 13 or more frame threads to decode.
This email is a professional courtesy.
Derek Buitenhuis (2):
h264_slice: Wait for refs to be available before we use them in error
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
tests/fate/h264.mak | 2 ++
tests/ref/fate/h264-missing-frame | 31 +++
2 files changed, 33 insertions(+)
create mode 100644 tests/ref/fate/h264-missing-frame
diff --git a/tests/fat
This could happen when there was a frame number gap and frame threading was
used.
Debugging-by: Ronald S. Bultje <rsbul...@gmail.com>
Debugging-by: Justin Ruggles <justin.rugg...@gmail.com>
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
libavcodec/h264_slice
From: Derek Buitenhuis <derek.buitenh...@gmail.com>
This is in the same the same vein as 380146924ecad2e05e9dcc5c3c2e1b5ba47c51e8.
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
A professional courtesy.
---
libavcodec/libx265.c | 5 -
libavcodec/version.h | 2
This breaks files with legitimate single-entry edit lists,
and the hack, introduced in f03a081df09f9c4798a17d7e24446ed47924b11b,
has no link to any known sample in its commit message.
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
libavformat/isom.h | 1 -
libavformat
I ran into issues with these at work, and fixed them in FFmpeg.
I've rebased them on Libav and am sending them as a professional courtesy.
Keep in mind I'm still unscubscribed from both lists, so relevant comments
may need to be CC'd to me if you feel something needs changing.
Cheers.
Derek
This was added before edts support existed, and is no longer
valid.
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
libavformat/mov.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 89c2c23..ca49716 100644
--- a/libavformat
On 5/9/2016 5:13 PM, Vittorio Giovara wrote:
> *on gcc 4.4.
On all compilers. 4.4 just happened to hit it.
- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 5/9/2016 2:16 PM, Luca Barbato wrote:
> Let me sum up the evolution:
>
> - The functions had their max range embedded
> - people used to have the exact range complained
>
> - Considering their complaint valid, Alexandra accepted to use another
> set of names.
>
> - Then somebody
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
libavcodec/mjpegdec.c | 52 +++
1 file changed, 28 insertions(+), 24 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 5625929..1f36b39
On 5/7/2016 11:35 AM, Alexandra Hájková wrote:
> -if (get_bits_long(gb, 32) != MKBETAG('A','L','S','\0'))
> +if (bitstream_read_narrow(bc, 32) != MKBETAG('A','L','S','\0'))
To me, this change pretty much highlights how confusing the new vague
names are. I can't even tell if this change is
On 5/9/2016 11:41 AM, Alexandra Hájková wrote:
> I was foolowing the ML discussion and used the names the majority agreed on,
> however I can never satisfy everyone. I'd suggest to consider naming
> bikesheding to be over.
I must admit though, for people who complain the old names are too
On 5/5/2016 1:58 PM, wm4 wrote:
> But I don't understand why my sample file has this 0-sized packet.
If it's an MP4, then it's the index that has them coded like that.
You can look at them with boxdumper.
- Derek
___
libav-devel mailing list
On 5/4/2016 8:40 PM, wm4 wrote:
> This fixes behavior with "legitimate" 0-sized packets that appear mid-
> stream, and which are _not_ flush packets.
I still do not think these packets are "legitimate".
The correct fix is to make sure lavf doesn't return 0-sized packets, no?
Can anyone inform
On 5/4/2016 11:01 PM, Diego Biurrun wrote:
> This default was chosen when there was still some amount of
> general-purpose code under GPL. Now only special modules are covered by
> GPL. When enabling those modules, one can turn on GPL along with them.
> ---
> tests/fate.sh | 1 -
> 1 file
On 5/3/2016 5:19 PM, Vittorio Giovara wrote:
> You know, the best way to make a dev care about some code is making
> sure that that code is present in that dev's project.
> I'm sure Alexandra will happily update her patchset when that poc is
> present in Libav.
IIRC someone is already working on
On 4/29/2016 9:13 AM, Christophe Gisquet wrote:
> The results are interesting:
> time / size / decode_gray_bitstream _TIMER
> 4.16 / 34236 / 190887 UNITS in gray, 262143 runs, 1 skips
> 6.41 / 16080 / 283210 UNITS in gray, 262144 runs, 0 skips
I'm not entirely sure how to interpret these...
On 4/27/2016 1:56 PM, Alexandra Hájková wrote:
> I sent this small RFC patchset to be discussed and I'm waiting for
> all the opinions
You can surely reply to the opinions/questions in the current mails though.
- Derek
___
libav-devel mailing list
On 4/21/2016 10:24 PM, Vittorio Giovara wrote:
> +size_t len = atom.size - sizeof(uuid);
> +uint8_t *buffer = av_malloc(len + 1);
> +if (!buffer)
> +return AVERROR(ENOMEM);
> +buffer[len] = '\0';
> +
> +ret = ffio_read_size(pb, buffer, len);
On 4/25/2016 1:25 PM, Martin Storsjö wrote:
> ---
> libavformat/movenc-test.c | 40
> tests/ref/fate/movenc | 2 ++
> 2 files changed, 42 insertions(+)
Unrelated to the patch, but at this point, it may be worth pointing to this
file as an example of
On 4/25/2016 1:25 PM, Martin Storsjö wrote:
> Previously, zero sized packets can be used to signal the nominal
> start time for a track, when muxing discontinuously. (That is,
> to indicate that the track starts at dts=-1, pts=0, while starting
> to mux from dts=99,pts=100, for muxing individual
On 4/25/2016 1:25 PM, Martin Storsjö wrote:
> If a packet is empty, and the muxer is flagged to treat such packets
> specially, don't update cur_dts, to allow a packet with the same
> timestamp to be written again later.
> ---
> libavformat/mux.c | 5 -
> 1 file changed, 4 insertions(+), 1
On 4/25/2016 1:25 PM, Martin Storsjö wrote:
> As long as caller only writes packets using av_interleaved_write_frame
> with no manual flushing, this should allow us to always have accurate
> durations at the end of fragments, since there should be at least
> one queued packet in each stream
On 4/25/2016 1:25 PM, Martin Storsjö wrote:
> This doesn't work for the few muxers that implement custom
> interleave_packet functions (gxfenc, mxfenc). It seems to me that
> they also could be covered, but that would require changing the
> signature of the interleave_packet function to split
On 4/25/2016 2:56 PM, Luca Barbato wrote:
> avformat_mux_queue_pull() <- remove from the queue
Would 'pop' not be more descriptive, since it is removed
and ownership is transfered?
Regardless, I have no strong feelings one way or another.
- Derek
___
On 4/27/2016 12:37 PM, Alexandra Hájková wrote:
> ---
> libavutil/attributes.h | 6 ++
> 1 file changed, 6 insertions(+)
Just for documentation reasons for people not on IRC:
[13:58] <@Daemon404> if it can be *proven* to speed up very core bits like
bitreading, i am not adverse to using it
On 4/27/2016 1:41 PM, Christophe Gisquet wrote:
> I guess this should be used sparingly, and with benchmark reports to
> back the few cases.
The problem with measuring perf for likely/unlikely is that half the time
it's either negligible or impossible to measure consistently. That's part
of what
On 4/27/2016 12:35 PM, Alexandra Hájková wrote:
> Greetings,
> I'd like to introduce a new bitstream reader I wrote. The advantages of the
> new bitreader are:
> * it is easier to use:
> for example there is just one function to read 0-32 bits instead of
> 3 of them in the get_bits.h
> * it
On 4/25/2016 5:19 PM, Vittorio Giovara wrote:
> I'm ok with lowering the limit of some percentage to accommodate
> random resolutions, but you can't really call HD what is not.
Semantics vs practicality.
- Frtrk
___
libav-devel mailing list
On 4/19/2016 12:08 PM, Martin Storsjö wrote:
> This codepath isn't quite as bad as it used to sound, if fragments
> are cut automatically at video packets.
> ---
> This is mostly a note to future self.
> ---
> libavformat/movenc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
LGTM.
On 4/6/2016 4:12 AM, Tim W. wrote:
> It is ugly, but AFAICT that's libxvid's fault; other solution I can imagine
> would be to create fake extradata like Anton did for QSV/HEVC/VPS, which is
> a lot more work for little benefit.
Definitely not worth it for this. Because SO many people encode xvid
On 4/5/2016 5:18 PM, Luca Barbato wrote:
>> +xerr = xvid_encore(NULL, XVID_ENC_CREATE, _enc_create, NULL);
>> +if( xerr ) {
>
> Meh, I'll fix it for you if nothing else crops up.
You should really explain *what* you'll fix, otherwise the review
is useless and I learn nothing new.
Modifying global header extradata in encode_frame is an API violation
and only happens to work currently because mov writes its header
at the end of the file.
Heavily based off of a patch from 2012 by Nicolas George.
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
Fixes en
Some context:
https://mailman.videolan.org/pipermail/vlc-devel/2016-February/106310.html
Basically, I would like to propose the following:
In the future, for major version bumps, we should push the commit
which bumps the version before the big list of commits that remove
all the deprecated
On 2/23/2016 1:17 AM, Vittorio Giovara wrote:
> ---
> The test sample is already on FATE strangely enough.
> Vittorio
>
> tests/fate/microsoft.mak| 3 +
> tests/ref/fate/wmv8-intrax8 | 475
>
> 2 files changed, 478 insertions(+)
> create mode
On 2/20/2016 7:36 PM, Vittorio Giovara wrote:
> I am able to reproduce with that exact same line, on OSX, with clang and gcc
A real (ports) GCC or the llvm-gcc that apple ships?
Could be the same DCE bug if so?
- Derek
___
libav-devel mailing list
This was broken in 243df1351d2d928caa084a5704ed783f0b83f072.
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
The default was changed to be out of range and caused warnings to be
printed for default values.
---
libavcodec/flacenc.c | 4 ++--
1 file changed, 2 insertions
On 1/28/2016 4:11 PM, Henrik Gramner wrote:
> ---
> configure | 1 +
> 1 file changed, 1 insertion(+)
OK.
- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 1/27/2016 10:16 PM, Luca Barbato wrote:
> When it is zero? (isn't there a check before to sanitize the time_base ?)
I only see a check for audio.
- Derek
___
libav-devel mailing list
libav-devel@libav.org
It could accidentally divide by zero if num was zero.
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
libavcodec/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index e06ee66..a3cb341 100644
--- a/liba
This feature is mostly only used by NLE software, and is
both of dubious value being enabled by default, and a
possible security risk.
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
libavformat/isom.h| 1 +
libavformat/mov.c | 20
libav
On 10/22/2015 1:13 PM, Vittorio Giovara wrote:
> This will allow dumping the complete x264 encode info when needed.
strings(1)
- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 1/15/2016 5:10 PM, Luca Barbato wrote:
> ---
>
> Possibly we could drop the 3 lines above.
>
> configure | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Normally I'm all for pkg-config. However for OpenSSL, it
is a system library on some platforms and does not have
a .pc file,
On 1/4/2016 8:32 AM, Anton Khirnov wrote:
> missing the props, probably lossy+intraonly
Some CFHD files seem to have skip frames, so perhaps not the latter?
- Derek
___
libav-devel mailing list
libav-devel@libav.org
On 1/3/2016 8:09 PM, Diego Biurrun wrote:
> This is wrong, not just in name.
Perhaps you should actually say how.
- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 11/27/2015 2:15 PM, Derek Buitenhuis wrote:
> I'm going to be devil's advocate here, and ask:
>
> Why was this written from scratch, rather than backporting
> from FFmpeg, which already has a fully working implementation?
> What technical advantages does it bring?
>
>
On 11/23/2015 12:05 PM, Luca Barbato wrote:
> -@item Building natively using MSYS2 can be sped up by disabling implicit
> rules
> -in the Makefile by calling @code{make -r} instead of plain @code{make}. This
> +@item Native MSYS building is discouraged, MSYS2 provides a full mingw-w64
>
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
libavformat/oggparsespeex.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/oggparsespeex.c b/libavformat/oggparsespeex.c
index f7af794..3cc9012 100644
--- a/libavformat/oggparsespeex.c
+++ b/libav
On 11/21/2015 10:51 AM, Henrik Gramner wrote:
> Is there any downside of making stuff "just work" (tm) with the
> default msys shell?
Yes. The default msys2 shell may have 'gcc' as the msys compiler.
That is, not mingw, but a special compiler that compiles the system
binaries for msys, like
On 11/9/2015 6:35 AM, Anton Khirnov wrote:
> This is just for mpeg2 video. I have no idea what it does for othe
> codecs.
Intra-only mpeg-2 in mxf is pretty common...
- Derek
___
libav-devel mailing list
libav-devel@libav.org
Random lazy questions incoming.
On 11/13/2015 5:11 PM, Alexandra Hájková wrote:
> Provide a bit-exact reconstruction.
>
> The dca core decoder converts integer coefficients read from the
> bitstream to floats just after reading them (along with dequantization).
> All the other steps of the audio
On 11/8/2015 7:57 PM, Anton Khirnov wrote:
> ---
> libavcodec/libx264.c | 8
> 1 file changed, 8 insertions(+)
Missing libx265.c?
- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 11/8/2015 7:57 PM, Anton Khirnov wrote:
> Checking the codec context parameters to find out this information is
> far too unreliable to be useful, so it is safer to assume B-frames are
> always present.
> ---
> libavformat/mxfenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Isn't
This makes AAC init threadsafe.
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
libavcodec/aacdec.c | 84 +++--
1 file changed, 49 insertions(+), 35 deletions(-)
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index f
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
libavcodec/utils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index a1aece7..430926d 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -845,7
On 10/8/2015 9:08 AM, Rémi Denis-Courmont wrote:
> I would assert and abort here. The most likely problems here are
> deadlocks (i.e. recursive initialization) and memory corruption (once
> ff_h264_vlc_init is garbage)...
I initially had this since Hendrik's patch could fail, but that is no
From: Anton Khirnov <an...@khirnov.net>
There's not much reason to generate such a small table at runtime.
Signed-off-by: Derek Buitenhuis <der...@vimeo.com>
---
libavcodec/cabac.c | 225 ---
libavcodec/cabac.h | 3 +-
This makes the h.264 decoder threadsafe to initialize.
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
libavcodec/h264.c | 9 -
libavcodec/h264.h | 1 +
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 4
Towards a glorious non-locking future.
Anton Khirnov (1):
cabac: Make CABAC states hardcoded.
Derek Buitenhuis (1):
h264: Run VLC init under pthread_once
libavcodec/cabac.c | 225 ---
libavcodec/cabac.h | 3 +-
libavcodec
On 10/7/2015 5:44 PM, Luca Barbato wrote:
> Do you plan to use it outside somehow? The rest seems fine.
No.
- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
libavcodec/utils.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 1721c09..586e7be 100644
--- a/libavcodec/utils.c
On 10/1/2015 4:00 PM, wm4 wrote:
> Is this a preparation for a long, painful transition, or just a way to
> workaround your particular failure case?
Depends what you mean transitioning to.
Currently, I'm just making the existing flag actually *do* something
useful.
(I will be converting codecs
On 10/1/2015 4:16 PM, Hendrik Leppkes wrote:
> Isn't this and the condition above backwards?
Oh, yep! I got confused when backporting from my FFmpeg
version, since it needs the opposite...
- Derek
___
libav-devel mailing list
libav-devel@libav.org
There's no reason this should be required.
Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
---
As far as I know, anyway.
---
libavformat/movenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index ee2f089..9
On 9/23/2015 2:11 PM, Martin Storsjö wrote:
> On Wed, 23 Sep 2015, Derek Buitenhuis wrote:
>
>> There's no reason this should be required.
>>
>> Signed-off-by: Derek Buitenhuis <derek.buitenh...@gmail.com>
>> ---
>> As far as I know, anyway.
>> ---
On 9/22/2015 4:20 PM, Luca Barbato wrote:
> Uhm we have some already.
MSDN must be lying to me...
- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 9/22/2015 12:56 PM, Vittorio Giovara wrote:
> -dist = abs(a - b);
> +dist = llabs(a - b);
I don't think llabs is supported everywhere. e.g. MSVC, I think,
has has only had it since MSVS 2013.
- Derek
___
libav-devel
On 7/23/2015 5:35 PM, Martin Storsjö wrote:
With the MSVC 2013 compiler, using the Windows 10 SDK from VS 2015 RC?
This will never be a supported set up. Ever. It's a hack.
- Derek
___
libav-devel mailing list
libav-devel@libav.org
On 7/23/2015 6:23 PM, Steve Lhomme wrote:
What's the other alternative ? dirname is always used as $(dirname
$xyz) in configure.
Is $(dirname `command -v cl`) not equivalent to $(dirname $(command -v cl))
?
Maybe I am lacking in my shell-fu.
- Derek
On 7/23/2015 6:02 PM, Derek Buitenhuis wrote:
On 7/23/2015 5:41 PM, Steve Lhomme wrote:
Looping in the other list, cause I forgot.
--
favor link over link.exe in case some wrapper script already exists
fallback to link in the path if the one next to cl is not found
---
configure | 2
On 7/23/2015 5:41 PM, Steve Lhomme wrote:
--
favor link over link.exe in case some wrapper script already exists
fallback to link in the path if the one next to cl is not found
---
configure | 2 +-
tools/mslink.sh | 9 +
Should be under compat.
diff --git a/tools/mslink.sh
On 7/2/2015 12:42 PM, Steve Lhomme wrote:
What version of Windows is Wine equivalent to these days ?
One that doesn't exist.
It implements APIs as they are needed, so it's a mishmash.
- Derek
___
libav-devel mailing list
libav-devel@libav.org
Any other x265 symbol may not exported, e.g. if the build is a
multilib (10-bit and 8-bit in one) build.
This is the only symbol we directly call, and is available in the
build number we check for.
Fixes the configure check on multilib x265 builds.
Signed-off-by: Derek Buitenhuis derek.buitenh
On 5/31/2015 4:02 PM, Vittorio Giovara wrote:
Although might not be immediately useful, there could be occurrences where it
is.
-- MiNi
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 5/13/2015 10:37 AM, Diego Biurrun wrote:
Forbidding them to contribute to libav is OK in your opinion?
I haven't seen such a thing.
Regardless of that, this is entirely unrelated to the thread at hand
and nothing but trolling. Be less butthurt, it's been years.
Thank you Nicholas for your
On 5/13/2015 9:59 AM, Luca Barbato wrote:
+#if (X265_BUILD = 57)
+#define init_libx265(B) \
+do { \
+ctx-api = x265_api_get((B)); \
+if (!ctx-api) \
+ctx-api = x265_api_get(0); \
+} while (0)
+
+#undef x265_encoder_open
+
+#define x265_param_free(PA)
On 5/12/2015 6:55 PM, Diego Biurrun wrote:
It would be nice if more people from your team worked in that spirit of
cooperation instead of requiring that ffmpeg gsoc students not contribute
to libav.
Requiring that students that air paid to work on ffmpeg, work on ffmpeg,
isn't exactly
On 5/11/2015 5:23 PM, Vittorio Giovara wrote:
+av_log(matroska-ctx, AV_LOG_ERROR,
+ mov FourCC not found %s.\n, buf);
Is this guaranteed to be printable? Should it not be hex?
- Derek
___
libav-devel mailing list
On 5/12/2015 2:48 PM, Vittorio Giovara wrote:
buf is initialized with av_get_codec_tag_string which converts hex to
readable tags
buf should be of size 21 then, no?
e.g.: a tag of 0x - [255][255][255][255] with null terminator.
- Derek
___
On 5/12/2015 3:56 PM, Diego Biurrun wrote:
I have no idea what you are trying to tell me. The reviewer should
fix what the patch submitter failed to fix for n rounds of review?
I'll break it down. Please:
1) Be less condescending.
2) Be consistent between reviews in what you request.
3) Less
On 5/12/2015 3:45 PM, Diego Biurrun wrote:
Reviewer time is precious, so the onus is on the
patch submitter to ease the reviewer's burden.
Everyone's time is precious, and doing N rounds of review and
e.g. finding things the Nth time, that have been present since the
first revision, should not
-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
configure| 4 ++--
libavcodec/libx265.c | 29 +
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/configure b/configure
index f3e5154..5bcc2df 100755
--- a/configure
+++ b/configure
@@ -4268,8
On 5/2/2015 9:34 PM, Martin Storsjö wrote:
It's not irrelevant at all. Previously, the first member of x265_picture
used to be a struct (which would be why the extra braces were added), now
it isn't a struct any longer, causing warnings due to the extra braces. Or
at least this is a
On 5/1/2015 6:28 PM, Luca Barbato wrote:
Which version of x265 ?
Irrelevant. This is in our code.
- Derek
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 5/1/2015 3:39 PM, Vittorio Giovara wrote:
---
libavcodec/libx265.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
http://permalink.gmane.org/gmane.comp.video.libav.devel/50988
- Derek
___
libav-devel mailing list
libav-devel@libav.org
On 4/29/2015 6:01 AM, Anton Khirnov wrote:
I already asked in the last review -- any reason for this to be signed?
This would go infinitely smoother if there were actual responses to reviews,
and not just a giant new patch with no notes on what changed.
My 2 cents.
- Derek
On 4/11/2015 2:04 PM, Diego Biurrun wrote:
Rude is your continued trolling on this mailing list. Please take it back
to your FFmpeg home turf where such behavior is apparently tolerated. It
is not tolerated here.
You are the one who is trolling here Diego.
- Derek
From: James Almer jamr...@gmail.com
Based on code from libavcodec/libx264.c
Signed-off-by: James Almer jamr...@gmail.com
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavcodec/libx265.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git
On 4/10/2015 11:26 AM, Martin Storsjö wrote:
These headers can't be included in any arbitrary order.
---
Updated the comment about winsock2.h vs windows.h; on MSVC it is an error
to include them in the wrong order, while mingw only warns about it.
---
libavdevice/vfwcap.c | 9 ++---
1
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavformat/mpegtsenc.c | 10 +++---
libavformat/version.h | 2 +-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 2340e34..5635a8e 100644
--- a/libavformat
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavformat/mpegtsenc.c | 10 +++---
libavformat/version.h | 2 +-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 28b700e..2340e34 100644
--- a/libavformat
This saves a lot of muxing overhead, especially on lower bitrate
segments.
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavformat/hlsenc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 21c9526
Derek Buitenhuis (3):
mpegtsenc: Allow user to set SDT retransmission period
mpegtsenc: Allow user to set PAT/PMT retransmission period
hlsenc: Only write PAT/PMT once per segment
libavformat/hlsenc.c| 10 +-
libavformat/mpegtsenc.c | 20 ++--
libavformat
On 4/5/2015 7:48 PM, Martin Storsjö wrote:
For things like this, you could use av_opt_set_int. But in this case,
these don't need to be reset for each segment at all, but could be set
just once at startup, via an AVDictionary to avformat_write_header.
All right.
Will send a new patch in a
On 4/5/2015 8:41 PM, Martin Storsjö wrote:
This changes the default value for the CBR case
I know. There was no explanation why it differed. (I also tend to think
separate defaults are just insane.)
We should keep one or the other, but not both.
This is a bit problematic, when one single
From: Michael Niedermayer michae...@gmx.at
Signed-off-by: Michael Niedermayer michae...@gmx.at
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavcodec/libx265.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index
1 - 100 of 1298 matches
Mail list logo
