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

[burek]

[00:01:08 CET] <durandal_170> unholy_me: filter initialization and parameters checking
[00:01:54 CET] <durandal_170> unholy_me: search tree there is doc about writing new filters
[00:04:26 CET] <unholy_me> ok found it
[00:04:32 CET] <unholy_me> it is at dead bottom
[00:05:10 CET] <unholy_me> i wanted to ask about this af_pan
[00:05:23 CET] <unholy_me> is this only working on one channel?
[01:04:05 CET] <cone-768> ffmpeg 03Michael Niedermayer 07master:4b72d5cd6f93: avcodec/mjpegdec: Fix runtime error: left shift of negative value -511
[01:04:05 CET] <cone-768> ffmpeg 03Michael Niedermayer 07master:3b0b35150df4: avcodec/mpegaudiodec_template: Fix runtime error: signed integer overflow: 2053224902 + 2053224902 cannot be represented in type 'int'
[01:04:05 CET] <cone-768> ffmpeg 03Michael Niedermayer 07master:6191198c216e: avcodec/interplayvideo: Fix timeout from lack of bitstream end check
[01:04:05 CET] <cone-768> ffmpeg 03Michael Niedermayer 07master:55196e5d10af: Revert "avutil/frame: Disallow zero sized frame side data"
[01:04:33 CET] <unholy_me> ok i finally created my own filter
[01:05:18 CET] <unholy_me> now how are we handling multiple channels?
[02:05:51 CET] <cone-768> ffmpeg 03Carl Eugen Hoyos 07master:9ae762da7e25: lavf/matroska: Support codec ID V_FFV1 for demuxing.
[09:09:28 CET] <wm4> going to push those filter merger patches
[09:09:32 CET] <wm4> anyone want to stop me?
[09:09:38 CET] <wm4> you have 10 mins or so
[09:10:34 CET] <nevcairiel> did you get the crashing sample from michael
[09:13:43 CET] <wm4> yes
[09:15:11 CET] <nevcairiel> i assume its fixed by the top commit in your branch?
[09:15:23 CET] <wm4> yes
[09:15:37 CET] <wm4> just repushed the newest version
[09:17:41 CET] <nevcairiel> no complaints from me then
[09:30:01 CET] <cone-574> ffmpeg 03wm4 07master:33580a8625c7: ffmpeg: make sure packets put into the muxing FIFO are refcounted
[09:30:01 CET] <cone-574> ffmpeg 03Anton Khirnov 07master:4ee5aed122ba: ffmpeg: do packet ts rescaling in write_packet()
[09:30:01 CET] <cone-574> ffmpeg 03Anton Khirnov 07master:af1761f7b5b1: ffmpeg: init filtergraphs only after we have a frame on each input
[09:30:01 CET] <cone-574> ffmpeg 03wm4 07master:97614a68e474: ffmpeg: fix printing of filter input/output names
[09:30:01 CET] <cone-574> ffmpeg 03Anton Khirnov 07master:cb884f8d7e3b: ffmpeg: move flushing the queued frames to configure_filtergraph()
[09:30:02 CET] <cone-574> ffmpeg 03Anton Khirnov 07master:76e13bdeaabc: ffmpeg: restructure sending EOF to filters
[09:30:02 CET] <cone-574> ffmpeg 03Timo Rothenpieler 07master:736f4af4fea4: ffmpeg_cuvid: adapt for recent filter graph initialization changes
[09:30:03 CET] <cone-574> ffmpeg 03wm4 07master:7dd44cde2abb: ffmpeg: delay processing of subtitles before filters are initialized
[09:30:03 CET] <cone-574> ffmpeg 03wm4 07master:16abc10b0997: ffmpeg: properly cleanup filter graph on init failure
[09:44:58 CET] <ubitux> nice
[09:45:08 CET] <ubitux> thx wm4
[09:46:12 CET] <mateo`> thanks :)
[09:46:15 CET] <ubitux> wm4: so, how many commits can we skip in the next merge?
[09:46:53 CET] <wm4> I don't know, those were 4 merged commits
[09:47:09 CET] <ubitux> we're almost at 1k commits to merge
[09:47:21 CET] <wm4> I'll probably look at the hwaccel threading ones next (at least those are pretty self-contained)
[09:49:55 CET] <ubitux> wm4: you're not going to like the last mail from Carl, i'm sorry
[09:50:14 CET] <ubitux> i'm calling for ignoring him
[09:54:46 CET] <mateo`> seriously ?
[09:55:33 CET] <mateo`> what he is trying to achieve there ...
[09:55:35 CET] <wm4> "braking"
[09:55:38 CET] <wm4> so I'm slowing him down?
[09:59:12 CET] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-February/207648.html damnit i missed that one too
[10:12:07 CET] <wm4> that last case, dvbsubtest.ts, actually works now with my patches applied if the target container is mkv
[10:12:19 CET] <ismail> Compn: done, thanks!
[10:12:28 CET] <wm4> it failed with "Application provided invalid, non monotonically increasing dts" before
[12:29:24 CET] <cone-574> ffmpeg 03Paul B Mahol 07master:6d93e7d1a3e6: avcodec/scpr: fix top left prediction for special case when x is 0 for keyframes
[15:14:58 CET] <J_Darnley> Is it worthwhile making and submitting a couple of patches to change/fix cosmetic issues in libavcodec/h264idct_template.c?
[15:17:31 CET] <jamrial> if they change one or two lines then no, but if you're reindenting a lot of things or such then yes
[16:02:33 CET] <J_Darnley> Ha ha ha damn!  What did I do to make ffmpeg crash in libc's malloc_consolidate?
[16:02:38 CET] <J_Darnley> Come here valgrind
[16:02:44 CET] <JEEB> sounds like fun :D
[16:06:51 CET] <J_Darnley> Hm.  Invalid write of 8 in ???
[16:10:48 CET] <BBB> youre writing past buffer size i think
[16:10:53 CET] <BBB> in your assembly
[16:11:27 CET] <J_Darnley> Yeah, but the stack doesn't look like where the function I was working on is called
[16:12:00 CET] <J_Darnley> But it is caled though a function pointer passed at from at least 3 functions higher
[16:12:29 CET] <BBB> try asan
[16:12:37 CET] <BBB> asan detects stack overwrites better than valgrind
[16:13:06 CET] <J_Darnley> Thanks.  I'll do that after valgrind finished running with my function removed
[16:25:25 CET] <J_Darnley> Why on earth am I doing that on my cheap(ish) laptop when I could be doing it on a big and powerful server?
[16:26:01 CET] <nevcairiel> convenience of local work?
[16:26:08 CET] <J_Darnley> Indeed
[16:27:32 CET] <jkqxz> The big and powerful server doesn't have AVX2?
[16:29:36 CET] <jkqxz> The bigger Intel cores lagging behind on features like that is kindof annoying, though maybe AVX-512 is indicating a change of strategy there.
[16:30:44 CET] <J_Darnley> Meh, a way to cut up their offering to maximise profit I guess.
[16:32:52 CET] <nevcairiel> AVX2 is old enough by now, though
[16:34:04 CET] <nevcairiel> anyhow the bigger cores don't necessarily lag behind in features, they just generally lag behind in release dates. It takes often over a year for the big variants of a chip to be released, with the same features as the consumer variant then.
[16:35:22 CET] <J_Darnley> What I am most gutted about is their low end ones not having avx/avx2.  I want avx and ecc on the cheap.
[16:35:41 CET] <nevcairiel> dont you have to go very low end for those to be cut out
[16:35:57 CET] <nevcairiel> thats basically atom cores then isnt it, no wonder, different core entirely =p
[16:36:07 CET] <J_Darnley> avx is missing in pentium and celeron, but those both have ecc
[16:36:22 CET] <nevcairiel> they make ecc pentiums and celerons?
[16:36:23 CET] <jkqxz> No, you have to go low-end for ECC on consumer cores (don't want to eat into the server market).
[16:36:38 CET] <jkqxz> Core iN no longer has ECC anywhere.
[16:36:45 CET] <nevcairiel> low-end e3 cpus are usually not that expensive
[16:36:58 CET] <nevcairiel> do they even have consumer mainboards with ecc support
[16:37:44 CET] <J_Darnley> Allegedly
[16:38:00 CET] <J_Darnley> Not the registered kind
[16:38:18 CET] <nevcairiel> thats only supported in xeons anyway, isnt it
[16:38:36 CET] <nevcairiel> and e5 and above only
[16:38:41 CET] <nevcairiel> (ie. the proper xeons)
[16:39:44 CET] <nevcairiel> cheapest skylake xeon e3 is 190¬, not that bad, but still more then some  pentium i guess
[16:41:37 CET] <J_Darnley> That seems pretty reasonable.
[16:42:54 CET] <jkqxz> Still more than twice the price of the most expensive pentium (which has fewer but faster cores, uses less power, and has free graphics for extra floppiness should you be that way inclined).
[16:43:53 CET] <nevcairiel> could pay 30 or so more for the igpu
[16:44:20 CET] <J_Darnley> I was eyeing the G3930 or G4650 for ~¬40 and ~¬60
[16:44:29 CET] <nevcairiel> it seems odd that they allow the pentiums and celerons to have ecc
[16:44:36 CET] <nevcairiel> seems like a odd feature to have in those
[16:44:55 CET] <J_Darnley> Maybe the low power T variant if they become available
[16:45:07 CET] <nevcairiel> dont those typically even cost more
[16:45:12 CET] <nevcairiel> just buy a normal and downclock it =p
[17:07:53 CET] <J_Darnley> Oh cock.  fate needs the lavfi input "device"
[17:13:09 CET] <nevcairiel> yeah its used to generate test data
[17:13:50 CET] <J_Darnley> I guess I was just surprised to learn that it is a device
[17:14:06 CET] <nevcairiel> you might as well call it a "demuxer"
[17:14:12 CET] <nevcairiel> none of the words fit very well
[17:14:51 CET] <J_Darnley> Meh.  It is a device because ffmpeg/configure calls it a device.
[17:18:38 CET] <cone-574> ffmpeg 03Takayuki 'January June' Suwa 07master:13332504c989: omx: Add support for specifying H.264 profile [v5']
[17:18:39 CET] <cone-574> ffmpeg 03Michael Niedermayer 07master:d8094a303ba3: avcodec/vp3: Do not return random positive values but the buf size
[17:24:18 CET] <Guest7213> durandal_1707: I have re-forked, applied patch, and freshly compiled the FFmpeg repository, please tell what I should do next?
[17:25:21 CET] <durandal_1707> does it displays xpm with ffplay?
[17:26:00 CET] <durandal_1707> patebin output of  git diff master
[17:26:28 CET] <adeeln_> durandal_1707: okay
[17:30:50 CET] <adeeln_> durandal_1707: Here is the output of 'git diff master': https://gist.github.com/adl1995/a9d78dc9de8891582854ef669c558c8f
[17:32:28 CET] <durandal_1707> adeeln_: you forgot to add libavcodec/xpmdec.c to your branch
[17:32:38 CET] <durandal_1707> same for xpmenc.c
[17:35:09 CET] <adeeln_> durandal_1707: oh, I didn't commit. Do I commit to the same master branch (just want to be sure).
[17:38:31 CET] <cone-574> ffmpeg 03James Almer 07master:e2b7ae4b198c: avutil/md5: fix misaligned reads
[17:38:32 CET] <cone-574> ffmpeg 03James Almer 07master:a43389547c51: avutil/md5: stop discarding the const qualifier for the src pointer
[17:40:40 CET] <Miles> Anyone here involved in user documentation? Noticed an ommission for the flac encoder.
[17:41:22 CET] <Miles> The numeric range for compression_level isn't mentioned which is kind of important since the one in ffmpeg goes from 0-12 unlike every other encoder.
[17:42:31 CET] <durandal_1707> adeeln_: do not touch master branch
[17:42:50 CET] <durandal_1707> adeeln_: on which branch you are working?
[17:44:36 CET] <adeeln_> durandal_1707: I've added the patch on master branch, but I haven't commited yet.
[17:44:53 CET] <adeeln_> durandal_1707: should I create a new branch?
[17:45:00 CET] <jamrial> Miles: thanks, will fix that
[17:46:13 CET] <Miles> jamrial: Cool, thanks for looking into it. Just to be clear I mean over here but it may be missing in other relevant places too
[17:46:13 CET] <Miles> https://ffmpeg.org/ffmpeg-codecs.html#flac-2
[17:46:37 CET] <Miles> Actually I don't thin -h encoder=flac mentions the compression_level parameter at all let alone a range
[17:47:03 CET] <jamrial> that's because compression_level is a generic option used by many encoders
[17:47:25 CET] <jamrial> it's not specific to flac
[17:47:37 CET] <nevcairiel> its an unfortunate limitation of our option system
[17:47:48 CET] <Miles> But it has different meanings and valid ranges for different encoders? Seems worth putting in the encoder command line help.
[17:47:52 CET] <Miles> Oh I see.
[17:48:26 CET] <nevcairiel> global options that are re-used by many things dont get codec-specific docs
[17:50:00 CET] <Miles> Where can I learn more about why it goes to 12 and what each preset does? flacenc.c in libavcodec didn't tell me a whole lot.
[17:50:21 CET] <cone-574> ffmpeg 03James Almer 07master:68ee800a9dd9: doc/encoders: mention valid values for compression_level when using FLAC encoder
[17:51:42 CET] <nevcairiel> the code basically has it, but its not documented i dont think
[17:52:03 CET] <nevcairiel> changes block size, lpc type,  min/max prediction order, and prediction order method
[17:52:15 CET] <nevcairiel> oh and partition order
[17:52:54 CET] <Miles> Can I assume 12 is technically most efficient if not overkill?
[17:53:04 CET] <nevcairiel> http://pastebin.com/4nNjhU14 this basically, level is always an index into the tables
[17:53:20 CET] <jamrial> flac is so fast that no matter what you choose it will never be overkill
[17:53:31 CET] <nevcairiel> unless you u se the alien mode
[17:53:44 CET] <nevcairiel> (multi_dim_quant)
[17:53:46 CET] <nevcairiel> it can get slow
[17:54:55 CET] <durandal_1707> adeeln_: if your current branch is master, create new branch
[17:54:57 CET] <Miles> Oh the source is making a little more sense to me now, I see those 12-arrays corresponding to compression level.
[17:56:14 CET] <Miles> Thanks nevcairiel and jamrial, I think I'm good for now.
[17:57:19 CET] <adeeln_> durandal_1707: okay, creating new branch and commiting to it.
[17:58:13 CET] <jamrial> Miles: but yes, 12 is best compression
[17:58:47 CET] <jamrial> it is considerably slower than 0, admitedly, but only for encoding
[17:59:01 CET] <jamrial> there doesn't seem to be a difference when decoding the resulting files
[18:01:48 CET] <Miles> jamrial: Ok
[18:07:43 CET] <durandal_1707> adeeln_: now commit changes in it and paste diff
[18:12:31 CET] <adeeln_> durandal_1707: just did, please check: https://gist.github.com/adl1995/5b3f681ba2c710915cc6cf567d3cdb83
[18:28:23 CET] <J_Darnley> Can someone help me understand this message from gcc asan? http://pastebin.com/Ah1PYkpb
[18:28:48 CET] <J_Darnley> Can I have it print function names?
[18:46:37 CET] <kierank> J_Darnley: you have to use asan symboliser
[18:52:54 CET] <atana> michaelni, in ff_generate_window_func (float *lut, int N, int win_func, float *overlap) win_func -> WFUNC_HAMMING  what other parameters refers to? is there any example where is it used?
[18:53:27 CET] <kierank> J_Darnley: 5:46 PM <"kierank> J_Darnley: you have to use asan symboliser
[18:56:03 CET] <michaelni> atana, you can find occurances / uses of something with git grep ff_generate_window_func
[18:56:36 CET] <atana> ok
[19:34:38 CET] <JEEB> wm4: did your merge move the initialization of encoders later?
[19:35:08 CET] <JEEB> so in theory now in ffmpeg.c some stuff like utvideo.c might be able to get the colorimetry as it's already available @ init()
[19:35:15 CET] <JEEB> *utvideoenc.c
[19:43:50 CET] <nevcairiel> yes JEEB
[19:44:39 CET] <JEEB> \o/
[19:48:51 CET] <J_Darnley> kierank: thank you
[19:52:42 CET] <JEEB> hmm
[19:52:52 CET] <JEEB> well, seems like I am not getting love yet
[19:52:59 CET] <JEEB> with 68ee800
[19:53:24 CET] <nevcairiel> maybe the info is lost in a filter or something?
[19:53:33 CET] <nevcairiel> it sh ould create the encoder only after decoding a input frame
[19:53:35 CET] <nevcairiel> so it has all info
[19:54:46 CET] <JEEB> http://up-cat.net/p/e125038d
[19:55:32 CET] <JEEB> it should pick !ULY0 in case of BT.709
[19:55:41 CET] <JEEB> so during init() it still doesn't have the colorimetry
[19:55:53 CET] <JEEB> (pretty much a special case where the container contains the darn metadata)
[20:06:26 CET] <jkqxz> JEEB:  That information is on the frames, not the codec?  I don't think anything in the change actually picks that metadata off the frame itself.
[20:07:22 CET] <JEEB> not sure which value I used in init() (where that has to be set so it gets passed onto the AVI muxer early enough)
[20:07:27 CET] <JEEB> let me check
[20:07:46 CET] <JEEB> yeah, avctx->pix_fmt
[20:07:57 CET] <JEEB> as you only start getting frames @ process_frame()
[20:08:07 CET] <jkqxz> The stream is initialised when you have output from the decoder, but before you pick the first frame from the filter graph <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg.c;h=db7e8cd0c6723bbdefbb8d604d5131e7da3db31f;hb=HEAD#l1437>.
[20:09:07 CET] <jkqxz> So the extra parameters you are gaining here are from the decoder context, but any which only got attached to the individual frames will be lost.
[20:09:47 CET] <jkqxz> Well, not lost: are still missing.
[20:11:20 CET] <jkqxz> It would take a bit more work to push the output stream initialisation back even further, so that you have the first frame from the filter graph available as well and can use the colour information from it.
[20:12:19 CET] <JEEB> hmm, I don't think there was a filter in the middle
[20:12:25 CET] <JEEB> it was just yuv420p to yuv420p
[20:17:23 CET] <jkqxz> You get a filter graph anyway in transcode.
[20:17:31 CET] <JEEB> right
[20:18:53 CET] <nevcairiel> I thought things are actually initialized from the frame themself
[20:18:55 CET] <nevcairiel> not from any context
[20:19:04 CET] <nevcairiel> so you would need to have some kind of frame done already
[20:19:46 CET] <adeeln_> durandal_1707: please check: https://gist.github.com/adl1995/5b3f681ba2c710915cc6cf567d3cdb83
[20:19:48 CET] <jkqxz> That's the input to the filter attached to the output stream.
[20:20:16 CET] <JEEB> in formats where the initialization of colorspace information is coded into the video stream itself it can be in the actual encode() calls
[20:20:36 CET] Action: JEEB wonders why umezawa went for separate fourccs instead
[20:42:44 CET] <J_Darnley> Ugh.  I'm sure it is user error but I think this asan stuff is rubbish.
[20:42:47 CET] <J_Darnley> I have no idea what its doing and most of my searches get corrected into "asian symbol".
[20:44:19 CET] <nevcairiel> JEEB: guess that information isnt actually transfered to an encoder, ffmpeg.c would probably need to explicitly do that somehow
[20:46:18 CET] <nevcairiel> but it can do that now!
[20:46:28 CET] <JEEB> yea
[20:46:35 CET] <JEEB> totally a step to a better future
[20:56:55 CET] <atomnuker> I need ideas for a gsoc project
[20:57:58 CET] <jamrial> improvements to your opus encoder?
[20:58:10 CET] <michaelni> Ive sent invites for gsoc mentoring to everyone listed on the ideas page, if someone has been missed ping me, if someone is added to the page and needs a invite ping me
[20:59:17 CET] <jamrial> make the vorbis encoder not suck. make the dca encoder not suck and also write bitexact dts-ma streams (maybe also other extensions like dts-es or dts-hra)
[20:59:26 CET] <jamrial> fix the truehd encoder so it's actually bitexact
[20:59:40 CET] <michaelni> also i need a backup mentor for "Minterpolate improvments" (DSM might be the student for this one)
[21:03:43 CET] <atomnuker> jamrial: danail's already working on the dca encoder, so I guess I'll put both truehd and vorbis up there
[21:15:36 CET] <jamrial> atomnuker: the truehd encoder is recent and supposedly has a maintainer (one of the two authors), so probably better poke them about it first
[21:16:28 CET] <atomnuker> yeah, only listed the vorbis one
[21:16:53 CET] <atomnuker> also I'm not sure that it deserves an entire gsoc project since I think its a one line fix somewhere
[21:30:35 CET] <ember3> is the motion vector computation approach in https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/extract_mvs.c as fast as could be expected? it runs at only 2.9x realtime
[21:32:26 CET] <ember3> (also notice it's using many deprecated things like avcodec_decode_video2)
[21:33:50 CET] <wm4> yeah, the examples and even ffmpeg.c have a bad track record at using deprecated APIs
[21:34:18 CET] <ember3> presumably it should be consuming avcodec_receive_frame
[21:34:31 CET] <wm4> yes
[21:34:50 CET] <ember3> would there be a dramatic speed difference?
[21:34:51 CET] <wm4> OTOH the deprecated one will still work for a long time
[21:34:54 CET] <wm4> no
[21:35:13 CET] <wm4> could even get slower if you e.g. don't pass a refcounted input buffer (to ...send_packet)
[21:35:20 CET] <ember3> really don't understand why it's so slow, haven't started digging through the internals yet
[21:35:42 CET] <wm4> probably because it decodes the whole video? whatever you're doing
[21:38:17 CET] <ember3> wall clock of 2.9x is on the example, reading a 41mb mp4 and writing to /dev/null
[21:44:30 CET] <ubitux> ember3: yes it needs to decode the video to extract the mvs
[21:45:06 CET] <ubitux> at some point it was considered to skip the idct etc, but it required hacking quite excessively the decoder
[21:45:22 CET] <ubitux> and you won't be able to skip the entropy step anyway
[21:48:12 CET] <ember3> will it in theory run the decoding through hwaccel if hardware is available?
[21:49:35 CET] <JEEB> uhh
[21:49:41 CET] <JEEB> how do you get that data from a hw decoder?
[21:49:52 CET] <JEEB> it's stuff that is explicitly gotten from the insides of that decoder
[21:50:11 CET] <JEEB> so unless you get such surgical access into the internals of a hw decoder then there's no way of doing that
[21:52:10 CET] <ubitux> using hwaccel means you're skipping the software decoding so you won't get the mvs as they are obtained from the software decoder
[21:52:28 CET] <ubitux> so hw decoder seems to expose them somehow, i think there was some rpi/android crap stuff about this
[21:52:35 CET] <ubitux> some*
[21:52:41 CET] <ubitux> but not supported in ffmpeg
[21:52:48 CET] <ember3> you can get that out as side information..
[21:52:50 CET] <ember3> https://www.raspberrypi.org/blog/vectors-from-coarse-motion-estimation/
[21:52:51 CET] <ember3> yeah
[21:52:53 CET] <ubitux> (not the rpi accel. the mvs exposition)
[22:30:05 CET] <DSM_> ubitux: as hwaccel don't give motion vectors, how about using a filter for mvs
[22:30:08 CET] <DSM_> https://ffmpeg.org/ffmpeg-filters.html#mestimate
[22:30:37 CET] <JEEB> ember3 was trying to get the coded vectors :P
[22:31:09 CET] <DSM_> okay
[22:31:11 CET] <ember3> I really just want the lowest motion frames within a time interval
[22:31:13 CET] <wm4> DSM_: how does this compare to mvtools anyway?
[22:31:28 CET] <ubitux> DSM_: mestimate is not mature enough; last time i tried it was slow and had bad results
[22:31:29 CET] <ember3> seems like working from motion vectors would be simplest
[22:32:16 CET] <ubitux> DSM_: also, i suppose it's in the context where you don't have the necessary computing resources available so you want to reuse mvs to have a quick & dirty result
[22:33:38 CET] <wm4> yeah, codec mvs can apparently be bad for motion estimation, since they optimize for reducing redundancy, not detecting motion
[22:33:42 CET] <ubitux> so reusing already estimated data is a good idea, but in practice if your platform don't have much processing resources, it's likely it won't have enough to software decode the video
[22:33:45 CET] <JEEB> wm4: yup
[22:33:47 CET] <wm4> so the mvs can be all over the place
[22:38:40 CET] <ember3> wm4: has that effect been formally characterized somewhere? motion visualizations from codec mvs are pretty compelling to the naked eye
[22:43:31 CET] <jkqxz> The best result is very bitrate-dependent.  At low bitrates you end up smoother than reality, because the motion is predicted from nearby motion (spatial, also temporal in newer codecs) and therefore it minimises bit use to just take the prediction and use it (possible with some of fudging of the residuals).
[22:43:54 CET] <ubitux> it depends on the encoder and its options too
[22:44:09 CET] <jkqxz> At high bitrates the opposite happens - since the motion encoding is much less significant, you place it minimise residuals and fuck how well it matches the prediction.
[22:44:12 CET] <ubitux> you'll have frame with no mvs btw
[22:44:39 CET] <ubitux> if you have computing power, you better go for your own optical flow
[22:45:17 CET] <ubitux> if you're on embedded devices i'd actually also be tempted to go in something similar exploiting at best the hw chip available
[22:45:47 CET] <ubitux> mvs from ffmpeg are ok for experimenting but the main goal is debugging (see codecview filter)
[22:51:14 CET] <DSM_> ubitux: i don't know how fast hwaccel decoding + mestimate can be compared to software decoding. of course choice depends on application. mestimate uses motion_estimation.c functions, which were intended to be used in both filters and codecs
[22:51:28 CET] <DSM_> can you please suggest to make them more mature?
[22:52:17 CET] <ubitux> DSM_: nothing more than what i raised on the ml
[22:52:23 CET] <DSM_> apart from speed optimizations
[22:53:04 CET] <ubitux> apart from speed the mvs where not convincing at all; i remember sharing a sample
[22:53:10 CET] <ubitux> or two
[22:53:51 CET] <ubitux> anyway, if you use hw decoding on embedded system, you likely want to avoid going back to cpu world
[22:57:16 CET] <DSM_> ubitux: on ml? on motion interpolation thread iirc? 
[22:57:32 CET] <ubitux> yes, iirc you even answered
[22:58:25 CET] <DSM_> yeah :D probably it
[22:58:37 CET] <DSM_> *it's because of penalty
[22:58:42 CET] <philipl> BtbN: do you have an opinion on the nvenc constant quality question I asked? p vs b vs i values?
[22:59:11 CET] <BtbN> The one weather the values for p/b should differ from the I one?
[23:01:54 CET] <BtbN> I don't really have an idea what's the right solution there.
[23:24:13 CET] <philipl> Yeah, that one.
[00:00:00 CET] --- Sat Mar  4 2017