Hacker Newsnew | comments | show | ask | jobs | submit | frozenport's comments login

Ummm. Calvin is most famous for his work in Geneva, which is incidently what the author contrasts with our culture.

The divergent views on work life balance happened later, perhaps during the USA's rapid industrialization and sold to the people under the idea of 'land of oppertunity'.


As a Gentoo user we're gonna have terrible dependency problems for the next few years. Specifically VLC and Qt.

Somebody at Redmond is laughing at the OSS community for failing to provide functionality that comes out of the box on the latest Windows systems.


Nothing that Microsoft has comes close to the functionality of ffmpeg. Apple, either, for that matter. Last time I checked neither OS even supported reading Matroska containers natively, and containers are pretty simple compared to codecs.

    $ ffmpeg -codecs 2> /dev/null | wc -l
         396
ffmpeg and libav are simply the most comprehensive collections of video codec software in existence.

>Last time I checked neither OS even supported reading Matroska containers natively

Windows 10 actually does support Matroska out of the box, albeit 11 years later than FFmpeg.


And the code is surprinsingly compact.

That doesn't make either one good.

I can promise nearly every implementation in ffmpeg is better than the competitors. No commercial product has the motivation to keep making improvements to their code that already works "well enough", and they don't have as good a set of working optimizations to apply to new codecs.

They can get new features out the door, though. One reason for the original fork in ffmpeg was that the very strict code review culture made it difficult to get anything in that was experimental or depended on personal taste.


There is a lot of very useful functionality in ffmpeg/libav. That doesn't make using it pleasurable.

Were you trying to use it from the API or the command line?

Either way, yes. Elenril and others were doing good work cleaning up the API when I last paid attention years ago, but there's a lot of surprise technical issues esp. in libavformat that it has to cover up. (Like, PTS/DTS in avi. Like operations that are instant in some file types might be real-time minutes in others.)

As for the command line, major customers tended to not ever give feedback on it, and it was maintained by Michael who tended to use the same code-review standards on the UI code as on the inside of a video encoder. This made it quite difficult to ever get anywhere. That's one of the reasons there was a fork back then.

Of course, there's deep technical problems there too - you can tell it to do all kinds of things that are actually really hard, and it will kind of half-heartedly do them then fail. Try converting a Matroska file to MP4 without re-encoding it; you'll get a weird error. That one weird error would take more than a year of developer time to fix.


Yeah, both. In fairness, the last time I tried using the API was before the libav split, and I have no doubt that the situation has improved; the command line, while almost ludicrously powerful, retains a lot of terrible habits -- silent defaults, mutually contradictory options, &c.

I have somewhere a much more prescriptive python library that sits on top of the command line API, but I think it'd be really great if there were a "strict" mode for the CLI -- no more implicits, no more silent rejiggering of options. If you don't totally account for your input and output, it's an error. Then, there could be a much more forgiving and intelligent front end to the front end that allowed for things like "-i foo.avi ./foo.mp4", making best guesses at each stage of the pipeline.


It makes them better than the competition, in that I can throw practically any video format in the world at libavformat and friends based players (like vlc or mplayer) and it just works.

It may not be "pleasurable" but it's nothing to be trifled with.

Perhaps video is just a hard problem?


There's no question that ffmpeg set itself a very difficult problem, and largely succeeds. But it does so in a way that is brittle and (whether purposefully or simply out of lack of knowledge) learnt nothing from e.g. QuickTime or DirectShow.

The problem as I see it is that media manipulation is not really suitable for a one-size-fits-all command-line solution, and the API was slave to the command-line tools. This may have changed recently, which would be great.


Further, after six years they might have fixed the problem.

>>They are, but once you start learning about them, you realize the "black magic" part comes mostly from their mathematical nature and very little from them being "inteligent computers".

Oh humbug! The black magic comes from the vast resources Google drew to obtain perfect training datasets. Each step in the process took years to tune, demonstrating that data is indeed for those who dont have enough priors.


>>By the end of the book, the reader is at a loss.

>> sounds appealing but is frustratingly vague.

AHHHHHH!

In a act that can only be described as `post-modern` the reviewer commits the same sin of `frustrating vague`ness that the ruined the original book. Indeed, I feel the need to write a similar review of the review to keep the meme alive. In my dreams I see a future where nobody knows of the book but for its frustrating vagueness.


My high school English teach taught me to demonstrate rather then assign traits. Somehow between all the fluff I lost the author's message, and skipped to the last few paragraph.

I find it crazy that one small aircraft could collide with another small aircraft, with such a vast amount of space to avoid each other. How is a collision possible? What am I missing?

When I was going through flight training, I thought about this a lot. I think the reason is that the places airplanes go is not random. If airplanes just went to random places in the sky at random altitudes, then indeed accidents would be rare, but everyone heads towards airports, which have particular traffic pattern altitudes for instance. I don't know the specifics of this situation, but perhaps the military pilot wanted to practice IFR near the ground and there also happened to be a VFR corridor passing through there. These non-random intents of pilots mean that airplanes get a lot closer together than you would otherwise think.

There's a known problem in the sailing world where people will set their autopilots to GPS coordinates from waypoints published in sailing magazines, and then collide with another vessel in the middle of deep ocean with no landmarks around.

> I think the reason is that the places airplanes go is not random.

This is how two planes collided 37,000 feet above the Amazon rain forest.

http://www.vanityfair.com/culture/2009/01/air_crash200901


Thank you for that, that was an incredible article. I was ultra surprised that just after finishing that, this popped up on HN's front page:

https://news.ycombinator.com/item?id=9970336


very rare event. But rare events happen.

>>unless our knowledge of physics advances and SoL is no longer a limit

The latency of the human mind is around the same. There are lots of tricks like predicting the future game state that can result in a better user experience.


UI Response time is at most 100 ms [1], as anything more that is very noticeable laggy.

Actual perception times are much lower than that, about 13ms [2]. You can see the difference for yourself by looking at a 30FPS (33ms) and 60FPS (16ms) video [3], and the effect is much greater when you're actually providing the inputs.

[1]: https://stackoverflow.com/questions/536300/what-is-the-short... [2]: https://newsoffice.mit.edu/2014/in-the-blink-of-an-eye-0116 [3]: http://www.30vs60fps.com/


Will a commercial enterprise see people as a needless expense that hurts their bottom line? Why cant robots mine the moon withiut us?

Mostly used to cheat in higher level physics classes.

-----

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: