Josh de Kock itanimul.li> writes:
> +if (p->buf[1080] == 'M' && p->buf[1081] == '.' &&
> +p->buf[1082] == 'K' && p->buf[1083] == '.')
> +return AVPROBE_SCORE_MAX;
This should return EXTENSION + 1 when testing 32bit.
> +openmpt->channels = openmpt_module_get_num_channels(
On Mon, Jun 6, 2016 at 12:19 AM, Muhammad Faiz wrote:
> On Sun, Jun 5, 2016 at 12:33 AM, Michael Niedermayer
> wrote:
>> On Thu, Jun 02, 2016 at 03:32:49PM +0700, Muhammad Faiz wrote:
>>> On Thu, May 5, 2016 at 2:21 PM, Muhammad Faiz wrote:
>>> > this allow a filter to be written like this:
>>>
DeHackEd dehacked.net> writes:
> So here's a first revision of a patch to fix that issue.
How can I reproduce the issue?
Imo, the reindentation makes your patch very difficult to read.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Paul B Mahol gmail.com> writes:
> I'm still for removing this.
Please provide a new commit message.
> I added 10-bit support to native decoder.
This is a good reason for the removal.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Am 11.06.16 um 18:35 schrieb Paul B Mahol:
> On 6/11/16, Michael Niedermayer wrote:
>> On Sat, Jun 11, 2016 at 01:55:01PM +0200, Clement Boesch wrote:
>>> On Sat, Jun 11, 2016 at 12:57:13PM +0200, Michael Niedermayer wrote:
Hi
the MAINTAINERs file contains a bunch of inaccurate and
Signed-off-by: Michael Niedermayer
---
libavcodec/h264_sei.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c
index 95fc5da..1c6b0d7 100644
--- a/libavcodec/h264_sei.c
+++ b/libavcodec/h264_sei.c
@@ -425,6 +425,8 @@ static i
On 06/12/2016 04:07 AM, Carl Eugen Hoyos wrote:
> DeHackEd dehacked.net> writes:
>
>> So here's a first revision of a patch to fix that issue.
>
> How can I reproduce the issue?
1) Produce a very long video, around 27 hours long or so, in mpegts format
$ ffmpeg -r 5 -f lavfi -i testsrc -c:v li
Hi,
My quesions are shown below:
1) Is there some way to check whether media files contain 3d Video or not?
Thanks!
B.R.
andrew
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 6/11/2016 12:57 PM, Michael Niedermayer wrote:
> Hi
>
> the MAINTAINERs file contains a bunch of inaccurate and outdated
> entries.
>
> What should be done about this ?
> should we remove everyone who was inactive in FFmpeg
> (aka no commit/author since 2 years) as in git log --first-parent ..
Hi,
I don't care much for MAINTAINERS, I certainly don't use it for anything,
but ...
On Sat, Jun 11, 2016 at 12:31 PM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:
> On Sat, Jun 11, 2016 at 01:55:01PM +0200, Clément Bœsch wrote:
> > On Sat, Jun 11, 2016 at 12:57:13PM +0200, Michael Nied
On Sat, Jun 11, 2016 at 06:55:32PM -0400, DeHackEd wrote:
> Presently the mpegts demuxer passes the timestamps from received packets
> directly to the output AVPackets. 2^33 / 9
> seconds is about 26.5 hours at which point applications start having a fit,
> and that's assuming timestamps begi
Hi,
On Sun, Jun 12, 2016 at 8:23 AM, Michael Niedermayer wrote:
> On Sat, Jun 11, 2016 at 06:55:32PM -0400, DeHackEd wrote:
> > Presently the mpegts demuxer passes the timestamps from received packets
> directly to the output AVPackets. 2^33 / 9
> > seconds is about 26.5 hours at which point
On 06/12/2016 08:23 AM, Michael Niedermayer wrote:
> On Sat, Jun 11, 2016 at 06:55:32PM -0400, DeHackEd wrote:
>> Presently the mpegts demuxer passes the timestamps from received packets
>> directly to the output AVPackets. 2^33 / 9
>> seconds is about 26.5 hours at which point applications st
On Sun, Jun 12, 2016 at 09:37:28AM +, Petru Rares Sincraian wrote:
> Hi there,
>
> I'm sorry, I hadn't considered mingw. Here is the patch without the
> filter-afade-ihsin.
applied
>
> One question. In which cases I need to test?
Theres no definite list
linux 32/64 is a good choice as it
Le quartidi 24 prairial, an CCXXIV, Marton Balint a écrit :
> Maybe I am missing something, but as far as I see the alloc is due to the
> alloc in ff_bsf_get_packet. We could create a similar function
> ff_bsf_get_packet2(AVBSFContext *ctx, AVPacket *pkt) which does not allocate
> a packet but simp
On Sun, 12 Jun 2016, Nicolas George wrote:
Le quartidi 24 prairial, an CCXXIV, Marton Balint a écrit :
Maybe I am missing something, but as far as I see the alloc is due to the
alloc in ff_bsf_get_packet. We could create a similar function
ff_bsf_get_packet2(AVBSFContext *ctx, AVPacket *pkt) w
On Sun, Jun 12, 2016 at 08:31:45AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Jun 12, 2016 at 8:23 AM, Michael Niedermayer > wrote:
>
> > On Sat, Jun 11, 2016 at 06:55:32PM -0400, DeHackEd wrote:
> > > Presently the mpegts demuxer passes the timestamps from received packets
> > directly to
On Sun, Jun 12, 2016 at 07:57:03AM -0400, Ronald S. Bultje wrote:
> Hi,
>
> I don't care much for MAINTAINERS, I certainly don't use it for anything,
> but ...
>
> On Sat, Jun 11, 2016 at 12:31 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
> > On Sat, Jun 11, 2016 at 01:55:01PM +0
Le tridi 23 prairial, an CCXXIV, sebechlebsky...@gmail.com a écrit :
> From: Jan Sebechlebsky
>
> Signed-off-by: Jan Sebechlebsky
> ---
> libavformat/tee.c | 27 +--
> 1 file changed, 17 insertions(+), 10 deletions(-)
Out of curiosity, in what situation is this a probl
DeHackEd dehacked.net> writes:
> $ ffmpeg -r 5 -f lavfi -i testsrc -c:v libx264 -profile:v veryfast
> -t 97000 bigfile.ts
> $ ffmpeg -i bigfile.ts -c:v copy -f null /dev/null
> frame=487718 fps=228472 q=-1.0 Lsize=N/A time=27:05:43.00
So the bug is that the file gets longer when read with FFm
On Sun, Jun 12, 2016 at 12:49 PM, Michael Niedermayer
wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/h264_sei.c |6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
One argument here is that if one SEI is corrupt, there is no
guarantees even the size information was
On 06/12/2016 12:06 PM, Carl Eugen Hoyos wrote:
> DeHackEd dehacked.net> writes:
>
>> $ ffmpeg -r 5 -f lavfi -i testsrc -c:v libx264 -profile:v veryfast
>> -t 97000 bigfile.ts
>
>> $ ffmpeg -i bigfile.ts -c:v copy -f null /dev/null
>
>> frame=487718 fps=228472 q=-1.0 Lsize=N/A time=27:05:43.00
DeHackEd dehacked.net> writes:
> > So the bug is that the file gets longer when read with FFmpeg?
>
> Heh... that's my fault for copy/pasting from the wrong invocation.
> I have two test cases, one generated from the above testsrc and
> one that actually consists of a 28+ hour recording from a
On 06/12/2016 01:57 PM, Carl Eugen Hoyos wrote:
> DeHackEd dehacked.net> writes:
>
>>> So the bug is that the file gets longer when read with FFmpeg?
>>
>> Heh... that's my fault for copy/pasting from the wrong invocation.
>> I have two test cases, one generated from the above testsrc and
>> on
---
untested
---
libavcodec/vda_h264_dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vda_h264_dec.c b/libavcodec/vda_h264_dec.c
index a092693..a196eb7 100644
--- a/libavcodec/vda_h264_dec.c
+++ b/libavcodec/vda_h264_dec.c
@@ -226,7 +226,7 @@ static av_cold int
On 06/12/2016 04:26 PM, Nicolas George wrote:
Le tridi 23 prairial, an CCXXIV, sebechlebsky...@gmail.com a écrit :
From: Jan Sebechlebsky
Signed-off-by: Jan Sebechlebsky
---
libavformat/tee.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
Out of cur
From: Jan Sebechlebsky
Signed-off-by: Jan Sebechlebsky
---
libavformat/tee.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/libavformat/tee.c b/libavformat/tee.c
index 806beaa..bf7438c 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -27,8
DeHackEd dehacked.net> writes:
> The effects vary a bit. One guy in IRC basically had ffmpeg
> crash for him every 26.5 hours when he was saving to HLS
And when I asked him how I can reproduce this issue he
unfortunately couldn't answer;-(
Carl Eugen
_
---
untested
---
libavcodec/videotoolbox.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 4dc843d..4d86251 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -102,11 +102,11 @@ CFDataRef
On Sun, Jun 12, 2016 at 08:38:12PM +0200, Clément Bœsch wrote:
> ---
> untested
> ---
> libavcodec/videotoolbox.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 4dc843d..4d86251 100644
> --- a/libavcodec
On Sun, Jun 12, 2016 at 08:12:33PM +0200, Clément Bœsch wrote:
> ---
> untested
> ---
> libavcodec/vda_h264_dec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vda_h264_dec.c b/libavcodec/vda_h264_dec.c
> index a092693..a196eb7 100644
> --- a/libavcodec/vda_h
On 06/12/2016 02:31 PM, Carl Eugen Hoyos wrote:
> DeHackEd dehacked.net> writes:
>
>> The effects vary a bit. One guy in IRC basically had ffmpeg
>> crash for him every 26.5 hours when he was saving to HLS
>
> And when I asked him how I can reproduce this issue he
> unfortunately couldn't answ
DeHackEd dehacked.net> writes:
> $ ffmpeg -i longvideo.ts -c copy -f mpegts -copyts output.ts
Why are you using -copyts and what is wrong with the output file?
If the crash report is really unreproducible (which seems
inexplicable to me), then at least backtrace, disassembly
and register dump
On Sun, Jun 12, 2016 at 07:56:31AM +0700, Muhammad Faiz wrote:
> give high quality resampling
> as good as with linear_interp=on
> as fast as without linear_interp=on
> tested visually with ffplay
> ffplay -f lavfi "aevalsrc='sin(1*t*t)', aresample=osr=48000,
> showcqt=gamma=5"
> ffplay -f lavf
We haven't had a stable release since the packet_gap addition, so probably it
is worth reworking the option to something that makes more sense to the end
user. Also add burst_bits option to specify maximum length of bit bursts.
Signed-off-by: Marton Balint
---
doc/protocols.texi| 9 +++-
Signed-off-by: Marton Balint
---
libavformat/udp.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/libavformat/udp.c b/libavformat/udp.c
index 531e254..f2446c6 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -552,6 +552,7 @@ static void *circular_buf
On Sun, Jun 12, 2016 at 02:43:10AM +0100, Josh de Kock wrote:
> ---
> configure| 4 +
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/libopenmpt.c | 185
> +++
> 4 files changed, 191 insertions(+)
On Sun, Jun 12, 2016 at 02:59:14PM -0400, DeHackEd wrote:
> On 06/12/2016 02:31 PM, Carl Eugen Hoyos wrote:
> > DeHackEd dehacked.net> writes:
> >
> >> The effects vary a bit. One guy in IRC basically had ffmpeg
> >> crash for him every 26.5 hours when he was saving to HLS
> >
> > And when I as
This is disabled by default when the empty_moov flag is enabled
---
libavformat/dashenc.c | 43 -
libavformat/movenc.c | 105 +++---
2 files changed, 123 insertions(+), 25 deletions(-)
diff --git a/libavformat/dashenc.c b/libavform
---
libavformat/segment.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index d22d550..d8877f0 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -89,6 +89,7 @@ typedef struct SegmentCo
---
tests/fate/vpx.mak | 5 +
1 file changed, 5 insertions(+)
diff --git a/tests/fate/vpx.mak b/tests/fate/vpx.mak
index f0bcfac..29cd2a7 100644
--- a/tests/fate/vpx.mak
+++ b/tests/fate/vpx.mak
@@ -133,5 +133,10 @@ FATE_VP9-$(CONFIG_IVF_DEMUXER) += fate-vp9-05-resize
fate-vp9-05-resize: CMD
---
tests/fate/hevc.mak | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index 05266cd..5ae5d3d 100644
--- a/tests/fate/hevc.mak
+++ b/tests/fate/hevc.mak
@@ -225,6 +225,17 @@ $(foreach N,$(HEVC_SAMPLES_444_12BIT),$(eval $(call
FATE_HEVC_T
---
tests/fate/aac.mak | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tests/fate/aac.mak b/tests/fate/aac.mak
index 3d64031..b02b768 100644
--- a/tests/fate/aac.mak
+++ b/tests/fate/aac.mak
@@ -241,6 +241,10 @@ FATE_AAC_LATM += fate-aac-latm_stereo_to_51
fate-aac-l
---
tests/fate/h264.mak | 2 ++
tests/ref/fate/h264-autobsf-mp4toannexb | 1 +
2 files changed, 3 insertions(+)
create mode 100644 tests/ref/fate/h264-autobsf-mp4toannexb
diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak
index e12263c..5307a29 100644
--- a/tests/fate/h26
---
libavformat/mux.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index dd3de24..071eac1 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -484,8 +484,11 @@ int avformat_write_header(AVFormatContext *s, AVDictionary
**optio
This allows a consumer to run the muxer's init function without actually
writing the header, which is useful in chained muxers that support
automatic bitstream filtering.
---
libavformat/avformat.h | 34 +--
libavformat/internal.h | 10
libavformat/mux.c | 64
This is mostly useful for muxers that wrap other muxers, such as dashenc
and segment. The actual duplicated bitstream filtering is largely harmless,
but delaying the header can cause problems when the muxer intended the header
to be written to a separate file.
---
libavformat/avformat.h | 1 +
---
libavformat/movenc.c | 65 ++--
1 file changed, 28 insertions(+), 37 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 2f00091..acb0e25 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5284,21 +5284,18 @
---
libavformat/dashenc.c | 51 +--
1 file changed, 17 insertions(+), 34 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 519f9c4..0848052 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -580,16 +580,12
---
libavformat/internal.h | 5 +++--
libavformat/mux.c | 45 +-
libavformat/segment.c | 6 +++--
libavformat/utils.c| 59 +-
4 files changed, 91 insertions(+), 24 deletions(-)
diff --git a/libavformat
---
libavformat/avformat.h | 3 +++
libavformat/utils.c| 4
2 files changed, 7 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index f66c39b..b4fe626 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2869,8 +2869,11 @@ int avformat_queue_atta
---
libavformat/segment.c | 47 ---
1 file changed, 20 insertions(+), 27 deletions(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 4c6c6d4..d22d550 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -627,8 +627,9 @@ st
Hi,
As requested in the IRC meeting I hereby request for the
voting committee to begin voting on whatever to ban Carl
Eugen Hoyos from mailing list, trac and IRC for 4 months,
starting after the voting has finished.
Voting will last 7 days from now.
In order for the vote to pass, at least 50% of
Hi all,
Here's three patches. These are still WIP and not ready to be pushed.
0001-avfilter-add-libebur128-port.patch
This first patch ports libebur128 to ffmpeg. I haven't re-indented
these yet, so please diff `ebur128.c' and `ebur128.h' with the
original libebur128 files[1][2] to see what has c
On Sun, 12 Jun 2016, Rodger Combs wrote:
---
libavformat/mux.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index dd3de24..071eac1 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -484,8 +484,11 @@ int avformat_write_heade
---
libavformat/avformat.h | 3 +++
libavformat/utils.c| 4
2 files changed, 7 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index f66c39b..b4fe626 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2869,8 +2869,11 @@ int avformat_queue_atta
This is mostly useful for muxers that wrap other muxers, such as dashenc
and segment. The actual duplicated bitstream filtering is largely harmless,
but delaying the header can cause problems when the muxer intended the header
to be written to a separate file.
---
libavformat/avformat.h | 1 +
---
libavformat/segment.c | 47 ---
1 file changed, 20 insertions(+), 27 deletions(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index 4c6c6d4..d22d550 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -627,8 +627,9 @@ st
---
libavformat/internal.h | 5 +++--
libavformat/mux.c | 45 +-
libavformat/segment.c | 6 +++--
libavformat/utils.c| 59 +-
4 files changed, 91 insertions(+), 24 deletions(-)
diff --git a/libavformat
---
libavformat/mux.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index dd3de24..071eac1 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -484,8 +484,11 @@ int avformat_write_header(AVFormatContext *s, AVDictionary
**optio
This allows a consumer to run the muxer's init function without actually
writing the header, which is useful in chained muxers that support
automatic bitstream filtering.
---
libavformat/avformat.h | 34 +--
libavformat/internal.h | 10
libavformat/mux.c | 64
---
libavformat/movenc.c | 67 +++-
1 file changed, 29 insertions(+), 38 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 2f00091..2f6f8bf 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5284,21 +5284,18 @
This is disabled by default when the empty_moov flag is enabled
---
libavformat/dashenc.c | 43 +++-
libavformat/movenc.c | 107 +++---
2 files changed, 124 insertions(+), 26 deletions(-)
diff --git a/libavformat/dashenc.c b/libavforma
---
libavformat/dashenc.c | 51 +--
1 file changed, 17 insertions(+), 34 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 519f9c4..0848052 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -580,16 +580,12
---
libavformat/segment.c | 29 -
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/libavformat/segment.c b/libavformat/segment.c
index d22d550..d8877f0 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -89,6 +89,7 @@ typedef struct SegmentCo
---
tests/fate/hevc.mak | 11 +++
1 file changed, 11 insertions(+)
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index 05266cd..5ae5d3d 100644
--- a/tests/fate/hevc.mak
+++ b/tests/fate/hevc.mak
@@ -225,6 +225,17 @@ $(foreach N,$(HEVC_SAMPLES_444_12BIT),$(eval $(call
FATE_HEVC_T
---
tests/fate/h264.mak | 2 ++
tests/ref/fate/h264-autobsf-mp4toannexb | 1 +
2 files changed, 3 insertions(+)
create mode 100644 tests/ref/fate/h264-autobsf-mp4toannexb
diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak
index e12263c..5307a29 100644
--- a/tests/fate/h26
---
tests/fate/aac.mak | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tests/fate/aac.mak b/tests/fate/aac.mak
index 3d64031..b02b768 100644
--- a/tests/fate/aac.mak
+++ b/tests/fate/aac.mak
@@ -241,6 +241,10 @@ FATE_AAC_LATM += fate-aac-latm_stereo_to_51
fate-aac-l
On 12 June 2016 at 22:14, Kyle Swanson wrote:
> Hi all,
>
> Here's three patches. These are still WIP and not ready to be pushed.
>
> 0001-avfilter-add-libebur128-port.patch
> This first patch ports libebur128 to ffmpeg. I haven't re-indented
> these yet, so please diff `ebur128.c' and `ebur128.h
> On Jun 12, 2016, at 16:24, Marton Balint wrote:
>
>
> On Sun, 12 Jun 2016, Rodger Combs wrote:
>
>> ---
>> libavformat/mux.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/mux.c b/libavformat/mux.c
>> index dd3de24..071eac1 100644
>> --- a/libavfo
On Sun, 12 Jun 2016, Rodger Combs wrote:
---
libavformat/internal.h | 5 +++--
libavformat/mux.c | 45 +-
libavformat/segment.c | 6 +++--
libavformat/utils.c| 59 +-
4 files changed, 91 insertions(+), 2
Le quintidi 25 prairial, an CCXXIV, Marton Balint a écrit :
> So you probably don't have to
> support multiple filters, it is enough if you support a single one.
This is not settled. I still think a specific API is better than a container
filter.
Regard
On Sun, 12 Jun 2016, Rodger Combs wrote:
This allows a consumer to run the muxer's init function without actually
writing the header, which is useful in chained muxers that support
automatic bitstream filtering.
---
libavformat/avformat.h | 34 +--
libavformat/internal.h
On Sun, Jun 12, 2016 at 09:30:18PM +0200, Marton Balint wrote:
> We haven't had a stable release since the packet_gap addition, so probably it
> is worth reworking the option to something that makes more sense to the end
> user. Also add burst_bits option to specify maximum length of bit bursts.
>
Hi,
On Sun, Jun 12, 2016 at 4:34 PM, Rodger Combs
wrote:
> ---
> tests/fate/vpx.mak | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/tests/fate/vpx.mak b/tests/fate/vpx.mak
> index f0bcfac..29cd2a7 100644
> --- a/tests/fate/vpx.mak
> +++ b/tests/fate/vpx.mak
> @@ -133,5 +133,10 @@
On 6/12/16, Paul B Mahol wrote:
> Hi,
>
> As requested in the IRC meeting I hereby request for the
> voting committee to begin voting on whatever to ban Carl
> Eugen Hoyos from mailing list, trac and IRC for 4 months,
> starting after the voting has finished.
I don't remember such thing to have b
On Sun, Jun 12, 2016 at 04:30:59PM -0500, Rodger Combs wrote:
> ---
> tests/fate/h264.mak | 2 ++
> tests/ref/fate/h264-autobsf-mp4toannexb | 1 +
> 2 files changed, 3 insertions(+)
> create mode 100644 tests/ref/fate/h264-autobsf-mp4toannexb
tested on linux32/64 mingw32/64 m
On Sun, Jun 12, 2016 at 04:31:00PM -0500, Rodger Combs wrote:
> ---
> tests/fate/aac.mak | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
tested on linux32/64 mingw32/64 mips & arm
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When you are o
On Sun, Jun 12, 2016 at 04:31:01PM -0500, Rodger Combs wrote:
> ---
> tests/fate/hevc.mak | 11 +++
> 1 file changed, 11 insertions(+)
tested on linux32/64 mingw32/64 mips & arm
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made a
On Sat, Jun 11, 2016 at 08:11:45PM +0200, Michael Niedermayer wrote:
> On Wed, Jun 01, 2016 at 04:55:45AM +, Maxim Petrov wrote:
> >
>
> > vf_eq.c |1 +
> > 1 file changed, 1 insertion(+)
> > 30ab72e9b52283cc69755e0205bd8c2f0c133954
> > 0001-Timeline-function-for-the-eq-filter.patch
>
On 6/13/16, Ivan Kalvachev wrote:
> On 6/12/16, Paul B Mahol wrote:
>> Hi,
>>
>> As requested in the IRC meeting I hereby request for the
>> voting committee to begin voting on whatever to ban Carl
>> Eugen Hoyos from mailing list, trac and IRC for 4 months,
>> starting after the voting has finis
On Mon, Jun 13, 2016 at 2:19 AM, Michael Niedermayer
wrote:
> On Sun, Jun 12, 2016 at 07:56:31AM +0700, Muhammad Faiz wrote:
>> give high quality resampling
>> as good as with linear_interp=on
>> as fast as without linear_interp=on
>> tested visually with ffplay
>> ffplay -f lavfi "aevalsrc='sin(1
On Sun, Jun 12, 2016 at 04:14:56PM -0500, Kyle Swanson wrote:
> Hi all,
>
> Here's three patches. These are still WIP and not ready to be pushed.
>
> 0001-avfilter-add-libebur128-port.patch
> This first patch ports libebur128 to ffmpeg. I haven't re-indented
> these yet, so please diff `ebur128.c
On 13 June 2016 at 01:57, Michael Niedermayer
wrote:
> On Sun, Jun 12, 2016 at 04:14:56PM -0500, Kyle Swanson wrote:
> > Hi all,
> >
> > Here's three patches. These are still WIP and not ready to be pushed.
> >
> > 0001-avfilter-add-libebur128-port.patch
> > This first patch ports libebur128 to f
On 6/13/16, Paul B Mahol wrote:
> On 6/13/16, Ivan Kalvachev wrote:
>> On 6/12/16, Paul B Mahol wrote:
>>> Hi,
>>>
>>> As requested in the IRC meeting I hereby request for the
>>> voting committee to begin voting on whatever to ban Carl
>>> Eugen Hoyos from mailing list, trac and IRC for 4 month
On Mon, Jun 13, 2016 at 07:46:22AM +0700, Muhammad Faiz wrote:
> On Mon, Jun 13, 2016 at 2:19 AM, Michael Niedermayer
> wrote:
> > On Sun, Jun 12, 2016 at 07:56:31AM +0700, Muhammad Faiz wrote:
> >> give high quality resampling
> >> as good as with linear_interp=on
> >> as fast as without linear_i
On Wed, Jun 08, 2016 at 10:46:49AM -0700, Jon Toohill wrote:
> Michael et al., is this good to merge as-is? I just tested and a round trip
> with ffmpeg from wav -> mp3 -> wav retains the correct number of samples.
There seems to be a inconsistency
try the patch below with your patch, and write
On Sun, Jun 12, 2016 at 8:07 PM, Rostislav Pehlivanov
wrote:
> On 13 June 2016 at 01:57, Michael Niedermayer
> wrote:
>
>> On Sun, Jun 12, 2016 at 04:14:56PM -0500, Kyle Swanson wrote:
>> > Hi all,
>> >
>> > Here's three patches. These are still WIP and not ready to be pushed.
>> >
>> > 0001-avfi
On Sun, Jun 12, 2016 at 4:32 PM, Rostislav Pehlivanov
wrote:
> On 12 June 2016 at 22:14, Kyle Swanson wrote:
>
>> Hi all,
>>
>> Here's three patches. These are still WIP and not ready to be pushed.
>>
>> 0001-avfilter-add-libebur128-port.patch
>> This first patch ports libebur128 to ffmpeg. I hav
Signed-off-by: Kyle Swanson
---
tools/normalize.py | 33 --
tools/normalize.rb | 60 ++
2 files changed, 60 insertions(+), 33 deletions(-)
delete mode 100755 tools/normalize.py
create mode 100644 tools/normalize.rb
On Mon, Jun 13, 2016 at 9:05 AM, Michael Niedermayer
wrote:
> On Mon, Jun 13, 2016 at 07:46:22AM +0700, Muhammad Faiz wrote:
>> On Mon, Jun 13, 2016 at 2:19 AM, Michael Niedermayer
>> wrote:
>> > On Sun, Jun 12, 2016 at 07:56:31AM +0700, Muhammad Faiz wrote:
>> >> give high quality resampling
>>
On Sun, Jun 12, 2016 at 8:14 PM, Michael Niedermayer
wrote:
> On Sun, Jun 12, 2016 at 09:37:28AM +, Petru Rares Sincraian wrote:
>> Hi there,
>>
>> I'm sorry, I hadn't considered mingw. Here is the patch without the
>> filter-afade-ihsin.
>
> applied
>
fail without SAMPLES
ffmpeg version N-8
92 matches
Mail list logo
