On 15/09/14 00:24, "Martin Storsjö" <[email protected]> wrote:

>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.

You are quite right, I must have got my test files mixed up. Libav/ffmpeg
does produce tfxd boxes, our third-party packager does not.

   Mika
        
>
>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

Reply via email to