Recherche avancée

Médias (91)

Autres articles (13)

  • Publier sur MédiaSpip

    13 juin 2013

    Puis-je poster des contenus à partir d’une tablette Ipad ?
    Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir

  • Configuration spécifique d’Apache

    4 février 2011, par

    Modules spécifiques
    Pour la configuration d’Apache, il est conseillé d’activer certains modules non spécifiques à MediaSPIP, mais permettant d’améliorer les performances : mod_deflate et mod_headers pour compresser automatiquement via Apache les pages. Cf ce tutoriel ; mode_expires pour gérer correctement l’expiration des hits. Cf ce tutoriel ;
    Il est également conseillé d’ajouter la prise en charge par apache du mime-type pour les fichiers WebM comme indiqué dans ce tutoriel.
    Création d’un (...)

  • Taille des images et des logos définissables

    9 février 2011, par

    Dans beaucoup d’endroits du site, logos et images sont redimensionnées pour correspondre aux emplacements définis par les thèmes. L’ensemble des ces tailles pouvant changer d’un thème à un autre peuvent être définies directement dans le thème et éviter ainsi à l’utilisateur de devoir les configurer manuellement après avoir changé l’apparence de son site.
    Ces tailles d’images sont également disponibles dans la configuration spécifique de MediaSPIP Core. La taille maximale du logo du site en pixels, on permet (...)

Sur d’autres sites (3442)

  • What's the best way to get video metadata from a MP4 file in ASP.Net MVC using C# ?

    23 septembre 2019, par Maddhacker24

    I’ve been searching on Google and StackOverflow for a good couple of hours. There seems to be a lot of similar questions on StackOverflow but they are all about 3-5 years old.

    Is using FFMPEG still the best way these days to pull metadata from a video file in a .NET web application ? And if so, what’s the best C# wrapper out there ?

    I’ve tried MediaToolkit, MediaFile.dll without any luck. I saw ffmpeg-csharpe but that looks like it hasn’t been touched in a few years.

    I haven’t found any current data on this subject. Is the ability to pull metadata from a video built into the latest version of .NET now ?

    I’m basically looking for any direction at this point.

    I should add that whatever I use could be invoked thousands of times per hour so it will need to be efficient.

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

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

Navigation