Movie Player Buffer problem?

[ozbodd]

I am converting YouTube videos to play as TS files on the DBox. Works well but the problem is the video stream being cut short by 10-15 seconds. Because it is a matter of seconds it is obvious with music clips that end fairly abruptly anyway. I suspect it would be difficult to it pick up on recordings and movies.

It has been confirmed on two different images.

I have uploaded an example file for you to test - Don't mind the choice! I have shortened it to 7MB and the end is intact and will fade to black when played on the PC but not on the Dbox.
http://www.ictjuices.com/assets/sherbet.ts

Also could the Movie player have a random shuffle mode?

And can the TS Moviebrowser cache the files to the share to prevent enumerating all files on every boot?

English only please hope I am in the right place.

[Tommy]

The issue is known. On the end of a movie the buffer will wasted not played. The time u'll left is as high as the buffersize is setted up. If you have the buffer set to 0 or have disabled the buffer named "Waberqueue" this issue don't occur. I already had escalated this but gmo18t (who had implemented this buffer) seems to be not an active developer last time - unfortunately

[ozbodd]

The issue is known. On the end of a movie the buffer will wasted not played. The time u'll left is as high as the buffersize is setted up. If you have the buffer set to 0 or have disabled the buffer named "Waberqueue" this issue don't occur. I already had escalated this but gmo18t (who had implemented this buffer) seems to be not an active developer last time - unfortunately

OK thanks - I found "Use buffer (WabberQueue) = Yes" changed to No with no effect; the clip is still cutting short. Where else can I change the buffer size to change?

I am getting excited that I may be able to use the dbox as a video jukebox if the movie player had shuffle. I wondered if the Audo player shuffle coding could be used?

BTW I am not an experienced coder

[ozbodd]

I made a 25 second black and silent TS file using Audacity/GiMP and Jahshaka to save as avi and then use VLC to transcode to TS !!!! Thank goodness that only requires doing once (See below for the file)

I then used TSSplitter(and joiner) http://www.ffprojects.net/tssplitter/
to join the converted YouTube video clip to the black silent clip.

In the settings for Movie Player I changed the Buffer Segments form 24 to 15 and that has solved the problem. Perhaps you could just extend the silent clip if you do not want to change the buffer size.

This adds about 1MB to your clip.

I have uploaded the blank TS file on MediaFire http://www.mediafire.com/?dwwmgyrh2iw

Here is a 35 second version that works nicely with the Buffer Segments left at 24 http://www.mediafire.com/?0xwgc8w2ndj

This is still just a fix, it would be great if someone could get to the bottom of the buffer issue.

Now all I want is a shuffle mode for the Movie Player...

[Tommy]

I think to fix this in source of Moviplayer would be a better choice

[ozbodd]

I think to fix this in source of Moviplayer would be a better choice

LOL I agree

[ozbodd]

Can anyone point me to where I can see the code for the Audioplayer Shuffle or is it only available in the cvs (Kiddie scripter here

I've copied all the root code and tried text searches but can only find references in the locale and y-web files.

Is it feasible to use this code for the Movie Player? I will have a go myself if I can be pointed In the right direction.

Cheers

[seife]

Code: Alles auswählen

seife@susi:/local/seife/src/tuxbox-newmake-26> grep "CAudioPlayerGui::shuffelPlaylist" -r apps/tuxbox/neutrino/src/gui/
apps/tuxbox/neutrino/src/gui/audioplayer.cpp:bool CAudioPlayerGui::shuffelPlaylist(void)

[ozbodd]

Right so it is Audioplayer.cpp that is the script - Will have a poke around in the cvs to see if I can make any sense of it . Thanks

[ozbodd]

I find the movie is ending at the WabberQueue value (buffer_time I think) + 3 seconds early. Below is the suspicious code

Code: Alles auswählen

				if(g_playstate == CMoviePlayerGui::PLAY)
				{
					nothingreceived++;
					if(nothingreceived > (buffer_time + 3)*100) // wait at least buffer time secs +3 to play buffer when stream ends
					{
						printf ("[movieplayer.cpp] ReceiveStreamthread: Didn't receive for a while. Stopping.\n");
						g_playstate = CMoviePlayerGui::STOPPED;
					}
					usleep(10000);	//sleep 10 ms
				}

nothingrecevied is counting in 10ms intervals.

For example a video I have the WabberQueue set to 10 and am finding the clip ends 13 seconds from the end which appears to be when nothingreceived > 1300


Would the fix be to simply double the buffer_time for example

Code: Alles auswählen

				if(g_playstate == CMoviePlayerGui::PLAY)
				{
					nothingreceived++;
					if(nothingreceived > ((buffer_time*2) + 3)*100) // wait at least 2 x buffer time secs +3 to play buffer when stream ends
					{
						printf ("[movieplayer.cpp] ReceiveStreamthread: Didn't receive for a while. Stopping.\n");
						g_playstate = CMoviePlayerGui::STOPPED;
					}
					usleep(10000);	//sleep 10 ms
				}

I could well be way off track here ....

Would/could someone possibly test this theory?

[seife]

You are off track. Or do you see the "[movieplayer.cpp] ReceiveStreamthread: Didn't receive for a while. Stopping.\n" message on the console when the clip ends? I don't.
I just see:

Code: Alles auswählen

[mp] ... reader thread terminated
[mp] leaving player loop ...
[mp] ... checking for another playlist item
[mp] mp_playFileThread terminated
[frontend] uncommitted_switch_mode 0

So IMHO you need to defer the "leaving player loop" until the buffer is empty.

[seife]

I think i found a fix, but i'm not sure about side effects.
Works quite well for me, though:

Code: Alles auswählen

Index: movieplayer.cpp
===================================================================
RCS file: /cvs/tuxbox/apps/tuxbox/neutrino/src/gui/movieplayer.cpp,v
retrieving revision 1.158
diff -u -p -r1.158 movieplayer.cpp
--- movieplayer.cpp     9 Dec 2007 23:30:53 -0000       1.158
+++ movieplayer.cpp     19 Jan 2008 21:49:51 -0000
@@ -1661,11 +1661,11 @@ uint8_t *TPtrQueue::lockWriteSeg(void)
   //-----------------------------------
   for(;;)
   {
-       if (isTerminated) return NULL;  // abort
-
        //-- check low level ... --
        if ( level < 2 )
        {
+               if (isTerminated) return NULL;  // abort
+
                //-- ... and freeze playback --
                if (!freezed)
                {

Only terminates the writer thread, if the buffer is empty.

[ozbodd]

OK, not surprised I am off track

I am finding there may be another cause and that is mal-formed TS files.

For example a clip that was ending 13 seconds early. I ran it through Avidemux and recompiled as a TS file. I am now finding the clip is playing to within 3 seconds of the end of file.

Your fix how might I test it? Do you have it in an 2x image I could try?

[seife]

Just apply it to movieplayer.cpp and rebuild neutrino.
It is enough to copy neutrino to /tmp/ on the box and start it for testing. Or just build a complete image, doesn't take much longer anyway

I only tested it on the dreambox, but i could clearly see (with maximum buffer segments) that the reader thread ended 10 seconds before the video stopped. Without the fix, the video stopped immediately when the reader thread ended.

[ozbodd]

Thanks - I do not know how to do that so I have asked modders on my local forum to build it, will report back on the results when available.

BTW is this reader thread you mention relative to the video length? I keep getting inconsistent times for different clips ending, sometimes 3, 1, 10 seconds, which makes me think it is a TS structure problem ...

[seife]

No, the reader thread just reads the file until the end.
The different times you got might be from different buffer settings - or simply from different bitrates of the video files. A broken TS is of course also an option, but there are many more possibilities.

[Tommy]

I have placed a neutrino binary with seifes patch in ULC. (untested, unstripped)

copy to /tmp, kill start_neutrino, kill neutrino, start neutrino from /tmp

neutrino

[ozbodd]

Thanks - I decided to approach this scientifically

I made 3 x 30 second control clips (Downloading FLV from YouTube and converting to TS using Riva Encoder) On BOTH MoviePlayer scripts they each stopped at 20, 21, 20 seconds respectively.

I transcoded these clips using Avidemux to TS again with exactly the same results :/

I then used DGIndex and HCGui to spit to the elementary streams (Selecting make DVD compliant option), Remuxed the streams to MPeg using ImagoMpeg-Muxer and finally transcoded the container to TS using VLC. The result for BOTH MoviePlayer scripts was 27, 28 and 28 seconds respectively.

Unfortunately I couldn't see a difference (I really wanted to) and think I have confirmed this is a mal-formed TS problem not a Movieplayer problem.

There does seem to be a 2-3 second cut-off that may be fixed somewhere in the script.

[seife]

There is no script.
Either Tommy made an error patching the Source (i don't believe that) or you made an error starting the modified neutrino (and did start the old, unpatched binary instead).

With the patched neutrino (and a sufficiently large buffersize), you should clearly see on the console where neutrino was started, that the reader thread ends before the player quits whereas the unpatched neutrino will quit the player as soon as the reader thread ends.

You are playing those clips via a network mount, not http, correct?

[ozbodd]

OK this is what I did

I FTP'd the neutrino into the tmp folder and chmod 755
I telnetted the box and changed to /tmp
killall -9 start_neutrino
killall -9 neutrino
neutrino -u

Then tested the movies from a cifs share under /mnt using Play TS with the buffer segments set to 24

I just repeated these steps again with the same results, the control movies stopped 10 seconds short and the remuxed movies play to within 2-3 seconds of the end on both the original and the tmp movieplayer. I did a reboot between each test & used Tommy's and another made on my usual forum.

I can send you the clips if you wish to try them.

[PT-1]

how about /tmp/neutrino -u
as your command would start neutrino from /bin

[ozbodd]

Yep that did it

The control clips played through to the end so the fix does work. Tested playing mpg files via VLC too.

Well seife

[Tommy]

@ozbodd: Then you have to find someone who built in this patch in a regular image. The unstripped binary may be to large to store it in /var (to start it on boot). I don't know whether this patch could have a negative impact to the main functionality of MP.

[ozbodd]

Yes I am hoping that it will be - Just had the dbox lockup at the end of the clip with the 'Buffering...' text showing, had to reboot, never does this before. Could this be because it is running from tmp or does it suggest a possible bug?

[Tommy]

run from /tmp makes no difference except u cannot shutdown the box as usual (because the start_neutrino is not longer running). What u see may be a sideeffect of seifes patch.