It's time for another snapshot binary. It's been a few months, and there have been lots of changes. As the list below will reveal, the most apparent change to users is SRT subtitle support and a number of improvements to closed captioning support. Hopefully, stability's improved. But, then, that's what you're going to find out for us.
This is a snapshot release of SVN revision 2773. It is not stable code. It is unstable (and undocumented) development code which will one day lead to a stable release of HandBrake 0.9.4. But in order for that process to happen, it needs a lot more bug testing.
When you find broken things in this snapshot--which you will--post a thorough bug report in our bugs forum. Don't pay too much attention to interface issues at this point. We know some things are still kind of rough around the edges. The biggest concern right now is the fundamentals -- that encodes perform as expected. Prettying things up more will come later.
x264 bumped from 1169 to 1195, which means new default settings (see r2742 commit comment). Note: it's not the latest rev because we're holding off on mbtree for now in the trunk.
Leaves closed captioning capitalization alone
Closed captioning style markup
ATSC closed caption support
Workaround for libdvdread malloc bomb on invalid PGC entry
DVD drive region detection support in Linux
New mode structure for the decomb filter
Handles DVD programs with more than 16 streams
Caters to Theora's insistence on content having mod16 framing dimensions specified
Fixed interjob framerate calculation
Fixed pthreads regression in cygwin
Fixed timing for first two frames coming out of filters
No longer tries to detect and discard duplicate titles when scanning
No longer truncates the last (dummy) chapter of non-DVD sources
MacGUI:
SRT subtitle import
Queue displays varying row heights based on encode settings
Foreign language subtitle search integrated into live preview
Fixed quality slider for ffmpeg and theora
More responsive HUD
WinGUI:
SRT subtitle import
Growl for Windows notification support
General UI improvements
Preset import
Custom anamorphic improvements
Preferred language control for audio dubs and subtitles
Fixed file extensions resetting to m4v when enabling chapter markers in mkv
Faster updating of GUI elements from CLI data
LinGUI:
SRT subtitle import
Preset import/export
General UI improvements
Preferred language control for audio dubs and subtitles
BTW: .srt support is a great idea but I have a question: can these kind of subtitles be burned directly into video stream?. If the answer is yes I will be really happy because I use the encoded videos in a non subtitle stream capable device. I tried to make it but it show the column "Burned in: No" in the srt track list and I don't find how to change it...
Thanks and best regards (and excuse my poor english).
great job on the new snapshot! I'm not sure if it's a bug or not, but I can't seem to be able to select the m4v file extension with the svn2773 snapshot (svn2773 x86_64 (2009082401)). What is going on?
Edit: Thanks for the quick reply!
Last edited by Nemesis7 on Mon Aug 24, 2009 1:40 pm, edited 1 time in total.
themacjedi wrote:I don't even know if this is possible but can you try to include support for the iPhone 3.0 new features of, 30 second rewind, 2X play & 1/2X play?
I know those features work on podcasts but I don't know what they're limited to.
Those are pretty nice features especially the 30 second rewind.
They are limited to audio only, so they do not apply.
I cant find the "Picture setting" button under Mac GUI. I need that to select "detelecine". May be I missed something, but on 0.93 version, its right there under the video tab on the right side.
Thx,
Suz
On OSX, is there any difference between the 64bit and 32 bit other than ones 64bit and ones 32bit? I think I remember older versions of the 64bit version could not rip dvds from disc.
Lostless wrote:On OSX, is there any difference between the 64bit and 32 bit other than ones 64bit and ones 32bit? I think I remember older versions of the 64bit version could not rip dvds from disc.
Under Mac OS X, HandBrake uses VLC to decrypt DVDs. A 32-bit HandBrake build requires a 32-bit VLC build; 64-bit HB requires 64-bit VLC.
Should performance be reduced for these snapshot builds? I ask because I'm ripping blu ray and I'm only averaging about 6 fps when encoding from a mkv file at 720p. Takes about 4-5 hours per file. When I encoded at 1080p it took about 16 hours!! I have a iMac core 2 duo so I would think I'd get better performance, but maybe not since it's HD. A SD movie takes about an hour or so. Any thoughts?
Is it possible to have a feature that lets users choose CPU intensitive under video compression In example low, medium or high. Ranging from apr 20% CPU usage—100% CPU usage (single core). I wouldnt mind if it takes days to compress a good movie.
sadcaper wrote:Should performance be reduced for these snapshot builds? I ask because I'm ripping blu ray and I'm only averaging about 6 fps when encoding from a mkv file at 720p. Takes about 4-5 hours per file. When I encoded at 1080p it took about 16 hours!! I have a iMac core 2 duo so I would think I'd get better performance, but maybe not since it's HD. A SD movie takes about an hour or so. Any thoughts?
Oh, encoding HD movies that have up to 6 times as many pixels as SD movies is slower, big surprise there
This snapshot isn't slower than 0.9.3 (or than the previous snapshot, for that matter). If anything, it's faster. And yes, HD takes longer to encode.
sadcaper wrote:Should performance be reduced for these snapshot builds? I ask because I'm ripping blu ray and I'm only averaging about 6 fps when encoding from a mkv file at 720p. Takes about 4-5 hours per file. When I encoded at 1080p it took about 16 hours!! I have a iMac core 2 duo so I would think I'd get better performance, but maybe not since it's HD. A SD movie takes about an hour or so. Any thoughts?
Oh, encoding HD movies that have up to 6 times as many pixels as SD movies is slower, big surprise there
Encoding a Blu-Ray stream gives me troubles at around 0.13 % of the encoding, with and without turbo first pass I get the same result. The Mac OS X version doesn't even start encoding...