coded_width/height are unnitialized and will be overwritten by
dec_ctx->width/height in avcodec_open2()
This fixes tiket #6958.
Signed-off-by: Zhong Li
---
fftools/ffprobe.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 0e7a771..233760d 10
On 1/11/2018 7:12 PM, Gyan Doshi wrote:
The no-op commit e496c45 from Libav introduced an option which allowed
the user to relocate text to fit within the frame if it was going out of
bounds.
For some reason, when the merge commit b479e01 was applied, the option
was added but the code fragme
Improves remuxing support when vp9 decoder is not compiled in.
Signed-off-by: James Almer
---
libavcodec/vp9_parser.c | 98 -
1 file changed, 97 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c
index 9531
> On 19 Jan 2018, at 11:18, Jeyapal, Karthick wrote:
>
>
>
> On 1/19/18 8:42 AM, Brendan McGrath wrote:
>> Thanks Karthick - I can confirm that your patch does solve the issue.
> Thanks for the confirmation.
>>
>> However - I noticed your patch does not include HEVC. I believe this format
>>
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Thursday, January 18, 2018 5:26 PM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH V2 2/2] Don't overwrite previously setup
> dimensions for all codecs
>
>
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Almer
> Sent: Thursday, January 18, 2018 1:15 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavc: Add coded_w/h to
> AVCodecParameters
>
> On 1/18/2018 2:03
On 1/19/18 8:42 AM, Brendan McGrath wrote:
> Thanks Karthick - I can confirm that your patch does solve the issue.
Thanks for the confirmation.
>
> However - I noticed your patch does not include HEVC. I believe this format
> is now supported in HLS (and that several players including iOS 11 now
Thanks Karthick - I can confirm that your patch does solve the issue.
However - I noticed your patch does not include HEVC. I believe this
format is now supported in HLS (and that several players including iOS
11 now provide support).
On 19/01/18 00:41, Jeyapal, Karthick wrote:
On 1/18/18 6:
On 11/01/18 07:07, Jun Zhao wrote:
> From b76a2f790814df326d7d93c54b14b3c8e74ab759 Mon Sep 17 00:00:00 2001
> From: Jun Zhao
> Date: Thu, 11 Jan 2018 15:00:30 +0800
> Subject: [PATCH 2/2] example/vaapi_transcode: Add a VA-API transcode example.
>
> Add VA-API transcoding example, useage like:
> .
On 13/01/18 01:08, Rodger Combs wrote:
> ---
> libavfilter/vf_scale_vaapi.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
> index 22e928c..4bead5a 100644
> --- a/libavfilter/vf_scale_vaapi.c
> +++ b/libavfilter/vf_scale_v
In the file the fuzzer produced the frame rate is incredibly small
(7.29112e-304).
I thought %e (or %g if you prefer) produced the most appropriate and
readable log message.
Also happy to just remove the frame rate from the log if you prefer?
On Thu, Jan 18, 2018 at 4:02 PM, Carl Eugen Hoyos
wrot
On 19/01/18 00:41, Jun Zhao wrote:
> On 2018/1/19 8:25, Mark Thompson wrote:
>> On 18/01/18 05:18, Jun Zhao wrote:
>>> From d157fdbffebd07066b1a857398e1067615f908b3 Mon Sep 17 00:00:00 2001
>>> From: Jun Zhao
>>> Date: Mon, 8 Jan 2018 16:02:35 +0800
>>> Subject: [PATCH V3 2/6] lavfi: use common VP
On 2018/1/19 8:33, Mark Thompson wrote:
> On 18/01/18 05:18, Jun Zhao wrote:
>> From 795fc41a83c23ff461fef1870a003d77b070084f Mon Sep 17 00:00:00 2001
>> From: Jun Zhao
>> Date: Mon, 8 Jan 2018 16:12:41 +0800
>> Subject: [PATCH V3 4/6] lavfi: add ProcAmp(color balance) vaapi video filter.
>>
>>
On 2018/1/19 8:25, Mark Thompson wrote:
> On 18/01/18 05:18, Jun Zhao wrote:
>> From d157fdbffebd07066b1a857398e1067615f908b3 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao
>> Date: Mon, 8 Jan 2018 16:02:35 +0800
>> Subject: [PATCH V3 2/6] lavfi: use common VPP infrastructure for
>> vf_scale_vaapi.
On 18/01/18 05:18, Jun Zhao wrote:
>
> From 795fc41a83c23ff461fef1870a003d77b070084f Mon Sep 17 00:00:00 2001
> From: Jun Zhao
> Date: Mon, 8 Jan 2018 16:12:41 +0800
> Subject: [PATCH V3 4/6] lavfi: add ProcAmp(color balance) vaapi video filter.
>
> add ProcAmp(color balance) vaapi video filter,
On 18/01/18 05:18, Jun Zhao wrote:
>
> From d157fdbffebd07066b1a857398e1067615f908b3 Mon Sep 17 00:00:00 2001
> From: Jun Zhao
> Date: Mon, 8 Jan 2018 16:02:35 +0800
> Subject: [PATCH V3 2/6] lavfi: use common VPP infrastructure for
> vf_scale_vaapi.
>
> Use the common VPP infrastructure re-wor
On 18/01/18 05:18, Jun Zhao wrote:
>
> V3: - Fix the error handle in vaapi_vpp.
> - Fix the build issue and remove the duplicated header file
> - Add a entry to Changelog for procamp_vaapi filter.
>
> V2: - Fix the resource leak in procamp/misc VPP filter.
> - Re-work the common VAAP
On 19/01/18 00:08, Carl Eugen Hoyos wrote:
> 2018-01-19 0:42 GMT+01:00 Mark Thompson :
>
>> To offer this suggestion in a more concrete form.
>
> Works as expected here except for printing an error which
> may be intended.
Yes, that's intended. Data may have been lost unexpectedly (as with any
2018-01-19 0:42 GMT+01:00 Mark Thompson :
> To offer this suggestion in a more concrete form.
Works as expected here except for printing an error which
may be intended.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://
2018-01-19 0:21 GMT+01:00 Nikolas Bowe :
> + av_log(matroska->ctx, AV_LOG_WARNING,
> + "Invalid frame rate %e. Cannot calculate default
> duration.\n",
> + track->video.frame_rate);
We currently have one ocurence of "%e" in the who
On Thu, Jan 18, 2018 at 07:39:07PM +0100, Thilo Borgmann wrote:
> This time including the patch...
> fftools/ffmpeg.c | 28 +++
> fftools/ffmpeg_opt.c |2
> libavformat/Makefile |2
> libavformat/allformats.c |1
> libavformat/rm.c |1
> libavformat/r
On systems which deliver SIGPIPE (Unices), a broken pipe will currently
result in the immediate termination of the ffmpeg process (the default
disposition as required by POSIX). This is undesirable, because while
the broken pipe is likely fatal to useful cleanup of whatever component
is writing to
On Thu, Jan 18, 2018 at 09:24:20AM +0100, Jorge Ramirez-Ortiz wrote:
> On 01/09/2018 11:56 PM, Jorge Ramirez-Ortiz wrote:
> >From: Mark Thompson
> >
> >Refcount all of the context information. This also fixes a potential
> >segmentation fault when accessing freed memory (buffer returned after
> >
---
libavformat/matroskadec.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 496499b553..cd9e1f56c2 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2096,8 +2096,16 @@ static in
---
libavutil/x86/x86inc.asm | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 438863042f..5044ee86f0 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
@@ -827,9 +827,8 @@ BRANCH_INSTR jz, je, jnz,
---
libavutil/x86/x86inc.asm | 87
1 file changed, 36 insertions(+), 51 deletions(-)
diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index de048f863d..438863042f 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/x86/x86inc.asm
There are 32 pseudo-instructions for each floating-point comparison
instruction, but only 8 of them are actually valid in legacy-encoded mode.
The remaining 24 requires the use of VEX-encoded (v-prefixed) instructions
and can therefore be disregarded for this purpose.
---
libavutil/x86/x86inc.asm
The standard section for read-only data on Windows is .rdata. Nasm will
flag non-standard sections as executable by default which isn't ideal.
---
libavutil/x86/x86inc.asm | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 3b43dbc2e0..
On ELF platforms such symbols needs to be flagged as functions with the
correct visibility to please certain linkers in some scenarios.
---
libavutil/x86/x86inc.asm | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
Henrik Gramner (5):
x86inc: Enable AVX emulation for floating-point pseudo-instructions
x86inc: Use .rdata instead of .rodata on Windows
x86inc: Support creating global symbols from local labels
x86inc: Correctly set mmreg variables
x86inc: Drop cpuflags_slowctz
libavutil/x86/x86inc.asm
Hi!
Attached patch fixes a warning, I suspect it makes the code more correct.
Please comment, Carl Eugen
From 0460da037b91bbc4d0fbca3b756f5c7d345c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 18 Jan 2018 23:31:48 +0100
Subject: [PATCH] lavc/svq3: Do not write into memory define
On 1/18/2018 6:16 PM, James Almer wrote:
> On 1/18/2018 6:06 PM, Marton Balint wrote:
>> Blend function speedups on x86_64 Core i5 4460:
>>
>> ffmpeg -f lavfi -i allyuv -vf framerate=60:threads=1 -f null none
>>
>> C: 447548411 decicycles in Blend,2048 runs, 0 skips
>> SSSE3: 130020087
> +
> +
> +%if HAVE_AVX2_EXTERNAL
> +
> +INIT_YMM avx2
> +BLEND_FRAMES
> +
> +INIT_YMM avx2
>
Don't think it's necessary to repeat INIT_YMM avx2.
> +BLEND_FRAMES16
> +
> +%endif
> --
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http:
On 1/18/2018 6:06 PM, Marton Balint wrote:
> Blend function speedups on x86_64 Core i5 4460:
>
> ffmpeg -f lavfi -i allyuv -vf framerate=60:threads=1 -f null none
>
> C: 447548411 decicycles in Blend,2048 runs, 0 skips
> SSSE3: 130020087 decicycles in Blend,2048 runs, 0 skip
Blend function speedups on x86_64 Core i5 4460:
ffmpeg -f lavfi -i allyuv -vf framerate=60:threads=1 -f null none
C: 447548411 decicycles in Blend,2048 runs, 0 skips
SSSE3: 130020087 decicycles in Blend,2048 runs, 0 skips
AVX2: 128508221 decicycles in Blend,2048 runs,
On Thu, 18 Jan 2018, Carl Eugen Hoyos wrote:
2018-01-18 1:03 GMT+01:00 Marton Balint :
Blend function speedups on x86_64 Core i5 4460:
ffmpeg -f lavfi -i allyuv -vf framerate=60:threads=1 -f null none
C: 447548411 decicycles in Blend,2048 runs, 0 skips
SSSE3: 130020087 decicycle
Hi!
The probe score for swf files (with uncompressed headers) is currently
very high after testing a little more than 24bit, attached patch
reduces the score.
Please comment, Carl Eugen
From 561cb5cea0ead726c747edea7d1c3e8c768eac81 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Thu, 18 Ja
On 1/18/2018 3:37 PM, Thilo Borgmann wrote:
> From 0386c9e0a4c2ea1579378807ff5a7a04c508c50e Mon Sep 17 00:00:00 2001
> From: Thilo Borgmann
> Date: Wed, 17 Jan 2018 23:13:53 +0100
> Subject: [PATCH 2/3] Add codec wrapper for librv11
>
> ---
> MAINTAINERS | 1 +
> configure
2018-01-18 19:37 GMT+01:00 Thilo Borgmann :
Needs non-free (and therefore cannot be auto-detected).
And please link at compile-time unless there are no
visible symbols except the lookup function.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffm
2018-01-18 19:39 GMT+01:00 Thilo Borgmann :
> This time including the patch...
Why do you add a new demuxer?
Isn't it sufficient to add the new descriptor (with AV_RB32()) to the
existing probe function?
Please split this patch:
From a (very) quick look, I saw:
Demuxing MLTI, muxing aac, muxing R
Am 18.01.18 um 19:36 schrieb Thilo Borgmann:
> Realnetworks released Linux libraries for their encoder/decoder of RealVideo
> 11 (RV60) [1].
[1] http://www.rmhd.io
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo
This time including the patch...
From aaeaf7721ba5e9afd79ee13dbb9cc7c3226027b3 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Wed, 17 Jan 2018 23:09:03 +0100
Subject: [PATCH 1/3] Add muxing/demuxing of RMHD
---
fftools/ffmpeg.c | 28 +++-
fftools/ffmpeg_opt.c | 2 +-
libavfor
From 933e314a2571f0e57ec078b87dc4990a4fe213f1 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Wed, 17 Jan 2018 23:14:16 +0100
Subject: [PATCH 3/3] Add docs and Changelog
---
Changelog | 2 ++
doc/encoders.texi | 92 +++
doc/genera
From 0386c9e0a4c2ea1579378807ff5a7a04c508c50e Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Wed, 17 Jan 2018 23:13:53 +0100
Subject: [PATCH 2/3] Add codec wrapper for librv11
---
MAINTAINERS | 1 +
configure | 8 +
libavcodec/Makefile | 2 +
libavcodec/a
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi,
Realnetworks released Linux libraries for their encoder/decoder of RealVideo 11
(RV60) [1].
This is a joint approach to add a codec wrapper and suport muxing/demuxing of
the latest real format version (RMHD).
I'd especially appreciate feedback on the handling of the PTS/DTS which IMHO is
n
> On 18 Jan 2018, at 08:56, Tobias Rapp wrote:
>
> On 15.01.2018 13:48, Dmytro Humeniuk wrote:
>>> On 15 Jan 2018, at 09:14, Tobias Rapp wrote:
>>>
>>> On 13.01.2018 23:52, Дмитрий Гуменюк wrote:
Hi,
> On 13 Jan 2018, at 01:37, Дмитрий Гуменюк
> wrote:
>
> Hi
>
>>>
On 18/01/18 16:02, Carl Eugen Hoyos wrote:
> 2018-01-18 16:55 GMT+01:00 Mark Thompson :
>
>> Setting the termination option in the ffmpeg program or not shouldn't
>> make a difference to the behaviour inside the muxer
>
> How did you test this?
The signal is received by a write call deep inside
> On 18 Jan 2018, at 00:13, Moritz Barsnick wrote:
>
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -680,13 +680,13 @@ select RIAA.
>> @item cd
>> select Compact Disc (CD).
>> @item 50fm
>> -select 50??s (FM).
>> +select 50??s (FM).
>> @item 75fm
>> -select 75??s (FM).
>> +select 75??
On 18/01/18 15:58, Nicolas George wrote:
> Mark Thompson (2018-01-18):
>> Changing it to ignore the signal (set it to SIG_IGN) instead sounds
>> like a safer option?
>
> Yes, I think it would be somewhat safer. And it can be done without
> modification to FFmpeg.
To clarify: I was definitely prop
On Thu, 18 Jan 2018 16:30:22 +0100
Carl Eugen Hoyos wrote:
> 2018-01-18 16:27 GMT+01:00 Nicolas George :
> > Carl Eugen Hoyos (2018-01-18):
> >> Could you please tell us which cases get broken?
> >
> > I cannot.
>
> Ok.
>
> So we both agree that FFmpeg should get rid of
> Vincent as fast
The intention is to:
1. let API users know whether a HLS stream is live
2. let API users know about the safe seek range
This is supposed to avoid Bad things happening when seeking outside of
range.
There are lots of problems with this patch:
- the API consists of adding yet another set of obscure
2018-01-18 16:55 GMT+01:00 Mark Thompson :
> Setting the termination option in the ffmpeg program or not shouldn't
> make a difference to the behaviour inside the muxer
How did you test this?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg
Mark Thompson (2018-01-18):
> Changing it to ignore the signal (set it to SIG_IGN) instead sounds
> like a safer option?
Yes, I think it would be somewhat safer. And it can be done without
modification to FFmpeg.
What is missing, though, is better control on error conditions: when
muxing in one o
On 18/01/18 14:49, Dave Rice wrote:
> Thread bump.
>
>> On Jan 11, 2018, at 5:51 PM, Nicolas George wrote:
>>
>> Moritz Barsnick (2018-01-11):
>>> This patch doesn't change the handling of SIGTERM
>>
>> You should have read SIGPIPE, obviously.
>>
>>> Is SIGPIPE an interactive signal?
>>
>> Of cou
Carl Eugen Hoyos (2018-01-18):
> We have disagreed in the past about pkg-config,
> you don't want me to test FFmpeg on less common
> systems, fine.
This is untrue. I have offered you help to find a work-flow to test
FFmpeg on less common systems while playing nice with pkg-config, but
you never ac
On 1/18/18, Nicolas George wrote:
> Carl Eugen Hoyos (2018-01-18):
>> Could you please tell us which cases get broken?
>
> I cannot. But these are Unix signals: there are.
Just ignore Nicolas, he doesn't know any better.
___
ffmpeg-devel mailing list
ff
2018-01-18 16:27 GMT+01:00 Nicolas George :
> Carl Eugen Hoyos (2018-01-18):
>> Could you please tell us which cases get broken?
>
> I cannot.
Ok.
So we both agree that FFmpeg should get rid of
Vincent as fast as possible.
We have disagreed in the past about pkg-config,
you don't want me to test
Carl Eugen Hoyos (2018-01-18):
> Could you please tell us which cases get broken?
I cannot. But these are Unix signals: there are.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@f
2018-01-18 16:19 GMT+01:00 Nicolas George :
> Carl Eugen Hoyos (2018-01-18):
>> The OP has created a very easy to reproduce case where
>> FFmpeg unexpectedly doesn't close its output files, and
>> a patch that fixes this (broken) behaviour.
>
> And the OP neglected to check that the patch does not
Carl Eugen Hoyos (2018-01-18):
> The OP has created a very easy to reproduce case where
> FFmpeg unexpectedly doesn't close its output files, and
> a patch that fixes this (broken) behaviour.
And the OP neglected to check that the patch does not break other cases.
> Why do you believe there is an
2018-01-18 16:05 GMT+01:00 Nicolas George :
> Carl Eugen Hoyos (2018-01-18):
>> Would you like to elaborate?
>
> Of course, provided somebody is interested.
>
> Issuing the following command:
>
> trap "" SIGPIPE
>
> will ignore SIGPIPE in the shell and all subsequent programs started
> from
Carl Eugen Hoyos (2018-01-18):
> Would you like to elaborate?
Of course, provided somebody is interested.
Issuing the following command:
trap "" SIGPIPE
will ignore SIGPIPE in the shell and all subsequent programs started
from it. It will achieve exactly the result of this patch, in a m
2018-01-18 15:54 GMT+01:00 Nicolas George :
> The same result can be achieved with the shell
Would you like to elaborate?
> without the corresponding drawbacks.
Maybe you could explain the drawbacks?
Exiting FFmpeg without closing output files seems like a
major drawback to me, independently of
On Thu, 18 Jan 2018 15:54:46 +0100
Nicolas George wrote:
> Dave Rice (2018-01-18):
> > Not sure if I understand well the disadvantage of this patch.
>
> When dealing with Unix signals, "not sure if I understand" means
> "don't".
Well, he's asking you why.
If you refuse to explain, I don't th
Dave Rice (2018-01-18):
> Not sure if I understand well the disadvantage of this patch.
When dealing with Unix signals, "not sure if I understand" means
"don't".
The same result can be achieved with the shell, without the
corresponding drawbacks.
Regards,
--
Nicolas George
signature.asc
De
Thread bump.
> On Jan 11, 2018, at 5:51 PM, Nicolas George wrote:
>
> Moritz Barsnick (2018-01-11):
>> This patch doesn't change the handling of SIGTERM
>
> You should have read SIGPIPE, obviously.
>
>> Is SIGPIPE an interactive signal?
>
> Of course not.
>
>>
On 1/18/18 6:53 PM, Brendan McGrath wrote:
> I tried your suggestion and it still didn't work. So I took another look at
> the spec and it looks like what was originally there was correct (as seen in
> the below example):
> https://tools.ietf.org/html/rfc8216#section-8.6
>
> In that example - e
I tried your suggestion and it still didn't work. So I took another look
at the spec and it looks like what was originally there was correct (as
seen in the below example):
https://tools.ietf.org/html/rfc8216#section-8.6
In that example - english-audio.m3u8 appears in both a MEDIA and
STREAM-I
> if (s->bitdepth == 8) {
> s->blend_factor_max = 1 << BLEND_FACTOR_DEPTH8;
> -s->blend = blend_frames_c;
> +if (ARCH_X86 && EXTERNAL_AVX2(cpu_flags))
> +s->blend = ff_blend_frames_avx2;
>
I think it's :
if (EXTERNAL_AVX2_FAST(cpu_flags)
> +else
Am 18.01.2018 um 03:38 schrieb Gonzalo Martinez:
Hi I have a client written in C++ that use a Hardware Encoder called Cedar
and Stream the Video and Audio to my RTMPS server but now I need to change
that to Stream locally to a ffserver.
The problem that I have when modify the URL from rtmps to
h
On 1/18/18 2:39 PM, Brendan McGrath wrote:
> When using an 'agroup' within var_stream_map - the audio stream is
> being added to the master playlist file as both an audio rendition
> and an individual stream (with an AUDIO reference back to itself).
>
> This patch ensures an audio rendition does
On Thu, Jan 18, 2018 at 6:14 AM, James Almer wrote:
> On 1/18/2018 2:03 AM, Zhong Li wrote:
>> coded_width/height may be different from width/height sometimes
>
>> (e.g, crop or lowres cases).
>
> Which is why it's not a field that belongs to AVCodecParameters.
>
> Codec level cropping has nothing
If no representation bandwidth value is set, the url value returned
by get_content_url is corrupt (as the memory has been freed).
This change ensures the url string is not freed unless it is about
to be reused
Signed-off-by: Brendan McGrath
---
libavformat/dashdec.c | 4 +++-
1 file changed, 3
> On 18 Jan 2018, at 17:09, Brendan McGrath wrote:
>
> When using an 'agroup' within var_stream_map - the audio stream is
> being added to the master playlist file as both an audio rendition
> and an individual stream (with an AUDIO reference back to itself).
https://patchwork.ffmpeg.org/patch/
2018-01-18 6:03 GMT+01:00 Zhong Li :
> Currently a hacky way is used for some specific codecs such as
> H264/VP6F/DXV
> (and "lowres" case is broken now).
How can I reproduce this?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http:/
2018-01-18 1:03 GMT+01:00 Marton Balint :
> Blend function speedups on x86_64 Core i5 4460:
>
> ffmpeg -f lavfi -i allyuv -vf framerate=60:threads=1 -f null none
>
> C: 447548411 decicycles in Blend,2048 runs, 0 skips
> SSSE3: 130020087 decicycles in Blend,2048 runs, 0 skips
>
When using an 'agroup' within var_stream_map - the audio stream is
being added to the master playlist file as both an audio rendition
and an individual stream (with an AUDIO reference back to itself).
This patch ensures an audio rendition does not also appear within
the stream info list.
What fol
On 01/09/2018 11:56 PM, Jorge Ramirez-Ortiz wrote:
From: Mark Thompson
Refcount all of the context information. This also fixes a potential
segmentation fault when accessing freed memory (buffer returned after
the codec has been closed).
just a follow up on the patchset (patches 1 to 3)
any
79 matches
Mail list logo
