yashsingh1/xdaforums huggingface dataset:
[Eee Pad Transformer General] bartleyg82:
Here's the big picture as I see it: the Transformer cannot properly play video using hardware acceleration when audio is simultaneously being decoded.

All of the random things I've tried to get it working have basically just been me grasping at straws. VBR/CBR audio makes no difference, video resolution/bitrate/profile/etc makes no difference (as long as it's within the specs of what Tegra2 can handle), cpu clock speed/governor makes no difference. I went to Best Buy today and played the Pan's Labyrinth high profile clip on the Xoom and the Galaxy 10.1. Both were very slightly better than the Transformer, but neither were great. The only thing that makes the videos play smoothly is muxing out the audio track, and it works EVERY time. So I don't know whether it's a video decoding/rendering issue or audio decoding issue, but there is a problem that needs to be addressed.

I'm not sure where the solution lies, or even if there is one. But what I do know is that tweaking the encoding settings won't get me anywhere. Perhaps Nvidia/Google will get this ironed out in Honeycomb 3.2, but who knows. It's very possible that I'll just have to wait for the Kal-El tablets to see this resolved.

I showed some of the clips to my wife and her response to the judder was "it's definitely there, but I don't think it would be a complete deal breaker." I think that sums it up well. The clips that I posted were specifically selected because they accentuate the problem. Most of the time the judder is either barely noticeable or not noticeable at all. I'm not going to return my Transformer because of this, but it's a bummer that when I pick movies to put on it, I think to myself "does this movie have lots of slow, dramatic pans, because if so, I better not bother with it." And to reiterate something I posted previously, it's even more of a bummer that a 3 year old netbook with a single core atom cpu can play these clips smoothly when my brand new state of the art tablet cannot.

/end rant
[Eee Pad Transformer General] Garf123:
That about sums up what I believe also bartleyg.

It is a shame that TF has issues with this, I see it in encoded dvd's I have made, it's not just 720p.

Let's hope it gets fixed soon, either with the devs, or in an Andriod OS release.
[Eee Pad Transformer General] sontin:
I speeded up the Pan Video to 29,97 fps: http://www.multiupload.com/AGJ3KKEFIP

I think that the demuxer can't handle a video with sound and a lower fps than the display (hertz). Because, with lower fps there is more stuttering. Without sound there is no problem.
[Eee Pad Transformer General] jkcheng122:
Question regarding HB. If we have a 720p downloaded material that only needs its DTS/AC3 audio re-encoded to AAC, is there a setting in HB that will allow me to just do the audio and not re-encode the video? This should make the process much faster too although obviously doesn't solve the "stutter during panning" issue.
[Eee Pad Transformer General] deadman3000:
If you can get your hands on a copy of Plex server (free) installed on a reasonably powerful Windows 7 PC (Mine is a dual core E7600 which is just at the limit) and Plex for Android (Not free). It streams movies at up to 5mbit 1280x800 and the judder is NOT THERE! There is stutter but it's not the same kind of judder I see when playing video files directly. The video is transcoded on-the-fly by Plex (it actually uses ffmpeg which I assume is transcoding to MPEG2 video and audio). The video is a LOT smoother. I am still getting judder but it's different. More like frame drop but that may be my transcoding PC is just not powerful enough. I would like to hear someones experiences of using Plex on a socket 1155 i5 or better still i7 processor.

Anyone else tried this? It's the best workaround I have found but only for streaming over wifi at home. Not so useful when you are on an airplane though. I may look into transcoding using ffmpeg to a MPEG2 file if that is what it is doing and try playing that directly on the TF to see what happens.
[Eee Pad Transformer General] AlexTheStampede:
With a T8100 I had no issues watching a whole episode of an anime in 720p. Well, aside from the lack of subtitles, one day they'll add it... one day.... anyway it was smooth, but you could tell that there had been some video compression. Nothing bad, but it didn't look perfect as the source. I like to keep Plex set up properly, so for local streaming I picked 5mbit.
[Eee Pad Transformer General] kbotherway:
I use this script to convert my m2ts to mp4 on Linux by just converting the AC3 audio to AAC and then using MP4Box (gpac) to put the file back together. Requres: tsmuxer, ffmpeg, gpac and libfaac.
[Eee Pad Transformer General] e.mote:
Instead of outputing the video encode to raw .264, then having to supplement it with -fps, you can output to .mp4. That not only retains the framerate info, but other needed info that wasn't taken into account, like DAR. As it is, the script doesn't work for anamorphic content, nor will it work for VFR content that's in wide use for animes. There's no need for MP4Box because ffmpeg can mux, nor for TSMuxer to demux when ffmpeg can read in the file as-is.

Your ffmpeg commandline can be just this, after grepping the track IDs,

ffmpeg -i infile.m2ts -vcodec copy -acodec libfaac -ab [bitrate] -ac 2 -vol 456 outfile.mp4 -map 0.[video_track_id] -map 0.[audio_track_id]

You'd need to grep from ffmpeg -i output to find track IDs in this case, since ffmpeg uses a 0-based id scheme.
[Eee Pad Transformer General] sassafras_:
e.mote,

Since there is no reason to ever telecine 24fps h.264 material, I've never learned if it was even possible, but from sontin's post I was thinking that frame rate may actually be the issue in the slow panning scenes.

Doing an ffmpeg -r 30000/1001 gives terrible results, and then I hit the limit of my knowledge on the subject. Are you aware of any way to change the framerate (telecine or otherwise) of h.264 content non-destructively and without changing playback speed?

sassafras
[Eee Pad Transformer General] e.mote:
The "judder" some talked about is a known issue with the speed of 24fps itself,

http://www.projectorcentral.com/judder_24p.htm

[Note: This article is dated 2008, before the advent of 120Hz HDTVs and motion-interpolation that's standard now on most sets.]

While most people take the "jumpiness" in stride, it's a major problem for a few. My opinion is that it's a perceptual sensitivity issue, exacerbated by the Teg2's borderline performance, or possibly a crappy player issue. Note that, stock player aside, every 3rd-party player is ffmpeg-based. If ffmpeg has issues--and it has many issues--then playback of all these players would be affected.

I also noticed the jumpiness in one of my sample MP4 clips, that wasn't there in the RMVB source. This happens on my PC. Because it's a VFR clip, I attributed to that. Since it was only for that clip, I didn't look further into it.

Back to your question. I have never tried telecining, as most of the time, we want to do the opposite (IVTC), but telecining, or more specifically 24p to 30p conversion, isn't a big deal. It's just the reverse of IVTC. Search on '24p to 30p conversion'. Here's one from that search

http://forum.videohelp.com/threads/319418-I-need-to-convert-24p-to-30p-fps-please-help

Before you start, arm yourself with how the process works. Once you know this, the rest can be implemented with whatever tool that can do the job. It's just a matter of separating the frames into fields, and recombining the fields into whatever pattern to smoothly fit the desired framerate.

http://en.wikipedia.org/wiki/Telecine#2:3_pulldown

Here is one for 24p to 60p conversion (for broadcasting use).

http://forum.doom9.org/archive/index.php/t-69876.html

The most popular tool to use is AVISynth. Linux guys can use it in Wine. I'm sure field-based operations are possible with ffmpeg, but I never bothered with it due to its arcane syntax and abysmal docs. AVISynth is just more powerful and flexible for this purpose.

Edit: The simplest 24->30 method, as pointed out in one of the above links, is to duplicate every 4th frame. Then there's no need to mess with fields. Many commercial content use this method. It's not noticeable to the human eye.
[Eee Pad Transformer General] sassafras_:
Thanks. I've used AVISynth extensively in the past with MPEG2 encoding so I'm familiar with it already.

I've just never had to do 3:2 pulldown with h.264 encoding so I wasn't sure the best way to accomplish it.

Maybe I'll set up avisynth in my new Debian environment and see if that fixes the apparent judder issue with some of these slow pans.

sassafras
[Eee Pad Transformer General] e.mote:
# Using FFMS2 plugin

A = FFAudioSource("video.mkv")

V = FFVideoSource("video.mkv")

AudioDub(V,A)

AssumeTFF() #change this to fit detected field order

ConvertToYUY2()

SeparateFields()

SelectEvery(8, 0,1,0, 3,2, 5,4,5, 6,7)

Weave()
[Eee Pad Transformer General] levenite:
judder

There is no doubt some judder is being introduced on playback at least on x264 material with sound. If everyone agrees playback is smooth without sound, then how can the judder be inherent in the source 24fps or otherwise?

For a more scientific look at the issue see the video test in the link posted here http://xdaforums.com/showthread.php?t=1132576

Be sure to check out his results directory for direct comparisons of video playback on the various devices. Notice how random the judder appears on the xoom compared to the ipad.
[Eee Pad Transformer General] jadesse:
This little piece of information should have been in post #1.
[Eee Pad Transformer General] sassafras_:
As e.mote suggested, it is probably a result of the Tegra GPU being near its capacity doing motion interpolation on the 24p source without sound. Adding in the sound pushes it over the top and it stops interpolating the frames up to the native screen resolution and just skips it to maintain sync and smooth olayback without dropping frames.

Don't be confused, it's not dropping frames by adding sound its just not blending them anymore to bring the source rate up to the screen native rate.

I'm away from home right now but later I'm going to hard telecine some stuff up to 30 fps and see if that fixes the problem. Stay tuned.

Sassafras
[Eee Pad Transformer General] levenite:
Emote can speak for himself. I don't believe that is what he was saying. How do you explain why people are seeing the issue with even baseline video encodes? Examine the 360p videos in the link; the same type of judder is still there. It has also been mentioned that the judder changes when playing an mpeg2 video. I cannot say that the judder in these videos are what people are seeing, but again, compare the ipad video with the xoom. Which one do you think will have smoother playback? This is a good thing. It probably means some software optimization can resolve the issue.:)
[Eee Pad Transformer General] e.mote:
I think it's the audio decoding, since even the recoded Pan's Lab 640x360 clip was reported to have judder.

To isolate this further, set Mobo to software mode, and play this 640x360 clip with AAC, then with MP3 muxed. With this small-res clip, Teg2's performance is removed as a variable. If judder only occurs with AAC, then it would support the supposition.

Remember that 24->30 conversion produces interlaced material, for which you'd need a deinterlace filter. Suggest yadif for AVISynth.

Secondly, after this conversion, the material will look worse. It's why we use IVTC in the first place. The trade-off is the impact on visual quality against the annoyance from judder.
[Eee Pad Transformer General] e.mote:
Try these in Mobo in software mode.
[Eee Pad Transformer General] sassafras_:
Does Mobo offload the video to the GPU if it is decoding audio with ffmpeg? Since the stock player doesn't support mp3 in the mp4 container I'm concerned that it might just use ffmpeg to software decode the video in the mp3 containing clip.

sassafras
[Eee Pad Transformer General] e.mote:
The point is to use software mode for both, since it's the only way to fairly test MP3 vs AAC. As you say, MP3 in MP4 only plays in software mode. The Teg2 should easily handle these clips in software mode.

To force software mode, these two clip (same as above, but telecined to 29.97) use MKV container.
[Eee Pad Transformer General] sassafras_:
I guess I'm confused then. Are you supposing that the issues with the judder are entirely related to decoding the audio?

Forcing the CPU to render the video work on both seems like it takes out what is the real culprit: the buggy GPU decoding.

For the record, I can see no difference between the two when played using software decoding though both seem less obviously terrible than the original clip at 24fps

sassafras
[Eee Pad Transformer General] e.mote:
>Are you supposing that the issues with the judder are entirely related to decoding the audio?

First, I don't have a Tegra 2, so I can't test this "judder" issue. I'm here for academic interest only.

I can only go by reports from others. Various theories have been raised, 24fps, audio decoding, etc. I'm providing test material for those affected to test their theories.

Feedback should include whether or not judder is present (since that's the whole purpose of these queries). The 29.97 clips are to test whether 24fps is a factor. The AAC-vs-MP3 clips are to test whether AAC decoding is a factor. All were encoded in low-res to remove the Teg2's performance as a factor.

Troubleshooting is a process of systematic elimination of possible causes.
[Eee Pad Transformer General] e.mote:
To test the theory of buggy GPU decoding: Play the 24fps AAC MP4 clip in Mobo in hardware mode, then software mode. If it stutters in hardware but not software, then there's an issue with hardware mode.
[Eee Pad Transformer General] AlexTheStampede:
Either the specific clip or how you people encode, rub the wrong way hardware decoding. Smooth via software, still there via hardware. Now for the best part: both on the TF and the Galaxy tab! My guess is more like "Android hardware decode bug", and not a specific platform/OS/vendor implementation.
[Eee Pad Transformer General] e.mote:
Thanks for the prompting. I should've stated their specs better.

The clips are encoded in x264cli, which is the engine of most every free encoder available. The muxing is by MP4Box, which again is a popular tool used by many software. Both are as standard as they come.

Video encoding params: --preset medium --crf 21 --profile baseline --tune film

Audio encoding params:

NeroAACEnc: -q 0.4

Lame: -V 5 -h --noreplaygain

The 29.97 clips were produced from the 24fps source, using the telecine setting in AVISynth mentioned earlier.
[Eee Pad Transformer General] AlexTheStampede:
Also worth mentioning that software mode dosen't help with the mkv one (tested only the aac version). Just.... wtf.

Yeah, nothing to do with Tegra. It happens even on an Xperia X10 mini pro (600mhz). No software mode as that way it became literally a slideshow.
[Eee Pad Transformer General] sassafras_:
I think you're just overly sensitive. The software decoding of the low quality 29.97 playback is, to my eyes, exactly the same on my PC as the Transformer. With a slow pan like that there will almost assuredly be some judder on an LCD display. There are two ways that the device can turn something encoded at 24 fps into something that refreshes at 30 (or 60) fps. Either it can just insert frames at a certain interval to raise the rate (this causes judder) or it can generate entirely new frames that exist in some state between the two known frames--this is known as interpolation.

Many modern HDTVs have some sort of interpolation algorithm (120Hz sound familiar?) and some computer software players will do it as well (PowerDVD comes to mind). I don't know for sure, but I am willing to bet that the Tegra hardware decoding algorithm is _NOT_ going to interpolate frames, it will just duplicate them to bring it up to the resolution rate. This assumption is based on a few things: First, interpolation takes a non-trivial amount of processing power to accomplish, and second, there is no real reason to do this because your Transformer screen is not an HDTV.

Back to what we're dealing with. There is clearly a problem with the hardware decoder somewhere--it might be the GPU, it might be the demuxer, it might be the rendering library, it might be something about the audio decoding.

I'll admit that I initially dismissed the issue altogether so I'm having to backtrack here somewhat, but I think it should be considered that the original 720p clip without audio is the 'Gold Standard'. There is a little judder, yes, but it's clearly better than when audio is added to the mix.

Alex, I'd like you to watch the original video without audio. You'll see a little judder. This is inevitable and about the best we can hope for.

e.mote, It may be something to do with AAC specifically, but it will be hard to diagnose as (to my knowledge) the only audio filetype supported in the .mp4 container is AAC audio.

What I don't understand is why introducing audio to the video causes such an increase in judder. To my eye, it seems as if the decoder stops duplicating frames altogether making the step between consecutive frames more jarring.

sassafras
[Eee Pad Transformer General] e.mote:
Sure, it may be a lost cause, but the sleuthing process can be worth it for its own sake.

On the report that MPEG2 plays smoother than H.264, here's another thought for low-latency encoding.

For x264cli, try these params

--tune fastdecode (or) --tune zerolatency

Note there can be only one --tune param, so one of these would replace the --tune film param. But you can use both of them by combining their low-level param equivalents.

fastcode is a preset for these params: --no-cabac --no-deblock --no-weightb --weightp 0

zerolatency is a preset for these params: --bframes 0 --force-cfr --no-mbtree --sync-lookahead 0 --sliced-threads --rc-lookahead 0

Sassafras, I guess it's up to you, since it seems that most here have abandoned the chase.
[Eee Pad Transformer General] AlexTheStampede:
And that's also what you get in the 640 test files inside the mp4 with software decode, while the mkv ones tend to the original apparently "hardware centric" issue.

However.... where did everybody else go? :-\ Alone I'm a lousy statistical sample.
[Eee Pad Transformer General] mlbl:
I've tested this out and it works great but havent tried with audio, wonder would the lag kick in if i added audio
[Eee Pad Transformer General] WheresWaldo:
Hey I'm still here but have been preoccupied with family matters. Near the middle of next week I will be able to start focusing on this again.
[Eee Pad Transformer General] jjsoviet:
I'm just waiting for some preset profiles to try lol.
[Eee Pad Transformer General] bartleyg82:
e.mote, I'm thankful and impressed by your dedication to this thread despite not even owning a transformer! Unfortunately, our problems persist...

I tried both fastcode and zerolatency using 640 and 1280 resolutions. Both have the exact same judder as all the other videos that have audio. Aside from waiting for an official fix, I'm pretty much out of ideas. That being said, I'm willing to try any other suggestions that you might have. Thanks again for all of your help.
[Eee Pad Transformer General] sassafras_:
I re-encoded the videos using the WebM codec (VP8 video + ogg audio) and they play back without excessive judder (like the clip without audio).

The catch? It's not GPU dependent so it relies on CPU decoding. This results in single digit frame rates on 720p content.

This does, however, indicate that the GPU codec for h.264 decoding is at fault. Hopefully it is something that can be fixed with a software patch and is not a fault inherent to the Tegra platform.

sassafras
[Eee Pad Transformer General] dcc22:
You should try GPU accelerated converters. Using MediaEspresso dropped the time from 1:40hrs (quadcore 3,6ghz) to 25 minutes (gtx570).
[Eee Pad Transformer General] sassafras_:
You misunderstand. The tablet can only play the media in the single digit frame rates.

Secondarily, I believe GPU acceleration relies on fixed function hardware built into the GPU which works when the GPU is designed to deal with the codec (like h.264) but doesn't do any good when the GPU is not designed for it.

sassafras
[Eee Pad Transformer General] jjsoviet:
I think he meant that converting videos on a PC would be faster if we were using GPU-accelerated encoders. Another example would be Badaboom by nVidia, but unfortunately its features aren't as robust as in Handbrake or RipBot.
[Eee Pad Transformer General] sassafras_:
I know what he meant. I believe he misunderstood what I meant.

I was talking about WebM videos playing poorly on the Transformer, not about the speed of re-encoding them.

To that effect though, the nVidia accelerated encoders (like Badaboom and anything else that uses CUDA) stink. Their output looks terrible in comparison to anything using x264 (which is what Handbrake uses).

sassafras
[Eee Pad Transformer General] ran_k:
quick question, i didnt succeed to encode MKV movies so i can hear the sound,

but is it possible to use Handbrake to increase the sound in other movies?
[Eee Pad Transformer General] CyberMicha:
Is there any way to get 5.1 Sound? Want to stream the video to a TV / mediaplayer.

Tried aac - 6 channels discrete but gut only no sound :)

greetings cyber
[Eee Pad Transformer General] sontin:
The second good news after the 720p flash playback is today that the stuttering problem is not a hardware problem. Because there is way less stuttering in the flash player...

Try the Videos from guimark3: http://www.craftymind.com/guimark3/

Or try the brave teaser:

Youtube Flashplayer: http://www.youtube.com/watch?v=tYg0VgPy6Uk

MP4 from Tubemate: http://www.multiupload.com/I2X1ETXXB0

And don't forget the pan video: http://www.youtube.com/watch?v=RBH7nMFoRXQ
[Eee Pad Transformer General] sassafras_:
You're comparing apples and oranges. The codecs may be different, the encoding parameters are most assuredly different, and the fact that it's wrapped into the Flash Video container, means the job is completed in an entirely different fashion.

It was never confirmed to be a hardware problem (in fact, I still suspect it isn't), but this only provides evidence--it doesn't prove the case.

sassafras
[Eee Pad Transformer General] dmoney94:
Did anybody found a solution for this or NVIDIA Tegra 2 chip is dead.now I know why boxee box dump this chip.
[Eee Pad Transformer General] sontin:
Right now? Use Flash. There is no stuttering.

I asked in the xoom forum and someone wrote that 3.2 fixed the problem. So maybe we get a better playback sooner than later.
[Eee Pad Transformer General] 2slow4u:
I'm really disappointed by the multimedia performance of HC 3.1/Tegra 2 combo.

I felt more of a program to convert my movies, I followed a half dozen different guides with different profiles but microstuttering is unavoidable.

I also noticed that the resolution of the movie is relatively influential, I am finding the same issue even with LD video (DVD), it seems that the limit is precisely in the H264 decoding.

Paradoxically, the software decoding (by moboplayer) of a dvd rip in divx format, provides better results that the same file encoded in native format for Tegra 2 (H264)...

Too bad! :(
[Eee Pad Transformer General] david279:
I think I have found a solution to player problems. It's called dice video player in the market. It plays all my hd mkv's perfectly. There is a trial in the market, tell me what you think of it.
[Eee Pad Transformer General] AustinMartin:
It might just be a placebo effect but this also seems to eliminate the "judder" issue with slow panning scenes in 720p. I'll have to check another movie or two, but this looks pretty sweet.
[Eee Pad Transformer General] sassafras_:
It's just another ffmpeg using player like all the others. However they built it though, it does work a lot better and I would go so far as to say perfect.

Good find. Now I'm going to have to decompile it and see if I can figure out why :)

sassafras