
Recherche avancée
Autres articles (105)
-
Support audio et vidéo HTML5
10 avril 2011MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...) -
HTML5 audio and video support
13 avril 2011, parMediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
For older browsers the Flowplayer flash fallback is used.
MediaSPIP allows for media playback on major mobile platforms with the above (...) -
De l’upload à la vidéo finale [version standalone]
31 janvier 2010, parLe chemin d’un document audio ou vidéo dans SPIPMotion est divisé en trois étapes distinctes.
Upload et récupération d’informations de la vidéo source
Dans un premier temps, il est nécessaire de créer un article SPIP et de lui joindre le document vidéo "source".
Au moment où ce document est joint à l’article, deux actions supplémentaires au comportement normal sont exécutées : La récupération des informations techniques des flux audio et video du fichier ; La génération d’une vignette : extraction d’une (...)
Sur d’autres sites (10850)
-
avformat/dhav : fix backward scanning for get_duration and optimize seeking
21 mars, par Justin Rugglesavformat/dhav : fix backward scanning for get_duration and optimize seeking
The backwards scanning done for incomplete final packets should not
assume a specific alignment at the end of the file. Truncated files
result in hundreds of thousands of seeks if the final packet does not
fall on a specific byte boundary, which can be extremely slow.
For example, with HTTP, each backwards seek results in a separate
HTTP request.This changes the scanning to check for the end tag 1 byte at a time
and buffers the last 1 MiB to avoid additional seek operations.Co-authored-by : Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by : Justin Ruggles <justinr@vimeo.com>
Signed-off-by : Derek Buitenhuis <derek.buitenhuis@gmail.com> -
ffmpeg : Converting animated GIF files to video while upscaling produces a file with inaccurate colors
14 juin 2020, par MetamoranI apologize if this is a dumb question, but even after using the search function I have not seen anyone asking about this.



I'm trying to both 
(1) : Convert some low-resolution animated GIF files (pixel art in particular) to video, and
(2) : Upscale them at the same time, using nearest-neighbor to preserve the hard edges.



ffmpeg does everything with no warnings or errors whatsoever, but the end result's colors look off. If I convert without upscaling, the color accuracy is preserved. I have tried both using and NOT using "palettegen", but it does not make a difference. For brevity, I'm only pasting the lines with palettegen in them. The end results are the same either way.



This is what I've been using for upscaling :



ffmpeg -i input.gif -c:v libx264 -b:v 10000K -y -vf "split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse,scale=2*iw:2*ih:flags=neighbor" output.mp4




This is what I used for testing conversion (with no upscaling) :



ffmpeg -i input.gif -c:v libx264 -b:v 10000K -y -vf "split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" output.mp4




Here's the input file :






Here's a screenshot of how the final video looks if I don't upscale (colors look exactly like in the input file) :



Screenshot - Final - No Upscaling



And here's the result if I upscale (2x Nearest-Neighbor upscaling, with the screenshot downsized 50% to make comparison easier. Colors were not altered during the process.) :



Screenshot - Final - 2x Upscaling (Nearest-Neighbor) [Downsized]



Folder with all relevant files :
Google Drive



Is there something I'm missing ? Or is there some sort of technical limitation, a step that will alter the colors of the video no matter what I try ? I'm not technically inclined, I'd like to know if that is the case. Thank you for your time.


-
Join 8 mono channels into 7.1 audio stream
10 juin 2020, par Rafal BI'm trying to join 8 mono channels into 7.1 channels layout :



ffmpeg -i L.ac3 -i R.ac3 -i C.ac3 -i Sub.ac3 -i BL.ac3 -i BR.ac3 -i SL.ac3 -i SR.ac3 -filter_complex "[0:a][1:a][2:a][3:a][4:a][5:a][6:a][7:a]join=inputs=8:channel_layout=7.1[a]"
-map "[a]" final-output.ac3




but I'm getting :



Stream mapping:
 Stream #0:0 (ac3) -> join:input0
 Stream #1:0 (ac3) -> join:input1
 Stream #2:0 (ac3) -> join:input2
 Stream #3:0 (ac3) -> join:input3
 Stream #4:0 (ac3) -> join:input4
 Stream #5:0 (ac3) -> join:input5
 Stream #6:0 (ac3) -> join:input6
 Stream #7:0 (ac3) -> join:input7
 join -> Stream #0:0 (ac3)
Press [q] to stop, [?] for help
Output #0, ac3, to 'final-output.ac3':
 Metadata:
 encoder : Lavf58.29.100
 Stream #0:0: Audio: ac3, 48000 Hz, **5.1(side)**, fltp, 640 kb/s (default)
 Metadata:
 encoder : Lavc58.54.100 ac3




Why the output file is 5.1(side) ?



Audio
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Duration : 54 min 5 s
Bit rate mode : Constant
Bit rate : 640 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 248 MiB (100%)
Service kind : Complete Main




I did not found anything that would explain this behavior.
I'm using latest ffmpeg and tried different methods : join, amerge. Always output file is 5.1(side)