Recherche avancée

Sur d’autres sites (6575)

• Notes on Linux for Dreamcast

  23 février 2011, par Multimedia Mike — Sega Dreamcast, VP8

  I wanted to write down some notes about compiling Linux on Dreamcast (which I have yet to follow through to success). But before I do, allow me to follow up on my last post where I got Google’s libvpx library decoding VP8 video on the DC. Remember when I said the graphics hardware could only process variations of RGB color formats ? I was mistaken. Reading over some old documentation, I noticed that the DC’s PowerVR hardware can also handle packed YUV textures (UYVY, specifically) :

  
  
  

  The video looks pretty sharp in the small photo. Up close, less so, due to the low resolution and high quantization of the test vector combined with the naive chroma upscaling. For the curious, the grey box surrounding the image highlights the 256-square texture that the video frame gets plotted on. Texture dimensions have to be powers of 2.

  Notes on Linux for Dreamcast
  I’ve occasionally dabbled with Linux on my Dreamcast. There’s an ancient (circa 2001) distro based around a build of kernel 2.4.5 out there. But I wanted to try to get something more current compiled. Thus far, I have figured out how to cross compile kernels pretty handily but have been unsuccessful in making them run.

  Here are notes are the compilation portion :
  

  • kernel.org provides a very useful set of cross compiling toolchains
  • get the gcc 4.5.1 cross toolchain for SH-4 (the gcc 4.3.3 one won’t work because the binutils is too old ; it will fail to assemble certain instructions as described in this post)
  • working off of Linux kernel 2.6.37, edit the top-level Makefile ; find the ARCH and CROSS_COMPILE variables and set appropriately :

    ARCH ?= sh
    CROSS_COMPILE ?= /path/to/gcc-4.5.1-nolibc/sh4-linux/bin/sh4-linux-
    

  • $ make dreamcast_defconfig
  • $ make menuconfig ... if any changes to the default configuration are desired
  • manually edit arch/sh/Makefile, changing :

    cflags-$(CONFIG_CPU_SH4) := $(call cc-option,-m4,) \
            $(call cc-option,-mno-implicit-fp,-m4-nofpu)
    

    to :

    cflags-$(CONFIG_CPU_SH4) := $(call cc-option,-m4,) \
            $(call cc-option,-mno-implicit-fp)
    

    I.e., remove the '-m4-nofpu' option. According to the gcc man page, this will "Generate code for the SH4 without a floating-point unit." Why this is a default is a mystery since the DC’s SH-4 has an FPU and compilation fails when enabling this option.

  • On that note, I was always under the impression that the DC sported an SH-4 CPU with the model number SH7750. According to this LinuxSH wiki page as well as the Linux kernel help, it actually has an SH7091 variant. This photo of the physical DC hardware corroborates the model number.
  • $ make ... to build a Linux kernel for the Sega Dreamcast

  Running
  So I can compile the kernel but running the kernel (the resulting vmlinux ELF file) gives me trouble. The default kernel ELF file reports an entry point of 0x8c002000. Attempting to upload this through the serial uploading facility I have available to me triggers a system reset almost immediately, probably because that’s the same place that the bootloader calls home. I have attempted to alter the starting address via ’make menuconfig’ -> System type -> Memory management options -> Physical memory start address. This allows the upload to complete but it still does not run. It’s worth noting that the 2.4.5 vmlinux file from the old distribution can be executed when uploaded through the serial loader, and it begins at 0x8c210000.

• avconv stops streaming after some time

  4 juin 2014, par Dhrumil Doshi

  I am using raspberry-pi board and a usb camera attached with it. i use avconv tool to capture live video from camera and streaming it on network using rtp protocol.

  My command on server(raspberry-pi board) is as below :

  avconv -f video4linux2 -s 160x120 -i /dev/video0 -vcodec mpeg2video -r 25 -pix_fmt yuv420p -me_method epzs -b 2600k -bt 256k -f rtp rtp ://192.168.1.141:8554

  streaming works successfully using this command. Here IP address 192.168.1.141 is the ip address of my client pc. i can play live streaming on client side using vlc successfully.

  But Issue is after some time encoding and streaming on server stop automatically. And command hangs there.

  Output on server is as below :

  $ avconv -f video4linux2 -s 160x120 -v debug -i /dev/video0 -vcodec mpeg2video -r 25 -pix_fmt yuv420p -me_method epzs -b 2600k -bt 256k -f rtp rtp://192.168.1.141:8554
  
  avconv version 0.8.10-6:0.8.10-1+rpi1, Copyright (c) 2000-2013 the Libav developers
  
    built on Mar 22 2014 02:13:15 with gcc 4.6.3
  
    configuration: --arch=arm --enable-pthreads --enable-runtime-cpudetect --extra-version='6:0.8.10-1+rpi1' --libdir=/usr/lib/arm-linux-gnueabihf --prefix=/usr --disable-yasm --enable-bzlib --enable-libdc1394 --enable-libdirac --enable-libfreetype --enable-frei0r --enable-gnutls --enable-libgsm --enable-libmp3lame --enable-librtmp --enable-libopencv --enable-libopenjpeg --enable-libpulse --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-vaapi --enable-vdpau --enable-libvorbis --enable-libvpx --enable-zlib --enable-gpl --enable-postproc --enable-swscale --enable-libcdio --enable-x11grab --enable-libx264 --enable-libxvid --shlibdir=/usr/lib/arm-linux-gnueabihf --enable-shared --disable-static
  
    libavutil    51. 22. 2 / 51. 22. 2
  
    libavcodec   53. 35. 0 / 53. 35. 0
  
    libavformat  53. 21. 1 / 53. 21. 1
  
    libavdevice  53.  2. 0 / 53.  2. 0
  
    libavfilter   2. 15. 0 /  2. 15. 0
  
    libswscale    2.  1. 0 /  2.  1. 0
  
    libpostproc  52.  0. 0 / 52.  0. 0
  
  [video4linux2 @ 0x54d7a0] [4]Capabilities: 84000001
  
  [video4linux2 @ 0x54d7a0] The V4L2 driver changed the pixel format from 0x32315559 to 0x56595559
  
      Last message repeated 1 times
  
  [video4linux2 @ 0x54d7a0] The V4L2 driver changed the pixel format from 0x50323234 to 0x56595559
  
  [video4linux2 @ 0x54d7a0] The V4L2 driver set input_id: 0, input: Camera 1
  
  [rawvideo @ 0x54f860] err{or,}_recognition separate: 1; 1
  
  [rawvideo @ 0x54f860] err{or,}_recognition combined: 1; 1
  
  [video4linux2 @ 0x54d7a0] All info found
  
  [video4linux2 @ 0x54d7a0] Estimating duration from bitrate, this may be inaccurate
  
  Input #0, video4linux2, from '/dev/video0':
  
    Duration: N/A, start: 21891.364784, bitrate: 9216 kb/s
  
      Stream #0.0, 1, 1/1000000: Video: rawvideo, yuyv422, 160x120, 1/30, 9216 kb/s, 30 tbr, 1000k tbn, 30 tbc
  
  [buffer @ 0x54f220] w:160 h:120 pixfmt:yuyv422
  
  [avsink @ 0x54d740] auto-inserting filter 'auto-inserted scaler 0' between the filter 'src' and the filter 'out'
  
  [scale @ 0x54f7e0] w:160 h:120 fmt:yuyv422 -> w:160 h:120 fmt:yuv420p flags:0x4
  
  [mpeg2video @ 0x54ea60] err{or,}_recognition separate: 1; 1
  
  [mpeg2video @ 0x54ea60] err{or,}_recognition combined: 1; 1
  
  [mpeg2video @ 0x54ea60] detected 1 logical cores
  
  [mpeg2video @ 0x54ea60] Unsupported bit depth: 0
  
  [rawvideo @ 0x54f860] err{or,}_recognition separate: 1; 1
  
  [rawvideo @ 0x54f860] err{or,}_recognition combined: 1; 1
  
  Output #0, rtp, to 'rtp://192.168.1.141:8554':
  
    Metadata:
  
      encoder         : Lavf53.21.1
  
      Stream #0.0, 0, 1/90000: Video: mpeg2video, yuv420p, 160x120, 1/25, q=2-31, 2600 kb/s, 90k tbn, 25 tbc
  
  Stream mapping:
  
    Stream #0:0 -> #0:0 (rawvideo -> mpeg2video)
  
  SDP:
  
  v=0
  
  o=- 0 0 IN IP4 127.0.0.1
  
  s=No Name
  
  c=IN IP4 192.168.1.141
  
  t=0 0
  
  a=tool:libavformat 53.21.1
  
  m=video 8554 RTP/AVP 32
  
  b=AS:2600
  
  
  
  Press ctrl-c to stop encoding
  
  *** drop!
  
      Last message repeated 1 times
  
  *** 1 dup!
  
  *** 16 dup! fps= 25 q=2.0 size=    1027kB time=5.24 bitrate=1605.2kbits/s dup=1 drop=2    
  
  *** drop!
  
      Last message repeated 11 times
  
  *** drop!49 fps= 26 q=2.0 size=    1059kB time=5.92 bitrate=1464.9kbits/s dup=17 drop=14    
  
      Last message repeated 2 times
  
  *** drop!76 fps= 25 q=2.0 size=    2022kB time=11.00 bitrate=1505.7kbits/s dup=17 drop=17    
  
  *** drop!48 fps= 25 q=2.0 size=    4086kB time=21.88 bitrate=1529.8kbits/s dup=17 drop=18    
  
  *** 1 dup!
  
  *** 1 dup!0 fps= 25 q=2.0 size=    4171kB time=22.36 bitrate=1528.2kbits/s dup=18 drop=19    
  
  *** 1 dup!1 fps= 25 q=2.0 size=    4859kB time=26.00 bitrate=1530.8kbits/s dup=19 drop=19    
  
  *** 1 dup!0 fps= 25 q=2.0 size=    5152kB time=27.56 bitrate=1531.5kbits/s dup=20 drop=19    
  
  *** 1 dup!3 fps= 25 q=2.0 size=    5250kB time=28.08 bitrate=1531.7kbits/s dup=21 drop=19    
  
  *** drop!64 fps= 25 q=2.0 size=    7215kB time=38.52 bitrate=1534.5kbits/s dup=22 drop=19    
  
  *** 1 dup!6 fps= 25 q=2.0 size=    7306kB time=39.00 bitrate=1534.6kbits/s dup=22 drop=20    
  
  *** drop!07 fps= 25 q=2.0 size=    8288kB time=44.24 bitrate=1534.7kbits/s dup=23 drop=20    
  
  *** 1 dup!0 fps= 25 q=2.0 size=   10054kB time=53.56 bitrate=1537.8kbits/s dup=23 drop=21    
  
  *** 1 dup!9 fps= 25 q=2.0 size=   10342kB time=55.12 bitrate=1537.1kbits/s dup=24 drop=21    
  
      Last message repeated 1 times
  
  *** drop!93 fps= 25 q=1.6 size=   10445kB time=55.68 bitrate=1536.7kbits/s dup=26 drop=21    
  
  *** 1 dup!
  
  *** 7036829 dup! 25 q=2.0 size=   10630kB time=56.68 bitrate=1536.4kbits/s dup=27 drop=22 

  Any ideas ?

  Thanks in advance.

• Recapping WebM’s First Week

  25 mai 2010, par noreply@blogger.com (John Luther) — webm, vp8, vorbis

  The WebM project launched last Wednesday with broad industry backing (watch video of the announcement). The list of supporters keeps growing with new additions such as the popular VLC media player, Miro Video Converter, HeyWatch cloud encoding platform, and videantis programmable processor platform. We’re also happy to see that future versions of IE will support playback of VP8 when the user has installed the codec.

  Our announcement sparked discussions in the community around the design and quality of our developer release. We’ve done extensive testing of VP8 and know that the codec can match or exceed the quality of other leading codecs. Starting this week, the engineers behind WebM will post frequently to this blog with details on how to make optimal use of its VP8 video codec and Vorbis audio codec. We are confident that the open development model will bring additional improvements that will further optimize WebM. In fact, the power of open development is already visible, with developers submitting patches and the folks at Flumotion enabling live streaming support in their product just three days after the project was launched.

  Keep an eye on this blog for regular updates on the adoption and development of WebM. To participate in the conversation or to ask questions of the WebM team, please join our discussion group.

  John Luther
  Product Manager, Google