Okay the following patch should fix this issue. Chromium/reviewable version
here https://chromium-review.googlesource.com/c/572585/
- dale
On Fri, Jul 14, 2017 at 6:31 PM, Dale Curtis
wrote:
> On Fri, Jul 14, 2017 at 5:38 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>>
>> I dont
On Fri, Jul 14, 2017 at 5:38 PM, Michael Niedermayer wrote:
>
> I dont think CTTS is the only affected atom.
>
>
Thanks for the response. Yes, I think that's likely true. The ctts one is
just likely the most important since it controls timestamp ordering.
> what you describe sounds like an opti
Hi
On Fri, Jul 14, 2017 at 02:52:23PM -0700, Dale Curtis wrote:
> After looking at this some more. I don't think the way ctts entries are
> stored is correct unless you assume all ctts entries are known prior to any
> seeks taking place. Either through reading all trun boxes ahead of time or
> con
After looking at this some more. I don't think the way ctts entries are
stored is correct unless you assume all ctts entries are known prior to any
seeks taking place. Either through reading all trun boxes ahead of time or
content having a ctts atom.
The current code is broken in the presence of s
Hmm, finally got around to looking into this again and this still isn't
fixed. Just seeking a few times in ffplay can trigger this issue with the
clip linked in my original message:
http://storage.googleapis.com/dalecurtis-shared/buck480p30_na.mp4
./ffplay -v debug -drp 1 ~/Downloads/buck480p30_n
This issue is fixed by this patch, but I'm unsure of possible implications on
other files. It passes FATE, at least.
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 149e3b4..c5e0a1e 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3609,7 +3609,7 @@ static int mov_read_trun(MOVC
Michael, I wanted to check if you have you looked into this playback issue,
or were planning to?
- Dan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Fri, Jan 15, 2016 at 10:24:43PM +, Dan Sanders wrote:
> Michael, I wanted to check if you have you looked into this playback issue,
> or were planning to?
i didnt look into it, i had thought rodger would look into it as it
was his patch ...
rodger, did you look into this ?
[...]
--
Micha
I took a look at the structure of this file, and the encoding appears to be
correct. The frame order in the moof boxes matches the H.264 stream, and
the durations of the moof boxes match with the sidx.
Some notes to help with analysis: There are no per-frame durations
specified, every frame is exa
This patch seems to be causing some issues with some h264 video-only
content. Attempting to play the following in ffplay with "-v debug -drp 1"
(disables pts/dts fixups and purely uses pts) will cause jerky playback
after seeking around a few times due to dropped out of order frames. These
are show
On Tue, Oct 06, 2015 at 03:50:23AM -0500, Rodger Combs wrote:
> Fixes trac #3842
> ---
> libavformat/isom.h | 2 +
> libavformat/mov.c | 245
> -
> 2 files changed, 208 insertions(+), 39 deletions(-)
i think this should be applied unless som
Fixes trac #3842
---
libavformat/isom.h | 2 +
libavformat/mov.c | 245 -
2 files changed, 208 insertions(+), 39 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index aee9d6e..6e921c0 100644
--- a/libavformat/isom.h
+++ b/li
2015-10-04 1:57 GMT+09:00 Rodger Combs :
> Fixes trac #3842
> ---
> libavformat/isom.h | 2 +
> libavformat/mov.c | 250
> -
> 2 files changed, 213 insertions(+), 39 deletions(-)
>
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> inde
On Sat, 3 Oct 2015 11:57:03 -0500
Rodger Combs wrote:
> Fixes trac #3842
> ---
> libavformat/isom.h | 2 +
> libavformat/mov.c | 250
> -
> 2 files changed, 213 insertions(+), 39 deletions(-)
>
> diff --git a/libavformat/isom.h b/libavfor
Fixes trac #3842
---
libavformat/isom.h | 2 +
libavformat/mov.c | 250 -
2 files changed, 213 insertions(+), 39 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index aee9d6e..6e921c0 100644
--- a/libavformat/isom.h
+++ b/li
Fixes trac #3842
---
libavformat/isom.h | 1 +
libavformat/mov.c | 192 +
2 files changed, 179 insertions(+), 14 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index aee9d6e..8f22ea5 100644
--- a/libavformat/isom.h
+++ b/li
The logic in mov_seek_fragment for matching track_ids to AVStream ids is
almost certainly wrong, and should be corrected (by someone who knows more
about the relevant structures) before this is merged.
Fixes trac #3842
---
libavformat/isom.h | 1 +
libavformat/mov.c | 182 +
On Wed, Sep 09, 2015 at 10:01:32AM -0500, Rodger Combs wrote:
> The logic in mov_seek_fragment for matching track_ids to AVStream ids is
> almost certainly wrong, and should be corrected (by someone who knows more
> about the relevant structures) before this is merged.
>
> Fixes trac #3842
> ---
>
The logic in mov_seek_fragment for matching track_ids to AVStream ids is
almost certainly wrong, and should be corrected (by someone who knows more
about the relevant structures) before this is merged.
Fixes trac #3842
---
libavformat/isom.h | 1 +
libavformat/mov.c | 181 +
On Mon, Jul 20, 2015 at 03:04:55PM -0500, Rodger Combs wrote:
> The logic in mov_seek_fragment for matching track_ids to AVStream ids is
> almost certainly wrong, and should be corrected (by someone who knows more
> about the relevant structures) before this is merged.
>
> Fixes trac #3842
> ---
>
The logic in mov_seek_fragment for matching track_ids to AVStream ids is
almost certainly wrong, and should be corrected (by someone who knows more
about the relevant structures) before this is merged.
Fixes trac #3842
---
libavformat/isom.h | 1 +
libavformat/mov.c | 181 +
21 matches
Mail list logo
