Recherche avancée

Sur d’autres sites (7720)

• Revisiting the Belco Alpha-400

  26 août 2010, par Multimedia Mike — General

  Relieved of the primary FATE maintenance duties, I decided to dust off my MIPS-based Belco Alpha-400 and try to get it doing FATE cycles. And just as I was about to get FATE running, I saw that Mans already got his MIPS-based Popcorn Hour device to run FATE. But here are my notes anyway.

  
  
  

  Getting A Prompt
  For my own benefit, I made a PDF to remind me precisely how to get a root prompt on the Alpha-400. The ‘jailbreak’ expression seems a little juvenile to me, but it seems to be in vogue right now.

  alpha-400-jailbreak.pdf

  Toolchain
  When I last tinkered with the Alpha-400, I was trying to build a toolchain that could build binaries to run on the unit’s MIPS chip, to no avail. Sometime last year, MichaelK put together x86_32-hosted toolchains that are able to build mipsel 32-bit binaries for Linux 2.4 and 2.6. The Alpha-400 uses a 2.4 kernel and the corresponding toolchain works famously for building current FFmpeg (--disable-devices is necessary for building).

  FATE Samples
  Next problem : Making the FATE suite available to the Alpha-400. I copied all of the FATE suite samples onto a VFAT-formatted SD card. The filename case is not preserved for all files which confounds me since it is preserved in other cases. I tried formatting the card for ext3 but the Alpha-400 would not mount it, even though /proc/filesystems lists ext3 (supporting an older version of ext3 ?).

  Alternative : Copy all of the FATE samples to the device’s rootfs. Space will be a little tight, though. Then again, there is over 600 MB of space free ; I misread earlier and thought there were only 300 MB free.

  Remote Execution
  To perform FATE cycles on a remote device, it helps to be able to SSH into that remote device. I don’t even want to know how complicated it would be to build OpenSSH for the device. However, the last time I brought up this topic, I learned about a lighter weight SSH replacement called Dropbear. It turns out that Dropbear runs great on this MIPS computer.

  Running FATE Remotely
  I thought all the pieces would be in place to run FATE at this point. However, there is one more issue : Running FATE on a remote system requires that the host and the target are sharing a filesystem somehow. My personal favorite remote filesystem method is sshfs which is supposed to work wherever there is an SSH server. That’s not entirely true, though– sshfs also requires sftp-server to be installed on the server side, a program that Dropbear does not currently provide.

  I’m not even going to think about getting Samba or NFS server software installed on the Alpha-400. According to the unit’s /proc/filesystems file, nfs is a supported filesystem. I hate setting up NFS but may see if I can get that working anyway.

  Residual Weirdness
  The unit comes with the venerable Busybox program (BusyBox v1.4.1 (2007-06-01 20:37:18 CST) multi-call binary) for most of its standard command line utilities. I noticed a quirk where BusyBox’s md5sum gives weird hex characters. This might be a known/fixed issue.

  Another item is that the Alpha-400′s /dev/null file only has rwxr-xr-x per default. This caused trouble when I first tried to scp using Dropbear using a newly-created, unprivileged user.

• Revision 4937 : On prend en compte la nouvelle fonctionnalité de GIS de centrage ...

  7 février 2011, par kent1 — Log

  On prend en compte la nouvelle fonctionnalité de GIS de centrage automatique de l’utilisateur lors de la création de points On vide les request des données géo lors de la suppression d’un point

• The Future of the VP8 Bitstream

  17 juin 2010, par noreply@blogger.com (John Luther) — vp8

  Recently we’ve seen software products such as VLC, FFmpeg, Logitech Vid, Flumotion and Tixeo adopting and using WebM and VP8 (the video codec in WebM) in exciting new ways.

  In addition to software developers, many hardware vendors have committed to shipping VP8-accelerated products based on our current bitstream in 2011 . Devices that use hardware acceleration for video are a very small percentage of overall web traffic today, but they are a rapidly growing segment of the market and our project must be mindful of these vendors’ needs. Given the longer lead times for changes in chipsets, hardware companies implementing the codec today need to be confident that it will be stable and supported as VP8 content proliferates.

  Like every codec, WebM is not immune to change ; the difference in our project is that the improvements are publicly visible, and compatibility and implementation issues can be worked through in an open forum.

  So, to maintain codec stability while also allowing for quality and performance improvements in VP8, we have added an experimental branch to the VP8 source tree. The WebM community can use this unstable branch to propose changes to VP8 that will produce the best video codec possible, but without the constraints of a frozen bitstream. At some point in the future, when the experimental branch proves significantly better than the stable branch, we will create a new version of the codec.

  Teams dedicated to improving WebM are actively investigating and evaluating new techniques, and are committed to do so for the long term. We encourage the WebM community to keep contributing as well. To learn more about the experimental branch and get involved, see our repository layout page.

  Jim Bankoski is Codec Engineering Manager at Google.