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

[burek]

[00:54:52 CEST] <cone-164> ffmpeg 03Rostislav Pehlivanov 07master:e24c31b65625: dirac_vlc: fix undefined shifts
[00:54:53 CEST] <cone-164> ffmpeg 03Rostislav Pehlivanov 07master:9c0aba434e77: dirac_vlc: remove redundant macro declaration
[00:54:54 CEST] <cone-164> ffmpeg 03Rostislav Pehlivanov 07master:b2b12b2d4ab1: diracdec: fix maximum quantization index checks
[00:54:55 CEST] <cone-164> ffmpeg 03Rostislav Pehlivanov 07master:000eb01a7d14: diracdec: fix unchecked byte length
[01:40:55 CEST] <atomnuker> BBB: so how did vp9 end up with just a very simple scalar quantization?
[01:41:35 CEST] <jamrial> atomnuker: vc2 vsynth fate tests seem broken
[01:42:19 CEST] <atomnuker> huh, tested them on mine before I pushed, let me check again
[01:49:16 CEST] <atomnuker> okay, the first commit broke them, though not sure how, the residue should be zero either way
[01:50:11 CEST] <BBB> atomnuker: its done in-line with actual token decoding, where its essentially negligible, but it saves a load/store pair
[01:50:27 CEST] <BBB> atomnuker: if you wanted, I suppose you could do it in line in the idct but its so neglgible that nobody cares
[01:50:40 CEST] <BBB> its just one op/coef in the token decoding so its really not that important
[01:50:56 CEST] <jamrial> atomnuker: try multiplying instead of shifting. any compiler worth anyne's time will optimize it right
[01:51:04 CEST] <BBB> for most codecs, dequant is a real process with rounding and shifting etc. (e.g. see hevc)
[01:51:12 CEST] <BBB> but vp9 is just one mul op, thats all
[01:51:32 CEST] <atomnuker> yeah, I thought it was kinda odd to see such a simple dequant in this day and age
[01:52:06 CEST] <BBB> dunno
[01:52:08 CEST] <BBB> it works for them :)
[01:54:29 CEST] <TD-Linux> atomnuker, are you excited for PVQ? :)
[01:55:45 CEST] <BBB> I think Im starting to see I totally misunderstood the original question
[01:55:53 CEST] <BBB> you were asking about the coding technique/algorithm, not the code
[01:56:04 CEST] <atomnuker> yeah
[01:56:09 CEST] <BBB> yes quant can be improved quite a bit
[01:56:21 CEST] <BBB> e.g. different quants per band, full quant tables
[01:56:32 CEST] <BBB> esp. for larger transforms
[01:57:01 CEST] <TD-Linux> AV1 has QMs as an option now
[01:57:46 CEST] <TD-Linux> a lot of places in the libvpx encoder assume quantization is free, though, which makes things "interesting"
[02:03:07 CEST] <cone-164> ffmpeg 03Rostislav Pehlivanov 07master:c4adcff97604: dirac_vlc: add a SET_RESIDUE macro and fix recent regression
[02:08:14 CEST] <atomnuker> TD-Linux: I am, but it seems it'll take a lot more surgery to make the current codebase work well with it
[02:23:15 CEST] <jamrial> atomnuker: you're back at shifting 64 bits when B is 0
[02:24:54 CEST] <jamrial> put the B ? CONVERT : 0 back in SET_RESIDUE. that should hopefully fix it
[02:26:01 CEST] <atomnuker> it didn't since INIT_RESIDUE already had that when coverity did its thing
[02:26:33 CEST] <atomnuker> (it's really a misdetection since it didn't take the check into account, but oh well)
[02:30:11 CEST] <cone-164> ffmpeg 03Rostislav Pehlivanov 07master:f41e37b84f3d: dirac_vlc: prevent shifting a 0 by 64 bits when zeroing residue
[09:20:38 CEST] <bp0>  is there a way to only sync the dependencies of a certain test instead of make fate-rsync ?
[09:43:04 CEST] <nevcairiel> not automatically, no
[09:47:49 CEST] <cone-531> ffmpeg 03Matthieu Bouron 07master:6c8942cdfb8b: lavf/mov: fix stream extradata_size allocation
[13:43:37 CEST] <kurosu> BBB, fyi, the openhevc guys probably split out the idct from residual adding, because hevc has inter-component residual prediction (...) so, basically, ease of implementation > speed
[13:43:58 CEST] <BBB> thats not even part of baseline profile
[13:44:24 CEST] <kurosu> ffmpeg hevc decoder supports 4:4:4, where that exists
[15:40:51 CEST] <BBB> kurosu: I worry a little that our hevc decoder will perform significantly worse than commercial decoders
[15:41:25 CEST] <BBB> kurosu: which maybe is a good thing given the terrible licensing situation hevcs IP holders created for themselves
[15:41:32 CEST] <BBB> kurosu: but still, from a technical point of view, its not quite right
[15:41:56 CEST] <BBB> does anyone want to review my 32x32 avx2 vp9 idct patch?
[16:00:44 CEST] <kurosu> BBB, I don't worry much about software decoding anyway
[16:01:15 CEST] <kurosu> most of the new h/w supports it
[16:02:02 CEST] <nevcairiel> latest gen supposedly even supports 12-bit, but i havent seen software interfaces yet to make use of that
[16:02:12 CEST] <nevcairiel> just higher chroma is left to software
[16:03:48 CEST] <kurosu> actually, it's more the availability of encoders that matter
[16:03:52 CEST] <kurosu> decoders are easy
[16:03:57 CEST] <kurosu> good encoders are more difficult
[16:04:22 CEST] <kurosu> the serving for vp9 is rather poor at the time, be it s/w or h/w
[16:05:15 CEST] <nevcairiel> hw decoding for vp9 also exists, although less common then hevc
[16:05:29 CEST] <kurosu> I meant encoding
[16:07:33 CEST] <kurosu> as for ffmpeg hevc decoding, even if it had proper idcts, yes, there's a 10-15% performance likely missing in addition
[16:08:01 CEST] <kurosu> well, not likely, provably
[16:11:36 CEST] <kurosu> btw, what is netflix waiting for to switch from hevc to vp9? proper hdr support?
[16:21:36 CEST] Action: ubitux going back to merges in about an hour
[17:04:48 CEST] <kierank> kurosu: vp9 in mp4 support
[17:04:54 CEST] <kierank> so they can do encryption
[17:14:44 CEST] <BBB> kurosu: hey, vp9 has a wonderful encoder out there
[17:38:06 CEST] <kurosu> kierank, ah right, if that happens - though support in ffmpeg was added recently
[17:38:54 CEST] <kurosu> BBB, err yes, I was too focusing on live/well-multithreaded encoders, but I recall it was a goal of yours if your encoder got traction
[17:54:42 CEST] <ubitux> http://b.pkh.me/0001-lavfi-selectivecolor-add-8bit-support.patch
[17:54:44 CEST] <ubitux> ugly :(
[17:54:47 CEST] <ubitux> oh well.
[17:55:18 CEST] <BBB> kurosu: dont worry its ok
[17:55:58 CEST] <cone-908> ffmpeg 03Michael Niedermayer 07master:de9674c5eacc: avformat/mux: Factor do_packet_auto_bsf() out
[17:55:58 CEST] <cone-908> ffmpeg 03Michael Niedermayer 07master:a2c90d5f9828: avformat/mux: Apply auto bsfs in av_write_frame() too
[18:23:22 CEST] <bp0> how can you look at the log output to test the result for fate?
[18:26:25 CEST] <BBB> bp0: what do you mean?
[18:26:44 CEST] <BBB> bp0: if you want to know what it runs, check make V=1 fate-...
[18:27:37 CEST] <bp0> oh, I mean when adding a test to fate, how could you test for a line in the log as the result?
[18:28:30 CEST] <BBB> like a metadata line?
[18:29:07 CEST] <bp0> no, like a line that is av_log(ctx, AV_LOG_INFO, ..) ed
[18:29:22 CEST] <bp0> by a filter
[18:29:33 CEST] <BBB> Im not sure we have infrastructure for that
[18:30:01 CEST] <BBB> you can probably just redirect output to a file and compare that file to a ref, but Im not a fate expert by any means
[18:31:36 CEST] <bp0> I did make an attempt to add a function to fate_run.sh to match a line in the output, but it wouldn't let me use REF in the test definition to specify the text to match
[18:32:14 CEST] <bp0> said REF needed to be a file, although elsewhere REF can be an md5 sum
[18:36:19 CEST] <bp0> maybe I could not use REF and do it all as a new function in fate-fun.sh
[18:54:25 CEST] <cone-908> ffmpeg 03Paul B Mahol 07master:d78fd2fa21cd: Add MagicYUV decoder
[18:54:26 CEST] <cone-908> ffmpeg 03Clément BSsch 07master:c3e2e842fa91: Merge commit 'd78fd2fa21cde28465e40dd0be4446b1387d22a6'
[19:00:03 CEST] <cone-908> ffmpeg 03Vittorio Giovara 07master:cc58656aca95: fate: Add tests for MagicYUV
[19:00:04 CEST] <cone-908> ffmpeg 03Clément BSsch 07master:cd02df52567d: Merge commit 'cc58656aca95b5ab517989a9524b9a2b1c5653cf'
[19:02:11 CEST] <cone-908> ffmpeg 03Clément BSsch 07master:9e6bb3b6eebd: fate/video: use FATE_VIDEO instead of FATE_SAMPLES_AVCONV
[19:14:45 CEST] <cone-908> ffmpeg 03Clément BSsch 07master:87e9cefa9110: lavc/codec_desc: move a few codecs out of the image codecs list
[19:22:01 CEST] <vade> Hi : Im curious : is it expected for an opened AVCodecContext* to change its time_base after the first call to avcodec_receive_frame wen decoding frames?
[19:24:08 CEST] <nevcairiel> its possible yes
[19:24:15 CEST] <nevcairiel> any info can change at any time, really
[19:24:42 CEST] <vade> interesting.
[19:24:47 CEST] <vade> thank you nevcairiel 
[19:30:33 CEST] <cone-908> ffmpeg 03Paul B Mahol 07master:470cd0c5fe63: Add TrueMotion 2.0 Real Time decoder
[19:30:34 CEST] <cone-908> ffmpeg 03Clément BSsch 07master:93c13886a2d6: Merge commit '470cd0c5fe6337b6cb5276b3f84400999450fc1b'
[19:30:35 CEST] <cone-908> ffmpeg 03Clément BSsch 07master:bec714525216: lavc/truemotion2rt: mark AVPacket* as const
[19:36:10 CEST] <cone-908> ffmpeg 03Vittorio Giovara 07master:906ffed9b1b8: fate: Move Duck Truemotion 1 and 2 tests to vpx.mak
[19:36:11 CEST] <cone-908> ffmpeg 03Clément BSsch 07master:e28d66052dd3: Merge commit '906ffed9b1b8b06979eb656989aecacb1ae75a3a'
[19:38:16 CEST] <cone-908> ffmpeg 03Vittorio Giovara 07master:523c4c5b7099: fate: Add TrueMotion 2 RT tests
[19:38:17 CEST] <cone-908> ffmpeg 03Clément BSsch 07master:def850676625: Merge commit '523c4c5b70994f5cd1f192b68d07cf24b292ca05'
[19:38:49 CEST] <ubitux> 3rd h264 wave now.
[19:43:05 CEST] <ubitux> still no one to move ffmpeg to codecpar btw?
[19:43:37 CEST] <cone-908> ffmpeg 03Anton Khirnov 07master:b25cd7540e7c: h264: pass a H2645NAL to slice header decoding
[19:43:38 CEST] <cone-908> ffmpeg 03Clément BSsch 07master:2c138b2c9b0e: Merge commit 'b25cd7540e7cba9868edc13817c0ce1ddef90ffc'
[19:48:17 CEST] <ubitux> oooh that's going to be annoying.
[19:49:06 CEST] <ubitux> guess what, it takes out stuff from the function we didn't want to move last time
[19:49:08 CEST] <ubitux> :(
[20:43:25 CEST] <BBB> ubitux: the downside of the whole merging business is indeed that everytime we dont maintain ourselves as a strict patchset on top of libav (which is obviously ridiculous), we have to do tons of extra work to merge non-trivial patches to divergent codebases :(
[20:43:35 CEST] <BBB> ubitux: I dont think theres a good solution to that
[20:43:59 CEST] <ubitux> well we didn't move it because it was breaking things only in ffmpeg in the first place
[20:44:07 CEST] <ubitux> not because their change was wrong
[20:58:55 CEST] <nevcairiel> (those two are not mutually exclusive)
[21:09:37 CEST] <BBB> loopfilter simd is nearly 10% of runtime on this media file Im testing
[21:10:23 CEST] <BBB> so thats promising
[21:41:39 CEST] <cone-908> ffmpeg 03Steven Liu 07master:e29d2d9c92e1: avformat/segment: remove the check_bitstream from segment
[21:55:57 CEST] <BBB> what does failed to issue emms in checkasm mean?
[21:57:21 CEST] <jamrial> BBB: that's the error i mentioned the other day
[21:57:34 CEST] <BBB> Im adding some new asm and Im getting that
[21:57:44 CEST] <BBB> what do I do?
[21:57:56 CEST] <jamrial> replace declare_func with declare_func_emms like in the other vp9 tests
[21:58:11 CEST] <BtbN> My assembler knowledge is lacking, but isn't emms the instruction to reset the fp registers, and you are supposed to call if after being done with mmx instructions?
[21:58:42 CEST] <jamrial> BtbN: yes
[21:58:45 CEST] <BtbN> So I'd interpret it as "you are not calling emms while you should"
[21:58:54 CEST] <BBB> I shouldn't
[21:59:00 CEST] <BBB> I Expect the caller to do that (and it does)
[21:59:25 CEST] <nevcairiel> then you should tell your test that
[21:59:28 CEST] <jamrial> BtbN: sort of. it's a change to checkasm that came from a merge that's got the naming inverted i think
[21:59:33 CEST] <BBB> ugh it still fails :-p
[21:59:40 CEST] <BBB> (but now with a checkasm fail instead of a emms fail)
[21:59:46 CEST] <BBB> so I guess the assembly is broken
[21:59:51 CEST] <jamrial> BBB: declare_func_emms(AV_CPU_FLAG_MMX | AV_CPU_FLAG_MMXEXT, void, ...
[22:00:00 CEST] <BBB> yup
[22:00:05 CEST] <jamrial> still fails? huh
[22:00:05 CEST] <BBB> ty
[22:00:12 CEST] <BBB> my assembly is broken :-p
[22:00:15 CEST] <jamrial> ah
[22:58:31 CEST] <BBB> actually the assembly was fine, the funcptr assignment was broken (I assigned a vertical filter function to the horizontal filter index in the dsp func array)
[22:58:35 CEST] <BBB> duh duh duh
[23:09:50 CEST] <jkqxz> Has anyone actually tried to use qsvdec in recent times?
[23:09:57 CEST] <jkqxz> In <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/qsvdec.c;hb=HEAD#l361>, how can it ever successfully decode a frame given that sync must be a null pointer when we dereference it at line 412?
[23:14:00 CEST] <nevcairiel> why does it have to be null
[23:14:26 CEST] <nevcairiel> its allocated there and filled by MFXVideoDECODE_DecodeFrameAsync
[23:15:36 CEST] <jkqxz> Line 407 is the only way to break out of the loop, but it can only get there if it takes the else branch of the condition above (the if has a continue), where sync is unconditionally freed.
[23:20:04 CEST] <michaelni> bp0, the 2 fate references are together 6mb, is that size needed ?
[23:43:26 CEST] <atomnuker> >If you have a chance to put the audio in a audio editor and zoom very close in, you see that there is a clipping error, or something else.
[23:43:43 CEST] <atomnuker> excellent, top tier bug reporting here
[23:45:07 CEST] <atomnuker> "if you zoom into this jpeg image with a magnifying glass you can see a blocky halo around this letter here"
[23:46:11 CEST] <jamrial> why is he reencoding 192k aac into 128k aac anyway?
[23:47:11 CEST] <atomnuker> why is he not using opus
[23:52:23 CEST] <jamrial> atomnuker: seeing he's using mp4/h264/aac, it's probably because he wants a hardware or smartphone compliant file
[23:52:34 CEST] <jamrial> or simply a file that will be compatible with everything under the sun
[23:53:42 CEST] <jamrial> he should stream copy that audio stream. lossy to lossy audio conversion is evil
[00:00:00 CEST] --- Fri Jul 15 2016