Recherche avancée

Médias (91)

Autres articles (37)

  • Le plugin : Podcasts.

    14 juillet 2010, par

    Le problème du podcasting est à nouveau un problème révélateur de la normalisation des transports de données sur Internet.
    Deux formats intéressants existent : Celui développé par Apple, très axé sur l’utilisation d’iTunes dont la SPEC est ici ; Le format "Media RSS Module" qui est plus "libre" notamment soutenu par Yahoo et le logiciel Miro ;
    Types de fichiers supportés dans les flux
    Le format d’Apple n’autorise que les formats suivants dans ses flux : .mp3 audio/mpeg .m4a audio/x-m4a .mp4 (...)

  • Déploiements possibles

    31 janvier 2010, par

    Deux types de déploiements sont envisageable dépendant de deux aspects : La méthode d’installation envisagée (en standalone ou en ferme) ; Le nombre d’encodages journaliers et la fréquentation envisagés ;
    L’encodage de vidéos est un processus lourd consommant énormément de ressources système (CPU et RAM), il est nécessaire de prendre tout cela en considération. Ce système n’est donc possible que sur un ou plusieurs serveurs dédiés.
    Version mono serveur
    La version mono serveur consiste à n’utiliser qu’une (...)

  • Submit bugs and patches

    13 avril 2011

    Unfortunately a software is never perfect.
    If you think you have found a bug, report it using our ticket system. Please to help us to fix it by providing the following information : the browser you are using, including the exact version as precise an explanation as possible of the problem if possible, the steps taken resulting in the problem a link to the site / page in question
    If you think you have solved the bug, fill in a ticket and attach to it a corrective patch.
    You may also (...)

Sur d’autres sites (8259)

  • avcodec/nvenc : De-compensate aspect ratio compensation of DVD-like content.

    28 janvier 2015, par Philip Langdale
    avcodec/nvenc : De-compensate aspect ratio compensation of DVD-like content.
    

    For reasons we are not privy to, nvidia decided that the nvenc encoder
    should apply aspect ratio compensation to ’DVD like’ content, assuming that
    the content is not bt.601 compliant, but needs to be bt.601 compliant. In
    this context, that means that they make the following, questionable,
    assumptions :

    1) If the input dimensions are 720x480 or 720x576, assume the content has
    an active area of 704x480 or 704x576.

    2) Assume that whatever the input sample aspect ratio is, it does not account
    for the difference between ’physical’ and ’active’ dimensions.

    From, these assumptions, they then conclude that they can ’help’, by adjusting
    the sample aspect ratio by a factor of 45/44. And indeed, if you wanted to
    display only the 704 wide active area with the same aspect ratio as the full
    720 wide image - this would be the correct adjustment factor, but what if you
    don’t ? And more importantly, what if you’re used to ffmpeg not making this kind
    of adjustment at encode time - because none of the other encoders do this !

    And, what if you had already accounted for bt.601 and your input had the
    correct attributes ? Well, it’s going to apply the compensation anyway !
    So, if you take some content, and feed it through nvenc repeatedly, it
    will keep scaling the aspect ratio every time, stretching your video out
    more and more and more.

    So, clearly, regardless of whether you want to apply bt.601 aspect ratio
    adjustments or not, this is not the way to do it. With any other ffmpeg
    encoder, you would do it as part of defining your input paramters or
    do the adjustment at playback time, and there’s no reason by nvenc
    should be any different.

    This change adds some logic to undo the compensation that nvenc would
    otherwise do.

    nvidia engineers have told us that they will work to make this
    compensation mechanism optional in a future release of the nvenc
    SDK. At that point, we can adapt accordingly.

    Signed-off-by : Philip Langdale <philipl@overt.org>
    Reviewed-by : Timo Rothenpieler <timo@rothenpieler.org>
    Signed-off-by : Michael Niedermayer <michaelni@gmx.at>

    • [DH] libavcodec/nvenc.c
  • Nginx with rtmp-module stalls between streams

    14 janvier 2015, par churchmf

    I’m experiencing some troubles using NGINX with rtmp-module as a media server. I wish to present a continuous video as a live stream (with up to 60 second latency). However, due to some hardware constraints, I am unable to stream directly from the device. Instead, I can save out X amount of seconds from the device’s buffer as an MP4. My solution has been to save X seconds of video from the device then stream that X seconds, rise and repeat. This has been working mostly well, except for stalls ( 20 seconds) in the stream between calls.

    I have searched far and wide for a solution to this however most of the people experiencing this problem have the collection of videos before starting the stream and can simply concatenate them.

    My running theory is that when a stream finishes, it does an unpublish event in NGINX followed by a timeout period. This prevents the NGINX server from receiving the next publish until the timeout period has expired. I have tried adjusting nginx.config values related to timeouts, respawns, restarts, and publish, but to no avail.

    Pseudocode :
    while true
    - > capture X seconds of video to "output.mp4" (this takes less than 300ms)
    - > stream the MP4 with FFMPEG (takes X seconds using -re)

    FFMPEG call :
    ffmpeg -re -i "output.mp4" -vcodec libx264 -preset veryfast -maxrate 2000k -bufsize 4000k -g 60 -acodec libmp3lame -b:a 128k -ac 2 -ar 44100 -f flv rtmp :/MYSERVER/live/output

    I am using JWPlayer client side to watch the video stream, however I experience similar issues using VLC.

    I have been trying to figure this out for a few days and I would appreciate any insight an expert to video streaming and NGINX can give. Thank you !

  • ffserver configuration vs ffmpeg parameters

    7 janvier 2015, par bogdanioan.gabor

    I’m not understanding which is the priority when you’re setting movflags (and other parameters) in the ffmpeg, but also into the ffserver.
    Example :

    I have the ffserver configuration like that :

    Port 8080
    BindAddress 0.0.0.0
    MaxHTTPConnections 10
    MaxClients 10
    MaxBandwidth 40000

    <feed>
       File /tmp/feed.ffm
       Feed feed.ffm

       VideoCodec libx264
       AVOptionVideo flags +global_header
       AVOptionVideo movflags faststart+frag_key_frame+empty_moov

       NoAudio
    </feed>

    And the ffmpeg command :

    ffmpeg -rtsp_transport tcp -i "rtsp://x.x.x.x" -an -vcodec copy -movflags faststart+frag_keyframe+empty_moov "http://127.0.0.1:8080/feed.ffm"

    Questions :
    1. Which one has precedence : the parameters from the ffmpeg, or the one from ffserver.
    2. I’m using ffprobe for testing the stream which comes from ffserver. I’ve used faststart, but I’m still getting the "moov atom not found" error ; shouldn’t faststart flag move the moov atom to beginning ?

    More info :

    ffserver version :

    ffserver version 2.3.4 Copyright (c) 2000-2014 the FFmpeg developers
    built on Dec  4 2014 09:23:21 with gcc 4.8.2 (GCC) 20140120 (Red Hat 4.8.2-16)
    configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --optflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' --enable-bzlib --disable-crystalhd --enable-gnutls --enable-libass --enable-libcdio --enable-libdc1394 --disable-indev=jack --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-openal --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libv4l2 --enable-libx264 --enable-libxvid --enable-x11grab --enable-avfilter --enable-avresample --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-runtime-cpudetect
    libavutil      52. 92.100 / 52. 92.100
    libavcodec     55. 69.100 / 55. 69.100
    libavformat    55. 48.100 / 55. 48.100
    libavdevice    55. 13.102 / 55. 13.102
    libavfilter     4. 11.100 /  4. 11.100
    libavresample   1.  3.  0 /  1.  3.  0
    libswscale      2.  6.100 /  2.  6.100
    libswresample   0. 19.100 /  0. 19.100
    libpostproc    52.  3.100 / 52.  3.100

    ffmpeg version :

    ffmpeg version 2.3.4 Copyright (c) 2000-2014 the FFmpeg developers
    built on Dec  4 2014 09:23:21 with gcc 4.8.2 (GCC) 20140120 (Red Hat 4.8.2-16)
    configuration: --prefix=/usr --bindir=/usr/bin --datadir=/usr/share/ffmpeg --incdir=/usr/include/ffmpeg --libdir=/usr/lib64 --mandir=/usr/share/man --arch=x86_64 --optflags='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' --enable-bzlib --disable-crystalhd --enable-gnutls --enable-libass --enable-libcdio --enable-libdc1394 --disable-indev=jack --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-openal --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libvorbis --enable-libv4l2 --enable-libx264 --enable-libxvid --enable-x11grab --enable-avfilter --enable-avresample --enable-postproc --enable-pthreads --disable-static --enable-shared --enable-gpl --disable-debug --disable-stripping --shlibdir=/usr/lib64 --enable-runtime-cpudetect
    libavutil      52. 92.100 / 52. 92.100
    libavcodec     55. 69.100 / 55. 69.100
    libavformat    55. 48.100 / 55. 48.100
    libavdevice    55. 13.102 / 55. 13.102
    libavfilter     4. 11.100 /  4. 11.100
    libavresample   1.  3.  0 /  1.  3.  0
    libswscale      2.  6.100 /  2.  6.100
    libswresample   0. 19.100 /  0. 19.100
    libpostproc    52.  3.100 / 52.  3.100

    Thank you.