Recherche avancée
Médias (1)
-
Sintel MP4 Surround 5.1 Full
13 mai 2011, par
Mis à jour : Février 2012
Langue : English
Type : Video
Autres articles (65)
-
Les images
15 mai 2013 -
Taille des images et des logos définissables
9 février 2011, parDans beaucoup d’endroits du site, logos et images sont redimensionnées pour correspondre aux emplacements définis par les thèmes. L’ensemble des ces tailles pouvant changer d’un thème à un autre peuvent être définies directement dans le thème et éviter ainsi à l’utilisateur de devoir les configurer manuellement après avoir changé l’apparence de son site.
Ces tailles d’images sont également disponibles dans la configuration spécifique de MediaSPIP Core. La taille maximale du logo du site en pixels, on permet (...) -
Mediabox : ouvrir les images dans l’espace maximal pour l’utilisateur
8 février 2011, parLa visualisation des images est restreinte par la largeur accordée par le design du site (dépendant du thème utilisé). Elles sont donc visibles sous un format réduit. Afin de profiter de l’ensemble de la place disponible sur l’écran de l’utilisateur, il est possible d’ajouter une fonctionnalité d’affichage de l’image dans une boite multimedia apparaissant au dessus du reste du contenu.
Pour ce faire il est nécessaire d’installer le plugin "Mediabox".
Configuration de la boite multimédia
Dès (...)
Sur d’autres sites (6688)
-
Simply beyond ridiculous
For the past few years, various improvements on H.264 have been periodically proposed, ranging from larger transforms to better intra prediction. These finally came together in the JCT-VC meeting this past April, where over two dozen proposals were made for a next-generation video coding standard. Of course, all of these were in very rough-draft form ; it will likely take years to filter it down into a usable standard. In the process, they’ll pick the most useful features (hopefully) from each proposal and combine them into something a bit more sane. But, of course, it all has to start somewhere.
A number of features were common : larger block sizes, larger transform sizes, fancier interpolation filters, improved intra prediction schemes, improved motion vector prediction, increased internal bit depth, new entropy coding schemes, and so forth. A lot of these are potentially quite promising and resolve a lot of complaints I’ve had about H.264, so I decided to try out the proposal that appeared the most interesting : the Samsung+BBC proposal (A124), which claims compression improvements of around 40%.
The proposal combines a bouillabaisse of new features, ranging from a 12-tap interpolation filter to 12thpel motion compensation and transforms as large as 64×64. Overall, I would say it’s a good proposal and I don’t doubt their results given the sheer volume of useful features they’ve dumped into it. I was a bit worried about complexity, however, as 12-tap interpolation filters don’t exactly scream “fast”.
I prepared myself for the slowness of an unoptimized encoder implementation, compiled their tool, and started a test encode with their recommended settings.
I waited. The first frame, an I-frame, completed.
I took a nap.
I waited. The second frame, a P-frame, was done.
I played a game of Settlers.
I waited. The third frame, a B-frame, was done.
I worked on a term paper.
I waited. The fourth frame, a B-frame, was done.
After a full 6 hours, 8 frames had encoded. Yes, at this rate, it would take a full two weeks to encode 10 seconds of HD video. On a Core i7. This is not merely slow ; this is over 1000 times slower than x264 on “placebo” mode. This is so slow that it is not merely impractical ; it is impossible to even test. This encoder is apparently designed for some sort of hypothetical future computer from space. And word from other developers is that the Intel proposal is even slower.
This has led me to suspect that there is a great deal of cheating going on in the H.265 proposals. The goal of the proposals, of course, is to pick the best feature set for the next generation video compression standard. But there is an extra motivation : organizations whose features get accepted get patents on the resulting standard, and thus income. With such large sums of money in the picture, dishonesty becomes all the more profitable.
There is a set of rules, of course, to limit how the proposals can optimize their encoders. If different encoders use different optimization techniques, the results will no longer be comparable — remember, they are trying to compare compression features, not methods of optimizing encoder-side decisions. Thus all encoders are required to use a constant quantizer, specified frame types, and so forth. But there are no limits on how slow an encoder can be or what algorithms it can use.
It would be one thing if the proposed encoder was a mere 10 times slower than the current reference ; that would be reasonable, given the low level of optimization and higher complexity of the new standard. But this is beyond ridiculous. With the prize given to whoever can eke out the most PSNR at a given quantizer at the lowest bitrate (with no limits on speed), we’re just going to get an arms race of slow encoders, with every company trying to use the most ridiculous optimizations possible, even if they involve encoding the frame 100,000 times over to choose the optimal parameters. And the end result will be as I encountered here : encoders so slow that they are simply impossible to even test.
Such an arms race certainly does little good in optimizing for reality where we don’t have 30 years to encode an HD movie : a feature that gives great compression improvements is useless if it’s impossible to optimize for in a reasonable amount of time. Certainly once the standard is finalized practical encoders will be written — but it makes no sense to optimize the standard for a use-case that doesn’t exist. And even attempting to “optimize” anything is difficult when encoding a few seconds of video takes weeks.
Update : The people involved have contacted me and insist that there was in fact no cheating going on. This is probably correct ; the problem appears to be that the rules that were set out were simply not strict enough, making many changes that I would intuitively consider “cheating” to be perfectly allowed, and thus everyone can do it.
I would like to apologize if I implied that the results weren’t valid ; they are — the Samsung-BBC proposal is definitely one of the best, which is why I picked it to test with. It’s just that I think any situation in which it’s impossible to test your own software is unreasonable, and thus the entire situation is an inherently broken one, given the lax rules, slow baseline encoder, and no restrictions on compute time.
-
Simply beyond ridiculous
For the past few years, various improvements on H.264 have been periodically proposed, ranging from larger transforms to better intra prediction. These finally came together in the JCT-VC meeting this past April, where over two dozen proposals were made for a next-generation video coding standard. Of course, all of these were in very rough-draft form ; it will likely take years to filter it down into a usable standard. In the process, they’ll pick the most useful features (hopefully) from each proposal and combine them into something a bit more sane. But, of course, it all has to start somewhere.
A number of features were common : larger block sizes, larger transform sizes, fancier interpolation filters, improved intra prediction schemes, improved motion vector prediction, increased internal bit depth, new entropy coding schemes, and so forth. A lot of these are potentially quite promising and resolve a lot of complaints I’ve had about H.264, so I decided to try out the proposal that appeared the most interesting : the Samsung+BBC proposal (A124), which claims compression improvements of around 40%.
The proposal combines a bouillabaisse of new features, ranging from a 12-tap interpolation filter to 12thpel motion compensation and transforms as large as 64×64. Overall, I would say it’s a good proposal and I don’t doubt their results given the sheer volume of useful features they’ve dumped into it. I was a bit worried about complexity, however, as 12-tap interpolation filters don’t exactly scream “fast”.
I prepared myself for the slowness of an unoptimized encoder implementation, compiled their tool, and started a test encode with their recommended settings.
I waited. The first frame, an I-frame, completed.
I took a nap.
I waited. The second frame, a P-frame, was done.
I played a game of Settlers.
I waited. The third frame, a B-frame, was done.
I worked on a term paper.
I waited. The fourth frame, a B-frame, was done.
After a full 6 hours, 8 frames had encoded. Yes, at this rate, it would take a full two weeks to encode 10 seconds of HD video. On a Core i7. This is not merely slow ; this is over 1000 times slower than x264 on “placebo” mode. This is so slow that it is not merely impractical ; it is impossible to even test. This encoder is apparently designed for some sort of hypothetical future computer from space. And word from other developers is that the Intel proposal is even slower.
This has led me to suspect that there is a great deal of cheating going on in the H.265 proposals. The goal of the proposals, of course, is to pick the best feature set for the next generation video compression standard. But there is an extra motivation : organizations whose features get accepted get patents on the resulting standard, and thus income. With such large sums of money in the picture, dishonesty becomes all the more profitable.
There is a set of rules, of course, to limit how the proposals can optimize their encoders. If different encoders use different optimization techniques, the results will no longer be comparable — remember, they are trying to compare compression features, not methods of optimizing encoder-side decisions. Thus all encoders are required to use a constant quantizer, specified frame types, and so forth. But there are no limits on how slow an encoder can be or what algorithms it can use.
It would be one thing if the proposed encoder was a mere 10 times slower than the current reference ; that would be reasonable, given the low level of optimization and higher complexity of the new standard. But this is beyond ridiculous. With the prize given to whoever can eke out the most PSNR at a given quantizer at the lowest bitrate (with no limits on speed), we’re just going to get an arms race of slow encoders, with every company trying to use the most ridiculous optimizations possible, even if they involve encoding the frame 100,000 times over to choose the optimal parameters. And the end result will be as I encountered here : encoders so slow that they are simply impossible to even test.
Such an arms race certainly does little good in optimizing for reality where we don’t have 30 years to encode an HD movie : a feature that gives great compression improvements is useless if it’s impossible to optimize for in a reasonable amount of time. Certainly once the standard is finalized practical encoders will be written — but it makes no sense to optimize the standard for a use-case that doesn’t exist. And even attempting to “optimize” anything is difficult when encoding a few seconds of video takes weeks.
Update : The people involved have contacted me and insist that there was in fact no cheating going on. This is probably correct ; the problem appears to be that the rules that were set out were simply not strict enough, making many changes that I would intuitively consider “cheating” to be perfectly allowed, and thus everyone can do it.
I would like to apologize if I implied that the results weren’t valid ; they are — the Samsung-BBC proposal is definitely one of the best, which is why I picked it to test with. It’s just that I think any situation in which it’s impossible to test your own software is unreasonable, and thus the entire situation is an inherently broken one, given the lax rules, slow baseline encoder, and no restrictions on compute time.
-
Could not find tag for codec h264 in stream #0 (mp4)
18 août 2019, par TabsNotSpacesI’ve been using the sickbeard_mp4_converter for a while to convert video files to mp4 by generating a script for ffmpeg. I’m not sure what I changed, but the ffmpeg script it generates no longer works and I’m having trouble debugging it. Can anyone tell from my log what the issue is ? Yes, its supposed to be an mp4 to an mp4, which is typically fine.
I’m at the point where I’m using an mp4 that worked with the same autogenerated script yesterday but it no longer is. I remember updating ffmpeg but downgrading did not resolve the issue, though I may have not downgraded enough.
ffmpeg 4.1.4
MediaInfo output :
$ mediainfo --fullscan Downloads/Dallas\ Buyers\ Club\ \(2013\).mp4.original
General
Count : 334
Count of stream of this kind : 1
Kind of stream : General
Kind of stream : General
Stream identifier : 0
Count of video streams : 1
Count of audio streams : 1
Video_Format_List : AVC
Video_Format_WithHint_List : AVC
Codecs Video : AVC
Audio_Format_List : AAC LC
Audio_Format_WithHint_List : AAC LC
Audio codecs : AAC LC
Audio_Language_List : English
Complete name : Downloads/Dallas Buyers Club (2013).mp4.original
Folder name : Downloads
File name extension : Dallas Buyers Club (2013).mp4.original
File name : Dallas Buyers Club (2013).mp4
File extension : original
Format : MPEG-4
Format : MPEG-4
Format/Extensions usually used : braw mov mp4 m4v m4a m4b m4p m4r 3ga 3gpa 3gpp 3gp 3gpp2 3g2 k3g jpm jpx mqv ismv isma ismt f4a f4b f4v
Commercial name : MPEG-4
Format profile : Base Media
Internet media type : video/mp4
Codec ID : isom
Codec ID : isom (isom/avc1)
Codec ID/Url : http://www.apple.com/quicktime/download/standalone.html
CodecID_Compatible : isom/avc1
File size : 1987698473
File size : 1.85 GiB
File size : 2 GiB
File size : 1.9 GiB
File size : 1.85 GiB
File size : 1.851 GiB
Duration : 7017023
Duration : 1 h 56 min
Duration : 1 h 56 min 57 s 23 ms
Duration : 1 h 56 min
Duration : 01:56:57.023
Duration : 01:56:58;17
Duration : 01:56:57.023 (01:56:58;17)
Overall bit rate mode : VBR
Overall bit rate mode : Variable
Overall bit rate : 2266144
Overall bit rate : 2 266 kb/s
Frame rate : 23.976
Frame rate : 23.976 FPS
Frame count : 168239
Stream size : 3690657
Stream size : 3.52 MiB (0%)
Stream size : 4 MiB
Stream size : 3.5 MiB
Stream size : 3.52 MiB
Stream size : 3.520 MiB
Stream size : 3.52 MiB (0%)
Proportion of this stream : 0.00186
HeaderSize : 3690598
DataSize : 1984007824
FooterSize : 51
IsStreamable : Yes
Title : Dallas Buyers Club
Movie name : Dallas Buyers Club
Director : Jean-Marc Valle
Actor : Matthew McConaughey / Jennifer Garner / Jared Leto / Denis O'Hare / Steve Zahn
Screenplay by : Craig Borten / Melisa Wallack
Producer : Robbie Brenner / Rachel Winter / Kerry Barden / Rich Delia / Paul Schnee
Genre : Drama
ContentType : Unknown Type
Description : Sometimes it takes a hustler to change the world
Recorded date : 2013-11-17
Encoded date : UTC 2014-01-24 08:11:15
Tagged date : UTC 2014-01-24 08:11:15
File last modification date : UTC 2019-08-16 16:44:14
File last modification date (local) : 2019-08-16 11:44:14
Writing application : MDH:Dallas Buyers Club (2013).mp4
Writing application : MDH:Dallas Buyers Club (2013).mp4
Cover : Yes
ContentRating : mpaa|R|400|
LongDescription : Loosely based on the true-life tale of Ron Woodroof, a drug-taking, women-loving, homophobic man who in 1986 was diagnosed with HIV/AIDS and given thirty days to live.
FileExtension_Invalid : braw mov mp4 m4v m4a m4b m4p m4r 3ga 3gpa 3gpp 3gp 3gpp2 3g2 k3g jpm jpx mqv ismv isma ismt f4a f4b f4v
Video
Count : 378
Count of stream of this kind : 1
Kind of stream : Video
Kind of stream : Video
Stream identifier : 0
StreamOrder : 0
ID : 1
ID : 1
Format : AVC
Format : AVC
Format/Info : Advanced Video Codec
Format/Url : http://developers.videolan.org/x264.html
Commercial name : AVC
Format profile : High@L4.1
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, CABAC : Yes
Format settings, Reference frames : 4
Format settings, Reference frames : 4 frames
Internet media type : video/H264
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 7016967
Duration : 1 h 56 min
Duration : 1 h 56 min 56 s 967 ms
Duration : 1 h 56 min
Duration : 01:56:56.967
Duration : 01:56:58;17
Duration : 01:56:56.967 (01:56:58;17)
Bit rate : 2169000
Bit rate : 2 169 kb/s
Maximum bit rate : 12300880
Maximum bit rate : 12.3 Mb/s
Width : 1920
Width : 1 920 pixels
Height : 800
Height : 800 pixels
Sampled_Width : 1920
Sampled_Height : 800
Pixel aspect ratio : 1.000
Display aspect ratio : 2.400
Display aspect ratio : 2.40:1
Rotation : 0.000
Frame rate mode : CFR
Frame rate mode : Constant
Frame rate : 23.976
Frame rate : 23.976 (24000/1001) FPS
FrameRate_Num : 24000
FrameRate_Den : 1001
Original frame rate : 23.976
Original frame rate : 23.976 (23976/1000) FPS
FrameRate_Original_Num : 23976
FrameRate_Original_Den : 1000
Frame count : 168239
Color space : YUV
Chroma subsampling : 4:2:0
Chroma subsampling : 4:2:0
Bit depth : 8
Bit depth : 8 bits
Scan type : Progressive
Scan type : Progressive
Bits/(Pixel*Frame) : 0.059
Stream size : 1901715488
Stream size : 1.77 GiB (96%)
Stream size : 2 GiB
Stream size : 1.8 GiB
Stream size : 1.77 GiB
Stream size : 1.771 GiB
Stream size : 1.77 GiB (96%)
Proportion of this stream : 0.95674
Writing library : x264 - core 135 r2 f0c1c53
Writing library : x264 core 135 r2 f0c1c53
Encoded_Library_Name : x264
Encoded_Library_Version : core 135 r2 f0c1c53
Encoding settings : cabac=1 / ref=4 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.15 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-3 / threads=36 / lookahead_threads=3 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / bitrate=2169 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=31250 / vbv_bufsize=31250 / nal_hrd=none / ip_ratio=1.40 / aq=1:1.00
Encoded date : UTC 2014-01-24 08:11:15
Tagged date : UTC 2014-01-24 08:11:38
colour_description_present : Yes
colour_description_present_Source : Stream
Color range : Limited
colour_range_Source : Stream
Color primaries : BT.709
colour_primaries_Source : Stream
transfer_characteristics_Source : Stream
Matrix coefficients : BT.709
matrix_coefficients_Source : Stream
Codec configuration box : avcC
Audio
Count : 280
Count of stream of this kind : 1
Kind of stream : Audio
Kind of stream : Audio
Stream identifier : 0
StreamOrder : 1
ID : 2
ID : 2
Format : AAC
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Commercial name : AAC
Format settings, SBR : No (Explicit)
Format settings, SBR : No (Explicit)
Format_AdditionalFeatures : LC
Codec ID : mp4a-40-2
Duration : 7017023
Duration : 1 h 56 min
Duration : 1 h 56 min 57 s 23 ms
Duration : 1 h 56 min
Duration : 01:56:57.023
Duration : 01:56:38:17
Duration : 01:56:57.023 (01:56:38:17)
Bit rate mode : VBR
Bit rate mode : Variable
Bit rate : 93816
Bit rate : 93.8 kb/s
Maximum bit rate : 107376
Maximum bit rate : 107 kb/s
Channel(s) : 2
Channel(s) : 2 channels
Channel positions : Front: L R
Channel positions : 2/0/0
Channel layout : L R
Samples per frame : 1024
Sampling rate : 48000
Sampling rate : 48.0 kHz
Samples count : 336817104
Frame rate : 46.875
Frame rate : 46.875 FPS (1024 SPF)
Frame count : 328923
Compression mode : Lossy
Compression mode : Lossy
Stream size : 82292328
Stream size : 78.5 MiB (4%)
Stream size : 78 MiB
Stream size : 78 MiB
Stream size : 78.5 MiB
Stream size : 78.48 MiB
Stream size : 78.5 MiB (4%)
Proportion of this stream : 0.04140
Language : en
Language : English
Language : English
Language : en
Language : eng
Language : en
Encoded date : UTC 2014-01-24 08:11:37
Tagged date : UTC 2014-01-24 08:11:38Log :
$ /usr/local/bin/ffmpeg -i "/Users/Me/Downloads/Dallas Buyers Club (2013).mp4.original" -vcodec libx264 -map 0:0 -vb 2063k -c:a:0 copy -map 0:2 -metadata:s:a:0 language=eng -disposition:a:0 default -f mp4 -threads 0 -y "/Users/Me/Downloads/Dallas Buyers Club (2013).mp4"
ffmpeg version 4.1.4 Copyright (c) 2000-2019 the FFmpeg developers
built with Apple LLVM version 10.0.1 (clang-1001.0.46.4)
configuration: --prefix=/usr/local/Cellar/ffmpeg/4.1.4_1 --enable-shared --enable-pthreads --enable-version3 --enable-avresample --cc=clang --host-cflags='-I/Library/Java/JavaVirtualMachines/adoptopenjdk-12.0.1.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/adoptopenjdk-12.0.1.jdk/Contents/Home/include/darwin' --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libmp3lame --enable-libopus --enable-librubberband --enable-libsnappy --enable-libtesseract --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-librtmp --enable-libspeex --enable-videotoolbox --disable-libjack --disable-indev=jack --enable-libaom --enable-libsoxr
libavutil 56. 22.100 / 56. 22.100
libavcodec 58. 35.100 / 58. 35.100
libavformat 58. 20.100 / 58. 20.100
libavdevice 58. 5.100 / 58. 5.100
libavfilter 7. 40.101 / 7. 40.101
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 3.100 / 5. 3.100
libswresample 3. 3.100 / 3. 3.100
libpostproc 55. 3.100 / 55. 3.100
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fc38e801400] stream 0, timescale not set
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/Users/Me/Downloads/Dallas Buyers Club (2013).mp4.original':
Metadata:
major_brand : isom
minor_version : 1
compatible_brands: isomavc1
title : Dallas Buyers Club
genre : Drama
date : 2013-11-17
encoder : MDH:Dallas Buyers Club (2013).mp4
media_type : 9
hd_video : 2
description : Sometimes it takes a hustler to change the world
synopsis : Loosely based on the true-life tale of Ron Woodroof, a drug-taking, women-loving, homophobic man who in 1986 was diagnosed with HIV/AIDS and given thirty days to live.
creation_time : 2014-01-24T08:11:15.000000Z
Duration: 01:56:57.02, start: 0.000000, bitrate: 2266 kb/s
Stream #0:0: Video: mjpeg, yuvj420p(pc, bt470bg/unknown/unknown), 500x750 [SAR 1:1 DAR 2:3], 90k tbr, 90k tbn, 90k tbc
Stream #0:1(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709/bt709/unknown), 1920x800, 2168 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default)
Metadata:
creation_time : 2014-01-24T08:11:15.000000Z
handler_name : video.264#trackID=1:fps=23.976 - Imported with GPAC 0.5.0-rev
Stream #0:2(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 93 kb/s (default)
Metadata:
creation_time : 2014-01-24T08:11:37.000000Z
handler_name : GPAC ISO Audio Handler
Stream mapping:
Stream #0:0 -> #0:0 (mjpeg (native) -> h264 (libx264))
Stream #0:2 -> #0:1 (copy)
Press [q] to stop, [?] for help
[mp4 @ 0x7fc38e811000] Frame rate very high for a muxer not efficiently supporting it.
Please consider specifying a lower framerate, a different muxer or -vsync 2
[libx264 @ 0x7fc38e823e00] using SAR=1/1
[libx264 @ 0x7fc38e823e00] MB rate (135360000) > level limit (16711680)
[libx264 @ 0x7fc38e823e00] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
[libx264 @ 0x7fc38e823e00] profile High, level 6.2
[libx264 @ 0x7fc38e823e00] 264 - core 155 r2917 0a84d98 - H.264/MPEG-4 AVC codec - Copyleft 2003-2018 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_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 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=abr mbtree=1 bitrate=2063 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
[mp4 @ 0x7fc38e811000] Could not find tag for codec h264 in stream #0, codec not currently supported in container
Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument
Error initializing output stream 0:0 --
[libx264 @ 0x7fc38e823e00] final ratefactor: 89.20
Conversion failed!
Syndiquer tout le site
