Recherche avancée

Médias (33)

Mot : - Tags -/creative commons

Autres articles (58)

  • Multilang : améliorer l’interface pour les blocs multilingues

    18 février 2011, par

    Multilang est un plugin supplémentaire qui n’est pas activé par défaut lors de l’initialisation de MediaSPIP.
    Après son activation, une préconfiguration est mise en place automatiquement par MediaSPIP init permettant à la nouvelle fonctionnalité d’être automatiquement opérationnelle. Il n’est donc pas obligatoire de passer par une étape de configuration pour cela.

  • Ajouter des informations spécifiques aux utilisateurs et autres modifications de comportement liées aux auteurs

    12 avril 2011, par

    La manière la plus simple d’ajouter des informations aux auteurs est d’installer le plugin Inscription3. Il permet également de modifier certains comportements liés aux utilisateurs (référez-vous à sa documentation pour plus d’informations).
    Il est également possible d’ajouter des champs aux auteurs en installant les plugins champs extras 2 et Interface pour champs extras.

  • List of compatible distributions

    26 avril 2011, par

    The table below is the list of Linux distributions compatible with the automated installation script of MediaSPIP. Distribution nameVersion nameVersion number Debian Squeeze 6.x.x Debian Weezy 7.x.x Debian Jessie 8.x.x Ubuntu The Precise Pangolin 12.04 LTS Ubuntu The Trusty Tahr 14.04
    If you want to help us improve this list, you can provide us access to a machine whose distribution is not mentioned above or send the necessary fixes to add (...)

Sur d’autres sites (9160)

  • Annual Release of External-Videos plugin – we’ve hit v1.0

    13 janvier 2017, par silvia

    This is the annual release of my external-videos wordpress plugin and with the help of Andrew Nimmolo I’m proud to annouce we’ve reached version 1.0 !

    So yes, my external-videos wordpress plugin is now roughly 7 years old, who would have thought ! During the year, I don’t get the luxury of spending time on maintaining this open source love child of mine, but at Christmas, my bad conscience catches up with me – every year ! I then spend some time going through bug reports, upgrading the plugin to the latest wordpress version, upgrading to the latest video site APIs, testing functionality and of course making a new release.

    This year has been quite special. The power of open source has kicked in and a new developer took an interest in external-videos. Andrew Nimmolo submitted patches over all of 2016. He decided to bring the external-videos plugin into the new decade with a huge update to the layout of the settings pages, general improvements, and an all-round update of all the video site APIs which included removing their overly complex SDKs and going straight for the REST APIs.

    Therefore, I’m very proud to be able to release version 1.0 today. Thanks, Andrew !

    Enjoy – and I look forward to many more contributions – have a Happy 2017 !

    NOTE : If you’re upgrading from an older version, you might need to remove and re-add your social video sites because the API details have changed a bit. Also, we noticed that there were layout issues on WordPress 4.3.7, so try and make sure your WordPress version is up to date.

  • 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 ?​