search

popcornmix / omxplayer

omxplayer
GNU General Public License v2.0
1.02k stars 332 forks source link

OMXPlayer randomly hangs #12

Closed cjsoftuk closed 10 years ago

cjsoftuk commented 11 years ago

Got a project that I can't disclose much info about, unfortunately, however..... We use omxplayer and Raspberry Pi as part of the project, and we play lots of videos, back-to-back (i.e. OMXPlayer quits, and our project starts a new one almost immediately).

However, from time to time (usually within an hour), OMXPlayer will hang. We do have a custom kernel we use, which I can post the .config for later today and I plan to swap back to stock kernel if the issue recurs again today (I'm currently in the middle of doing live demos to prospective customers). Other than the custom kernel, we're up to date as far as the bootloader goes and all other packages (inc OMXPlayer - 0.3.0 installed to try and fix this issue).

Usually, the hang will occur at the end of the video. OMXPlayer doesn't quit, doesn't print any messages to the log.

We're invoking omxplayer as follows: DISPLAY=:0 /usr/bin/omxplayer -o local --win "0 0 160 96" /content/file.mp4 </tmp/omxplayer

/tmp/omxplayer is a fifo that is created by my program.

Can anyone shed any light on the matter? Is there any more info you need?

Thanks for your help in advance.

Cheers,

Chris

cjsoftuk commented 11 years ago

Log file can be obtained from http://hosting.cmalton.me.uk/chrism/omxplayer.log.gz

popcornmix commented 11 years ago

Does sending q to stop work at this point?

Really I'll need a file that exhibits the problem.

cjsoftuk commented 11 years ago

Haven't tested that - will do so next time it hangs. I'll try and get authorisation to send you one of the files.

The script I use to do the conversion to x624 is as follows:

#! /bin/bash

FILEBASE=`echo $1 | sed -E -e 's/\.(.*)$//g'`

ffmpeg -i $1 -vcodec libx264 -s 1920x1080 -aspect '16:9' -vb 4M -acodec libmp3lame -ab 128k ${FILEBASE}-hd.mp4

All of the files are encoded using that. FFmpeg version is: ffmpeg version 1.0.6 Copyright (c) 2000-2013 the FFmpeg developers built on Mar 25 2013 16:06:49 with gcc 4.7 (Debian 4.7.2-5) configuration: --prefix=/usr --extra-cflags='-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security ' --extra-ldflags='-Wl,-z,relro' --cc='ccache cc' --enable-shared --enable-libmp3lame --enable-gpl --enable-nonfree --enable-libvorbis --enable-pthreads --enable-libfaac --enable-libxvid --enable-postproc --enable-x11grab --enable-libgsm --enable-libtheora --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libx264 --enable-libspeex --enable-nonfree --disable-stripping --enable-libvpx --enable-libschroedinger --disable-encoder=libschroedinger --enable-version3 --enable-libopenjpeg --enable-librtmp --enable-avfilter --enable-libfreetype --enable-libvo-aacenc --disable-decoder=amrnb --enable-libvo-amrwbenc --enable-libaacplus --libdir=/usr/lib/x86_64-linux-gnu --disable-vda --enable-libbluray --enable-libcdio --enable-gnutls --enable-frei0r --enable-openssl --enable-libass --enable-libopus --enable-fontconfig --enable-libdc1394 --enable-libfdk-aac --disable-altivec --dis libavutil 51. 73.101 / 51. 73.101

Like I say, this happens on one of N files (where N is any number!), and only started happening since early April (the version of OMXplayer we used at the last event in May worked fine!). The file is seemingly random, although there are a couple that cause the issue more often than others.

cjsoftuk commented 11 years ago

I've got clearance to send over one of the videos that tends to cause the problem. It's a whopping 11MB and we'd prefer not to send it completely in the clear. Could you ping me over an email address I can send the link to? Mine, should you need it is chrism (at) cmalton (dot) me (dot) uk.

cjsoftuk commented 11 years ago

I can confirm that sending a single q at this point will cause OMXplayer to stop and quit correctly, so this seems to not be a full hang per-say, more OMXplayer running off the end of the video and carrying on!

cjsoftuk commented 11 years ago

Looking at it, it seems https://github.com/huceke/omxplayer/issues/178 is possibly related.

cjsoftuk commented 11 years ago

Also: https://github.com/raspberrypi/firmware/issues/185

I'll try an out-of-band firmware update tomorrow.

cjsoftuk commented 11 years ago

Out-of-band (i.e. non-APT) firmware installed from raspberrypi's git repo. Does not fix this issue. Looking at other workarounds.

popcornmix commented 11 years ago

omxplayer -o local --win "0 0 160 96" dell/temp/test/problematic/Combat-hd.mp4 exits at end of file. What version of omxplayer are you using? What does: omxplayer --version report? You can download the latest version here: http://omxplayer.sconde.net/

cjsoftuk commented 11 years ago

Like I say, this isn't 100% reproducible - it occurs at some point after so many videos have run. I couldn't tell you how many times I have to run OMXPlayer (it seems to be ~45 mins to 1hr in, which is around 100 plays (based on average duration of the clips we are running)

Version is as follows:

omxplayer - Commandline multimedia player for the Raspberry Pi
        Build date: Thu, 27 Jun 2013 11:17:32 +0200
        Version   : b853c39 [master]
        Repository: https://github.com/popcornmix/omxplayer.git

I've currently got a workaround in place that has a 1 minute 40 second timeout, and if OMXPlayer hasn't quit by that point, it quits OMXPlayer and then the next video plays.

Does that help matters?

andyjagoe commented 11 years ago

I've been experiencing similar problems and I can reproduce it.

I have thousands of short h264 encoded (directly from iPhone with no transcoding) videos that are played in a loop one after another in xbmc. I noticed in recent Raspbmc and OpenELEC builds that the video stream would frequently hang which never used to happen in the past. There were no messages in xbmc.log that gave any indication of the fact this was happening or why--videos just stopped playing.

To debug, I built a video loop using omxplayer directly and cutting xbmc out of the picture, but encountered the same problem. What I've found is that on most videos omxplayer shuts down and returns to the console once it finishes playing, but on some videos omxplayer doesn't finish and just stalls...usually toward the end of the video with about one second to go. If you press 'q' omxplayer quits gracefully. Separate to the shell script, I see the same behavior in a version of pyomxplayer I've used---pyomxplayer never receives an EOF from omxplayer on certain videos.

I'm using an updated/upgraded 2013-05-25-wheezy-raspbian and the very recent 4fa7d64 build of omxplayer. Let me know if you'd like me to PM a copy of the video causing problems--a typical one is about 60 MB.

andyjagoe commented 11 years ago

top of the log file is below for command: omxplayer -o local -s - g IMG_2314.MOV

05:10:25 T:266791293   DEBUG: DllBcm: Using omx system library
05:10:25 T:266795830   DEBUG: DllOMX: Using omx system library
05:10:25 T:266798991   DEBUG: Previous line repeats 1 times.
05:10:25 T:266798991   DEBUG: DllAvFormat: Using libavformat system library
05:10:25 T:266799366   DEBUG: DllAvUtilBase: Using libavutil system library
05:10:25 T:266799556   DEBUG: DllAvCodec: Using libavcodec system library
05:10:25 T:266799709   DEBUG: DllAvFormat: Using libavformat system library
05:10:25 T:266980635   DEBUG: COMXCoreComponent::Initialize : OMX.broadcom.clock handle 0x59f0a0 dllopen : 1
05:10:25 T:266987235   DEBUG: COMXCoreComponent::Initialize OMX.broadcom.clock input port 80 output port 81
05:10:25 T:266988158   DEBUG: DllAvUtilBase: Using libavutil system library
05:10:25 T:266988430   DEBUG: DllAvCodec: Using libavcodec system library
05:10:25 T:266988640   DEBUG: DllAvFormat: Using libavformat system library
05:10:25 T:266988851   DEBUG: DllOMX: Using omx system library
05:10:25 T:266990565   DEBUG: Previous line repeats 9 times.
05:10:25 T:266990565   DEBUG: COMXCoreComponent::Initialize : OMX.broadcom.video_decode handle 0x586c00 dllopen : 1
05:10:25 T:266994139   DEBUG: COMXCoreComponent::Initialize OMX.broadcom.video_decode input port 130 output port 131
05:10:25 T:266995432   DEBUG: COMXCoreComponent::Initialize : OMX.broadcom.text_scheduler handle 0x5bc3e8 dllopen : 1
05:10:25 T:266999679   DEBUG: COMXCoreComponent::Initialize OMX.broadcom.text_scheduler input port 150 output port 151
05:10:25 T:267003879   DEBUG: COMXCoreComponent::AllocInputBuffers component(OMX.broadcom.video_decode) - port(130), nBufferCountMin(1), nBufferCountActual(60), nBufferSize(81920), nBufferAlignmen(16)
05:10:25 T:267036746   DEBUG: COMXCoreComponent::AllocInputBuffers component(OMX.broadcom.text_scheduler) - port(150), nBufferCountMin(1), nBufferCountActual(100), nBufferSize(1024), nBufferAlignmen(16)
05:10:25 T:267076069   DEBUG: COMXCoreComponent::AllocOutputBuffers component(OMX.broadcom.text_scheduler) - port(151), nBufferCountMin(1), nBufferCountActual(1), nBufferSize(1024) nBufferAlignmen(16)
05:10:25 T:267081660   DEBUG: COMXVideo::Open - decoder_component(0x0x586c00), input_port(0x82), output_port(0x83) deinterlace 0 hdmiclocksync 0
05:10:25 T:267087991   DEBUG: OMXThread::Create - Thread with id -1291193248 started
05:10:25 T:267088351   DEBUG: DllAvUtilBase: Using libavutil system library
05:10:25 T:267088539   DEBUG: DllAvCodec: Using libavcodec system library
05:10:25 T:267088695   DEBUG: DllAvFormat: Using libavformat system library
05:10:25 T:267090507   DEBUG: DllAvUtilBase: Using libavutil system library
05:10:25 T:267090662   DEBUG: DllAvCodec: Using libavcodec system library
05:10:25 T:267090783   DEBUG: DllAvFormat: Using libswresample system library
05:10:25 T:267098920   DEBUG: DllOMX: Using omx system library
05:10:25 T:267099371   DEBUG: Previous line repeats 5 times.
05:10:25 T:267099371   DEBUG: DllAvUtilBase: Using libavutil system library
05:10:25 T:267099577    INFO: CPCMRemap: I channel map: CE
05:10:25 T:267099710   DEBUG: CPCMRemap: Mapping mono audio to front left and front right
05:10:25 T:267099899   DEBUG: pcm->direction      : in
05:10:25 T:267100032   DEBUG: pcm->nPortIndex     : 0
05:10:25 T:267100152   DEBUG: pcm->eNumData       : 0
05:10:25 T:267100324   DEBUG: pcm->eEndian        : 1
05:10:25 T:267100450   DEBUG: pcm->bInterleaved   : 1
05:10:25 T:267100633   DEBUG: pcm->nBitPerSample  : 32
05:10:25 T:267100752   DEBUG: pcm->ePCMMode       : 0
05:10:25 T:267100865   DEBUG: pcm->nChannels      : 1
05:10:25 T:267100975   DEBUG: pcm->nSamplingRate  : 44100
05:10:25 T:267101092   DEBUG: OMX_AUDIO_ChannelCF
05:10:25 T:267101214   DEBUG: pcm->direction      : out
05:10:25 T:267101330   DEBUG: pcm->nPortIndex     : 0
05:10:25 T:267101445   DEBUG: pcm->eNumData       : 0
05:10:25 T:267101565   DEBUG: pcm->eEndian        : 1
05:10:25 T:267101682   DEBUG: pcm->bInterleaved   : 1
05:10:25 T:267101800   DEBUG: pcm->nBitPerSample  : 16
05:10:25 T:267101917   DEBUG: pcm->ePCMMode       : 0
05:10:25 T:267102037   DEBUG: pcm->nChannels      : 2
05:10:25 T:267102233   DEBUG: pcm->nSamplingRate  : 44100
05:10:25 T:267102360   DEBUG: OMX_AUDIO_ChannelLF
05:10:25 T:267102475   DEBUG: OMX_AUDIO_ChannelRF
05:10:25 T:267103954   DEBUG: COMXCoreComponent::Initialize : OMX.broadcom.audio_decode handle 0x58bf68 dllopen : 1
05:10:25 T:267107262   DEBUG: COMXCoreComponent::Initialize OMX.broadcom.audio_decode input port 120 output port 121
05:10:25 T:267111133   DEBUG: COMXCoreComponent::AllocInputBuffers component(OMX.broadcom.audio_decode) - port(120), nBufferCountMin(4), nBufferCountActual(4), nBufferSize(32768), nBufferAlignmen(16)
05:10:25 T:267128707   DEBUG: COMXAudio::Initialize Ouput bps 16 samplerate 44100 channels 2 device local buffer size 176400 bytes per second 88200 passthrough 0 hwdecode 0
05:10:25 T:267129446   DEBUG: COMXAudio::Initialize Input bps 32 samplerate 44100 channels 1 device local buffer size 176400 bytes per second 88200 passthrough 0 hwdecode 0
05:10:25 T:267135907   DEBUG: OMXThread::Create - Thread with id -1299581856 started
05:10:25 T:267136183   DEBUG: OMXClock::OMXStart(0)
05:10:25 T:267137051    INFO: OMXClock::OMXPause
05:10:25 T:267137272   DEBUG: OMXClock::OMXSetSpeed(0)
05:10:25 T:267145185   DEBUG: Normal M:1466 (A:-4503599627370496 V:-4503599627370496) P:1 A:0.00 V:0.00/T:0.20 (0,0,0,0) A:0% V:0% (0.00,2.00)
05:10:25 T:267145786    INFO: CDVDPlayerAudio::Decode dts:0 pts:0 size:4
05:10:25 T:267146571   DEBUG: COMXAudioCodecOMX::Decode(0x6503b8,4) format=8(8) chan=1 samples=1024 size=4096/4096,4096/4096,8192 data=0xeed7e0,(nil),(nil),(nil),(nil),(nil),(nil),(nil)
05:10:25 T:267146837   DEBUG: COMXAudioCodecOMX::GetData size=4096/0/4096 cont=1 buf=0xeed7e0
05:10:25 T:267148849   DEBUG: COMXCoreComponent::Initialize : OMX.broadcom.audio_mixer handle 0xda0e88 dllopen : 1
05:10:25 T:267154490   DEBUG: COMXCoreComponent::Initialize OMX.broadcom.audio_mixer input port 232 output port 231
05:10:25 T:267155468   DEBUG: Normal M:1466 (A:0 V:-4503599627370496) P:1 A:-0.00 V:0.00/T:0.20 (1,0,0,0) A:0% V:0% (0.37,2.00)
05:10:25 T:267156845   DEBUG: COMXCoreComponent::Initialize : OMX.broadcom.audio_render handle 0x5aff70 dllopen : 1
05:10:25 T:267157859   DEBUG: Normal M:1466 (A:0 V:-4503599627370496) P:1 A:-0.00 V:0.00/T:0.20 (1,0,0,0) A:0% V:0% (0.37,2.00)
05:10:25 T:267161094   DEBUG: Previous line repeats 1 times.
05:10:25 T:267161094   DEBUG: COMXCoreComponent::Initialize OMX.broadcom.audio_render input port 100 output port 100
05:10:25 T:267161720   DEBUG: Normal M:1466 (A:0 V:-4503599627370496) P:1 A:-0.00 V:0.00/T:0.20 (1,0,0,0) A:0% V:0% (0.37,2.00)
05:10:25 T:267198448   DEBUG: Previous line repeats 32 times.
05:10:25 T:267198448   DEBUG: Normal M:1466 (A:0 V:-4503599627370496) P:1 A:-0.00 V:0.00/T:0.20 (1,0,0,0) A:0% V:0% (0.00,2.00)
05:10:25 T:267204897   DEBUG: Previous line repeats 7 times.
05:10:25 T:267204897    INFO: CDVDPlayerVideo::Decode dts:0 pts:0 cur:0, size:254415
05:10:25 T:267205238   DEBUG: OMXVideo::Decode VDec : setStartTime 0.000000
05:10:25 T:267209546   DEBUG: Normal M:1466 (A:0 V:0) P:1 A:-0.00 V:-0.00/T:0.20 (1,1,0,0) A:0% V:0% (0.00,2.00)
05:10:25 T:267212403   DEBUG: Previous line repeats 1 times.
05:10:25 T:267212403    INFO: CDVDPlayerVideo::Decode dts:33333 pts:33333 cur:33333, size:62720
05:10:25 T:267214330   DEBUG: Normal M:1466 (A:0 V:33333) P:1 A:-0.00 V:0.03/T:0.20 (1,1,0,0) A:0% V:0% (0.00,2.00)
05:10:25 T:267216367   DEBUG: Previous line repeats 1 times.
05:10:25 T:267216367    INFO: CDVDPlayerVideo::Decode dts:66667 pts:66667 cur:66667, size:24413
05:10:25 T:267220868    INFO: CDVDPlayerAudio::Decode dts:23220 pts:23220 size:145
05:10:25 T:267222507    INFO: CDVDPlayerAudio::Decode dts:46440 pts:46440 size:203
05:10:25 T:267224346    INFO: CDVDPlayerAudio::Decode dts:69660 pts:69660 size:185
05:10:25 T:267226946   DEBUG: Normal M:1466 (A:69660 V:66667) P:1 A:0.07 V:0.07/T:0.20 (1,1,0,0) A:0% V:0% (0.00,2.00)
05:10:25 T:267228340   DEBUG: Previous line repeats 1 times.
05:10:25 T:267228340    INFO: CDVDPlayerAudio::Decode dts:92880 pts:92880 size:184
05:10:25 T:267230097   DEBUG: Normal M:1466 (A:92880 V:66667) P:1 A:0.09 V:0.07/T:0.20 (1,1,0,0) A:0% V:0% (0.37,2.00)
05:10:25 T:267230887    INFO: CDVDPlayerVideo::Decode dts:100000 pts:100000 cur:100000, size:66420
05:10:25 T:267233044   DEBUG: Normal M:1466 (A:92880 V:100000) P:1 A:0.09 V:0.10/T:0.20 (1,1,0,0) A:0% V:0% (0.37,2.00)
cjsoftuk commented 11 years ago

@andyjagoe: Thanks for confirming this isn't just me. I've had to bodge around it in my software - which is highly unpleasant. Look forward to hearing from @popcornmix when the problem has been identified. More than happy to try testing builds now - I have about a month and a half to get this under control for the project I'm working on now.

andyjagoe commented 11 years ago

@cjsoftuk: No problem. Are your freezes usually at the end of the video as well (all of mine seem to be) or do they occur at other times too? A possible workaround I'm considering until this is fixed is to run a separate timer in parallel (starting and stopping it with pause requests) and then sending a quit request to omxplayer if my counter detects a problem (e.g. our video should be finished but omxplayer hasn't issued EOF). Maybe this would work for you as well.

On Sun, Jul 7, 2013 at 11:19 PM, cjsoftuk notifications@github.com wrote:

@andyjagoe https://github.com/andyjagoe: Thanks for confirming this isn't just me. I've had to bodge around it in my software - which is highly unpleasant. Look forward to hearing from @popcornmixhttps://github.com/popcornmixwhen the problem has been identified. More than happy to try testing builds now - I have about a month and a half to get this under control for the project I'm working on now.

— Reply to this email directly or view it on GitHubhttps://github.com/popcornmix/omxplayer/issues/12#issuecomment-20587431 .

cjsoftuk commented 11 years ago

@andyjagoe: Yes, all my freezes that I've noticed were at the end as well. I'm already using the workaround you described - quite effective, but very irritating!

On 08/07/13 08:45, andyjagoe wrote:

@cjsoftuk: No problem. Are your freezes usually at the end of the video as well (all of mine seem to be) or do they occur at other times too? A possible workaround I'm considering until this is fixed is to run a separate timer in parallel (starting and stopping it with pause requests) and then sending a quit request to omxplayer if my counter detects a problem (e.g. our video should be finished but omxplayer hasn't issued EOF). Maybe this would work for you as well.

On Sun, Jul 7, 2013 at 11:19 PM, cjsoftuk notifications@github.com wrote:

@andyjagoe https://github.com/andyjagoe: Thanks for confirming this isn't just me. I've had to bodge around it in my software - which is highly unpleasant. Look forward to hearing from @popcornmixhttps://github.com/popcornmixwhen the problem has been identified. More than happy to try testing builds now - I have about a month and a half to get this under control for the project I'm working on now.

— Reply to this email directly or view it on GitHubhttps://github.com/popcornmix/omxplayer/issues/12#issuecomment-20587431 .

— Reply to this email directly or view it on GitHub https://github.com/popcornmix/omxplayer/issues/12#issuecomment-20590029.

popcornmix commented 11 years ago

@andyjagoe Do you have a file that hangs every time at end of file? A link would be useful (popcornmix at gmail dot com)

andyjagoe commented 11 years ago

@popcornmix Yes...just uploaded and shared via Google Drive. The link is https://docs.google.com/file/d/0B37YAa2drcMuMldYOFdrRUpTd28/edit?usp=sharing

It is shared to your gmail account. Let me know if you have any problems accessing it.

popcornmix commented 11 years ago

@andyjagoe Got the file, and I can see the hang.

popcornmix commented 11 years ago

I've committed a fix that fixes @andyjagoe's file.

andyjagoe commented 11 years ago

Thanks @popcornmix. Hugely appreciate the quick response. I'm traveling but will be able to try it out in a day or so.

andyjagoe commented 11 years ago

@popcornmix

Fix is working great and I'm seeing no further problems. Thanks for the quick response. I'm ok to close this issue, but I'll leave that to you or to @cjsoftuk since he hasn't commented yet and he opened it.

cjsoftuk commented 11 years ago

Cheers for the quick fix @popcornmix - I'll try and test it out as soon as I can. I see that the sconde.net builds are now up to date with this fix patched in, so I'll be trying it out by leaving a Pi running tomorrow when I go out to work.

cjsoftuk commented 11 years ago

OK, I've left it running, and all seems good at the moment, I'll let you know when I get back from work if it's still getting stuck.

cjsoftuk commented 11 years ago

@popcornmix This doesn't seem to have fixed my issue unfortunately! I was just about to go out to work and I've noticed it's got stuck (And this time it was the first time it played that video I sent you).

omxplayer - Commandline multimedia player for the Raspberry Pi
        Build date: Tue, 09 Jul 2013 06:05:28 +0200
        Version   : 2b110d9 [master]
        Repository: https://github.com/popcornmix/omxplayer.git
cjsoftuk commented 11 years ago

OK, this is a curious one. I've set off a test run calling just "omxplayer -g /content/Combat-hd.mp4" and we're at iteration 30 without any issue so far. I'll try and pin this down further.

cjsoftuk commented 11 years ago

Yep - seems to be with the way I'm calling omxplayer now (i.e. omxplayer and SDL interacting badly!) - I'd like to keep this open for the moment @popcornmix until such point as I can pin down what's actually responsible (SDL or OMXplayer or python)

Last night we got to 300+ iterations of the same video without faolure.

popcornmix commented 11 years ago

Okay. Let us know when you have more info.

andyjagoe commented 11 years ago

@cjsoftuk did you get any more info on this? I just experienced this issue again with another file and (unfortunately) cannot repeat it. The hang was very curious in that it was clearly the end of the video, but omxplayer was continuing to stream stats (I used the '-s' option) and increment the M: value.

@popcornmix ...any thoughts on how we might best to trap this issue? Not sure if my omxplayer.log was of any value for the last file you helped with.

andyjagoe commented 11 years ago

Also...is it possible to specify a path / filename for the '-g' option? I'm running my loop now so next time it hangs I'll have the omxplayer log file.

popcornmix commented 11 years ago

@andyjagoe The log may be illuminating. The first one was. Instructions to reproduce the issue (ideally quickly) are even better.

No way to change the destination directory of log file other than changing current directory. e.g. cd /home/pi/log && omxplayer file.mkv

andyjagoe commented 11 years ago

Thanks @popcornmix

I've uploaded both the video that hung and the omxplayer log file to Google Drive and shared them with you. The video is only 15 seconds long. I put it in an infinite loop by itself and it hung after 16 plays.

I'm wondering if the issue now is with older video files? For example, the new files taken from an iPhone 4S in MPEG-4 that caused problems before your last fix I've been looping for days with thousands of plays.

I'm using a Python subprocess running in a separate thread to play the file (code below). The Clock.schedule_once callback is how I kick off the next action, and it doesn't get called unless the omxplayer operation completes. This is equivalent to calling omxplayer -s -g -o hdmi filename.

    def play_video(self, path):
        Logger.info('Playing video: ' + path)

        #set up our subprocess
        p = subprocess.Popen( ['omxplayer', 
                       '-s',
                       '-g',
                       '-o',
                       'hdmi', 
                       path
                       ], 
                      stdin = subprocess.PIPE, 
                      stdout = subprocess.PIPE, 
                      close_fds = True) 

        #run it and get results
        stdout_text, stderr_text = p.communicate()

        #schedule our next image for asap once our video ends
        Clock.schedule_once(self.next_image_callback)

        #get and print data for debugging
        data = stdout_text.rstrip()
        Logger.debug(data)

I've modified the code so you can quickly paste it into a file called test.py (or anything you like), modify the path to the video file, and put omxplayer into an infinite loop on the file by calling 'python test.py':

import subprocess

global count
count = 0

def play_video(path):
    global count
    print 'Playing video: ' + path

    #set up our subprocess
    p = subprocess.Popen( ['omxplayer',
                   '-s',
                   '-g',
                   '-o',
                   'hdmi',
                   path
                   ],
                  stdin = subprocess.PIPE,
                  stdout = subprocess.PIPE,
                  close_fds = True)

    #run it and get results
    stdout_text, stderr_text = p.communicate()

    #get and print data for debugging
    data = stdout_text.rstrip()
    print data

    #put our video player into an infinite loop
    count = count + 1
    print 'video play count: ' + str(count)
    play_video(path)

play_video('/path/to/video/file')

Notice that the first omxplayer log file is 287 MB because omxplayer ran all night never finishing until I killed it. I'm wondering if until I get this fixed I need to run a separate timer and kill the process if it runs for longer than the video file length (+/- any pauses in playback)?

Video File in Question (6MB) shared via Google Drive: https://docs.google.com/file/d/0B37YAa2drcMudzR4dG1DUXhLdlU/edit?usp=sharing

First omxplayer.log file (287MB) when it had been running all night (shared via Google Drive) https://docs.google.com/file/d/0B37YAa2drcMuZTBvUUpsdDJydjA/edit?usp=sharing

Second omxplayer.log file (3MB) when I put it in a dedicated loop to try to force a crash (shared via Google Drive) https://docs.google.com/file/d/0B37YAa2drcMuQnRxYWg1NmJrYWs/edit?usp=sharing

andyjagoe commented 11 years ago

Ok, so I've noticed that the files that tend to hang print the following warning message to the console: Invalid framerate 120, using forced 25fps and just trust timestamps. They're all MPEG-4 h264 encoded, but these files have been transcoded from older videos.

I've run the standalone loop again with the problem file and omxplayer hangs after 7 plays. I tried IMG_2314.MOV, the file you fixed last time, and it has done 100+ plays in the same code block and is still going with what seems to be no issues.

I've also noticed that in the stats, V: appears to go negative for more than 1 second on the problem file whereas on IMG_2314.MOV it is closer to 0.5s. Not sure if this matters at all.

cjsoftuk commented 11 years ago

I haven't had as much time as I'd like to look into this properly yet, however it looks like @andyjagoe has hit this again.

I'm currently attempting to reproduce this issue with one of the problem videos my end using @andyjagoe 's script. I'll let you know when it does so, the console log, the debug log, and the number of plays after which it happens.

andyjagoe commented 11 years ago

Thanks @cjsoftuk

cjsoftuk commented 11 years ago

I've just had one of those "OOHHHHH!" moments. Normally, when my program is in operation, it's looping through multiple videos. There's not enough RAM on the Pi to cache them all - so it's having to go to disk every time. When I run OMXPlayer in a tight loop with the same video, it's managed to cache it all in RAM, so there's no major disk IO, as indicated by the lack of a wildly flashing OK light.

While I know the USB on a RasPi isn't the most stable thing in the world, I am going to see if running my /content disk off a USB key, or external HDD makes a difference. Or even, over an NFS or CIFS share!?

andyjagoe commented 11 years ago

I'm running off a 64GB USB flash drive and I've found it to be better. Not sure about HDD, NFS or CIFS.

popcornmix commented 11 years ago

Is this still an issue?

andyjagoe commented 11 years ago

I believe so, but I haven't been watching for it explicitly anymore. I've added a workaround wrapper that runs a separate timer and kills omxplayer if it's runtime exceeds the duration of the video. I need to address this properly though...since this workaround makes it difficult to pause, rewind or fast-forward.

Separately, I've run into what might be a memory leak problem in one of the most recent omxplayer builds. I haven't posted an issue yet because I haven't debugged sufficiently to make an informed report. My app that ran for weeks on end with no problem in a previous build, now consistently complains about an out of memory issue and dies after 12-24 hours of running. Nothing other than omxplayer version has changed between the two results. I need to see if the issue is related to my version of Raspbian, but I've run apt-get update and apt-get upgrade.

Can you confirm which version of Raspbian you're testing builds prior to release?

popcornmix commented 11 years ago

I'm running an old raspbian image, but with a recent apt-get upgrade, so it should be pretty much the same as latest sdcard image.

andyjagoe commented 11 years ago

Ok. I'm doing the same. Let me try a simple shell script 1) looping omxplayer continuously over a single file, and 2) looping omxplayer continuously over a few thousand different files to see if I can isolate. It's possible the issue I'm having is something external to omxplayer.

johnspackman commented 10 years ago

We've just started hitting this problem; I upgraded our distribution this week to the latest 2014-01-07 Raspbian, then did apt-get update, and apt-get upgrade and rpi-update and downloaded the latest omxplayer version efb9fe5 (Build date: Wed, 15 Jan 2014 22:06:50 +0100) from the website.

Since then, omxplayer will stop playing in exactly the manner described above - IE the log will show that it's playing, wit a black screen, well beyond the duration of the movie.

There doesn't seem to be much of a pattern as to which movie it will stop on, or how many plays it will take before it hangs - sometimes approx 10 play OK, sometimes 30 or 40. I have noticed that if I use --genlog then it is much less likely to hang, EG with --genlog I can sometimes get up to nearly an hour before it hangs.

Most times it seems to hang at the end, but sometimes (although rarely) it will hang at the beginning, too. The only solution I've found is to use ffprobe to get the video duration and implement a watchdog to kill USR1 the process.

Our movies are all approx 30 seconds long and encoded in h264 by: ffmpeg -i "$i" -vcodec libx264 -profile:v baseline -preset fast -pix_fmt yuv420p -threads 0 -an

(ffmpeg version N-54897-g7dc7761 and x264 0.135.2345 f0c1c53, both were built from current git as at Jul 23 2013 14:39:29)

Our old player that worked fine was 2013-09-25 Raspbian but the omxplayer does not support -version, it's dated 27th April 2013.

I have an omxplayer log file I can send if that's helpful, and I've just started collecting stats on how often and which videos cause the problem; let me know if you want any of it, my email is john.spackman at zenesis dot com

johnspackman commented 10 years ago

I've been running three players since Friday night and tracking stats on the number of failures; I have 4,796 playbacks, of which 131 overran by more than 5 seconds and had to be killed by the watchdog - IE just under 3%. This appears to be consistent, the past 18 hours have had 51/1770 failures.

I get the same error in the omxplayer.log as @jehutting found in issue #124 - 

09:00:01 T:18446744072709605712   DEBUG: Resume 0.00,0.23 (0,0,1,1) EOF:0 PKT:(nil)
09:00:01 T:18446744072709608454   ERROR: COMXCoreComponent::SetStateForComponent - OMX.broadcom.clock failed with omx_err(0x80001000)
09:00:01 T:18446744072709614460   ERROR: OMXClock::StateExecute m_omx_clock.SetStateForComponent
09:00:01 T:18446744072709614814   DEBUG: OMXClock::OMXSetSpeed(1.00) pause_resume:1
XionTech commented 10 years ago

This issue has driven me mad for two weeks. At first I thought it was because I was running a background mpd service to play mp3's while the videos looped in omxplayer. Then I saw that omxplayer.bin was still processing, just with a blank screen as mentioned above... I had tried every known solution to 'blank at the end of a video' but none seem to affect this particular issue at all. Pressing q at the console or killing the omxplayer.bin would bring it back and it was good to go for another 1 - 4 hours. This is running only 1 or 2 videos, looping, and it is completely random.

Tried various video formats to no avail. But is anyone else using other processes at the same time that could be causing the hiccup as the video is finishing? I thought just maybe my mpd service was starting a new song right when a video was ending and hitting a conflict.

Are there any flags I haven't seen for running a video without processing for sound? I want the omxplayer muted since my background plays the music...

I don't suppose anyone wants to share their watchdog script until this issue is pinpointed?

KenT2 commented 10 years ago

seems to be an omxplayer problem rather than interaction with other applications

see #124 and others for discussion see #124 and #59 for watchdog (just timeouts) see #59 for how to kill omxplayer when q does not work for volume just use the --vol option

amaaov commented 10 years ago

Same problem here. Made custom loop sctipt on Ruby, script forks and runs omxplayer (evenmore with root priv.), but it does hang after random number of cycles. Term signal kills current omxplayer.bin instance and next omxplayer starts playing just fine.

I thought that omxplayer can't allocate needed memory and it just hangs, but no messages about it.

Well, I used omxd for playlisting and omxplayer didn't hang.

tengil commented 10 years ago

I too just upgraded raspbian a couple of days ago and started getting this problem. Prior to that we had an rpi playing a video loop for over a year non-stop. Now it hangs after an hour or so. Guess I'm rolling back until this is fixed.

jehutting commented 10 years ago

Hi @aawray I read that you are using omxd. I'm looking at issue #131 (and also @subogero omxd repository issue 14). Are you using omxd with POPCORNMIX omxplayer or are you using an older (HUCEKE) omxplayer release? HUCEKE omxplayer doesn't have the --version option. POPCORNMIX omxplayer does. Or are you using a Raspbian released omxplayer? Don't know how to find out which repository is used to build the omxplayer for a DEB(ian) build package (?)/Raspbian release!? @engil I assume you are also referring to an older release of HUCEKE omxplayer?

amaaov commented 10 years ago

@jehutting I was using raspbian released omxplayer.

jehutting commented 10 years ago

@aawray Thanks. Now I need to find out to which repository it belongs ;)

amaaov commented 10 years ago

@jehutting got it: omxplayer | 0.3.3~git20131216~b34143c | http://archive.raspberrypi.org/debian/ wheezy/main armhf Packages