
Recherche avancée
Médias (1)
-
Bug de détection d’ogg
22 mars 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Video
Autres articles (56)
-
Websites made with MediaSPIP
2 mai 2011, parThis page lists some websites based on MediaSPIP.
-
Creating farms of unique websites
13 avril 2011, parMediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
This allows (among other things) : implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...) -
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 (...)
Sur d’autres sites (8696)
-
Building ffmpeg on mac results in undefined symbols
9 juin 2017, par PeterEnvironment : macOS 10.12.5, Xcode 8.3.3, pkg-config installed via brew
I need to build a minimal version of ffmpeg that supports H.264 decoding. I have downloaded the source for ffmpeg version 3.3.1 and have successfully built it for Windows and Linux. Now, I am trying to build it for mac.
The specific flags of the configuration that are relevant are :
--disable-yasm
--disable-everything
--enable-decoder=h264
--enable-decoder=h264_vda
--enable-vdaAfter running the configuration, when I run make, all the libraries such as libavcodec.a, libavfilter.a, libavformat.a, are built. However, ffmpeg itself does not get built. The error I get is :
Undefined symbols for architecture x86_64:
"_ff_vda_create_decoder", referenced from:
_vdadec_init in libavcodec.a(vda_h264_dec.o)
"_ff_vda_destroy_decoder", referenced from:
_vdadec_init in libavcodec.a(vda_h264_dec.o)
_vdadec_close in libavcodec.a(vda_h264_dec.o)
ld: symbol(s) not found for architecture x86_64Looks like the functions are defined in ./libavcodec/vda_h264.c. However, it appears vda_h264.c is never compiled. Other vda related files such as vda.c and vda_h264_dec.c do get compiled (and added to libavcodec.a).
I am thinking perhaps I am missing a configuration flag. Can someone please help ? Regards.
-
How to "extend" aws docker base image (.net core from scratch) by ... libs/ubuntu/ffmpeg ?
26 avril 2022, par Nigrimmisti would like to use AWS Lambda through the image containers using .net core 3.1 and it is works fine for me in simplest code case. But i stucked with next scenario :


By default, aws provide base image with .net core with aws libs based on "from scratch". So as i know, it minimal Linux that does not contains even package manager.


I need to work with ffmpeg in the code, but to do it i need to install few packages and ... fmpeg. I have working code on image


FROM mcr.microsoft.com/dotnet/runtime:3.1-bionic



It is ubuntu with .net core runtime. But what is the right strategic in case of AWS Lambda image ? How can i ... merge them ?.


Have few ideas, but not sure :


- 

- use as is
FROM public.ecr.aws/lambda/dotnet:core3.1
and try to install package manager, all depenendencies to use ffmpeg and so on ? - Use
mcr.microsoft.com/dotnet/runtime:3.1-bionic
, somehow add required by amazon dependencies (how ? download content and attach from local ?) and configure it to run in Lambda runtime ? - ... ?








Will be glad to hear where is the solution here. Thanks !


- use as is
-
snow : remove an obsolete av_assert2
9 juillet 2015, par Andreas Cadhalpunsnow : remove an obsolete av_assert2
It asserts that the frame linesize is larger than 37, but it can be
smaller and decoding such frames works.Before commit cc884a35 src_stride > 7*MB_SIZE was necessary, because the
blocks were interleaved in the tmp buffer and the last block was added
with an offset of 6*MB_SIZE.
It was changed for src_stride <= 7*MB_SIZE to write the blocks
sequentially, hence the larger tmp_step.
After that the assert was only necessary to make sure that the buffer
remained large enough.
Since commit bd2b6b33 s->scratchbuf is used as tmp buffer.
As part of commit 86e107a7 the minimal scratchbuf size was increased to
256*7*MB_SIZE, which is enough for any src_stride <= 7*MB_SIZE.Also add a comment explaining the tmp_step calculation.
Signed-off-by : Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>