---
libavformat/hls.c | 208 +++---
1 file changed, 119 insertions(+), 89 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index ab6ff187a6..3c2c720abe 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -314,6 +314,8 @@ static
---
doc/demuxers.texi | 6
libavformat/hls.c | 106 ++
2 files changed, 98 insertions(+), 14 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 73dc0feec1..33643f966a 100644
--- a/doc/demuxers.texi
+++
v4: fixed the memleak properly
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
---
doc/demuxers.texi | 6
libavformat/hls.c | 106 ++
2 files changed, 98 insertions(+), 14 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 73dc0feec1..33643f966a 100644
--- a/doc/demuxers.texi
+++
fixed mem leak poined out by Steven
---
doc/demuxers.texi | 5 +
libavformat/hls.c | 304 --
2 files changed, 209 insertions(+), 100 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 73dc0feec1..634b122e10 100644
---
---
libavformat/hls.c | 209 +++---
1 file changed, 120 insertions(+), 89 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index ab6ff187a6..3f83707c1f 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -314,6 +314,8 @@ static
I tried to implement what you requested
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
2017-11-27 22:53 GMT+01:00 Anssi Hannula <anssi.hann...@iki.fi>:
> Hi,
>
> Rainer Hochecker kirjoitti 2017-11-26 12:46:
>>
>> fixed mem leak poined out by Steven
>>
>> ---
>> doc/demuxers.texi | 5 +
>> libavformat/hls.c | 304
>> +++
Variants are presented as programs and can be loaded later by
setting discard flags on the program. Currently Kodi chooses the
program that best matches the desired bit rate.
Rainer
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
2017-11-26 12:04 GMT+01:00 Steven Liu <lingjiujia...@gmail.com>:
> 2017-11-26 18:46 GMT+08:00 Rainer Hochecker <fernetme...@online.de>:
>> fixed mem leak poined out by Steven
> Hi Rainer,
>
> I'm not sure that is memleak, but looks like memleak when reading
>
>> +/*
>> + * If this is a live stream and this playlist looks like it is one
>> segment
>> + * behind, try to sync it up so that every substream starts at the same
>> + * time position (so e.g. avformat_find_stream_info() will see packets
>> from
>> + * all active streams
fixed mem leak poined out by Steven
---
doc/demuxers.texi | 5 +
libavformat/hls.c | 304 --
2 files changed, 209 insertions(+), 100 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 73dc0feec1..634b122e10 100644
---
fate runs now without error, sorry for that
---
doc/demuxers.texi | 5 +
libavformat/hls.c | 302 --
2 files changed, 207 insertions(+), 100 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 73dc0feec1..634b122e10 100644
Shouldn't this be:
0 (or -1) for all streams (default), n>0 (or > -1) for the nth stream.
I guess it is at least possible that the user knows in advance which
streams the source will offer.
No?
Carl Eugen
It is very unlikely that this is known in advance. Also there is no reason
why you want
Currently all variants/playlists get parsed on open. For a master playlist
with many different bitrates this can take several seconds. With the new
option set to 0 only the first variant of a master playlist is opened. Others
can be activated later by setting discard option on a program. Default
---
doc/demuxers.texi | 5 +
libavformat/hls.c | 299 --
2 files changed, 204 insertions(+), 100 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 73dc0feec1..634b122e10 100644
--- a/doc/demuxers.texi
+++
absolutely. thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
We already included this patch in Kodi v17. Dropping this incomplete
feature is much better than living with the downsides. Having files on a
network share is a common use case and in most cases there is no index
anyway: start video and seek forward.
___
From: Rainer Hochecker <fernetme...@online.de>
Alternative patch. Revert the original code because it does more harm than any
good.
Signed-off-by: Rainer Hochecker <fernetme...@online.de>
---
libavformat/matroskadec.c | 12
1 file changed, 12 deletions(-)
I was tempted to submit a patch with this feature deleted. Unfortunately I
was not able to find the original reason
why this was implemented. I am sure there was a good reason and this reason
may still be a good one.
___
ffmpeg-devel mailing list
From: Rainer Hochecker <fernetme...@online.de>
Allow players to reduce the time read_seek sets the file pos before desired
position.
Hard coded 30 seconds is a lot and takes several seconds when the source is on
a network share.
Signed-off-by: Rainer Hochecker <fernetme...@
I got a mpegts file with hevc that fails estimating duration. Increasing number
of
retries fixes the issue.
Rainer
---
libavformat/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 251b2c6..f8ddaf7 100644
---
---
libavcodec/hevc_parser.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index f970de5..35cace5 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -410,19 +410,30 @@ static
fix splitting extradata from ts
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Carl Eugen Hoyos ag.or.at> writes:
> Do you have a sample for us?
> Or an explanation on how to reproduce.
I tested with this sample:
http://www.demo-uhd3d.com/fiche.php?cat=uhd=22
check spec 7.4.2.4.4 Order of NAL units and coded pictures
and their association to access units
>
> Sorry if
Carl Eugen Hoyos cehoyos at ag.or.at writes:
That sounds impossible since the patch was pushed as
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=f7ed997a
Carl Eugen
Why exactly is that impossible?
It crashes in ff_pack_8ch_float_to_int32_a_sse2 on Windows.
Same code, same
Michael Niedermayer michaelni at gmx.at writes:
can someone who has ICL/MSVC setup test this please
failing that, lets apply the patch
[...]
Kodi crashes on Windows when doing 8 channel conversion. This seems to be the
source of the problem.
Hendrik Leppkes h.leppkes at gmail.com writes:
Kodi's build script suggests that FFmpeg is build with gcc - this
crash and fix only ever applied to MSVC/ICL builds.
It starts crashing with this commit:
https://github.com/FFmpeg/FFmpeg/commit/37b35feb64e4e0382cd5e4502dbf0f7ff9aa0
b5f
Carl Eugen Hoyos cehoyos at ag.or.at writes:
So does adding attribute_align_arg to swr_convert_frame()
(and friends?) fix the issue?
Carl Eugen
I added it to swr_convert and it does fix the issue here.
Rainer
___
ffmpeg-devel mailing list
From 85ea58a3129b1766d44bf1425c6656d7a4f5624c Mon Sep 17 00:00:00 2001
From: Rainer Hochecker fernetme...@online.de
Date: Wed, 13 May 2015 18:21:38 +0200
Subject: [PATCH] swr: fix alignment issue caused by 8ch sse functions
---
libswresample/swresample.c | 5 +++--
1 file changed, 3 insertions
[PATCH] swr: fix alignment issue caused by 8ch sse functions
Fix crash when doing 8 ch conversion from apps compiled with MSVS
Thanks to Ronald for giving this hint:
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-May/173049.html
___
ffmpeg-devel mailing
Michael Niedermayer michaelni at gmx.at writes:
could it be that this should be using nal_length_size ?
[...]
I tried nal_length_size and it does not fix the issue. Instead it breaks some
other files. Seems silly VDA does only support 4 byte avcC flavour. The
patch brakes annexb. Should
vda wants the entire buffer with all info. it has no other means to deliver
picture parameters.
according to documentation start_frame can pass the entire buffer
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
---
libavcodec/h264.c | 2 +-
libavcodec/vda_h264.c | 25 -
2 files changed, 9 insertions(+), 18 deletions(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index e8d5120..60f8aa1 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -1589,7 +1589,7 @@ again:
Hendrik Leppkes h.leppkes at gmail.com writes:
On Wed, Apr 1, 2015 at 12:40 PM, Rainer Hochecker fernetmenta at
online.de
wrote:
vda wants the entire buffer with all info. it has no other means to deliver
picture parameters.
according to documentation start_frame can pass the entire
Michael Niedermayer michaelni at gmx.at writes:
could it be that this should be using nal_length_size ?
[...]
I am quite sure that the fix is correct. Our VDA decoder has always been
working like this.
Further I could not find any info on developer@apple that the current
code is valid. No
Carl Eugen Hoyos cehoyos at ag.or.at writes:
(guessing, needs --enable-libx264)
$ ffmpeg -f lavfi -i testsrc -pix_fmt yuv420p -t 10 out.mp4
$ ffmpeg -f lavfi -i testsrc -pix_fmt yuv420p -t 10 out.h264
Carl Eugen
my vda decoder does not even open with those generated samples. it fails in
---
libavcodec/h264_slice.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 80d27e5..9477650 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1417,7 +1417,8 @@ int
---
libavcodec/hevc.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index fdbaa28..b52e778 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -280,7 +280,7 @@ static int decode_lt_rps(HEVCContext *s,
---
libavcodec/hevc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index b52e778..998d58e 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -2605,7 +2605,8 @@ static int hevc_frame_start(HEVCContext *s)
if (ret 0)
The first patch avoids unnecessary calls to get_format. We open a new
hw decoder on every call to get_format. hevc seems to do something
different than h264. deleting any provious allocated hw decoders
at the application level results in heap corruption. There may be some other
issue left but the
Rainer Hochecker fernetmenta at online.de writes:
hevc_decode_flush(AVCodecContext *avctx)
{
HEVCContext *s = avctx-priv_data;
ff_hevc_flush_dpb(s);
+hevc_decode_free(avctx);
+s-context_initialized = 0;
s-max_ra = INT_MAX;
}
this is a left over from debugging
Hendrik Leppkes h.leppkes at gmail.com writes:
Just making the ff_thread_finish_setup call in hevc_frame_start
conditional on !hwaccel should do what the other patches did.
My code isn't setup to use this path, so someone that does should test
it and send it.
- Hendrik
Reimar Döffinger Reimar.Doeffinger at gmx.de writes:
Any reason to believe this patch causes it?
Because I can't see how it would.
Maybe it's just a bug with DXVA and multithreading in the HEVC code?
Can you provide some more information like a stacktrace, possibly using a
tool like
Reimar Döffinger Reimar.Doeffinger at gmx.de writes:
I tried this patch with Kodi but did not get very far.
int ff_thread_can_start_frame(AVCodecContext *avctx)
{
PerThreadContext *p = avctx-internal-thread_ctx;
if (avctx-active_thread_typeFF_THREAD_FRAME)
return 0;
Reimar Döffinger Reimar.Doeffinger at gmx.de writes:
I have tested this with Kodi. Works with sw decoding. With DXVA it crashes,
looks like heap corruption or the like.
setting thread_safe_callbacks = 1 cures the issue but I get some green
frames at start of playback.
---
libavcodec/hevc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index fdbaa28..7c7f920 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -307,7 +307,7 @@ static int set_sps(HEVCContext *s, const HEVCSPS *sps)
*fmt++ =
Rainer Hochecker fernetmenta at online.de writes:
---
libavcodec/hevc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index fdbaa28..7c7f920 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
at at -307,7 +307,7
Reimar Döffinger Reimar.Doeffinger at gmx.de writes:
I sent an alternative patch pthread: Fix ff_thread_get_format issues
when called outside frame decode.
right, I didn't see you patch not the other code path.
However there are additional bugs like update_context calling this and thus
a
Michael Niedermayer michaelni at gmx.at writes:
ive already applied wm4s patch yesterday, so the next ffmpeg release
(2.6) should contain avformat_flush()
if further changes are needed please tell me
[...]
Thanks for notification. I will switch Kodi to 2.6 this weekend.
Rainer Hochecker fernetmenta at online.de writes:
It's me again. I got a matroshka sample for which I get ASS subs without
timestamps (NOPTS_VALUE):
https://mega.co.nz/#!dEcRwZ4C!cg_6xlpPlhRN0trGEDH1C-ErJ7gXIe6CUezaEokBSV8 .
Am I doing anything wrong?
Rainer
This file has
Clément Bœsch u at pkh.me writes:
I'm seeing timestamps set in the packets with:
ffprobe -show_packets -show_data -select_streams s:0
~/samples/Test_File-01.mkv
Same with other streams
Thanks, making use of ffprobe was a good idea. Now I see the difference.
With version 2.4 we got
Clément Bœsch u at pkh.me writes:
+1
Applied
We at XBMC got the first complaints about broken subtitles. Why was this
removed?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Clément Bœsch u at pkh.me writes:
Hi,
We just made the ASS packets from the Matroska output them verbatim, and
not hacked with timestamps included into the timestamps.
The packets are now typically broadcastable to libass.
Note that this change has been documented since 2.0;
Clément Bœsch u at pkh.me writes:
On Mon, Sep 22, 2014 at 03:12:02PM +, Rainer Hochecker wrote:
[...]
Hi,
Thank you very much for this explanation and sorry for not having read
release notes properly. subs are not my territory but the maintainer is busy
with real life so I
55 matches
Mail list logo
