Recherche avancée

Médias (1)

Mot : - Tags -/Rennes

Autres articles (112)

  • Mise à jour de la version 0.1 vers 0.2

    24 juin 2013, par

    Explications des différents changements notables lors du passage de la version 0.1 de MediaSPIP à la version 0.3. Quelles sont les nouveautés
    Au niveau des dépendances logicielles Utilisation des dernières versions de FFMpeg (>= v1.2.1) ; Installation des dépendances pour Smush ; Installation de MediaInfo et FFprobe pour la récupération des métadonnées ; On n’utilise plus ffmpeg2theora ; On n’installe plus flvtool2 au profit de flvtool++ ; On n’installe plus ffmpeg-php qui n’est plus maintenu au (...)

  • Personnaliser en ajoutant son logo, sa bannière ou son image de fond

    5 septembre 2013, par

    Certains thèmes prennent en compte trois éléments de personnalisation : l’ajout d’un logo ; l’ajout d’une bannière l’ajout d’une image de fond ;

  • Ecrire une actualité

    21 juin 2013, par

    Présentez les changements dans votre MédiaSPIP ou les actualités de vos projets sur votre MédiaSPIP grâce à la rubrique actualités.
    Dans le thème par défaut spipeo de MédiaSPIP, les actualités sont affichées en bas de la page principale sous les éditoriaux.
    Vous pouvez personnaliser le formulaire de création d’une actualité.
    Formulaire de création d’une actualité Dans le cas d’un document de type actualité, les champs proposés par défaut sont : Date de publication ( personnaliser la date de publication ) (...)

Sur d’autres sites (14623)

  • dnn/vf_dnn_detect.c : add tensorflow output parse support

    6 mai 2021, par Ting Fu
    dnn/vf_dnn_detect.c : add tensorflow output parse support
    

    Testing model is tensorflow offical model in github repo, please refer
    https://github.com/tensorflow/models/blob/master/research/object_detection/g3doc/tf2_detection_zoo.md
    to download the detect model as you need.
    For example, local testing was carried on with 'ssd_mobilenet_v2_coco_2018_03_29.tar.gz', and
    used one image of dog in
    https://github.com/tensorflow/models/blob/master/research/object_detection/test_images/image1.jpg

    Testing command is :
    ./ffmpeg -i image1.jpg -vf dnn_detect=dnn_backend=tensorflow:input=image_tensor:output=\
    "num_detections&detection_scores&detection_classes&detection_boxes":model=ssd_mobilenet_v2_coco.pb,\
    showinfo -f null -

    We will see the result similar as below :
    [Parsed_showinfo_1 @ 0x33e65f0] side data - detection bounding boxes :
    [Parsed_showinfo_1 @ 0x33e65f0] source : ssd_mobilenet_v2_coco.pb
    [Parsed_showinfo_1 @ 0x33e65f0] index : 0, region : (382, 60) -> (1005, 593), label : 18, confidence : 9834/10000.
    [Parsed_showinfo_1 @ 0x33e65f0] index : 1, region : (12, 8) -> (328, 549), label : 18, confidence : 8555/10000.
    [Parsed_showinfo_1 @ 0x33e65f0] index : 2, region : (293, 7) -> (682, 458), label : 1, confidence : 8033/10000.
    [Parsed_showinfo_1 @ 0x33e65f0] index : 3, region : (342, 0) -> (690, 325), label : 1, confidence : 5878/10000.

    There are two boxes of dog with cores 94.05% & 93.45% and two boxes of person with scores 80.33% & 58.78%.

    Signed-off-by : Ting Fu <ting.fu@intel.com>
    Signed-off-by : Guo, Yejun <yejun.guo@intel.com>

    • [DH] libavfilter/vf_dnn_detect.c
  • Dreamcast Track Sizes

    1er mars 2015, par Multimedia Mike — Sega Dreamcast

    I’ve been playing around with Sega Dreamcast discs lately. Not playing the games on the DC discs, of course, just studying their structure. To review, the Sega Dreamcast game console used special optical discs named GD-ROMs, where the GD stands for “gigadisc”. They are capable of holding about 1 gigabyte of data.

    You know what’s weird about these discs ? Each one manages to actually store a gigabyte of data. Each disc has a CD portion and a GD portion. The CD portion occupies the first 45000 sectors and can be read in any standard CD drive. This area is divided between a brief data track and a brief (usually) audio track.

    The GD region starts at sector 45000. Sometimes, it’s just one humongous data track that consumes the entire GD region. More often, however, the data track is split between the first track and the last track in the region and there are 1 or more audio tracks in between. But the weird thing is, the GD region is always full. I made a study of it (click for a larger, interactive graph) :


    Dreamcast Track Sizes

    Some discs put special data or audio bonuses in the CD region for players to discover. But every disc manages to fill out the GD region. I checked up on a lot of those audio tracks that divide the GD data and they’re legitimate music tracks. So what’s the motivation ? Why would the data track be split in 2 pieces like that ?

    I eventually realized that I probably answered this question in this blog post from 4 years ago. The read speed from the outside of an optical disc is higher than the inside of the same disc. When I inspect the outer data tracks of some of these discs, sure enough, there seem to be timing-sensitive multimedia FMV files living on the outer stretches.

    One day, I’ll write a utility to take apart the split ISO-9660 filesystem offset from a weird sector.

  • FFmpeg : canvas and crop work separately but result in black screen when combined

    25 janvier, par didi00

    I'm working on a video processing pipeline with FFmpeg, where I :

    &#xA;

      &#xA;
    • Create a black canvas using the color filter.
    • &#xA;

    • Crop a region from my video input.
    • &#xA;

    • Overlay the cropped region onto the black canvas.
    • &#xA;

    &#xA;

    Both the canvas and the crop display correctly when tested individually. However, when I attempt to combine them (overlay the crop onto the canvas), the result is a black screen.&#xA;What Works :

    &#xA;

    Black Canvas Alone :

    &#xA;

    ffmpeg -filter_complex "color=c=black:s=1920x1080[out]" -map "[out]" -f nut - | ffplay &#xA;-&#xA;

    &#xA;

    This shows a plain black screen, as expected.

    &#xA;

    Cropped Region Alone :

    &#xA;

    ffmpeg -f v4l2 -input_format yuyv422 -framerate 60 -video_size 1920x1080 -i /dev/video0 &#xA;\ -vf "crop=1024:192:0:0" -f nut - | ffplay -&#xA;

    &#xA;

    This shows the cropped region of the video correctly.

    &#xA;

    When I combine these steps to overlay the crop onto the black canvas, I get a black screen :

    &#xA;

    ffmpeg -f v4l2 -input_format yuyv422 -framerate 60 -video_size 1920x1080 -i /dev/video0 &#xA;\-filter_complex "color=c=black:s=1920x1080,format=yuv420p[background]; \&#xA;[0:v]crop=1024:192:0:0,format=yuv420p[region0]; \&#xA;[background][region0]overlay=x=0:y=0[out]" \&#xA;-map "[out]" -f nut - | ffplay -&#xA;

    &#xA;

    Environment :

    &#xA;

      &#xA;
    • OS : Linux (Debian-based)
    • &#xA;

    • FFmpeg Version : [Insert version, e.g., 4.x or 5.x]
    • &#xA;

    • Capture Card Format : yuyv422
    • &#xA;

    &#xA;

    Question :

    &#xA;

    Why does the pipeline result in a black screen when combining the canvas and the crop, even though both work separately ? Is this an issue with pixel format compatibility, or is there something I'm overlooking in the overlay filter setup ?

    &#xA;