Recherche avancée

Médias (3)

Mot : - Tags -/collection

Autres articles (54)

  • Demande de création d’un canal

    12 mars 2010, par

    En fonction de la configuration de la plateforme, l’utilisateur peu avoir à sa disposition deux méthodes différentes de demande de création de canal. La première est au moment de son inscription, la seconde, après son inscription en remplissant un formulaire de demande.
    Les deux manières demandent les mêmes choses fonctionnent à peu près de la même manière, le futur utilisateur doit remplir une série de champ de formulaire permettant tout d’abord aux administrateurs d’avoir des informations quant à (...)

  • Gestion de la ferme

    2 mars 2010, par

    La ferme est gérée dans son ensemble par des "super admins".
    Certains réglages peuvent être fais afin de réguler les besoins des différents canaux.
    Dans un premier temps il utilise le plugin "Gestion de mutualisation"

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

Sur d’autres sites (8037)

  • Getting media duration with ffprobe after decoding with FFmpeg

    23 août 2019, par Brad

    With ffprobe, it’s possible to get the duration of a media file :

    ffprobe -show_format 1064428_cityLights_HD_BG.mp4

    [FORMAT]
    …
    duration=10.010000

    However, ffprobe only digs into the container and doesn’t decode the media. For container formats that have no inherent duration, or for broken files that play but maybe weren’t finalized, the duration isn’t available :

    [FORMAT]
    …
    duration=N/A

    The recommended solution to this problem is to use FFmpeg to decode, and then parse STDERR.

    ffmpeg -i input.webm -f null -

    frame=206723 fps=1390 q=-0.0 Lsize=N/A time=00:57:28.87 bitrate=N/A speed=23.2x

    This works well enough, but if I’m integrating this into other programs and scripts, I have to assume that the output of FFmpeg isn’t going to change from version to version. It would be much more convenient if there were a way to use ffmpeg and ffprobe together, so that I could continue to utilize the JSON output of ffprobe.

    Is there some way to force ffmpeg to decode the media and pipe it to ffprobe in some way that allows ffprobe to include the duration in its output for these types of situations ?

    (Note : I know I can just have FFmpeg output a file, and then input that into ffprobe. For convenience, I’m curious if there’s an all-in-one solution, with a pipe or equivalent.)

  • Having trouble obtaining the time from RTP Timestamps obtained through OpenCV

    24 août 2019, par Fr0sty

    I am finding it a bit difficult trying to understand whether or not the hack around with FFmpeg and OpenCV really provided a RTP timestamp. My last post helped a little bit but got me stuck in trying to validate the timestamps obtained through this work around by modifying ffmpeg and opencv.

    FFmpeg version : 4.1.0
    OpenCV version : 3.4.1

    import cv2
    
import time
    
from datetime import datetime, date
    

    
uri = 'rtsp://admin:password@192.168.1.66:554/Streaming/Channels/101'
    
cap = cv2.VideoCapture(uri)
    
'''One is the offset between the two epochs. Unix uses an epoch located at 1/1/1970-00:00h (UTC) and NTP uses 1/1/1900-00:00h.
    
This leads to an offset equivalent to 70 years in seconds (there are 17 leap years between the two dates so the offset is'''
    
time_offset = 2208988800 # (70*365 + 17)*86400 = 2208988800 (in seconds)
    
# offset = 3775484294
    
days = 43697
    
pdat = "1900-01-01 00:00:00:00"
    
mdat = "2019-08-23 22:02:44:00" # str(datetime.now()) + str(datetime.now().time())
    
pdate = datetime.strptime(pdat, "%Y-%m-%d %H:%M:%S:%f").date()
    
mdate = datetime.strptime(mdat, "%Y-%m-%d %H:%M:%S:%f").date()
    
delta = (mdate - pdate).days
    
offset = delta * 86400
    
def time_delta(s):
    
    return (s - time_offset)
    

    
while True:
    
    frame_exists, curr_frame = cap.read()
    
    if frame_exists:
    
        seconds = cap.getRTPTimeStampSeconds()
    
        fraction = cap.getRTPTimeStampFraction()
    
        timestamp = cap.getRTPTimeStampTs()
    
        unix_offset = seconds - time_offset
    
        msec = int((int(fraction) / 0xFFFFFFFF) * 1000.0)
    
        ts = float(str(unix_offset) + "." + str(msec))
    
        # print("Timestamp per Frame:%i" % timestamp)
    
        print((datetime.fromtimestamp(float(ts) + offset)))
    
cap.release()

    My Output :

    On August 23, 2019 at 22:02

    ...
    
2019-08-23 13:59:52.781000
    
2019-08-23 13:59:52.726000
    
2019-08-23 13:59:52.671000
    
2019-08-23 13:59:52.616000
    
2019-08-23 13:59:52.561000
    
2019-08-23 13:59:52.506000
    
2019-08-23 13:59:52.451000
    
2019-08-23 13:59:52.396000
    
2019-08-23 13:59:52.342000
    
2019-08-23 13:59:52.287000
    
2019-08-23 13:59:52.232000
    
2019-08-23 13:59:52.177000
    
2019-08-23 13:59:52.122000
    
2019-08-23 13:59:52.067000
    
2019-08-23 13:59:52.012000
    
2019-08-23 13:59:53.570000
    
2019-08-23 13:59:53.020000
    
2019-08-23 13:59:53.847000
    
2019-08-23 13:59:53.792000

    I’ve noticed how the time increments weirdly (that’s not suppose to happen in the real, current time), such as the last two lines and a few others in between in the output. A bit flabbergasted as to what went wrong. Also trying this out on multiple IP cameras, with each showing a different timestamp probably related to when they were turned on.

  • RTP Timestamps Are Not Monotonically increasing

    25 août 2019, par Fr0sty

    I am finding it a bit difficult trying to understand whether or not the hack around with FFmpeg and OpenCV really provided a RTP timestamp. My last post helped a little bit but got me stuck in trying to validate the timestamps obtained through this work around by modifying ffmpeg and opencv.

    FFmpeg version : 4.1.0
    OpenCV version : 3.4.1

    import cv2
    
import time
    
from datetime import datetime, date
    

    
uri = 'rtsp://admin:password@192.168.1.66:554/Streaming/Channels/101'
    
cap = cv2.VideoCapture(uri)
    
'''One is the offset between the two epochs. Unix uses an epoch located at 1/1/1970-00:00h (UTC) and NTP uses 1/1/1900-00:00h.
    
This leads to an offset equivalent to 70 years in seconds (there are 17 leap years between the two dates so the offset is'''
    
time_offset = 2208988800 # (70*365 + 17)*86400 = 2208988800 (in seconds)
    
# offset = 3775484294
    
days = 43697
    
pdat = "1900-01-01 00:00:00:00"
    
mdat = "2019-08-23 22:02:44:00" # str(datetime.now()) + str(datetime.now().time())
    
pdate = datetime.strptime(pdat, "%Y-%m-%d %H:%M:%S:%f").date()
    
mdate = datetime.strptime(mdat, "%Y-%m-%d %H:%M:%S:%f").date()
    
delta = (mdate - pdate).days
    
offset = delta * 86400
    
def time_delta(s):
    
    return (s - time_offset)
    

    
while True:
    
    frame_exists, curr_frame = cap.read()
    
    if frame_exists:
    
        seconds = cap.getRTPTimeStampSeconds()
    
        fraction = cap.getRTPTimeStampFraction()
    
        timestamp = cap.getRTPTimeStampTs()
    
        unix_offset = seconds - time_offset
    
        msec = int((int(fraction) / 0xFFFFFFFF) * 1000.0)
    
        ts = float(str(unix_offset) + "." + str(msec))
    
        # print("Timestamp per Frame:%i" % timestamp)
    
        print((datetime.fromtimestamp(float(ts) + offset)))
    
cap.release()

    My Output :

    On August 23, 2019 at 22:02

    ...
    
2019-08-23 13:59:52.781000
    
2019-08-23 13:59:52.726000
    
2019-08-23 13:59:52.671000
    
2019-08-23 13:59:52.616000
    
2019-08-23 13:59:52.561000
    
2019-08-23 13:59:52.506000
    
2019-08-23 13:59:52.451000
    
2019-08-23 13:59:52.396000
    
2019-08-23 13:59:52.342000
    
2019-08-23 13:59:52.287000
    
2019-08-23 13:59:52.232000
    
2019-08-23 13:59:52.177000
    
2019-08-23 13:59:52.122000
    
2019-08-23 13:59:52.067000
    
2019-08-23 13:59:52.012000
    
2019-08-23 13:59:53.570000
    
2019-08-23 13:59:53.020000
    
2019-08-23 13:59:53.847000
    
2019-08-23 13:59:53.792000

    I’ve noticed how the time increments weirdly (that’s not suppose to happen in the real, current time), such as the last two lines and a few others in between in the output. A bit flabbergasted as to what went wrong. Also trying this out on multiple IP cameras, with each showing a different timestamp probably related to when they were turned on.

Navigation