HandBrake 1.0.0 Released
handbrake.fr
handbrake.fr
I ended up making a wrapper for HandBrakeCLI to simplify this: https://github.com/xenomachina/dvdrip
Handbrake was the top search hit and immediately became my workhorse for ripping DVDs. (Main use case is to rip my own DVDs for more convenient viewing on another device)
Well done, Handbrake.fr By the way, mine is version 0.10.5 and when I tell it to check for updates, it says:
HandBrake 0.10.5 x86_64 is currently the newest version available.
I guess the update isn't in the queue quite yet.
Really makes me think twice about giving them my money
Disney is doing some funky disc encryption and I didn't find a solution with a few hours of googling.
I've been fascinated with some projects that have tried to recreate the original theater experience of the original Star Wars,[0] or groups trying to capture classics that influenced Chinese cinema but haven't been widely reproduced, like Red Heroine.[1]
If everything moves to streaming though, even that could become impossible. Wonder how long until they'll stop printing DVDs...
[0] http://webcache.googleusercontent.com/search?q=cache:b1Dmiou...
Experienced the same. I never got into this via IRC. My main thing was music genres, but also on the side quite some non-fiction(documentaries), and a few fiction. I met some awesome people on Soulseek and went from there into DCPP and FTP. This was around 2007-9. DCPP being the frontend for the users. It was a gentlemen's club and from there you just meet different people who see your collection and who invite you into different circles. Back then, there was an auto trader app written in Java, using self signed SSL certificates (w/o pinning). I never understood why they didn't just use rsync over SSH, but it takes more than 1 person to change such habits.
It was an adventure to be able to pull down obscure work from people I'd never heard of previously. As it goes, a lot of the stuff was above my head - but occasionally I'd stumble on something amazing and go deep on that creator. Later, my university had a very good cinema library. You had to request films my name, necessitating research and sapping some of the adventure of chance.
I also hear good things about MakeMKV [1], which apparently allows some sort of lossless ripping of video files (I haven't used it, so I cannot confirm this), although the MKV format does not support menus.
On the order of 2:1 or 3:1 vs MPEG2 format for DVD.
If the question was about balancing quality and file size I would've given a different answer.
sudo cat /dev/sr0 > ~/example.isoDRM is dumb.
Not necessarily, see HDCP.
Not necessarily, see HDCP strippers.
Regardless, my point was the futility of it because screen recording is acceptable, not that we shouldn't strive for better.
You do in the USA? Why? AFAIK, not in The Netherlands. The copy was made from a legal source and in a legal way, and is therefore legal regardless if you do or do not possess the original copy.
2. "Clean" mmap(2)ed pages count as "cache" in the above.
3. Memory allocations are usually physically contiguous—when you mmap(2) something, and then read every byte of that thing in order, that thing usually ends up in a contiguous run of physical memory as clean page-cache entries. This will be true to the extent that you have no other memory pressure forcing the page cache to fragment, evict other caches, or overwrite itself.
4. ASLR just juggled virtual-memory, not physical memory. IIRC (not a kernel dev), Linux at least has an allocation strategy that will effectively allocate physical memory serially if there's no contention.
Put 1-4 together, and you get a system where a big mmap(2)ed file that takes up all the physical memory of an otherwise-idle system, will end up putting that thing into the same places each time (because that's the only place such a large allocation will fit.)
One possibility is that he didn't restart the program between retries, and the memory in question was already allocated. Another possibility is that he only ran handbrake and nothing else, and the OS was in more or less the same state both times. It could be that the problem was triggered by stack allocations rather than heap allocations and the video block in question caused a large-ish recursion that hit the problem, and would be likely to hit the problem no matter what was running since it's somewhat rare to have large stack allocations.
Chances are it was actually none of those things, but they're real possibilities anyway.
What with Windows Update and the variety of other similar OS- and application-level auto-updaters, is getting the computer into a very similar state likely? I'm not sure but my gut says no.
That said, at first I was imagining a desktop computer with 4 or 8 memory modules, but given a machine with just 2 modules, maybe it follows that one module usually gets filled with "core stuff" and the second, defective module somewhat infrequently sees "big user stuff" after the first module is filled, and I guess that isn't too much of a head-scratcher when it comes to identifying the source of the problem.
Actually, it does. It's possible to calculate WCET involving ram accesses, as the behaviour is deterministic; there's a set latency.
It's not possible whenever SWAP is involved, which is why most of the realtime world simply avoids swap. This is mentioned in the Genode handbook, if you're willing to dig into it more.
I assumed that swap wasn't involved, and I was even going to mention it but decided against. While it is remotely possible, there's not much reason to suspect swap, Handbrake was actively running, doesn't normally use enough memory to start swapping, and people ripping DVDs usually know not to be doing other things and/or using all their memory while ripping.
That said, are you saying swap in the OS really is non-deterministic by design, or just hard to predict? And what does Genode have to do with this, assuming he wasn't using Genode?
If Handbrake fails, it's only because your hardware is broken.
Since I used this machine to backup my data on DVDs I got many errors in my data on backup. But since I had a copy of everything on another HDD I throw the DVDs away and backed up everything again (after replacing defective RAM module and reinstalling OS and SW on my machine).
Which in itself alludes to the encoding stream itself (or one of the intermediate streams during the encoding process) having some form of strong channel coding - in error detection - either by design or not. Detect 1-bit error in a gig+ stream, perhaps without easily being able to locate it, beyond saying it's in such or such chunk (the current frame(s) being processed).
Though 1.0 usually has a different meaning in both world's.
1.0 usually includes a set of features the project had in mind at the beginning in open source. Whereas in closed source it usually means the first version that works to a minimal extent.
Closed source 1.0 equals open source 0 point something.
1.0 for some people, is 0.1 for others.
1.0 might mean it's stable, or it could meant that it's feature complete. As you say it could also be used to convey the confidence the developers have in the software.
The thing I find most important myself is conveying compatibility, i.e. semver. To me that tells me it will be easy to upgrade a library, or it could be hard.
Traditionally, version numbering has been used to signal the significance of the release. for version x.y.z, you could expect that
* x is incremented: Major new features, possibly incompatibilities
* y incremented but not x: Minor new features and bug fixes.
* z changed only: Bug fixes only.
Of cause there has always been a pressure from the marketing departments to have a new major release, while the engineers has been holding back, so you have always seen major releases that isn't that major, and sometimes incompatible changes sneaked into minor releases. The latter has generally been considered bad form.
Contrarily, I've noticed in Rails that A LOT of major refactoring and functionality has been added via minor bumps that, while still backwards compatible for Rails itself, often breaks custom implementations, usually related to javascript modules and configs.
Overall, though, I agree with you.
(When engineering and marketing aren't on the same page?)
HandBrake probably does not bring money to its developers, so the pace is inherently limited.
To give an example, it took VLC a long time to reach version 1, yet even in its 0.x releases it was amongst the best video players available (in terms of features, performance and stability), better than many other closed-source competitors with higher version numbers.
In other words, aside from libraries and programming languages (where major version numbers do have extra significance), version numbers are only loosely coupled to software quality.
For something in the middle - offering both convenience and scriptability - I recommend video_transcoding[1] (uses handbrake-cli and ffmpeg under the covers). It's a really handy set of command-line tools that eliminate a lot of the guesswork and frustration.
Do any small developers actually do this? It seems entirely useless from a security prospective. You go through an expensive process so that at the end it can "verify" that the binary was signed by an individual the user has never met who may not even live in the same country and for all anyone knows is perfectly willing to sign ransomware, or who has stolen some arbitrary third party's signing key.
If you don't actually know and trust the party who makes the software then the signature is worse than useless because it makes people think signed=trustworthy when in reality it only means signed=signed. And if you do know and trust the authors you don't need a CA to verify anything more, at great expense, when you can already just download via HTTPS from the domain you trust.
Apple should eliminate practice entirely, and in the meantime no one should use it.
Not true. The signature only needs to mean "we've verified the author's ID and he lives in a country that enforces the law". Then if he ships and signs malware, he can be sued and/or charged criminally.
This is what I mean by worse than useless. Promoting reliance on the signature to mean something.
To pick a country, quite a lot of entirely legitimate software comes out of Russia. So does a lot of malware. Does Russia enforce the law? Sure, against people who aren't politically connected. Some of the malware authors are, so you're screwed. You can't just write off a country like that. There is still a baby in that bathwater. And that's not the only country with organized crime or corruption.
As soon as you have many small developers signing things you can't even really exclude by country at all because there are too many soft targets for malware authors to steal keys from. Some college student gets a signing key to sign his calculator app and then gets hacked, and now there is malware signed by John Smith of New Jersey. By the time anyone figures it out the attackers, now equipped with the false sense of security created by the signature, have hacked many other people and captured even more signing keys.
It's like security theater where the criminals pick your pocket while you're distracted watching the show.
It's hard to talk about Gatekeeper without also talking about the Mac App Store, which as far as I can tell is a fiasco in all ways.
GPG signing and releasing fingerprints of all released artifacts on an https://-served release notice would accomplish nearly the same thing, but requires more steps and causes a confusing `“HandBrake” can’t be opened because it is from an unidentified developer.` dialog.
It is a best-practice to both GPG sign all release artifacts and use vendor-specific code-signing / app stores, otherwise conversion will suffer with each additional hoop multiplied by the N of the entire user-base resulting in much more time-wasting.
End-to-end integrity also prevents entire classes of attacks such as hacked CDNs, hacked networks and so on.
The "end-to-end chain-of-custody" is actually the problem, because it does two bad things.
First it encourages people to give it more faith than is due. Having an ironclad guarantee that something is approved by a specific untrustworthy person can do more harm than good when people see the guarantee and not the guarantor.
Second, when the process has barriers (e.g. for poor students or foreign nationals), you get a lot of legitimate software that isn't signed, which means you're harmfully desensitizing users to security warnings. Or locking out legitimate software.
Suppose you replace that with automatic GPG signatures, where the software has to be signed by the author but the author doesn't have to be signed by anybody else. You still have something useful -- you can verify that two pieces of software are from the same author. And that updates are from the same author as the original. And the author can publish their public key to their website, allowing security-conscious users to link the software to the trusted website.
Meanwhile signing becomes only a checkbox with no gatekeeper deciding who can and can't sign, no one is excluded, so everything can be signed there are no spurious security warnings for legitimate software.
Do not install untrusted, unverifiable apps is security 101.
I often download stuff for my children from YouTube using a YouTube downloader, and then transcode them to the ideal iPad format, so the children can watch stuff in the car on the iPad without an internet connection. Great for long trips.
And yes, great team.
Until hardware H.265 decoding is introduced to the popular media center hardware, H.264 will remain the codec of choice for most people.
Might never happen, thanks to netvc.
I'm not certain the scene releasers with reputations to maintain are going to release terrible quality rips.
And also some nice queue management, a bit better than what you'd get from shell scripting.
The downside is that it's a GUI.
The JSON API to interact with libhb also sounds interesting.
Myself personally, I feel quite comfortable with ffmpeg and I never had any problems with it so whenever I can I use it.
If a user types 3 + 4 [Enter] into a desktop calculator and gets 8, they probably would think the calculator is defective. If the calculator's manual documents that the 4 and 5 key had to be swapped for a legacy manufacturing reason, then who is at fault, the calculator or the user?
Confusing flags and poor defaults that cause the user [1] to misuse the software are "bugs" too, regardless of whether the author intended it to work that way.
[1] We're talking about the collective user here, a UI will never be intuitive to 100% of your users, but if only 5% of your users understand it that's a problem.
The FFmpeg project produces libraries for handling digital multimedia, and it also offers a command line application. Handbrake, on the other hand, is a GUI-based application meant for DVD ripping and video transcoding. These two projects may appear to share many goals, but there is little end-user overlap and they serve quite different purposes. And I might add -- both projects are _outstanding_.
Handbrake has a specific set of tasks on which it focuses. FFmpeg, on the other hand, endeavors to provide a powerful set of multimedia codecs, container handling libraries, codec- and bitstream-level filters, a high-performance scaler, etc.
In other words, FFmpeg's command line application is meant to be used by power users who know exactly what they are trying to do and what they need done to their files to produce that outcome. Handbrake, despite its extensive feature set, simply does not expose the low-level functionality that FFmpeg/libav does. Under the hood, a lot is going on in Handbrake about which the user is totally unaware.
To take an example from the OP -- in order to avoid faulty initiation of an audio track in a video, an FFmpeg user must explicitly rebuild the output container's time base. If the team is not knowledgeable in these lower-level areas of digital media, then it seems totally logical for them to use Handbrake. Handbrake will auto-detect the need to do this process for each individual source and implement it without even informing the user in its log output.
The FFmpeg project is not responsible for teaching software developers about the fundamentals of digital multimedia, and it is not a 'bug' that they don't do so.
- a gui
In short - just fine to use and it's the default (without -strict) now.
There's a built-in ffmpeg AAC encoder too, but despite the author's claims it is not as good as libfdk_aac.
And libfdk_aac itself isn't as good as Apple's AAC codec either. There's a Hydrogenaudio listening test demonstrating that.
It worked surprisingly well. Glad to see a new version of this released.
By 60 minutes in the sound is a full five second behind the video.
For everything else I loved it.
I haven't used either in a long time and would appreciate the input.
Could've fooled me...
There's no good reason not to use a secure hash function.
I'm not sure why they haven't retroactively calculated checksums for older versions.
But you're right that SHA-1 needs to stop being used: https://sites.google.com/site/itstheshappening/
These researchers have found the first "freestart" collision, and they estimate the SHA-1 collision cost to take a few months, costing between 75K$ and 120K$.
Practically speaking, I don't think anyone could make a profit by forging a Handbrake release, but the FBI probably do have some very high-profile targets who use video encoding software.