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

Thu Oct 3 03:05:04 EEST 2019

[00:12:32 CEST] <mkver> cehoyos: Why do you think that ticket #5937 is of minor importance?
[00:34:14 CEST] <cehoyos> It looks minor to me - not sure if I understand you?
[00:34:39 CEST] <cehoyos> A false warning is hardly a "real" bug, no?
[00:35:09 CEST] <BtbN> That looks more like a slightly corrupted but playable file to me
[00:35:21 CEST] <cehoyos> Even more so if a work-around exists for those who don't like the message
[00:35:35 CEST] <cehoyos> Why do you think so?
[00:36:07 CEST] <BtbN> Just from the message. Just needs a single bitflip to cause what it describes.
[00:36:15 CEST] <cehoyos> (The flac application has a test function to validate files)
[00:36:37 CEST] <cehoyos> I would expect a bitflip to have more effects than a warning message for a lossless format, no?
[00:36:47 CEST] <BtbN> Depends on where it occurs
[00:41:35 CEST] <BtbN> hm, unrelated, but I found this while looking at the code: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/flac_parser.c#L442
[00:41:53 CEST] <BtbN> passing AV_LOG_DEBUG to the log_level_offset parameter does not seem right
[00:43:00 CEST] <BtbN> But yeah, the code path does not look like it's hitting any unepxected code path. It's just informing about it.
[00:43:06 CEST] <BtbN> -path
[00:45:23 CEST] <mkver> This is not just a bogus warning. Some packets are somehow omitted; so decoding is not lossless and streamcopy doesn't work correctly either.
[00:45:43 CEST] <cehoyos> What do you mean with "decoding is not lossless"?
[00:45:57 CEST] <cehoyos> And "streamcopy doesn't work correcly either"?
[00:46:06 CEST] <cehoyos> Or to say it differently: Which sample are you testing?
[00:46:48 CEST] <mkver> This one: https://trac.ffmpeg.org/ticket/5937#comment:4
[00:47:24 CEST] <mkver> Somehow the parser omits some packets, so that both decoding as well as streamcopy doesn't work as it should.
[00:47:26 CEST] <cehoyos> But the sample for ticket 5937 is in http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket5937/
[00:47:42 CEST] <cehoyos> I don't think high-jacking tickets should be encouraged.
[00:48:16 CEST] <cehoyos> This regression is of course (very) important but it's not what was reported.
[00:53:44 CEST] <cehoyos> I will open a new ticket tomorrow.
[05:23:20 CEST] <wbs> jamrial: yes, I'm subscribed
[07:40:08 CEST] <rcombs> jkqxz: tracking down a weird VAAPI H264 encoder quality issue and it seems to have regressed in 2562dd9e7831743ba6dc5680501fb7d26a2ec62c, but simply reverting that commit on current master doesn't resolve it
[07:41:28 CEST] <rcombs> seeing it with resolution 854x480 and params -b 2757k -maxrate 3676k -bufsize 7352k
[07:41:57 CEST] <rcombs> the first [decent chunk, maybe to the first scenecut?] of the video ends up severely bitstarved and looks like garbage
[07:42:07 CEST] <rcombs> and then after that it behaves more or less normally
[07:42:27 CEST] <rcombs> erm, not first scenecut actually& hard to say exactly what the trigger is
[08:42:15 CEST] <rcombs> looks like it happens if either of af532c921575eb8ee805cc2c64a914f6302442e1 or 2562dd9e7831743ba6dc5680501fb7d26a2ec62c is applied
[08:46:45 CEST] <nevcairiel> i saw reports like that, are you on master?
[08:48:53 CEST] <nevcairiel> There is for example this https://patchwork.ffmpeg.org/patch/14454/ which was deemed a driver bug
[08:49:48 CEST] <nevcairiel> (also https://patchwork.ffmpeg.org/patch/14453/)
[08:54:20 CEST] <rcombs> looks to be related to ctx->va_bit_rate being replaced with avctx->bit_rate
[08:54:36 CEST] <rcombs> goes away if I revert that bit in vaapi_encode_h264.c (and 2562dd9e7831743ba6dc5680501fb7d26a2ec62c)
[08:56:08 CEST] <rcombs> yeah looks like it's probably that
[08:56:11 CEST] <rcombs> cc: tmm1 
[08:57:07 CEST] <rcombs> >It could be reproduced when mpeg2_vaapi decode was involved in the transcode pipeline.
[08:57:07 CEST] <rcombs>  👍 1
[08:57:07 CEST] <rcombs>  
[08:57:09 CEST] <rcombs> huh wow
[08:57:22 CEST] <rcombs> I am indeed using mpeg2 here, but I'd assumed that was irrelevant
[08:57:25 CEST] <rcombs> because, y'know
[08:57:26 CEST] <rcombs> sanity
[08:57:28 CEST] <JEEB> :)
[08:57:42 CEST] <JEEB> I remember one random Japanese fork having something regarding MPEG-2 video decoding
[08:57:46 CEST] <JEEB> via vaapi
[08:58:08 CEST] <rcombs> wonder if it'd go away if I scaled by like 2px
[08:58:18 CEST] <JEEB> https://github.com/0p1pp1/FFmpeg/commit/b049b2f232a15d92563ceb9f3bf7f36a8302e21e https://github.com/0p1pp1/FFmpeg/commit/67306b7beaa5dd59ce44af786efb2df95895483a
[08:58:26 CEST] <JEEB> can't say anything regarding these two
[08:58:43 CEST] <JEEB> just remember noticing them when looking through this fork
[08:59:18 CEST] <rcombs> ¯\_(Ä)_/¯ I can try 'em and see if they make a difference for kicks
[09:00:54 CEST] <JEEB> probably won't, but (´4@) indeed
[09:02:17 CEST] <rcombs> INTEL
[09:03:32 CEST] <rcombs> nope
[09:14:29 CEST] <rcombs> so it seems like (a) the rate control is getting reset a lot for no reason, and (b) the ratecontrol _sucks_ after a reset
[09:16:43 CEST] <JEEB> yea
[09:53:54 CEST] <rcombs> hmm, except it's not actually getting reset constantly
[09:55:33 CEST] <rcombs> looks to me like the effect of tmm1's patches (or mine) is actually to force an extra reset on the second keyframe
[09:55:56 CEST] <JEEB> vOv
[09:56:12 CEST] <JEEB> that would kind of explain the effect
[10:03:08 CEST] <rcombs> if you reset constantly, shit's bad, and if you only reset on the first frame, shit's bad
[10:03:22 CEST] <rcombs> but if you reset on the second keyframe then only the first GoP's bad
[10:03:30 CEST] <rcombs> now& why
[10:56:39 CEST] <cone-589> ffmpeg 03Paul B Mahol 07master:9847380f5f5a: avfilter/vf_elbg: stop leaking frame on error
[10:59:36 CEST] <JEEB> michaelni: btw what is your opinion on back-porting of fixes? I've heard the opinion that only regressions should be fixed in release branches, which would not (in my meaning of regressions, which are limited to our code) encompass f.ex. bad usage of GnuTLS APIs which depend on how the other side is configured
[11:00:46 CEST] <JEEB> f.ex. "connections to nice_streaming_service.org used to work, but after they changed their TLS config it no longer works" would not technically be a regression on our side (since the code was always broken), but it is a regression for the user
[11:01:29 CEST] <nevcairiel> imho clear-cut bugfixes should also be backported, the regression "rule" only comes from one person :p
[11:01:36 CEST] <michaelni> JEEB, regression and bugfixes should be ok assuming there is nothing odd on the backported patch
[11:02:22 CEST] <JEEB> nevcairiel: that was my understanding as well for the "regressions only" opinion
[11:02:28 CEST] <JEEB> just wanted another senior opinion on it :P
[12:40:33 CEST] <rcombs> so, the key thing is calling gen9_avc_kernel_brc_init_reset an extra time
[12:40:38 CEST] <rcombs> even doing it on the second frame works
[12:40:55 CEST] <rcombs> (just doing it twice in a row doesn't, though)
[12:41:13 CEST] <rcombs> (even if you make it a GEN9_AVC_KERNEL_BRC_RESET)
[12:41:33 CEST] <JEEB> :D
[12:47:18 CEST] <BtbN> https://gitlab.com/esr/gif2png/commit/a8a761561b2a071e7452a00868efd5bdf795c443 well that's one way to deal with "meaningless fuzzer attacks"
[12:53:30 CEST] <durandal_1707> haha
[12:55:36 CEST] <thardin> lol
[13:00:35 CEST] <thardin> is the go version just piggybacking off the name?
[13:01:14 CEST] <rcombs> specifically, resetting immediately after the gen9_avc_kernel_brc_frame_update on the first frame works
[13:01:19 CEST] <rcombs> but I have absolutely no idea why
[13:02:27 CEST] <rcombs> jkqxz: ^ you know more about the driver internals than me, any ideas? this is all in src/i965_avc_encoder.c
[15:29:54 CEST] <cone-955> ffmpeg 03Michael Niedermayer 07master:9c84c162e9f9: avcodec/g2meet: Check if adjusted pixel was on the stack
[15:29:55 CEST] <cone-955> ffmpeg 03Michael Niedermayer 07master:61dd2e07be7c: avcodec/g2meet: Check for end of input in jpg_decode_block()
[17:48:53 CEST] <nevcairiel> jamrial: i revived my fate box, do you have any idea why the fitsdec stuff fails on mingw gcc 32-bit?
[17:50:02 CEST] <nevcairiel> although the box feels rather slow after the migraiton, might need to set it up fresh
[17:51:45 CEST] <jamrial> nevcairiel: not sure, but i recall fuzzing found issues in some float calculations in it
[18:07:09 CEST] <nevcairiel> its odd, mingw-gcc is usually not the one to produce mismatches in float
[18:18:50 CEST] <jamrial> nevcairiel: the odd thing is having bitexact fate tests for a decoder using floats
[18:19:29 CEST] <nevcairiel> we do that for float audio decoders as well, dont we
[18:19:40 CEST] <jamrial> like, michaelni's patch to fix some NaN -> int issue changed the checksums because lrint by default rounds in a different way
[18:20:41 CEST] <jamrial> float decoders use tiny_psnr
[18:21:09 CEST] <jamrial> i don't think any such fate test use framecrc
[18:23:24 CEST] <Lynne> *af_
[18:23:31 CEST] <jamrial> nevcairiel: as expected, using -msse2 -mfpmath=sse fixes the fate failure on mingw32
[18:23:53 CEST] <JEEB> \o/
[18:23:59 CEST] <JEEB> so 64bit just uses SSE2 by default
[18:24:10 CEST] <jamrial> yeah
[18:24:47 CEST] <nevcairiel> i actually build my own binaries with those flags, but fate doesnt use them
[18:24:51 CEST] <jamrial> the fits tests should be replaced. i don't know if we have other float video decoders and how they are tested
[18:27:04 CEST] <jamrial> fate doesn't even use --cpu on x86_32 during configure, meaning some build defines are disabled, like fast_cmov and cpunop
[18:27:34 CEST] <durandal_1707> x86_32 is dead
[18:28:28 CEST] <jamrial> if only
[18:28:33 CEST] <JEEB> ^
[18:29:01 CEST] <durandal_1707> yes, it is dead already, now do something else...
[18:29:12 CEST] <nevcairiel> i suppose i could add --cpu to the fate line there
[18:29:25 CEST] <jamrial> it may be dead, but it's making fate yellow, so it needs to be dealt with :p
[18:30:10 CEST] <nevcairiel> hm the fate config file includes cpu=i686, does that not get forwarded properly
[18:30:11 CEST] <durandal_1707> fate - old machines not running any tests for months
[18:30:40 CEST] <nevcairiel> most of those "old" entries are for release branches, which makes for a terrible overview
[18:30:44 CEST] <jamrial> nevcairiel: -mfpmath=sse is not implied by any -march value on x86_32, afaik, so --cpu alone is not enough
[18:30:52 CEST] <nevcairiel> why was the fatebeta thing never finished
[18:30:54 CEST] <jamrial> you need to add it with --extra-cflags or so
[18:31:14 CEST] <nevcairiel> i didnt want to enable sse math as such, just i686 mode for cmov etc
[18:31:27 CEST] <nevcairiel> oh but that is actually enabled
[18:32:04 CEST] <jamrial> without sse fp math the fits failure will remain, though
[18:32:16 CEST] <nevcairiel> good reminder to fix the test! :p
[18:32:30 CEST] <nevcairiel> i'm surprised none of the other weirdo systems errored on it
[18:32:42 CEST] <nevcairiel> some always seemed more prone to errors on float
[18:33:47 CEST] <nevcairiel> i wonder why fate takes sooo long on this new host for the VM
[18:34:29 CEST] <jamrial> intel/amd virtualization stuff disabled in the bios?
[18:35:26 CEST] <nevcairiel> i dont think so, but i can check later
[18:36:47 CEST] <nevcairiel> the host OS says its on
[18:38:14 CEST] <nevcairiel> oh well i'll poke it more later
[18:38:30 CEST] <nevcairiel> at least it runs again for the time being
[19:06:14 CEST] <durandal_1707> cehoyos: hardware filters are useless, repeat that until you learn it
[19:32:44 CEST] <cehoyos> I hope I didn't write that, or is that not your point?
[21:07:47 CEST] <cone-522> ffmpeg 03Paul B Mahol 07master:2a546fb7d572: avfilter/setpts: switch to activate
[21:19:21 CEST] <cehoyos> durandal_1707: Which sample gets fixed by the amr patch?
[21:20:26 CEST] <durandal_1707> cehoyos: https://0x0.st/zwrr.bin
[21:24:37 CEST] <cehoyos> Valid files are allowed to contain 0, even "00 00"
[21:25:55 CEST] <durandal_1707> cehoyos: give  such  files
[21:39:17 CEST] <rcombs> hmmmmmmmmm
[21:39:32 CEST] <rcombs> so I guess this only happens on Gen9, maybe Gen8
[21:39:48 CEST] <rcombs> in either case, only devices that support the iHD driver
[21:39:57 CEST] <rcombs> so I can probably get away with just switching to that for those
[21:43:33 CEST] <cehoyos> Did you try to encode any source?
[21:43:38 CEST] <cehoyos> How do I upload to 0x0?
[21:44:29 CEST] <cehoyos> http://0x0.st/zwsc.amr
[21:44:37 CEST] <cehoyos> http://0x0.st/zwsT.amr
[21:47:58 CEST] <durandal_1707> cehoyos: both files are not raw amr
[21:51:10 CEST] <cehoyos> http://0x0.st/zwsM.bin
[21:51:17 CEST] <cehoyos> http://0x0.st/zwsu.bin
[21:51:23 CEST] <cehoyos> Sorry
[22:27:52 CEST] <durandal_1707> cehoyos: bunch of zeros decodes to unpleasant noise
[22:28:17 CEST] <cehoyos> True. But it does decode
[22:28:26 CEST] <cehoyos> And zeros per-se are not invalid
[22:28:39 CEST] <cehoyos> I just sent another suggestion that would fix your sample.
[22:28:59 CEST] <cehoyos> Sorry: An idea for another solution
[22:29:13 CEST] <cehoyos> That I'll implement if you like the idea.
[22:29:58 CEST] <durandal_1707> encode few seconds of noise and silence and compare
[23:10:29 CEST] <cehoyos> For libopencore_amrnb, the result looks quite similar to your file;-(
[23:10:44 CEST] <cehoyos> (amrwb encodes silence to a file with all modes)
[00:00:01 CEST] --- Thu Oct  3 2019