Recherche avancée

Sur d’autres sites (13808)

• Revision a723f5ecd1 : Fix a tsan error bug in frame parallel decode. A frame may be waiting for an ou

  3 mars 2015, par hkuang

  Changed Paths :
   Modify /vp9/decoder/vp9_decodeframe.c

  
  
  Fix a tsan error bug in frame parallel decode.

  A frame may be waiting for an out of border pixel from another
  frame. A frame’s row progress variable is set to -1 when start being decoded
  and another frame may be waiting for -2 row pixel from this frame.
  In this case, vp9_frameworker_wait will return directly and skip the waiting
  which leads to tsan error between threads.

  Change-Id : Id16604915fb598b823e34393f696e3aa46fb6422

• Capture live video from a camera on a computer and using ffmpeg

  21 juin 2013, par Devendra

  I am trying to capture live video from a camera on a computer and using ffmpeg as an encoder, send this video for live streaming to a IIS server.

  Here is what I did :

  1. Captured feed from webcam using video4linux2 and ffmpeg

  2. Installed x264 for a h.264 codec

  3. Used muxer feature in ffmpeg, as described on this link -
     http://www.ffmpeg.org/ffmpeg-formats.html#Muxers
     to generate ismv file locally
     Command -
     ffmpeg -f video4linux2 -r 25 -s 640x480 -i /dev/video0 -b:v 661k -c:v libx264 -movflags isml+frag_keyframe+empty_moov -f ismv test.ismv

  4. Now to get the complete system in place (live capture from webcam and live streaming on IIS server), I want ffmpeg to generate this ffmpeg file on a publish point. here is the command I used
     ffmpeg -f video4linux2 -r 25 -s 640x480 -i /dev/video0 -b:v 661k -c:v libx264 -movflags isml+frag_keyframe+empty_moov -f ismv http://www.MY-SERVER/PushToPublishPoint/Test.isml

  as described at this link :

  http://www.unified-streaming.com/support/documentation/content-delivery/publishing-points/
  http://www.unified-streaming.com/support/documentation/content-encoding/encoders/

  It shows some video is being generated, but I cannot see any activity at the server.

  When I use wireshark to look at the packet info, there are many packet transfers between pc and the server.

  I have kept publishing point in IDLE state, STARTING state to see if that is the problem, but no progress there as well.
  I think I am unable to establish communication with the server. Pls help.

  Any help would be appreciated.

  Thanks

• Making Sure The PNG Gets There

  14 juin 2013, par Multimedia Mike — General

  Rewind to 1999. I was developing an HTTP-based remote management interface for an embedded device. The device sat on an ethernet LAN and you could point a web browser at it. The pitch was to transmit an image of the device’s touch screen and the user could click on the picture to interact with the device. So we needed an image format. If you were computing at the time, you know that the web was insufferably limited back then. Our choice basically came down to GIF and JPEG. Being the office’s annoying free software zealot, I was championing a little known up and coming format named PNG.

  So the challenge was to create our own PNG encoder (incorporating a library like libpng wasn’t an option for this platform). I seem to remember being annoyed at having to implement an integrity check (CRC) for the PNG encoder. It’s part of the PNG spec, after all. It just seemed so redundant. At the time, I reasoned that there were 5 layers of integrity validation in play.

  I don’t know why, but I was reflecting on this episode recently and decided to revisit it. Here are all the encapsulation layers of a PNG file when flung over an ethernet network :

  
  
  

  So there are up to 5 encapsulations for the data in this situation. At the innermost level is the image data which is compressed with the zlib DEFLATE method. At first, I thought that this also had a CRC or checksum. However, in researching this post, I couldn’t find any evidence of such an integrity check. Further, I don’t think we bothered to compress the PNG data in this project long ago. It was a small image, monochrome, and transferring via LAN, so the encoder could get away with signaling uncompressed data.

  The graphical data gets wrapped up in a PNG chunk and all PNG chunks have a CRC. To transmit via the network, it goes into a TCP frame, which also has a checksum. That goes into an IP packet. I previously believed that this represented another integrity check. While an IP frame does have a checksum, the checksum only covers the IP header and not the payload. So that doesn’t really count towards this goal.

  Finally, the data gets encapsulated into an ethernet frame which has — you guessed it — a CRC.

  I see that other link layer protocols like PPP and wireless ethernet (802.11) also feature frame CRCs. So I guess what I’m saying is that, if you transfer a PNG file over the network, you can be confident that the data will be free of any errors.