yashsingh1/xdaforums huggingface dataset:
[Eee Pad Transformer General] sassafras_:
I've made a video that displays the current bitrate at playback to see if the device is choking on high bitrates.

My results are not scientific, but just for my informal reference:

h.264 Baseline profile: No stutter and smooth playback all the way up to 9,500kbps (I did not test anything higher as even the crispest 1080p rarely breaks this threshold)

h.264 Main profile: Some slight stutter and apparent dropped frames at bitrates in excess of 6,000kbps. This effect was slight and rare due to the fact that even the most complex of action shots rarely break this threshold at 720p.

h.264 High profile: Some stutter which is noticeable above 5,000 kbps and can be distracting at times.

While the Tegra can clearly handle 720p encodes and will even decode high profile video, it just doesn't have the horsepower to really push through the high profile encodes as smoothly as I'd like.

If it's me, I'll encode all my 720p stuff using the main profile (and fast preset in x264) and call it a day.

sassafras
[Eee Pad Transformer General] liorry:
Trying this solution... but it can't be our only solution... 45min for a 3GB file on an i7 processor with 8GB RAM...

Sure hope Honeycomb 3.2 will address this issue.

Edit: worked great... runs smooth and with sound (both with stock video player and mVideoPlayer which has hardware acceleration support).

Still wish HC 3.2 will fix the need for this conversion.
[Eee Pad Transformer General] e.mote:
The x264 profile setting is only one of many that can affect playback. By itself it isn't a good indicator of what is playable on the Teg2.

Example: From the commandline, dump 'x264 --fullhelp' to a file. Look at the difference in settings between 'veryslow' and 'veryfast' presets. Many of these "higher compression" settings will affect playback, but yet they aren't explicitly specified on the commandline. So, the 'veryslow' setting by itself can make playback worse.

Secondly, many believe that it's the --level setting that makes the difference, eg level 4.1 & 5.1 (the so-called warez standard) won't be playable. Again, it depends on the content. Some content, notably anime with many duplicate frames that can make use of a large ref frame count (determined by the level setting), will choke. Some will play fine. The rule is that you do not manually set this setting, as the encoder will chose the minimum level needed for the resolution and framerate. If you set this manually, in excess of what is needed, playback will not be better, but can end up worse.

These are just a couple of instances of the many variables affecting playback. There are just as many variables on the device side. For example, the ARM CPU's freq is scalable on demand. Some have found that there are instances when the CPU don't scale up during playback as would be expected. This would lead to jumpy playback.
[Eee Pad Transformer General] sassafras_:
Exactly. I think the takeaway here is that there is no optimal setting for all movies. I think that's what I was trying to get at. I just went through and batch encoded all of my 720 or higher stuff to be compliant with the transformer and I didn't want to have to trial and error each file to determine what the Tegra would choke on.

Essentially it boils down to this:

720p stuff encoded using "-preset fast -tune film -profile high -crf 21" played back flawlessly (or nearly enough that I don't care) and is more than acceptable quality, size and convenience for my needs.

Your mileage may vary.

sassafras
[Eee Pad Transformer General] e.mote:
>-preset fast -tune film -profile high -crf 21

I agree with this, and with the notion of "recode everything" via batch. That's why my scripts existed in the first place, even without considering tablets/phones. Most of the "downloadable" content can be recoded to a fraction of their orig size, w/o discernable quality loss.

The frustrating part is to find people thinking that complex, esoteric settings are the way to go (probably because they're more "techy"), and they go hunting about for the "best" settings by trial-and-error. You tell them, but they ignore you. Oh well. Life goes on.
[Eee Pad Transformer General] e.mote:
>Has it been confirmed the same issue exists with other audio codecs, say mp2,mp3?

In the survey, there were variations of the same Avatar clip to test for flexibility of HC's MP4 support. The few reports I got was that only stereo AAC plays back correctly in hardware mode.

You can try them for yourself. All have same video track and MP4 container (except for one which is muxed to MKV):

http://mediafire.com/?15ec78k8s57db1z Avatar_clip_1280_high.mp4

This has stereo AAC. Use this as your benchmark. Most in the survey said it was "mostly" smooth, except for the "mud splats." In other words, it was playable, but borderline.

http://mediafire.com/?t4en4ihc7kds8yl Avatar_clip_1280_high_5.1.aac.mp4

http://mediafire.com/?w5pt0warm2zopro Avatar_clip_1280_high_mp3.mp4

http://mediafire.com/?909217fe7z4272p Avatar_clip_1280_high_2.0aac_5.1aac.mp4

This dual-audio clip was reported to play fine.

http://mediafire.com/?yc7ao5d2fmijrro Avatar_clip_1280_high.mkv

This clip is same as the first stereo AAC clip, but muxed to MKV.

BTW, the mentioned H.264 video survey is here,

http://xdaforums.com/showthread.php?t=1091204
[Eee Pad Transformer General] leonpr:
With the news that asus just released the offical 3.1 kernal source it should be possible to figure out whats going on in the coming days. Keep an eye on the dev section :)
[Eee Pad Transformer General] usafle:
I'm not ignoring you. :) I've gleaned some good information that I knew nothing of before everyone started talking about this stuff.

The setting below is applied to which program now? Handbrake? RipBot? That Windoze DOS script you posted earlier?
[Eee Pad Transformer General] levenite:
:cool:This would be a powerful tool. Care to share how it was done?
[Eee Pad Transformer General] djglenn1337:
What file format are you guys starting from? I have a huge library of mkv's, but appreciate the file sizes are a problem on fat32.... All advice appreciated!
[Eee Pad Transformer General] e.mote:
To give an idea of what bitrate the Tegra 2 can handle:

This bitrate graph is of the Avatar clip posted. The clip uses '--crf 23 --tune film --preset veryfast --profile high'. The sequence is a very demanding scene (I call it worst-case), and even at CRF 23, bitrate averages 6.6Mb/s, with two peaks going over 10Mb/s.

The two >10Mb/s peaks are the two "mud splat" scenes below, at 0:44 and 1:10. These were where users reported jumpy playbacks. Since the scenes were only a few seconds long, viewing experience wasn't significantly impacted. Hence, CRF 23 is "safe" for Avatar at 720p. To use 20 or 21 for Avatar, baseline profile or reduced resolution would be needed. Avatar is a demanding movie; with the majority of films, CRF 22 is probably "safe" for 720p.

This doesn't mean specifying your bitrate at, say, 6Mb/s, will make it all smooth. The specified bitrate for 2-pass is an average, not a ceiling. The 2-pass bitrate graph will be identical to the 1-pass above, since they use the same algorithm.

This is why it's a bad idea to use 2-pass, aside from the fact that it's slower. 2-pass means you manually specify the bitrate, but different content can require vastly different bitrates, and there's no way for a user to know how much is needed. If you set one bitrate for all your encodes, some will have more bits than they need and be bloated, some will not have enough, and visual quality will suffer.

To put a ceiling on bitrate consumption, you'd want to try different values for the vbv-xxx settings, and check the bitrate graph. I would say a safe ceiling for Tegra 2 (on 3.1) is 8Mb/s with high profile and default x264 settings (ie Medium preset).

Note that this has nothing to do with the ongoing "micro stutter" issue some reported. This pertains to the Tegra 2's current limit.
[Eee Pad Transformer General] sassafras_:
Just to follow up, there is a libx264 switch to cap the maximum bitrate known as --vbv-maxrate which allows you to cap the theoretical maximum bitrate of the video buffer in the decoder (the tegra chip). Setting this to a value roughly around 10Mbit as e.mote suggested might help to prevent problems in hard to encode scenes.

Note that if you set the --vbv-maxrate flag you also need to set the --vbv-bufsize flag to a value correlating to the maximum video buffer you expect the tegra to have (I'd say 7500 is reasonable but I honestly have no idea what it uses as a buffer).

Do this if you're paranoid about high motion scenes causing stutter.

sassafras
[Eee Pad Transformer General] AlexTheStampede:
Looks interesting... could you do the same test on my "perfect" file? Smooth as butter, and yet it should have a peak in the 20Mb/s range.

http://dl.dropbox.com/u/420077/Bayonetta_TGSTrailer-HD720.mp4
[Eee Pad Transformer General] e.mote:
The >20Mb/s scene is only 2 sec long (0:10-0:12), and because the clouds were slow-moving, any frame jump would be hard to detect. For normal viewing, most probably won't notice it.

Also, the clip is encoded in Main profile, which is typical of most trailers, and is marginally easier for the Teg2 to handle. I don't have much experience with Main, as I mostly use High, or if needed, Baseline.
[Eee Pad Transformer General] sassafras_:
Just a note. Your video is encoded using the h.264 'main' profile which requires less work to decode than a 'high' profile video.

Don't forget that even though the GPU is doing the heavy lifting, it's still a processor that can only accomplish so much per clock cycle. If it has to do more complicated math then it's effective maximum bitrate will be lower than if it's doing less work.

EDIT: What he said ;)

sassafras
[Eee Pad Transformer General] e.mote:
Some graphs below to give an idea of bitrate variability of different movies. These were recoded from 1080p BD ISOs to 720p, with settings '--crf 21 --preset veryslow --tune film --profile high'. Note that Avatar requires almost twice the bitrate of Matrix, at the same constant-quality settings.
[Eee Pad Transformer General] jjsoviet:
Excellent studies. So far, we're seeing how Tegra 2's limitations hamper smooth video playback - at least in the higher bitrate encoded codecs. But given that ASUS already released the kernel source, could we be seeing improvements by introducing some custom kernels? Possibly more optimizations to the code?

Also, it would be awesome if you guys provide the settings for both Handbrake and RipBot for us mere mortals to use with. Well, if you don't mind. :D
[Eee Pad Transformer General] bartleyg82:
I feel like I'm taking crazy pills regarding this judder issue. Here are a few more clips to demonstrate the problem that I've been talking about. This is the first 40 seconds of Pan's Labyrinth. The clips are mostly slow pans to accentuate the issue I've been seeing. They were encoded using e-mote's script and the exact settings recommended multiple times in this thread: "-preset fast -tune film -profile high -crf 21". Just for comparison, I encoded one using the baseline profile as well. I muxed out the audio from the high profile clip to show that without audio the playback is MUCH MUCH smoother (nearly flawless).

High profile clip with audio (~8 mb):

http://www.mediafire.com/?s3j5nalnc999th5

High profile clip without audio (~8 mb):

http://www.mediafire.com/?5st4fb66zpb1m3m

Base profile clip with audio (~8 mb):

http://www.mediafire.com/?ibhuv6cmfnqj4u8

Lastly, here's the source material, which is an uncompressed mkv blu-ray rip with flac audio. If someone can work magic and encode this in a way that doesn't have the judder when played on the transformer, I'd forever be in your debt. And of course I would like to know your encoding settings :)

Uncompressed clip with audio (~92 mb):

http://www.mediafire.com/?kpu0j6gqig425rl

Please let me know how these play on your transformer (or whichever tablet you have, for that matter). Thanks in advance!!
[Eee Pad Transformer General] AlexTheStampede:
I'm learning things here... so to over simplify Main is easy, Baseline medium and High well, high? I would've guessed that Baseline and Main were the other way around.
[Eee Pad Transformer General] sassafras_:
Baseline has very little optimizations, main has a few and high has most of them.

So yes, your original idea was right.
[Eee Pad Transformer General] e.mote:
Try these two:

http://mediafire.com/?rp1r91g071ahzg7 Pans_Labyrinth_clip_640_tight.mp4

http://mediafire.com/?84mnbbxcqlyxavr Pans_Labyrinth_clip_1280_tight.mp4

Both clips use the same video settings as yours. Audio is 96K CBR. Mux uses -tight for smallest possible interleave.

The first is 640 width. This should be the baseline. If this results in judder, don't know what to tell ya, other than, well, try it on a different TF.

The second is 1280 width. Assuming at least one of these two works, then begin to scale up from there. I'm using what I consider as "minimum" settings.

@Alex

In descending order of decoding requirement: High, Main, Baseline. So you were right the first time.
[Eee Pad Transformer General] usafle:
I second that request! :)
[Eee Pad Transformer General] e.mote:
speed:
. medium = (default)
. fast = rc-lookahead=30:ref=2:subme=6:weightp=1

profile:
. high = (default)
. baseline = no-8x8dct:bframes=0:no-cabac:cqm=flat:weightp=0

tune:
. film = deblock=-1,-1:psy-rd=,0.15
. animation = deblock=1,1:psy-rd=0.4,:aq-strength=0.6:bframes={+2}:ref={Double if >1 else 1}

-tune animation can't be done by a simple setting, as you need to take the current ref= count and times 2. If you have anime, just don't use tune. (In a script, you can determine ref=.)

To sum, for the equiv of '--crf 21 --preset fast --tune film --profile high', select CQ 21 and enter this into HB's custom params box:

rc-lookahead=30:ref=2:subme=6:weightp=1:deblock=-1,-1:psy-rd=,0.15

For '--crf 21 --preset fast --tune film --profile baseline', enter this:

rc-lookahead=30:ref=2:subme=6:deblock=-1,-1:psy-rd=,0.15:no-8x8dct:bframes=0:no-cabac:cqm=flat:weightp=0

For '--crf 21 --preset medium --tune film --profile high', enter this:

deblock=-1,-1:psy-rd=,0.15

You may need to enter -x in front of the options to signify they are x264 options. I'm not familiar with HB's GUI; I only use the HB CLI.

FYI, per the HB 4/11/2011 IRC log, HB is supposed to get x264's "plain-english" settings by next version.
[Eee Pad Transformer General] AlexTheStampede:
I'm having doubts about the encoding. Aside from the audio less one, the others do not play smooth (not even e.mote ones!) on the Galaxy tab... not a good sign if you ask me, as this thing proved to be a beast. Either that or Samsung idea of Gingerbread included a seriously broken hardware decoding.
[Eee Pad Transformer General] e.mote:
Try this:

http://xdaforums.com/showthread.php?t=1111156
[Eee Pad Transformer General] NeoStuey:
Progress. :D

Well I just had a look at the link out of curiosity and decided to try no-frills cpu control with netformer @ 1.504 GHz min/max and the performance governor and have seen a marked improvement on my mp4 playback through the stock player. I had a grin on my face when the first couple of problem scenes played back so well. I'm sure that more improvements will come and I hope they do as I am still at the mercy of getting my source from the net as I cannot rip my own bluray collection for lack of a decent computer.
[Eee Pad Transformer General] bartleyg82:
Thanks for letting me know that you're seeing the problem on your galaxy tab.

e.mote - Thanks for all of your help in this thread, you obviously know your way around video encoding. Unfortunately, both of the videos you encoded still have judder on my transformer. Perhaps this issue is simply out of my control.

Has anyone else tried the videos that e.mote and I posted? I would love to hear if any of you are getting smooth playback with these samples - if so, maybe I have a defective tablet and I can exchange it for another one. It's frustrating to see all of the judder in these videos when they play perfectly on my wife's netbook that is three years old and is powered by a single core atom cpu.
[Eee Pad Transformer General] AlexTheStampede:
I might add for clarity that it's the single core Hummingbird 7" model, and that overclocking didn't help. Still plays perfectly files that unwatchable on the TF.
[Eee Pad Transformer General] sassafras_:
One other thing to try:

Download an app like SetCPU or the like and set your CPU governor to 'Performance'. It may be that it stutters on initial playback because the CPU isn't scaling up to match speed as fast as the video requires. If the performance setting fixes your problem, try 'On Demand' next as it is a rapidly upscaling governor that still allows downclocking to save battery.
[Eee Pad Transformer General] bluecnc:
Wow!

Not long ago this thread had only maybe 3 pages. It is amazing that so much interest has been generated by people that want to watch movies on their TF while not at home. That is the main reason I got mine. And it has frustrated me to no end to find that I couldn't encode one movie that would play smoothly. I have used Hand Brake, DVD Clone Mobile and Nero 10 without success. A friend of mine had an encoded copy(AVI) of The Mechanic that I copied to my Micro SD card. It played smooth as butter. But!! The quality was horrible because the file was only about 600mb. And any scene where there was rapid movement would look like a compilation of three or four frozen frames until something would catch back up. For an entertainment device the Transformer sure has much to go. To make matters worse all the same stuff plays on my Zune HD almost flawlessly. Go figure. That screen is so small I need more than my reading glasses to watch anything. Oh well. I will keep tinkering. BTW. I am only encoding DVD's. No HD.
[Eee Pad Transformer General] seshmaru:
If you aren't encoding HD video then you are doing something terribly wrong, I can play ANY DVD rip in ANY format flawlessly with moboplayer.
[Eee Pad Transformer General] bluecnc:
Gee. Thanks.

Maybe it is my old HP laptop. Dual core Pentium with 3gb of ram.
[Eee Pad Transformer General] deadman3000:
All these tests keep being done on the video side of things. But I have already stated a few times the judder only occurs when there is audio being played! If you play a 720p high profile video with NO SOUND muxed into the container (MP4, MKV it does not matter) then the video plays buttery smooth.

The problem lies somewhere between when audio is being decoded. So all these playing with different profiles does not seem to be the cause here. People also said that maybe decoding the audio adds extra stress that might tip things over the edge. If that was the case I think we would be seeing more than just the constant judder but actual dropped frames and pausing. This does not occur.

Anyhow surely decoding MP3 audio is no biggie it's been out since donkey years and even the lowest of spec devices can decode it with no trouble whatsoever.

BTW if you want to try and test this then why not mux a WAV file into a MP4 or MKV and see if it still stutters. A WAV file takes no strain whatsoever to decode so that would completely rule out audio decoding causing extra stress. I really think that's a red herring personally.

But the audio playback DOES seem to be the thing that causes the juddering to occur as previously demonstrated.
[Eee Pad Transformer General] Nascar Dog:
Maybe this is why the Transformer has poor video performance...

What do you guys think about these results?

18 bit color...WTF

http://www.displaymate.com/Asus_Transformer_ShootOut.htm

http://www.displaymate.com/Tablet_ShootOut_1.htm
[Eee Pad Transformer General] bartleyg82:
I agree with you 100% that audio decoding is causing our playback issues. I think that the Pan's Labyrinth clips I posted demonstrate it nicely. The problem is that AAC is the only audio format (AFAIK) that is supported with hardware acceleration. You can make clips with mp3 audio tracks and play them with software accelerated players (eg moboplayer), but in order to get decent framerates, the you have to lower the video quality so much that in my opinion it really isn't worth it. I'm not sure about wav audio, but the file sizes would be so big that it's not a practical solution. Unless the folks in the development forum can cook up a solution, I think we're out of luck until the issue is addressed by nvidia or asus.

In the meantime, I would still like to know if others are having this problem, especially those who can test the clips on a xoom/iconia/gt 10.1.
[Eee Pad Transformer General] sassafras_:
First of all, the stock player won't play anything but AAC in the mp4 container.

You can swap in mp3 but the differences in requirements to decode are minimal at best. WAV is right out as it's not supported on the platform at all.

See here if you want a full list of what the stock player can and can't do: http://developer.android.com/guide/appendix/media-formats.html

That aside, I still think you are missing the big picture here. Decoding audio takes very little work, there is actually little difference between CBR and VBR schemes in terms of processing power, and the CPU when scaled up is basically only tasked with audio decoding. The GPU does all the rendering of the video and is then directly rendered on screen using an android library known as Stagefright.

I'm starting to suspect your problem is actually tied to the CPU not scaling adequately enough to meet the demands of what's going on. I'd like you both to try setting your CPU to a constant clock speed (ie, set the minimum and maximum speeds to the same setting - like 1000MHz). The governor shouldn't matter if it's not scaling, but just set it to on demand anyway. Let me know how that goes.

sassafras
[Eee Pad Transformer General] bmcglone:
This is fantastic, great work.
[Eee Pad Transformer General] deadman3000:
I'm without TF at present so can't do anything. Hopefully I will have it back in the next day or two (Assuming no other issues arise after reading the Asus repair horror stories).
[Eee Pad Transformer General] lightsout:
I've been doing my encodes in HB with profile and all the advanced video settings left alone. I set the target nitrate between 1250 and 1500 depending on the movie. They play great and the file size is small but the quality looks good still. No blocking or any of that.