From: Pavel Koshevoy
ps.sps_list entries may be NULL, so check before dereferencing
---
libavcodec/vda_h264_dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vda_h264_dec.c b/libavcodec/vda_h264_dec.c
index 92839e2..972bd6b 100644
--- a/libavcodec/vda_h264_dec.
2017-02-09 18:40 GMT+01:00 Alex Converse :
> Quiets some log spam on pure upsampling mode.
Please mention ticket #5163.
For the whole patchset, I suggest you push as soon as everybody
agrees on the function prefixes.
Could you review my patch for ticket #1614?
https://ffmpeg.org/pipermail/ffmpeg
I've separated and updated the mov_read_{senc,saiz}() patch, attached.
It avoids allocation wraps in those two functions.
On Wed, Feb 8, 2017 at 3:48 PM, Matthew Wolenetz
wrote:
> I've separated and updated the mov_read_udta_string() patch, attached.
> It prevents accessing MOVContext.meta_keys[
On 2/9/2017 2:40 PM, Alex Converse wrote:
> diff --git a/libavcodec/mpeg4audio.c b/libavcodec/mpeg4audio.c
> index 5f85b64cb8..9fe257838c 100644
> --- a/libavcodec/mpeg4audio.c
> +++ b/libavcodec/mpeg4audio.c
> @@ -83,70 +83,62 @@ static inline int get_sample_rate(GetBitContext *gb, int
> *index)
On Thu, Feb 09, 2017 at 01:20:09PM +0100, Michael Niedermayer wrote:
[...]
> > int ff_mjpeg_encode_stuffing(MpegEncContext *s)
> > {
> > int i;
> > PutBitContext *pbc = &s->pb;
> > int mb_y = s->mb_y - !s->mb_x;
> >+int ret;
> >+MJpegContext *m;
> >+
> >+m = s->mjpeg_ctx;
>
On 09/02/17 20:54, Mark Thompson wrote:
> On 08/02/17 19:21, Takayuki 'January June' Suwa wrote:
>> From: Takayuki 'January June' Suwa
>>
>> This adds "-profile[:v] profile_name"-style option IOW.
>>
>> Now default/unknown profile means FF_PROFILE_H264_HIGH strictly, for both
>> better coding sty
Account for the RTP seq num restarting after 65535 when logging the
number of missed RTP packets.
Change-Id: I3510c2dfb830614e25f7b93de9b3b10aa724d00c
---
libavformat/rtpdec.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.
Hi Pedro,
On Thu, Feb 9, 2017 at 3:10 PM, Pedro Arthur wrote:
> 2017-02-09 17:01 GMT-02:00 Ronald S. Bultje :
>
> > Before we get into adding new things to swscale: I will veto anything
> that
> > doesn't use the provided API in libavutil. So no new SWS_CS_*.
> >
> > Maybe is there something tha
On 08/02/17 19:21, Takayuki 'January June' Suwa wrote:
> From: Takayuki 'January June' Suwa
>
> This adds "-profile[:v] profile_name"-style option IOW.
>
> Now default/unknown profile means FF_PROFILE_H264_HIGH strictly, for both
> better coding style and preserving the original behavior.
> ---
Dne 9.2.2017 v 07:49 wm4 napsal(a):
On Wed, 8 Feb 2017 23:31:54 +0100
Miroslav Slugeň wrote:
It is much more robust solution to always calculate second field (when
deinterlacing) PTS from frame rate, then relating on previous PTS,
because if there are B frames in input and some video frames ar
Dne 8.2.2017 v 23:59 Carl Eugen Hoyos napsal(a):
2017-02-08 23:31 GMT+01:00 Miroslav Slugeň :
It is much more robust solution to always calculate second field
(when deinterlacing) PTS from frame rate
Without looking at your patch, I would have guessed that not
every stream has a useful frame ra
2017-02-09 17:01 GMT-02:00 Ronald S. Bultje :
> Before we get into adding new things to swscale: I will veto anything that
> doesn't use the provided API in libavutil. So no new SWS_CS_*.
>
> Maybe is there something that doesn't use libavutil in swscale that can be
turned in a qualification task?
On Thu, 9 Feb 2017 14:01:59 -0500
"Ronald S. Bultje" wrote:
> Hi,
>
> On Wed, Feb 8, 2017 at 8:21 PM, Michael Niedermayer
> wrote:
>
> > On Thu, Feb 09, 2017 at 01:03:06AM +0100, Michael Niedermayer wrote:
> > > On Wed, Feb 08, 2017 at 09:07:09PM -0200, Pedro Arthur wrote:
> > > > 2017-01-
Hi,
On Wed, Feb 8, 2017 at 8:21 PM, Michael Niedermayer
wrote:
> On Thu, Feb 09, 2017 at 01:03:06AM +0100, Michael Niedermayer wrote:
> > On Wed, Feb 08, 2017 at 09:07:09PM -0200, Pedro Arthur wrote:
> > > 2017-01-27 1:01 GMT-02:00 Michael Niedermayer :
> > >
> > > > we need more (backup) mentor
From: Takayuki 'January June' Suwa
This adds "-profile[:v] profile_name"-style option IOW.
Now default/unknown profile means FF_PROFILE_H264_HIGH strictly, for both
better coding style and preserving the original behavior.
---
libavcodec/omx.c | 20
1 file changed, 20 inse
nevermind , bad idea.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Thu, Feb 09, 2017 at 12:50:48PM -0500, Compn wrote:
> as stated , this is a community issue, so heres the vote thread.
>
> vote to add kieran and wm4 to ffmpeg-security email alias.
>
> any votes for or against?
> votes will be tallied in 2 weeks. active committers/contributors will be
> count
This preserves sync extensions.
---
libavcodec/aacdec.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index 709ac7cdf8..08d92fe145 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -289,17 +28
as stated , this is a community issue, so heres the vote thread.
vote to add kieran and wm4 to ffmpeg-security email alias.
any votes for or against?
votes will be tallied in 2 weeks. active committers/contributors will be
counted.
if you have ideas for how the -security should be handled, make
A strict reading of the spec seems to imply that it should be aligned to
the start of the element instance tag, but that would break all of the
samples with PCEs.
It seems like a well formed LATM stream should have its PCE in the ASC
rather than inband.
Fixes ticket 4544
---
libavcodec/aacdec_te
Fixes ticket 4730
---
libavcodec/aacdec.c | 26 --
libavcodec/aacdec_template.c | 82
libavcodec/mpeg4audio.c | 76 ++--
libavcodec/mpeg4audio.h | 12 ++-
4 files changed, 120 insert
On Wed, Feb 08, 2017 at 01:13:57PM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/huffyuvencdsp.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically
Quiets some log spam on pure upsampling mode.
---
libavcodec/aacdec_template.c | 2 +-
libavcodec/aacsbr.h | 2 +-
libavcodec/aacsbr_template.c | 3 ++-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 2a06f82
On Wed, Feb 08, 2017 at 01:13:56PM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> Decent compilers are smart enough to truncate those ULL constants on targets
> where long is 32 bits (and do things like shift+and/add instead of mul).
> This is for those that are not.
>
> libavcod
>
> > >
> > > I dont think we should give access to ffmpeg-security to everyone who
> > > wants to be on the list. This is of course something the community
> > > has to decide and not me, iam just err-ing on the safe side and am very
> > > restrictive on who is added.
> > >
> >
> > This is a bogus
Am 09.02.17 um 16:01 schrieb Daniel Oberhoff:
> [...]
> we would like to contribute this back to ffmpeg as it may be useful
> for others. do you think so to? if so, should we send one big patch
> or split it up somehow?
Yes. Try to conform to our developer documentation at
http://ffmpeg.org/dev
based on ligverds patch from
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/199183.html
---
libavformat/dashenc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 534fa75..18c39c5 100644
--- a/libavformat/d
sets the MPEG-DASH profile identifier in the header (for example for
specifying on-demand vs default live profile)
Signed-off-by: Sol Bekic
---
libavformat/dashenc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 18c3
On 2/9/2017 10:24 AM, Kieran Kunhya wrote:
>>
>> I dont think we should give access to ffmpeg-security to everyone who
>> wants to be on the list. This is of course something the community
>> has to decide and not me, iam just err-ing on the safe side and am very
>> restrictive on who is added.
>>
On Thu, Feb 09, 2017 at 03:29:40PM +0100, Paul B Mahol wrote:
> On 2/9/17, Michael Niedermayer wrote:
> > On Thu, Feb 09, 2017 at 08:25:43AM +0100, wm4 wrote:
> >> On Wed, 8 Feb 2017 22:07:24 +0100
> >> Michael Niedermayer wrote:
> >>
> >> > Hi all
> >> >
> >> > On Sat, Aug 08, 2015 at 03:51:11AM
Hello all,
We do some performance critical processing with ffmpeg involving image scaling
and warping. To support this we did implemented some new algorithms and
parallelized one.
1. parallelize remap
2. implement remap_frac that interprets data as 13.3 fixed point (i.e. 3 bits
for subpixel wa
On Thu, Feb 09, 2017 at 09:07:39AM -0500, Compn wrote:
> On Thu, 09 Feb 2017 13:24:53 +, Kieran Kunhya
> wrote:
>
> > >
> > > I dont think we should give access to ffmpeg-security to everyone who
> > > wants to be on the list. This is of course something the community
> > > has to decide and
On Thu, 9 Feb 2017 15:27:03 +0100
Michael Niedermayer wrote:
> On Thu, Feb 09, 2017 at 08:25:43AM +0100, wm4 wrote:
> > On Wed, 8 Feb 2017 22:07:24 +0100
> > Michael Niedermayer wrote:
> >
> > > Hi all
> > >
> > > On Sat, Aug 08, 2015 at 03:51:11AM +0200, Michael Niedermayer wrote:
> > > >
On 2/9/17, Michael Niedermayer wrote:
> On Thu, Feb 09, 2017 at 08:25:43AM +0100, wm4 wrote:
>> On Wed, 8 Feb 2017 22:07:24 +0100
>> Michael Niedermayer wrote:
>>
>> > Hi all
>> >
>> > On Sat, Aug 08, 2015 at 03:51:11AM +0200, Michael Niedermayer wrote:
>> > > On Fri, Aug 07, 2015 at 07:46:55PM -
On Thu, Feb 09, 2017 at 08:25:43AM +0100, wm4 wrote:
> On Wed, 8 Feb 2017 22:07:24 +0100
> Michael Niedermayer wrote:
>
> > Hi all
> >
> > On Sat, Aug 08, 2015 at 03:51:11AM +0200, Michael Niedermayer wrote:
> > > On Fri, Aug 07, 2015 at 07:46:55PM -0400, compn wrote:
> > > > hello,
> > > >
>
On Thu, 09 Feb 2017 13:24:53 +, Kieran Kunhya
wrote:
> >
> > I dont think we should give access to ffmpeg-security to everyone who
> > wants to be on the list. This is of course something the community
> > has to decide and not me, iam just err-ing on the safe side and am very
> > restrictive
>
> I dont think we should give access to ffmpeg-security to everyone who
> wants to be on the list. This is of course something the community
> has to decide and not me, iam just err-ing on the safe side and am very
> restrictive on who is added.
>
This is a bogus argument considering how many pe
On Thu, Feb 09, 2017 at 03:44:59AM +0100, Michael Niedermayer wrote:
> On Wed, Feb 01, 2017 at 11:23:04PM -0800, Jerry Jiang wrote:
[...]
> i sadly dont have time to do a more complete review ATM (need sleep)
> but this patch doesnt look like it was ready for being pushed
more reviewing related to
When user use the hls_wrap, there have many problem:
1. some platform refersh the old but usefull segment
2. CDN(Content Delivery Network) Deliver HLS not friendly
The hls_wrap is used to wrap segments for use little space,
now user can use hls_list_size and hls_flags delete_segments
instead it.
2017-02-09 18:53 GMT+08:00 Carl Eugen Hoyos :
> 2017-02-09 11:52 GMT+01:00 Steven Liu :
> > 2017-02-09 18:46 GMT+08:00 Carl Eugen Hoyos :
> >
> >> 2017-02-09 8:58 GMT+01:00 Steven Liu :
> >>
> >> > +#if FF_API_HLS_WRAP
> >> > {"hls_wrap", "set number after which the index wraps",
> >> OF
2017-02-09 11:52 GMT+01:00 Steven Liu :
> 2017-02-09 18:46 GMT+08:00 Carl Eugen Hoyos :
>
>> 2017-02-09 8:58 GMT+01:00 Steven Liu :
>>
>> > +#if FF_API_HLS_WRAP
>> > {"hls_wrap", "set number after which the index wraps",
>> OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX,
2017-02-09 18:46 GMT+08:00 Carl Eugen Hoyos :
> 2017-02-09 8:58 GMT+01:00 Steven Liu :
>
> > +#if FF_API_HLS_WRAP
> > {"hls_wrap", "set number after which the index wraps",
> OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},
> > +#endif
>
> (Even if this is not done fo
2017-02-09 8:58 GMT+01:00 Steven Liu :
> +#if FF_API_HLS_WRAP
> {"hls_wrap", "set number after which the index wraps",
> OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},
> +#endif
(Even if this is not done for other deprecated options:)
Imo, either add the word dep
Michael Niedermayer wrote:
>also in absence of any other ideas, YCoCg support may be a
>qualification task. Maybe not the best choice but certainly
>usefull on its own
+1
Y'CoCg support would be useful indeed.
Best regards, Reto
___
ffmpeg-devel mail
On 2/9/17, Marton Balint wrote:
> Fixes Coverity CID 1396259.
>
> Signed-off-by: Marton Balint
> ---
> libavfilter/f_sendcmd.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libavfilter/f_sendcmd.c b/libavfilter/f_sendcmd.c
> index fb30220..522d6ad 100644
> --- a/libavfilter/f_s
45 matches
Mail list logo
