Recherche avancée

Médias (21)

Mot : - Tags -/Nine Inch Nails

Autres articles (40)

  • Les tâches Cron régulières de la ferme

    1er décembre 2010, par

    La gestion de la ferme passe par l’exécution à intervalle régulier de plusieurs tâches répétitives dites Cron.
    Le super Cron (gestion_mutu_super_cron)
    Cette tâche, planifiée chaque minute, a pour simple effet d’appeler le Cron de l’ensemble des instances de la mutualisation régulièrement. Couplée avec un Cron système sur le site central de la mutualisation, cela permet de simplement générer des visites régulières sur les différents sites et éviter que les tâches des sites peu visités soient trop (...)

  • Use, discuss, criticize

    13 avril 2011, par

    Talk to people directly involved in MediaSPIP’s development, or to people around you who could use MediaSPIP to share, enhance or develop their creative projects.
    The bigger the community, the more MediaSPIP’s potential will be explored and the faster the software will evolve.
    A discussion list is available for all exchanges between users.

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

  • Replacing the standard Android H264 software encoder with an ffmpeg based one

    10 août 2012, par rubenvb

    In Android ICS and later, a new OpenMax IL API version is in use, making old binary blobs useless/unused. This leads to older devices that otherwise run ICS just fine and dandy to have broken video playback (YouTube HQ and IMBD, for example) because Androids fallback software decoder sucks when compared to what ffmpeg can do on the same device (I tested MXPlayer+arm6vfp ffmpeg and a 720p movie played back great).

    I am trying to dig through the Android source code to see where and what exactly I could add/replace code to allow the ffmpeg library's awesomeness to be used. The problem is I don't know exactly what code is being used in for example the YouTube app to decode video, or how that's decided.

    So I have two options as far as I can tell :

    1. Figure out the current software decoder being used, and try to wrap its external interface around ffmpeg, effectively replacing the slow software decoder currently used. The end result would be a single .so I could push to the device.

    2. Figure out how to trick Android into thinking an OMX library based on ffmpeg (I have built one succesfully for Android : limoa) and add this somewhere to the list of considered libraries (or better : replace the unusable hardware codec).

    As an extension, I'd like to also make camcorder video encoding work through this, so a true integrated solution would be very much wanted. The question is : how, and where, and what ? Searching the Android source tree gives numerous counts of "H264" and related stuff in many different places. I need the lowest and simplest possible, so I can simply wrap the hypothetical decode(buffer) function call to use ffmpeg (libavcodec).

  • ffmpeg : RTP missed packets, how to avoid ? [on hold]

    17 mai 2019, par James Adams

    I am saving H.264/5 video (from IP camera) to MP4 using ffmpeg without transcoding :

    $ ffmpeg -i  -vcodec copy -y -rtsp_transport tcp video.mp4

    I’m getting numerous missing packets messages, for example :

    [rtsp @ 0x55d6a47a8d40] RTP: missed 3 packets
    
[rtsp @ 0x55d6a47a8d40] max delay reached. need to consume packet
    
[rtsp @ 0x55d6a47a8d40] RTP: missed 1 packets
    
[rtsp @ 0x55d6a47a8d40] max delay reached. need to consume packet
    
[rtsp @ 0x55d6a47a8d40] RTP: missed 4 packets
    
[rtsp @ 0x55d6a47a8d40] max delay reached. need to consume packet

    The above results in MP4 files that are wonky looking in some places, apparently data has been lost and this results in smeared looking video files.

    I seem to have better luck when I change the option order and put the -rtsp_transport tcp before the -i , but that’s also problematic because it seems to hang without ever finishing (at least I’ve never waited long enough for it to finish on its own before killing the process).

    I have had better luck with reading the video stream (same RTSP URL) using OpenCV (no missing packet messages) but I know of no way to avoid the transcoding step using that package so I’m stuck with ffmpeg (it seems that I’m not alone). Maybe OpenCV is doing some sort of buffering that helps it avoid dropping packets, and there’s a corresponding option that I haven’t found yet that will enable this for ffmpeg ?

    My system is a Dell XPS laptop running Ubuntu 18.04.

    How can I work around this issue ?

  • ffmpeg - compositing a video within a video in the centre

    1er mars 2017, par kieran

    I’m looking to composite a video with ffmpeg that places the video in the centre no matter what the composited video’s aspect ratio/size.

    The "background" video will always be 16:9 and 1920x1080px. I won’t know the aspect ratio or size of the overlay video as it will be user uploaded and could be any size/ratio.

    Here’s an example of what I’m trying to achieve :

    This is the background image :

    enter image description here

    Now I want to overlay a video over the top :

    enter image description here

    This should also work :enter image description here

    Essentially no matter what the dimensions I want to ensure it’s always resized to fit within 1920x1080 and in addition ensure it’s always centred.

    Finally, if the uploaded video is also 16:9 it should simply overlay the entire video :
    enter image description here

Navigation