Recherche avancée

Médias (1)

Mot : - Tags -/copyleft

Autres articles (35)

  • 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

  • Contribute to a better visual interface

    13 avril 2011

    MediaSPIP is based on a system of themes and templates. Templates define the placement of information on the page, and can be adapted to a wide range of uses. Themes define the overall graphic appearance of the site.
    Anyone can submit a new graphic theme or template and make it available to the MediaSPIP community.

  • 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 (...)

Sur d’autres sites (5420)

  • FFMPEG Understanding AVFrame::linesize (Audio)

    11 avril 2021, par user3584691

    As per the doucmentation of AVFrame, for audio, lineSize is size in bytes of each plane and only linesize[0] may be set. But however, am unsure whether lineszie[0] is holding per plane buffer size or is it the complete buffer size and we have to divide it by no of channels to get per plane buffer size.

    



    For Example, when I call
 int data_size = av_samples_get_buffer_size(NULL, iDesiredNoOfChannels, iAudioSamples, (AVSampleFormat)iDesiredFormat, 0) ; For iDesiredNoOfChannels = 2, iAudioSamples = 1024 & iDesiredFormat = AV_SAMPLE_FMT_FLTP data_size=8192. Pretty straightforward, as each sample is 4 bytes and since there are 2 channels total memory will be (1024 * 4 * 2) bytes. As such lineSize[0] should be 4096 for planar audio. data[0] & data[1] should be each of size 4096. However, pFrame->lineSize[0] is giving 8192. So to get the size per plane, I have to do pFrame->lineSize[0] / pFrame->channels. Isn't this behaviour different from what the documentation suggests or is my understanding of the documentaion wrong.

    


  • Why is recording webcam with FFmpeg much faster with an input format ?

    29 juin 2021, par Alter

    Question is the title

    


    It's a basic question, but one that I can't find clearly answered in google or the documentation, which says :

    


    


    If you specify the input format and device then ffmpeg can grab video and audio directly.

    


    


    This isn't explicit enough for a beginner like me and raises other questions. What does ffmpeg do when the input format isn't specified and why is it so slow ? If ffmpeg can figure out the encoding, doesn't it just do so once ?

    


    Examples

    


    For completeness... I'm using an Rasperry Pi 4 with a Picamera2 to record 1080p

    


    With input format, I get the full 30fps : ffmpeg -input_format h264 -i /dev/video0 -codec h264_v4l2m2m test.h264

    


    Without the input format, I get about 5fps : ffmpeg -i /dev/video0 -codec h264_v4l2m2m test.h264

    


    Note : it will run without the hardware acceleration option -codec h264_v4l2m2m but doesn't reach the full 30fps

    


    Formats

    


    In response to @llogan's comment, the output of v4l2-ctl --list-formats-ext is :

    


    ioctl: VIDIOC_ENUM_FMT
    Type: Video Capture

    [0]: 'YU12' (Planar YUV 4:2:0)
        Size: Stepwise 32x32 - 2592x1944 with step 2/2
    [1]: 'YUYV' (YUYV 4:2:2)
        Size: Stepwise 32x32 - 2592x1944 with step 2/2
    [2]: 'RGB3' (24-bit RGB 8-8-8)
        Size: Stepwise 32x32 - 2592x1944 with step 2/2
    [3]: 'JPEG' (JFIF JPEG, compressed)
        Size: Stepwise 32x32 - 2592x1944 with step 2/2
    [4]: 'H264' (H.264, compressed)
        Size: Stepwise 32x32 - 2592x1944 with step 2/2
    [5]: 'MJPG' (Motion-JPEG, compressed)
        Size: Stepwise 32x32 - 2592x1944 with step 2/2
    [6]: 'YVYU' (YVYU 4:2:2)
        Size: Stepwise 32x32 - 2592x1944 with step 2/2
    [7]: 'VYUY' (VYUY 4:2:2)
        Size: Stepwise 32x32 - 2592x1944 with step 2/2
    [8]: 'UYVY' (UYVY 4:2:2)
        Size: Stepwise 32x32 - 2592x1944 with step 2/2
    [9]: 'NV12' (Y/CbCr 4:2:0)
        Size: Stepwise 32x32 - 2592x1944 with step 2/2
    [10]: 'BGR3' (24-bit BGR 8-8-8)
        Size: Stepwise 32x32 - 2592x1944 with step 2/2
    [11]: 'YV12' (Planar YVU 4:2:0)
        Size: Stepwise 32x32 - 2592x1944 with step 2/2
    [12]: 'NV21' (Y/CrCb 4:2:0)
        Size: Stepwise 32x32 - 2592x1944 with step 2/2
    [13]: 'RX24' (32-bit XBGR 8-8-8-8)
        Size: Stepwise 32x32 - 2592x1944 with step 2/2


    


  • lavfi/drawutils : overhaul to improve pixel format support

    24 décembre 2021, par rcombs
    lavfi/drawutils : overhaul to improve pixel format support

    - No longer mixes u8 and u16 component accesses (this was UB)

    - De-duplicated 8->16 conversion

    - De-duplicated component -> plane+offset conversion

    - De-duplicated planar + packed RGB

    - No longer calls ff_fill_rgba_map

    - Removed redundant comp_mask data member

    - RGB0 and related formats no longer write an alpha value to the 0 byte

    - Non-planar YA formats now work correctly

    - High-bit-depth semi-planar YUV now works correctly
    • [DH] libavfilter/drawutils.c
    • [DH] libavfilter/drawutils.h
    • [DH] tests/ref/fate/filter-pixfmts-pad

Navigation