
Recherche avancée
Médias (1)
-
The Great Big Beautiful Tomorrow
28 octobre 2011, par
Mis à jour : Octobre 2011
Langue : English
Type : Texte
Autres articles (32)
-
Support de tous types de médias
10 avril 2011Contrairement à beaucoup de logiciels et autres plate-formes modernes de partage de documents, MediaSPIP a l’ambition de gérer un maximum de formats de documents différents qu’ils soient de type : images (png, gif, jpg, bmp et autres...) ; audio (MP3, Ogg, Wav et autres...) ; vidéo (Avi, MP4, Ogv, mpg, mov, wmv et autres...) ; contenu textuel, code ou autres (open office, microsoft office (tableur, présentation), web (html, css), LaTeX, Google Earth) (...)
-
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 (...) -
Supporting all media types
13 avril 2011, parUnlike 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 (4107)
-
avutils/hwcontext : When deriving a hwdevice, search for existing device in both direc...
25 novembre 2021, par Soft Worksavutils/hwcontext : When deriving a hwdevice, search for existing device in both directions
The test /libavutil/tests/hwdevice checks that when deriving a device
from a source device and then deriving back to the type of the source
device, the result is matching the original source device, i.e. the
derivation mechanism doesn't create a new device in this case.Previously, this test was usually passed, but only due to two different
kind of flaws :1. The test covers only a single level of derivation (and back)
It derives device Y from device X and then Y back to the type of X and
checks whether the result matches X.What it doesn't check for, are longer chains of derivation like :
CUDA1 > OpenCL2 > CUDA3 and then back to OpenCL4
In that case, the second derivation returns the first device (CUDA3 ==
CUDA1), but when deriving OpenCL4, hwcontext.c was creating a new
OpenCL4 context instead of returning OpenCL2, because there was no link
from CUDA1 to OpenCL2 (only backwards from OpenCL2 to CUDA1)If the test would check for two levels of derivation, it would have
failed.This patch fixes those (yet untested) cases by introducing forward
references (derived_device) in addition to the existing back references
(source_device).2. hwcontext_qsv didn't properly set the source_device
In case of QSV, hwcontext_qsv creates a source context internally
(vaapi, dxva2 or d3d11va) without calling av_hwdevice_ctx_create_derived
and without setting source_device.This way, the hwcontext test ran successful, but what practically
happened, was that - for example - deriving vaapi from qsv didn't return
the original underlying vaapi device and a new one was created instead :
Exactly what the test is intended to detect and prevent. It just
couldn't do so, because the original device was hidden (= not set as the
source_device of the QSV device).This patch properly makes these setting and fixes all derivation
scenarios.(at a later stage, /libavutil/tests/hwdevice should be extended to check
longer derivation chains as well)Reviewed-by : Lynne <dev@lynne.ee>
Reviewed-by : Anton Khirnov <anton@khirnov.net>
Tested-by : Wenbin Chen <wenbin.chen@intel.com>
Signed-off-by : softworkz <softworkz@hotmail.com>
Signed-off-by : Haihao Xiang <haihao.xiang@intel.com> -
fftools/ffprobe : print size of attachment streams (extradata_size)
25 novembre 2021, par softworkzfftools/ffprobe : print size of attachment streams (extradata_size)
Signed-off-by : softworkz <softworkz@hotmail.com>
Signed-off-by : Marton Balint <cus@passwd.hu>- [DH] doc/ffprobe.xsd
- [DH] fftools/ffprobe.c
- [DH] tests/ref/fate/concat-demuxer-extended-lavf-mxf
- [DH] tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10
- [DH] tests/ref/fate/concat-demuxer-simple1-lavf-mxf
- [DH] tests/ref/fate/concat-demuxer-simple1-lavf-mxf_d10
- [DH] tests/ref/fate/concat-demuxer-simple2-lavf-ts
- [DH] tests/ref/fate/flv-demux
- [DH] tests/ref/fate/mov-zombie
- [DH] tests/ref/fate/mxf-probe-d10
- [DH] tests/ref/fate/oggopus-demux
- [DH] tests/ref/fate/ts-demux
- [DH] tests/ref/fate/ts-opus-demux
- [DH] tests/ref/fate/ts-small-demux
-
Anomalie #3645 : Hauteur du champ texte en sortie de plein écran
20 août 2016, par RastaPopoulos ♥Oui, merci, je ne ferme volontairement pas moi-même les tickets généralement, je mets en résolu le temps que d’autres confirment qu’effectivement ça marche aussi chez eux. Si c’est tout bon, c’est super. :)