Page 14 of 58 [868 Posts]   Goto page: Previous 1, 2, 3, ..., 12, 13, 14, 15, 16, ..., 56, 57, 58 Next
Author Message
goingnuts
PostPosted: Sat 07 Jul 2012, 17:25    Post subject:

jamesbond wrote:

ffmpeg 0.6.3 in Fatdog 521 works - it can fetch and display the tiny video from URLs produced by your script.

I can confirm this works in P412 too - haven't tested audio but video works. ffmpeg 0.6.3 builds fine with uclibc. Just parsing
Code:
 LD="/usr/i386-linux-uclibc/bin/i386-uclibc-ld" CC="/usr/i386-linux-uclibc/bin/i386-uclibc-gcc" CFLAGS="-pipe -Os -mtune=i386 -D_BSD_SOURCE -D_GNU_SOURCE" LDFLAGS="-static -Wl,--gc-sections,--sort-common,-s" ./configure
ends up in a 5880K static bin but that might me reduced by fine tuning to what is needed for this purpose.
Code:
 ffmpeg  -i "rtsp://v3.cache5.c.youtube.com/CjgLENy73wIaLwlbFbiQveu_nRMYDSANFEIJbXYtZ29vZ2xlSARSB3Jlc3VsdHNg4diBq4H-qPxPDA==/0/0/0/video.3gp" test.avi

created video that played fine with mplayer...although you have to wait for the stream to end and after that play the created video in mplayer...

Any chance to get access to a bigger version of the videos...they are hard to view... Smile
jamesbond
PostPosted: Sat 07 Jul 2012, 05:53    Post subject:

technosaurus wrote:
I could make a lightweight youtube browser, but can't find a working mplayer/vlc/ffplay/gxine... anyone know what version of any (if any) works on Google rtsp 1.0 streams?

ffmpeg 0.6.3 in Fatdog 521 works - it can fetch and display the tiny video from URLs produced by your script. It is configured like this:
Code:
--prefix=/usr --libdir=/usr/lib64 --enable-postproc --enable-gpl --enable-nonfree --enable-version3 --enable-shared --enable-libfaac --enable-libx264 --enable-x11grab --enable-libxvid --enable-libopencore-amrwb --enable-libopencore-amrnb --enable-libvorbis --enable-libtheora --enable-libmp3lame --enable-runtime-cpudetect --enable-pthreads --enable-swscale --extra-ldflags='--as-needed -L/usr/X11R7/lib' --enable-libopenjpeg --enable-libvpx --disable-debug

I noticed that the videos are contained in 3gp and uses h263 for video and amr for audio.
technosaurus
PostPosted: Sat 07 Jul 2012, 02:25    Post subject:

today's puzzle:
I figured out this:
Code:
#!/bin/ash
busybox wget -O - -U firefox "http://m.youtube.com/results?gl=US&client=mv-google&hl=en&q=$@&submit=Search" | awk '
/^<a href=\"rtsp/{printf "%s\t%s\t", $2, $5}
/^<a access/{$1="";$2="";$3="";print "Title=\"" $0 "\"" }'
#incomplete until I find a compatible rtsp streamer

...gives me the rtsp streaming url, screenshot and description of youtube videos matching $@ (args are passed to search and results parsed)
I could make a lightweight youtube browser, but can't find a working mplayer/vlc/ffplay/gxine... anyone know what version of any (if any) works on Google rtsp 1.0 streams?
goingnuts
PostPosted: Sun 01 Jul 2012, 10:51    Post subject:

Removed mplayer build from previous post.
New build MPlayer-1.0pre7_static_010712.tar.gz:
* Size reduced to 4798K (2081K upx)
* Included video via fbdev
* OSD-menu works (ex. mplayer -menu -subfont-text-scale 3 movie_file2play)
* Subtitles (ex. mplayer -sub subtitle_file movie_file2play)
* Sound works with dvd-play (ex. mplayer -alang en -slang da dvd://1)
* Shipped with some of the needed auxilary config-files

Code:
Available video output drivers:
        xv      X11/Xv
        x11     X11 ( XImage/Shm )
        xover   General X11 driver for overlay capable video output drivers
        sdl     SDL YUV/RGB/BGR renderer (SDL v1.1.7+ only!)
        fbdev   Framebuffer Device
        fbdev2  Framebuffer Device
        vesa    VESA VBE 2.0 video output
        null    Null video output
        mpegpes Mpeg-PES file
        yuv4mpeg        yuv4mpeg output for mjpegtools
        tga     Targa output
        pnm     PPM/PGM/PGMYUV file
        md5sum  md5sum of each frame

Available audio output drivers:
        mpegpes Mpeg-PES audio output
        oss     OSS/ioctl audio output
        sdl     SDLlib audio output
        null    Null audio output
        pcm     RAW PCM/WAVE file writer audio output

Mplayer configured with:
Code:
CC="diet gcc -nostdinc -nostdlib" CFLAGS="-Os -march=i386 -mtune=i386 -nostdinc -nostdlib -DTRANS_CLIENT -trigraphs" LDFLAGS=" -Wl,--gc-sections,--sort-common,-s " ./configure  --disable-gcc-checking --prefix=/opt/diet --confdir=/etc/mplayer --with-x11incdir=/opt/diet/include --with-x11libdir=/opt/diet/lib --with-extraincdir=/opt/diet/include --with-extralibdir=/opt/diet/lib --with-sdl-config=/opt/diet/bin/sdl-config   --with-freetype-config=/opt/diet/bin/freetype-config --disable-dshow --disable-real --disable-mmx2 --disable-mmx --disable-3dnow --disable-3dnowex --enable-static --disable-vidix --disable-live --enable-menu --disable-win32 --disable-dynamic-plugins
Ibidem
PostPosted: Sat 30 Jun 2012, 01:05    Post subject:

technosaurus wrote:
The issues aren't necessarily with musl, but I am having to add a few includes here and there or add -D_GNU_SOURCE or similar, but I am just going to add those to my wrapper script and maybe every once in a while add a symlink for a missing include like io.h (but most are kernel headers that just got missed or were overwritten by glibc)

After I have done a run through all of the useful C libraries on this toolchain without threads and locales, I will do a try with a native toolchain and try them out. (I just wanted to minimize my patching on the first run - its less overwhelming that way)

*question???
What is the best way to get a disk image onto a really low resource computer using minimal ram/cpu, but also not really long or complicated. I was thinking of piping an xz compressed tarball of a filesystem image through dd. However I am hesitant to do it that way due to the possibility of broken pipes (the plumbing is not always in good in these old beasts)

finally remembered a couple things.
1- native binutils + gcc usually works better, as long as you kill gcc's "fixed" (automatically broken) includes. Be sure to prevent fixinc.sh from doing anything when you build gcc, or you will be wondering "what on earth broke that?"
also, configure binutils & gcc with --host=i?86-*-linux --target=i?86-*-linux - autodetect is broken and figures __ELF__ means glibc1 unless __GLIBC__ is 2.
glibc2 toolchains will work, but glibc1 only builds static binaries and they're slightly broken.
if you want C++, the libstdc++ config for linux-gnu or whatever they name it there must be replaced with generic (iirc, cd libstdc*/config; mv linux-gnu linux-glibc-only; ln -s linux-gnu generic -- I may be misremembering names, though)
2- why use an fs image, if you can boot linux? it's lighter to tar the root tree, untar, then chroot & configure. In fact, that's exactly how many installers work.
in many places, a disk image will have the wrong boot information.
you can split it up by tarring /bin /etc /usr/bin /usr/share and so on separately.
goingnuts
PostPosted: Sun 24 Jun 2012, 08:31    Post subject:

Finally got xine-lib build and also gxine...but seems that xine-lib wont load plugins statically - so for now it seems as a no-go...

Mplayer-1.1 builds fine with normal glibc and dynamic linking. Video fails when linked static though. Did not manage to build it with uclibc/tinyX11.

But managed to "reproduce" a diet libc build of MPlayer 1.0pre7 with gcc 4.2.2. Ended up in 5847K (1927K upx) for mplayer and 4712K (1387K upx) for mencoder.

It plays mp3, avi, mpeg and dvd-isoimage/dvd in drive (dvd without sound Question ) with the standard Xvesa in P412 but unfortunatly the static build (uclibc/tinyX11) Xvesa has some problems so I have to dig into that (plays ok fullscreen Xvesa but not in windowed mode).

I expect to be able to decrease size or add/remove filters/drivers/features if I manage to transfer the build to uclibc/tinyX11 as the diet-X11-libs are quite large.

Update 010612: Removed the attached bin view later post
technosaurus
PostPosted: Mon 18 Jun 2012, 14:08    Post subject:

The patch was against v1.1 ... I found it on ftp before the official release announcement Smile and iirc the only options I passed were for enabling the GUI (i pass all of my CFLAGS in my gcc wrapper) the configure script worked fine, except my non-standard jpeg lib was missing encoding capability and I ran out of time to rebuild.
goingnuts
PostPosted: Mon 18 Jun 2012, 13:15    Post subject:

Ibidem:Thanks!
technosaurus:A new mplayer (MPlayer 1.1) out - I will try to work a little with that one - although the configure options are more than 200 lines of possibilities - might get lost just trying to configure that beast!

Would be nice if there was a simple standalone avi-player and another simple mpg-player ala minimp3-player but I havent been able to track one...
Not sure if xine-lib can be build static at all?
technosaurus
PostPosted: Sun 17 Jun 2012, 23:03    Post subject:

goingnuts wrote:
Thanks for the patch. I am still not able to build a static mplayer - that is: I can build it but it only shows a 2 cm broad band with psychedelic colors in the top of my screen when playing...
There is gxine-0.2.1 as alternative - but I never managed to do a static xinelib that works.
Found a third way - a pre xine lib - but cant find my notes or remember the name. I think it was in one of the first puppys or maybe in a pre-puppy thing...
Would be nice to have a decent videoplayer....
Update: the name was xanim: http://xanim.polter.net/
Although it compiles I haven't been able to play anything with it...
sorry about that, the build takes a long time on my box and my cutdown static libraries were missing some encoding type symbols (it saves quite a bit to disable things like image output & compression and only read/decompress... but that was really leftovers from an experimentation to find out if it would be feasible to use a small shared lib for read/decode and static for write/encoding). I also found that there is not a large difference between tinyx11 and current if you simply remove the larger locales (just put a full version in a separate NLS pack.)
I'll take a look at gxine to see how hard it would be to patch a recent build, but iirc xanim supported few formats.
Ibidem
PostPosted: Sun 17 Jun 2012, 22:10    Post subject:

Ibidem wrote:
I've dug up the nroff patch. Not bothering to attach the original, since it's hopelessly ancient...

And yes, it does have bad formatting.

Oops...it doesn't have nroff.c

It took a couple small changes to get it going with bb current (_BB_* ->BB_*, and usage is now in a comment within the applet).

If you need an older BB, the nroff.c here should still work.
Other than build fixes it's the same code.
goingnuts
PostPosted: Tue 12 Jun 2012, 11:21    Post subject:

Found a small net traffic sniffer: dietsniff-0.4
Amazing to view what traffic goes behind the scene...
goingnuts
PostPosted: Tue 12 Jun 2012, 00:58    Post subject:

Thanks for the patch. I am still not able to build a static mplayer - that is: I can build it but it only shows a 2 cm broad band with psychedelic colors in the top of my screen when playing...
There is gxine-0.2.1 as alternative - but I never managed to do a static xinelib that works.
Found a third way - a pre xine lib - but cant find my notes or remember the name. I think it was in one of the first puppys or maybe in a pre-puppy thing...
Would be nice to have a decent videoplayer....
Update: the name was xanim: http://xanim.polter.net/
Although it compiles I haven't been able to play anything with it...
technosaurus
PostPosted: Sun 10 Jun 2012, 23:55    Post subject:

here is a patch for mplayer - they seem to have broken the gtk1 gui a while back
technosaurus
PostPosted: Sat 09 Jun 2012, 11:22    Post subject:

Ibidem wrote:
If apps are trying g++, that's because they look for a C++ compiler.
The quickest stop to that business is CXX=false CC=musl-gcc ./configure
(and by the way, would CFLAGS=-UUSE_GMODULE help for gdk-pixbuf?)
Threads should be safe with musl--unless you use a kernel that needs linuxthreads (Linux 2.4.x)
Also, musl supports utf8 natively. This can enlarge binaries a little, but not much.
Also, what sort of issues are you having? musl-gcc currently (0.9.x) only changes the spec file for gcc, so it should be 99% compatible.
CPP is the preprocessor (the thing that handles all of the macros/includes/etc...) - in a gcc tool chain usually this is just gcc -E, but in order to force it to look in my musl toolchain and not the standard directories I tell it to use my make shift wrapper built on the musl wrapper (just a script named gcc that calls gcc-real with appropriate defines and flags, yes I renamed gcc and called the wrapper gcc to save a helluvalotta editing) that prevents most of these broken scripts from doing the wrong thing. The issues aren't necessarily with musl, but I am having to add a few includes here and there or add -D_GNU_SOURCE or similar, but I am just going to add those to my wrapper script and maybe every once in a while add a symlink for a missing include like io.h (but most are kernel headers that just got missed or were overwritten by glibc)

After I have done a run through all of the useful C libraries on this toolchain without threads and locales, I will do a try with a native toolchain and try them out. (I just wanted to minimize my patching on the first run - its less overwhelming that way)

*question???
What is the best way to get a disk image onto a really low resource computer using minimal ram/cpu, but also not really long or complicated. I was thinking of piping an xz compressed tarball of a filesystem image through dd. However I am hesitant to do it that way due to the possibility of broken pipes (the plumbing is not always in good in these old beasts)
Ibidem
PostPosted: Sat 09 Jun 2012, 01:37    Post subject:

technosaurus wrote:
doing a static toolchain, you find a lot of bugs that go unseen otherwise... I am just trying to narrow down the issues to the appropriate place - usually it is autoconf
for gdk-pixbuf --disable-modules _should_ undef, not #define USE_GMODULE 1
(removed support for libtiff while I was at it - its just larger than it is useful)
I am trying to set up things as much as possible to allow people to use the toolchain without having to learn the intricacies of gcc ( I'm adding appropriate flags in a wrapper script - the included one has a couple of issues that require constant patching of makefiles ... sometimes libtool or autotools ignore CC=musl-gcc and CPP="musl-gcc -E" amongst other things and I figured I may as well hard code in all of the safe optimizations and necessary defines while I was at it)

I have also patched tinyX11 to some extent, but if you have your patched sources still, it would help (right now I have threads and NLS disabled and minimal utf8 in order to build - it seems that the sources from xfree86-4.8 work fine

If apps are trying g++, that's because they look for a C++ compiler.
The quickest stop to that business is CXX=false CC=musl-gcc ./configure
(and by the way, would CFLAGS=-UUSE_GMODULE help for gdk-pixbuf?)
Threads should be safe with musl--unless you use a kernel that needs linuxthreads (Linux 2.4.x)
Also, musl supports utf8 natively. This can enlarge binaries a little, but not much.
Also, what sort of issues are you having? musl-gcc currently (0.9.x) only changes the spec file for gcc, so it should be 99% compatible.
Display posts from previous:   Sort by:   
Page 14 of 58 [868 Posts]   Goto page: Previous 1, 2, 3, ..., 12, 13, 14, 15, 16, ..., 56, 57, 58 Next

Powered by phpBB © 2001, 2005 phpBB Group