Technology Temple

How do we run it from the com­mand line? I am fol­low­ing the “README” file and cre­ated a yt-args text file using the dumper script. I man­u­ally down­loaded watch_as3-vfl169211.swf.

All I get is a brief win­dow cre­ation then exit and tons of NOT_IMPLEMENTED prints on stdout.

I tried mozilla plu­gin. It crashed my sys­tem when I tried view youtube video. All I saw was some gray rec­tan­gle in right bot­tom cor­ner of the screen. I’m on Lucid with ati 3200hd and oss driver

” that should be fully sup ported by Gnash.“
Can we install Gnash and Lightspark along­side? I didn’t think so! Is the choos­ing of one or another auto­mat­i­cal? Or is it a planned feature?

Please report this bug on launch­pad detail­ing your sys­tem con­fig­u­ra­tion (CPU/video card/video driver)

I would be inter­ested in the posi­tion­ing of Light­park to Gnash and Swfdec. Why have you decided to cre­ate another free flash player instead of con­tribut­ing to one of the exist­ing play­ers? Are there some tech­ni­cal reasons?

Btw. great to have a free flash player with youtube support!

run­ning it like
lightspark –p yt-args watch_as3-vfl169211.swf
should be enough, if not please report the bug on launch­pad. Which video have you passed to the dumper script?

I’ve taken a look around gnash code and it’s not the kind of code where it’s easy to inte­grate mod­ern func­tion­al­ity. When work­ing on par­al­lel code every­thing should be designed from the begin­ning to be thread safe. More­over, lightspark has been designed to be effi­cient on mod­ern, main­stream architecture.

Look­ing in launch­pad I can only see the 0.4.0 release. Is the 0.4.1 release on launch­pad or elsewhere?

I’ve added the 0.4.1 tar­ball. Thanks for the report.

I try to com­pile this on Fedora 13 and I stall here, because of the DSO link­ing feature.

[ 94%] Built tar­get spark
Link­ing CXX exe­cutable lightspark
/usr/bin/ld: /usr/lib64/llvm/libLLVMSystem.a(DynamicLibrary.o): unde­fined ref­er­ence to sym­bol ‘dlsym@@GLIBC_2.2.5′
/usr/bin/ld: note: ‘dlsym@@GLIBC_2.2.5′ is defined in DSO /usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/libdl.so so try adding it to the linker com­mand line
/usr/lib/gcc/x86_64-redhat-linux/4.4.4/../../../../lib64/libdl.so: could not read sym­bols: Invalid oper­a­tion
collect2: ld devolvió el estado de sal­ida 1
make[2]: *** [lightspark] Error 1
make[1]: *** [CMakeFiles/lightspark.dir/all] Error 2
make: *** [all] Error 2

How can I fix this? Any hint?

I’m see­ing the same issues build­ing in F-14 regard­ing the issues seen with F-13 below.

Also is there any plans to add sup­port for gstreamer for the under­ly­ing media side of things? This would allow easy sup­port of new codecs (such as WebM that adobe has said it will sup­port in Flash) as well as the use of things like HW accel­er­a­tion on dif­fer­ent plat­forms such as ARM etc where there’s quite a bit of sup­port for gstreamer HW acceleration.

Not yet, but I’m think­ing about a way to fall back on gnash.

I’ve cho­sen FFm­peg for its light­weight. Sup­port for VP8 and Vor­bis (the streams con­tained in WebM) is guar­an­teed by FFm­peg. FFm­peg also includes sup­port for libVa which should in the future wrap all the var­i­ous HW decod­ing fea­tures. More­over, I don’t like the idea of main­tain­ing more than a back­end, and FFm­peg has proven to be pretty good per­for­mance wise. I will of course wel­come any con­tri­bu­tions and per­for­mance test with GStreamer.

I’ve received sev­eral report of build prob­lems on Fedora. They are related to some weird dynamic load­ing con­fig­u­ra­tion I have no expe­ri­ence with. I’m hop­ing to get some feed­back upstream.

The prob­lems with FFm­peg is that it will never be pack­aged in Fedora and sim­i­lar dis­tros due to the use of var­i­ous codes. It also doesn’t really have a sta­ble api which I think is pos­si­bly part of the issue with com­pil­ing within fedora. I don’t think things like the Broad­com BCM70012 chipset are sup­ported through libVa at the moment and a lot of the ARM chipsets (see Nokia n900 for exam­ple) use a gstreamer spe­cific inter­face to the DSP.

May I sug­gest to read this post about a sim­i­lar prob­lem with a fix that could help you?
http://www.gossamer-threads.com/lists/linux/ker...

Here’s a fix for this par­tic­u­lar bug inspired by the link I pro­vided :
In CMakeList.txt
@@ –80, 1 +80,1 @@IF(COMPILE_LIGHTSPARK OR COMPILE_TIGHTSPARK)
ADD_LIBRARY(spark STATIC ${LIBSPARK_SOURCES})
TARGET_LINK_LIBRARIES(spark ${lib_pthread} ${lib_glew} ${EXTRA_LIBS_LIBRARIES} ${ZLIB_LIBRARIES} ${LLVM_LIBS_CORE} ${LLVM_LIBS_JIT}
– ${SDL_LIBRARY} ${CURL_LIBRARIES})
+ ${SDL_LIBRARY} ${CURL_LIBRARIES} –ldl)

—
How­ever, I’m not an expert in prog, so it may not be the real prob­lem and I may be wrong in how to point where the fix goes. I’m just try­ing to help. With this fix, I get the same error as pre­vi­ously encoun­tered when I tried to com­pile two weeks ago :

Link­ing CXX exe­cutable lightspark
/usr/bin/ld: libspark.a(geometry.cpp.o): unde­fined ref­er­ence to sym­bol ‘gluTessProp­erty’
/usr/bin/ld: note: ‘gluTessProp­erty’ is defined in DSO /usr/lib64/libGLU.so.1 so try adding it to the linker com­mand line
/usr/lib64/libGLU.so.1: could not read sym­bols: Invalid oper­a­tion
collect2: ld returned 1 exit sta­tus
make[2]: *** [lightspark] Error 1
make[1]: *** [CMakeFiles/lightspark.dir/all] Error 2
make: *** [all] Error 2

I fixed the prob­lem with libGLU and another one that appeared after that about librt.so :
(for libGLU) In CMakeList.txt
@@ –51,1 +51,1 @@FIND_LIBRARY(lib_pthread pthread REQUIRED)
FIND_LIBRARY(lib_glew GLEW REQUIRED)
+FIND_LIBRARY(lib_glu GLU REQUIRED)

(for librt) In CMakeList.txt where the fix for dynamic library was inserted by my pre­vi­ous fix
@@ –80, 1 +80,1 @@IF(COMPILE_LIGHTSPARK OR COMPILE_TIGHTSPARK)
ADD_LIBRARY(spark STATIC ${LIBSPARK_SOURCES})
TARGET_LINK_LIBRARIES(spark ${lib_pthread} ${lib_glew} ${EXTRA_LIBS_LIBRARIES} ${ZLIB_LIBRARIES} ${LLVM_LIBS_CORE} ${LLVM_LIBS_JIT}
– ${SDL_LIBRARY} ${CURL_LIBRARIES} –ldl)
+ ${SDL_LIBRARY} ${CURL_LIBRARIES} –ldl –lrt)

—
In other words, all the fixes con­sist in specif­i­cally telling to link to librt and libdl with the options –ldl and –lrt, and find­ing where the libGLU is located with FIND_LIBRARY(lib_glu GLU REQUIRED) as you do for libGLEW

I just dis­cov­ered that a bug in launch­pad had been filled and that details about a fix for Fedora (which are mostly the same thing that I pro­posed below) :
https://bugs.launchpad.net/lightspark/+bug/592730

–ldl –lGLU –lrt have to be appended :
@@ –80, 1 +80,1 @@IF(COMPILE_LIGHTSPARK OR COMPILE_TIGHTSPARK)
ADD_LIBRARY(spark STATIC ${LIBSPARK_SOURCES})
TARGET_LINK_LIBRARIES(spark ${lib_pthread} ${lib_glew} ${EXTRA_LIBS_LIBRARIES} ${ZLIB_LIBRARIES} ${LLVM_LIBS_CORE} ${LLVM_LIBS_JIT}
– ${SDL_LIBRARY} ${CURL_LIBRARIES})
+ ${SDL_LIBRARY} ${CURL_LIBRARIES} –ldl –lrt –lGLU)