Recherche avancée

Médias (91)

Autres articles (68)

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

  • 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 (...)

  • L’utiliser, en parler, le critiquer

    10 avril 2011

    La première attitude à adopter est d’en parler, soit directement avec les personnes impliquées dans son développement, soit autour de vous pour convaincre de nouvelles personnes à l’utiliser.
    Plus la communauté sera nombreuse et plus les évolutions seront rapides ...
    Une liste de discussion est disponible pour tout échange entre utilisateurs.

Sur d’autres sites (8033)

  • bad audio mic recording quality with ffmpeg compared to sox

    1er juillet 2021, par user2355330

    I am contacting you as after 3 days of searching I am stuck on a really simple point.

    


    I want to record the sound of my mic on MacOS using ffmpeg.

    


    I managed to do it using the following command :

    


    ffmpeg -f avfoundation -audio_device_index 2 -i "none:-" -c:a pcm_s32l alexspeaking.wav -y -loglevel debug


    


    The issue is that each time I am speaking, there are cracks and pop in the sound...

    


    I tried to use sox and it gave me a perfect and crystal clear sound and I have no idea why... Below is the output of the sox command :

    


    sox -t coreaudio "G935 Gaming Headset" toto.wav -V6
sox:      SoX v
time:     Nov 15 2020 01:06:02
uname:    Darwin MacBook-Pro.local 20.5.0 Darwin Kernel Version 20.5.0: Sat May  8 05:10:33 PDT 2021; root:xnu-7195.121.3~9/RELEASE_X86_64 x86_64
compiler: gcc Apple LLVM 12.0.0 (clang-1200.0.32.27)
arch:     1288 48 88 L
sox INFO coreaudio: Found Audio Device "DELL U2721DE"
sox INFO coreaudio: Found Audio Device "G935 Gaming "
sox DBUG coreaudio: audio device did not accept 2 channels. Use 1 channels instead.
sox DBUG coreaudio: audio device did not accept 44100 sample rate. Use 48000 instead.
Input File     : 'G935 Gaming Headset' (coreaudio)
Channels       : 1
Sample Rate    : 48000
Precision      : 32-bit
Sample Encoding: 32-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no
sox INFO sox: Overwriting `toto.wav'
sox DBUG wav: Writing Wave file: Microsoft PCM format, 1 channel, 48000 samp/sec
sox DBUG wav:         192000 byte/sec, 4 block align, 32 bits/samp
Output File    : 'toto.wav'
Channels       : 1
Sample Rate    : 48000
Precision      : 32-bit
Sample Encoding: 32-bit Signed Integer PCM
Endian Type    : little
Reverse Nibbles: no
Reverse Bits   : no
Comment        : 'Processed by SoX'
sox DBUG effects: sox_add_effect: extending effects table, new size = 8
sox INFO sox: effects chain: input        48000Hz  1 channels (multi) 32 bits unknown length
sox INFO sox: effects chain: output       48000Hz  1 channels (multi) 32 bits unknown length
sox DBUG sox: start-up time = 0.051332
In:0.00% 00:00:07.13 [00:00:00.00] Out:340k  [      |      ]        Clip:0    ^C
sox DBUG input: output buffer still held 2048 samples; dropped.
Aborted.
sox DBUG wav: Finished writing Wave file, 1359872 data bytes 339968 samples


    


    I am pretty sure the issue is linked to the way the encoding is done and the params I used with ffmpeg but I don't seem to be able to grasp which one I must use.

    


    Any ideas if there are ffmpeg experts here ?

    


  • Unable to merge videos using ffmpeg within Azure Batch

    7 juillet 2019, par JJuice

    Using a tutorial by MSDN I am trying to build a Batch operation, executed within an Azure Function that merges to videos using FFMPEG. Somehow I am doing something wrong because the merging fails.

    The code where I create the task to merge the videos :

    private static async Task> AddTasksAsync(BatchClient batchClient, string jobId, List<resourcefile> inputFiles, string outputContainerSasUrl)
       {
           Console.WriteLine("Adding {0} tasks to job [{1}]...", inputFiles.Count, jobId);

           // Create a collection to hold the tasks added to the job:
           List<cloudtask> tasks = new List<cloudtask>();

           // Assign a task ID for each iteration
           string taskId = String.Format("Task0");

           string appPath = String.Format("%AZ_BATCH_APP_PACKAGE_{0}#{1}%", appPackageId, appPackageVersion);
           Console.WriteLine(inputFiles[0].FilePath);
           Console.WriteLine(inputFiles[1].FilePath);
           Console.WriteLine(inputFiles[2].FilePath);
           string outputMediaFile = String.Format("ResultaatFilmpje.MOV");
           string taskCommandLine = String.Format("cmd /c {0}\\ffmpeg-20190706-feade2b-win64-static\\bin\\ffmpeg.exe -safe 0 -f concat -i {1} -c copy {2}",
                                               appPath, inputFiles[2].FilePath, outputMediaFile);

           // Create a cloud task (with the task ID and command line) and add it to the task list
           CloudTask task = new CloudTask(taskId, taskCommandLine);
           task.ResourceFiles = new List<resourcefile> { inputFiles[2] };

           // Task output file will be uploaded to the output container in Storage.

           List<outputfile> outputFileList = new List<outputfile>();
           OutputFileBlobContainerDestination outputContainer = new OutputFileBlobContainerDestination(outputContainerSasUrl);
           OutputFile outputFile = new OutputFile(outputMediaFile,
                                                   new OutputFileDestination(outputContainer),
                                                   new OutputFileUploadOptions(OutputFileUploadCondition.TaskSuccess));
           outputFileList.Add(outputFile);
           task.OutputFiles = outputFileList;
           tasks.Add(task);

           // Call BatchClient.JobOperations.AddTask() to add the tasks as a collection rather than making a
           // separate call for each. Bulk task submission helps to ensure efficient underlying API
           // calls to the Batch service.
           await batchClient.JobOperations.AddTaskAsync(jobId, tasks);

           return tasks;
       }
    </outputfile></outputfile></resourcefile></cloudtask></cloudtask></resourcefile>

    When I run the same command from the command-line locally it works fine and FFMpeg merges the two videos.

    I think it has something to do with FFMPEG not able to find the input videos. The location of the input files is stored in the file myfile.txt within the same blob storage container as the two videos itself.
    The videos are listed in the myfile.txt as follows :

    file IMG_7442.MOV
    file IMG_7456.MOV

    Does anyone have an idea on where the failure is coming from ? Any help would be greatly appreciated !

  • lavu/pixfmt : Add P012, Y212, XV30, and XV36 formats

    13 août 2022, par Philip Langdale
    lavu/pixfmt : Add P012, Y212, XV30, and XV36 formats
    

    These are the formats we want/need to use when dealing with the Intel
    VAAPI decoder for 12bit 4:2:0, 12bit 4:2:2, 10bit 4:4:4 and 12bit 4:4:4
    respectively.

    As with the already supported Y210 and YUVX (XVUY) formats, they are
    based on formats Microsoft picked as their preferred 4:2:2 and 4:4:4
    video formats, and Intel ran with it.

    P12 and Y212 are simply an extension of 10 bit formats to say 12 bits
    will be used, with 4 unused bits instead of 6.

    XV30, and XV36, as exotic as they sound, are variants of Y410 and Y412
    where the alpha channel is left formally undefined. We prefer these
    over the alpha versions because the hardware cannot actually do
    anything with the alpha channel and respecting it is just overhead.

    Y412/XV46 is a normal looking packed 4 channel format where each
    channel is 16bits wide but only the 12msb are used (like P012).

    Y410/XV30 packs three 10bit channels in 32bits with 2bits of alpha,
    like A/X2RGB10 style formats. This annoying layout forced me to define
    the BE version as a bitstream format. It seems like our pixdesc
    infrastructure can handle the LE version being byte-defined, but not
    when it's reversed. If there's a better way to handle this, please
    let me know. Our existing X2 formats all have the 2 bits at the MSB
    end, but this format places them at the LSB end and that seems to be
    the root of the problem.

    • [DH] doc/APIchanges
    • [DH] libavutil/pixdesc.c
    • [DH] libavutil/pixfmt.h
    • [DH] libavutil/version.h
    • [DH] tests/ref/fate/imgutils
    • [DH] tests/ref/fate/sws-pixdesc-query