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

[burek]

[00:08:44 CEST] <nevcairiel> kierank: it automatically unrefs the old buffer if this case happens, ie. basically you dont have to think you it, because its refcounted.
[00:09:07 CEST] <kierank> I realise that now after reading buffer.c
[00:09:36 CEST] <nevcairiel> thats what one might expect to happen as well, why would av_buffer_realloc require any other actions to be taken depending on what the buffer was before
[00:50:49 CEST] <BBB> michaelni: Im not sure how that currently works w.r.t. frame threading?
[00:51:14 CEST] <BBB> michaelni: I dont think were asking you to actually fix mpeg4-frame-mt (theres no issues anyway), more to figure out which fields to sync so the memcpy is unneeded
[00:51:46 CEST] <BBB> the way I would do that is to copy all fields and remove them until frame-mt+fate breaks or tsan stops complaining
[00:52:34 CEST] <BBB> michaelni: but I agree that it is likely boring :-/
[00:52:47 CEST] <BBB> michaelni: the rest of the tsan fixing was quite boring also
[00:53:42 CEST] <durandal_1707> you must be superstar when everything is boring
[01:04:20 CEST] <kierank> hmmm why my patch not appear
[01:36:07 CEST] <jamrial> kierank: you could do the same with hevc close captions. the code there is more or less a copy paste of the h264 implementation
[01:36:15 CEST] <kierank> I have no samples of those
[01:36:20 CEST] <kierank> otherwise I could
[01:36:22 CEST] <kierank> same with mpeg-2 field
[01:36:40 CEST] <kierank> also like BBB i don't care about hevc :)
[01:38:03 CEST] <JEEB> yea, I haven't seen any HEVC closed captions either :D
[01:39:44 CEST] <JEEB> kierank: btw I guess pengvado's vbv.py is the best VBV/HRD verifier that there is in OSS? I was thinking of writing something if that was the case.
[01:40:01 CEST] <kierank> yes afaik
[01:40:06 CEST] <JEEB> k
[01:40:15 CEST] <kierank> vbv.pl I think
[01:40:19 CEST] <kierank> if only it was python :)
[01:40:22 CEST] <JEEB> ugh, yes :)
[01:40:32 CEST] <JEEB> the thing I was writing had a code name like that :P
[01:40:49 CEST] <JEEB> although I think I'd have to go further for anything like UDP stream validation etc
[01:40:57 CEST] <kierank> I think penvagdo's thing doesn't do the hrd weirdness
[01:41:00 CEST] <JEEB> yea
[01:41:02 CEST] <JEEB> it's very simple
[01:41:22 CEST] <kierank> udp stream validation is a bit meh to be honest
[01:41:26 CEST] <kierank> all the numbers are made up
[01:41:30 CEST] <kierank> imo
[01:41:38 CEST] <JEEB> well so far that's how it looks :P
[01:42:06 CEST] <kierank> for me what matters is dts < pcr
[01:48:46 CEST] <JEEB> but yea, I'm mostly interested because I'm getting kind of tired of some people telling me that my rate control is off according to something VeryExpensive (which most likely doesn't even read my HRD data if it says so). what I have atm utilizes something as simple as packets and the duration of them which is complete bullshit but does give me some values. for actual real stuff I'd have to do the 
[01:48:52 CEST] <JEEB> parsing of NAL units myself etc.
[01:49:46 CEST] <kierank> JEEB: what analyser is this?
[01:49:56 CEST] <kierank> pm me if need be
[01:50:15 CEST] <JEEB> I haven't had the chance to see which it is
[01:50:18 CEST] <kierank> lol
[01:53:27 CEST] <JEEB> anyways, tomorrow^Wtoday's a new day so off to hit the sack for me o/
[01:54:28 CEST] <BBB> kierank: I can be made to care about hevc
[01:55:05 CEST] <BBB> kierank: but my general opinion is that because the IP holders have been such enormous &^*%%#$@ about squeezing money out of it before its anything at all, Im not going to be any different
[01:56:15 CEST] <BBB> durandal_1707: dont you find tsan-like bugs (or ub-like bugs, which tend to be similar) kinda boring? simd is fun, on the other hand
[02:25:19 CEST] <cone-265> ffmpeg 03Wan-Teh Chang 07master:2f84f40d451c: avformat/avio: Remove no-op code in url_find_protocol().
[12:17:13 CEST] <cone-729> ffmpeg 03Paul B Mahol 07master:fa3fd7f5a003: avcodec/magicyuv: make RLE table reading match reference
[12:17:14 CEST] <cone-729> ffmpeg 03Paul B Mahol 07master:0281d5ece640: avcodec/magicyuv: add 12 bit formats
[13:10:50 CEST] <J_Darnley> atomnuker: if you are around I want to ask you more questions about vc2enc
[13:11:46 CEST] <J_Darnley> I'll start with: where does the encoder move data out of the whole plane transform into slices.
[13:12:14 CEST] <J_Darnley> I think that's where I need to look for more changes to make
[13:25:50 CEST] <kierank> wm4: are you sure changing the src context is ok?
[13:25:50 CEST] <kierank> 6:54 PM <"BBB> kierank: this isnt so much a convention but a necessity, because the previous thread expects the contents not to change under its feet while the current frame is decoding concurrently with the next frame
[13:26:04 CEST] <wm4> kierank: no, but your patch changes it anyway?
[13:26:18 CEST] <kierank> via the bufref mechanism which should be thread safe
[13:26:27 CEST] <wm4> or did I read the patch wrongly
[13:26:31 CEST] <wm4> let me check again
[13:27:12 CEST] <wm4> +        av_buffer_unref(&h1->sei.a53_caption.buf_ref);
[13:27:16 CEST] <wm4> h1 is from src
[13:27:48 CEST] <wm4> the AVBufferRef* itself is not thread-safe - it's just a normal, non-atomic pointer
[13:28:10 CEST] <wm4> av_buffer_unref(x) is a helper for freeing the AVBufferRef and doing *x=NULL
[13:28:44 CEST] <kierank> then I don't know how else to do it
[13:29:02 CEST] <wm4> chances are, you don't actually want to clear the h1->sei.a53_caption.buf_ref?
[13:29:06 CEST] <BBB> I dont think we should change anything in src that can change actual non-reference-count values
[13:29:26 CEST] <BBB> what does the source do depending on buf_ref being NULL or not?
[13:29:32 CEST] <kierank> wm4: iirc if you don't it reappears in a future thread
[13:29:36 CEST] <kierank> because of context reuse perhaps
[13:30:24 CEST] <kierank> BBB: if a frame is output it uses the data then unrefs, if no frame is output it needs to pass the buf_ref to the next field
[13:30:32 CEST] <wm4> well the worker thread itself should probably clear it when a new frame is being decoded or so
[13:30:51 CEST] <BBB> its an obvious race condition
[13:30:53 CEST] <BBB> IMO
[13:31:11 CEST] <BBB> imagine that thread 1 and 2 happen entirely serially
[13:31:14 CEST] <BBB> (that can happen)
[13:32:12 CEST] <kierank> serial is good, no?
[13:32:52 CEST] <kierank> parallel is bad
[13:33:03 CEST] <kierank> or maybe i misunderstand
[13:36:48 CEST] <kierank> init_context might be the place to do it
[13:40:54 CEST] <kierank> actually no i have to do it this way i think
[13:41:10 CEST] Action: J_Darnley goes afk
[14:01:15 CEST] Action: J_Darnley is back
[14:02:02 CEST] <BBB> serial means one starts after the other finishes
[14:02:07 CEST] <BBB> it means no parallelism/multithreading
[14:04:10 CEST] <iive> can we get the captions before sending the field bitstream to a worker thread?
[14:10:06 CEST] Action: kierank not sure what to do
[14:12:38 CEST] <BBB> kierank: have a sample you can share? :)
[14:21:33 CEST] <wm4> I mean the basic idea of that patch is probably right, just changing the src context is probably not great
[14:23:46 CEST] <kierank> I can get rid of the unref but I get double free on exit
[14:33:29 CEST] <J_Darnley> I hate this vc2 crap.  Never ending nesting of pointers, buffers, strcutures.
[14:35:24 CEST] <wm4> kierank: wut
[14:45:42 CEST] <J_Darnley> kierank: Do you know why vc2enc allocates a buffer for the dwt of twice as many values as I thought necesary?
[14:45:54 CEST] <kierank> 10-bit?
[14:46:17 CEST] <J_Darnley> It already has a sizeof if that's what you mean
[15:59:41 CEST] <wm4> nevcairiel: fine if I push that dxva2 patch I just sent to libav to ffmpeg master?
[16:00:39 CEST] <nevcairiel> should be fine
[16:04:39 CEST] <cone-729> ffmpeg 03wm4 07master:c64da19bbc1d: dxva: DXVA2_ModeHEVC_VLD_Main10 does not support Main
[17:02:16 CEST] <atomnuker> J_Darnley: it looks up the start address of each slice, no copying involved
[17:02:29 CEST] <atomnuker> it allocates 2x because of precision reasons IIRC
[17:03:22 CEST] <J_Darnley> Okay, not copying...
[17:04:15 CEST] <J_Darnley> I guess: where does it get the DC or LL coeffs for one slice out of the whole?
[17:04:38 CEST] <J_Darnley> I can't see the deinterleave(?) for each slice
[18:13:00 CEST] <atomnuker> J_Darnley: look at encode_subband
[18:14:55 CEST] <J_Darnley> noted
[18:23:00 CEST] <J_Darnley> Dammit.  I can never remember the order of operations with a cast.
[18:23:43 CEST] <J_Darnley> Is "(uint16_t*)a + b" the same as "((uint16_t)a*) + b"
[18:26:22 CEST] <J_Darnley> Yes. There it is.  Higher precedence
[18:29:53 CEST] <iive> i had no idea the latter is valid C
[18:30:40 CEST] <J_Darnley> It (probably) isn't I made a horrible typo
[18:30:51 CEST] <peloverde> durandal_1707: Any chance we'll see the AAC-LC 960 patch hit the list soon?
[18:31:23 CEST] <atomnuker> I always go for ((uint16_t *)a) + b
[18:32:37 CEST] <iive> btw, I think i had some fun lately with (float*)y[i] lately :D
[18:32:37 CEST] <durandal_1707> peloverde: dunno, its  incomplete
[18:33:24 CEST] <peloverde> It seems pretty complete for LC (just have it turn off SBR). What's still missing?
[18:33:28 CEST] <J_Darnley> Now there's another I'd have to lookup
[18:46:08 CEST] <kierank> wm4: how much do you know about ac3 in hdmi?
[18:46:15 CEST] <kierank> is it just spdif mapping?
[18:47:05 CEST] <JEEB> seems like it? just with more bandwidth. although I haven't dealt with the HW side
[18:47:14 CEST] <JEEB> a lot of stuff seems to use the same APIs
[18:47:29 CEST] <wm4> yes, just put it into a spdif frame
[18:47:38 CEST] <wm4> which I think is defined by IEC 61937?
[18:47:45 CEST] <wm4> and libavformat/spdifenc implements it
[18:47:52 CEST] <wm4> (extremely awkward API, but works)
[18:49:11 CEST] <nevcairiel> 61937 is correct, it just extended the formats supported for HDMI, but same packing as SPDIF
[18:52:37 CEST] <nevcairiel> and i use spdifenc as well, works fine
[18:52:57 CEST] <nevcairiel> its a bit tedious since i dont want it to write to a file, but shrug
[18:53:07 CEST] <kierank> there's no special signalling to signal compressed data?
[18:53:10 CEST] <kierank> or is that ignored in practice?
[18:53:35 CEST] <nevcairiel> there is, whatever audio api you use would have to implement that
[18:53:39 CEST] <wm4> there is signaling, but often enough it's indeed ignored or briken
[18:53:46 CEST] <wm4> broken even
[18:53:50 CEST] <JEEB> them headers, right?
[18:53:57 CEST] <nevcairiel> for HD formats it seems to work
[18:54:11 CEST] <kierank> JEEB: there's also sometimes a flag that goes with the headers
[18:54:19 CEST] <kierank> but in aes3 (pro spdif) it doesn't seem to matter if they are there
[18:54:20 CEST] <nevcairiel> for the spdif-comptible formats .. you can claim its ac3 and send dts and it still works
[18:54:25 CEST] <kierank> ok
[18:54:29 CEST] <JEEB> hah
[18:56:03 CEST] <wm4> on some OSX you sometimes have to send ac3 data as floats (doing the proper int->float conversion) to get passthrough
[18:56:11 CEST] <wm4> broken shitty consumer garbage
[18:56:41 CEST] <nevcairiel> osx is generally terrible, they only implemented int audio as an addon later
[18:56:48 CEST] <nevcairiel> and then called it a feature
[18:57:38 CEST] Action: J_Darnley goes afk
[18:58:05 CEST] <wm4> I should try whether passthrough of "HD" formats is possible yet, somehow
[19:04:29 CEST] <peloverde> Is the info that used to be in config.log kept around somewhere?
[19:07:07 CEST] <JEEB> it's in a subdirectory now
[19:09:03 CEST] <peloverde> JEEB: thanks
[19:34:03 CEST] <peloverde> durandal_1707: This hunk should conceal up the HE-AAC artifacts https://pastebin.com/de2HxZWt
[21:03:27 CEST] <cone-729> ffmpeg 03Derek Buitenhuis 07master:5ca063799c16: rtspdec: Fix return error
[21:11:17 CEST] <kierank> BBB: had any time to look at my sample?
[21:11:28 CEST] <BBB> not that quickly yet, sorry :(
[21:11:31 CEST] <BBB> hopefully later this week
[21:11:35 CEST] <kierank> still not sure how to fix it without modifying source thread
[21:11:36 CEST] <kierank> ok
[21:11:45 CEST] <kierank> might send end user a temporary fix of setting threads=1
[21:14:30 CEST] <BBB> does the source thread know anything in advance about passing the data to the second thread?
[21:14:49 CEST] <BBB> who adds the side data to the avframe? thread 1 or 2?
[21:15:11 CEST] <BBB> (first or second in order of field decoding in terms of incoming data, no in terms of field order)
[21:15:21 CEST] <BBB> s/no/not/
[21:31:01 CEST] <kierank> field 2
[21:31:15 CEST] <kierank> i.e the thread that actually outputs an AVFrame
[21:49:26 CEST] <J_Darnley> atomnuker: what?  encode_subband appears to encode in a linear manner.
[21:49:35 CEST] <J_Darnley> for y; for x; coeff[x] ...
[21:51:28 CEST] <J_Darnley> 1000gg
[21:52:21 CEST] <J_Darnley> whoops, wrong keyboard
[21:54:12 CEST] Action: J_Darnley curses how he got roped into looking after a cat and a rabbit
[22:03:26 CEST] <Compn> just put them in same room and then you'll only have to deal with the cat
[22:53:01 CEST] <durandal_1707> michaelni: do you know how to modify mjpeg bits generation so it creates lengths for 0 probable symbols?
[00:00:00 CEST] --- Tue Jul 11 2017