Recherche avancée

Médias (1)

Mot : - Tags -/école

Autres articles (82)

  • Encoding and processing into web-friendly formats

    13 avril 2011, par

    MediaSPIP automatically converts uploaded files to internet-compatible formats.
    Video files are encoded in MP4, Ogv and WebM (supported by HTML5) and MP4 (supported by Flash).
    Audio files are encoded in MP3 and Ogg (supported by HTML5) and MP3 (supported by Flash).
    Where possible, text is analyzed in order to retrieve the data needed for search engine detection, and then exported as a series of image files.
    All uploaded files are stored online in their original format, so you can (...)

  • MediaSPIP Player : problèmes potentiels

    22 février 2011, par

    Le lecteur ne fonctionne pas sur Internet Explorer
    Sur Internet Explorer (8 et 7 au moins), le plugin utilise le lecteur Flash flowplayer pour lire vidéos et son. Si le lecteur ne semble pas fonctionner, cela peut venir de la configuration du mod_deflate d’Apache.
    Si dans la configuration de ce module Apache vous avez une ligne qui ressemble à la suivante, essayez de la supprimer ou de la commenter pour voir si le lecteur fonctionne correctement : /** * GeSHi (C) 2004 - 2007 Nigel McNie, (...)

  • Supporting all media types

    13 avril 2011, par

    Unlike most software and media-sharing platforms, MediaSPIP aims to manage as many different media types as possible. The following are just a few examples from an ever-expanding list of supported formats : images : png, gif, jpg, bmp and more audio : MP3, Ogg, Wav and more video : AVI, MP4, OGV, mpg, mov, wmv and more text, code and other data : OpenOffice, Microsoft Office (Word, PowerPoint, Excel), web (html, CSS), LaTeX, Google Earth and (...)

Sur d’autres sites (5496)

  • H.264 conversion with FFmpeg (from a RTP stream)

    12 juillet 2014, par Toby

    Environment :

    I have an IP Camera, which is capable of streaming it’s data over RTP in a H.264 encoded format. This raw stream is recorded from the ethernet. With that data I have to work.

    Goal :

    In the end I want to have a *.mp4 file, which I can play with common Media Players (like VLC or Windows MP).

    What have I done so far :

    I take that raw stream data I have and parse it. Since the data has been transmitted via RTP I need to take care of the NAL Bytes, SPS and PPS.

    1. Write a raw file

    First I determine the type of each frame received over Ethernet. To do so, I parse the first two bytes of every RTP Payload, so I can get the 8 NAL Unit Bit, the Fragment Type Bits and the Start, Reserved and End Bit. In the payload, they’re arranged like this :

    Byte 1: [          3 NAL Unit Bits          | 5 Fragment Type Bits]
    Byte 2: [Start Bit | Reserved Bit | End Bit | 5 NAL Unit Bits]

    From this I can determine :

    • Start and End of
      a Video Frame -> Start Bit and End Bit
    • Type of the Payload -> 5 Fragment Type Bits
    • NAL Unit Byte

    The Fragment types which are necessary in my case are :

    Fragment Type  7 = SPS
    Fragment Type  8 = PPS
    Fragment Type 28 = Video Fragment

    The NAL Byte is created by putting the NAL Unit Bits from Byte 1 and 2 together.

    Now depending on the fragmentation type I do the following :

    SPS/PPS :

    1. Write the NAL Prefix (0x00 0x00 0x01) and then the SPS or PPS data

    Fragmentation with Start Bit

    1. Write NAL Prefix
    2. Write NAL Unit Byte
    3. Write remaining raw data

    Fragmentation without Start Bit

    1. Write raw data

    This means my raw file looks something like this :

    [NAL Prefix][SPS][NAL Prefix][PPS][NAL Prefix][NAL Unit Byte][Raw Video Data][Raw Video Data]....[NAL Prefix][NAL Unit Byte][Raw Video Data]...

    For every PPS and SPS I find in my stream data, I just write a NAL Prefix ( 0x00 0x00 0x01 ) and then the SPS/PPS itself.

    Now I can’t play this data with some media player, which leads me to :

    2. Convert the file

    Since I wanted to avoid working much with codecs I just went to use an existing application -> FFmpeg. This I am calling with those parameters :

    ffmpeg.exe -f h264 -i <rawinputfile> -vcodec copy -r 25 <outputfilename>.mp4</outputfilename></rawinputfile>

    -f h264 : This should tell ffmpeg I have a h264 coded stream

    -vcodec copy : Quote from the manpage :

    Force video codec to codec. Use the "copy" special value to tell that the raw codec data must be copied as is.

    -r 25 : Sets the framerate to 25 FPS.

    When I call ffmpeg with those parameters I get an .mp4 File, which I can play with VLC and Windows MP, so it actually works. But the file now looks a bit different from my raw file.

    This leads me to my question :

    What did I actually do ?

    My problem is not that it is not working. I just want/need to know what I have actually done with calling ffmpeg. I had a raw H264 file which I could not play. After using FFmpeg I can play it.

    There are the following differences between the original raw file (which I have written) and the one written by FFmpeg :

    1. Header : The FFmpeg File has like about 0x30 Bytes of Header
    2. Footer : The FFmpeg File also has a footer
    3. Changed Prefix and 2 new Bytes :

    While a new Video Frame from the Raw File started like
    [NAL Prefix][NAL Unit Byte][Raw Video Data] in the new file it looks like this :

    [0x00 0x00][2 "Random" Bytes][NAL Unit Byte][Raw Video Data].....[0x00 0x00[2 other "Random" Bytes][NAL Unit Byte][Raw Video Data]...

    I understand that the Video Stream needs a container format (correct me if I am wrong but I assume that the new header and footer are responsible for that). But why does it change actually some Bytes in the raw data ? It can’t be some decoding since the stream itself should get decoded by the player and not ffmpeg.

    As you can see I don’t need a new solution for my problem as far more an explanation (so I can explain it by myself). What does ffmpeg actually do ? And why does it change some bytes within the video data ?

  • avcodec/flac_parser : Fix off-by-one error

    6 octobre 2019, par Andreas Rheinhardt
    avcodec/flac_parser : Fix off-by-one error
    

    The flac parser uses a fifo to buffer its data. Consequently, when
    searching for sync codes of flac packets, one needs to take care of
    the possibility of wraparound. This is done by using an optimized start
    code search that works on each of the continuous buffers separately and
    by explicitly checking whether the last pre-wrap byte and the first
    post-wrap byte constitute a valid sync code.

    Moreover, the last MAX_FRAME_HEADER_SIZE - 1 bytes ought not to be searched
    for (the start of) a sync code because a header that might be found in this
    region might not be completely available. These bytes ought to be searched
    lateron when more data is available or when flushing.

    Unfortunately there was an off-by-one error in the calculation of the
    length to search of the post-wrap buffer : It was too large, because the
    calculation was based on the amount of bytes available in the fifo from
    the last pre-wrap byte onwards. This meant that a header might be
    parsed twice (once prematurely and once regularly when more data is
    available) ; it could also mean that an invalid header will be treated as
    valid (namely if the length of said invalid header is
    MAX_FRAME_HEADER_SIZE and the invalid byte that will be treated as the
    last byte of this potential header happens to be the right CRC-8).

    Should a header be parsed twice, the second instance will be the best child
    of the first instance ; the first instance's score will be
    FLAC_HEADER_BASE_SCORE - FLAC_HEADER_CHANGED_PENALTY ( = 3) higher than
    the second instance's score. So the frame belonging to the first
    instance will be output and it will be done as a zero length frame (the
    difference of the header's offset and the child's offset). This has
    serious consequences when flushing, as returning a zero length buffer
    signals to the caller that no more data will be output ; consequently the
    last frames not yet output will be dropped.

    Furthermore, a "sample/frame number mismatch in adjacent frames" warning
    got output when returning the zero-length frame belonging to the first
    header, because the child's sample/frame number of course didn't match
    the expected sample frame/number given its parent.

    filter/hdcd-mix.flac from the FATE-suite was affected by this (the last
    frame was omitted) which is the reason why several FATE-tests needed to
    be updated.

    Fixes ticket #5937.

    Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

    • [DH] libavcodec/flac_parser.c
    • [DH] tests/fate/filter-audio.mak
  • Reading live output from FFMPEG using PHP

    29 septembre 2018, par user561787

    the problem i’m dealing with is getting the shell output from a ffmpeg command while it’s being executed and writing it in an html page using php.

    After some research i found a very similar request here :Update page content from live PHP and Python output using Ajax, which seemed to be perfect, but it’s not working at all.

    The basic idea is to use an AJAX request to invoke the PHP script, which should execute the command and echo the live read content from the process, taking care to use this.readyState==3 (otherwise the JS script would receive the response only upon completion)

    For the PHP section i tried using the code in the answer above, (obviously adapted to my needs) :

    function liveExecuteCommand($command){

       while (@ ob_end_flush()); // end all output buffers if any

       $proc = popen($command, 'r');

       $live_output     = "";
       $complete_output = "";

       while (!feof($proc))
       {
           $live_output     = fread($proc, 4096);
           $complete_output = $complete_output . $live_output;
           echo "<pre>$live_output</pre>";
           @ flush();
       }

       pclose($proc);          

    }

    And for the AJAX section i used

    function getLiveStream(){


           var ajax = new XMLHttpRequest();
             ajax.onreadystatechange = function() {
               if (this.readyState == 3) {

                 document.getElementById("result").innerHTML = this.responseText;
               }              
           };          
           var url = 'process/getlive';
           ajax.open('GET', url,true);
           ajax.send();
      }

    Which sadly doesn’t work.

    The command being executed is this : 'ffmpeg.exe -i "C:/Users/BACKUP/Desktop/xampp/htdocs/testarea/test.mp4" -map 0:0 -map 0:1 -c:v libx264 -preset fast -crf 26 -c:a libmp3lame -ar 24000 -q:a 5 "C:\Users\BACKUP\Desktop\xampp\htdocs\testarea\output/test.mkv"', which i tested and it works.

    When i run the html page and the ajax script within, the ffmpeg command doesn’t even run, as i checked in task managet. It simply returns a blank text.

    When i run the php script by itself, the command runs, the file is converted but it doesn’t echo anything at all.

    After some more research i also found this page, which seems to be made for this exact purpose : https://github.com/4poc/php-live-transcode/blob/master/stream.php

    The relevant section is at the end, the code before is for dealing with options specific to ffmpeg. But it didn’t work either, with the same exact outcomes.

    Now i’m considering simply writing the output to a file and reading it from it dinamically, but i’d really like to know the reason why they both don’t work for me.

    EDIT : PHP Execute shell command asynchronously and retrieve live output answers to how to get content from a temporary file that is being written, not directly from the process.