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

HandBrake 1.0.0 Released

handbrake.fr

Post reply on HN
Print view View original

141–150 of 181 posts

Re: HandBrake 1.0.0 Released

#141

Post by seanalltogether »

AnthonyMouse wrote: post #98
NelsonMinar wrote: post #60

I'm a little surprised they aren't signing their MacOS releases. It's even documented on the download page, "We are not currently able to sign the HandBrake downloads". I wonder if it's a philosophical choice or a legal one? It seems like a failure of Apple's Gatekeeper though: either because such a popular app is not able to be signed, or because it's not signed and yet so many people run it anyway.

> I'm a little surprised they aren't signing their MacOS releases. 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…

There is no expense to have a developer account with Apple to sign releases. You have to pay to distribute on iOS or Mac App store. At this point so much of it is automated by xcode that there are no real extra steps to do simple developer signed release.

Re: HandBrake 1.0.0 Released

#142

Post by eltoozero »

ZenoArrow wrote: post #75
walterbell wrote: post #65

Earlier quoted context omitted.

What's the best software for lossless archival ripping?

This is an interesting one, in that most data on DVDs is already stored in lossy formats (such as MPEG-2 for video https://en.m.wikipedia.org/wiki/DVD-Video ). The best form of preservation is to rip the contents as a DVD ISO, which will use the same video and audio formats, as well as preserving extra features like the DVD menus. Any DVD ripper that can rip to a DVD ISO format and perform checksums on the ripped con…

h.264 or h.265 is going to yield a much better compression ratio for equivalent quality, even after transcoding formats.

On the order of 2:1 or 3:1 vs MPEG2 format for DVD.

Re: HandBrake 1.0.0 Released

#143

Post by ZenoArrow »

eltoozero wrote: post #142
ZenoArrow wrote: post #75

Earlier quoted context omitted.

This is an interesting one, in that most data on DVDs is already stored in lossy formats (such as MPEG-2 for video https://en.m.wikipedia.org/wiki/DVD-Video ). The best form of preservation is to rip the contents as a DVD ISO, which will use the same video and audio formats, as well as preserving extra features like the DVD menus. Any DVD ripper that can rip to a DVD ISO format and perform checksums on the ripped con…

h.264 or h.265 is going to yield a much better compression ratio for equivalent quality, even after transcoding formats. On the order of 2:1 or 3:1 vs MPEG2 format for DVD.

Lossy in top of lossy is never going to be the best approach for archival purposes, which is what the GP was looking for.

If the question was about balancing quality and file size I would've given a different answer.

Re: HandBrake 1.0.0 Released

#144

Post by AnthonyMouse »

seanalltogether wrote: post #141
AnthonyMouse wrote: post #98

Earlier quoted context omitted.

> I'm a little surprised they aren't signing their MacOS releases. 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…

There is no expense to have a developer account with Apple to sign releases. You have to pay to distribute on iOS or Mac App store. At this point so much of it is automated by xcode that there are no real extra steps to do simple developer signed release.

The expense isn't so much money you pay to Apple, it's the typically multiple hours and hundreds of dollars necessary to get an EV certificate from a CA.

Re: HandBrake 1.0.0 Released

#145

Post by AndrewUnmuted »

KerrickStaley wrote: post #57
AndrewUnmuted wrote: post #26

Earlier quoted context omitted.

The issues you bring up are not deficiencies with ffmpeg, but rather the user. One can prevent all of the issues you cited with the correct ffmpeg commands and an understanding of how media codecs and containers work.

An issue that causes the user to misuse the software can rightfully be considered a bug. 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 th…

I don't disagree with your opening sentence, but your premise is likely based on an incomplete understanding.

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.

Re: HandBrake 1.0.0 Released

#146

Post by dexterdog »

EvanAnderson wrote: post #28
AndrewUnmuted wrote: post #25

Earlier quoted context omitted.

Why transcode just to package media into an mkv container? Mkv is pretty much codec agnostic, you could probably just steam copy. You'll save a lot of time and audio-visual quality by doing so.

I transcode because H.264 saves me a lot of space over MPEG 2. I don't notice the quality loss but I do notice the disk space and faster file transfers.

Also, most modern players are much faster at seeking through a proper mkv that an old avi or a much larger file.

Re: HandBrake 1.0.0 Released

#148

Post by sp332 »

Fnoord wrote: post #121
witty_username wrote: post #73

Earlier quoted context omitted.

Yes, but it stops easy copying. Don't let good be the enemy of perfect.

Ironically, you're allowed to make a copy for yourself if you rent.

But you have to delete the copy when you give the original back so what's the advantage?

Re: HandBrake 1.0.0 Released

#149

Post by AndrewUnmuted »

dexterdog wrote: post #146
EvanAnderson wrote: post #28

Earlier quoted context omitted.

I transcode because H.264 saves me a lot of space over MPEG 2. I don't notice the quality loss but I do notice the disk space and faster file transfers.

Also, most modern players are much faster at seeking through a proper mkv that an old avi or a much larger file.

This is true indeed, mkv is a great container. The reason for my question was that the OP appeared to be transcoding (a codec-level operation) just to switch the container type. When it was mentioned that the transcode was to convert from MPEG-2 to H.264, my question was answered. :)

Re: HandBrake 1.0.0 Released

#150

Post by JshWright »

aianus wrote: post #112
JshWright wrote: post #78

Earlier quoted context omitted.

Verifying a downloaded file doesn't require a cryptographically secure hash function...

Of course it does, otherwise a malicious mirror can (theoretically) work to find a collision between their malware and the legitimate file and serve you the former. There's no good reason not to use a secure hash function.

If your threat model involves an attacker who is able to achieve a hash collision while still implanting a sophisticated malware, you should probably avoid downloading software from random websites...
Post reply on HN