ubuntu-phone team mailing list archive

[Jim Hodapp <jim.hodapp@xxxxxxxxxxxxx>]

On Thu, Mar 20, 2014 at 11:44 AM, Ricardo Salveti de Araujo <
ricardo.salveti@xxxxxxxxxxxxx> wrote:

> On Thu, Mar 20, 2014 at 5:58 AM, Michał Sawicz
> <michal.sawicz@xxxxxxxxxxxxx> 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