On Wed, Oct 21, 2015 at 11:14:02PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavformat/electronicarts.c | 19 +++
> 1 file changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
> index c0b6d
On 10/22/15, Peter Ross wrote:
> Signed-off-by: Peter Ross
>
> http://wiki.multimedia.cx/index.php?title=Electronic_Arts_SCxl
> ---
> libavformat/electronicarts.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
> index 5d21d49.
On Thu, Oct 15, 2015 at 8:01 PM, Ganesh Ajjanagadde
wrote:
> Current code is fine, this just adds robustness.
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavutil/wchar_filename.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
On Sun, 18 Oct 2015, Michael Niedermayer wrote:
On Sun, Oct 18, 2015 at 12:24:05AM +0200, Marton Balint wrote:
Signed-off-by: Marton Balint
---
ffmpeg.c | 27 ---
1 file changed, 12 insertions(+), 15 deletions(-)
LGTM
thanks
Applied, thanks.
Marton
__
On Mon, 19 Oct 2015, Michael Niedermayer wrote:
On Mon, Oct 19, 2015 at 01:57:31AM +0200, Marton Balint wrote:
Signed-off-by: Marton Balint
---
ffmpeg.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
should be ok
Applied, thanks.
Marton
_
On Sun, 18 Oct 2015, Michael Niedermayer wrote:
On Sun, Oct 18, 2015 at 12:38:51AM +0200, Michael Niedermayer wrote:
On Sun, Oct 18, 2015 at 12:24:04AM +0200, Marton Balint wrote:
Signed-off-by: Marton Balint
---
ffmpeg.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ffmpeg.c b/ffmp
On Mon, 19 Oct 2015, Michael Niedermayer wrote:
On Sun, Oct 18, 2015 at 12:07:34PM +0200, Marton Balint wrote:
Signed-off-by: Marton Balint
---
ffmpeg.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 36a68fb..252bc0d 100644
--- a/ffmpeg.c
+++
How this passed through the commit hook?
Signed-off-by: Marton Balint
---
ffmpeg.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ffmpeg.h b/ffmpeg.h
index 5722816..8c232f3 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -273,7 +273,7 @@ typedef struct InputStream {
int
On Wed, Oct 21, 2015 at 10:46 AM Christophe Gisquet <
christophe.gisq...@gmail.com> wrote:
> 2015-10-18 2:47 GMT+02:00 Timothy Gu :
> > This function is only used within other inline asm functions, hence the
> > HAVE_MMX_INLINE guard. Per recent discussions, we should not worry about
> > the perfo
Signed-off-by: Peter Ross
http://wiki.multimedia.cx/index.php?title=Electronic_Arts_SCxl
---
libavformat/electronicarts.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index 5d21d49..335a635 100644
--- a/libavformat/electronicarts
On Mon, Oct 19, 2015 at 11:35:15AM +0200, Paul B Mahol wrote:
> Such files have empty gaps between chunks.
>
> Signed-off-by: Paul B Mahol
> ---
> libavformat/electronicarts.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/electronicarts.c b/libavfo
On Tue, Oct 20, 2015 at 11:50 PM, Michael Niedermayer <
mich...@niedermayer.cc> wrote:
>
> the last element to be written should be checked, so that if
> initialization is done by 2 threads at the same time, neither can
> return from this function without initialization having finished
>
> also the
On 21.10.2015 01:46, Michael Niedermayer wrote:
> On Wed, Oct 21, 2015 at 12:36:59AM +0200, Andreas Cadhalpun wrote:
>> avpriv_ac3_parse_header was removed in commit 3dfb643.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavcodec/ac3_parser.c | 4 ++--
>> libavcodec/ac3_parser.h | 2 +-
>> l
On 21.10.2015 11:48, Michael Niedermayer wrote:
> On Wed, Oct 14, 2015 at 01:50:33AM +0200, Andreas Cadhalpun wrote:
>> It is only used inside libavcodec.
>>
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavcodec/h264_slice.c | 2 +-
>> libavcodec/internal.h | 2 +-
>> libavcodec/utils.c
On Wed, Oct 21, 2015 at 11:31:45PM +0200, Tomas Härdin wrote:
> On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote:
> > ---
> > libavformat/mxfdec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 94a953b..0
On Wed, Oct 21, 2015 at 11:31:48PM +0200, Tomas Härdin wrote:
> On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote:
> > ---
> > libavformat/mxfdec.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 0a
Thanks for all , if you add "*Streaming*" *Presets* To Nvidia Nevec
Presets , like this :
Automatic
Low Latency
Low Latency 2Pass
HQ Low Latency 2Pass
Lossless
HP lossless
Thanks
--
*Best Regards ,*
*Rifat Maswadeh*
*Technical Support Department.*
*Zaytona For **Communications.*
*Ramall
On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote:
> Some files such as those from tickets #2817 & #2776 claim to have constant
> edit unit size but,
> in fact, have some of them that are smaller. This confuses the demuxer that
> tries to infer the
> current edit unit from the position in t
On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote:
> ---
> libavformat/mxfdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 94a953b..0ae7ce6 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@
On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote:
> ---
> libavformat/mxfdec.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 0ae7ce6..593604e 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfde
On Wed, 2015-10-21 at 18:00 +0200, Alexis Ballier wrote:
> klv_decode_ber_length cannot return -1, but can return AVERROR_INVALIDDATA.
> Store its return value in a signed integer (instead of unsigned
> KLVPacket.length) and forward the error appropriately.
> ---
> libavformat/mxfdec.c | 6 --
Signed-off-by: Paul B Mahol
---
libavformat/electronicarts.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/libavformat/electronicarts.c b/libavformat/electronicarts.c
index c0b6d6e..12eec80 100644
--- a/libavformat/electronicarts.c
+++ b/libavformat/elec
On Wed, Oct 21, 2015 at 9:42 PM, Paul Knopf wrote:
> I just realized that I was also getting an error on the stdout.
>
> [h264_qsv @ 00c7e6d8e680] Specified pixel format yuv420p is
> invalid or not supported
>
Which probably means you also get an error return from one of the
initialization fu
On Tue, 2015-10-20 at 16:43 +0200, Marton Balint wrote:
> On Mon, 19 Oct 2015, Tomas Härdin wrote:
>
> > On Mon, 2015-10-19 at 11:40 +0200, Alexis Ballier wrote:
> >> On Mon, 19 Oct 2015 10:30:00 +0200
> >> Michael Niedermayer wrote:
> >>
> >>> On Fri, Oct 16, 2015 at 10:42:32AM +0200, Alexis Bal
On Wed, Oct 21, 2015 at 09:35:39PM +0200, Paul B Mahol wrote:
> On 10/21/15, Tobias Rapp wrote:
> > Analogous to my previous patch to vf_psnr.c the attached patch
> > implements writing SSIM frame stats to standard output if the filename
> > is "-".
> >
> > Regards,
> > Tobias
> >
>
> lgtm
appli
I just realized that I was also getting an error on the stdout.
[h264_qsv @ 00c7e6d8e680] Specified pixel format yuv420p is
invalid or not supported
On Wed, Oct 21, 2015 at 3:13 PM, Paul Knopf
wrote:
> Hey guys,
>
> Is there an example somewhere, using the "h264_qsv" encoder at an API
> le
On 10/21/15, Tobias Rapp wrote:
> Analogous to my previous patch to vf_psnr.c the attached patch
> implements writing SSIM frame stats to standard output if the filename
> is "-".
>
> Regards,
> Tobias
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@f
On Wed, Oct 21, 2015 at 10:32 AM Timothy Gu wrote:
> On Tue, Oct 20, 2015 at 7:36 PM James Almer wrote:
>
>> On 10/20/2015 10:32 PM, Timothy Gu wrote:
>>
> > +; mov type used for src1q, dstq, first reg, second reg
>> > +%macro DIFF_BYTES_LOOP_CORE 4
>> > +%if regsize != 16
>>
>> %if mmsize != 16
Hey guys,
Is there an example somewhere, using the "h264_qsv" encoder at an API level?
Let's say I have an application that encodes and muxes a file to mp4, using
libx264. Is it possible to just switch encoders? Will other things have to
change, like pixel formats?
I switched the encoders just l
On 21.10.15 19:11, wm4 wrote:
On Wed, 21 Oct 2015 18:48:42 +0200
Julian Scheel wrote:
Am 21.10.2015 um 17:24 schrieb wm4:
On Wed, 21 Oct 2015 17:15:14 +0200
Julian Scheel wrote:
Am 21.10.2015 um 16:18 schrieb wm4:
On Wed, 21 Oct 2015 16:07:08 +0200
Hendrik Leppkes wrote:
On Wed, Oct
Hi,
2015-10-18 2:47 GMT+02:00 Timothy Gu :
> This function is only used within other inline asm functions, hence the
> HAVE_MMX_INLINE guard. Per recent discussions, we should not worry about
> the performance of inline asm-only builds.
On a quick glance, looks good.
> The conversion process has
On Tue, Oct 20, 2015 at 7:36 PM James Almer wrote:
> On 10/20/2015 10:32 PM, Timothy Gu wrote:
> > +; mov type used for src1q, dstq, first reg, second reg
> > +%macro DIFF_BYTES_LOOP_CORE 4
> > +%if regsize != 16
>
> %if mmsize != 16
>
> By checking regsize you're using the SSE2 version in the AV
On Wed, 21 Oct 2015 18:48:42 +0200
Julian Scheel wrote:
> Am 21.10.2015 um 17:24 schrieb wm4:
> > On Wed, 21 Oct 2015 17:15:14 +0200
> > Julian Scheel wrote:
> >
> >> Am 21.10.2015 um 16:18 schrieb wm4:
> >>> On Wed, 21 Oct 2015 16:07:08 +0200
> >>> Hendrik Leppkes wrote:
> >>>
> On
Am 21.10.2015 um 17:24 schrieb wm4:
On Wed, 21 Oct 2015 17:15:14 +0200
Julian Scheel wrote:
Am 21.10.2015 um 16:18 schrieb wm4:
On Wed, 21 Oct 2015 16:07:08 +0200
Hendrik Leppkes wrote:
On Wed, Oct 21, 2015 at 3:55 PM, Julian Scheel wrote:
Wait for the first decoded frame to be returned
---
libavformat/mxfdec.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 020294d..606afe6 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -727,6 +727,8 @@ static int mxf_read_content_storage(void *arg, AV
---
libavformat/mxfdec.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 75858fc..020294d 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -192,6 +192,12 @@ typedef struct MXFDescriptor {
---
libavformat/mxfdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 5c224ef..75858fc 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -198,6 +198,7 @@ typedef struct MXFIndexTableSegment {
int edit_unit_byte_count;
---
libavformat/mxfdec.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 2b776f6..5c224ef 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -161,6 +161,7 @@ typedef struct {
int intra_only;
uint64_t sample_count;
---
libavformat/mxfdec.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index e16c678..1320fad 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -722,6 +722,9 @@ static int mxf_read_source_clip(void *arg, AVIOContext *pb,
int tag,
---
libavformat/mxfdec.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 1320fad..2b776f6 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -121,6 +121,8 @@ typedef struct MXFSequence {
typedef struct MXFTimecodeComponent
---
libavformat/mxfdec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 0ae7ce6..593604e 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2767,13 +2767,13 @@ static int mxf_read_header(AVFormatContext *s
Some files such as those from tickets #2817 & #2776 claim to have constant edit
unit size but,
in fact, have some of them that are smaller. This confuses the demuxer that
tries to infer the
current edit unit from the position in the file. By trying to increment the
current edit unit
before rejec
typedef struct MXFTrack { ... } MXFTimecodeComponent; -> typedef struct
MXFTimecodeComponent { ... } MXFTimecodeComponent;
---
libavformat/mxfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 526eca6..e16c678 100644
--- a/l
---
libavformat/mxfdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 94a953b..0ae7ce6 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2959,7 +2959,7 @@ static int mxf_read_packet_old(AVFormatContext *s,
AVP
klv_decode_ber_length cannot return -1, but can return AVERROR_INVALIDDATA.
Store its return value in a signed integer (instead of unsigned
KLVPacket.length) and forward the error appropriately.
---
libavformat/mxfdec.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib
Main patch is patch 4/11 fixing 2 tickets.
Patches 5+ are not very useful by themselves but since I wrote the code
for them trying to understand the issue, I thought I'd just send them anyway.
Those can be dropped without any problem.
Alexis Ballier (11):
libavformat/mxfdec.c: klv_read_packet:
On 2015-10-21 12:18, wm4 wrote:
> with size_t/ptrdiff_t
> being 128 bit, and a new "long long long int" type (I swear, they will
> do it, even if that type name looks horrible).
Please no! Just require a C99 style uint128_t/int128_t type.
signature.asc
Description: OpenPGP digital signature
__
On 2015-10-21 14:44, Clément Bœsch wrote:
> On Wed, Oct 21, 2015 at 06:00:21AM -0400, Ganesh Ajjanagadde wrote:
> [...]
>> why don't you spend 5 minutes trying to outline to beginners like me
>> what is "actually important" in your view?
>>
>
> According to the first 100 answers of the survey, the
On Wed, 21 Oct 2015 17:15:14 +0200
Julian Scheel wrote:
> Am 21.10.2015 um 16:18 schrieb wm4:
> > On Wed, 21 Oct 2015 16:07:08 +0200
> > Hendrik Leppkes wrote:
> >
> >> On Wed, Oct 21, 2015 at 3:55 PM, Julian Scheel wrote:
> >>> Wait for the first decoded frame to be returned by mmal before
Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a
matter of setting the correct MMAL_ENCODING on the input port. To ease the
addition of further supported mmal codecs a macro is introduced to generate
the decoder and decoder class structs.
Signed-off-by: Julian Scheel
---
C
Am 21.10.2015 um 16:18 schrieb wm4:
On Wed, 21 Oct 2015 16:07:08 +0200
Hendrik Leppkes wrote:
On Wed, Oct 21, 2015 at 3:55 PM, Julian Scheel wrote:
Wait for the first decoded frame to be returned by mmal before setting
pix_fmt. This is important for avformat probing to work properly as it is
On Wed, 21 Oct 2015 16:07:08 +0200
Hendrik Leppkes wrote:
> On Wed, Oct 21, 2015 at 3:55 PM, Julian Scheel wrote:
> > Wait for the first decoded frame to be returned by mmal before setting
> > pix_fmt. This is important for avformat probing to work properly as it is
> > one
> > of the criterion
Am 21.10.2015 um 16:09 schrieb Hendrik Leppkes:
On Wed, Oct 21, 2015 at 3:54 PM, Julian Scheel wrote:
Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a
matter of setting the correct MMAL_ENCODING on the input port. To ease the
addition of further supported mmal codecs a m
On Wed, Oct 21, 2015 at 3:54 PM, Julian Scheel wrote:
> Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a
> matter of setting the correct MMAL_ENCODING on the input port. To ease the
> addition of further supported mmal codecs a macro is introduced to generate
> the decoder
On Wed, 21 Oct 2015 15:54:39 +0200
Julian Scheel wrote:
> Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a
> matter of setting the correct MMAL_ENCODING on the input port. To ease the
> addition of further supported mmal codecs a macro is introduced to generate
> the decod
On Wed, Oct 21, 2015 at 3:55 PM, Julian Scheel wrote:
> Wait for the first decoded frame to be returned by mmal before setting
> pix_fmt. This is important for avformat probing to work properly as it is one
> of the criterions to decide whether to decode a frame or not for probing.
>
> Signed-off-
On Wed, 21 Oct 2015 15:55:09 +0200
Julian Scheel wrote:
> Wait for the first decoded frame to be returned by mmal before setting
> pix_fmt. This is important for avformat probing to work properly as it is one
> of the criterions to decide whether to decode a frame or not for probing.
>
> Signed-
Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a
matter of setting the correct MMAL_ENCODING on the input port. To ease the
addition of further supported mmal codecs a macro is introduced to generate
the decoder and decoder class structs.
Signed-off-by: Julian Scheel
---
Wait for the first decoded frame to be returned by mmal before setting
pix_fmt. This is important for avformat probing to work properly as it is one
of the criterions to decide whether to decode a frame or not for probing.
Signed-off-by: Julian Scheel
---
libavcodec/mmaldec.c | 10 +-
1
On Wed, Oct 21, 2015 at 11:04:39AM +0200, wm4 wrote:
> On Wed, 21 Oct 2015 09:00:33 +0200
> Julian Scheel wrote:
>
> > There is no avpriv_atomic_get, instead avpriv_atomic_int_get is to be used
> > for
> > integers. This fixes building mmaldec.
> >
> > Signed-off-by: Julian Scheel
> > ---
> >
On Wed, Oct 21, 2015 at 06:00:21AM -0400, Ganesh Ajjanagadde wrote:
[...]
> why don't you spend 5 minutes trying to outline to beginners like me
> what is "actually important" in your view?
>
According to the first 100 answers of the survey, the majority of the
users want... speed optimisation ab
Please note this is tonight - Don't say you weren't told!
Kieran
On 9 October 2015 at 07:37, Kieran Kunhya wrote:
> Hello,
>
> Please note there will be a trac outage owing to the rerouting of fibre as
> part of the London Underground extension.
>
> Regards,
> Kieran Kunhya
>
> -- Forwar
This implementation does not support TLS listen sockets and loading
CA/Certs from files.
The Windows API does not support loading PEM certs, and would either
require a manual loader or instead be limited to loading Windows PFX
certificates
TLS listen sockets would have to be implemented quite sep
On 10/21/15, Hendrik Leppkes wrote:
> Function protoypes without arguments require a void argument in C,
> instead of an empty list.
> ---
> libavcodec/aacdec_template.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_templ
Function protoypes without arguments require a void argument in C,
instead of an empty list.
---
libavcodec/aacdec_template.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index aabd3f0..c279510 100644
--- a/libavcod
On Wed, Oct 21, 2015 at 6:18 AM, wm4 wrote:
> On Wed, 21 Oct 2015 06:00:21 -0400
> Ganesh Ajjanagadde wrote:
>
>> I don't "expect support" from anyone. Frankly, I have dealt with
>> enough mud from you, who seems to take great pleasure in criticizing
>> or otherwise derailing every patch/discussi
On Wed, Oct 21, 2015 at 6:10 AM, Carl Eugen Hoyos wrote:
> Ganesh Ajjanagadde mit.edu> writes:
>
>> Since you seem to be an "expert" on what things
>> affect this decade, why don't you spend 5 minutes
>> trying to outline to beginners like me what is
>> "actually important" in your view?
>
> Impo
On Wed, 21 Oct 2015 06:00:21 -0400
Ganesh Ajjanagadde wrote:
> I don't "expect support" from anyone. Frankly, I have dealt with
> enough mud from you, who seems to take great pleasure in criticizing
> or otherwise derailing every patch/discussion of mine to not care
> about things either way - if
Ganesh Ajjanagadde mit.edu> writes:
> Since you seem to be an "expert" on what things
> affect this decade, why don't you spend 5 minutes
> trying to outline to beginners like me what is
> "actually important" in your view?
Important is whatever you want to work on.
That can be DTS-XLL or any
On Wed, Oct 21, 2015 at 5:31 AM, Hendrik Leppkes wrote:
> On Wed, Oct 21, 2015 at 11:10 AM, Ganesh Ajjanagadde wrote:
>> On Wed, Oct 21, 2015 at 1:24 AM, Timothy Gu wrote:
>>> On Tue, Oct 20, 2015 at 7:09 PM Ganesh Ajjanagadde wrote:
>>>
Hi all,
It is known that there exist at le
On Wed, 21 Oct 2015 11:53:46 +0200
Hendrik Leppkes wrote:
> On Wed, Oct 21, 2015 at 11:44 AM, Gwenole Beauchesne
> wrote:
> > 2015-10-21 11:27 GMT+02:00 Hendrik Leppkes :
> >> On Sat, Oct 17, 2015 at 9:28 PM, Hendrik Leppkes
> >> wrote:
> >>> On Sat, Oct 17, 2015 at 9:27 PM, Hendrik Leppk
On Wed, Oct 21, 2015 at 11:44 AM, Gwenole Beauchesne wrote:
> 2015-10-21 11:27 GMT+02:00 Hendrik Leppkes :
>> On Sat, Oct 17, 2015 at 9:28 PM, Hendrik Leppkes wrote:
>>> On Sat, Oct 17, 2015 at 9:27 PM, Hendrik Leppkes
>>> wrote:
---
libavcodec/utils.c | 6 ++
1 file changed
On Wed, Oct 14, 2015 at 01:50:33AM +0200, Andreas Cadhalpun wrote:
> It is only used inside libavcodec.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/h264_slice.c | 2 +-
> libavcodec/internal.h | 2 +-
> libavcodec/utils.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions
2015-10-21 11:27 GMT+02:00 Hendrik Leppkes :
> On Sat, Oct 17, 2015 at 9:28 PM, Hendrik Leppkes wrote:
>> On Sat, Oct 17, 2015 at 9:27 PM, Hendrik Leppkes wrote:
>>> ---
>>> libavcodec/utils.c | 6 ++
>>> 1 file changed, 6 insertions(+)
>>>
>>
>> Above patch is submitted as an RFC, however I
On Wed, Oct 21, 2015 at 11:10 AM, Ganesh Ajjanagadde wrote:
> On Wed, Oct 21, 2015 at 1:24 AM, Timothy Gu wrote:
>> On Tue, Oct 20, 2015 at 7:09 PM Ganesh Ajjanagadde wrote:
>>
>>> Hi all,
>>>
>>> It is known that there exist at least certain parts of the codebase
>>> that do not work correctly
On Sat, Oct 17, 2015 at 9:28 PM, Hendrik Leppkes wrote:
> On Sat, Oct 17, 2015 at 9:27 PM, Hendrik Leppkes wrote:
>> ---
>> libavcodec/utils.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>
> Above patch is submitted as an RFC, however I strongly believe its the
> only way to keep hwaccels
> -Ursprüngliche Nachricht-
> Von: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] Im Auftrag
> von Moritz Barsnick
> Gesendet: Mittwoch, 14. Oktober 2015 11:23
> An: FFmpeg development discussions and patches
> Betreff: Re: [FFmpeg-devel] [PATCH] Added QSV based VPP filter
>
> On
On Wed, Oct 21, 2015 at 1:24 AM, Timothy Gu wrote:
> On Tue, Oct 20, 2015 at 7:09 PM Ganesh Ajjanagadde wrote:
>
>> Hi all,
>>
>> It is known that there exist at least certain parts of the codebase
>> that do not work correctly if ints are 64 bits. One of them I noticed
>> was in avutil/intmath.h
On Wed, 21 Oct 2015 09:00:33 +0200
Julian Scheel wrote:
> There is no avpriv_atomic_get, instead avpriv_atomic_int_get is to be used for
> integers. This fixes building mmaldec.
>
> Signed-off-by: Julian Scheel
> ---
> libavcodec/mmaldec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-
On Wed, Oct 21, 2015 at 1:14 AM, Mark Harris wrote:
> On Tue, Oct 20, 2015 at 7:08 PM, Ganesh Ajjanagadde wrote:
>> Hi all,
>>
>> It is known that there exist at least certain parts of the codebase
>> that do not work correctly if ints are 64 bits. One of them I noticed
>> was in avutil/intmath.h
On Tue, 20 Oct 2015 16:57:49 -0700
Dale Curtis wrote:
> Minor waste and more annoyingly triggers race detectors when the
> re-initialization happens across multiple threads. cos(0) == 1 and by
> default statics initialize to 0, so this check is safe.
>
> Signed-off-by: Dale Curtis
> ---
> liba
>> Any I/O can cause delay. When the user close the window, they want it to
>> close immediately, not in five seconds.
Can you confirm that the problem is blocking io, and more generally
blocking system calls more than just io ? (i mean, we must take no risk to
have to wait, versus doing some non b
There is no avpriv_atomic_get, instead avpriv_atomic_int_get is to be used for
integers. This fixes building mmaldec.
Signed-off-by: Julian Scheel
---
libavcodec/mmaldec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mmaldec.c b/libavcodec/mmaldec.c
index bb8f17
83 matches
Mail list logo