You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now the buffer is appended with chunks so the stream is incremental.
This has limitations:
-song buffer can be big (above all in mobile device (my android phone is crashed for out of memory)or for long files)
if multiple players are embedded in a html page( i think a facebook template example) the problem get more critical
A more generic solution is to permit to append a chunk from a specific file offset:
append call might add a parameter append(offset,buffer)
the buffersize must be fixed (maybe configurable)
player.buffered might be a object like {start:x , end:y} ,x<y. for defining a segment inside the time line.
-demuxer seek(time) might return the file offset from where to upload the chunks (the upper limit could be handled automatically by demuxer (merging or skipping or replacing)) or seek(time) return a range (missing segment)
I use a similar logic for another decoder and it works
The text was updated successfully, but these errors were encountered:
publicocean0
changed the title
suggestion for new featute ( seekable stream)
suggestion for new feature ( seekable stream)
May 31, 2017
Now the buffer is appended with chunks so the stream is incremental.
This has limitations:
-song buffer can be big (above all in mobile device (my android phone is crashed for out of memory)or for long files)
A more generic solution is to permit to append a chunk from a specific file offset:
-demuxer seek(time) might return the file offset from where to upload the chunks (the upper limit could be handled automatically by demuxer (merging or skipping or replacing)) or seek(time) return a range (missing segment)
I use a similar logic for another decoder and it works
The text was updated successfully, but these errors were encountered: