Recherche avancée

Médias (2)

Mot : - Tags -/rotation

Autres articles (99)

  • MediaSPIP 0.1 Beta version

    25 avril 2011, par

    MediaSPIP 0.1 beta is the first version of MediaSPIP proclaimed as "usable".
    The zip file provided here only contains the sources of MediaSPIP in its standalone version.
    To get a working installation, you must manually install all-software dependencies on the server.
    If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...)

  • Les vidéos

    21 avril 2011, par

    Comme les documents de type "audio", Mediaspip affiche dans la mesure du possible les vidéos grâce à la balise html5 .
    Un des inconvénients de cette balise est qu’elle n’est pas reconnue correctement par certains navigateurs (Internet Explorer pour ne pas le nommer) et que chaque navigateur ne gère en natif que certains formats de vidéos.
    Son avantage principal quant à lui est de bénéficier de la prise en charge native de vidéos dans les navigateur et donc de se passer de l’utilisation de Flash et (...)

  • Participer à sa traduction

    10 avril 2011

    Vous pouvez nous aider à améliorer les locutions utilisées dans le logiciel ou à traduire celui-ci dans n’importe qu’elle nouvelle langue permettant sa diffusion à de nouvelles communautés linguistiques.
    Pour ce faire, on utilise l’interface de traduction de SPIP où l’ensemble des modules de langue de MediaSPIP sont à disposition. ll vous suffit de vous inscrire sur la liste de discussion des traducteurs pour demander plus d’informations.
    Actuellement MediaSPIP n’est disponible qu’en français et (...)

Sur d’autres sites (11248)

  • libavformat : add RCWT closed caption muxex

    14 janvier 2024, par Marth64
    libavformat : add RCWT closed caption muxex
    

    Signed-off-by : Marth64 <marth64@proxyid.net>

    Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
    used open source tool for processing 608/708 closed caption (CC) sources.
    It can be used to archive the original, raw CC bitstream and to produce
    a source file file for later CC processing or conversion. As a result,
    it also allows for interopability with ccextractor for processing CC data
    extracted via ffmpeg. The format is simple to parse and can be used
    to retain all lines and variants of CC.

    A free specification of RCWT can be found here :
    https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT
    This muxer implements the specification as of 01/05/2024, which has
    been stable and unchanged for 10 years as of this writing.

    This muxer will have some nuances from the way that ccextractor muxes RCWT.
    No compatibility issues when processing the output with ccextractor
    have been observed as a result of this so far, but mileage may vary
    and outputs will not be a bit-exact match.

    Specifically, the differences are :
    (1) This muxer will identify as "FF" as the writing program identifier, so
    as to be honest about the output's origin.

    (2) ffmpeg's MPEG-1/2, H264, HEVC, etc. decoders extract closed captioning
    data differently than ccextractor from embedded SEI/user data.
    For example, DVD captioning bytes will be translated to ATSC A53 format.
    This allows ffmpeg to handle 608/708 in a consistant way downstream.
    This is a lossless conversion and the meaningful data is retained.

    (3) This muxer will not alter the extracted data except to remove invalid
    packets in between valid CC blocks. On the other hand, ccextractor
    will by default remove mid-stream padding, and add padding at the end
    of the stream (in order to convey the end time of the source video).

    • [DH] Changelog
    • [DH] doc/muxers.texi
    • [DH] libavformat/Makefile
    • [DH] libavformat/allformats.c
    • [DH] libavformat/rcwtenc.c
    • [DH] tests/fate/subtitles.mak
  • ffmpeg chains parameters and options while being used in a loop

    10 janvier 2024, par Simon Nazarenko

    I got a code that generates videos from scratch (got gifs, captions and audio). It works amazing when done once, however, when put in a loop and it should create more than 1 video it freezes being caused by memory leak. Upon investigation I realized that ffmpeg (v1.1.0) chains the loop iterations carrying the parameters and options from the first iteration to the second. It then breaks (overwrites) the first video and infinitely writes the second.

    &#xA;

    This is my dependency

    &#xA;

    const ffmpeg = require("fluent-ffmpeg")()&#xA;  .setFfprobePath(ffprobe.path)&#xA;  .setFfmpegPath(ffmpegInstaller.path)&#xA;

    &#xA;

    It looks like this

    &#xA;

    async function convertGifToVideo(&#xA;  gifFile,&#xA;  audioFile,&#xA;  subtitlesFile,&#xA;  tempDirectory&#xA;) {&#xA;  return new Promise((resolve, reject) => {&#xA;    const outputFile = `${tempDirectory}/video_${Date.now()}.mp4`&#xA;    &#xA;    ffmpeg&#xA;      .input(gifFile)&#xA;      .inputFormat("gif")&#xA;      .inputOptions("-stream_loop -1")&#xA;      .input(audioFile)&#xA;      .outputOptions("-shortest")&#xA;      .outputOptions(`-vf subtitles=${subtitlesFile}`)&#xA;      .outputOptions("-report")&#xA;      .output(outputFile)&#xA;      .on("end", () => {&#xA;        console.log(`Combined ${gifFile} and ${audioFile} into ${outputFile}`)&#xA;        resolve(outputFile)&#xA;      })&#xA;      .on("error", (err, stdout, stderr) => {&#xA;        console.error("Error combining GIF and audio:", err)&#xA;        console.error("ffmpeg stdout:", stdout)&#xA;        console.error("ffmpeg stderr:", stderr)&#xA;        reject(err)&#xA;      })&#xA;      .run()&#xA;  })&#xA;}&#xA;

    &#xA;

    And it's called in a loop

    &#xA;

    for (const key in script) {&#xA;    if (script.hasOwnProperty(key)) {&#xA;      ...stuff&#xA;&#xA;      const videoFileName = await convertGifToVideo(&#xA;        gifFileName,&#xA;        audioFileName,&#xA;        subtitlesFileName,&#xA;        tempDirectory&#xA;      )&#xA;    }&#xA;  }&#xA;

    &#xA;

    Here is a piece of log from the first video generation

    &#xA;

    &#xA;

    ffmpeg started on 2024-01-10 at 02:58:52&#xA;Report written to "ffmpeg-20240110-025852.log"&#xA;Command line :&#xA;/home/simon/Documents/AFYTUBE/node_modules/@ffmpeg-installer/linux-x64/ffmpeg -f gif -stream_loop -1 -i ./temp/gif_funny_frogs.gif -i ./temp/funny_frogs.mp3 -y -shortest -vf "subtitles=./temp/funny_frogs.srt" -report ./temp/video_1704880732780.mp4

    &#xA;

    &#xA;

    Here is a piece of log from the second one

    &#xA;

    &#xA;

    /home/simon/Documents/AFYTUBE/node_modules/@ffmpeg-installer/linux-x64/ffmpeg -f gif -stream_loop -1 -i ./temp/gif_funny_frogs.gif -i ./temp/funny_frogs.mp3 -f gif -stream_loop -1 -i ./temp/gif_leg_exercises.gif -i ./temp/leg_exercises.mp3 -y -shortest -vf "subtitles=./temp/funny_frogs.srt" -report -shortest -vf "subtitles=./temp/leg_exercises.srt" -report ./temp/video_1704880732780.mp4 ./temp/video_1704880750879.mp4

    &#xA;

    &#xA;

    Any ideas what I am doing wrong ?

    &#xA;

  • FFMPEG - copy the SPECIFED tracks only, ignore all others

    10 janvier 2024, par GDP

    I have some very strange MP4 files that we get regularly for processing created by Wowza. Neither FFMPEG or MEDIAINFO can detect that there are subtitles soft-coded in them, but they ARE there, I can extract them with ccextractor, and when they're played, the captions appear later in the video where the actually start in the timeline.

    &#xA;

    I've tried every variation of copying with/without re-encoding, but all the answers show how to "omit" the subtitles with -sn such as these :

    &#xA;

     ffmpeg -i 3078.mp4 -c copy -sn 3078_sn.mp4&#xA; ffmpeg -i 3078.mp4 -c:v libx264 -c:a ac3 -map 0:v:0 -map 0:a:1 3078_sn.mp4&#xA; ffmpeg -i 3078.mp4 -map 0:v:0 -map 0:a:0  -map -0:s -map -0:d  -c copy 3078_sn2.mp4 -y&#xA;

    &#xA;

    FFprobe :

    &#xA;

    ffprobe 3078.mp4 -hide_banner&#xA;[mov,mp4,m4a,3gp,3g2,mj2 @ 000001ef2bcd9e00] multiple fourcc not supported&#xA;Input #0, mov,mp4,m4a,3gp,3g2,mj2, from &#x27;3078.mp4&#x27;:&#xA;  Metadata:&#xA;    major_brand     : f4v&#xA;    minor_version   : 0&#xA;    compatible_brands: isommp42m4v&#xA;    creation_time   : 2024-01-09T19:59:28.000000Z&#xA;  Duration: 02:17:18.47, start: 0.000000, bitrate: 2165 kb/s&#xA;  Stream #0:0[0x1](eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 1902 kb/s, 29.96 fps, 29.97 tbr, 90k tbn (default)&#xA;    Metadata:&#xA;     creation_time   : 2024-01-09T19:59:28.000000Z&#xA;     handler_name    : WowzaStreamingEngine&#xA;     vendor_id       : [0][0][0][0]&#xA;     encoder         : WowzaStreamingEngine&#xA;  Stream #0:1[0x2](eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 257 kb/s (default)&#xA;    Metadata:&#xA;     creation_time   : 2024-01-09T19:59:28.000000Z&#xA;     handler_name    : WowzaStreamingEngine&#xA;     vendor_id       : [0][0][0][0]&#xA;  Stream #0:2[0x3](eng): Data: none (amf0 / 0x30666D61), 1 kb/s (default)&#xA;    Metadata:&#xA;     creation_time   : 2024-01-09T19:59:28.000000Z&#xA;     handler_name    : WowzaStreamingEngine&#xA;Unsupported codec with id 0 for input stream 2&#xA;

    &#xA;

    The problem seems to be that FFMPEG isn't detecting they're there, and so copies them anyways. My assumption is that they're not stored in the header of the MP4 properly (or however that's done), so get because they're later detect, but weren't omitted when it checked the header (pure guesswork on that).

    &#xA;

    So, is there a way to copy ONLY the video, regardless of whatEVER tracks may or not be in the file, then do the same for audio, and then merge the two single-track files ?

    &#xA;