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

--get-filename not getting the final filename (was: get filename not working?) #5710

Open
undefinedstudio opened this issue May 15, 2015 · 16 comments
Labels

Comments

@undefinedstudio
Copy link

"--get-filename" returns a different name from a normal execution.

~# youtube-dl -o 'test.%(ext)s' --prefer-ffmpeg --get-filename https://www.youtube.com/watch?v=f3gNU0rNIIo
test.webm

:~# youtube-dl -o 'test.%(ext)s' --prefer-ffmpeg https://www.youtube.com/watch?v=f3gNU0rNIIo
[youtube] f3gNU0rNIIo: Downloading webpage
[youtube] f3gNU0rNIIo: Extracting video information
[youtube] f3gNU0rNIIo: Downloading DASH manifest
WARNING: You have requested formats incompatible for merge. The formats will be merged into mkv
[download] Destination: test.f248.webm
[download] 100% of 83.44MiB in 00:02
[download] Destination: test.f141.m4a
[download] 100% of 7.24MiB in 00:00
[ffmpeg] Merging formats into "test.mkv"
Deleting original file test.f248.webm (pass -k to keep)
Deleting original file test.f141.m4a (pass -k to keep)
~# ls
test.mkv

I am expecting the two commands to return the same filename (either .mkv or .webm).

What am I doing wrong?
Thanks

@jaimeMF jaimeMF added the bug label May 15, 2015
@jaimeMF
Copy link
Collaborator

jaimeMF commented May 15, 2015

The problem is that we output the filename before deciding if the formats have to be merged into an mkv file.

The workaround is to use -f best (you won't get the DASH) or -f 'bestvideo[ext=mp4]+bestaudio[ext=m4a]/bestvideo[ext=webm]+bestaudio[ext=webm]/best'

@undefinedstudio
Copy link
Author

Thanks, the second solution worked for me, although I'm planning to just read the generated filename for now.

@eriktjacobsen
Copy link

@jaimeMF If there is no extension used, such as simply -o output, shouldn't it not matter whether any formats have to be merged and just use the output name? Instead of appending any extensions?

Or an option to force not using an extension so we can trust what we pass to the -o option will be whats written?

@dstftw
Copy link
Collaborator

dstftw commented Aug 9, 2015

@eriktjacobsen if not extension is used ffmpeg is not able to merge.

@eriktjacobsen
Copy link

@dstftw I see... Ok, just trying to get a handle on whether devs see this as something working as intended or something to be fixed. Couldn't youtube-dl just wait until ffmpeg finishes the merge, and then if no extension is listed in the -o output option, the file is renamed from whatever extension it used to the supplied output name?

Then at least it could be trusted to have some predictable output.

@dstftw
Copy link
Collaborator

dstftw commented Aug 10, 2015

@eriktjacobsen there wouldn't be a bug label on the issue if it were expected.

@yan12125
Copy link
Collaborator

The problem is that the final filename may not be determined until actual downloading. For example, FFmpegExtractAudioPP uses ffprobe to determine the output file extension. This semantic needs real files.

If anyone else have a good idea, feel free to post it.

@joeynotjoe
Copy link

I too am running into the need for this functionality. It would be great if there was a way to pass the output file onto another script after downloading. If I'm missing something obvious, please let me know!

@satouriko
Copy link

Hi everyone, is there anyway I can get the final output filename (correctly) up to now?
ps. I would like the best video+best audio, even if they're always merged into mkv doesn't matter to me

@satouriko
Copy link

info_dict = ydl.extract_info(url, download=True)
fn = ydl.prepare_filename(info_dict)

This seems can only get the filename "prepared to be", i.e. maybe get something.mp4 while the actual filename is something.mkv

satouriko added a commit to cool2645/youtube-to-netdisk that referenced this issue Mar 6, 2018
Requested formats are incompatible for merge and will be merged into mkv.
ytdl-org/youtube-dl#5710
@jwhittaker
Copy link

Brute force solution piece for a script:

class MyLogger(object):
    def debug(self, msg):
        match = re.search(r'.ffmpeg..[Dd]estination..(.*?)$', msg)
        if match:
            final_path = match.group(1)

And to cut down on msg:

ydl_opts = {
    'noprogress': True,

@bjuergens
Copy link

this might be a stupid question, but can't I just 'outtmpl': 'file.mkv', since it always falls back to mkv (assuming I don't care about audio-files)?

Or to phrase it differently: are there cases in which youtubedl won't give me a mkv-file?

@Hrxn
Copy link

Hrxn commented Aug 13, 2018

Uh.. depends on the site/extractor?

I mostly have webm (from YT) and mp4 (others)..

@kaerns
Copy link

kaerns commented Aug 17, 2019

A brave suggestion: Implement an additional (command-line) parameter or alter the existing one to print the true and final filename after all processing happened.
It's not really fun to write special cases for every extension-change that can happen between --get-filename and the process end.

@jaysonlarose
Copy link

Or — and not having looked at the code, I have no idea how much work it'd be to implement — how about outputting all of youtube-dl's "ok, I'm downloading stuff, here's how it's going" chatter to stderr, and after all is said and done, printing out the final output filename to stdout? It's a nice UNIX-y way to do things that's easy to deal with in just about any programming or scripting language. It seems like a crying shame that, how amazing this program is at grabbing video from so many different sources, that it can't report back on what it just downloaded.

@ytdl-org ytdl-org locked and limited conversation to collaborators Sep 2, 2019
@dirkf
Copy link
Contributor

dirkf commented May 17, 2024

#5710 (comment): --exec ...

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests