-
After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.
Help Anyone converting movies with Handbrake yet? (or other tools)
- Thread starter legacy
- Start date
-
- Tags
- htc evo 3d
I'm very curious as to how much the decoder can handle in terms of bitstream features. How many reference frames, B-frames (and attendant features as bime, pyramid, etc), weighted P-frames, framerates, max resolutions, etc.
Ideally one would be able to encode only once -- and that encode would look great both on the PC and the phone. My suggestion in this case is 720p -- even though the phone's screen can't support it, its HDMI-out certainly can, and so can your computer and other devices which could play 720p.
Of course, the definition of what is "good" quality to anyone's eyes varies per person, and the lower quality limit is likely significantly lower on the handheld than on your 19" computer screen (or 42" TV).
Therefore, my suggestion is to wait until the device comes out and is put through the paces before encoding anything for it. Once it does come out and you can test it out (or someone else can do the testing -- I certainly will, for one, the moment I get my 3VO!), you can then encode to the maximum AVC features the device supports.
yourfriendmat
Well-Known Member
For me, I'm turning my 3D Blurays into side-by-side mp4s at 540x960. This is the format in which I'm assuming the device records video, so it should be able to play it this way. Maybe I'll ask the Wirefly guy on youtube about the format of the video sample he showed.
EDIT: Forgot to mention that I'm doing it at that resolution because I don't want to waste space on my SD card and I don't really plan on sharing the video with an external display.
EDIT: Forgot to mention that I'm doing it at that resolution because I don't want to waste space on my SD card and I don't really plan on sharing the video with an external display.
"Format" means a lot more than many people might think it does. For instance, it's possible to put hundreds of entirely different video standards of identical framerates and resolutions into an .avi file (the extension of a media file denotes only the container into which the 'formats' are packed). Although there is some popularity bias among formats (AVI today is almost expected to contain MPEG-4-ASP with no QPel or GMC -- the likes of old 'default' Xvid/DivX encodes), this largely holds true nevertheless.
Resolution and framerate are only a small part of the puzzle (you should always aim to preserve native framerate, by the way -- 'real' native framerate, however, for telecined sources and the like, might be harder to attain than one might think).
Currently, the most modern and usable of the popular video standards (and that supporting the greatest amount of compression yet also enjoying hardware accelerated playback on mobile devices) is level-restricted 8-bit YV12-colorspace h.264/AVC in either the MP4 or MKV containers. But that's still just as ambiguous as saying "the most popular article of clothing to wear is a pair of pants," since although you've identified the general type of clothing, you still say nothing about the pants themselves -- what material, color, garment style, length, thickness, fastening design, etc.
It's good to know these things when creating your own encodes. When you make a pair of winter pants for your 8-yr old daughter, you wouldn't take two 3-meter rolls of dried leaves tied to a paper-mache basket and still deem it a suitable pair for the occasion. Maybe in some bygone primordial era this was the best you could do (if you could cram her into such a contraption), but today it's both silly and wasteful to do so in the presence of much more suitable possibilities of higher quality and better fit.
Using a stock 'iPod' preset has been a bit silly with Android devices for some time now. Most software that caters to the "iPod" use very, very poor encoding features by Android's standards. Baseline (notice the word here, "baseline") h.264 with vastly sub-par CUDA/x264/Nero/DivXHD encoder presets represents a very limited (and therefore significantly lower-quality) subset of the potential of the very same underlying h.264 'format' being used.
Ideally, then, one should seek to encode their files to the greatest level of encoding complexity their mobile device supports in order to avoid wasting significantly more space on potentially lower quality output video. When done correctly, encoding even 720p content at this complexity limit would result in truly versatile files you can keep on your computer, share with friends (be careful to observe copyright restrictions), display on a larger screen via HDMI/MHL, or simply play back in high quality on the device and its own qHD screen (recall that this native resolution is so high already that 720p videos are only 33.3% larger in each direction anyway).
novox77
Leeeroy Jennnkinnns!
For me, if I'm going to put a movie on my phone, I'm only going to use that file with the phone. It will allow me to fit a lot more videos on the sdcard. Space is kinda valuable on the phone; not so on the desktop/laptop where I have tons of disk space and I can DLNA to the TV rather than use the phone as the media server.
It will be a while before I have a TV that supports MHL, and I'm not so keen on buying the cables/adaptors to dual stream and charge with the phone.
My video sources are going to be my blurays (1080p) and DVDs (480p). So encoding to 720p just to put it back on the TV doesn't make sense for either scenario. One results in reduced quality. The other results in an enlarged 480p-quality image, which doesn't look very good.
OTOH, for someone who exclusively uses the phone to provide video content to the TV, encoding in 720p would make perfect sense, given that the source video is 720p or higher.
It will be a while before I have a TV that supports MHL, and I'm not so keen on buying the cables/adaptors to dual stream and charge with the phone.
My video sources are going to be my blurays (1080p) and DVDs (480p). So encoding to 720p just to put it back on the TV doesn't make sense for either scenario. One results in reduced quality. The other results in an enlarged 480p-quality image, which doesn't look very good.
OTOH, for someone who exclusively uses the phone to provide video content to the TV, encoding in 720p would make perfect sense, given that the source video is 720p or higher.
My argument was that 720p files, properly compressed, can be both small enough to fit well on an SD card and look "good" on the PC/TV all in one. Downscaling many 1080p Blu-rays isn't such a losing option for many of them -- quality can still be "good enough", especially if you're aiming to cram your 200 movie collection on that computer hard-drive. I rarely encode to 1080p (except for a few exceptional sources), so I'd rather have a decent 720p file that works with the whole range. Doing so nets you:
- Portability -- one file works everywhere
- Reduced encoding time -- one encode is all you need
- Universal, tweakable balance of quality vs size -- it is now possible to have your movies in great quality at much lower sizes than 5 years ago
- Very little space 'loss' -- with only 33.3% more vertical and horizontal size, 720p still fits well enough without waste on a qHD screen, especially considering h.264's 16x16 macroblocks (and HP 8x8 adaptive transform size). It's not a linear filesize increase per additional unit of area, especially on scalings of the same video.
- Huge overall PC space savings -- you can maintain just one library of your movies, not two as would be necessitated by the dual-encode approach. (If you're not keeping a dual-library in the dual-encode approach, "you're doing it wrong" -- how else would you swap out a dozen movies from that microSD card for others? Encode them again?)
And yes, well said, novox77. Allow me to also reiterate a burning truth in the encoding realm: obviously, one should NEVER upscale any video (except on the PC during playback), for that wastes time and space for zero apparent gain.
yourfriendmat
Well-Known Member
@fattank
In general, I understand what you're saying (the analogy helps), but I'm not well versed in the video coding realm. I know that less pixels = less file size, and higher compression = smaller file sizes. And obviously both of these can reduce quality of the output.
However, my point is similar to novox's. I have all of the original sources for my converted files, so I have no real need to have them at a quality appropriate for an external display. Also, while I admit I didn't use the terminology correctly, the logic still stands that the container for the 3D files is likely a common format since, in the video review, he was able to incorporate it into the video with no mention of format or difficulty of conversion. Lastly, we still don't know what sort of format/compression/container/etc. we should use to optimize video output on the Evo 3D. How would we figure that out?
You do make good points, but I think until we understand the way the device will work, we can't really apply the information.
In general, I understand what you're saying (the analogy helps), but I'm not well versed in the video coding realm. I know that less pixels = less file size, and higher compression = smaller file sizes. And obviously both of these can reduce quality of the output.
However, my point is similar to novox's. I have all of the original sources for my converted files, so I have no real need to have them at a quality appropriate for an external display. Also, while I admit I didn't use the terminology correctly, the logic still stands that the container for the 3D files is likely a common format since, in the video review, he was able to incorporate it into the video with no mention of format or difficulty of conversion. Lastly, we still don't know what sort of format/compression/container/etc. we should use to optimize video output on the Evo 3D. How would we figure that out?
You do make good points, but I think until we understand the way the device will work, we can't really apply the information.
I'd trust the Sensation specs from HTC for the containter type:
And just like with the Evo, consider a good media player that extends the playback capabilities over that offered by HTC, as needed.
I'd guess going in that if your targets are H.264-vid/AAC-sound (H.264 and AAC are codecs) within a .mp4 file (container), you ought not suffer too much grief.
That said - while H.264/AAC are popular, your BD movies may be encoded using other codecs - it would seem to me if your tools were to tell you that, you could find a downsampling scheme, perhaps resulting in a .wmv file where you were only increasing compression, and not changing codecs (transcoding) at the same time. I could be wrong on that - but I'm kinda sure that BD movies come in more than just one way.
http://en.wikipedia.org/wiki/Blu-ray_Disc#Codecs
yourfriendmat
Well-Known Member
I'll have to look into it. I'm using DVDFab in case anyone cares
Their website says that for 3D Blurays, they use the H.264 MVC (Multiview Video Decoding) which is an extension of the H.264 AVC codec. From what I can tell, this is the standard codec for 3D Blurays. Interesting (but sort of off topic) is that the way 3D Blurays are encoded is meant to allow backwards compatibility in that your device should be able to read the 3D data as 2D (H.264 AVC) and ignore the extra information. Yet whenever I have tried to watch a 3D movie on my 2D TV, it tells me that the display won't support the video format... odd.
Anyway, I think you're right about Blurays using multiple codecs, but it seems the 3D Bluray is standardized to just the one. Sorry if my lack of understanding has presented any of this material incorrectly, and feel free to make it right
Source: Blu-ray Disc - Wikipedia, the free encyclopedia
P.S. Do you think the Evo 3D will record 3D video as .3gp? I don't know much about it, but it seems like an old file type (I remember some older phones of mine using it).
P.P.S. I guess the Evo 4G records to this file type, so maybe it wouldn't be off base to think the 3D will as well. I just want to find out what format/codec/file type will be required to play 3D videos on the Evo 3D.
sabertwist
Member
With an app such as Rockplayer, is there really any need to use Handbrake to convert movie files ? I know I don't.
I think for purposes of what we care, Sensation features = 3vo features.
The 3gp container is just a minor inconvenience. The newer HTC Evo Shift records all vid in H.264 and then sticks into that container type - along with AMR audio.
That AMR audio codec is what's scaring me (NeoteriX pointed that out, tip of topper there). The Sensation ads say it will record in stereo - but AMR is that same crappy audio we have on the Evo.
If you want to reduce them to what's allowable for file size (2GB) on an SD card formatted as FAT32, then yep, you need some tool to downsample on the PC side.
These container formats are pretty standard -- you'll find a similar (if not even identical) list for even 3-yr-old non-smartphone types (cheap Nokias, for instance).
The point I'm trying to make is that we'll need to figure out what the hardware can decode within a given spec. For instance, at 720p, what level is supported? 3.1? 4.1? CABAC? 8x8DCT? How many reference frames are supported? How many B-frames? What features of the B-frames? Weighted P-frames? Closed-GOP? Colorspaces? Custom matrices? mv-length? MBAFF/PAF interlaced mode? Max macroblocks/sec[/frame] beyond level limit? Etc...
Once these are known (and they can be known by testing the device), 720p content (or any other content, even just qHD) can be created for the device in a manner that takes full advantage of the hardware decoding and provides the best picture quality. Hence my point to hold off converting until this is known.
The reason you saw the 3D video from Wirefly in such a manner is likely because 3D AVC is just header signalling of whatever type you're using internally. The major currently-supported AVC 3D signalling are: SBS, OU, HSBS, HOU, of which the device itself appears to be using HSBS given the output picture in the Wirefly demo (either the signalling wasn't respected or it was ignored due to lack of appropriate hardware/rendering chain). But again, this is just saying the pants are blue.
We still need to know what they're really made of!
The limit is 4GB for FAT32 -- (2^32)-1 bytes, to be exact. Most 720p videos can be converted to well under this limit, retaining 720p resolution and a very high perceptual quality. "Downsampling" is also not necessary.
The limit is 4GB for FAT32 -- (2^32)-1 bytes, to be exact. Most 720p videos can be converted to well under this limit, retaining 720p resolution and a very high perceptual quality. "Downsampling" is also not necessary.
In Android, I do believe you'll find that it's using a signed, not unsigned, in the file code, therefore, 2^16-1 or about 4 GB - so we were both wrong on the math I think.
But yes, I believe I was wrong, it's 4 GB.
Ha ha ha.
I have never had such a math challenged day in my llfe.
Ok, that's back to 2 GB.
I have never had such a math challenged day in my llfe.
Ok, that's back to 2 GB.
yourfriendmat
Well-Known Member
These container formats are pretty standard -- you'll find a similar (if not even identical) list for even 3-yr-old non-smartphone types (cheap Nokias, for instance).
The point I'm trying to make is that we'll need to figure out what the hardware can decode within a given spec. For instance, at 720p, what level is supported? 3.1? 4.1? CABAC? 8x8DCT? How many reference frames are supported? How many B-frames? What features of the B-frames? Weighted P-frames? Closed-GOP? Colorspaces? Custom matrices? mv-length? MBAFF/PAF interlaced mode? Max macroblocks/sec[/frame] beyond level limit? Etc...
Once these are known (and they can be known by testing the device), 720p content (or any other content, even just qHD) can be created for the device in a manner that takes full advantage of the hardware decoding and provides the best picture quality. Hence my point to hold off converting until this is known.
The reason you saw the 3D video from Wirefly in such a manner is likely because 3D AVC is just header signalling of whatever type you're using internally. The major currently-supported AVC 3D signalling are: SBS, OU, HSBS, HOU, of which the device itself appears to be using HSBS given the output picture in the Wirefly demo (either the signalling wasn't respected or it was ignored due to lack of appropriate hardware/rendering chain). But again, this is just saying the pants are blue.
We still need to know what they're really made of!
I suppose none of that matters for me. I would have no idea how to make use of any of that information
I've been using FAT32 systems my whole life, and I've never heard of an implementation so horrifically screwed up in such a ridiculous way. This is the first I've heard of this. FAT32 is a standard with known limits (in practice), and Android supposedly doesn't respect this? What a strike against Android if this is truly how it 'works' -- I use linux regularly, too (on kernel 2.6.32, actually, which I believe was the base for Froyo). I admit I know very little about the internals of Android, but I assumed they maintained at least some semblance of common sense -- in common, at least, with other variations of primitive Linux distributions aside from the Dalvic VM. I see this is clearly no longer the case. How patently (no pun intended, Motorola) absurd.
2GB filesize limit? Has anyone verified this? If so, consider my mind blown. And color me disgusted (for many reasons).
I suppose none of that matters for me. I would have no idea how to make use of any of that information
Well for one, it means you can use a much better quality "preset" in your encoding software than "iPod."
yourfriendmat
Well-Known Member
Well for one, it means you can use a much better quality "preset" in your encoding software than "iPod."
You'll have to teach me how haha.
Sure! Let's see... well, I'd have to install "handbrake" first. Which I gather isn't difficult, so I'll see what I can do. In any case, no good would come from it until someone tests the device for its max capabilities. I know I will.
And for the 4Gb thing, I'm glad I tried it for myself. I simply couldn't believe a standard kernelspace environment would somehow use broken FAT32 drivers, so I stuck on a 3.1gig file and watched it to the end. It seeks just fine, too. I can now (easily) verify up to 4gb files work fine (Froyo). You guys scared me for a second, sheesh. XD
And for the 4Gb thing, I'm glad I tried it for myself. I simply couldn't believe a standard kernelspace environment would somehow use broken FAT32 drivers, so I stuck on a 3.1gig file and watched it to the end. It seeks just fine, too. I can now (easily) verify up to 4gb files work fine (Froyo). You guys scared me for a second, sheesh. XD
I apologize. I've had a red letter day of getting things wrong all day.
No need to apologize! Because of this, I got around to processing (and encoding) that seminar I was putting off -- and in what quality indeed!
I'm still marveling over how this forum is of a significantly higher quality than certain others I'm used to -- and in large part this is due to you (and the other incredibly helpful mods around here)!This just makes me more excited for the 3VO.
I'm curious if the they support ext2 or ext3 or ntfs which all support much larger files. If so does the player handle files >> 4gb ? Also why would folks encode to the full resolution of the screen ? On most ios/ android devices I've tinkered with the player places a border around the screen. Does the htc player play the video border-less if the resolution matches the screen ?
-
On the above topic I believe one of the issue with the galaxy s was that it was very slow with fat32 but very fast with ext3 (ext3 has a lot of nice features).
-
On the above topic I believe one of the issue with the galaxy s was that it was very slow with fat32 but very fast with ext3 (ext3 has a lot of nice features).