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

[burek]

[00:13:41 CEST] <jamrial_> nevcairiel: ok to push the first two patches from the dts express set?
[00:13:54 CEST] <jamrial_> they mostly move tables around
[00:14:13 CEST] <jamrial_> foo86 should have created the first patch with the -B (detect rewrites) option to make it more readable
[00:34:33 CEST] <nevcairiel> i cant say i looked at them much, but if you think its fine
[00:35:23 CEST] <jamrial_> those two should
[01:13:18 CEST] <cone-562> ffmpeg 03foo86 07master:2df7d4fa4524: avcodec/dca: move huffman data into separate object file
[01:13:19 CEST] <cone-562> ffmpeg 03foo86 07master:1fee770a1cec: avcodec/dca: move channel counter utility into dca.h
[04:25:16 CEST] <cone-280> ffmpeg 03Jan Sebechlebsky 07master:0ff3489534ea: avcodec/mjpeg2jpeg_bsf: Check ff_bsf_get_packet success
[12:27:03 CEST] <wm4> "mpeg2 with alpha"
[12:29:10 CEST] <Compn> wm4 : dont forget "in avi"
[13:23:14 CEST] <cone-738> ffmpeg 03Michael Niedermayer 07master:deaf58abf236: avcodec/mjpegdec: Do not try to detect last scan but apply idct after all scans for progressive jpeg
[13:24:41 CEST] <kierank> always nice to see commits without anything on the ml
[13:28:09 CEST] <wm4> you have to accept that some devs are above reviews
[13:29:24 CEST] <ubitux> i asked michael for that problem
[13:29:35 CEST] <ubitux> i can't share the sample unfortunately
[13:30:19 CEST] <ubitux> (also, he's the maintainer of that file)
[13:45:34 CEST] <durandal_1707> I hate this guy job
[13:53:58 CEST] <kierank> durandal_1707: ?
[13:54:07 CEST] <kierank> ami_stuff
[13:54:08 CEST] <kierank> ?
[13:56:11 CEST] <durandal_1707> yes
[14:29:30 CEST] <BBB> durandal_1707: I would hate to do his job, but Im happy hes doing it
[14:29:40 CEST] <BBB> durandal_1707: I guess thats what you mean?
[14:30:29 CEST] <durandal_1707> I hate bugs
[14:31:02 CEST] <kierank> durandal_1707: btw I spoke to cfhd author
[14:31:35 CEST] <durandal_1707> you are very lucky
[14:32:36 CEST] <durandal_1707> I failed to talk with tak and optimfrog authors
[14:32:58 CEST] <wm4> (not too surprising)
[14:33:29 CEST] <kierank> I spoke IRL
[14:37:26 CEST] <durandal_1707> wow
[14:37:35 CEST] <kierank> he was a cool guy
[14:37:50 CEST] <durandal_1707> was?
[14:40:17 CEST] <BBB> haha
[14:40:22 CEST] <wm4> durandal_1707: multimedia is a tough business
[14:40:34 CEST] <BBB> kierank: arent you the cfhd author?
[14:40:41 CEST] <BBB> or you mean the guy that designed the codec?
[14:40:45 CEST] <kierank> the guy that made the codec
[14:43:25 CEST] <BBB> is this at that las vegas conference last month?
[14:43:37 CEST] <BBB> nab, I guess
[14:44:27 CEST] <BBB> brb
[14:49:55 CEST] <Daemon404> [13:37] <+kierank> he was a cool guy <-- was he at all involved in the 'spec'
[14:50:07 CEST] <kierank> yeah he said the spec was a disaster
[14:50:11 CEST] <kierank> because of smpte politics
[14:50:17 CEST] <kierank> and they've given up on it really
[14:50:21 CEST] <Daemon404> lul.
[14:50:56 CEST] <nevcairiel> so smpte actively wants those crappy specs for some reason?
[14:51:05 CEST] <nevcairiel> i thought its just the companies behind the specs being stupid
[14:54:28 CEST] <wm4> what kind of politics lead to a spec disaster?
[15:02:23 CEST] <Compn> buzzword warfare
[15:22:02 CEST] <ubitux> so BBB posted https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-vp9-encoder-eve-2/ like nothing happened
[15:23:57 CEST] <Shiz> conclusion, vp9 is still slow as shit?
[15:23:59 CEST] <ubitux> BBB: you didn't even shared your blog post
[15:24:13 CEST] <BBB> what did I just run in to (re: shiz)
[15:24:18 CEST] <BBB> ubitux: share where?
[15:24:40 CEST] <ubitux> here at least :P
[15:24:49 CEST] <BBB> I wondered if it was off-topic for ffmpeg :-p
[15:24:51 CEST] <Daemon404> hackew news, reddit
[15:24:53 CEST] <Daemon404> probably.
[15:24:57 CEST] <Daemon404> ubitux loves karma
[15:25:00 CEST] <Daemon404> im sure hell post it
[15:25:04 CEST] <BBB> yeah I should probably do that
[15:25:04 CEST] <kierank> I look forward to when it gets on streamingmediaeurope
[15:25:07 CEST] <kierank> and you get lulz questions
[15:25:23 CEST] <ubitux> Daemon404: yeah, just posted on HN
[15:25:28 CEST] <Daemon404> ;p
[15:25:28 CEST] <BBB> where do I post it on reddit? I never know where to put this kind of stuff& r/linux?
[15:25:31 CEST] <BBB> or r/webm?
[15:25:35 CEST] <kierank> r/programming
[15:25:40 CEST] <BBB> r/vp9 is closed as violating the terms of use (gun-related, I think)
[15:25:51 CEST] <ubitux> don't worry, it will be mirrored from HN
[15:26:34 CEST] <BBB> ok so I dont need to do anything
[15:26:49 CEST] <Shiz> obviously r/x264
[15:26:51 CEST] <mateo`> I think it's relevant here as an encoder using it may land ?
[15:26:51 CEST] <Shiz> duh
[15:27:15 CEST] <Daemon404> BBB, r/programming like kierank said
[15:27:20 CEST] <Shiz> i don't see that happening very soon as long as it's proprietary :p
[15:27:23 CEST] <mateo`> by encoder i mean an ffmpeg one
[15:27:25 CEST] <BBB> Shiz: so, as for speed, typically if I can gain 5-10% and be faster than libvpx, its not hard to simply copy relevant speed settings for higher speed modes (cpu-used) and get the same speed gains
[15:27:43 CEST] <BBB> Shiz: but obviously Im trying to do better than that, so I havent published anything on that subject yet for a reason
[15:28:35 CEST] <ubitux> http://www.twoorioles.com/eve-vp9-video-encoder :(
[15:31:00 CEST] <Shiz> BBB: well, good luck ;p
[15:39:21 CEST] <Daemon404> i wonder how long until the big G attempts to buy out
[15:39:46 CEST] <Daemon404> (asusming they even care about encoeer qualiy
[15:40:28 CEST] <rcombs> "15-20% better than x264" with VP_9_
[15:43:06 CEST] <wm4> BBB: so uh when will you post a patch for a lavc wrapper
[15:43:16 CEST] <BBB> is that useful?
[15:43:24 CEST] <Daemon404> i cant imagine it will be accepted
[15:44:03 CEST] <BBB> rcombs: 15-20% at 360p, thats not bad (given that vp9/hevc are primarily focussed on 1080p/4k)
[15:47:56 CEST] <wm4> well somehow I expected that to become open source, but maybe I'm completely wrong there
[15:48:20 CEST] <JEEB> if you can actually pay people's salary with it ;)
[15:50:45 CEST] <BBB> ubitux: I fixed the website up with a few sentences on stuff.. Ill add images later, but ...
[15:50:50 CEST] <BBB> Id rather code :-p
[15:50:53 CEST] <Daemon404> wm4, something that is only useful if you have a commercial sdk is probably not useful to the general punlic
[15:50:56 CEST] <Daemon404> public even
[15:53:21 CEST] <BBB> wm4: so & yeah, about opensource & I need to figure out ways to make opensource work with paying the rent, and most attempts at that have not been very succesful if theyre purely single software piece based
[15:53:29 CEST] <BBB> wm4: so Im not directly intending to opensource it
[15:57:42 CEST] <BBB> so I would really like to get comments on the visual comparisons, do you guys think theyre helpful/fair/useful/...?
[15:58:08 CEST] <BBB> on-screen visual comparison is easy, but write-down visual comparisons are notoriously hard IMO
[15:58:22 CEST] <Daemon404> is it possible to publish webms/mp4s
[15:58:38 CEST] <Daemon404> short ones obv
[15:59:26 CEST] <Daemon404> [14:34] < maseck> No multithreaded results. I'm guessing that he isn't targeting that.
[15:59:29 CEST] <Daemon404> ^ btw from #daala
[16:02:20 CEST] <BBB> MT is planned but not yet done, right
[16:03:14 CEST] <Daemon404> maybe make a small note
[16:30:34 CEST] <kierank> there were a few live vp9 encoders at nab
[16:30:35 CEST] <kierank> was quite surprising
[16:30:41 CEST] <Daemon404> hw?
[16:30:42 CEST] <Daemon404> or sw?
[16:30:56 CEST] <Daemon404> and did nay use libvpx
[16:32:25 CEST] <kierank> sw i think
[16:32:31 CEST] <kierank> dunno
[16:39:33 CEST] <BBB> crap I should have gone to nab I guess
[16:39:47 CEST] <BBB> kierank: is there a calender of video-related conferences where I should go to?
[16:39:49 CEST] <Daemon404> isnt having a booth at nab expensive
[16:39:55 CEST] <Daemon404> BBB, IBC is the next biggest
[16:40:24 CEST] <BBB> thats around vdd right?
[16:40:31 CEST] <Daemon404> right after
[16:40:35 CEST] <Daemon404> or rather a week after
[16:40:39 CEST] <Daemon404> i think
[16:41:35 CEST] <BBB> I can visit my family/friends in NL that week, maybe
[16:54:05 CEST] <Daemon404> makes sense
[16:54:06 CEST] <Daemon404> ibc is .nl
[17:07:26 CEST] <andrey_utkin> Hi! I find it unfortunate that there's "aspect" option for SAR in libavcodec/options_table.h, but ffmpeg_opt.c squats its name with its "aspect" option which stands for DAR. Any comments please, which solution to this would be welcome? Or is there a way to let ffmpeg CLI util know that it shouldn't parse the option, but pass it to libavcodec? I have tried "-aspect", "-aspect:v", it definitely is percepted as ffmpeg_opt.c option which sets DAR.
[17:43:40 CEST] <Angus> Good morning folks
[17:43:55 CEST] <Angus> Is anyone here familar with H264 byte stream? 
[17:44:19 CEST] <Angus> I'm running into [h264 @ 0xf9c1a0] decoding for stream 0 failed
[17:44:39 CEST] <Angus> where the left is the original file, and the right is the contents being copied into AVIO Buffer: http://i.imgur.com/cZ7pYtE.png
[17:45:19 CEST] <Angus> might anyone recognize what the missing bytes are? and if they are relevant to H264 decode?
[17:45:57 CEST] <Angus> for reference, once the decoding for frame 1 fails, the rest of the video does play, although running into this error every frame: [NULL @ 0xf9d460] non-existing PPS 0 referenced
[17:47:38 CEST] <BtbN> did you try to increase the log level? Also, not a question for this channel.
[17:54:55 CEST] <Angus> BtbN: I'm writing the code to call on the FFMpeg API, the cli app isn't being used here.
[17:55:07 CEST] <BtbN> still not the right channel.
[17:55:53 CEST] <Angus> Oh, should I be in the regular ffmpeg channel?
[18:21:49 CEST] <RiCON> BBB: the second graph in CRF says PSNR but the text implies it should be SSIM(?)
[18:22:22 CEST] <BBB> yup
[18:22:24 CEST] <BBB> let me fix
[18:25:01 CEST] <BBB> RiCON: fixed
[18:52:20 CEST] <Shiz> I'm trying to write a parser that sets some things like block_size and sample_rate, but it seems the decoder inits before that and bails out because these things... aren't set
[18:52:36 CEST] <Shiz> am I doing something architecturally wrong here? the issue is that metadata like that is encoded in the individual frames
[18:52:55 CEST] <Shiz> and I don't feel comfortable stuffing that stuff in the mpeg.c demux code
[19:07:13 CEST] <JEEB> Shiz: I'm pretty sure the single review for that ATRAC3+ parser back in '14 was that one shouldn't set values in avcodeccontext in the parser, but rather just pass on decode'able packets to the decoder
[19:09:55 CEST] <Shiz> well that's a bit of an issue considering the decoder needs these fields filled in
[19:09:58 CEST] <Shiz> or it will bail
[19:10:16 CEST] <JEEB> so the demuxer was setting them before?
[19:10:40 CEST] <Shiz> well, nothing is setting them right now :p but yeah, in OAM stuff the demuxer sets it
[19:11:03 CEST] <Shiz> oma*
[19:11:17 CEST] <Shiz> see lavf/omadec.c
[19:12:56 CEST] <Shiz> specifically around 'case OMA_CODECID_ATRAC3P:'
[19:13:13 CEST] <JEEB> I remember poking around ATRAC3+ some time ago
[19:14:41 CEST] <JEEB> I think the biggest issue is that it expects avtx->channels to be set
[19:14:44 CEST] <JEEB> *avctx
[19:14:56 CEST] <Shiz> it expects more to be set
[19:14:58 CEST] <Shiz> but yes
[19:15:12 CEST] <Shiz> OTOH, setting those valuesi n the mpeg demuxer doesn't seem like a great idea either
[19:15:15 CEST] <JEEB> and yes, that's an architectural FU
[19:15:46 CEST] <JEEB> Shiz: well I just looked at the init
[19:16:43 CEST] <JEEB> and it only seems to require channel count to get through
[19:16:49 CEST] <JEEB> init()
[19:17:38 CEST] <Shiz>     if (!avctx->block_align) {
[19:17:40 CEST] <Shiz> also block_align
[19:43:45 CEST] <kurosu> So I can confirm that the number of threads spawned considerably slows the dirac decoder on Win64 (with 32x16 slices, that's 4050 threads per image...)
[19:44:01 CEST] <kurosu> running per line of slice is a 25% speed improvement for 6 cores/threads
[19:47:20 CEST] <Daemon404> it is unfortunate that someone already replied to say "all of libav's code is faster anyway"
[19:48:13 CEST] <kurosu> err, I didn't read or understand that from anywhere?
[19:48:34 CEST] <kurosu> the decrease I was seeing was just a byproduct of that bad threading
[19:48:45 CEST] <kurosu> not because of the new implementation
[19:49:09 CEST] <kurosu> *new bitstream implementation
[19:49:22 CEST] <Daemon404> https://lists.libav.org/pipermail/libav-devel/2016-May/076493.html
[19:49:24 CEST] <Daemon404> i may have misread
[19:49:33 CEST] <Daemon404> kurosu, OH, ok
[19:50:17 CEST] <kurosu> well, I don't know if the golomb code becomes slower
[19:50:25 CEST] <kurosu> on the fixed dirac decoder, it seems faster
[19:50:31 CEST] <Daemon404> ic
[19:50:42 CEST] <kurosu> so I assume Luca is right, although I haven't tested every and each codec that was ported
[19:51:08 CEST] <kurosu> the easy, high bitrate ones probably are improved (confirmed with prores, dnxhd and huffyuv)
[19:56:20 CEST] <kierank> kurosu: we have that in our vc2hq tree, yes
[19:56:40 CEST] <kierank> it became a nightmare supporting all those ancient variants
[20:02:07 CEST] <durandal_170> so they gonna port all 1000 decoders
[20:04:59 CEST] <kurosu> kierank, is there only one dirac file in fate? Because I assume it doesn't cover the hq & "normal" low delay variants ?
[20:05:13 CEST] <kurosu> and it would be nice having a better coverage in fate
[20:05:19 CEST] <kierank> yes, we should probably add more
[20:08:27 CEST] <kurosu> kierank, how can one trigger one or another profile ?
[20:08:41 CEST] <kierank> use the encoder for hq
[20:08:43 CEST] <kierank> the others no idea
[20:10:13 CEST] <kierank> we got a bit fed up with the other variants
[21:49:04 CEST] <kurosu> kierank / atomnuker, are there restrictions on dimensions with vc2? encoding 640x320 or 352x288 to drc produces content with a few random bytes
[21:49:21 CEST] <kurosu> it does decode to the same content though
[21:49:29 CEST] <kierank> broadcast resolutions most likely
[21:49:43 CEST] <Daemon404> 'random'?
[21:49:52 CEST] <kurosu> 480x270, 960x540, 1920x1080 are fine
[21:50:03 CEST] <kurosu> Daemon404, different every run
[21:50:11 CEST] <kurosu> ie, not good for fate
[21:50:14 CEST] <kierank> dunno, non broadcast  resolutions was atomnuker's bugbear
[21:50:33 CEST] <kierank> and so I am not getting involved in that
[21:51:38 CEST] <kurosu> I won't either then
[21:51:56 CEST] <cone-273> ffmpeg 03Christophe Gisquet 07master:79e86640ff55: fate: wma: add lossless 24bits tests
[21:52:20 CEST] <Daemon404> does this mean 24bit wma lossless works now?
[21:52:35 CEST] <Daemon404> i have checks at work to make sure ffmpeg never decoded it (because it was insanely wrong before)
[21:53:19 CEST] <kurosu> I suppose, those are files that had problems before and pinpointed various bugs
[21:53:33 CEST] <Daemon404> oic
[21:53:46 CEST] <Daemon404> it used to e.g. decode to almost-silence sometimes
[21:53:48 CEST] <atomnuker> kurosu: I'm not seeing anything wrong at those resolutions with any pixel format 
[21:53:48 CEST] <Daemon404> users really hate that
[21:53:50 CEST] <Daemon404> better to fail
[21:56:43 CEST] <kurosu> atomnuker, ran along ffmpeg -f rawvideo -s 640x320 -pix_fmt yuv420p -threads 1 -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact -i vsynth1.yuv -threads 1 -pix_fmt yuv420p -vcodec vc2 -frames 5 -strict -1 -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact -y vsynth1-vc2-420p.drc && md5sum vsynth1-vc2-420p.drc && ffmpeg -i vsynth1-vc2-420p.drc -f crc - 2>&1 | grep CRC
[21:57:01 CEST] <kurosu> (actually, edited line generated by fate, but you should see the idea)
[21:59:39 CEST] <atomnuker> kurosu: the CRC doesn't change between runs
[21:59:44 CEST] <kurosu> no
[21:59:53 CEST] <atomnuker> at least on my machine
[21:59:55 CEST] <kurosu> but the md5 sum of the input file does
[22:00:15 CEST] <atomnuker>  vsynth1-vc2-420p.drc?
[22:00:33 CEST] <atomnuker> that doesn't vary either
[22:01:24 CEST] <kurosu> ah
[22:01:31 CEST] <kurosu> atomnuker, work in progress: https://0x0.st/NHt.patch
[22:01:50 CEST] <kurosu> varies every run here with these resolutions
[22:02:12 CEST] <kurosu> I don't have a memory poisoner/valgrind at hand, so can't say if it's by luck or anything
[22:02:48 CEST] <kurosu> when it was failing for mov, I decided to go raw with drc but no change
[22:07:11 CEST] <atomnuker> kurosu: what's the fate test name?
[22:07:39 CEST] <atomnuker> ah nvm
[22:07:57 CEST] <kurosu> $( make fate-list | grep vc2 ) :D
[22:08:38 CEST] <kurosu> I can force the resolution but well, that's fragile
[22:14:26 CEST] <atomnuker> kurosu: no reference file
[22:14:58 CEST] <kurosu> run fate with GEN=1
[22:15:44 CEST] <kurosu> or I'm misunderstanding your sentence
[22:19:24 CEST] <kurosu> it may fail with vsynth3 or vsynth_lena but that's not the matter atm
[22:20:59 CEST] <atomnuker> nope, none of the pixel formats fail here, no matter how many times I rerun them
[22:21:06 CEST] <atomnuker> valgrind doesn't say anything as well
[22:21:23 CEST] <atomnuker> I'll try it again with gcc
[22:21:34 CEST] <kurosu> oh, that wasn't with gcc
[22:21:45 CEST] <kurosu> I'm using 5.1 and Win64
[22:21:59 CEST] <atomnuker> gcc 5.1?
[22:22:16 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07master:11db7eee9b00: avformat/options_table: Add missing identifier for very strict compliance
[22:22:17 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07master:9fcb59c9bc5c: avcodec/options_table: fix strict compliance constant flags to match the strict field
[22:23:05 CEST] <durandal_170> Daemon404: yes, 24bit support should be working, previous hack was just evil and lazy
[22:23:46 CEST] <kurosu> yeah, I don't want to bother with various people toolchains, and the one I get allows me to build Win32 binaries by just passing -m32 when needed
[22:24:09 CEST] <kurosu> (using msys2, but not their toolchain)
[22:24:25 CEST] <kurosu> anyway, I'll just force the resolution
[22:26:07 CEST] <kurosu> https://0x0.st/NH6.patch <- should run work, but only tests 1080p
[22:26:52 CEST] <kurosu> *fate should work
[22:26:55 CEST] <atomnuker> nope, everything still passes with gcc 6.1
[22:27:13 CEST] <atomnuker> if you could somehow get me a valgrind log that'd be nice
[22:27:31 CEST] <atomnuker> I don't have a windows system at hand to test with
[22:27:36 CEST] <kurosu> I can't, Win64, and then it would be another computer then
[22:27:43 CEST] <kurosu> but I'll try to see if I can reproduce
[22:28:01 CEST] <kurosu> not for tonight though
[22:29:18 CEST] <atomnuker> alright, thanks
[22:30:14 CEST] <kurosu> what's the plans for submitting the improved dirac (lowdelay) decoder ?
[22:30:20 CEST] <kurosu> *what are
[22:30:41 CEST] <kurosu> atm it's not very nice that threading causes that kind of issues
[22:34:17 CEST] <atomnuker> it's not yet significantly improved other than it's stable-er, decodes in rows and does the idwt in parallel
[22:35:13 CEST] <atomnuker> also it supports decoding field-coded pictures (which definitely didn't use to play nice at all with the rest of the decoder)
[22:36:17 CEST] <kierank> I'd like to merge it I guess as a vc2hq decoder
[22:36:20 CEST] <atomnuker> the problem is that vc2 and dirac are basically the same codec and you can't really differentiate between them
[22:36:25 CEST] <atomnuker> so you'd have to call the decoder from the current dirac decoder
[22:36:26 CEST] <kierank> but it's a pain in the arse to say the least
[22:36:39 CEST] <atomnuker> which isn't a pretty thing IMO
[22:43:36 CEST] <kurosu> well the decoding in rows is a 25% speedup here
[22:43:42 CEST] <kierank> yes
[22:44:04 CEST] <kurosu> you can probably create a new decoder that calls the same functions, only switching on the codec name
[22:44:12 CEST] <kierank> nontrivial to implement for non inra though
[22:44:18 CEST] <kurosu> vc2 is intra only ie could use frame threading
[22:44:56 CEST] <kierank> yes but perverse to use frame threading for a low delay codec
[22:45:18 CEST] <kurosu> yes, once you have implemented (efficiently) slice threading
[22:47:32 CEST] <kierank> probably easy to backport yet
[22:47:38 CEST] <kierank> s
[23:41:18 CEST] <kierank> lol "Resubmitting test file, commands and console as per Carlos' request."
[23:59:52 CEST] <cone-273> ffmpeg 03foo86 07master:ce2f9fdb0a92: avcodec/dca: fix sync word search error condition
[00:00:00 CEST] --- Tue May  3 2016