Weird freezes on DIVX5 movies / PocketMVP

[KuroNeko]

I used to have freezes that lasted a second or so, every 1-1.5 minutes. A Hard-Reset of my Ipaq3970 and playing with PocketMVP's cache solved this.

But now I've started to make my own encodes, and things 've turned odd. I now have freezes that last 10-15 seconds (at first I thought it just got stuck...). This happens at irregular intervals (sometimes no freeze for 15 minutes, sometimes a few within 5 minutes). I have about 5 freezes in a DIVX5 file of 45 minutes.

Really annoying and really weird, as I don't see any problems when playing this on a desktop PC. Haven't had a chance to try it on a friend's Dell yet (he's on holiday). Scenes where it happens can be action or just dialog shots, so I don't think the CPU is overloaded then.

My settings in Vdubmod (encoding SVCD to DIVX5):

- filters: resize 480x480 to 320x240 (restoring correct aspect ratio as well) and rotate 90 degrees left

- decimate frames by 2, leave encode to progressive and unchanged framerate of 23.98)

- DIVX5.05. Profile "portable" checked, stuff like Bframes, psychononsense etc is all turned off. Crop is set to crop 50 off the left and 54 off the right, leaving a resolution of 136x320. Encode at 150kbits, multipass (2 passes total).

Afterwards, audio is re-encoded (Vdubmod does not do audio re-encode) with Vdub, using MPEG layer 3 encoding at 40kbit, 22KHz, 5K/sec stereo. Simple directs stream copy for video, no re-encode here.

I used these settings to re-encode a DIVX movie (single pass though), and didn't have this problem - seems to happen when re-encoding SVCDs only...

Any ideas WTH is happening?

TIA!
Neko

[Buddha]

Weird problem,

If I understand you correctly: when you convert a ('big') DivX movie to a smaller (ppc-sized) DivX movie with Single-pass you don't have the 'stopping problem' but when you convert a SVCD to a DivX you have the stopping problem?

While I can't you why this is happening, most of your settings are ok, here are a couple of pointers:

-Do you have the same problem when you play a movie that is stored in the internal memory of your ppc?

-136x320 is not a totally 'valid' resolution, it should always be divisible by 16. Does the single-pass movie have the same res?

-Try encoding a movie with DivX 5.02 or 5.03

-Try encoding a SVCD movie in Single-pass and see if the problem still occurs.

-Does the problem still happen when you turn off caching in PocketMVP or does it get worse? I know you've turned it on but just for double-checking's sake try turning it off again)

-Try encoding a SVCD movie with mono sound instead of stereo and see if it still happens.

-Encode a SVCD movie without sound and play it on your ppc and again see if the problem still occurs.

Good luck!

[KuroNeko]

Thanks for your reply. I'm in the process of doing what you suggested already, but on my slow PC you can imagine how long all those variations on encoding take.

I have found out a bit more already. It's definitely related to the caching system. I have it switched ON, even if it's very small cache, because if I don't, I get short freezes every 1-2 minutes. Obviously, this is MVP reading video not continuously from the SD card, but in bursts. And on the burst, the movie freezes.

Now, with the cache enabled, the bursts are 'delayed', but longer since it needs to fill the cache. The bigger I make the cache, the fewer freezes I get, but they last longer.

Either the Ipaq SD interface is too slow, or the SD card is too slow, or PocketMVP isn't doing a good job.

*edit* bakaneko... SDcard is fast enough, copying stuff on it via external card reader is lightning fast...

But the odd thing is, that some movies work right. I re-encoded that DIVX movie at 220kbit/sec, and at a bit higher audio quality (24KHz, because it came from an AC3 48KHz file). It has a much greater data throughput that the files I'm now making.

Question: how much CPU power does transporting data from the SD card to the cache take (even with cache disabled, PocketMVP must use some kind of caching in a minimal way)?

Another question: does higher compressed DIVX material take more CPU cycles to decompress?

I tried copying a rediced file (30MB) to the internal memory but although I made sure 45 MB is free, it keeps complaining there's not enough room...

At the moment I'm running an encode, same parameters, but with profiles disabled and using the "old" 2 pass system. Someone mentioned in another thread/forum, that the profiles would enable a few new things that could cause problems. Not sure if this is true, the problem things like B-frames and psychostuff can be disabled manually (and were disabled)

Anyway, I'll keep trying. Any tips much welcomed and if someone could have alook at those questions, much appreciated!

TIA!
Neko

[hollis_f]

Are you overclocking? I need to disable PocketHackMaster if I want decent playback from pMVP

[Buddha]

Either the Ipaq SD interface is too slow, or the SD card is too slow, or PocketMVP isn't doing a good job

It could be there's something wrong with the interface however this is unlikely as the other movie works ok. The same can be said for the SD card although everything points to that beeing the most likely bottleneck
being able to play that single-pass movie (with a higher bitrate) breaks that assumption aswell.

I assume from your post that you are pretty familiar with encoding but just in case: did you make sure that the audio was converted correctly in the movie from the SVCD file (I presume you have as otherwise you would have had a much BIGGER file... :wink: Should you want to check, Gspot is the tool for the job, it can be found on Doom9 (http://www.doom9.org) in the download section.

I tried copying a rediced file (30MB) to the internal memory but although I made sure 45 MB is free, it keeps complaining there's not enough room...

This is something that can happen if you tried to copy the file via ActiveSync. While there is no direct solution for this, a workaround that could work is:

copy the file to your SD with your card-reader, pop it in your ipaq and copy it from the SD to the internal memory.

Question: how much CPU power does transporting data from the SD card to the cache take (even with cache disabled, PocketMVP must use some kind of caching in a minimal way)?


I don't know but not enough that it should really bother you :)

Another question: does higher compressed DIVX material take more CPU cycles to decompress?

No, while divx takes more cpu to decompress, (than say mpeg) the higher the divx is compressed the smaller the bitrate gets. In simple terms: the higher the movie is compressed (the file gets smaller) the less data the CPU has to process per second.

While with eg ZIP, compression means it keeps the original file in its original state when decompressed, when compressing video, the higher the compression the more detail it throws out the door. This results in 'less image' when it is decompressed again during playback.


Another good point Hollis_f gave: be sure you kill all your apps when running PocketMVP.

Sorry I couldn't be of more help, when your friend is back borrow his SD and try playing the movie from his SD card in your ipaq.

[Pat Logsdon]

I'd recommend trying two things. First, I wouldn't use a profile at all. Second, I'd make sure that your rotate filter is ABOVE the resize filter. For some reason, that's caused stuttering for me in the past.

[KuroNeko]

Thanks a lot for all the tips guys!

I'll try switching the filters, although it didn't seem to be a bother for the divx re-encoded one before (as did resolution - had the same 136x320, though I will keep an eye on the divisible by 16 rule from now on)

As for other apps: none running. I don't overclock, nor have task managers and stuff running. I just use the PPC for reading books and playing music/movies. Occasional game, but since the hard reset I haven't installed any.

Buddha, I'm new to divx encoding, but I have a bit of video experience, mostly analog and more recently MPG2/DVD. The audio was re-encoded to mp3, or indeed I'd need a very big SD card. However, it did point to a possible other problem: the original divx re-encode that worked was re-encoded with Vdub, after demuxing the audio to AC3 stream with Vdubmod, then converted AC3 to wav. During encode I used the "wav audio" option of Vdub. Maybe there is a problem in Vdub when decoding MP2 audio and compressing to MP3, causing a muxing problem? I'll have to try this road too.

As for the copying of the file: that's how I did it (AS is way too slow) - copy to SD, insert SD and copy to memory. Didn't work. Something may be fishy in memory handling. Maybe I should give it another hard reset...

My friend will be back in a week. He's drying up in Italy right now (they even asked him to take water with him when he went there... must be really dry now). I'll have plenty of movies for him to try on his PPC :-)

One more thing. The divisble by 16 rule... it clashes with cropping. Cropping is good because it eliminates the useless black borders, saves bits in encoding. When you have to stay on resolutions divisible by 16, you either have to crop into the actual picture (not advisable, already few pixels in PPC format widescreen) or have a part of the black border taking into encoding. What you'd get is macroblocks that have one half (or part) black, one half actual picture. In MPG2 this encodes badly, often you get artefacts like faint horizontal lines at the top of the picture. How do you cope with this in Divx or is this not an issue in MPG4?

Neko

[Buddha]

Cropping is good because it eliminates the useless black borders, saves bits in encoding.
You're absolutely right 8) always get rid of those black borders.



When you have to stay on resolutions divisible by 16, you either have to crop into the actual picture (not advisable, already few pixels in PPC format widescreen) or have a part of the black border taking into encoding.

You're right once again, to archieve this you'll have to do another 'unethical' ( :wink: ) thing: first crop and then resize to a 'valid' res. If the aspect ratio is correct on the svcd you shouldn't notice too much real distortion when applying a little over-resize on it ( as the original one was 136 and to have it be divisible by sixteen you would have to use 128x320 or 144x320 which is a little bigger or a little smaller) then again if the movie gets too distorted by doing this you might just stick to the 136x320 res :mrgreen: one of the reasons for using the 16 rule is that 16x16 is the size of a macro block.

[KuroNeko]

Well, I actually wanted to do this, but hit a snag - which shows what a newbie I am at this :lol:

I could not find a filter that would crop! At first I was quite worried, until I found the cropping function in DIVX encoding settings :lol:

Which filter in Vdub can I use to crop? Or should I look for an additional (not included) filter, I think I saw some mention of this - some links - in the manual, I'll have to reread it (again, after some :sleeping: and some :morning: :lol:)

Thanks for your help!

Neko

[Buddha]

Just add a 'null transform' filter (its in the list) in Vdub, then select that filter in the filter window and click the 'cropping' button in the bottom right corner. :) now you can crop all you want. Then after doing this you can add a resize filter.

[Talyn]

You can also just highlight the resize filter (once it's been configured) and crop from there without adding the null filter.