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

[burek]

[00:01:59 CET] <kierank> BBB: yes that was intentional
[00:02:21 CET] <kierank> https://usercontent.irccloud-cdn.com/file/sP9DDca9/two_ac_coeffs.png
[00:02:29 CET] <kierank> two coefficients is quite objectionable
[00:06:47 CET] <iive> kierank: have you taken into account the idct permutation?
[00:07:29 CET] <iive> some DSP idct reorder ac coefficients, so they can load them in a single SIMD instruction.
[00:08:00 CET] <iive> so the ordering is combined with the zigzag.
[00:21:40 CET] <kierank> BBB: also gcc -fsanitize=undefined doesn't complain
[00:25:38 CET] <BBB> hm...
[00:25:42 CET] <BBB> is that 2x1 or 2x2 coeffs?
[00:26:16 CET] <kierank> 1x DC and 2x AC
[00:26:20 CET] <kierank> should I put another AC in?
[00:26:21 CET] <BBB> from this, I would suggest that perhaps the ac is over-dequantized
[00:27:04 CET] <kierank> ok
[00:27:36 CET] <BBB> is it possible that theres different quantization tables for the dc vs. ac but youre using the same quantizer for both
[00:27:37 CET] <BBB> ?
[00:28:21 CET] <kierank> there could be a lot of things to be honest
[00:28:28 CET] <kierank> but I've checked the dequant so many times
[00:29:07 CET] <kierank> the bitstream sends a really strange quant matrix
[00:30:27 CET] <kierank> let's try ignoring it and using default
[00:30:34 CET] <BBB> :)
[00:31:37 CET] <BBB> can you debug the dequant matrix also? maybe that helps
[00:31:43 CET] <BBB> (debug as in printf() it)
[00:34:43 CET] <kierank> http://pastebin.com/BCYSEUx7
[00:34:45 CET] <kierank> that's the quant matrix
[00:34:51 CET] <kierank> that's sent in the bitstream
[00:37:59 CET] <kierank> https://usercontent.irccloud-cdn.com/file/7AzrM8AB/SonyHDCAMSR
[00:38:03 CET] <kierank> durandal_1707: ^
[00:38:07 CET] <kierank> that's the binary decoder
[00:38:20 CET] <kierank> can you see if you can find dequant
[01:24:53 CET] <BBB> kierank: that dequant table looks exceptionally weird
[01:25:30 CET] <BBB> kierank: Im guessing that the dc is at a scale of 4 (so it should be 32) and all coeffs should be divided by 4 after the idct
[01:26:07 CET] <kierank> the spec says the dc must be 8
[01:26:28 CET] <BBB> it might be scaled by fractional bits
[01:26:43 CET] <BBB> the vp9 idct, for example, has two fractional bits
[01:26:51 CET] <BBB> also, never trust the spec
[01:27:00 CET] <kierank> ah yes there was something about fractional bits in the idct description
[01:27:26 CET] <kierank> The coefficients are
[01:27:26 CET] <kierank> represented in (n+7) bits including three fractional bits.
[01:27:55 CET] <kierank> so divide by 8 after idct?
[01:28:30 CET] <BBB> thats what it looks like then, yes
[01:28:33 CET] <BBB> and that means the dc is 64
[01:29:16 CET] <kierank> do I need to modify the idct to do the divide or can I just do it afterwards?
[01:29:55 CET] <BBB> you can do it whenever, really
[01:30:03 CET] <kierank> I don't understand why dc-only looks correct then
[01:30:07 CET] <kierank> surely it will be dark afterwardsd
[01:30:17 CET] <BBB> because your dc is missing fractional adjustment, and so is your idct
[01:30:25 CET] <BBB> the ac is fractionally adjusted, but the idct isn't
[01:30:33 CET] <BBB> so all ac coefficients are scaled up by a factor 8
[01:30:39 CET] <BBB> you can divide idct coeffs by 8 and test that
[01:30:42 CET] <BBB> ac coeffs
[01:30:49 CET] <BBB> that should give almost-correct results
[01:34:09 CET] <kierank> hmm looks much better but a bit weird still
[01:34:12 CET] <kierank> lemme upload photo
[01:36:28 CET] <kierank> https://usercontent.irccloud-cdn.com/file/TVIpLucG/better.png
[01:38:14 CET] <kierank> If each pixel is represented by n bits per pixel, the input to the forward transform and output from the inverse
[01:38:14 CET] <kierank> transform is represented with (n+1) bits.
[01:38:26 CET] <kierank> is there another shift I am missing
[01:42:56 CET] <BBB> is that with all coefficients?
[01:43:19 CET] <kierank> that picture is all ac coeffs
[01:43:20 CET] <BBB> not bad -as in, better than before :)
[01:43:29 CET] <kierank> yeah nearly there
[01:44:34 CET] <kierank> ac coefficients shifted I mean
[01:44:52 CET] <BBB> maybe
[01:45:01 CET] <BBB> try different shifts, e.g. divide them by 16 or 32
[01:45:09 CET] <BBB> 32 may well be correct
[01:45:10 CET] <BBB> given how far theyre still off
[01:45:27 CET] <BBB> and fits the n+1 bits per 1d
[01:45:27 CET] <BBB> (the bas eunit being 8, plus 1 bit per 1d idct, making 32)
[01:47:17 CET] <kierank> 32 looks different, things are blurrier
[01:47:23 CET] <kierank> wouldn't say it's better though
[01:47:25 CET] Action: kierank tries 64
[01:47:29 CET] <kierank> and 8
[01:47:43 CET] <kierank> sorry just tried 16
[01:47:44 CET] <kierank> trying 32
[01:49:02 CET] <BBB> a potential issue might be that if youre dividing the ac coeffs by a high number, that a large portion of the signal actually gets lost, so blurry is potentially what you might expect then
[01:49:22 CET] <BBB> (i.e. in the real solution, youd upscale the dc by that and divide the post-idct by that, rather than dividing the ac coeffs by that)
[01:49:32 CET] <BBB> (but were just playing around here to find out the issue)
[01:52:27 CET] <kierank> I think / 8 looks the best
[02:06:05 CET] <BBB> 8 is the one from the screenshot?
[02:06:16 CET] <kierank> yes
[02:07:03 CET] <BBB> very odd artifacts at this point
[02:07:32 CET] <kierank> let me go back to trying a few coeffs
[02:07:49 CET] <BBB> did you try default quant tables?
[02:07:55 CET] <kierank> yes looked really bad
[02:08:02 CET] <kierank> shifting DC was bad too
[02:08:04 CET] <BBB> but it looks like some artifacts are like as if its using horizontal interlacing
[02:08:10 CET] <BBB> it looks pretty terrible
[02:08:35 CET] <kierank> could  be a bug in coefficient extraction
[02:08:56 CET] <kierank> there might be some undocumented range limits in get_xbits and similar
[02:27:25 CET] <kierank> michaelni: just to check is get_xbits enough to decode table b.46?
[02:28:16 CET] <iive> once again, check the permutation
[02:28:27 CET] <iive> the artifacts do look like ac in wrong positions
[02:33:44 CET] <iive> well, if kierank have me on ignore, i guess he'll have to figure it out on his own.
[02:53:15 CET] <kierank> BBB: also weird that the matrix sends 254 but the spec says that's reserved
[02:56:19 CET] <BBB> is there a reference output that you can fdct to get the intended scaled coefficients?
[02:58:48 CET] <atomnuker> 1D DCTs are no simpler
[02:59:21 CET] <kierank> I have no reference decoder
[02:59:47 CET] <kierank> I think this will become an IDA pro job :(
[03:30:53 CET] <Compn> [20:28] <iive> once again, check the permutation
[03:30:53 CET] <Compn> [20:28] <iive> the artifacts do look like ac in wrong positions
[03:31:27 CET] <Compn> kierank ^
[04:09:42 CET] <jamrial> durandal_170: the two av_strdup() you added to avf_aphasemeter.c are leaking
[04:21:32 CET] <kierank> BBB: damn the decoder binary application only lets you output rgb :(
[04:22:03 CET] <BBB> thats ok right?
[04:22:12 CET] <BBB> just convert to yuv, do fdct on the planes
[04:22:17 CET] <BBB> it should be approximately correct
[04:22:31 CET] <BBB> spec sounds very unhelpful though :(
[04:22:37 CET] <kierank> dunno, I guess, would have been nice to have yuv though
[04:24:52 CET] <kierank> can ffmpeg do rgb -> yuv bt709 conversion?
[04:24:54 CET] <kierank> afaik it can't
[04:33:58 CET] <atomnuker> kierank: vf_colorspace should, I think it just referred to rgb as something different for some reason
[04:34:23 CET] <kierank> even rgb48?
[04:34:26 CET] <kierank> to yuv422p10?
[04:35:37 CET] <atomnuker> huh, srgb is only listed under input transfer characteristics
[04:36:00 CET] <atomnuker> (I guess it doesn't make sense as colorspace/primaries?)
[04:39:05 CET] <atomnuker> BBB: will vf_colorspace do the correct thing for RGB?
[04:39:25 CET] <atomnuker> (what to set as iprimaries and ispace to make itrc=srgb work?)
[04:40:43 CET] <BBB> vf_colorspace only handles yuv
[04:40:57 CET] <BBB> theres no reason it cant handle rgb, but I havent implemented it
[04:42:07 CET] <kierank> oh right the matrix is fine 254 is allowed
[04:42:18 CET] <kierank> it's not allowed for the first dc
[04:43:31 CET] <atomnuker> rgb* <-> yuv* is like the most common conversion, getting that working would be able to replace swscale for like 90% of all things
[04:44:10 CET] <kierank> yeah but these things need to be thought through
[04:44:18 CET] <kierank> otherwise we rebuild swscale v2
[04:44:52 CET] <wm4> atomnuker: and we'd need to use the lavfi API for it... no thanks
[04:44:56 CET] <atomnuker> yeah, templating like libswscale isn't cool
[04:45:16 CET] <kierank> wm4: that too
[04:45:19 CET] <BBB> vf_colorspace isnt intended to be swscale
[04:45:27 CET] <BBB> I know it does some things more correctly than swscale
[04:45:30 CET] <BBB> thats why I built it
[04:48:33 CET] <BBB> but its not a generic scaler
[04:48:40 CET] <BBB> in fact it doesnt even scale at all
[04:54:54 CET] <wm4> "	libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7506000)
[04:54:54 CET] <wm4> 	libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf734f000)
[04:54:54 CET] <wm4> 	/lib/ld-linux.so.2 (0x5658c000)
[04:54:54 CET] <wm4> 	libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf7323000)
[04:54:55 CET] <wm4> 	libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf731f000)
[04:54:56 CET] <wm4> 	libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf7316000)
[04:54:58 CET] <wm4> vlx at debian:/mnt/doh/sandgrube/d3_2$ ls movies/
[04:55:00 CET] <wm4> sorry
[04:55:08 CET] <wm4> so... "seek_frame_generic failed as this stream seems to contain no keyframes after the target timestamp, 1002 non keyframes found"
[04:55:21 CET] <wm4> it shouldn't really do this
[04:55:41 CET] <wm4> instead, it should seek to the first frame
[04:56:04 CET] <wm4> but nice to see that ffmpef somehow supports decoding descent 3 in-game movies
[04:58:02 CET] <BBB> wm4: http://trac.ffmpeg.org/ticket/4904
[04:58:18 CET] <BBB> (same bug)
[04:58:51 CET] <wm4> yeah, same bug
[04:59:01 CET] <wm4> ffmpeg and its stupid heuristics
[04:59:19 CET] <wm4> because broken files are more important than sane ones that are "unexpected"
[04:59:21 CET] <BBB> I agree it should search back or at least thats what the default behaviour should be with no specific flags to disallow that
[04:59:29 CET] <BBB> but & thats not what we do now, obviously
[05:01:13 CET] <wm4> the code is even worse
[05:01:15 CET] <wm4> if (nonkey++ > 1000 && st->codecpar->codec_id != AV_CODEC_ID_CDGRAPHICS) {
[05:01:20 CET] <wm4> cdgraphics??
[05:01:37 CET] <cone-753> ffmpeg 03Bela Bodecs 07master:9ec52a0a9b08: libavformat/hlsenc: fix delete_segments when use_localtime_mkdir
[05:01:38 CET] <wm4> probably should add interplayvideo and vp9 here lol
[05:03:49 CET] <kierank> lol
[05:05:17 CET] <wm4> cdg.c (cdgraphics demuxer) actually has code to mark some keyframes
[05:06:13 CET] <wm4> this commit adds the cdg codec id: "lavf: cdg has large non keyframe segments and should thus be exempt from the non keyframe check in seeking.    Improves seeking for cdg files."
[05:06:14 CET] <wm4> by michaelni 
[05:06:46 CET] <wm4> "improves seeking" => allow broken seeks? wat
[05:07:24 CET] <wm4> the 1000 frames heuristic was added in the same year, by michaelni: "generic seeking: fail if there are 1000 non keyframes found with no keyframe.    This avoids scanning through a whole file just to fail."
[05:08:39 CET] <BBB> wm4: uhm yeah we all know utils.c has very questionable code
[05:08:44 CET] <BBB> lets come up with something better
[05:08:53 CET] <BBB> that works for vp9, cdf, interplay as well as h264/etc.
[05:09:16 CET] <wm4> <wm4> "improves seeking" => allow broken seeks? wat <- actually I got this the wrong way around, the cdg exception was added after it was observed to break with the previously added 1000 frames heuristic
[05:09:22 CET] <BBB> I agree the randomness is amusing
[05:10:02 CET] <BBB> sounds like we need a way to mark streams as non-resumable without keyframes"
[05:10:05 CET] <BBB> like vp9 etc.
[05:10:08 CET] <kierank> BBB: http://pastebin.com/svLhKFyk  fixed the DC dequant
[05:10:58 CET] <BBB> cool
[05:11:11 CET] <BBB> the post idct has a lot of zeroes in it
[05:11:13 CET] <kierank> yeah
[05:11:16 CET] <BBB> but I guess thats OK?
[05:11:20 CET] <kierank> not doing any shifts
[05:11:36 CET] <BBB> does it look alright?
[05:11:37 CET] <kierank> no
[05:11:44 CET] <kierank> worse but dc is correct i think now
[05:12:14 CET] <BBB> its possible something overflows inside the idct now
[05:12:25 CET] <BBB> 15328 is very large, almost outside int16_t range
[05:12:32 CET] <BBB> so some multiplications could overflow 32bit
[05:12:37 CET] <BBB> (31+sign)
[05:12:55 CET] <kierank> the actual image is a really high frequency net
[05:13:11 CET] <kierank> so I wonder if shifting the coefficients and getting weird artefacts is actually the correct result
[05:13:26 CET] <BBB> probably not
[05:13:38 CET] <BBB> I think the 15k is causing an overflow somewhere
[05:13:48 CET] <BBB> possibly at the end of the first 1d idct when youre storing intermediates
[05:14:02 CET] <BBB> you may have to downshift at the end of the first 1d idct already
[05:14:24 CET] <BBB> its also still a horizontal mirror
[05:16:00 CET] <wm4> just removing the heuristic from the generic seek code makes seeking backwards fail as well
[05:16:25 CET] <kierank> BBB: yeah *row is an int16_t ...
[05:17:13 CET] <kierank> do no other codecs store such a large dc?
[05:22:50 CET] <BBB> they use int32_t for this bitdepth ;)
[05:22:58 CET] <kierank> BBB: if I use the float dct then shift up two to go back to 10-bit, will that work?
[05:23:06 CET] <wm4> crazy times when game developers made their own relatively advanced video and audio codecs and interleaved containers
[05:23:07 CET] <BBB> sure
[05:23:36 CET] <BBB> kierank: using float for testing is a great idea imo
[05:24:36 CET] Action: BBB sleep
[05:24:38 CET] <BBB> tty tomorrow
[05:29:20 CET] <wm4> woah av_index_search_timestamp is public API
[05:29:39 CET] <wm4> and av_add_index_entry too
[05:37:02 CET] <kierank> atomnuker: do we have a float idct?
[05:37:07 CET] <kierank> I can only find the fdct
[05:40:41 CET] Action: wm4 stares at the dynarray_add macro in libavformat/internal.h
[05:40:53 CET] Action: kierank tries octave
[05:41:52 CET] <kierank> wm4: is that some kind of riced linked list?
[05:42:13 CET] <wm4> it calls av_dynarray_add, but with additional type checking via #ifdef __GNUC__
[05:58:58 CET] <wm4> meh fixing this seems too much effort after all
[10:17:54 CET] <fritsch> we currently hit some "funny" limits with kodi 32 bit and ffmpeg
[10:18:17 CET] <fritsch> we found that the x64 bit version of ffmpeg (zerone build) is roughly 2 times faster when doing hevc decoding
[10:18:28 CET] <fritsch> that's most likely caused by the intrinsics right?
[10:18:51 CET] <fritsch> e.g. the 64 bit version can / may use sse4 and stuff automatically?
[10:19:13 CET] <nevcairiel> automatically ? unlikely. but we do have a variety of asm thats only available on 64-bitz
[10:19:14 CET] <nevcairiel> -z
[10:20:05 CET] <fritsch> quite easy test
[10:20:14 CET] <fritsch> download zerone's 32 bit build and his 64 bit build
[10:20:17 CET] <fritsch> take this sample:
[10:20:29 CET] <fritsch> http://fritsch.fruehberger.net/samples/future-live-tv-hevc-10bit.ts
[10:20:31 CET] <fritsch> and run:
[10:21:09 CET] <nevcairiel> it is somewhat known that 64-bit hevc is about twice as fast then 32-bit, most of that comes from the asm thats not available on 32
[10:21:26 CET] <fritsch> ffmpeg -i future-live-tv-hevc-10bit.ts -f null -
[10:21:34 CET] <nevcairiel> even more pronounced if you imported the openhevc simd improvements that are not in mainline ffmpeg
[10:22:06 CET] <fritsch> then it will be the same speed?
[10:22:23 CET] <nevcairiel> it will never be the same speed
[10:22:30 CET] <nevcairiel> x64 is just faster no matter what you do
[10:22:38 CET] <fritsch> yeah
[10:22:58 CET] <fritsch> double the data per instruction (depending on instruction)
[10:23:27 CET] <nevcairiel> for h264, which is more thoroughly simd'ed even on 32-bit, the difference is around 10%
[10:24:02 CET] <fritsch> do you think that's roughly the same difference possible for hevc?
[10:24:08 CET] <fritsch> I cannot really believe that
[10:24:21 CET] <nevcairiel> possible? maybe. but will anyone care to make it possible? unlikely
[10:24:25 CET] <fritsch> as yeah, there are instructions when used with 64 bit are really twice as fast
[10:24:49 CET] <fritsch> hehe, yeah. We are trying to go to kodi 64 bit on windows for the next release
[10:24:57 CET] <fritsch> and will leave the 32 bit world behind
[10:25:21 CET] <nevcairiel> the main difference comes from SIMD, which is mostly independent of the arch, with one exception - the number of registers available, which is the limiting factor why people don't write 32-bit SIMD ASM in the first place
[10:25:52 CET] <fritsch> yesh, that was also my assumption as written in my intro
[10:26:07 CET] <fritsch> oki, so we should not really bother but concentrate on going the 64 bit direction?
[10:26:33 CET] <JEEB> except when people talk of intrinsics they usually mean intrinsics and not asm. upstream FFmpeg doesn't take in IA32/x86_64 intrinsics
[10:26:45 CET] <nevcairiel> if you want to improve 32-bit performance, feel free, but other then windows any other platforms largely don't care anymore either way
[10:27:17 CET] <fritsch> i thought ffmpeg uses yasm and this also generates quite optimized instructions, right JEEB?
[10:27:24 CET] <JEEB> that's what is meant with asm
[10:27:46 CET] <JEEB> intrinsics is something you sprinkle within the C code and hope your compiler can optimize it well enough
[10:28:07 CET] <fritsch> yeah, we do that for our gpu memory copies to system memory
[10:28:30 CET] <fritsch> but other than that, we removed most of that stuff and leave it to the pros :-)
[10:28:37 CET] <fritsch> by e.g. using ffmpeg methods
[10:29:02 CET] <JEEB> and asm is usually a whole function implemented in asm and exported from the assembled object
[10:29:19 CET] <JEEB> less simple since you can't just dump some random instructions in the middle of a function ;)
[10:29:50 CET] <fritsch> i think it's good for platform comaptibility
[10:30:04 CET] <fritsch> as the optimizations can be clearly separated from common code
[10:30:18 CET] <fritsch> not sure how ffmpeg does that, function ptrs?
[10:30:22 CET] <JEEB> yup
[10:30:29 CET] <fritsch> for different archs?
[10:30:56 CET] <JEEB> I think intel arch and arm (?) are the two where having pure asm works
[10:31:31 CET] <JEEB> otherwise it probably is intrinsics because there's no standard assembler for that arch
[11:21:11 CET] <atomnuker> I think all of my asm is 32 bits compatible but its such a pain because when you run out of registers you have to resort to very hacky methods
[11:25:54 CET] <nevcairiel> you can often save a reg here and there by being a bit smarter with parameter handling and whatnot, but once those tricks are all done and you still need more ... stack yoo
[12:45:25 CET] <Compn> fritsch : its possible that zeranoe is disabling something for the 32bit build in order to get it to build...
[12:46:16 CET] <Compn> fritsch : i would like to see some better benchmarks , compile yourself, on hevc 64bit vs x86....
[12:50:13 CET] <Compn> i also wonder if there is some software for converting the existing 64bit code to 32bit...
[12:53:00 CET] <JEEB> Compn: don't confuse the person :P There's just less 32bit SIMD for HEVC
[12:54:09 CET] <Compn> right
[12:54:11 CET] <Compn> that too
[12:54:21 CET] <Compn> did we ever steal anything from http://simd.sourceforge.net/ ?
[16:20:20 CET] <nevcairiel> updated my build system to the latest mingw-w64 release, and they still didnt manage to include vp9 dxva headers in it, despite them being submitted to master almost 10 months before the release .. how slow can you work o.o
[16:22:00 CET] <JEEB> funky, how long before release did they branch off o_O
[16:22:14 CET] <nevcairiel> no clue
[16:22:17 CET] <nevcairiel> but more then 10 months
[16:22:27 CET] <j-b> yes, 5.0 was long to come
[16:22:41 CET] <j-b> nevcairiel: we're doing a 5.0.1 release soon. Any sha1 you want to backport?
[16:22:53 CET] <nevcairiel> its technically a feature, i guess, no clue how they work
[16:23:17 CET] <j-b> depends on how nicely it is asked and how intrusive
[16:23:37 CET] <j-b> just f94008512312a54d142e97868e7585d69a323a62 ?
[16:23:46 CET] <nevcairiel> that should be all, yes
[16:23:56 CET] <nevcairiel> its just data structures, not even any symbols
[16:24:23 CET] <j-b> I will ask.
[16:24:26 CET] <j-b> nevcairiel: anything else?
[16:24:38 CET] <nevcairiel> not that i'm aware, just started using 5.0 today
[16:25:10 CET] <j-b> you might not like it too much :)
[16:25:21 CET] <nevcairiel> is it broke?
[16:25:28 CET] <j-b> a bit.
[16:25:47 CET] <nevcairiel> all i build with it is x264 and ffmpeg, so maybe i get by
[16:25:51 CET] <j-b> but 5.0.1 is around the corner
[16:26:02 CET] <j-b> nevcairiel: sure, don't hesitate to ask other things, if needed
[16:40:07 CET] <Guest28924> Hello, my name is Ezequiel. I have some problems to build the lastest ffmpeg on TinyCore 7 x86_64. Can you help me? Thanks! 
[16:49:08 CET] <Chloe> Guest28924 you probably want #ffmpeg
[16:50:14 CET] <Guest28924> I'm not sure. I'll try there.  Thanks!
[17:08:41 CET] <BBB> nevcairiel: remember that thing I said yesterday (building ffmpeg for win64 using msvc)?
[17:08:45 CET] <BBB> nevcairiel: I learned something new
[17:09:54 CET] <BBB> nevcairiel: not only am I a fake, Im also a swindler - fun discovery, no?
[17:28:23 CET] <nevcairiel> Self discovery is always fascinating
[17:54:53 CET] <BBB> nevcairiel: especially when prompted by trolls
[17:58:39 CET] <Gramner> BBB: my favorite comment on that stackoverflow thread is "People are earning big bucks for building ffmpeg. That's why nobody is willing to explain how to do it."
[17:58:50 CET] <Chloe> if only
[17:59:00 CET] <BBB> can I have some of that money?
[17:59:04 CET] <BBB> would be very useful
[17:59:39 CET] <BBB> I think he did finally explain what his problem is. he edited his post a couple of times and now it says that it says 1000 times that features.h is missing"
[17:59:55 CET] <BBB> I dont know when it says that or what hes doing
[17:59:56 CET] <nevcairiel> people get paid for building ffmpeg?
[17:59:58 CET] <nevcairiel> i should get on that
[18:00:05 CET] <BBB> yeah yeah, didnt you know? youtube money dude
[18:00:12 CET] <BBB> every build is worth 10 youtube dollars
[18:00:16 CET] <nevcairiel> offer customized builds on request!
[18:00:27 CET] <nevcairiel> just the things you need, nothing more!
[18:00:28 CET] <nevcairiel> :D
[18:01:08 CET] <RiCON> zeranoe used to have custom builds on request
[18:01:17 CET] <nevcairiel> work was using zeranoe builds until i came along, was so nice to cut the binary bloat to like one third
[18:01:18 CET] <RiCON> not sure if paid or not, but it's gone with the new design
[18:01:37 CET] <nevcairiel> noone needs every external library in existance
[18:01:51 CET] <nevcairiel> but thats the fate of a generic build for you
[18:02:24 CET] <BBB> hey nevcairiel so you build ffmpeg right? you must be rich
[18:02:50 CET] <BBB> I mean, only on windows of course, building on linux is for losers that dont have features.h
[18:02:51 CET] <nevcairiel> rich enough to afford a cpu to build ffmpeg with!
[18:02:57 CET] <BBB> o o o
[18:03:06 CET] <BBB> can I get half of your cores to build ffmpeg also?
[18:03:10 CET] <BBB> we could get twice as rich!
[18:03:15 CET] <nevcairiel> (i dont even know what features.h is)
[18:03:24 CET] <BBB> (neither do I)
[18:03:46 CET] <Gramner> you need at least one core per source file for that optimal parallell benefits
[18:04:16 CET] <nevcairiel> neither mingw nor msvc have a features.h that i can see
[18:04:19 CET] <nevcairiel> so .. shrug
[18:04:39 CET] <nevcairiel> back to cooking my lasagna, i guess
[18:04:43 CET] <BBB> enjoy
[18:04:50 CET] <RiCON> there's at least three maintained scripts for building ffmpeg with mingw, what are people crying about?
[18:05:10 CET] <nevcairiel> you dont even need a "script" for a basic build
[18:05:19 CET] <nevcairiel> those scripts just fetch all those pesky external libraries
[18:06:31 CET] <RiCON> the one i maintain at least leaves the choice to the user of how much bloat they cram into ffmpeg
[18:06:37 CET] <nevcairiel> hehe
[18:07:09 CET] <RiCON> though most people making issues always use the one with at least the same libs as zeranoe
[18:07:50 CET] <RiCON> people want their libschroedinger
[18:16:21 CET] <nevcairiel> i only ever used the important ones, x264, lame, opus, and maybe twolame for extreme cases of legacy =p
[18:17:31 CET] <BBB> libvpx?
[18:17:49 CET] <nevcairiel> never had a need to encode vp8/9
[18:21:51 CET] <nevcairiel> but i suppose its common enough these days
[18:21:57 CET] <RiCON> lame, opus, vorbis, vpx, x264, x265 and the built-ins nvenc, avisynth, schannel should be enough for most uses
[18:23:07 CET] <jamrial> you forgot fdk-aac
[18:23:18 CET] <RiCON> ffaac is good enough
[18:23:33 CET] <nevcairiel> my decoder actually builds  speex and opencore-amr, mostly because people asked at some point about samples and it was easy
[18:23:37 CET] <jamrial> we removed faac
[18:23:37 CET] <RiCON> fdk makes the build unredistributable too
[18:23:40 CET] <nevcairiel> fdk-aac is also nonfree
[18:23:49 CET] <nevcairiel> jamrial: ffaac, not faac
[18:23:49 CET] <nevcairiel> :D
[18:23:57 CET] <jamrial> oh right
[18:24:02 CET] <jamrial> yeah, that's good enough
[18:25:47 CET] <jamrial> 99% of users are good with x264+aac+mp4
[18:26:26 CET] <jamrial> i suppose someone out there still uses libxvid because h264 is too much for their netburst/k7 rig
[18:26:33 CET] <nevcairiel> heh
[18:26:45 CET] <nevcairiel> i let those people suffer with built-in mpeg4enc
[18:27:04 CET] <nevcairiel> its not that terrible if you tweak its parameters some, it just has awful defaults
[19:31:12 CET] <BBB> I still hear reports that ffaac isnt as good as fdk_aac. is that old/uninformed/legacy/dogma? or is that still true?
[19:35:56 CET] <Chloe> atomnuker: ^
[19:37:29 CET] <aballier> i think fdk_aac remains the only encoder capable of doing any version of he-aac
[19:38:13 CET] <aballier> (meaning it is probably much better at lower bitrates than ffaac)
[19:39:59 CET] <nevcairiel> fdk is probably still better .. how much? much less then it used to be, for sure.
[20:05:59 CET] <RiCON> BBB: listening tests by kamedo still put ffaac a bit behind fdk
[20:06:17 CET] <BBB> a bit is not terrible for a redistributable binary
[20:06:38 CET] <RiCON> http://d.hatena.ne.jp/kamedo2/20160215/1455552816
[20:07:17 CET] <RiCON> this was before some changes, i don't think there were any other tests
[20:10:27 CET] <RiCON> more recent tests compare aac with other codecs but only QAAC
[21:05:37 CET] <kierank> BBB: octave idct2 looks more sane, will find a float idct to port to ffmpeg
[21:06:17 CET] <BBB> sounds good
[21:47:55 CET] <atomnuker> BBB: depends on the sample and bitrate but yeah for the 96-82k range fdk_aac does slightly better if you can hear it
[21:48:27 CET] <atomnuker> at around 48k we win on alot more samples since fdk_aac will never use PNS nor TNS
[21:49:36 CET] <atomnuker> (we also adjust the lowpass filter based on the range if the lambda's in the gutter)
[21:50:52 CET] <atomnuker> btw the opus encoder I have is better than anything else other than libopus we have supported
[21:51:42 CET] <nevcairiel> is it just the opus features being so nice that its apparently so easy to w rite a decent encoder?
[21:52:01 CET] <atomnuker> and I'm not even doing psychoacoustics, transients, vbr, TF switching, RDO, theta tweaking, IS analysis, MS analysis, alloc slope & band boosts
[21:52:58 CET] <atomnuker> nevcairiel: its purely because of the quntization and the decoupling between band amplitude and bit allocation (aac/mp3 scalefactors)
[21:54:58 CET] <BBB> atomnuker: so when will you implement psychoacoustics, transients, vbr, TF switching, RDO, theta tweaking, IS analysis, MS analysis, alloc slope & band boosts?
[21:55:05 CET] <BBB> atomnuker: just wondering ;)
[21:55:45 CET] <atomnuker> its going to be the best one day and I'll have to
[21:56:13 CET] <atomnuker> (also add flexible framesizes if that experiment works out)
[22:47:56 CET] <kierank> BBB: ported a float idct, looks interesting to say the least, not right though
[22:48:03 CET] <kierank> is there a reference float idct somewhere?
[22:48:20 CET] <BBB> just take the one from wikipedia
[22:48:27 CET] <BBB> libvpx also has one
[22:48:31 CET] <kierank> y is screwed, u looks much better
[22:48:32 CET] <BBB> (in the tests directory)
[22:55:06 CET] <kierank> BBB: do I need to add a bias as well?
[22:55:10 CET] <kierank> or just shift?
[22:55:25 CET] <BBB> for rounding?
[22:55:42 CET] <BBB> its float right?
[22:55:48 CET] <BBB> so no loss of precision, just exponent change
[22:55:59 CET] <kierank> yes and I'm directly converting to uint16_t
[22:56:01 CET] <kierank> not sure if that's right
[22:56:13 CET] <kierank> so uint16_t foo = float_coeff[x];
[22:57:32 CET] <kierank> http://pastebin.com/1yHNZ4xV
[22:57:39 CET] <kierank> get even weird coeffs
[22:58:52 CET] <BBB> I think you need to divide by 4
[22:59:01 CET] <BBB> if the number of bits per 1d idct is 1 more than the bit depth
[22:59:15 CET] <BBB> then you need to remove 2 bits for the pixel conversion for a 2d idct
[22:59:28 CET] <kierank> In case of mpeg2_stream = 0, The coefficients are
[22:59:29 CET] <kierank> represented in (n+7) bits including three fractional bits.
[22:59:37 CET] <kierank> so 7 bits, right?
[23:00:01 CET] <kierank> If each pixel is represented by n bits per pixel, the input to the forward transform and output from the inverse
[23:00:01 CET] <kierank> transform is represented with (n+1) bits.
[23:00:17 CET] <BBB> so 2x1 + 3, I think
[23:00:20 CET] <BBB> so 5
[23:00:32 CET] <BBB> but it could be any number
[23:00:40 CET] <BBB> also dont forget to clip in the domain
[23:00:46 CET] <kierank> yeah I guess
[23:00:57 CET] <BBB> so if x < 0 x else if x >= 1024 1023 else x
[23:01:19 CET] <kierank> yeah
[23:01:30 CET] <BBB> look forward to seeing what you cooked up ;)
[23:02:47 CET] <kierank> https://www.irccloud.com/pastebin/ZmCxNktL/
[23:02:52 CET] <kierank> still weird
[23:03:22 CET] <kierank> y looks okish
[23:03:24 CET] <kierank> u and v terrible
[23:03:33 CET] <kierank> ah perhaps u and v needs a bias
[23:04:05 CET] <kierank> not sure how the octave idct looks sane
[23:04:16 CET] <kierank> https://www.irccloud.com/pastebin/Gdm9wj9r/
[23:04:18 CET] <kierank> for comparison
[23:06:16 CET] <BBB> 2048 is a high value for 10bits content
[23:06:31 CET] <kierank> yeah I would guess it's /4 or something
[23:06:36 CET] <kierank> but it's much smoother
[23:06:41 CET] <kierank> like no random zeroes
[23:06:44 CET] <BBB> right
[23:07:03 CET] <BBB> is that u/v or y?
[23:07:06 CET] <kierank> ah the zeroes are clipping
[23:07:17 CET] <kierank> perhaps I will not use av_clip
[23:07:23 CET] <kierank> might be an artefact of that
[23:07:32 CET] <BBB> ?
[23:07:40 CET] <BBB> you should clip while converting float->int
[23:07:47 CET] <BBB> i.e. do the comparison in float
[23:07:54 CET] <BBB> if you know what I mean
[23:07:57 CET] <kierank> yeah just reaslised that...
[23:08:00 CET] <BBB> :)
[23:08:11 CET] <BBB> well get somewhere eventually ;)
[23:09:55 CET] <kierank> https://www.irccloud.com/pastebin/xZILSih1/
[23:11:13 CET] <BBB> still very strange
[23:13:48 CET] <BBB> what I find strange is that the dc is soooooo huge
[23:14:00 CET] <BBB> yet the values within are wildly flunctuating
[23:14:09 CET] <BBB> between whatever and whatever
[23:14:29 CET] <BBB> 15326=1915.75 if theres 3 fractional bits
[23:15:19 CET] <BBB> so if the idct only takes 1 bit off& then doesnt that mean it should have a dc of ~1000?
[23:15:32 CET] <BBB> yet the average of the values youre pasting is 250 or 300 or so
[23:15:38 CET] <BBB> so something is still very wrong
[23:15:40 CET] <kierank> I also find that odd
[23:17:33 CET] <kierank> could be a spec typo
[23:18:26 CET] <BBB> oh I see
[23:18:31 CET] <BBB> you ported the fdct
[23:18:32 CET] <BBB> :-p
[23:18:49 CET] <kierank> crap, yes I did
[23:18:49 CET] <BBB> the test you copied the code from is a reference fdct (8x8) to test the integer 8x8 idct
[23:19:00 CET] Action: kierank can't read
[23:19:43 CET] <kierank> ok the original idct i think was ok, certainly it had interesting pictures
[23:19:47 CET] <kierank> the old float one
[23:20:25 CET] <kierank> ok that explains why the fdct was scaling up...
[23:21:10 CET] Action: kierank copies mpeg idct
[23:21:41 CET] <BBB> I always thought libvpx had a reference idct also
[23:21:44 CET] <BBB> cant find it though :(
[23:24:15 CET] <kierank> ok let's go back to steinar''s idct
[23:26:32 CET] <kierank> let me check the dc falls within the range of spec
[23:28:09 CET] <kierank> might be a bitstream parsing issue
[23:33:56 CET] <BBB> or were scaling the dc wrong ;)
[23:38:24 CET] <kierank> doesn't mpeg2 have a dc that's high precision than AC as well
[23:41:04 CET] <BBB> I dont know, it depends on the scale factors in the implementation
[23:41:13 CET] <BBB> if the dc is wrong, its easy to spot
[23:41:13 CET] <j-b> nevcairiel: 23:20 <@jon_y> j-b: ordinarily I wouldn't but looks alright
[23:41:18 CET] <j-b> nevcairiel: so, done for 5.0.1
[23:41:30 CET] <BBB> the differences are good, but the baseline is wrong
[23:46:48 CET] <kierank> dc quantised: 1043, maximum is 4095 so that seems fine
[23:47:15 CET] <kierank> multiplier is weird
[23:48:28 CET] <kierank> and multiplier is (8 >> intra_dc_precision) x base_quantiser scale x 8
[23:48:56 CET] <kierank> where base_quantiser_scale is 1 / dct_precision
[23:49:04 CET] <kierank> so in practice 8 >> dct_precision
[00:00:00 CET] --- Fri Dec 30 2016