Recherche avancée

Médias (91)

Autres articles (52)

  • Keeping control of your media in your hands

    13 avril 2011, par

    The vocabulary used on this site and around MediaSPIP in general, aims to avoid reference to Web 2.0 and the companies that profit from media-sharing.
    While using MediaSPIP, you are invited to avoid using words like "Brand", "Cloud" and "Market".
    MediaSPIP is designed to facilitate the sharing of creative media online, while allowing authors to retain complete control of their work.
    MediaSPIP aims to be accessible to as many people as possible and development is based on expanding the (...)

  • Submit bugs and patches

    13 avril 2011

    Unfortunately a software is never perfect.
    If you think you have found a bug, report it using our ticket system. Please to help us to fix it by providing the following information : the browser you are using, including the exact version as precise an explanation as possible of the problem if possible, the steps taken resulting in the problem a link to the site / page in question
    If you think you have solved the bug, fill in a ticket and attach to it a corrective patch.
    You may also (...)

  • Automated installation script of MediaSPIP

    25 avril 2011, par

    To overcome the difficulties mainly due to the installation of server side software dependencies, an "all-in-one" installation script written in bash was created to facilitate this step on a server with a compatible Linux distribution.
    You must have access to your server via SSH and a root account to use it, which will install the dependencies. Contact your provider if you do not have that.
    The documentation of the use of this installation script is available here.
    The code of this (...)

Sur d’autres sites (10601)

  • Anomalie #3075 : #LOGO_ARTICLE_RUBRIQUE_NORMAL ne retourne rien sous SPIP 3

    7 octobre 2018

    C’est juste que je déteste les comportements apparemment dérogatoires.

    Or, j’ai l’impression que _NORMAL et _SURVOL sont des suffixes qui permettent de ne retourner qu’un des 2 logos.
    Mais que ces suffixes ne marchent pas avec #LOGO_ARTICLE_RUBRIQUE

    Donc, oui, j’ai reçu une réponse qui met sur le même plan les suffixes _NORMAL/_SURVOL et _RUBRIQUE

    Mais puisque j’ai pu comprendre de travers par une systématisation abusive des suffixes en question (_NORMAL/_SURVOL), je penses qu’il faut, soit corriger le code (ce qui serait esthétiquement souhaitable), soit documenter la non généricité de ces suffixes (ce qui éviterait de passer à côté de l’info qui finalement n’est que dans le code).

    Et j’insiste qu’il n’est pas logique ni cohérent de ne pas pouvoir extraire le logo normal ou de survol dans toutes les situations.

  • How to set frame offset for source and reference video for calculating using FFMpeg commandline ?

    1er septembre 2018, par Souvik Das

    I have a scenario where I am streaming a reference video on a server machine and receiving it at a client machine with exact same codec, using FFMpeg via UDP/RTP.

    So, I have a reference.avi file and a recording.ts file with me. Now, due to a network side issue and FFMpeg discarding old frames, often the recording.ts lacks exactly 12 FRAMES from the beginning. Sometimes, it may lack more frames in-between but that’d due to general network traffic and packet loss reason and I don’t plan to account for that. Anyways, due to those 12 frames, when I calculate the PSNR, it drops down to 13, even though remaining frames may/may not be affected.

    So, my aim is to discard first 12 frames from reference.ts and then compare. For that, I would also need to adjust the frames from recording.ts.

    Consider the following scenario :

    reference.ts has 1500 frames. So naturally I am going to cut-short it 1488. Then we have the following cases :

    1. recording.ts has 1500 frames. This is not affected. Still I will remove 12 frames to match the count. So frame 1 would then represent frame 13.
    2. recording.ts has 1496 frames. This is not affected. Still I will remove 12 frames even though it’d get to 1484 count assuming that frame 1 would then represent frame 13.
    3. recording.ts has 1488 frames. This is affected. No need to remove frames.
    4. recording.ts has 1480 frames. This is affected. No need to remove frames.

    Once that is done, then I will calcualte the PSNR. So, my FFMpeg should be able to do all this, hopefully in a single command on bash.

    A better alternative would be for FFMpeg to find the where the 13th frame is in recording.ts and then cut-short from the beginning. That’d be more preferred and even more if there is no cut-shorting required, i.e. if offset could be set in-line to command and no additional video output is generated for use in PSNR comparison.

    Current I am using the following command to calculate the PSNR.

    ffmpeg -i 'recording.ts' -vf "movie='reference.avi', psnr=stats_file='psnr.txt'" -f rawvideo -y /dev/null

    It’d be great if somebody could help me in this regard. Thanks.

  • OpenCV video capture - output even potentially corrupt frames

    20 juillet 2018, par J. S.

    In FFmpeg, there is a flag "output_corrupt" that allows the command to output even corrupted frames. I am sending h264 stream to a server where its first few frames are corrupted. By setting "output_corrupt" flag in my FFmpeg command, I am able to view the live stream.
    I can see the live stream by piping FFmpeg data to OpenCV VideoCapture (i.e. cv2.VideoCapture(’/dev/stdin’))

    Note : since my plan is to run CV algorithms on those frames, I need to be able to run it on OpenCV.

    However, by not directly sending the data through VideoCapture, it unavoidably causes some latency issue.

    The best scenario would be to just directly send the h264 stream to OpenCV VideoCapture (i.e. cv2.VideoCapture(’udp ://......’))
    However, because of the corrupted frames, the OpenCV script gets stuck after a second.

    Is there any way to run OpenCV VideoCapture such that it still outputs potentially corrupt frames ?

    Thank you.

Navigation