
Recherche avancée
Médias (2)
-
Rennes Emotion Map 2010-11
19 octobre 2011, par
Mis à jour : Juillet 2013
Langue : français
Type : Texte
-
Carte de Schillerkiez
13 mai 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Texte
Autres articles (27)
-
Support audio et vidéo HTML5
10 avril 2011MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...) -
HTML5 audio and video support
13 avril 2011, parMediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
For older browsers the Flowplayer flash fallback is used.
MediaSPIP allows for media playback on major mobile platforms with the above (...) -
De l’upload à la vidéo finale [version standalone]
31 janvier 2010, parLe chemin d’un document audio ou vidéo dans SPIPMotion est divisé en trois étapes distinctes.
Upload et récupération d’informations de la vidéo source
Dans un premier temps, il est nécessaire de créer un article SPIP et de lui joindre le document vidéo "source".
Au moment où ce document est joint à l’article, deux actions supplémentaires au comportement normal sont exécutées : La récupération des informations techniques des flux audio et video du fichier ; La génération d’une vignette : extraction d’une (...)
Sur d’autres sites (2048)
-
Modifying FFmpeg and OpenCV source code to capture the RTP timestamp for each packet in NTP format
22 août 2019, par Fr0styI was trying a little experiment in order to get the timestamps of the RTP packets using the VideoCapture class from Opencv’s source code in python, also had to modify FFmpeg to accommodate the changes in Opencv.
Since I read about the RTP packet format.Wanted to fiddle around and see if I could manage to find a way to get the NTP timestamps. Was unable to find any reliable help in trying to get RTP timestamps. So tried out this little hack.
Credits to ryantheseer on github for the modified code.
Version of FFmpeg : 3.2.3
Version of Opencv : 3.2.0In Opencv source code :
modules/videoio/include/opencv2/videoio.hpp :
Added two getters for the RTP timestamp :
.....
/** @brief Gets the upper bytes of the RTP time stamp in NTP format (seconds).
*/
CV_WRAP virtual int64 getRTPTimeStampSeconds() const;
/** @brief Gets the lower bytes of the RTP time stamp in NTP format (fraction of seconds).
*/
CV_WRAP virtual int64 getRTPTimeStampFraction() const;
.....modules/videoio/src/cap.cpp :
Added an import and added the implementation of the timestamp getter :
....
#include <cstdint>
....
....
static inline uint64_t icvGetRTPTimeStamp(const CvCapture* capture)
{
return capture ? capture->getRTPTimeStamp() : 0;
}
...
</cstdint>Added the C++ timestamp getters in the VideoCapture class :
....
/**@brief Gets the upper bytes of the RTP time stamp in NTP format (seconds).
*/
int64 VideoCapture::getRTPTimeStampSeconds() const
{
int64 seconds = 0;
uint64_t timestamp = 0;
//Get the time stamp from the capture object
if (!icap.empty())
timestamp = icap->getRTPTimeStamp();
else
timestamp = icvGetRTPTimeStamp(cap);
//Take the top 32 bytes of the time stamp
seconds = (int64)((timestamp & 0xFFFFFFFF00000000) / 0x100000000);
return seconds;
}
/**@brief Gets the lower bytes of the RTP time stamp in NTP format (seconds).
*/
int64 VideoCapture::getRTPTimeStampFraction() const
{
int64 fraction = 0;
uint64_t timestamp = 0;
//Get the time stamp from the capture object
if (!icap.empty())
timestamp = icap->getRTPTimeStamp();
else
timestamp = icvGetRTPTimeStamp(cap);
//Take the bottom 32 bytes of the time stamp
fraction = (int64)((timestamp & 0xFFFFFFFF));
return fraction;
}
...modules/videoio/src/cap_ffmpeg.cpp :
Added an import :
...
#include <cstdint>
...
</cstdint>Added a method reference definition :
...
static CvGetRTPTimeStamp_Plugin icvGetRTPTimeStamp_FFMPEG_p = 0;
...Added the method to the module initializer method :
...
if( icvFFOpenCV )
...
...
icvGetRTPTimeStamp_FFMPEG_p =
(CvGetRTPTimeStamp_Plugin)GetProcAddress(icvFFOpenCV, "cvGetRTPTimeStamp_FFMPEG");
...
...
icvWriteFrame_FFMPEG_p != 0 &&
icvGetRTPTimeStamp_FFMPEG_p !=0)
...
icvGetRTPTimeStamp_FFMPEG_p = (CvGetRTPTimeStamp_Plugin)cvGetRTPTimeStamp_FFMPEG;Implemented the getter interface :
...
virtual uint64_t getRTPTimeStamp() const
{
return ffmpegCapture ? icvGetRTPTimeStamp_FFMPEG_p(ffmpegCapture) : 0;
}
...In FFmpeg’s source code :
libavcodec/avcodec.h :
Added the NTP timestamp definition to the AVPacket struct :
typedef struct AVPacket {
...
...
uint64_t rtp_ntp_time_stamp;
}libavformat/rtpdec.c :
Store the ntp time stamp in the struct in the finalize_packet method :
static void finalize_packet(RTPDemuxContext *s, AVPacket *pkt, uint32_t timestamp)
{
uint64_t offsetTime = 0;
uint64_t rtp_ntp_time_stamp = timestamp;
...
...
/*RM: Sets the RTP time stamp in the AVPacket */
if (!s->last_rtcp_ntp_time || !s->last_rtcp_timestamp)
offsetTime = 0;
else
offsetTime = s->last_rtcp_ntp_time - ((uint64_t)(s->last_rtcp_timestamp) * 65536);
rtp_ntp_time_stamp = ((uint64_t)(timestamp) * 65536) + offsetTime;
pkt->rtp_ntp_time_stamp = rtp_ntp_time_stamp;libavformat/utils.c :
Copy the ntp time stamp from the packet to the frame in the read_frame_internal method :
static int read_frame_internal(AVFormatContext *s, AVPacket *pkt)
{
...
uint64_t rtp_ntp_time_stamp = 0;
...
while (!got_packet && !s->internal->parse_queue) {
...
//COPY OVER the RTP time stamp TODO: just create a local copy
rtp_ntp_time_stamp = cur_pkt.rtp_ntp_time_stamp;
...
#if FF_API_LAVF_AVCTX
update_stream_avctx(s);
#endif
if (s->debug & FF_FDEBUG_TS)
av_log(s, AV_LOG_DEBUG,
"read_frame_internal stream=%d, pts=%s, dts=%s, "
"size=%d, duration=%"PRId64", flags=%d\n",
pkt->stream_index,
av_ts2str(pkt->pts),
av_ts2str(pkt->dts),
pkt->size, pkt->duration, pkt->flags);
pkt->rtp_ntp_time_stamp = rtp_ntp_time_stamp; #Just added this line in the if statement.
return ret;My python code to utilise these changes :
import cv2
uri = 'rtsp://admin:password@192.168.1.67:554'
cap = cv2.VideoCapture(uri)
while True:
frame_exists, curr_frame = cap.read()
# if frame_exists:
k = cap.getRTPTimeStampSeconds()
l = cap.getRTPTimeStampFraction()
time_shift = 0x100000000
#because in the getRTPTimeStampSeconds()
#function, seconds was multiplied by 0x10000000
seconds = time_shift * k
m = (time_shift * k) + l
print("Imagetimestamp: %i" % m)
cap.release()What I am getting as my output :
Imagetimestamp: 0
Imagetimestamp: 212041451700224
Imagetimestamp: 212041687629824
Imagetimestamp: 212041923559424
Imagetimestamp: 212042159489024
Imagetimestamp: 212042395418624
Imagetimestamp: 212042631348224
...What astounded me the most was that when i powered off the ip camera and powered it back on, timestamp would start from 0 then quickly increments. I read NTP time format is relative to January 1, 1900 00:00. Even when I tried calculating the offset, and accounting between now and 01-01-1900, I still ended up getting a crazy high number for the date.
Don’t know if I calculated it wrong. I have a feeling it’s very off or what I am getting is not the timestamp.
-
Having trouble obtaining the time from RTP Timestamps obtained through OpenCV
24 août 2019, par Fr0styI 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.1import 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.792000I’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.
-
Warning "i686-mingw32-pkg-config not found, library detection may fail" while cross compiling ffmpeg
1er juillet 2019, par S BI get the following warning while trying to cross compile ffmpeg as below
$ ./configure --enable-gpl --enable-version3 --enable-libgsm --enable-libvorbis --enable-libtheora --enable-libspeex --enable-libmp3lame --enable-libopenjpeg --enable-libopencore_amrwb --enable-libopencore_amrnb --arch=x86 --enable-runtime-cpudetect --enable-static --disable-shared --enable-libxvid --enable-libx264 --target-os=mingw32 --enable-avisynth --enable-w32threads --cross-prefix=i686-mingw32- --cc='i686-mingw32-gcc' --enable-memalign-hack --disable-doc --enable-avfilter --disable-ffplay --disable-ffserver --disable-ffprobe
Configure ran fine but with the following warning
License: GPL version 3 or later
Creating config.mak and config.h...
libavutil/avconfig.h is unchanged
WARNING: i686-mingw32-pkg-config not found, library detection may fail.How do I provide
i686-mingw32-pkg-config
to configure ?