On 7/13/2014 9:17 PM, Reimar Döffinger wrote:
Well, IMHO if this is a requirement that was added, I would say
it was an API change, and MPlayer might just be the first where
the API change was detected.
Indeed there should have been a version bump in
419ade4b6193c6eb626cda01b21e7091f42b2cc2.
On 7/14/2014 8:15 AM, Reimar Döffinger wrote:
There is also the issue about how much sense the check makes: while I decided
to do it (slightly) more properly, a fix would be to just set width/height
to 320x240 no matter what you actually encode in the end.
This is a bad idea. API users don't
On 7/30/2014 6:10 PM, Nicolas George wrote:
This is tiring. Everyone knows it already and it has been explained numerous
times.
Yeah, why should you have to explain the reason for a change in
a review of that change? How silly. I should just divine the reason
why. I guess we don't count as
On 8/21/2014 12:09 PM, Christophe Gisquet wrote:
I'm not sure it is the best fix, but I don't think this could happen
in any valid file, nor it would help to swallow the error.
Perhaps off-topic, but the source drop from Elemental seems to include
completely rewritten dref code -- is it worth
On 8/21/2014 4:13 PM, Michael Niedermayer wrote:
can you provide a link ?
Provided on IRC.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 8/25/2014 6:46 PM, Gonzalo Garramuno wrote:
It is patented but free to use as long as you use the openexr library.
wat
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 8/26/2014 12:42 AM, Michael Niedermayer wrote:
[...]
tests/lena.pnm | 109
I'm sorry but this is beyond stupid.
We can't use the defacto DSP testing image because it is not *FREE* enough
for Debian? It is utterly asinine to remove
On 8/26/2014 3:47 PM, Andreas Cadhalpun wrote:
We can't use the defacto DSP testing image because it is not *FREE* enough
for Debian? It is utterly asinine to remove it because Debian doesn't want
to distribute Lena with source deb. They can remove it themselves.
You could still use it, just
On 8/28/2014 2:25 AM, James Almer wrote:
wget is not available on a standard Msys installation. Probably the same with
Cygwin.
bc isn't standard either and FATE uses it.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 8/28/2014 1:42 PM, Andreas Cadhalpun wrote:
That's clear. But it doesn't work without internet connection.
So why not use fate-rsync, which is only run manually, when internet is
available?
Probably because it entails reworking the vsynth build system stuff quite
a bit to placate a single
On 9/4/2014 4:33 AM, Reinhard Tartler wrote:
So the promise given in
https://lists.libav.org/pipermail/libav-devel/2012-February/020712.html
doesn't hold anymore?
Any chance to make you reconsider reviving the standalone libpostproc.git?
Guilty party here.
I kinda just neglected it because
On 9/28/2014 3:46 AM, Michael Niedermayer wrote:
applied
Sorry I missed that, been very busy lately.
Luckily the patch seems OK.
Is there a similar flag for SSIM?
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 9/28/2014 2:26 PM, Michael Niedermayer wrote:
i dont think so, also
libxvid and libx264 use private AVOptions for ssim,
OK.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Decided to fuzz some stuff randomly again, using:
https://gist.github.com/dwbuiten/7101755
Derek Buitenhuis (2):
avfilter/aresample: Check for mmemory alloc failure for out sample
rates
avfilter: Properly check for failed format query
libavfilter/af_aresample.c |5
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavfilter/avfiltergraph.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
index 9178939..a859ecb 100644
--- a/libavfilter/avfiltergraph.c
+++ b
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavfilter/af_aresample.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/libavfilter/af_aresample.c b/libavfilter/af_aresample.c
index 5f34321..550da54 100644
--- a/libavfilter/af_aresample.c
+++ b
On 10/2/2014 11:55 AM, Derek Buitenhuis wrote:
avfilter/aresample: Check for mmemory alloc failure for out sample
rates
Typo fixed locally. Woops.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo
On 10/21/2014 8:21 AM, Carl Eugen Hoyos wrote:
This sounds like a very bad idea to me
I agree. It's not nice to have remnants of the build process in the
installed binaries.
If you need to run them during development, use LD_LIBRARY_PATH or
or build statically.
- Derek
On 10/21/2014 10:47 AM, Stefano Sabatini wrote:
-int64_t cur_sample = av_rescale_q(buf-pts, (AVRational){1,
outlink-sample_rate}, outlink-time_base);
+int64_t cur_sample = av_rescale_q(buf-pts, inlink-time_base,
(AVRational){1, inlink-sample_rate});
Probably OK.
- Derek
On 10/21/2014 9:12 AM, Thilo Borgmann wrote:
Subject: [PATCH] lavf/mov.c: Prevent memory leak in case of invalid metadata
reads.
---
libavformat/mov.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
LGTM.
- Derek
___
On 10/21/2014 8:32 AM, Carl Eugen Hoyos wrote:
+The filter only works for strictly constant frame rate input. If your input
+has variable frame rate, try the @ref{pullup} filter.
Perhaps the filter should output a warning as well?
- Derek
___
On 10/21/2014 7:56 AM, James Almer wrote:
No need to keep the old symbols around until a major bump since lavd
functions
with the avpriv_ prefix were never exposed.
lol.
Signed-off-by: James Almer jamr...@gmail.com
---
avpriv_*; can be added to libavdevice.v after this patch, but
On 10/21/2014 10:47 AM, Stefano Sabatini wrote:
- AV_OPT_TYPE_INT, { .i64 = 2 }, 2, INT_MAX, V|A|F},
+ AV_OPT_TYPE_INT, { .i64 = 1 }, 1, INT_MAX, V|A|F},
I'm not sure I follow how this 'allows' n=1? Doesn't this just
change the default?
- Derek
On 10/21/2014 11:22 AM, Stefano Sabatini wrote:
- AV_OPT_TYPE_INT, { .i64 = 2 }, 2, INT_MAX, V|A|F},
+ AV_OPT_TYPE_INT, { .i64 = 2 }, 1, INT_MAX, V|A|F},
OK.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 11/9/2014 11:04 PM, Jan Ehrhardt wrote:
I am using these sources for fdk-aac:
https://github.com/mstorsjo/fdk-aac.git
This is not the repo for fdk-aac and you should not be using it.
FDK-AAC is from:
Releases: http://sourceforge.net/projects/opencore-amr/files/fdk-aac/
Git:
On 11/20/2014 8:40 AM, Benoit Fouet wrote:
LGTM
http://fate.ffmpeg.org/report.cgi?time=20141120142015slot=i686-windows-icl
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 11/28/2014 4:47 PM, Reimar Döffinger wrote:
That doesn't explain why the patch changes the zlib / bz2 include position?
They include it.
e.g.: https://github.com/madler/zlib/blob/master/zconf.h#L321-339
- Derek
___
ffmpeg-devel mailing list
On 12/11/2014 1:09 PM, Michael Niedermayer wrote:
Fixes CID1257656
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/libutvideoenc.cpp |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
OK.
Though I still prefer this file is just removed.
- Derek
If allocation fails earlier on, and thd next frame is processed,
the slice buffer could be left in a state where line and data_stack
have already been freed, or are otherwise null pointers.
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavcodec/snow_dwt.c | 9 +++--
1 file
On 12/16/2014 12:39 AM, Jesse Jiang wrote:
Hi All,
I want to make MSVC build ffmpeg more easily. There is a problem, if we
launch msys.bat which in mingw enviroment, the link.exe in msys will conflict
with link.exe in MSVC.
This is covered in the documentation:
On 12/19/2014 9:09 PM, Thomas Volkert wrote:
+ av_log(s, AV_LOG_ERROR, invalid start code %c%c%c%c in RIFF header\n,
tag 0xFF, (tag 8) 0xFF, (tag 16) 0xFF, (tag 24) 0xFF);
I'm sure printing possibly non-printable chars is a great idea. Nothing
could go wrong.
Use 0x%X or something
On 12/30/2014 9:51 AM, Reimar Döffinger wrote:
So I'll actually change my vote to let's not even try to support such
a braindead idea.
I agree it's a bad idea. We don't do this for libx264 either.
- Derek
___
ffmpeg-devel mailing list
On 12/31/2014 10:00 PM, David Ison wrote:
3. I am planning initial implementations using OpenMP. There is good
support on Gnu, LLVM and other compilers
http://openmp.org/wp/openmp-compilers/.
I think it is probably unlikely that OMP will be accepted for a bunch of
reasons (compiler
On 1/16/2015 9:02 AM, Clément Bœsch wrote:
I believe there is a large perference for C.
Not only that, but our configure is downright broken
for C++ files, so to speak.
We hardcode libstdc++, which is de facto wrong.
- Derek
___
ffmpeg-devel mailing
On 1/16/2015 12:47 AM, Stephen Hutchinson wrote:
There have been times I've run into issues
because a shared library FFmpeg was linked against somehow
got removed or was updated and broke compatibility.
[...]
Dynamic loading allows the main binary to still function
correctly if this occurs,
On 1/21/2015 3:36 PM, Rodger Combs wrote:
-const char *number_format = DASH_TMPL_ID_TIME ? lld : d;
+const char *number_format = (id_type == DASH_TMPL_ID_TIME) ?
lld : d;
Why not inttypes.h format?
- Derek
___
ffmpeg-devel
On 1/21/2015 4:28 PM, Michael Niedermayer wrote:
this is missing pic==NULL checks or should be under the if() above
or something like that
No? It has X265_TYPE_AUTO as the fallback if it is NULL. Just like libx264.c:
On 12/31/2014 3:53 AM, Derek Buitenhuis wrote:
On 12/31/2014 10:00 PM, David Ison wrote:
3. I am planning initial implementations using OpenMP. There is good
support on Gnu, LLVM and other compilers
http://openmp.org/wp/openmp-compilers/.
I think it is probably unlikely that OMP
On 1/21/2015 4:46 PM, Timo Rothenpieler wrote:
No? It has X265_TYPE_AUTO as the fallback if it is NULL. Just like libx264.c:
Is falls back to that if pic-pict_type is NULL, but if pic is NULL, it
will just crash.
I meant to send a reply saying I misread,
but responded to the wrong mail in my
On 1/19/2015 7:32 PM, James Almer wrote:
-@item @uref{http://www.mingw.org/, MSYS}
+@item @uref{http://msys2.github.io/, MSYS2}
@item @uref{http://yasm.tortall.net/, YASM}
Yasm/Nasm are both available from MSYS2's package manager, so maybe add
comment about it being
needed for msvc/icl
On 1/22/2015 2:44 PM, Derek Buitenhuis wrote:
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavcodec/libx265.c | 5 +
1 file changed, 5 insertions(+)
This is v2.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavcodec/libx265.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 923c750..5e4931a 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -226,6 +226,11 @@ static
On 2/17/2015 11:56 PM, Michael Niedermayer wrote:
this should be EINVAL too i think
Yep. Changed locally.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavcodec/libx265.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index c35f6c2..0d546d8 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavcodec/libx265.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 9f40e95..c35f6c2 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -99,7 +99,7
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavcodec/libx265.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index aee7ae2..9f40e95 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
On 1/10/2015 8:43 AM, Timotius Margo wrote:
Hi,
The attached patch updates the Platform Specific Information with build
instruction for Windows Store and Windows Phone 8.1.
[...]
+@heading MinGW Setup
Almost whole patch is wrong (should use MSYS2), out of scope for FFmpeg, and
uses the
On 1/10/2015 8:40 AM, Timotius Margo wrote:
+* text eol=lf
I think this is wrong. git should be set up to pull and push verbatim,
not a specific line ending.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 1/10/2015 8:40 AM, Timotius Margo wrote:
This causes a problem with autoconf and prevents
user from building FFmpeg successfully without applying a workaround.
I forgot to mention this is fixed in newer make.exe's, and I think
it's included in MSYS2.
- Derek
On 1/10/2015 10:28 AM, Matt Oliver wrote:
Although this may be a good example of why it could be useful to make it
clear somewhere that MSYS2 is the recommended setup to help avoid these
issues that way.
Agreed.
- Derek
___
ffmpeg-devel mailing list
On 1/10/2015 6:02 PM, Timothy Gu wrote:
Almost whole patch is wrong (should use MSYS2), out of scope for FFmpeg,
and
uses the wrong title (we *do not* want MinGW here at all).
Sure. My issue is that people confused MinGW (the toolchain) with MSYS (the
environment, which is sometimes on
On 3/17/2015 2:19 PM, Derek Buitenhuis wrote:
[...]
---
libavformat/isom.h| 1 +
libavformat/mov.c | 46 +++---
libavformat/version.h | 4 ++--
3 files changed, 38 insertions(+), 13 deletions(-)
Ping.
-Derek
On 3/18/2015 2:01 PM, Michael Niedermayer wrote:
LGTM but like the previous version i did not verify that it actually
produces the same sequence of packets, i dont think its critical to
verify that ...
I've verified this patch on several pathological samples I have, and it works.
- Derek
On 3/18/2015 2:08 PM, greeshma wrote:
The .diff file is also attached henceforth.Please have a look.
This is still not a git-format patch as required and asked for
by Michael.
Also, the style and formatting is all over the place - that is,
there is no consistent style or formatting at all.
On 3/18/2015 2:20 PM, Derek Buitenhuis wrote:
Also, if you wrote this code, this copyright is both incorrect
and makes it non-free.
Hi,
So after checking, the vast majority of this patch is copy pasted
from OpenEXR.
On that note, a few points:
1. You have no properly recreated the license
in the index entries is implemented as
a linear search since, in MOV, the index entries may be out of
order in terms of file position, in particularily insane files.
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavformat/isom.h| 1 +
libavformat/mov.c | 71
On 3/16/2015 8:17 PM, Michael Niedermayer wrote:
LGTM
Martin had a few suggestions, and I will send a v2 in a bit.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
The current behavior may produce a different sequence of packets
after seeking, compared to demuxing linearly from the beginning.
This is because the MOV demuxer seeks in each stream individually,
based on timestamp, which may set each stream at a slightly different
position than if the file would
On 3/17/2015 4:26 PM, James Almer wrote:
We don't have a generic decorrelate dsp?
I think there was something in fmtconvert, but libav nuked it for being
unused.
Can we not just use a different return format?
- Derek
___
ffmpeg-devel mailing list
On 3/11/2015 8:25 PM, Michael Niedermayer wrote:
whats important is a patchset based on and tested on FFmpeg, at least
if people want a working decoder in FFmpeg
No, what's important is that the best possible code is used. Origin is
irrelevant.
- Derek
On 3/11/2015 9:36 PM, Michael Niedermayer wrote:
Thats analogous to saying no its not important to put fuel in a
car, its important to drive the best car
No what I propose is to look at both and decide which is best. Simply being
submitted to FFmpeg first does not make it better.
the 2nd is
On 3/11/2015 2:42 PM, Marcus Johnson wrote:
I've been working on adding XLL for the last couple months, it's still not
quite complete, basically I have to combine the Core and XLL samples before
it's output, and I also have to finish the latter stages of decoding the
XLL like channel
On 3/12/2015 12:34 PM, Michael Niedermayer wrote:
Its interresting what kind of bizare replies one gets by stating on
the main FFmpeg development list that work should be based on FFmpeg
and should be tested. And then repeating a few times that this is
really what was meant and none of the
On 3/12/2015 11:25 AM, Michael Niedermayer wrote:
you continue to talk about something completely unrelated to what i
said/meant.
you: take best code
[...]
I: for code to be ever in FFmpeg it must either be developed on top
of FFmpeg or it must be rebased/ merged/integrated at some point.
On 3/11/2015 2:42 PM, Marcus Johnson wrote:
I've been working on adding XLL for the last couple months, it's still not
quite complete, basically I have to combine the Core and XLL samples before
it's output, and I also have to finish the latter stages of decoding the
XLL like channel
On 3/24/2015 1:16 PM, smo wrote:
got a strange problem on ffmpeg only if i enable hevc and ac3 (no
problems on linux and windows with same sources)
here s the log
http://paste.ubuntu.com/10668205/
how can i fix it please?
Chromium embeds their own copy of FFmpeg and uses their own
On 3/30/2015 11:45 PM, Michael Niedermayer wrote:
pkt-pts = x265pic_out.pts;
pkt-dts = x265pic_out.dts;
+switch (x265pic_out.sliceType) {
+case X265_TYPE_IDR:
+case X265_TYPE_I: avctx-coded_frame-pict_type = AV_PICTURE_TYPE_I;
break;
+case X265_TYPE_P:
On 3/4/2015 7:21 PM, Andreas Cadhalpun wrote:
Unfortunately XBMC is using these semi-private fields, so it gets broken by
this
change. Therefore I think it would be better to postpone this until after a
SOVERSION bump.
Why exactly should we care about a project that uses explicitly private
On 3/5/2015 5:32 PM, selst wrote:
From: selsta selsta@home
Configure your name and email.
Date: Thu, 5 Mar 2015 01:26:47 +0100
Subject: [PATCH] hls: detect SAMPLE-AES encryption
This doesn't look like it was sent with git send-email?
SAMPLE-AES encryption is not commonly used yet, but
On 3/1/2015 12:26 PM, Robert Krüger wrote:
Am I reading the committed patch incorrectly or is colr still not written
by default? I thought the argument against replacing the flag (Derek's
first patch) was withdrawn because there has not been a release that
contained the original flag.
The
Some formats require this, such as v210. The consensus seems to be
to write it by default.
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
This is a silent behavior change, and I have updated the API doc
accordingly.
---
doc/APIchanges| 3 +++
libavformat/movenc.c | 2
On 2/24/2015 2:49 PM, Clément Bœsch wrote:
Well, unfortunately this breaks the API. I'd just add the flag to the
default values. People who set flags are supposed to use a + as a prefix
so that won't be a problem.
Right.
- Derek
___
ffmpeg-devel
Several formats require the colr atom, and the consensus seems
to be to write it by default.
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
Changing the flag as I do here is one approach. Comments needed.
---
libavformat/movenc.c | 4 ++--
libavformat/movenc.h | 2
On 2/24/2015 5:46 PM, Robert Krüger wrote:
is this correct for all mov, mp4, 3gp, psp, ... ?
or should it be writteb by default only for some of them ?
Good point, but this raises the whole ugly question of the least crappy
way of setting a default for only one format in the monster that is
On 2/26/2015 4:04 PM, Nicolas George wrote:
If we are talking about end-user interface, the changes should happen in
cmdutils.c.
Fair enough.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
On 2/26/2015 4:10 PM, Clément Bœsch wrote:
Yes, it will return an error and abort the operation. Be it done on the
command line or via the API. So said differently it won't work anymore.
I do wonder what the point of the whole AVOption API is then, if we can't
break it any more than a struct.
On 2/26/2015 3:35 PM, Nicolas George wrote:
The second issue is that with the windows file API, when the file is opened
in the so-called text mode, there is an implicit conversion between '\n'
in memory (which is actually exactly 0x0A) and \r\n in the file; there is
also a conversion between
This also restricts it to MOV and MP4, since it is only
defined for those formats.
Signed-off-by: Derek Buitenhuis derek.buitenh...@gmail.com
---
libavformat/movenc.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/libavformat/movenc.c b
On 2/26/2015 1:42 PM, James Cowgill wrote:
The assembly versions have a few problems
- They only work with mips32r2 enabled
- They don't work on 64-bits
- They're massive and complex
So replace them with C implementations which solve these problems and let GCC
magically optimize for
On 2/26/2015 2:09 PM, Carl Eugen Hoyos wrote:
+snprintf(header, len + 3, %s\r\n, s-headers);
This does not necessarily work on windows. The C standard idctates that in
text mode, \n is translated to the system's native newline.
Use memcpy and 0x0D / 0X0A / 0x00.
This may also
On 2/26/2015 1:50 PM, Clément Bœsch wrote:
If the option is set by default, you don't want to warn for no reason.
It's not set by default. That patch never went in.
I don't believe silently not writing it is a valid approach. Then
again I think setting a default movflag like that instead of
On 2/26/2015 5:02 PM, Michael Niedermayer wrote:
just of the top of my head, i can think of:
AVOptions allows listing the available options, like for automatically
building a list of available options in a GUI
it allows changing the type int-int64, int-double
it stores default value, min and
On 5/11/2015 5:57 AM, Gopu Govindaswamy wrote:
Thanks for review, Do i need to send a new patch or this patch itself can
move into ffmpeg repo?
I fixed and pushed it. I was out of the country for a few days, hence the delay.
- Derek
___
ffmpeg-devel
On 5/5/2015 9:54 AM, Gopu Govindaswamy wrote:
From c882bbf42b0f13f98fb706139b7d3fbc53665319 Mon Sep 17 00:00:00 2001
From: Gopu Govindaswamy g...@multicorewareinc.com
Date: Tue, 5 May 2015 12:24:44 +0530
Subject: [PATCH] avcodec/libx265: use x265 Multi-library Interface to query
the API
The
On 5/16/2015 4:05 AM, Steve Borho wrote:
Without this change, if you link with an 8bit libx265 and try to specify
a 10bit input color space via:
ffmpeg -i in.mov -c:v libx265 -pix_fmt yuv420p10le out.mp4
It will error with:
nit: It's not an error, it just changes the filter chain.
On 4/6/2015 4:43 AM, Michael Niedermayer wrote:
* Post merge reviewcleanup, changes merged from libav would benefit from
people reviewing and MUCH MUCH more importantly also people actually caring
about and taking responsibility not just dumping comments with the idea
someone will fix
On 4/5/2015 11:34 PM, Michael Niedermayer wrote:
this is missing documentation about the units in which sdt_period is.
as is this depends on mux_rate 1
if its intended to stay that way, then this should be documented
Yes it depends on muxrate.
I'll rework these soon.
- Derek
On 4/6/2015 11:23 PM, compn wrote:
i think we tried this a few years ago and found that we do still have
ffserver users, they are just quiet until we threaten to rm it. if/when
it breaks, someone will either be there to fix it or it will rot.
That's stupid. Either someone steps up to fix it
On 4/4/2015 11:36 AM, Michael Niedermayer wrote:
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/error_resilience.c | 13 +++--
libavcodec/error_resilience.h |3 ++-
2 files changed, 9 insertions(+), 7 deletions(-)
I assume there are no matching races for
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
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 ae0593d..861da95 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 7885351
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 861da95..e1158f8 100644
--- a/libavformat
On 4/5/2015 7:44 PM, James Almer wrote:
Shouldn't this be a micro bump? It's just a new AVOption for a specific muxer.
Or at most bump minor only once for both SDT and PAT/PMT options.
I have no opinion on the matter myself.
- Derek
___
ffmpeg-devel
On 4/5/2015 7:37 PM, Derek Buitenhuis wrote:
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(-)
This patch will get
On 4/8/2015 6:16 PM, Gilles Chanteperdrix wrote:
Signed-off-by: Gilles Chanteperdrix gilles.chanteperd...@xenomai.org
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/youtubedl.c | 221
+++
3 files changed,
On 6/22/2015 5:33 PM, James Almer wrote:
I have no opinion one or way or another regarding this addition, but if this
is a GSoC project then i guess the time to show disagreement was back in
February when it was a suggested project waiting for applications, and not in
the middle of the program
On 6/22/2015 6:52 PM, Michael Niedermayer wrote:
When and where ?
Example: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/179883
And also *constantly* on IRC, although I am sure IRC doesn't count
or somesuch.
My argument then is the same as now: this does not belong in libav*. It
On 6/22/2015 9:15 PM, Mariusz Szczepańczyk wrote:
Thank you for clarification. I understand there are people who are not
happy with additions like this. However, there are also people who think
these changes are needed and trying to stop them just because we don't
want this here or worse,
On 6/22/2015 11:58 PM, Mariusz Szczepańczyk wrote:
I don't think it's fair to say Lukasz is the only one standing for these
changes. But let's not make it personal and hold on any grudges for a
moment.
I hold no ill will against anyone, as long as no ill will is held against me.
I do,
1 - 100 of 1386 matches
Mail list logo
