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

[burek]

[00:27:19 CET] <kierank> durandal_1707: ping
[00:52:35 CET] <kierank> boooom
[01:26:16 CET] <cone-054> ffmpeg 03Marton Balint 07master:89a1471a72cb: avdevice/decklink_dec: properly initialize no_video variable
[01:26:16 CET] <cone-054> ffmpeg 03Marton Balint 07master:a7946c896469: avdevice/decklink_enc: do not reference this after freeing it
[02:41:31 CET] <kierank> michaelni: what does this mean
[02:41:32 CET] <kierank> int b8_stride;             ///< 2*mb_width+1 used for some 8x8 block arrays to allow simple addressing
[02:42:19 CET] <kierank> I'm trying to figure out where to put my dc predictor value but the addressing is very confusing
[02:48:39 CET] <cone-054> ffmpeg 03Michael Niedermayer 07master:b347ca93412f: avformat/matroskadec: Fix OOM on long streams
[02:50:09 CET] <michaelni> some of the strides are choosen so that theres a border of blocks outside the image
[02:58:52 CET] <kierank> michaelni: how should I address s->dc_val[a][b] then?
[02:59:09 CET] <kierank> the prediction is simple, I just need a place to store the data
[03:01:51 CET] <kierank> actually maybe i'll just put it in my own place
[03:01:56 CET] <kierank> and then later on merge it if necessary
[03:12:36 CET] <cone-054> ffmpeg 03Jesper Ek 07master:c7c0046efc3a: Fix bug when incrementing initial_prog_date_time when removing segments
[03:25:52 CET] <michaelni> dc_val[1] and [2]  will probably need bigger strides for 422/444
[03:31:58 CET] <kierank> I just need one value per component, dc_val seems excessive for what I need actuall
[03:32:02 CET] <kierank> I just made a new variable for now
[03:42:02 CET] <cone-054> ffmpeg 03Bodecs Bela 07master:0ff8c6b6d524: avformat/hlsenc: strftime identifiers and segment index  in filenames
[04:00:29 CET] <kierank> crap my dc coefficient is wrong
[05:35:34 CET] <kierank> michaelni: yeah i need 32-bit coefficients
[05:35:44 CET] <kierank> see A.1.1
[05:36:08 CET] <kierank> In case of mpeg2_stream = 0, The coefficients are
[05:36:08 CET] <kierank> represented in (n+7) bits including three fractional bits.
[06:13:38 CET] <durandal_170> kierank: you need to ping me multiple times to wake me up
[06:13:53 CET] <kierank> I solved that problem
[06:13:59 CET] <kierank> now i have much bigger problem
[06:28:40 CET] <durandal_170> kierank: when you sleep?
[06:30:39 CET] <kierank> I was sleeping now until you woke me up =p
[09:10:02 CET] <torroid> Hi! I would like to contribute.. Please could I get a starting point
[09:10:42 CET] <JEEB> just start with compiling, then poking around and finding your niche :P not sure if there's a clear-cut list of things doable by a newcomer. most people work either on what they like or what they need for their $dayjob
[09:13:02 CET] <atomnuker> whoa, its a huge mjpegenc patch!
[09:15:22 CET] <rcombs> JEEB: or both!
[09:16:09 CET] <rcombs> atomnuker: wow, wonder what for
[09:17:15 CET] <JEEB> rcombs: that'd be nice :D
[09:17:22 CET] <JEEB> and to be honest, for a while I did that
[09:17:26 CET] <rcombs> also, at a quick glance, it looks& not awful?
[09:17:38 CET] <atomnuker> rcombs: the ethernal strife of encoding: quality improvements
[09:18:02 CET] <rcombs> atomnuker: yeah, I see, I'm wondering why the hell anyone would put significant effort into making MJPEG better
[09:30:06 CET] <atomnuker> I'd put effort into making the vorbis encoder better if vorbis was to be the standard for web audio for the next 20 years or so
[09:30:41 CET] <atomnuker> (I should do it anyway, vorbis has huge huge window sizes which makes it interesting)
[09:51:25 CET] <rcombs> atomnuker: I sure hope MJPEG isn't going to be the standard for web video for the next 20 years or so
[09:51:50 CET] <rcombs> though it might remain the standard for DCPs until the end of time
[09:53:30 CET] <atomnuker> it isn't the standard for web video, ip cams don't really classify as maistream web video
[09:54:00 CET] <atomnuker> MJPEG = JPEG to me
[10:03:28 CET] <j-b> 'morning
[11:20:39 CET] <ubitux> http://www.ipol.im/pub/art/2016/130/
[14:16:18 CET] <Compn> hmm
[14:16:23 CET] <Compn> looking at encoders.texi
[14:16:39 CET] <Compn> are there more encoders with options that are not documented ?
[14:16:48 CET] <Compn> i see mjpeg isnt listed
[14:17:05 CET] <Compn> amongst others. feels like a bunch are not documented :\
[14:53:15 CET] <RiCON> i'd have no idea ffflacenc supported 0-12 compression_level unless i read the code
[15:22:24 CET] <raphael29_> hi
[15:22:30 CET] <raphael29_> I am a 3rd year CS student looking for participating in GSoC 2017. While browsing through the 2016 GSoC list, I found this project which caught my attention. Can someone give me some more details about it?
[15:23:31 CET] <Compn> sure
[15:23:39 CET] <Compn> what details are you looking for raphael29_ ?
[15:23:58 CET] <Compn> ffmpeg is a multimedia toolkit for processing audio and video related media
[15:24:17 CET] <Compn> currently ffmpeg is installed on more than a billion computers, smart tvs, cell phones etc
[15:24:37 CET] <Compn> mostly written in C with a lot of assembly in nasm/yasm format
[15:25:17 CET] <Compn> we have participated in GSoC in multiple years with success and failures
[15:25:48 CET] <raphael29_> Compn: it sounds cool. Do you intend to participate this year too?
[15:26:09 CET] <Compn> skills useful for the project include reverse engineering, reading specifications, C/C++ and asm writing... 
[15:26:22 CET] <Compn> i am not a student :)
[15:26:49 CET] <raphael29_> Compn: you ==FFMPEG project :D
[15:27:16 CET] <iive> Compn is our PR person :D
[15:27:25 CET] <Compn> i just here to answer questions on irc
[15:29:05 CET] <kierank> 8:51 AM <rcombs> though it might remain the standard for DCPs until the end of time
[15:29:08 CET] <kierank> nop that's jpeg2k
[15:29:40 CET] <raphael29_> Compn: ok, so I meant "Do FFMPEG project intend to participate in GSoC 2017"?
[15:30:12 CET] <Compn> possibly ffmpeg will be in gsoc 2017, it depends if we come up with tasks and have mentors and google accepts us
[15:30:40 CET] <Compn> since we have been in a lot of past gsoc, they might pick other projects instead to sponsor
[15:30:56 CET] <Compn> we will probably try again in 2017 
[15:31:21 CET] <Compn> raphael29_ : if you work on ffmpeg now, it will increase your chances of getting picked for student spot :)
[15:34:16 CET] <raphael29_> Compn: it sounds great. I will start digging in and come back if I have any questions :)
[15:35:23 CET] <Compn> ok, please do.
[15:35:38 CET] <Compn> although, before you ask, we dont really have any specific things to work on for new contributors
[15:36:04 CET] <Compn> so try reviewing code or patches or bug reports... maybe just figure out git and patches and read the developer documentation 
[15:36:16 CET] <kierank> michaelni: ping
[15:36:24 CET] <Compn> have you worked with open source before? 
[15:36:28 CET] <Compn> lots to learn :)
[15:36:49 CET] Action: Compn afk bbl
[15:40:49 CET] <michaelni> kierank, pong
[15:41:00 CET] <kierank> 4:35 AM <"kierank> michaelni: yeah i need 32-bit coefficients
[15:41:00 CET] <kierank> 4:35 AM <"kierank> see A.1.1
[15:41:00 CET] <kierank> 4:36 AM <"kierank> In case of mpeg2_stream = 0, The coefficients are
[15:41:00 CET] <kierank> 4:36 AM <"kierank> represented in (n+7) bits including three fractional bits.
[15:41:09 CET] <kierank> michaelni: any advice on how to add 10-bit to mpegvideo.c
[15:41:14 CET] <kierank> 32-bit coefficients
[15:41:15 CET] <kierank> i mean
[15:41:55 CET] <kierank> I have coefficient decoding working now and need to add dequant which is reasonably simple
[15:44:12 CET] <michaelni> the functions need to pass 32bit coeffs then. i assume decode, dequant (if seperate) and idct all need to be different so i guess they wont get mixed with the 16bit variants
[15:45:46 CET] <kierank> it's just idct that matters
[15:45:57 CET] <kierank> can't I keep the same function pointers and then just cast to int32_t?
[15:46:03 CET] <kierank> for the block data
[15:46:23 CET] <kierank> and expand the array of existing int16_t?
[15:47:27 CET] <michaelni> yes that seems simplest
[15:47:51 CET] <kierank> that's what h264 does at least
[15:48:12 CET] <kierank> I guess I need to ask BBB which DCT is the best to use
[15:48:18 CET] <kierank> hopefully I don't need to write my own
[15:48:20 CET] <BBB> ?
[15:48:25 CET] <BBB> whats the problem?
[15:48:35 CET] <kierank> I'm adding 10-bit support to mpegvideo.c
[15:48:41 CET] <kierank> to decode 10/12-bit mpeg-4 video files
[15:49:08 CET] <BBB> just do what we did for h264, add a template for the mpegvideo dsp and change the types of idct from int16_t to dctcoef and uint8_t to pixel
[15:49:20 CET] <kierank> yeah, that's fine, I don't know which DCT is best to use. prores?
[15:49:29 CET] <kierank> IDCT*
[15:49:46 CET] <BBB> depends on the idct defined or expected in the bitstream
[15:49:53 CET] <BBB> I thought mpegvideo uses simple_idct?
[15:50:04 CET] <BBB> so prores could probably work yes
[15:50:28 CET] <BBB> theres something funky in the prores idct I dont recall exactly what it is
[15:50:32 CET] <michaelni> IIUC the new profile uses the withdrawn IEEE nn bitexact idct
[15:50:47 CET] <michaelni> nOn bitexact
[15:51:07 CET] <BBB> dont all mpegs use non-bitexact idct?
[15:51:12 CET] <BBB> (pre-h264)
[15:51:14 CET] <michaelni> yes
[15:51:22 CET] <BBB> so no surprise there I suppose
[15:51:45 CET] <kierank> The N by N inverse discrete transform shall conform to IEEE Standard Specification for the Implementations of 8 by
[15:51:46 CET] <kierank> 8 Inverse Discrete Cosine Transform, Std 1180-1990, December 6, 1990.
[15:52:01 CET] <BBB> raphael29_: yes were likely participating in the gsoc 2017
[15:52:22 CET] <BBB> raphael29_: well have some standard projects, but if you want to do a project of your own, thats fine also, just find your own mentor
[15:52:30 CET] <kierank> maybe I should write my own idct as an exercise
[15:52:40 CET] <BBB> its a fun exercise
[15:52:52 CET] <BBB> but its probably faster to use the existing one and template it for 10bit
[15:53:05 CET] <BBB> the prores idct should work okish and already has simd
[15:53:13 CET] <BBB> merging code like that is always good
[15:57:13 CET] <kierank> BBB: thanks I will try with the existing idct and see if I get pictures first
[16:01:37 CET] <BBB> very well
[16:03:42 CET] <BBB> Gramner: do you have push access?
[16:04:06 CET] <cone-931> ffmpeg 03Ronald S. Bultje 07master:1c8fbd7b9046: checkasm/vp9: benchmark all sub-IDCTs (but not WHT or ADST).
[16:04:06 CET] <cone-931> ffmpeg 03Ronald S. Bultje 07master:992cb15e6713: wmavoice: move wmavoice_flush() up.
[16:04:06 CET] <cone-931> ffmpeg 03Ronald S. Bultje 07master:3deb4b54a24f: wmavoice: disable bitstream checking.
[16:04:06 CET] <cone-931> ffmpeg 03Ronald S. Bultje 07master:b011bb5f8b2c: wmavoice: reindent.
[16:04:06 CET] <cone-931> ffmpeg 03Ronald S. Bultje 07master:7b27dd5c16de: wmavoice: move overflow handling to common code.
[16:04:07 CET] <cone-931> ffmpeg 03Ronald S. Bultje 07master:33d7f822f8ed: wmavoice: protect against zero-energy in adaptive gain control.
[16:04:35 CET] <iive> you'll get picture, but there might be effects like green tilt
[16:04:59 CET] <Gramner> BBB: yes
[16:05:23 CET] <BBB> (just checking if youre waiting for one of us to push that x86inc.asm patch)
[16:05:51 CET] <Gramner> not like it's in a hurry since it doesn't affect any existing ffmpeg code
[16:10:26 CET] <raphael29_> BBB: thanks for your answer.
[17:38:02 CET] <kierank> haasn: nice blog post
[17:38:49 CET] <durandal_170> BBB: i have frequency of simbols used in qdmc. how can I convert it to vlc?
[17:39:54 CET] <BBB> huffman?
[17:40:47 CET] <BBB> kierank: link missing
[17:41:02 CET] <kierank> BBB: https://haasn.xyz/posts/2016-12-25-falsehoods-programmers-believe-about-%5Bvideo-stuff%5D.html
[17:43:10 CET] <BBB> so much stuff there ;)
[18:05:15 CET] <durandal_170> BBB: most likely
[18:10:43 CET] <durandal_1707> BBB: see qdmc page on wiki.multimedia.cx
[18:12:03 CET] <ubitux> haasn: where is the audio now?
[18:12:44 CET] <nevcairiel> there is a whole bunch in there one might argue with though  =p, ie. a h264 decoder that does impact quality is just flat out broken
[18:13:00 CET] <kierank> yes but he's saying don't make the assumption
[18:13:35 CET] <JEEB> the H.264 thing was mostly about HW decoding APIs that for RGB output on your and whatsoever
[18:13:37 CET] <kierank> there's also "don't assume a hardware encoder is better than a software one"
[18:13:41 CET] <JEEB> I herped a derp at him quite a bit
[18:13:46 CET] <JEEB> for the original wording of it
[18:14:24 CET] <ubitux> "every hardware acceleration can be abstracted with a generic interface"
[18:14:34 CET] <ubitux> +common
[18:14:43 CET] <nevcairiel> that was fine until apple was being apple
[18:14:44 CET] <nevcairiel> :D
[18:15:57 CET] <ubitux> "software subtitle rendering can not possibly be the playback speed bottleneck"
[18:16:21 CET] <JEEB> :D
[18:16:40 CET] <JEEB> "my ASS tracks can't possibly be *this* slow to render!"
[18:16:45 CET] <fritsch> hehe
[18:16:50 CET] <ubitux> "a subtitle format can not include markup from multiple other formats"
[18:17:02 CET] <ubitux> "or at least not in the same file"
[18:18:54 CET] <ubitux> "rendering modern subtitles doesn't require a browser engine"
[18:18:56 CET] <kierank> can we get rid of mpeg1_fast_decode_block_inter?
[18:19:18 CET] <nevcairiel> some people probably like the fast mode for obscure reasons
[18:19:24 CET] <kierank> for mpeg1
[18:19:42 CET] <kierank> it also crashes on corrupt stream
[18:22:13 CET] <nevcairiel> fast is known to be insecure, thats probably what makes it fast =p
[18:26:37 CET] <iive> "since H.264 decoding is bit-exact, the decoder used does not affect the quality", could somebody explain me why this is falsehood?
[18:26:52 CET] <JEEB> oh yes, I noted that
[18:26:57 CET] <JEEB> he mostly meant HW decoding interfaces
[18:27:10 CET] <JEEB> which force a specific YCbCr->RGB conversion on you
[18:27:17 CET] <JEEB> before you get the data, that is
[18:27:32 CET] <JEEB> I did note it that most people probably won't read it like he'd think :P
[18:27:36 CET] <kierank> I am bored of people telling me about quicksync
[18:27:39 CET] <cone-931> ffmpeg 03Christophe Gisquet 07master:e3312b3746ef: MAINTAINERS: update
[18:28:01 CET] <Gramner> even so, color space conversion isn't really a part of the actual decoder though
[18:28:07 CET] <JEEB> yes
[18:28:26 CET] <iive> :)
[18:31:04 CET] <JEEB> iive: basically when I pointed the way we read it he replied with
[18:31:05 CET] <JEEB> < haasn> ¬(A’B) is not the same as ¬A
[18:31:49 CET] <JEEB> and then pointed out that he meant those specific HW decoding APIs which don't necessarily give you the YCbCr surfaces
[18:33:29 CET] <atomnuker> some actually give you 2 separate fields instead of 3 solid planes (hi vdpau) even for progressive content
[18:34:05 CET] <kierank> looool
[18:34:13 CET] <iive> nv12 ?
[18:34:16 CET] <kierank> atomnuker: you must have loved that :)
[18:34:17 CET] <iive> hm12?
[18:34:25 CET] <Gramner> if a decoding API does additional stuff in addition to decoding then it's a bit of a misnomer to call it a decoding API. "video processing API" or whatever would be more accurate
[18:35:46 CET] <atomnuker> kierank: not me, wm4 since he had to deal with it :)
[18:41:44 CET] <iive> JEEB: i do not accept his explanation, because he have a whole separate section for color conversions...
[18:42:52 CET] <iive> or you can say 3 or 4 sections...
[18:43:03 CET] <JEEB> yeah but you can clearly see it being on top of the "HW decoders are faster" and "HW decoders can decode everything you can feed 'em"
[18:43:28 CET] <JEEB> but yeah, I don't like the wording but at this point I've given up because I can't come up with anything that's jazzy enough for him :P
[18:43:35 CET] <iive> well, this only makes it more confusing
[18:43:56 CET] <JEEB> and/or in his opinion I'm just reading it wrong :D
[18:44:04 CET] <iive> because he clearly states hardware decoders, when he talks about hardware decoders.
[18:44:13 CET] <nevcairiel> it kinda makes sense, if some decoder cant give you access to the unmodified image, then its clearly worse then other decoders
[18:44:31 CET] <nevcairiel> and its certainly possible someone might build a software decoder with similar sillyness
[18:45:56 CET] <JEEB> sure, the point itself is valid, I think it's just worded in a way that makes it seem as if H.264 isn't spec-wise bitexact
[18:46:01 CET] <kierank> nevcairiel: it's not silly
[18:46:24 CET] <kierank> being able to do some kind of transform when the data is in cache is a good idea
[18:46:43 CET] <nevcairiel> "being able to" is  quite some ways from "not being able to not do that"
[18:46:46 CET] <Alex2001> Hi guys
[18:47:04 CET] <kierank> meh, closed source, deal with it
[18:47:05 CET] <nevcairiel> if its the only mode it knows, someone build sillyness
[18:47:13 CET] <nevcairiel> if its optional, great, features!
[18:48:20 CET] <nevcairiel> (and somehow i dont think video images are particularly nice on caches in general)
[18:48:25 CET] <Alex2001> Could anyone here take a minute and help me out a little bit on a project? I'm having difficulties in getting the end time for DVB subtitles...
[18:49:12 CET] <iive> Alex2001: I might remember wrongly, but you render empty subtitle to hide them
[18:49:20 CET] <iive> or you use the timeout
[18:49:46 CET] <j-b> is Christophe Gisquet around?
[18:49:51 CET] <Alex2001> Well, I'm currently working on a subtitle extraction program
[18:50:04 CET] <Alex2001> and I was wondering if it's actually possible to get the end time for a subtitle
[18:50:06 CET] <nevcairiel> j-b: he doesnt often come to irc
[18:50:10 CET] <kierank> atomnuker: if i recall correctly it is undefined
[18:50:16 CET] <kierank> Alex2001: i mean
[18:50:23 CET] <j-b> nevcairiel: yeah, I thought that too. but I wanted to check.
[18:50:33 CET] <Alex2001> as far as I can see I am only provided with a PTS for each subtitle
[18:50:35 CET] <nevcairiel> he goes by the name kuroso i think
[18:51:36 CET] <j-b> nevcairiel: thx
[18:52:43 CET] <nevcairiel> Alex2001: as far as i can see, there is no end time for dvb subtitles, and instead you get a "empty" subtitle that clears the screen when necessary, as iive said
[18:52:59 CET] <Alex2001> the problem seems to be that after a bitmap says "display" we write it to file and that's not the way to do it
[18:53:04 CET] <Alex2001> Oh, empty subtitle?
[18:54:16 CET] <jamrial> j-b, nevcairiel: it's kurosu
[18:54:23 CET] <nevcairiel> well, close!
[18:54:27 CET] <j-b> jamrial: thx man.
[18:55:12 CET] <jamrial> nevcairiel: you can't start a query if you don't have it right :P
[18:55:34 CET] <nevcairiel> you cant start a query either way if he isnt there :D
[19:06:22 CET] <durandal_1707> michaelni: do you have an idea how to get vlc tables from frequencies?
[19:07:14 CET] <kierank> durandal_1707: I would guess you make the most probable frequency have the shortest code
[19:09:16 CET] <durandal_1707> higher number bigger probability or vice versa?
[19:10:51 CET] <kierank> dunno
[19:12:44 CET] <atomnuker> durandal_1707: highest probabilities -> shorter symbols makes sense
[19:13:16 CET] <atomnuker> question is: is 10 shorter than 11?
[19:13:47 CET] <durandal_1707> and how I could convert those to codes and lengths? manually?
[19:14:09 CET] <durandal_1707> smaller tables have 8 elements
[19:14:36 CET] <kierank> perhaps using rice codes or similar
[19:15:28 CET] Action: kierank curses mpeg specs
[19:15:28 CET] <kierank> ( QF[v][u] * W[0][v][u] * quantiser_scale * base_quantiser scale * 8 * 2 ) / 32;
[19:17:41 CET] <atomnuker> oh hey it's the vp9 school of dequantization
[19:19:34 CET] <kierank> same as mpeg-2
[19:19:53 CET] <kierank> actually a bit different
[19:24:21 CET] <wm4> <atomnuker> some actually give you 2 separate fields instead of 3 solid planes (hi vdpau) even for progressive content <- even better, vdpau doesn't for hevc, which makes no sense, i.e. nvidia left it buggy for ages and just doesn't give a shit anymore
[19:25:06 CET] <michaelni> durandal_1707, i think the stuff in libavcodec/huffman.h did one variant of that
[19:26:49 CET] <durandal_1707> michaelni: already tried that one
[20:05:29 CET] <durandal_1707> michaelni: have any idea?
[20:49:12 CET] <kierank> durandal_1707: I am stuck like you now :(
[20:50:19 CET] <durandal_1707> kierank: i think I got it just need to test idea
[20:50:39 CET] <kierank> I can't get VLCs to work on some MBs
[20:50:40 CET] <kierank> :(
[21:07:39 CET] <Alex2001> Could someone please tell me if the save_subtitle_set() call is necessary in the parse_page_segment() function? I'm having trouble getting the end time of DVB subtitles for a subtitle extractor program and I think it's because I don't call that function
[21:10:49 CET] <Alex2001> The part of the program used for DVB extraction is based a lot on the ffmpeg source (it's almost copy paste), specifically the decoding of the segments part
[21:11:26 CET] <Alex2001> And I believe my program might have this problem because I don't call save_subtitle_set
[21:16:24 CET] <kierank> michaelni: what does it mean when get_vlc2 returns -1?
[21:28:45 CET] <iive> invalid code?
[21:33:12 CET] <durandal_1707> kierank: i can't get little endian vlc generation
[21:34:58 CET] <michaelni> kierank, as iive said, invalid code aka not a valid code
[21:35:32 CET] <kierank> :(
[21:50:50 CET] <haasn> iive: I pretty much meant what I meant: even though H.264 decoders should all produce the result, you can't use all hardware decoders without quality loss *in practice*
[21:50:58 CET] <haasn> because the APIs are shit and won't give you the actual result
[21:51:02 CET] <haasn> but rather some postprocessed version
[21:51:18 CET] <iive> haasn: quality loss where?
[21:51:33 CET] <haasn> even if you can get the YCbCr planes, for example, some APIs will dither 10 bit content to 8 bit textures
[21:51:38 CET] <haasn> or pull 4:2:0 up to 4:2:2 (yes)
[21:51:45 CET] <iive> well, then you can say that...
[21:52:37 CET] <iive> the point is, the decoder as specified by the standard will decode to the correct image
[21:52:43 CET] <haasn> also lol I'm surprised that that's the only statement that basically every decoder person is taking extreme offense to :p
[21:53:23 CET] <haasn> my statement doesn't contradict that
[21:53:27 CET] <haasn> in fact it uses that as an assumption
[21:53:30 CET] <iive> yes it does
[21:53:43 CET] <iive> it basically says that this is fallacy
[21:54:00 CET] <iive> you may want to say something else, but that is what you've written.
[21:54:03 CET] <haasn> ¬(A’B) is not the same as (A¬B)'¬A
[21:54:32 CET] <haasn> I wrote ¬(A’B), which is true; and we know A is true; so the only thing I've said here is ¬B
[21:54:35 CET] <haasn> which is also definitely true
[21:54:47 CET] <haasn> and part of the reason why --hwdec is so strongly discouraged in mpv
[21:54:51 CET] <iive> i'm not sure what these things mean
[21:55:29 CET] <haasn> A = all decoders produce the same result, B = hwdec = swdec in terms of quality, A is clearly true (nobody's trying to argue against that), B is clearly false (--hwdec loses you quality in most cases)
[21:55:31 CET] <haasn> So clearly A can't imply B
[21:55:36 CET] <haasn> even though the naive logic would say yes
[21:55:42 CET] <iive> and i'm not even sure what is A and B in your case.
[21:55:47 CET] <haasn> if all decoders produce the same result, surely it must not matter what decoder I use is a reasonable assumption
[21:55:51 CET] <haasn> which is false, because the APIs are shit
[21:56:02 CET] <haasn> and that's my point
[21:56:07 CET] <haasn> sorry you're reading too much into it
[21:56:10 CET] <kierank> https://www.reddit.com/r/programming/comments/5kkmww/falsehoods_programmers_believe_about_video_stuff/dbotib1/
[21:56:13 CET] <kierank> reddit is lulz
[21:56:27 CET] <iive> haasn: i think the problem here is what do you consider a decoder
[21:56:49 CET] <haasn> iive: the API is part of the decoder, for me
[21:56:57 CET] <haasn> I mean all the algorithms in the world won't help me if I can't actually use them to decode stuff
[21:57:18 CET] <iive> haasn: but you are not talking about API, you are talking about decoder
[21:57:37 CET] <iive> so you say A is false
[21:59:18 CET] <iive> "since H.264 decoding is bit-exact, you will be able to get the bit-exact image from it"
[21:59:32 CET] <haasn> I'll add a footnote, I guess, since I'm getting so many people who misunderstand what I wrote
[22:03:41 CET] <JEEB> haasn: I wonder if it's a linguistic structure that Germans are used to because nevcairiel seemed to parse it similarly to you
[22:03:54 CET] <JEEB> that, or I just fail at English :P
[22:04:47 CET] <iive> I actually would like to ask why this is falsehood, too: "rendering subtitles at the output resolution is always better than rendering them at the video resolution"
[22:06:51 CET] <JEEB> iive: with only text that might work, but depending on your artisticity the end result might be incorrect if you scale things differently in the subtitle renderer compared to the video renderer
[22:07:48 CET] <iive> doesn't render kind of hint about text subtitles?
[22:07:59 CET] <JEEB> it can be vectors etc
[22:08:16 CET] <JEEB> and you're correct, it could even be so with text if it's stylized enough
[22:08:16 CET] <iive> fonts are vectors :D
[22:08:29 CET] <iive> well, mostly
[22:08:31 CET] <JEEB> well yes, but I mean the crazy shit you get with ASS, for example
[22:08:37 CET] <JEEB> and yes, bitmaps in fonts are a thing as well
[22:08:42 CET] <JEEB> (mostly for small sizes)
[22:09:17 CET] <iive> "theres an ASS specification" that has a point :D
[22:09:23 CET] <haasn> iive: https://haasn.xyz/posts/2016-12-25-falsehoods-programmers-believe-about-%5Bvideo-stuff%5D.html#fn1 how's this?
[22:10:09 CET] <haasn> iive: somebody else asked about that comment, and I clarified a few points here: https://news.ycombinator.com/item?id=13260826
[22:10:38 CET] <haasn> That one is probably footnote-worthy as well
[22:10:54 CET] <haasn> but I think it's a valid point, especially the part where softsubbed signs can look out of place at the full screen res
[22:11:40 CET] <iive> well, this happens for 2 reasons:
[22:11:41 CET] <haasn> all of those points only apply to softsubbed signs, I'm sure
[22:12:02 CET] <iive> 1. ass specs are never followed, instead vobsub bugs are replicated.
[22:12:04 CET] <haasn> hence why I wish we had a distinction between signs and text
[22:12:43 CET] <iive> 2. the display resolution is not properly mapped to the video, probably because of #1
[22:13:47 CET] <haasn> when I say out of place I don't mean in the wrong position, I mean they don't feel right / blend in
[22:13:57 CET] <haasn> Obviously there are bugs where stuff like transformations are not properly scaled to screen space
[22:14:13 CET] <haasn> but I mean if you have a blurry video and a sign on that video is suddenly sharp instead of blurry, it doesn't fit
[22:14:19 CET] <iive> oh, you mean, they look better than the video?
[22:14:22 CET] <haasn> yeah
[22:14:31 CET] <haasn> I've noticed that a few times in practice
[22:14:41 CET] <haasn> and it always makes me wish I could distinguish between signs and text in code
[22:14:43 CET] Action: iive adds blur image to ass.2.1
[22:14:49 CET] <haasn> because it would be trivial to render signs on top of the video and text on top of the final output
[22:15:05 CET] <haasn> that way it would also the best of all worlds
[22:15:14 CET] <haasn> signs would get affected by video color management and stuff like motion interpolation
[22:15:31 CET] <JEEB> PGS subs for signs and an ASS track for text? :P
[22:15:47 CET] <JEEB> PGS is even YCbCr (although libavcodec converts it to RGB)
[22:16:00 CET] <JEEB> so you can just literally overlay PGS subs on top of yer YCbCr :D
[22:16:19 CET] <JEEB> because the spec just says that the video's colorimetry applies. that's it
[22:18:03 CET] <haasn> yeah I would love something like that
[22:18:16 CET] <haasn> I would also love it if we had a second transparent H.264 track so we could hardsub all signs but still toggle them :p
[22:18:24 CET] <haasn> (and without having to re-encode the video track)
[22:18:32 CET] <haasn> of course that's a pipe dream
[22:18:38 CET] <haasn> even though the H.264 specs do support it (I think)
[22:18:57 CET] <iive> mpeg4 in higher profiles actually supports object and compositions
[22:19:18 CET] <nevcairiel> noone ever used that, hence why it went away again
[22:19:38 CET] <iive> e.g. you can encode the frame, but without the human face, the face is separate object ...
[22:19:53 CET] <JEEB> haasn: so basically you want two tracks and the player to be able to enable multiple at once :P
[22:20:14 CET] <iive> yeh, it involves a lot of complications in the decoder and even more in the encoder.
[22:21:03 CET] <JEEB> haasn: and if you don't remember, PGS are paletted video resolution based (usually) subpictures
[22:21:08 CET] <JEEB> vOv
[22:21:19 CET] <ubitux> fun fact: clamping like clip(x, min, max) in a spreadsheet is MEDIAN(min, x, max) 
[22:22:15 CET] <iive> median sorts by value and takes the middle
[22:22:24 CET] <atomnuker> haasn: that's a shit dream, softsubbing signs sucks
[22:23:00 CET] <JEEB> didn't he want hardsubs as a subpicture track?
[22:23:08 CET] <atomnuker> yeah, and that's mental
[22:23:40 CET] <ubitux> iive: yes, which has the same result, so it's cool
[22:23:46 CET] <iive> ubitux: :)
[22:24:05 CET] <ubitux> it's like a clip function where you can shuffle all the args
[23:15:01 CET] <durandal_1707> kierank: i kind of have vlc lens but codes may be incorrect for cases when lens are same
[23:16:40 CET] <durandal_1707> what was the name of application that used qt api on Windows it was handy encoder
[23:16:41 CET] <kierank> I got problems my with my vlcs as well
[23:18:50 CET] <durandal_1707> are tables mentioned in specifications?
[23:20:11 CET] <kierank> durandal_1707: in my spec, yes
[23:20:17 CET] <kierank> but I can't decode some macroblocks
[23:20:57 CET] <durandal_1707> do you get any sensible output?
[23:21:19 CET] <kierank> I am just decoding the coefficients at the moment
[23:21:38 CET] <kierank> but I hang on some samples after a few hundred macroblocks but on another sample within 2 macroblocks
[23:22:46 CET] <durandal_1707> no need to align bits?
[23:22:59 CET] <kierank> dunno
[23:24:16 CET] <durandal_1707> well I would try to get some output to be sure at least basic stuff works
[23:25:07 CET] <kierank> i am a long way from that
[23:38:18 CET] <ubitux> http://sprunge.us/FEVL anything faster to suggest?
[23:41:50 CET] <nevcairiel> dont we have median3
[23:43:13 CET] <nevcairiel> mid_pred should be median3
[23:44:40 CET] <ubitux> nice!
[23:45:00 CET] <ubitux> (should we define av_clip on mid_pred? :-°)
[23:46:06 CET] <ubitux> ah unfortunately it's in libavcodec
[23:46:15 CET] <ubitux> i wonder if that's ok to include it in libavfilter
[23:46:15 CET] <nevcairiel> has arch optimizations though
[23:46:30 CET] <ubitux> should be fine as it's an inline though
[23:46:38 CET] <nevcairiel> mid_pred has a cmov variant
[23:46:43 CET] <iive> ubitux: i'd think that median might be a bit slower
[23:49:03 CET] <atomnuker> _clip* needs all the speed it can get, it's very frequently used on entire frames
[23:51:58 CET] <cone-608> ffmpeg 03Clément BSsch 07master:571a36015738: lavfi/transpose: add missing const options flags
[23:52:30 CET] <jamrial> av_clip* for integers have asm optimization on arm only. x86 has no saturate gprs instructions
[23:53:03 CET] <jamrial> they would be a nice addition for a potential future set, though (BMI3?)
[23:53:57 CET] <jamrial> one could maybe use packss* but moving from gpr to xmm and back to gpr is probably too slow to make a difference
[23:54:54 CET] <nevcairiel> maaybe a cmov thing like median3 could be used?
[23:58:18 CET] <cone-608> ffmpeg 03Clément BSsch 07master:afaaf8db1847: lavfi/selectivecolor: simplify crazy mid val computations
[23:58:23 CET] <ubitux> ok now i'm happy
[00:00:00 CET] --- Wed Dec 28 2016