Recherche avancée

Sur d’autres sites (4819)

• Lossless avi encoding on linux

  21 septembre 2022, par dlants

  I am trying to write video using opencv. It is important for me to do this precisely - so it has to be a lossless codec. I am working with OpenCV 2.4.1 on Ubuntu 12.04

  



  Previously, I was using the fourcc code 0. This gave me the exact result I wanted, and I was able to recover the images perfectly.

  



  I am not sure what happened, but as of a recent update (around Jul 20th 2012), something went wrong and I am no longer able to write files with this fourcc code. I really don't remember what it was, but it could have come from doing an update, removing some software from my software center, and some other things I did during general cleaning...

  



  When I check an older file with mediainfo (http://www.fourcc.org/identifier/) I see the following result :

  



  Complete name                            : oldsample.avi
Format                                   : AVI
Format/Info                              : Audio Video Interleave
Format profile                           : OpenDML
File size                                : 1.07 GiB
Duration                                 : 41s 467ms
Overall bit rate                         : 221 Mbps
Writing application                      : Lavf53.5.0
Video
ID                                       : 0
Format                                   : RGB
Codec ID                                 : 0x00000000
Codec ID/Info                            : Basic Windows bitmap format. 1, 4 and 8 bpp     versions are palettised. 16, 24 and 32bpp contain raw RGB samples
Duration                                 : 41s 467ms
Bit rate                                 : 221 Mbps
Width                                    : 640 pixels
Height                                   : 4294966 816 pixels
Display aspect ratio                     : 0.000
Frame rate                               : 30.000 fps
Bit depth                                : 8 bits
Stream size                              : 1.07 GiB (100%)


  



  Now, I see that when I write using the 0 fourcc codec, the program actually defaults to the i420 codec. Here is the output from one of the files I try to write now :

  



  Complete name                            : newsample.avi
Format                                   : AVI
Format/Info                              : Audio Video Interleave
File size                                : 73.0 MiB
Duration                                 : 5s 533ms
Overall bit rate                         : 111 Mbps
Writing application                      : Lavf54.6.100
Video
ID                                       : 0
Format                                   : YUV
Codec ID                                 : I420
Codec ID/Info                            : 8 bit Y plane followed by 8 bit 2x2 subsampled U and V planes.
Duration                                 : 5s 533ms
Bit rate                                 : 111 Mbps
Width                                    : 640 pixels
Height                                   : 480 pixels
Display aspect ratio                     : 4:3
Frame rate                               : 30.000 fps
Compression mode                         : Lossless
Bits/(Pixel*Frame)                       : 12.000
Stream size                              : 72.9 MiB (100%)


  



  This format, and other formats I try to use (like huffyuv HFYU), do not work for me because I end up with effects like this http://imgur.com/a/0OC4y - you see the bright artifacts coming in due to what I assume is either lossy compression or chroma subsampling in the case of HFYU which is supposed to be lossless. What you are looking at is the red channel from one of my videos. The perceptual effect is negligible when you look at all 3 channels simultaneously but it is essential that I reconstruct the images exactly.

  



  Furthermore, while I am able to play my old files in media players like vlc, I suddenly find them to be completely incompatible with opencv. When I try to open the older files with a videocapture, the open step works fine, but trying to do a read operation results in a segfault. Furthermore, When I try to write with either :

  



  CV_FOURCC(0,0,0,0)
0


  



  Opencv defaults to I420 for some reason.

  



  Next, I tried using some alternate codecs. 'DIB ' seems like something that should work for me, and on the opencv website (http://opencv.willowgarage.com/wiki/VideoCodecs) it is listed as a 'recommended' codec. However, trying to use this results in the following message :

  



  OpenCV-2.4.1/modules/highgui/src/cap_gstreamer.cpp:483: error: (-210) Gstreamer Opencv backend doesn't support this codec acutally. in function CvVideoWriter_GStreamer::open

Aborted (core dumped)


  



  I checked the opencv source for this codec, and stumbled across the following :

  



  cd OpenCV-2.4.1/modules
grep -i -r "CV_FOURCC" ./*
...
./highgui/src/cap_qt.cpp:    /*if( fourcc == CV_FOURCC( 'D', 'I', 'B', ' ' ))
./highgui/include/opencv2/highgui/highgui_c.h:#define CV_FOURCC_DEFAULT CV_FOURCC('I', 'Y', 'U', 'V') /* Use default codec for specified filename (Linux only) */


  



  I tried installing qt4 and reconfiguring with the WITH_QT flag, but that did not change anything. I also tried uncommenting that part of the code and reinstalling opencv, but that also did not work.

  



  My ultimate goal is for any way to efficiently store and retrieve a video stream with 16 bits for every pixel (like 32float would work fine, and then it wouldn't need to be perfect). Right now I am unpacking the 16 bits into the red and green channels, which is why I need it to be perfect - since an error of 1 in the red channel is multiplied by 256 in the final result. I am not having success with any of the fourcc codes available to me.

  


• C# Bitmap to AVI / WMV with Compression

  5 juillet 2019, par Digitalsa1nt

  Prelude :

  I’m going to preface this with, I have been learning C# in my spare time at work, and that I have been staring at code for a solid two days trying to wrap my head around this problem. I am developing some software to be used with a visualiser that connects by USB to a standard Desktop PC, the software detects the capture device and loads frames into bitmap using a New Frame Event, this is then displayed in a ’picture box’ as a live video stream. The problem as it sits is trying to encorporate the ability to record the stream and save to file, preferably a WMV or a compressed AVI.

  What’s been tried :

  I have considered and looked into the following :

  SharpAVI - cant seem to get this to compress or save the frames properly as it appears to mainly look at existing AVI files.

  AForge.Video.VFW - AVI files can be created but are far too large to be used, due to restrictions on the user areas of the individuals who will be using this software.

  AForge.Video.FFMPEG - Again due to considerations of those using this software I can’t have unmanaged DLL’s sat in the output folder with the Executable file, and unfortunately this particular DLL cant be compiled properly using Costura Fody.

  AVIFile Library Wrapper (From Code Project) - Again can’t seem to get this to compress a stream correctly from Bitmaps from the New Frame Events.

  DirectShow - Appears to use C++ and unfortunately is beyond my skill level at this time.

  The Relevant Code Snippets :

  Current References :

  using System.Data;
  
  using System.Drawing;
  
  using System.Linq;
  
  using System.Text;
  
  using System.Threading.Tasks;
  
  using System.Windows.Forms;
  
  using System.Resources;
  
  using System.Drawing.Imaging;
  
  using System.IO;
  
  //Aforge Video DLL's
  
  using AForge.Video;
  
  using AForge.Video.VFW;
  
  using AForge.Video.DirectShow;
  
  //Aforge Image DLL's
  
  using AForge.Imaging;
  
  using AForge.Imaging.Formats;
  
  using AForge.Imaging.Filters;
  
  //AviLibrary
  
  using AviFile;

  Global Variables :

      #region Global Variables
  
  
  
      private FilterInfoCollection CaptureDevice; // list of available devices
  
      private VideoCaptureDevice videoSource;
  
      public System.Drawing.Image CapturedImage;
  
  
  
      bool toggleMic = false;
  
  
  
      bool toggleRec = false;
  
      //aforge
  
      AVIWriter aviWriter;
  
      Bitmap image;
  
  
  
  
  
      #endregion

  Code for Displaying Stream

      #region Displays the Stream
  
  
  
      void videoSource_NewFrame(object sender, NewFrameEventArgs eventArgs)
  
      {
  
          picBoxStream.SizeMode = PictureBoxSizeMode.Zoom;
  
          picBoxStream.Image = (Bitmap)eventArgs.Frame.Clone();// clones the bitmap
  
  
  
  
  
          if (toggleRec == true)
  
          {
  
              image = (Bitmap)eventArgs.Frame.Clone();
  
              aviWriter.AddFrame(image);
  
          }
  
      }
  
  
  
      #endregion

  Current Code for Recording Stream

      #region Record Button
  
  
  
      private void btnRecord_Click(object sender, EventArgs e)
  
      {
  
          if (toggleRec == false)
  
          {
  
              saveAVI = new SaveFileDialog();
  
              saveAVI.Filter = "AVI Files (*.avi)|*.avi";
  
  
  
              if (saveAVI.ShowDialog() == DialogResult.OK)
  
              {
  
                  aviWriter = new AVIWriter();
  
                  aviWriter.Open(saveAVI.FileName, 1280, 720);
  
  
  
                  toggleRec = true;
  
                  Label lblRec = new Label();
  
              }
  
  
  
          }
  
          else if (toggleRec == true)
  
          {
  
              aviWriter.Close();
  
              toggleRec = false;
  
          }
  
      }
  
  
  
      #endregion

  I apoligise if the above code doesn’t look quite right, I have been swapping, changing and recoding those three sections a lot in order to find a working combination. This means that it’s rather untidy but I didn’t see the point in cleaning it all up until I had the code working. That being said really any help that you can provide is greatfully recieved, even if it’s a case of what I want to do just cannot be done.

  Thank you in advance.

  EDIT : 2019 :

  It’s been awhile since I posted this and it still gets the odd bit of interest here and there. Back when I posted this I was teaching myself to code and I had this weird quirk that I didn’t like using 3rd party libraries if I could avoid it, I wanted to do my own work, since then I’ve learnt a lot and one of those things is that the open source world is immense, impressive and kind. So if there is a 3rd party library that does what you want just use it, it’ll save you time.

• Ode to the Gravis Ultrasound

  1er août 2011, par Multimedia Mike — General

  WARNING : This post is a bunch of nostalgia. Feel free to follow along if you recall the DOS days of the early-mid 1990s.

  I finally let go of my Gravis Ultrasound MAX sound card a little while ago. It felt like the end of an era for me, even though I had scarcely used the card in recent memory.

  
  
  

  The Beginning
  What is the Gravis Ultrasound ? Only the finest PC sound card from the classic DOS days. Back in the day (very early 1990s), most consumer PC sound cards were Yamaha OPL FM synthesizers paired with a basic digital to analog converter (DAC). Gravis, a company known for game controllers, dared to break with the dominant paradigm of Sound Blaster clones and create a sound card that had 32 digital channels.
  
  I heard about the GUS sometime in 1992 through one of the dominant online services at the time, Prodigy. Through the message boards, I learned of a promotion with Electronic Arts in which customers could pre-order a GUS at a certain discount along with 2 EA games from a selected catalog (with progressive discounts when ordering more games from the list). I know I got the DOS version of PowerMonger ; I think the other was Night Shift, though that doesn’t seem to be an EA title.

  Anyway, 1992 saw many maddening delays of the GUS hardware. Finally, reports of GUS shipments began to trickle into the Prodigy message forums. Then one day in November, 1992, mine arrived. Into the 286 machine it went and a valiant attempt at software installation was made. A friend and I fought with the software late into the evening, trying to make this thing work reasonably. I remember grabbing a pair of old headphones sitting near the computer that were used for an ancient (even for the time) portable radio. That was the only means of sound reproduction we had available at that moment. And it still sounded incredible.

  After graduating to progressively superior headphones, I would later return to that original pair only to feel my ears were being physically assaulted. Strange, they sounded fine that first night I was trying to make the GUS work. I guess this was my first understanding that the degree to which one is a snobby audiophile is all a matter of hard-earned experience.

  Technology
  The GUS was powered by something called a GF1 which was supposed to use a technology called wavetable synthesis. In the early days, I thought (and I wasn’t alone in this) that this meant that the GF1 chip had a bunch of digitized instrument samples stored in the ASIC. That wasn’t it.

  However, it did feature 32 digital channels at a time when most PC audio cards had 2 (plus that Yamaha FM synthesizer). There was some hemming and hawing about how the original GUS couldn’t drive all 32 channels at a full 44.1 kHz ("CD quality") playback rate. It’s true— if 14 channels were enabled, all could be played at 44.1 kHz. Enabling more channels started progressive degradation and with all 32 channels, each was only playing at around 19 kHz. Still, from my emerging game programmer perspective, that allowed for 8-channel tracker music and 6 channels of sound effects, all at the vaunted CD level of quality.

  Games and Compatibility
  The primary reason to have a discrete sound card was for entertainment applications — ahem, games. GUS support was pretty sketchy out of the gate (ostensibly a major reason for the card’s delay). While many sound cards offered Sound Blaster emulation by basically having the same hardware as Sound Blaster cards, the GUS took a software route towards emulating the SB. To do this required a program called the Sound Blaster Operating System, or SBOS.

  Oh, how awesome it was to hear the program exclaim "SBOS installed !" And how harshly it grated on your nerves after the 200th time hearing it due to so many reboots and fiddling with options to make your games work. Also, I’ve always wondered if there’s something special about sampling an ’s’ sound — does it strain the sampling frequency range ? Perhaps the phrase was sampled at too low a bitrate because the ’s’ sounds didn’t come through very clearly, which is something you notice after hundreds of iterations when there are 3 ’s’ sounds in the phrase.

  Fortunately, SBOS became less relevant with the advent of Mega-Em, a separate emulator which intercepted calls to Roland MIDI systems and routed them to the very capable GUS. Roland-supporting games sounded beautiful.

  Eventually, more and more DOS games were released with native Gravis support, sometimes with the help of The Miles Sound System (from our friends at Rad Game Tools — you know, the people behind Smacker and Bink). The library changelog is quite the trip down PC memory lane.

  An important area where the GUS shined brightly was that of demos and music trackers. The emerging PC demo scene embraced the powerful GUS (aided, no doubt, by Gravis’ sponsorship of the community) and the coolest computer art and music of the time natively supported the card.

  Programming
  At this point in my life, I was a budding programmer in high school and was fairly intent on programming video games. So far, I had figured out how to make a few blips using a borrowed Sound Blaster card. I went to great lengths to learn how to program the Gravis Ultrasound.

  Oh you kids today, with your easy access to information at the tips of your fingers thanks to Google and the broader internet. I had to track down whatever information I could find through a combination of Prodigy message boards and local dialup BBSes and FidoNet message bases. Gravis was initially tight-lipped about programming information for its powerful card, as was de rigueur of hardware companies (something that largely persists to this day). But Gravis eventually saw an opportunity to one-up encumbent Creative Labs and released a full SDK for the Ultrasound. I wanted the SDK badly.

  So it was early-mid 1993. Gravis released an SDK. I heard that it was available on their support BBS. Their BBS with a long distance phone number. If memory serves, the SDK was only in the neighborhood of 1.5 Mbytes. That takes a long time to transfer via a 2400 baud modem at a time when long distance phone charges were still a thing and not insubstantial.

  Luckily, they also put the SDK on something called an ’FTP site’. Fortunately, about this time, I had the opportunity to get some internet access via the local university.

  Indeed, my entire motivation for initially wanting to get on the internet was to obtain special programming information. Is that nerdy enough for you ?

  I see that the GUS SDK is still available via the Gravis FTP site. The file GUSDK222.ZIP is dated 1998 and is less than a megabyte.

  Next Generation : CD Support
  So I had my original GUS by the end of 1992. That was just the first iteration of the Gravis Ultrasound. The next generation was the GUS MAX. When I was ready to get into the CD-ROM era, this was what I wanted in my computer. This is because the GUS MAX had CD-ROM support. This is odd to think about now when all optical drives have SATA interfaces and (P)ATA interfaces before that— what did CD-ROM compatibility mean back then ? I wasn’t quite sure. But in early 1995, I headed over to Computer City (R.I.P.) and bought a new GUS MAX and Sony double-speed CD-ROM drive to install in the family’s PC.

  
  
  

  About the "CD-ROM compatibility" : It seems that there were numerous competing interfaces in the early days of CD-ROM technology. The GUS MAX simply integrated 3 different CD-ROM controllers onto the audio card. This was superfluous to me since the Sony drive came with an appropriate controller card anyway, though I didn’t figure out that the extra controller card was unnecessary until after I installed it. No matter ; computers of the day were rife with expansion ports.

  
  
  The 3 different CD-ROM controllers on the GUS MAX
  

  Explaining The Difference
  It was difficult to explain the difference in quality to those who didn’t really care. Sometime during 1995, I picked up a quasi-promotional CD-ROM called "The Gravis Ultrasound Experience" from Babbage’s computer store (remember when that was a thing ?). As most PC software had been distributed on floppy discs up until this point, this CD-ROM was an embarrassment of riches. Tons of game demos, scene demos, tracker music, and all the latest GUS drivers and support software.

  Further, the CD-ROM had a number of red book CD audio tracks that illustrated the difference between Sound Blaster cards and the GUS. I remember loaning this to a tech-savvy coworker who disbelieved how awesome the GUS was. The coworker took it home, listened to it, and wholly agreed that the GUS audio sounded better than the SB audio in the comparison — and was thoroughly confused because she was hearing this audio emanating from her Sound Blaster. It was the difference between real-time and pre-rendered audio, I suppose, but I failed to convey that message. I imagine the same issue comes up even today regarding real-time video rendering vs., e.g., a pre-rendered HD cinematic posted on YouTube.

  Regrettably, I can’t find that CD-ROM anymore which leads me to believe that the coworker never gave it back. Too bad, because it was quite the treasure trove.

  Aftermath
  According to folklore I’ve heard, Gravis couldn’t keep up as the world changed to Windows and failed to deliver decent drivers. Indeed, I remember trying to keep my GUS in service under Windows 95 well into 1998 but eventually relented and installed some kind of more appropriate sound card that was better supported under Windows.

  Of course, audio output capability has been standard issue for any PC for at least 10 years and many people aren’t even aware that discrete sound cards still exist. Real-time audio rendering has become less essential as full musical tracks can be composed and compressed into PCM format and delivered with the near limitless space afforded by optical storage.

  A few years ago, it was easy to pick up old GUS cards on eBay for cheap. As of this writing, there are only a few and they’re pricy (but perhaps not selling). Maybe I was just viewing during the trough of no value a few years ago.

  Nowadays, of course, anyone interested in studying the old GUS or getting a nostalgia fix need only boot up the always-excellent DOSBox emulator which provides remarkable GUS emulation support.