anyaudio / anyaudio-server

:musical_note: Simple server to search youtube and give direct audio download and stream links
91 stars 19 forks source link

Limit by duration as conversion takes time #17

Closed aviaryan closed 8 years ago

aviaryan commented 8 years ago

The amount of time taken to convert OR the amount of time taken to start download is directly proportional to length. This can keep a worker busy for far more longer time than expected.

singhpratyush commented 8 years ago

Limit by duration as conversion takes time

Does duration refers to media length?

aviaryan commented 8 years ago

Yes

On Mon, Aug 8, 2016 at 10:31 PM, Pratyush Singh notifications@github.com wrote:

Limit by duration as conversion takes time

Does duration refers to media length?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/aviaryan/youtube-mp3-server/issues/17#issuecomment-238301252, or mute the thread https://github.com/notifications/unsubscribe-auth/AD3C7TTRGwJAPkSxdp9GgX01zmgb9oDvks5qd2DdgaJpZM4Jesfg .

singhpratyush commented 8 years ago

Server will still serve /g/<video_id> whose media length is large.

aviaryan commented 8 years ago

Good point. Actually /g/ is not a problem as it just fetches the URL. The real issue is with /d/ which downloads the file and converts it. We should create an internal API to fetch video information from ID (through web scraping or youtubedl API) and then use it to get video information. It will also help to return meaningful filename (not music.mp3) for a file.

aviaryan commented 8 years ago

Infact the /d/ endpoint is highly obsfucated so no one will be able to use it to download a large file. It just won't work.

singhpratyush commented 8 years ago

If you make this project public, it will no longer be obsfucated.

aviaryan commented 8 years ago

Still no one will be able to use it. What will they do ? Get youtube direct link on their system and b64 encode it and send to /d/ . That won't work as the machine is different and they will instantly get a 400. (no problem for us) The real need is to block users to send any link they want into the /d/ endpoint. And we can do it using little encryption. So I think this issue can be closed. I will open a new issue for encrypting /download urls.

singhpratyush commented 8 years ago

I think this can be closed now.