yashsingh1/xdaforums huggingface dataset:
[Eee Pad Transformer General] levenite:
The audio does seem to be an issue. One thing mentioned in some thread was that mp3 audio was smoother than aac. The best option would be to test converting to a raw PCM stream, since there will be minumum processing required. I have found ac3 2 ch audio with mpeg2video works, at least when using an mpegts container at SD resolution.
[Eee Pad Transformer General] WheresWaldo:
A quick update, I have been playing all afternoon with x264 presets and come to a realization that as long as the video bit rate is under 5000 kbps it doesn't matter what audio you add, it will stutter in the same spots in equal amounts. Again pointing to the audio decoding as taking too many CPU cycles and causing all our issues with Honeycomb. I have been gradually increasing the level from 3.0 - 3.2 - 4.0 and saw no difference in the stuttering, but a good bit of difference in the video quality, especially in dark scenes and scene changes. Right now I am focusing on level 3.2 as it has been consistently encoding at a rate of around 1600 kbps for video.

Next focus was on the quality slider, I am not sure I need to play with this more having settled on a value of 18 to get a good handle on the bit rate and not allow it to skyrocket. This setting encodes files nearing 2000 kbps. What I am seeing is what I would call good quality video from the small 10.1" screen.

Now without doing 2-pass encoding the last focus is where the --presets come in. These presets add more and higher default settings to the encode process to use more frames/memory/CPU to make the compression more efficient to reduce file size without sacrificing quality. As an example I was able to encode the 18.8 GB Blade Runner Final Cut down to a 1.77 GB (94% reduction) while still retaining good video quality. The two problems that remain is time to encode and audio.

By default most tools are using what is equivalent to the Medium preset. It is a good compromise between quality and speed, I have been playing with the Slow and Slower preset. The Slow preset adds about 80% more time to my encodes but results in better quality at the same bit rate, right now the Slower setting seems to be adding about 200% more time and I won't be able to tell if there is a significant difference until it finishes in about 5 more hours. I have a feeling that Slow will be good enough.

rlpaul and I have been working on video/audio and he thinks he has hit on something. It seems that nearly every video that plays "perfect" with audio may be using constant bit rate AAC. What we are both running into is how to create CBR audio when every tool we look at wants to create VBR audio.

All this until everything changes again for 3.2 and then again with ICS.
[Eee Pad Transformer General] e.mote:
Find better tools.

CBR AAC: neroaacenc -cbr [data rate]
[Eee Pad Transformer General] jjsoviet:
Cool, it seems e.mote is here to clarify things out. I hope you guys will collaborate to get the best compromise for quality and performance for smooth video playback. Really, this is the only problem with the Transformer that hinders it from becoming a true multimedia machine. I also hope Honeycomb 3.2 and ICS will fix this issue. :D
[Eee Pad Transformer General] rlpaul:
That's what I'm using. Would just be nice to have a frontend that uses it automatically instead of ABR :)
[Eee Pad Transformer General] levenite:
Do you know of a tools similar to bitrate viewer for linux?
[Eee Pad Transformer General] Digiguest:
There is no better tool than Handbrake.
[Eee Pad Transformer General] e.mote:
@rlpaul

Write a shell script. That's what I do. I just drag-drop.

@levenite

Sorry, my encoding stuff are all on Windoze.

@Digiguest

Handbrake is basically a wrapper for the x264 engine, plus some image processing thrown in. I use it for my DVD converter script, since for non-techs its auto-settings are nice to have.

For "converted" material that's the bulk of "downloadable" content that people are concerned with, you don't need the deinterlace/ivtc stuff, and the commandline x264 is actually much simpler to use, and faster. The sad thing is that command line isn't most people's cup of tea.

The HB interface is antiquated since it doesn't (yet) use the x264cli plain-english presets that have been available for a couple of years now. But since now they are available in libx264, I expect the next official version of HB will include them. Believe me, they make things MUCH simpler.

Video encoding used to be for hardcore nerds (I was there). It still is for the more esoteric stuff, but for "regular" stuff that we're talking about, plain-english presets work best. Take it from a hardcore nerd.
[Eee Pad Transformer General] levenite:
@emote:

I have the latest ffmpeg but there are issues with some libx264 profiles. I had to modify the baseline profile just to get it to work. Would you posting the your profiles files as an attachment so I can ensure a proper set? Thanks.
[Eee Pad Transformer General] e.mote:
OK, I have to take that last part back. HB also includes stream parsing/muxing/audio, which x264cli doesn't handle. To do all of this manually is considerably more complicated. So, yes, HB is "best" if you want a high-quality free all-in-one tool.

But with respect to AAC encoder, the Nero encoder along with the Apple AAC encoder are considered much superior to the (quasi-)open-source faac encoder in ABX tests.

http://www.google.com/search?q=nero+aac+vs+faac
[Eee Pad Transformer General] e.mote:
@levenite

What you need should be here:

=====

FFmpeg now accesses x264 presets via libx264. This extends functionality by introducing several new libx264 options including -preset, -tune, and -profile. You can read more detailed information about these options with "x264 --fullhelp".

The syntax has changed so be sure to update your commands. Example:

ffmpeg -i input -vcodec libx264 -preset fast -tune film -profile baseline -crf 22 -threads 0 output

=====

There's no longer a need to use -vpre, so the old "profiles" no longer apply.
[Eee Pad Transformer General] levenite:
Thanks, I'll give it a try.
[Eee Pad Transformer General] bartleyg82:
megui can utilize nero and encode constant bitrate aac. it's not the most straightforward gui to use, but at least it's a frontend.
[Eee Pad Transformer General] e.mote:
http://google.com/search?q=neroaacenc+gui
[Eee Pad Transformer General] AlexTheStampede:
Thanks for giving that video some attention, lol. Do you think that the extreme opposite might be useful? Because no matter what I do, my Turbo.264HD generates files that aren't stuttering... more like slide showing on the TF.
[Eee Pad Transformer General] bartleyg82:
Just out of curiosity, does anyone actually have a clip of 24p material that plays without judder? If so, can you please share it with all of us?
[Eee Pad Transformer General] e.mote:
Try this:

http://mediafire.com/?9uk4z06ig651x3u Avatar_clip_1280_baseline.mp4

This was used in my video survey. It uses the x264cli setting I mentioned earlier with CRF 23 and preset VERYFAST. Most in the survey (mostly Xoomers) have said that it played smoothly. Tip: Do a hard reset before playback to minimize system load.

The default AV interleave per MP4Box is 500ms. If it's still not smooth, you can try a smaller interleave. Syntax for, say, 250ms interleave:

mp4box -add "path\infile.mp4" -inter 250 -new "path\outfile.mp4"

If you don't like commandline stuff and if you're running Windoze, download my conversion script here,

http://xdaforums.com/showthread.php?t=1102922

For most H264/AAC content, the script remuxes w/o conversion.

Edit script, search for line

"%vHome%\MP4Box" !_vMuxParam! !_aMuxParam! -new "%_outpath%%vName%!_tmp!.mp4" >nul

and change to

"%vHome%\MP4Box" !_vMuxParam! -inter 250 !_aMuxParam! -new "%_outpath%%vName%!_tmp!.mp4" >nul

Optionally, in place of '-inter xxx' you can also use '-tight'. This interleaves per sample, and reduces seeks, but will increase size due to higher overhead.

"%vHome%\MP4Box" !_vMuxParam! -tight !_aMuxParam! -new "%_outpath%%vName%!_tmp!.mp4" >nul

To convert to CBR AAC, edit script, search for

-q 0.4

and change to

-cbr 128000

This last only works if the audio track isn't already in stereo AAC, since it needs to be recoded. The script automatically remuxes any existing stereo AAC track w/o recoding.
[Eee Pad Transformer General] usafle:
This thread has now gone far far FAR past my knowledge into the realm of medical terminology. LoL I have ZERO idea what the heck any of you are talking about now. :(

I'll just keep an eye on this thread and keep using Handbrake and wait for you all to start speaking English again. :)
[Eee Pad Transformer General] WheresWaldo:
e.mote and I are working on two completely different premises as far as source material is concerned and his script is set up to do as little processing as possible with already encoded, usually downloaded, source material. I am sure that it works well in those circumstances. He has mentioned more than once, (maybe I read in in multiple threads) that he was talking about downloaded content. My focus has always been on direct from source un-encoded rips of either Bluray or HD-DVD material. With this you need to encode, and you have to use every tool available to get the quality you want at a size that is manageable. We are using the same tools but in slightly different ways.

If you have already encoded material download his script and drag and drop your content on top to either re-encode or remux into the appropriate container. His settings will work perfectly for that purpose. If you have new material with very large amounts of data then his settings won't work adequately and you will likely be disappointed with the results.

Now on to his mod for CBR audio. This is where I think we should be focusing our attention. The hardware has no issues decoding High Profile 720p material at bit rates nearing 5000 kbps. The problem is not the video, it is the audio decoding. If there is a way for us to mux in audio that requires little or no decoding of any kind I think most of the objectionable stuttering will be eliminated. It still won't be perfect but it will be of high enough quality that you can show your iPad2 toting friends and they will be jealous, or at least won't sneer at you.

Even if this doesn't make you feel any better just remember that there are a number of complaints in every Tegra 2 thread on XDA, They are all the same regardless of forum. Everyone is struggling to find the right settings to make their device be what they want it to be, an entertainment appliance.
[Eee Pad Transformer General] e.mote:
@usafle

The script is designed for the non-techie.

@WheresWaldo

There is no different approach. The encode settings are the same, regardless of the source. The only thing that's extra is the ripping from the disc (DVD or BD) and the stream parsing. That has nothing to do with the encoding.

The script was posted upon request from a user in the Xoom forum, and it's geared for the most common source of content, which are "downloadables" from the net. Few people would want to rip their own BDs, since it takes tens of gigabytes and a quadcore or better. In any case, there's very little difference. As long as the material is ripped and the streams are parsed into an accepted container, the encoding is the same, and my script works the same way.
[Eee Pad Transformer General] WheresWaldo:
You have a PM.

No disrespect was intended.
[Eee Pad Transformer General] WheresWaldo:
CBR doesn't seem to help

After a long evening of muxing and remuxing I can't seem to find any difference between VBR audo and CBR audio. I was really hoping there was something there. What was evident was that the TF can handle much higher bitrates than we have been throwing at it with many of these samples.

Here are a few clips to prove this point.

One minute clip with no sound - http://db.tt/OnWu4gT

Note the smooth scrolling as we pass the balcony railing near the end of the clip

Same clip with VBR audio - http://db.tt/MmjrjeQ

Same clip with CBR audio - http://db.tt/xjaF3zU

Maybe it's just me but I really don't see any difference in these two clips.

Second one minute clip with no sound - http://db.tt/VUmAQCe

Panning from the front of the building toward the window and again inside the room just before starting the questioning, each one smooth.

Second clip with VBR audio - http://db.tt/yz5GZDP

Second clip with CBR audio - http://db.tt/tQEHvsK

Again I just don't see any difference in these two clips. MediaInfo still shows both the CBR clips as VBR even though this was encoded with Nero using the cbr parameter.

I am making a public apology to e.mote as I did not mean to imply that his script was trash. I have now examined it in detail and it is actually a very nice piece of work and would come in handy for anyone that does not want to play with x264 settings. My comments were directed at the --preset veryfast which he used for the Avatar clip, which I personally feel is useless for most encoding except for the "I am in a rush and must watch something" types of encodes.

I have also tried the --preset slow and --preset slower and on the TF cannot really appreciate any improvement in video quality. There is a substantial increase in encode time as you move from medium through placebo presets. As a suggestion I would like to see e.mote add the slow preset and drop the veryfast from his script. I am not sure I would ever use the veryslow for anything because of extreme encode times, just a suggestion not a criticism.

After all this encoding and several days of work I believe some progress has been made. At least we can probably agree that the audio is the real problem and that an update to HC is most likely required to see this resolved. I also think that as soon as kernel source is released and some of the devs start working on an Asus specific OC kernel, it would be a good idea to jump on that as it might get us over the hump, so to speak, until this is resolved.

If you are using RipBot or Handbrake here are profiles that should get you quite a bit of quality out of the video but unfortunately still do not resolve the audio issues. Use these with a CQ setting of 18 or 19. Try the slow ones first and report your results.
[Eee Pad Transformer General] jjsoviet:
My guess is that despite the source audio as CBR, the encoding process makes it VBR along with the video. How about trying to somehow force audio and video to playback as separate files? Just a suggestion.

Trying your very slow presets, and I'll report in... 5 hours. D:
[Eee Pad Transformer General] usafle:
I did use e.mote's script on "downloaded" content (720p), either in .AVI or .MKV format.

His settings (no offense) did not work at all on my T.F. It was all together unwatchable. Stuttering, dropped frames, audio out of sync..etc..etc..

That's why I asked if it was just an issue with my T.F. or was I supposed to be encoding back into a .mkv container instead of .avi. I tried it both ways and neither worked.

Went back to Handbrake with the same source files and sat there for 2+ hours (RipBot264 is like a greased pig compared to Handbrake) and the same exact files played fine on the T.F. with the OP settings for Handbrake.

So, I'm not sure what or, where the problem lies?

It's great that this discussion is getting so much attention. With all these "super brains" trying to figure out how to encode, a solution should present itself in no time.
[Eee Pad Transformer General] bartleyg82:
I've basically given up on this whole process. e.mote's script is pretty slick and I appreciate that it uses nero's aac encoder instead of FAAC. However, even when I encode with constant audio bitrate, the videos still judder when the camera pans. Again, none of this happens when audio is not being decoded. It's almost as if AAC decoding completely breaks the player's 3:2 pulldown process. I suspect that this is not something that'll be fixed with any sort of magical encoding settings. I guess I'll keep my fingers crossed that Honeycomb 3.2 addresses this issue, but for now I'm just going to enjoy the many other things that my transformer does well. If i need to watch hd video on the go, I always have my laptop.
[Eee Pad Transformer General] usafle:
Just tried this one out as well e.mote. No joy. Still stutters, dropped frames, etc..etc..
[Eee Pad Transformer General] WheresWaldo:
They weren't lying when they said SLOW, I tried the SLOWER on one movie and even at 4 cores w/ 8 threads at 3.36 Ghz it took over 6 hours to encode.

I usually don't download content but movies I own, I own because I want to see them more than once, so it is very typical for me to rip DVD (my DVD collection is getting smaller as BluRays become available), HD-DVD (I am still stuck with a few of these and still have the worlds slowest booting JVC HD-DVD player) and BluRay disks. There are some classic movies I cannot encode to a small enough size to play on the TF. These are usually BW movies with enormous dynamic range or excessive film grain, examples: Orsen Wells in The Third Man the best encode I have done got me down to 9GB, Raging Bull was 16GB, The Seventh Seal was 11GB, even Casablanca was 5GB.

The big reason for not transcoding at home is that if I am at home I would rather watch something on one of the three flat screens rather than on my TF, I would even choose my computer before the TF at home. One of the main reasons I wanted a tablet is that when I travel I want to watch something rather than just listen to something. If I only wanted music then why carry anything more than my Captivate w/Voodoo Sound!

I am going to try to encode the audio all by itself and see if there is any difference but I am not holding out any hope.
[Eee Pad Transformer General] WheresWaldo:
I think if you use the slow preset or the slower preset you will have better luck but you are right about several things, 3:2 pulldown breaks when you must decode audio of any kind, likely it will need to be fixed by Google/Nvidia. As long as I am not concentrating on the video the stuttering is not too objectionable. I don't have many movies that are one pan after another, I suppose then I would consider it unwatchable.
[Eee Pad Transformer General] levenite:
I have two issues that need clarification. I believe emote uses a Xoom rather than a transformer, Correct? This could explain his not having the same audio issues. The consensus seems to be there is an issue at least with aac audio. Has it been confirmed the same issue exists with other audio codecs, say mp2,mp3? There is no restriction in using a different audio codec in the mp4 container although handbrake may not offer this option. If the TF has an audio issue, it is quite reasonable it is not common to all audio codecs.
[Eee Pad Transformer General] WheresWaldo:
Actually rlpaul and I tried multiple audio codes. I personally tried Ogg Vorbis and AC3 and I know he tried MP3 and AC3. We might have tried others too, I forget. The results were exactly the same stutter or worse, but not anything better. Ogg only played one frame every 2-3 seconds although audio played for a few minutes until moboplayer froze. I don't recall if AC3 worked at all. MP3 resulted in the same stuttering.

I am open to suggestions, and as long as there is some open source or free encoder I am willing to try anything.

With regard to what e.mote uses it doesn't matter, he is using x264 presets and the encoder presets are the same no matter what device you display the resulting file on. As long as you restrict your encode to 720p, use high profile a low enough CQ number and a good preset you should be good to go. One thing e.mote did not implement was levels. The Ripbot profiles I zipped use level 3.2 (has to do with max bit rates), the HandBrake ones do not use levels.
[Eee Pad Transformer General] bartleyg82:
If emote uses a Xoom then that would explain why the Avatar clip he posted plays so poorly on my TF (lots of slowdown, dropped frames, etc). You're right that you can mux a variety of other audio formats into an mp4 container, but as far as I know, when using hardware acceleration, the TF can only decode aac.
[Eee Pad Transformer General] NeoStuey:
I just tried that Avatar clip that emote put up on Transformer and it played smoothly for me, no slowdown or visable dropped frames.

Just as an aside are the users with bad playback using the OC kernel? I ask that as it is great for 3D benchmarks but FAR worse for mp4 video playback than the stock 3.1 kernel in my own experience, even overclocked to 1.6ghz it would stutter and drop frames where the same movie would be mostly fine on stock. On exceptionally high bit rates I have experienced limited frame drop or aslight stutter on panning but then I am at the mercy of having others providing the rips of films I own on bluray as I don't have the infrastructure here to do my own rips. I just trascode the multi channel audio to faac stereo.

Going to read back through the thread now as I have missed much of the discussion.
[Eee Pad Transformer General] bartleyg82:
You are correct. I was using the OC kernel and after switching back to stock, that video plays much more smoothly. Still a few dropped frames here and there, but dramatically better. I had sort of forgotten about the video playback issues with the OC kernel. Anyways, the judder issue remains, but overall playback of high bitrate files is definitely improved. Thanks for the heads up.
[Eee Pad Transformer General] jjsoviet:
So this is now a kernel issue, if the stock 3.1 plays videos better than the provided OC kernels. Now we need ASUS to release source code so we could get into this problem.
[Eee Pad Transformer General] sassafras_:
Good luck. Google is the reason companies are withholding the source.

We'll see HC source when ICS is released.

sassafras
[Eee Pad Transformer General] jjsoviet:
Samsung released its source immediately after the Galaxy Tab 10.1 units are released. So ASUS should do the same.
[Eee Pad Transformer General] WheresWaldo:
OT. Google is not releasing ROM source their decision has nothing to do with kernel source. We don't need ROM source, we need kernel source to have a kernal that supports Asus mods and has OC. Not the hacked kernel that is out now.

@jjsoviet - That kernel is some fantastic work but Asus source is what is needed to be 100% compatible.

I am currently remuxing some of the videos from the last two days playing with an option or two in mp4box to see if it makes any difference.
[Eee Pad Transformer General] sassafras_:
I should have been a little clearer. This likely isn't a kernel issue at all. As with the Flash video problems it's probably a problem in Stagefright or at least the Asus implementation of it. As such, we likely won't see the Honeycomb source for the multimedia renderer any time soon.

sassafras
[Eee Pad Transformer General] e.mote:
Comments:

You need to be clearer. "Judder" is an artifact of 2:3 pulldown, which isn't used in most of today's digital content. Even if it were, better converters would have IVTC'ed to restore the original framerate. If you mean "stutter", as in a periodic frame hesitation at regular intervals, then it would help to be precise in the duration of intervals, and their prevalence. Are they from beginning to end, in every movie, or only in certain instances? Or perhaps you mean frame-drops, as in actual frame skipping? It helps to be clear.

The baseline video posted was reported as smooth for everyone who participated in the survey. In troubleshooting parlance, it's called a "known-good" sample. If you still have playback issue with a "known-good", then it's a device-specific issue, not an encoding issue. Further, given that only a handful on this forum have reported this "stutter" issue, then either it's your particular devices (as opposed to all of the TFs), or it's a perceptual sensitivity issue. You need to determine which.

Either way, I've given some tips on possible solutions, but I've yet to see anyone taking advantage of them.

BTW, the mantra of troubleshooting is to minimize your configuration. That means running stock, with the bare minimum of apps. And hard reset before playing each video.

As this is a Handbrake preset thread, questions regarding my script should be asked in its existing thread.