Recherche avancée

Sur d’autres sites (6000)

• Merge remote-tracking branch ’qatar/master’

  4 novembre 2013, par Michael Niedermayer

  Merge remote-tracking branch ’qatar/master’
  * qatar/master :
  
    aacdec : Set the profile during decoding
  Merged-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavcodec/aacdec.c
  • [DH] libavcodec/aacsbr.c

• I have a log file with RTP packets : now what ?

  9 mai 2012, par Brannon

  I have a log file with RTP packets coming off of a black box device. I also have a corresponding SDP file (RTSP DESCRIBE) for that. I need to convert this file into some kind of playable video file. Can I pass these two files to FFMpeg or VLC or something else and have it mux that data into something playable ?

  As an alternate plan, I can loop through the individual packets in code and do something with each packet. However, it seems that there are existing libraries for parsing this data. And it seems to do it by hand would be asking for a large project. Is there some kind of video file format that is a pretty raw mix of SDP and RTP ? Thanks for your time.

  Is there a way for FFmpeg or VLC to open an SDP file and then get their input packets through STDIN ?

  I generally use C#, but I could use C if necessary.

  Update 1 : Here is my unworking code. I'm trying to get some kind of output to play with ffplay, but I haven't had any luck yet. It gives me invalid data errors. It does go over all the data correctly as far as I can tell. My output is nearly as big as my input (at about 4MB).

      public class RtpPacket2
  
      {
  
          public byte VersionPXCC;
  
          public byte MPT;
  
          public ushort Sequence; // length?
  
          public uint Timestamp;
  
          public uint Ssrc;
  
          public int Version { get { return VersionPXCC >> 6; } }
  
          public bool Padding { get { return (VersionPXCC & 32) > 0; } }
  
          public bool Extension { get { return (VersionPXCC & 16) > 0; } }
  
          public int CsrcCount { get { return VersionPXCC & 0xf; } } // ItemCount
  
          public bool Marker { get { return (MPT & 0x80) > 0; } }
  
          public int PayloadType { get { return MPT & 0x7f; } } // PacketType
  
      }
  
  
  
  
  
      static void Main(string[] args)
  
      {
  
          if (args.Length != 2)
  
          {
  
              Console.WriteLine("Usage: <input rtp="rtp" file="file" /> <output 3gp="3gp" file="file">");
  
              return;
  
          }
  
          var inputFile = args[0];
  
          var outputFile = args[1];
  
          if(File.Exists(outputFile)) File.Delete(outputFile);
  
  
  
          // FROM the SDP : fmtp 96 profile-level-id=4D0014;packetization-mode=0
  
          var sps = Convert.FromBase64String("Z0LAHoiLUFge0IAAA4QAAK/IAQ=="); //      BitConverter.ToString(sps)  "67-42-C0-1E-88-8B-50-58-1E-D0-80-00-03-84-00-00-AF-C8-01"  string
  
          var pps = Convert.FromBase64String("aM44gA=="); //      BitConverter.ToString(pps)  "68-CE-38-80"   string
  
          var sep = new byte[] { 00, 00, 01 };
  
  
  
          var packet = new RtpPacket2();
  
          bool firstFrame = true;
  
          using (var input = File.OpenRead(inputFile))
  
          using (var reader = new BinaryReader(input))
  
          using (var output = File.OpenWrite(outputFile))
  
          {
  
              //output.Write(header, 0, header.Length);
  
              output.Write(sep, 0, sep.Length);
  
              output.Write(sps, 0, sps.Length);
  
              output.Write(sep, 0, sep.Length);
  
              output.Write(pps, 0, pps.Length);
  
              output.Write(sep, 0, sep.Length);
  
              while (input.Position &lt; input.Length)
  
              {
  
                  var size = reader.ReadInt16();
  
                  packet.VersionPXCC = reader.ReadByte();
  
                  packet.MPT = reader.ReadByte();
  
                  packet.Sequence = reader.ReadUInt16();
  
                  packet.Timestamp = reader.ReadUInt32();
  
                  packet.Ssrc = reader.ReadUInt32();
  
                  if (packet.PayloadType == 96)
  
                  {
  
                      if (packet.CsrcCount > 0 || packet.Extension) throw new NotImplementedException();
  
  
  
                      var header0 = reader.ReadByte();
  
                      var header1 = reader.ReadByte();
  
  
  
                      var fragmentType = header0 &amp; 0x1F; // should be 28 for video
  
                      if(fragmentType != 28) // 28 for video?
  
                      {
  
                          input.Position += size - 14;
  
                          continue;
  
                      }
  
                      var nalUnit = header0 &amp; ~0x1F;
  
                      var nalType = header1 &amp; 0x1F;
  
                      var start = (header1 &amp; 0x80) > 0;
  
                      var end = (header1 &amp; 0x40) > 0;
  
  
  
                      if(firstFrame)
  
                      {
  
                          output.Write(sep, 0, sep.Length);
  
                          output.WriteByte((byte)(nalUnit | fragmentType));
  
                          firstFrame = false;
  
                      }
  
  
  
                      for (int i = 0; i &lt; size - 14; i++)
  
                          output.WriteByte(reader.ReadByte());
  
                      if (packet.Marker)
  
                          firstFrame = true;
  
                  }
  
                  else input.Position += size - 12;
  
              }
  
          }
  
      }
  
  </output>

• Solving The XVD Puzzle

  15 avril 2012, par Multimedia Mike — General, multimedi archaeology, silicon valley, vg2, xvd, zygo

  I downloaded a multimedia file a long time ago (at least, I strongly suspected it was a multimedia file which is why I downloaded it). It went by the name of ‘lamborghini_850kbps.vg2′. I have had it in my collection for at least 7 years. I couldn’t remember where I found it. I downloaded it before it occurred to me to take notes about this sort of stuff.

  I found myself staring at the file again today and Googled the filename. This led me to a few Japanese sites which also contained working URLs for a few more .vg2 samples. Some other clues led me to a Russian language forum where someone had linked to a site that had Win32 codec modules that could process the files. The site was defunct but the Internet Archive Wayback Machine kept a copy for me, as well as copies of several more .vg2 samples from a defunct Japanese site previously involved with this codec.

  Sometimes this internet technology works really well. But I digress.

  Anyway, through all this, I finally found a clue : XVD. and wouldn’t you know, there is already a basic page on the MultimediaWiki describing the technology. In fact, while VG2 is a custom container, the MultimediaWiki states that the video component has a FourCC of VGMV, and there is already a file named VGMV.avi in the root V-codecs/ samples directory, something I vow to correct (that’s a big pet peeve of mine– putting samples in the root V-codecs/ or A-codecs/ directories).

  XVD… XVD… XVD… why does that sound so familiar ? Oh, of course ; there is a company named XVD and they have an office in the Bay Area which I have passed on numerous occasions, like this morning :

  
  <

  Someone originally connected with the multimedia technology in question operates a website which contains an unofficial history of the XVD tech. At first, I was wondering if the technology was completely defunct (and should therefore be open sourced). But if XVD’s solutions page (dated 2010) is to be believed, the technology is still in service, and purported to be better than H.264 and VC-1 : “The current generation of XVD video compression technology provides better video quality at any given data rate than standards-based codecs (H.264 or VC-1) with four times lower encoding complexity (when compared with H.264 Main Profile).”

  If they say so. For my part, I’m just happy that I have finally figured out what this lamborghini_850kbps.vg2 is so that I can properly catalog it on the samples site, which I have now done, along with other samples and various codecs modules.

  This episode reminds me that there’s a branch office of Zygo Corporation close to my home (though the headquarters are far, far away). The companies you see in Silicon Valley. Anyway, long-time open source multimedia hackers will no doubt recognize Zygo from the ZyGo FourCC & video codec transported in QuickTime files that was almost decode-able using an H.263 decoder.

  
  
  

  I may never learn what Zygo’s core competency actually is, but I will always remember their multimedia tech every time I run past their office.