Hi,
2014-11-30 4:08 GMT+01:00 Michael Niedermayer michae...@gmx.at:
this breaks ABI/API
why is what is done in init not just done in the first packet when
the args are already available ?
This seems simpler and would avoid introducing a API that is possibly
going to be deprecated once a
Hi,
2014-11-30 2:11 GMT+01:00 Carl Eugen Hoyos ceho...@ag.or.at:
Christophe Gisquet christophe.gisquet at gmail.com writes:
libavcodec/h264_changesps_bsf.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
Please merge this into the earlier patch, as-is
Christophe Gisquet christophe.gisquet at gmail.com writes:
some people prefer squashing together those
kinds of patches, but I hate that
I completely agree and would only squash this one
(because it fixes compilationn) but not the next
one (that wasn't written by the original author).
Carl
Hi,
2014-11-30 1:45 GMT+01:00 Christophe Gisquet christophe.gisq...@gmail.com:
From: Zongyi Zhou zho...@os.pku.edu.cn
Mostly unverified, but seems to have been extensively tested here:
http://forum.doom9.org/showthread.php?t=152419
For the record, I don't think I'm making a good argument for
2014-11-30 10:59 GMT+01:00 Christophe Gisquet christophe.gisq...@gmail.com:
So I'm going to add a AVDictionary *bsf_args to OutputStream.
That dictionary lookup seems negligible to the amount of work done overall.
Done in the attached patch. I've edited the documentation also to
reflect this
This very slightly improves quality at the expense of 96kb more memory for
tables
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/pcm.c |4 ++--
libavcodec/pcm_tablegen.h | 12 ++--
tests/ref/acodec/pcm-alaw |6 +++---
tests/ref/acodec/pcm-mulaw
Hi,
2014-11-30 10:29 GMT+01:00 Carl Eugen Hoyos ceho...@ag.or.at:
I completely agree and would only squash this one
(because it fixes compilationn) but not the next
one (that wasn't written by the original author).
Agreed, dropping that patch and squashing with the import patch.
--
2014-11-30 1:45 GMT+01:00 Christophe Gisquet christophe.gisq...@gmail.com:
From: Zongyi Zhou zho...@os.pku.edu.cn
Squashed and updated patch attached.
From a49425e6af4e3e488c390d94d8f86c5d1745dda3 Mon Sep 17 00:00:00 2001
From: Zongyi Zhou zho...@os.pku.edu.cn
Date: Sat, 29 Nov 2014 15:04:37
Hi,
2014-11-30 12:11 GMT+01:00 Michael Niedermayer michae...@gmx.at:
This very slightly improves quality at the expense of 96kb more memory for
tables
I'm not concerned by this case, but maybe put that under CONFIG_SMALL
or something related?
Also, out of curiosity rather than concern:
On Sun, Nov 30, 2014 at 12:19:50PM +0100, Christophe Gisquet wrote:
Hi,
2014-11-30 12:11 GMT+01:00 Michael Niedermayer michae...@gmx.at:
This very slightly improves quality at the expense of 96kb more memory for
tables
I'm not concerned by this case, but maybe put that under
2014-11-30 13:03 GMT+01:00 Michael Niedermayer michae...@gmx.at:
not really, no,
that was also why i posted a patch for this, i wasnt sure this is
worth the extra table size
No strong opinion here, I don't think the increased memory/potential
speed impact are critical, in particular for this
On 12/11/2014 23:38, Aleksey Vasenev wrote:
Signed-off-by: Aleksey Vasenev margtu-f...@ya.ru
---
libavfilter/vf_interlace.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavfilter/vf_interlace.c b/libavfilter/vf_interlace.c
index e07963f..42e2c9a 100644
---
On 30/11/2014 01:45, Christophe Gisquet wrote:
Most of the code is actually not mine but originated from Direct264:
http://forum.doom9.org/showthread.php?t=152419
https://svn.code.sf.net/p/direct264/code/Patches/
Therefore I've tried to split as best as possible the code I have added.
There are
On 12/11/2014 23:39, Aleksey Vasenev wrote:
Signed-off-by: Aleksey Vasenev margtu-f...@ya.ru
---
libavfilter/vf_tinterlace.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavfilter/vf_tinterlace.c b/libavfilter/vf_tinterlace.c
index 6bc55b5..7397beb 100644
---
On Sun, Nov 30, 2014 at 12:11:07PM +0100, Christophe Gisquet wrote:
2014-11-30 10:59 GMT+01:00 Christophe Gisquet christophe.gisq...@gmail.com:
So I'm going to add a AVDictionary *bsf_args to OutputStream.
That dictionary lookup seems negligible to the amount of work done overall.
Done
On Sun, Nov 30, 2014 at 01:15:43PM +0100, Vittorio Giovara wrote:
On 30/11/2014 01:45, Christophe Gisquet wrote:
Most of the code is actually not mine but originated from Direct264:
http://forum.doom9.org/showthread.php?t=152419
https://svn.code.sf.net/p/direct264/code/Patches/
Therefore
Hi,
now that we can pass bsf arguments through the command-line, it's
worth updating the documentation for it.
--
Christophe
From 4cd13dd05bb654ee311109c7289155ca82be5121 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet christophe.gisq...@gmail.com
Date: Sun, 30 Nov 2014 11:59:22 +0100
On Sun, Nov 30, 2014 at 1:39 PM, Aleksey Vasenev margtu-f...@ya.ru wrote:
We keep only half source frames.
Source: time_base 1/10 and ptss 0 1 2 3 4 5 6 7 8 9
Before change: time_base 1/5 and ptss 0 1 2 3 4
After change: time_base 1/10 and ptss 0 2 4 6 8
Yes, that's probably wrong, interlaced
On Sun, Nov 30, 2014 at 02:45:54PM +0100, Christophe Gisquet wrote:
Hi,
now that we can pass bsf arguments through the command-line, it's
worth updating the documentation for it.
--
Christophe
bitstream_filters.texi |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
On Sun, Nov 30, 2014 at 01:07:52PM +0100, Vittorio Giovara wrote:
On 12/11/2014 23:39, Aleksey Vasenev wrote:
Signed-off-by: Aleksey Vasenev margtu-f...@ya.ru
---
libavfilter/vf_tinterlace.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavfilter/vf_tinterlace.c
Logging system must not change state of passed objects.
Missing consts also blocks many other places where functions
should have const arguments, but it would cause a warning.
Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
---
cmdutils.c| 4 ++--
cmdutils.h
We keep only half source frames.
Source: time_base 1/10 and ptss 0 1 2 3 4 5 6 7 8 9
Before change: time_base 1/5 and ptss 0 1 2 3 4
After change: time_base 1/10 and ptss 0 2 4 6 8
You can see that before and after equal. No problem with timings.
We still need reduce frame_rate because it now
The file is already present in git and by using it we can perform more tests
without the need of fate samples
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
tests/Makefile |3 +++
tests/fate/vcodec.mak |8 ++--
This avoids confusion with a growing number of vsynth tests
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
tests/Makefile |2 +-
tests/fate/ffmpeg.mak |8 +-
tests/fate/seek.mak|
Hi,
Le 30/11/2014 13:11, Christophe Gisquet a écrit :
2014-11-30 13:03 GMT+01:00 Michael Niedermayer michae...@gmx.at:
not really, no,
that was also why i posted a patch for this, i wasnt sure this is
worth the extra table size
No strong opinion here, I don't think the increased
On Sun, Nov 30, 2014 at 08:52:15PM +0100, Benoit Fouet wrote:
Hi,
Le 30/11/2014 13:11, Christophe Gisquet a écrit :
2014-11-30 13:03 GMT+01:00 Michael Niedermayer michae...@gmx.at:
not really, no,
that was also why i posted a patch for this, i wasnt sure this is
worth the extra table size
Changes since v1:
* move EssenceGroup at the end of the enum
* removed changes to fate-lavf-mxf tests
* tested memory handling with valgrind
Mark Reid (1):
libavformat/mxfdec.c: initial support for EssenceGroups
libavformat/mxf.c| 1 +
libavformat/mxf.h| 3 +-
---
libavformat/mxf.c| 1 +
libavformat/mxf.h| 3 +-
libavformat/mxfdec.c | 148 +--
3 files changed, 124 insertions(+), 28 deletions(-)
diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index 4dc54d7..14d143e 100644
---
On Sun, Nov 30, 2014 at 12:16:27PM -0800, Mark Reid wrote:
---
libavformat/mxf.c| 1 +
libavformat/mxf.h| 3 +-
libavformat/mxfdec.c | 148
+--
3 files changed, 124 insertions(+), 28 deletions(-)
applied
i left the comment on
On 20.11.2014 20:14, Michael Niedermayer wrote:
On Thu, Nov 20, 2014 at 05:59:35PM +0100, Andreas Cadhalpun wrote:
Hi,
currently the native aac encoder is marked as experimental, while
the libvo_aacenc encoder is not.
However, after reading the wiki [1] and especially the mentioned
mail [2],
Hi,
the license template of doc/t2h.pm incorrectly mentions the Lesser
General Public License even though the license is GPL 3+.
Attached patch fixes this.
Best regards,
Andreas
From 5b287f85837be262c973ef696f3d77488f7ddec1 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Hi,
attached patch fixes some spelling mistakes in the documentation and
code comments.
succesfully = successfully
reproducable = reproducible
specifiying = specifying
isnt = isn't
seperated = separated
Best regards,
Andreas
From cf836c2b85f2bffe3de7b87b4f4c89e150640c58 Mon Sep
On Mon, Dec 01, 2014 at 12:08:03AM +0100, Andreas Cadhalpun wrote:
Hi,
attached patch fixes some spelling mistakes in the documentation and
code comments.
succesfully = successfully
reproducable = reproducible
specifiying = specifying
isnt = isn't
seperated = separated
On Mon, Dec 01, 2014 at 12:05:11AM +0100, Andreas Cadhalpun wrote:
Hi,
the license template of doc/t2h.pm incorrectly mentions the Lesser
General Public License even though the license is GPL 3+.
Attached patch fixes this.
Best regards,
Andreas
t2h.pm |4 ++--
1 file changed, 2
Thanks for your point of view.
I'll fix properly and submit later.
2014-11-27 5:53 GMT+09:00 Clément Bœsch u...@pkh.me:
On Tue, Nov 25, 2014 at 06:07:30PM +0900, Jeong-Hoon Seo wrote:
SAMI and ASS have different precision of duration in FFMPEG
(SAMI: millisecond, ASS: centisecond)
I tried compiling ffmpeg on armv8 aarch64 platform , and it's ok. But when
compiling on aarch32, compiling error occured. It seems some instructions
in assembly files are not supported.Is there any plan to add aarch32
patches?
___
ffmpeg-devel mailing
Hi,
On Sunday, November 30, 2014, Xiong Tang tangx5...@gmail.com wrote:
I tried compiling ffmpeg on armv8 aarch64 platform , and it's ok. But when
compiling on aarch32, compiling error occured. It seems some instructions
in assembly files are not supported.Is there any plan to add aarch32
On Sun, Nov 30, 2014 at 11:43:45PM +0100, Andreas Cadhalpun wrote:
On 20.11.2014 20:14, Michael Niedermayer wrote:
On Thu, Nov 20, 2014 at 05:59:35PM +0100, Andreas Cadhalpun wrote:
Hi,
currently the native aac encoder is marked as experimental, while
the libvo_aacenc encoder is not.
38 matches
Mail list logo