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

[burek]

[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 at 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/8e1b13e440182391ec826c4723fa910881e09100
[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/b1f16b679cf331ba9c264c2a564d2e852e690c28
[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