Recherche avancée

Médias (91)

Autres articles (50)

  • Participer à sa documentation

    10 avril 2011

    La documentation est un des travaux les plus importants et les plus contraignants lors de la réalisation d’un outil technique.
    Tout apport extérieur à ce sujet est primordial : la critique de l’existant ; la participation à la rédaction d’articles orientés : utilisateur (administrateur de MediaSPIP ou simplement producteur de contenu) ; développeur ; la création de screencasts d’explication ; la traduction de la documentation dans une nouvelle langue ;
    Pour ce faire, vous pouvez vous inscrire sur (...)

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

Sur d’autres sites (5683)

  • ffmepg always get broken video streaming from rtsp protocol [on hold]

    6 janvier 2014, par poc

    I'm trying to capture rtsp streaming from Ip Camera by the command

    ffmpeg -t 10 -i  rtsp://172.19.1.42/live.sdp  -ss 00:00:02.500  -c:v copy download.mp4

    However I always get the broken streaming, but if I used the VLC or Qucicktime to watch the RTSP streaming, it worked fine , there was no broken streaming.

    Is there any setting or options for ffmpeg can improve the streaming quality ? Thanks

    [rtsp @ 0x7f9a84017c00] Estimating duration from bitrate, this may be inaccurate
    
Input #0, rtsp, from 'rtsp://172.19.1.42/live.sdp':
    
  Metadata:
    
    title           : RTSP server
    
  Duration: N/A, start: 0.000000, bitrate: N/A
    
    Stream #0:0: Video: h264 (Main), yuv420p, 2048x1536, 13.33 tbr, 90k tbn, 180k tbc
    
-t is not an input option, keeping it for the next output; consider fixing your command line.
    
Output #0, mp4, to 'c0_s1_h264_1920x1536_10_cbr_500_6000000_imagequality.mp4':
    
  Metadata:
    
    title           : RTSP server
    
    encoder         : Lavf54.63.104
    
    Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 2048x1536, q=2-31, 90k tbn, 90k tbc
    
Stream mapping:
    
  Stream #0:0 -> #0:0 (copy)
    
Press [q] to stop, [?] for help
    
[NULL @ 0x7f9a83805200] RTP: missed 3 packets
    
    Last message repeated 1 times
    
RTP: missed 3 packets=-1.0 size=     521kB time=00:00:00.80 bitrate=5303.8kbits/s
    
[NULL @ 0x7f9a83805200] RTP: missed 3 packets
    
RTP: missed 3 packets=-1.0 size=     895kB time=00:00:01.40 bitrate=5224.0kbits/s
    
[NULL @ 0x7f9a83805200] RTP: missed 3 packets
    
RTP: missed 3 packets=-1.0 size=    1271kB time=00:00:02.00 bitrate=5192.3kbits/s
    
[NULL @ 0x7f9a83805200] RTP: missed 3 packets
    
RTP: missed 3 packets=-1.0 size=    1646kB time=00:00:02.60 bitrate=5175.1kbits/s
    
RTP: missed 2 packets=-1.0 size=    2029kB time=00:00:03.20 bitrate=5183.5kbits/s
    
RTP: missed 3 packets=-1.0 size=    2420kB time=00:00:03.80 bitrate=5207.3kbits/s
    
RTP: missed 2 packets=-1.0 size=    2801kB time=00:00:04.40 bitrate=5206.0kbits/s
    
[NULL @ 0x7f9a83805200] RTP: missed 3 packets
    
RTP: missed 2 packets=-1.0 size=    3180kB time=00:00:05.00 bitrate=5201.6kbits/s
    
[NULL @ 0x7f9a83805200] RTP: missed 3 packets
    
RTP: missed 3 packets=-1.0 size=    4708kB time=00:00:07.41 bitrate=5204.6kbits/s
    
RTP: missed 2 packets=-1.0 size=    5088kB time=00:00:08.01 bitrate=5202.7kbits/s
    
RTP: missed 2 packets=-1.0 size=    5857kB time=00:00:09.21 bitrate=5207.3kbits/s
    
[NULL @ 0x7f9a83805200] RTP: missed 2 packets
    
frame=  100 fps= 10 q=-1.0 Lsize=    6382kB time=00:00:09.96 bitrate=5246.4kbits/s

  • fate : adjust frequencies of the sine filter

    9 novembre 2024, par Marton Balint
    fate : adjust frequencies of the sine filter

    The filter currently uses inaccurate frequencies, this is in preparation for
    
fixing that, by using numbers that will map to the equivalent value in the
    
future code.
    

    Signed-off-by : Marton Balint <cus@passwd.hu>
    • [DH] tests/fate/ffmpeg.mak
    • [DH] tests/fate/filter-video.mak
    • [DH] tests/fate/libswresample.mak
    • [DH] tests/filtergraphs/concat
    • [DH] tests/filtergraphs/concat-vfr
    • [DH] tests/filtergraphs/crazychannels

  • fftools/ffmpeg_enc : always use video frame durations when available

    15 avril 2023, par Anton Khirnov
    fftools/ffmpeg_enc : always use video frame durations when available

    Previously they would only be used with trivial filtergraphs, because
    
filters did not handle frame durations. That is no longer true - most
    
filters process frame durations properly (there may still be some that
    
don't - this change will help finding and fixing them).
    

    Improves output video frame durations in a number of FATE tests.
    • [DH] fftools/ffmpeg_enc.c
    • [DH] tests/ref/fate/filter-concat-vfr
    • [DH] tests/ref/fate/gif-disposal-restore
    • [DH] tests/ref/fate/gif-gray
    • [DH] tests/ref/fate/quickdraw

Navigation