Previously, the bug was that if -1 < start_time < 0, the reported
"start" time would lose the negative-sign.
---
libavformat/dump.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 3d117f6..a84dcc6 100644
--- a/libavformat/du
Second patchset addresses feedback after discussion with Martin. It is now
accounting for the fact that avg_frame_rate may not always be set.
On Wed, Nov 18, 2015 at 1:13 AM, Bryan Huh wrote:
> DASH manifest should have framerate specified as an attribute in the
> AdaptationSet eleme
DASH manifest should have framerate specified as an attribute in the
AdaptationSet element and Representation elements. Though ISO/IEC
23009-1:2014 doesn't seem to define frameRate as a required attribute,
it is at least optional, and DASH-IF IOP 3.0 seems to require it. See
section 3.2.4 of http:/
DASH manifest should have framerate specified as an attribute in the
AdaptationSet element and Representation elements. Though ISO/IEC
23009-1:2014 doesn't seem to define frameRate as a required attribute,
it is at least optional, and DASH-IF IOP 3.0 seems to require it. See
section 3.2.4 of http:/
No functional changes in this commit, mostly adding comments for
improved readability. Also minor re-arrangements of variables.
---
libavformat/avio.h| 47 +++
libavformat/aviobuf.c | 16 +---
2 files changed, 56 insertions(+), 7 dele
Small refactor of fps code for improved readability. In particular
the "cor" variable was unnecessary and misleading because it would
always be set to -delta0.
---
ffmpeg.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 3341777..560c5a0
---
ffmpeg.c | 16
ffmpeg.h |2 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index 3341777..a56ec87 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -984,11 +984,11 @@ static void do_video_out(AVFormatContext *s,
Michael, can you merge this?
On Wed, Nov 11, 2015 at 6:47 PM, Zhang Rui wrote:
> 2015-11-12 9:45 GMT+08:00 Bryan Huh :
> >
> >
> > On Wed, Nov 11, 2015 at 3:06 AM, Zhang Rui wrote:
> >>
> >> 2015-11-11 18:00 GMT+08:00 Bryan Huh :
> >> >
When async issues its inner seek via ffurl_seek, it treats failures as
EOF being reached. This is not consistent with the behavior of other
protocols (e.g. http, cache) which continue to tolerate reads after
failed seeks, and therefore does not interact correctly with them.
A common pattern where
Chapter-indexing can be expensive since chapters may be interspersed
throughout the entire file and may require many seeks - especially
costly when consuming a video over a remote protocol like http.
Furthermore it is often unnecessary, especially when only trying to get
video info (e.g. via ffprob
Chapter-indexing can be expensive since chapters may be interspersed
throughout the entire file and may require many seeks - especially
costly when consuming a video over a remote protocol like http.
Furthermore it is often unnecessary, especially when only trying to get
video info (e.g. via ffprob
cache protocol indexes its cache using AVTreeNodes which require a cmp
function for inserting and searching new cache-entries. This cmp
function expects a 32-bit int return value (negative, zero, or positive)
but the cache cmp function returns an int64_t which can overflow the
int, giving negative
cache protocol indexes its cache using AVTreeNodes which require a cmp
function for inserting and searching new cache-entries. This cmp
function expects a 32-bit int return value (negative, zero, or positive)
but the cache cmp function returns an int64_t which can overflow the
int, giving negative
ael Niedermayer
wrote:
> On Sun, Nov 01, 2015 at 10:56:45PM -0800, Bryan Huh wrote:
> > Fixes an issue where an int64_t ffurl_seek return-value was being stored
> > in a generic int "r" variable, leading to integer overflow when seeking
> > into a large file (>2
Fixes an issue where an int64_t ffurl_seek return-value was being stored
in an int (32-bit) "r" variable, leading to integer overflow when seeking
into a large file (>2GB), and ultimately a "Failed to perform internal
seek" error mesage.
To test, try running `ffprobe 'cache:http://'` on a file tha
Fixes an issue where an int64_t ffurl_seek return-value was being stored
in a generic int "r" variable, leading to integer overflow when seeking
into a large file (>2GB), and ultimately a "Failed to perform internal
seek" error mesage. The "r" variable was used both for storing the
result of any se
Yes. Even with his change to the if-statement, I am proposing the same
change: to remove the if-statement.
It would be nice to get this sanity-checked by Martin though.
On Wed, Oct 29, 2014 at 7:24 PM, Michael Niedermayer
wrote:
> On Tue, Oct 28, 2014 at 11:05:54PM +0000, Bryan Huh wr
The MOV_TRUN_DATA_OFFSET flag was always getting set, so data_offset is
being expected and read. The offset was computed correctly anyway during
fragment-flush. Alternatively, I could have selectively set the flag
only when base-data-offset is defined, but certain players (Chrome)
seem to fail when
Sorry I am not posting to the same thread directly, I joined the list after
this discussion finished a few weeks ago.
I was reading Yusuke's explanation (pasted below) regarding the
relationship between PTS, CTS, and DTS in the context of fragments, and
there are some parts that I don't understand
19 matches
Mail list logo
