Closed aviaryan closed 8 years ago
Limit by duration as conversion takes time
Does duration
refers to media length?
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 .
Server will still serve /g/<video_id>
whose media length is large.
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.
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.
If you make this project public, it will no longer be obsfucated.
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.
I think this can be closed now.
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.