Recherche avancée

Médias (91)

Autres articles (72)

  • Qu’est ce qu’un éditorial

    21 juin 2013, par

    Ecrivez votre de point de vue dans un article. Celui-ci sera rangé dans une rubrique prévue à cet effet.
    Un éditorial est un article de type texte uniquement. Il a pour objectif de ranger les points de vue dans une rubrique dédiée. Un seul éditorial est placé à la une en page d’accueil. Pour consulter les précédents, consultez la rubrique dédiée.
    Vous pouvez personnaliser le formulaire de création d’un éditorial.
    Formulaire de création d’un éditorial Dans le cas d’un document de type éditorial, les (...)

  • Personnaliser en ajoutant son logo, sa bannière ou son image de fond

    5 septembre 2013, par

    Certains thèmes prennent en compte trois éléments de personnalisation : l’ajout d’un logo ; l’ajout d’une bannière l’ajout d’une image de fond ;

  • Gestion des droits de création et d’édition des objets

    8 février 2011, par

    Par défaut, beaucoup de fonctionnalités sont limitées aux administrateurs mais restent configurables indépendamment pour modifier leur statut minimal d’utilisation notamment : la rédaction de contenus sur le site modifiables dans la gestion des templates de formulaires ; l’ajout de notes aux articles ; l’ajout de légendes et d’annotations sur les images ;

Sur d’autres sites (15250)

  • fate : Remove duplicate wmv8_x8intra.wmv test

    8 mai 2016, par Michael Niedermayer
    fate : Remove duplicate wmv8_x8intra.wmv test
    

    Also temporary enable the test so we get updated fate failure statistics

    Note, this does not work on all platforms, it fails on MIPS
    and ml archives indicate it failed on x86 openbsd with some compilers as well

    Reviewed-by : Derek Buitenhuis <derek.buitenhuis@gmail.com>
    Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>

    • [DH] tests/fate/microsoft.mak
    • [DH] tests/ref/fate/wmv8-intrax8
  • fate : Fix the sub-mcc tests on Windows in eastern time zones

    11 août, par Martin Storsjö
    fate : Fix the sub-mcc tests on Windows in eastern time zones
    

    Previously, these tests failed when running on Windows, if the
    system is configured with a time zone east of Greenwich, i.e.
    with a positive GMT offset.

    The muxer converts the creation_date given by the user using
    av_parse_time to unix time, as a time_t. The creation_date is
    interpreted as a local time, i.e. according to the current time
    zone. (This time_t value is then converted back to a broken out
    local time form with localtime_r.)

    The given reference date/time, "1970-01-01T00:00:00", is the
    origin point for unix time, corresponding to time_t zero. However
    when interpreted as local time, this doesn't map to exactly zero.
    Time zones east of Greenwich reached this time a number of hours
    before the point of zero time_t - so the corresponding time_t
    value essentially is minus the GMT offset, in seconds.

    Windows mktime returns an error, returning (time_t)-1, when given
    such a "struct tm", while e.g. glibc mktime happily returns a
    negative time_t. av_parse_time doesn't check the return value of
    mktime for potential errors.

    This is observable with the following test snippet :

    struct tm tm = 0  ;
    tm.tm_year = 70 ;
    tm.tm_isdst = -1 ;
    tm.tm_mday = 1 ;
    tm.tm_hour = 0 ;
    time_t t = mktime(&tm) ;
    printf("%d-%02d-%02d %02d :%02d :%02d\n", tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, tm.tm_hour, tm.tm_min, tm.tm_sec) ;
    printf("t %d\n", (int)t) ;

    By varying the value of tm_hour and the system time zone, one
    can observe that Windows mktime returns -1 for all time_t values
    that would have been negative.

    This range limit is also documented by Microsoft in detail at
    https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/mktime-mktime32-mktime64.

    To avoid the issue, pick a different, arbitrary reference time,
    which should have a nonnegative time_t for all time zones.

    • [DH] tests/fate/subtitles.mak
    • [DH] tests/ref/fate/sub-mcc-remux
    • [DH] tests/ref/fate/sub-mcc-remux-eia608
    • [DH] tests/ref/fate/sub-mcc-remux-eia608-bsf
    • [DH] tests/ref/fate/sub-mcc-remux-eia608-recode
  • OpenCV 4.5.2 takes a long time (>100ms) to retrieve a single frame from a webcam, C++ on Windows 10

    9 juin 2021, par Mustard Tiger

    I've been having a tough time getting my webcam working quickly with opencv. Frames take a very long time to read, (a recorded average of 124ms across 500 frames) I've tried on three different computers (running Windows 10) with a logitech C922 webcam. The most recent machine I tested on has a Ryzen 9 3950X, with 32gbs of ram ; no lack of power.

    &#xA;

    Here is the code :

    &#xA;

    cv::VideoCapture cap = cv::VideoCapture(m_cameraNum);&#xA;&#xA;// Check if camera opened successfully&#xA;if (!cap.isOpened())&#xA;{&#xA;    m_logger->critical("Error opening video stream or file\n\r");&#xA;    return -1;&#xA;}&#xA;&#xA;bool result = true;&#xA;result &amp;= cap.set(cv::CAP_PROP_FRAME_WIDTH, 1280);&#xA;result &amp;= cap.set(cv::CAP_PROP_FRAME_HEIGHT, 720);&#xA;&#xA;bool ready = false;&#xA;std::vector<string> timeLog;&#xA;timeLog.reserve(50000);&#xA;int i = 0;&#xA;&#xA;while (i &lt; 500)&#xA;{&#xA;    auto start = std::chrono::system_clock::now();&#xA;    &#xA;    cv::Mat img;&#xA;    ready = cap.read(img);&#xA;&#xA;    // If the frame is empty, break immediately&#xA;    if (!ready)&#xA;    {&#xA;        timeLog.push_back("continue");&#xA;        continue;&#xA;    }&#xA;&#xA;    i&#x2B;&#x2B;;&#xA;    auto end = std::chrono::system_clock::now();&#xA;    timeLog.push_back(std::to_string(std::chrono::duration_cast(end - start).count()));&#xA;}&#xA;&#xA;for (auto&amp; entry : timeLog)&#xA;    m_logger->info(entry);&#xA;&#xA;cap.release();&#xA;return 0;&#xA;</string>

    &#xA;

    Notice that I write the elapsed time to a log file at the end of execution. The average time is 124ms for debug and release, and not one instance of "continue" after half a dozen runs.

    &#xA;

    It doesn't matter if I use USB 2 or USB 3 ports (the camera is USB2) or if I run a debug build or a release build, the log file will show anywhere from 110ms to 130ms of time for each frame. The camera works fine in other app, OBS can get a smooth 1080@30fps or 720@60fps.

    &#xA;

    Stepping through the debugger and doing a lot of Googling, I've learned the following about my system :

    &#xA;

      &#xA;
    • The backend chosen by default is DSHOW. GStreamer and FFMPEG are also available.
    • &#xA;

    • DSHOW uses FFMPEG somehow (it needs the FFMPEG dll) but I cannot use FFMPEG directly through opencv. Attempting to use cv::VideoCapture(m_cameraNum, cv::CAP_FFMPEG) always fails. It seems like Opencv's interface to FFMPEG is only capable of opening video files.
    • &#xA;

    • Microsoft really screwed up camera devices in Windows a few years back, not sure if this is related to my problem.
    • &#xA;

    &#xA;

    Here's a short list of the fixes I have tried, most taken from older SO posts :

    &#xA;

      &#xA;
    • result &= cap.set(cv::CAP_PROP_FRAME_COUNT, 30) ; // Returns false, does nothing
    • &#xA;

    • result &= cap.set(cv::CAP_PROP_CONVERT_RGB, 0) ; // Returns true, does nothing
    • &#xA;

    • result &= cap.set(cv::CAP_PROP_MODE, cv::VideoWriter::fourcc('M', 'J', 'P', 'G')) ; // Returns false, does nothing
    • &#xA;

    • Set registry key from http://alax.info/blog/1693 that should disable the new Windows camera server.
    • &#xA;

    • Updated from 4.5.0 to 4.5.2, no change.
    • &#xA;

    • Asked device manager to find a newer driver, no newer driver found.
    • &#xA;

    &#xA;

    I'm out of ideas. Any help ?

    &#xA;