Recherche avancée

Médias (2)

Mot : - Tags -/kml

Autres articles (28)

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

  • MediaSPIP version 0.1 Beta

    16 avril 2011, par

    MediaSPIP 0.1 beta est la première version de MediaSPIP décrétée comme "utilisable".
    Le fichier zip ici présent contient uniquement les sources de MediaSPIP en version standalone.
    Pour avoir une installation fonctionnelle, 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 (...)

Sur d’autres sites (3666)

  • Change file format from flv to anything android will play

    19 octobre 2011, par Bilthon

    I need to take this file which encoded is in h264 but in a flv container and just put it in a mp4, 3gp or whatever file format the android MediaPlayer will understand.

    I want to do this natively. As I will not be decoding nor encoding anything I think I will not be wasting a lot of power (am I wrong ?)

    I followed the instructions from here http://www.roman10.net/?p=394 and could sucessfully compile and use ffmpeg and use it with mp4 and 3gp files.

    But when it comes to flv files it fails. I understand there is no format definition for flv files in that specific port of ffmpeg for android.

    There is no libavformat/flv.h header file for instance.

    Maybe that's why this works :

    extern AVInputFormat ff_mov_demuxer ;
    av_register_input_format(&ff_mov_demuxer) ;

    While this fails :

    extern AVInputFormat ff_flv_demuxer;
    av_register_input_format(&ff_flv_demuxer);

    Question is, is there a light at the end of the tunnel ? has someone done something similar ? is it useful ? I mean, I can always just throw the flv media file into a flash player and voila.. the thing is that this would be a parcial solution, as it will not work for all those folks running slower devices that can't yet run Flash.

    Nelson

    PS. Just in case. Here's some info about the file I'm talking about :

    ffmpeg -i rio.flv
    ffmpeg version N-32624-gea8de10, Copyright (c) 2000-2011 the FFmpeg developers
     built on Sep 15 2011 23:31:42 with gcc 4.5.2
     configuration: --enable-libfaac --enable-libmp3lame --enable-librtmp --enable-libtheora --enable-libx264 --enable-libxvid --enable-gpl --enable-nonfree
     libavutil    51. 16. 0 / 51. 16. 0
     libavcodec   53. 15. 0 / 53. 15. 0
     libavformat  53. 12. 0 / 53. 12. 0
     libavdevice  53.  3. 0 / 53.  3. 0
     libavfilter   2. 42. 0 /  2. 42. 0
     libswscale    2.  1. 0 /  2.  1. 0
     libpostproc  51.  2. 0 / 51.  2. 0

    Seems stream 0 codec frame rate differs from container frame rate: 2000.00 (2000/1) -> 14.99 (15000/1001)
    Input #0, flv, from 'rio.flv':
     Duration: 00:01:00.06, start: 0.000000, bitrate: 783 kb/s
       Stream #0.0: Video: h264 (Main), yuv420p, 704x480 [SAR 10:11 DAR 4:3], 14.99 tbr, 1k tbn, 2k tbc
  • Streaming raw h264 video from Raspberry PI to server for capture and viewing [closed]

    24 juin 2024, par tbullers

    This is really an optimization question - I have been able to stream h264 from a raspberry pi 5 to a linux system and capture the streams and save them to .mp4 files.

    


    But I intend to run the video capture and sending on a battery powered Pi Zero 2 W and want to use the least amount of power to maximize battery life and still providing good video quality.

    


    I've explored many different configuration settings but am getting lost in all the options.

    


    This is what I run on the pi :

    


    rpicam-vid -t 30s --framerate 30 --hdr --inline --listen -o tcp://0.0.0.0:5000


    


    I retrieve this video from the more powerful Ubuntu server with :

    


    ffmpeg -r 30 -i tcp://ralph:5000 -vcodec copy video_out103.mp4


    


    It generally works but I receive lots of errors on the server side like this :

    


    [mp4 @ 0x5f9aab5d0800] pts has no valuee= 975.4kbits/s speed=1.19x
Last message repeated 15 times
[mp4 @ 0x5f9aab5d0800] pts has no valuee=1035.3kbits/s speed=1.19x
Last message repeated 15 times
[mp4 @ 0x5f9aab5d0800] pts has no valuee=1014.8kbits/s speed=1.18x
Last message repeated 9 times
[mp4 @ 0x5f9aab5d0800] pts has no valuee=1001.1kbits/s speed=1.17x
Last message repeated 7 times
[mp4 @ 0x5f9aab5d0800] pts has no value
Last message repeated 1 times
[out#0/mp4 @ 0x5f9aab5ad5c0] video:3546kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead : 0.120360%
size= 3550kB time=00:00:27.50 bitrate=1057.5kbits/s speed=1.18x

    


    Any suggestions on how to correct these errors ?

    


    Also any suggestions on how to make the video capture side more efficient ? Should I use a different codec ? (yuv instead of h264 ?) Would using UDP decrease overhead ? Can I improve video quality with the mode or hdr options ? What does denoise do ?

    


    With all the options available with these tools I think it's unlikely that I have a well thought out approach to capture and streaming. I'm hoping that people who are more familiar with this space might be able to provide some suggestions.

    


    Thank you !

    


    -tom

    


  • x264 encoding taking longer when encoding static frames (than

    14 septembre 2015, par Danilo

    ​Hi,
    I’m using x264 for live video streaming and I’ve noticed that the thread
    responsible for encoding uses ​​more cpu (sometimes 50% more with 1920x1080) when the video stream is frozen (i.e. : camera is sending the same frame over an over again) or when I make it encode the same image over and over again.

    This seems somewhat counter intuitive to me, as I would expect x264 to use
    more processing power when encoding complex scenes other then static ones.

    My encoder settings are the following :

    1280x720 fps=25/1 timebase=0/0 bitdepth=8 cabac=0 ref=1 deblock=1:0:0 analyse=0x3:0x113
    me=hex subme=2 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1
    8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=1 lookahead_threads=0
    sliced_threads=0 slice_max_size=1190 nr=60 decimate=1 interlaced=0 bluray_compat=0
    constrained_intra=0 bframes=0 weightp=0  keyint=1200 keyint_min=120 scenecut=40
    intra_refresh=0 rc_lookahead=0 rc=crf mbtree=0 crf=24.0 qcomp=0.60 qpmin=0 qpmax=69
    qpstep=4 vbv_maxrate=1024 vbv_bufsize=350 crf_max=35.0 nal_hrd=none

    I created a github gist based on the example.c encoder bundled in x264’s
    source code and tested encoding times with it. (You can find it here :
    https://gist.github.com/danilogr/ab4976ff4e0831ab274b)

    Average encoding time for the static scene is 38% bigger than for a scene
    with movements. (You can find my test case and also the output from my test
    encoder on the link above).

    ​​
    ​I’ve also noticed that by setting ​​scenecut=0, subme=0, trellis=0 and me=dia I can get rid of this problem​, but with noticeable quality​ decrease.


    ​Could anyone, please, shed some light on the reasons for this odd behavior ?
    ​Also, what can be done in order to avoid this situation without a major decrease in quality ?​