Qtopia-interest Archive, January 2008
Qtopia mediaplayer video MIME type support
Pages: Prev | 1 | 2 | Next
Message 1 in thread
I'm trying to play any video file using qtopia 4.3.0 configured with
gstreamer.
In my Documents directory, I have .mp4 files which show up in the file
view with movie reel icons (other .avi, .mpeg files have question mark
icons). When I select a mp4 file, in the console I get:
** Message: don't know how to handle audio/x-m4a
Using vsexplorer, I see:
/Media > ls Library/Info/Simple/GStreamer/
uriSchemes/ 'file, http' (QStringList)
mimeTypes/ 'audio/x-wav, audio/mpeg,
video/x-msvideo, video/mpeg, video/mp4, audio/ogg, video/)
I tried using a .mp4 video file with no audio track, but that also
failed with:
** Message: don't know how to handle video/quicktime
What MIME type should I try?
Thanks,
John
--
[ signature omitted ]
Message 2 in thread
To answer my own question, I needed to install gst-ffmpeg to get the
mpeg4 decoder gstreamer element.
Now when I select the .mp4 video there's no console error and I get a
progress bar in the media player which I guess is indicating the state
of playback. Unfortunately no video shows, just blackness.
,
John
John Faith wrote:
> I'm trying to play any video file using qtopia 4.3.0 configured with
> gstreamer.
>
> In my Documents directory, I have .mp4 files which show up in the file
> view with movie reel icons (other .avi, .mpeg files have question mark
> icons). When I select a mp4 file, in the console I get:
>
> ** Message: don't know how to handle audio/x-m4a
>
> Using vsexplorer, I see:
> /Media > ls Library/Info/Simple/GStreamer/
> uriSchemes/ 'file, http' (QStringList)
> mimeTypes/ 'audio/x-wav, audio/mpeg,
> video/x-msvideo, video/mpeg, video/mp4, audio/ogg, video/)
>
>
> I tried using a .mp4 video file with no audio track, but that also
> failed with:
>
> ** Message: don't know how to handle video/quicktime
>
> What MIME type should I try?
>
--
[ signature omitted ]
Message 3 in thread
What's your target platform? Or are you just running in qvfb? What's
your colour depth?
On 1/18/08, John Faith <jfaith@xxxxxxxxxxxxx> wrote:
> To answer my own question, I needed to install gst-ffmpeg to get the
> mpeg4 decoder gstreamer element.
>
> Now when I select the .mp4 video there's no console error and I get a
> progress bar in the media player which I guess is indicating the state
> of playback. Unfortunately no video shows, just blackness.
>
> ,
> John
>
>
> John Faith wrote:
> > I'm trying to play any video file using qtopia 4.3.0 configured with
> > gstreamer.
> >
> > In my Documents directory, I have .mp4 files which show up in the file
> > view with movie reel icons (other .avi, .mpeg files have question mark
> > icons). When I select a mp4 file, in the console I get:
> >
> > ** Message: don't know how to handle audio/x-m4a
> >
> > Using vsexplorer, I see:
> > /Media > ls Library/Info/Simple/GStreamer/
> > uriSchemes/ 'file, http' (QStringList)
> > mimeTypes/ 'audio/x-wav, audio/mpeg,
> > video/x-msvideo, video/mpeg, video/mp4, audio/ogg, video/)
> >
> >
> > I tried using a .mp4 video file with no audio track, but that also
> > failed with:
> >
> > ** Message: don't know how to handle video/quicktime
> >
> > What MIME type should I try?
> >
>
> --
> To unsubscribe - send "unsubscribe" in the subject to
> qtopia-interest-request@xxxxxxxxxxxxx
>
>
--
[ signature omitted ]
Message 4 in thread
Hi Tom,
The platform is an embedded PowerPC board with 32bpp color depth.
I see that QtopiaVideoSink::render() in
src/plugins/mediaengines/gstreamer/gstreamerqtopiavideosink.cpp has the
format in paint() hard-coded to "QImage::Format_RGB16".
,
John
Tom Cooksey wrote:
> What's your target platform? Or are you just running in qvfb? What's
> your colour depth?
>
>
>
> On 1/18/08, John Faith <jfaith@xxxxxxxxxxxxx> wrote:
>> To answer my own question, I needed to install gst-ffmpeg to get the
>> mpeg4 decoder gstreamer element.
>>
>> Now when I select the .mp4 video there's no console error and I get a
>> progress bar in the media player which I guess is indicating the state
>> of playback. Unfortunately no video shows, just blackness.
>>
>> ,
>> John
>>
>>
>> John Faith wrote:
>>> I'm trying to play any video file using qtopia 4.3.0 configured with
>>> gstreamer.
>>>
>>> In my Documents directory, I have .mp4 files which show up in the file
>>> view with movie reel icons (other .avi, .mpeg files have question mark
>>> icons). When I select a mp4 file, in the console I get:
>>>
>>> ** Message: don't know how to handle audio/x-m4a
>>>
>>> Using vsexplorer, I see:
>>> /Media > ls Library/Info/Simple/GStreamer/
>>> uriSchemes/ 'file, http' (QStringList)
>>> mimeTypes/ 'audio/x-wav, audio/mpeg,
>>> video/x-msvideo, video/mpeg, video/mp4, audio/ogg, video/)
>>>
>>>
>>> I tried using a .mp4 video file with no audio track, but that also
>>> failed with:
>>>
>>> ** Message: don't know how to handle video/quicktime
>>>
>>> What MIME type should I try?
>>>
>> --
>> To unsubscribe - send "unsubscribe" in the subject to
>> qtopia-interest-request@xxxxxxxxxxxxx
>>
>>
--
[ signature omitted ]
Message 5 in thread
> Hi Tom,
> The platform is an embedded PowerPC board with 32bpp color depth.
>
> I see that QtopiaVideoSink::render() in
> src/plugins/mediaengines/gstreamer/gstreamerqtopiavideosink.cpp has the
> format in paint() hard-coded to "QImage::Format_RGB16".
That's what I was affraid of and is probably the problem. :-(
Although, if the image format's wrong you should see a garbled
display, not a black one. If this is in the latest version (4.2.4 I
believe?), I recomend you raise it as a bug. Can you switch to 16-bit
temporarily until this is fixed?
I don't know the qtopia code base I'm affraid so probably not too much
help. Might be interesting to note that Trolltech are bundling the
Phonon with Qt 4.4
(http://trolltech.com/company/newsroom/announcements/press.2007-12-11.2263733764).
Having said that, I'm not sure if Qtopia is going to switch to phonon
given it already has a fairly well featured media framework (even if
it doesn't support 32-bit colour depth on gstreamer yet).
I believe Helix supports MP4 containers & MPEG4-part2 video. Have you
tried that as a back end instead? When you say mpeg4, I assume you
mean MP4 container encapsulating MPEG4-part2 data?
Cheers,
Tom
--
[ signature omitted ]
Message 6 in thread
Hi John,
I've looked through the code and it's not actually a bug. Assuming the
qtopia core libs were built with 16bpp & 32bpp support, things should
be working (I.e. QT_QWS_DEPTH_32 & QT_QWS_DEPTH_16 are defined). If
the libs weren't built with QT_QWS_DEPTH_16 defined, you should be
seeing an error message. As your not seeing an error, my guess is it's
something else. The path from QtopiaVideoSink::render to the QScreen's
blit function is reasonably strait forward and I can't see any
problems. I assume your using a bog standard linuxfb QScreen driver?
The problem must be somewhere before QtopiaVideoSink::render is
called. Either the function's being called with a blank buffer, or
it's not being called at all. You could try adding a "qDebug() <<
"Boo!";" to the top of QtopiaVideoSink::render() to make sure it is
being called?
Alternetively, try the helix backend as I've mentioned already.
Cheers,
Tom
On 1/18/08, Tom Cooksey <tomcooksey@xxxxxxxxxxxxxx> wrote:
> > Hi Tom,
> > The platform is an embedded PowerPC board with 32bpp color depth.
> >
> > I see that QtopiaVideoSink::render() in
> > src/plugins/mediaengines/gstreamer/gstreamerqtopiavideosink.cpp has the
> > format in paint() hard-coded to "QImage::Format_RGB16".
>
> That's what I was affraid of and is probably the problem. :-(
> Although, if the image format's wrong you should see a garbled
> display, not a black one. If this is in the latest version (4.2.4 I
> believe?), I recomend you raise it as a bug. Can you switch to 16-bit
> temporarily until this is fixed?
>
> I don't know the qtopia code base I'm affraid so probably not too much
> help. Might be interesting to note that Trolltech are bundling the
> Phonon with Qt 4.4
> (http://trolltech.com/company/newsroom/announcements/press.2007-12-11.2263733764).
> Having said that, I'm not sure if Qtopia is going to switch to phonon
> given it already has a fairly well featured media framework (even if
> it doesn't support 32-bit colour depth on gstreamer yet).
>
> I believe Helix supports MP4 containers & MPEG4-part2 video. Have you
> tried that as a back end instead? When you say mpeg4, I assume you
> mean MP4 container encapsulating MPEG4-part2 data?
>
>
> Cheers,
>
> Tom
>
--
[ signature omitted ]
Message 7 in thread
Hi Tom,
I put a printf() in QtopiaVideoSink::render() and did see the message on
the console (with non-NULL pointers passed in) and I checked that
QT_QWS_DEPTH_32 and QT_QWS_DEPTH_16 are both defined. I'll contact the
person who wrote the framebuffer driver to see if he has any ideas.
I have looked at Helix, but did not get past trying to build it. I've
had better luck with gstreamer in getting all the parts of the source
needed.
Thanks for your help!
,
John
Tom Cooksey wrote:
> Hi John,
>
> I've looked through the code and it's not actually a bug. Assuming the
> qtopia core libs were built with 16bpp & 32bpp support, things should
> be working (I.e. QT_QWS_DEPTH_32 & QT_QWS_DEPTH_16 are defined). If
> the libs weren't built with QT_QWS_DEPTH_16 defined, you should be
> seeing an error message. As your not seeing an error, my guess is it's
> something else. The path from QtopiaVideoSink::render to the QScreen's
> blit function is reasonably strait forward and I can't see any
> problems. I assume your using a bog standard linuxfb QScreen driver?
>
> The problem must be somewhere before QtopiaVideoSink::render is
> called. Either the function's being called with a blank buffer, or
> it's not being called at all. You could try adding a "qDebug() <<
> "Boo!";" to the top of QtopiaVideoSink::render() to make sure it is
> being called?
>
> Alternetively, try the helix backend as I've mentioned already.
>
>
> Cheers,
>
> Tom
>
> On 1/18/08, Tom Cooksey <tomcooksey@xxxxxxxxxxxxxx> wrote:
>>> Hi Tom,
>>> The platform is an embedded PowerPC board with 32bpp color depth.
>>>
>>> I see that QtopiaVideoSink::render() in
>>> src/plugins/mediaengines/gstreamer/gstreamerqtopiavideosink.cpp has the
>>> format in paint() hard-coded to "QImage::Format_RGB16".
>> That's what I was affraid of and is probably the problem. :-(
>> Although, if the image format's wrong you should see a garbled
>> display, not a black one. If this is in the latest version (4.2.4 I
>> believe?), I recomend you raise it as a bug. Can you switch to 16-bit
>> temporarily until this is fixed?
>>
>> I don't know the qtopia code base I'm affraid so probably not too much
>> help. Might be interesting to note that Trolltech are bundling the
>> Phonon with Qt 4.4
>> (http://trolltech.com/company/newsroom/announcements/press.2007-12-11.2263733764).
>> Having said that, I'm not sure if Qtopia is going to switch to phonon
>> given it already has a fairly well featured media framework (even if
>> it doesn't support 32-bit colour depth on gstreamer yet).
>>
>> I believe Helix supports MP4 containers & MPEG4-part2 video. Have you
>> tried that as a back end instead? When you say mpeg4, I assume you
>> mean MP4 container encapsulating MPEG4-part2 data?
>>
>>
>> Cheers,
>>
>> Tom
>>
--
[ signature omitted ]
Message 8 in thread
> Hi Tom,
> I put a printf() in QtopiaVideoSink::render() and did see the message on
> the console (with non-NULL pointers passed in) and I checked that
> QT_QWS_DEPTH_32 and QT_QWS_DEPTH_16 are both defined. I'll contact the
> person who wrote the framebuffer driver to see if he has any ideas.
If it's a standard linuxfb, I.e. Qtopia Core is using it's LinuxFB
screen driver, it should be fine. The qscreenlinuxfb_qws driver
doesn't reimplement blit() meaning it will use QScreen's blit()
implementation, which has some optimised routines for blit'ing (&
converting) any supported image format. If you've written your own
QScreen driver which re-implements blit(), it will have to do the
conversion from 16-bit to 32-bit. If it's not doing the conversion,
that could be the problem.
Any change you could printf the width & height and maybe the first few
words of buf? If buf contains 0x00000000, then we know the problems
before that point. Also, is render() being called repeadadly (say
about the framerate of the video source?) :-)
Cheers,
Tom
--
[ signature omitted ]
Message 9 in thread
> Any change you could printf the width & height and maybe the first few
> words of buf? If buf contains 0x00000000, then we know the problems
> before that point. Also, is render() being called repeadadly (say
> about the framerate of the video source?) :-)
That should read "Any chance..." :-)
Also, are you running the media player stand-alone, or from a
launcher? If it's not the only Qtopia process running, kill all the
other processes & start the mediaplayer with the -qws command
argument.
--
[ signature omitted ]
Message 10 in thread
Tom Cooksey wrote:
>> Any change you could printf the width & height and maybe the first few
>> words of buf? If buf contains 0x00000000, then we know the problems
>> before that point. Also, is render() being called repeadadly (say
>> about the framerate of the video source?) :-)
QtopiaVideoSink::render(101320b8, 106e7000)
width=190 height=240
data= ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
So it looks like bad data coming from gstreamer decode.
> Also, are you running the media player stand-alone, or from a
> launcher? If it's not the only Qtopia process running, kill all the
> other processes & start the mediaplayer with the -qws command
> argument.
I was running from the launcher, but for some reason touching
gstreamerqtopiavideosink.cpp has made the launcher fail to work as
expected. For the above case, I've run it by itself while qpe is also
running. When I try '-qws' without qpe the media player does not try to
play the video file and I see:
# ./mediaplayer -qws /root/Documents/sample_mpeg4_nosound.mp4
WARNING: Cannot change document system connection type in file main.cpp
line 26
ApplicationLayer: Unable to connect to server, application layer will be
disabled.
Thanks,
John
--
[ signature omitted ]
Message 11 in thread
> >> Any change you could printf the width & height and maybe the first few
> >> words of buf? If buf contains 0x00000000, then we know the problems
> >> before that point. Also, is render() being called repeadadly (say
> >> about the framerate of the video source?) :-)
>
>
> QtopiaVideoSink::render(101320b8, 106e7000)
> width=190 height=240
> data= ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff
>
> So it looks like bad data coming from gstreamer decode.
>
>
> > Also, are you running the media player stand-alone, or from a
> > launcher? If it's not the only Qtopia process running, kill all the
> > other processes & start the mediaplayer with the -qws command
> > argument.
>
> I was running from the launcher, but for some reason touching
> gstreamerqtopiavideosink.cpp has made the launcher fail to work as
> expected. For the above case, I've run it by itself while qpe is also
> running. When I try '-qws' without qpe the media player does not try to
> play the video file and I see:
>
> # ./mediaplayer -qws /root/Documents/sample_mpeg4_nosound.mp4
> WARNING: Cannot change document system connection type in file main.cpp
> line 26
> ApplicationLayer: Unable to connect to server, application layer will be
> disabled.
Well it sounds to me like your right - GStreamer is giving you bad
data, although the screen should be white not black if it's getting
0xFFFFFFFF? It could still be a problem with Qtopia if the sink
element isn't registered with gstreamer properly, although it feels
like a GStreamer or ffmpeg issue to me.
I guess mediaplayer needs to connect to qpe for things other than just
window management - I guess for things like pausing playback when a
call comes in. Like I say, I'm not too familiar with Qtopia, I'm more
of a Qtopia Core man. :-)
Does the video play if you use a desktop media player with a
gstreamer+ffmpeg backend?
Cheers,
Tom
--
[ signature omitted ]
Message 12 in thread
Tom Cooksey wrote:
>>>> Any change you could printf the width & height and maybe the first few
>>>> words of buf? If buf contains 0x00000000, then we know the problems
>>>> before that point. Also, is render() being called repeadadly (say
>>>> about the framerate of the video source?) :-)
>>
>> QtopiaVideoSink::render(101320b8, 106e7000)
>> width=190 height=240
>> data= ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> ff ff ff ff
>>
>> So it looks like bad data coming from gstreamer decode.
>>
...
>
> Well it sounds to me like your right - GStreamer is giving you bad
> data, although the screen should be white not black if it's getting
> 0xFFFFFFFF? It could still be a problem with Qtopia if the sink
> element isn't registered with gstreamer properly, although it feels
> like a GStreamer or ffmpeg issue to me.
...
>
> Does the video play if you use a desktop media player with a
> gstreamer+ffmpeg backend?
>
Yes, the video plays fine on the desktop using kaffine, vlc, ffplay,
gstreamer 'playbin', or a gstreamer pipeline specifying the ffdec_mpeg4
element explicitly.
Thanks,
John
--
[ signature omitted ]
Message 13 in thread
I think I found the problem.
In PlaybinSession::getStreamsInfo() in
src/plugins/mediaengines/gstreamer/gstreamerplaybinsession.cpp, the flag
haveStreamInfo is set if the method is ever called. In my case, the
first time it is called, the playbin stream-info has nothing in it, so
the QMediaVideoControlServer never gets created.
If I wait until GST_STREAM_TYPE_VIDEO type stream-info arrives before
setting haveStreamInfo=true, then the mediaplayer is happier and I see
video data.
,
John
--
[ signature omitted ]
Message 14 in thread
Hi John,
I see what your saying... From your description & looking at the code,
I guess whats happining is that the element created by gstreamer (to
handle the url passed to the factory) is causing the state transition
of the Qtopia sink element from GST_STATE_READY->GST_STATE_PAUSED
twice. During the first transition, playbin has no stream info. It's
only on the second transition does playbin contain stream info. I
don't know gstreamer too well, but this seems wrong. Surely an element
should not transition to GST_STATE_PAUSED if there's no stream info
avaliable yet? What happens if you add a printf to
PlaybinSession::busMessage() in the "case GST_MESSAGE_STATE_CHANGED:"
printing out oldState & newState? I'm curious what other state
transitions are occuring.
Cheers,
Tom
PS: What time zone are you in?
On 1/21/08, John Faith <jfaith@xxxxxxxxxxxxx> wrote:
> I think I found the problem.
>
> In PlaybinSession::getStreamsInfo() in
> src/plugins/mediaengines/gstreamer/gstreamerplaybinsession.cpp, the flag
> haveStreamInfo is set if the method is ever called. In my case, the
> first time it is called, the playbin stream-info has nothing in it, so
> the QMediaVideoControlServer never gets created.
>
> If I wait until GST_STREAM_TYPE_VIDEO type stream-info arrives before
> setting haveStreamInfo=true, then the mediaplayer is happier and I see
> video data.
>
> ,
> John
>
> --
> To unsubscribe - send "unsubscribe" in the subject to
> qtopia-interest-request@xxxxxxxxxxxxx
>
>
--
[ signature omitted ]
Message 15 in thread
Hi Tom,
Below is the type of output I saw. I got 3 calls to getStreamsInfo()
before there was a TYPE_VIDEO.
# ./mediaplayer /root/Documents/sample_mpeg4_nosound.mp4
set playbin to GST_STATE_PLAYING
GST_MESSAGE_STATE_CHANGED GST_STATE_READY
GST_MESSAGE_STATE_CHANGED GST_STATE_READY
GST_MESSAGE_STATE_CHANGED GST_STATE_READY
GST_MESSAGE_STATE_CHANGED GST_STATE_READY
GST_MESSAGE_STATE_CHANGED GST_STATE_READY
GST_MESSAGE_STATE_CHANGED GST_STATE_READY
GST_MESSAGE_STATE_CHANGED GST_STATE_PAUSED
getStreamsInfo()
GST_MESSAGE_STATE_CHANGED GST_STATE_PAUSED
getStreamsInfo()
GST_MESSAGE_STATE_CHANGED GST_STATE_READY
GST_MESSAGE_STATE_CHANGED GST_STATE_PAUSED
getStreamsInfo()
GST_MESSAGE_STATE_CHANGED GST_STATE_READY
GST_MESSAGE_STATE_CHANGED GST_STATE_READY
GST_MESSAGE_STATE_CHANGED GST_STATE_READY
GST_MESSAGE_STATE_CHANGED GST_STATE_PAUSED
getStreamsInfo()
GST_STREAM_TYPE_VIDEO
,
John
Timezone is US Pacific
Tom Cooksey wrote:
> Hi John,
>
> I see what your saying... From your description & looking at the code,
> I guess whats happining is that the element created by gstreamer (to
> handle the url passed to the factory) is causing the state transition
> of the Qtopia sink element from GST_STATE_READY->GST_STATE_PAUSED
> twice. During the first transition, playbin has no stream info. It's
> only on the second transition does playbin contain stream info. I
> don't know gstreamer too well, but this seems wrong. Surely an element
> should not transition to GST_STATE_PAUSED if there's no stream info
> avaliable yet? What happens if you add a printf to
> PlaybinSession::busMessage() in the "case GST_MESSAGE_STATE_CHANGED:"
> printing out oldState & newState? I'm curious what other state
> transitions are occuring.
>
>
> Cheers,
>
> Tom
>
> PS: What time zone are you in?
>
>
> On 1/21/08, John Faith <jfaith@xxxxxxxxxxxxx> wrote:
>> I think I found the problem.
>>
>> In PlaybinSession::getStreamsInfo() in
>> src/plugins/mediaengines/gstreamer/gstreamerplaybinsession.cpp, the flag
>> haveStreamInfo is set if the method is ever called. In my case, the
>> first time it is called, the playbin stream-info has nothing in it, so
>> the QMediaVideoControlServer never gets created.
>>
>> If I wait until GST_STREAM_TYPE_VIDEO type stream-info arrives before
>> setting haveStreamInfo=true, then the mediaplayer is happier and I see
>> video data.
...
--
[ signature omitted ]
Pages: Prev | 1 | 2 | Next
