AVI playback

[GodEater]

And as Llorean says, even with more video codecs supported in the plugin, you would STILL have to resize the videos before you load them onto a Rockbox player, or they won't display right. A lot of original firmware's get to gloss this fact over by forcing you to use some particular piece of software to sync your files with your player, and that then do this scaling on the fly - so you don't notice it's happening.

One of the trade offs you get with Rockbox is we don't make you use any syncing software - it's up to the user - but that means you're going to have to manually do some stuff you'd get "for free" with specialised syncing software.

[reszerve]

Just a follow up query on this - why would you need to resize the video file?  Don't devices like the gigabeat f/x/s have enough grunt to rescale in real time?

Clearly resizing to to actual screen size lowers CPU work on playback, but based on my experience with desktop PC's, even those of ten years ago did not seem to find on the fly rescaling too hard.

Is this just another way of saying many of the target devices don't have enough grunt?

[GodEater]

The Gigabeat S might have enough grunt to do it. The F/X I'm not so sure about. *No* other Rockbox target has got anything like the processing power to do it. The iPod Video doesn't even have enough grunt to playback movies that ARE the right size for it at a decent framerate.

[saratoga]

Clearly resizing to to actual screen size lowers CPU work on playback, but based on my experience with desktop PC's, even those of ten years ago did not seem to find on the fly rescaling too hard.

Ten years ago PCs already ran at 1GHz and had GPUs.  Even the S is many times slower. 

[XVilka]

May you can add only support of AVI container (and may be others, for example mkv) from libavformat (part of ffmpeg)?
And other codecs can added more simply.

[saratoga]

May you can add only support of AVI container (and may be others, for example mkv) from libavformat (part of ffmpeg)?
And other codecs can added more simply.

Its certainly possible to add other containers right now.  Just takes some effort.

(IMO VOB makes a lot more sense then AVI given that MPEG2 in AVI is nonexistant). 

[gottahavit]

ok so mostly because I'm bored right now and was curious how this might work.  I ported an mpeg-4/avi decoder I worked with a few years ago to rockbox this weekend.  Right now it's just decoding and displaying AFAP to the display, but I do have the decoding and display working(at least on my sansa and the simulator).  If anyone with a faster target device is curious to try this I would love to see how fast it is on other devices.

If you are interested please PM me with your device info and contact info and I will get you a .rock to try it out.

Please keep in mind this is not a functional "player" it's just decoding and rendering the video, no audio, no menus and I take no responsibility for crashing your player.

As for speed on my e280 v1 it can decode and display 220X176 divx encoded at 250kbps at an average of 26fps.  not sure how much I can speed it up but at least with dual core audio won't slow it down.

I am currently working on adding audio and synching.  Later assuming I don't lose interest I will look at re-using mpegplayer UI and controls.

[saratoga]

ok so mostly because I'm bored right now and was curious how this might work.  I ported an mpeg-4/avi decoder I worked with a few years ago to rockbox this weekend.  Right now it's just decoding and displaying AFAP to the display, but I do have the decoding and display working(at least on my sansa and the simulator). 

Awesome!

If you are interested please PM me with your device info and contact info and I will get you a .rock to try it out.

This probably won't work.  .rock files usually don't work too well outside of the version they're compiled for.  A better idea would be to open a flyspray task with your patch and then ask people to test it on various devices and post the results there.  Plus technically you have to give out the source code with the .rock file anyway, so its usually just easier to use the patch tracker.

[gottahavit]

ok so mostly because I'm bored right now and was curious how this might work.  I ported an mpeg-4/avi decoder I worked with a few years ago to rockbox this weekend.  Right now it's just decoding and displaying AFAP to the display, but I do have the decoding and display working(at least on my sansa and the simulator). 

Awesome!

If you are interested please PM me with your device info and contact info and I will get you a .rock to try it out.

This probably won't work.  .rock files usually don't work too well outside of the version they're compiled for.  A better idea would be to open a flyspray task with your patch and then ask people to test it on various devices and post the results there.  Plus technically you have to give out the source code with the .rock file anyway, so its usually just easier to use the patch tracker.

Well I looked and the plugin version hasn't been updated in quite a while so anyone with a recent version should be able to add the reference in the viewers config and copy in the .rock. 

As it stands the code is a total mess and I have no intentions of releasing it in it's current state for view by anyone nor making the test available to more than a few people at this point.

IF and WHEN this gets closer to a useable target I will be happy to submit it to the rockbox gods to see if they want to include in the official build, but right now I am just looking for couple people to confirm this as a proof of concept.

If this is against any rockbox rules then I will withdraw the request for testers and wait until I have this in a more useable state. 

BTW I Don't want to start a big phillisophical debate, but I have never heard anyone claim that GPL negates the ability to distribute limited binary only release  to testers. 

[saratoga]

As it stands the code is a total mess and I have no intentions of releasing it in it's current state for view by anyone nor making the test available to more than a few people at this point.

IF and WHEN this gets closer to a useable target I will be happy to submit it to the rockbox gods to see if they want to include in the official build, but right now I am just looking for couple people to confirm this as a proof of concept.

If this is against any rockbox rules then I will withdraw the request for testers and wait until I have this in a more useable state. 

BTW I Don't want to start a big phillisophical debate, but I have never heard anyone claim that GPL negates the ability to distribute limited binary only release  to testers. 

It does't prevent a limited test, but you'd have to give the limited set of testers the source code. 

And if you're going to do that, I recommend posting the source code on the patch tracker.  Generally people post code there before its ready to be committed since it allows feedback while the code is under revision, which most people find helpful.  Not to mention its kind of silly to ask a community of developers and hackers for feedback modifying code they wrote without showing them what you changed

[Llorean]

The GPL requires that if you give someone the binary, and they ask for the source, you have to then give them the source.

So you can distribute the binary to testers, but then any one of them can request the source and then pass it on to share.

Why not just post it, so you can get feedback about the code too, as well as help developing it further?

[gottahavit]

The GPL requires that if you give someone the binary, and they ask for the source, you have to then give them the source.

So you can distribute the binary to testers, but then any one of them can request the source and then pass it on to share.

Why not just post it, so you can get feedback about the code too, as well as help developing it further?

because as I said the code is currently a total mess and has lots of stuff I already know needs to be completely reworked.  but that's fine if that is the current SOP on this community then I will simply keep working on this as I have time and IF/WHEN it ever gets to a point where I think it's actually useable  and I get the code to a point where I actually want feedback and suggestions then I will post.

again I don't want to get into a big GPL argument here(been there done that), but I can tell you that I have worked on and run several GPL and GPL "mutant" projects in the past and have never had an issue picking a couple beta testers have them do quick runs of my code without publishing the "proof of concept" source.

Apparently I jumped the gun here. NBD. :-)

[Llorean]

I'm not saying you won't get testers. I'm simply pointing out that if one of those testers decides he or she also wants the source, you will be in violation of the GPL if you deny them.

It's not a community issue. Go and actually read the GPL. Giving them the test version is distributing a binary, and there are obligations that come with doing so.

Seriously, if you know there's lots of cleanup to be done post it to the tracker with a mention of what you intend to clean up. That way if you disappear or don't have time to finish it, someone can continue the work anyway.

Simply put, your work benefits nobody until it's shared - the sooner you share it, the sooner you can cement your place as having contributed something.

If it already decodes at 26fps, it's a solid starting point for anyone to work on even if over the next two years you don't have a minute of free time. But if you're in a car wreck tomorrow, the entire Rockbox community loses out on having a chance to benefit from the time you've already put into it.

[gbl08ma]

So, we got stuck? It seems so. Or that, or the mpeg-4 decoder of the above posts was "written" in 1st April... which, just in case you don't remember, is April fools day on many countries.

But assuming that mpeg-4 decoder at 26fps was not a fool, it seems we got stuck since there is no patch available to public...
"That way if you disappear or don't have time to finish it, someone can continue the work anyway." (Llorean)

Sorry for reviving a very old thread. But, even having only an iPod Nano with a microscopic screen, I sometimes like to watch videos in there (specially videoclips) and I'm tired of having to convert everything to mpeg-1 or mpeg-2 format getting an enormous file size.

Yes, I understand that most targets don't have power to decode mpeg-4, but anyways is there any progress in the video scene? If mpeg-4 is too much heavy, is there any other format that could replace mpeg-4, providing the same quality but not enlarging the file size as mpeg-1 and mpeg-2?

Thanks.

[saratoga]

So, we got stuck? It seems so. Or that, or the mpeg-4 decoder of the above posts was "written" in 1st April... which, just in case you don't remember, is April fools day on many countries.

He didn't write anything so there never was anything to get stuck. 

Sorry for reviving a very old thread. But, even having only an iPod Nano with a microscopic screen, I sometimes like to watch videos in there (specially videoclips) and I'm tired of having to convert everything to mpeg-1 or mpeg-2 format getting an enormous file size.

File size for MPEG4-SP videos is basically the same as MPEG2, and of course you'll still have to convert them to MPEG4-SP in the first place.

there any other format that could replace mpeg-4, providing the same quality but not enlarging the file size as mpeg-1 and mpeg-2?

Yes, MPEG2.