youtube-dl
youtube-dl copied to clipboard
ytdl-org
Add a postprocessor to concatenate files in a playlist
It may not be pretty, but it friggin' works. I did some initial testing with The Daily Show, but I have no idea how it handles other sites. Of particular concern is non-MP4 formats. Currently, the output file is always an MP4 container (this should be fixed), since I have concerns about it breaking with obscure containers. I've tested AVI, FLV, MP4, and MKV (they work), but there are dozens of others I haven't tested. For the time being, MP4 seems a reasonable default, since just about everything can play it.
This patch changes a few interfaces, most notably adding a return value to the process_info() function in YoutubeDL.py. Also, a 'saved-filename' key is added to the dictionary returned by process_video_result(). Also, run_ffmpeg_multiple_files() now accepts an optional list argument called preopts, for arguments that need to go before the input files. (Oh, ffmpeg. You so silly.)
The command line option is --join. Also, joining silently fails if the IE doesn't return "playlist" as the _type. Also, I have no idea what happens if you specify multiple URLs that are each a playlist. Or if you specify some that are and some that aren't. Or if the items in the playlist have different formats. Or something else I forgot in the time it took me to write out those other three.
I can't think of anything else to add to this wall of text, and getting acquainted with the youtube-dl internals has left my brain a pile of mush, so beware of mistakes both large and small. Now if you'll excuse me, I've got about a month's worth of Daily Show to catch up on.
Okay, looks like multiple URLs that are returned by their respective IEs a playlists get appended separately, as they should be. (In this case, anyway. Should be fun when some user wants to append two random YouTube videos.)
Oh yeah, and the process for concatenating involves writing a temporary file that ffmpeg reads. Ugly, but the one page of documentation I read didn't mention any way to use only the command line. Should really look for an alternative.
Some more issues to investigate later:
- FLV to MP4 doesn't work. Ffmpeg barfs, saying
Could not find tag for codec flv1 in stream #0, codec not currently supported in container. Going to have to use the input extension. Need to add an error message for when the inputs are different containers. - Single quotes and other special characters written to the list file need to be escaped with a backslash.
- Investigate possible line ending issues.
Okay, the output extension is now that of the first input file, and will warn if all the extensions aren't the same (no warning is given for different formats, however, and that needs to be fixed).
Single quotes in filenames are now escaped in the temp file, though I've noticed utils.py:encodeFilename() mangles single quotes for some reason, like so: Garry'"'"'s Mod.3gp.list.txt. That file doesn't exist, so ffmpeg barfs and dies.
ffmpeg (or at least my build of it) doesn't need Windows-style line endings, so that's nice.
Someone should probably check to see if this works with avconv since something in libav is always broken.
In a word, no. It was never merged because it was never completed. I managed to get it working for what I needed, but it wasn't good enough to release even as an experimental feature in the main branch. After getting it to it's present kinda-working state, RL issues took me away from it, and by the time I was able to work on it again, I had forgotten how half of it worked, and another PR to do that same thing was submitted (#2844).
If it's a feature you need and you can't implement yourself, I might be able to take another shot at it, though I no longer have hours of free time nowadays, so no guarantees.
I would like to add my support for this feature!
If edge cases are a concern for certain formats, would it be worth simply restricting the flag to being compatible with only certain formats (eg mp4)?
It's OK to support MP4 first, while the implementation should be easy to extend support to other formats.
After playing extensively today with concatenating Youtube downloads with ffmpeg, I believe the primary cause of failures are FPS differences!
It is of course not the only cause of failure—resolution or codec differences will do it too—but it's the least obvious one. And, the failure state for frame-rate differences is bizarre—ffmpeg will happily write the concatenated file, and the first part may even play fine, but as soon as you reach the section whose source video had a different frame-rate... well, the effects vary, but suffice to say really weird things start happening.
If the reason this feature hasn't been implemented is because devs are worried about edge cases, try adding a framerate check! I bet that will solve most of the problems. (And if not, I'd still like to have this as an experimental feature. 😀)