H.264 profile for new 5.5G Ipod?

[migrena]

but using h264 you could produce comparable quality with smaller filesizes, right? if yes its worth checking, especially if someone has 30GB model
personally i find encodes done with xvid more blurry and greyish than encodes done with x264

FYI, see below statistics obtained from a Quicktime Pro 7.1.3 encoded MPEG-4 AVC / H.264 bitstream (iPod setting) :
- Profile : 66
- Level : 30
- Nb. of Ref. pictures : 1
- Weighted P preds : OFF
- Weighted B preds : DEFAULT
- Chroma Q offset : 0
- Entropy coding mode : CAVLC
- Deblocking filter : OFF
- only Intra 16x16, Inter 16x16 and Skip allowed (no Bipred, Direct/NoMC, Intra 4x4, Inter 16x8, Inter 8x16)
why they turned deblocking off? it works for old 320x240 profile...

@Student Driver mpeg4 asp in ipod is very limited - no b-frames, no qpel, no gmc (and probably only h263 quantization matrice), check if setting you selected in megui are meeting those conditions

[Manao]

but using h264 you could produce comparable quality with smaller filesizes, right?Wrong. If they prevent the use of all the tools that makes h264 better than mpeg4, then you end up with a codec only as good as a mpeg4 codec.personally i find encodes done with xvid more blurry and greyish than encodes done with x264You don't prevent x264 from using the 'good' tools ( namely : cabac, deblocking, subpartition, bframes, mreferences... ), that's why you get better results.why they turned deblocking off? it works for old 320x240 profile...Because deblocking slows down the decoding a lot. It's not a question of what features are implemented in the decoder : deblocking is implemented, I bet subpartitions too, and perhaps even cabac. But these features slows the decoding a lot, and the processing power on an ipod is limited. For example, on a computer, deblocking takes ~30% of the decoding time. Cabac can take up to 30% more than cavlc. That's huge.

[BeyondTheEyes]

That's what I said earlier. Yet, it doesn't tell us if the ipod supports more than that. It only tells what their encoder produces.

If the ipod were to support only that ( in 640x480 ), it would make AVC hardly more efficient than mpeg4p2 SP.

-> rate-distortion optimization ?
<- for VGA 30Hz @ 1.5 Mbps, RD-opt may not be that important...:\

[BeyondTheEyes]

Because deblocking slows down the decoding a lot. It's not a question of what features are implemented in the decoder : deblocking is implemented, I bet subpartitions too, and perhaps even cabac. But these features slows the decoding a lot, and the processing power on an ipod is limited. For example, on a computer, deblocking takes ~30% of the decoding time. Cabac can take up to 30% more than cavlc. That's huge.

exactly : S. Jobs does want you to buy 2-hours-length (and more) movies through iTunes 7, movies that you can playback on your brand new iPod 5.5G without having to reload the batteries every 30 minutes... ;-)

[Manao]

RD optimizations are a decision coding tool. Any codec can use them. XviD does ( VHQ is exactly that ), x264 does ( subme 6, 7 ). Trellis ( present in both codecs ) is an avatar of RD opts. DivX 6 uses RD opts too, so does ffmpeg, nero...

RD opts have no influence whatsoever on the decoding complexity.

[BeyondTheEyes]

RD opts have no influence whatsoever on the decoding complexity. agreed, I was thinking aloud about the coding efficiency (independently from the codec used) at 1.5 Mbps for VGA resolution

[BeyondTheEyes]

RD opts have no influence whatsoever on the decoding complexity. More exactly I would counterbalance this statement by highlighting the fact that some RD-opt settings (depending on lambda setting, bit-rate) may tend to favour some MB modes to the detriment of others and results in e.g. many inter MBs that would then require inverse motion compensation at decoder side, which may increase decoding complexity as well, in comparison with intra prediction ?

[Sharktooth]

@BeyondTheEyes: There's a reason if an EDIT button exists...

[Manao]

Any decision algorithm changes the MB modes decision and so is liable ( to a marginal extent ) to make the file easier/harder to decode. RD, in that regards, doesn't differ from other decision schemes.

[_leech_]

Apparently the new version of ffmpegx supports the "new" format:

# Added "iPod H.264 w640" preset to support new high-resolution 640x480 h.264 in updated 5G iPods.

http://www.ffmpegx.com/news.html

[migrena]

Wrong. If they prevent the use of all the tools that makes h264 better than mpeg4, then you end up with a codec only as good as a mpeg4 codec.You don't prevent x264 from using the 'good' tools ( namely : cabac, deblocking, subpartition, bframes, mreferences... ), that's why you get better results.

i was comparing encodes done with 5.5 ipod profile in megui and xvid in virtualdub

Because deblocking slows down the decoding a lot. It's not a question of what features are implemented in the decoder : deblocking is implemented, I bet subpartitions too, and perhaps even cabac. But these features slows the decoding a lot, and the processing power on an ipod is limited. For example, on a computer, deblocking takes ~30% of the decoding time. Cabac can take up to 30% more than cavlc. That's huge.
deblocking works fine with 640x480 clips, but old batteries may have problems with this
external power source can be a resonable solution

[Nic]

Finally found some time. Made a modified MP4Box that mux's 640x H264 files so that Windows iTunes will accept them. :)

Got to do a lot more testing, but will release it tomorrow. Hopefully someone will find it useful.

-Nic

[Student Driver]

Fantastic! So are we able to use Baseline level 3.0 with this, or are there several restrictions we need to keep in mind?

[Sirber]

@Nic

can you post a binary please? :D

[Nic]

@Student Driver: Don't know the limitations yet. My tests mainly are:
x264 --no-cabac --level 30 --progress -B 500 --sar 1:1 -o video.mp4 video.avs
neroAacEnc.exe -br 80000 -if wav.wav -of aac.mp4
NicMP4Box -add aac.mp4 -add video.mp4 Muxed.mp4

Need to do more testing :) (edit: doesn't seem to like b-frames :( )

@Sirber: Patience ;) You'll get the source and binary soon. Currently it's implemented in the worse way possible, but I'm not sure I care, so I may not clean the code up :D

-Nic

[Nic]

http://nic.dnsalias.com/NicMP4Box.zip

There ya go. Hopefully, the ReadMe.txt is comprehensive enough to get you going.

Should allow the muxing of H264 640 width (and less) MP4 files that are compatible with the new iTunes 7.0 and iPod firmware v1.2.

It's worked so far, but I should really have done more testing. Let me know of any issues.

-Nic

[simonhowson]

Thanks so much for the time and effort.

[NWDaniels91]

Thanks, Nic!

I used the "PD-iPod 5.5G" MeGUI profile, and then muxed with YAMB (with the new tweaked MP4Box). It works in iTunes and on the iPod.

I'm guessing it will be a while before MP4Box is officially changed to support the strange iPod needs, and even longer before an option is added to MeGUI to support it. But I don't really care, because I can do it manually, thanks to Nic.


EDIT: I just noticed that the "PD-iPod 5.5G" MeGUI profile has been changed. The only difference I noticed is that P8x8 and B8x8 are turned off. But the video I just encoded, that works fine on the iPod, used the older version of the profile, in which both options were turned on. Could someone explain why they have been turned off?

[Nic]

@NWDaniels91: Glad it worked :) I'm hoping people will use it to give me a full list of what works and what doesn't.

I haven't found an exhaustive list yet of which options work and which ones fail. Otherwise I'll try and make a list myself of what options we can use to and what options will cause iTunes to refuse copying the file.

-Nic

[Student Driver]

OK, I was going to use MeGUI with Sharktooth's "PD-iPod 5.5G" profile as NWDaniels91 did. However, the command line doesn't include "--sar 1:1" and the level is "3" rather than "30". If it worked for NWDaniels91, do we still need these options?

I have to run this via an RDP session and I won't be able to sync until I get home to find out the answer, but I have several videos I would like to get started if it will work. :)

[Nic]

@Student Driver: I just tried with:
x264.exe --no-cabac -o video.mp4 avs.avs

And then after the mux the file worked fine in iTunes and the iPod :) So that's why I need a list of what options work and which ones don't. I'll need to test more.

-Nic

EDIT: The above is incorrect! My automated testing had a bug, that muxed the wrong file!

[Student Driver]

Spiffy. I should know more tonight as I have a conversion going right now.

[NWDaniels91]

Before the firmware upgrade, the iPod could play AVC files with up to 76800 pixels. Apple said the limit was 320x240, but that wasn't entirely true. The iPod could play other resolutions, like 368x208, because it was 76544 pixels, just under the 76800 limit.

After the firmware upgrade, I read somewhere that AVC files now have a hard cap on the width of 640, instead of just the pixel count limit. To test this, I encoded the same 16x9 file with all the same parameters except the resolution. I did one at 640x352 and one at 736x416 (306176 pixels, which is just under the 307200 pixels that 640x480 has). iTunes could play both files just fine, but refused to transfer the 736x416 file to the iPod, because "it cannot be played."

I might try some more tests to see exactly what encoding options work and don't work, but this confirms that there is a hard limit on the video width of 640.

[Nic]

Ok, done more tests:

You definitely need CABAC turned off (--no-cabac)
You don't appear to need a SAR (one might be recommended however, i.e. --sar 1:1)
You do need to set a level (--level 30, although setting --level 3 will also work BTW)
B-Frames are not supported
"-A all" is supported and works fine
-8 does not work
--mixed-refs does work
You can have more than one reference frame (I've tried -r 3 with no problems)
--subme 7 works fine


Most other options require CABAC or b-frames, so they're not relevant.

I hope this helps people when choosing their settings.

Cheers,
-Nic

[Taxidermista]

Before the firmware upgrade, the iPod could play AVC files with up to 76800 pixels. Apple said the limit was 320x240, but that wasn't entirely true. The iPod could play other resolutions, like 368x208, because it was 76544 pixels, just under the 76800 limit.

After the firmware upgrade, I read somewhere that AVC files now have a hard cap on the width of 640, instead of just the pixel count limit. To test this, I encoded the same 16x9 file with all the same parameters except the resolution. I did one at 640x352 and one at 736x416 (306176 pixels, which is just under the 307200 pixels that 640x480 has). iTunes could play both files just fine, but refused to transfer the 736x416 file to the iPod, because "it cannot be played."

I might try some more tests to see exactly what encoding options work and don't work, but this confirms that there is a hard limit on the video width of 640.

I don't know. Have you tried copying the video directly (http://www.ipodwizard.net/showthread.php?t=15015) to your iPod?

[NWDaniels91]

I don't know. Have you tried copying the video directly (http://www.ipodwizard.net/showthread.php?t=15015) to your iPod?

Even if that could get a 736x416 file to play, and there's no evidence that it can, the average user would not want to go through all that trouble for a slightly higher resolution, especially on the 2.5-inch iPod screen.

[dohcmark8]

Just to confirm some more. Using the new MP4Box from Nic and the 5.5G iPod profile in MeGUI, I have just successfully encoded and played a 640x480 music video on the iPod.

Thanks. :)

[Student Driver]

Fantastic! Works great for me! Here's the command line from MeGUI:

C:\Program Files\x264\x264.exe --pass 2 --bitrate 1000 --stats "M:\Ipod Videos\megui\NWD-III-smaller.stats" --level 3 --filter -2,-2 --no-cabac --subme 1 --analyse none --qpmin 16 --vbv-maxrate 1500 --me dia --merange 12 --progress --no-psnr --output "M:\Ipod Videos\megui\NWD-III-smaller.avs" --sar 1:1

[Adub]

Good work there Nic! Mind if I include a link in MeGUI wiki?

[NWDaniels91]

Here's the command line that works for me:
C:\Program Files\MeGUI\x264.exe --pass 2 --bitrate 700 --stats ".stats" --level 3 --ref 2 --mixed-refs --filter -1,-1 --no-cabac --subme 7 --analyse p8x8,b8x8 --qpmin 16 --vbv-maxrate 1500 --me umh --merange 12 --thread-input --progress --no-psnr --output "D:\Video.mp4" "D:\Video.avs"

[Student Driver]

I ran this one, and the iPod pauses during playback (works fine on PC):

C:\Program Files\x264\x264.exe --pass 2 --bitrate 1500 --stats "M:\Ipod Videos\megui\INERTIA-short.stats" --level 3 --filter -1,-1 --no-cabac --subme 6 --analyse p8x8,b8x8,i4x4,p4x4 --qpmin 16 --vbv-maxrate 1500 --me umh --merange 12 --progress --no-psnr --output "M:\Ipod Videos\megui\INERTIA-short.mp4" "M:\Ipod Videos\megui\INERTIA-short.avs"

I presume it's the "--analyse p8x8,b8x8,i4x4,p4x4" part that made it worse, but I'm going to try again without the i4x4 and p4x4 parts.

[Nic]

@Merlin7777: Do whatever you wish with it :)

@Student Driver & NWDaniels91: Thanks for testing, my tests were mainly to test if the file would be transferred to the iPod rather than if it would play well on the iPod, so I'm glad your testing that side of things.

-Nic

[Student Driver]

Cool enough. I ran the same vid clip again and it still pauses with the 8x8 settings as well. I am researching what those actually do (I don't know yet :)) and I wonder if dropping the bitrate down would offset this.

[Nic]

You are really maxing out the bitrate there. I'd drop that down a bit first to help decide which parameters work and which ones don't.

-Nic

[migrena]

iirc -8 is high profile option, i dont think ipod will be able to decode this
[edit] oh, you were talking about -A, i used almost exact settings (bitrate 1100) and they worked

[dohcmark8]

Has anyone else noticed some pretty bad color banding on 640x480 videos? They arent there when I encode in 320x240...

I think it has something to do with how the ipod scales.

[Student Driver]

Well, the videos I have tested look fantastic on my iPod, and great on my PC. I did see some banding in a few sky scenes with earlier attempts, but not so much in these later ones.

The last command I have listed works great at 1Mbps, and I haven't tried going back up in rate. With these options and 1Mbps, I have been getting around 425MB/hr during encoding of 4:3 material.

[migrena]

that banding might be caused by ipod lcd screen, it has only 65k colors

[NWDaniels91]

that banding might be caused by ipod lcd screen, it has only 65k colors

Yep. I've noticed banding while watching videos on the iPod. The same video, on a TV or computer screen, does not show the banding.

[dohcmark8]

I shoulda been more clear, on the iPod 640x480 videos show banding that their 320x250 counterparts do not...

[NWDaniels91]

I shoulda been more clear, on the iPod 640x480 videos show banding that their 320x250 counterparts do not...

I've noticed banding on the iPod for a long time. I see no difference now that the videos are higher resolution.

[Student Driver]

Ditto. Are you trying a common source video that you already had (such as a DVD that you already ripped)?

[dohcmark8]

Ditto. Are you trying a common source video that you already had (such as a DVD that you already ripped)?

Nope its the same exact video, using the same source (DVD music video) and avisynth script and x264 settings, only change is the resolution.

[Paul Curtis]

Since my beloved Rio Karma finally seems to be giving up the ghost, last night I broke down and picked up one of the new 80GB video iPods. Since then, I've made the interesting discovery that the iPod will accept and play MPEG4 files encoded at 50fps (on the built-in screen, anyway--I haven't tried it with an external monitor). Using AviSynth and ProCoder, I've now successfully made several MPEG4 conversions from interlaced PAL video sources, which retain the full temporal resolution of the original footage. My question is, can this also be accomplished with H.264? It certainly can't be done using the iTunes "Convert Selection for iPod" function--I've tried it, and it just knocks everything down to 25fps, eliminating the fluid "video look" that I'm able to get with regular MPEG4. Does the current version of QuickTime Pro permit H.264 encoding at 50p (or 60p, for that matter)? And if so, will the iPod decode and display it at the full frame rate, like it does with 2.5mbps MPEG4?

BTW, I'm a little perplexed by the issue mentioned above re: color banding when 640x480 footage is played on the internal screen. Since (as far as I know) all of the iPod-compatible video formats employ 4:2:0 chroma sampling, wouldn't 640x480 footage offer at least a theoretical improvement, in that the chroma resolution (320x240) would match the screen precisely? (Admittedly, the extra luma resolution would be entirely wasted, so this might not be a very efficient use of bandwidth.)

Thanks very much!
--Paul Curtis

[koosoul]

can someone(NWDaniels91, Student Driver :P) post their final setting that works well on iPod? and someone please tell me how to use commandline...and do you still need to create a aviscript when you have a commandline?

[Adub]

yes you do, as the commandline incorporates the avisynth script.

[koosoul]

hmm i noticed that i can't encode audio, cause meGui won't update neroaccencoder

[Kurtnoise]

@Nic : do you still have the patch for MP4Box ? I would like to merge your code with the disabling of NALU size available in the last cvs entry in my build...Thanks.

[check]

@koosoul - the nero files cannot be hosted on the megui update server. You must download them from nero's site: http://ww2.nero.com/nerodigital/enu/index.html

[celtic_druid]

So using -ipod or m4v/m4a as an extension with mp4box isn't enough?