Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Mush Man
Jun 25, 2010

Nintendo announces Frolf means Frog Golf.
Oven Wrangler
There are some serious issues with the recommended YouTube encoding guidelines, especially in recommending all videos be encoded at 720p or over. Here's exactly what's wrong:

  • The section explaining when YouTube encodes to HD is wrong. YouTube will always encode your videos as HD if they have a resolution of 720 vertical pixels or more. Horizontal resolution does not matter.
  • While YouTube regularly messes with 480p, it doesn't always. Recommending a target of 720p+ isn't always necessary.
  • YouTube can still mess with your video even if it's 720p (frame from source). Recommending 720p+ doesn't always fix the problem of bad 480p encodes.
  • Sources that aren't 720p+ are recommended to be encoded as 720p+. That's excessive.
    • If your source is 480p or less you should render to 480p, partially because YouTube's player is 480p but also because the original resolution is too small to watch without resizing.
    • YouTube will offer the 720p option. This option has literally no benefit.
    • This recommendation tells users to render videos up to double the resolution they need to be, requiring the videos to be four times the size for these cases.
  • The Spline resize filter is recommended. It results in sampling artifacts seen in its example. It's better to use a Bilinear filter for all non-point resizes.
  • YouTube does not encode audio in SD videos at 96 kbps. It can encode audio at 256 kbps.
  • You should only pad a video if you can't point resize exactly to a supported YouTube resolution and don't want to use another resizing filter to reach it.
  • Padding shouldn't be recommended at all as it's an option only highly experienced users may want. Its benefits are almost entirely negligible.

There's a better way to solve bad 480p enocdes. Here's a good workflow:

  1. Render to 480p according to the following steps for your source:

    • Is your video 480p?
      • Upload that video without any changes.
    • Is your video less than 480p but 360p or higher?
      • Either upscale straight to 480p or Point Resize by 2x and downscale to 480p. The difference between each method is negligible.
    • Does your video's vertical resolution divide evenly into 480? Is your video 240p, 160p, 120p, etc.?
      • Point Resize to exactly 480p.
    • Is your video less than 360p and has a vertical resolution which does not divide evenly into 480?
      • Point Resize to just above or below 480p and then scale to 480p.

  2. If your video doesn't encode correctly, render to a resolution higher than 480p but less than 720p. This encode should come out right.
    • It doesn't need to be much higher than 480p. Experiment if you want.
  3. If, and only if, the previous encode comes out bad (very unlikely), encode to 720p.
    • If you can Point Resize to 720p evenly, do that.
    • Otherwise, it doesn't matter if you upscale your video straight to 720p or Point Resize to above 720p and then downscale.
  4. If your 720p render still encodes incorrectly, pad the horizontal resolution to 1280.
  5. If that encode screws up (it shouldn't), upload a Point Resize encode above 720p.

I've never needed to go beyond step 2 in that process. Users following this guide will only need to go through it once if they have problems and won't need to worry about large files and resolutions.

Mico posted:

Just about the only reason to use XSplit is if you're stubborn and still on WinXP since OBS is DirectX10.

XSplit isn't actually bad or anything. It's still a viable option.

Adbot
ADBOT LOVES YOU

Mush Man
Jun 25, 2010

Nintendo announces Frolf means Frog Golf.
Oven Wrangler

Admiral H. Curtiss posted:

Perhaps, but it happens very often, and is especially noticable on things like text. Feel free to try uploading 480p, but in my experience the result will look like poo poo more often than not.

The video I provided shows that the issue does not always occur. We should not recommend people jump straight to 720p+, but instead let them upload and see if they encounter the issue and try the workaround I posted if they do. That way, they only need to move to 720p+ if it is necessary.

quote:

It did for me. Download my example videos linked and you will see that the SD ones are 96 kbps and the HD ones are 192 kbps.

The video I provided has an audio bitrate of 256 kbps. A video I just uploaded in 480p had an audio bitrate of 128 kbps. Since YouTube doesn't always encode audio at 96 kbps, that part should be ammended.

quote:

Also I *really* have to question your advice of using Bilinear resizing, because that will almost certainly result in a blurry mess.

Blurriness is always going to happen for non-point resizes. Bilinear resizes will only be too blury if they are done incorrectly. Examples: Point 3x > Bilinear 480 - Point 2x > Bilinear 480 - No preprocess > Bilinear 480 - Point 3x > Spline36 480

I recommend Bilinear over Spline because it does not cause sampling errors as seen in your example.

Mush Man fucked around with this message at 15:16 on Dec 13, 2013

Mush Man
Jun 25, 2010

Nintendo announces Frolf means Frog Golf.
Oven Wrangler

wdarkk posted:

So Hauppage replaced my broken HDPVR with a new HDPVR2 Gaming Edition.

Except it only outputs in HDMI, and my only HDMI device is a monitor with no speakers attached.

So now I have two options:
  • Use a y-splitter for the audio like these. I'm not sure what kind of quality loss that'd give.

I use these. The only problem I've had is that some receiving devices (not the HDPVR2) may find the signal too weak and drop scanlines or the entire signal. I've yet to get a new TV, but using my setup with composite video before I switched to component when I got my HDPVR2 worked well.

Mush Man
Jun 25, 2010

Nintendo announces Frolf means Frog Golf.
Oven Wrangler

wdarkk posted:

Scanlines=video? I'm not sure why I'd need to split video, supposedly the HDPVR2 has a no-delay HDMI converter.

I also don't have an HDMI receiving device (sans the HDPVR). My solution was to split the video and audio and feed the lines to my TV and PVR.

I don't think you'll have any audio quality issues. If something does go wrong, buy a two RCA audio to 3.5 mm jack converter as well, connect that to your Line-In port and record that.

Mush Man
Jun 25, 2010

Nintendo announces Frolf means Frog Golf.
Oven Wrangler

dscruffy1 posted:

So I'm having issues smashing together my audio/video files. I recorded a multiplayer stream with DXtory grabbing video/Skype sounds and recorded my microphone through Audacity. I imported the video audio into Audacity and matched it up, exported that as a FLAC file. I'm trying to mux an MP4 so I can edit/grab frame numbers but I keep getting an error when I'm trying to mux.

This is after re-running the video through a Lagarith encoding with no audio.

I expect MP4Box is rejecting your video because MP4's are only supposed to contain particular streams. Lagarith and FLAC aren't formats that MP4 explicitly supports. If you really need your video in a container other than AVI, try muxing to MKV.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply