Recherche avancée

Sur d’autres sites (11306)

• Image sequence to video stream ?

  22 août 2015, par Hauns TM

  Like many people already seem to have (there are several threads on this subject here) I am looking for ways to create video from a sequence of images.

  I want to implement my functionality in C# !

  Here is what I wan’t to do :

  /*Pseudo code*/
  
  void CreateVideo(List<image> imageSequence, long durationOfEachImageMs, string outputVideoFileName, string outputFormat)
  
  {
  
      // Info: imageSequence.Count will be > 30 000 images
  
      // Info: durationOfEachImageMs will be &lt; 300 ms
  
  
  
      if (outputFormat = "mpeg")
  
      {
  
      }
  
      else if (outputFormat = "avi")
  
      {      
  
      }
  
      else
  
      {
  
      }
  
  
  
      //Save video file do disk
  
  }
  
  </image>

  I know there’s a project called Splicer (http://splicer.codeplex.com/) but I can’t find suitable documentation or clear examples that I can follow (these are the examples that I found).

  The closest I want to do, which I find here on CodePlex is this :
  How can I create a video from a directory of images in C# ?

  I have also read a few threads about ffmpeg (for example this : C# and FFmpeg preferably without shell commands ? and this : convert image sequence using ffmpeg) but I find no one to help me with my problem and I don’t think ffmpeg-command-line-style is the best solution for me (because of the amount of images).

  I believe that I can use the Splicer-project in some way (?).

  In my case, it is about about > 30 000 images where each image should be displayed for about 200 ms (in the videostream that I want to create).

  (What the video is about ? Plants growing ...)

  Can anyone help me complete my function ?

• Is Java fast enough to do live screensharing ?

  10 mars 2012, par user1260501

  For the past few months, a developer and I have been working on a screensharing applet that streams to a media server like Wowza or Red5, but no matter what we do, we have about 5 seconds of latency, which is too long for a live application where people are interacting with each other. We've tried xuggle, different encoders, different players, different networks, different media servers, and even streaming locally, there's significant latency.

  So, I'm beginning to wonder…

  Is Java fast enough to do live screensharing ?

  I've seen lots of screen recording applets written in Java, but none of them are streaming live. Everything that's done live, such as GoToMeeting, seems to use C++. I'm thinking maybe there's a reason.

  It's not a compression problem. Using ScreenVideo, we've compressed an hour-long stream down to about 100 MB, and we have plenty of bandwidth. The processor isn't overloaded doing the compression, either, but it seems to be taking too much time. We are getting the best results from some code pulled out of BigBlueButton, but still, the latency is terrible.

  Streaming the WebCam, on the other hand, is nice and snappy. Almost no latency at all. So, the problem is the applet.

  The only other idea I can think of is somehow emulating a WebCam with Java. Not sure if that would be faster or not.

  Ideas ? Or should I just give up on Java and do this in C++ ? I would hate to do that, because then I would have to create different versions for different platforms, but if it's the only way, it's the only way.

• ANSI Code Coverage Followup

  9 mars 2012, par Multimedia Mike — Programming

  The people behind sixteencolors.net noticed my code coverage project concerning the ANSI video decoder and asked what they could do to help. I had already downloaded 350 / 4000 of their artpacks but didn’t want to download the remainder if I could avoid it. They offered to run my tool against their local collection of files.

  Aside : They have all of the artpacks archived at Github.

  The full corpus of nearly 4000 artpacks contains over 146,000 files. Versus my sampling of 350 artpacks and 13,000 files that covered all but 45 lines of the ansi.c source file, the full corpus has files to exercise… 6 more of those lines. Whee. This means that there are files which exercise the reverse and concealed attributes, all 3 “erase in line” modes, and one more error path (which probably wasn’t a valid file anyway).

  Missing features mostly cluster around different video modes, including : 320×200 (25 rows), 640×200 (25 rows), 640×350 (43 rows), and 640×480 (60 rows) ; on the plus side, nothing tripped the “unsupported screen mode” case. There are no files that switch modes during playback.

  I guess statistical sampling theory holds out here– a small set of randomly chosen files would do a fine job covering code. But this experiment is about finding the statistical outliers.