Bug 9182 – No video shown, only audio, when streaming over upnp

Bug 9182 - (int-158527) No video shown, only audio, when streaming over upnp

(int-158527)
Summary:	No video shown, only audio, when streaming over upnp

Status:	RESOLVED FIXED

Product:	Media player
Component:	General
Version:	5.0/(3.2010.02-8)
Platform:	All Maemo

Importance:	Unspecified normal with 1 vote (vote)
Target Milestone:	5.0/(10.2010.19-1)
Assigned To:	unassigned
QA Contact:	media-player-bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree

Reported:	2010-02-20 15:27 UTC by Martin Dederer
Modified:	2010-03-15 20:55 UTC (History)
CC List:	2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description Martin Dederer (reporter) 2010-02-20 15:27:53 UTC

SOFTWARE VERSION:
5.0/(3.2010.02-8)

EXACT STEPS LEADING TO PROBLEM: 
1. launch ushare upnp server, no on the n900 (ushare -c <some directory
containing video file>
2. launch Media Player on N900
3. access upnp server in Media Player
4. start playback of video files

EXPECTED OUTCOME:
playback of video including audio and picture

ACTUAL OUTCOME:
only the audio track of the video is played, screen remains black

REPRODUCIBILITY:
always

EXTRA SOFTWARE INSTALLED:
none

OTHER COMMENTS:

The video files with which this behaviour occurs do play perfectly fine in
Media Player when they are copied onto the n900 in usb mass storage mode. I
tried mediatomb and ushare as upnp servers, both lead to the observed
behaviour. Streaming from the upnp servers works in totem on ubuntu 9.10.

Comment 1 Andre Klapper maemo.org

2010-02-25 23:27:41 UTC

Hi Martin, thanks for reporting this!

Comment 2 Andre Klapper maemo.org

2010-03-01 16:32:06 UTC

Can you provide a video clip that does not work?
Internal testing could not reproduce this.

Comment 3 Craig Woodward 2010-03-02 06:53:06 UTC

I have the same issue, and can easily point you to a small sample video that
fails.  Runs well on the device, but does not stream properly:

http://castus.dnsalias.com:8080/share/maemo_flyby_xvid_lame_r3.avi

It appears that most videos that are divx/xvid encoded only get audio via
streaming.  I tried changing the supplied mime-type and extentions to "trick"
media player into load it, but it failed. I do think mime-type plays a role in
it though, as below:

One thing to note is that mp4/mpeg encoded videos DO seem to stream as
expected, but only if the proper mime-type is sent.  The mime type sent by
default by ushare recognized as audio, not video, since .mp4 feed the mime type
as audio/mp4, not video/mp4.  If you rename such files to .m4v or .mpeg they
stream fine, but named .mp4 they stream only audio, as if they were .mp3 files.

Mediaplay may want to take the streamed mime type as more of a hint than a
solid answer and scan the stream header to see what it's getting vs what it was
told.

Comment 4 Andre Klapper maemo.org

2010-03-05 12:32:03 UTC

Forwarding internal comment:

(In reply to comment #3)
> http://castus.dnsalias.com:8080/share/maemo_flyby_xvid_lame_r3.avi

This video works with ushare with internal image 10.2010.08-23.


> It appears that most videos that are divx/xvid encoded only get audio via
> streaming.  I tried changing the supplied mime-type and extentions to "trick"
> media player into load it, but it failed. I do think mime-type plays a role in
> it though, as below:
> 
> One thing to note is that mp4/mpeg encoded videos DO seem to stream as
> expected, but only if the proper mime-type is sent.  The mime type sent by
> default by ushare recognized as audio, not video, since .mp4 feed the mime type
> as audio/mp4, not video/mp4.  If you rename such files to .m4v or .mpeg they
> stream fine, but named .mp4 they stream only audio, as if they were .mp3 files.

I have noticed also that ushare does regognizes .mp4 as audio.

> Mediaplay may want to take the streamed mime type as more of a hint than a
> solid answer and scan the stream header to see what it's getting vs what it was
> told.
> 

Mediaplayer gets mime type from mafw. If mafw gets mime type from server that
will be used.

This bug is already fixed internally.

A future public update will include the fix.

To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/

Comment 5 Andre Klapper maemo.org

2010-03-15 20:55:10 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).