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

[burek]

[01:10:58 CET] <jkqxz> jamrial:  Sent a new version.
[01:12:51 CET] <jamrial> jkqxz: can't see it in my inbox yet, but will test it once it's there, thanks
[01:32:16 CET] <jkqxz> jamrial:  Did you have any thoughts on including some AV1 streams in fate for testing?
[01:33:29 CET] <jamrial> jkqxz: the aom testsuite is pretty barebones (just different quantizer setting during encoding), but it's enough for some basic tests
[01:34:18 CET] <jamrial> aside from those, we could include some of the small samples i created using Tears of Steel to test parsing things like error resilence and redundant frame headers, timing info using decode model, and such
[01:39:30 CET] <cone-223> ffmpeg 03Mark Thompson 07master:34429182b931: configure: Fix av1_metadata BSF dependency
[01:41:34 CET] <jamrial> jkqxz: https://pastebin.com/qAxM1zBc
[01:42:15 CET] <jamrial> file is unreadable after that. libaom can't read it, and i can't seem to get the ivf demuxer to output anything
[01:42:56 CET] <jkqxz> Since it's read in order you lose the first tile group.
[01:43:27 CET] <jkqxz> I was looking at trace_headers to show that the redundant frame header was used correctly.
[01:43:54 CET] <jamrial> i did an av1_metadata passthrough and it works after your patch. checksum matches
[01:44:19 CET] <jamrial> before it would crash and burn
[01:44:49 CET] <jkqxz> Yep, your file passes through to be identical.  I don't have any others to try, though.
[01:45:30 CET] <jamrial> you can create them with aomenc by using error resilence mode with 2+ tile groups
[01:45:58 CET] <jamrial> that's the only case where it adds redundant frame headers in between each tile group on every frame except key frames
[01:57:16 CET] <cone-223> ffmpeg 03James Almer 07master:89a0d33e3a53: avcodec/cbs_av1: fix decoder/encoder_buffer_delay variable types
[02:07:28 CET] <cone-223> ffmpeg 03James Almer 07release/4.1:1c98cf4ddd38: avformat/ivfenc: use the av1_metadata bsf to insert Temporal Delimiter OBUs if needed
[02:07:29 CET] <cone-223> ffmpeg 03Mark Thompson 07release/4.1:acd13f12556b: configure: Fix av1_metadata BSF dependency
[02:07:30 CET] <cone-223> ffmpeg 03James Almer 07release/4.1:398a70309e4f: avcodec/cbs_av1: fix decoder/encoder_buffer_delay variable types
[02:18:06 CET] <nicolas17> can ffmpeg read AV1 without extra libraries?
[02:18:12 CET] <jkqxz> If I made the bit comparison come one byte at a time rather than one bit at a time would that be better?
[02:20:07 CET] <jkqxz> It could certainly be suppressed by splitting into read/write branches and just doing the necessary bit(read|write)er operations, but I think it's preferable to show something there.
[02:21:12 CET] <jkqxz> Wrt refcounting, yes for read only.  Again it needs to split the read/write branches out further, so code becomes even more horrible.
[02:21:24 CET] <jkqxz> nicolas17:  Depends what you mean by "read".
[02:24:59 CET] <jamrial> nicolas17: decode? no. Parse, extract, remux? yes
[02:47:32 CET] <BBB> nicolas17: for av1, some of us decided to write the decoder outside ffmpeg, so its a library to be linked in. some others are planning to eventually integrate the code directly into ffmpeg, which is fine but not yet done
[13:41:32 CET] <dualz> I'm writing a filter that takes two inputs and has two outputs (audio and video). I noticed that filters with two input pads do not receive a filter_frame call back. Upon further reading it says I should use activate() so I messed around trying to get it to work and am dropping frames. I saw an example of a filter with multiple inputs (streamselect) and they use FrameSync, but FS doesn't work with multiple outputs
[13:43:21 CET] <dualz> A little guidance on how to use activate() would be appreciated. I can't find a single filter that has two inputs and two outputs for an example
[13:45:30 CET] <durandal_1707> dualz: what your filter will do that it needs 2->2 ?
[13:46:37 CET] <dualz> for the time being I want a simple pass through
[13:47:00 CET] <durandal_1707> framesync as name says, is for receiving synced frames from all inputs, eg, it will buffer to match same time before filtering
[13:48:29 CET] <durandal_1707> dualz: afir filter have 2 audio inputs and audio output + video output, but its very specific usecase
[13:49:11 CET] <durandal_1707> so doing only passthrough with activate is easy
[13:49:40 CET] <dualz> is there a writeup somewhere that'll help?
[13:50:04 CET] <durandal_1707> just consume frame from all inputs and output what you want with whatever pts you seem fit
[13:51:35 CET] <durandal_1707> look at concat filter
[13:51:55 CET] <durandal_1707> and feel free to ask questions if something is not clear
[13:52:03 CET] <dualz> so activate { for each input { consume_frame } then for each output filter_frame } ?
[13:52:18 CET] <durandal_1707> ff_filter_frame
[13:52:27 CET] <dualz> can I call filter frame twice in one activate?
[13:54:10 CET] <durandal_1707> dualz: activate does one thing only per call, so better no, best is output one frame and then have state what to push when
[13:54:56 CET] <durandal_1707> also you need to signal that you need frames from inlinks
[13:55:16 CET] <durandal_1707> and need to handle eof on inlinks and outlinks
[13:58:07 CET] <dualz> if activate does one thing, how do I know to consume my audio input or my video input
[13:58:50 CET] <dualz> sorry for the noob questions, I just started with ffmpeg
[14:00:54 CET] <durandal_1707> dualz: by keeping state in some variable in filter private context
[14:01:25 CET] <durandal_1707> and you can consume both video and audio at same time if its availabe
[14:01:37 CET] <durandal_1707> just not output both...
[14:05:03 CET] <dualz> so I consume both audio and video, I now how a AVFrame* video and *audio when is the best time to output these
[14:05:28 CET] <dualz> if I can only output 1 per activate
[14:06:30 CET] <dualz> store a reference in my filter context then wait for the next activate?
[14:06:32 CET] <durandal_1707> you keep track of consumed frames in context, if you filter out consumed frame, you set it to NULL, so you need to pick new one, if its not NULL you output it
[14:15:51 CET] <dualz> durandal_1707: is this the right idea https://gist.github.com/ryanmarin/213606922dff8fd0ae1a513727260483
[14:16:54 CET] <dualz> with this design will there ever be a activate() call where ctx.abuf is null and it'll try to output ctx.vbuf
[14:18:46 CET] <durandal_1707> dualz: ff_inlink_consume_frame may return 0 if there is no frame available
[14:19:27 CET] <durandal_1707> also your gist have wrong check for null/0 case
[14:20:08 CET] <durandal_1707> also you do not need to consume all at once, just when you need it
[14:20:28 CET] <dualz> how would i know when i need it
[14:23:03 CET] <durandal_1707> dualz: ff_outlink_frame_wanted()
[14:23:30 CET] <durandal_1707> you call that that to check if next filter in chain wants frame
[14:24:54 CET] <durandal_1707> and if you need frame from inlink you call ff_inlink_request_frame()
[14:37:53 CET] <dualz> durandal_1707: https://gist.github.com/ryanmarin/083afed8e909167da24d119d662ab6bf closer?
[14:41:58 CET] <durandal_1707> dualz: something like that, missing eof handling and forwarding outlink status to other links
[14:42:41 CET] <dualz> will ctx.vbuf ever be null for the ctx.abuf code to run?
[14:44:40 CET] <durandal_1707> you can add check for other buf to not request new one if there is one to output
[14:45:18 CET] <durandal_1707> AV case may have several small audio frames for each video frame
[14:45:59 CET] <durandal_1707> and you can use consume_samples to keep AV in sync
[15:05:32 CET] <cone-321> ffmpeg 03Martin Storsjö 07master:4e9cff282476: libavutil: Undeprecate the AVFrame reordered_opaque field
[15:05:32 CET] <cone-321> ffmpeg 03Martin Storsjö 07master:882ae091d48b: libx264: Pass the reordered_opaque field through the encoder
[15:05:32 CET] <cone-321> ffmpeg 03Martin Storsjö 07master:e7ed9d81bff0: flvdec: Rename FLV_STREAM_TYPE_DATA into FLV_STREAM_TYPE_SUBTITLE
[15:05:32 CET] <cone-321> ffmpeg 03Martin Storsjö 07master:d7638d8dfc3c: flvdec: Export unknown metadata packets as opaque data
[15:10:39 CET] <dualz> ok so I'm looking at consume samples
[15:10:55 CET] <dualz> there's a min and a max argument
[15:11:17 CET] <dualz> where do I get these from?
[15:12:38 CET] <atomnuker> wbs: mate, 882ae091d48b112004b977314884176841f12cef looks very sketchy
[15:12:49 CET] <atomnuker> wouldn't this be better done using side data?
[15:13:26 CET] <atomnuker> would avoid the need for a codec cap flag too
[15:13:49 CET] <atomnuker> but most importantly you wouldn't be stuffing pointers in random avframe fields
[15:14:03 CET] <nevcairiel> this isnt exactly new api, that existed for years
[15:14:10 CET] <nevcairiel> also, read ML if you want to review patches =P
[15:14:10 CET] <wbs> atomnuker: does the encoder already bring side data along from the AVFrame into the AVPacket?
[15:14:32 CET] <wbs> otherwise, yes, that's a bigger and more complete framework for the same thing; reordered_opaque is the old lightweight mechanism
[15:14:52 CET] <wbs> and even then, a codec cap would be needed if you wanted a caller to know whether it really works or not for each encoder
[15:15:02 CET] <atomnuker> old lightweight? its a hack.
[15:15:25 CET] <wbs> feel free to propose patches that does things differently, this has been on the ML for weeks
[15:15:26 CET] <atomnuker> you're putting a random pointer in there
[15:15:54 CET] <durandal_1707> dualz: just use min = max = ff_inlink_queued_samples
[15:15:56 CET] <nevcairiel> its up to the user to specify the content of the field, avcodec does nothing of that sort
[15:16:24 CET] <dualz> ok
[15:16:39 CET] <atomnuker> wbs: I'd rather see this reverted and done properly
[15:16:45 CET] <wbs> atomnuker: what "properly"?
[15:16:49 CET] <atomnuker> side data
[15:17:26 CET] <wbs> atomnuker: I don't stuff pointers into ints anywhere in that patch, even though that's one thing the caller of libavcodec _can_ do if they want to
[15:17:46 CET] <wbs> it's the converse; libavcodec has got an opaque int64_t field you can use. x264 similarly has got a void* you can use
[15:18:09 CET] <wbs> to cater for systems where sizeof(int64_t) > sizeof(void*) I keep the int64_t in a buffer in libavcodec and have x264 point to it
[15:18:22 CET] <nevcairiel> you dont get to ignore the ML for weeks and then cry for a revert when it hits, you missed your chance, besides, this doesn't add any new API or bad hacks that haven't existed before, reordered_opaque is as old as avcodec
[15:19:42 CET] <atomnuker> its a high bandwidth ML, pushing it and saying you can't change it anymore is ridiculous
[15:20:42 CET] <wbs> if you contest the use of reordered_opaque here, you can convince nevcairiel and other external users to remove the mechanism altogether. this is just using the existing api for what it was meant for
[15:22:39 CET] <atomnuker> sure its meant to be opaque but its a bit of a stretch to put a pointer in there
[15:22:50 CET] <nevcairiel> thats the users doing
[15:22:57 CET] <nevcairiel> avcodec does nothing l ike that or even suggests it
[15:23:26 CET] <wbs> atomnuker: I don't put a pointer in there, where do you claim I'm doing that?
[15:24:43 CET] Action: durandal_1707 grabs something... ML is not high bandwidth
[15:27:40 CET] <atomnuker> wbs: erm right, nevermind then, the x264 commit message mislead me
[15:27:57 CET] <atomnuker> nothing wrong here
[15:28:33 CET] <cone-321> ffmpeg 03Mark Thompson 07master:a4fb2b115071: configure: Add missing IVF muxer BSF dependency
[15:28:34 CET] <cone-321> ffmpeg 03Mark Thompson 07master:e9d2e3fdaacb: configure: Add missing V4L2 M2M decoder BSF dependencies
[15:29:05 CET] <wbs> exactly; if our reordered_opaque would have been 32 bit only, we _could_ have considered squeezing it into x264's void* opaque, but we can't, hence the buffer
[16:43:08 CET] <BBB> atomnuker: why would tristans patch be incompatible with simd? arent the two complementary?
[16:43:25 CET] <BBB> atomnuker: his patch basically just adds a branch before calling the simd code, which you need anyway
[16:46:42 CET] <cone-321> ffmpeg 03Valery Kot 07master:be827e1d38cb: libopenh264enc: Handle sample_aspect_ratio
[17:49:41 CET] <atomnuker> BBB: why would you need the branch at all?
[17:49:59 CET] <BBB> thats what the header bit does
[17:50:08 CET] <BBB> when that header bit is set, the bitstream cdfs are non-per-symbol-adaptive
[17:50:29 CET] <BBB> the cpu branch predictor should take care of making that efficient, Id expect
[17:50:33 CET] <atomnuker> yes, but you can avoid the branch by just changing the function pointer to a function which does nothing
[17:50:53 CET] <BBB> that means an extra call
[17:50:57 CET] <BBB> vs. a predictable branch
[17:51:00 CET] <BBB> seems unfavourable
[17:51:02 CET] <BBB> right?
[17:51:21 CET] <atomnuker> I'd disagree in this case
[17:51:32 CET] <BBB> the extra call is slower, right?
[17:52:02 CET] <atomnuker> optimally we'd like to have no function calls at all which means integrating decoding and updating into a single piece of asm
[17:52:46 CET] <atomnuker> yes, its slower, but given how little overhead updating has with simd I'm not sure its even worth doing in pure asm
[17:53:10 CET] <atomnuker> e.g. disabling adaptation
[17:59:48 CET] <BBB> but the two approaches are sort of mutually incompatible, riht?
[18:00:11 CET] <BBB> and youd still need a branch if you wanted the whole function in asm
[18:13:03 CET] <atomnuker> for adaptation I'd say it would be unnecessary
[18:14:52 CET] <atomnuker> as good as a branch predictor is I'd rather not rely on it unless there's no other choice
[18:23:38 CET] <BBB> but an empty function call is worse
[18:23:42 CET] <BBB> so what else do you propose then?
[18:26:42 CET] <JEEB> rcombs: you make me feel dirty
[18:26:50 CET] <rcombs> same
[18:26:53 CET] <JEEB> I had to read through dolby documents
[18:27:09 CET] <rcombs> the sample file I was looking at when I sent that seems to decode as normal-ass HEVC
[18:27:20 CET] <JEEB> yea, it seems to depend on the profile
[18:27:26 CET] <JEEB> for which they made additional boxes, of course
[18:27:36 CET] <JEEB> I linked both specs (ISOBMFF and the general profiles=
[18:27:46 CET] <rcombs> the colors look weird but idk it's an HDR sample, they always try to look ~vibrant~
[18:28:04 CET] <rcombs> it's not like it has a convenient set of color bars I can verify
[18:28:24 CET] <rcombs> and even if it is decoding wrong, I'm gonna assert that something is better than nothing here
[18:36:13 CET] <Gramner> atomnuker: indirect function calls are branches too as far as the branch predictis is concerned
[18:36:39 CET] <Gramner> and indirect branches are predicted worse than normal ones since they can go anywhere, not just two ways
[19:10:09 CET] <cone-321> ffmpeg 03Vittorio Giovara 07master:febaa63b0f7f: proresenc_anatoliy: Rename a profile name with the correct one
[19:10:10 CET] <cone-321> ffmpeg 03Vittorio Giovara 07master:cdc487bfc841: prores: Use profile names in the various encoders and decoders
[19:10:11 CET] <cone-321> ffmpeg 03Vittorio Giovara 07master:aefbb2bf029f: proresdec2: Parse codec_tag and export profile information
[19:10:12 CET] <cone-321> ffmpeg 03Vittorio Giovara 07master:d37faad0cdbb: mjpeg: Use profile names in the encoder and decoder
[22:04:33 CET] <dualz> durandal_1707: I got it working! I just need to test if the audio is falling out of sync or not
[22:10:33 CET] <dualz> can anyone tell me when exactly and at what frequency activate() gets called?
[22:36:03 CET] <cone-309> ffmpeg 03Ruiling Song 07master:952a299fd390: doc/filters: add document for opencl filters
[22:36:03 CET] <cone-309> ffmpeg 03Ruiling Song 07master:a587454fd07c: doc/filters: add tonemap_opencl document.
[23:53:58 CET] <durandal_1707> dualz: whenever is needed, there is set_ready to make it more frequent
[23:55:11 CET] <michaelni> jamrial, are you done with the av1 fixes ? or there is more to wait for ?
[23:56:00 CET] <jamrial> michaelni: two patches by jkqxz on the ml that i already reviewed need to be pushed and backported, and that's it
[23:57:34 CET] <michaelni> jamrial, ok no hurry
[23:59:32 CET] <jkqxz> Just getting that now.
[00:00:00 CET] --- Tue Nov  6 2018