Hacker News Reader

Comment by UnoriginalGuy | Hacker News Reader

I wish the audience's audio wasn't much MUCH louder than the speaker. I had to turn the audio up to hear him, but the laughing was so loud I had to turn it down every few seconds.

Also a fun video to watch, but he kind of skips over some of the most interesting technical details (like writing the software).

View on HN

Hi! I shot the video. We had some problems with the mic hookup on stage so I was using a mic all the way back at the camera that wasn't nearly as directional as I hoped. Apologies to everyone's eardrums !

You could have also run a noise filter over it I believe, the quality wasn't good even when the crowd was quit.

Well, you have the video now, you can download it and run said noise filter over it yourself..

Your effort is much appreciated, the talk was worth it. Thank you!

Agreed, my neighbors probably hate me right now from the audio.

On a serious note, though, I hope a write up with more details pops up.

This was bad enough that I bothered to figure out how to fix it.

VLC -> Media -> Open Network Stream, paste in the youtube URL.

VLC -> Tools -> Effects and Filters -> Audio Effects -> Compressor.

Enable the compressor. Here's where I moved the sliders: http://i.imgur.com/fGlPM5R.png

I basically followed the advice given here: http://lifehacker.com/5920290/how-to-fix-movies-that-are-rea...

The last 10 seconds of the video is the best way to verify it is working. Without compression, the clapping is ear-drum-splitting-loud compared to the speakers voice.

Thank you, that made this super-interesting video actually watchable.

Also, I learned VLC will just happily play a YouTube video right from the page's URL.

Yeah, that trick is also useful for older machines which are otherwise too slow to play stutter-free youtube video in a web browser. The VLC implementation appears to be significantly more CPU efficient.

Probably pulls the h264 version instead of VP8/9.

I was gonna say there's a Chrome extension (H264ify) that allows that, but then again I doubt the machine would even be capable of running chrome.

That's probably not why. h264 would indeed use less cpu time than vp8 if there was hardware acceleration from the graphics driver available and being used for h264 but not vp8 (which is plausible). But software decoding can be pretty efficient in dedicated video players, and browsers and flash can be pretty damn slow at just getting decoded frames to display.

Back in 2010 I was using a computer I built in 2004, which had a single-core athlon64 3200. Watching standard definition video in Hulu was a blocky slideshow, totally unusable. But I could watch 720p h264 video at a decent bitrate, with mplayer, with no hardware acceleration.

One of the bigger differences is that browsers/flash have to put the video output as a surface that they composite with the controls on top and the rest of the page behind. Old-style video players actually render to a different hardware "overlay" plane and don't mix anything with it in software, and it makes a huge difference.

(My mplayer example is from linux, but I've also used MPC on windows a lot. You can change the renderer in the settings, and "overlay" doesn't support showing subtitles, but has noticeably faster/smoother performance. Well, back on windows XP.)

You think VLC pulls the VP8/9 version instead of the h264 version? I seriously doubt it. Why would it? It would make no sense. Most devices have h264 hardware decoders. Most don't have VP8/9 decoders (though they exist).

I also have no doubts that an Athlon64 could decode 720p h264 completely in software. You'd be pegging that single core pretty high, but it could do it.

My point was that the hardware acceleration, and vp8 vs h264, doesn't really matter. The computation power of processors sold in 2010, even those in not-very-thick laptops, was probably double my Athlon64. The difference is everything else, the UI stuff (and maybe also flash and browsers being less efficient at decoding than ffmpeg).

Well, on a single core you are going to hit issues with multiple processes running. If you have the browser, flash, network, and decoding all happening on a single core, it wouldn't be surprising to see stuttering. Obviously, offloading the decode to a different processor would help out, but so would running just a single process.

Well, you'd use 30% less bandwidth (and therefore start / seek faster).

In addition, decoding VP9 in software is actually faster than H.264 with ffmpeg, the decoding library that VLC uses.

Are you sure overlay doesn't support subtitles? IIRC, they had a special color value that the graphics card replaced with the decoded video, and they just didn't use that color wherever they wanted to display subtitles. This is just from memory and from what I deduced, so take it with a grain of salt.

wow, that's amazing. thank you.

Looks like VLC uses http://ffmpeg.org/ffmpeg-filters.html#compand. If someone wanted to have a permanent fixed version.

Nice to know that VLC takes youtube urls. The compressor didn't improve the sound for me though.

The worst part was that the jokes weren't even funny. It sounded more forced than a '90s sitcom laugh track.

"As you can see, I got a G-" <HAHAHAHAH>, "that's like ... a good grade" <HAHAHAHAHAHAH>, "of course, an E is for excellent" <BAHAHAHAHAHAHAH!!!! ::standing ovation::>

... why am I so cynical? ;_;

Agreed though, the actual concept was really cool! Maybe to the author, try subtitling the video given the bad audio? Then we could just watch the video muted, and the (minor) problem would be solved :)

(and feel free to downvote this, I know I sound like a monster, complaining about laughter >_>;)

I am not the one to complain often. But I really was very irritated, by the hysterical laughs, at regular frequency.

Reply on news.ycombinator.com