On Fri, 12 Sep 2014, Raento Mika wrote:
On 11/09/14 14:18, "Martin Storsjö" <[email protected]> wrote:
On Thu, 11 Sep 2014, Raento Mika wrote:
After looking at the files I have, I think we need a parser for the Tfxd
to get a real fix.
Yeah, that's pretty much my conclusion as well. I can try to create a
patch for that, but it'll probably take until next week.
I'll resubmit a patch that just writes the first chunk start time and
fixes the last duration but doesn't shift all the timestamps.
Ok, that sounds good.
// Martin
So that was a false track: only live ismv files contain txfds - and they
do not contain mfra; at least that's the case with my files and what
happens in ffmpeg: if you tell it to output isml, it'll output txfds, and
if you ask for ismv it won't.
I had the idea that these were present in on-demand streams as well, but
after rechecking the spec they do indeed seem to be optional (and should
be ignored for on-demand streams).
The ismv muxer in libavformat that I wrote does add them for on-demand
streams as well though, which doesn't really seem to match what you
describe.
The tfxd boxes (which tell the identity of the current fragment) are
always written when you write ism*, but the tfrf boxes (which tell you
about the timestamps and durations for upcoming fragments) are only
written if you specify the ism_lookahead option. Can you confirm this, or
do you see different behaviour?
This also means that AFAICT we should be able to rewrite the start time to
0 in the non-live case.
Not quite. However even in the non-live case, if we rewrite the timestamps
to start at 0, the timestamps in the mfra/tfra index won't match with the
ismc file (and thus, with what clients will request) and won't be usable
with e.g. IIS.
Anyway, your updated patch doesn't seem to be shifting the timestamps any
longer, so this is just general discussion.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
