[9fans] Multimedia on Plan 9

[9fans] Multimedia on Plan 9

[Anant Narayanan]

Hi All,

While madplay does a good job of playing MP3s, I haven't been able to
get mpeg_play working yet. (It just displays a blank screen and does
nothing, killing it gives no messages either)

There are large number of other A/V formats out there, which are
conventionally played, in form on another, via the ffmpeg library on
Linux/BSD machines. Looking at the 9fans archives it seems like there
was some effort to port it, but I can't find any code.

Also, the SDL/madplay/mpeg_play ports are all based on APE (for obvious
reasons), but APE always seems like a sub-optimal solution as far as
Plan 9 is concerned. How difficult would it be to develop a native Plan
9 library for A/V decoding? Note that most A/V libraries out there make
extensive use of inline assembly, how would that fit in with "The Plan 9
way"?

Hints would be helpful.

Cheers,
--
Anant

Re: [9fans] Multimedia on Plan 9

[Charles Forsyth]

>Note that most A/V libraries out there make
>extensive use of inline assembly, how would that fit in with "The Plan 9
>way"?

it depends whether it's actually sensible, since the inline assembly often
does little enough.  in this case, assuming it makes sense, you'd just write
it up in .s and call it.  if the overhead of a function call is too much,
there wasn't much point in doing the low-level fiddling in the first place.
that's roughly the approach.

Re: [9fans] Multimedia on Plan 9

[Jack Johnson]

Though not quite the Plan 9 way, do you suspect it would be easier to
start over from scratch, maybe using Limbo/Inferno, rather than
dragging a bunch of code that's probably C++ anyway over to Plan 9?

In some ways it's the HTML problem, where the flavor of the month
target moves faster than the motivation of the coders.  How long
before OGG and Flash are on the request list?

-Jack

Re: [9fans] Multimedia on Plan 9

[Roman Shaposhnick]

On Thu, 2007-06-21 at 15:53 -0700, Jack Johnson wrote:
> Though not quite the Plan 9 way, do you suspect it would be easier to
> start over from scratch, maybe using Limbo/Inferno, rather than
> dragging a bunch of code that's probably C++ anyway over to Plan 9?

  One of the reasons I would like to fully port ffmpeg to plan 9 is
because it is a nice C code base. Besides it fits very well the
overall 9P model (think of codecs as the way for endpoints to
communicate efficiently).

> In some ways it's the HTML problem, where the flavor of the month
> target moves faster than the motivation of the coders.  How long
> before OGG and Flash are on the request list?

  There's nothing wrong with OGG and Flash. In fact, one of the coolest
features of FFmpeg is that we try to implement most of the codecs
and formats as clean room implementations, not because we are ignorant
bastards but because we can usually do a waaay better job than the
bloated implementations which are out there.

Thanks,
Roman.

Re: [9fans] Multimedia on Plan 9

[Richard Miller]

> How long
> before OGG and Flash are on the request list?

Ogg is already done - see /n/sources/contrib/cnielsen

Re: [9fans] Multimedia on Plan 9

[vir]

On Fri, 22 Jun 2007 10:01:06 +0100
 Richard Miller <9fans@hamnavoe.com> wrote:
> > How long
> > before OGG and Flash are on the request list?
> 
> Ogg is already done - see /n/sources/contrib/cnielsen
> 

What about some multimedia framework, like Microsoft
DirectShow, GStream or likewise? What is the Plan 9 way? It
seems like every multimedia component should be a file
server with some standart interface, something like:
./input1
./inputfmt1
./input2
./inputfmt2
./output1
./outputfmt1

Re: [9fans] Multimedia on Plan 9

[Steve Simon]

> It seems like every multimedia component should be a file
> server with some standart interface

Beware of pushing the file mataphor too far, jpg(1) and tojpg(1) work
pretty well, as pipelined processes though animated gifs don't fit so well.

This said animated gifs are really short movies so gif -c could output a
movie clip file (format yet to be defined) rather than a single image file,
this would fit the model much better...

If anyone is interested I ranted on the idea of a toolkit approach to movies
here /n/sources/contrib/steve/Blog

-Steve

Re: [9fans] Multimedia on Plan 9

[Roman Shaposhnick]

On Fri, 2007-06-22 at 10:52 +0100, Steve Simon wrote:
> > It seems like every multimedia component should be a file
> > server with some standart interface
>
> Beware of pushing the file mataphor too far, jpg(1) and tojpg(1) work
> pretty well, as pipelined processes though animated gifs don't fit so well.
>
> This said animated gifs are really short movies so gif -c could output a
> movie clip file (format yet to be defined) rather than a single image file,
> this would fit the model much better...

  Well, you're right. But there's nothing special about gif per se. Gif
happens to be both a container format and a picture codec at the same
time. Handling animated GIFs in that regard should  be no different from
handling AVIs with MPEG4 in them.

  Although Plan9 file model, as nice as it is breaks horribly when
we start talking about HD multimedia content. The performance bottleneck
is quite noticeable at 50MBpbs :-(

Thanks,
Roman.

Re: [9fans] Multimedia on Plan 9

[Lyndon Nerenberg]

>>> It seems like every multimedia component should be a file
>>> server with some standart interface

What do you need beyond what the plumber provides?

--lyndon

   Always Mount a Scratch Monkey

Re: [9fans] Multimedia on Plan 9

[erik quanstrom]

>   Although Plan9 file model, as nice as it is breaks horribly when
> we start talking about HD multimedia content. The performance bottleneck
> is quite noticeable at 50MBpbs :-(

50 MB/s == 1 gigabit

i think this will be a problem as soon as there exist gigabit link to actual
content providers.

- erik

Re: [9fans] Multimedia on Plan 9

[Roman Shaposhnick]

On Fri, 2007-06-22 at 17:07 -0400, erik quanstrom wrote:
> >   Although Plan9 file model, as nice as it is breaks horribly when
> > we start talking about HD multimedia content. The performance bottleneck
> > is quite noticeable at 50MBpbs :-(
>
> 50 MB/s == 1 gigabit
> i think this will be a problem as soon as there exist gigabit link to actual
> content providers.

  Sorry for the garbled 'MBpbs' junk (tired fingers on a keyboard which
is waaaay smaller than I usually use). Of course I meant Mbits per
second. And that's now the norm in HD media.

Thanks,
Roman.

Re: [9fans] Multimedia on Plan 9

[Roman Shaposhnick]

On Fri, 2007-06-22 at 13:15 +0400, vir@comtv.ru wrote:
> On Fri, 22 Jun 2007 10:01:06 +0100
>  Richard Miller <9fans@hamnavoe.com> wrote:
> > > How long
> > > before OGG and Flash are on the request list?
> >
> > Ogg is already done - see /n/sources/contrib/cnielsen
> >
>
> What about some multimedia framework, like Microsoft
> DirectShow, GStream or likewise?

  These are very bad examples to mimic.

> What is the Plan 9 way? It
> seems like every multimedia component should be a file
> server with some standart interface, something like:
> ./input1
> ./inputfmt1
> ./input2
> ./inputfmt2
> ./output1
> ./outputfmt1

  What kind of a framework are you trying to build?

Thanks,
Roman.

Re: [9fans] Multimedia on Plan 9

[Roman Shaposhnick]

On Thu, 2007-06-21 at 22:30 +0100, Charles Forsyth wrote:
> >Note that most A/V libraries out there make
> >extensive use of inline assembly, how would that fit in with "The Plan 9
> >way"?
>
> it depends whether it's actually sensible, since the inline assembly often
> does little enough.  in this case, assuming it makes sense, you'd just write
> it up in .s and call it.  if the overhead of a function call is too much,
> there wasn't much point in doing the low-level fiddling in the first place.
> that's roughly the approach.

  I still disagree. Here's why: I tried it in FFmpeg once and the basic
lesson was it wasn't so much the cost of the call per se that killed
performance but the fact that the register allocation was totally
screwed up if you had to resort to separate functions in .s files
all of which get called as part of a bigger complex computation routine.
And this is, basically, what SIMD is all about: it gives you nice
building blocks but they are so low level that you have to be really
conscious of how you use them.

Thanks,
Roman.

Re: [9fans] Multimedia on Plan 9

[Roman Shaposhnick]

On Thu, 2007-06-21 at 23:49 +0530, Anant Narayanan wrote:
> Hi All,
>
> While madplay does a good job of playing MP3s, I haven't been able to
> get mpeg_play working yet. (It just displays a blank screen and does
> nothing, killing it gives no messages either)
>
> There are large number of other A/V formats out there, which are
> conventionally played, in form on another, via the ffmpeg library on
> Linux/BSD machines. Looking at the 9fans archives it seems like there
> was some effort to port it, but I can't find any code.

  It is on my TODO list.

> Also, the SDL/madplay/mpeg_play ports are all based on APE (for obvious
> reasons), but APE always seems like a sub-optimal solution as far as
> Plan 9 is concerned. How difficult would it be to develop a native Plan
> 9 library for A/V decoding? Note that most A/V libraries out there make
> extensive use of inline assembly, how would that fit in with "The Plan 9
> way"?

  FFmpeg can be easily configured in a way that #ifdefs out all of the
GNUisms. But you pay a hefty price in performance for that.

Thanks,
Roman.