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

Inconsistent quality behavior? #10065

Closed
Tanksenior opened this issue Jul 11, 2016 · 7 comments
Closed

Inconsistent quality behavior? #10065

Tanksenior opened this issue Jul 11, 2016 · 7 comments

Comments

@Tanksenior
Copy link

@Tanksenior Tanksenior commented Jul 11, 2016

Make sure you are using the latest version: run youtube-dl --version and ensure your version is 2016.07.11. If it's not read this FAQ entry and update. Issues with outdated version will be rejected.

  • I've verified and I assure that I'm running youtube-dl 2016.07.11

Before submitting an issue make sure you have:

  • At least skimmed through README and most notably FAQ and BUGS sections
  • Searched the bugtracker for similar issues including closed ones

What is the purpose of your issue?

  • Bug report (encountered problems with youtube-dl)
  • Site support request (request for adding support for a new site)
  • Feature request (request for a new functionality)
  • Question
  • Other

Hello, I have a little question about what seems to be inconsistent behavior regarding format/quality selection. Or perhaps my expectations about said options are inaccurate? I hope someone can help clarify if that is the case.

I'll explain/show my actions and results below.

Video used as example: https://www.youtube.com/watch?v=f25R9Gl6FWc

Download without any parameters(for reference):
http://imgur.com/GS4fSku

Media info:
http://imgur.com/kT0uW9R

Now for the interesting part, download with parameters taken from the "Format selection examples" section. (https://github.com/rg3/youtube-dl#format-selection-examples)

Download best mp4 format available or any other best if no mp4 available

$ youtube-dl -f 'bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best'

http://imgur.com/VOrVs9N

Media info:
http://imgur.com/LnjUqHl

Now for the final result using -f best
http://imgur.com/LVQP4QI

Media info:
http://imgur.com/BDuaDNx

Note the significantly larger file size and higher bit rates for both audio and video.

Why does "# Download best mp4 format available or any other best if no mp4 available" not actually return the best quality mp4 available but -f best does? Am I misunderstanding things? Am I doing something wrong? Are my expectations off?

Please explain if you can, thanks in advance.

@dstftw
Copy link
Collaborator

@dstftw dstftw commented Jul 12, 2016

Read format selection. It explains everything or use search.

@dstftw dstftw closed this Jul 12, 2016
@Tanksenior
Copy link
Author

@Tanksenior Tanksenior commented Jul 12, 2016

Do you honestly think I didn't read that about 100 times before posting this?

Nothing in there explains what I'm asking.

Kind of ironic since you obviously didn't take the time to actually read my questions.

@Hrxn
Copy link

@Hrxn Hrxn commented Jul 12, 2016

Well, the format selection guide is correct. But results depend on the site/extractor.
And not even all videos on YouTube, for example, are available in all formats. There is some variation, partially depending on the age of the video upload.

You can list the available formats for any chosen video with -F, or --list-formats

@yan12125
Copy link
Collaborator

@yan12125 yan12125 commented Jul 12, 2016

It's a limitation of youtube-dl: sometimes the actual quality is unknown until the file is downloaded. In this example, bestvideo is:

136          mp4        1280x720   720p  278k , avc1.4d401f, 30fps, video only, 48.46MiB

And best is:

22           mp4        1280x720   hd720 , avc1.64001F,  mp4a.40.2@192k (best)

As both formats have the same dimension, the only factor is their bitrates. Unfortunately, YouTube does not provide the bitrate information for format 22 of this video. In most cases, bestvideo is better than best, so we make it the default. This video is a good counterexample, but we can do nothing without sufficient information. If you know how to determine video qualities without actual downloading, please propose it. There are already lots of related feature requests. For example, a not-so-good idea was proposed at #6055. (It downloads some portion of the video, which slows down the extraction step.)

@Tanksenior
Copy link
Author

@Tanksenior Tanksenior commented Jul 12, 2016

I see, thank you so much for explaining yan12125! That's the information I was looking for.

Until a solution is found I guess it's going to be a bit trial-and-error to find the highest quality in some cases, I'm just happy to know why it happens though, thanks again.

Edit: One thing I can think of is perhaps looking at the file size(if possible?), as I understand it bigger is usually better, correct me if I'm wrong.

@ghost
Copy link

@ghost ghost commented Aug 16, 2016

Downloading portions of the video to test the bit rates doesn't seem like such a bad solution to this and a few additional megabytes is rather tame. I think having it as an option would be great.

@yan12125
Copy link
Collaborator

@yan12125 yan12125 commented Aug 17, 2016

bigger is usually better

Not always true. Comparing bitrates among different codecs is meaningless. See #6018 (comment) and https://en.wikipedia.org/wiki/Video_quality. You need some mathematical metrics, such as SSIM, PSNR, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.