
Recherche avancée
Médias (1)
-
The pirate bay depuis la Belgique
1er avril 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Image
Autres articles (81)
-
Amélioration de la version de base
13 septembre 2013Jolie sélection multiple
Le plugin Chosen permet d’améliorer l’ergonomie des champs de sélection multiple. Voir les deux images suivantes pour comparer.
Il suffit pour cela d’activer le plugin Chosen (Configuration générale du site > Gestion des plugins), puis de configurer le plugin (Les squelettes > Chosen) en activant l’utilisation de Chosen dans le site public et en spécifiant les éléments de formulaires à améliorer, par exemple select[multiple] pour les listes à sélection multiple (...) -
Menus personnalisés
14 novembre 2010, parMediaSPIP utilise le plugin Menus pour gérer plusieurs menus configurables pour la navigation.
Cela permet de laisser aux administrateurs de canaux la possibilité de configurer finement ces menus.
Menus créés à l’initialisation du site
Par défaut trois menus sont créés automatiquement à l’initialisation du site : Le menu principal ; Identifiant : barrenav ; Ce menu s’insère en général en haut de la page après le bloc d’entête, son identifiant le rend compatible avec les squelettes basés sur Zpip ; (...) -
Gestion de la ferme
2 mars 2010, parLa 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"
Sur d’autres sites (11250)
-
SRT protocol not found - Raspbery Pi 4 via ffmpeg
12 août 2021, par Tim MartinWe tried to stream from a rasp Pi 4 via SRT, but we got a error : "protocol not found". Our command line is :


ffplay srt://127.0.0.1:9500?mode=listener&latency=20000



We tried the following guides :
https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu
how to compile ffmpeg with enabling libsrt
https://www.undergroundnews.dk/index.php/item/107-rtmp-eller-srt-streaming


Those guides worked so far and compiled but we still got the error message.


Do you have any ideas how to get the srt protocol working on a pi via ffmpeg ?


-
Multimedia Exploration Journal : The Past Doesn’t Die
12 juillet 2011, par Multimedia Mike — Game HackingNew haul of games, new (old) multimedia formats.
Lords of Midnight
Check out the box copy scan for Lords of Midnight in MobyGames. In particular, I’d like to call your attention to this little blurb :
Ahem, "Journey through an immense world — the equivalent of 8 CD-ROMs." Yet, when I procured the game, it only came on a single CD-ROM. It’s definitely a CD-ROM (says so on the disc) and, coming from 1995, certainly predates the earliest DVD-ROMs (which can easily store 8 CD-ROMs on a disc). Thus, I wanted to jump in a see if they were using some phenomenal compression in order to squeeze so much info into 600 or so megabytes.
I was surprised to see the contents of the disc clocking in at just under 40 megabytes. An intro movie and an outro movie account for 75% of that. Format ? None other than that curious ASCII anomaly, ARMovie/RPL with Escape 122 codec data.
Cyclemania
Cyclemania is one of those FMV backdrop action games, but with a motorcycle theme. I had a good feeling I would find some odd multimedia artifacts here and the game didn’t disappoint. The videos are apparently handled using 3-4 discrete files per animation. I’ve documented my cursory guesses and linked some samples at the new MultimediaWiki page.
Interplay ACMP
This is unrelated to this particular acquistion, but I was contacted today about audio files harvested from the 1993 DOS game Star Trek : Judgment Rites. The files begin with the ASCII signature "Interplay ACMP Data". This reminds me of Interplay MVE files which begin with the similar string "Interplay MVE File". My theory is that these files use the ACOMP compression format, though I’m still trying to make it fit.Wiki and samples are available as usual if you’d like to add your own research.
-
RTP and H.264 (Packetization Mode 1)... Decoding RAW Data... Help understanding the audio and STAP-A packets
12 février 2014, par LaneI am attempting to re-create a video from a Wireshark capture. I have researched extensively and the following links provided me with the most useful information...
How to convert H.264 UDP packets to playable media stream or file (defragmentation) (and the 2 sub-links)
H.264 over RTP - Identify SPS and PPS Frames...I understand from these links and RFC (RTP Payload Format for H.264 Video) that...
-
The Wireshark capture shows a client communicating with a server via RTSP/RTP by making the following calls... OPTIONS, DESCRIBE, SETUP, SETUP, then PLAY (both audio and video tracks exist)
-
The RTSP response from PLAY (that contains the Sequence and Picture Parameter Sets) contains the following (some lines excluded)...
Media Description, name and address (m) : audio 0 RTP/AVP 0
Media Attribute (a) : rtpmap:0 PCMU/8000/1
Media Attribute (a) : control:trackID=1
Media Attribute (a) : x-bufferdelay:0Media Description, name and address (m) : video 0 RTP/AVP 98
Media Attribute (a) : rtpmap:98 H264/90000
Media Attribute (a) : control:trackID=2
Media Attribute (a) : fmtp:98 packetization-mode=1 ;profile-level-id=4D0028 ;sprop-parameter-sets=J00AKI2NYCgC3YC1AQEBQAAA+kAAOpg6GAC3IAAzgC7y40MAFuQABnAF3lwWNF3A,KO48gA==Media Description, name and address (m) : metadata 0 RTP/AVP 100
Media Attribute (a) : rtpmap:100 IQ-METADATA/90000
Media Attribute (a) : control:trackID=3...the packetization-mode=1 means that only NAL Units, STAP-A and FU-A are accepted
- The streaming RTP packets (video only, DynamicRTP-Type-98) arrive in the following order...
1x
[RTP Header]
0x78 0x00 (Type is 24, meaning STAP-A)
[Remaining Payload]36x
[RTP Header]
0x7c (Type is 28, meaning FU-A) then either 0x85 (first) 0x05 (middle) or 0x45 (last)
[Remaining Payload]1x
[RTP Header]
0x18 0x00 (Type is 24, meaning STAP-A)
[Remaining Payload]8x
[RTP Header]
0x5c (Type is 28, meaning FU-A) then either 0x81 (first) 0x01 (middle) or 0x41 (last)
[Remaining Payload]...the cycle then repeats... typically there are 29 0x18/0x5c RTP packets for each 0x78/0x7c packet
- Approximately every 100 packets, there is an audio RTP packet, all have their Marker set to true and their sequence numbers ascend as expected. Sometimes there is an individual RTP audio packet and sometimes there are three, see a sample one here...
RTP 1042 PT=ITU-T G.711 PCMU, SSRC=0x238E1F29, Seq=31957, Time=1025208762, Mark
...also, the type of each audio RTP packet is different (as far as first bytes go... I see 0x4e, 0x55, 0xc5, 0xc1, 0xbc, 0x3c, 0x4d, 0x5f, 0xcc, 0xce, 0xdc, 0x3e, 0xbf, 0x43, 0xc9, and more)
- From what I gather... to re-create the video, I first need to create a file of the format
0x000001 [SPS Payload]
0x000001 [PPS Payload]
0x000001 [Complete H.264 Frame (NAL Byte, followed by all fragmented RTP payloads without the first 2 bytes)
0x000001 [Next Frame]
Etc...I made some progress where I can run "ffmpeg -i file" without it saying a bad input format or unable to find codec. But currently it complains something about MP3. My questions are as follows...
-
Should I be using the SPS and PPS payload returned by the response to the DESCRIBE RTSP call or use the data sent in the first STAP-A RTP packets (0x78 and 0x18) ?
-
How does the file format change to incorporate the audio track ?
-
Why is the audio track payload headers all over the place and how can I make sense / utilize them ?
-
Is my understanding of anything incorrect ?
Any help is GREATLY appreciated, thanks !
-