---
libavcodec/libvpxenc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 1a1d55f..3db617d 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -690,6 +690,7 @@ static int storeframe(AVCodecContext
---
libavcodec/libvpxenc.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index fb412b7..1a1d55f 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -717,12 +717,16 @@ FF_ENABLE_DEPRECATION_WARNINGS
This commit removes a redundant argument from the functions in aaccoder.
The argument lambda was redundant as it was just a copy of s->lambda,
to which all functions have access to anyway. This cleans up the function
pointers a bit which is helpful as there are a lot of other search_for_*
functions
This commit moves the quantization function to a separate file.
This is done because the current extensions under development have
separate files, and due to the fact that there was no way to get the
distortion measurements from outside the aaccoder.c file a separate
file had to be made. Most of th
With the new method to determine the phase, the functions
got sufficiently large to have their own file.
There are absolutely no changes from the IS patch from
this patchset, this commit simply moves it out of aaccoder.c
Encoding is still being done within the aacenc.c file due
to the way IS and M/
This commit moves any tables specific to the encoder from aacenc
and aaccoder to a separate file called 'aacenctab.c/.h'.
This was done as a clean up attempt as the encoder was filled with
tables pasted in between functions which made it confusing to follow
and track where each table and definition
As well as tables littered everywhere, functions were spread
out all across the encoder's files. This moves them to a single
place where they can be used by either the encoder's main files
or additional encoder files. Additionally, it changes the type
of some to 'inline' to enable us to simply put
This commit improves the intensity stereo phase detection by considering
the distortion measurement of both phases and picking the phase with the
lowest distortion. This way the phase is always explicitly chosen with
producing the least amount of distortions in both channels.
This commit also enabl
This patchset attempts to clean up the encoder by moving out
the multitude of tables, small helper functions and big functions
to separate file, allowing them to be used by files external to the
encoder's main two files.
The intensity stereo implementation was taken out of the aaccoder file
by incl
May be used to fix Ticket4577
Signed-off-by: Ganesh Ajjanagadde
---
libavformat/riffdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/riffdec.c b/libavformat/riffdec.c
index 7eecdb2..43d4cfc 100644
--- a/libavformat/riffdec.c
+++ b/libavformat/riffdec.c
@@
May be used to fix Ticket4577
Signed-off-by: Ganesh Ajjanagadde
---
libavformat/wavdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index 9bc8c4f..db42f59 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -430,7 +
Signed-off-by: James Almer
---
This can be tested with the rtmpe server listed in
http://wiki.multimedia.cx/?title=RTMP
libavformat/rtmp.h | 3 ---
libavformat/rtmpproto.c | 39 ++-
2 files changed, 10 insertions(+), 32 deletions(-)
diff --git a/libavf
On 29.07.2015, at 05:00, Reimar Döffinger wrote:
> On 29.07.2015, at 03:10, Sasi Inguva wrote:
>> A little context on why I need this. I use individual stream durations to
>> validate , if the outputs after transcoding have the same stream durations.
>> For this we need to know the stream duratio
On 29.07.2015, at 03:10, Sasi Inguva wrote:
> A little context on why I need this. I use individual stream durations to
> validate , if the outputs after transcoding have the same stream durations.
> For this we need to know the stream durations through a quick parse of the
> header of the file, s
> do you think this patch would be ready to push to main ffmpeg once
> this (and any other remaining) issues are fixed
> or is there still some speed loss ?
>
I think I should work a bit more on it, in my tests some cases there is
still 3% speed loss.
Usualy it occurs when the vertical filter size
A little context on why I need this. I use individual stream durations to
validate , if the outputs after transcoding have the same stream durations.
For this we need to know the stream durations through a quick parse of the
header of the file, since demuxing the whole file is too slow. We can have
On Tue, 28 Jul 2015, Michael Niedermayer wrote:
From: Michael Niedermayer
Fixes some files from Ticket679
This also changes subtitles to 4:2:0 matching the output format and thus
simplifying the blend code.
This restricts placement to the chroma sample resolution though, speak up
if you cons
On Tue, Jul 28, 2015 at 07:24:08PM -0400, Ganesh Ajjanagadde wrote:
> https://trac.ffmpeg.org/ticket/4577 has been updated recently by me
> with some analysis. Basically, strictly following spec, this file does
> not follow it. I do not know what ffmpeg's policy is regarding such
> files; hence thi
https://trac.ffmpeg.org/ticket/4577 has been updated recently by me
with some analysis. Basically, strictly following spec, this file does
not follow it. I do not know what ffmpeg's policy is regarding such
files; hence this message.
Depending on this policy, this either needs to be marked as a wo
On Tue, Jul 28, 2015 at 06:06:04PM -0300, Pedro Arthur wrote:
> All these weird bugs were caused by the mmx code expecting the chroma U
> and V buffer to be contiguous in memory. As I was allocating the slice
> lines U
> and V separately the mmx code was using some random memory.
> In the attached
All these weird bugs were caused by the mmx code expecting the chroma U
and V buffer to be contiguous in memory. As I was allocating the slice
lines U
and V separately the mmx code was using some random memory.
In the attached patch there is a fix for it.
I also added some documentation to the new
On Tue, Jul 28, 2015 at 9:39 PM, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva
> ---
> libavformat/matroska.h | 1 +
> libavformat/matroskadec.c| 21 +-
> libavformat/matroskaenc.c| 66
> ++--
> tests/fate/wavpack.mak |
On Tue, Jul 28, 2015 at 06:26:34PM +0300, Ivan Uskov wrote:
> Hello All,
>
> There is same patch as 1/2 but for decoder part.
>
>
> --
> Best regards,
> Ivanmailto:ivan.us...@nablet.com
> qsvdec.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 865c91
Signed-off-by: Sasi Inguva
---
libavformat/matroska.h | 1 +
libavformat/matroskadec.c| 21 +-
libavformat/matroskaenc.c| 66 ++--
tests/fate/wavpack.mak | 4 +--
tests/ref/acodec/tta | 4 +--
tests/ref/fate/binsub
On Tue, Jul 28, 2015 at 06:49:13PM +0300, Ivan Uskov wrote:
> Hello wm4,
>
> Tuesday, July 28, 2015, 6:39:22 PM, you wrote:
> >> Official MFX/QSV samples by Intel are use 1 millisecond (i.e. 1000
> >> microseconds) everywhere where MFX_WRN_DEVICE_BUSY does appear.
> >> So 500us is much more optima
Works only for flv, h263 and huffyuv decoders, for video with yuv420p pixel
format.
Makes only one pass through the file (this should be changed to two passes)
---
tests/api/Makefile| 1 +
tests/api/api-band-test.c | 229 ++
tests/fate/api.mak
It works for decoding only in one thread. I use only one buffer, so when
different frames are decoded in different threads I get wrong pieces in my
result buffer. I don't know how to work with multiple buffers (which call of
draw_horiz_band is for which frame?).
___
On Tue, Jul 28, 2015 at 05:40:23PM +0200, Nedeljko Babic wrote:
> From: Nedeljko Babic
>
> There was fixed number of loops (2048) in preparation for resampler, so
> when number of samples is smaller than this, there would be an overflow on
> ret_buf.
>
> For some reason this behavior popped out
On Tue, Jul 28, 2015 at 04:21:12PM +, Carl Eugen Hoyos wrote:
> Vesselin Bontchev yandex.com> writes:
>
> > +@example
> > +ffmpeg -v debug -i input.aa -c:a copy output.wav
>
> I don't think this is a very useful example, instead
> please document the option that the demuxer has in
> short
I sneaked in some more fixes in this revision :)
VesselinFrom 5db4be22af277030cdbe234843e7aae55bf667e1 Mon Sep 17 00:00:00 2001
From: Vesselin Bontchev
Date: Sun, 19 Jul 2015 23:16:36 +0200
Subject: [PATCH] Add support for Audible AA files
https://en.wikipedia.org/wiki/Audible.com#Quality
---
d
28.07.2015, 19:23, "Carl Eugen Hoyos" :
> Vesselin Bontchev yandex.com> writes:
>
>> +@example
>> +ffmpeg -v debug -i input.aa -c:a copy output.wav
>
> I don't think this is a very useful example, instead
> please document the option that the demuxer has in
> short words (you don't have to docum
Thanks for all the feedback.
VesselinFrom d035dc7dd0c95079ca9f94c7acb7aab0d48f16cb Mon Sep 17 00:00:00 2001
From: Vesselin Bontchev
Date: Sun, 19 Jul 2015 23:16:36 +0200
Subject: [PATCH] Add support for Audible AA files
https://en.wikipedia.org/wiki/Audible.com#Quality
---
doc/demuxers.texi
Vesselin Bontchev yandex.com> writes:
> +@example
> +ffmpeg -v debug -i input.aa -c:a copy output.wav
I don't think this is a very useful example, instead
please document the option that the demuxer has in
short words (you don't have to document the default
value imo).
> + * Redistribution a
Hello wm4,
Tuesday, July 28, 2015, 6:39:22 PM, you wrote:
>> Official MFX/QSV samples by Intel are use 1 millisecond (i.e. 1000
>> microseconds) everywhere where MFX_WRN_DEVICE_BUSY does appear.
>> So 500us is much more optimal value than 1us.
w> Are you 100% sure that there is no event-based way
From: Nedeljko Babic
There was fixed number of loops (2048) in preparation for resampler, so
when number of samples is smaller than this, there would be an overflow on
ret_buf.
For some reason this behavior popped out only under valgrind with
--disable-memory-poisoning option.
This is now fixed
On Tue, 28 Jul 2015 18:30:56 +0300
Ivan Uskov wrote:
> Hello All,
>
> The attached patch replaces 1 microsecond delay to 500 microsecond for
> case when MFX library does return MFX_WRN_DEVICE_BUSY status.
> In general this warning never appears for simple encoding or
> transcoding session becaus
>>On Sat, Jul 25, 2015 at 05:37:56AM +0200, Michael Niedermayer wrote:
>>> On Mon, Jul 20, 2015 at 01:36:21PM +0200, Nedeljko Babic wrote:
>>> > Signed-off-by: Nedeljko Babic
>>> > ---
>>> > tests/fate/aac.mak | 58
>>> > +-
>>> > 1 file change
Hello All,
There is same patch as 1/2 but for decoder part.
--
Best regards,
Ivanmailto:ivan.us...@nablet.com
0002-libavcodec-qsvdec.c-delay-in-1-microsecond-replaced-.patch
Description: Binary data
___
ffmpeg-devel maili
Hello All,
The attached patch replaces 1 microsecond delay to 500 microsecond for
case when MFX library does return MFX_WRN_DEVICE_BUSY status.
In general this warning never appears for simple encoding or
transcoding session because GPU so fast so almost always not busy and
any delay value just no
Hi,
I am attaching a new revision (v3) of the "Audible AA" patch.
VesselinFrom 30757211a81f5b0c852e1f4e620c03b9ae08f99e Mon Sep 17 00:00:00 2001
From: Vesselin Bontchev
Date: Sun, 19 Jul 2015 23:16:36 +0200
Subject: [PATCH] Add support for Audible AA files
https://en.wikipedia.org/wiki/Audible.
On Tue, Jul 28, 2015 at 05:25:21PM +0300, Vesselin Bontchev wrote:
> Hi,
>
> I am attaching a new revision (v3) of the "Audible AA" patch.
>
> Vesselin
[...]
> +avio_skip(pb, 24); // header termination block (ignored)
> +npairs = avio_rb32(pb); // read dictionary entries
> +for (i =
On Tue, Jul 28, 2015 at 04:39:04PM +0300, Ivan Uskov wrote:
> Hello All,
>
> This patch implements optional mode which disables context
> extradata modification by bsf. The modification of extradata become
> an issue when bsf restarts (after stream detection for example).
> Please review.
>
> --
Hello All,
This patch implements optional mode which disables context
extradata modification by bsf. The modification of extradata become
an issue when bsf restarts (after stream detection for example).
Please review.
--
Best regards,
Ivan mailto:ivan.us...@nablet.com
Le decadi 10 thermidor, an CCXXIII, Stephan Holljes a écrit :
> I thought it was necessary for the application to indicate it wants to
> finish the handshake. I think with the FINAL state this is
> superfluous.
Eventually, applications must be able to choose, but the default can be
anything, and s
2015-07-28 16:04 GMT+08:00 Clément Bœsch :
> On Mon, Jul 27, 2015 at 10:10:12PM +0800, Zhang Rui wrote:
>> 2015-07-27 20:14 GMT+08:00 Clément Bœsch :
>> > On Mon, Jul 27, 2015 at 06:13:30PM +0800, Zhang Rui wrote:
>> >> 2015-07-15 21:51 GMT+08:00 Clément Bœsch :
>> >> > On Sat, Jun 20, 2015 at 01:3
Hi,
Am 27.07.15 um 18:08 schrieb Gianluigi Tiesi:
> Hi, with the attached patch, ffmpeg avfoundation device input
> is able to find my canopus dv firewire adapter.
> I only have 1 format 'muxed' and it's not possible to set resolution or
> framerate
> via 'setValue'.
>
> I've looked at the code
On Tue, Jul 28, 2015 at 12:37:41AM +0200, Michael Niedermayer wrote:
> Hi
>
> Can you share the testcase you used for below ?
> this is not correct (for FFmpeg at least).
> I know how to fix it but having a testcase would ensure that the fix
> works
not sure the reply was intended to be private b
On Mon, Jul 27, 2015 at 10:10:12PM +0800, Zhang Rui wrote:
> 2015-07-27 20:14 GMT+08:00 Clément Bœsch :
> > On Mon, Jul 27, 2015 at 06:13:30PM +0800, Zhang Rui wrote:
> >> 2015-07-15 21:51 GMT+08:00 Clément Bœsch :
> >> > On Sat, Jun 20, 2015 at 01:33:00PM +0200, Sebastien Zwickert wrote:
> >> >> O
48 matches
Mail list logo
