
Recherche avancée
Médias (2)
-
Valkaama DVD Label
4 octobre 2011, par
Mis à jour : Février 2013
Langue : English
Type : Image
-
Podcasting Legal guide
16 mai 2011, par
Mis à jour : Mai 2011
Langue : English
Type : Texte
Autres articles (45)
-
Soumettre améliorations et plugins supplémentaires
10 avril 2011Si vous avez développé une nouvelle extension permettant d’ajouter une ou plusieurs fonctionnalités utiles à MediaSPIP, faites le nous savoir et son intégration dans la distribution officielle sera envisagée.
Vous pouvez utiliser la liste de discussion de développement afin de le faire savoir ou demander de l’aide quant à la réalisation de ce plugin. MediaSPIP étant basé sur SPIP, il est également possible d’utiliser le liste de discussion SPIP-zone de SPIP pour (...) -
Menus personnalisés
14 novembre 2010, parMediaSPIP utilise le plugin Menus pour gérer plusieurs menus configurables pour la navigation.
Cela permet de laisser aux administrateurs de canaux la possibilité de configurer finement ces menus.
Menus créés à l’initialisation du site
Par défaut trois menus sont créés automatiquement à l’initialisation du site : Le menu principal ; Identifiant : barrenav ; Ce menu s’insère en général en haut de la page après le bloc d’entête, son identifiant le rend compatible avec les squelettes basés sur Zpip ; (...) -
Possibilité de déploiement en ferme
12 avril 2011, parMediaSPIP peut être installé comme une ferme, avec un seul "noyau" hébergé sur un serveur dédié et utilisé par une multitude de sites différents.
Cela permet, par exemple : de pouvoir partager les frais de mise en œuvre entre plusieurs projets / individus ; de pouvoir déployer rapidement une multitude de sites uniques ; d’éviter d’avoir à mettre l’ensemble des créations dans un fourre-tout numérique comme c’est le cas pour les grandes plate-formes tout public disséminées sur le (...)
Sur d’autres sites (9563)
-
How to port signal() to sigaction() ?
28 septembre 2016, par Sharkdue to recent problems discovered with NDK12 and NDK13b2, i’m thinking of ’porting’ libx264’s use of signal() (and missing bsd_signal() in ndk12) to use sigaction() instead.
The problem is, I’m not quite sure what’s the simple&fastest way to replace signal() calls with sigaction() ones.
For all i see, it’s mainly used in x264-snapshot/common/cpu.c in the following manner :
using the following signal handler :
static void sigill_handler( int sig )
{
if( !canjump )
{
signal( sig, SIG_DFL );
raise( sig );
}
canjump = 0;
siglongjmp( jmpbuf, 1 );
}This is the problematic
x264_cpu_detect
function... currently, i’m guessing i only need to tackle the ARM version, but i’ ; ; still have to replace all occurances ofsignal()
withsigaction()
so i might just cover both of them to get the thing building...FYI - the NDK13 beta2 still has "unstable" libc and the build doesn’t fail on this part, but rather the first invocation of the
rand()
function somewhere else... So i’m out of luck and replacing the signal() calls might be better than just waiting for the official NDK13 release. I’m doing this to get rid of text-relocations so i can run the library (and doubango) on API 24 (Android N)the problematic part of function that invokes
signal()
:#elif SYS_LINUX
uint32_t x264_cpu_detect( void )
{
static void (*oldsig)( int );
oldsig = signal( SIGILL, sigill_handler );
if( sigsetjmp( jmpbuf, 1 ) )
{
signal( SIGILL, oldsig );
return 0;
}
canjump = 1;
asm volatile( "mtspr 256, %0\n\t"
"vand 0, 0, 0\n\t"
:
: "r"(-1) );
canjump = 0;
signal( SIGILL, oldsig );
return X264_CPU_ALTIVEC;
}
#endif
#elif ARCH_ARM
void x264_cpu_neon_test( void );
int x264_cpu_fast_neon_mrc_test( void );
uint32_t x264_cpu_detect( void )
{
int flags = 0;
#if HAVE_ARMV6
flags |= X264_CPU_ARMV6;
// don't do this hack if compiled with -mfpu=neon
#if !HAVE_NEON
static void (* oldsig)( int );
oldsig = signal( SIGILL, sigill_handler );
if( sigsetjmp( jmpbuf, 1 ) )
{
signal( SIGILL, oldsig );
return flags;
}
canjump = 1;
x264_cpu_neon_test();
canjump = 0;
signal( SIGILL, oldsig );
#endif
flags |= X264_CPU_NEON;
// fast neon -> arm (Cortex-A9) detection relies on user access to the
// cycle counter; this assumes ARMv7 performance counters.
// NEON requires at least ARMv7, ARMv8 may require changes here, but
// hopefully this hacky detection method will have been replaced by then.
// Note that there is potential for a race condition if another program or
// x264 instance disables or reinits the counters while x264 is using them,
// which may result in incorrect detection and the counters stuck enabled.
// right now Apple does not seem to support performance counters for this test
#ifndef __MACH__
flags |= x264_cpu_fast_neon_mrc_test() ? X264_CPU_FAST_NEON_MRC : 0;
#endif
// TODO: write dual issue test? currently it's A8 (dual issue) vs. A9 (fast mrc)
#endif
return flags;
}
#else
uint32_t x264_cpu_detect( void )
{
return 0;
}So the question is really this : what would be the quickest/easiest//fastest way to replace the
signal()
calls withsigaction()
ones while preserving the current functionality ?EDIT :
The reason i’m trying to get rid ofsignal()
are these build errors :/home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function sigill_handler: error: undefined reference to 'bsd_signal'
/home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
/home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
/home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'I already know that this is a known NDK12 problem, that might be solved by bringing
bsd_signal
back to the libc in NDK13. However, in it’ beta state with it’s unstable libc - it’s currently missing the rand() function and simply waiting for it might not do the trick. But in the worst-case scenario, i guess i’ll just have to wait for it and retry after it’s release.But as it currently is, the prebuilt version of the library i want to use has text-relocations and is being rejected by phones running newer API / version of the android OS.
EDIT2 :
I also know thatsignal()
usually works by usingsigaction()
under the hood, but maybe i won’t get bsd_signal related build-errors... since i’m suspecting that this one isn’t using it. It’s obviously using bsd_signal, which may or may not be the same underlying thing :/ -
How to port signal() to sigaction() ?
28 septembre 2016, par Sharkdue to recent problems discovered with NDK12 and NDK13b2, i’m thinking of ’porting’ libx264’s use of signal() (and missing bsd_signal() in ndk12) to use sigaction() instead.
The problem is, I’m not quite sure what’s the simple&fastest way to replace signal() calls with sigaction() ones.
For all i see, it’s mainly used in x264-snapshot/common/cpu.c in the following manner :
using the following signal handler :
static void sigill_handler( int sig )
{
if( !canjump )
{
signal( sig, SIG_DFL );
raise( sig );
}
canjump = 0;
siglongjmp( jmpbuf, 1 );
}This is the problematic
x264_cpu_detect
function... currently, i’m guessing i only need to tackle the ARM version, but i’ ; ; still have to replace all occurances ofsignal()
withsigaction()
so i might just cover both of them to get the thing building...FYI - the NDK13 beta2 still has "unstable" libc and the build doesn’t fail on this part, but rather the first invocation of the
rand()
function somewhere else... So i’m out of luck and replacing the signal() calls might be better than just waiting for the official NDK13 release. I’m doing this to get rid of text-relocations so i can run the library (and doubango) on API 24 (Android N)the problematic part of function that invokes
signal()
:#elif SYS_LINUX
uint32_t x264_cpu_detect( void )
{
static void (*oldsig)( int );
oldsig = signal( SIGILL, sigill_handler );
if( sigsetjmp( jmpbuf, 1 ) )
{
signal( SIGILL, oldsig );
return 0;
}
canjump = 1;
asm volatile( "mtspr 256, %0\n\t"
"vand 0, 0, 0\n\t"
:
: "r"(-1) );
canjump = 0;
signal( SIGILL, oldsig );
return X264_CPU_ALTIVEC;
}
#endif
#elif ARCH_ARM
void x264_cpu_neon_test( void );
int x264_cpu_fast_neon_mrc_test( void );
uint32_t x264_cpu_detect( void )
{
int flags = 0;
#if HAVE_ARMV6
flags |= X264_CPU_ARMV6;
// don't do this hack if compiled with -mfpu=neon
#if !HAVE_NEON
static void (* oldsig)( int );
oldsig = signal( SIGILL, sigill_handler );
if( sigsetjmp( jmpbuf, 1 ) )
{
signal( SIGILL, oldsig );
return flags;
}
canjump = 1;
x264_cpu_neon_test();
canjump = 0;
signal( SIGILL, oldsig );
#endif
flags |= X264_CPU_NEON;
// fast neon -> arm (Cortex-A9) detection relies on user access to the
// cycle counter; this assumes ARMv7 performance counters.
// NEON requires at least ARMv7, ARMv8 may require changes here, but
// hopefully this hacky detection method will have been replaced by then.
// Note that there is potential for a race condition if another program or
// x264 instance disables or reinits the counters while x264 is using them,
// which may result in incorrect detection and the counters stuck enabled.
// right now Apple does not seem to support performance counters for this test
#ifndef __MACH__
flags |= x264_cpu_fast_neon_mrc_test() ? X264_CPU_FAST_NEON_MRC : 0;
#endif
// TODO: write dual issue test? currently it's A8 (dual issue) vs. A9 (fast mrc)
#endif
return flags;
}
#else
uint32_t x264_cpu_detect( void )
{
return 0;
}So the question is really this : what would be the quickest/easiest//fastest way to replace the
signal()
calls withsigaction()
ones while preserving the current functionality ?EDIT :
The reason i’m trying to get rid ofsignal()
are these build errors :/home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function sigill_handler: error: undefined reference to 'bsd_signal'
/home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
/home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'
/home/devshark/SCRATCH/doubango/thirdparties/android/armv5te/lib/dist/libx264.a(cpu.o):cpu.c:function x264_cpu_detect: error: undefined reference to 'bsd_signal'I already know that this is a known NDK12 problem, that might be solved by bringing
bsd_signal
back to the libc in NDK13. However, in it’ beta state with it’s unstable libc - it’s currently missing the rand() function and simply waiting for it might not do the trick. But in the worst-case scenario, i guess i’ll just have to wait for it and retry after it’s release.But as it currently is, the prebuilt version of the library i want to use has text-relocations and is being rejected by phones running newer API / version of the android OS.
EDIT2 :
I also know thatsignal()
usually works by usingsigaction()
under the hood, but maybe i won’t get bsd_signal related build-errors... since i’m suspecting that this one isn’t using it. It’s obviously using bsd_signal, which may or may not be the same underlying thing :/ -
FFmpeg filter config with aecho fails to configure all the links and formats - avfilter_graph_config
23 janvier 2021, par cs guyI am following the official tutorial of FFMpeg to create a filter chain. This tutorial shows how to pass data through a chain as :




The filter chain it uses is : * (input) -> abuffer -> volume ->
aformat -> abuffersink -> (output)




Here is my code - sorry for boiler code, it is just ffmpeg way :(


frame = av_frame_alloc();
 filterGraph = avfilter_graph_alloc();

 if (!frame) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Could not allocate memory for frame");
 return;
 }

 if (!filterGraph) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor FXProcessor! %s", av_err2str(AVERROR(ENOMEM)));
 return;
 }

 const AVFilter *abuffer;
 const AVFilter *abuffersink;
 AVFilterContext *aformat_ctx;
 const AVFilter *aformat;
 AVFilterContext *choisen_beat_fx_ctx;
 const AVFilter *choisen_beat_fx;

 /* Create the abuffer filter;
 * it will be used for feeding the data into the graph. */
 abuffer = avfilter_get_by_name("abuffer");
 if (!abuffer) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Could not find the abuffer filter!");
 return;
 }
 abuffer_ctx = avfilter_graph_alloc_filter(filterGraph, abuffer, "src");
 if (!abuffer_ctx) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Could not allocate the abuffer_ctx instance! %s",
 av_err2str(AVERROR(ENOMEM)));
 return;
 }

 char ch_layout[64];
 /* Set the filter options through the AVOptions API. */
 av_get_channel_layout_string(ch_layout, sizeof(ch_layout), 0, AV_CH_LAYOUT_STEREO);
 av_opt_set(abuffer_ctx, "channel_layout", ch_layout, AV_OPT_SEARCH_CHILDREN);
 av_opt_set(abuffer_ctx, "sample_fmt", av_get_sample_fmt_name(AV_SAMPLE_FMT_FLT),
 AV_OPT_SEARCH_CHILDREN);
 av_opt_set_q(abuffer_ctx, "time_base", (AVRational) {1, defaultSampleRate},
 AV_OPT_SEARCH_CHILDREN);
 av_opt_set_int(abuffer_ctx, "sample_rate", defaultSampleRate, AV_OPT_SEARCH_CHILDREN);
 /* Now initialize the filter; we pass NULL options, since we have already
 * set all the options above. */

 if (avfilter_init_str(abuffer_ctx, nullptr) < 0) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Could not initialize the abuffer filter!");
 return;
 }

 // TODO: select FX's dynamically
 /* Create aecho filter. */
 if (true) {

 choisen_beat_fx = avfilter_get_by_name("volume");
 if (!choisen_beat_fx) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Could not find the aecho filter!");
 return;
 }

 choisen_beat_fx_ctx = avfilter_graph_alloc_filter(filterGraph, choisen_beat_fx, "echo");
 if (!choisen_beat_fx_ctx) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Could not allocate the choisen_beat_fx_ctx instance! %s",
 av_err2str(AVERROR(ENOMEM)));
 return;
 }

 av_opt_set (choisen_beat_fx_ctx, "volume", AV_STRINGIFY(0.5), AV_OPT_SEARCH_CHILDREN);

 if (avfilter_init_str(choisen_beat_fx_ctx, nullptr) < 0) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Could not initialize the choisen_beat_fx_ctx filter!");
 return;
 }
 }

 /* Create the aformat filter;
 * it ensures that the output is of the format we want. */
 aformat = avfilter_get_by_name("aformat");
 if (!aformat) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Could not find the aformat filter!");
 return;
 }
 aformat_ctx = avfilter_graph_alloc_filter(filterGraph, aformat, "aformat");
 if (!aformat_ctx) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Could not allocate the aformat instance!");
 return;
 }

 av_opt_set(aformat_ctx, "sample_fmts", av_get_sample_fmt_name(AV_SAMPLE_FMT_FLT),
 AV_OPT_SEARCH_CHILDREN);
 av_opt_set_int(aformat_ctx, "sample_rates", defaultSampleRate, AV_OPT_SEARCH_CHILDREN);
 av_get_channel_layout_string(ch_layout, sizeof(ch_layout), 0, AV_CH_LAYOUT_STEREO);
 av_opt_set(aformat_ctx, "channel_layouts", ch_layout, AV_OPT_SEARCH_CHILDREN);

 if (avfilter_init_str(aformat_ctx, nullptr) < 0) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Could not initialize the aformat filter!");
 return;
 }

 /* Finally create the abuffersink filter;
 * it will be used to get the filtered data out of the graph. */
 abuffersink = avfilter_get_by_name("abuffersink");
 if (!abuffersink) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Could not find the abuffersink filter!");
 return;
 }

 abuffersink_ctx = avfilter_graph_alloc_filter(filterGraph, abuffersink, "sink");
 if (!abuffersink_ctx) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Could not allocate the abuffersink instance!");
 return;
 }

 /* This filter takes no options. */
 if (avfilter_init_str(abuffersink_ctx, nullptr) < 0) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Could not initialize the abuffersink instance.!");
 return;
 }

 /* Connect the filters;
 * in this simple case the filters just form a linear chain. */
 if (avfilter_link(abuffer_ctx, 0, choisen_beat_fx_ctx, 0) != 0) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Error connecting filters.!");
 return;
 }
 if (avfilter_link(choisen_beat_fx_ctx, 0, aformat_ctx, 0) != 0) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Error connecting filters.!");
 return;
 }
 if (avfilter_link(aformat_ctx, 0, abuffersink_ctx, 0) != 0) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Error connecting filters.!");
 return;
 }

 /* Configure the graph. */
 if (avfilter_graph_config(filterGraph, nullptr) < 0) {
 *mediaLoadPointer = FAILED_TO_LOAD;
 LOGE("FXProcessor::FXProcessor Error configuring the filter graph!");
 return;
 }



This code works fine when the chain is




- 

- (input) -> abuffer -> aecho-> aformat -> abuffersink -> (output)






However, I would like to use
adelay
instead ofvolume
filter. So I want :



The filter chain it uses is : * (input) -> abuffer -> volume ->
aformat -> abuffersink -> (output)




I changed the code at


choisen_beat_fx = avfilter_get_by_name("volume");



to


choisen_beat_fx = avfilter_get_by_name("aecho");



and removed the line


av_opt_set (choisen_beat_fx_ctx, "volume", AV_STRINGIFY(0.5), AV_OPT_SEARCH_CHILDREN);



everything goes smooth until the last line.

avfilter_graph_config
fails and returns negative value. Functions document :



avfilter_graph_config : Check validity and configure all the links and
formats in the graph.




So my guess is I need extra links to insert aecho to my chain ? How can I insert aecho into my filter chain ?