To serve it in a truly streaming way does require some special purpose server or configuration, but the `@availabilityTimeComplete` field that is written into the manifest is supposed to indicate to the client making the request whether or not the segment file is complete at the time it becomes available. In streaming mode, this is set to false so the client should expect that it can get a partial segment between the available start time and the segment duration.
So as each box is written to the file, it should be safe for the HTTP server to send the partial segment file that is currently on disk. And the DASH spec specifically indicates whether or not to expect a partial file for the segment being requested. If the client can’t handle a partial file and is still making an attempt to request it before it’s fully available (which is calculable from the information in the manifest), the client wouldn’t be respecting the DASH spec. Kevin LaFlamme Director of Engineering (Front End) 774.265.0382 (m) aiera.com On Jun 8, 2021, 3:34 PM -0400, Timo Rothenpieler <t...@rothenpieler.org>, wrote: > On 08.06.2021 21:24, Kevin LaFlamme wrote: > > For streaming mode with fragmented MP4 the intention is to have the client > > read a partial file since it’s broken up into sequential boxes that are > > playable independently. This doesn’t change the segment files themselves or > > how they are written, it just writes a full index file ahead of time. > > > > Even currently, the manifest gets written after the first segment is > > written and the player can immediately attempt to start reading the second > > segment before it’s fully written. > > > > This is the same thing that the “-lhls” is doing in the block below, > > writing out the HLS manifest immediately so that it contains X-EXT-PREFETCH > > fields for the partial segment files. > > > > Currently, if you have a low latency DASH stream with “-ldash” and > > “-streaming” and the player joins in the middle of the stream everything > > works and it starts playing from the middle of the current segment. This > > means even with 10 second segments you can have latency < 1sec of the live > > edge. However, this doesn’t work for the very first segment because the > > manifest isn’t available to the player yet. > > > > I have a low-latency player where I’m seeing this issue right now and this > > addresses the problem, and seems consistent with the “-lhls” handling > > below, but happy to make changes if there is something else I’m missing. > > Yes, I'm aware that that's how it's supposed to work in theory. > But does that work with any HTTP server? > Do they really manage to stream the file while it's being written to? > Or does this need special software to serve the file? And in turn, will > it break for a user just pointing apache/nginx at such a list? > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
