Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Deprecated: Function create_function() is deprecated in /sites/ on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/ on line 845 Deprecated: Function create_function() is deprecated in /sites/ on line 111 FS#12510 : MPEG player does not work on Fuze+



FS#12510 - MPEG player does not work on Fuze+

Attached to Project: Rockbox
Opened by Michael Rodger (megal0maniac) - Wednesday, 04 January 2012, 22:35 GMT
Last edited by MichaelGiacomelli (saratoga) - Wednesday, 11 April 2012, 02:00 GMT
Task Type Bugs
Category Video
Status Closed
Assigned To No-one
Operating System Sansa Fuze+
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Appears in all tested builds up until current (r31583)
Video playback fails with error message "Cannot create buffering thread" regardless of file format.
Tested formats:
MPEG-PS 43m59s / 128x62 157kbps VBR MPEG2 / 320kbps 44.1KHz CBR Stereo MP3 / Encoded for, and works on Clip+ with 3.10
MPEG-PS 19m14s / 320x240 379kbps VBR MPEG2 / 128kbps 44.1KHz CBR Stereo MP3
Text file (To test whether error is file type specific. It isn't.)

Steps to recreate: Attempt to open any file with MPEG Player on Fuze+
This task depends upon

Closed by  MichaelGiacomelli (saratoga)
Wednesday, 11 April 2012, 02:00 GMT
Reason for closing:  Fixed
Comment by Michael Sevakis (MikeS) - Thursday, 05 January 2012, 04:01 GMT
I would expect that if the target uses any threads of its own and didn't define TARGET_EXTRA_THREADS, there won't be enough free thread slots to allocate.

TIP: Check System->Debug->View OS Stacks and there needs to be three thread slots free for mpegplayer to work.
Comment by Michael Rodger (megal0maniac) - Thursday, 05 January 2012, 08:08 GMT
Immediately after bootup, only slots 15 and 16 are available.
How can this be resolved?
Comment by amaury pouly (pamaury) - Thursday, 05 January 2012, 12:11 GMT
I thought I already define TARGET_EXTRA_THREADS but perhaps I put the wrong value. I'll check that asap.
Comment by Michael Rodger (megal0maniac) - Friday, 06 January 2012, 22:54 GMT
If I wanted to build my own, how would I define this? I only know how to build a clean build at this stage.
Comment by Michael Rodger (megal0maniac) - Saturday, 07 January 2012, 11:46 GMT
I ran SVN update, edited thread.h to say TARGET_EXTRA_THREADS 1, executed the make file and replaced the rockbox.sansa file. There are still only 2 threads open. What have I missed?
Running Crunchbang Statler (Debian Squeeze based)
Comment by Michael Sevakis (MikeS) - Saturday, 07 January 2012, 12:15 GMT
Edit the the main config file from /firmware/export/config, not thread.h
Comment by Michael Sevakis (MikeS) - Saturday, 07 January 2012, 12:25 GMT
Just apply this? :)
Comment by amaury pouly (pamaury) - Saturday, 07 January 2012, 16:31 GMT
I have set the number of extra threads to 1 in the SVN. This should solve the issue.
Comment by Michael Rodger (megal0maniac) - Saturday, 07 January 2012, 20:39 GMT
Thanks! Video playback no longer fails, confirmed 3 open threads under OS Stacks.
However, playback does not work correctly.

Limit FPS: Yes (default)
Skip frames: Yes (default)
Upon opening the video, nothing is displayed. When pausing (and thus bringing up the seek bar) there is video in a small section of the top right corner of the screen (in landscape orientation) and the video updates every second on the second (as the counter advances, and I'd imagine the region is redrawn)
After bringing up the seek bar and it disappearing, the section of video becomes slightly larger but does not advance.
Indicated frame rate is around 25.

Limit FPS: No
Skip frames: No
Exactly the same thing, except the indicated FPS is around 20.

With both scenarios, audio works perfectly. Video is refreshed if Show FPS is on (so if anything on the screen is being re-drawn)
The size of the segment of video shown varies. Same video files as mentioned above were used. More of the 128x62 video could be seen than the 320x240.

Screendump did not work correctly while playing video. I can take a picture tomorrow with a digital camera if that would help.

Sorry if I appear to be asking stupid questions or providing excessive detail. I'm pretty new to this.
Thanks for the tip regarding SVN. I'm learning quickly :)
Comment by amaury pouly (pamaury) - Sunday, 22 January 2012, 12:40 GMT
The problems comes from the implementation of yuv blitting. For historical reason, lcd_blit_yuv bypasses the software framebuffer and writes directly into the hardware framebuffer, but since the fuze+ needs to sends command to update the screen, these are never sent and the screen is never refreshed on yuv blitting. There are several ways to solve that, one would be to implement lcd yuv blitting instead of using the generic implementation. I'm working on using the hardware to do the yuv conversion, that would solve the problem and be much more efficient.
Comment by amaury pouly (pamaury) - Friday, 27 January 2012, 19:21 GMT
d32891f should have fixed the isssue with mpegplayer. I don't have any videos at hand but at least it fixes yuv blitting which I believe is the culprit. Can you try again ?
Comment by Michael Rodger (megal0maniac) - Friday, 27 January 2012, 22:12 GMT
d684858 works perfectly :)
Video is smooth and as it should be.
More of a matter of interest than a problem, but if showfps is enabled, the number isn't shown but flashes once every second - regardless of whether the seek bar is visible. Only when the video is paused does the fps reading stay on the screen.
I'm not complaining, I'm ecstatic that video now works. Just thought I'd mention it, since it seems strange.
Thank you very much for your work on this!
Comment by Michael Sevakis (MikeS) - Saturday, 28 January 2012, 03:36 GMT
The FPS is supposed to be drawn (just copied, not completely rendered) on every frame after the video updates though perhaps things are working differently here.
Comment by Jean-Louis Biasini (JeanLouisBiasini) - Wednesday, 28 March 2012, 15:26 GMT
this appears to be fixed, can I close this?
Comment by Michael Rodger (megal0maniac) - Wednesday, 28 March 2012, 18:31 GMT
Yeah, you can close.
Only remaining issue is the FPS not being drawn correctly, but thats a minor thing and does not belong on this task.