• Status Closed
  • Percent Complete
  • Task Type Bugs
  • Category Video
  • Assigned To No-one
  • Operating System Sansa Fuze+
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by megal0maniac - 2012-01-04
Last edited by saratoga - 2012-04-11

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

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 / 128×62 157kbps VBR MPEG2 / 320kbps 44.1KHz CBR Stereo MP3 / Encoded for, and works on Clip+ with 3.10
MPEG-PS 19m14s / 320×240 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+

Closed by  saratoga
2012-04-11 02:00
Reason for closing:  Fixed
MikeS commented on 2012-01-05 04:01

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.

Immediately after bootup, only slots 15 and 16 are available.
How can this be resolved?

I thought I already define TARGET_EXTRA_THREADS but perhaps I put the wrong value. I’ll check that asap.

If I wanted to build my own, how would I define this? I only know how to build a clean build at this stage.

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)

MikeS commented on 2012-01-07 12:15

Edit the the main config file from /firmware/export/config, not thread.h

MikeS commented on 2012-01-07 12:25

Just apply this? :)

I have set the number of extra threads to 1 in the SVN. This should solve the issue.

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 128×62 video could be seen than the 320×240.

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 :)

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.

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 ?

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!

MikeS commented on 2012-01-28 03:36

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.

this appears to be fixed, can I close this?

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.


Available keyboard shortcuts


Task Details

Task Editing