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

[burek]

[00:20:02 CEST] <michaelni> atomnuker, have you looked at the  gaplessenc-pcm-to-mov-aa failure ?
[00:20:20 CEST] <michaelni> gaplessenc-pcm-to-mov-aac
[00:23:06 CEST] <michaelni> also aac-fixed-al_sbr_hq_cm_48_2 and others fail on arm
[00:26:46 CEST] <atomnuker> I did actually, it was the PNS system doing something weird again
[00:27:13 CEST] <atomnuker> I didn't have time to find a fix yet though
[00:27:59 CEST] <michaelni> ok, but the number of fate and aac issues is growing and these things must be dealt with
[00:30:28 CEST] <atomnuker> clipping the quantization value might work as a temporary workaround
[00:30:50 CEST] <atomnuker> will give that a try
[00:32:13 CEST] <michaelni> atomnuker, thx, btw, if there are crashes which you cannot reproduce (i think i rememer something like that, not sure which ticket it was) it might help to avoid all uninitialized memory that could make aacenc take more similar codepaths on user & devel system
[00:34:33 CEST] <atomnuker> I think that was a long time ago and got fixed by Claudio's fixes, haven't had unreporoducable bugs
[00:36:23 CEST] <michaelni> hmm, ok then should these be closed ? http://trac.ffmpeg.org/ticket/4943  http://trac.ffmpeg.org/ticket/4942
[01:40:43 CEST] <atomnuker> av_clip_uintp2(something, 8) should be equivalent to av_clip(something, 0, 256), right?
[01:48:59 CEST] <mark4o> atomnuker: av_clip(something, 0, 255)
[01:50:05 CEST] <jamrial> atomnuker: for that just use av_clip_uint8(something)
[01:51:35 CEST] <atomnuker> I ask because I think clang miscompiles av_clip_uintp2 and causes that fate test to fail
[01:54:01 CEST] <jamrial> replace it with uint8 then. worth trying and it's technically the "more correct" choice as well
[01:55:20 CEST] <atomnuker> acutally it's av_clip_uintp2(something, 13) so av_clip(something, 0, (1 << 13) - 1) seems more appropriate
[02:06:02 CEST] <cone-507> ffmpeg 03Rostislav Pehlivanov 07master:c0918613a0ec: aacenc: use av_clip() instead of av_clip() during quantization
[02:06:44 CEST] <atomnuker> michaelni: should be fixed now
[02:07:35 CEST] <ubitux> wtf
[02:07:51 CEST] <mark4o> av_clip_uintp2_c does look buggy for the case where a == INT_MIN
[02:09:23 CEST] <michaelni> didnt the INT_MIN occur due to a float -> int overflow? 
[02:12:20 CEST] <michaelni> casting out of range float to int is undefined behavior, anything can happen it can fail in any way on any system with any random pattern
[02:13:53 CEST] <michaelni> iff the huge float is correct and intended then the cliping must be done before converting to int
[02:14:12 CEST] <michaelni> no idea if the float value is correct or not i dont know the code
[02:14:44 CEST] <michaelni> atomnuker, ^#
[02:14:48 CEST] <michaelni> s/#//
[02:17:16 CEST] <atomnuker> the float value might definitely be out of range, and it could happen in any code which touches the spectral coefficients
[02:17:37 CEST] <atomnuker> Claudio agreed this would work as a quick fix to find out which one it is
[02:18:53 CEST] <atomnuker> though that still doesn't explain why the quantization index is out of range
[02:22:08 CEST] <michaelni> so its now not only wrong but covered up ?
[02:23:00 CEST] <michaelni> undefined behavior is not ok and is not safe
[02:23:22 CEST] <michaelni> this very easily can crash on some platforms
[02:23:30 CEST] <atomnuker> still not sure where the issue happens, but the overflow definitely happens in -a >> 31 & ((1<<p) - 1)
[02:23:36 CEST] <atomnuker> which is after the float to int conversion
[02:23:58 CEST] <michaelni> if float is out of range there is no after the cast
[02:24:21 CEST] <michaelni> "after the cast" is like the end of the universe for the program if the cast is undefined beavior
[02:25:36 CEST] <michaelni> "-a" is bad if a is INT_MIN but if we end at INT_MIN because float is outside INT_MIN .. INT_MAX then "-a" is after the problem
[02:25:55 CEST] <atomnuker> so you think it's best to do the float to int coast separately
[02:26:15 CEST] <atomnuker> s/coast/cast
[02:29:41 CEST] <michaelni> 6.3.1.4 Real floating and integer: When a finite value of real floating type is converted to an integer type other than _Bool,the fractional part is discarded (i.e., the value is truncated toward zero). If the value of the integral part cannot be represented by the integer type, the behavior is undefined.)
[02:31:00 CEST] <michaelni> <-- Thus implicitly or explicitly casting a float value that has a integral part outside INT_MIN..INT_MAX to a int is a bug
[02:31:10 CEST] <michaelni> also for example even if that value is not used 
[02:32:24 CEST] <michaelni> clang has every right to give a negative value to a too large positive float, or terminating the program or calling the ghost busters
[02:32:43 CEST] <atomnuker> fair enough, it's a bug
[02:35:01 CEST] <atomnuker> for now it's covered up until we can find why it happens to keep FATE happy
[03:00:44 CEST] <michaelni> atomnuker, ffmpeg now fails with gcc too "Assertion n <= 31 && value < (1U << n) failed at libavcodec/put_bits.h:157"
[03:01:19 CEST] <michaelni> i suggest to revert this patch
[03:29:45 CEST] <atomnuker> odd, I did test it with assert level 2
[03:29:48 CEST] <atomnuker> I'll revert it
[03:33:04 CEST] <cone-507> ffmpeg 03Rostislav Pehlivanov 07master:7cda7683a547: Revert "doc/filters: remove false claim in sofalizer description"
[03:33:05 CEST] <cone-507> ffmpeg 03Rostislav Pehlivanov 07master:02172d93f6b2: Revert "aacenc: use av_clip() instead of av_clip() during quantization"
[03:33:57 CEST] <atomnuker> GODDAMNIT IT
[03:34:05 CEST] <atomnuker> *GIT
[03:34:42 CEST] <atomnuker> sorry durandal... he's not here
[03:36:22 CEST] <cone-507> ffmpeg 03Paul B Mahol 07master:974734c98ce4: doc/filters: remove false claim in sofalizer description
[03:37:49 CEST] <michaelni> ill post a patch that works around the undefined behavior
[03:38:04 CEST] <michaelni> but fixing it is for someone who knows aac
[03:38:14 CEST] <atomnuker> I'll get to the bottom of this bug, it's definitely in the coder
[03:38:58 CEST] <atomnuker> 600+ lines of code for a single continuous function can't lack a few
[03:39:52 CEST] <atomnuker> but I made a large enough mess today to know when to give up and sleep
[03:40:45 CEST] <michaelni> atomnuker, also theres somethig else odd coef is cliped to 0.. but 0..15 seem to be faulty in the following put_bits due to them ending in negative values in shifts
[03:41:04 CEST] <michaelni> or negative value in put_bits and
[03:41:42 CEST] <michaelni> is the puts_sbits intended to store only positive values?
[03:41:55 CEST] <atomnuker> also I do remember reading somewhere that put_bits for 0 bits isn't very correct
[03:42:05 CEST] <michaelni> yes
[03:43:28 CEST] <michaelni> the code smells a bit like the sbits is intended to get a coeff that can be also negative but the code passes one cliped to 0..1<<13 IIUC
[03:43:56 CEST] <michaelni> anyway, ill post my patch and the go to sleep too :)
[03:44:06 CEST] <atomnuker> definitely odd, I'll check what the specs say about BT_ESC
[03:46:07 CEST] <michaelni> yes please do
[03:46:40 CEST] <michaelni> after sleeping that is, sleep is important if you are tired :)
[04:01:33 CEST] <TheRyuu> michaelni: responded to that mingw-w64 gdb thing and sent in a patch
[04:21:35 CEST] <Zeranoe> Interestingly the MFX/QSV hang does not happen when using Intel's "sample_encode" program. It must be in the way FFmpeg is implementing it.
[04:28:15 CEST] <cone-507> ffmpeg 03Michael Niedermayer 07master:c7b983249aa4: tests/audiomatch: also print signal vs reference length
[04:28:16 CEST] <cone-507> ffmpeg 03Michael Niedermayer 07master:b3ec5b00ce6e: tests/audiomatch: Reduce search window
[11:25:07 CEST] <BtbN> Do these HEVC AUDs have any negative effects, or why do they have to be explicitly enabled if some (shitty?) players need them?
[11:25:57 CEST] <kierank> AUDs make it *much* easier to parse frames
[11:26:07 CEST] <kierank> parse pictures to be more precise
[11:26:13 CEST] <kierank> it's mandatory in mpeg-ts for example
[11:26:25 CEST] <Mavrik> Not sure about HEVC, but I've seen bunch of players choke and die on AUD streams.
[11:26:30 CEST] <Mavrik> iOS 7 was one of those.
[11:26:35 CEST] <nevcairiel> containers like mkv and mp4 usually dont have them, but in my experience it usually also has never broken anything if its present
[11:26:37 CEST] <Mavrik> H.264 that is.
[11:26:53 CEST] <Mavrik> I'd guess HEVC decoders have that fixed by now.
[11:26:59 CEST] <BtbN> So just hardcoding them to enabled shouldn't be an issue?
[11:27:17 CEST] <nevcairiel> does nvenc differentiate between generating mp4-style and annexb?
[11:27:26 CEST] <BtbN> Not that I'm aware of.
[11:27:32 CEST] <nevcairiel> if yes, do it with annexb only, imho, if not, just turn it on
[11:28:20 CEST] <nevcairiel> BtbN: usually thats controlled by the global_header flag
[11:29:14 CEST] <nevcairiel> but it shouldnt really harm anything to generate them always
[11:30:47 CEST] <BtbN> "if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {" ?
[11:31:53 CEST] <BtbN> that's translated to disableSPSPPS/repeatSPSPPS. And if disabled, the extradata is copied to a buffer once at startup
[11:34:54 CEST] <BtbN> I don't think this controls how NVENC writes its NAL stuff, that's probably allways Annex B I'd assume.
[11:56:13 CEST] <Guest76821> Hi there. Recently I sent a test but Michael says it's hard to keep updated. He is right.  The test is for alphaless_fmt() function, it basically a function with a switch and a lot of cases. I have no idea how to do a good test for this. Any idea?
[11:58:39 CEST] <petrurares> In the old test I did the following code for each case:
[11:58:53 CEST] <petrurares> result = alphaless_fmt(AV_PIX_FMT_ARGB) == AV_PIX_FMT_RGB24;
[11:58:54 CEST] <petrurares> printf("AV_PIX_FMT_ARGB == AV_PIX_FMT_RGB24 ? %d\n", result);
[11:59:46 CEST] <wm4> I question the need for such fine grained tests, they probably cause more trouble than they help
[12:00:19 CEST] <wm4> and often higher level tests will be better, e.g. it might be better to just test libswscale output with various alpha and non-alpha pixfmts
[12:01:36 CEST] <petrurares> ok, surely that is better
[12:06:08 CEST] <BtbN> hm, can't see anything breaking with enabled AUD.
[12:07:53 CEST] <cone-303> ffmpeg 03Timo Rothenpieler 07master:b3557c79dcd8: avcodec/nvenc: Generate AUD NAL units for better compatiblity
[12:08:39 CEST] <wm4> nevcairiel: do you have a sample for the flv metadata case that the not-merged libav commit supposedly broke?
[15:04:49 CEST] <cone-303> ffmpeg 03Claudio Freire 07master:c883da6bf461: AAC encoder: fix signed integer overflow
[15:52:21 CEST] <kierank> Gramner: is there a way of doing >> 0 with pmulhuw
[15:55:42 CEST] <Gramner> maybe not
[15:57:06 CEST] <kierank> I think we can do it with PMULHRSW
[15:57:08 CEST] <Gramner> pmulhrsw shoule be able to, but only your input is less than 0x0200 or something like that
[15:58:14 CEST] <Gramner> because a real no-op would require an src of 0x8000, but that's a negative number so you'll end up multiplying by -1 instead of 1
[15:58:56 CEST] <Gramner> 0x7fff works, but only if the other value isn't too large
[15:59:06 CEST] <ubitux> Daemon404: ea9317b8 fixes fate-sub-cc btw
[15:59:12 CEST] <kierank> Gramner: I think that's what x264 v210 does
[15:59:15 CEST] <Gramner> 0x2000 is probably the limit actually
[15:59:54 CEST] <Gramner> yes. x264 also does this fun thing where I merged the vpermd indices in the pmulhrsw mask, because it's evil and why not
[16:00:25 CEST] <Gramner> thing about the cache savings!
[16:01:03 CEST] <kierank> we don't have avx2 yet
[16:01:07 CEST] <kierank> lane problems
[16:01:28 CEST] <kierank> but I guess we should add it later
[16:03:06 CEST] <Gramner> dug up my pmulhrsw notes. 0x7fff is equal to *1 iff the input is 0x4000 or less
[16:05:35 CEST] <Gramner> note that I think using pmulhrsw for variable right-shift requires the msb of the bits to be shifted out to be zero
[16:05:57 CEST] <Gramner> unless you want rounding
[16:09:58 CEST] <kierank> we can move our mask to before the shuffle though to avoid that
[16:14:31 CEST] <j-b> 'morning
[16:16:26 CEST] <durandal_170> good afternoon
[16:17:22 CEST] <wm4> Daemon404, nevcairiel: I think the h264-conformance failures are only due to timestamp crap in ffmpeg.c? both decode the same number of frames with the same contents, so I don't see how it has to do with has_b_frames
[16:17:33 CEST] <wm4> but the way how ffmpeg.c does timestamps is a mystery to me
[16:18:11 CEST] <nevcairiel> dont they change DTS only? that smells like a change in codec delay to me
[16:18:36 CEST] <nevcairiel> in any case, that property s hould be exported anyway
[16:19:05 CEST] <wm4> well according to ffprobe, those samples don't have timestamps at all
[16:19:20 CEST] <wm4> but I remember now that ffmpeg.c actually changes the dts packet timestamps to something made up
[16:19:22 CEST] <wm4> (blergh)
[16:19:22 CEST] <nevcairiel> they are raw files, of course they dont
[16:19:33 CEST] <nevcairiel> but something generated timestamps before
[16:19:38 CEST] <nevcairiel> probably from codec timebase
[16:20:32 CEST] <nevcairiel> since h264 actually carries some sort of timing information, that can allow you to generate proper pts/dts .. if that information is present
[16:28:14 CEST] <Daemon404> ubitux, \o/
[16:28:28 CEST] <Daemon404> wm4, i fixed one thing with raw h264 timestamps already
[16:28:30 CEST] <ubitux> Daemon404: so basically it doesn't need my commits
[16:28:30 CEST] <Daemon404> it was in rawdec
[16:28:49 CEST] <ubitux> Daemon404: because we can now use avctx->time_base...
[16:29:03 CEST] <Daemon404> ubitux, update codecpar branch as necessary pls
[16:29:21 CEST] <ubitux> well, as i said, it doesn't need to
[16:29:26 CEST] <ubitux> your commit fixes it
[16:29:28 CEST] <Daemon404> nevcairiel, yes but i addressed this in the other fix to rawdec
[16:29:32 CEST] <Daemon404> ubitux, ok
[16:31:03 CEST] <Daemon404> ubitux, ea9317b8 should be cherry picked?
[16:31:24 CEST] <ubitux> ea9317b8 is in codecpar, it's your commit
[16:31:31 CEST] <Daemon404> >hashes
[16:31:55 CEST] <Daemon404> O_o
[16:32:00 CEST] <Daemon404> updating a different fate test fixes it?
[16:32:11 CEST] <ubitux> well you are setting avctx->time_base
[16:32:20 CEST] <ubitux> so now the timing computation works again :p
[16:32:27 CEST] <Daemon404> oh... wtf github
[16:32:31 CEST] <Daemon404> was looking at wrong one
[16:33:12 CEST] <ubitux> i don't understand the commented av_codec_set_pkt_timebase in that commit though
[16:33:25 CEST] <Daemon404> i fixed that in the next one
[16:33:29 CEST] <Daemon404> it was accidental debug comments
[16:33:57 CEST] <ubitux> ah, missed that
[16:36:23 CEST] <Daemon404> wm4, what exactly changes in teh h264 conformance tests?
[16:36:35 CEST] <Daemon404> i fixed it gettign no timestamps, iirc
[16:37:07 CEST] <wm4> Daemon404: timestamps increase in steps of 2 instead of 1
[16:37:22 CEST] <Daemon404> but same timebase?
[16:40:04 CEST] <wm4> AFAIR yes
[16:40:39 CEST] <Daemon404> ic
[16:45:43 CEST] <Daemon404> wm4, [framecrc @ 0x3906900] Encoder did not produce proper pts, making some up.
[16:45:47 CEST] <Daemon404> did you see this
[16:45:54 CEST] <Daemon404> or is tha texpected
[16:46:29 CEST] <Daemon404> nope looks like it is
[16:46:32 CEST] <wm4> yes I see this too
[16:46:36 CEST] <wm4> on the pmp test too
[16:46:39 CEST] <wm4> whatever the fuck it means
[16:47:24 CEST] <Daemon404> //XXX/FIXME this is a temporary hack until all encoders output pts
[16:47:26 CEST] <Daemon404> nice
[16:47:36 CEST] <wm4> how many years?
[16:47:52 CEST] <nevcairiel> encoders generally do
[16:47:59 CEST] <Daemon404> too lazy to look
[16:48:09 CEST] <Daemon404> i need to trol through refactorings
[16:48:25 CEST] <nevcairiel> the problem starts when you use rawvideo which just copies input timestamps, which have no guarantees =p
[16:49:43 CEST] <Daemon404> pkt->pts = st->priv_pts->val;
[16:49:48 CEST] <Daemon404> ok so its likely from init_pts
[16:49:59 CEST] <Daemon404> which had that weird thing
[16:50:54 CEST] <Daemon404> i have an idea
[16:51:54 CEST] <Daemon404> fixed it.
[16:52:03 CEST] <Daemon404> just runnign fate
[16:52:14 CEST] <Daemon404> ah... only most were fixed
[16:56:08 CEST] <Daemon404> hmmmm
[16:56:14 CEST] <Daemon404> so one of teh h264 tests fails with hash changes
[16:56:14 CEST] <Daemon404> wtf
[16:56:48 CEST] <kierank> Gramner: is  there an algorithm for generating the shifts with PMULHRSW 
[16:57:04 CEST] <Daemon404> wm4, fix pushed for most of the h264 tests
[16:58:00 CEST] <Daemon404> pmp still is iffy too
[16:58:02 CEST] <wm4> apparently you understand this code
[16:58:24 CEST] <Daemon404> wm4, yeah but the next h264 failures arent timestamps
[16:58:37 CEST] <kierank> Gramner: ah it uses the lowest bit
[16:58:46 CEST] <kierank> ignores the lowest bit
[16:59:01 CEST] <wm4> is multiplying these time bases a cheap way to get a common denominator or so?
[17:00:27 CEST] <Daemon404> it seems like its just a hack to try and find a "good" value to increment by and start at
[17:00:53 CEST] <Daemon404> nothing is particularily correct in the old or new one.
[17:02:16 CEST] <Daemon404> -0,          1,          1,        1,    38016, 0xb6261cdd
[17:02:16 CEST] <Daemon404> +0,          1,          1,        1,    38016, 0xfcd6aec1
[17:02:21 CEST] <Daemon404> this sort of stfuf is disturbing
[17:02:33 CEST] <Daemon404> (on e.g. fate-h264-conformance-caba3_sony_c)
[17:03:58 CEST] <Daemon404> [h264 @ 0x2d4d1a0] Increasing reorder buffer to 1
[17:03:58 CEST] <Daemon404> [h264 @ 0x2d4d1a0] Increasing reorder buffer to 2
[17:04:03 CEST] <Daemon404> ok .... has_b_frames
[17:04:05 CEST] <Daemon404> ?
[17:04:06 CEST] <Daemon404> maybe?
[17:04:07 CEST] <wm4> yeah
[17:04:12 CEST] <wm4> sounds like it
[17:04:56 CEST] <Daemon404> that warning is in avcodec...
[17:06:08 CEST] <Gramner> kierank: 0x8000 >> shift_amount is the value to use as the pmulhrsw multiplier
[17:06:26 CEST] <Gramner> (with the exeption for shift==0)
[17:06:30 CEST] <kierank> ah except for 0
[17:06:54 CEST] <nevcairiel> Daemon404: of course because the h264 decoder is in avcodec
[17:07:46 CEST] <Daemon404> yeah
[17:07:52 CEST] <Daemon404> but im wondering where it would be set in avf
[17:08:02 CEST] <Daemon404> that it no longer is and/or is set differently
[17:08:49 CEST] <nevcairiel> if the decoded hashes change, its likely just avcodec missing the has_b_frames flag and discarding a few frames
[17:09:37 CEST] <Daemon404> yes thats what it looks lile in the avcodec code
[17:09:42 CEST] <wm4> nevcairiel: so basically you're saying the flv demuxer is broken in Libav?
[17:11:03 CEST] <Daemon404> found it i think
[17:11:45 CEST] <nevcairiel> wm4: to some degree of broken, it probably still plays, but may lack metadata it had before
[17:12:31 CEST] <Daemon404> maybe not
[17:16:45 CEST] Action: Daemon404 isnt quite sure where to fix this
[17:16:54 CEST] <Daemon404> i only see it set in one place, and changing it doesn help
[17:17:14 CEST] <fritsch> who is in charge of the neon sws_scale intrinsics?
[17:17:26 CEST] <Daemon404> in fact regexing teh entirety of lavf to use codec->has_b_frames seems to not work?!
[17:17:39 CEST] <wm4> Daemon404: lol
[17:17:51 CEST] <wm4> so did we add it as codecpar field yet or not?
[17:17:55 CEST] <wm4> it seems like we really need it
[17:18:04 CEST] <Daemon404> well add one for delay or something
[17:18:11 CEST] <Daemon404> but id like to figure this out first
[17:18:15 CEST] <nevcairiel> we kinda agreeed to do it, with a more generically useful name, but didnt do it yet
[17:18:42 CEST] <Daemon404> fix stuff first to even work
[17:18:44 CEST] <Daemon404> then worry about that
[17:19:10 CEST] <nevcairiel> if it doesnt work because it lacks this property, then wouldnt the fix be to send it over?
[17:20:05 CEST] <Daemon404> nevcairiel, [16:17] <@Daemon404> in fact regexing teh entirety of lavf to use codec->has_b_frames seems to not work?!
[17:20:21 CEST] <nevcairiel> maybe you should just use has_b_frames
[17:20:25 CEST] <nevcairiel> and buy a new regex tool
[17:20:46 CEST] <Daemon404> [16:20] <@nevcairiel> maybe you should just use has_b_frames <-- ?
[17:21:08 CEST] <nevcairiel> if codec->has_b_frames doesnt work, then make the string smaller =p
[17:21:19 CEST] <Daemon404> heh
[17:21:32 CEST] <Daemon404> im not sure it will work... 
[17:21:46 CEST] <Daemon404> hmm...
[17:21:51 CEST] <Daemon404> did any of teh copy_proprs things change
[17:21:52 CEST] <Daemon404> or stuff
[17:22:09 CEST] <Daemon404> or some call to copy props
[17:22:56 CEST] <nevcairiel> there is plenty codec->has_b_frames things in avformat btw
[17:23:00 CEST] <nevcairiel> your regex must be invalid
[17:26:19 CEST] <Daemon404> i diffed against pre-merge not
[17:26:30 CEST] <Daemon404> and no uses of has_b_frames have changed after my regex
[17:26:33 CEST] <Daemon404> now*
[17:26:36 CEST] <Daemon404> so it caght them all.
[17:27:59 CEST] <wm4> maybe it's somehow overwritten when copying the codecpar?
[17:28:36 CEST] <Daemon404> maybe
[17:29:00 CEST] <nevcairiel> where do you think has_b_frames is going to be set
[17:29:25 CEST] <Daemon404> i really dont know
[17:29:36 CEST] <Daemon404> it has to be moved from teh stream context to the decode context at some point
[17:30:17 CEST] <nevcairiel> its deteremined by the decoder in find_stream_info, which used to just decode straight into the st->codec context
[17:30:19 CEST] <nevcairiel> but no longer
[17:30:21 CEST] <nevcairiel> so its no longer set
[17:31:15 CEST] <Daemon404> in fact
[17:31:16 CEST] <Daemon404> has_b_frames=1
[17:31:23 CEST] <Daemon404> from ffprobe on the stream
[17:31:29 CEST] <Daemon404> (after my regex)
[17:31:31 CEST] <Daemon404> and it still fails.
[17:31:36 CEST] <Daemon404> so i dont think you are right about what is going on
[17:31:59 CEST] <nevcairiel> i have no clue what you are on about with the regex anyway
[17:32:41 CEST] <nevcairiel> regexes are no solutions =p
[17:32:48 CEST] <Daemon404> its a test
[17:36:48 CEST] <Daemon404> nevcairiel, both hard setting has_b_frames before deocding, and also trying to use the stream context directly for find_stream_info do not fix anything.
[17:37:58 CEST] <Daemon404> oh what... TIL
[17:38:04 CEST] <Daemon404> has_b_frames can be *2*?
[17:38:14 CEST] <nevcairiel> it is the number of b frames
[17:38:21 CEST] <nevcairiel> not just 1
[17:38:29 CEST] <nevcairiel> but the amount of b-frame delay
[17:38:41 CEST] <nevcairiel> it can be up to 16 on h264
[17:38:51 CEST] <nevcairiel> or maybe 15
[17:38:54 CEST] <nevcairiel> i forget how it works
[17:39:46 CEST] <Daemon404> fffffff
[17:39:50 CEST] <Daemon404> so even the name is a lie
[17:39:56 CEST] <Daemon404> *HAS*
[17:40:09 CEST] <wm4> lol
[17:43:43 CEST] <Daemon404> i think i finally grok this...
[17:44:22 CEST] <Daemon404> mmm nope.
[17:45:59 CEST] <michaelni> yes, the name has_b_frames is complete nonsense
[17:46:08 CEST] <michaelni> its just the delay
[17:46:20 CEST] <michaelni> has_b_frames = 1 does not gurantee that there are b frames
[17:47:30 CEST] <Daemon404> michaelni, yeah i get that now
[17:55:30 CEST] <Daemon404> i wonder if ok i managed to fix the test with a hack, but i guess i need to do it properly
[17:55:57 CEST] <Daemon404> s/i wonder if //
[17:56:14 CEST] <nevcairiel> the tests would probably start working if you jus set st->codec->has_b_frames = st->internal->avctx->has_b_frames
[17:56:27 CEST] <nevcairiel> but it should be exported if its needed
[17:57:05 CEST] <Daemon404> nevcairiel, i added this at the end of try_decode_frame:
[17:57:05 CEST] <Daemon404> +    st->codec->has_b_frames = avctx->has_b_frames;
[17:57:11 CEST] <Daemon404> hack, but it 'works'
[17:57:27 CEST] <Daemon404> proper fix is to add a codecpar field i suppose
[17:57:37 CEST] <nevcairiel> indeed
[17:58:25 CEST] <Daemon404> also, try_decode_frame does *not* use the internal avctx
[17:58:28 CEST] <Daemon404> but a new one
[17:58:51 CEST] <Daemon404> which i suppose could conflict with the internal one
[17:59:02 CEST] <Daemon404> it should perhaps use the internal one?
[17:59:10 CEST] <Daemon404> and then has_b_frames is copied over properly at the end?
[17:59:19 CEST] <nevcairiel> Daemon404: from try_decode_frame, AVCodecContext *avctx = st->internal->avctx; ?
[17:59:27 CEST] <Daemon404> oh
[17:59:30 CEST] <Daemon404> reading is hard mmkay
[18:00:44 CEST] <Daemon404> st->codec->has_b_frames should still be set under deprecation guards too.
[18:01:03 CEST] <nevcairiel> if you make codecpar include that, then this will  handle that automatically
[18:01:10 CEST] <Daemon404> ah
[18:03:50 CEST] <Daemon404> nevcairiel, idea for name?
[18:03:54 CEST] <Daemon404> michaelni, ^
[18:04:54 CEST] <ubitux> maybe_b_frames
[18:05:03 CEST] <wm4> delay?
[18:05:17 CEST] <Daemon404> wm4, i currently have it as video_delay
[18:05:22 CEST] <wm4> also fine
[18:05:37 CEST] <wm4> note that some fields are used for both audi and video, with different meaning
[18:05:43 CEST] <wm4> ("format" at least)
[18:05:52 CEST] <Daemon404> i dont intend to reuse a field
[18:05:59 CEST] <Daemon404> thats asking for trouble later on
[18:06:04 CEST] <wm4> ok I agree
[18:06:51 CEST] <Daemon404> shouldnt be that hard....
[18:11:06 CEST] <Daemon404> wooo
[18:11:12 CEST] <Daemon404> fate-h264 passes with a codecpar field
[18:18:40 CEST] <BBB> passing 'uint8_t *[8]' to parameter of type 'const uint8_t **' (aka 'const unsigned char **') discards qualifiers in nested pointer types [-Wincompatible-pointer-types-discards-qualifiers]
[18:18:43 CEST] <BBB> what does that mean?
[18:19:11 CEST] <nevcairiel> that C const-ness is broken
[18:19:21 CEST] <wm4> yep
[18:20:47 CEST] <BBB> and why is AVFrame->linesize still int[] instead of ptrdiff_t[]?
[18:21:10 CEST] <nevcairiel> because api change is hard and linesizes over 32-bit seem uncommon?
[18:23:00 CEST] <wm4> one argument is that them being int is likely to break a lot of code which does "int h; h*linesize..."
[18:23:16 CEST] <wm4> which is also why image sizes are restricted to ~16000x16000
[18:23:19 CEST] <BBB> x86-64 simd tends to use linesizes
[18:23:25 CEST] <BBB> and we need to sign-extend them
[18:23:41 CEST] <BBB> right now we cant use frame->linesize directly as input to the simd function (the array, not the value)
[18:23:51 CEST] <BBB> or, well, the simd would have to sign-extend
[18:23:53 CEST] <BBB> which is slightly annoying
[18:26:08 CEST] <Daemon404> runnign a full make fate on codecpar now;...
[18:26:11 CEST] <Daemon404> fingers crossed.
[18:31:34 CEST] <Daemon404> fate with -O0 = slow
[18:34:33 CEST] <wm4> was the pmp-demux thing fixed?
[18:35:56 CEST] <Daemon404> not yet no
[18:36:03 CEST] <Daemon404> im running with GEN=1 to see what is left to fix
[18:37:59 CEST] <jamrial> i thought you couldn't compile ffmpeg with -O0 because of dce
[18:38:25 CEST] <Daemon404> depends on the compiler and version.
[18:43:36 CEST] <Daemon404> wm4, updated etherpad
[18:43:45 CEST] <Daemon404> most look related to priv_pts insanity
[18:44:25 CEST] <Daemon404> except vp6 and wmv
[18:44:27 CEST] <Daemon404> er xmv
[18:44:32 CEST] <wm4> so those fate tests like pmp-demux still fail?
[18:45:05 CEST] <Daemon404> no... only some
[18:45:35 CEST] <Daemon404> i never did figure out how pmp demux timestamos came to be
[18:45:42 CEST] <Daemon404> -#extradata 0:        4, 0x015a00ad
[18:45:46 CEST] <Daemon404> and tehre's this from xmv
[18:46:26 CEST] <wm4> short look suggests it might change extradata later
[18:46:31 CEST] <wm4> so it doesn't get copied
[18:46:55 CEST] <Daemon404> sigh
[18:49:15 CEST] <wm4> don't we have side data to update extradata?
[19:11:36 CEST] <BBB> wm4: yes
[19:15:15 CEST] <fritsch> https://github.com/FFmpeg/FFmpeg/blob/release/3.0/libswscale/arm/yuv2rgb_neon.S#L404 <- how to force this part of the code on the commandline?
[19:15:22 CEST] <fritsch> argh, sorry - was for user's channel
[19:23:08 CEST] <Daemon404> i STILL cannot find where dts is set for rawdec stuff
[19:36:38 CEST] <wm4> Daemon404: it sets it on the packet
[19:37:09 CEST] <Daemon404> where
[19:37:14 CEST] <wm4> looking
[19:37:22 CEST] <wm4> decode_video
[19:37:26 CEST] <wm4> pkt->dts  = av_rescale_q(ist->dts, AV_TIME_BASE_Q, ist->st->time_base);
[19:37:40 CEST] <wm4> PS: this is insane, and I had my own fun with it, and avconv doesn't do this
[19:37:51 CEST] <wm4> or maybe this is not what you're looking for?
[19:37:56 CEST] <Daemon404> no
[19:38:10 CEST] <Daemon404> im slowly tracing this hevc failure
[19:38:32 CEST] <Daemon404> all but the last few frames properly have NOTS set as the val
[19:39:19 CEST] <wm4> hahaha
[19:39:43 CEST] <wm4> that's probably when ffmpeg.c sets dts on a flush packet?
[19:39:53 CEST] <Daemon404> no
[19:39:55 CEST] <Daemon404> its in utils.c
[19:39:57 CEST] <wm4> and if the codec delay is "wrong" it won't work
[19:40:04 CEST] <wm4> hm
[19:40:06 CEST] <Daemon404> im checking values returned by av_read_frame
[19:40:11 CEST] <Daemon404> unless ffmpeg.c is to blame
[19:40:13 CEST] <Daemon404> and im wrong
[19:41:41 CEST] <Daemon404> or hkmmm
[19:41:41 CEST] <wm4> so it's libavformat timestamp-making-up-code?
[19:41:52 CEST] <Daemon404> nope
[19:41:53 CEST] <Daemon404> i was wrong
[19:42:00 CEST] <Daemon404> NOTS si set properly on the flush packets
[19:42:13 CEST] <Daemon404> so dts is done in ffmpeg.c... ?
[19:51:17 CEST] <Daemon404> solved it
[19:51:18 CEST] <Daemon404> D:
[19:53:27 CEST] <nevcairiel> Daemon404: btw they updated clang/c2 today
[19:54:17 CEST] <Daemon404> oh?
[19:56:17 CEST] <nevcairiel> as part of 2015u2
[19:56:30 CEST] <Daemon404> ah
[19:56:54 CEST] <Daemon404> woo fixed hevc
[19:58:26 CEST] <wm4> nevcairiel: is it usable yet?
[19:58:37 CEST] <nevcairiel> who knows
[19:58:40 CEST] <nevcairiel> +will have to find out
[20:01:15 CEST] <Daemon404> only 3 fate failures left
[20:01:35 CEST] <JEEB> nice
[20:04:08 CEST] <Daemon404> wm4, i havent been following the big githbu comment threads. is it possible to fix wmv and pals?
[20:05:22 CEST] <ubitux> fritsch: it's triggered by default,-f lavfi -i testsrc2,format=yuv420p,format=rgba should do it
[20:05:59 CEST] <Daemon404> ok so vp6 is [flv @ 0x2dd9900] video stream discovered after head already parsed
[20:06:21 CEST] <nevcairiel> that warning is "normal" now
[20:06:26 CEST] <nevcairiel> should be disabled probably
[20:06:34 CEST] <Daemon404> i see
[20:06:39 CEST] <Daemon404> but the test is still failing
[20:07:02 CEST] <Daemon404> packet size is wrong (wtf?)
[20:07:21 CEST] <Daemon404> -0,          0,          0,        1,    81000, 0xcb92962d
[20:07:21 CEST] <Daemon404> +0,          0,          0,        1,   135000, 0xc6c0bf8b
[20:07:31 CEST] <Daemon404> and so forth
[20:07:37 CEST] <Daemon404> and xmv failure is extradata.
[20:10:42 CEST] <ubitux> fritsch: there are a bunch of patches pending for that code btw
[20:11:08 CEST] <ubitux> (including zomg speed)
[20:11:24 CEST] <Daemon404> ok i solved pmp
[20:11:35 CEST] <Daemon404> so just the flv / extradtaa stuff left
[20:13:15 CEST] <Daemon404> wm4, ^
[20:18:45 CEST] <nevcairiel> also, MS ships a bash shell and various tools now, w onder if that can run configure ... and maybe faster?
[20:19:30 CEST] <Plorkyeran> no inherent reason it shouldn't be able to
[20:19:41 CEST] <Plorkyeran> might be quirks that need to be dealt with
[20:20:09 CEST] <Plorkyeran> I wouldn't really expect it to be faster unless the slowness is actually win32-specific
[20:20:24 CEST] <Plorkyeran> (as opposed to an NT thing)
[20:21:47 CEST] <Daemon404> slowness is win32 specific (forks)
[20:21:57 CEST] <Daemon404> unless you mean something else
[20:22:26 CEST] <Plorkyeran> well it's probably a separate subsystem
[20:22:30 CEST] <Plorkyeran> since it runs native elf binaries
[20:22:49 CEST] <Plorkyeran> so it might have better fork performance
[20:23:22 CEST] <Daemon404> runs elf O_o
[20:23:37 CEST] <nevcairiel> runs native ubuntu usermode binaries
[20:24:28 CEST] <BtbN> The NT kernel has a native (but undocumented) fork call since quite a while, and cygwin uses that to "emulate" fork.
[20:24:47 CEST] <TD-Linux> BtbN, I don't think they actually use that last I checked
[20:26:20 CEST] <nevcairiel> its a OS feature in the upcoming win10 version though, not something that comes through VS for earlier OSes
[20:27:33 CEST] <BtbN> RtlCloneUserProcess isn't new.
[20:28:26 CEST] <nevcairiel> noone is talking about that but you =P
[20:28:40 CEST] <nevcairiel> it runs native ELF binaries
[20:28:50 CEST] <nevcairiel> not some cross-compiled things
[20:31:35 CEST] <Daemon404> nevcairiel / wm4, will you be attempting to tackle the xmv/flv stuff?
[20:31:40 CEST] <Daemon404> or am i stuck poking it
[20:33:41 CEST] <nevcairiel> i can try later
[20:34:06 CEST] <Daemon404> all right
[20:34:17 CEST] <Daemon404> i spent too much time looking at insane timstamp code today
[20:34:21 CEST] <Daemon404> my brain is mush
[20:35:35 CEST] <wm4> I don't think I have any time for this
[20:38:49 CEST] <Daemon404> well someone's gonna have to, and i still dont fully grok the problem.
[20:42:31 CEST] <Daemon404> nevcairiel, in the meantime i am going to start converting some has_b_frame code + missed stuff in lavf to codecpar, since i can actually run fate now
[20:43:19 CEST] <Daemon404> unless you think that should wait on this.
[21:02:05 CEST] <fritsch> ubitux: it crashes hard if it copes with a non aligned memory adress
[21:20:37 CEST] <wm4> it's not really clear if passing unaligned pointers to libswscale is supposed to work or not
[21:21:17 CEST] <Daemon404> if (!decode && codec_ctx->codec->caps_internal & FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM) {
[21:21:24 CEST] <Daemon404> why do we have a unit test for teh api with this
[21:21:33 CEST] <Daemon404> D:
[21:21:54 CEST] <Daemon404> is Matthieu Bouron on irc
[21:22:33 CEST] <wm4> Daemon404: to avoid decoding pngs and jpgs in lavf
[21:22:40 CEST] <JEEB> I think it's mateo`_
[21:22:41 CEST] <Daemon404> thats nice
[21:22:45 CEST] <Daemon404> but it's hella illegal
[21:22:48 CEST] <Daemon404> youre accessign internal structs
[21:22:59 CEST] <wm4> lol patch reviews
[21:23:03 CEST] <wm4> that thread was long
[21:23:09 CEST] <wm4> and nobody spotted it? (including myself)
[21:25:06 CEST] <Daemon404> ill look at it later...
[21:25:23 CEST] <Daemon404> did a bunch of conversions now.... im beat... put a ton of work into tep2 the past few days.
[21:25:37 CEST] Action: Daemon404 will stop and wait for nevcairiel or wm4 to figure out flv
[21:26:03 CEST] <wm4> does flv still make any fate test fail?
[21:26:14 CEST] <wm4> or is it not covered
[21:26:36 CEST] <Daemon404> vp6
[21:26:40 CEST] <Daemon404> some alpha thing
[21:26:46 CEST] <Daemon404> skipalpha
[21:26:55 CEST] <wm4> exact name of the test?
[21:27:06 CEST] <Daemon404> vp6a-skip_alpha
[21:27:13 CEST] <Daemon404> that, and wmv, are the only two failing tests.
[21:27:16 CEST] <wm4> ah yeah it's actually on the etherpad
[21:27:22 CEST] <Daemon404> we xmv*
[21:27:24 CEST] <Daemon404> er*
[21:28:59 CEST] <Daemon404> i think ive toiled away on my own in insaity enough for now. im sure you all can find some time in the next few days.
[21:29:02 CEST] Action: Daemon404 cracks a beer
[21:40:34 CEST] <wm4> I totally love how a "broken" codecpar build actually outputs alpha, while ffmpeg 2.8 doesn't
[21:40:37 CEST] <wm4> for this sample
[21:41:00 CEST] <Daemon404> the point of this sample is to skip alpha
[21:41:08 CEST] <Daemon404> it's a feature (git log on the fate ref(
[21:41:10 CEST] <wm4> aha
[21:42:09 CEST] <wm4> "useful"
[21:43:19 CEST] <BBB> hm, so I think my colorspace filter works now
[21:44:02 CEST] <BBB> it has 8/10/12bpp yuv420/422/444 support and supports both a fast (incorrect) colormatrix-style conversion as well as a slow (correct) one that includes primary/gamma correction
[21:44:10 CEST] <rcombs> anyone have any objection to my auto-bsf segment patch?
[21:45:47 CEST] <BBB> rcombs: looks rather straightforward
[21:46:18 CEST] <BBB> its a little hacky/one-off but I dont see why thats a problem for now
[21:48:04 CEST] <wm4> Daemon404: that just means the sample _should_ have alpha
[21:49:15 CEST] <wm4> ah nevermind it's just me being dumb
[21:49:26 CEST] <wm4> so, just -skip_alpha is broken
[21:49:44 CEST] <Daemon404> theres a prores skip alpha test too
[21:49:46 CEST] <Daemon404> but it doesnt fail
[21:49:52 CEST] <Daemon404> my bet is still on flv
[21:50:49 CEST] <baptiste> rcombs, auto bsf is nice, wanted that for years
[21:51:14 CEST] <rcombs> baptiste: I implemented it a while back and it's in master; this patch is just for handling it in the segment muxer
[21:53:27 CEST] <baptiste> make sense :>
[22:01:22 CEST] <durandal_170> BBB: how much to pay for source?
[22:01:42 CEST] <BBB> huh?
[22:03:13 CEST] <BBB> what do you mean exactly?
[22:23:06 CEST] <durandal_170> BBB: colormatrix filter
[22:25:30 CEST] <BBB> why would I need colormatrix filter source?
[22:26:52 CEST] <durandal_170> I meant to replace current gpl version
[22:27:40 CEST] <BBB> I already finished it
[22:28:03 CEST] <BBB> if you want to delete colormatrix, just delete it
[22:30:24 CEST] <durandal_170> I want to replace it
[22:30:42 CEST] <BBB> so wait a few minutes for me to send the patch
[22:30:45 CEST] <BBB> then approve it
[22:30:49 CEST] <BBB> delete colormatrix yourself
[22:30:50 CEST] <BBB> and youre done
[22:32:04 CEST] <durandal_170> you picked different name?
[22:32:22 CEST] <BBB> yes
[22:32:58 CEST] <BBB> it works slightly different, I dont care about compatibility or whatever, so I just used a different name
[22:33:01 CEST] <BBB> much easier
[22:35:28 CEST] <BBB> there you go
[22:36:26 CEST] <BBB> so, things to note: no simd yet (lets get base filter in first), and the gamma correction is lut-based. I have an integer version (dont ask) that may be faster but Ill need to revive it from some very old archive and port it over
[22:37:57 CEST] <wm4> Daemon404: the failure is caused by -skip_alpha not being propagated somewhere
[22:40:27 CEST] <Daemon404> that seems like an odd breakage
[22:40:48 CEST] <wm4> or maybe it just looks like that who knows
[22:41:02 CEST] <wm4> is there a way to direct an option to a decoder instead of lavf?
[22:43:48 CEST] <wm4> adding this to decode_frame() gives a better result: av_dict_set(options ? options : &thread_opt, "skip_alpha", "1", 0);
[22:45:14 CEST] <Daemon404> hmm youre right, it seems its not being propgated
[22:48:56 CEST] <wm4> another difference is that the codecpar pixelformat is apparently different in both cases
[22:49:01 CEST] <wm4> (alpha vs. not alpha)
[22:49:09 CEST] <wm4> why didn't ffprobe -show_streams show this
[22:49:16 CEST] <Daemon404> yes which it gets from find_stream_info
[22:49:20 CEST] <Daemon404> thats what im looking at right now
[22:49:25 CEST] <nevcairiel> ffmpeg.c probably sets the option on st->codec, somehow?
[22:50:32 CEST] <wm4> oh wait does ffmpeg.c still use st->codec for decoding?
[22:50:54 CEST] <Daemon404> i didnt think it did
[22:51:12 CEST] <Daemon404> the problem i think is that the pix fmt is set in find_stream_info
[22:51:21 CEST] <Daemon404> and the vp6 code checks teh pixfmt
[22:51:35 CEST] <wm4> oh ok
[22:51:43 CEST] <Daemon404> i think it may not be propogated to that?
[22:51:45 CEST] <wm4> yes I think ffmpeg.c creates a separate context
[22:52:01 CEST] <Daemon404> i dont know how to dump an avdict to printf debug
[22:52:02 CEST] <Daemon404> :V
[22:52:09 CEST] <Daemon404> (in try_decode_frame)
[22:52:32 CEST] <wm4> so skip_alpha is probably not set on the ffmpeg.c decoder context, but if codecpar pixfmt is non-alpha, it won't decode alphas
[22:52:47 CEST] <wm4> so the question is where the heck does the skip_alpha option get "consumed"
[22:53:06 CEST] <wm4> it doesn't go to ffmpeg.c's decoder, it doesn't go to lavf's internal decoder either?
[22:53:11 CEST] <wm4> maybe I'm just crazy
[22:53:51 CEST] <Daemon404> i think the problem is that its not set on the decoder in find_stream_info
[22:54:38 CEST] <wm4> if skip_alpha were set on the ffmpeg.c decoder context, the test would probably succeed
[22:55:23 CEST] <Daemon404> did you test this
[22:55:39 CEST] <wm4> let me
[22:56:36 CEST] <Daemon404> hmm nope you dont have to
[22:56:43 CEST] <Daemon404> i set it manually in try_decode_frame, and it fixes it
[22:56:49 CEST] <Daemon404> so it isnt getting propogated there.
[22:56:53 CEST] <wm4> I did that too
[22:57:04 CEST] <wm4> I'm wondering about ffmpeg.c's
[22:57:19 CEST] <Daemon404> the decode does get the flag
[22:57:23 CEST] <Daemon404> otherwise the prores test would fail
[22:57:48 CEST] <wm4> huh, still fails if I set it in ffmpeg.c
[22:58:08 CEST] <Daemon404> ffmpeg.c makes no diff
[22:58:13 CEST] <Daemon404> you only have to set it in try_decode_frame
[22:58:41 CEST] <wm4> I know, but the test basically fails because the decoder outputs alpha, so setting skip_alpha on ffmpeg.c's decoder should fix it
[22:59:21 CEST] <Daemon404> /* Set AVCodecContext options for avformat_find_stream_info */
[22:59:23 CEST] <Daemon404> looks related
[22:59:59 CEST] <wm4> (fuck ffmpeg.c option handling)
[23:01:16 CEST] <wm4> could it depend on whether the streams exist before or after find_stream_info?
[23:01:52 CEST] <Daemon404> yes
[23:02:06 CEST] <Daemon404> because during find_stream_info is when it sets the pix_fmt... i think
[23:02:25 CEST] <wm4> I was thinking about how skip_alpha gets consumed
[23:02:36 CEST] <BBB> michaelni: your framehash change doesnt register size changes
[23:02:42 CEST] <wm4> it works for the prores test, which uses a mov container and not flv
[23:02:54 CEST] <wm4> while flv was changed to add streams at a later point (during findf_stream_info)
[23:02:58 CEST] <BBB> michaelni: e.g. look at vp8-size-change
[23:03:10 CEST] <Daemon404> wm4, i see
[23:04:11 CEST] <wm4> so we should change the test to set the option correctly
[23:04:16 CEST] <wm4> but I have no clue how that works
[23:04:39 CEST] <Daemon404> i think it is setting it correctly? i dont know.
[23:04:39 CEST] <nevcairiel> not sure you can really set options to the decoder used in find_stream_info
[23:05:02 CEST] <wm4> I mean the API allows it
[23:05:25 CEST] <wm4> and setup_find_stream_info_opts somehow uses it
[23:07:30 CEST] <michaelni> BBB, didnt think about that, will fix it
[23:07:39 CEST] <wm4> if I set the option there it doesn't work (wut)
[23:07:41 CEST] <BBB> ty
[23:10:48 CEST] <wm4> well maybe I'll try some more tomorrow
[23:11:33 CEST] <cone-330> ffmpeg 03Michael Niedermayer 07master:a35a4a5774a1: fate: Add filter-metadata-cropdetect
[23:19:40 CEST] <Daemon404> wm4, i think the option cant be applied because the stream hasnt been found before calling find_stream_info
[23:20:07 CEST] <wm4> oh right
[23:20:11 CEST] <wm4> no way to pass it
[23:20:21 CEST] <Daemon404> yea
[23:20:55 CEST] <wm4> I still don't get why it doesn't work when setting the option on the decoder
[23:22:04 CEST] <wm4> or why the option gets "lost"
[23:23:54 CEST] <Daemon404> wm4, the decoder does see it
[23:24:07 CEST] <Daemon404> when it is init'd for the actual decoding (not in find_stream_info)
[23:24:12 CEST] <Daemon404> the option is correctly set there
[23:24:26 CEST] <wm4> also I see "Input stream #0:0 frame changed from size:300x180 fmt:yuva420p to size:300x180 fmt:yuv420p"
[23:24:52 CEST] <Daemon404> yes thats why
[23:25:06 CEST] <Daemon404> since it changed between init and decode
[23:25:20 CEST] <wm4> ooh
[23:25:35 CEST] <wm4> and rawenc is fixed to yuva?
[23:25:47 CEST] <Daemon404> possible
[23:25:55 CEST] <wm4> well uh that sucks
[23:26:50 CEST] <wm4> [scaler for output stream 0:0 @ 0x93f200] w:300 h:180 fmt:yuv420p sar:0/1 -> w:300 h:180 fmt:yuva420p sar:0/1 flags:0x4
[23:27:10 CEST] <Daemon404> if i force the pix_fmt it works
[23:27:29 CEST] <Daemon404> so it seems to happen due to initing with yuva and selectign the raw output colorspace based on that
[23:27:44 CEST] <wm4> but shouldn't the decoder set the right pixfmt during opening, or is that too late too
[23:28:25 CEST] <Daemon404> i think ffmpeg.c sets it all up before opening
[23:28:29 CEST] <Daemon404> i could be wrong
[23:28:36 CEST] <wm4> sigh
[23:29:18 CEST] <Daemon404> its not wrong to do so
[23:29:22 CEST] <wm4> it is
[23:29:27 CEST] <Daemon404> youd think the info you get from find_stream_info is correct
[23:29:37 CEST] <Daemon404> for frame 1 at least
[23:29:44 CEST] <wm4> yeah, but the pixfmt is one of those things which easily can change from decoder to decoder
[23:29:56 CEST] <wm4> or because the parser sets something else etc.
[23:30:15 CEST] <Daemon404> maybe nevcairiel has an opinion.
[23:31:18 CEST] <wm4> ffmpeg_opt.c line 709 inits it with the lavf pixfmt before opening a decoder, it seems
[23:32:40 CEST] <wm4> and forcing the pixfmt on the command line doesn't test what the test is supposed to test
[23:34:54 CEST] <wm4> could we remux the sample to some other container?
[23:35:06 CEST] <wm4> one that doesn't do delayed adding of AVStreams
[23:36:41 CEST] <wm4> vp6a can go into avi and mov and consequently also mkv (jesus christ multimedia is horrible)
[23:36:46 CEST] <Daemon404> seems like working around a problem
[23:37:07 CEST] <wm4> the problem is that we trigger a ffmpeg.c bug due to slight change in behavior as far as I'm concerned
[23:37:37 CEST] <wm4> I also tested with mpv and everything works as expected
[23:38:15 CEST] <Daemon404> true.
[23:40:04 CEST] <wm4> haha
[23:40:14 CEST] <wm4> I remuxed it to mov and adjusted the filename in fate, and it works
[23:40:55 CEST] <wm4> both tests which use the file
[23:41:15 CEST] <wm4> so we should be able to go with this?
[23:41:32 CEST] <Daemon404> i would personally, others may have ~opinions~
[23:41:40 CEST] <nevcairiel> changing the tests are not fixes =p
[23:41:55 CEST] <Daemon404> depends if you consider the ffmpeg.c was broken to begin with
[23:42:00 CEST] <Daemon404> that*
[23:42:13 CEST] <Daemon404> im not sure what a correct fix would be otherwise
[23:42:15 CEST] <nevcairiel> where is the option applied anyway? in find_stream_info?
[23:42:20 CEST] <BBB> file a bug for the broken file
[23:42:23 CEST] <BBB> so it doesnt get lost
[23:42:28 CEST] <Daemon404> nevcairiel, the problem is not the option
[23:42:29 CEST] <BBB> and then chagne test so it no longer triggers
[23:42:45 CEST] <nevcairiel> Daemon404: thats not what i asked :)
[23:43:03 CEST] <Daemon404> it used to be applied in find_stream_info and on teh decode context in ffmpeg.c
[23:43:08 CEST] <Daemon404> not it is only applied on the latter
[23:43:19 CEST] <Daemon404> because it isnt passed to find_stream_info
[23:43:24 CEST] <Daemon404> due to tehre being no streams 
[23:43:26 CEST] <Daemon404> before the call.
[23:43:31 CEST] <nevcairiel> so find_stream_info keeps a list of options it couldnt apply, why not re-try to apply it when a new stream shows up?
[23:43:59 CEST] <wm4> nevcairiel: because the options are per-stream
[23:44:00 CEST] <wm4> shit API
[23:44:01 CEST] <Daemon404> i am not sure whether it is find_stream_info of ffmpeg*.c that keeps the list of options for a stream
[23:44:05 CEST] <Daemon404> or*
[23:44:19 CEST] <wm4> you can't set options on streams which appear during find_steram_info
[23:44:20 CEST] <wm4> shit API
[23:44:21 CEST] <nevcairiel> so ffmpeg.c just doesnt passs any options?
[23:44:29 CEST] <Daemon404> let me check
[23:44:33 CEST] <Daemon404> i was pretty sure it passed NULL
[23:44:39 CEST] <Daemon404> since it didnt find any streams to apply options to
[23:44:48 CEST] <wm4> I'm also pretty sure that effectively happens (and it can't pass any)
[23:45:04 CEST] <nevcairiel> right, the API calls for passing an array of dicts that matches the stream size
[23:45:18 CEST] <wm4> we could add new API for this
[23:45:25 CEST] <wm4> a dict of options to apply to new streams or so
[23:45:52 CEST] <nevcairiel> I could fix the trust_metadata option in flv and we just add that to the test
[23:46:00 CEST] <nevcairiel> hm wait no that doesnt help
[23:46:07 CEST] <nevcairiel> still delayed
[23:46:14 CEST] <nevcairiel> since the metadata block isnt part of the header
[23:47:05 CEST] <erraunt> Hi. I am wondering how to check which projects from GSoC have been taken? I am wondering if I could do something similar outside of GSoC? I have a university course and probably could also use the code as a basis for my "bachelor thesis". I have some experience in coding in C, last semester I tried to contribute to FreeBSD kernel but I believe I did not do a good job, so I will also welcome
[23:47:07 CEST] <erraunt> discouragment if appropriate.
[23:47:50 CEST] <Daemon404> nevcairiel, yes im not sure how to handle that
[23:48:00 CEST] <nevcairiel> erraunt:  You are always free to work on FFmpeg on any project you want, and many of us are happy to help. But note that we cannot pay you like google would in GSoC
[23:49:11 CEST] <wm4> erraunt: yeah, the only thing we can't provide is payment (outside of gsoc)
[23:49:11 CEST] <erraunt> nevcairiel: of course, I did not mention anything about paying. (taking part in GSoC)
[23:49:16 CEST] <nevcairiel> Daemon404: if the test is meant to test vp6a and not flv, then remuxing is probably fine in t his case
[23:49:22 CEST] <nevcairiel> erraunt: just making sure :)
[23:49:42 CEST] <erraunt> so how can I figure which projects have been taken?
[23:49:57 CEST] <wm4> so I vote for remuxing the file to mov, uploading to... whereever the samples are stored, and be done with it
[23:50:07 CEST] <Daemon404> nevcairiel, that doesnt really solve the "flv problem" does it?
[23:50:12 CEST] <Daemon404> or is it a problem?
[23:50:30 CEST] <nevcairiel> Daemon404: its a basic  api problem that has always existed, couldnt set it on mpegts either, for example
[23:50:32 CEST] <wm4> and yes the tests are in vpx.mak
[23:50:44 CEST] <Daemon404> nevcairiel, true good point
[23:51:03 CEST] <wm4> ffmpeg.c could just be slightly less dumb, but that's not our job here
[23:51:44 CEST] <wm4> any API user who checks the pixfmt after opening will be fine too
[23:52:08 CEST] <wm4> (I wonder if the opening call couldn't just be moved in ffmpeg.c?)
[23:52:58 CEST] <wm4> erraunt: look around in the wiki, there might be a page about candidates and their progress
[23:53:11 CEST] <wm4> erraunt: if everything else fails, mail the mentors
[23:53:32 CEST] <Daemon404> wm4, assuming anyone even gives a shit abotu skip alpha.
[23:53:33 CEST] <nevcairiel> what status is gsoc in anyway, i think its not quite clear which projects are really assigned, is it
[23:53:47 CEST] <nevcairiel> dont think google did that yet
[23:54:05 CEST] <wm4> Daemon404: mplayer?
[23:54:12 CEST] <Daemon404> lol.
[23:54:31 CEST] <Daemon404> anyway... just one fate test left which is xmv.
[23:54:40 CEST] <Daemon404> with post-open extradata
[23:55:11 CEST] <wm4> nasty
[23:55:27 CEST] <nevcairiel> did you fix voc?
[23:55:42 CEST] <Daemon404> voc passes, and wm4 made a commit to it
[23:55:50 CEST] <Daemon404> so i assume so, nless he says otherwise
[23:55:54 CEST] <erraunt> wm4: ok
[23:55:55 CEST] <wm4> maybe it's still wrong?
[00:00:00 CEST] --- Thu Mar 31 2016