Update video.c

[nagualcode]

Remove the timout, to avoid the application quits before the ending of some videos.
(Application used to hang before last commit, now it quits, either, the only way to watch some video files till the end is to remove timeout completely like I am suggesting now, or to incrase it, but I dont now what should be better pratice.

[popcornmix]

Can you provide a sample file that fails without this change?
How high does timeout need to be to fix the issue?
I'd be happier with a larger timeout than infinite.

[nagualcode]

Hello PopcornmIX.
This is the file the problematic file for me:
https://www.dropbox.com/s/xlyaflmmij4unms/2menu.h264?dl=0

Old video.c used to hang forever with this video.
This recent commit just quits (at the exact frame it used to hang)
I have been working with a local forked version, with timeout set at 90000, without problems with many videos...
Today I had found an old thread were I was talking about this same problem, where an user suggest the -1 timeout.

So I wonder if -1 may be better choice for very long videos... I have tested videos up to 5 minutes so far...

https://www.raspberrypi.org/forums/viewtopic.php?f=38&t=79868&p=819730#p819730

Ps. Many people suggest to just use omxplayer. But Hello_video seamless transitions between a list of files is essential for a video art presentation.

Thank you!

[popcornmix]

That timeout shouldn't be related to the duration of the video, only the amount of data queued by openmax. I think there is around 1M-2M buffered in codein (for cabac/cavlc), plus the openmax buffers (20 x 80K = 1.6M I think).
So it's the longest time it takes to decode and return ~3M of video data. I expect the codec can process around 10MB/s, so something like 300ms seems like plenty.

So, with a bit of margin for error, try with 500000. If that works for all your files, then adjust the PR and I'll be okay to accept it. Even if something goes wrong and we don't get the EOS signal, then rather than hanging forever (which the -1 will do), it will just hang for half a second.

[popcornmix]

EDIT: ignore previous comment.
The timeout was in milliseconds rather than microseconds, so was already ten seconds. It is surprising that so much data can be buffered up, but @deborah-c has confirmed that with high resolution and very low bitrate that the amount of data buffered can take many seconds to play out.

So leave it as -1 for now. We'll deal with the issue if and when it occurs if we get videos hanging because of this.
We've talked about adding an option to video_decode component to try to limit the amount of data buffered to a sensible amount (e.g. one second), although that can be difficult to predict when the data isn't framed with timestamps.

[popcornmix]

This has now been merged.