[03:39:21 CEST] <jamrial> Daemon404, wm4: valgrind is complaining after either the latest merge batch or the new decode api [03:40:21 CEST] <jamrial> vc1 tests only [04:50:13 CEST] <cone-224> ffmpeg 03Michael Niedermayer 07master:268b5ae10aa6: doc/APIchanges: Fix bistream typo [08:11:03 CEST] <cone-511> ffmpeg 03Lou Logan 07master:3eafbbe70a10: doc/APIchanges: Fix bitsream typo [09:12:45 CEST] <wm4> hm will take a look at the vc1 valgrind thing later [10:51:05 CEST] <fritsch> wm4: do you have an email adresse that I can use when writing to the intel mesa / drm folks for a EGL image interop possibility for hevc-10bit? [10:52:50 CEST] <wm4> fritsch: you could use the one I have on github and the ffmpeg mailing list [10:53:01 CEST] <fritsch> i looked into your last commit [10:53:04 CEST] <fritsch> wm4@nowhere [10:53:07 CEST] <fritsch> but i will find it :-) [10:53:12 CEST] <wm4> https://github.com/wm4/ [10:53:25 CEST] <wm4> also, remind those guys that D3D11 provides this just fine on Windows [10:53:36 CEST] <fritsch> Will do [10:54:43 CEST] <fritsch> wm4: G16, GR1616 would be fine I think for now [10:54:51 CEST] <fritsch> but let's see what they reply to us [10:55:04 CEST] <fritsch> i added everyone that contributed to the last mesa changes [10:56:06 CEST] <wm4> yep, I'd expect a 16 bit fixed-point texture [10:57:54 CEST] <fritsch> sent [10:58:06 CEST] <fritsch> if something is technically wrong, does not matter - they know we are coming now :-) [10:58:09 CEST] <fritsch> and need something [10:59:14 CEST] <wm4> thanks for doing this [10:59:44 CEST] <fritsch> i have a selfish own interest in that :-) [10:59:58 CEST] <fritsch> as I want to watch future live tv [11:00:17 CEST] <fritsch> nope - the real reason is: i know the oss world stuff for too long ... have seen too many ugly workarounds [11:00:26 CEST] <fritsch> that all had some disadvantages at a point [11:00:33 CEST] <fritsch> so we need to do it right from the beginning [11:00:39 CEST] <fritsch> and that's the way to go [11:02:27 CEST] <wm4> yeah, with the EGL interop, video rendering with vaapi finally becomes less of a joke [11:03:06 CEST] <wm4> those who are into doing TVs with Linux seem to be more into using Intel's fixed-function video rendering, though [11:03:18 CEST] <wm4> to the point of declaring video rendering with OpenGL a ridiculous idea [11:03:39 CEST] <fritsch> yeah - I also had such a discussion [11:03:44 CEST] <fritsch> with a wayland dev ... [11:03:50 CEST] <wm4> me too [11:03:51 CEST] <fritsch> an gstreamer highpriest [11:04:58 CEST] <fritsch> kodi's some million users with an upcoming perfect BXT setup also have some influence [11:05:05 CEST] <fritsch> so - it will work out - I am sure [11:06:14 CEST] <wm4> surely it will [14:22:00 CEST] <Daemon404> wm4, did you look into that valgrind thing? [14:26:08 CEST] <wm4> Daemon404: not yet, but will do today [14:27:01 CEST] <Daemon404> ok [15:37:36 CEST] <atomnuker> Gramner: can you check if I'm doing something obviously wrong in this piece of assembly: https://0x0.st/Zez.diff ? [15:39:35 CEST] Action: Daemon404 wonders why firefox wont display diff as text [15:45:07 CEST] <durandal_1707> don't use Firefox [15:51:13 CEST] <wm4> get the "Open in Browser" extension and never worry again [15:55:56 CEST] <wm4> meh every time I pull and rebuild, the build first goes well, and then errors because configure wasn't rerun [15:56:36 CEST] <Daemon404> this happens when new codecs or demuxers are added [15:56:52 CEST] <wm4> I know (but usually it's due to new filters) [15:57:25 CEST] <Daemon404> ideally the build system would be smart enough [15:57:29 CEST] <Daemon404> (based on date of all*.c) [15:57:31 CEST] <Daemon404> ideally. [15:58:10 CEST] <wm4> in theory it prints a warning message at some point [15:58:54 CEST] <wm4> so, how do I run fate with valgrind? [16:00:23 CEST] <nevcairiel> configure --toolchain=valgrind [16:01:03 CEST] <nevcairiel> or rather --toolchain=valgrind-memcheck [16:01:06 CEST] <wm4> uh, so rebuilding again [16:06:56 CEST] <Shiz> can't make it easy now can you [16:07:28 CEST] <wm4> well I still don't know how to make fate use vaslgrind [16:09:39 CEST] <wm4> seems like I needed TARGET_EXEC=valgrind [16:10:09 CEST] <wm4> I did "make fate-vc1 -j4 SAMPLES=../fate/ TARGET_EXEC=valgrind" but nothing shows up, seems all fine [16:13:36 CEST] <Daemon404> wm4, try with THREADS=N? i dunno [16:13:44 CEST] <Daemon404> or wait for jamrial to appear [16:13:57 CEST] <wm4> added THREADS=4, nothing [16:14:12 CEST] <nevcairiel> wm4: if you configure with that it should use the target exec automatically [16:14:45 CEST] <wm4> nevcairiel: it appears it didn't [16:14:48 CEST] <BBB> Daemon404: is the h264 bug still there? [16:16:17 CEST] <Daemon404> BBB, yes [16:18:19 CEST] <BBB> Daemon404: where is the file? [16:18:24 CEST] <BBB> and trac thing? [16:22:30 CEST] <Daemon404> https://trac.ffmpeg.org/ticket/5458 [16:22:33 CEST] <Daemon404> all info and file there [16:37:10 CEST] <BBB> did you try with er turned off? [16:37:16 CEST] <BBB> assuming the bug is b/c the file is damaged [16:41:27 CEST] <BBB> Ill look at it maybe after lunch or so, have had a long long week so a little downtime would be nice [16:49:20 CEST] <Gramner> atomnuker: does that asm work correctly? [16:55:20 CEST] <atomnuker> Gramner: no, every 2 samples appear darker and seem to be clipping [16:55:57 CEST] <atomnuker> so I was wondering if maybe the values were too large for pmuhswr [16:55:59 CEST] <Gramner> you seem to be reversing the bytes in each pixel [16:56:22 CEST] <Gramner> or is that supposed to happen? [16:57:04 CEST] <atomnuker> yes, they have different endianess [17:00:03 CEST] <Gramner> 10-bit values are fine with pmulhrsw [17:01:15 CEST] <Gramner> 0x7fff for multiply by 1 starts to fail with inputs larger than 0x4000 [17:02:13 CEST] <Gramner> but you don't reverse the bytes in the c version? [17:02:27 CEST] <Gramner> av_le2ne32 is a no-op on x86 [17:12:52 CEST] <JEEB> wm4: btw do you think that we should be exporting pgs and other ycbcr based subpictures as 4:4:4 with alpha? [17:13:23 CEST] <wm4> JEEB: maybe we should - but currently we can't [17:13:51 CEST] <wm4> they should be exported as their native format, paletted yuv [17:13:58 CEST] <wm4> which is satan [17:20:22 CEST] <BBB> paletted yuv [17:20:23 CEST] <BBB> omg [17:20:38 CEST] <BBB> next comes paletted bayer [17:21:14 CEST] <Daemon404> i sitll, and always will, maintain exporting paletted "colorspaces" is dumb. [17:21:58 CEST] <nevcairiel> if anything subtitles should be converted to AVFrame somehow, then you can export subtitles using de-palettized yuv [17:22:34 CEST] <wm4> de-palettizing is an attractive idea, but could make things slower in some scenarios [17:22:43 CEST] <wm4> we can just hope it doesn't matter [17:23:27 CEST] <Daemon404> slower, or "now its only 800x realime insteam of 1000x"? [17:24:12 CEST] <nevcairiel> the only source for PGS is blu-ray, which is 1080p video or some such, pgs subtitle decoding pales in comparison to even parsing the bitstream of the video =p [17:35:30 CEST] <BBB> I think for transcoding the idea of having access to the original paletted buffer makes sense [17:35:41 CEST] <BBB> but thats about the only thing I can think of where its sensible [17:39:52 CEST] <Daemon404> BBB, we have other various "reasons" like passing it to libavfilter [17:40:04 CEST] <Daemon404> to benefit in some way for ... things? [17:40:08 CEST] <wm4> subtitles can't be represented as single AVFrame [17:40:16 CEST] <wm4> so it's not that simple wrt. lavfi [17:40:38 CEST] <wm4> (at least pgs subs can have multiple bitmaps) [17:40:39 CEST] <Daemon404> they could if it had a duration [17:40:54 CEST] <BBB> multiple bitmaps? [17:41:01 CEST] <wm4> Daemon404: that's also not enough [17:41:02 CEST] <nevcairiel> lavfi doesnt do subtitles right now either way =p [17:41:02 CEST] <BBB> like highlight on/off or so? [17:41:17 CEST] <wm4> BBB: just multiple bitmaps [17:41:29 CEST] <nevcairiel> BBB: it can have multiple distinct images on the screen at the same time, with their own palette even if they wanted to etc [17:41:54 CEST] <Daemon404> i would just render them as one... it's a bluray [17:41:56 CEST] <Daemon404> res is known. [17:42:23 CEST] <nevcairiel> pgs has a fiel for presentation size either way [17:42:26 CEST] <nevcairiel> field* [17:42:27 CEST] <Daemon404> i would admit its kind of annoying i there are weird timign overlaps [17:42:40 CEST] <JEEB> yeah, presentation size is there anyways [17:42:43 CEST] <nevcairiel> and you would potentially need to re-render it when one of them times out [17:42:44 CEST] <wm4> Daemon404: yeah, I suggested that too once [17:42:48 CEST] <nevcairiel> which is weird [17:43:10 CEST] <Daemon404> nevcairiel, this is how dvd subs were coded iirc [17:43:16 CEST] <Daemon404> as in on the dvd itself. [17:43:25 CEST] <JEEB> on DVDs only one could be active anyways [17:43:27 CEST] <JEEB> at a given time [17:43:28 CEST] <JEEB> IIRC [17:43:28 CEST] <wm4> don't dvd subs just use rle [17:43:36 CEST] <Daemon404> wm4, not what i meant [17:43:38 CEST] <wm4> so they code the whole frame [17:43:39 CEST] <nevcairiel> dvds only have one active object, so if they want two, they need to code a big image containing both [17:43:45 CEST] <Daemon404> i meant dvd subs essentially re-render [17:43:48 CEST] <Daemon404> like nevcairiel was describing [17:43:50 CEST] <wm4> yeah [17:43:51 CEST] <Daemon404> due to format limitations [17:43:58 CEST] <wm4> and highlights are satan [17:44:08 CEST] <wm4> they can't really be done with libavcodecs decoder [17:44:10 CEST] <nevcairiel> but pgs is more dynamic, screwing this dynamic and just making everything dumb again seems less then ideal [17:44:15 CEST] <Daemon404> wm4, i heard you love per-character sub styles [17:44:38 CEST] <nevcairiel> wm4: you know whats fun, animated dvd subtitles [17:44:45 CEST] <Daemon404> nevcairiel, it's almost as if subtitles are out of place in a video/audio library. [17:44:48 CEST] <Daemon404> almost. [17:44:59 CEST] <wm4> nevcairiel: they just have high bitrate right [17:45:34 CEST] <Daemon404> i used to have a piece of code that rendered after effects generated overlays (like fansubbers use for signs) as bluray subs [17:45:37 CEST] <nevcairiel> wm4: no, the subtitle itself is static, it just codes multiple palettes to fade them in and out =p [17:45:38 CEST] <Daemon404> one per frame [17:45:38 CEST] <wm4> bitmap sub decoders in lavc are almost reasonable [17:45:44 CEST] <Daemon404> i wonder if wm4 would murder me if i dug it up [17:45:45 CEST] <wm4> what gets me are text subtitle converters in lavc [17:45:54 CEST] <wm4> Daemon404: possible [17:46:18 CEST] <wm4> the best thing I've ever seen was a mkv file with 300MB or so of ASS extradata [17:46:18 CEST] <Daemon404> youll be happy to know i stopped fansubbing before we could render bluray subs [17:46:21 CEST] <Daemon404> so it never did anything. [17:46:24 CEST] <BBB> overlay rendering into bitmap is silly [17:46:25 CEST] <wm4> with useless aegisub crap in it [17:46:30 CEST] <wm4> (easily half of the file size) [17:46:31 CEST] <BBB> a proper player overlays them as separate textures [17:46:40 CEST] <Daemon404> BBB, of course. [17:46:52 CEST] <BBB> and then timing overlap doesnt matter [17:46:58 CEST] Action: BBB goes pick up kids from school [17:47:02 CEST] <BBB> will look at h264 issue later [17:47:03 CEST] <BBB> bye [17:47:06 CEST] <Daemon404> aloha. [17:47:52 CEST] <JEEB> anyways, I guess for now we'll just have to do the PAL8 dance [17:48:16 CEST] <JEEB> also I always thought the PAL there was for NTSC,PAL,SECAM PAL [17:48:18 CEST] <Daemon404> not me becaus ei dont care about subtitles! [17:48:44 CEST] <JEEB> :) [17:51:12 CEST] <JEEB> also I do wonder why there's YUV_TO_RGB1 and 2. first one takes your chroma and the second takes your r,g,b and luma [17:52:34 CEST] <Daemon404> JEEB, because mutlimedia is neverending pain, to quote wm4. [17:52:53 CEST] <JEEB> yup [18:22:22 CEST] <cone-582> ffmpeg 03Anton Khirnov 07master:e3dfef8e3c85: qsvdec_h2645: switch to the new BSF API [18:22:23 CEST] <cone-582> ffmpeg 03Anton Khirnov 07master:704a39769719: rtmpdh: add an stdio.h include [18:22:24 CEST] <cone-582> ffmpeg 03Derek Buitenhuis 07master:a980cc47cd01: Merge commit 'e3dfef8e3c85a64dbe6388117303f5819fa3c6a2' [18:22:25 CEST] <cone-582> ffmpeg 03Derek Buitenhuis 07master:53a9b164c560: Merge commit '704a39769719d2e1ae3f13bfc562b51c9cd002d7' [18:25:28 CEST] <wm4> ah, skipped [18:25:35 CEST] <Daemon404> i mailed Ivan [18:25:59 CEST] <Daemon404> also apparently qsv decoder has crashed for 11 days [18:26:01 CEST] <Daemon404> and nobody noticed [18:26:07 CEST] <Daemon404> according to him [18:26:21 CEST] <Daemon404> it took less time for someone to notice libnut... [18:51:19 CEST] <jamrial> wm4: did you look at vc1 valgrind memleaks? [18:51:54 CEST] <jamrial> judging by the commits since the last good run, the new decode api is most likely at fault [18:53:02 CEST] <wm4> jamrial: ah, so just memory leaks? what fate command line would show this? [18:53:22 CEST] <wm4> just running with valgrind I see no additional output [18:54:02 CEST] <jamrial> http://fate.ffmpeg.org/report.cgi?time=20160422161453&slot=x86_64-archlinux-gcc-valgrind [18:54:24 CEST] <jamrial> configure with --toolchain=valgrind and run any of those vc1 tests [18:55:10 CEST] <jamrial> valgrind-memcheck, rather [18:55:29 CEST] <nevcairiel> thats what I said [18:55:30 CEST] <nevcairiel> works for me [18:58:11 CEST] <wm4> it doesn't use valgrind by default for me [18:58:19 CEST] <wm4> and enabling it explicitly doesn't show any warnings [18:59:18 CEST] <jamrial> let me see if i can reproduce it [19:04:00 CEST] <jamrial> yep [19:05:12 CEST] <jamrial> configure --enable-gpl --toolchain=valgrind-memcheck --samples=/path/to/samples && make fate-vc1_ilaced_twomv [19:06:40 CEST] <jamrial> using gcc 5.3 on linux x86_64 [19:06:46 CEST] <jamrial> wm4: ^ [19:07:33 CEST] <jamrial> or try "valgrind --error-exitcode=1 --malloc-fill=0x2a --track-origins=yes --leak-check=full --gen-suppressions=all --suppressions=/path/to/ffmpeg-src/tests/fate-valgrind.supp /path/to/ffmpeg-build/ffmpeg -nostdin -nostats -cpuflags all -flags +bitexact -hwaccel none -threads 1 -thread_type frame+slice -i /path/to/samples/vc1/ilaced_twomv.vc1 -flags +bitexact -fflags +bitexact -f framecrc -" [19:10:24 CEST] <wm4> ah, --toolchain=valgrind-memcheck was PEBKAC, and now fate fails as well [19:10:31 CEST] <wm4> *not working [19:19:16 CEST] <wm4> jamrial: does fate with valgrind generally fully succeed? [19:20:41 CEST] <wm4> api-threadmessage fails [19:21:09 CEST] <wm4> but I'm fairly sure it prints system-dependent crap anyway, or worse [19:23:29 CEST] <BBB> Daemon404: I can not reproduce the different output [19:23:34 CEST] <BBB> Daemon404: or corruption [19:23:37 CEST] <BBB> Daemon404: it works fine for me [19:25:19 CEST] <Daemon404> are you sure [19:25:22 CEST] <Daemon404> even carl reprod it [19:25:34 CEST] <Daemon404> which file are you testing, mine or carl's? [19:27:22 CEST] <jamrial> wm4: supposedly, yeah. ubitux's boxes show that every other test passes [19:29:50 CEST] <jamrial> configure with --disable-stripping (or use ffmpeg_g if you run the command above), otherwise the backtrace will not be useful [19:30:02 CEST] <wm4> it's a minor memory leak, do you want to review it or can I just push? [19:30:28 CEST] <jamrial> if it's trivial and it fixes it then just push [19:31:02 CEST] <cone-423> ffmpeg 03wm4 07master:27adf9f9cdbc: avcodec/utils: fix minor memory leaks on avcodec_open2() failure [19:32:47 CEST] <BBB> Daemon404: carl's [19:33:05 CEST] <Daemon404> i cannot vouch for his cut [19:33:22 CEST] <BBB> $ ./ffmpeg -threads 8 -i ~/Downloads/nondeterministic_cut.h264 -f framemd5 -nostats -v 0 -|md5 [19:33:23 CEST] <BBB> f69630d6c78fa2b4a1a838ea13fc5a76 [19:33:26 CEST] <BBB> it never changes [19:34:44 CEST] <Daemon404> ill check, but like i said, i cant vouch for carl's cut. [19:36:09 CEST] <Daemon404> especially since he uploaded an annexb stream, which means he ran a BSF on it [19:40:18 CEST] <Daemon404> BBB, i cant reproduce it with carl's file [19:40:21 CEST] <Daemon404> but i CAN with mine [19:40:26 CEST] <BBB> hm... [19:40:26 CEST] <Daemon404> i dont know how he made his cut. [19:40:50 CEST] <BBB> do the frame numbers in his seq correspond to where you see issues? [19:40:57 CEST] <BBB> (in his crc diff) [19:40:59 CEST] <BBB> or not even that? [19:41:06 CEST] <BBB> if not, we should remove his comment as unrelated [19:41:16 CEST] <BBB> I dont want multiple issues in one trac entry [19:41:18 CEST] <Daemon404> i have no idea what his cut is from or how it is related [19:41:40 CEST] <BBB> ok, can repro with yours [19:41:47 CEST] <BBB> $ for n in `seq 0 10`; do ./ffmpeg -threads 8 -i ~/Downloads/nondeterministic.mp4 -f framemd5 -nostats -v error -|md5; done [19:41:47 CEST] <BBB> 503761ed866c82ab06a5717757b4cc1d [19:41:48 CEST] <BBB> 0aa0670d052dd0e4fd0de28222a7e717 [19:42:34 CEST] <Daemon404> i managed to repro with his... once [19:42:40 CEST] <Daemon404> it might just be really hard with a small sample? [19:42:46 CEST] <Daemon404> this is a race cond after all [19:43:06 CEST] <BBB> perhaps [19:44:31 CEST] <Daemon404> btw insterestingly, using your cmdline above, i get 53a96fb1350e6dbd5a35053c8f5282a6 [19:44:39 CEST] <Daemon404> except once in a while [19:45:43 CEST] <BBB> $ for n in `seq 0 1000`; do md5=`./ffmpeg -threads 8 -i ~/Downloads/nondeterministic_cut.h264 -f framemd5 -nostats -v error -|md5`; if [ $md5 != f69630d6c78fa2b4a1a838ea13fc5a76 ]; then echo $md5; fi; done [19:45:43 CEST] <BBB> a5308eca9ff7e6c3adc6a882290ff1a0 [19:45:44 CEST] <BBB> 9d7716a42b36ebf6367229de95ec5238 [19:45:45 CEST] <BBB> that works [19:46:30 CEST] <BBB> ok lets work with what we have [19:48:17 CEST] <BBB> did framemd5 output change? [19:48:21 CEST] <BBB> my checkout may be a little old [19:48:27 CEST] <BBB> that may cause your md5 being different [19:48:28 CEST] <Daemon404> yeah i think so [19:48:31 CEST] <Daemon404> thats probably why [20:08:32 CEST] <cone-423> ffmpeg 03Jan Sebechlebsky 07master:f9d7e9feec2a: avformat/tee: Fix leaks in tee muxer when open_slave fails [20:08:33 CEST] <cone-423> ffmpeg 03Jan Sebechlebsky 07master:2063f3ed9c2f: avformat/tee: Handling slave failure in tee muxer [21:07:48 CEST] <JEEB> https://github.com/jeeb/ffmpeg/commit/8e1b13e440182391ec826c4723fa910881e091... [21:07:51 CEST] <JEEB> comments pl0x [21:09:28 CEST] <wm4> why do you determine hdtv vs. sd it lazily? [21:09:38 CEST] <wm4> and then stick to the result? [21:09:59 CEST] <JEEB> if you're OK with it changing with every presentation segment I can do that, too [21:10:33 CEST] <JEEB> it's just that cehoyos's patch had the default -1 value and seemed to try to do that - although it had some weird logic there [21:10:35 CEST] <wm4> I just see no reason to it lazily... although the current code structure could be used to force it via a private option [21:10:59 CEST] <wm4> also not too fond of extending this cryptic macroshit [21:11:22 CEST] <JEEB> well it's basically that or we start dragging zimg or BBB's proper colorimetry thing in [21:11:36 CEST] <wm4> what proper colorimetry thing? [21:11:57 CEST] <JEEB> he made the new colorspace filter I think [21:12:47 CEST] <JEEB> (cehoyos's second patch was http://up-cat.net/p/35963179 ) [21:12:58 CEST] <JEEB> (see how it overrides things to SD :P) [21:13:42 CEST] <JEEB> but yeah, I do hate the macroshit [21:13:56 CEST] <JEEB> but in the short term there's just the macroshit unless we start dragging in dependencies [21:14:05 CEST] <wm4> "avctx->pix_fmt = AV_PIX_FMT_PAL8;" lol didn't spot that yet [21:14:24 CEST] <wm4> (it's just context, but it's "fun" on its own) [21:17:37 CEST] <TMA-1> Hi all, I know there is a built-in DCT in ffmpeg, but are there any wavelet transforms that I could make use of? [21:19:26 CEST] <JEEB> wm4: so basically I just unlazify it [21:21:42 CEST] <JEEB> wm4: https://github.com/jeeb/ffmpeg/commit/b1f16b679cf331ba9c264c2a564d2e852e690c... [21:21:45 CEST] <JEEB> unlazified [21:22:18 CEST] <JEEB> argh, the comment [21:22:24 CEST] <wm4> yeah, better, although there's still no need for the ctx->hdtv field [21:22:45 CEST] <JEEB> ? [21:23:00 CEST] <wm4> you could just use avctx->height and compare it directly when converting the colors, tight? [21:23:02 CEST] <wm4> *right [21:23:16 CEST] <JEEB> the video track might not be the original [21:24:05 CEST] <JEEB> as far as I can see the video width and height have to follow the original presentation video's size [21:24:07 CEST] <wm4> it does this: ret = ff_set_dimensions(avctx, w, h); [21:24:12 CEST] <wm4> which means avctx->height is set to h [21:24:18 CEST] Action: JEEB facepalms [21:25:45 CEST] <JEEB> so I should check for (h < 0 || h > 576) in the conversion spot? [21:25:53 CEST] <JEEB> the default was -1 , right? [21:26:16 CEST] <JEEB> (I have no idea if our parser will go into this spot without proper height/width) [21:26:52 CEST] <JEEB> if the default's zero then not much can be done about that and I'll just check for h > 576 [21:27:18 CEST] <wm4> no idea, I thought the size was always known [21:27:46 CEST] <JEEB> not sure if a presentation segment has to always come before a palette segment [21:28:19 CEST] <wm4> ah good point [21:28:52 CEST] <JEEB> and the private option kind of lets you have a default that you know how it works, as opposed to avctx's which I don't remember the workings of at all [21:29:20 CEST] <JEEB> although since the valid values of height are known [21:29:30 CEST] <JEEB> I could check if h == 480 || h == 576 [21:29:37 CEST] <JEEB> and otherwise HDTV [21:29:55 CEST] <JEEB> which should hopefully include the avctx default [21:31:42 CEST] <JEEB> so which solution do you think is better? [21:32:56 CEST] <wm4> the palette is always copied on output [21:33:20 CEST] <wm4> so the color conversion could be moved to output (in display_end_segment) [21:33:44 CEST] <wm4> of course that's a bit more complicated [21:34:16 CEST] <JEEB> yeaaah... [21:36:15 CEST] <JEEB> but isn't that already an RGB'ized palette btw? [21:36:23 CEST] <JEEB> in display_end_segment [21:40:50 CEST] <jamrial_> TMA-1: check jpeg2000dwt.c, maybe [21:43:26 CEST] <atomnuker> TMA-1: you can use vc2's DWT transforms [21:43:44 CEST] <atomnuker> they're simpler to use and set up [21:43:48 CEST] <atomnuker> or snow [21:45:46 CEST] <JEEB> wm4: I guess I'll go with the extra field for now... while I probably know the default values for avctx->height I'm lazy [21:52:03 CEST] <wm4> JEEB: this would still output a first bogus subtitle if it goes wrong? [21:52:55 CEST] <JEEB> if there is no presentation segment yet and you are watching subtitles made for SD, yes [21:53:14 CEST] <JEEB> because the default is HD [21:54:57 CEST] <TMA-1> atomnuker: Ah I didn't see them before. Do you know if they have a db2 transform? [21:55:10 CEST] <JEEB> of course this is all due to the design where we convert to RGB at this point in the process (and the fact that we're converting at all) [21:55:34 CEST] <JEEB> but I don't care about PGS enough to start reworking the whole "decoder" [22:02:57 CEST] <atomnuker> TMA-1: db2 transform? [22:03:37 CEST] <atomnuker> Daubechies? [22:07:41 CEST] <TMA-1> atomnuker: yes, sorry [22:07:53 CEST] <TMA-1> Daubechies D4 transform (which I believe is also known as 'db2'). [22:08:36 CEST] <atomnuker> not sure what kind of Daubechies vc2/dirac uses, but either way that transform's missing from the encoder [22:09:03 CEST] <atomnuker> only LeGall, Deslauries-Dubuc 9/7 and Haar are implemented on the encoder side [22:09:39 CEST] <atomnuker> I think libschroedinger has Daubechies though [22:11:18 CEST] <TMA-1> Huh, didn't know about libschroedinger, will check that out. Thanks atomnuker. [22:37:34 CEST] <fner> Hello. Is this a good place to ask about building libav* libs for windows? [22:44:12 CEST] <Compn> fner : no, try #ffmpeg [22:44:18 CEST] <Compn> this channel is for devs [22:56:38 CEST] <fner> thanks! [23:18:03 CEST] <wm4> wow [23:20:50 CEST] <ln-> could be spam [23:21:13 CEST] <iive> it is definitely a spam [23:21:47 CEST] <iive> the problem is how tecsolution account have been created and elevated [23:23:11 CEST] <iive> michaelni: [23:25:34 CEST] <BtbN> i wonder what the point of this kind of spam is. Noone in their right mind would respond to that. [23:28:00 CEST] <iive> it's in the wiki on the website [23:28:09 CEST] <iive> they abuse ffmpeg ranking [23:29:15 CEST] <iive> these are fishing sites. [23:30:09 CEST] <BtbN> it's just a phone number? [23:31:54 CEST] <iive> just disable the account [23:32:02 CEST] <iive> and delete these pages, if you have admin rights [23:32:15 CEST] <iive> never heard of microsoft support call scam? [23:34:01 CEST] <BtbN> I don't have any special permissions on trac [23:40:04 CEST] <michaelni> accont deleted [23:40:31 CEST] <BBB> tnx [23:40:43 CEST] <BBB> isnt there a badwords wiki page? [23:41:18 CEST] <michaelni> yes [23:41:24 CEST] <BBB> I forgot the exact name [23:42:17 CEST] <michaelni> me too :( [23:43:16 CEST] <michaelni> https://trac.ffmpeg.org/wiki/BadContent [23:43:35 CEST] <michaelni> also he passed captcha checks [23:44:22 CEST] <BBB> its probably a person, not a machine [23:44:37 CEST] <BBB> the time between page creations was very long [23:45:10 CEST] <BBB> if you give me delete permissions Ill simply delete all the pages he created :-p [23:46:47 CEST] <BBB> and maybe add (?i)helpline to BadContent (Im not a maintainer either so I cant do that either) [23:47:17 CEST] <JEEB> yeah, spammers have noticed that it can actually be cheaper to pay people to post spam than to develop a system that keeps up to speed with CAPTCHA systems [23:48:10 CEST] <BBB> BadIP even better ;) [23:48:40 CEST] <michaelni> BBB, whats your user name on trac ? [23:48:46 CEST] <BBB> rbultje [23:50:18 CEST] <michaelni> you have wiki delete powers now, also ive added you to the developers group you seem not to have been in it or i missed you [23:52:56 CEST] <BBB> all pages deleted [23:53:06 CEST] <BBB> I suppose fflogger will catch that? [23:53:10 CEST] <BBB> maybe not [23:57:46 CEST] <BBB> JEEB: and colorspace conversion in a decoder yikes [23:57:47 CEST] <BBB> :D [23:57:57 CEST] <JEEB> yes [23:58:37 CEST] <JEEB> it's all eww and I wish your thing or zimg could be used instea :P [23:58:51 CEST] <JEEB> but that's how those subtitle decoders seem to work [23:59:09 CEST] <JEEB> you call those macros for all parts in the palette [23:59:26 CEST] <JEEB> and then that's it and you've got PAL8 :P [00:00:00 CEST] --- Sat Apr 23 2016