On Fri, Dec 16, 2016 at 5:32 PM, wm4 wrote:
> On Fri, 16 Dec 2016 11:12:02 +0100
> Steve Lhomme wrote:
>
>> From: Steve Lhomme
>>
>> ---
>> libavutil/Makefile | 3 +
>> libavutil/hwcontext.c | 3 +
>> libavutil/hwcontext.h | 1 +
>> libavutil/hwcontext_d3d11v
On 23.12.2016 21:49, Michael Niedermayer wrote:
On Fri, Dec 23, 2016 at 02:50:16PM +0100, Tobias Rapp wrote:
Fixes pts gaps when reading AVI files > 256GiB generated by FFmpeg.
Signed-off-by: Tobias Rapp
---
libavformat/avidec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
applie
On Tue, Jan 03, 2017 at 02:15:20PM +0100, Vittorio Giovara wrote:
> On Mon, Jan 2, 2017 at 2:00 AM, James Almer wrote:
> > On 1/1/2017 8:28 PM, Michael Niedermayer wrote:
> >> Fixes CID1396405
>
> What is the CID about?
sorry for not quoting this prviously, it isnt very interresting.
my patch is
The following three commits created a regression by writing initially
invalid mkv headers:
650e17d88b63b5aca6e0a43483e89e64b0f7d2dd avformat/matroskaenc: write a
CRC32 element on Tags
3bcadf822711720ff0f8d14db71ae47cdf97e652 avformat/matroskaenc: write a
CRC32 element on Info
ee888cfbe777cd2916a35
On 1/3/2017 9:57 PM, Ronald S. Bultje wrote:
> Hm, right... OK, yeah, I understand the issue, but I somehow doubt there's
> an easy way to resolve that that isn't disgustingly hacky on our side.
If you're not very fond of happiness or joy, you could run a separate
64-bit process to decode and pass
Hi,
On Tue, Jan 3, 2017 at 4:35 PM, Matthieu Beghin <
matthieu.beg...@garagecube.com> wrote:
> Hi,
>
> > On 03 Jan 2017, at 18:26, Ronald S. Bultje wrote:
> >
> > Hi,
> >
> > On Tue, Jan 3, 2017 at 12:16 PM, Matthieu Beghin <
> > matthieu.beg...@garagecube.com> wrote:
> >
> >>
> >>> On 03 Jan 20
Hi,
> On 03 Jan 2017, at 18:26, Ronald S. Bultje wrote:
>
> Hi,
>
> On Tue, Jan 3, 2017 at 12:16 PM, Matthieu Beghin <
> matthieu.beg...@garagecube.com> wrote:
>
>>
>>> On 03 Jan 2017, at 17:55, Ronald S. Bultje wrote:
>>>
>>> Hi,
>>>
>>> On Tue, Jan 3, 2017 at 11:44 AM, Matthieu Beghin <
On Tue, Jan 03, 2017 at 12:26:59PM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Jan 3, 2017 at 12:16 PM, Matthieu Beghin <
> matthieu.beg...@garagecube.com> wrote:
>
> >
> > > On 03 Jan 2017, at 17:55, Ronald S. Bultje wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Jan 3, 2017 at 11:44 AM, Matth
Hi,
On Tue, Jan 3, 2017 at 12:16 PM, Matthieu Beghin <
matthieu.beg...@garagecube.com> wrote:
>
> > On 03 Jan 2017, at 17:55, Ronald S. Bultje wrote:
> >
> > Hi,
> >
> > On Tue, Jan 3, 2017 at 11:44 AM, Matthieu Beghin <
> > matthieu.beg...@garagecube.com> wrote:
> >
> >>> I'm assuming that you'
> On 03 Jan 2017, at 17:55, Ronald S. Bultje wrote:
>
> Hi,
>
> On Tue, Jan 3, 2017 at 11:44 AM, Matthieu Beghin <
> matthieu.beg...@garagecube.com> wrote:
>
>>> I'm assuming that you're talking about 8K H264 with pixfmt=yuv420p10? 8K
>> yuv420p10 frames are 100MB
>>
>> Correct
>>
>>> 32 plu
looks like there is a bug in commit
1a08758e7c4e14a9ea8d2fef6c33ad411b2d3c40 relating to the handling of
ptr in decode_frame after decode_block is called, before this commit
ptr would have been incremented for each line in the data window, now
after the commit it is left at the start of the first i
Hi,
On Tue, Jan 3, 2017 at 11:44 AM, Matthieu Beghin <
matthieu.beg...@garagecube.com> wrote:
> > I'm assuming that you're talking about 8K H264 with pixfmt=yuv420p10? 8K
> yuv420p10 frames are 100MB
>
> Correct
>
> > 32 plus delayed output and current_pic gives H264_MAX_PICTURE_COUNT = 36
> with
> I'm assuming that you're talking about 8K H264 with pixfmt=yuv420p10? 8K
> yuv420p10 frames are 100MB
Correct
> 32 plus delayed output and current_pic gives H264_MAX_PICTURE_COUNT = 36
> without threading: 36*100=3.6GB.
What do you mean by "delayed output” ? Can you link me to a document ?
Hi,
On Tue, Jan 3, 2017 at 10:58 AM, Matthieu Beghin <
matthieu.beg...@garagecube.com> wrote:
> Hi,
>
> My application is using libavcodec etc. to playback movies. Everything is
> ok with our 64 bits app. But I have a 32 bits app and there when playing a
> 8k we reach 3 GB memory usage, so when a
On Tue, Jan 03, 2017 at 16:29:44 +0100, Gerion Entrup wrote:
> The matching is not calculated automatically but with a commandline switch.
> I've tried
> to reformulate it in a better way.
Very good, I understand it now. :-)
> I don't understand fully what your question is.
>
> The output path
Hi,
My application is using libavcodec etc. to playback movies. Everything is ok
with our 64 bits app. But I have a 32 bits app and there when playing a 8k we
reach 3 GB memory usage, so when adding another 4k or a few HD movies, the app
crashes.
I haven’t found a way to reduce memory usage. T
On Dienstag, 3. Januar 2017 11:33:48 CET Moritz Barsnick wrote:
> On Mon, Jan 02, 2017 at 23:52:58 +0100, Gerion Entrup wrote:
> > +Calculates the MPEG-7 Video Signature. The filter could handle more than
> > one
> > +input. In this case the matching between the inputs could be calculated.
> > Th
2017-01-03 22:07 GMT+08:00 Bodecs Bela :
>
>
> 2017.01.03. 13:58 keltezéssel, Steven Liu írta:
>
>> 2017-01-03 20:52 GMT+08:00 Moritz Barsnick :
>>
>> On Tue, Jan 03, 2017 at 13:38:44 +0100, Bodecs Bela wrote:
>>>
I have technical difficulties to merge them into one commit. I am not a
gi
On Thu, Dec 22, 2016 at 08:35:57PM +0100, Michael Niedermayer wrote:
> On Thu, Dec 22, 2016 at 02:16:30PM +0100, Tobias Rapp wrote:
> > Signed-off-by: Tobias Rapp
> > ---
> > libavformat/avidec.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
>
> LGTM
applied
[...]
--
2017.01.03. 13:58 keltezéssel, Steven Liu írta:
2017-01-03 20:52 GMT+08:00 Moritz Barsnick :
On Tue, Jan 03, 2017 at 13:38:44 +0100, Bodecs Bela wrote:
I have technical difficulties to merge them into one commit. I am not a
git expert.
This muxers.texi patch is based on my earlier accepted,
On Mon, Jan 2, 2017 at 2:00 AM, James Almer wrote:
> On 1/1/2017 8:28 PM, Michael Niedermayer wrote:
>> Fixes CID1396405
What is the CID about?
>> Untested except fate which does not test this, please someone test this
>
> The encoder seems to need libsnappy, so no FATE test can be added.
Only
On 03/01/17 07:13, Huang, Zhengxu wrote:
> From 687ce9c804b2618f021100235c46a33b48fa522c Mon Sep 17 00:00:00 2001
> From: Zhengxu
> Date: Wed, 14 Dec 2016 11:55:31 +0800
> Subject: [PATCH] libavutil/hwcontext_qsv: Command line using hwaccel 'QSV'
> doesn't work.
>
> Command: ffmpeg -hwaccel qsv
2017-01-03 20:52 GMT+08:00 Moritz Barsnick :
> On Tue, Jan 03, 2017 at 13:38:44 +0100, Bodecs Bela wrote:
> > I have technical difficulties to merge them into one commit. I am not a
> > git expert.
> > This muxers.texi patch is based on my earlier accepted, but yet not
> > applied doc patch on thi
On Tue, Jan 03, 2017 at 13:38:44 +0100, Bodecs Bela wrote:
> I have technical difficulties to merge them into one commit. I am not a
> git expert.
> This muxers.texi patch is based on my earlier accepted, but yet not
> applied doc patch on this same file.
> I created the related code patch in a d
On 03/01/17 06:35, Huang, Zhengxu wrote:
> From 8b1bcc0634f6ce36acfbd2bfdd26690a6323d09c Mon Sep 17 00:00:00 2001
> From: Zhengxu
> Date: Fri, 16 Dec 2016 11:10:34 +0800
> Subject: [PATCH] libavutil/hwcontext_qsv: Fix bug that the QSV encoded frames'
> width and height are 32-aligned.
>
> Descri
2017.01.03. 12:48 keltezéssel, Steven Liu írta:
2017-01-03 19:41 GMT+08:00 Bodecs Bela :
2017.01.03. 11:42 keltezéssel, Moritz Barsnick írta:
On Tue, Jan 03, 2017 at 09:38:18 +0100, Bodecs Bela wrote:
doc/muxers.texi | 19 ++-
1 file changed, 18 insertions(+), 1 dele
2017-01-03 19:41 GMT+08:00 Bodecs Bela :
>
>
> 2017.01.03. 11:42 keltezéssel, Moritz Barsnick írta:
>
>> On Tue, Jan 03, 2017 at 09:38:18 +0100, Bodecs Bela wrote:
>>
>>> doc/muxers.texi | 19 ++-
>>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>>
>> You should probably squ
2017.01.03. 11:42 keltezéssel, Moritz Barsnick írta:
On Tue, Jan 03, 2017 at 09:38:18 +0100, Bodecs Bela wrote:
doc/muxers.texi | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
You should probably squash this with the other patch, into one commit.
-Makes it possi
On Tue, Jan 03, 2017 at 09:38:18 +0100, Bodecs Bela wrote:
> doc/muxers.texi | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
You should probably squash this with the other patch, into one commit.
> -Makes it possible to use segment indexes as %%d besides date/time val
On Mon, Jan 02, 2017 at 23:52:58 +0100, Gerion Entrup wrote:
> +Calculates the MPEG-7 Video Signature. The filter could handle more than one
> +input. In this case the matching between the inputs could be calculated. The
> +filter passthrough the first input. The signature of each stream could be
2017-01-03 16:47 GMT+08:00 Bodecs Bela :
>
>
> 2017.01.03. 9:23 keltezéssel, Steven Liu írta:
>
>> 2017-01-03 16:11 GMT+08:00 Bodecs Bela :
>>
>>
>>> 2017.01.03. 2:34 keltezéssel, Steven Liu írta:
>>>
>>> 2017-01-03 8:22 GMT+08:00 Steven Liu :
2017-01-03 2:58 GMT+08:00 Bodecs Bela :
2017.01.03. 9:23 keltezéssel, Steven Liu írta:
2017-01-03 16:11 GMT+08:00 Bodecs Bela :
2017.01.03. 2:34 keltezéssel, Steven Liu írta:
2017-01-03 8:22 GMT+08:00 Steven Liu :
2017-01-03 2:58 GMT+08:00 Bodecs Bela :
Dear All,
this patch makes it possible to put actual segment file size
2017.01.03. 1:22 keltezéssel, Steven Liu írta:
2017-01-03 2:58 GMT+08:00 Bodecs Bela :
Dear All,
this patch makes it possible to put actual segment file size (measured
in bytes) and/or duration (calculated in microseconds) into segment
filenames. This feature is useful when post-processing l
2017-01-03 16:11 GMT+08:00 Bodecs Bela :
>
>
> 2017.01.03. 2:34 keltezéssel, Steven Liu írta:
>
>> 2017-01-03 8:22 GMT+08:00 Steven Liu :
>>
>>
>>> 2017-01-03 2:58 GMT+08:00 Bodecs Bela :
>>>
>>> Dear All,
this patch makes it possible to put actual segment file size (measured
in byt
2017.01.03. 2:34 keltezéssel, Steven Liu írta:
2017-01-03 8:22 GMT+08:00 Steven Liu :
2017-01-03 2:58 GMT+08:00 Bodecs Bela :
Dear All,
this patch makes it possible to put actual segment file size (measured
in bytes) and/or duration (calculated in microseconds) into segment
filenames. Thi
35 matches
Mail list logo
