Support and General Use > Plugins/Viewers
Holy cripes, the video project has finally gotten started!
linuxstb:
--- Quote from: Atheistic Freedom on August 07, 2006, 07:52:57 PM ---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.
--- End quote ---
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:
--- Quote from: linuxstb on August 08, 2006, 04:43:53 AM ---
--- Quote from: Atheistic Freedom on August 07, 2006, 07:52:57 PM ---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.
--- End quote ---
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...
--- End quote ---
What did you use to encode the videos?
linuxstb:
--- Quote from: The D on August 08, 2006, 07:13:10 AM ---What did you use to encode the videos?
--- End quote ---
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:
--- Quote from: senab on August 08, 2006, 05:24:45 AM ---In terms of complexity, how complex is MPEG2 to decode? I know H264 is more much more complex, but what about straight MPEG4-V?
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version