Re: [Screenkast-devel] Export to MPEG-2

[Zak <iw...@iw...>]

On Monday 31 July 2006 18:34, Bram Biesbrouck wrote:
> ScreenKast saves it's commentboxes (etc) as xml ... By fixating 
> those boxes into the stream of rects, you lose all the important
> abilities you need to edit the boxes, including translation, so as a
> native format, MPEG-2 (and all other suggestions) is no viable
> option, I guess.

I agree.  When I say "baseline export format", I mean "most basic and 
most supported" - not "native".  In exactly the same way that a 
Hollywood film is "natively" kept in some absurdly high-quality format, 
capable of being transformed for anything from an IMAX cinema screen to 
an "iPod Video" but useless to the average user, screenkast's native 
format should continue to be a custom one (currently ISD) that supports 
all the features and allows editing, but is (usually) encoded to other 
formats before end-users receive it.

> > I think the key to getting this right is to offer a baseline export
> > format that's supported absolutely everywhere.
> 
> I don't fully understand what you are talking about: [the ISD, the
> FLV], or the file format used by captorials.com.

I'm saying that every captorial should be available in at least *one* 
format that "just works".  On the website, I'm imagining something 
like:

  Click here to view this captorial in Flash (requires Flash plugin).
  You can also view this captorial in:
    * ~400K MPEG (works on any platform)  [<-- this is always available]
    * ~1000K ISD (requires AJAX-compliant browser)
    * ~9999K VNC (requires VNC player)
    * [etc etc]

That way absolutely anyone coming to the site using any PC will find a 
copy of the captorial they're after in *some* format that "just works".

In the screenkast tool itself you'd have to make sure that the "most 
basic and most supported" format was exportable from the standard 
install, so that someone creating a captorial can just export and 
e-mail it to absolutely anyone without a second thought.  Again, by all 
means *also* provide whatever other formats that you think are useful - 
FLV, ISD, VNC, MOV, MJPEG and whatever else you like.  More choice is 
obviously a good thing, and if users want to send something that the 
recipient can edit, they'll have to accept that installing extra stuff 
will be necessary.

> Hmm, looking at this last remark, perhaps you did mean the file
> format captorials.com used to deliver it's content to the client.
> Yes, I chose FLV for this...

Regarding captorials.com, there's a missing link for me in the process 
of making FLV available.  As far as I can tell, my Flash plugin doesn't 
support playing raw FLVs - yet it does play captorials.com content.  So 
I'm guessing you somehow wrapped the FLVs in SWF in some tool I've not 
seen?  Maybe I have this tool and I just don't know it, but the real 
issue is that I can't just e-mail the FLV to my sister.

> I'm gradually coming back to that decision. Currently, I'm
> implementing a highly innovative AJAX-client that doesn't need any
> plugin to play the stream.

Ah, a web client that somehow plays back ISDs from the server instead of 
playing back Flash with a plugin?

> Explorer is so far from supporting them, that I'm really
> thinking of shutting out IE-users from captorials.com (call me crazy,
> yes) and dropping flash-support entirely... Don't know yet.

You're crazy :)

Seriously, though...if it works for IE users now (as Flash), there's no 
harm in continuing to support that.  If they can't use the fancier 
client without installing Firefox, they'll survive as long as 
that "most basic and supported" format is available.

> All such criticism is most welcome here...

That's good to hear :)  My reason for writing is that I've been 
exploring all the available screencasting options lately, with a view 
to 1) being able to send my Linux-newbie sister some captorials very 
much like the ones on your site, and 2) being able to submit better bug 
reports.  (Plus, I'll be honest, 3) being able to submit a bug report 
that "proves" that a bug exists, as far as that's possible; when all 
they can see is a written description that doesn't seem logical, 
developers often appear to assume that person reporting the bug is 
mistaken, not the application.)  None of the solutions I found 
(screenkast, vnc2swf, vncrec+transcode, Istanbul, xvidcap and a couple 
more) did quite what I wanted.  Screenkast did OK, and seems to have 
some activity, and it's best to provide feedback as early as possible.

One other thing; I don't know how difficult this is, but it's got to be 
better to use x11vnc as standard instead of a separate VNC server 
(probably minimising the screenkast window while capturing).  Less 
experienced users will have no idea how to turn that raw-xterm-and-twm 
into something resembling a desktop, and will probably /expect/ 
screenkast to grab what they were looking at before they started 
screenkast up.  Obviously screenkast allows this already, because you 
can connect to any VNC server - I'm just saying I think it should be 
the default.

Now I come to think of it, screenkast would ideally allow a fourth thing 
in addition to the above: make it easy for my sister to send *me* 
screencasts of things that didn't work.

Zak