Recherche avancée

Médias (91)

Autres articles (63)

  • La file d’attente de SPIPmotion

    28 novembre 2010, par

    Une file d’attente stockée dans la base de donnée
    Lors de son installation, SPIPmotion crée une nouvelle table dans la base de donnée intitulée spip_spipmotion_attentes.
    Cette nouvelle table est constituée des champs suivants : id_spipmotion_attente, l’identifiant numérique unique de la tâche à traiter ; id_document, l’identifiant numérique du document original à encoder ; id_objet l’identifiant unique de l’objet auquel le document encodé devra être attaché automatiquement ; objet, le type d’objet auquel (...)

  • Les autorisations surchargées par les plugins

    27 avril 2010, par

    Mediaspip core
    autoriser_auteur_modifier() afin que les visiteurs soient capables de modifier leurs informations sur la page d’auteurs

  • 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

Sur d’autres sites (11949)

  • Using Unicast RTSP URIs via ffmpeg

    6 août 2019, par Chris Marshall

    I’m fairly new to ffmpeg, so I’d certainly appreciate being given an "M" to "RTFM." The ffmpeg docs are...not-so-easy...to navigate, but I’m trying.

    The goal is to develop a compiled server that incorporates ffmpeg, but first, I need to get it working via CLI.

    I have a standard AXIS Surveillance camera (AXIS M5525-E), set up as an ONVIF device (but that isn’t really relevant to this issue).

    When I query it, I get the following URI as its video streaming URI :

    rtsp://192.168.4.12/onvif-media/media.amp?profile=profile_1_jpeg&streamtype=unicast

    The IP is local to a sandboxed network.

    I add the authentication parameters to it, like so :

    rtsp://<login>:<password>@192.168.4.12/onvif-media/media.amp?profile=profile_1_jpeg&amp;streamtype=unicast
    
</password></login>

    (Yeah, I know that’s not secure, but this is just for testing and feasibility study. The whole damn sandbox is an insecure mess).

    Now, if I use VLC to open the URI, it works great (of course). Looking at it with a packet analyzer, I see the following negotiation between the device and my computer (at .2 - Clipped for brevity) :

    Id = 11
    
Source = 192.168.4.12
    
Destination = 192.168.4.2
    
Captured Length = 82
    
Packet Length = 82
    
Protocol = TCP
    
Date Received = 2019-08-06 12:18:37 +0000
    
Time Delta = 1.342024087905884
    
Information = 554 -> 53755 ([ECN, ACK, SYN], Seq=696764098, Ack=3139240483, Win=28960)
    
                    °
    
                    °
    
                    °
    
Id = 48
    
Source = 192.168.4.12
    
Destination = 192.168.4.2
    
Captured Length = 366
    
Packet Length = 366
    
Protocol = TCP
    
Date Received = 2019-08-06 12:18:38 +0000
    
Time Delta = 2.09382700920105
    
Information = 554 -> 53755 ([ACK, PUSH], Seq=696765606, Ack=3139242268, Win=1073)

    Followed immediately by UDP stream packets.

    If, however, I feed the same URI to ffmpeg :

    ffmpeg -i rtsp://<login>:<password>@192.168.4.12/onvif-media/media.amp?profile=profile_1_jpeg&amp;streamtype=unicast -c:v libx264 -crf 21 -preset veryfast -g 30 -sc_threshold 0 -f hls -hls_time 4 /Volumes/Development/webroot/fftest/stream.m3u8
    
</password></login>

    I get nothing. No negotiation at all between the device and my computer.

    After that, if I then remove the &amp;streamtype=unicast argument, I get a negotiation, and a stream :

    Id = 10
    
Source = 192.168.4.12
    
Destination = 192.168.4.2
    
Captured Length = 82
    
Packet Length = 82
    
Protocol = TCP
    
Date Received = 2019-08-06 10:37:48 +0000
    
Time Delta = 3.047425985336304
    
Information = 554 -> 49606 ([ECN, ACK, SYN], Seq=457514925, Ack=2138974173, Win=28960)
    
                    °
    
                    °
    
                    °
    
Id = 31
    
Source = 192.168.4.12
    
Destination = 192.168.4.2
    
Captured Length = 345
    
Packet Length = 345
    
Protocol = TCP
    
Date Received = 2019-08-06 10:37:49 +0000
    
Time Delta = 3.840152025222778
    
Information = 554 -> 49606 ([ACK, PUSH], Seq=457516393, Ack=2138975704, Win=1039)

    I will, of course, be continuing to work out why this is [not] happening, and will post any solutions that I find, but, like I said, I’m fairly new to this, so it’s entirely possible that I’m missing some basic stuff, and would appreciate any guidance.

    Thanks !

  • Evolution #4148 : Augmenter la largeur de l’espace privé

    14 juin 2018, par tcharlss (*´_ゝ｀)

    J’ai activé le plugin sur un site de test pour se faire une idée du résultat : http://bravecassine.com/dev/spip-interface/ecrire/

    • login : spip
    • mot de passe : spipspip

    La colonne #extra est visible sur la page d’un article : http://bravecassine.com/dev/spip-interface/ecrire/?exec=article&id_article=1

  • Anomalie #4363 : mot de passe vide bloque le formulaire de réinitialisation du mot de passe d’un u...

    9 août 2019, par RastaPopoulos ♥

    Oui un auteur peut juste être une signature, mais pourquoi on bloquerait l’envoi d’un jeton de mot de passe ? Car si tel auteur est juste une signature, alors il n’a pas de d’email non plus (Victor Hugo n’a pas d’email), et si jamais à tout hasard il y a un email associé, c’est volontairement et donc ça ne sera pas l’email d’une personne qui n’aurait pas le droit de récupérer un accès à ce compte !

    Donc à partir du moment où il y a bien un email, on devrait pouvoir faire un rappel de mot de passe et alors en définir un nouveau, peu importe qu’il y ait déjà un mot de passe ou pas. (Et moi j’ajouterais : et même s’il n’y a pas de login, vu que l’email permet aussi de se loguer, mais bon c’est encore une autre décision.)

Navigation