Hi,
On Mon, Jul 27, 2015 at 6:01 AM,
mailto:shivraj.pa...@imgtec.com>> wrote:
+++ b/libavcodec/mips/vp8dsp_init_mips.c
Is there a reason the init code lives in a different file than the
implementations? It seems to me all symbols could be static if the init code
lived in the same file as the
On 31.07.2015, at 17:47, Nicolas George wrote:
> I can propose the following middle term:
I do have on more proposal, but the problem is it needs someone to do the work.
For each removed feature, prepare documentation "a monkey could follow" on how
to replace it (you could call it a transition g
Signed-off-by: Philip Langdale
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index da02165..b0d0dc7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -304,7 +304,7 @@ Hardware acceleration:
libstagefright.cppMoha
This is the same fix that Hendrik made to dxva2_hevc. It should be
equally required here, although I don't see any visual difference.
Nevertheless, best to stay consistent.
Signed-off-by: Philip Langdale
---
libavcodec/vdpau_hevc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
The latest nvidia 355.06 drivers fixes the interleaving bug when
video surfaces are rendered. It still seems to be broken for
read-back with getBits but that's sufficiently uninteresting that
I don't think we need to wait for it to remove the flag.
Signed-off-by: Philip Langdale
---
libavcodec/v
With the latest nvidia driver update, HEVC decoding basically works now.
Philip Langdale (3):
avcodec/vdpau_hevc: Remove experimental flag
avcodec/vdpau_hevc: Properly signal the num_delta_pocs from the SPS
RPS
MAINTAINERS: Add myself to vdpau maintainers
MAINTAINERS | 3 ++
On Fri, 31 Jul 2015 19:25:58 +0530
Niklesh Lalwani wrote:
> From: Niklesh
>
> The font names are extracted from the font table, present in text
> sample entry. More than one fonts can be present, which is taken care
> of in the patch.
>
> Signed-off-by: Niklesh
> ---
> libavcodec/movtextdec.
Hi Ivan,
On Mon, Aug 3, 2015 at 4:50 PM, Ivan Uskov wrote:
> Hello Ronald,
>
> Monday, August 3, 2015, 11:37:22 PM, you wrote:
>
> RSB> On Mon, Aug 3, 2015 at 3:25 PM, Ivan Uskov
> wrote:
>
> >> By the way, about old implementation which "worked fine".
> >> It just did drop all buffered frames
Ok. i'll drop this patch . Does outputting stream DURATION values in
matroskaenc.c as string tag's , (same as mkvmerge does ) seem ok? Atleast
then, I can parse those string metadata in our own video pipeline which
will solve my use case.
On Sat, Aug 1, 2015 at 11:42 AM, wm4 wrote:
> On Sat,
On Sun, 2 Aug 2015 17:35:59 +0200, Paul B Mahol wrote:
[...]
> +@item 0rdiv
> +@item 1rdiv
> +@item 2rdiv
> +@item 3rdiv
> +Set multiplicator for calculated value for each plane.
"Default is 1.0."
Can you use the word "multiplier" instead?
Mentioning range would be helpful, if possible.
> +@
On Tue, Aug 04, 2015 at 12:57:38AM +0200, wm4 wrote:
> On Tue, 4 Aug 2015 00:51:17 +0200
> Michael Niedermayer wrote:
>
> > On Tue, Aug 04, 2015 at 12:12:24AM +0200, wm4 wrote:
>
> > > > As well as benchmark results in some commits like
> > > > 4302a92835313000d4bf8030baae32c2b130d8a1
> > >
> >
The windows SDL audio driver plays the old data in the buffer in a loop if it
is not updated in time. So instead of waiting for data and blocking the the
audio thread, return silence if no data is available.
Should fix ticket #2289.
Signed-off-by: Marton Balint
---
ffplay.c | 7 +++
1 file
On Tue, 4 Aug 2015 00:51:17 +0200
Michael Niedermayer wrote:
> On Tue, Aug 04, 2015 at 12:12:24AM +0200, wm4 wrote:
> > > As well as benchmark results in some commits like
> > > 4302a92835313000d4bf8030baae32c2b130d8a1
> >
> > avcodec/pcm: Better min_size for ff_alloc_packet2()
> >
> >
On Tue, Aug 04, 2015 at 12:12:24AM +0200, wm4 wrote:
> On Mon, 3 Aug 2015 22:59:48 +0200
> Michael Niedermayer wrote:
>
> > On Mon, Aug 03, 2015 at 10:05:23PM +0200, wm4 wrote:
> > > On Mon, 3 Aug 2015 19:17:16 +0200
> > > Michael Niedermayer wrote:
> > >
> > > > From: Michael Niedermayer
> >
Signed-off-by: James Almer
---
libavcodec/x86/sbrdsp.asm | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/libavcodec/x86/sbrdsp.asm b/libavcodec/x86/sbrdsp.asm
index 083461a..a96451f 100644
--- a/libavcodec/x86/sbrdsp.asm
+++ b/libavcodec/x8
On Mon, 3 Aug 2015 22:59:48 +0200
Michael Niedermayer wrote:
> On Mon, Aug 03, 2015 at 10:05:23PM +0200, wm4 wrote:
> > On Mon, 3 Aug 2015 19:17:16 +0200
> > Michael Niedermayer wrote:
> >
> > > From: Michael Niedermayer
> > >
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavc
On Mon, Aug 03, 2015 at 11:45:51PM +0200, Michael Niedermayer wrote:
> On Mon, Aug 03, 2015 at 10:45:52PM +0200, wm4 wrote:
> > On Mon, 3 Aug 2015 17:33:15 -0300
> > James Almer wrote:
> >
> > > On 03/08/15 5:05 PM, wm4 wrote:
> > > > - we'll probably see a flood of commits changing random encode
On Mon, Aug 03, 2015 at 10:45:52PM +0200, wm4 wrote:
> On Mon, 3 Aug 2015 17:33:15 -0300
> James Almer wrote:
>
> > On 03/08/15 5:05 PM, wm4 wrote:
> > > - we'll probably see a flood of commits changing random encoders to
> > > this new function, for no reason (I'm looking forward to be proven
Michael Niedermayer niedermayer.cc> writes:
> > But this should not be necessary if somebody
> > can confirm that it is ok to seek back x bytes
> > in a demuxer.
>
> it is safe if ffio_ensure_seekback() is used with
> appropriate arguments before these x bytes are read
> (or the stream is see
Carl Eugen Hoyos ag.or.at> writes:
> Attached patch fixes ticket #4747 for me, I don't know how to
> detect that the wave atom contains no frma / alac atom...
New patch sent that detects and skips the frma atom or
reads the extradata if no frma atom is present.
Carl Eugen
Hi!
Attached patch fixes ticket #4747 and should not introduce any
theoretical regressions.
Please review, Carl Eugendiff --git a/libavformat/mov.c b/libavformat/mov.c
index 154d2f8..f3cb71f 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1435,6 +1435,28 @@ static int mov_read_wave(MO
On Mon, Aug 03, 2015 at 10:05:23PM +0200, wm4 wrote:
> On Mon, 3 Aug 2015 19:17:16 +0200
> Michael Niedermayer wrote:
>
> > From: Michael Niedermayer
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/internal.h |9 +++--
> > 1 file changed, 7 insertions(+), 2 deletion
Hello Ronald,
Monday, August 3, 2015, 11:37:22 PM, you wrote:
RSB> On Mon, Aug 3, 2015 at 3:25 PM, Ivan Uskov wrote:
>> By the way, about old implementation which "worked fine".
>> It just did drop all buffered frames at decoder re-init on new
>> sequence header, there is nice comment inside ol
On Mon, 3 Aug 2015 17:33:15 -0300
James Almer wrote:
> On 03/08/15 5:05 PM, wm4 wrote:
> > - we'll probably see a flood of commits changing random encoders to
> > this new function, for no reason (I'm looking forward to be proven
> > wrong)
>
> ff_alloc_packet() is marked as deprecated. I wo
Hi,
On Mon, Aug 3, 2015 at 3:25 PM, Ivan Uskov wrote:
> By the way, about old implementation which "worked fine".
> It just did drop all buffered frames at decoder re-init on new
> sequence header, there is nice comment inside old qsvdec_h264.c:
> /* TODO: flush delayed frames on reinit */
Eac
On 03/08/15 5:05 PM, wm4 wrote:
> - we'll probably see a flood of commits changing random encoders to
> this new function, for no reason (I'm looking forward to be proven
> wrong)
ff_alloc_packet() is marked as deprecated. I wouldn't find it odd at
all if maintainers for different encoders mak
On 03/08/15 7:27 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Aug 3, 2015 at 2:41 AM, James Almer wrote:
>
>> Only two functions that use xop multiply-accumulate instructions where the
>> first operand is the same as the fourth actually took advantage of the
>> macros.
>>
>> This further reduce
On Mon, Aug 3, 2015 at 10:12 PM, Nicolas George wrote:
> Le sextidi 16 thermidor, an CCXXIII, Hendrik Leppkes a écrit :
>> Mixing stdio and low-level IO on stdin is not safe.
>> ---
>> ffmpeg.c | 12 ++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/ffmpeg.c b/ff
Le sextidi 16 thermidor, an CCXXIII, Hendrik Leppkes a écrit :
> Mixing stdio and low-level IO on stdin is not safe.
> ---
> ffmpeg.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 5575e2f..206b3dc 100644
> --- a/ffmpeg.c
> +++ b
On Sat, Aug 01, 2015 at 11:29:05AM +1000, Peter Ross wrote:
> On Fri, Jul 31, 2015 at 08:56:49PM -0400, Ganesh Ajjanagadde wrote:
> > On Fri, Jul 31, 2015 at 8:08 PM, Michael Niedermayer
> > wrote:
> > > On Fri, Jul 31, 2015 at 07:33:01PM -0400, Ganesh Ajjanagadde wrote:
> > >> On Fri, Jul 31, 201
On Mon, 3 Aug 2015 19:17:16 +0200
Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/internal.h |9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
>
On Mon, Aug 3, 2015 at 9:30 PM, Nicolas George wrote:
> Le sextidi 16 thermidor, an CCXXIII, Michael Niedermayer a écrit :
>> i also found this comment in a patch in my inbox:
>>
>> + /* When using Standard C input functions, also check if there
>> + is anything in the buffer. After a call to s
Mixing stdio and low-level IO on stdin is not safe.
---
ffmpeg.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 5575e2f..206b3dc 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3428,9 +3428,17 @@ static int check_keyboard_interaction(int64_t cu
On Mon, Aug 03, 2015 at 10:32:02AM +, Carl Eugen Hoyos wrote:
> Paul B Mahol gmail.com> writes:
>
> > > Attached patch fixes ticket #4747 for me,
>
> > > I don't know how to detect that the wave
> > > atom contains no frma / alac atom...
> >
> > And that is mentioned because?
>
> The fil
On Mon, Aug 03, 2015 at 09:30:33PM +0200, Nicolas George wrote:
> Le sextidi 16 thermidor, an CCXXIII, Michael Niedermayer a écrit :
> > i also found this comment in a patch in my inbox:
> >
> > + /* When using Standard C input functions, also check if there
> > + is anything in the buffer. Aft
To avoid duplicate code
---
tests/api/api-h264-test.c | 47 +++
1 file changed, 15 insertions(+), 32 deletions(-)
diff --git a/tests/api/api-h264-test.c b/tests/api/api-h264-test.c
index 4d2a5b0..e4bc0b8 100644
--- a/tests/api/api-h264-test.c
+++ b/test
Hello wm4,
Monday, August 3, 2015, 10:33:30 PM, you wrote:
w> I was under the impression that the original Libav code handled this
w> correctly.
Unfortunately not, you can still see this comment at line 371
https://git.libav.org/?p=libav.git;a=blob;f=libavcodec/qsvdec.c
and there is no any flush
On Mon, Aug 03, 2015 at 08:51:10AM +0100, tim nicholson wrote:
> On 31/07/15 17:19, Michael Niedermayer wrote:
> > On Fri, Jul 31, 2015 at 05:37:12PM +0200, Clément Bœsch wrote:
> > [...]
> >> So in order for the community to continue this, I'd say we probably need
> >> to have some help for:
> >>
On Mon, Aug 3, 2015 at 9:33 PM, wm4 wrote:
> On Mon, 3 Aug 2015 22:25:20 +0300
> Ivan Uskov wrote:
>
>> Hello Michael, Hendrik,
>>
>> I would like to make sure about following moment regarding handling of
>> sequence header changing. The decoder has buffering of decoded frames,
>> so when new fra
On Mon, 3 Aug 2015 22:25:20 +0300
Ivan Uskov wrote:
> Hello Michael, Hendrik,
>
> I would like to make sure about following moment regarding handling of
> sequence header changing. The decoder has buffering of decoded frames,
> so when new frame dimensions are detected we can not just reset
> de
Le sextidi 16 thermidor, an CCXXIII, Michael Niedermayer a écrit :
> i also found this comment in a patch in my inbox:
>
> + /* When using Standard C input functions, also check if there
> + is anything in the buffer. After a call to such functions,
> + the input waiting in the pipe will be c
Hello Michael, Hendrik,
I would like to make sure about following moment regarding handling of
sequence header changing. The decoder has buffering of decoded frames,
so when new frame dimensions are detected we can not just reset
decoder, we should to deffer re-init and switch decoder to some
"fl
On Mon, Aug 03, 2015 at 07:26:30PM +0200, Michael Niedermayer wrote:
> On Mon, Aug 03, 2015 at 05:21:58PM +0200, Nicolas George wrote:
> > Le sextidi 16 thermidor, an CCXXIII, Hendrik Leppkes a écrit :
> > > The FILE struct is opaque in MSVC 2015, and the members of this struct
> > > were never mea
Hi,
On Mon, Jul 27, 2015 at 6:01 AM, wrote:
> +++ b/libavcodec/mips/vp8dsp_init_mips.c
>
Is there a reason the init code lives in a different file than the
implementations? It seems to me all symbols could be static if the init
code lived in the same file as the implementation. This isn't a big
On 03/08/15 3:25 PM, Hendrik Leppkes wrote:
> On Mon, Aug 3, 2015 at 8:21 PM, James Almer wrote:
>> On 03/08/15 3:12 PM, Hendrik Leppkes wrote:
>>> Since I wasn't sure in which direction of packed/planar the problem
>>> usually happened, I tried 8ch s32 -> 8ch s32p, 8ch s32 -> 2ch s32p,
>>> 8ch s3
On Mon, Aug 3, 2015 at 5:08 PM, Hendrik Leppkes wrote:
> The FILE struct is opaque in MSVC 2015, and the members of this struct
> were never meant to be accessed in any case.
>
> No conditions are known where this check was needed to get characters
> from stdin.
I can confirm that this patch fixe
On Mon, Aug 3, 2015 at 8:21 PM, James Almer wrote:
> On 03/08/15 3:12 PM, Hendrik Leppkes wrote:
>> Since I wasn't sure in which direction of packed/planar the problem
>> usually happened, I tried 8ch s32 -> 8ch s32p, 8ch s32 -> 2ch s32p,
>> 8ch s32p -> 8ch s32 and 8ch s32p -> 2ch s32, and all wor
On 03/08/15 3:12 PM, Hendrik Leppkes wrote:
> Since I wasn't sure in which direction of packed/planar the problem
> usually happened, I tried 8ch s32 -> 8ch s32p, 8ch s32 -> 2ch s32p,
> 8ch s32p -> 8ch s32 and 8ch s32p -> 2ch s32, and all work fine.
>
> - Hendrik
If those tests were done with lib
On Mon, Aug 3, 2015 at 5:26 PM, James Almer wrote:
> On 03/08/15 9:50 AM, Hendrik Leppkes wrote:
>> On Mon, Aug 3, 2015 at 10:31 AM, Henrik Gramner wrote:
>>> On Mon, Aug 3, 2015 at 2:18 AM, Ronald S. Bultje wrote:
So, I think the code changes themselves look mostly healthy. Is there a
On Mon, Aug 3, 2015 at 7:26 PM, Michael Niedermayer
wrote:
> On Mon, Aug 03, 2015 at 05:21:58PM +0200, Nicolas George wrote:
>> Le sextidi 16 thermidor, an CCXXIII, Hendrik Leppkes a écrit :
>> > The FILE struct is opaque in MSVC 2015, and the members of this struct
>> > were never meant to be acc
On Mon, Aug 03, 2015 at 10:26:51AM +, Carl Eugen Hoyos wrote:
> Michael Niedermayer gmx.at> writes:
>
> > -git push
> > +git push origin master --dry-run
>
> Doesn't git push -n also work?
yes, i intentionally used the long form as it should be easier to
remember and harder to get wrong in
On Mon, Aug 03, 2015 at 05:21:58PM +0200, Nicolas George wrote:
> Le sextidi 16 thermidor, an CCXXIII, Hendrik Leppkes a écrit :
> > The FILE struct is opaque in MSVC 2015, and the members of this struct
> > were never meant to be accessed in any case.
> >
> > No conditions are known where this ch
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
libavcodec/internal.h |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 202f82d..17c86a3 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/interna
On 03/08/15 9:50 AM, Hendrik Leppkes wrote:
> On Mon, Aug 3, 2015 at 10:31 AM, Henrik Gramner wrote:
>> On Mon, Aug 3, 2015 at 2:18 AM, Ronald S. Bultje wrote:
>>> So, I think the code changes themselves look mostly healthy. Is there a
>>> behavioural difference before/after this patch? (Like: we
Le sextidi 16 thermidor, an CCXXIII, Hendrik Leppkes a écrit :
> The FILE struct is opaque in MSVC 2015, and the members of this struct
> were never meant to be accessed in any case.
>
> No conditions are known where this check was needed to get characters
> from stdin.
> ---
>
> If someone does
The FILE struct is opaque in MSVC 2015, and the members of this struct
were never meant to be accessed in any case.
No conditions are known where this check was needed to get characters
from stdin.
---
If someone does know which particular purpose this check serves, please
do let me know, and I'l
Hi all,
Can you please remove me from this group.
Thanks,
Hitesh
On Aug 3, 2015 2:14 AM, "Henrik Gramner" wrote:
> Change ALLOC_STACK to always align the stack before allocating stack space
> for
> consistency. Previously alignment would occur either before or after
> allocating
> stack space d
Hi,
On Mon, Aug 3, 2015 at 8:50 AM, Hendrik Leppkes wrote:
> On Mon, Aug 3, 2015 at 10:31 AM, Henrik Gramner
> wrote:
> > On Mon, Aug 3, 2015 at 2:18 AM, Ronald S. Bultje
> wrote:
> >> So, I think the code changes themselves look mostly healthy. Is there a
> >> behavioural difference before/af
Le sextidi 16 thermidor, an CCXXIII, Hendrik Leppkes a écrit :
> Trashing the state even more often just because there is one example
> where this can already happen is not a valid reasoning.
The changes should be applied because they are the RIGHT behaviour, as I
explained in this mail:
http://f
On Mon, Aug 3, 2015 at 10:40 AM, Hendrik Leppkes wrote:
> On Mon, Aug 3, 2015 at 4:34 PM, Ganesh Ajjanagadde wrote:
>> On Sat, Aug 1, 2015 at 6:54 AM, Nicolas George wrote:
>>> Le quartidi 14 thermidor, an CCXXIII, Michael Niedermayer a écrit :
> ffmpeg -lavfi testsrc -f framecrc | head
>>>
On Mon, Aug 3, 2015 at 4:34 PM, Ganesh Ajjanagadde wrote:
> On Sat, Aug 1, 2015 at 6:54 AM, Nicolas George wrote:
>> Le quartidi 14 thermidor, an CCXXIII, Michael Niedermayer a écrit :
>>> > ffmpeg -lavfi testsrc -f framecrc | head
>>> Thats interresting, i tried this and it did not trash my term
On Sat, Aug 1, 2015 at 6:54 AM, Nicolas George wrote:
> Le quartidi 14 thermidor, an CCXXIII, Michael Niedermayer a écrit :
>> > ffmpeg -lavfi testsrc -f framecrc | head
>> Thats interresting, i tried this and it did not trash my terminal
>> also ive almost never seen ffmpeg trash my terminal with
Hello Hendrik,
Thank you very much for the bugreport, I believe I will able to fix all these
issues
quick.
In general all these issues are known and in my todo list.
Monday, August 3, 2015, 3:18:04 PM, you wrote:
HL> Hey,
HL> after a discussion on IRC about the declining quality of the QSV
HL
Hello Michael,
Monday, August 3, 2015, 12:14:39 PM, you wrote:
MN> On Mon, Aug 03, 2015 at 11:36:09AM +0300, Ivan Uskov wrote:
>> Hello Hendrik,
>>
>> Monday, August 3, 2015, 12:45:36 AM, you wrote:
>>
>>
>> HL> The decoder should depend on the header in configure directly already,
>> HL> so i
On Sun, Aug 2, 2015 at 2:10 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Aug 2, 2015 at 7:10 AM, Hendrik Leppkes wrote:
>
>> On Sun, Aug 2, 2015 at 1:07 PM, Hendrik Leppkes
>> wrote:
>> > It needs to point to the value from the sps rps, not the final computed
>> one from the slice header.
>> >
2015-08-03 21:53 GMT+09:00 wm4 :
> On Mon, 3 Aug 2015 10:32:02 + (UTC)
> Carl Eugen Hoyos wrote:
>
> > Paul B Mahol gmail.com> writes:
> >
> > > > Attached patch fixes ticket #4747 for me,
> >
> > > > I don't know how to detect that the wave
> > > > atom contains no frma / alac atom...
> > >
On Mon, 3 Aug 2015 10:32:02 + (UTC)
Carl Eugen Hoyos wrote:
> Paul B Mahol gmail.com> writes:
>
> > > Attached patch fixes ticket #4747 for me,
>
> > > I don't know how to detect that the wave
> > > atom contains no frma / alac atom...
> >
> > And that is mentioned because?
>
> The fil
On Mon, Aug 3, 2015 at 10:31 AM, Henrik Gramner wrote:
> On Mon, Aug 3, 2015 at 2:18 AM, Ronald S. Bultje wrote:
>> So, I think the code changes themselves look mostly healthy. Is there a
>> behavioural difference before/after this patch? (Like: were there bugs in
>> the original code, or does th
On Mon, 3 Aug 2015 14:18:04 +0200
Hendrik Leppkes wrote:
> Hey,
>
> after a discussion on IRC about the declining quality of the QSV
> decoders, I decided to do actual tests and document the results, so we
> can get these fixed.
>
> A lot of these issues are regressions from recent changes, and
On Mon, Aug 03, 2015 at 02:18:04PM +0200, Hendrik Leppkes wrote:
> Hey,
>
> after a discussion on IRC about the declining quality of the QSV
> decoders, I decided to do actual tests and document the results, so we
> can get these fixed.
>
> A lot of these issues are regressions from recent change
Hey,
after a discussion on IRC about the declining quality of the QSV
decoders, I decided to do actual tests and document the results, so we
can get these fixed.
A lot of these issues are regressions from recent changes, and work
fine in the original qsv decoders merged from libav, so they should
On Mon, 3 Aug 2015 13:27:48 +0200
"Romeyke, Andreas" wrote:
> Dear FFMPEG-developer,
>
> in case of digital preservation I want to convert/normalize videos to
> files with Matroska-Container, FFV1 video- and wave-PCM audiocodec.
>
> I am using this commandline:
>
> ffmpeg -i inputvideo.webm -c
Hi,
On Mon, Aug 3, 2015 at 7:27 AM, Romeyke, Andreas <
andreas.rome...@slub-dresden.de> wrote:
> And secondly, could you explain the difference between the various
> PCM-encodings? My assumpation was, that
> * the unsigned variant are "linear PCM", because there are only positive
> quantization
On Mon, Aug 3, 2015 at 1:37 AM, Ronald S. Bultje wrote:
> Does silencing these warnings still work after this patch?
Yes, undefining __SECT__ is no longer needed after this patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/m
On 8/3/15, Romeyke, Andreas wrote:
> Dear FFMPEG-developer,
>
> in case of digital preservation I want to convert/normalize videos to files
> with Matroska-Container, FFV1 video- and wave-PCM audiocodec.
>
> I am using this commandline:
>
> ffmpeg -i inputvideo.webm -c:v ffv1 -level 3 -g 1 -coder
Dear FFMPEG-developer,
in case of digital preservation I want to convert/normalize videos to files
with Matroska-Container, FFV1 video- and wave-PCM audiocodec.
I am using this commandline:
ffmpeg -i inputvideo.webm -c:v ffv1 -level 3 -g 1 -coder 1 -context 1 -slices
16 -slicecrc 1 -report -c:
Hi,
On Mon, Aug 3, 2015 at 4:42 AM, Shivraj Patil
wrote:
> Hi,
> May I request somebody from maintainers to review this patch please?
Sorry, missed the original email - I'll review later today.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpe
Paul B Mahol gmail.com> writes:
> > Attached patch fixes ticket #4747 for me,
> > I don't know how to detect that the wave
> > atom contains no frma / alac atom...
>
> And that is mentioned because?
The file from ticket #4747 does not contain an
alac atom which is required for alac decoding
Michael Niedermayer gmx.at> writes:
> -git push
> +git push origin master --dry-run
Doesn't git push -n also work?
Anyway, lgtm.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi,
On Mon, Aug 3, 2015 at 2:41 AM, James Almer wrote:
> Only two functions that use xop multiply-accumulate instructions where the
> first operand is the same as the fourth actually took advantage of the
> macros.
>
> This further reduces differences with x264's x86inc.
>
> Signed-off-by: James
Shiz shiz.me> writes:
> On Xcode's clang on OS X, $cc --version will output a 'Configured with:'
> line to stderr, which clobbers the configure script output. As this line
> serves no further purpose, it should be silenced.
I cannot test atm, but the patch looks like a
very good idea to me.
Ca
On Xcode's clang on OS X, $cc --version will output a 'Configured with:'
line to stderr, which clobbers the configure script output. As this line
serves no further purpose, it should be silenced.
The same applies to apple-gcc 4.2.1, which complains that it can not
understand the kernel version it
From: Michael Niedermayer
I do not think having "git push" as example is a good idea.
The command has a very high chance of pushing things which are unwanted to be
pushed
Signed-off-by: Michael Niedermayer
---
doc/git-howto.texi |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
d
On Mon, Aug 03, 2015 at 11:36:09AM +0300, Ivan Uskov wrote:
> Hello Hendrik,
>
> Monday, August 3, 2015, 12:45:36 AM, you wrote:
>
>
> HL> The decoder should depend on the header in configure directly already,
> HL> so its not built at all when the header is not available.
> In general I do not
On Mon, Aug 3, 2015 at 10:36 AM, Ivan Uskov wrote:
> Hello Hendrik,
>
> Monday, August 3, 2015, 12:45:36 AM, you wrote:
>
>
> HL> The decoder should depend on the header in configure directly already,
> HL> so its not built at all when the header is not available.
> In general I do not understandi
Hello Hendrik,
Monday, August 3, 2015, 12:58:28 AM, you wrote:
>> Because if it's missing, ff_get_format() refuses to return the QSV
>> opaque format. I think. So you need AVHWAccels for every codec/decoder
>> combination.
HL> But if you use the normal h264 decoder and select the QSV format in
H
Hello Hendrik,
Monday, August 3, 2015, 12:45:36 AM, you wrote:
HL> The decoder should depend on the header in configure directly already,
HL> so its not built at all when the header is not available.
In general I do not understanding why it necessary at all.
All necessary headers currently avail
On Mon, Aug 3, 2015 at 2:18 AM, Ronald S. Bultje wrote:
> So, I think the code changes themselves look mostly healthy. Is there a
> behavioural difference before/after this patch? (Like: were there bugs in
> the original code, or does this change behaviour of previous code in a
> significant way?)
On Fri, Jul 31, 2015 at 08:57:49PM +0200, Clément Bœsch wrote:
> On Thu, Jul 30, 2015 at 05:12:21PM +0800, Zhang Rui wrote:
> [...]
> > BTW:
> > I think current patch is OK enough.
>
> I will push it soon (unless Sebastien has write access?)
>
Applied.
> > Async-mode could be an experimental op
On 31/07/15 17:19, Michael Niedermayer wrote:
> On Fri, Jul 31, 2015 at 05:37:12PM +0200, Clément Bœsch wrote:
> [...]
>> So in order for the community to continue this, I'd say we probably need
>> to have some help for:
>>
>> - guidelines on the merge strategies
>> - step-by-step on the release pr
On Mon, Aug 3, 2015 at 9:02 AM, Dave Yeo wrote:
> Here, if the 32 is left as the alignment, the build dies.
That's why I removed the 32. It seems to run fine on Haswell (which
has AVX2) without it, so I don't know the reason for why it was added
in the first place.
___
On 08/02/15 11:04 PM, Clément Bœsch wrote:
On Sun, Aug 02, 2015 at 10:40:02PM +0200, Henrik Gramner wrote:
The .text section is already 16-byte aligned by default on all supported
platforms so `SECTION_TEXT` isn't any different from `SECTION .text`.
naive question, what about the few SECTION_T
92 matches
Mail list logo
