Holy cripes, the video project has finally gotten started!

[linuxstb]

It's interesting that it's optimized for the Photo/Color and Nano instead of, well, the Video, but time will tell how good this will turn out to be.

This post doesn't belong in this iPod Video forum - the mpegplayer now in CVS is implemented purely using the CPU, and not using the iPod Video's Broadcom chip.  Hopefully this thread will be moved, so I'm posting a little status update here.

I own an ipod Color, and the Photo/Color and Nano share the same LCD driver, which is why those targets have received the first optimisations.  I also own an ipod 5g, and will be working with that as well. 

All ipods (with colour LCDs) have a more or less identical main CPU (the PortalPlayer chip), which means that out of those targets, the Nano is most likely to get working video support first - a full-screen video on the Nano is only 176x128, compared with 224x176 for the Photo/Color and 320x240 for the Video.  So there is both less data to decode, and less data to write to the LCD.

Currently, the player can play back a 176x128 MPEG-2 file at around 24fps on the ipods - so this means either full-screen on the Nano or smaller than full-screen on the Photo/Color and 5g.  Full-size videos on the Photo/Color and 5g play much slower than that.  The aim is to get this up to at least 25fps (PAL framerate) and hopefully 29.97fps (NTSC framerate) for full-size video on all targets.

The PortalPlayer chips inside the ipods have two 75Mhz ARM cpu cores.  Currently the video player (and Rockbox in general) is just using one.  The hope is that if one core can cope with full-speed video decoding (and writing to the LCD), the other core can be brought into use to handle the audio decoding, buffering the data from disk, and whatever else a video player needs.

Things are not looking as bright on the Coldfire-based targets (iriver H300 and iaudio X5) - full-screen video is around 9fps on the H300 at the moment when running the CPU at the full 124MHz.  And there is no second core to use for audio - the main CPU will need to handle everything.  But these are early days - all the audio codecs were also worryingly slow when first run on the Coldfire.  I personally will probably not be working on the Coldfire version (I don't own a H300 or X5), so developers are needed...

[senab]

In terms of complexity, how complex is MPEG2 to decode? I know H264 is more much more complex, but what about straight MPEG4-V?

[The D]

It's interesting that it's optimized for the Photo/Color and Nano instead of, well, the Video, but time will tell how good this will turn out to be.

This post doesn't belong in this iPod Video forum - the mpegplayer now in CVS is implemented purely using the CPU, and not using the iPod Video's Broadcom chip.  Hopefully this thread will be moved, so I'm posting a little status update here.

I own an ipod Color, and the Photo/Color and Nano share the same LCD driver, which is why those targets have received the first optimisations.  I also own an ipod 5g, and will be working with that as well. 

All ipods (with colour LCDs) have a more or less identical main CPU (the PortalPlayer chip), which means that out of those targets, the Nano is most likely to get working video support first - a full-screen video on the Nano is only 176x128, compared with 224x176 for the Photo/Color and 320x240 for the Video.  So there is both less data to decode, and less data to write to the LCD.

Currently, the player can play back a 176x128 MPEG-2 file at around 24fps on the ipods - so this means either full-screen on the Nano or smaller than full-screen on the Photo/Color and 5g.  Full-size videos on the Photo/Color and 5g play much slower than that.  The aim is to get this up to at least 25fps (PAL framerate) and hopefully 29.97fps (NTSC framerate) for full-size video on all targets.

The PortalPlayer chips inside the ipods have two 75Mhz ARM cpu cores.  Currently the video player (and Rockbox in general) is just using one.  The hope is that if one core can cope with full-speed video decoding (and writing to the LCD), the other core can be brought into use to handle the audio decoding, buffering the data from disk, and whatever else a video player needs.

Things are not looking as bright on the Coldfire-based targets (iriver H300 and iaudio X5) - full-screen video is around 9fps on the H300 at the moment when running the CPU at the full 124MHz.  And there is no second core to use for audio - the main CPU will need to handle everything.  But these are early days - all the audio codecs were also worryingly slow when first run on the Coldfire.  I personally will probably not be working on the Coldfire version (I don't own a H300 or X5), so developers are needed...

What did you use to encode the videos?

[linuxstb]

What did you use to encode the videos?

I'm a Linux user, and used mpeg2enc from the mjpegtools project, converting from an existing MPEG-2 file using mpeg2dec.  An example command is:

mpeg2dec -t 17 -o pgmpipe < inputfile.ts | pgmtoy4m -i p -r 60000:1001 -a 16:9 | y4mscaler -O size=320x176 | yuvfps -r 30000:1001 | mpeg2enc -a 3 -f 8 -q 6 -D 10 -E -10 -K tmpgenc -4 1 -2 1 -o test-320x176.m2v

This example takes a high-definition (1280x720p) 59.94fps input file (MPEG-2 transport stream) and converts to a 320x176 (16:9 aspect ratio, 29.97fps) file for my 5g ipod.

But any MPEG-2 encoder should work - but you'll need to tell it to create a ".m2v" raw video stream, or if your encoder only generates .avi or .mpg files, then you'll need to find another tool to demux the .m2v stream before copying it to your player.

An important thing to remember is that MPEG-2 works with 16x16 blocks - so you should encode to a multiple of 16x16 - e.g. 224x176 for 220x176 LCDs, and 176x128 for the Nano's 176x132 LCD.

[linuxstb]

In terms of complexity, how complex is MPEG2 to decode? I know H264 is more much more complex, but what about straight MPEG4-V?

The short answer is that I don't know - but I would expect MPEG-4 to be more complex.  Newer codecs normally are...  But then again, I expected mpegplayer to perform better with MPEG-1 files than MPEG-2, but it seems to decode them at a similar speed.

There is a port of an xvid decoder on the patch tracker - so it's possible to use that to do some basic speed tests and compare with libmpeg2's performance.

But I don't think it really matters which codec Rockbox supports - to get the best performance, you will always be required to re-encode videos on your PC so that they match the resolution of the LCD on your player.  And I don't think MPEG-4 will give great quality/bitrate gains at such low resolutions -  I'm getting excellent quality at around 450kbps for a 320x176 30fps video stream which is low enough for me.

[senab]

MPEG4 would be better than MPEG2 at low bitrates and H264 would be alot better than both of them. To be honest I don't actually think MPEG4 is that much more complex in terms of computing, H264 would be though and you'd definetly need the broadcom core on the 5G for using that.

[michael.conner]

Are there any plans to get the video out on the Photo/Video models (the composite signal from the headphone jack) working in Rockbox?  I mean, first things first, obviously -- but it would be really cool to be able to use Rockbox to watch video on a TV.

[The D]

What did you use to encode the videos?

I'm a Linux user, and used mpeg2enc from the mjpegtools project, converting from an existing MPEG-2 file using mpeg2dec.  An example command is:

mpeg2dec -t 17 -o pgmpipe < inputfile.ts | pgmtoy4m -i p -r 60000:1001 -a 16:9 | y4mscaler -O size=320x176 | yuvfps -r 30000:1001 | mpeg2enc -a 3 -f 8 -q 6 -D 10 -E -10 -K tmpgenc -4 1 -2 1 -o test-320x176.m2v

This example takes a high-definition (1280x720p) 59.94fps input file (MPEG-2 transport stream) and converts to a 320x176 (16:9 aspect ratio, 29.97fps) file for my 5g ipod.

But any MPEG-2 encoder should work - but you'll need to tell it to create a ".m2v" raw video stream, or if your encoder only generates .avi or .mpg files, then you'll need to find another tool to demux the .m2v stream before copying it to your player.

An important thing to remember is that MPEG-2 works with 16x16 blocks - so you should encode to a multiple of 16x16 - e.g. 224x176 for 220x176 LCDs, and 176x128 for the Nano's 176x132 LCD.

On my gen 5 the video is messed up, odd colours ect.

[Llorean]

Rockbox always plans on supporting every feature of the hardware eventually. It's just a matter of how long.

[linuxstb]

On my gen 5 the video is messed up, odd colours ect.

Please edit when you quote...

What encoder did you use?  It's been reported that mpegplayer has problems dealing with files encoded by ffmpeg (including mencoder).  That's on my list of things to investigate.

[The D]

What encoder did you use?  It's been reported that mpegplayer has problems dealing with files encoded by ffmpeg (including mencoder).  That's on my list of things to investigate.

lol, guess what I used 

[linuxstb]

The video glitches with ffmpeg encoded files should now be fixed in CVS - you can try the latest build from here:

http://www.rockbox.org/cvs.shtml

[laberlaber]

Rockbox always plans on supporting every feature of the hardware eventually. It's just a matter of how long.

Sorry if this sounds stupid, but does this mean that video playback support for the H1x0 series will eventually be implemented?

[Llorean]

They're discussing what to do with H1x0. They're considering taking a different path with it, but we shall see. There will be *some* sort of video support, at least.

[crescentfresh]

Is there some sort of player you will need, or should video just start simply from selecting a file from your list?  I popped an mpg1 file on my player just to see how things would look on it, and it didn't even recognize it as a supported file with today's daily build.