Recherche avancée

Médias (1)

Mot : - Tags -/publishing

Autres articles (29)

  • Encoding and processing into web-friendly formats

    13 avril 2011, par

    MediaSPIP automatically converts uploaded files to internet-compatible formats.
    Video files are encoded in MP4, Ogv and WebM (supported by HTML5) and MP4 (supported by Flash).
    Audio files are encoded in MP3 and Ogg (supported by HTML5) and MP3 (supported by Flash).
    Where possible, text is analyzed in order to retrieve the data needed for search engine detection, and then exported as a series of image files.
    All uploaded files are stored online in their original format, so you can (...)

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

  • Création définitive du canal

    12 mars 2010, par

    Lorsque votre demande est validée, vous pouvez alors procéder à la création proprement dite du canal. Chaque canal est un site à part entière placé sous votre responsabilité. Les administrateurs de la plateforme n’y ont aucun accès.
    A la validation, vous recevez un email vous invitant donc à créer votre canal.
    Pour ce faire il vous suffit de vous rendre à son adresse, dans notre exemple "http://votre_sous_domaine.mediaspip.net".
    A ce moment là un mot de passe vous est demandé, il vous suffit d’y (...)

Sur d’autres sites (7449)

  • ffmpeg weird x264 encoding behavior

    1er février 2016, par JMor

    I have a captured a 720x480 video with a display aspect ratio of 16:9 which I want to crop, resize and pad, but just the x264 encoding command is giving me a headache.

    (Screenshot of input.m2v) Here is my command :

    ffmpeg -ss 1861 -i input.m2v -c:v libx264 -profile:v main -preset:v medium -level 3.1 -x264opts crf=21.228 -t 60 -y -f mp4 output.mp4

    And here is the ffmpeg output :

    (Screen shot of output.mp4)

    Input #0, mpegvideo, from 'input.m2v':
     Duration: N/A, bitrate: N/A
       Stream #0:0: Video: mpeg2video (Main), yuv420p(tv), 720x480 [SAR 32:27 DAR 1
    6:9], max. 6605 kb/s, 31.02 fps, 59.94 tbr, 1200k tbn, 59.94 tbc
    [libx264 @ 02ba84c0] using SAR=32/27
    [libx264 @ 02ba84c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
    [libx264 @ 02ba84c0] profile Main, level 3.1
    [libx264 @ 02ba84c0] 264 - core 144 r2525 40bb568 - H.264/MPEG-4 AVC codec - Cop
    yleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deb
    lock=1:0:0 analyse=0x1:0x111 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 m
    e_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chro
    ma_qp_offset=-2 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1
    interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1
    b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scene
    cut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=21.2 qcomp=0.60 qpmin
    =0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
    Output #0, mp4, to 'output.mp4':
     Metadata:
       encoder         : Lavf56.19.100
       Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 720x48
    0 [SAR 32:27 DAR 16:9], q=-1--1, 29.97 fps, 30k tbn, 29.97 tbc
       Metadata:
         encoder         : Lavc56.21.102 libx264
    Stream mapping:
     Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (libx264))

    The output size is 720x480, displayed as 853x480, as expected.
    But it looks like the frame has been vertically scaled by a factor of 1.18 and then cropped to a height of 480, so that I am losing the top and bottom of the frame. In fact, the behavior is equivalent to :

    -vf "scale=720:569,crop=720:480:0:0"

    Although I assume the aspect ratio plays a part here (I think the 1.18 factor is really (16/9)/(720/480)) I am surprised that ffmpeg would do that out of the blue. May be someone more knowledgeable than me could explain it ?

  • ffmpeg weird x264 encoding behavior

    1er février 2016, par JMor

    I have a captured a 720x480 video with a display aspect ratio of 16:9 which I want to crop, resize and pad, but just the x264 encoding command is giving me a headache.

    (Screenshot of input.m2v) Here is my command :

    ffmpeg -ss 1861 -i input.m2v -c:v libx264 -profile:v main -preset:v medium -level 3.1 -x264opts crf=21.228 -t 60 -y -f mp4 output.mp4

    And here is the ffmpeg output :

    (Screen shot of output.mp4)

    Input #0, mpegvideo, from 'input.m2v':
     Duration: N/A, bitrate: N/A
       Stream #0:0: Video: mpeg2video (Main), yuv420p(tv), 720x480 [SAR 32:27 DAR 1
    6:9], max. 6605 kb/s, 31.02 fps, 59.94 tbr, 1200k tbn, 59.94 tbc
    [libx264 @ 02ba84c0] using SAR=32/27
    [libx264 @ 02ba84c0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
    [libx264 @ 02ba84c0] profile Main, level 3.1
    [libx264 @ 02ba84c0] 264 - core 144 r2525 40bb568 - H.264/MPEG-4 AVC codec - Cop
    yleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deb
    lock=1:0:0 analyse=0x1:0x111 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 m
    e_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chro
    ma_qp_offset=-2 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1
    interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1
    b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scene
    cut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=21.2 qcomp=0.60 qpmin
    =0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
    Output #0, mp4, to 'output.mp4':
     Metadata:
       encoder         : Lavf56.19.100
       Stream #0:0: Video: h264 (libx264) ([33][0][0][0] / 0x0021), yuv420p, 720x48
    0 [SAR 32:27 DAR 16:9], q=-1--1, 29.97 fps, 30k tbn, 29.97 tbc
       Metadata:
         encoder         : Lavc56.21.102 libx264
    Stream mapping:
     Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (libx264))

    The output size is 720x480, displayed as 853x480, as expected.
    But it looks like the frame has been vertically scaled by a factor of 1.18 and then cropped to a height of 480, so that I am losing the top and bottom of the frame. In fact, the behavior is equivalent to :

    -vf "scale=720:569,crop=720:480:0:0"

    Although I assume the aspect ratio plays a part here (I think the 1.18 factor is really (16/9)/(720/480)) I am surprised that ffmpeg would do that out of the blue. May be someone more knowledgeable than me could explain it ?

  • AAC encoder : don’t apply MS on special bands

    8 janvier 2016, par Claudio Freire
    AAC encoder : don’t apply MS on special bands
    

    Change the condition for application of the M/S transform to match
    that of the decoder. Namely, that no special coding books must be
    in use in either channel. While the condition ought to be
    equivalent to the current one when the invariant of is_mask is
    kept, matching the decoder’s condition is safer and easier to
    maintain.

    • [DH] libavcodec/aacenc.c