Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFMPEG from Zero to Hero

ffmpegfromzerotohero.com

Post reply on HN
Print view View original

31–40 of 140 posts

Re: FFMPEG from Zero to Hero

#31

Post by sbarre »

d0100 wrote: post #26

After seeing some posts here on HN about FFMPEG I tried looking into green-screen joining two Twitch streams together. Sometimes a streamer wants to overlay his stream with a tournament channel, but because of copyright they can't. It'd be nice to have an easy way to set that up, if twitch won't do it on their end the user can do it themselves

People do this using OBS already, don't they? I've definitely seen streamers do "talk over" streams of press conferences or "watch party" streams of tournaments..

Re: FFMPEG from Zero to Hero

#32

Post by trog »

d0100 wrote: post #26

After seeing some posts here on HN about FFMPEG I tried looking into green-screen joining two Twitch streams together. Sometimes a streamer wants to overlay his stream with a tournament channel, but because of copyright they can't. It'd be nice to have an easy way to set that up, if twitch won't do it on their end the user can do it themselves

Can OBS not do that? I haven't used it much but I have had some success merging video streams from different sources without a lot of effort.

Re: FFMPEG from Zero to Hero

#33

Post by wmf »

herpderperator wrote: post #11
Confiks wrote: post #2

Might have come in handy while I was struggling to type out ffmpeg -i part0.mp4 -i part1.mp4 -filter_complex "[1:v]scale=1280:720:force_original_aspect_ratio=decrease,pad=1280:720:(ow-iw)/2:(oh-ih)/2[v1]; [0:v] [0:a] [v1] [1:a] concat=n=2:v=1:a=1 [v] [a]" -map "[v]" -map "[a]" out.mp4 to concatenate two videos with different sizes today. My relation with it is almost identical to my relation with any bash scripting m…

It's true, and I feel the same, but to give it some credit: wouldn't that apply to anything you don't use regularly? Programming languages or even regular languages. You have to use it or lose it.

If you don't perform a task frequently, a discoverable interface (e.g. GUI) is dramatically more productive than reading documentation.

Re: FFMPEG from Zero to Hero

#36

Post by strogonoff »

The part of the book that covers raw[0] image conversion is lacking. It suggests ImageMagick or SIPS (on macOS), completely ignoring the difficulty of properly converting image from scene-referred to output-referred format. The result is probably going to be of limited usefulness in most cases involving interpretation of raw footage.

If the author is here, I suggest looking into RawTherapee. It offers a GUI for authoring and applying raw processing profiles, as well as a CLI tool that can be used for batch application of a given profile to raw images. If you consider raw image processing within the scope of the book, you might as well cover it properly.

[0] Setting aside the insistence of the author to spell “RAW” as an abbreviation, which it isn’t. “PodCast” is another instance of weird, excessive and sometimes inconsistent capitalization style used in the book. Not to say this detracts from the substance, but I would suggest that an editor or a proofreader could help your books be more professional.

Re: FFMPEG from Zero to Hero

#37

Post by astrange »

merb wrote: post #15
the_only_law wrote: post #10

ffmpeg is really useful, but isn't doing some of these things on a CPU really inefficient? I know there are some offloads for Nvidia GPU’s for some video stuff, but I was under the impression that they used Nvidia’s proprietary libraries that have limited codec support.

it's always a tradeoff between speed and quality. and most of the time cpu offers more quality while hardware encoders are faster, this is mostly because gpu encoders have a different use case than cpu encoders.

The GPU encoders aren't GPGPU programs, but just hardware encoders that happen to be on the GPU. The reason they're worse is because the algorithms they use are worse than x264, which had much more development time and better developers. (who have since retired to become professional cosplayers.)

Re: FFMPEG from Zero to Hero

#38

Post by tialaramex »

herpderperator wrote: post #11
Confiks wrote: post #2

Might have come in handy while I was struggling to type out ffmpeg -i part0.mp4 -i part1.mp4 -filter_complex "[1:v]scale=1280:720:force_original_aspect_ratio=decrease,pad=1280:720:(ow-iw)/2:(oh-ih)/2[v1]; [0:v] [0:a] [v1] [1:a] concat=n=2:v=1:a=1 [v] [a]" -map "[v]" -map "[a]" out.mp4 to concatenate two videos with different sizes today. My relation with it is almost identical to my relation with any bash scripting m…

It's true, and I feel the same, but to give it some credit: wouldn't that apply to anything you don't use regularly? Programming languages or even regular languages. You have to use it or lose it.

There's a continuum, and yes that applies to human languages, both natural and constructed, and to other skills. But where you can choose (so, not natural languages really) you can design things to make this easier, or, I guess, harder.

For example English orthography is a horrible mess. The inventory of squiggles needed to write English isn't too bad, but the correspondence between the words you know and the correct sequence of squiggles to write them is unnecessarily complicated. No benefit accrues to us from this, and in some other written languages it's much easier.

I'd place ffmpeg somewhere in the not-bad but not-great part of the continuum. As with English orthography of course the problem is if you change things with the intent to make them better you actually introduce a cost for existing users which may be impossible to sustain.

Re: FFMPEG from Zero to Hero

#40

Post by tartoran »

wmf wrote: post #33
herpderperator wrote: post #11

Earlier quoted context omitted.

It's true, and I feel the same, but to give it some credit: wouldn't that apply to anything you don't use regularly? Programming languages or even regular languages. You have to use it or lose it.

If you don't perform a task frequently, a discoverable interface (e.g. GUI) is dramatically more productive than reading documentation.

Conversely, if you perform a task frequently you want to be able to script it out and automate it away.
Post reply on HN