Recherche avancée

Médias (1)

Mot : - Tags -/artwork

Autres articles (27)

  • Support audio et vidéo HTML5

    10 avril 2011

    MediaSPIP 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, par

    MediaSPIP 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, par

    Le 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)

  • Capturing RTP Timestamps

    10 septembre 2019, par m00ncake

    I 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.0

    In 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 &amp; 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 &amp; 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 &amp;&amp;
    
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 &amp;&amp; !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 &amp; 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.

  • FFmpeg .jpg images to .mp4 incompatible with Windows Media Player

    8 janvier 2020, par willspill

    I have a series of 10 images with which I am trying to form an animation. I have used the following code below in the command line :

    ffmpeg -f image2 -i plot-%03d.jpg -r 5 -pix_fmt yuv420p -vcodec mpeg4 output.mp4

    This creates a .mp4 file with a seemingly valid file size, however, when trying to open with Windows Media Player gives the following error :

    Windows Media Player cannot play the file. The Player might not support the file type or might not support the codec that was used to compress the file.

    I have tried many solutions from previous threads but have found no solution. I have checked that my version of windows media player is compatible with mp4, avi, wmv etc. and have tried all of these outputs also. Any ideas of the issue ?

    The full code :

    M:Example\Frames_plot-001_jpg>ffmpeg -f image2 -i plot-%03
    
ix_fmt yuv420p -vcodec mpeg4 output.mp4
    
FFmpeg version SVN-r11200, Copyright (c) 2000-2007 Fabrice Bellard,
    
  configuration: --enable-memalign-hack
    
  libavutil version: 49.5.0
    
  libavcodec version: 51.48.0
    
  libavformat version: 52.1.0
    
  built on Dec 11 2007 14:33:27, gcc: 3.4.5 (mingw special)
    
Input #0, image2, from 'plot-%03d.jpg':
    
  Duration: 00:00:00.4, start: 0.000000, bitrate: N/A
    
    Stream #0.0: Video: mjpeg, yuvj420p, 4167x4167 [PAR 120:120 DAR
    
tb(r)
    
Output #0, mp4, to 'output.mp4':
    
    Stream #0.0: Video: mpeg4, yuv420p, 4167x4167 [PAR 1:1 DAR 1:1]
    
 kb/s,  5.00 tb(c)
    
Stream mapping:
    
  Stream #0.0 -> #0.0
    
Press [q] to stop encoding
    
Compiler did not align stack variables. Libavcodec has been miscomp
    
and may be very slow or crash. This is not a bug in libavcodec,
    
but in the compiler. You may try recompiling using gcc >= 4.2.
    
Do not report crashes to FFmpeg developers.
    
frame=    3 fps=  3 q=4.0 Lsize=     917kB time=0.6 bitrate=12522.6
    
video:916kB audio:0kB global headers:0kB muxing overhead 0.072455%

  • 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