Recherche avancée

Sur d’autres sites (7856)

• PC Video Conferencing in the Year 1999

  21 juin 2011, par Multimedia Mike — General

  Remember Intel’s custom flavor of H.263 cleverly named I.263 ? I think I have finally found an application that used it thanks to a recent thrift shop raid— Intel Video Phone :

  
  
  

  The root directory of the disc has 2 copies of an intro.avi video. One copy uses Intel Indeo 3 video and PCM audio. The other uses I.263 video and an undetermined (presumably Intel-proprietary) audio codec — RIFF id 0x0402 at a bitrate of 88 kbits/sec for stereo, 22 kHz audio. The latter video looks awful but is significantly smaller (like 4 MB vs. 25 MB).

  This is the disc marked as "Send it to a friend...". Here’s the way this concept was supposed to operate :

  • You buy an Intel Video Phone Camera Pack (forgotten page courtesy of the Internet Archive) which includes a camera and 2 CDs.
  • You install the camera and video phone software on your computer.
  • You send the other CD to the person whom you want to be able to see your face when you’re teleconferencing with them.
  • The other party installs the software.
  • The 2 of you may make an internet phone call presumably using commodity PC microphones for the voice component ; the person who doesn’t have a camera is able to see the person who does have a camera.
  • In a cunning viral/network marketing strategy, Intel encourages the other party to buy the physical hardware as well so that they may broadcast their own visage back to the other person.

  If you need further explanation, the intro lady does a great job :

  
  
  

  I suspect I.263 was the video codec driving this since Indeo 3 would probably be inappropriate for real time video applications due to its vector quantizing algorithm.

• FFmpeg avcodec_decode_video2 decode RTSP H264 HD-video packet to video picture with error

  29 mai 2018, par Nguyen Ba Thi

  I used FFmpeg library version 4.0 to have simple C++ program, in witch is a thread to receive RTSP H264 video data from IP-camera and display it in program window.

  Code of this thread is follow :

  DWORD WINAPI GrabbProcess(LPVOID lpParam)
  
  // Grabbing thread
  
  {
  
    DWORD i;
  
    int ret = 0, nPacket=0;
  
    FILE *pktFile;
  
    // Open video file
  
    pFormatCtx = avformat_alloc_context();
  
    if(avformat_open_input(&pFormatCtx, nameVideoStream, NULL, NULL)!=0)
  
        fGrabb=-1; // Couldn't open file
  
    else
  
    // Retrieve stream information
  
    if(avformat_find_stream_info(pFormatCtx, NULL)<0)
  
        fGrabb=-2; // Couldn't find stream information
  
    else
  
    {
  
        // Find the first video stream
  
        videoStream=-1;
  
        for(i=0; inb_streams; i++)
  
          if(pFormatCtx->streams[i]->codec->codec_type==AVMEDIA_TYPE_VIDEO)
  
          {
  
            videoStream=i;
  
            break;
  
          }
  
        if(videoStream==-1)
  
            fGrabb=-3; // Didn't find a video stream
  
        else
  
        {
  
            // Get a pointer to the codec context for the video stream
  
            pCodecCtxOrig=pFormatCtx->streams[videoStream]->codec;
  
            // Find the decoder for the video stream
  
            pCodec=avcodec_find_decoder(pCodecCtxOrig->codec_id);
  
            if(pCodec==NULL)
  
                fGrabb=-4; // Codec not found
  
            else
  
            {
  
                // Copy context
  
                pCodecCtx = avcodec_alloc_context3(pCodec);
  
                if(avcodec_copy_context(pCodecCtx, pCodecCtxOrig) != 0)
  
                    fGrabb=-5; // Error copying codec context
  
                else
  
                {
  
                    // Open codec
  
                    if(avcodec_open2(pCodecCtx, pCodec, NULL)<0)
  
                        fGrabb=-6; // Could not open codec
  
                    else
  
                    // Allocate video frame for input
  
                    pFrame=av_frame_alloc();
  
                    // Determine required buffer size and allocate buffer
  
                    numBytes=avpicture_get_size(pCodecCtx->pix_fmt, pCodecCtx->width,
  
                        pCodecCtx->height);
  
                    buffer=(uint8_t *)av_malloc(numBytes*sizeof(uint8_t));
  
                    // Assign appropriate parts of buffer to image planes in pFrame
  
                    // Note that pFrame is an AVFrame, but AVFrame is a superset
  
                    // of AVPicture
  
                    avpicture_fill((AVPicture *)pFrame, buffer, pCodecCtx->pix_fmt,
  
                        pCodecCtx->width, pCodecCtx->height);
  
  
  
                    // Allocate video frame for display
  
                    pFrameRGB=av_frame_alloc();
  
                    // Determine required buffer size and allocate buffer
  
                    numBytes=avpicture_get_size(AV_PIX_FMT_RGB24, pCodecCtx->width,
  
                        pCodecCtx->height);
  
                    bufferRGB=(uint8_t *)av_malloc(numBytes*sizeof(uint8_t));
  
                    // Assign appropriate parts of buffer to image planes in pFrameRGB
  
                    // Note that pFrameRGB is an AVFrame, but AVFrame is a superset
  
                    // of AVPicture
  
                    avpicture_fill((AVPicture *)pFrameRGB, bufferRGB, AV_PIX_FMT_RGB24,
  
                        pCodecCtx->width, pCodecCtx->height);
  
                    // initialize SWS context for software scaling to FMT_RGB24
  
                    sws_ctx_to_RGB = sws_getContext(pCodecCtx->width,
  
                        pCodecCtx->height,
  
                        pCodecCtx->pix_fmt,
  
                        pCodecCtx->width,
  
                        pCodecCtx->height,
  
                        AV_PIX_FMT_RGB24,
  
                        SWS_BILINEAR,
  
                        NULL,
  
                        NULL,
  
                        NULL);
  
  
  
                    // Allocate video frame (grayscale YUV420P) for processing
  
                    pFrameYUV=av_frame_alloc();
  
                    // Determine required buffer size and allocate buffer
  
                    numBytes=avpicture_get_size(AV_PIX_FMT_YUV420P, pCodecCtx->width,
  
                        pCodecCtx->height);
  
                    bufferYUV=(uint8_t *)av_malloc(numBytes*sizeof(uint8_t));
  
                    // Assign appropriate parts of buffer to image planes in pFrameYUV
  
                    // Note that pFrameYUV is an AVFrame, but AVFrame is a superset
  
                    // of AVPicture
  
                    avpicture_fill((AVPicture *)pFrameYUV, bufferYUV, AV_PIX_FMT_YUV420P,
  
                        pCodecCtx->width, pCodecCtx->height);
  
                    // initialize SWS context for software scaling to FMT_YUV420P
  
                    sws_ctx_to_YUV = sws_getContext(pCodecCtx->width,
  
                        pCodecCtx->height,
  
                        pCodecCtx->pix_fmt,
  
                        pCodecCtx->width,
  
                        pCodecCtx->height,
  
                        AV_PIX_FMT_YUV420P,
  
                        SWS_BILINEAR,
  
                        NULL,
  
                        NULL,
  
                        NULL);
  
                  RealBsqHdr.biWidth = pCodecCtx->width;
  
                  RealBsqHdr.biHeight = -pCodecCtx->height;
  
                }
  
            }
  
        }
  
    }
  
    while ((fGrabb==1)||(fGrabb==100))
  
    {
  
        // Grabb a frame
  
        if (av_read_frame(pFormatCtx, &packet) >= 0)
  
        {
  
          // Is this a packet from the video stream?
  
          if(packet.stream_index==videoStream)
  
          {
  
              // Decode video frame
  
              int len = avcodec_decode_video2(pCodecCtx, pFrame, &frameFinished, &packet);
  
              nPacket++;
  
              // Did we get a video frame?
  
              if(frameFinished)
  
              {
  
                  // Convert the image from its native format to YUV
  
                  sws_scale(sws_ctx_to_YUV, (uint8_t const * const *)pFrame->data,
  
                      pFrame->linesize, 0, pCodecCtx->height,
  
                      pFrameYUV->data, pFrameYUV->linesize);
  
                  // Convert the image from its native format to RGB
  
                  sws_scale(sws_ctx_to_RGB, (uint8_t const * const *)pFrame->data,
  
                      pFrame->linesize, 0, pCodecCtx->height,
  
                      pFrameRGB->data, pFrameRGB->linesize);
  
                  HDC hdc=GetDC(hWndM);
  
                  SetDIBitsToDevice(hdc, 0, 0, pCodecCtx->width, pCodecCtx->height,
  
                      0, 0, 0, pCodecCtx->height,pFrameRGB->data[0], (LPBITMAPINFO)&RealBsqHdr, DIB_RGB_COLORS);
  
                  ReleaseDC(hWndM,hdc);
  
                  av_frame_unref(pFrame);
  
              }
  
          }
  
          // Free the packet that was allocated by av_read_frame
  
          av_free_packet(&packet);
  
        }
  
     }
  
     // Free the org frame
  
    av_frame_free(&pFrame);
  
    // Free the RGB frame
  
    av_frame_free(&pFrameRGB);
  
    // Free the YUV frame
  
    av_frame_free(&pFrameYUV);
  
  
  
    // Close the codec
  
    avcodec_close(pCodecCtx);
  
    avcodec_close(pCodecCtxOrig);
  
  
  
    // Close the video file
  
    avformat_close_input(&pFormatCtx);
  
    avformat_free_context(pFormatCtx);
  
  
  
    if (fGrabb==1)
  
        sprintf(tmpstr,"Grabbing Completed %d frames", nCntTotal);
  
    else if (fGrabb==2)
  
        sprintf(tmpstr,"User break on %d frames", nCntTotal);
  
    else if (fGrabb==3)
  
        sprintf(tmpstr,"Can't Grabb at frame %d", nCntTotal);
  
    else if (fGrabb==-1)
  
        sprintf(tmpstr,"Couldn't open file");
  
    else if (fGrabb==-2)
  
        sprintf(tmpstr,"Couldn't find stream information");
  
    else if (fGrabb==-3)
  
        sprintf(tmpstr,"Didn't find a video stream");
  
    else if (fGrabb==-4)
  
        sprintf(tmpstr,"Codec not found");
  
    else if (fGrabb==-5)
  
        sprintf(tmpstr,"Error copying codec context");
  
    else if (fGrabb==-6)
  
        sprintf(tmpstr,"Could not open codec");
  
    i=(UINT) fGrabb;
  
    fGrabb=0;
  
    SetWindowText(hWndM,tmpstr);
  
    ExitThread(i);
  
    return 0;
  
  }
  
  // End Grabbing thread  

  When program receive RTSP H264 video data with resolution 704x576 then decoded video pictures are OK. When receive RTSP H264 HD-video data with resolution 1280x720 it look like that first video picture is decoded OK and then video pictures are decoded but always with some error.

  Please help me to fix this problem !

  Here is problems brief :
  I have an IP camera model HI3518E_50H10L_S39 (product of China).
  Camera can provide H264 video stream both at resolution 704x576 (with RTSP URI "rtsp ://192.168.1.18:554/user=admin_password=tlJwpbo6_channel=1_stream=1.sdp ?real_stream") or 1280x720 (with RTSP URI "rtsp ://192.168.1.18:554/user=admin_password=tlJwpbo6_channel=1_stream=0.sdp ?real_stream").
  Using FFplay utility I can access and display them with good picture quality.
  For testing of grabbing from this camera, I have a simple (above mentioned) program in VC-2005. In "Grabbing thread" program use FFmpeg library version 4.0 for opening camera RTSP stream, retrieve stream information, find the first video stream... and prepare some variables.
  Center of this thread is loop : Grab a frame (function av_read_frame) - Decode it if it’s video (function avcodec_decode_video2) - Convert to RGB format (function sws_scale) - Display to program window (GDI function SetDIBitsToDevice).
  When proram run with camera RTSP stream at resolution 704x576, I have good video picture. Here is a sample :
  704x576 sample
  When program run with camera RTSP stream at resolution 1280x720, first video picture is good :
  First good at res.1280x720
  but then not good :
  not good at res.1280x720
  Its seem to be my FFmpeg function call to avcodec_decode_video2 can’t fully decode certain packet for some reasons.

• Further Dreamcast Hacking

  3 février 2011, par Multimedia Mike — Sega Dreamcast

  I’m still haunted by Sega Dreamcast programming, specifically the fact that I used to be able to execute custom programs on the thing (roughly 8-10 years ago) and now I cannot. I’m going to compose a post to describe my current adventures on this front. There are 3 approaches I have been using : Raw, Kallistios, and the almighty Linux.

  
  

  Raw
  What I refer to as "raw" is an assortment of programs that lived in a small number of source files (sometimes just one ASM file) and could be compiled with the most basic SH-4 toolchain. The advantage here is that there aren’t many moving parts and not many things that can possibly go wrong, so it provides a good functional baseline.

  One of the original Dreamcast hackers was Marcus Comstedt, who still has his original DC material hosted at the reasonably easy-to-remember URL mc.pp.se/dc. I can get some of these simple demos to work, but not others.

  I also successfully assembled and ran a pair of 256-byte (!!) demos from this old DC scene page.

  KallistiOS
  KallistiOS (or just KOS) was a real-time OS developed for the DC and was popular among the DC homebrew community. All the programming I did back in the day was based around KOS. Now I can’t get any of it to work. More specifically, KOS can’t seem to make it past a certain point in its system initialization.

  The Linux Option
  I was never that excited about running Linux on my Dreamcast. For some hackers, running Linux on a given piece of consumer electronics is the highest attainable goal. Back in the day, I looked at it from a much more pragmatic perspective— I didn’t see much use in running Linux on the DC, not as much as running KOS which was developed to be a much more appropriate fit.

  However, I was able to burn a CD-R of an old binary image of Linux 2.4.5 compiled for the Dreamcast and boot it some months ago. So I at least have a feeling that this should work. I have never cross-compiled a kernel of my own (though I have compiled many, many x86 kernels in my time, so I’m not a total n00b in this regard). I figured this might be a good time to start.

  The first item that worries me is getting a functional cross-compiling toolchain. Fortunately, a little digging in the Linux kernel documentation pointed me in the direction of a bunch of ready-made toolchains hosted at kernel.org. So I grabbed one of the SH toolchains (gcc-4.3.3-nolibc) and got rolling.

  I’m well familiar with the cycle of 'make menuconfig' in order to pick configuration options, and then 'make' to build a kernel (or usually 'make zImage' or 'make bzImage' to create compressed images). For cross compiling, the primary difference seems to be editing the root Makefile in the Linux source code tree (I’m using 2.6.37, the latest stable as of this writing) and setting a value for the CROSS_COMPILE variable. Then, run 'make menuconfig' followed by 'make' as normal.

  The Linux 2.6 series is supposed to support a range of Renesas (formerly Hitachi) SH processors and board configurations. This includes reasonable defaults for the Sega Dreamcast hardware. I got it all compiling except for a series of .S files. Linus Torvalds once helped me debug a program I work on so I thought I’d see if there was something I could help debug here.

  The first issue was with ASM statements of a form similar to :

  mov #0xffffffe0, r1
  

  Now, the DC’s SH-4 is a RISC CPU. A lot of RISC architectures adopt a fixed instruction size of 32 bits. You can’t encode an entire 32-bit immediate value inside of a 32-bit instruction (there would be no room for the instruction encoding). Further, the SH series encoded instructions with a mere 16 bits. The move immediate data instruction only allows for an 8-bit, sign-extended value.

  I decided that the above statement is equivalent to :

  mov #-32, r1
  

  I’ll give this statement the benefit of the doubt that it used to work with the gcc toolchain somewhere along the line. I assume that the assembler is supposed to know enough to substitute the first form with the second.

  The next problem is that an ’sti’ instruction shows up in a number of spots. Using Intel x86 conventions, this is a "set interrupt flag" instruction (I remember that the 6502 CPU had the same instruction mnemonic, though its interrupt flag’s operation was opposite that of the x86). The SH-4 reference manual lists no ’sti’ instruction. When it gets to these lines, the assembler complains about immediate move instructions with too large data, like the instructions above. I’m guessing they must be macro’d to something else but I failed to find where. I commented out those lines for the time being. Probably not that smart, but I want to keep this moving for now.

  So I got the code to compile into a kernel file called ’vmlinux’. I’ve seen this file many times before but never thought about how to get it to run directly. The process has usually been to compress it and send it over to lilo or grub for loading, as that is the job of the bootloader. I have never even wondered what format the vmlinux file takes until now. It seems that ’vmlinux’ is just a plain old ELF file :

  $ file vmlinux
  vmlinux : ELF 32-bit LSB executable, Renesas SH,
  version 1 (SYSV), statically linked, not stripped
  

  The ’dc-tool’ program that uploads executables to the waiting bootloader on the Dreamcast is perfectly cool accepting ELF files (and S-record files, and raw binary files). After a very lengthy upload process, execution fails (resets the system).

  For the sake of comparison, I dusted off that Linux 2.4.5 bootable Dreamcast CD-ROM and directly uploaded the vmlinux file from that disc. That works just fine (until it’s time to go to the next loading phase, i.e., finding a filesystem). Possible issues here could include the commented ’sti’ instructions (could be that they aren’t just decoration). I’m also trying to understand the memory organization— perhaps the bootloader wants the ELF to be based at a different address. Or maybe the kernel and the bootloader don’t like each other in the first place— in this case, I need to study the bootable Linux CD-ROM to see how it’s done.

  Optimism
  Even though I’m meeting with rather marginal success, this is tremendously educational. I greatly enjoy these exercises if only for the deeper understanding they bring for the lowest-level system details.