From e37b2598d372b790c0a496c7b750802a1aa102be Mon Sep 17 00:00:00 2001
From: Jun Zhao
Date: Wed, 8 Feb 2017 15:25:18 +0800
Subject: [PATCH] lavc/vaapi_encode: fix PoC negative issue.
the issue occurs when setting a large b frames number with option "bf",
it results from hard coding the sps.log2_m
On Tue, Feb 07, 2017 at 12:54:23PM -0500, Ronald S. Bultje wrote:
> On Tue, Feb 7, 2017 at 12:04 PM, wrote:
>
> > cinepak, rgb2419.7 (via the fast bilinear swscaler)
> > cinepak, internal rgb565 6.0
>
>
> The reason that your decoder-integrated colorspace convertor is so much
Hey is there an update on the status of the patch? Any other requested
changes?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Tue, Feb 7, 2017 at 10:54 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Feb 7, 2017 at 12:04 PM, wrote:
>
>> cinepak, rgb2419.7 (via the fast bilinear swscaler)
>> cinepak, internal rgb565 6.0
>
>
> The reason that your decoder-integrated colorspace convertor is so much
> fas
2017-01-12 3:29 GMT+08:00 Michael Niedermayer :
> On Tue, Jan 10, 2017 at 07:44:32PM +0800, Steven Liu wrote:
> > CID: 1396852
> > check the devices_list alloc status,
> > and release the devices_list when alloc devices error
> >
> > Signed-off-by: Steven Liu
> > ---
> > cmdutils_opencl.c | 7 ++
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.
On Wed, Feb 08, 2017 at 01:25:58AM +, Mark Thompson wrote:
> On 08/02/17 00:09, Matthew Wolenetz wrote:
> > From 1763ad5ae340e09081d8f50e867c2702cb5ec61e Mon Sep 17 00:00:00 2001
> > From: Matt Wolenetz
> > Date: Wed, 14 Dec 2016 15:26:19 -0800
> > Subject: [PATCH] lavf/mov.c: Avoid heap alloc
On Tue, Feb 07, 2017 at 03:46:02PM -0800, Matthew Wolenetz wrote:
> Updated to SIZE_MAX. Thank you for your comments.
>
>
> On Thu, Dec 15, 2016 at 5:23 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>
> > On 15.12.2016 03:25, James Almer wrote:
> > > On 12/14/2016 10:39 PM,
On 08/02/17 00:09, Matthew Wolenetz wrote:
> From 1763ad5ae340e09081d8f50e867c2702cb5ec61e Mon Sep 17 00:00:00 2001
> From: Matt Wolenetz
> Date: Wed, 14 Dec 2016 15:26:19 -0800
> Subject: [PATCH] lavf/mov.c: Avoid heap allocation wrap in mov_read_uuid
>
> Core of patch is from p...@paulmehta.com
Updated to SIZE_MAX. Thank you for your comments.
On Wed, Dec 14, 2016 at 5:39 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 15.12.2016 00:36, Matthew Wolenetz wrote:
> > From 9d45f272a682b0ea831c20e36f696e15cc0c55fe Mon Sep 17 00:00:00 2001
> > From: Matt Wolenetz
> > Da
Updated to SIZE_MAX. Thank you for your comments.
On Thu, Dec 15, 2016 at 5:23 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 15.12.2016 03:25, James Almer wrote:
> > On 12/14/2016 10:39 PM, Andreas Cadhalpun wrote:
> >> On 15.12.2016 00:34, Matthew Wolenetz wrote:
> >>>
>
and the forgotten-CC mail
On Tue, Feb 07, 2017 at 11:28:21PM +0100, Michael Niedermayer wrote:
> On Tue, Feb 07, 2017 at 10:01:52AM -0500, Vittorio Giovara wrote:
> > ---
> > libavutil/imgutils.h | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/imgut
On Tue, Feb 07, 2017 at 04:36:38PM +, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis
> ---
> I wrote this in Nov 2015, and it has resided on my GitHub fork in a branch
> since then, since I never ot around to finishing it. I noticed a spike in
> interest in the 'feature', so I rebas
On Tue, Feb 07, 2017 at 10:01:52AM -0500, Vittorio Giovara wrote:
> ---
> libavutil/imgutils.h | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/imgutils.h b/libavutil/imgutils.h
> index 67063a2..ac1bcb8 100644
> --- a/libavutil/imgutils.h
> +++ b/libavutil/
On Sun, Jan 29, 2017 at 06:44:59PM +0100, u-9...@aetey.se wrote:
> Attaching the new version.
>
> Regards,
> Rune
> cinepak.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> def45a2ab19cda70cad0618033a002298cbae056
> 0003-libavcodec-cinepak.c-fix-a-wrong-inverted-misleading.pa
On Tue, Feb 07, 2017 at 12:54:02PM +0100, u-9...@aetey.se wrote:
> Hello Michael,
>
> On Tue, Feb 07, 2017 at 03:09:56AM +0100, Michael Niedermayer wrote:
> > > What about the other patches from that series?
> >
> > > The second one is purely cosmetic (looks useful to me but not much
> > > of con
On Mon, Feb 06, 2017 at 05:14:14PM +0200, Maksym Veremeyenko wrote:
> Hi,
>
> Attached patch fixes chroma positioning during scaling interlaced 4:2:0.
>
> On a first iteration default context value been overwritten by new
> value and not been update on next iterations for fields. This mean
> that
On Mon, Feb 06, 2017 at 09:41:03AM +0200, Petri Hintukainen wrote:
> ---
> libavformat/matroska.c | 1 +
> 1 file changed, 1 insertion(+)
applied
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Democracy is the form of government in which you can choose yo
Skips using temporary files when outputting to a protocol other than
"file", which enables dash to output content over network
protocols. The logic has been copied from the HLS format.
---
libavformat/dashenc.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
d
From: Takayuki 'January June' Suwa
This adds "-profile[:v] profile_name"-style option IOW.
Thanks for reviewing my poor ugly patch, Mark... and I get back to an original
purpose - forcing OMX to use baseline profile.
(eg. RasPiCam-to-Ustream webcasting w/o additional xcoding)
---
libavcodec/o
On Mon, Feb 06, 2017 at 05:14:57PM +0100, Matthieu Bouron wrote:
> ---
> libavcodec/h264dec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
ok
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Rewriting code that is poorly written but fully und
Hello Ronald,
On Tue, Feb 07, 2017 at 10:29:01AM -0500, Ronald S. Bultje wrote:
> So, right now, the decoder outputs pal8 vs. rgb24 depending on the internal
> format of the bitstream, and you're changing it to do conversion so it
> outputs a selectable output format directly, right? (And then the
On Tue, Feb 7, 2017 at 6:48 PM, wrote:
> On Tue, Feb 07, 2017 at 04:17:30PM +0100, Hendrik Leppkes wrote:
>> On Tue, Feb 7, 2017 at 3:57 PM, wrote:
>> > Still, given the disapproval of the "code quality" without a tangible
>> > criteria to follow, I can hardly take any accomodating steps, barri
On Tue, 7 Feb 2017 12:54:23 -0500
"Ronald S. Bultje" wrote:
> Hi,
>
> On Tue, Feb 7, 2017 at 12:04 PM, wrote:
>
> > cinepak, rgb2419.7 (via the fast bilinear swscaler)
> > cinepak, internal rgb565 6.0
>
>
> The reason that your decoder-integrated colorspace convertor is s
Hi,
On Tue, Feb 7, 2017 at 12:04 PM, wrote:
> cinepak, rgb2419.7 (via the fast bilinear swscaler)
> cinepak, internal rgb565 6.0
The reason that your decoder-integrated colorspace convertor is so much
faster than swscale is because swscale is converting internally to yuv420p
On Tue, Feb 07, 2017 at 04:17:30PM +0100, Hendrik Leppkes wrote:
> On Tue, Feb 7, 2017 at 3:57 PM, wrote:
> > Still, given the disapproval of the "code quality" without a tangible
> > criteria to follow, I can hardly take any accomodating steps, barring
> > the omission of the unused code - would
On Tue, Feb 07, 2017 at 04:23:50PM +0100, wm4 wrote:
> > Still, given the disapproval of the "code quality" without a tangible
> > criteria to follow, I can hardly take any accomodating steps, barring
> > the omission of the unused code - would this step be enough?
>
> Bad:
> - dead code
Already
On Fri, Feb 03, 2017 at 11:42:03AM +0100, u-9...@aetey.se wrote:
> On Fri, Feb 03, 2017 at 11:14:28AM +0100, wm4 wrote:
> > > On a 16-bit-per-pixel output with a CPU-based decoder you will
> > > not find _any_ over 25% of Cinepak speed. Raw video can not compete
> > > either when indata delivery ba
Signed-off-by: Derek Buitenhuis
---
I wrote this in Nov 2015, and it has resided on my GitHub fork in a branch
since then, since I never ot around to finishing it. I noticed a spike in
interest in the 'feature', so I rebase and am forwarding this, in case it
is of interest.
During the triage I no
On Tue, 7 Feb 2017 15:57:03 +0100
u-9...@aetey.se wrote:
> On Mon, Feb 06, 2017 at 11:05:06PM +0100, Clément Bœsch wrote:
> > On Mon, Feb 06, 2017 at 10:05:10AM +0100, u-9...@aetey.se wrote:
> > [...]
> > > > No, code quality is not outside the scope of your patch.
> > >
> > > Code quality is
Hi,
On Tue, Feb 7, 2017 at 9:57 AM, wrote:
> Still, given the disapproval of the "code quality" without a tangible
> criteria to follow, I can hardly take any accomodating steps, barring
> the omission of the unused code - would this step be enough?
So, right now, the decoder outputs pal8 vs.
On Tue, Feb 7, 2017 at 3:57 PM, wrote:
> On Mon, Feb 06, 2017 at 11:05:06PM +0100, Clément Bœsch wrote:
>> On Mon, Feb 06, 2017 at 10:05:10AM +0100, u-9...@aetey.se wrote:
>> [...]
>> > > No, code quality is not outside the scope of your patch.
>> >
>> > Code quality is a subjective matter.
>> >
---
libavutil/imgutils.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavutil/imgutils.h b/libavutil/imgutils.h
index 67063a2..ac1bcb8 100644
--- a/libavutil/imgutils.h
+++ b/libavutil/imgutils.h
@@ -169,7 +169,12 @@ int av_image_fill_arrays(uint8_t *dst_data[4], int
On Mon, Feb 06, 2017 at 11:05:06PM +0100, Clément Bœsch wrote:
> On Mon, Feb 06, 2017 at 10:05:10AM +0100, u-9...@aetey.se wrote:
> [...]
> > > No, code quality is not outside the scope of your patch.
> >
> > Code quality is a subjective matter.
> >
>
> I'm not going to fight with you
Appreciat
Hello Michael,
On Tue, Feb 07, 2017 at 03:09:56AM +0100, Michael Niedermayer wrote:
> > What about the other patches from that series?
>
> > The second one is purely cosmetic (looks useful to me but not much
> > of concern)
>
> I have no oppinion about // vs /**/ comments but in the absence of
>
35 matches
Mail list logo
