On Wed, 10 Sep 2014, Raento Mika wrote:
On 10/09/14 00:43, "Martin Storsjö" <[email protected]> wrote:
On Sat, 6 Sep 2014, Mika Raento wrote:
The input file may not be contiguous in time, this produces the right
manifest to keep video and audio in sync.
---
tools/ismindex.c | 76
+++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 75 insertions(+), 1 deletion(-)
Ok, so I finally got to crafting a file that triggers this case, and
reading up on what my code actually does, so now I see better what you
think could benefit from sharing with libavformat/smoothstreamingenc.c.
A few further questions though, just to evaluate solutions/workarounds
better...
Great comments.
Which of all these cases did you actually encounter in practice, and
which
ones of them are only added for completeness sake? E.g. I can see how
other tools easily could write an ismv file where the first fragment
starts at a time different than zero. But did you run into files with
real
discontinuities/missing fragments (e.g. frag N time + duration < frag N+1
time) as well? E.g. is it worth a bigger effort to handle such files
properly, or are they only a constructed case? If there would be e.g.
subtitle tracks in the files I could see that such cases might actually
exist, or are there better explanations for those cases?
I'll have to check.
Definitely missing chunks are to be expected when capturing broadcast
video -
there are always dropped/corrupt parts in the stream, and not all packagers
fill those with empty frames themselves.
Also, for the case when the first timestamp isn't zero - I think the
current normalization (by shifting them to zero) might not be the best
solution. Since the fragments themselves contain the tfxd box which
indicates the timestamp and duration, this would lead to a mismatch, i.e.
when the client requests QualityLevels(42)/Fragments(video=0), but this
fragment actually contains tfxd box saying time=<nonzero>. Wouldn't it be
better to just add the time of the first chunk when setting the duration
of the last chunk? That is, this:
Right. I'll check this and get back to you. Maybe it isn't the best
solution.
I thought of another reason why the timestamps should be left as is (and
just the (final) duration fixed) - if you'd serve such an ismv file with
IIS, it would use the mfra/tfra/mfro index at the end of the file to
locate the right fragment. But if the timestamps are offset, it won't be
able to find the right one. So shifting them would only work when you're
splitting the files (or serving them manually with the ismf file).
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
