smearing color on a few seconds
#1
hi, is thare a fix for raspberry when skipping video to get rid of smearing color for a few seconds
Reply
#2
What smearing color? I don't see smearing color...
Reply
#3
Image
Reply
#4
needs to seek to key frame Smile
Reply
#5
but how that on windows or ubuntu this not happend
Reply
#6
It probably works a bit slower than on desktop/laptop hardware and you can see the seeking you normally don't. Smile
Reply
#7
I get the same thing, Doktor-X. I figured it was to be expected as the RPi isn't exactly a powerhouse for processing. It looks like it's only redrawing areas of a scene that are changing.
Reply
#8
Not sure processing power is the answer to this. Apple tv 2 shows non of this and i assume it does not have the fastest cpu.
Have someone that manage to overclock the raspberry pi seen any improvments on this?
Regards Stefan
Reply
#9
No, it's not processor power related.
You can stop the corrupt frames being displayed with (in advancedsettings.xml):
Code:
<omx>
         <omxdecodestartwithvalidframe>1</omxdecodestartwithvalidframe>
</omx>

However, due to the way OpenMax is configured with the clock derived from the audio, you will have to wait for an I frame before video continues.
Typically these are every second or two, so that tends to work quite well.
However if I frames are only occasional, you will wait with no video for that time (the same time you currently see corrupted frames).

You can also try enabling "sync playback to display" which makes the clock come from audio which changes the behaviour, but is still not perfect.

How OpenMAX is meant to be configured is to make the clock start with the first video I frame, so you get no corruption and little delay.
It's something I will look into when I get the chance, but with any OpenMAX code, it's very tricky to get right.
Reply
#10
(2012-11-17, 15:00)popcornmix Wrote: No, it's not processor power related.
You can stop the corrupt frames being displayed with (in advancedsettings.xml):
Code:
<omx>
         <omxdecodestartwithvalidframe>1</omxdecodestartwithvalidframe>
</omx>

However, due to the way OpenMax is configured with the clock derived from the audio, you will have to wait for an I frame before video continues.
Typically these are every second or two, so that tends to work quite well.
However if I frames are only occasional, you will wait with no video for that time (the same time you currently see corrupted frames).

You can also try enabling "sync playback to display" which makes the clock come from audio which changes the behaviour, but is still not perfect.

How OpenMAX is meant to be configured is to make the clock start with the first video I frame, so you get no corruption and little delay.
It's something I will look into when I get the chance, but with any OpenMAX code, it's very tricky to get right.

popcornmix,
any chance you are able to have a go at fixing the OpenMAX code before the stable frodo is released?
Regards Stefan
Reply
#11
[/quote]
popcornmix,
any chance you are able to have a go at fixing the OpenMAX code before the stable frodo is released?
Regards Stefan
[/quote]
Unlikely. This is likely to be very difficult and could easily break some use cases.
Reply

Logout Mark Read Team Forum Stats Members Help
smearing color on a few seconds0