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

[burek]

[00:14:02 CEST] <cehoyos> jkqxz: I believe the additional magic can be useful (sorry for the delay, suse is not as responsive as I expected - or actually they respond differently than I expected)
[00:46:29 CEST] <jkqxz> cehoyos:  Do you have any thoughts on how you'd like that additional magic to work?
[00:46:36 CEST] <jkqxz> What I come up with is something like conditioning the behaviour of the pix_fmt option on whether the decoder which gets used is get_format-capable or not (with a new flag in lavc to signal that).
[00:49:56 CEST] <cehoyos> I am not saying that I have a solution (or even an idea). I always thought that it is (already) possible to choose the pix_fmt in a decoder (at least one lavc decoder support two pix_fmts for one type of input) but apparently this is only possible with MPlayer. I would really like the option "pix_fmt" when used as an input option choose the pix_fmt for decoders that support this feature.
[00:50:06 CEST] <jkqxz> But that causes weird problems in redundant options.  You run "ffmpeg -pix_fmt yuv420p -i h264.mkv ..." and it's, then you run "ffmpeg -pix_fmt yuv420p -i theora.ogv ..." and it errors out.
[00:50:41 CEST] <cehoyos> You mean if the file cannot be decoded as yuv420p?
[00:51:24 CEST] <cehoyos> A warning could also be printed but it is certainly ok to error out if the (new) input option "pix_fmt" is used and a pix_fmt is requested that cannot be returned.
[00:51:57 CEST] <jkqxz> No, that failure is because the magic choice triggered the other way with get_format not being supported, and libavformat doesn't like the option.
[00:52:20 CEST] <jkqxz> (Try -pix_fmt now on an input which isn't rawvideo or some things in lavd.)
[00:54:04 CEST] <cehoyos> Of course, what I suggest is to add an lavc input option
[00:56:36 CEST] <jkqxz> How would you intend to distinguish it from the identically-named lavf/lavd option?
[00:56:58 CEST] <cehoyos> jkqxz: Sorry, have to sleep - I believe it would make user's life much easier if the option is called "pix_fmt", if this is impossible, too bad.
[00:57:10 CEST] <cehoyos> But for rawvideo, it would continue to work, no?
[00:57:20 CEST] <cehoyos> For lavd, we should just remove the option.
[00:58:22 CEST] <jkqxz> Unfortunately the rawvideo case is the lavd option (then passed into lavc via codecpar).
[00:58:27 CEST] <cehoyos> Given that there is no option "pix_fmt" in lavf, I don't see the big issue: rawvideo just will have to use the future lavc option instead of the lavf option.
[00:58:42 CEST] <cehoyos> But there is no option "pix_fmt" in lavf, no?
[00:58:59 CEST] <jkqxz> The option is pixel_format in lavf; see link above.  Users are setting it as -pix_fmt on the command line.
[00:59:12 CEST] <cehoyos> But we are allowed to change the command line interface.
[00:59:45 CEST] <cehoyos> And it could still be "pix_fmt" for rawvideo: The decoder should understand the new option.
[01:00:08 CEST] <jkqxz> I think lavd still wants it for codecpar.
[01:00:09 CEST] <cehoyos> And - see above - pix_fmt for "mjpeg" in v4l2 seems bad to me independently of the new use case.
[01:00:18 CEST] <cehoyos> Ahhh, and we are there!
[01:00:29 CEST] <jkqxz> *rawvideo in lavd, I mean.
[01:00:35 CEST] <cehoyos> Imo, we should try to do it.
[01:00:42 CEST] <jkqxz> *rawvideo in lavf.  Grr.
[01:00:57 CEST] <jkqxz> Killing the option in lavd would make sense.
[01:01:00 CEST] <cehoyos> Imo, the rawvideo decoder should in the future read the "pix_fmt" lavc option.
[01:01:19 CEST] <cehoyos> (the future "pix_fmt" lavc option)
[01:01:54 CEST] <jkqxz> I think it's still an ffmpeg option rather than an lavc option, but it passes into the right place.
[01:02:57 CEST] <cehoyos> I thought the existing patch adds a new option to lavc, does it not?
[01:03:57 CEST] <jkqxz> The existing patch touches only ffmpeg.
[01:05:00 CEST] <cehoyos> Yes, I found it, sorry!
[01:05:35 CEST] <cehoyos> So if there is a possibility to detect that the input is (format) rawvideo, it would be great imo.
[01:07:10 CEST] <jkqxz> Ok, so: (a) remove the pix_fmt -> pixel_format case for all of the lavd things, only trigger it if we actually have rawvideo; then (b) make this option as pix_fmt.
[01:10:14 CEST] <jkqxz> I'd be happy with that answer.  People would need to change their command lines for v4l2 and similar, but that option is somewhat confusing anyway because it's not a pixfmt (input_format is indeed much clearer) so I'm not sure that's a bad thing.
[01:14:55 CEST] <cehoyos> That would - without a lot of thinking - a good solution imo!
[02:55:12 CEST] <mkver> @michaelni: Your cinepak is missing a 'const' qualifer.
[02:56:09 CEST] <mkver> Your cinepak patch of course.
[08:22:52 CEST] <cone-296> ffmpeg 03Michael Niedermayer 07master:7eba264513b3: avcodec/cinepak: Add missing const
[11:56:59 CEST] <jdarnley> Who's in charge of managing ssh keys for the git repo?  michaelni?
[12:45:06 CEST] <nevcairiel> thats probably your best bet
[15:01:24 CEST] <BBB> hm... so when I have grayscale (y plane only) data, and I try to generate a y4m from it, I get this: "[rawvideo @ 0x7f9dcc814000] Invalid buffer size, packet size 230400 < expected frame_size 340200"
[15:01:45 CEST] <BBB> ffmpeg -f rawvideo -s 630x360 -pixel_format gray8 -i ${file}.y -y -f yuv4mpegpipe ${file}.y4m
[15:01:57 CEST] <BBB> is rawvideo somehow not aware of gray8 not having chroma planes?
[15:06:13 CEST] <durandal_1707> BBB: move pixel_format before -f rawvideo?
[15:06:46 CEST] <durandal_1707> i can not reproduce this
[15:06:59 CEST] <BBB> let me update (that's probably always the first fix)
[15:42:30 CEST] <cone-519> ffmpeg 03Paul B Mahol 07master:bf5d814f1082: avcodec/wavpackenc: use ff_clz()
[17:12:09 CEST] <durandal_1707> BBB: i considering resurrecting vmaf patches, are you by any chances working on them?
[17:14:19 CEST] <BBB> no
[17:14:30 CEST] <BBB> that would be cool
[17:52:27 CEST] <durandal_1707> cehoyos, michaelni: you stopped applying others people patches, why?
[18:02:40 CEST] <cehoyos> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=499b46fd0a891b6518f4e421aa2582dc70f700d9
[18:02:41 CEST] <cehoyos> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=4d2f62150dba814eeb28de0d6723f6beb3638be9
[18:02:49 CEST] <cehoyos> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=499b46fd0a891b6518f4e421aa2582dc70f700d9
[18:03:07 CEST] <cehoyos> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=2be7c388db67a0ba7fe480e95a3455b1adc992ce
[18:03:40 CEST] <cehoyos> There was a fourth one in April (sorry for the duplicate), I don't think I ever committed more patches by other developers
[18:04:20 CEST] <qyot27> Out of curiosity, is it preferable to ping each individual patch of a patchset on the mailing list that's not moved in a few weeks, or point to it from here and see if there's any more comments?
[18:05:00 CEST] <cehoyos> Pinging the first one may help, pinging all might annoy some people...
[18:05:01 CEST] <JEEB> pinging the patch set in general tends to be the thing. although mentioning a patchwork link here can also be of use
[18:20:13 CEST] <qyot27> The original had some email client weirdness posting them out-of order, but the two most relevant posts on the mailing list for the patchset are http://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241924.html and a slightly more updated version of one of the six patches at http://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/241948.html
[18:20:18 CEST] <qyot27> The patchwork ids for the latest versions of the patches are 12537, 12420, 12423, 12421, 12543, and 12538.
[18:31:57 CEST] <qyot27> And I've also just pinged the two mailing list posts, just in case.
[18:55:42 CEST] <cone-519> ffmpeg 03Tristan Matthews 07master:1e5617351582: rtsp: add pkt_size option
[18:55:43 CEST] <cone-519> ffmpeg 03Martin Storsjö 07master:c0bd865ad60d: configure: Add -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 for mingw as well
[18:55:44 CEST] <cone-519> ffmpeg 03Martin Storsjö 07master:c93e92f2b25f: configure: Include time.h when checking for gmtime_r and localtime_r
[18:55:45 CEST] <cone-519> ffmpeg 03Michael Niedermayer 07master:9485cce6d55b: time_internal: Do not attempt to override *time_r() macros
[18:55:46 CEST] <cone-519> ffmpeg 03Martin Storsjö 07master:c4642788e83b: time_internal: Prefix fallback versions of gmtime_r/localtime_r with ff_
[18:55:47 CEST] <cone-519> ffmpeg 03James Almer 07master:3e076faf3b86: Merge commit '1e56173515826aa4d680d3b216d80a3879ed1c68'
[18:55:48 CEST] <cone-519> ffmpeg 03James Almer 07master:0084eed5bffe: Merge commit 'c0bd865ad60da31282c5d8e1000c98366249c31e'
[18:55:49 CEST] <cone-519> ffmpeg 03James Almer 07master:67d466d09b10: Merge commit 'c93e92f2b25f4174350ded3f59ad117ec8eb1fe4'
[18:55:50 CEST] <cone-519> ffmpeg 03James Almer 07master:e645d7a6d452: Merge commit '9485cce6d55baf547e92ef1f54cad117f2a38287'
[18:55:51 CEST] <cone-519> ffmpeg 03James Almer 07master:e427ba5c68a5: Merge commit 'c4642788e83b0858bca449f9b6e71ddb015dfa5d'
[19:25:18 CEST] <cone-519> ffmpeg 03James Darnley 07master:e2cbf24f2738: avcodec/v210dec: move DSP function setting into dedicated function
[19:25:19 CEST] <cone-519> ffmpeg 03James Darnley 07master:76c370af64e4: checkasm: add test for v210dec
[19:25:20 CEST] <cone-519> ffmpeg 03Michael Stoner 07master:ebd6fb23c537: libavcodec Adding ff_v210_planar_unpack AVX2
[20:20:46 CEST] <jdarnley> damn, looks like that assembly is wrong on some 32-bit platforms
[20:46:17 CEST] <jdarnley> naturally I can't seem to reproduce it on 32-bit cygwin
[20:52:12 CEST] <cone-519> ffmpeg 03Andreas Rheinhardt 07master:73ef1f47f593: lavf/webm_chunk: Respect buffer size
[21:08:37 CEST] <jdarnley> yay, thanks yasm
[21:09:51 CEST] <jdarnley> it doesn't like vpblendd
[21:10:47 CEST] <BBB> works for me?
[21:11:01 CEST] <BBB> I think you need to explicitly give it a dst register
[21:11:06 CEST] <BBB> whereas in nasm that can be implied
[21:11:12 CEST] <BBB> (by src1)
[21:11:13 CEST] <jdarnley> for the V-form I guess
[21:12:46 CEST] <jdarnley> oh, maybe there is no legacy form
[21:16:24 CEST] <jdarnley> and I can reproduce with yasm on x86-64 linux
[21:21:12 CEST] <cone-519> ffmpeg 03James Darnley 07master:46f1718cd97c: avcodec/x86/v210: fix operands of vpblendd used in new avx2 code
[22:36:29 CEST] <Gramner> yeah, yasm requires some instructions to explicitly state the dst operand even when it's identical to src1. but only for some randomly picked subset of instructions
[23:09:30 CEST] <durandal_1707> BBB: have you tested this vmaf code? looks like last filter is broken
[23:09:45 CEST] <BBB> I have tested what was committed/merged
[23:09:53 CEST] <BBB> (vmafmotion)
[23:10:07 CEST] <BBB> I think I was working on testing the next one also and I submitted some fixes to get that working
[23:10:11 CEST] <BBB> I don't think I tested the last one
[23:11:43 CEST] <durandal_1707> BBB: last filter is completely botched....
[23:16:53 CEST] <BBB> sorry :(
[23:17:00 CEST] <BBB> there's a reason it wasn't merged, I guess
[23:18:15 CEST] <durandal_1707> you should not pass him
[23:20:07 CEST] <BBB> toolate
[00:00:00 CEST] --- Fri May  3 2019