Recherche avancée

Sur d’autres sites (5710)

• ffmpeg2theora oggfwd not working with icecast2

  6 décembre 2011, par achilles

  I have a camera streaming (mjpeg) in http://192.168.x.x/image (where x are the rest of the IP). I start my icecast2 server (Ubuntu 10.10) and then I stream using :

  ffmpeg2theora -f mjpeg http://192.168.x.x/image -o /dev/stdout - | oggfwd localhost 8000 password /test

  The mountpoint is created but the video is not showing on Firefox. I do see the video box but it's just infinitely showing the "thinking" icon and video does not show.

  If I download a proper ogg file and do

  cat proper_ogg_file.ogg | oggfwd localhost 8000 password /test

  I see the video on the icecast server's website.

  In addition I did :

  ffmpeg2theora -f mjpeg http://192.168.x.x/image -o test_video.ogg

  Once I stop the process (CTRL+C) and go to my Desktop where the video is saved and open it with VLC or any other media player, it plays the portion of the stream that I allowed to be recorded all the way up to pressing CTRL+C.

  If I take that file and use the previous method :

  cat test_video.ogg | oggfwd localhost 8000 password /test

  I get the same issue as when I was directly piping the camera to stdout and then to oggfwd. So therefore I assume this is a "conversion" to ogg issue ? Can anybody help ? Any idea why i can't do that ?

• More Weird VP8 Encodings

  10 décembre 2010, par Multimedia Mike — VP8

  When I announced that I had transitioned my VP8 encoder’s status from "toy" to "working", Jim L. lamented the loss of humorous posts about oddly encoded images output from my encoder. Not so ! There are still plenty of features that I have yet to implement, each of which carries the possibility of bizarre images.

  For example, I dusted off my work-in-progress intra 4x4 encoding, fixed a few of the more obvious bugs, and told the encoder to encode the first block in 4x4 mode and the rest in the usual, working, debugged 16x16 mode. The results of the first pass surprised me :

  
  
  

  The reason this surprised me was that I intuitively expected one of 2 outcomes :

  • Perfect image right away since everything is correct (very unlikely but not outside the realm of possibility)
  • Total garbage with, at most, the first macroblock looking somewhat legible ; this would be due to having some of the first macroblock correct but completely desynchronizing the bitstream for the purpose of decoding the rest of the coefficients.

  I absolutely did not expect the first macroblock to look messed up but for the rest of the picture to look fine. For fun, I reversed the logic and encoded the first block as 16x16 and the rest with the experimental 4x4 mode :

  
  
  

  If you examine carefully, you will see that the color planes are correct (though faint). There just isn’t much going on in the luma plane. This made sense when I noticed the encoder was encoding a blank (undefined, actually) set of luma coefficients for 4x4 mode macroblocks due to a bug. This helps to rationalize the first image as well— the first macroblock was encoding nonsense for the first macroblock which messed up the macroblocks which immediately surrounded it. Eventually, macroblock decoding got back on track when the prediction modes weren’t relying on the errantly decoded macroblocks.

  After I fixed that bug, I let the 4x4 mode rip through the whole image. That’s when I got what I am terming the "dark and gritty reboot of Big Buck Bunny" :

  
  
  

  Fortunately, this also turned out to be traceable to a pretty obvious code bug.

  One day, this VP8 encoder might do the right thing while implementing all of the algorithm’s features. In the meantime, it’s at least entertaining to watch it make mistakes.

• Revision 2bd6fe08f8 : Enable early termination in rd search This commit allows encoder to detect the

  3 juillet 2013, par Jingning Han

  Changed Paths :
   Modify /vp9/encoder/vp9_rdopt.c

  
  
  Enable early termination in rd search

  This commit allows encoder to detect the cumulative rate-distortion
  cost per transformed block inside a partition. If the cumulative
  rd cost is already above the best rd value, it terminates the rest
  operations and continue to next prediction mode test.

  It reduces the runtime of bus at target bit-rate 2000 from 308 second
  to 266 second, i.e., about 13% speed-up at no performance penalty.

  Change-Id : I5f15a3d8955d97031d5653006027866a00654e7a