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

[burek]

[00:24:47 CEST] <cone-330> ffmpeg 03Jun Zhao 07master:71e2ec017a1b: lavc: enable hwaccel_flags option
[00:24:48 CEST] <cone-330> ffmpeg 03Jun Zhao 07master:217a723b4e05: lavc/vaapi_decode: fix profile search when profile mismatch is allowed
[00:27:51 CEST] <jamrial> jkqxz: https://pastebin.com/raw/8kTUy4gk
[00:28:10 CEST] <jamrial> guess the range you hardcoded (0, 4) is wrong?
[00:28:45 CEST] <jamrial> this is in pps rext
[00:33:01 CEST] <jkqxz> "When present, the value of log2_max_transform_skip_block_size_minus2 shall be less than or equal to MaxTbLog2SizeY - 2."
[00:34:12 CEST] <jkqxz> "The CVS shall not contain data that result in MaxTbLog2SizeY greater than Min( CtbLog2SizeY, 5 )."
[00:34:30 CEST] <jkqxz> And isn't CtbLog2SizeY bounded above by 6?  (64x64)
[00:36:24 CEST] <jamrial> i have no idea
[00:36:32 CEST] <jamrial> but does this mean the conformance sample is not in fact conformant? :p
[00:37:06 CEST] <jkqxz> Does the trace look otherwise sensible?
[00:38:41 CEST] <jamrial> seems fine otherwise
[00:39:45 CEST] <jamrial> found this btw when i was trying to add cbs tests using the rext samples. all work and the output is bitexact, except for that one where parsing fails because of that one field
[00:43:25 CEST] <jkqxz> Well, the rest of that stream has log2_min_luma_coding_block_size_minus3 = 1, log2_diff_max_min_luma_coding_block_size = 2.
[00:43:53 CEST] <jkqxz> So MinCbLog2SizeY = 4 and CtbLog2SizeY = 6.
[00:44:30 CEST] <jkqxz> So log2_max_transform_skip_block_size_minus2 can't be greater than 4.
[00:44:35 CEST] <jkqxz> I wonder what the reference decoder says.
[00:45:42 CEST] <jkqxz> "     233  log2_max_transform_skip_block_size_minus2          ue(v) : 6"
[00:45:43 CEST] <jkqxz> Hmm.
[00:46:46 CEST] <jkqxz> I must be getting something wrong here...
[00:52:54 CEST] <jkqxz> It's not nonsensical for it to be higher, it just means "transform_skip_flag is always present if it can be".
[00:54:50 CEST] <jkqxz> <https://hevc.hhi.fraunhofer.de/trac/hevc/ticket/1363>
[00:55:06 CEST] <jkqxz> Maybe it really is out-of-range in that sample and noone ever noticed.
[01:04:39 CEST] <jamrial> jkqxz: probably. there's a new sample replacing this one, called PERSIST_RPARAM_A_RExt_Sony_3, where this field has a value of 3
[01:04:46 CEST] <jkqxz> Thinking further, min(x, 5) is because the largest defined transform is 32x32.  Given that, offering the possibility of transform skip for anything greater than 32x32 makes no sense, so log2_max_transform_skip_block_size_minus2 should be bounded above at 3.
[01:04:54 CEST] <jkqxz> So the sample is just wrong?
[01:05:20 CEST] <jamrial> i have no idea, but it very well could be, judging by that
[01:05:23 CEST] <jamrial> http://wftp3.itu.int/av-arch/jctvc-site/bitstream_exchange/draft_conformance/RExt/
[01:05:39 CEST] <jamrial> since it's been superseeded...
[01:06:21 CEST] <jkqxz> Right, in the explanatory text for that it has "Maximum transform skip log2 maximum size set to 5 (32x32) (previous revisions had the value of 8).".
[01:06:42 CEST] <jamrial> mystery solved :p
[01:06:45 CEST] <jkqxz> Yay!
[01:06:51 CEST] <jamrial> maybe we should add this sample to the fate suite
[01:07:30 CEST] <jkqxz> Would be nice if it could replace the invalid one...
[01:07:39 CEST] <jamrial> it can't. old releases and all that
[01:07:46 CEST] <jkqxz> But I guess that's not really allowed, yeah.
[01:09:39 CEST] <jamrial> michaelni, nevcairiel: can you upload http://wftp3.itu.int/av-arch/jctvc-site/bitstream_exchange/draft_conformance/RExt/PERSIST_RPARAM_A_RExt_Sony_3.zip (only the .bit file inside the zip) to the hevc-conformance folder?
[01:10:47 CEST] <jkqxz> I've corrected the bounds to [0, 3] locally.
[01:11:42 CEST] <jkqxz> What tests are you intending to add?  I avoided running across everything in FATE because I thought people would say that was excessive, hence the current subset of streams hopefully covering all header cases.
[01:12:01 CEST] <jkqxz> Normal cases, though, not rext.
[01:25:15 CEST] <jamrial> jkqxz: tried all the rext ones (HEVC_SAMPLES_422_* and HEVC_SAMPLES_444_* in hevc.mak)
[01:25:27 CEST] <jamrial> and only that one tripped with that field
[01:25:43 CEST] <jamrial> the rest were bitexact after passing through hevc_metadata
[01:25:56 CEST] <jamrial> so imo, add one of each
[01:28:04 CEST] <jamrial> none had the extensions you don't support (3d, multilayer, etc)
[01:39:57 CEST] <michaelni> jamrial, bit file uploded
[01:40:12 CEST] <jamrial> michaelni: thanks
[02:42:31 CEST] <cone-330> ffmpeg 03James Almer 07master:fde3bb16f90a: build: prevent SDL2 from polluting global cflags and extralibs
[03:46:44 CEST] <cone-330> ffmpeg 03James Almer 07master:17ba9e123f1e: fate: update fate-api reference files after 71e2ec017a
[17:38:48 CEST] <wm4> what does -Wbool-operation do?
[17:38:58 CEST] <wm4> of course nobody knows because Carl Eugen Hoyos can't write commit messages
[17:43:17 CEST] <jkqxz> Compiler tells you you are naughty for writing things like { ~(a == b) } or { !a & b }.
[17:52:53 CEST] <BtbN> wm4, do you still want to rename stuff to nvdec btw.? I wanted to rename cuvid for a while, since nvdec is what nvidia calls it everywhere now. And the new thing would be a perfect chance to just call it nvdec from the beginning.
[17:54:12 CEST] <wm4> jkqxz: ????
[17:54:30 CEST] <wm4> jkqxz: i.e. compiler devs being patronizing?
[17:54:49 CEST] <wm4> BtbN: if we remove dummy hwaccels (Libav patch pending), then that won't be necessary for now
[17:55:17 CEST] <BtbN> Yeah, I know it's not technically neccesary.
[17:55:33 CEST] <wm4> or do you want the Libav thing renamed?
[17:55:48 CEST] <BtbN> That was my idea, yes
[17:56:07 CEST] <BtbN> Just calling it nvdec instead of cuvid. Avoids confusion between the current cuvid, and does the rename I wanted to do eventually anyway
[17:58:24 CEST] <wm4> would it be ok to rename the ffmpeg cuvid source file anyway, and commit the Libav thing under the libav name, then rename it in a separate commit? I'm worried about git's rename tracking
[17:58:38 CEST] <BtbN> yeah, of course
[17:59:06 CEST] <BtbN> keeping the history like that sounds like a good idea to me
[17:59:45 CEST] <Emerica> I have modified mpegtsenc to support user specified pid values based on the the stream index.  ie -mpegts_pids "0=1311,1=1411"   I'm using avstrtok to breakup the input string and store the pid values to an array.  is this the wrong approach in bringing in the input values?
[18:00:40 CEST] <BtbN> wouldn't sscanf be easier?
[18:00:59 CEST] <Emerica> I don't know enough to know, but now I'll look :)
[18:31:57 CEST] <BtbN> wm4, what I'm kinda missing in the libav-cuvid is any kind of capability check. With ffmpeg own h264 parser in place, the information should all be readily available.
[18:32:09 CEST] <BtbN> But I guess I can just add one once it's merged
[18:33:37 CEST] <wm4> hm I assume it relies on h264 calling this only for generally supported profiles? still seems rather fishy
[18:34:09 CEST] <BtbN> It just assumes the hardware supports 10bit, no check on that whatsoever
[18:34:20 CEST] <BtbN> and the resolution and so on
[18:35:11 CEST] <nevcairiel> its a normal hwaccel in the future, it should implement checks like any ohter hwaccels
[18:35:45 CEST] <wm4> yeah, that seems lacking
[18:36:27 CEST] <BtbN> I'd not change the cherry-picked commit too much though. That stuff can be added later
[18:38:01 CEST] <wm4> is the change to dynamic loading within the cherry-pick commit still ok?
[18:38:12 CEST] <BtbN> Yeah, that's essential for it to work at all
[18:39:02 CEST] <BtbN> There's also a bunch of if-defery and configure checks for features tied to that. No point in dealing with that.
[18:40:31 CEST] <wm4> yes, it'd need to temporarily introduce full linking support
[18:45:38 CEST] <BtbN> changing the libav cherry-pick so much that it actually works seems fine enough. Additions like capability checks are ffmpeg patches on top of it.
[18:46:00 CEST] <BtbN> Also allows for them to be maybe merged back to libav if anyone cares.
[19:20:25 CEST] <ticktack> Hey! I am new to ffmpeg and want to work on some beginner stuff, any suggestion or any issue i can work on
[19:24:15 CEST] <JEEB> ticktack: start with compiling it, then think of what interests you within it or a problem that you can feel yourself
[19:24:31 CEST] <JEEB> usually if you yourself are affected it's better
[19:54:34 CEST] <Compn> doh he left
[20:12:48 CEST] <cone-404> ffmpeg 03Marton Balint 07master:ff6de6b180fd: Makefile: generate stripped CLI tools directly instead of copying unstripped ones first
[20:12:49 CEST] <cone-404> ffmpeg 03Devin Heitmueller 07master:278588cd0bf7: libavdevice/decklink: add support for -sources and -sinks arguments
[20:12:50 CEST] <cone-404> ffmpeg 03Devin Heitmueller 07master:77f7d710e086: libavdevice/decklink: add support for 10-bit output for Decklink SDI
[20:17:12 CEST] <jamrial> michaelni: it should now be fine to release 3.4
[20:34:44 CEST] <durandal_1707> cehoyos is very short sighted persona
[20:36:32 CEST] <BBB> now now now
[20:36:40 CEST] <BBB> lets remain nice
[22:21:19 CEST] <BBB> this helmut guy I suspect check_disable_warning has a bug very dry :D
[22:30:37 CEST] <wm4> isn't it that clang simply doesn't error out on unknown warnings and thus the check succeeds
[22:30:52 CEST] <wm4> so not really an error, just sabotage by the compiler devs
[22:34:18 CEST] <JEEB> yea I noticed the unknown options just got used :)
[22:57:25 CEST] <jkqxz> Is anyone reverting the second -Wno-bool-operation patch?  It seems pretty clear now that it's not acceptable with a lot of versions of clang (only apple ones?).
[23:02:05 CEST] <BBB> maybe adjust the compiler check so it catches the specific warning from clang also, and the flag is not inserted?
[23:02:15 CEST] <BBB> that seems the whole goal of that configure check
[23:02:35 CEST] <jkqxz> I do not have such a clang.  Do you?
[23:06:16 CEST] <BBB> $ gcc -Wno-bool-operation /dev/null -c -o /tmp/x.o && echo success
[23:06:17 CEST] <BBB> clang: warning: /dev/null: 'linker' input unused [-Wunused-command-line-argument]
[23:06:18 CEST] <BBB> clang: warning: argument unused during compilation: '-Wno-bool-operation' [-Wunused-command-line-argument]
[23:06:19 CEST] <BBB> success
[23:06:20 CEST] <BBB> ?
[23:07:10 CEST] <BBB> (Apple LLVM version 8.1.0 (clang-802.0.42))
[23:08:25 CEST] <BBB> $ gcc -Wno-bool-operation /dev/null -c -o /tmp/x.o -Werror=unused-command-line-argument && echo success
[23:08:25 CEST] <BBB> clang: error: /dev/null: 'linker' input unused [-Werror,-Wunused-command-line-argument]
[23:08:26 CEST] <BBB> but
[23:08:30 CEST] <BBB> $ gcc -Wno-bool-operation /tmp/x.c -c -o /tmp/x.o -Werror=unused-command-line-argument && echo success
[23:08:31 CEST] <BBB> warning: unknown warning option '-Wno-bool-operation'; did you mean '-Wno-bool-conversion'? [-Wunknown-warning-option]
[23:08:32 CEST] <BBB> 1 warning generated.
[23:08:33 CEST] <BBB> success
[23:08:37 CEST] <BBB> so thats not very useful
[23:12:32 CEST] <wbs> BBB: try -Werror=unknown-warning-option
[23:12:40 CEST] <JEEB> ah
[23:12:49 CEST] <BBB> woohoo
[23:12:58 CEST] <BBB> wbs: you are genious
[23:13:33 CEST] <wbs> (that particular behaviour in clang is rather annoying)
[23:13:53 CEST] <BBB> but why didnt the original message say that? (I admit I ignored the second message)
[23:14:15 CEST] <BBB> it sounds almost as if theyre using a state machine for error reporting
[23:20:13 CEST] <cone-629> ffmpeg 03Gyan Doshi 07master:d251effe7320: doc/filters: note minimum resolution for pixscope
[23:29:34 CEST] <cone-629> ffmpeg 03Marton Balint 07master:f280575a0fc9: configure: fix decklink dependencies
[23:39:56 CEST] <thebombzen> zimg supports sRGB transfer characteristics, but the zscale filter wrapper does not. Is this just an oversight? should I send a patch to add this feature?
[23:48:38 CEST] <wm4> ask durandal_1707, but most likely yes
[23:50:12 CEST] <thebombzen> turns out it would be easy to support, but you'd need to add SRGB to "enum AVColorTransferCharacteristic" in libavutil/pixfmt.h
[23:50:55 CEST] <thebombzen> the comment says "These values match the ones defined by ISO/IEC 23001-8_2013 § 7.2." so I'm not sure where or if it would be a good idea to add it immediately
[23:51:36 CEST] <jkqxz> Is the transfer you want actually the same as one of the others?
[23:52:59 CEST] <jkqxz> (If you don't feel like paying 158 swiss fracs for the standard, you may wish to know that it happens to be identical to ITU H.273.)
[23:53:29 CEST] <wm4> thebombzen: you could add it as value over 256 lol
[23:53:41 CEST] <wm4> because the bitstream field in h264/hevc is only 8 bit wide
[23:54:09 CEST] <wm4> most likely this would trigger a very unproductive bikeshed flamewar though
[00:00:00 CEST] --- Wed Oct 11 2017