[IMC-Video] [IMC-Tech] cloning youtube?

[boud]

hi john,

On Thu, 26 Oct 2006, john duda wrote:

> Ok, faced with multiple requests from non-tech people, I'm working on
> a way to embed flash video in the browser for imc content(cue
> objections about flash being nonfree).

john, thanks for your cue. Since i don't want to help put imc
activists in virtual chains, no matter how comfortable that may be (a
bit like a monkey putting his/her hand in a jar full of peanuts and
then not being able to take it out because his/her hand is full of
nice peanuts), i've used a (non-free) search engine to find some free
stuff. i understand that getting lots of peanuts is a Good Thing and
grassroots and all that, but maybe if we remember the problems with
peanuts in jars that have happened in the past, we could together try
to find out how to get free peanuts...

http://www.gnu.org/software/gnash/

Does anyone have experience with this?

Could people starting to support flash at least try out gnash and other
free packages?

i think we could at least try to stick to things compatible with free
flash viewers such as gnash - presumably it's like for other standards - 
by everyone trying to switch to the open standards, the imprisoned
standards will be forced to evolve or be ignored.


> the basic idea would be a script, called periodically, which would
> encode arbitrary video files to .flv format and, when done, generate
> an include file with the appropriate code for a nice in-browser video
> experience(using flowplayer from flowplayer.sf.net).  so it could
> theoretically be usuable, with few modifications, across a wide range
> of imc codebases.  doing it out of the flow of the normal cms stuff
> would mean that encoding time would not be related to upload response
> time(slow enough already!)  there's even going to be a cheeky little
> javascript thing so you could put like <span id="stillencoding">still
> encoding for flash playback!  check back in 10 minutes!</span> in the
> template right before you reference the include file and then the
> include file itself, once it exists, will turn this message off.  the
> include file will also have the code you need to embed the video in
> another webpage, just like youtube does to great effect.
>
> my question is: has anyone already done this work?  i'm using mencoder
> right now(you can pull a version from the debian-multimedia unofficial
> repositories that seems to handle random videos being thrown at it
> better than ffmpeg), but i'd be really excited if someone had more
> experience with tweaking the command line encoder options.
>
> currently, i'm using:
>
> mencoder vftr_acalltomediaarms_hq.avi -o movie5.flv -of lavf \
>  -lavfopts i_certify_that_my_video_stream_does_not_use_b_frames \
>  -oac mp3lame -lameopts abr:br=56 -ovc lavc \
>  -lavcopts vcodec=flv:keyint=50:vbitrate=300:mbd=2:mv0:trell:v4mv:cbp:last_pred=3 \
>  -vop scale=320:240 -srate 22050
> cat movie5.flv | flvtool2 -U stdin movie5.flv


mp3lame sounds a bit dangerous to me - i can't find it in debian anywhere
(even unstable) - does anyone know more?

Hmm, it seems like it's a problem to do with patents:

http://en.wikipedia.org/wiki/Mp3lame
> Legal issues
> 
> LAME, as any MP3 encoder, is claimed to implement some processes
> covered by some patents filled by Fraunhofer.
> 
> LAME developers state that since their code is only released in source
> form, it should only be considered as a description of an MP3 encoder,
> and thus does not infringe any patent by itself when released as
> source code only [2]. At the same time, they advise to obtain a
> patents license [3] before including a compiled version of the encoder
> into a product.


Since software patents exist in the US (and the battle against software
patents in the EU is not over yet, it's going to another phase of 
corporations against citizens), systematic usage of the above 
mencoder method using mp3lame would presumably mean that if a US-based 
server got seized, the authorities could claim patent royalties from us.

Using free software is not just idealism, it can also have practical
consequences...



i tried:
   -oac twolame  -twolameopts br=56

and got: ...
VIDEO CODEC ID: 0
AUDIO CODEC ID: 15000, TAG: 0
Writing header...
[NULL @ 0x86a4660]codec not compatible with flv
Floating point exception


> which does the trick(see
> http://manifestor.org/john/wetube/qt/test.html) for a proof of
> concept) but which is a) slow b) results, at least for a quicktime
> file i threw at it, a really big file, and c) scares me with the b
> frame stuff which makes no sense to me as someone who doesn't deal all
> that much with video stuff.

The b frame stuff just says that mplayer developers have not fully
protected the user from making bad combinations of certain options,
and they found a creative way of avoiding bug reports about an error
they know people are likely to make.


i'd like to know if someone knows how to do this without using mp3lame.

solidarity
boud


> So any advice would be appreciated!
>
> thanks,
> john
>
>
>
>
>
> --
>
> this is where my public key can be found:
> gpg --keyserver pgp.mit.edu --recv-keys 03817826
> Key fingerprint = 6C11 8D70 2ADE EFA9 498D  72CB 77EA 391A 0381 7826
>
>
> _______________________________________________
> imc-tech mailing list
> imc-tech at lists.indymedia.org
> http://lists.indymedia.org/mailman/listinfo/imc-tech
>