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, 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,
> > >
> > > some of you know that we have a list for security / CVE issues.
>
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 are
> corrupted (dropped) it wil
On Thu, Feb 09, 2017 at 04:30:02AM +0100, Michael Niedermayer wrote:
> On Thu, Feb 09, 2017 at 03:17:23AM +, Rostislav Pehlivanov wrote:
> > On 9 February 2017 at 02:44, Michael Niedermayer
> [...]
> > > i sadly dont have time to do a more complete review ATM (need sleep)
> > > but this patch
On Thu, Feb 09, 2017 at 03:17:23AM +, Rostislav Pehlivanov wrote:
> On 9 February 2017 at 02:44, Michael Niedermayer
[...]
> > 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
> >
>
> Perhaps I was too hasty
On 9 February 2017 at 02:44, Michael Niedermayer
wrote:
>
> > +
> > +int ff_mjpeg_encode_mb(MpegEncContext *s, int16_t block[12][64])
> > +{
> > +int i, is_chroma_420;
> > +
> > +// Number of bits used depends on future data.
> > +// So, nothing that relies on encoding many times and
On Wed, Feb 01, 2017 at 11:23:04PM -0800, Jerry Jiang wrote:
> > seems to break
> > make fate-vsynth1-mjpeg-444
>
> Fixed.
>
Missing commit message
[...]
> -void ff_mjpeg_encode_mb(MpegEncContext *s, int16_t block[12][64])
> +// Possibly reallocate the huffman code buffer, assuming blocks_per_
On Wed, Feb 01, 2017 at 11:23:04PM -0800, Jerry Jiang wrote:
> > seems to break
> > make fate-vsynth1-mjpeg-444
>
> Fixed.
>
> ---
> Changelog| 1 +
> doc/encoders.texi| 21 ++
> libavcodec/Makefile
On Wed, Feb 08, 2017 at 10:54:06AM +0800, Steven Liu wrote:
> 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,
> no
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) mentors, so yes, i think its needed
> > >
> > > also if you want to be mentor for
For use by codec implementations which can allocate frames internally.
---
This seems to have reached agreement in libav. If there are no more comments
here, I will commit this to both tines soon.
Thanks,
- Mark
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 24 +++
On Wed, Feb 08, 2017 at 11:19:22PM +, Rostislav Pehlivanov wrote:
> Happened when max_length == 0, in which case i wasn't set to 0 during
> the first run. i is supposed to already be at the maximum size when the
> max_length is 0.
when / for what is max_length = 0 used ?
maybe i misuderstand b
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) mentors, so yes, i think its needed
> >
> > also if you want to be mentor for a swscale related project i would
> > support that idea
>
>
> Hi, sorry for th
I've separated and updated the mov_read_udta_string() patch, attached.
It prevents accessing MOVContext.meta_keys[0] in that method. That array is
1-based.
On Wed, Dec 14, 2016 at 5:40 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:
> On 15.12.2016 00:37, Matthew Wolenetz 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_sendcmd.c
+++ b/libavfilter/f_sendcmd.c
@@ -268,6 +2
Happened when max_length == 0, in which case i wasn't set to 0 during
the first run. i is supposed to already be at the maximum size when the
max_length is 0.
Fixes CID1400146
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/mjpegenc_huffman.c | 2 +-
1 file changed, 1 insertion(+), 1 deletio
Fixes Coverity CID 1396259.
Signed-off-by: Marton Balint
---
libavfilter/f_sendcmd.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavfilter/f_sendcmd.c b/libavfilter/f_sendcmd.c
index fb30220..ce21369 100644
--- a/libavfilter/f_sendcmd.c
+++ b/libavfilter/f_sendcmd.c
@@ -268,6 +26
Fixes Coverity CID 1396416.
Signed-off-by: Marton Balint
---
libavdevice/iec61883.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavdevice/iec61883.c b/libavdevice/iec61883.c
index c45ae9a..721dca3 100644
--- a/libavdevice/iec61883.c
+++ b/libavdevice/iec61883.c
@@ -120,6 +120,7 @@ stat
Fixes Coverity CID 1396277.
Signed-off-by: Marton Balint
---
libavformat/fifo.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index 8f525e5..2cbe5c5 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -19,6 +19,7 @@
* 51
2017-01-27 1:01 GMT-02:00 Michael Niedermayer :
> we need more (backup) mentors, so yes, i think its needed
>
> also if you want to be mentor for a swscale related project i would
> support that idea
Hi, sorry for the late reply.
I think implementing a cascade-less swscale could be a good proje
Andy Furniss wrote:
Another possible issue which I haven't fully investigated =
This doesn't obey setfield, which makes me think that maybe it's
only working by luck on tff input.
Ugh, ignore that bit as I don't think it should matter as long as
the filter always sees weaved frames.
A quick
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 rate.
(It's 1000fps for asf input)
Carl Eugen
___
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 are
corrupted (dropped) it will calculate wrong PTS for second field and
could hang on encoding
On Sun, 5 Feb 2017, Marton Balint wrote:
The command line parameter remains linear.
Signed-off-by: Marton Balint
---
ffplay.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/ffplay.c b/ffplay.c
index 1c9db73..cf138dc 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -73,8
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,
> >
> > some of you know that we have a list for security / CVE issues.
> > some of you did not know this.
> >
> > i think it is a private list due to n
On Wed, Feb 08, 2017 at 09:02:44AM -0500, Ronald S. Bultje wrote:
> I encourage you to fork the code and publish the faster decoder so others
> with use cases like yours can use it. It's free software, you're allowed
> and encouraged to do that.
I considered this possibility. My scope of contribut
Signed-off-by: James Almer
---
libavcodec/huffyuvencdsp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/huffyuvencdsp.c b/libavcodec/huffyuvencdsp.c
index 7edcce872b..427d118be4 100644
--- a/libavcodec/huffyuvencdsp.c
+++ b/libavcodec/huffyuvencdsp.c
@@ -21
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.
libavcodec/huffyuvdsp.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-
On Wed, Feb 8, 2017 at 9:35 AM, James Almer wrote:
> On 2/8/2017 10:47 AM, Vittorio Giovara wrote:
>> On Mon, Feb 6, 2017 at 4:59 PM, Aaron Colwell wrote:
>>> - Extracts common spherical metadata parsing logic.
>>> - Adds checks to enforce that only non-tiled equirect & non-padded cubemaps
>>>
On 2/8/2017 10:47 AM, Vittorio Giovara wrote:
> On Mon, Feb 6, 2017 at 4:59 PM, Aaron Colwell wrote:
>> - Extracts common spherical metadata parsing logic.
>> - Adds checks to enforce that only non-tiled equirect & non-padded cubemaps
>> are accepted.
>
> Hi Aaron,
> this patch basically ignore
On Tue, Feb 7, 2017 at 5:30 PM, Michael Niedermayer
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,
Andy Furniss wrote:
Michael Niedermayer wrote:
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
On February 6, 2017 at 8:39:30 PM, Aman Gupta (ffm...@tmm1.net) wrote:
Last October, kernrj and I commited a series of patches to add a53cc
support to the videotoolbox encoder.
In using that feature over the past few months, I've discovered that the
generated streams can sometimes contain random/
On 8 February 2017 at 07:09, Jerry Jiang wrote:
> 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
>
Hi, sorr
On Wed, 8 Feb 2017 09:02:44 -0500
"Ronald S. Bultje" wrote:
> (Going back to the native format discussion, I looked at decode_codebook
> and it appears the native format is actually 8-bit/component YCgCo; it's
> interesting that we chose rgb24 as output format, I'm guessing it's because
> YCgCo
Hi,
On Wed, Feb 8, 2017 at 2:45 AM, wrote:
> This unfortunately can not come near an identical performance because
> it would have to work on several times more data (frame vs codebook).
[..]
> I value layered design as much as you do, but it introduces limitations.
[..]
> In certain aspects
On Mon, Feb 6, 2017 at 4:59 PM, Aaron Colwell wrote:
> - Extracts common spherical metadata parsing logic.
> - Adds checks to enforce that only non-tiled equirect & non-padded cubemaps
> are accepted.
Hi Aaron,
this patch basically ignores all my comments, so I'm not very happy with it.
I beli
On Wed, 8 Feb 2017 13:05:40 +
Mark Thompson wrote:
> On 08/02/17 08:41, Saverio Blasi wrote:
> > +avctx->extradata = av_malloc(avctx->extradata_size +
> > AV_INPUT_BUFFER_PADDING_SIZE);
> > +if (!avctx->extradata) {
> > +av_log(avctx, AV_LOG_ERROR, "Failed to all
On 08/02/17 08:41, Saverio Blasi wrote:
> - This patch contains the changes to interface the Turing codec
> (http://turingcodec.org/) with ffmpeg. The patch was modified to address the
> comments in the review as follows:
> - Added a pkg-config file to list all dependencies required by libturin
Michael Niedermayer wrote:
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
On Wed, Feb 08, 2017 at 11:12:12 +0100, Moritz Barsnick wrote:
> Your switch/case no longer has a default. Is that intended? (Code
> linters will complain.) AFAICT, avctx->profile will be unset if an
> unknown s->profile is given. Is that okay? (It might be - I'm just
> wondering. I *do* understand
On Tue, Feb 07, 2017 at 19:05:55 +0900, Takayuki 'January June' Suwa wrote:
> +switch (s->profile) {
> +case FF_PROFILE_H264_BASELINE:
> +avctx->profile = s->profile;
> +avc.eProfile = OMX_VIDEO_AVCProfileBaseline;
> +break;
> +case FF_PRO
On Wed, 8 Feb 2017 08:41:56 +
Saverio Blasi wrote:
> - This patch contains the changes to interface the Turing codec
> (http://turingcodec.org/) with ffmpeg. The patch was modified to address the
> comments in the review as follows:
> - Added a pkg-config file to list all dependencies re
On Wed, 8 Feb 2017 11:30:59 +0300
Aleksey M wrote:
> Hi Ronald.
>
> Probably I found the reason why my filter (and vp9_superframe_bsf too) is
> not working.
>
> This code in "FFMPEG.C" just overwrites "ret" value, not handling EAGAIN at
> all (FFMPEG ver 3.1):
So try ffmpeg git master? Develop
On Tue, Feb 07, 2017 at 09:07:02PM -0700, Daniel Verkamp wrote:
> There is already a rgb24-to-rgb565 path, but it does not get used by
> default because of the needsDither check in ff_get_unscaled_swscale().
> If the scaling algorithm is set to fast_bilinear, needsDither is
> ignored and the RGB24
On Tue, Feb 07, 2017 at 10:50:42PM +0100, Michael Niedermayer wrote:
> There is no "Rl" in there
>
> git removes that when applying with git am
> git am
> ...
> From: Rl
> ...
> git show
> ...
> Author: addr-see-the-webs...@aetey.se
Oh! :-/
> I dont know why git does that but it does, i retest
- This patch contains the changes to interface the Turing codec
(http://turingcodec.org/) with ffmpeg. The patch was modified to address the
comments in the review as follows:
- Added a pkg-config file to list all dependencies required by libturing.
This should address the issue pointed out by
Hi Ronald.
Probably I found the reason why my filter (and vp9_superframe_bsf too) is
not working.
This code in "FFMPEG.C" just overwrites "ret" value, not handling EAGAIN at
all (FFMPEG ver 3.1):
ret = av_bsf_receive_packet(ost->bsf_ctx[idx - 1], pkt);
>
> /* HACK! - aac_
Dear Henrik,
On Tue, Feb 07, 2017 at 07:21:39PM +0100, Hendrik Leppkes wrote:
> > Why not, if there will be a data consumer with this hypothetical format
> > and we will need speed? Why not? This _is_ efficient at the decoder,
> > it is just many of the developers ignored this fact until now.
>
>
49 matches
Mail list logo
