Raspberry pi 3 video restart error

[adamkalicinscy]

Hi

I am running this player on Raspberry pi 3 wist latest Jessie and it plays 20 seconds from 30 second video and then restart with this error. Video file is ok because system omxplayer plays it properly.

I have video memory set to 192

[ error ] Component::~Component(): 80 OMX_ErrorBadParameter
[ error ] OMX_ERRORTYPE Component::waitForCommand(OMX_COMMANDTYPE, OMX_U32, long int): OMX.broadcom.audio_render TIMEOUT
OMX_EventCmdComplete
OMX_CommandStateSet
2

[ error ] OMX_ERRORTYPE Component::setState(OMX_STATETYPE): 864
[notice ] bool ofxOMXPlayerEngine::didReadFile(bool): didOpenMovie TOOK 7 MS
[notice ] bool ofxOMXPlayerEngine::openPlayer(int): duration SET: 29.6
[notice ] bool ofxOMXPlayerEngine::openPlayer(int): Opened video PASS
[ error ] OMX_ERRORTYPE Component::waitForEvent(OMX_EVENTTYPE, long int): OMX.broadcom.audio_render waitForEvent Event: OMX_EventPortSettingsChanged TIMED OUT at: 20
[ error ] Component::~Component(): 80 OMX_ErrorBadParameter
[ error ] OMX_ERRORTYPE Component::waitForCommand(OMX_COMMANDTYPE, OMX_U32, long int): OMX.broadcom.audio_render TIMEOUT
OMX_EventCmdComplete
OMX_CommandStateSet
2

[vberthiaume]

i have the exact same error, with my RPI 3 and my RPIs 2

[vberthiaume]

Turns out the problem is with your icebreak() in omPlayer.cpp. Comment line 172:

this->iceBreak(); 

and videos run to their end rather than stopping in the middle. I realize this is a fix for jvcleave/ofxOMXPlayer#62, but I guess this is not working for me. With this line uncommented, most of my videos stop about 3/4th of the time around their halfpoint.

[Maigre]

Hi,
jvcleave did a lot of work since last HPlayer release and i did not have
time to update the code accordingly.
the iceBreak function was there as a safeguard to unlock bad situations,
but it might not be effective any more.
I'll check that out and post an update soon.

Best,

2016-08-17 20:06 GMT+02:00 Vincent Berthiaume [email protected]:

Turns out the problem is with your icebreak() in omPlayer.cpp. Comment
line 172:

this->iceBreak();

and videos run to their end rather than stopping in the middle. I realize
this is a fix for jvcleave/ofxOMXPlayer#62
jvcleave/ofxOMXPlayer#62, but I guess this is
not working at all for me. With this thing on, most of my videos stop about
3/4th of the time around their halfpoint.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#34 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAq2wWY3lvIZi26MzKymY3zQdwisilp-ks5qg02UgaJpZM4JR_U3
.

http://www.hemisphere-project.com/

[vberthiaume]

Hi!

Yes, it does seems to be the case that some of the work jvcleave did
interfered with the way HPlayer works. Thanks!

Cheers

On Mon, Sep 12, 2016 at 1:01 PM, Maigre [email protected] wrote:

Hi,
jvcleave did a lot of work since last HPlayer release and i did not have
time to update the code accordingly.
the iceBreak function was there as a safeguard to unlock bad situations,
but it might not be effective any more.
I'll check that out and post an update soon.

Best,

2016-08-17 20:06 GMT+02:00 Vincent Berthiaume [email protected]:

Turns out the problem is with your icebreak() in omPlayer.cpp. Comment
line 172:

this->iceBreak();

and videos run to their end rather than stopping in the middle. I realize
this is a fix for jvcleave/ofxOMXPlayer#62
jvcleave/ofxOMXPlayer#62, but I guess this
is
not working at all for me. With this thing on, most of my videos stop
about
3/4th of the time around their halfpoint.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#34 (comment)
240496666>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
AAq2wWY3lvIZi26MzKymY3zQdwisilp-ks5qg02UgaJpZM4JR_U3>
.

http://www.hemisphere-project.com/

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#34 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADjIMcq8z13gzobIHisLWB8JelCdSzDwks5qpYVzgaJpZM4JR_U3
.

[Maigre]

Hi,
it seems the default not textured mode is broken.
Please try to use
--gl 1
arguments to see if it helps.
Also i think the player is picky with media encoding.
Try to reencode your media with x264 high / aac

You can also send me a video of yours where the problem occurs so it could help debugging.

I will release an update to remove the non-textured mode and check all the updates brought by jvcleave.

Best,

[vberthiaume]

awesome i'll try that asap. In the meantime, here's one of my videos:

https://www.dropbox.com/s/v4jw48ov9y0as1d/video1.mp4?dl=0

It's currently uploading, should be there in like 10 min.

On Tue, Sep 13, 2016 at 10:32 AM, Maigre [email protected] wrote:

Hi,
it seems the default not textured mode is broken.
Please try to use
--gl 1
arguments to see if it helps.
Also i think the player is picky with media encoding.
Try to reencode your media with x264 high / aac

You can also send me a video of yours where the problem occurs so it could
help debugging.

I will release an update to remove the non-textured mode and check all the
updates brought by jvcleave.

Best,

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#34 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADjIMXOtHfO9lkNGVRT-Riy4UTB0I3GLks5qprQOgaJpZM4JR_U3
.

[vberthiaume]

the --gl 1 option makes the video play through (30sec) as opposed to
stopping around half-way (15sec), but the framerate (or something) is
super, super slow...

On Tue, Sep 13, 2016 at 10:59 AM, Vincent Berthiaume [email protected]
wrote:

awesome i'll try that asap. In the meantime, here's one of my videos:

https://www.dropbox.com/s/v4jw48ov9y0as1d/video1.mp4?dl=0

It's currently uploading, should be there in like 10 min.

On Tue, Sep 13, 2016 at 10:32 AM, Maigre [email protected] wrote:

Hi,
it seems the default not textured mode is broken.
Please try to use
--gl 1
arguments to see if it helps.
Also i think the player is picky with media encoding.
Try to reencode your media with x264 high / aac

You can also send me a video of yours where the problem occurs so it
could help debugging.

I will release an update to remove the non-textured mode and check all
the updates brought by jvcleave.

Best,

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#34 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADjIMXOtHfO9lkNGVRT-Riy4UTB0I3GLks5qprQOgaJpZM4JR_U3
.

[Maigre]

Ok,

• what kind of slow FPS do you have ? (you can display FPS with --info 1 argument)
• what version of RPi are you using ?
• did you set memory split to at least 128mb (or 256mb if Rpi>=2) ?
• do you run other processes in the same time ?
• can you check cpu usage with htop while video is playing ?

I'll check with your video to see if i get the same problem.
Again, a reencoding might fix the issue, omxplayer is picky..

[vberthiaume]

Hey,

• FPS: around 9-10
• RPi: version 3
• memory split at 512 (tried 256, doesn't change anything)
• no other process
• here's what top (through ssh) looks like while HPlayer is running:

On Tue, Sep 13, 2016 at 11:16 AM, Maigre [email protected] wrote:

Ok,

• what kind of slow FPS do you have ? (you can display FPS with --info
  1 argument)
• what version of RPi are you using ?
• did you set memory split to at least 128mb (or 256mb if Rpi>=2) ?
• do you run other processes in the same time ?
• can you check cpu usage with htop while video is playing ?

I'll check with your video to see if i get the same problem.
Again, a reencoding might fix the issue, omxplayer is picky..

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#34 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADjIMauB2ZFGku4TqibXwZQI3cgRfYSvks5qpr4ygaJpZM4JR_U3
.

[Maigre]

I am not sure why the FPS drop like that, since the CPU seems not overloaded.

So there is 2 problem here:

• non textured mode is ok except that iceBreak is broken and kill the video too early
• textured mode has low FPS in FullHD with no apparent CPU overload

I'll try to see if i can solve the first problem quickly,
and try to understand the roots of the second issue

[vberthiaume]

yes, that summarizes the issues very well! Thank you so much!

On Fri, Sep 16, 2016 at 6:30 AM, Maigre [email protected] wrote:

I am not sure why the FPS drop like that.
So there is 2 problem here:

• non textured mode is fat but iceBreak is broken and kill the video
  too early
• textured mode has low FPS in FullHD

I'll try to see if i can solve the first problem quickly,
and try to understand the roots of the second issue

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#34 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADjIMYRgj1vUdAxcn_8zmfCzuHgJE2T_ks5qqm_agaJpZM4JR_U3
.

[LoicLac]

Just to share my experience here,
I had the same issue .
I solved it when i take a great care of my h264 video encoding .
It seems that a constant bitrate and a big attention on quality is important here.
Ffmpeg on mac worked better for me than everything else because i could limit the bitrate and make it constant . Use aac too .