On Thu, Mar 20, 2014 at 11:44 AM, Ricardo Salveti de Araujo < ricardo.salv...@canonical.com> wrote:
> On Thu, Mar 20, 2014 at 5:58 AM, Michał Sawicz > <michal.saw...@canonical.com> wrote: > > On 20.03.2014 09:24, Selene Scriven wrote: > >> I've also noticed that our media player doesn't seem to support > >> very many video codecs. I had difficulty finding videos it can > >> actually play. This most likely isn't a regression, but it'd be > >> awfully nice if we could add in the full lavc / ffmpeg codec set, > >> and be able to play practically every video format ever made. > > > > The "industry standards", i.e. mp4 / mov / flv with h264 and mp3 should > > play just fine. AFAICT shipping lavc is not an option due to licensing. > > And then it adds a whole lot of MBs to our image size with all the > > dependencies. > > We had lavc / ffmpeg and had to remove because of licensing issues. > Even if we add them back, software decoding is currently broken, so it > wouldn't help. > > >> That is, assuming the hardware can handle it. I think we're > >> still using software decoders, considering that my battery charge > >> level actually went down during playback even though it was > >> plugged in. (and that was on a low-bitrate 640x352 video; > >> probably drains faster with HD video) > > > > No, it's not playing in software - if battery is drained during playback > > that's a bug. > > We're only doing hardware decoding, so it might be indeed a bug in our > gst-hybris stack. Would you mind opening a bug for that? I know Jim > changed the dequeue timeout values before, and that directly affects > the amount of cpu used, so we might have a regression (probably need > some further fine tuning). > I suspect what Ricardo said is correct, that the timeout needs tweaking. The good news is I have a tweaked value that will land as part of the media-hub change set. I know that right now the timeout is set to 0 for enqueuing and dequeing decoding output buffers, and that takes the CPU usage to right about max. With a proper timeout, on the latest Nexus 7, it's somewhere in the 40% mark. > > >> (would also be pretty cool if we could include support for > >> mounting nfs and samba shares directly and playing media from > >> them) > > > > *cough* geek alert *cough* > > > > But for real, a network-share browser would be part of the content-hub > > story, I imagine. You'd browse the remote shares and either share the > > actual content to a music app (which would then actually be downloaded > > to the device), or just a playlist (which would then be streamed, > > assuming gstreamer can actually stream from whatever source that is). > > Streaming from nfs/samba should probably work already, but we'd need > someone to give that specific url to the mediaplayer-app. > Streaming definitely works and should work for almost any type of streaming source that GStreamer can handle. One exception might be RTP/RTSP, but I doubt we'll have a requirement for that any time soon. > > Cheers, > -- > Ricardo Salveti de Araujo > Jim
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
