Recherche avancée

Sur d’autres sites (7874)

• 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.

• Problem with xampp, some other program you use ? [closed]

  4 avril 2024, par user13449797

  I have been using xampp for several years, but recently I have become more and more bothered by using this program.

  


  sometimes there is a problem with starting MYSQL services. Sometimes solution with helps
text
I don't understand why this problem hasn't been solved yet and what exactly is the problem that sometimes it stops working on its own.

  


  Maybe you have any better alternatives to Windows 11 ?

  


• Unable to stream video file from MediaMTX media server to browser via WebRTC

  8 juin 2024, par thegreatjedi

  I took over a repository at work. It's a working demo comprising a web server which receives video and camera feeds from a media server (built from the rtsp-simple-server Docker image) via a RTSP relay server and streams the feeds to the client, all deployed via Docker Compose.

  


  I'm trying to switch over to use WebRTC instead. rtsp-simple-server has upgraded into MediaMTX since the time the demo was created 2 years ago. This is the relevant section of the updated Docker Compose configuration :

  


    media-server:
    image: bluenviron/mediamtx:latest-ffmpeg
    expose:
      - 8889
    init: true
    ports:
      - 8889:8889
    restart: unless-stopped
    volumes:
      - type: bind
        source: ./demo/vids
        target: /vids
      - type: bind
        source: ./demo/mediamtx.yml
        target: /mediamtx.yml


  


  Relevant part of the MediaMTX custom configuration in mediamtx.yml :

  


  ###############################################
# Path settings

# Settings in "paths" are applied to specific paths, and the map key
# is the name of the path.
# Any setting in "pathDefaults" can be overridden here.
# It's possible to use regular expressions by using a tilde as prefix,
# for example "~^(test1|test2)$" will match both "test1" and "test2",
# for example "~^prefix" will match all paths that start with "prefix".
paths:
  # example:
  # my_camera:
  #   source: rtsp://my_camera
  ~^demo\d+$:
    runOnDemand: ffmpeg -re -stream_loop -1 -i /vids/$MTX_PATH.mp4 -c:v libvpx -b:v 0 -crf 18 -qmin 18 -qmax 18 -f webm http://localhost:8889/$MTX_PATH/whip

  # Settings under path "all_others" are applied to all paths that
  # do not match another entry.
  all_others:


  


  I've absolutely no experience with WebRTC. This is my first time hearing of this protocol, let alone working with it. From what I understand, I need to convert my demo mp4 videos (which were successfully streaming via RTSP in the previous implementation) to a compatible video codec, so I've opted for VP8.

  


  Before trying to stream the videos into my web server, I tested the stream directly in the browser (tried with both the latest versions of Chrome and Edge). I went to http://localhost:8889/demo0 (which should convert demo0.mp4 to VP8 and then stream it over WebRTC). The video player loaded in the browser but no video data was received and nothing played. After several seconds, the screen displayed "Error : bad status code 400, retrying in some seconds". In the browser console, it showed :

  


  Failed to load resource : the server responded with a status of 400 (Bad Request)

  


  Inside the MediaMTX container's runtime logs, this is what's displayed :

  


  2024-04-02 14:53:08 ffmpeg version 6.1.1 Copyright (c) 2000-2023 the FFmpeg developers
2024-04-02 14:53:08   built with gcc 13.2.1 (Alpine 13.2.1_git20231014) 20231014
2024-04-02 14:53:08   configuration: --prefix=/usr --disable-librtmp --disable-lzma --disable-static --disable-stripping --enable-avfilter --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libdrm --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-libmp3lame --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librist --enable-libsoxr --enable-libsrt --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-lto=auto --enable-lv2 --enable-openssl --enable-pic --enable-postproc --enable-pthreads --enable-shared --enable-vaapi --enable-vdpau --enable-version3 --enable-vulkan --optflags=-O3 --enable-libjxl --enable-libsvtav1 --enable-libvpl
2024-04-02 14:53:08   libavutil      58. 29.100 / 58. 29.100
2024-04-02 14:53:08   libavcodec     60. 31.102 / 60. 31.102
2024-04-02 14:53:08   libavformat    60. 16.100 / 60. 16.100
2024-04-02 14:53:08   libavdevice    60.  3.100 / 60.  3.100
2024-04-02 14:53:08   libavfilter     9. 12.100 /  9. 12.100
2024-04-02 14:53:08   libswscale      7.  5.100 /  7.  5.100
2024-04-02 14:53:08   libswresample   5.  0.100 /  5.  0.100
2024-04-02 14:53:08   libpostproc    57.  3.100 / 57.  3.100
2024-04-02 14:53:08 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/vids/demo0.mp4':
2024-04-02 14:53:08   Metadata:
2024-04-02 14:53:08     major_brand     : isom
2024-04-02 14:53:08     minor_version   : 512
2024-04-02 14:53:08     compatible_brands: isomiso2mp41
2024-04-02 14:53:08     encoder         : Lavf58.76.100
2024-04-02 14:53:08   Duration: 00:00:03.47, start: 0.000000, bitrate: 1675 kb/s
2024-04-02 14:53:08   Stream #0:0[0x1](und): Video: mpeg1video (mp4v / 0x7634706D), yuv420p(tv, progressive), 640x360 [SAR 1:1 DAR 16:9], 104857 kb/s, 30 fps, 30 tbr, 90k tbn (default)
2024-04-02 14:53:08     Metadata:
2024-04-02 14:53:08       handler_name    : VideoHandler
2024-04-02 14:53:08       vendor_id       : [0][0][0][0]
2024-04-02 14:53:08     Side data:
2024-04-02 14:53:08       cpb: bitrate max/min/avg: 0/0/0 buffer size: 49152 vbv_delay: N/A
2024-04-02 14:53:08 Stream mapping:
2024-04-02 14:53:08   Stream #0:0 -> #0:0 (mpeg1video (native) -> vp8 (libvpx))
2024-04-02 14:53:08 Press [q] to stop, [?] for help
2024-04-02 14:53:08 [libvpx @ 0x7faa8591b8c0] v1.13.1
2024-04-02 14:53:08 [libvpx @ 0x7faa8591b8c0] Bitrate not specified for constrained quality mode, using default of 256kbit/sec
2024-04-02 14:53:08 Output #0, webm, to 'http://localhost:8889/demo0/whip':
2024-04-02 14:53:08   Metadata:
2024-04-02 14:53:08     major_brand     : isom
2024-04-02 14:53:08     minor_version   : 512
2024-04-02 14:53:08     compatible_brands: isomiso2mp41
2024-04-02 14:53:08     encoder         : Lavf60.16.100
2024-04-02 14:53:08   Stream #0:0(und): Video: vp8, yuv420p(tv, progressive), 640x360 [SAR 1:1 DAR 16:9], q=2-31, 256 kb/s, 30 fps, 1k tbn (default)
2024-04-02 14:53:08     Metadata:
2024-04-02 14:53:08       handler_name    : VideoHandler
2024-04-02 14:53:08       vendor_id       : [0][0][0][0]
2024-04-02 14:53:08       encoder         : Lavc60.31.102 libvpx
2024-04-02 14:53:08     Side data:
2024-04-02 14:53:08       cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
2024-04-02 14:53:18 2024/04/02 06:53:18 INF [path demo0] runOnDemand command stopped: timed out
2024-04-02 14:53:18 2024/04/02 06:53:18 INF [WebRTC] [session 0f460c76] closed: source of path 'demo0' has timed out
[out#0/webm @ 0x7faa859487c0] video:272kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.042856%
2024-04-02 14:53:18 frame=  315 fps= 32 q=18.0 Lsize=     275kB time=00:00:10.46 bitrate= 215.1kbits/s speed=1.05x    
2024-04-02 14:53:18 Exiting normally, received signal 2.


  


  I'm not sure what this is supposed to mean ? Why isn't the server able to stream this 3-second, 709kb video even once ? The browser connected to the server and the URL successfully, but no data was being transferred.

  


  Just in case, I decided to manually convert all of my mp4 files to webm using ffmpeg, and verified with Window's media player that the webm videos work. Then, I modified MediaMTX's configuration to stream the webm videos directly :

  


  paths:
  # example:
  # my_camera:
  #   source: rtsp://my_camera
  ~^demo\d+$:
    runOnDemand: ffmpeg -re -stream_loop -1 -i /vids/$MTX_PATH.webm -c copy -f webm http://localhost:8889/$MTX_PATH/whip


  


  However, the error persists :

  


  2024-04-02 15:03:58 ffmpeg version 6.1.1 Copyright (c) 2000-2023 the FFmpeg developers
2024-04-02 15:03:58   built with gcc 13.2.1 (Alpine 13.2.1_git20231014) 20231014
2024-04-02 15:03:58   configuration: --prefix=/usr --disable-librtmp --disable-lzma --disable-static --disable-stripping --enable-avfilter --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libdrm --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-libmp3lame --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librist --enable-libsoxr --enable-libsrt --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-lto=auto --enable-lv2 --enable-openssl --enable-pic --enable-postproc --enable-pthreads --enable-shared --enable-vaapi --enable-vdpau --enable-version3 --enable-vulkan --optflags=-O3 --enable-libjxl --enable-libsvtav1 --enable-libvpl
2024-04-02 15:03:58   libavutil      58. 29.100 / 58. 29.100
2024-04-02 15:03:58   libavcodec     60. 31.102 / 60. 31.102
2024-04-02 15:03:58   libavformat    60. 16.100 / 60. 16.100
2024-04-02 15:03:58   libavdevice    60.  3.100 / 60.  3.100
2024-04-02 15:03:58   libavfilter     9. 12.100 /  9. 12.100
2024-04-02 15:03:58   libswscale      7.  5.100 /  7.  5.100
2024-04-02 15:03:58   libswresample   5.  0.100 /  5.  0.100
2024-04-02 15:03:58   libpostproc    57.  3.100 / 57.  3.100
2024-04-02 15:03:58 Input #0, matroska,webm, from '/vids/demo0.webm':
2024-04-02 15:03:58   Metadata:
2024-04-02 15:03:58     COMPATIBLE_BRANDS: isomiso2mp41
2024-04-02 15:03:58     MAJOR_BRAND     : isom
2024-04-02 15:03:58     MINOR_VERSION   : 512
2024-04-02 15:03:58     ENCODER         : Lavf60.16.100
2024-04-02 15:03:58   Duration: 00:00:03.47, start: 0.000000, bitrate: 217 kb/s
2024-04-02 15:03:58   Stream #0:0: Video: vp8, yuv420p(tv, progressive), 640x360, SAR 1:1 DAR 16:9, 30 fps, 30 tbr, 1k tbn (default)
2024-04-02 15:03:58     Metadata:
2024-04-02 15:03:58       HANDLER_NAME    : VideoHandler
2024-04-02 15:03:58       VENDOR_ID       : [0][0][0][0]
2024-04-02 15:03:58       ENCODER         : Lavc60.31.102 libvpx
2024-04-02 15:03:58       DURATION        : 00:00:03.466000000
2024-04-02 15:03:58 Output #0, webm, to 'http://localhost:8889/demo0/whip':
2024-04-02 15:03:58   Metadata:
2024-04-02 15:03:58     COMPATIBLE_BRANDS: isomiso2mp41
2024-04-02 15:03:58     MAJOR_BRAND     : isom
2024-04-02 15:03:58     MINOR_VERSION   : 512
2024-04-02 15:03:58     encoder         : Lavf60.16.100
2024-04-02 15:03:58   Stream #0:0: Video: vp8, yuv420p(tv, progressive), 640x360 [SAR 1:1 DAR 16:9], q=2-31, 30 fps, 30 tbr, 1k tbn (default)
2024-04-02 15:03:58     Metadata:
2024-04-02 15:03:58       HANDLER_NAME    : VideoHandler
2024-04-02 15:03:58       VENDOR_ID       : [0][0][0][0]
2024-04-02 15:03:58       ENCODER         : Lavc60.31.102 libvpx
2024-04-02 15:03:58       DURATION        : 00:00:03.466000000
2024-04-02 15:03:58 Stream mapping:
2024-04-02 15:03:58   Stream #0:0 -> #0:0 (copy)
2024-04-02 15:03:58 Press [q] to stop, [?] for help
2024-04-02 15:04:08 2024/04/02 07:04:08 INF [path demo0] runOnDemand command stopped: timed out
2024-04-02 15:04:08 2024/04/02 07:04:08 INF [WebRTC] [session 829664cb] closed: source of path 'demo0' has timed out
[out#0/webm @ 0x7f04b00515c0] video:281kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 1.023511%
2024-04-02 15:04:08 size=     284kB time=00:00:10.49 bitrate= 221.3kbits/s speed=1.05x    
2024-04-02 15:04:08 Exiting normally, received signal 2.


  


  This is the same when I try to stream my other videos (demo1.mp4, demo2.mp4 etc.). What am I doing wrong ?