Recherche avancée

Médias (39)

Mot : - Tags -/audio

Autres articles (39)

  • Les vidéos

    21 avril 2011, par

    Comme les documents de type "audio", Mediaspip affiche dans la mesure du possible les vidéos grâce à la balise html5 .
    Un des inconvénients de cette balise est qu’elle n’est pas reconnue correctement par certains navigateurs (Internet Explorer pour ne pas le nommer) et que chaque navigateur ne gère en natif que certains formats de vidéos.
    Son avantage principal quant à lui est de bénéficier de la prise en charge native de vidéos dans les navigateur et donc de se passer de l’utilisation de Flash et (...)

  • MediaSPIP v0.2

    21 juin 2013, par

    MediaSPIP 0.2 est la première version de MediaSPIP stable.
    Sa date de sortie officielle est le 21 juin 2013 et est annoncée ici.
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Comme pour la version précédente, il est nécessaire d’installer manuellement l’ensemble des dépendances logicielles sur le serveur.
    Si vous souhaitez utiliser cette archive pour une installation en mode ferme, il vous faudra également procéder à d’autres modifications (...)

  • Mise à disposition des fichiers

    14 avril 2011, par

    Par défaut, lors de son initialisation, MediaSPIP ne permet pas aux visiteurs de télécharger les fichiers qu’ils soient originaux ou le résultat de leur transformation ou encodage. Il permet uniquement de les visualiser.
    Cependant, il est possible et facile d’autoriser les visiteurs à avoir accès à ces documents et ce sous différentes formes.
    Tout cela se passe dans la page de configuration du squelette. Il vous faut aller dans l’espace d’administration du canal, et choisir dans la navigation (...)

Sur d’autres sites (6964)

  • FFmpeg cant recognize 3 channels with each 32 bit

    4 avril 2022, par Chryfi

    I am writing the linearized depth buffer of a game to openEXR using FFmpeg. Unfortunately, FFmpeg does not adhere to the openEXR file specification fully (like allowing unsigned integer for one channel) so I am writing one float channel to openEXR, which is put into the green channel with this command -f rawvideo -pix_fmt grayf32be -s %WIDTH%x%HEIGHT% -r %FPS% -i - -vf %DEFVF% -preset ultrafast -tune zerolatency -qp 6 -compression zip1 -pix_fmt gbrpf32le %NAME%_depth_%d.exr.

    


    The float range is from 0F to 1F and it is linear. I can confirm that the calculation and linearization is correct by testing 16 bit integer (per pixel component) PNG in Blender compositor. The 16 bit integer data is written like this short s = (short) (linearzieDepth(depth) * (Math.pow(2,16) - 1)) whereas for float the linearized value is directly written to OpenEXR without multiplying with a value.

    


    However, when viewing the openEXR file it doesn't have the same "gradient" as the 16 bit png... when viewing them side by side, it appears as if the values near 0 are not linear, and they are not as dark as they should be like in the 16 bit png.
(And yes, I set the image node to linear), and comparing it with 3d tracking data from the game I cant reproduce the depth and cant mask things using the depth buffer where as with the png I can.

    


    How is it possible for a linear float range to turn out so different to a linear integer range in an image ?

    


    UPDATE :

    


    I now write 3 channels to the ffmpeg with this code

    


    float f2 = this.linearizeDepth(depth);

buffer.putFloat(f2);
buffer.putFloat(0);
buffer.putFloat(0);


    


    the byte buffer is of the size width * height * 3 * 4 -> 3 channels with each 4 bytes. The command is now -f rawvideo -pix_fmt gbrpf32be -s %WIDTH%x%HEIGHT% -r %FPS% -i - -vf %DEFVF% -preset ultrafast -tune zerolatency -qp 6 -compression zip1 -pix_fmt gbrpf32le %NAME%_depth_%d.exr which should mean that the input (byte buffer) is expecting 32 bit floats with 3 channels. This is how it turns out

    


    FFmpeg is somehow splitting up channels or whatever... could be a bug, could be my fault ?

    


  • ffmpeg libavfilter acrossfade : I jget just first input in output

    29 juillet 2024, par Alex

    I'm trying to combine two raw audio chunks (s16, 48000, mono) through acrossfade.

    


    I create filter nodes (skip all error checking here) :

    


    avfilter_graph_create_filter(&mediaIn_1,
    avfilter_get_by_name("abuffer"),
    "MediaIn_1",
    "sample_rate=48000:sample_fmt=s16:channel_layout=mono",
    NULL, graph);
avfilter_graph_create_filter(&mediaIn_2,
    avfilter_get_by_name("abuffer"),
    "MediaIn_2",
    "sample_rate=48000:sample_fmt=s16:channel_layout=mono",
    NULL, graph);
avfilter_graph_create_filter(&mediaOut,
    avfilter_get_by_name("abuffersink"),
    "MediaOut",
    NULL, NULL, graph);
avfilter_graph_create_filter(&crossfade,
    avfilter_get_by_name("acrossfade"),
    "crossfade", "nb_samples=6000:c1=tri:c2=tri", NULL, graph);


    


    Then I link them in a graph :

    


    avfilter_link(mediaIn_1, 0, crossfade, 0);
avfilter_link(mediaIn_2, 0, crossfade, 1);
avfilter_link(crossfade, 0, mediaOut, 0);
avfilter_graph_config(graph, NULL);


    


    After that I create a frame with all the chunk data :

    


    frame1 = av_frame_alloc();
frame1->format = AV_SAMPLE_FMT_S16;
frame1->nb_samples = buf1sz / 2;
frame1->sample_rate = 48000;
frame1->ch_layout.order = AV_CHANNEL_ORDER_NATIVE;
frame1->ch_layout.nb_channels = 1;
frame1->ch_layout.u.mask = AV_CH_LAYOUT_MONO;
frame1->ch_layout.opaque = NULL;
frame1->pts = 0;
frame1->duration = buf1sz / 2;
frame1->time_base.num = 1;
frame1->time_base.den = 48000;

av_frame_get_buffer(frame1, 0);
memcpy(frame1->buf[0]->data, buf1, buf1sz);


    


    Same for second chunk.
And send frames into each input buffer :

    


    av_buffersrc_add_frame_flags(mediaIn_1, frame1, 0);
av_buffersrc_add_frame_flags(mediaIn_1, NULL, AV_BUFFERSRC_FLAG_PUSH);

...
av_buffersrc_add_frame_flags(mediaIn_2, frame2, 0);
av_buffersrc_add_frame_flags(mediaIn_2, NULL, AV_BUFFERSRC_FLAG_PUSH);


    


    Then I'm getting output frame :

    


    oframe = av_frame_alloc();
av_buffersink_get_frame_flags(mediaOut, oframe, 0);
...
av_frame_unref(oframe);


    


    The oframe contains (frame1->nb_samples - 6000) number of samples instead of (frame1->nb_samples + frame2->nb_samples - something_for_xfade_needs).
Next call to av_buffersink_get_frame_flags returns AVERROR_EOF.

    


    What is wrong with this algorithm ?

    


    I tried afade filter with "t=in" input and it works fine. I think the problem is with two inputs. I don't get it.

    


  • swscale : add two spatially stable dithering methods

    23 mars 2014, par Øyvind Kolås
    swscale : add two spatially stable dithering methods
    

    Both of these dithering methods are from http://pippin.gimp.org/a_dither/ for
    GIF they can be considered better than bayer (provides more gray-levels), and
    spatial stability - often more than twice as good compression and less visual
    flicker than error diffusion methods (the methods also avoids error-shadow
    artifacts of diffusion dithers).

    These methods are similar to blue/green noise type dither masks ; but are
    simple enough to generate their mask on the fly. They are still research work
    in progress ; though more expensive to generate masks (which can be used in a
    LUT) like ’void and cluster’ and similar methods will yield superior results

    • [DH] doc/scaler.texi
    • [DH] libswscale/options.c
    • [DH] libswscale/output.c
    • [DH] libswscale/swscale_internal.h
    • [DH] libswscale/utils.c