yashsingh1/xdaforums huggingface dataset:
[Nook Color General] a.fenderson:
thanks for testing, all!

Awesome, thanks for testing! :)

Therein lies the issue. This is relatively ineffecient codec, space-wise, because it's intra-only: MediaInfo reports the video bitrate as 17.4 Mbps, which is comparable to Blu-ray bitrates of 1920x1080 material. This clip is exactly one minute @ 125 MB, so at 90 minutes this would be (depending on how you define 1 GB) between 10 and 11.25 GB. For a 2-hour, 120-minute film, you're looking at around 15 GB. There may be further refinements to the bitrate possible, through lowering the quanitzer a bit during encode, but you'll likely lose quality quickly and end up being better off with up-scaled, hardware-decoded AVC @ 854x480.

As for the YouTube how-to, I'm not very good on camera, and I'm quite sure that the method I used was very inefficient--I just had to use the apps I'm familiar with, apart from XviD4PSP, so for now I'll give a brief workflow, to be followed by a detailed written step-by-step, and then I'll let someone smarter than me boil that down to an easier process. ;)

This assumes a non-branching disc with one single .M2TS file comprising the entire feature:

1. Decrypt & rip BD to HDD via AnyDVD-HD--for content you own, IF this is legal in your location, some restrictions apply. ;)

2. Demux the video and audio streams of the feature .M2TS file into their raw components using tsMuxeRGui 1.10.6.

3. Use VLC's Convert/Save function to convert the audio to raw MP3, down-sampled to 44.1 KHz at 96 Kbps, stereo/2-channel.

4. Remux the original demuxed video and the new MP3 audio track to .TS via tsMuxeR

5. Drop the file into XviD4PSP (link warning: although this program is great, the site is one huge monolithic Silverlight monstrosity--it is composed of slow and fail), and convert to container .AVI, video M-JPEG scaled to 1024x600, compression quantizer 1; leave audio intact via "copy".

6. Enjoy near-HD goodness. :)

Now THAT is good news! But please give details on the clip: codec, bitrate, encode-options if known, and is it actually high-detail that ends up looking comparable or better than the "Just Say Yes" M-JPEG clip, with no stuttering or other issues? Would it be possible to share a segment of it so others can try to reproduce the playback?
[Nook Color General] Divine_Madcat:
I may have spoken too fast, as the audio comes across as a loud hiss... but the video is flawless. If you want to try it:

http://dl.dropbox.com/u/19844443/VIDEO0021.3gp

The video plays with hardware decoding mode on BTW.. its just the audio that isn't playing right.. bummer..
[Nook Color General] colbur87:
OMG I tested your video clip and WOW. It looked freaking amazing. It is by far the best quality I have seen yet on my nook. I think proof of concept is confirmed.

Audio works fine for me as well
[Nook Color General] swaaye:
I wonder if a profile for Xvid could be made that would have low enough CPU usage on playback. There are a number of settings that reduce playback complexity.

For example,

http://forum.doom9.org/showthread.php?p=398214

I'm not a big fan of encoding videos to a specific device because said device will be obsolete within a year anyway. We are really close to having handheld devices that will play anything.

I think most of our software players are using a port of FFMPEG and I'm not sure how optimized that is for ARM NEON. A Google search does show some talk about NEON optimizations though. But I'm thinking that it could go a lot farther given some time...

http://www.google.com/search?hl=en&...official&q=ffmpeg+neon&aq=f&aqi=g10&aql=f&oq=

Be thankful for the popularity of ARM cpus. :) It helps make things happen.
[Nook Color General] cowballz69:
just to let u guys know the audio and video was PERFECT , no audio stuttering and im sure its due to the newest test kernel and alsa patch. so if u have audio issues with his clip he uploaded def flash new test kernel and alsa
[Nook Color General] a.fenderson:
Thanks. I've remuxed your 720p MP4-ASP file to an AVI, with the original video intact, and the audio converted to mp3 @ 64 Kbps (you're not losing much quality here, subjectively), and the sampling rate was already super low. Try it now, if you want, maybe this will play: http://www.slingfile.com/file/wC8Wczp3d6

Excerpts from MediaInfo on your original file's video (it must have lost lots of this header info in the remux):

Format : MPEG-4 Visual

Format profile : Simple@L6

Format settings, BVOP : Yes

Format settings, QPel : No

Format settings, GMC : No warppoints

Format settings, Matrix : Default (H.263)

Codec ID : 20

Duration : 18s 234ms

Bit rate mode : Constant

Bit rate : 8 000 Kbps

Width : 1 280 pixels

Height : 720 pixels

Display aspect ratio : 16:9

Frame rate mode : Variable

Frame rate : 23.527 fps

Minimum frame rate : 5.000 fps

Maximum frame rate : 33.333 fps

Color space : YUV

Bit depth : 8 bits

Scan type : Progressive

Excerpts from MediaInfo on the reencoded audio:

Audio

Codec ID/Hint : MP3

Bit rate mode : Constant

Bit rate : 64.0 Kbps

Channel(s) : 1 channel

Sampling rate : 8 000 Hz

Great, thanks! I actually hated having to lower the quality of the audio as per recommendations in this thread (props to dalingrin et al), because at this bitrate I can hear compression artifacts really easily, but if I could find a way to stick M-JPEG and AAC in a workable container, maybe the increased quality will help negate the low bitrate. Or, maybe the lower sampling rate has more impact than the lower bitrate and we could bump the audio Kbps back up--more experimentation needed, but I don't have access to the rip until I get home.

See above--Divine_Madcat was playing 720p MP4-ASP/XviD-encoded material, with only slight audio problems. See if the remux I posted works on yours with audio intact.

On the one hand, I completely agree--this is a lot of work to produce some really huge files that don't necessarily have much use elsewhere (apart from iPads, from which specs I actually got the initial idea), but on the other hand, even if it's only for having one super high-quality sample clip that plays absolutely perfectly so I can show it off to my geek friends and family and leave them stunned at the quality, it'll be worth it. ;)

Bring on the optimizations! :D
[Nook Color General] dalingrin:
I never said anything about lowering the bitrate. If you can tell a difference between 48K and 44.1K on the horrible nook audio then props to you =P

Any audio issues related to sample rate are fixed now anyway
[Nook Color General] a.fenderson:
Thanks for the info, and I'm sorry--I didn't mean to misquote you. Lowering sampling rate to 44.1K and bitrate was the overall plan I came away with after reading through that entire thread. It's great to know that the audio sampling rates can be high enough to maintain near-transparency. And no, I can't tell a difference between 48K and 44.1K sampling rate, all other things being equal, even on half-way decent equipment. No golden ears here. ;)

Edit: when I said "maybe the lower sampling rate has more impact than the lower bitrate" I meant on playability, not on audio quality. My bad.
[Nook Color General] dalingrin:
No worries, i just wanted to make it clear.
[Nook Color General] Divine_Madcat:
So, i tried the new version of my video, and while the audio sounds good, it is out of sync. Not studdering, just a few seconds fast (the bird chirps are before the bird actually starts doing it..
[Nook Color General] a.fenderson:
I downloaded my upload (...yeah...) and it's playing in sync on pc via VLC, so I think it's not a delay issue in the muxing, and would seem to be a genuine playback issue, but it's strange that it's just the sync. Maybe the player isn't picking up audio delay/sync data from the container.

I tried remuxing your original file several times, with no success--my tools keep crashing. I'll try again later on another pc.
[Nook Color General] a.fenderson:
Here's the same video, but encoded in H264, 854x480. In all fairness, I didn't go back to the 1080p source (I used my M-JPEG as source, but since I'm downscaling it should give fairly representative results), as I don't have access to the BD-rip at the moment, and I didn't have/exert control over the scaling method used by Handbrake. Could someone try playing back with and without hardware accel, and qualitatively compare it to the largish M-JPEG file @ 1024x600? Any impressions or info is welcome, especially from any gurus who can parse my encode options below and make sure I didn't violate any of the level/profile/etc restrictions for hardware-decode on this device.

Short version: 2-pass, 3000 Kbps VBR, and overkill on the analysis.

Full MediaInfo report:

General

Complete name : [redacted]Just Say Yes Handbrake Test.m4v

Format : MPEG-4

Format profile : Base Media / Version 2

Codec ID : mp42

File size : 22.4 MiB

Duration : 59s 935ms

Overall bit rate : 3 131 Kbps

Encoded date : UTC 2011-04-14 23:41:31

Tagged date : UTC 2011-04-14 23:56:33

Writing application : HandBrake 0.9.5 2011010300

Video

ID : 1

Format : AVC

Format/Info : Advanced Video Codec

Format profile : Baseline@L3.0

Format settings, CABAC : No

Format settings, ReFrames : 2 frames

Codec ID : avc1

Codec ID/Info : Advanced Video Coding

Duration : 59s 935ms

Bit rate mode : Variable

Bit rate : 3 000 Kbps

Width : 854 pixels

Height : 480 pixels

Display aspect ratio : 16:9

Frame rate mode : Variable

Frame rate : 23.976 fps

Minimum frame rate : 23.974 fps

Maximum frame rate : 23.994 fps

Color space : YUV

Chroma subsampling : 4:2:0

Bit depth : 8 bits

Scan type : Progressive

Bits/(Pixel*Frame) : 0.305

Stream size : 21.4 MiB (96%)

Writing library : x264 core 112

Encoding settings : cabac=0 / ref=2 / deblock=1:0:0 / analyse=0x1:0x111 / me=tesa / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=20 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=240 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=3000 / ratetol=1.0 / qcomp=0.60 / qpmin=3 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

Encoded date : UTC 2011-04-14 23:41:31

Tagged date : UTC 2011-04-14 23:56:33

Color primaries : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M

Transfer characteristics : BT.709-5, BT.1361

Matrix coefficients : BT.601-6 525, BT.1358 525, BT.1700 NTSC, SMPTE 170M

Audio

ID : 2

Format : AAC

Format/Info : Advanced Audio Codec

Format profile : LC

Codec ID : 40

Duration : 59s 721ms

Bit rate mode : Variable

Bit rate : 128 Kbps

Maximum bit rate : 264 Kbps

Channel(s) : 2 channels

Channel positions : Front: L R

Sampling rate : 44.1 KHz

Compression mode : Lossy

Stream size : 933 KiB (4%)

Encoded date : UTC 2011-04-14 23:41:31

Tagged date : UTC 2011-04-14 23:56:32
[Nook Color General] a.fenderson:
If we could get to the point of 1280x720p24(/30?/60?????) AVC playing smoothly with an established set of encode parameters, that would be incredibly awesome. This is going to be an incredibly noobish question, but since you know so much about the hardware: would it be possible for a media player to distribute the decoding process between the cpu and the dsp, possibly alternate frame rendering to each, so that together they are able to consistently decode decent-bitrate 720p AVC? Or do some/all of the available players already implement some form of this scheme anyway?

Further M-JPEG 1024x600 experimentation:

Let's step it up a bit, frame-rate style, and see how the NC fares with this file:

1024x600 @ 30 fps M-JPEG, 69 seconds, 213 MB (w/ audio) (the file-name on the hosting site reflects the source material, forgot to change it)

(Note: this clip is not from as visually-sharp and high-bandwidth a source as was the Just Say Yes 1024x600@24fps clip, but it should serve to test 30fps playback.)

More to come (60fps!?!?!)....
[Nook Color General] Divine_Madcat:
No offense a.fenderson, but you give aludal a bit too much credit by saying "you know so much about the hardware".. I won't go into detail, but needless to say, its too much.

As it is, our TI chip has a hardware decoder (DSP) that is capable of 854x480 decoding. Anything above that, and other non supported codecs, are in software. This has NOTHING to do with the GPU that aludal keeps mentioning (which has driven more than one dev mad; the GPU is working fine, but is NOT responsible for our decoding duties). Frankly, the impressive looking post up there is not much more than rambling babble, and has little to do with what is going on here.

Yes, i am coming off as a jerk, but there is too much misinformation out there, which is getting wrongly spread. Our chip, the 3621, is basically a slightly souped up 3620, which unlike the 3630, has a weaker DSP. Information about our chipset is here:

http://focus.ti.com/general/docs/wt...65895&DCMP=wtbu_ebook_2010&HQS=Other+OT+ebook

The important quote:

Why he keeps thinking that our hardware can decode anthing above 480P is beyond me and aggrivating. It has nothing to do with B&Ns devs, or ours.. it is hardware, plain and simple.

I will conceed that the B&N shipped OS had more supported codecs, and hopefully we can get more for CM7 in the future.. But that is the only thing our DSP is lacking right now. Given that our DSP is offically the TMS320C64x+, it also means that C64x+ Codecs should be compatible as given here:

http://focus.ti.com/dsp/docs/dspfin...tionId=3&tabId=1460&toolTypeId=65&familyId=44

Mobo player, on the other hand, is interesing, since it makes use of ARM 7 specific instructions, which seem to enable psudo hardware decoding (it is still done by the CPU, thus software, but using extra instructions not normally used, providing more capability) (Arm7 neon)..

Anyway, i may take some flack, but i have to call it like i see it. I think we have some room for improvement, but lets get it right, withh respect ot what CAN and CANNOT be done...mmmk?
[Nook Color General] a.fenderson:
Thanks for the info and the links.

On that second page, where the C64x+ DSP (among others) has its inherent abilities outlined in the chart, do you interpret "MPEG-4 Video" there to mean ASP/DivX/Xvid?

Also interesting that it does have a JPEG image decoder function in the DSP--makes me wonder whether M-JPEG playback on the available players is being done in software/CPU, or DSP, or a combination of both--or could be done this way if needed. Thoughts on this?

So this definitively precludes CPU/DSP distributed decode of >480p resolutions, even at effectively half-or-lower framerates from the DSP's standpoint, when using the DSP-supported codecs?

Off-hand, do you (or anyone) know if the screen on the NC is actually capable of 60p refresh rates?

Forum-related aside: anyone else notice that when quoting other posts, they show italicized in preview, but not after you post, unless you add italics tags? Kind of annoying.
[Nook Color General] swaaye:
MPEG4 is a standard that encompasses many modern video codecs. DIVX/Xvid are MPEG4-ASP, a simpler and earlier standard than MPEG4 AVC/H.264.

http://en.wikipedia.org/wiki/MPEG-4

I actually find it somewhat interesting that there is a DSP at all considering how impressive NEON sounds. This could mean that NEON is not nearly as practical/powerful as it seems. But on the other hand having a DSP taking care of video allows the system to remain responsive because the CPU isn't maxed out while playing a video. It also surely uses less power than the CPU would.

If the DSP doesn't have HD video support well that's the end of that. CPU is the only hope. Maybe the DSP could be used to partially offload but that would require a more flexible interface for accessing it and it doesn't exist AFAIK. This will become a moot point in a year though once all devices are HD capable, so frankly I don't think it would be worth the effort to try to push our obsolete hardware somewhere it wasn't meant to go.

I do wish that the DSP could be coaxed into liking .mkv files with AAC and H.264 inside. It's so inflexible right now that it's a real shame and that's probably because of how closed TI is about the details of the hardware and no open source codecs.
[Nook Color General] Divine_Madcat:
I have to say, Mobo player v7 Neon works quite well, and decodes the previously posted "Pirates" trailer at 720P extremely well, with no shuddering. It is making use of the NEON SMID extensions, and i think its fair to say, that it shows...
[Nook Color General] swaaye:
I will check it out. :)
[Nook Color General] aludal:
Actually, I don't know anything about our SGX GPU (PowerVR SGX530) and DSP (IVA2.2 (?) apart from very scarce, incomplete specs that TI decided to publish. I know next to nothing about NEON implementations between Android 2.1, 2.2 and 2.3, I know they are different, and even if these were found working at some stage, then they become non-forward-portable (Stagefright of Froyo is completely different from "HW" stagefright subsystem of @.3.3 -- just as an example).

Now Google in its infinite wisdom has decided to fade off NEON as a bad, weak, non-scalable enough concept for tablets (read: XOOM Tegra2 of which BTW doesn't support NEON by its "clever" design)

Our only hope is adapting and using current TI SGX and DSP code. However, it might be only used with kernels 2.6.3x, or so it seems.

Another hope is getting a help of an experienced FFmpeg programmer who could clean and tune up our particular implementation. Plus an ALSA programmer, memory/cache optimizer...

A very distant and almost unreal hope is to get a qualified 2D/3D (Open GL EX) graphics driver developer and maybe even a (DirectFB) hardware overlay programmer.

A good indication of everything above well done is a smooth rendering of Web page layout/video playback when changing the NC orientation from, say, landscape to portrait, (like that demonstrated by Playbook, iPad, and dual-core Snapdragon devices). We also can expect extremely fast scrolling of pages rendered in stock browser (like in Opera Mobile today) and overall "iPad" level of responsiveness.

I repeat, I do believe it's all doable, many piece of code needed here might be even developed and fine tuned by our CM team for CM 7.1, CM 7.2, etc. projects. Or CM 8?

As for HW assisted/accelerated video pipeline, since DirectX for x86 architecture, it was divided into (DSP) demuxing, decoding (20...30 % of all video processing computational workload) and HW overlay offered (or not?) by SGX's shaders. It could reach 80...70 % of total workload, because the task of scaling and "deinterlacing", resyncing -- like in generating "non-existent" frames. If somebody would argue that ARM/embedded Linux video workflow is seriously different from DirectX/DirectFB framework, I'd be puzzled. Now, some players boast they have hardware assisted FFmpeg implementations. When these obviously won't work, then something is missing either in their implementations, or in our NC, or both.

P.S. SGX530-based Intel's GMA-something in my 7-year old ThinkPad T41p does 10...12 Mb/sec mpeg4/H.264/AVC video (up to "720p") perfectly well.

-----------------

fineoils.blogspot.com
[Nook Color General] swaaye:
I think you are asking a LOT of our community developers though. Optimizing all of those subsystems is probably a job for 20 specialized programmers (and they don't work for free). Blame Google, indeed. It's also B&N's fault, but you know they aren't selling these Nook Colors as full featured multimedia devices in the first place.

I tried out the Xoom the other day at a store. I went right to the browser and to the XDA forums here to see if it was still slow, and it was. Blame Google More. ;) Apparently Dolphin HD is hardware accelerated on 3.0 though, and of course Opera Mobile is amazing (but I dislike the UI and its permanent overview mode).
[Nook Color General] a.fenderson:
I know, but if you check the page I was referencing, they list "H.264" which is specific for MPEG-4 Part 10 / AVC, and "MPEG-4" which is vague and really means, well, not a lot, seeing as how by itself it encompasses H.264 and ASP.

Well, I plan on getting an NC soon, and not getting rid of it in only a year's time. Development geared towards it may not be active at that time, but meanwhile, if the smart people can push the limits of what it can do, via NEON extensions or otherwise, all the better! :D

That's what I'm talking about--if this can be pushed, perfected, and made reliable within certain encode restraints, I'd be happy--720p H264/AVC would be great, because it's something that's also presumably "good enough" even for most higher-end mobile video devices and scenarios, requiring no reencodes for other/future/"better" devices, even ones with higher-res screens (at least for me and others for whom decent 720p is just fine on portable devices).
[Nook Color General] Divine_Madcat:
P.S..... SO WHAT. Its not the SGX that is decoding. Please, for the love of god, try to understand this. It is our DSP that is doing the work. Stop referring to the SGX at all!

@a.fenderson- in case youa re interested in Mobo Player:

http://www.moboplayer.com/moboplayer_en.html#faq
[Nook Color General] swaaye:
I suggest you not buy a NC if video playback is a priority because there are zero guarantees that it will ever be anywhere near perfect for it. There are going to be much more suitable devices not far into the future. There already are better devices, they just cost more, but you do get what you pay for.

If it can't do what you want on day one you are betting your money on developers who are volunteering. they will lose interest at some point. there may also be issues that can't be solved or are simply too complex for them to want to deal with.

Personally I bought the NC as a hobby hacking project, a taste of tablets, and as a mobile Internet device but that's it. It was cheap so the cost of entry was nice and that's good because I think I prefer my 3 yr old EeePC 900 over the tablet experience.

Mobo Player seems to have problems with mkv H.264+5.1 AAC 480p so I'm not all that impressed. It's mostly smooth but the audio is just a squeal. These files seem to be the ultimate test for Android video players. Of course the EeePC on XP can play them fine. It can even play 1360x768 H.264+AAC these days thanks to FFMPEG advancements and this is just a 900 MHz Celeron M.

yxPlayer Neon plays them with audio but has sync issues and appears to reduce color depth causing banding.
[Nook Color General] a.fenderson:
Thanks for the recommendation. Perfect video playback isn't a necessity, though it would be nice. At the price level, and elegance of the hardware, it's just too tempting to pass up. Also, I need something of a hobby toy that I can play around with, and the idea of making it do things it wasn't designed to do also has a strange appeal. :) Of course I'm not a developer, but even finding ways of pushing the limits of the hardware through things I can control (video-encode, etc) should be fun. And just having something with simple spreadsheets that's portable would be very convenient. I'm sure I can find plenty of uses for it that don't attempt to surpass its hard limits.

Assuming, though, that video playback were the most important and overriding factor, and given a price range around say $350 USD, what devices do you think are/will be a better choice?

As for moboplayer having the issues you mentioned: does the video stream strictly comply to the requirements of the DSP's decode limitations for H.264? And why would you need a 5.1 audio stream?
[Nook Color General] djlim4:
i got my NC used for $160 and i don't regret it at all

The devs for this device are awesome.

But if i was willing to spend $350, i would've picked up iPad 1st gen or the samsung tab