[FFmpeg-devel] [PATCH 1/1] fix - increment index_entry_pos after log statement so that logs for index entries derived from trun atom use correct index

2018-09-21 Thread Nick Ryan
Signed-off-by: Nick Ryan --- libavformat/mov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index ec57a05803..540e5ca057 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -4856,11 +4856,11 @@ static int mov_read_trun(MOVContext

[FFmpeg-devel] [PATCH 0/1] Minor fix to prevent confusing logs when demuxing fragmented mp4

2018-09-21 Thread Nick Ryan
Minor fix to prevent confusing logs when demuxing fragmented mp4 Nick Ryan (1): fix - increment index_entry_pos after log statement so that logs for index entries derived from trun atom use correct index libavformat/mov.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.17.1

[FFmpeg-devel] [PATCH 0/1] mov.c: improvement to fMP4 bitrate estimation

2018-09-26 Thread Nick Ryan
0.023220, bitrate: 59 kb/s Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 4 kb/s (default) Metadata: creation_time : 2018-08-30T11:28:56.00Z handler_name: SoundHandler Nick Ryan (1): possible fix to correct (improve) bitrate esti

[FFmpeg-devel] [PATCH 0/1] mov.c: improvement to fMP4 bitrate estimation

2018-09-26 Thread Nick Ryan
Current code estimates bitrate by taking size of a single fragment and dividing by the total duration. This patch changes calculation to be based on duration used for framerate estimation. Nick Ryan (1): possible fix to correct (improve) bitrate estimation for streams in fragmented MP4

[FFmpeg-devel] [PATCH 1/1] possible fix to correct (improve) bitrate estimation for streams in fragmented MP4 when calculation is based on trex_data

2018-09-26 Thread Nick Ryan
Signed-off-by: Nick Ryan --- libavformat/mov.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 540e5ca057..67015a72a1 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -7459,14 +7459,14 @@ static int mov_read_header

[FFmpeg-devel] [PATCH 1/1] Trying to fix trac ticket #7359

2018-09-26 Thread Nick Ryan
Signed-off-by: Nick Ryan --- libavformat/mov.c | 19 --- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 67015a72a1..587513e06e 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -7605,15 +7605,15 @@ static int

[FFmpeg-devel] [PATCH 0/1] Trying to fix trac ticket #7359

2018-09-26 Thread Nick Ryan
ll(s->pb) != ts->last_pos) { int i; av_log(ts->stream, AV_LOG_TRACE, "Skipping after seek\n"); /* seek detected, flush pes buffer */ I have basically tried to do the same ‘reset’ logic within mov.c mov_read_packet() and force a search for the next mov ro

[FFmpeg-devel] Possible fix for trac ticket #7359

2018-10-24 Thread Nick Ryan
This is my 2nd attempt with an improved fix. With reference to: https://trac.ffmpeg.org/ticket/7359 I believe another way this issue manifests itself is using ffplay and trying to seek forward 10 seconds with the right arrow key: playback freezes. I have dug into this and developed a solutio

[FFmpeg-devel] [PATCH] fix trac ticket #7359

2018-10-24 Thread Nick Ryan
Signed-off-by: Nick Ryan --- libavformat/hls.c | 6 -- libavformat/mov.c | 36 +--- 2 files changed, 37 insertions(+), 5 deletions(-) diff --git a/libavformat/hls.c b/libavformat/hls.c index 8ad08baaed..99373d0f45 100644 --- a/libavformat/hls.c +++ b