Skip to content
This repository was archived by the owner on Sep 12, 2022. It is now read-only.

Conversation

@Wolvan
Copy link

@Wolvan Wolvan commented Oct 1, 2018

The way Youtube delivers media files now is by splitting them up into 2
separate streams of audio only and video only. Unfortunately, it isn't
possible to get a fully muxed stream that has decent quality anymore.

I attempted to mux using ffmpeg, but the speed was nowhere near
sufficient to give a smooth stream. In the end, the only option that
really worked out is have Youtube-dl download the video and audio, mux
it into a local file and then have omxplayer play this file.

The video file gets removed as soon as playback is finished as to not
cause hard drive clutter on already limited space like an RPi.

Closes #60

The way Youtube delivers media files now is by splitting them up into 2
separate streams of audio only and video only. Unfortunately, it isn't
possible to get a fully muxed stream that has decent quality anymore.

I attempted to mux using ffmpeg, but the speed was nowhere near
sufficient to give a smooth stream. In the end, the only option that
really worked out is have Youtube-dl download the video and audio, mux
it into a local file and then have omxplayer play this file.

The video file gets removed as soon as playback is finished as to not
cause hard drive clutter on already limited space like an RPi.

Closes vincelwt#60
@vincelwt
Copy link
Owner

vincelwt commented Oct 2, 2018

Hello!
Thank you for your contribution :)

When we first made RaspberryCast we were using os.system to use youtube-dl but it turns out it is much much slower than using the youtube_dl Python bindings. Switching to them saved a few seconds of processing for each videos.

Isn't it possible to use these the bindings in this case?

process.py Outdated
)
if "/tmp/" in url:
os.system(
"rm -rf " + url
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line sort of scares me - is there not a safer way to do this? 🙂

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You know, you're right. That wasn't a good idea. Sorry, this is my first time playing around with python, I'm still getting used to it. I'll look into it!

Using `rm -rf` was quite frankly a terrible idea, this way only a file
can be deleted, minimizing potential harm.
In theory, this should increase speed of the youtube-dl processing. I
have not tested the speed advantage much, but what could go wrong with
calling native bindings?
@Wolvan
Copy link
Author

Wolvan commented Oct 11, 2018

Alright, first things first, I fixed the deletion mechanism. I really don't know what I was thinking when I wrote this and figured "rm -rf is a great idea!". That should be fixed by using python's removal now, hooray!

Furthermore, I tried implementing native youtube-dl calls. It seems to work so far.

@mheine
Copy link
Collaborator

mheine commented Oct 12, 2018

Code seems cleaner now, nice! I'll have a proper look and test it on my PI during the weekend 🙂

@mheine mheine self-assigned this Oct 12, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants