Recherche avancée

Médias (1)

Mot : - Tags -/école

Autres articles (37)

  • XMP PHP

    13 mai 2011, par

    Dixit Wikipedia, XMP signifie :
    Extensible Metadata Platform ou XMP est un format de métadonnées basé sur XML utilisé dans les applications PDF, de photographie et de graphisme. Il a été lancé par Adobe Systems en avril 2001 en étant intégré à la version 5.0 d’Adobe Acrobat.
    Étant basé sur XML, il gère un ensemble de tags dynamiques pour l’utilisation dans le cadre du Web sémantique.
    XMP permet d’enregistrer sous forme d’un document XML des informations relatives à un fichier : titre, auteur, historique (...)

  • Participer à sa documentation

    10 avril 2011

    La documentation est un des travaux les plus importants et les plus contraignants lors de la réalisation d’un outil technique.
    Tout apport extérieur à ce sujet est primordial : la critique de l’existant ; la participation à la rédaction d’articles orientés : utilisateur (administrateur de MediaSPIP ou simplement producteur de contenu) ; développeur ; la création de screencasts d’explication ; la traduction de la documentation dans une nouvelle langue ;
    Pour ce faire, vous pouvez vous inscrire sur (...)

  • Encodage et transformation en formats lisibles sur Internet

    10 avril 2011

    MediaSPIP transforme et ré-encode les documents mis en ligne afin de les rendre lisibles sur Internet et automatiquement utilisables sans intervention du créateur de contenu.
    Les vidéos sont automatiquement encodées dans les formats supportés par HTML5 : MP4, Ogv et WebM. La version "MP4" est également utilisée pour le lecteur flash de secours nécessaire aux anciens navigateurs.
    Les documents audios sont également ré-encodés dans les deux formats utilisables par HTML5 :MP3 et Ogg. La version "MP3" (...)

Sur d’autres sites (6178)

  • Dreamcast Anniversary Programming

    10 septembre 2010, par Multimedia Mike — Game Hacking

    This day last year saw a lot of nostalgia posts on the internet regarding the Sega Dreamcast, launched 10 years prior to that day (on 9/9/99). Regrettably, none of the retrospectives that I read really seemed to mention the homebrew potential, which is the aspect that interested me. On the occasion of the DC’s 11th anniversary, I wanted to remind myself how to build something for the unit and do so using modern equipment and build tools.



    Background
    Like many other programmers, I initially gained interest in programming because I desired to program video games. Not content to just plunk out games on a PC, I always had a deep, abiding ambition to program actual video game hardware. That is, I wanted to program a purpose-built video game console. The Sega Dreamcast might be the most ideal candidate to ever emerge for that task. All that was required to run your own software on the unit was the console, a PC, some free software tools, and a special connectivity measure.

    The Equipment
    Here is the hardware required (ideally) to build software for the DC :

    • The console itself (I happen to have 3 of them laying around, as pictured above)
    • Some peripherals : Such as the basic DC controller, the DC keyboard (flagship title : Typing of the Dead), and the visual memory unit (VMU)


    • VGA box : The DC supported 480p gaming via a device that allowed you to connect the console straight to a VGA monitor via 15-pin D-sub. Not required for development, but very useful. I happen to have 3 of them from different third parties :


    • Finally, the connectivity measure for hooking the DC to the PC.
      There are 2 options here. The first is rare, expensive and relatively fast : A DC broadband adapter. The second is slower but much less expensive and relatively easy to come by– the DC coder’s cable. This was a DB-9 adapter on one end and a DC serial adapter on the other, and a circuit in the middle to monkey with voltage levels or some such ; I’m no electrical engineer. I procured this model from the notorious Lik Sang, well before that outfit was sued out of business.


    Dealing With Legacy
    Take a look at that coder’s cable again. DB-9 ? When was the last time you owned a computer with one of those ? And then think farther back to the last time to had occasion to plug something into one of those ports (likely a serial mouse).



    A few years ago, someone was about to toss out this Belkin USB to DB-9 serial converter when I intervened. I foresaw the day when I would dust off the coder’s cable. So now I can connect a USB serial cable to my Eee PC, which then connects via converter to a different serial cable, one which has its own conversion circuit that alters the connection to yet another type of serial cable.

    Bits is bits is bits as far as I’m concerned.



    Putting It All Together
    Now to assemble all the pieces (plus a monitor) into one development desktop :



    The monitor says “dcload 1.0.3, idle…”. That’s a custom boot CD-ROM that is patiently waiting to receive commands, code and data via the serial port.

    Getting The Software
    Back in the day, homebrew software development on the DC revolved around these components :

    • GNU binutils : for building base toolchains for the Hitachi SH-4 main CPU as well as the ARM7-based audio coprocessor
    • GNU gcc/g++ : for building compilers on top of binutils for the 2 CPUs
    • Newlib : a C library intended for embedded systems
    • KallistiOS : an open source, real-time OS developed for the DC

    The DC was my first exposure to building cross compilers. I developed some software for the DC in the earlier part of the decade. Now, I am trying to figure out how I did it, especially since I think I came up with a few interesting ideas at the time.

    Struggling With the Software Legacy
    The source for KallistiOS has gone untouched since about 2004 but is still around thanks to Sourceforge. The instructions for properly building the toolchain have been lost to time, or would be were it not for the Internet Archive’s copy of a site called Hangar Eleven. Also, KallistiOS makes reference to a program called ‘dc-tool’ which is needed on the client side for communicating with dcload. I was able to find this binary at the Boob ! site (well-known in DC circles).

    I was able to build the toolchain using binutils 2.20.1, gcc 4.5.1 and newlib 1.18.0. Building the toolchain is an odd process as it requires building the binutils, then building the C compiler, then newlib, and then building the C compiler again along with the C++ compiler because the C++ compiler depends on newlib.

    With some effort, I got the toolchain to build KallistiOS and most of its example programs. I documented most of the tweaks I had to make, several of them exactly the same as this one that I recently discovered while resurrecting a 10-year-old C program (common construct in C programming of old ?).

    Moment of Truth
    So I had some example programs built as ELF files. I told dc-tool to upload and run them on the waiting console. Unfortunately, the tool would just sort of stall, though some communication had evidently taken place. It has been many years since I have seen this in action but I recall that something more ought to be happening.

    Plan B (Hardware)
    This is the point that I remember that I have been holding onto one rather old little machine that still has a DB-9 serial port. It’s not especially ergonomic to set up. I have to run it on my floor because, to connect it to my network, I need to run a 25′ ethernet cable that just barely reaches from the other room. The machine doesn’t seem to like USB keyboards, which is a shame since I have long since ditched any PS/2 keyboards. Fortunately, the box still has an old Gentoo distro and is running sshd, a holdover from its former life as a headless box.



    Now when I run dc-tool, both the PC and DC report the upload progress while pretty overscan bars oscillate on the DC’s monitor. Now I’m back in business, until…

    Plan C (Software)
    None of these KallistiOS example programs are working. Some are even reporting catastrophic failures (register dumps) via the serial console. That’s when I remember that gcc can be a bit fickle on CPU architectures that are not, shall we say, first-class citizens. Back in the day, gcc 2.95 was a certified no-go for SH-4 development. 3.0.3 or 3.0.4 was called upon at the time. As I’m hosting this toolchain on x86_64 right now, gcc 3.0.4 can’t even be built (predates the architecture).

    One last option : As I searched through my old DC project directories, I found that I still have a lot of the resulting binaries, the ones I built 7-8 years ago. I upload a few of those and I finally see homebrew programming at work again, including this old program (described in detail here).

    Next Steps
    If I ever feel like revisiting this again, I suppose I can try some of the older 4.x series to see if they build valid programs. Alternatively, try building an x86_32-hosted 3.0.4 toolchain which ought to be a known good. And if that fails, search a little bit more to find that there are still active Dreamcast communities out there on the internet which probably have development toolchain binaries ready for download.

  • C++, FFmpeg, save AVPacket infomation into videostate structure in ffplay.c

    28 mai 2015, par Yoohoo

    I am currently working on a project that tests video streaming. In the project, video stream is encoded with H.264 before send and decoded after receive, using FFmpeg codec and functions.

    I can encode video stream by

    init_video_encode(AV_CODEC_ID_H264);

    where

    static void init_video_encode(AVCodecID codec_id){
    codec = avcodec_find_encoder(codec_id);
    if (!codec) {
       fprintf(stderr, "Codec not found\n");
       exit(1);
    }

    c = avcodec_alloc_context3(codec);
    if (!c) {
       fprintf(stderr, "Could not allocate video codec context\n");
       exit(1);
    }

    /* put sample parameters */
    c->bit_rate = 400000;
    /* resolution must be a multiple of two */
    c->width = 640;
    c->height = 480;
    /* frames per second */
    c->time_base= (AVRational){1,25};
    c->gop_size = 10; /* emit one intra frame every ten frames */
    c->max_b_frames=max_f;
    c->pix_fmt = AV_PIX_FMT_YUV420P;

    if(codec_id == AV_CODEC_ID_H264)
       av_opt_set(c->priv_data, "preset", "slow", 0);

    /* open it */
    if (avcodec_open2(c, codec, NULL) < 0) {
       fprintf(stderr, "Could not open codec\n");
       exit(1);
    }

    frame = avcodec_alloc_frame();
    if (!frame) {
       fprintf(stderr, "Could not allocate video frame\n");
       exit(1);
    }
    frame->format = c->pix_fmt;
    frame->width  = c->width;
    frame->height = c->height;

    /* the image can be allocated by any means and av_image_alloc() is
    * just the most convenient way if av_malloc() is to be used */
    ret = av_image_alloc(frame->data, frame->linesize, c->width, c->height,
                        c->pix_fmt, 32);

    /* get the delayed frames */
    if (ret < 0) {
       fprintf(stderr, "Could not allocate raw picture buffer\n");
       exit(1);
    }
       av_init_packet(&pkt);

    //}

       pkt.data = NULL;    // packet data will be allocated by the encoder
       pkt.size = 0;
       //cout<<"\nBefore YUV\n";
       if(count == 0)
       read_yuv420(frame->data[0]);
       count ++;
      // cout<<"\nAfter YUV\n";
       if(count == SUBSITY) {
       count = 0;
       }

       frame->pts = i++;

       /* encode the image */
       ret = avcodec_encode_video2(c, &pkt, frame, &got_output);
       if (ret < 0) {
            fprintf(stderr, "Error encoding frame\n");
            return -1;
       }
       //cout<<"\nRecord the Video\n";
       if (got_output) {
            //printf("Write frame %3d (size=%5d)\n", i, pkt.size);
            //cout<<"\nBefore Memcpy\n\n\n";

            memcpy(inbufout+totalSize,pkt.data,pkt.size);
            //cout<<"\nAfter Memcpy\n\n\n";
            totalSize+=pkt.size;

    The video encoder works very well, if I write the encoded packet into a .h264 file, it can be played. But at the decoder side, I cannot decode the received packet with :

       codec = avcodec_find_decoder(AV_CODEC_ID_H264);
       if (!codec) {
           fprintf(stderr, "Codec not found\n");
           exit(1);
       }

       c = avcodec_alloc_context3(codec);
       if (!c) {
           fprintf(stderr, "Could not allocate video codec context\n");
           exit(1);
       }

       if(codec->capabilities&CODEC_CAP_TRUNCATED)
           c->flags|= CODEC_FLAG_TRUNCATED;

       /* open it */
       if (avcodec_open2(c, codec, NULL) < 0) {
           fprintf(stderr, "Could not open codec\n");
           exit(1);
       }

       frame = avcodec_alloc_frame();
       if (!frame) {
           fprintf(stderr, "Could not allocate video frame\n");
           exit(1);
       }
    len = avcodec_decode_video2(avctx, frame, &got_frame, pkt);
       if (len < 0) {
           fprintf(stderr, "Error while decoding frame %d\n", *frame_count);
           return len;
       }

    The reason of failure is lacking parser, I have tried to build a parser but failed......

    Therefore I am wondering using ffplay.c as a header file in my receiver program so that I can use it as the decoder and player.

    I have took a look at ffplay.c, it actually fetch file into a videostate structure and processing it. The fetching part is from line 3188 of ffplay.c :

    VideoState *is;

       is = av_mallocz(sizeof(VideoState));
       if (!is)
           return NULL;
       av_strlcpy(is->filename, filename, sizeof(is->filename));
       is->iformat = iformat;
       is->ytop    = 0;
       is->xleft   = 0;

       /* start video display */
       if (frame_queue_init(&is->pictq, &is->videoq, VIDEO_PICTURE_QUEUE_SIZE, 1) < 0)
           goto fail;
       if (frame_queue_init(&is->subpq, &is->subtitleq, SUBPICTURE_QUEUE_SIZE, 0) < 0)
           goto fail;
       if (frame_queue_init(&is->sampq, &is->audioq, SAMPLE_QUEUE_SIZE, 1) < 0)
           goto fail;

       packet_queue_init(&is->videoq);
       packet_queue_init(&is->audioq);
       packet_queue_init(&is->subtitleq);

       is->continue_read_thread = SDL_CreateCond();

       init_clock(&is->vidclk, &is->videoq.serial);
       init_clock(&is->audclk, &is->audioq.serial);
       init_clock(&is->extclk, &is->extclk.serial);
       is->audio_clock_serial = -1;
       is->av_sync_type = av_sync_type;
       is->read_tid     = SDL_CreateThread(read_thread, is);
       if (!is->read_tid) {
    fail:
           stream_close(is);
           return NULL;
       }

    Now instead of fetching file, I want to modify ffplay.c code so that let it fetch the received packet, I can save received packet to AVPacket by

    static AVPacket avpkt;
    avpkt.data = inbuf;

    My question is : how to put AVPacket information into videostate structure ?

  • how to make cloud services for camera device iot monitoring and control

    16 novembre 2019, par guardian presence

    Looking to use ffmpeg to pull video trsp stream over tcp pass the video feeds to opencv for object recognition and tracking passing the output to ardunio serial control systems like alarm systems drones ardunio controlled lawn mores.

    Lets say some one has a cctv system and a drone laying around if they connect to my cloud the system can pull the stream from the cctv cameras pull the stream from the drone if object moves in on camera zone the cloud can control the drone to move to that zone and take a closer look at a face if face detected send alert return drone to docking . if ptz camera opencv tracking zooming to face

    if ros can turn into a cloud service need to know about hosting and
    building front end user login and device login.

    i’m a cctv installer new to programming and want to setup cloud login for camera iot devises were users can control and monitoring of devices from a central cloud