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

[burek]

[00:12:37 CET] <cone-517> ffmpeg 03Andreas Rheinhardt 07master:6dafcb6fdb62: h264_redundant_pps: Fix logging context
[00:12:38 CET] <cone-517> ffmpeg 03Michael Niedermayer 07master:c305e134ce23: avcodec/imm4: Use ff_set_dimensions()
[02:13:30 CET] <cone-517> ffmpeg 03Jun Zhao 07master:81f2a9f136ca: fftools/ffmpeg: Remove the micor like "#if 1"
[02:13:31 CET] <cone-517> ffmpeg 03Jun Zhao 07master:3eccf5be9287: fftools/ffmpeg: Put the variable declaration at uppper for block.
[02:13:32 CET] <cone-517> ffmpeg 03Jun Zhao 07master:e24a754916be: fftools/ffmpeg: Indent the code
[12:23:06 CET] <BtbN> If I << a char, it will be auto promoted to an int, right? And not just shift out stuff after the first 8 bit?
[12:28:34 CET] <atomnuker> I'd cast it to make it obvious and be on the safe side
[12:45:55 CET] <thardin> I believe most/all artithmetic promote to at least int
[12:46:16 CET] <thardin> being explicity might be nice tho
[13:42:35 CET] <cone-542> ffmpeg 03Paul B Mahol 07master:8860d307311a: avfilter/vf_lut3d: ignore last whitespace when comparing LUT size string
[13:53:23 CET] <durandal_1707> what about replacing locale dependent functions that we use with native variants? so . is always used and not ,?
[13:59:33 CET] <atomnuker> yes, that would be awesome, lavu already replaces some so there can't be that many left
[15:08:38 CET] <durandal_1707> sscanf is not trivial to do
[15:12:22 CET] <atomnuker> yeah, seems so, wm4 wrote https://github.com/wm4/libinsanity and its strtod is complex and gplv3
[15:13:31 CET] <durandal_1707> that code is useless for us
[15:16:13 CET] <atomnuker> yeah, but you could rewrite parts of it to use in sscanf
[15:23:32 CET] <durandal_1707> atomnuker: why? i think about just using one of BSD implementations
[15:26:00 CET] <iive> what the license of musl?
[15:26:06 CET] <iive> what is...
[15:26:21 CET] <durandal_1707> AGPL+
[15:28:00 CET] <durandal_1707> MIT actually
[15:42:46 CET] <durandal_1707> are there other functions that handle . for floats differently?
[15:46:16 CET] <durandal_1707> also should i add new header lavfu/avstdio.h or put it into lavu/avstring.h ?
[15:49:42 CET] <durandal_1707> anyone dare to answer?
[15:50:04 CET] <atomnuker> I think this belongs in avstring.h
[15:50:07 CET] <BtbN> Can't ffmpeg just force the locale to C on startup or something?
[15:50:21 CET] <atomnuker> libraries shouldn't mess with locales
[15:50:38 CET] <BtbN> Was thinking more of the cli tool
[15:50:58 CET] <atomnuker> also the c.utf8 locale isn't available everywhere
[15:51:14 CET] <durandal_1707> its our mess, we need to fix it, and this is long issue
[15:51:19 CET] <JEEB> mpv got some weird PR regarding that which doesn't build on windows
[15:54:42 CET] <JEEB> durandal_1707: btw do you want to give any hints how a filter chain could be profiled? http://up-cat.net/p/e9f4a0cc
[15:56:12 CET] <durandal_1707> JEEB: profiled for what kind of issues?
[15:56:26 CET] <JEEB> blocking/slowness
[16:03:11 CET] <durandal_1707> JEEB: you could try to insert graphmonitor filter to see if something queues to much frames, and to see what is outputing frames at least rate, you will need to change your graph, and add second video output which you could encode to and watch immediately in separate process (no pipe, as that would block others)
[16:04:34 CET] <durandal_1707> do you work with files?
[16:05:05 CET] <JEEB> generally live input, although you can always dump the input into a file if a reproducible thing is required
[16:05:18 CET] <JEEB> although that might not repro it because the input can get new stuff right away
[16:06:10 CET] <durandal_1707> if that bug happens after parameters change midstream that is currently not supported generally by lavfi
[16:06:39 CET] <JEEB> I don't think that's the case
[16:07:57 CET] <durandal_1707> then slowest encoder may slow others
[16:11:36 CET] <JEEB> yea, I'll probably be able to give more info later next week, one of my hypotheses was that pre-framesync2 seemingly handled stuff better compared to the later versions. but I'll have to double-check that it isn't the sub2video patches I've posted on the ML fixing issues with overlays receiving premature EOS or ending up unscaled after a re-init
[16:13:21 CET] <JEEB> although it seemed to be there even during the first sub2video fix version (which didn't hit the premature EOS root reason properly)
[16:13:37 CET] <JEEB> and which went to master because it passed the single FATE test for it
[16:13:59 CET] <JEEB> (did I mention how much I ¤!%!& sub2video?)
[16:14:27 CET] <JEEB> it seems to be confusingly overcomplicated for a thing that's just supposed to provide overlay inputs
[16:15:59 CET] <durandal_1707> sometimes filter my just hang for whatever reason, usually at eof
[16:18:02 CET] <JEEB> well, EOF shouldn't be a problem. false EOS can happen with single filter chain and reconfig of say audio
[16:18:38 CET] <JEEB> but false EOS generally just results in overlay's secondary input stopping, but output seems to work
[16:18:46 CET] <JEEB> just that you stop getting subtitles overlayed
[17:33:07 CET] <jkqxz> jamrial:  Got a stream lying around with the alternative transfer characteristics message in?
[17:35:54 CET] <jamrial> no, but koda probably does. he's the one that added support to the decoder
[17:36:26 CET] <jamrial> you can look at it later in any case. no need to delay that patch just for it
[17:36:49 CET] <jkqxz> I've already written it (took two minutes).  Would be nice to test!
[17:36:57 CET] <jamrial> ah :p
[17:40:40 CET] <jkqxz> None of the conformance streams have it.
[17:44:05 CET] <durandal_1707> atomnuker: see my quick & dirty hack skills on ML - comments welcome
[17:46:34 CET] <durandal_1707> i copied parts of musl MIT code 
[17:47:23 CET] <jkqxz> FFFFFILE is a funny type name.
[17:48:45 CET] <cone-542> ffmpeg 03Mark Thompson 07master:fd1d735c0b98: fate/libavcodec: Fix config dependency of h264-levels test
[17:53:00 CET] <jamrial> jkqxz: it's a relatively recent addition for backwards compat. decoders compliant with and old spec will use the standard trc reported in the bitstream, new ones will look at the sei and use that instead
[17:53:17 CET] <jamrial> probably to support hdr videos on old decoders or such
[17:57:58 CET] <jamrial> jkqxz: x265 --atc-sei option generates one
[17:58:17 CET] <jamrial> not ideal, i guess
[18:00:21 CET] <jkqxz> I'm looking at some random HLG samples now.  (<https://4kmedia.org/travelxp-4k-hdr-hlg-sample/> lacks the SEI message, but it does kill Intel GPUs with VAAPI.  Oops.)
[18:02:01 CET] <JEEB> the travelxp sample I think has general corruption issues
[18:02:44 CET] <rcombs> jkqxz: have you seen dolby vision samples
[18:03:56 CET] <rcombs> they went and made up a color space
[18:03:57 CET] <jkqxz> Hmph.  That actually seems to have messed the GPU up pretty badly; I probably need to reboot to get it back.
[18:04:27 CET] <rcombs> wow
[18:04:32 CET] <nevcairiel> doesnt DV use ICtCp? That was added to the standards some time ago
[18:04:41 CET] <rcombs> nevcairiel: not quite
[18:04:46 CET] <jkqxz> rcombs:  Trying to avoid them.
[18:04:50 CET] <rcombs> it's something like ICtCp but not quite
[18:04:50 CET] <JEEB> nevcairiel: they adjust it. just adding base ICtCp support with BT.2020/PQ doesn't cut it
[18:05:01 CET] <rcombs> here have some samples https://dl.dropboxusercontent.com/s/bsgtnhnix56zutb/Aerial-vid-URLs.rar
[18:05:04 CET] <nevcairiel> of course DV is not PQ
[18:05:15 CET] <rcombs> we're pretty sure it's PQ
[18:05:22 CET] <JEEB> also we're specifically talking about profile 5
[18:05:28 CET] <JEEB> which is the backwards-incompatible one
[18:05:44 CET] <JEEB> and which uses a bastardization of PQ+ICtCp etc
[18:06:33 CET] <durandal_1707> what is that?
[18:06:41 CET] <rcombs> happy fun times https://gist.github.com/a8c91d940d4291120bb677eafc96e41d
[18:07:41 CET] <JEEB> ah, so that's the parser for the DOVIConfigurationBox
[18:07:47 CET] <nevcairiel> (note that the first part of the commit is technically wrong, a decoder should be capable of unsetting  those things)
[18:08:23 CET] <rcombs> nevcairiel: I'm not sure if it should in the "the bitstream doesn't have those values at all" case, though
[18:09:34 CET] <nevcairiel> where else, the decoder should keep the context up to date with what the bitstream says, and if it says unspecified, then it should set that
[18:09:36 CET] <rcombs> I've also been looking into this mostly just out of curiosity; the only files I've seen using it are random online demos/trailers, and those apple Aerial screensavers I just linked
[18:09:36 CET] Action: nevcairiel shrugs
[18:10:20 CET] <rcombs> well if the decoder overwrites with "unspecified" after the container set something, that leaves the consumer with no way to find out what the container said
[18:10:43 CET] <nevcairiel> or maybe there needs to be a proper api to separate that information
[18:10:50 CET] <nevcairiel> what if the  stream contains conflicting into
[18:10:50 CET] <rcombs> maybe
[18:10:54 CET] <nevcairiel> you still wont know
[18:11:01 CET] <rcombs> fair point, and I think one of apple's streams actually does that
[18:14:47 CET] <jkqxz> <https://4kmedia.org/lg-cymatic-jazz-hdr-hlg-uhd-4k-demo/> contains the message, but it also has broken AUDs so requires a bit of hacking to make CBS read it.
[18:16:21 CET] <jamrial> i have the hdr10 version of that video, and it doesn't have the sei
[18:17:14 CET] <jkqxz> HDR10 doesn't have the backward compatibility of HLG, so it would make less sense there.
[18:19:09 CET] <jkqxz> <https://0x0.st/slfp.txt>
[18:19:43 CET] <jkqxz> (With rbsp_stop_one_bit being zero in the AUDs.  Yay.)
[18:24:52 CET] <cone-542> ffmpeg 03Mark Thompson 07master:252e79663de8: cbs_h265: Add PTL parsing for sublayers
[18:26:50 CET] <jamrial> extract_extradata should probably also extract prefix sei messages i guess
[18:29:52 CET] <jkqxz> It only wants some message types, though.
[18:30:42 CET] <jkqxz> And maybe not necessarily all of the time if they they change through the stream, which they could do independently of the parameter sets.
[18:54:11 CET] <nevcairiel> SEI messages have a defined  lifetime, those with the highest one might make sense to extract
[19:17:12 CET] <durandal_1707> why: ffmpeg -i MUSIC_WITH_COVER -i ONLY_MUSIC -lavfi amix=inputs=2:duration=shortest -f null - stops when first video frame is encoded?
[20:24:37 CET] <cone-542> ffmpeg 03Andreas Rheinhardt 07master:6df9020f45ea: cbs_mpeg2: Improve performance of writing slices
[20:28:53 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/1c915dfc426512288559cd8f18cba382ec8d0216
[20:29:00 CET] <philipl> Common CHECK_CU implementation.
[20:35:53 CET] <cone-542> ffmpeg 03Marton Balint 07master:6c2a7a8e9a36: avfilter/vf_framerate: factorize SAD functions which compute SAD for a whole frame
[20:35:54 CET] <cone-542> ffmpeg 03Marton Balint 07master:7748f395de88: avfilter/vf_select: use common scene sad functions
[20:35:55 CET] <cone-542> ffmpeg 03Marton Balint 07master:936d18fb42bb: avfilter/vf_minterpolate: use common scene sad functions
[20:39:15 CET] <nevcairiel> philipl: public api for that makes me feel bad
[20:47:48 CET] <philipl> nevcairiel: alternative?
[20:50:21 CET] <jkqxz> nevcairiel:  +1
[20:50:36 CET] <jkqxz> philipl:  Include it in each library separately?
[20:51:30 CET] <philipl> Ok. It seems we need three copies. That's still less than eight I guess.
[20:54:10 CET] <philipl> Is there a legal way to share a single .c file between the various libs?
[20:55:42 CET] <jkqxz> #include
[20:56:23 CET] <philipl> I mean file placement...
[20:56:32 CET] <philipl> Do we do this anywhere today?
[20:56:47 CET] <wbs> there's a few cases, look at the various log2_tab.c
[20:56:52 CET] <JEEB> :)
[21:01:27 CET] <jamrial> avpriv?
[21:01:46 CET] <jamrial> also, what wbs said works as well
[21:07:38 CET] <cone-542> ffmpeg 03Martin Vignali 07master:0aba92d42d51: avcodec : add prores_metadata bsf for set the color property of each prores frame
[21:07:39 CET] <cone-542> ffmpeg 03Martin Vignali 07master:679ad3146972: fate/prores_metadata_bsf : add test for setting color property
[21:15:03 CET] <philipl> avpriv just means I change the prefix?
[21:15:09 CET] <philipl> That seems the easy option
[21:21:50 CET] <wbs> the problem with that is that even though it's supposed to be private, for shared libraries it more or less ends up as something that needs to be kept stable anyway, depending on how flexible linking setups you want to consider
[21:22:51 CET] <philipl> This would be stable in practice. We just don't want it to be part of the public API, right?
[21:24:04 CET] <philipl> But Ok, I see how I can reproduce what is done for log2_tab.c
[21:26:22 CET] <wbs> log2_tab.c is fine as long as the amount of data/code is small so adding a few bytes per library is easier than handling the symbol across dynamic linking boundaries (even though iirc such things should work fine even for msvc setups now)
[21:26:54 CET] <philipl> It's a single small function.
[21:37:40 CET] <cone-542> ffmpeg 03Paul B Mahol 07master:bdc66c50dd69: avfilter/af_afftfilt: extend filter functionality
[21:37:41 CET] <cone-542> ffmpeg 03Paul B Mahol 07master:d03030c07109: avfilter/af_afftfilt: add more window types
[21:44:26 CET] <cone-542> ffmpeg 03Martin Vignali 07master:752bf1f64c4c: fate/prores_metadata : fix md5 value
[21:44:35 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/be8f30cc355d553003d0cb9772f872d75296df75
[21:44:46 CET] <philipl> and everyone else who had opinions :-)
[21:45:12 CET] <BtbN> looks sensible to me on first glance
[22:13:49 CET] <JEEB> > Let me add that split filter derived sources seems to be also single threaded.
[22:14:00 CET] <JEEB> hmm, I wonder if that's correct
[22:22:03 CET] <durandal_1707> it is not correct for asplit and audio, same for video (didn't tested video)
[22:33:35 CET] <durandal_1707> but after split, slowest one will slow all others after split
[23:43:51 CET] <rcombs> nevcairiel: so apparently tls_schannel hard-fails if the OCSP service is down
[23:43:54 CET] <rcombs> any idea how to not
[23:44:21 CET] <rcombs> fails in InitializeSecurityContext
[23:51:23 CET] <nevcairiel> no clue
[00:00:00 CET] --- Mon Nov 12 2018