[Ffmpeg-devel-irc] ffmpeg-devel.log.20170323

burek burek021 at gmail.com
Fri Mar 24 03:05:03 EET 2017


[09:39:44 CET] <cone-520> ffmpeg 03wm4 07master:156bd8278f40: lavc: Add hwaccel_flags field to AVCodecContext
[09:39:44 CET] <cone-520> ffmpeg 03wm4 07master:7e4ba776a224: lavc: vdpau: Add support for new hw_frames_ctx and hw_device_ctx API
[11:14:33 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:5cc0057f4910: lavu: remove the custom atomic API
[11:14:34 CET] <cone-520> ffmpeg 03Clément BSsch 07master:d521258b19a5: Merge commit '5cc0057f4910c8c72421b812c8f337ef6c43696c'
[11:16:59 CET] <cone-520> ffmpeg 03Mark Thompson 07master:314b421dd891: vaapi_encode: Decide on GOP setup before initialising sequence parameters
[11:17:00 CET] <cone-520> ffmpeg 03Mark Thompson 07master:17a0f9481cf0: vaapi_h264: Fix CFR mode with frame_rate set in AVCodecContext
[11:17:01 CET] <cone-520> ffmpeg 03Mark Thompson 07master:ec17ab381ede: vaapi_h264: Write bitstream restriction fields
[11:17:02 CET] <cone-520> ffmpeg 03Mark Thompson 07master:fc30a90898e4: vaapi_h265: Fix slice header writing
[11:17:03 CET] <cone-520> ffmpeg 03Mark Thompson 07master:b8cac1e83066: vaapi_h265: Fix buffering parameters
[11:17:04 CET] <cone-520> ffmpeg 03Clément BSsch 07master:553d8a9ecf16: Merge commit 'b8cac1e83066aa87e8402c146c81b77a11b5eec3'
[11:17:13 CET] <wm4_> ubitux: I assume you skipped it for now
[11:17:36 CET] <ubitux> yes, see http://git.videolan.org/?p=ffmpeg.git;a=commit;h=d521258b19a54f4ada61d24b9adb15d5993eda1c
[11:17:58 CET] <ubitux> it's added to the libav merge doc
[11:18:03 CET] <ubitux> won't be forgotten
[11:19:02 CET] <wm4_> ok
[11:19:05 CET] <wm4_> makes sense
[11:19:37 CET] <cone-520> ffmpeg 03Mark Thompson 07master:eaaaabf6c933: hwcontext_vaapi: Enable P010 support
[11:19:38 CET] <cone-520> ffmpeg 03Clément BSsch 07master:c4f613fe5120: Merge commit 'eaaaabf6c93321cdb78bf61dc383cf515ec12e07'
[11:20:42 CET] <cone-520> ffmpeg 03Mark Thompson 07master:5a5df90d9c05: vaapi_h265: Add main 10 encode support
[11:20:43 CET] <cone-520> ffmpeg 03Clément BSsch 07master:1a5631dc716e: Merge commit '5a5df90d9c05d86d9b0564b8b40b6d64a324df5e'
[11:21:11 CET] <ubitux> btw, thanks for everyone who did cherry-picks in the past
[11:21:19 CET] <ubitux> it makes the merges much simpler :p
[11:23:18 CET] <wm4_> I guess the interesting parts get cherry-picked
[11:24:00 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:310c55f1799d: pixfmt: Document alternative names for smpte 431 and 432
[11:24:01 CET] <cone-520> ffmpeg 03Clément BSsch 07master:a1f6b1d9d816: Merge commit '310c55f1799deab395319471a75c528d0fa7b30d'
[11:26:46 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:bad4aad4037f: avidec: Do not special case palette on big-endian
[11:26:47 CET] <cone-520> ffmpeg 03Clément BSsch 07master:554cc43ac6c3: Merge commit 'bad4aad4037f59ba0ad656164be9ab8f7a0fa2d4'
[11:27:22 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:497c087939e3: avidec: Set palette alpha as fully opaque
[11:27:23 CET] <cone-520> ffmpeg 03Clément BSsch 07master:76e21e83acbe: Merge commit '497c087939e32b26b792515d2dbc7e22561203f7'
[11:28:23 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:b8d5070db631: avcodec: Document AV_PKT_DATA_PALETTE side data type
[11:28:24 CET] <cone-520> ffmpeg 03Clément BSsch 07master:7b3a3e6276c4: Merge commit 'b8d5070db6313f985562865edcfd08a01c2d7503'
[11:37:09 CET] <ubitux> can someone sync the fate samplse please? in particular /rscc/8bpp.avi
[11:37:13 CET] <ubitux> nevcairiel? michaelni?
[11:37:19 CET] <nevcairiel> sure
[11:37:23 CET] <ubitux> thanks :)
[11:38:32 CET] <nevcairiel> not sure w hat else might be new, so i'll just add that one
[11:38:59 CET] <ubitux> i'll poke you if i need more
[11:39:06 CET] <nevcairiel> its there now
[11:39:14 CET] <ubitux> perfect, thanks :)
[11:40:24 CET] <cone-520> ffmpeg 03Carl Eugen Hoyos 07master:c19830aa2c19: rscc: Support palette format
[11:40:25 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:dc3fe45fca9c: fate: Add test for rscc palette
[11:40:26 CET] <cone-520> ffmpeg 03Clément BSsch 07master:5f044d237263: Merge commit 'c19830aa2c19f9713b612f7e2fdb437df91ba266'
[11:40:27 CET] <cone-520> ffmpeg 03Clément BSsch 07master:dffa4ec1ed20: Merge commit 'dc3fe45fca9c10c4af6bfcf48eb7b81968892ef9'
[11:43:57 CET] <nevcairiel> neat we're at the hevc idct patches soon
[11:44:19 CET] <nevcairiel> (contrary to previous hevc patches, those should actually still fit)
[11:44:22 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:a451324dddf5: vp9: ignore reference segmentation map if error_resilience flag is set.
[11:44:23 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:c935b54bd6a1: checkasm: add VP9 loopfilter tests.
[11:44:24 CET] <cone-520> ffmpeg 03Clément BSsch 07master:a692724c5878: vp9lpf/x86: add x86 SSSE3/AVX SIMD for vp9_loop_filter_[vh]_16_16.
[11:44:25 CET] <cone-520> ffmpeg 03James Almer 07master:1f451eed606b: vp9lpf/x86: add ff_vp9_loop_filter_[vh]_16_16_sse2().
[11:44:26 CET] <cone-520> ffmpeg 03Clément BSsch 07master:6bea47815891: vp9lpf/x86: add ff_vp9_loop_filter_[vh]_88_16_{ssse3,avx}.
[11:44:27 CET] <cone-520> ffmpeg 03James Almer 07master:92d47550ea09: vp9lpf/x86: add an SSE2 version of vp9_loop_filter_[vh]_88_16
[11:44:28 CET] <cone-520> ffmpeg 03Clément BSsch 07master:f2e3d706a16d: vp9lpf/x86: add ff_vp9_loop_filter_h_{48,84}_16_{sse2,ssse3,avx}().
[11:44:29 CET] <cone-520> ffmpeg 03Clément BSsch 07master:0ed21bdc9e7f: vp9lpf/x86: add ff_vp9_loop_filter_[vh]_44_16_{sse2,ssse3,avx}.
[11:44:30 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:a6e288d62414: vp9lpf/x86: save one register in loopfilter surface coverage.
[11:44:31 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:6411c328a233: vp9lpf/x86: make cglobal statement more conservative in register allocation.
[11:44:32 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:6e74e9636b17: vp9lpf/x86: slightly simplify 44/48/84/88 h stores.
[11:44:33 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:683da2788e41: vp9lpf/x86: remove unused register from ABSSUB_CMP macro.
[11:44:34 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:e4961035b288: vp9lpf/x86: simplify ABSSUM_CMP by inverting the comparison meaning.
[11:44:35 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:4ce8ba72f9cb: vp9lpf/x86: move variable assigned inside macro branch.
[11:44:36 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:c6375a83d1ad: vp9lpf/x86: store unpacked intermediates for filter6/14 on stack.
[11:44:37 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:7c62891efedf: vp9lpf/x86: save one register in SIGN_ADD/SUB.
[11:44:38 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:be10834bd9dd: vp9lpf/x86: make filter_44_v work on 32-bit.
[11:44:39 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:37637e65907b: vp9lpf/x86: make filter_88_v work on 32-bit.
[11:44:40 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:b905e8d2fe03: vp9lpf/x86: make filter_48/84_v work on 32-bit.
[11:44:41 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:5bfa96c4b30d: vp9lpf/x86: make filter_16_v work on 32-bit.
[11:44:42 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:725a216481c4: vp9lpf/x86: make filter_44_h work on 32-bit.
[11:44:43 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:8915320db94c: vp9lpf/x86: make filter_48/84/88_h work on 32-bit.
[11:44:44 CET] <cone-520> ffmpeg 03Ronald S. Bultje 07master:715f139c9bd4: vp9lpf/x86: make filter_16_h work on 32-bit.
[11:44:45 CET] <cone-520> ffmpeg 03Clément BSsch 07master:9a23b149c7d8: Merge commit '715f139c9bd407ef7f4d1f564ad683140ec61e6d'
[11:47:44 CET] <cone-520> ffmpeg 03Steve Lhomme 07master:be630b1e08eb: d3d11va: Use the proper decoding slice index
[11:47:45 CET] <cone-520> ffmpeg 03Clément BSsch 07master:3e40c9560a57: Merge commit 'be630b1e08ebe8f766b1798accd6b8e5e096f5aa'
[11:56:16 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:d9dccc03890a: hevc: x86: Refactor IDCT macro declarations
[11:56:17 CET] <cone-520> ffmpeg 03Clément BSsch 07master:9954d5b44eec: Merge commit 'd9dccc03890a976dba59d66ed3b5aceeaa33d14c'
[11:57:15 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:20abcaa273a6: configure: #include stdint.h as part of libxavs test
[11:57:16 CET] <cone-520> ffmpeg 03Clément BSsch 07master:fb477193cd14: Merge commit '20abcaa273a6e77d0a2e1a98c643c73562c6f8f2'
[11:59:41 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:5801f9ed245c: h264_intrapred: x86: Update comments left behind in 95c89da36ebeeb96b7146c0d70f46c582397da7f
[11:59:42 CET] <cone-520> ffmpeg 03Clément BSsch 07master:4bb4fa28e374: Merge commit '5801f9ed245ca5ebb57b0b5183de7a24aaece133'
[12:00:16 CET] <ubitux> wait wat
[12:00:24 CET] <ubitux> i should have read a bit further the commit log lol
[12:01:47 CET] <ubitux> ah, i guess it's an authorship thing
[12:02:00 CET] <ubitux> should i merge the revert?
[12:02:09 CET] <ubitux> i think it's related to http://lists.libav.org/pipermail/libav-devel/2016-October/079560.html
[12:04:58 CET] <ubitux> i guess it will be re-applied differently later on
[12:05:44 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:e4128c08d786: Revert "hevc: x86: Refactor IDCT macro declarations"
[12:05:45 CET] <cone-520> ffmpeg 03Clément BSsch 07master:733b13ad666c: Merge commit 'e4128c08d786eb5513578e8c6063671ba03226ab'
[12:08:47 CET] <cone-520> ffmpeg 03Yogender Gupta 07master:da2848375a2e: nvenc: Force high_444 profile for 444 input
[12:08:48 CET] <cone-520> ffmpeg 03Clément BSsch 07master:464790f10922: Merge commit 'da2848375a2e2121dad9f1e8cbd0ead4e3bf77d6'
[12:11:39 CET] <cone-520> ffmpeg 03Yogender Gupta 07master:cbd84b8a51aa: nvenc: Fix error log
[12:11:40 CET] <cone-520> ffmpeg 03Clément BSsch 07master:1b2a7f42c0a0: Merge commit 'cbd84b8a51aa656d71b7d6ed44bd89041ff081a8'
[12:15:39 CET] <faLUCE> Hello. when I allocate an AVCodecContext* for a decoder, do I have to specify the pixel format (decodec_context->pix_fmt) ? This is absolutely not clear in the API. I opened a MJPEG decoder with codec = avcodec_find_decoder(AV_CODEC_ID_MJPEG) but codec->pix_fmts doesn't contain anything....
[12:16:09 CET] <ubitux> wbs: did 9b2ccafb480 led to glitches or something?
[12:16:28 CET] <wm4_> faLUCE: for decoding generally not, but a few obscure decoders need the pixfmt from the demuxer info... anyway, this is offtopic here, go to #ffmpeg
[12:16:54 CET] <wbs> ubitux: not reproduced in practice, but a few commits later you'll find checkasm support for aarch64 to detect missing sign extensions
[12:17:08 CET] <ubitux> interesting, cool, thanks
[12:17:14 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:9b2ccafb480c: aarch64: Add missing sign extension in ff_h264_idct8_add_neon
[12:17:15 CET] <cone-520> ffmpeg 03Clément BSsch 07master:739d8c83f2c6: Merge commit '9b2ccafb480c94fd09cfb24306d5296dc013cf5b'
[12:17:51 CET] <faLUCE> wm4_: nobody never answers in #ffmpeg. But in this way, how can I know which pixel format is used by the MJPEG decoder?
[12:18:27 CET] <wm4_> faLUCE: you know after decoding, also this channel is development _of_ ffmpeg only
[12:19:44 CET] <faLUCE> wm4_: I understand, but there's not another place where to ask. You say: " you know after decoding"---> how can I know that? from which struct/container I can pick this info?
[12:20:31 CET] <cone-520> ffmpeg 03Alexandra Hájková 07master:e3f941cb03b1: checkasm: add a test for HEVC IDCT
[12:20:32 CET] <cone-520> ffmpeg 03Clément BSsch 07master:50bbb674723e: Merge commit 'e3f941cb03b139b866a0ad6dc95fbe1b247d54af'
[12:20:41 CET] <wm4_> faLUCE: from the AVFrame, also in your case you could just look at any example or whatever
[12:20:48 CET] <faLUCE> thanks wm4_
[12:20:52 CET] <wm4_> of course half of our examples use deprecated APIs or bad practices
[12:21:19 CET] <ubitux> patch welcome btw
[12:21:54 CET] <ubitux> faLUCE: in exchange for special exclusive support, you're officially registered as responsible for updating the examples in FFmpeg tree
[12:21:58 CET] <faLUCE> wm4_: The library is like a Bible, but the examples are really a nightmare, and full of errors and wrappers to wrappers to wrappers. For example encode_aac is completely nonsense
[12:22:50 CET] <wm4_> you mean transcode_aac.c?
[12:24:03 CET] <faLUCE> [12:21] <ubitux> faLUCE: in exchange for special exclusive support, you're officially registered as responsible for updating the examples in FFmpeg tree  <--- I created a C++ library which wraps ffmpeg. I did that by making all the examples (decoding, encoding, resampling etc.) on myself and I would be interested in updating the doc/examples folder, because it is in a very bad state
[12:24:35 CET] <faLUCE> I'll do that as soon as I publish my library
[12:24:36 CET] <ubitux> main thing required in the examples is to update them to the new API
[12:24:47 CET] <ubitux> basically the push/received frame/packet thingy
[12:24:59 CET] <wm4_> faLUCE: if you're updating the ffmpeg in-repo examples, feel free to ask anything here
[12:25:02 CET] <faLUCE> ubitux: my lib is updated to 3.2 (I use send/receive)
[12:25:04 CET] <ubitux> or said differently, fix all the warnings you get when running `make examples`
[12:27:41 CET] <faLUCE> wm4_: I had to re-make all the examples in a very simpler way. It's nonsense, IMHO, to have such long examples (aac_transcode.c) which are full of errors, unuseful and obscure generic functions etc. I made examples for reading and encoding h264 from webcamera, for writing muxed data iun memory (through callbacks) etc. Ande they are SHORT
[12:28:04 CET] <wm4_> I agree
[12:28:08 CET] <faLUCE> anyway, as soon as my lib is finished I'll send you these snippets
[12:30:31 CET] <faLUCE> wm4_: for example, I made a code which reads from a raw audio frame (created with arecord on linux), encodes it to AAC, muxed into ADTS and write it into file through the callback. It's very short and useful for users. OK, I'll post it ASAP
[12:31:37 CET] <wm4_> if it's C++ we're probably not interested
[12:31:45 CET] <faLUCE> wm4_: no, it's plain C
[12:31:51 CET] <wm4_> then we're very interested
[12:32:48 CET] <faLUCE> wm4_: well, in one/two days I'll give you the code
[12:39:14 CET] <wm4_> was this never applied? http://ffmpeg.org/pipermail/ffmpeg-devel/2017-February/207296.html
[12:50:49 CET] <wm4_> ubitux: can I push a patch?
[12:54:14 CET] <ubitux> wm4_: yeah
[12:55:08 CET] <cone-520> ffmpeg 03Jan Berkel 07master:aff80aa4ecad: hls: consistent use of user_agent
[12:55:13 CET] <wm4_> done
[14:15:59 CET] <Guest60> Hello folks, my name is Koustuv Kanungo
[14:17:31 CET] <Guest60> I want to join the Google Summer of Code and do a project under FFmpeg
[14:18:06 CET] <Guest60> I'm comfortable with coding in C, but not proficient at signal theory, but I'm willing to learn
[14:18:31 CET] <Guest60> Do I need to learn any other skills for doing a project?
[14:18:53 CET] <nevcairiel> it depends which task you want to work on
[14:19:35 CET] <Guest60> I was thinking about the one on improvement of the Vorbis decoder
[14:23:45 CET] <wm4_> kkanungo17: contact whichever mentor is listed
[14:23:52 CET] <wm4_> (on the wiki)
[14:24:06 CET] <kkanungo17> I did email atomnuker
[14:24:18 CET] <kkanungo17> just wanted to make sure
[14:24:38 CET] <wm4_> he'll probably reply, unless you accidentally landed in his spam folder or so
[14:29:38 CET] <nevcairiel> the vorbis task doesnt list any special requirements, but you should be prepared to learn such things then ;)
[14:30:08 CET] <kkanungo17> I am, really looking forward to it :D
[14:57:21 CET] <atomnuker> kkanungo17: sorry, didn't have time to respond yesterday
[14:57:58 CET] <kkanungo17> its okay
[15:05:11 CET] <atomnuker> kierank: that'll not be a small task at all since we have no decoder to test with, and the aac decoder is the audio equivalent of the h264 decoder
[15:12:49 CET] <durandal_1707> wasnt it supported by libfdk?
[15:14:39 CET] <atomnuker> some fork of it
[15:26:15 CET] <cone-520> ffmpeg 03Michael Niedermayer 07master:3182e19c1c29: avcodec/tiff: Check geotag count for being non zero
[15:26:16 CET] <cone-520> ffmpeg 03Michael Niedermayer 07master:0f34c0789f85: avcodec/pictordec: runtime error: left shift of 15 by 28 places cannot be represented in type 'int'
[15:26:17 CET] <cone-520> ffmpeg 03Michael Niedermayer 07master:4f727fbc7330: avcodec/h264_ps: Fix runtime error: signed integer overflow: 2147483647 + 26 cannot be represented in type 'int'
[15:47:55 CET] <cone-520> ffmpeg 03James Almer 07master:005da88c1ee2: avcodec/mediacodec: convert to stdatomic
[15:51:45 CET] <cone-520> ffmpeg 03James Almer 07master:05510ec06776: avcodec/videotoolboxenc: remove unused atomic header
[15:53:08 CET] <ubitux> is bit depth 12 fundamentally different from bit depth 10 in hevc idct?
[15:53:46 CET] <ubitux> i'm wondering if i should add the idct 12 support in our libav merge document in the last section (extra changes for consistency)
[15:53:53 CET] <ubitux> since it may be forgotten
[15:59:44 CET] <cone-520> ffmpeg 03Alexandra Hájková 07master:112cee0241f5: hevc: Add SSE2 and AVX IDCT
[15:59:45 CET] <cone-520> ffmpeg 03Clément BSsch 07master:947230837cb6: Merge commit '112cee0241f5799edff0e4682b9e8639b046dc78'
[16:01:25 CET] <BtbN> philipl, thoughts on adding -cqp, to replace the weird -global_quality thing? global_quality isn't even intended to be a public option it seems, and it's used via -q, which does h263 qscale stuff, with very weird results.
[16:03:30 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:eb542106029a: swscale: Add missing yuv444p12 swapping
[16:03:31 CET] <cone-520> ffmpeg 03Clément BSsch 07master:4c45c866cfbb: Merge commit 'eb542106029a9b28b4f76ff7c181eb4f542da9c4'
[16:05:54 CET] <nevcairiel> ubitux: maybe jamrial wants to look into that, he made the idct_dc support 12-bit, which basically didnt require asm changes
[16:06:51 CET] <philipl> BtbN: makes sense to me.
[16:08:05 CET] <philipl> more intuitive wrt x264. I know global_quality had me scratching my head originally
[16:08:24 CET] <BtbN> I have actually no idea why on earth I picked that.
[16:08:31 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:14e7e19a90e9: lavc: bsf: Document input/output codecparam alloc/init process
[16:08:32 CET] <cone-520> ffmpeg 03Clément BSsch 07master:cc012c46e8b8: Merge commit '14e7e19a90e9b45db7adeb4d40e7f16aa7404f28'
[16:08:39 CET] <BtbN> -cqp is in line with how libx264 handles things
[16:08:44 CET] <philipl> right
[16:09:00 CET] <BtbN> What I'm also confused about is that -cq thing nvidia sent a patch for recently...
[16:09:07 CET] <BtbN> It looks like constant quality, but for the VBR mode?
[16:09:12 CET] <cone-520> ffmpeg 03Vittorio Giovara 07master:e7e5be8635c1: APIchanges: Expand the name of recently added pixel formats
[16:09:13 CET] <cone-520> ffmpeg 03Clément BSsch 07master:295450e7f438: Merge commit 'e7e5be8635c1cf0588d2a07e59374135de6da55a'
[16:09:31 CET] <philipl> Well, 'constant quality' is variable bitrate :-)
[16:09:44 CET] <BtbN> yes, but VBR RC mode rather than CONSTQP RC mode.
[16:09:57 CET] <philipl> Which subject?
[16:10:18 CET] <BtbN> It's already merged, the patch itself was fine, as it just exposes another option
[16:10:28 CET] <BtbN> I just wonder what that option itself does
[16:10:38 CET] <BtbN> Or rather, what the difference to constQP is
[16:10:39 CET] <philipl> K. Well, they never really explain how all their modes really work.
[16:11:07 CET] <philipl> For -cqp - I'd argue that it should also set the i/p/b ratios the same as x264 does
[16:11:48 CET] <BtbN> I'd migrate the entire code to use cqp where it currently uses global_quality, and then have one place set cqp from global_quality if it's set, and maybe print a deprecation warning.
[16:11:55 CET] <philipl> yes.
[16:12:31 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L511
[16:12:34 CET] <philipl> but I mean, today all three are set to the same value when you use global_quality. I'd say have the -2/-3 (or whatever) adjustments happen automatically like in x264
[16:12:43 CET] <BtbN> that's all I can see x264 do with the -cqp setting. What ratios do you mean?
[16:12:51 CET] <philipl> They are internal to x264
[16:12:54 CET] <philipl> Not our policy
[16:13:01 CET] <BtbN> ah. hm.
[16:13:44 CET] <BtbN> https://github.com/mirror/x264/blob/90a61ec76424778c050524f682a33f115024be96/encoder/ratecontrol.c#L821
[16:13:46 CET] <BtbN> you mean this?
[16:14:12 CET] <philipl> yeah
[16:15:01 CET] <BtbN> That basically increases the quality for I frames a bit, and recudes it for B frames
[16:15:21 CET] <philipl> right
[16:15:32 CET] <BtbN> Kind of makes sense, I guess
[16:15:39 CET] <philipl> which seems to be generally considered correct
[16:16:15 CET] <philipl> I need to head into the office now. Back in about an hour.
[16:23:24 CET] <cone-520> ffmpeg 03Michael Niedermayer 07master:1e93aa69a608: Add GBRP12 pixel format support
[16:23:25 CET] <cone-520> ffmpeg 03Clément BSsch 07master:fbd352e07719: Merge commit '1e93aa69a60815d1407a6c34d8da3f83ab193ad5'
[16:27:30 CET] <durandal_1707> ubitux: you sure gif can output fine with pal8?
[16:27:34 CET] <cone-520> ffmpeg 03Michael Niedermayer 07master:328ea6a9a5ab: swscale: Add input support for 12-bit formats
[16:27:35 CET] <cone-520> ffmpeg 03Michael Niedermayer 07master:f59750641afd: swscale: x86: Add some forgotten 12-bit planar YUV cases
[16:27:36 CET] <cone-520> ffmpeg 03Luca Barbato 07master:ef3740c3a02b: swscale: Enable GBRP12 output
[16:27:37 CET] <cone-520> ffmpeg 03Kieran Kunhya 07master:81f1f6c3f62b: Add GBRAP12 pixel format support
[16:27:38 CET] <cone-520> ffmpeg 03Luca Barbato 07master:881477c77bb1: swscale: Add the GBRAP12 output
[16:27:39 CET] <cone-520> ffmpeg 03Clément BSsch 07master:6d541424da7b: Merge commit '881477c77bb10c3c62fda111b0f1f3554968bc78'
[16:28:30 CET] <ubitux> durandal_1707: mmh, now that i think about it...
[16:28:54 CET] <ubitux> yeah indeed it may not due to palette changes accross frames and old colors keeping the same values
[16:29:01 CET] <ubitux> or a picture composed of multiple palettes
[16:30:04 CET] <durandal_1707> well, if number of colors is greater than 256
[16:30:34 CET] <durandal_1707> we donnt have color count filter
[16:30:59 CET] <iive> there are some animations that use same picture but change the palette 
[16:31:27 CET] <cone-520> ffmpeg 03Sean McGovern 07master:c9527bf3444c: Make the RELEASE file match with the most recent tag
[16:31:28 CET] <cone-520> ffmpeg 03Clément BSsch 07master:e7329c0fd55c: Merge commit 'c9527bf3444c5332fa04931d32997308784fc862'
[16:35:05 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:7395784ba727: rtmpproto: Check the return from ff_amf_read_string
[16:35:06 CET] <cone-520> ffmpeg 03Clément BSsch 07master:36fcbc00765a: Merge commit '7395784ba72742b6daa62d35db4028e09f3fdf06'
[16:36:00 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:d6ded94036e4: rtmpproto: Lengthen the filename buffer when receiving streams
[16:36:01 CET] <cone-520> ffmpeg 03Clément BSsch 07master:a106b7e8b93f: Merge commit 'd6ded94036e43a04889f4ff2813a7f7dd60b82fe'
[16:37:22 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:8b5e0d17e704: rtmpproto: Send chunk size on the network channel
[16:37:23 CET] <cone-520> ffmpeg 03Clément BSsch 07master:d1c341f77b01: Merge commit '8b5e0d17e70400eaf5dc3845b5c1df8b2b88d830'
[16:38:18 CET] <BtbN> philipl, wouldn't that be basically identical to the logic nvidia added for the init_qp_p?
[16:38:18 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:9f23f77a532c: rtmpproto: Don't include the libavformat version as "clientid"
[16:38:19 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:7d8d726be7dc: rtmpproto: Don't include a client version in the unencrypted C1 handshake
[16:38:20 CET] <cone-520> ffmpeg 03Clément BSsch 07master:ddcd396075df: Merge commit '9f23f77a532ca9c2b7dc4b5328bc413e4f6f5b56'
[16:38:21 CET] <cone-520> ffmpeg 03Clément BSsch 07master:8892739a1605: Merge commit '7d8d726be7dc46343ab1c98c339c1ed44bcb07c1'
[16:38:23 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L516
[16:38:49 CET] <BtbN> Except that it adds it to both, reducing both I and B frames quality
[16:40:38 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:20b75970e43a: file protocol: handle the file: protocol string in file_check
[16:40:39 CET] <cone-520> ffmpeg 03Clément BSsch 07master:962e15d0f525: Merge commit '20b75970e43a030f959b17ff2dfd561174b6f24e'
[16:41:25 CET] <cone-520> ffmpeg 03James Almer 07master:6c31ba226968: avformat/matroska: fix MatroskaVideoFieldOrder enum values
[16:41:26 CET] <cone-520> ffmpeg 03Clément BSsch 07master:590fb5291ad4: Merge commit '6c31ba226968f12f898120dbb928dab34e03782b'
[16:41:51 CET] <BtbN> philipl, ah, the avctx->i_quant_factor and b_quant_factor are set to -0.8 and 1.25
[16:41:58 CET] <BtbN> But why does he fabs() it?
[16:50:13 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:4abe3b049d98: hevc: rename hevc.[ch] to hevcdec.[ch]
[16:50:14 CET] <cone-520> ffmpeg 03Clément BSsch 07master:038e6aef7a54: Merge commit '4abe3b049d987420eb891f74a35af2cebbf52144'
[16:50:45 CET] <ubitux> anyone wants to take over the merges for a while? i'm getting tired :(
[16:51:24 CET] <ubitux> (ETA: 776)
[16:53:30 CET] <ubitux> we're mid-october 2016
[16:57:37 CET] <BtbN> philipl, nevermind, libx264.c in ffmpeg compensates for that - and +: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L527
[16:57:55 CET] <BtbN> In ffmpeg, the factor is instead less than 1
[17:07:08 CET] <BtbN> Is it only me, or is this specific line a bug in libx264.c: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L526
[17:07:23 CET] <BtbN> The i_quant_factor is -0.8 by default. The check should imo just be != 0.0
[17:11:00 CET] <nevcairiel> the default is -1, ie. disabled
[17:11:14 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/options_table.h#L204
[17:11:24 CET] <nevcairiel> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L988
[17:11:32 CET] <nevcairiel> need to read the correct defaults =p
[17:11:46 CET] <BtbN> But still, -0.8 would be a perfectly valid value
[17:12:00 CET] <nevcairiel> not necessarily for x264
[17:12:08 CET] <BtbN> would be no reason for the fabs() around it if it wasn't
[17:12:34 CET] <nevcairiel> makes no sense to use negative values then
[17:12:44 CET] <nevcairiel> so might as well leave it
[17:12:52 CET] <BtbN> yes, I do wonder why the options_table.h default is negative
[17:13:01 CET] <nevcairiel> probably for other encoders
[17:13:03 CET] <nevcairiel> mpeg2 or mpeg4
[17:13:05 CET] <BtbN> But the check for > 0 and fabs() in the very next line does seem a bit strange
[17:13:22 CET] <nevcairiel> -1 is typically used as a default-unused value
[17:13:44 CET] <BtbN> for a factor, 0 would make more sense there
[17:15:02 CET] <nevcairiel> the factor is a mulitplier, so 0 is inherently invalid and should probably be avoided as a value at any time
[17:16:09 CET] <BtbN> hm, wonder if I should override the default in nvenc as well then
[17:16:25 CET] <BtbN> Right now, the only way to disable the offset for nvenc is to set it to 0
[17:17:15 CET] <BtbN> So default the I offset to 0.8, B offset to 1.25, and drop all the fabs, and check for > 0
[17:18:19 CET] <BtbN> philipl, https://github.com/BtbN/FFmpeg/commits/master see my latest commits
[17:30:46 CET] <philipl> BtbN: looks good to me
[17:49:03 CET] <thebombzen> huh, I can't reproduce that bug and I built ffmpeg 5 minutes ago. says it's 3.2.4 tho so I'll try that
[17:50:42 CET] <thebombzen> okay, I can reproduce on 3.2.4 but not git master
[17:50:50 CET] <thebombzen> seems already fixed
[18:21:52 CET] <cone-520> ffmpeg 03Timo Rothenpieler 07master:7fb2a7afa174: avcodec/nvenc: Deprecate usage of global_quality, introducing qp
[18:21:53 CET] <cone-520> ffmpeg 03Timo Rothenpieler 07master:d84c2298e28c: avcodec/nvenc: apply quantization factors to cqp
[18:56:11 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:c359d624d3ef: hevcdec: move decoder-independent declarations into a separate header
[18:56:12 CET] <cone-520> ffmpeg 03James Almer 07master:a1a80a6c9ce5: avcodec/bytestream: check for AV_HAVE_BIGENDIAN instead of HAVE_BIGENDIAN
[18:56:13 CET] <cone-520> ffmpeg 03James Almer 07master:6397815be0be: Merge commit 'c359d624d3efc3fd1d83210d78c4152bd329b765'
[19:00:14 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:645c6ff4231a: hevcdec: drop the prototype of a non-existing function
[19:00:15 CET] <cone-520> ffmpeg 03James Almer 07master:e7a6200dcb3c: Merge commit '645c6ff4231a75a71db58c8e6d06346068d2f949'
[19:08:33 CET] <cone-520> ffmpeg 03James Almer 07master:5c6efaffd09d: avcodec/hevc: add missing hevc.h header
[19:17:03 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:150c896a9e46: hevcdec: split ff_hevc_diag_scan* declarations into a separate header
[19:17:04 CET] <cone-520> ffmpeg 03James Almer 07master:b29c8c995f17: Merge commit '150c896a9e46b23b97debb0a5f66fbaeaa32f153'
[20:09:10 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:f6e2f8a9ffda: hevcdec: move parameter set parsing into a separate header
[20:09:11 CET] <cone-520> ffmpeg 03James Almer 07master:4a5810b6592d: Merge commit 'f6e2f8a9ffda2247bffba991450990d075ea68e3'
[20:33:15 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:89b35a139e83: lavc: add a bitstream filter for extracting extradata from packets
[20:33:16 CET] <cone-520> ffmpeg 03James Almer 07master:7ebc9f8df403: Merge commit '89b35a139e838deeb32ec20d8d034c81014401d0'
[21:23:49 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:8e2ea691351c: lavf: use the new bitstream filter for extracting extradata
[21:23:50 CET] <cone-520> ffmpeg 03James Almer 07master:1c193ac1f9cf: Merge commit '8e2ea691351c5079cdab245ff7bfa5c0f3e3bfe4'
[21:35:39 CET] <legume> Another header needed since recent merges? libavcodec/vaapi_encode_h265.c:633:35: error: P_SLICE undeclared
[21:36:31 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:a05cc56124b4: checkasm: arm/aarch64: Fix the amount of space reserved for stack parameters
[21:36:32 CET] <cone-520> ffmpeg 03James Almer 07master:cab4c7fa199f: Merge commit 'a05cc56124b4f1237f6355784de821e3290ddb44'
[21:37:57 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:f1b3e1313851: checkasm: aarch64: Clobber the stack before calling functions
[21:37:58 CET] <cone-520> ffmpeg 03James Almer 07master:a2d34cc51ba1: Merge commit 'f1b3e131385176c3c9d9783b25047856a0dcebf6'
[21:39:10 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:c91d6a33f872: checkasm: aarch64: Add filler args to make sure all parameters are passed on the stack
[21:39:11 CET] <cone-520> ffmpeg 03James Almer 07master:67b639b49626: Merge commit 'c91d6a33f872574c95c8784277cf60ffcf6bff4f'
[21:42:56 CET] <ubitux> jamrial: nice, thanks for taking over
[21:42:58 CET] <ubitux> did you see dd5d4a0e1e?
[21:43:44 CET] <jamrial> we're not there yet
[21:44:02 CET] <jamrial> and no prob. I'll try to do some more
[21:45:02 CET] <ubitux> yeah but it's a regression in a commit you recently merged :)
[21:45:12 CET] <ubitux> but i guess you'll reach that one soon
[21:45:26 CET] <jamrial> ah, lol
[21:45:34 CET] <jamrial> if i don't i'll cherry pick it
[21:45:47 CET] <ubitux> it's 10 commits away
[21:45:49 CET] <ubitux> no worry
[22:00:05 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:93d5b022a9fd: build: Drop duplicate asm recipe
[22:00:06 CET] <cone-520> ffmpeg 03James Almer 07master:3ddae9eee9a8: Merge commit '93d5b022a9fd3a1a1f9c521a1eac7f0410e05b81'
[22:02:53 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:2816f8a8bb33: build: Drop arch-specific checkasm Makefiles
[22:02:54 CET] <cone-520> ffmpeg 03James Almer 07master:f23078904f99: Merge commit '2816f8a8bb33bd67fec5e94f5d357918caf4e055'
[22:03:40 CET] <faLUCE> ubitux: wm4_ : I wrote many examples which are SHORT and CLEAN, and can be really useful for the documentation, instead of the messy and not up to date doc/examples folder. I would be glad to push them to the ffmpeg project if you find them good/useful... but who is a person that can judge them? I can show you one of them, if you want
[22:06:25 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:6be7944ee2ec: x86: Add missing colons after assembly labels
[22:06:26 CET] <cone-520> ffmpeg 03James Almer 07master:29db87af522c: Merge commit '6be7944ee2ec2f045e6eb9a93237e992c8b20ac4'
[22:07:38 CET] <jamrial> faLUCE: send them to the ml. documentation and api usage examples are always welcome
[22:09:03 CET] <faLUCE> jamrial: after sending them to the ml, who will judge if they can be published ?
[22:09:31 CET] <jamrial> any developer who can review them
[22:10:08 CET] <faLUCE> jamrial: can I send them to some developer, directly ?
[22:11:23 CET] <cone-520> ffmpeg 03Mark Thompson 07master:f9bb356e0eb3: vaapi_h265: Include header for slice types
[22:11:24 CET] <cone-520> ffmpeg 03James Almer 07master:c43fd1f279ce: Merge commit 'f9bb356e0eb38ab4df32df8276b71a0b2626538f'
[22:15:02 CET] <jamrial> faLUCE: no
[22:16:27 CET] <cone-520> ffmpeg 03Mark Thompson 07master:0cf86fabfa58: vaapi_encode: Write sequence header as extradata
[22:16:28 CET] <cone-520> ffmpeg 03James Almer 07master:530066166e3c: Merge commit '0cf86fabfa5820596cca2cfead63c6f8df76c3f2'
[22:18:58 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:58224dc5f3d4: ppc: avcodec: Drop silly "_ppc" suffixes from files in ppc subdirectories
[22:18:59 CET] <cone-520> ffmpeg 03James Almer 07master:09a80419b73d: Merge commit '58224dc5f3d4fea40a8d55cca87291a960c11622'
[22:21:12 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:d32571626a2c: build: Add VSX-OBJS to SUBDIR_VARS
[22:21:13 CET] <cone-520> ffmpeg 03James Almer 07master:78c52e2721ca: Merge commit 'd32571626a2c36c026b7fa13d19ac4ed1aad75c9'
[22:28:12 CET] <cone-520> ffmpeg 03Michael Niedermayer 07master:be9dba5c8abc: swscale: Properly load alpha for planar rgb
[22:28:13 CET] <cone-520> ffmpeg 03James Almer 07master:0dcfa02fd278: Merge commit 'be9dba5c8abc6ecf0b8ee4ccb11c7850327fcf8d'
[22:31:18 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:7911186ed616: emms: Give apriv_emms_yasm() a more general name
[22:31:19 CET] <cone-520> ffmpeg 03James Almer 07master:c97e986e90c3: Merge commit '7911186ed616ae81dd8617d6d0e8b08c818db9d8'
[22:32:53 CET] <cone-520> ffmpeg 03Martin Storsjö 07master:dd5d4a0e1e3a: checkasm: aarch64: Don't clobber x29 in checkasm_stack_clobber
[22:32:54 CET] <cone-520> ffmpeg 03James Almer 07master:0d34473d8ecd: Merge commit 'dd5d4a0e1e3a30a254d1a57ecbdcedf230c6014b'
[22:34:41 CET] <cone-520> ffmpeg 03Luca Barbato 07master:da4f8c8e35a8: fate: Update filter-pixfmts-scale gbrap12le hash missing from be9dba5c8a
[22:34:42 CET] <cone-520> ffmpeg 03James Almer 07master:acf125f3336b: Merge commit 'da4f8c8e35a867f2d9fed0fb75e16c81ab968637'
[22:36:29 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:b89804da9bad: x86: videodsp: Add parentheses to expression to work around warning
[22:36:30 CET] <cone-520> ffmpeg 03James Almer 07master:bac44a50206e: Merge commit 'b89804da9bad2d94dd95bf20ac6187447e9c17e9'
[22:41:49 CET] <legume> build OK now
[22:44:17 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:1f821e5ad3f8: configure: Print warnings after all other output
[22:44:18 CET] <cone-520> ffmpeg 03James Almer 07master:d07f2dacb97f: Merge commit '1f821e5ad3f8ebacbbb362668561ad976c392c9e'
[22:46:55 CET] <cone-520> ffmpeg 03Diego Biurrun 07master:788544ff0ed6: audiodsp: x86: Remove pointless header file
[22:46:58 CET] <cone-520> ffmpeg 03James Almer 07master:380448194fb4: Merge commit '788544ff0ed6fe67fda80ad6d3a0796ace035584'
[22:58:13 CET] <jamrial> ubitux: could you check the failing subtitle tests?
[22:58:43 CET] <jamrial> the bad merge is 1c193ac1f9cf, with the new bsf
[23:00:01 CET] <jamrial> is the change desired or not? i ask based on the comment in the relevant merged commit
[23:01:04 CET] <ubitux> huh
[23:01:08 CET] <ubitux> we're loosing 1 sec?
[23:01:16 CET] <ubitux> on the pts
[23:02:34 CET] <ubitux> it's incorrect
[23:02:37 CET] <jamrial> supposedly, the commit may change packet durations
[23:02:43 CET] <jamrial> but yeah, i'm inclined to revert it
[23:02:53 CET] <jamrial> other failing tests are clearly broken
[23:03:04 CET] <ubitux> the first pts starts at 0 for subtitles
[23:03:07 CET] <jamrial> fuck, i was sure i ran fate before pushing it
[23:03:08 CET] <ubitux> while it shouldn't
[23:04:26 CET] <jamrial> i'm going to bet the problem is some difference in how we copy codecpar info with bsfs
[23:35:55 CET] <cone-520> ffmpeg 03James Almer 07master:40fa9d416a25: Revert "Merge commit '8e2ea691351c5079cdab245ff7bfa5c0f3e3bfe4'"
[23:40:37 CET] <ubitux> michaelni: http://sprunge.us/dNLZ isn't this more correcT?
[23:43:33 CET] <cone-520> ffmpeg 03Anton Khirnov 07master:096a8effa3f8: lavf: check that the codec is supported by extract_extradata
[23:43:34 CET] <cone-520> ffmpeg 03James Almer 07master:950c3fa52097: Merge commit '096a8effa3f8f3455292c958c3ed07e798def7bd'
[23:46:10 CET] <ubitux> michaelni: it's changing a bunch of fate ref though&
[23:46:45 CET] <ubitux> but maybe i do not understand the meaning of that macro
[23:47:56 CET] <ubitux> (also, shouldn't this list include the 0RGB and 0BGR pix fmts?)
[23:50:20 CET] <cone-520> ffmpeg 03James Almer 07master:0f4abbd4ee1c: doc/libav-merge: add a line about the extract_extradata commits
[23:56:01 CET] <michaelni> ubitux, IIRC RGBinInt would be the formats that are ordered as RGB when loaded in a integer 
[23:56:50 CET] <michaelni> i suspect the patch linked is wrong, but does it fix anything?
[23:57:41 CET] <ubitux> it probably doesn't
[23:57:48 CET] <ubitux> i indeed misunderstood the function then
[23:58:07 CET] <ubitux> but yeah i was wondering about the suncc fate failure
[23:59:02 CET] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20170323205016&slot=sparc-solaris-32bit-gcc-5.2
[23:59:47 CET] <ubitux> i'm wondering what would be a correct fix for this, if any
[00:00:00 CET] --- Fri Mar 24 2017


More information about the Ffmpeg-devel-irc mailing list