2012-11-02, 15:14
2012-11-02, 19:35
What smearing color? I don't see smearing color...
2012-11-02, 20:11
2012-11-03, 07:33
needs to seek to key frame 
2012-11-03, 15:01
but how that on windows or ubuntu this not happend
2012-11-04, 09:55
It probably works a bit slower than on desktop/laptop hardware and you can see the seeking you normally don't.
2012-11-08, 10:50
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.
2012-11-17, 13:09
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
Have someone that manage to overclock the raspberry pi seen any improvments on this?
Regards Stefan
2012-11-17, 15:00
No, it's not processor power related.
You can stop the corrupt frames being displayed with (in advancedsettings.xml):
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.
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.
2012-12-04, 11:11
(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
2012-12-04, 13:51
[/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.
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.