ArchiveOrangemail archive

qt-mobility-feedback.qt.nokia.com


(List home) (Recent threads) (3 other Qt lists)

Subscription Options

  • RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
  • Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
  • This list contains about 418 messages, beginning Dec 2010
  • This list doesn't seem to be active
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no

QMediaPlayer API for download the playing stream

Ad
Chen, Jacob 1303198642Tue, 19 Apr 2011 07:37:22 +0000 (UTC)
Hi here,
We have a requirement to download the playing http stream(video/audio) to hard disk concurrently.
The use case is like: When user is playing a video on Youtube, the downloaded stream can be saved concurrently. Once the playing is complete, then user can choose to save the stream to somewhere on hard disk.

To use gstreamer, this can be done by setting "GST_PLAY_FLAG_DOWNLOAD" flag to playbin2, connect to the pipeline to listen deep-notify::temp-location signal, set temp-remove property of queue2 to 0 to retrieve the downloaded stream.

My question is: As I know, QMediaPlayer is using gstreamer as the backend of playback but it seems like there is no API/implementation for this requirement. Can we extend the API for QMediaPlayer, implement this and get accepted?

Appreciate any suggestion!
Regards,
Jacob
Dmytro Poplavskiy 1303200370Tue, 19 Apr 2011 08:06:10 +0000 (UTC)
Hi Jacob,On Tue, 19 Apr 2011 05:36:10 pm ext Chen, Jacob wrote:
> Hi here,
> We have a requirement to download the playing http stream(video/audio) to hard disk concurrently.
> The use case is like: When user is playing a video on Youtube, the downloaded stream can be saved concurrently. Once the playing is complete, then user can choose to save the stream to somewhere on hard disk.
> 
> To use gstreamer, this can be done by setting "GST_PLAY_FLAG_DOWNLOAD" flag to playbin2, connect to the pipeline to listen deep-notify::temp-location signal, set temp-remove property of queue2 to 0 to retrieve the downloaded stream.
> 
> My question is: As I know, QMediaPlayer is using gstreamer as the backend of playback but it seems like there is no API/implementation for this requirement. Can we extend the API for QMediaPlayer, implement this and get accepted?I have implemented this feature in the master qtmobility branch,
but we don't have the API for controlling downloading the stream
and it's too late to add new APIs to QtMobility 1.2 release.

Currently I added the platform/backend specific "mediaDownloadEnabled" property to QGstreamerPlayerControl,
it's possible to call playerControl->setProperty("mediaDownloadEnabled", true);
to enable downloading.

you can access the media player control with
player->service()->requestControl<QMediaPlayerControl>();

It's possible to query the downloaded parts with QMediaPlayerControl::availablePlaybackRanges()

I don't have an extra property for setting temp-remove of queue2, if this is necessary
it's possible to expose it in the same way, together with location of cached media.

I'm not sure it's possible to have a useful cross platform API in this case
if behavior/supported features are significantly different between backends 
the possible solution would be to keep the current backend specific extensions.


Regards
  Dmytro.> 
> Appreciate any suggestion!
> Regards,
> Jacob
> 
>
Chen, Jacob 1303262524Wed, 20 Apr 2011 01:22:04 +0000 (UTC)
Hi Dmytro,

Many thanks for the reply and explanation! :)>>if behavior/supported features are significantly different between backbends 
>>the possible solution would be to keep the current backend specific extensions.I totally agree you with this. And I think it's enough for archiving our requirement. Further question: will the feature be included in 1.2 release? Is there a schedule for 1.2 release?

Thank you.
Jacob
-----Original Message-----
From: Dmytro Poplavskiy [mailto:] 
Sent: Tuesday, April 19, 2011 4:05 PM
To: 
Cc: Chen, Jacob
Subject: Re: [Qt-mobility-feedback] QMediaPlayer API for download the playing stream

Hi Jacob,On Tue, 19 Apr 2011 05:36:10 pm ext Chen, Jacob wrote:
> Hi here,
> We have a requirement to download the playing http stream(video/audio) to hard disk concurrently.
> The use case is like: When user is playing a video on Youtube, the downloaded stream can be saved concurrently. Once the playing is complete, then user can choose to save the stream to somewhere on hard disk.
> 
> To use gstreamer, this can be done by setting "GST_PLAY_FLAG_DOWNLOAD" flag to playbin2, connect to the pipeline to listen deep-notify::temp-location signal, set temp-remove property of queue2 to 0 to retrieve the downloaded stream.
> 
> My question is: As I know, QMediaPlayer is using gstreamer as the backend of playback but it seems like there is no API/implementation for this requirement. Can we extend the API for QMediaPlayer, implement this and get accepted?I have implemented this feature in the master qtmobility branch,
but we don't have the API for controlling downloading the stream
and it's too late to add new APIs to QtMobility 1.2 release.

Currently I added the platform/backend specific "mediaDownloadEnabled" property to QGstreamerPlayerControl,
it's possible to call playerControl->setProperty("mediaDownloadEnabled", true);
to enable downloading.

you can access the media player control with
player->service()->requestControl<QMediaPlayerControl>();

It's possible to query the downloaded parts with QMediaPlayerControl::availablePlaybackRanges()

I don't have an extra property for setting temp-remove of queue2, if this is necessary
it's possible to expose it in the same way, together with location of cached media.

I'm not sure it's possible to have a useful cross platform API in this case
if behavior/supported features are significantly different between backends 
the possible solution would be to keep the current backend specific extensions.


Regards
  Dmytro.> 
> Appreciate any suggestion!
> Regards,
> Jacob
> 
>
Home | About | Privacy