Ever wondered about the toolset of pirate movie groups?
Typically it involves demuxing the source with eac3to, decoding and indexing the video stream for avisynth (often with ffms2 for Blurays), filtering (such as resizing with a spline kernel, debanding, fixing dirty lines, fixing double range compression, correcting aliasing, removing edge enhancement artifacts, deinterlace/ivtc for DVDs etc.), followed by piping it out through avs2yuv to the x264 encoder. x264 parameters are often hand-tuned over a series of short test encodes at a fixed bitrate. Audio streams are left as is, stripped to the core (DTS-HD MA -> DTS) or transcoded to AC3 (Sony Soundforge), DTS (DTS-HD Master Audio Suite), AAC (qaac/fdkaac) or FLAC. Bitmap subtitles are ripped to text .srt files with subextractor/suprip/SubtitleEdit/ and spell-checked. Finally everything is muxed back together with mkvmerge.
I haven't looked too deep into Handbrake in a few years (so someone correct me if I am wrong), but I don't think they use ffmpeg. Their core, the codec libraries, is mostly the same as ffmpeg, but ffmpeg is not the "foundation" of Handbrake
If the task requires anything more complex than simple transcoding or encoding, then ffmpeg will require a user to understand DSP to some extent to be used successfully.
Of course this is no fault of ffmpeg, but a lot of frustrated users end up thinking that anyway.
Some interesting analysis here, but I think you are analysing a video far too heavily in the spatial space i.e at frame level, this doesn't particularly give reliable results as compression and hence artifacts can vary according to frame in time.
Video needs to be analysed ideally in the temporal space (i.e as a sequence). I see no mention of the GOP structure or length of the encoding chosen, which would need to be considered.
For example the one frame you have chosen to compare could be an I frame in some of the video compression or could be a P or B frame which would result in slight variance in quality and artifacts.
> "I dumped all the images into separate PNG files, and then used sips to convert the PNGs to somewhat-more-reasonably sized JPGs"
You are adding further compression to the PNGs (the frame grabs) by using JPEG (I assume you are using it in lossy mode), which is basically adding another form of compression to your results.
The fact you used JPEGs (further compression) for comparison basically null and voids all the results I am afraid.
When I open Handbrake, it's usually because I have a video that won't play in some device/program. For example, I have an mkv but my Chromecast only supports MP4. I found out recently that Handbrake isn't always the best option.
Oftentimes you want to remux the video, which means copying it to a new container format without touching the underlying stream. Handbrake doesn't support remuxing (no idea why); you have to turn to ffmpeg on the commandline [1]. Remuxing works if the video and audio codecs are supported by your target but the container isn't, and is very fast—about as fast as copying the file.
With remuxing you still have the option of changing the order of the audio tracks. For example, you can take a Cantonese film with a Mandarin dub and make the Mandarin dub primary so you don't have to fiddle with it (protip if you're learning Mandarin: all the good movies are in Cantonese but they all have Mandarin dubs).
[1] There are GUI options that I haven't explored, see below.
I've done shedloads (500+ discs) of rips through hand brake, mostly DVDs and some Blu-Rays.
What I discovered was, that unless you are rippling losslessly, your results will vary greatly from film to film.
The advice I give out is:
1. Start with the recommended defaults in Handbrake.
2. Rip a film you know well.
3. View that film on ALL platforms you are likely to view it on. [a]
If you are happy. You are done - keep ripping discs.
If not:
4. Adjust quality up/or down goto #2. Repeat until happy.
Do the above for each GENRE of film - Bright Action movies need different ripping specs compared to period dramas.
--
[a] I did not do this step originally, and the first batch of rips I did, looked good on my 24" monitor, good on my 50" plasma, and awful on my 9ft projector screen!
Pay special attention to videos whose source is TV (as opposed to film) because those sources tend to be interlaced, and you need to play around with the detelecine, decomb, and deinterlace settings. Unfortunately AFAIK Handbrake cannot detect this condition, and if you don't manually account for it, you'll get that ugly horizontal "comb" effect on output, during scenes showing motion.
I was using Handbrake to rip the DVDs of a certain low-budget 90's TV show (I am too embarrassed to say which) and noticed that certain special effects could confuse/anger Handbrake. Specifically, some cheap effect used to give a flat image the illusion of depth by making its outline gyrate back and forth combined with a lens flare, the effect was muted/eliminated when Handbrake ripped it, as though Handbrake was trying to stabilize the video or something. The effect was still visible on the raw MKV rip, but not after Handbrake's transcode.
Both of this tools use the same encoders under the hood, what you see here is just comparing different settings in default presets they provide. If you would like to experiment yourself with x264 encoding you can find descriptions of possible options here http://www.chaneru.com/Roku/HLS/X264_Settings.htm
I really can't say enough about how great the transcode-video library is in terms of "set it and forget it".
When I cut the cord I started down the path of figuring out how to do all the optimizations myself, but quickly realized just how deep and technical that was. I stumbled upon Don Melton's library and have used it as a key piece of my batch processing pipeline ever since.
Definitely check it out if you are looking to convert arbitrary video files to be played back later on arbitrary devices:
It is really confusing and super annoying that the author keeps calls 2 totally different tasks "ripping".
First, the author calls extracting the video/audio of the movie from the Blu Ray (and circumventing the DRM) "ripping". Quote from Article "On the Blu-ray, the music video is 2:18 long. When I ripped it to the hard drive using MakeMKV, the final file size was 279MB."
But then the author also calls encoding the extracted video/audio using HandBrake or transcode-video "ripping". Quotes from the article: "I then fed this .mkv file to both HandBrake and transcode-video, running it through all 26 different conversion options. This table shows the results, sorted by ripping app first..." and "I then copied that same frame from all 26 of the ripped versions of the music video..."
No! No you didn't! You ripped the movie once, and then encoded that 26 times, each time using different options, to compare encode-time, size, and attempted to compare the output quality.
Honestly, confusing these 2 fundamental concepts makes me seriously question your entire experiment.
Handbrake settings are hard. A few years ago I did a project that involved finding the appropriate settings to use[1]; it took me several weeks to go through all of the settings, look them up, figure out what they did, and test them to see what the correct value was. Some of the settings are (or were) really poorly documented--for example, why wouldn't you want iPod 5G support? Well, apparently it "breaks compatibility with certain players," though I couldn't find any data on which players would break.
That's because the effects are hard... in general, I find it much easier than trying to fiddle with ffmpeg or similar.
I tend to rip most things with one of two configs I have.. one for br/1080p, another for DVD, and I have a tweaked DVD for bad content (Think Babylon 5)... It took a while to find settings I generally like. I've also taken to letting things run for h.265, since I'm pretty concerned about the space on my nas.
If you aren't trying to match YIFY on your sizes, then you can get away with being a bit more loose on your configs.
I always preferred StaxRip. It ties all the tools together like Handbrake but gave you all the power of the CLI. It looks like the author is trying to completely re-work it in x64 now: https://github.com/stax76/staxrip
The critical problem I see with encoded films is what happens in high-action scenes. Often the detail is "good enough" for me until all of a sudden things start happening and you can really see degradation.
Thus I don't find their method of looking at stills to be all that compelling.
That happens for BD or streaming because complex scenes hit the bitrate-per-second cap (VBV maxrate) and quality has to take a hit to fit all the bits in.
If you're working from a source without problems, and they're ending up in the result, Handbrake might be enforcing max rate to hit the H.264 "level" conformance, so "level 5.0" might help. Don't remember if it's got an option for that.
i'm comfortable using ffmpeg, i just wish people would share their secret formulas that can:
- take a video of varying format (mov, mp4, webm, mkv)
- give it the desired output resolution
- give it the desired output quality preset (simple will do - hi, med, low)
- output resulting file(s)
- do it fast
i have a giant shell script of ffmpeg commands i've used in the past, but i have to stop myself from getting sucked in to trying to understand the whole process and losing a whole day at work
I spent a bit of time trying to understand ffmpeg last year (seems like you need to re-learn the codecs and best practices every few years!) and wrote some notes down on a blog post. Hope it helps someone other than me!
In another post, the author mentions a particular Pioneer Blu-ray drive that he uses with his Mac. Are they all pretty much the same, or are some models preferred?
I've just bought random USB drives that don't advertise Mac compatibility at all and never had any issues with ripping nor burning. Brands like Buffalo and Logitec (no H). They're all basically the same ATAPI drives inside a generic USB controller.
[+] [-] msimpson|9 years ago|reply
You'd be better off diving into the foundation of HandBrake and using it directly:
https://trac.ffmpeg.org/wiki
Also, in before, "ffmpeg is too complicated for the average user ..." It isn't, you just need to RTFM.
[+] [-] puzzlingcaptcha|9 years ago|reply
Typically it involves demuxing the source with eac3to, decoding and indexing the video stream for avisynth (often with ffms2 for Blurays), filtering (such as resizing with a spline kernel, debanding, fixing dirty lines, fixing double range compression, correcting aliasing, removing edge enhancement artifacts, deinterlace/ivtc for DVDs etc.), followed by piping it out through avs2yuv to the x264 encoder. x264 parameters are often hand-tuned over a series of short test encodes at a fixed bitrate. Audio streams are left as is, stripped to the core (DTS-HD MA -> DTS) or transcoded to AC3 (Sony Soundforge), DTS (DTS-HD Master Audio Suite), AAC (qaac/fdkaac) or FLAC. Bitmap subtitles are ripped to text .srt files with subextractor/suprip/SubtitleEdit/ and spell-checked. Finally everything is muxed back together with mkvmerge.
[+] [-] monochromatic|9 years ago|reply
[+] [-] apocalyptic0n3|9 years ago|reply
[+] [-] AndrewUnmuted|9 years ago|reply
Of course this is no fault of ffmpeg, but a lot of frustrated users end up thinking that anyway.
[+] [-] pmorici|9 years ago|reply
[+] [-] nom|9 years ago|reply
[+] [-] doc_holliday|9 years ago|reply
Video needs to be analysed ideally in the temporal space (i.e as a sequence). I see no mention of the GOP structure or length of the encoding chosen, which would need to be considered.
For example the one frame you have chosen to compare could be an I frame in some of the video compression or could be a P or B frame which would result in slight variance in quality and artifacts.
[+] [-] doc_holliday|9 years ago|reply
> "I dumped all the images into separate PNG files, and then used sips to convert the PNGs to somewhat-more-reasonably sized JPGs"
You are adding further compression to the PNGs (the frame grabs) by using JPEG (I assume you are using it in lossy mode), which is basically adding another form of compression to your results.
The fact you used JPEGs (further compression) for comparison basically null and voids all the results I am afraid.
[+] [-] KerrickStaley|9 years ago|reply
Oftentimes you want to remux the video, which means copying it to a new container format without touching the underlying stream. Handbrake doesn't support remuxing (no idea why); you have to turn to ffmpeg on the commandline [1]. Remuxing works if the video and audio codecs are supported by your target but the container isn't, and is very fast—about as fast as copying the file.
With remuxing you still have the option of changing the order of the audio tracks. For example, you can take a Cantonese film with a Mandarin dub and make the Mandarin dub primary so you don't have to fiddle with it (protip if you're learning Mandarin: all the good movies are in Cantonese but they all have Mandarin dubs).
[1] There are GUI options that I haven't explored, see below.
[+] [-] Jaruzel|9 years ago|reply
[+] [-] petecooper|9 years ago|reply
http://www.emmgunn.com/mp4tools-home/
[+] [-] seanalltogether|9 years ago|reply
for i in *mkv; do ffmpeg -i "$i" -vcodec copy -acodec copy "${i%.mkv}.mp4"; done;
[+] [-] paulmd|9 years ago|reply
[+] [-] Jaruzel|9 years ago|reply
What I discovered was, that unless you are rippling losslessly, your results will vary greatly from film to film.
The advice I give out is:
1. Start with the recommended defaults in Handbrake.
2. Rip a film you know well.
3. View that film on ALL platforms you are likely to view it on. [a]
If you are happy. You are done - keep ripping discs.
If not:
4. Adjust quality up/or down goto #2. Repeat until happy.
Do the above for each GENRE of film - Bright Action movies need different ripping specs compared to period dramas.
--
[a] I did not do this step originally, and the first batch of rips I did, looked good on my 24" monitor, good on my 50" plasma, and awful on my 9ft projector screen!
[+] [-] ryandrake|9 years ago|reply
Pay special attention to videos whose source is TV (as opposed to film) because those sources tend to be interlaced, and you need to play around with the detelecine, decomb, and deinterlace settings. Unfortunately AFAIK Handbrake cannot detect this condition, and if you don't manually account for it, you'll get that ugly horizontal "comb" effect on output, during scenes showing motion.
[+] [-] AdmiralAsshat|9 years ago|reply
[+] [-] ValentineC|9 years ago|reply
Ripping from DVD and Blu-rays is a lossless process involving the removal of DRM.
Encoding is where the space-saving magic happens, and where settings, and more importantly, bitrate, can lead to varying levels of quality.
[+] [-] lossolo|9 years ago|reply
[+] [-] stplsd|9 years ago|reply
[+] [-] JamesSwift|9 years ago|reply
When I cut the cord I started down the path of figuring out how to do all the optimizations myself, but quickly realized just how deep and technical that was. I stumbled upon Don Melton's library and have used it as a key piece of my batch processing pipeline ever since.
Definitely check it out if you are looking to convert arbitrary video files to be played back later on arbitrary devices:
https://github.com/donmelton/video_transcoding
[+] [-] j_s|9 years ago|reply
http://webcache.googleusercontent.com/search?q=cache:robserv...
[+] [-] billyhoffman|9 years ago|reply
First, the author calls extracting the video/audio of the movie from the Blu Ray (and circumventing the DRM) "ripping". Quote from Article "On the Blu-ray, the music video is 2:18 long. When I ripped it to the hard drive using MakeMKV, the final file size was 279MB."
But then the author also calls encoding the extracted video/audio using HandBrake or transcode-video "ripping". Quotes from the article: "I then fed this .mkv file to both HandBrake and transcode-video, running it through all 26 different conversion options. This table shows the results, sorted by ripping app first..." and "I then copied that same frame from all 26 of the ripped versions of the music video..."
No! No you didn't! You ripped the movie once, and then encoded that 26 times, each time using different options, to compare encode-time, size, and attempted to compare the output quality.
Honestly, confusing these 2 fundamental concepts makes me seriously question your entire experiment.
[+] [-] acomjean|9 years ago|reply
Was it really that hard to see what they were doing?
I thought the analysis was well written, and the screenshots helped show what was going on, terminology problems aside.
[+] [-] wolfgang42|9 years ago|reply
[1]: http://www.linestarve.com/blog/post/rendering-html5-video-wi...
[+] [-] tracker1|9 years ago|reply
I tend to rip most things with one of two configs I have.. one for br/1080p, another for DVD, and I have a tweaked DVD for bad content (Think Babylon 5)... It took a while to find settings I generally like. I've also taken to letting things run for h.265, since I'm pretty concerned about the space on my nas.
If you aren't trying to match YIFY on your sizes, then you can get away with being a bit more loose on your configs.
[+] [-] ukyrgf|9 years ago|reply
[+] [-] PaulHoule|9 years ago|reply
Thus I don't find their method of looking at stills to be all that compelling.
[+] [-] astrange|9 years ago|reply
If you're working from a source without problems, and they're ending up in the result, Handbrake might be enforcing max rate to hit the H.264 "level" conformance, so "level 5.0" might help. Don't remember if it's got an option for that.
[+] [-] elzi|9 years ago|reply
[+] [-] aorth|9 years ago|reply
https://mjanja.ch/2016/07/video-encoding-for-the-web-in-2016...
[+] [-] SloopJon|9 years ago|reply
[+] [-] kalleboo|9 years ago|reply
[+] [-] relics443|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]