On Sat, 11 Feb 2017 11:56:07 +0100
Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavformat/mpl2dec.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/libavformat/mpl2dec.c b/libavformat/mpl2dec.c
> index 59589d5..0e30cb0 100644
> --- a/libavformat/mpl2dec.c
> +++
There is no reason that draining couldn't return an error or two. But
some decoders don't handle this very well, and might always return an
error. This can lead to API users getting into an infinite loop and
burning CPU, because no progress is made and EOF is never returned.
In fact, ffmpeg.c cont
On Wed, 15 Feb 2017 05:33:38 +
Aman Gupta wrote:
> On Tue, Feb 14, 2017 at 5:14 PM Aman Gupta wrote:
>
> > From: Aman Gupta
> >
> > The videotoolbox hwaccel only receives SLICE and IDR_SLICE NALUs. This
> > works fine most of the time, but some streams fail to decode because
> > changes in
On Tue, Feb 14, 2017 at 5:14 PM Aman Gupta wrote:
> From: Aman Gupta
>
> The videotoolbox hwaccel only receives SLICE and IDR_SLICE NALUs. This
> works fine most of the time, but some streams fail to decode because
> changes in PPS are not propagated to the VT decoder.
Perhaps SPS can change m
On Tue, 14 Feb 2017 12:32:07 +
Yogender Gupta wrote:
> Hi Miroslav , Philip,
>
> We will look at this issue, and provide a fix for the same. Would be
> great to send me and Sumit (also copied here) the command lines that
> you tried and the observations to repro at our end.
Here's the sampl
On Tue, Feb 14, 2017 at 6:54 PM, James Almer wrote:
> On 2/14/2017 5:52 PM, Vittorio Giovara wrote:
>> On Fri, Feb 10, 2017 at 6:25 PM, Michael Niedermayer
>> wrote:
>>> On Fri, Feb 10, 2017 at 04:11:43PM -0500, Vittorio Giovara wrote:
Signed-off-by: Vittorio Giovara
---
This shou
On Wed, Feb 15, 2017 at 08:24:24AM +0800, Shi Qiu wrote:
> no, it's different in ffmpeg3
which commit fixed it ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
From: Aman Gupta
The videotoolbox hwaccel only receives SLICE and IDR_SLICE NALUs. This
works fine most of the time, but some streams fail to decode because
changes in PPS are not propagated to the VT decoder.
The failures in this case are incredibly annoying, as VTDecodeFrame()
still returns no
no, it's different in ffmpeg3
On Tue, Feb 14, 2017 at 9:21 PM, Michael Niedermayer wrote:
> On Tue, Feb 14, 2017 at 12:03:56PM +0800, Shi Qiu wrote:
> > libavformat/utils.c,line 3308:
>
> Is this issue reproduceable with git master ?
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147E
Needed by peakpoints filter
This is identical to how it is used in the other libs
---
libavfilter/Makefile| 1 +
libavfilter/file_open.c | 1 +
tests/ref/fate/source | 1 +
3 files changed, 3 insertions(+)
create mode 100644 libavfilter/file_open.c
diff --git a/libavfilter/Makefile b/liba
On 2/14/2017 5:52 PM, Vittorio Giovara wrote:
> On Fri, Feb 10, 2017 at 6:25 PM, Michael Niedermayer
> wrote:
>> On Fri, Feb 10, 2017 at 04:11:43PM -0500, Vittorio Giovara wrote:
>>> Signed-off-by: Vittorio Giovara
>>> ---
>>> This should help not losing details over muxing and allows
>>> callers
On Sat, Feb 11, 2017 at 02:56:32AM +0100, Michael Niedermayer wrote:
> On Fri, Feb 10, 2017 at 05:21:00PM -0500, Vittorio Giovara wrote:
> > In particular cases, it is possible to initialize top_field_first
> > but not interlaced_frame. Make sure to correctly tag a frame
> > as interlaced when this
On Tue, Feb 14, 2017 at 4:54 PM, Michael Niedermayer
wrote:
> On Tue, Feb 14, 2017 at 03:52:39PM -0500, Vittorio Giovara wrote:
>> On Fri, Feb 10, 2017 at 6:25 PM, Michael Niedermayer
>> wrote:
>> > On Fri, Feb 10, 2017 at 04:11:43PM -0500, Vittorio Giovara wrote:
>> >> Signed-off-by: Vittorio Gi
On Tue, Feb 14, 2017 at 03:52:39PM -0500, Vittorio Giovara wrote:
> On Fri, Feb 10, 2017 at 6:25 PM, Michael Niedermayer
> wrote:
> > On Fri, Feb 10, 2017 at 04:11:43PM -0500, Vittorio Giovara wrote:
> >> Signed-off-by: Vittorio Giovara
> >> ---
> >> This should help not losing details over muxin
On 14/02/17 19:44, Daniel Oberhoff wrote:
> filter strictly “halves” the image efficiently, which is often exactly what
> is needed
> likely much faster than using scale
Did you benchmark this? How?
$ time ./ffmpeg -f lavfi -i allyuv -vf 'scale=iw/2:ih/2' -vframes 400 -f null -
...
frame= 400
On Fri, Feb 10, 2017 at 6:25 PM, Michael Niedermayer
wrote:
> On Fri, Feb 10, 2017 at 04:11:43PM -0500, Vittorio Giovara wrote:
>> Signed-off-by: Vittorio Giovara
>> ---
>> This should help not losing details over muxing and allows
>> callers to get additional information in a clean manner.
>>
>>
On 2/14/17, Daniel Oberhoff wrote:
> filter strictly "halves" the image efficiently, which is often exactly what
> is needed
> likely much faster than using scale
> fully slice parallelized
>
> Signed-off-by: Daniel Oberhoff
> ---
> libavfilter/Makefile | 1 +
> libavfilter/allfilters.c |
On 2/14/17, Daniel Oberhoff wrote:
> Signed-off-by: Daniel Oberhoff
> ---
> libavfilter/vf_remap.c | 149
> -
> 1 file changed, 97 insertions(+), 52 deletions(-)
>
Have you benchmarked this with bench filter?
Is it actually faster?
__
On 2/14/17, Daniel Oberhoff wrote:
> this is a fractional version of remap that interprets
> the x/y maps as 13.3bit fixed point values, i.e
> the three least significant bits are used for inter-pixel
> interpolation by weighed averaging the four adjacent pixels
>
> Signed-off-by: Daniel Oberhoff
Signed-off-by: Daniel Oberhoff
---
libavfilter/vf_remap.c | 149 -
1 file changed, 97 insertions(+), 52 deletions(-)
diff --git a/libavfilter/vf_remap.c b/libavfilter/vf_remap.c
index e70956d..84b2466 100644
--- a/libavfilter/vf_remap.c
+++ b/libav
this is a fractional version of remap that interprets
the x/y maps as 13.3bit fixed point values, i.e
the three least significant bits are used for inter-pixel
interpolation by weighed averaging the four adjacent pixels
Signed-off-by: Daniel Oberhoff
---
libavfilter/Makefile| 1 +
liba
filter strictly “halves” the image efficiently, which is often exactly what is
needed
likely much faster than using scale
fully slice parallelized
Signed-off-by: Daniel Oberhoff
---
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_halve.c | 367 ++
On Tue, Feb 14, 2017 at 06:11:22PM +0100, Michael Niedermayer wrote:
> On Mon, Feb 13, 2017 at 12:57:30PM +0100, Michael Niedermayer wrote:
> > On Mon, Feb 13, 2017 at 10:31:19AM +0100, wm4 wrote:
> > > On Fri, 10 Feb 2017 15:25:13 +0100
> > > Michael Niedermayer wrote:
> > >
> > > > On Fri, Feb
On Mon, Feb 13, 2017 at 12:57:30PM +0100, Michael Niedermayer wrote:
> On Mon, Feb 13, 2017 at 10:31:19AM +0100, wm4 wrote:
> > On Fri, 10 Feb 2017 15:25:13 +0100
> > Michael Niedermayer wrote:
> >
> > > On Fri, Feb 10, 2017 at 03:22:28PM +0100, Michael Niedermayer wrote:
> > > > On Fri, Feb 10,
On Tue, 14 Feb 2017 13:50:16 -0300
James Almer wrote:
> On 2/13/2017 7:51 AM, wm4 wrote:
> > Public fields were added after the private fields (negating the entire
> > point of this). New private fields go into AVStreamInternal anyway.
> >
> > The new marker was set by guessing which fields are
On 2/13/2017 7:51 AM, wm4 wrote:
> Public fields were added after the private fields (negating the entire
> point of this). New private fields go into AVStreamInternal anyway.
>
> The new marker was set by guessing which fields are supposed to be
> private and wshich not. recommended_encoder_confi
Great thanks!
Joel
> On Feb 14, 2017, at 9:59 AM, Michael Niedermayer
> wrote:
>
> On Mon, Feb 13, 2017 at 09:57:13AM -0600, Joel Cunningham wrote:
>> Friendly ping! Any issues receiving this updated patch (submitted with git
>> send-email)? Anyone try it out yet?
>
> looks reasonable
> wi
On Mon, Feb 13, 2017 at 1:44 PM, James Darnley wrote:
> Originally committed to x264 in 1637239a by Henrik Gramner who has
> agreed to re-license it as LGPL. Original commit message follows.
>
> x86: Avoid some bypass delays and false dependencies
>
> A bypass delay of 1-3 clock cycles ma
On Mon, Feb 13, 2017 at 09:57:13AM -0600, Joel Cunningham wrote:
> Friendly ping! Any issues receiving this updated patch (submitted with git
> send-email)? Anyone try it out yet?
looks reasonable
will apply
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0
Ok, will try to get round to that today, otherwise it will be two weeks as I am
traveling.
> On 9 Feb 2017, at 17:15, Thilo Borgmann wrote:
>
> 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 t
On Tue, Feb 14, 2017 at 10:18:02PM +0800, Steven Liu wrote:
> 2017-02-14 21:14 GMT+08:00 Thomas Stephens :
>
> > Has anybody had a chance to look at this patch?
> >
> > Thanks,
> > --Thomas
> >
> > On Tue, Feb 7, 2017, 2:20 PM Thomas Stephens wrote:
> >
> > > Skips using temporary files when outp
Hi Rune,
On Tue, Feb 14, 2017 at 6:14 AM, wrote:
> The huge difference in the amount of the data to be processed; in other
> words the very essence of the vector quantization technology where frame
> data is represented by a codebook, by design meant to be much smaller.
We acknowledge that. We
2017-02-14 21:14 GMT+08:00 Thomas Stephens :
> Has anybody had a chance to look at this patch?
>
> Thanks,
> --Thomas
>
> On Tue, Feb 7, 2017, 2:20 PM Thomas Stephens wrote:
>
> > Skips using temporary files when outputting to a protocol other than
> > "file", which enables dash to output content
On Tue, Feb 14, 2017 at 12:03:56PM +0800, Shi Qiu wrote:
> libavformat/utils.c,line 3308:
Is this issue reproduceable with git master ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of
Has anybody had a chance to look at this patch?
Thanks,
--Thomas
On Tue, Feb 7, 2017, 2:20 PM Thomas Stephens wrote:
> 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
On Mon, Feb 13, 2017 at 06:27:50AM +0100, wm4 wrote:
> On Fri, 10 Feb 2017 22:43:26 +0100
> Michael Niedermayer wrote:
>
> > On Fri, Feb 10, 2017 at 01:35:34PM +0100, wm4 wrote:
> > > From: Anton Khirnov
> > >
> > > This will be useful in the following commit, after which the muxer
> > > timeba
Hi Miroslav , Philip,
We will look at this issue, and provide a fix for the same. Would be great to
send me and Sumit (also copied here) the command lines that you tried and the
observations to repro at our end.
Thanks,
Yogender
-Original Message-
From: Miroslav Slugeň [mailto:thunde..
2017-02-14 19:18 GMT+08:00 Michael Niedermayer :
> On Sun, Feb 12, 2017 at 07:12:31PM +0100, Miroslav Slugeň wrote:
> > If we are using copyts parameter it is not possible to inserting key
> > frames same way as hlsenc requests, this will lead to different hls
> > segments length.
> >
> > -copyts
On Sun, Feb 12, 2017 at 07:12:31PM +0100, Miroslav Slugeň wrote:
> If we are using copyts parameter it is not possible to inserting key
> frames same way as hlsenc requests, this will lead to different hls
> segments length.
>
> -copyts is required for long period audio/video sync
>
> Small modif
On Tue, Feb 14, 2017 at 10:03:41AM +0100, Paul B Mahol wrote:
> Correct way in solving this is outputing in cinepak decoder actual
> native format that it
> uses and not do any conversions of colorspace which is currently done.
> Implement correct colorspace conversions of cinepak format to others
Dne 14.2.2017 v 09:33 Steven Liu napsal(a):
2017-02-14 16:30 GMT+08:00 Miroslav Slugeň :
Dne 14.2.2017 v 04:59 Steven Liu napsal(a):
2017-02-13 21:15 GMT+08:00 Miroslav Slugeň :
This patch will fix cutting hls segments into exactly same length. Because
it will intialize only on first ref_pac
On 2/14/17, wm4 wrote:
> On Tue, 14 Feb 2017 09:51:54 +0100
> u-9...@aetey.se wrote:
>
>> On Tue, Feb 14, 2017 at 06:51:46AM +0100, wm4 wrote:
>> > On Mon, 13 Feb 2017 18:51:39 +0100
>> > u-9...@aetey.se wrote:
>> >
>> > > Then abstracting a "mini-swscale" could become justifiable.
>> >
>> > And t
On Tue, 14 Feb 2017 09:51:54 +0100
u-9...@aetey.se wrote:
> On Tue, Feb 14, 2017 at 06:51:46AM +0100, wm4 wrote:
> > On Mon, 13 Feb 2017 18:51:39 +0100
> > u-9...@aetey.se wrote:
> >
> > > Then abstracting a "mini-swscale" could become justifiable.
> >
> > And this is why we should probably
On Tue, Feb 14, 2017 at 06:51:46AM +0100, wm4 wrote:
> On Mon, 13 Feb 2017 18:51:39 +0100
> u-9...@aetey.se wrote:
>
> > Then abstracting a "mini-swscale" could become justifiable.
>
> And this is why we should probably reject this patch.
> What you wrote paints a horrifying future.
--^^^
2017-02-14 16:30 GMT+08:00 Miroslav Slugeň :
> Dne 14.2.2017 v 04:59 Steven Liu napsal(a):
>
> 2017-02-13 21:15 GMT+08:00 Miroslav Slugeň :
>>
>> This patch will fix cutting hls segments into exactly same length. Because
>>> it will intialize only on first ref_packet, which is video frame, not
>>>
Dne 14.2.2017 v 04:59 Steven Liu napsal(a):
2017-02-13 21:15 GMT+08:00 Miroslav Slugeň :
This patch will fix cutting hls segments into exactly same length. Because
it will intialize only on first ref_packet, which is video frame, not audio
frame (old behavior)
Now it should be possible to crea
Dne 14.2.2017 v 06:51 Hendrik Leppkes napsal(a):
On Mon, Feb 13, 2017 at 11:00 PM, Timo Rothenpieler
wrote:
It is problem in NVENC.
You create first frame before initialization of NVENC in CUVID, so this
first frame is not accesible to NVENC until
dl_fn->cuda_dl->cuCtxPushCurrent(ctx->cu_conte
47 matches
Mail list logo
