Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

suggestion for new feature ( seekable stream) #192

Open
publicocean0 opened this issue May 31, 2017 · 0 comments
Open

suggestion for new feature ( seekable stream) #192

publicocean0 opened this issue May 31, 2017 · 0 comments

Comments

@publicocean0
Copy link

publicocean0 commented 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)

  • 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

@publicocean0 publicocean0 changed the title suggestion for new featute ( seekable stream) suggestion for new feature ( seekable stream) May 31, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant