On Mon, Dec 14, 2015 at 02:26:38PM +0100, Matthieu Bouron wrote:
> On Fri, Dec 11, 2015 at 1:32 PM, Matthieu Bouron
> wrote:
>
> > From: Matthieu Bouron
> >
> > ---
> > libavfilter/avfilter.c | 1 +
> > libavfilter/avfilter.h | 5 +
> > libavfilter/video.c| 38
>
> using a random IV value would break any regression tests
> see AVFMT_FLAG_BITEXACT
>
Fixed, only generating a random IV when bitexact is not enabled.
Updated patch files attached.
>
> is this filling in a random IV that later is overridden ?
> random_seed() can be slow so it would be better
> are these encrypted mp4 files some kind of standard encryption?
>
Yes, these files conform to the common encryption specification ISO/IEC 23001-7
> rephrased... will encrypted files created by ffmpeg be able to be
> decrypted/decoded and played by quicktime? or any other player?
> (assuming oth
On Tue, Dec 15, 2015 at 10:00 AM, Michael Niedermayer
wrote:
> On Mon, Dec 14, 2015 at 02:26:38PM +0100, Matthieu Bouron wrote:
> > On Fri, Dec 11, 2015 at 1:32 PM, Matthieu Bouron <
> matthieu.bou...@gmail.com>
> > wrote:
> >
> > > From: Matthieu Bouron
> > >
> > > ---
> > > libavfilter/avfilt
On Mon, Dec 14, 2015 at 6:18 PM, Michael Niedermayer
wrote:
> On Mon, Dec 14, 2015 at 05:49:48PM +0100, Matthieu Bouron wrote:
> > From: Matthieu Bouron
> >
> > Also use the input frame format instead of the AVCodecContext one
> according
> > to the documentation of AVCodecContext.get_buffer2().
I found that the ffmpeg H.265 decoder can't run on the iOS platform when I
enable the neon assembly code, it crashed when playing the H.265 clip. When
disable the neon assembly code it works fine. What's the problem with the H.265
neon assembly code?
Best regards,
Zhuhb
_
On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote:
> Hallo Michael,
>
> On Mon, 14 Dec 2015 23:18:39 +0100, Michael Niedermayer wrote:
> > On Mon, Dec 14, 2015 at 07:36:51PM +0100, Jean Delvare wrote:
> > > As I understand it, the temporary stack buffer "src_data" was
> > > introduced s
On Tue, Dec 15, 2015 at 10:07:23 +, Zhu Hongbo wrote:
> I found that the ffmpeg H.265 decoder can't run on the iOS platform
> when I enable the neon assembly code, it crashed when playing the
> H.265 clip. When disable the neon assembly code it works fine. What's
> the problem with the H.265 n
On Tue, Dec 15, 2015 at 11:20 AM, Michael Niedermayer wrote:
> On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote:
>> Hallo Michael,
>>
>> On Mon, 14 Dec 2015 23:18:39 +0100, Michael Niedermayer wrote:
>> > On Mon, Dec 14, 2015 at 07:36:51PM +0100, Jean Delvare wrote:
>> > > As I underst
On Tuesday 15 December 2015 11:29:58 am Moritz Barsnick wrote:
> On Tue, Dec 15, 2015 at 10:07:23 +, Zhu Hongbo wrote:
> > I found that the ffmpeg H.265 decoder can't run on the iOS platform
> > when I enable the neon assembly code, it crashed when playing the
> > H.265 clip. When disable the
On Tue, 15 Dec 2015 11:20:40 +0100, Michael Niedermayer wrote:
> yes, I have no real oppinion on this except that C is insane or I am
C is insane, who would dare to argue otherwise? ;-)
More than the language itself, the fact that the compilers think they
can reorder instructions the way they lik
Hi Hendrik,
On Tue, 15 Dec 2015 11:31:57 +0100, Hendrik Leppkes wrote:
> On Tue, Dec 15, 2015 at 11:20 AM, Michael Niedermayer
> wrote:
> > On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote:
> >> Also I can see 12 occurrences of the same cast for this parameter of
> >> function av_ima
> >
> > +struct AVAESCTR;
>
> Is this needed?
>
Indeed compiles for me without it, I matched the existing code in aes.h, and in
general I prefer to define the structs in advance.
If you prefer that I will remove it, please let me know
> > +subsample_count = AV_RB16(sc->cenc.auxiliary_info_
On Fri, Dec 11, 2015 at 3:02 PM, Andrey Utkin
wrote:
> On Wed, Dec 9, 2015 at 2:07 AM, Andrey Utkin
> wrote:
>> Hi! Could please anybody look at MJPEG RTP encoder issue with yuvj422p
>> https://trac.ffmpeg.org/ticket/3823#comment:17 ? This pixel format
>> becomes popular for IP cameras having no
I don't really know which is worse, calling a function in mov.c, or
"duplicating" (because I'll have to admit that it's a form of
duplication in a technical sense) code in it. Because *if*, against all
odds, there would have to be a change in the QuickTime color table
handling, it's easy to for
So, to get somewhere with this, would everybody be ok if I change this
to remove the non-free marking, but keep it disabled by default for now?
Or is putting that exception-text in nvenc.c enough to make enabling it
by default viable?
signature.asc
Description: OpenPGP digital signature
___
On 15 Dec, Timo Rothenpieler wrote :
> So, to get somewhere with this, would everybody be ok if I change this
> to remove the non-free marking, but keep it disabled by default for now?
I still don't understand why you want to fork this header into the
FFmpeg tree.
--
Jean-Baptiste Kempf
http://
On 10 Dec, Philip Langdale wrote :
> >Are we really talking about including a huge 3rd party header because
> >distros are so lazy? What's next, do we add Windows headers to the
> >FFmpeg tree, because MinGW lags severely behind the newest definitions
> >like HEVC DXVA support?
>
> Admittedly, we
On Tue, Dec 15, 2015 at 09:16:11AM +, Eran Kornblau wrote:
[...]
> @@ -4007,6 +4008,147 @@ static int mov_read_free(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> return 0;
> }
>
> +static int mov_read_frma(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> +{
> +uint32_t format =
Hello All,
There is updated patch version initially introduced by Sven Dueking
This patch expose 3 QSV functions as public.
This is needed because the VPP needs access to these functions too.
Please review.
--
Best regards,
Ivan mailto:ivan.us...@nablet.com
0001-a
On Tue, Dec 15, 2015 at 09:16:11AM +, Eran Kornblau wrote:
> >
> > using a random IV value would break any regression tests
> > see AVFMT_FLAG_BITEXACT
> >
> Fixed, only generating a random IV when bitexact is not enabled.
> Updated patch files attached.
>
> >
> > is this filling in a rando
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
doc/ffmpeg.texi |4 ++--
ffmpeg_opt.c| 22 +-
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 6307470..a38a32e 100644
--- a/doc/ffmpeg.texi
+++
Sorry if this may sound idiotic, but if I provide a unified patch for a
file that is newer/different from the one I have here, it won't work, right?
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmp
From: Matthieu Bouron
---
Hi,
This commit is likely to break fate on arm since the current C code path
seems to use less precision.
How should I proceed to fix it ?
Matthieu
---
libswscale/arm/swscale_unscaled.c | 53 ---
libswscale/arm/yuv2rgb_neon.S | 77 ++
From: Matthieu Bouron
---
libswscale/arm/yuv2rgb_neon.S | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index 01d8536..9f9dd2a 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@
Hi Mats,
On Tue, Dec 15, 2015 at 16:58:41 +0100, Mats Peterson wrote:
> Sorry if this may sound idiotic, but if I provide a unified patch for a
> file that is newer/different from the one I have here, it won't work, right?
"It depends." ;-)
By the way, git handles this kind of stuff nicely.
It
On 12/15/2015 10:44 AM, Jean Delvare wrote:
> Originally I proposed this patch for performance reasons and also
> because I think it makes the code more readable. But seeing how the
> same cast is already present everywhere in the ffmpeg code, I would now
> also invoke consistency. There's no ratio
On 12/15/2015 05:49 PM, Moritz Barsnick wrote:
Hi Mats,
On Tue, Dec 15, 2015 at 16:58:41 +0100, Mats Peterson wrote:
Sorry if this may sound idiotic, but if I provide a unified patch for a
file that is newer/different from the one I have here, it won't work, right?
"It depends." ;-)
By the w
On Tue, 15 Dec 2015 16:56:02 +, Derek Buitenhuis wrote:
> On 12/15/2015 10:44 AM, Jean Delvare wrote:
> > Originally I proposed this patch for performance reasons and also
> > because I think it makes the code more readable. But seeing how the
> > same cast is already present everywhere in the
---
ffserver.c | 77 --
1 file changed, 50 insertions(+), 27 deletions(-)
diff --git a/ffserver.c b/ffserver.c
index 029771c..b7f9616 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -138,7 +138,7 @@ typedef struct HTTPContext {
int http
On 12/15/2015 5:23 PM, Jean Delvare wrote:
> Looks like something different from what we were discussing here.
In which way?
That patch fixes pointer aliasing in the same way yours breaks it, AFAICT?
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@f
On Tue, Dec 15, 2015 at 05:46:09PM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> ---
>
> Hi,
>
> This commit is likely to break fate on arm since the current C code path
> seems to use less precision.
>
> How should I proceed to fix it ?
hmm
can the precission of the C code path a
Here is a *suggestion* for how to end the QuickTime palette in Matroska
saga. I have created a new file 'qtpalette.c' with a function
get_qtpalette(), that will be called from both matroskadec.c and mov.c.
So, no more calling into another demuxer to get the palette, and no
duplicated code, sinc
Fixes ticket 279.
---
libavformat/mpegtsenc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 19032f3..a0dca4a 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -1519,8 +1519,6 @@ static int mpegts_write_packet_intern
On 12/15/2015 06:51 PM, Mats Peterson wrote:
Here is a *suggestion* for how to end the QuickTime palette in Matroska
saga. I have created a new file 'qtpalette.c' with a function
get_qtpalette(), that will be called from both matroskadec.c and mov.c.
So, no more calling into another demuxer to ge
On Tue, Dec 15, 2015 at 05:46:08PM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> ---
> libswscale/arm/yuv2rgb_neon.S | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
should be ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposi
On 15.12.2015 08:17, Anton Khirnov wrote:
> Can you share the sample that shows the problem?
I could, but it's of no use for comparing with libopus, because their
decoder errors out in an unrelated check.
> From what I can see, libopus does not do any clipping at that point, so
> something else m
On 15.12.2015 03:15, Michael Niedermayer wrote:
> On Tue, Dec 15, 2015 at 01:19:01AM +0100, Andreas Cadhalpun wrote:
>> On 15.12.2015 00:43, Michael Niedermayer wrote:
>> ffmdec.c | 28
>> 1 file changed, 28 insertions(+)
>> 5a300bbcfb78b1f24b8b7c572d420577b2a1b1f3
On 15.12.2015 14:42, Timo Rothenpieler wrote:
> So, to get somewhere with this, would everybody be ok if I change this
> to remove the non-free marking, but keep it disabled by default for now?
That would be OK for me.
> Or is putting that exception-text in nvenc.c enough to make enabling it
> by
On Tue, Dec 15, 2015 at 2:23 AM, Michael Niedermayer wrote:
> On Wed, Dec 09, 2015 at 06:55:25PM -0500, Ganesh Ajjanagadde wrote:
>> exp2 suffices here. Some trivial (~ 4x) speedup is done in addition here by
>> reusing results.
>>
>
>> This is bit-identical to the old values.
>
> That may be true
Hi Derek,
On Tue, 15 Dec 2015 17:39:23 +, Derek Buitenhuis wrote:
> On 12/15/2015 5:23 PM, Jean Delvare wrote:
> > Looks like something different from what we were discussing here.
>
> In which way?
>
> That patch fixes pointer aliasing in the same way yours breaks it, AFAICT?
I see two com
If that is the case, the loop setting predictor_state in
sonic_decode_frame causes out of bounds reads of int_samples, which has
only frame_size number of elements.
Signed-off-by: Andreas Cadhalpun
---
libavcodec/sonic.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavcodec/sonic
On Tue, Dec 15, 2015 at 10:41:15PM +0100, Andreas Cadhalpun wrote:
> On 15.12.2015 08:17, Anton Khirnov wrote:
> > Can you share the sample that shows the problem?
>
> I could, but it's of no use for comparing with libopus, because their
> decoder errors out in an unrelated check.
>
> > From what
On Tue, Dec 15, 2015 at 11:50:21PM +0100, Andreas Cadhalpun wrote:
> If that is the case, the loop setting predictor_state in
> sonic_decode_frame causes out of bounds reads of int_samples, which has
> only frame_size number of elements.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavcodec/so
On Tue, Dec 15, 2015 at 5:25 PM, Ganesh Ajjanagadde wrote:
> On Tue, Dec 15, 2015 at 2:23 AM, Michael Niedermayer wrote:
>> On Wed, Dec 09, 2015 at 06:55:25PM -0500, Ganesh Ajjanagadde wrote:
[...]
>>>
>>> diff --git a/libavcodec/nellymoserenc.c b/libavcodec/nellymoserenc.c
>>> index d998dba..e60
Adds HLS flags to emit the X-PLAYLIST-TYPE tag to the top of generated
M3U8 files.
See the spec:
https://tools.ietf.org/html/draft-pantos-http-live-streaming-18#section-4.3.3.5
There was also an FFMPEG trac ticket #4571 that had this as a wishlist item:
https://trac.ffmpeg.org/ticket/4571
---
d
On 12/10/2015 8:02 PM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/x86/hevc_sao_10bit.asm | 142
> +++---
> 1 file changed, 57 insertions(+), 85 deletions(-)
Ping for patchset.
___
ffmpeg-devel
These postfixes can be computed statically, and there is no need to
waste runtime resources.
Tested with FATE.
Signed-off-by: Ganesh Ajjanagadde
---
libavutil/eval.c | 52
1 file changed, 28 insertions(+), 24 deletions(-)
diff --git a/libavu
This uses ff_exp2fi to get a speedup (~ 6x).
sample benchmark (Haswell, GNU/Linux):
old:
19102 decicycles in sbr_dequant,1023 runs, 1 skips
19002 decicycles in sbr_dequant,2045 runs, 3 skips
17638 decicycles in sbr_dequant,4093 runs, 3 skips
15825 decicycles in s
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/internal.h | 19 +++
libavcodec/jpeg2000.c | 18 ++
2 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 445b45a..afcf00d 100644
--- a/libavcodec/intern
50 matches
Mail list logo
