---
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
+++ b/doc/demuxers.te
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
+++ b/doc/demuxers.te
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
--- a/do
---
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 :
> 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
http://ffmpeg.org
2017-11-26 12:04 GMT+01:00 Steven Liu :
> 2017-11-26 18:46 GMT+08:00 Rainer Hochecker :
>> fixed mem leak poined out by Steven
> Hi Rainer,
>
> I'm not sure that is memleak, but looks like memleak when reading
> the code, i see the code always in hls.c before this pat
>> +/*
>> + * 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 wit
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
--- a/do
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 to
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 v
---
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
+++ b/doc/demuxers.tex
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
Alternative patch. Revert the original code because it does more harm than any
good.
Signed-off-by: Rainer Hochecker
---
libavformat/matroskadec.c | 12
1 file changed, 12 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
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
ffmpeg-d
From: Rainer Hochecker
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
---
libavformat/matroskadec.c | 14 +-
1
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
--- a/libavforma
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&id=22
check spec 7.4.2.4.4 Order of NAL units and coded pictures
and their association to access units
>
> Sorry
---
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 i
fix splitting extradata from ts
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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
>From 85ea58a3129b1766d44bf1425c6656d7a4f5624c Mon Sep 17 00:00:00 2001
From: Rainer Hochecker
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(+), 2 deleti
Carl Eugen Hoyos 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
ffmp
Hendrik Leppkes 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
Rainer
Carl Eugen Hoyos 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 scenario
Michael Niedermayer 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.
___
Michael Niedermayer gmx.at> writes:
>
> have you tried this with both annex b and .mp4 style h264 ?
>
> [...]
I have updated the patch and tested both styles:
https://github.com/FFmpeg/FFmpeg/pull/129
___
ffmpeg-devel mailing list
ffmpeg-devel@ffm
Michael Niedermayer 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 we add a
Carl Eugen Hoyos 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
VDA
Michael Niedermayer gmx.at> writes:
>
> have you tried this with both annex b and .mp4 style h264 ?
>
> [...]
could you please point me the samples you want me to test?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailm
Michael Niedermayer 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 idea wh
Hendrik Leppkes gmail.com> writes:
>
> On Wed, Apr 1, 2015 at 12:40 PM, Rainer Hochecker
> 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
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
http://ffmpeg.org/mailman/listinfo/ffmp
---
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:
I think is useless to call get_format in this case, right?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
---
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 ff_h264_decode_slice_header(H264Co
Rainer Hochecker 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;
> }
>
---
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
---
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, Long
Hendrik Leppkes 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 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 DrMemory?
I don't thi
Reimar Döffinger 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.
__
Reimar Döffinger 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_type&FF_THREAD_FRAME)
return 0;
av_assert0(!p->main_threa
Reimar Döffinger 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 single SPS c
Rainer Hochecker 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
&g
---
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++ = sps
Michael Niedermayer 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.
__
wm4 googlemail.com> writes:
>
> > Now we get multiple packets with equal pts. This requires an additional
> > change for us.
> > http://paste.ubuntu.com/8426767/
>
> Why? I don't think subtitle packets with same PTS were impossible
> before.
Good question. I wish the author of this code was ar
Clément Bœsch 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 go
Rainer Hochecker 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?
>
Clément Bœsch pkh.me> writes:
>
> Supporting that properly is not that much work; there will just be a
> somewhat nasty convert from this layout to the internal one (when that
> last one will be sane).
>
> Maybe that's rare indeed, but then someone will suddenly find a .nut, or
> maybe try to p
Clément Bœsch pkh.me> writes:
>
> On Mon, Sep 22, 2014 at 03:12:02PM +0000, 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 m
Clément Bœsch 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; doc/API
Clément Bœsch 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
60 matches
Mail list logo
