Sur d’autres sites (5144)

• Winamp and the March of GUI

  1er juillet 2012, par Multimedia Mike — General, ars technica, gui, user interface, winamp

  Ars Technica recently published a 15-year retrospective on the venerable Winamp multimedia player, prompting bouts of nostalgia and revelations of "Huh ? That program is still around ?" from many readers. I was among them.

  
  
  

  I remember first using Winamp in 1997. I remember finding a few of these new files called MP3s online and being able to play the first 20 seconds using the official Fraunhofer Windows player— full playback required the fully licensed version. Then I searched for another player and came up with Winamp. The first version I ever used was v1.05 in the summer of 1997. I remember checking the website often for updates and trying out every single one. I can’t imagine doing that nowadays— programs need to auto-update themselves (which Winamp probably does now ; I can’t recall the last time I used the program).

  Video Underdog
  The last time Winamp came up on my radar was early in 2003 when a new version came with support for a custom, proprietary multimedia audio/video format called Nullsoft Video (NSV). I remember the timeframe because the date is indicated in the earliest revision of my NSV spec document (back when I was maintaining such docs in a series of plaintext files). This was cobbled together from details I and others in the open source multimedia community sorted out from sample files. It was missing quite a few details, though.

  Then, Winamp founder Justin Frankel — introduced through a colleague on the xine team — emailed me his official NSV format and told me I was free to incorporate details into my document just as long as it wasn’t obvious that I had the official spec. This put me in an obnoxious position of trying to incorporate details which would have been very difficult to reverse engineer without the official doc. I think I coped with the situation by never really getting around to updating my doc in any meaningful way. Then, one day, the official spec was released to the world anyway, and it is now mirrored here at multimedia.cx.

  I don’t think the format ever really caught on in any meaningful way, so not a big deal. (Anytime I say that about a format, I always learn it saw huge adoption is some small but vocal community.)

  What’s Wrong With This Picture ?
  What I really wanted to discuss in this post was the matter of graphical user interfaces and how they have changed in the last 15 years.
  
  I still remember when I first downloaded Winamp v1.05 and tried it on my Windows machine at the time. Indignantly, the first thought I had was, "What makes this program think it’s so special that it’s allowed to violate the user interface conventions put forth by the rest of the desktop ?" All of the Windows programs followed a standard set of user interface patterns and had a consistent look and feel... and then Winamp came along and felt it could violate all those conventions.

  I guess I let the program get away with it because it was either that or only play 20-second clips from the unregistered Fraunhofer player. Though incredibly sterile by comparison, the Fraunhofer player, it should be noted, followed Windows UI guidelines to the letter.

  As the summer of 1997 progressed and more Winamp versions were released, eventually one came out (I think it was v1.6 or so) that supported skins. I was excited because there was a skin that made the program look like a proper Windows program— at least if you used the default Windows color scheme, and had all of your fonts a certain type and size.

  Skins were implemented by packaging together a set of BMP images to overlay on various UI elements. I immediately saw a number of shortcomings with this skinning approach. A big one was UI lock-in. Ironically, if you skin an app and wish to maintain backwards compatibility with the thousands of skins selflessly authored by your vibrant community (seriously, I couldn’t believe how prolific these things were), then you were effectively locked into the primary UI. Forget about adding a new button anywhere.

  Another big problem was resolution-independence. Basing your UI on static bitmaps doesn’t scale well with various resolutions. Winamp had its normal mode and it also had double-sized mode.

  Skins proliferated among many types of programs in the late 1990s. I always treasured this Suck.com (remember them ? that’s a whole other nostalgia trip) essay from April, 2000 entitled Skin Cancer. Still, Winamp was basically the standard, and the best, and I put away my righteous nerd rage and even dug through the vast troves of skins. I remember settling on Swankamp for a good part of 1998, probably due to the neo-swing revival at the time.

  
  
  

  Then again, if Winamp irked me, imagine my reaction when I was first exposed to the Sonique Music Player in 1998 :

  
  
  

  The New UI Order
  Upon reflection, I realize now that I had a really myopic view of what a computer GUI should be. I thought the GUIs were necessarily supposed to follow the WIMP (windows, icons, mouse, pointer) paradigm and couldn’t conceive of anything different. For a long time, I couldn’t envision a useful GUI on a small device (like a phone) because WIMP didn’t fit well on such a small interface (even though I saw various ill-fated attempts to make it work). This thinking seriously crippled me when I was trying to craft a GUI for a custom console media player I was developing as a hobby many years ago.

  I’m looking around at what I have open on my Windows 7 desktop right now. Google Chrome browser, Apple iTunes, Adobe Photoshop Elements, and VMware Player are 4 programs which all seem to have their own skins. Maybe Winamp doesn’t look so out of place these days.

• Trying to use FFMPEG for android. Compiling but still not working

  15 avril 2014, par Austin Mueller

  So to start off... Im trying to use ffmpeg to compile an array of images into a video on Android.

  I have followed a variety of tutorials online and have gotten as far as being able to compile the lib for Android and still have to project run.
  The repo im now using can be found here : https://github.com/Batterii/android-ffmpeg-x264

  I made a couple tweaks to the setttings.sh just to correct ndk location. Besides that, I followed the instructions and it seemed to work flawlessly.

  After that, I converted the "Project" project into an Android stdio library module.
  

  I am not getting any compile errors, nor am I getting any runtime errors, or any other errors that I can detect... Nothing on logcat... But I am definitely not getting any video called out.mp4.
  In an onCreate of a particular activity, I am running this code :

  Videokit vk = new Videokit();
  
  vk.run(new String[]{"ffmpeg", "-r", "1/5", "-i", "%d.jpg", "-c:v", "libx264", "-r", "30", "-pix_fmt", "yuv420p", project.getProjectDirectory() + "/out.mp4"});

  This command is taken from the command line example found here :
  https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images

  Thank you in advance for anyone taking the time to look through this post... I am pretty baffled at this point, as there are no errors I can find and no video...
  Thanks

  ======================================================================

  Update

  Turns out it is not actually compiling correctly... but i have found a few things.
  here is the make file from the Eclipse version of the project

  LOCAL_PATH := $(call my-dir)
  
  
  
  include $(CLEAR_VARS)
  
  LOCAL_MODULE  := videokit
  
  # These need to be in the right order
  
  FFMPEG_LIBS := $(addprefix ffmpeg/, \
  
   libavdevice/libavdevice.a \
  
   libavformat/libavformat.a \
  
   libavfilter/libavfilter.a \
  
   libavcodec/libavcodec.a \
  
   libswscale/libswscale.a \
  
   libavutil/libavutil.a \
  
   libswresample/libswresample.a \
  
   libpostproc/libpostproc.a )
  
  # ffmpeg uses its own deprecated functions liberally, so turn off that annoying noise
  
  LOCAL_CFLAGS += -g -Iffmpeg -Ivideokit -Wno-deprecated-declarations 
  
  LOCAL_LDLIBS += -llog -lz $(FFMPEG_LIBS) x264/libx264.a
  
  LOCAL_SRC_FILES :=  ffmpeg/cmdutils.c ffmpeg/ffmpeg.c videokit/uk_co_halfninja_videokit_Videokit.c
  
  include $(BUILD_SHARED_LIBRARY)

  and here is the make file that gradle is auto-generating for me... thanks to Android Studio...

  LOCAL_PATH := $(call my-dir)
  
  include $(CLEAR_VARS)
  
  
  
  LOCAL_MODULE := videokit
  
  LOCAL_CFLAGS := -g -Isrc/main/jni/ffmpeg -Isrc/main/jni/videokit -Wno-deprecated-declarations
  
  LOCAL_LDLIBS := \
  
      -lffmpeg/libavformat/libavformat.a \
  
      -lffmpeg/libavcodec/libavcodec.a \
  
      -lffmpeg/libswresample/libswresample.a \
  
      -lffmpeg/libavfilter/libavfilter.a \
  
      -lffmpeg/libpostproc/libpostproc.a \
  
      -lffmpeg/libavdevice/libavdevice.a \
  
      -lx264/libx264.a \
  
      -lffmpeg/libavutil/libavutil.a \
  
      -llog \
  
      -lz \
  
      -lffmpeg/libswscale/libswscale.a \
  
  
  
  LOCAL_SRC_FILES := \
  
      Project/Module/src/main/jni/ffmpeg/cmdutils.c \
  
      Project/Module/src/main/jni/ffmpeg/ffmpeg.c \
  
      Project/Module/src/main/jni/videokit/com_t10_project_util_FfmpegHelper.c \
  
  
  
  LOCAL_C_INCLUDES += Project/Module/src/main/jni/ffmpeg/cmdutils.c
  
  LOCAL_C_INCLUDES += Project/Module/src/main/jni/ffmpeg/ffmpeg.c
  
  LOCAL_C_INCLUDES += Project/Module/src/main/jni/videokit/com_t10_project_util_FfmpegHelper.c
  
  LOCAL_C_INCLUDES += Project/Module/src/arm/jni
  
  LOCAL_C_INCLUDES += Project/Module/src/debug/jni
  
  LOCAL_C_INCLUDES += Project/Module/src/armDebug/jni
  
  
  
  include $(BUILD_SHARED_LIBRARY)

  And finally, here is my build.gradle

  apply plugin: 'android'
  
  
  
  android {
  
      compileSdkVersion 19
  
      buildToolsVersion '19.0.1'
  
  
  
      defaultConfig {
  
          minSdkVersion 14
  
          targetSdkVersion 19
  
          versionCode 1
  
          versionName "1.0"
  
  
  
          ndk {
  
              moduleName "videokit"
  
              stl "stlport_shared"
  
              ldLibs "log", "z",
  
                      "ffmpeg/libavdevice/libavdevice.a",
  
                      "ffmpeg/libavformat/libavformat.a",
  
                      "ffmpeg/libavfilter/libavfilter.a",
  
                      "ffmpeg/libavcodec/libavcodec.a",
  
                      "ffmpeg/libswscale/libswscale.a",
  
                      "ffmpeg/libavutil/libavutil.a",
  
                      "ffmpeg/libswresample/libswresample.a",
  
  
  
  
  
                "ffmpeg/libpostproc/libpostproc.a",
  
                  "x264/libx264.a"
  
              cFlags "-g -Isrc/main/jni/ffmpeg -Isrc/main/jni/videokit -Wno-deprecated-declarations"
  
  
  
          }
  
      }
  
  
  
      sourceSets.main {
  
          jniLibs.srcDir 'src/main/libs'
  
          jni.srcDirs = ['src/main/jni/ffmpeg/cmdutils.c',
  
                         'src/main/jni/ffmpeg/ffmpeg.c',
  
                         'src/main/jni/videokit/com_t10_project_util_FfmpegHelper.c']
  
      }
  
  
  
      productFlavors {
  
          x86 {
  
              versionCode Integer.parseInt("6" + defaultConfig.versionCode)
  
              ndk {
  
                  abiFilter "x86"
  
              }
  
          }
  
          mips {
  
              versionCode Integer.parseInt("4" + defaultConfig.versionCode)
  
              ndk {
  
                  abiFilter "mips"
  
              }
  
          }
  
          armv7 {
  
              versionCode Integer.parseInt("2" + defaultConfig.versionCode)
  
              ndk {
  
                  abiFilter "armeabi-v7a"
  
              }
  
          }
  
          arm {
  
              versionCode Integer.parseInt("1" + defaultConfig.versionCode)
  
              ndk {
  
                  abiFilter "armeabi"
  
              }
  
          }
  
          fat
  
      }
  
  
  
      buildTypes {
  
          release {
  
              runProguard false
  
              proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
  
          }
  
      }
  
  }
  
  
  
  dependencies {
  
      compile 'com.android.support:support-v4:19.0.0'
  
      compile fileTree(dir: 'libs', include: ['*.jar', '*.aar'])
  
  }

  As you can see, my build.gradle generates something that is pretty close to the original... but not the same. When i try to run/compile it, gradle spits this out

  Executing tasks: [:Project:assembleArmDebug]
  
  
  
  :Project:compileArmDebugNdkcc1: warning: Project/Module/src/main/jni/ffmpeg/cmdutils.c: not a directory [enabled by default]
  
  cc1: warning: Project/Module/src/main/jni/ffmpeg/ffmpeg.c: not a directory [enabled by default]
  
  cc1: warning: Project/Module/src/main/jni/videokit/com_t10_project_util_FfmpegHelper.c: not a directory [enabled by default]
  
  In file included from Project/Module/src/main/jni/ffmpeg/cmdutils.c:32:0:
  
  Project/Module/src/main/jni/ffmpeg/libavformat/avformat.h:82:32: fatal error: libavcodec/avcodec.h: No such file or directory
  
  compilation terminated.
  
  make: *** [Project/Module/build/ndk/arm/debug/obj/local/armeabi/objs/videokit/Project/Module/src/main/jni/ffmpeg/cmdutils.o] Error 1
  
   FAILED
  
  
  
  FAILURE: Build failed with an exception.
  
  
  
  * What went wrong:
  
  Execution failed for task ':Project:compileArmDebugNdk'.
  
  > com.android.ide.common.internal.LoggedErrorException: Failed to run command:
  
      android-ndk-r9d/ndk-build NDK_PROJECT_PATH=null APP_BUILD_SCRIPT=Project/Module/build/ndk/arm/debug/Android.mk APP_PLATFORM=android-19 NDK_OUT=Project/Module/build/ndk/arm/debug/obj NDK_LIBS_OUT=Project/Module/build/ndk/arm/debug/lib APP_STL=stlport_shared APP_ABI=armeabi
  
    Error Code:
  
      2
  
    Output:
  
      cc1: warning: Project/Module/src/main/jni/ffmpeg/cmdutils.c: not a directory [enabled by default]
  
      cc1: warning: Project/Module/src/main/jni/ffmpeg/ffmpeg.c: not a directory [enabled by default]
  
      cc1: warning: Project/Module/src/main/jni/videokit/com_t10_project_util_FfmpegHelper.c: not a directory [enabled by default]
  
      In file included from Project/Module/src/main/jni/ffmpeg/cmdutils.c:32:0:
  
      Project/Module/src/main/jni/ffmpeg/libavformat/avformat.h:82:32: fatal error: libavcodec/avcodec.h: No such file or directory
  
      compilation terminated.
  
      make: *** [Project/Module/build/ndk/arm/debug/obj/local/armeabi/objs/videokit/Project/Module/src/main/jni/ffmpeg/cmdutils.o] Error 1
  
  
  
  
  
  * Try:
  
  Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
  
  
  
  BUILD FAILED
  
  
  
  Total time: 8.184 secs

  I've been messing around with it for a couple hours now and pretty much every time, i get gradle yelling at me about the fact that it can't find some file. I'm beginning to think that maybe it is because my LOCAL_LDLIBS aren't in the same order as the original...? Im not entirely sure... Does anyone else have any ideas...?

• Why does my Blink based browser play hide and seek ?

  21 janvier 2016, par Caius Jard

  We have a C# tool (that I wrote) that records online broadcasts taking place a custom written (that we wrote) flash app. (There are no DRM or copyright issues here.)

  We’ve coded up a system whereby this tool is installed on a Windows Server 2012 R2 Amazon AWS instance. After we boot the instance, the tool loads, waits for the right time to start recording, launches a browser and passes the command line argument of the URL to access the broadcast. The browser will then load the flash app and the interview audio and video will start arriving at the browser instance on AWS

  By way of a virtual audio cable driver, screen / audio capture directshow filters and ffmpeg a screen recording is taken. The C# tool calls ffmpeg and ffmpeg will record the screen reliably for the entire interview, then the tool shuts the whole thing down

  The problem I’m having is that both Chrome and Electron browser sometimes simply don’t draw themselves on the screen so all ffmpeg ends up recording is a blank desktop and the audio of the broadcast (hence, the browser IS running)

  We found this out when recordings started turning up with X hours of merely recording the windows desktop and the tool’s main window with a countdown timer.

  A screenshotting facility was built into the tool and added to its web control interface, and this way we can test whether the browser is visible - a human looks at the screenshot of every broadcast, just after recording has started (the browser is supposed to be on show by this time)

  We notice that 50% of the time, the browser isn’t drawing itself on screen. By 50% I mean that every other recording that the AWS instance carries out, will be blank : AWS starts, records ok, shuts down. AWS starts again an hour later for a different broadcast, recording is blank, shuts down.. Starts/ok/shutdown. Starts/blank/shutdown. Repeat ad infinitum

  What’s even more strange is that if I run VNCviewer on my dev machine and connect up to an instance that is having a problem, the instant that the VNC connection is up and the remote desktop is showing on my screen, the browser suddenly appears as if nothing was ever wrong. A screenshot from before the VNC connect shows blank desktop, connect VNC, take another screenshot and the browser is there. All through it the audio is fine - the browser connected to the boadcast is fine, for sure

  It’s as though Chrome/Electron thinks "you know what, noone is looking at me so I’m not going to bother drawing myself". No screen saver is set, though the power plan has the setting "turn off the display after 15 minutes".

  Perhaps Chrome/Electron have a test amounts to "if the display is off, don’t draw". I can’t explain the inconsistency though - the recorder launches at least 1 hour before it’s needed, and sits there idle until it’s time to start the browser. You’d hence imagine that the "power off the monitor after 15 mins" setting would reliably have ensured the "monitor" is "off" by the time every recording start comes around

  This behaviour doesn’t happen with any of the other browsers (but unfortunately the app doesn’t and cannot work in them because it uses some weird chrome-only technology/API).

  Can anyone suggest anything to look at to help debug this, or anything I can build into the C# tool to overcome the problem ? Coding it up to connect to itself via VNC for a few seconds after it has launched the browser.. Well that just tastes nasty.

  Naturally, as soon as I connect to the machine via VNC (rather than RDP - RDP isn’t usable because the recording context is in a logged on session for a particular user) the problem goes away, which makes it frustratingly hard to debug.