Hello,
I worked on the attached patch to enable timecode tracks in MP4 files
written by ffmpeg. Could someone please take a look to see if it is
acceptable?
Thanks,
Andaleeb
0001-movenc-Timecode-in-MP4.patch
Description: Binary data
___
ffmpeg-devel
Thanks for the detailed responses and discussions, and apologies for
delayed response (I was considering to change the functions to a
serialize/deserialize to some wire format and keeping the struct, but wire
format would've essentially be a memcpy to the struct on little endian and
would only bene
May help to prevent incidents like 19e456d48c90a1e3ceeb9e6241383384cc73dfdf.
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/wma.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/wma.h b/libavcodec/wma.h
index 4aad713..325f03c 100644
--- a/libavcodec/wma.h
+++ b/libavcodec/wma.
It seems to miscompile them
Should fix fate-ra-288 and fate-twinvq
Signed-off-by: James Almer
---
The early clobber fix didn't do the trick.
Someone with ICC should to give it a look, but until then, disabling these
functions will solve the failures.
libavutil/x86/intmath.h | 4 ++--
1 file ch
On Thu, Jan 21, 2016 at 12:22:09AM +0100, Andreas Cadhalpun wrote:
> On 20.01.2016 21:01, Michael Niedermayer wrote:
> > From: Michael Niedermayer
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/avformat.h | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletion
On 01/21/2016 02:12 AM, Mats Peterson wrote:
On 01/20/2016 03:25 PM, Mats Peterson wrote:
On 01/20/2016 02:55 PM, Mats Peterson wrote:
This version uses 8-byte alignment of lines. However, this generates
"Warning. Data is not aligned!" messages for odd widths. Don't know how
important this is.
On 01/20/2016 03:25 PM, Mats Peterson wrote:
On 01/20/2016 02:55 PM, Mats Peterson wrote:
This version uses 8-byte alignment of lines. However, this generates
"Warning. Data is not aligned!" messages for odd widths. Don't know how
important this is.
I should add that both the 4 bpp (8 bytes a
On Thu, Jan 21, 2016 at 1:14 AM, Andreas Cadhalpun
wrote:
> On 20.01.2016 10:22, Hendrik Leppkes wrote:
>> On Tue, Jan 19, 2016 at 11:54 PM, Andreas Cadhalpun
>>> Can the crashes be reproduced with VLC?
>>> If so, are they reported in the VLC bug tracker?
>>
>> Who knows, I didn't test every singl
On 1/20/2016 7:46 PM, Clément Bœsch wrote:
> diff --git a/libavutil/thread.h b/libavutil/thread.h
> index 32ddf40..42430fb 100644
> --- a/libavutil/thread.h
> +++ b/libavutil/thread.h
> @@ -31,6 +31,15 @@
> #if HAVE_PTHREADS
> #include
>
> +static inline void ff_thread_setname(const char *name
On 20.01.2016 10:22, Hendrik Leppkes wrote:
> On Tue, Jan 19, 2016 at 11:54 PM, Andreas Cadhalpun
>> Can the crashes be reproduced with VLC?
>> If so, are they reported in the VLC bug tracker?
>
> Who knows, I didn't test every single player that uses avcodec.
> The image corruption on Intel GPUs
On 20.01.2016 10:11, wm4 wrote:
> On Tue, 19 Jan 2016 23:54:48 +0100
> Andreas Cadhalpun wrote:
>> On 19.01.2016 21:46, wm4 wrote:
>>> It was discussed to death on #libav-devel too.
>>
>> And the conclusion was to allow hwaccel with frame threads?
>
> From what I remember, the VLC developer in
Thanks Tim,I am developing a new protocol to support reading aes-ctr ecrypted
video files. So I this question is development related but I couldn't really
gauge if build issues are development or not.
>> But for convenience, you have to make sure the external libraries are built
>> as
>> static
On 20.01.2016 18:51, Michael Niedermayer wrote:
> On Wed, Jan 20, 2016 at 05:06:37PM +0100, Nicolas George wrote:
>> If people start to care about playlist-based security issues (Reimar used to
>> warn about it long ago), a cross-protocol solution needs to be found.
>
> thats true for git-master,
On 20.01.2016 21:01, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/avformat.h | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
Seems OK.
Best regards,
Andreas
_
On 20.01.2016 16:49, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> Signed-off-by: Michael Niedermayer
> ---
> doc/demuxers.texi | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index fb1e4fb..464f98d 100644
> ---
On 20.01.2016 11:10, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/concat.c |5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/concat.c b/libavformat/concat.c
> index 81fe970..7bcc279 1
Hi,
On Wednesday, January 20, 2016, John Pompeii
wrote:
> Hi,
> I am building ffmpeg.exe and ffprobe.exe on 64 bit windows (7) using
> MSYS2/MINGW64. I've resolved all the dependent libraries and got a build
> and it does appear to run just fine as a 64 windows app. This issue that I
> have is
Hi,
I am building ffmpeg.exe and ffprobe.exe on 64 bit windows (7) using
MSYS2/MINGW64. I've resolved all the dependent libraries and got a build and
it does appear to run just fine as a 64 windows app. This issue that I have is
that its linking the external libraries as dlls instead of static
On Wed, Jan 20, 2016 at 07:29:02PM -0300, James Almer wrote:
[...]
> CC libavformat/async.o
> F:/msys/ffmpeg/src/libavformat/async.c: In function 'async_buffer_task':
> F:/msys/ffmpeg/src/libavformat/async.c:184:5: error: implicit declaration of
> function 'ff_thread_setname' [-Werror=implici
On 1/20/2016 7:11 PM, Clément Bœsch wrote:
> ---
> Changes:
> - < 16 char length
> - no spaces
> - ff_pthread_setname → ff_thread_setname
> - changed ifdefery protection
>
> bonus: http://ubitux.fr/pub/pics/ffthreads.png
> ---
> libavcodec/frame_thread_encoder.c | 2 ++
> libavcodec/pthread_fram
On Wed, Jan 20, 2016 at 11:11:35PM +0100, Clément Bœsch wrote:
[...]
> +#elif defined(__linux__)
locally changed to defined(__linux__) && defined(__GLIBC__)
> +pthread_setname_np(pthread_self(), name);
> +#endif
> +}
> +
[...]
--
Clément B.
signature.asc
Description: PGP signature
___
On Wed, Jan 20, 2016 at 10:55:54PM +0100, wm4 wrote:
[...]
> > +static inline void ff_pthread_setname(const char *name)
> > +{
> > +#if defined(__APPLE__)
> > +pthread_setname_np(name);
> > +#elif defined(__linux__)
> > +pthread_setname_np(pthread_self(), name);
>
> Just because you're on
---
Changes:
- < 16 char length
- no spaces
- ff_pthread_setname → ff_thread_setname
- changed ifdefery protection
bonus: http://ubitux.fr/pub/pics/ffthreads.png
---
libavcodec/frame_thread_encoder.c | 2 ++
libavcodec/pthread_frame.c| 2 ++
libavcodec/pthread_slice.c| 2 ++
li
On Wed, 20 Jan 2016 21:44:32 +0100
Clément Bœsch wrote:
> ---
> libavcodec/frame_thread_encoder.c | 2 ++
> libavcodec/pthread_slice.c| 2 ++
> libavfilter/pthread.c | 2 ++
> libavformat/async.c | 2 ++
> libavformat/udp.c | 3 +++
> libavutil/t
On 1/20/2016 5:44 PM, Clément Bœsch wrote:
> ---
> libavcodec/frame_thread_encoder.c | 2 ++
> libavcodec/pthread_slice.c| 2 ++
> libavfilter/pthread.c | 2 ++
> libavformat/async.c | 2 ++
> libavformat/udp.c | 3 +++
> libavutil/thread.h
On Wed, Jan 20, 2016 at 12:48:52PM -0800, Timothy Gu wrote:
> On Wed, Jan 20, 2016 at 09:44:32PM +0100, Clément Bœsch wrote:
> > diff --git a/libavutil/thread.h b/libavutil/thread.h
> > index 32ddf40..a7b5763 100644
> > --- a/libavutil/thread.h
> > +++ b/libavutil/thread.h
> > @@ -169,4 +169,13 @@
On Wed, Jan 20, 2016 at 09:50:40PM +0100, Nicolas George wrote:
> Le primidi 1er pluviôse, an CCXXIV, Clement Boesch a écrit :
> > ---
> > libavcodec/frame_thread_encoder.c | 2 ++
> > libavcodec/pthread_slice.c| 2 ++
> > libavfilter/pthread.c | 2 ++
> > libavformat/async.c
Le primidi 1er pluviôse, an CCXXIV, Clement Boesch a écrit :
> ---
> libavcodec/frame_thread_encoder.c | 2 ++
> libavcodec/pthread_slice.c| 2 ++
> libavfilter/pthread.c | 2 ++
> libavformat/async.c | 2 ++
> libavformat/udp.c | 3 +++
> libavuti
On Wed, Jan 20, 2016 at 09:44:32PM +0100, Clément Bœsch wrote:
> diff --git a/libavutil/thread.h b/libavutil/thread.h
> index 32ddf40..a7b5763 100644
> --- a/libavutil/thread.h
> +++ b/libavutil/thread.h
> @@ -169,4 +169,13 @@ static inline int ff_thread_once(char *control, void
> (*routine)(void)
---
libavcodec/frame_thread_encoder.c | 2 ++
libavcodec/pthread_slice.c| 2 ++
libavfilter/pthread.c | 2 ++
libavformat/async.c | 2 ++
libavformat/udp.c | 3 +++
libavutil/thread.h| 9 +
6 files changed, 20 insertions(+)
On Wed, Jan 20, 2016 at 09:21:30PM +0100, Michael Niedermayer wrote:
> On Wed, Jan 20, 2016 at 11:10:28AM +0100, Michael Niedermayer wrote:
> > From: Michael Niedermayer
> >
> > This feature is not know much or used much AFAIK, and it might be helpfull
> > in
> > exploits.
> > No specific case i
On 1/20/16, Michael Niedermayer wrote:
> On Wed, Jan 20, 2016 at 05:06:37PM +0100, Nicolas George wrote:
>> Le primidi 1er pluviose, an CCXXIV, Michael Niedermayer a ecrit :
>> > From: Michael Niedermayer
>> >
>> > This should prevent the unintended use of concat
>>
>> I am rather against this pa
On Wed, 20 Jan 2016, Vittorio Gambaletta (VittGam) wrote:
Signed-off-by: Vittorio Gambaletta
---
doc/ffplay.texi |5 -
ffplay.c|3 ++-
2 files changed, 6 insertions(+), 2 deletions(-)
Thanks, applied.
Regards,
Marton
___
ffmpeg-
On Tue, Dec 22, 2015 at 09:05:24PM +0100, Clément Bœsch wrote:
> ---
> libavutil/thread.h | 96
> ++
> 1 file changed, 96 insertions(+)
>
> diff --git a/libavutil/thread.h b/libavutil/thread.h
> index 3d15737..0bb745e 100644
> --- a/libavutil/t
On Wed, Jan 20, 2016 at 11:10:28AM +0100, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> This feature is not know much or used much AFAIK, and it might be helpfull in
> exploits.
> No specific case is known where it can be used in an exploit though
> subsequent commits depend on this
On Wed, Jan 20, 2016 at 02:35:56AM +0100, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/img2dec.c |6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
applied
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF
On Wed, 20 Jan 2016, Derek Buitenhuis wrote:
On 1/16/2016 7:58 PM, Marton Balint wrote:
CLI users still going to need an option for it.
What do you mean? Demuxer options are all exposed in the CLI.
I was referring to the AVFormatContext.open_cb URL validator approach
which is not directl
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
libavformat/avformat.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index e6c35ab..4964263 100644
--- a/libavformat/avformat.h
+++ b/libavform
On Wed, Jan 20, 2016 at 03:32:13PM -0300, Claudio Freire wrote:
> On Wed, Jan 20, 2016 at 11:05 AM, Michael Niedermayer
> wrote:
> > From: Michael Niedermayer
> >
> > This is needed as near infinite values on the input side result in only some
> > output to be non finite.
> > Also it may still b
On 1/20/2016 4:38 PM, Paul B Mahol wrote:
> On 1/20/16, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> libavcodec/wavpackenc.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/wavpackenc.c b/libavcodec/wavpackenc.c
>> index 98a011f..979b921 100
On Wed, Jan 20, 2016 at 04:59:16PM +0100, Nicolas George wrote:
> Le primidi 1er pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
> > I have no idea how widely used this feature is, but it is mentioned in
> > doc/protocols.texi:
>
> It is also necessary for the dvd2concat tool.
the later patch i
On 1/20/16, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/wavpackenc.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/libavcodec/wavpackenc.c b/libavcodec/wavpackenc.c
> index 98a011f..979b921 100644
> --- a/libavcodec/wavpackenc.c
> +++ b/libavco
On Wed, Jan 20, 2016 at 11:05 AM, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> This is needed as near infinite values on the input side result in only some
> output to be non finite.
> Also it may still be insufficient if subsequent computations overflow
>
> Fixes null pointer deref
With this commit it is possible to use vf_overlay to center a video over
a black background, without having to know the video framerate in advance
and set it as parameter to lavfi.
Signed-off-by: Vittorio Gambaletta
---
doc/filters.texi | 14 ++
libavfilter/vf_overlay.c |
Signed-off-by: James Almer
---
libavcodec/pngdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 3059087..61857d0 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -787,7 +787,7 @@ static int decode_trns_chunk(AVCod
Signed-off-by: James Almer
---
libavcodec/amrwbdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/amrwbdec.c b/libavcodec/amrwbdec.c
index b73b700..a99dbd1 100644
--- a/libavcodec/amrwbdec.c
+++ b/libavcodec/amrwbdec.c
@@ -358,7 +358,7 @@ static void decode_pitch
Signed-off-by: James Almer
---
libavcodec/wavpackenc.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/wavpackenc.c b/libavcodec/wavpackenc.c
index 98a011f..979b921 100644
--- a/libavcodec/wavpackenc.c
+++ b/libavcodec/wavpackenc.c
@@ -2216,8 +2216,7 @@ static voi
Signed-off-by: James Almer
---
libavcodec/diracdsp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/diracdsp.c b/libavcodec/diracdsp.c
index e82b587..5698dd0 100644
--- a/libavcodec/diracdsp.c
+++ b/libavcodec/diracdsp.c
@@ -158,10 +158,10 @@ static void pu
Signed-off-by: James Almer
---
libavcodec/proresdec_lgpl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/proresdec_lgpl.c b/libavcodec/proresdec_lgpl.c
index 9e5674e..467a423 100644
--- a/libavcodec/proresdec_lgpl.c
+++ b/libavcodec/proresdec_lgpl.c
@@ -251,7 +251
On Wed, Jan 20, 2016 at 05:06:37PM +0100, Nicolas George wrote:
> Le primidi 1er pluviôse, an CCXXIV, Michael Niedermayer a écrit :
> > From: Michael Niedermayer
> >
> > This should prevent the unintended use of concat
>
> I am rather against this patch and the corresponding for subfile: these
>
On 1/16/2016 7:58 PM, Marton Balint wrote:
> CLI users still going to need an option for it.
What do you mean? Demuxer options are all exposed in the CLI.
-enable_drefs 1 works fine.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://
On Wed, 20 Jan 2016 13:26:05 +0100, you wrote:
>Hi,
>
>2016-01-19 13:46 GMT+01:00 John Cox :
>> I've just done a fair bit of work on hevc_cabac decode for the Rasberry
>> Pi2 and I think that the patch is generally applicable. Patch is
>> attached but you may prefer to take it from git:
>
>This w
Disregard this patch, turns out the parser needlessly warns. The whole
function simply checks if the parse offsets are sane but warns in case they
aren't even though it will continue scanning for other possible parse codes.
On 20 January 2016 at 11:37, Rostislav Pehlivanov
wrote:
> The specifica
On Wed, Jan 20, 2016 at 11:46:00AM +0100, wm4 wrote:
> On Wed, 20 Jan 2016 11:21:44 +0100
> Michael Niedermayer wrote:
>
> > From: Michael Niedermayer
> >
> > With this, user applications which use custom IO and have set a IO context
> > will not have
> > their already opened IO context ignore
On Wed, Jan 20, 2016 at 03:41:58PM +0100, Bodecs Bela wrote:
> Hi All,
>
> I have created corresponding documentation patch for may last patch
> for vf_scale.
>
> I have noticed that there are 2 undocumented parameters: param0 and
> param1, they are ready to use but missing from public documentat
Le primidi 1er pluviôse, an CCXXIV, Michael Niedermayer a écrit :
> From: Michael Niedermayer
>
> This should prevent the unintended use of concat
I am rather against this patch and the corresponding for subfile: these
protocols are not harmful by themselves, they are dangerous if and only
anoth
Le decadi 30 nivôse, an CCXXIV, Michael Niedermayer a écrit :
> This is safer, as a selected demuxer could still mean that it was
> auto-detected
> by a user application
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/concatdec.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletio
Le primidi 1er pluviôse, an CCXXIV, Andreas Cadhalpun a écrit :
> I have no idea how widely used this feature is, but it is mentioned in
> doc/protocols.texi:
It is also necessary for the dvd2concat tool.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
__
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
doc/demuxers.texi | 17 +
1 file changed, 17 insertions(+)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index fb1e4fb..464f98d 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -424,6 +424,23 @@ ff
On Sat, Jan 16, 2016 at 02:22:21PM +0100, Michael Niedermayer wrote:
> On Fri, Jan 15, 2016 at 05:03:49PM +, Derek Buitenhuis wrote:
> > This feature is mostly only used by NLE software, and is
> > both of dubious value being enabled by default, and a
> > possible security risk.
> >
> > Signed
On Wed, Jan 20, 2016 at 01:08:37AM +0100, Andreas Cadhalpun wrote:
> On 17.01.2016 15:55, Michael Niedermayer wrote:
> > From: Michael Niedermayer
> >
> > Fixes:
> > 55d71971da50365d542ed14b65565fe1/signal_sigsegv_4765a4_8499_f146af090a94f591d6254515c7700ef5.mkv
> >
> > Found-by: Mateusz "j00ru
On 20/01/16 13:15, Michael Niedermayer wrote:
> On Wed, Jan 20, 2016 at 12:21:37PM +, Vicente Olivert Riera wrote:
>> On 20/01/16 12:05, Michael Niedermayer wrote:
>>> On Wed, Jan 20, 2016 at 11:37:52AM +, Vicente Olivert Riera wrote:
Hello Michael,
On 19/01/16 22:11, Michael
Hi All,
I have created corresponding documentation patch for may last patch for
vf_scale.
I have noticed that there are 2 undocumented parameters: param0 and
param1, they are ready to use but missing from public documentation. I
have included them in this documentation patch.
I am not sure t
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
libavformat/libquvi.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/libavformat/libquvi.c b/libavformat/libquvi.c
index 7151694..1e5c8bc 100644
--- a/libavformat/libquvi.c
+++ b/libavformat/libquvi.c
@@ -95
On Wed, 20 Jan 2016 13:26:05 +0100, you wrote:
>Hi,
>
>2016-01-19 13:46 GMT+01:00 John Cox :
>> I've just done a fair bit of work on hevc_cabac decode for the Rasberry
>> Pi2 and I think that the patch is generally applicable. Patch is
>> attached but you may prefer to take it from git:
>
>This w
On 01/20/2016 02:55 PM, Mats Peterson wrote:
This version uses 8-byte alignment of lines. However, this generates
"Warning. Data is not aligned!" messages for odd widths. Don't know how
important this is.
I should add that both the 4 bpp (8 bytes alignment) and 8 bpp (4 bytes
alignment) depth
From: Michael Niedermayer
This is needed as near infinite values on the input side result in only some
output to be non finite.
Also it may still be insufficient if subsequent computations overflow
Fixes null pointer dereference
Fixes:
ae66c0f6c12ac1cd5c2c237031240f57/signal_sigsegv_2618c99_951
This version uses 8-byte alignment of lines. However, this generates
"Warning. Data is not aligned!" messages for odd widths. Don't know how
important this is.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 6e872d39ad8b087c5c510e71f6b1be1127a16229 Mon Sep 17 00:00:00 2001
From: M
On 01/20/2016 12:41 PM, Mats Peterson wrote:
I don't know about this one, since it adds some calculations inside the
loop, but it limits the line alignment to 16 bytes instead of 32 bytes
as before. Less overhead.
Mats
I could even do it with 8-byte line alignment as is already done for 4
bp
michael issa outlook.com> writes:
> Dear Michael my name is Michael issa I'm using UBUNTU 14.04.3
Please read https://www.ffmpeg.org/contact.html
Please do not post user questions on the
developer mailing list and please learn what
thread highjacking means (and avoid it).
Finally, do not top-p
On Wed, Jan 20, 2016 at 12:21:37PM +, Vicente Olivert Riera wrote:
> On 20/01/16 12:05, Michael Niedermayer wrote:
> > On Wed, Jan 20, 2016 at 11:37:52AM +, Vicente Olivert Riera wrote:
> >> Hello Michael,
> >>
> >> On 19/01/16 22:11, Michael Niedermayer wrote:
> >>> On Thu, Jan 14, 2016 at
Dear Michael my name is Michael issa I'm using UBUNTU 14.04.3
AND FFMPEG for streaming .my problem is I have video and audio but only run for
3 second ,I not very expert on this I have asked lots of IT guys no one able to
help ,my only chance is with you my Skype name is michaelissa or if u can
On Wed, Jan 20, 2016 at 09:05:49AM +, Paul B Mahol wrote:
> On 1/19/16, Bodecs Bela wrote:
> > Hi All,
> >
> > currently scale video filter accepts expressions in its width and height
> > parameters but evaluates them only once at init and replaces them with
> > their actual values. Later on,
Hi,
2016-01-19 13:46 GMT+01:00 John Cox :
> I've just done a fair bit of work on hevc_cabac decode for the Rasberry
> Pi2 and I think that the patch is generally applicable. Patch is
> attached but you may prefer to take it from git:
This work is certainly impressive, and most people would have
On 20/01/16 12:05, Michael Niedermayer wrote:
> On Wed, Jan 20, 2016 at 11:37:52AM +, Vicente Olivert Riera wrote:
>> Hello Michael,
>>
>> On 19/01/16 22:11, Michael Niedermayer wrote:
>>> On Thu, Jan 14, 2016 at 02:59:03PM +, Vicente Olivert Riera wrote:
Signed-off-by: Vicente Olivert
Hendrik Leppkes wrote:
On Wed, Jan 20, 2016 at 12:13 PM, Andy Furniss wrote:
wm4 wrote:
On Wed, 20 Jan 2016 09:59:12 + Andy Furniss
wrote:
wm4 wrote:
On Wed, 20 Jan 2016 00:42:18 + Andy Furniss
wrote:
Hendrik Leppkes wrote:
I do not agree that it should be a warning. As outl
On Wed, Jan 20, 2016 at 11:37:52AM +, Vicente Olivert Riera wrote:
> Hello Michael,
>
> On 19/01/16 22:11, Michael Niedermayer wrote:
> > On Thu, Jan 14, 2016 at 02:59:03PM +, Vicente Olivert Riera wrote:
> >> Signed-off-by: Vicente Olivert Riera
> >> ---
> >> Changes v5 -> v6:
> >> - Mu
I don't know about this one, since it adds some calculations inside the
loop, but it limits the line alignment to 16 bytes instead of 32 bytes
as before. Less overhead.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 8d15b348fc84d46f7e764a2e9822aacc80e74407 Mon Sep 17 00:00:00 200
On Wed, Jan 20, 2016 at 12:13 PM, Andy Furniss wrote:
> wm4 wrote:
>>
>> On Wed, 20 Jan 2016 09:59:12 + Andy Furniss
>> wrote:
>>
>>> wm4 wrote:
On Wed, 20 Jan 2016 00:42:18 + Andy Furniss
wrote:
> Hendrik Leppkes wrote:
>
I do not agree that it shoul
The specifications use uint32_t and this fixes a number of warnings
about invalid offsets of some files.
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/dirac_parser.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/dirac_parser.c b/libavcodec/dirac_parser.c
Hello Michael,
On 19/01/16 22:11, Michael Niedermayer wrote:
> On Thu, Jan 14, 2016 at 02:59:03PM +, Vicente Olivert Riera wrote:
>> Signed-off-by: Vicente Olivert Riera
>> ---
>> Changes v5 -> v6:
>> - Multiple changes:
>>- Use separate if blocks when detecting the MIPS ISA, this way wh
wm4 wrote:
On Wed, 20 Jan 2016 09:59:12 + Andy Furniss
wrote:
wm4 wrote:
On Wed, 20 Jan 2016 00:42:18 + Andy Furniss
wrote:
Hendrik Leppkes wrote:
I do not agree that it should be a warning. As outlined
in the commit message and this thread, there are serious
flaws with frame thr
On Wed, 20 Jan 2016 11:21:44 +0100
Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> With this, user applications which use custom IO and have set a IO context
> will not have
> their already opened IO context ignored and glob/seq being interpreted
>
> Comments and tests from maintai
Signed-off-by: Paul B Mahol
---
libavfilter/avf_showwaves.c | 274 +---
1 file changed, 206 insertions(+), 68 deletions(-)
diff --git a/libavfilter/avf_showwaves.c b/libavfilter/avf_showwaves.c
index 4c46d8e..71d6ca2 100644
--- a/libavfilter/avf_showwaves.
On Wed, 20 Jan 2016 09:59:12 +
Andy Furniss wrote:
> wm4 wrote:
> > On Wed, 20 Jan 2016 00:42:18 + Andy Furniss
> > wrote:
> >
> >> Hendrik Leppkes wrote:
> >>
> > I do not agree that it should be a warning. As outlined in
> > the commit message and this thread, there are ser
From: Michael Niedermayer
With this, user applications which use custom IO and have set a IO context will
not have
their already opened IO context ignored and glob/seq being interpreted
Comments and tests from maintainers of user apps are welcome!
Signed-off-by: Michael Niedermayer
---
libav
On Wed, Jan 20, 2016 at 12:09:28AM +0100, Andreas Cadhalpun wrote:
> On 19.01.2016 22:13, Michael Niedermayer wrote:
> > From: Michael Niedermayer
> >
> > This feature is not know much or used much AFAIK, and it might be helpfull
> > in
> > exploits.
> > No specific case is known where it can be
From: Michael Niedermayer
This feature is not know much or used much AFAIK, and it might be helpfull in
exploits.
No specific case is known where it can be used in an exploit though
subsequent commits depend on this commit though
Signed-off-by: Michael Niedermayer
---
libavformat/avio.c | 11
From: Michael Niedermayer
This should prevent the unintended use of subfile
Signed-off-by: Michael Niedermayer
---
libavformat/subfile.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/subfile.c b/libavformat/subfile.c
index 0e84384..3fbbb16 100644
--- a/libavformat/s
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
libavformat/concat.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/concat.c b/libavformat/concat.c
index 81fe970..7bcc279 100644
--- a/libavformat/concat.c
+++ b/libavformat/concat.c
@@ -65
From: Michael Niedermayer
This should prevent the unintended use of concat
Signed-off-by: Michael Niedermayer
---
libavformat/concat.c | 28
1 file changed, 28 insertions(+)
diff --git a/libavformat/concat.c b/libavformat/concat.c
index 7bcc279..a91bfb8 100644
-
wm4 wrote:
On Wed, 20 Jan 2016 00:42:18 + Andy Furniss
wrote:
Hendrik Leppkes wrote:
I do not agree that it should be a warning. As outlined in
the commit message and this thread, there are serious flaws
with frame threading and hwaccel.
I'm fine with it being an error, but since it is
On Tue, Jan 19, 2016 at 11:54 PM, Andreas Cadhalpun
wrote:
> On 19.01.2016 21:46, wm4 wrote:
>> On Tue, 19 Jan 2016 21:31:19 +0100
>> Hendrik Leppkes wrote:
>>> On Tue, Jan 19, 2016 at 9:27 PM, Andreas Cadhalpun
>>> wrote:
On 19.01.2016 21:22, Hendrik Leppkes wrote:
> On Tue, Jan 19, 20
On Tue, 19 Jan 2016 23:54:48 +0100
Andreas Cadhalpun wrote:
> On 19.01.2016 21:46, wm4 wrote:
> > On Tue, 19 Jan 2016 21:31:19 +0100
> > Hendrik Leppkes wrote:
> >> On Tue, Jan 19, 2016 at 9:27 PM, Andreas Cadhalpun
> >> wrote:
> >>> On 19.01.2016 21:22, Hendrik Leppkes wrote:
> On
On 1/19/16, Bodecs Bela wrote:
> Hi All,
>
> currently scale video filter accepts expressions in its width and height
> parameters but evaluates them only once at init and replaces them with
> their actual values. Later on, if any parameter of incoming frames
> changes - ie those were used in the
On Wed, 20 Jan 2016 00:42:18 +
Andy Furniss wrote:
> Hendrik Leppkes wrote:
>
> >>> I do not agree that it should be a warning. As outlined in the
> >>> commit message and this thread, there are serious flaws with
> >>> frame threading and hwaccel.
> >>
> >> I'm fine with it being an error
96 matches
Mail list logo
