Recherche avancée

Médias (3)

Mot : - Tags -/Valkaama

Autres articles (30)

  • Support audio et vidéo HTML5

    10 avril 2011

    MediaSPIP 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 (...)

  • De l’upload à la vidéo finale [version standalone]

    31 janvier 2010, par

    Le chemin d’un document audio ou vidéo dans SPIPMotion est divisé en trois étapes distinctes.
    Upload et récupération d’informations de la vidéo source
    Dans un premier temps, il est nécessaire de créer un article SPIP et de lui joindre le document vidéo "source".
    Au moment où ce document est joint à l’article, deux actions supplémentaires au comportement normal sont exécutées : La récupération des informations techniques des flux audio et video du fichier ; La génération d’une vignette : extraction d’une (...)

  • HTML5 audio and video support

    13 avril 2011, par

    MediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
    The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
    For older browsers the Flowplayer flash fallback is used.
    MediaSPIP allows for media playback on major mobile platforms with the above (...)

Sur d’autres sites (3885)

  • Resolving rtmp stream url from Adobe Flash container

    14 avril 2013, par Mustafe

    How can a rtmp stream url be retrieved completely with its playpath and be played with ffplay/avconv from a flash plugin. In embedded flash code below rtmp address exits (rtmp ://live.atv.com.tr/atv) , however it does not work with avplay since it needs playpath.

    /i.tmgrup.com.tr/p/flowplayer.controls.swf"},"influxis":{"url":"http://i.tmgrup.com.tr/p/flowplayer.rtmp.swf","netConnectionUrl":"rtmp://live.atv.com.tr/atv"},"ova":{"url":"http://i.tmgrup.com.tr/p/ova.swf","autoPlay":true,"overlays":{"regions":[{"id":"Reklam","verticalAlign":"bottom","horizontalAlign":"right","backgroundC...0,"style":".smalltext { font-style: italic; font-size:10; }"}]},"ads":{"notice":{"show":true,"region":"my-ad-notice","message":"<p class="\&quot;smalltext\&quot;" align="\&quot;right\&quot;"> Kalan süre : _countdown_ saniye.</p>"},"schedule":[{"zone":"5","position":"pre-roll","server":{"type":"direct","apiAddress":"http%3a%2f%2fad.reklamport.com%2frpgetad.ashx%3ftt%3dt_atv_canli_yayin_preroll_800x700%26vast%3d2"}}]}}},"playerId":"live","playlist":[{"eventCategory":"Canli Yayin","url":"atv3","live":true,"provider":"influxis"}]}" name="flashvars">

    Problem Solved : Using wireshark (network analyzer) is much more effective to retrieve paramaters like rtmp url, playpath...
    Edit2 : Some urls are also embedded in scripts files rather than directly in flash object, this variables are used in flash object above, later.

  • Revision ed2dc59c1b : Integral projection based motion estimation This commit introduces a new block

    13 février 2015, par Jingning Han

    Changed Paths :
     Modify /vp9/common/vp9_rtcd_defs.pl


     Modify /vp9/encoder/vp9_avg.c


     Modify /vp9/encoder/vp9_encodeframe.c


     Modify /vp9/encoder/x86/vp9_avg_intrin_sse2.c



    Integral projection based motion estimation

    This commit introduces a new block match motion estimation
    using integral projection measurement. The 2-D block and the nearby
    region is projected onto the horizontal and vertical 1-D vectors,
    respectively. It then runs vector match, instead of block match,
    over the two separate 1-D vectors to locate the motion compensated
    reference block.

    This process is run per 64x64 block to align the reference before
    choosing partitioning in speed 6. The overall CPU cycle cost due
    to this additional 64x64 block match (SSE2 version) takes around 2%
    at low bit-rate rtc speed 6. When strong motion activities exist in
    the video sequence, it substantially improves the partition
    selection accuracy, thereby achieving better compression performance
    and lower CPU cycles.

    The experiments were tested in RTC speed -6 setting :
    cloud 1080p 500 kbps
    17006 b/f, 37.086 dB, 5386 ms ->
    16669 b/f, 37.970 dB, 5085 ms (>0.9dB gain and 6% faster)

    pedestrian_area 1080p 500 kbps
    53537 b/f, 36.771 dB, 18706 ms ->
    51897 b/f, 36.792 dB, 18585 ms (4% bit-rate savings)

    blue_sky 1080p 500 kbps
    70214 b/f, 33.600 dB, 13979 ms ->
    53885 b/f, 33.645 dB, 10878 ms (30% bit-rate savings, 25% faster)

    jimred 400 kbps
    13380 b/f, 36.014 dB, 5723 ms ->
    13377 b/f, 36.087 dB, 5831 ms (2% bit-rate savings, 2% slower)

    Change-Id : Iffdb6ea5b16b77016bfa3dd3904d284168ae649c

  • Recording with libx264 results in audio muting prior to recording being stopped depending on preset

    24 janvier 2020, par Pyon
    ffmpeg -thread_queue_size 512 -f dshow -i audio="AudioDevice" -thread_queue_size 512 -f gdigrab -rtbufsize 100000000 -hwaccel auto -framerate 60 -offset_x 332 -offset_y 720 -video_size 340x162 -probesize 10000000 -i desktop -c:v libx264 -preset veryslow -crf 23 -pix_fmt yuv420p "output.mp4"

    I’m using the above command to record desktop video/audio in a defined region.
    The video is being recorded using gdigrab while the audio is being recorded using dshow with a custom loopback driver.

    When the libx264 preset is set to anything below "ultrafast" like "veryslow", the audio will be muted around 80% into the recording (varies depending on video size and the preset selected, worsening for slower presets). By muted I mean : If I record a 10 second video, the video will be 10 seconds in length but the audio will only be audible for the first 8 seconds.

    I’m not really sure what could be causing this, but is there any way around it ?

    Below are simplified versions which produces same results..

    Veryslow preset (audio issue) :

    ffmpeg -thread_queue_size 512 -f dshow -i audio="PriAudio" -thread_queue_size 512 -f gdigrab -i desktop -c:v libx264 -preset veryslow -crf 23 -pix_fmt yuv420p "output.mp4"

    Ultrafast preset (no audio issue) :

    ffmpeg -thread_queue_size 512 -f dshow -i audio="PriAudio" -thread_queue_size 512 -f gdigrab -i desktop -c:v libx264 -preset ultrafast -crf 23 -pix_fmt yuv420p "output.mp4"

    I don’t want to use ultrafast because it results in poor quality/compression ratio.