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

Download and serve subtitles #25

Open
nochso opened this issue Feb 20, 2016 · 5 comments
Open

Download and serve subtitles #25

nochso opened this issue Feb 20, 2016 · 5 comments

Comments

@nochso
Copy link
Contributor

nochso commented Feb 20, 2016

In addition to the largest file, subtitle files should also be downloaded and served via HTTP.

I'm not sure how video players handle this, but I remember PT having subtitle support so it must be possible.

What do you think?

@Sioro-Neoku
Copy link
Owner

We certainly could server the subtitle files via http, but I'm not sure if players can use that.
PT had their own player, which made it easier.

One idea that I was playing with in my head is to serve an html file, which users can open in a browser, where they could play the video using a <video> tag (if their browser supports the codecs).
If we'd do that, we could add subtitles.

There is one more caveat as we'd have to do some conversion, as vtt is not fully compatible with srt.

@nochso
Copy link
Contributor Author

nochso commented Feb 21, 2016

Apparently VLC supports the XSPF format which allows mentioning external subtitle files. Example.
Otherwise, of the players currently supported, they all allow passing a subtitle file (or a list of files) while launching.

I like the HTML5 idea as it would allow for a nice UI. No idea about the browser/codec/container support, I hope it's not too limiting. Otherwise I would prefer keeping it to desktop players.

Edit: I've been playing around with serving any requested file via HTTP but I'm having issues with it detecting the content-length. Because content-length is auto-detected via a os.SEEK_END the file size is reported as way too big because the readers seek to the end of the torrent by default. Instead SEEK_END needs to be limited to the end of the file within the torrent.

I'll play around some more and maybe push what I have so far.

@oz
Copy link

oz commented Apr 7, 2016

Is there any progress on this?

I maintain a small lib to fetch subtitles from “Open Subtitles”. It should not be too hard to get subtitles automatically too: right now, osdb requires the first (and last) 64k bytes of a file in order to compute a hash, then used to search subs on their service...

I'm not sure if it's the right approach, but I think that I could submit a PR that does the following:

  1. fetch enough movie data to search subs on osdb (64k offset thing),
  2. search osdb,
  3. provide a Reader interface to an SRT file,
  4. save to /tmp next to the downloaded file.

@nochso
Copy link
Contributor Author

nochso commented Apr 7, 2016

Sorry, I haven't gotten any further. Your suggestion sounds great to me, though I'm not sure what the impact of having to request the end of the file is going to be.

@Sioro-Neoku
Copy link
Owner

Should not be a problem, we can create a LimitedReader at the correct position and wait until we received it all.

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

3 participants