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

Fri Nov 18 03:05:02 EET 2016

[00:38:41 CET] <muxketeer> attempting to make use of the zimg lib in ffmpeg. Im interested in using the st_2084 color transfer function available in the latest version of zimg.  I have compiled the latest version of zimg and compiled ffmpeg pointing to that latest version of zimg.  however the following command doesnt work  root at 71cd9cfee65a:~/ffmpeg_sources/ffmpeg# ./ffmpeg -loglevel debug -y -start_number 86400 -f image2 -r 23.976 -i /path/to/ti
[00:38:55 CET] <muxketeer> os+accurate_rnd+print_info+full_chroma_int -vf showinfo,zscale=rangein=full:primariesin=2020:transferin=2020_10:matrixin=2020_ncl:range=full:primaries=2020:transfer=st_2084:matrix=2020_ncl,format=yuv420p10 -c:v rawvideo /path/to/rawframesYUV.yuv
[00:39:14 CET] <muxketeer> with output being  http://pastebin.com/LNhj9Jg3  according to zimg git hub page st_2084 is a valid enum for that argument.  is there something Im doing wrong?
[00:41:00 CET] <wm4> might need update of the zimg ffmpeg wrapper?
[00:47:19 CET] <muxketeer> is that the case?  I'm hoping it isn't . 
[00:50:12 CET] <muxketeer> was thinking that the 'st_2084' would just pass through to the lib without the ffmpeg wrapper needing to have the allowed enums duplicated.
[00:50:17 CET] <kierank> nevcairiel: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202859.html
[00:50:20 CET] <kierank> wtf is this about?
[00:50:45 CET] <nevcairiel> i have no clue, it just seemed fishy to somehow modify the output of a supposed lossless format
[00:50:50 CET] <nevcairiel> so i commented appropriately
[00:51:05 CET] <nevcairiel> i didnt understand his response one bit, or the passive-aggressive nature of it
[00:51:13 CET] <kierank> yes he is wrong
[00:51:21 CET] <kierank> he's doing some weird rgb full range shifting
[00:51:59 CET] <kierank> black needs to stay black, not end up with weird noise
[01:02:46 CET] <iive> doesn't this use the msb as filler to the empty bits?
[01:03:08 CET] <iive> aka, 00->0000 ; 7F->7F7F ; FF->FFFF ?
[02:36:08 CET] <llogan> BBB: is VP an acronym, and if it is what does it mean?
[02:58:28 CET] <Guest31671> hello, one point troubles me. why *(AVClass **)a not (AVClass *) directly?
[03:31:13 CET] <BBB> llogan: I dont tihnk it stands for anything; vp3 was basically assume the m in mp3 stands for music, then vp3 is the same but v being video
[03:31:27 CET] <BBB> llogan: and then all subsequent versions where vpn with n being >3
[03:35:03 CET] <llogan> ah, i had a feeling it didn't really mean anything
[03:40:07 CET] <klaxa> the m in mp3 is from mpeg though, isn't it?
[03:47:05 CET] <BBB> KLAXA: I didnt say it means music, I said assume it means music
[03:47:36 CET] <BBB> going to bed, gnite :)
[03:49:57 CET] <klaxa> ok then, well that's one explanation more
[04:51:22 CET] <Compn> Guest31671 : ask michaelni when he returns
[04:51:33 CET] <Compn> or ask on ml
[12:22:17 CET] <cone-780> ffmpeg 03Michael Niedermayer 07master:85407c7e6372: avcodec/mpegvideo: Fix edge emu buffer overlap with interlaced mpeg4
[12:22:18 CET] <cone-780> ffmpeg 03Michael Niedermayer 07master:2c9106257ffc: avcodec/mpeg4videodec: Workaround interlaced mpeg4 edge MC bug
[12:50:44 CET] <cone-780> ffmpeg 03Carl Eugen Hoyos 07master:f8247c0ccebc: lavc/ffv1enc: Support pix_fmt GRAY10.
[13:01:51 CET] <cone-780> ffmpeg 03Carl Eugen Hoyos 07master:55a424c5a836: lavc/ffv1dec: Scale output for msb-packed compression to full 16bit.
[13:13:49 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:48ee545d11e6: avformat/flvdec: Fix regression loosing streams
[13:13:50 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:c9c619e667e1: avcodec/8bps: Check side data size before use
[13:13:51 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:d8db018e313d: avcodec/cinepak: Check side data size before use
[13:13:52 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:be756396b579: avcodec/idcinvideo: Check side data size before use
[13:13:53 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:dc692ae1b727: avcodec/kmvc:  Check side data size before use
[13:13:54 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:3c1eb57d1eb5: avcodec/msrle:  Check side data size before use
[13:13:55 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:0c0aa5ebbaf7: avcodec/qtrle:  Check side data size before use
[13:13:56 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:7821c96dd050: avcodec/qpeg:  Check side data size before use
[13:13:57 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:956407b5df45: avcodec/msvideo1: Check side data size before use
[13:13:58 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:aa896c182dae: avcodec/rscc: Check side data size before use
[13:13:59 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:e8b93372819b: avcodec/rawdec: Check side data size before use
[13:14:00 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:fa1ee9602632: avcodec/rscc: Fix constant
[13:14:01 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:487accbf19be: avcodec/tscc:  Check side data size before use
[13:14:02 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:7521d5b8daae: avcodec/sunrast: Fix input buffer pointer check
[13:14:03 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:07c5e65e6d6b: ffmpeg: Fix bsf corrupting merged side data
[13:14:04 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:20d0f3201284: avcodec/movtextdec: Fix potential integer overflow
[13:14:05 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:a0c6b4cfd169: avcodec/movtextdec: Fix tsmb_size check==0 check
[13:14:06 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:8deaed3b12bf: avcodec/movtextdec: Add error message for tsmb_size check
[13:14:07 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:7e8eb30f4002: avcodec/ituh263dec: Avoid spending a long time in slice sync
[13:14:08 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:0f8de7a3db4a: avcodec/rv40: Test remaining space in loop of get_dimension()
[13:14:09 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:3f6aae377a09: avcodec/mpegvideo: Fix edge emu buffer overlap with interlaced mpeg4
[13:14:10 CET] <cone-780> ffmpeg 03Michael Niedermayer 07release/3.2:b9a01722608a: avcodec/mpeg4videodec: Workaround interlaced mpeg4 edge MC bug
[13:51:00 CET] <BBB> michaelni: ping
[13:51:12 CET] <BBB> michaelni: when I ffprobe a mxf file, I dont get a fps, why?
[13:51:19 CET] <BBB> it has an average fps, right?
[13:57:46 CET] <michaelni> BBB, trying with a random mxf i get fps & tbr values
[13:58:10 CET] <michaelni> Stream #0:2: Video: dnxhd (DNXHD), yuv422p(bt709/unknown/unknown, top first), 1920x1080, SAR 1:1 DAR 16:9, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
[13:59:20 CET] <BBB> I get  Stream #0:0: Video: jpeg2000, yuv422p10le(progressive), 3840x2160, SAR 1:1 DAR 16:9, 59.94 tbr, 59.94 tbn, 59.94 tbc
[13:59:27 CET] <BBB> for https://media.xiph.org/video/derf/meridian/MERIDIAN_SHR_C_EN-XX_US-NR_51_LTRT_UHD_20160909_OV/MERIDIAN_SHR_C_EN-XX_US-NR_51_LTRT_UHD_20160909_OV_01.mxf
[13:59:32 CET] <BBB> no fps there afaics
[14:04:23 CET] <BBB> the r_frame_rate in -show_streams is set, though
[14:04:26 CET] <BBB> and seems correct
[14:04:31 CET] <BBB> so not sure why its not reporting that value
[14:06:31 CET] <wm4> libavcodec/x86/vp9itxfm.asm:2149: error: instruction expected after label
[14:06:37 CET] <wm4> with ffmpeg git
[14:07:40 CET] <wm4> libass does it correctly: configure: WARNING: yasm is too old (found yasm 1.1.0.2352); ASM functions are disabled.
[14:32:10 CET] <BBB> wm4: probably a missing HAVE_EXTERNAL_AVX2 or so
[14:32:33 CET] <BBB> wm4: if you add that around the newly added iadst16 avx2 function (in .asm) and assignment (in _init.c), it should work
[14:34:19 CET] <wm4> well it fetches directly from git
[14:53:57 CET] <wm4> meh building ffmpeg qsv with mingw seems like a real PITA
[14:58:05 CET] <RiCON> wm4: how so?
[14:58:34 CET] <nevcairiel> probably want to use lucas libmfx thing with another build system
[14:59:01 CET] <cone-780> ffmpeg 03Martin Storsjö 07master:4f7723cb3b91: movenc: Add an option for skipping writing the mfra/tfra/mfro trailer
[14:59:02 CET] <cone-780> ffmpeg 03Hendrik Leppkes 07master:4a485daa7fc5: Merge commit '4f7723cb3b913c577842a5bb088c804ddacac8df'
[14:59:12 CET] <wm4> RiCON: include locations (well, general windows pain), msvc-only import libs, etc
[14:59:30 CET] <RiCON> oh, you're not using libmfx
[14:59:33 CET] <nevcairiel> the source of the library is shipped with the sdk
[14:59:36 CET] <nevcairiel> you can just rebuild it
[14:59:50 CET] <nevcairiel> or use lucas fork of it, he tacked on some build system
[15:00:06 CET] <nevcairiel> https://github.com/lu-zero/mfx_dispatch
[15:00:27 CET] <wm4> weird shit
[15:01:43 CET] <cone-780> ffmpeg 03Martin Storsjö 07master:d825b1a53065: libopenh264: Support building with the 1.6 release
[15:01:44 CET] <cone-780> ffmpeg 03Hendrik Leppkes 07master:da97b244b04b: Merge commit 'd825b1a5306576dcd0553b7d0d24a3a46ad92864'
[15:04:44 CET] <cone-780> ffmpeg 03Janne Grunau 07master:fc5cdc0d5372: doc: escape left brace in texi2pod.pl regex
[15:04:45 CET] <cone-780> ffmpeg 03Hendrik Leppkes 07master:711b7b77763c: Merge commit 'fc5cdc0d5372f5103c71d5dede296734fe71ead2'
[15:05:16 CET] <cone-780> ffmpeg 03Janne Grunau 07master:5f74bd31a9bd: vp8/armv6: mc: avoid boolean expression in calculation
[15:05:17 CET] <cone-780> ffmpeg 03Hendrik Leppkes 07master:2818aaaba09d: Merge commit '5f74bd31a9bd1ac7655103b11743c12d38e0419f'
[15:06:02 CET] <cone-780> ffmpeg 03Janne Grunau 07master:ec32574209f3: checkasm: vp8: mc: test unequal width/height for partitions
[15:06:03 CET] <cone-780> ffmpeg 03Hendrik Leppkes 07master:4fe013fc701a: Merge commit 'ec32574209f36467ef0d22c21a7e811ba98c15b6'
[15:06:18 CET] <cone-780> ffmpeg 03Janne Grunau 07master:8c816c0c9b12: checkasm/arm: align the clobber check data properly for ldrd
[15:06:19 CET] <cone-780> ffmpeg 03Hendrik Leppkes 07master:90b72f6bdac9: Merge commit '8c816c0c9b12fdefd9046415e97df299880bc9b8'
[15:06:36 CET] <cone-780> ffmpeg 03Martin Storsjö 07master:2866d108c9e9: vp8dsp: Remove the comment saying that the height is equal to the width
[15:06:37 CET] <cone-780> ffmpeg 03Hendrik Leppkes 07master:e999a4ed6c63: Merge commit '2866d108c9e9da7baf53ff57a51d470691049a57'
[15:06:52 CET] <cone-780> ffmpeg 03Steve Lhomme 07master:99cf943339a2: d3d11va: don't keep the context lock while waiting for a frame
[15:06:53 CET] <cone-780> ffmpeg 03Hendrik Leppkes 07master:4c5c522fc1a5: Merge commit '99cf943339a2e5171863c48cd1a73dd43dc243e1'
[15:18:53 CET] <cone-780> ffmpeg 03Anton Khirnov 07master:a8cbe5a0cceb: h264_ps: export actual height in MBs as SPS.mb_height
[15:18:54 CET] <cone-780> ffmpeg 03Hendrik Leppkes 07master:cca4fd477851: Merge commit 'a8cbe5a0ccebf60a8a8b0aba5d5716dd54c1595c'
[15:19:58 CET] <cone-780> ffmpeg 03Janne Grunau 07master:17c99b6158f2: h2645_parse: handle embedded Annex B NAL units in size prefixed NAL units
[15:19:59 CET] <cone-780> ffmpeg 03Hendrik Leppkes 07master:62d9b7a69b9b: Merge commit '17c99b6158f2c6720af74e81ee727ee50d2e7e96'
[15:21:23 CET] <cone-780> ffmpeg 03Janne Grunau 07master:80fbb7becae5: checkasm: vp8.mc: initialize the full src buffer after ec32574209f
[15:21:24 CET] <cone-780> ffmpeg 03Hendrik Leppkes 07master:c0af1ee90dcb: Merge commit '80fbb7becae530167373fe5178966b7d7604306e'
[15:21:41 CET] <cone-780> ffmpeg 03Janne Grunau 07master:7b1ae0e73ab7: checkasm/arm: preserve the stack alignment checkasm_checked_call
[15:21:42 CET] <cone-780> ffmpeg 03Hendrik Leppkes 07master:286d8bae61e8: Merge commit '7b1ae0e73ab7f7c5eabc70dbe2e579127c6e154f'
[15:25:05 CET] <cone-780> ffmpeg 03Vittorio Giovara 07master:61bd0ed781b5: h264: Log more information about invalid NALu size
[15:25:06 CET] <cone-780> ffmpeg 03Hendrik Leppkes 07master:2f1a539d4b90: Merge commit '61bd0ed781b56eea1e8e851aab34a2ee3b59fbac'
[15:27:43 CET] <cone-780> ffmpeg 03Vittorio Giovara 07master:cbbb40405587: fate: Restore order of h264 entries
[15:27:44 CET] <cone-780> ffmpeg 03Hendrik Leppkes 07master:1398ded7a77b: Merge commit 'cbbb404055877e3beb9890ffe22784a6a100963e'
[17:24:39 CET] <kierank> "So AFAIK the encoder pushes the values to the LSBs but the decoder didn't
[17:24:39 CET] <kierank> shift them back up?"
[17:24:43 CET] <kierank> atomnuker: no
[17:25:00 CET] <kierank> the decoder  is fine
[18:05:46 CET] <cone-780> ffmpeg 03Michael Niedermayer 07master:ae514b125431: avcodec/ass_split: Change order of operations in ass_split_section()
[18:10:22 CET] <gnafu> Hehe, "ass_split".
[18:26:06 CET] <microchip_> :D
[19:03:52 CET] <kierank> wtf is wrong with carl
[19:04:06 CET] <kierank> https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=55a424c5a836523828b3b2f02b7db610e898b3fc
[19:04:09 CET] <kierank> that's clearly wrong
[19:06:41 CET] <wm4> but but it's still lossless!
[19:07:03 CET] <kierank> on what planet is adding noise to the lsbs lossless
[19:07:11 CET] <durandal_1707> was it approved by Michael? 
[19:08:27 CET] <kierank> this is literally cargo cult programming
[19:08:31 CET] <wm4> he replied "probably ok"
[19:08:33 CET] <kierank> adding random junk to the LSBs
[19:10:14 CET] <jamrial_> so he pushed code that brings no benefits and makes the decoder slower at the same time?
[19:10:34 CET] <kierank> correct
[19:11:00 CET] <wm4> well... he said "Attached patch improves output for some ffv1 files imo."
[19:11:29 CET] <wm4> (improves output of a lossless decoder, I still don't get it)
[19:11:33 CET] <durandal_1707> some color issue 
[19:12:06 CET] <Chloe[m]> shouldnt colour issues be fixed using post processing/filters?
[19:12:29 CET] <durandal_1707> probably related what he uses to display video 
[19:12:30 CET] <wm4> it should produce exactly what was input?
[19:14:24 CET] <Chloe[m]> wm4: ofc, but if there an issue with the original source (or his display) then it should have been fixed through a filter (or similar)
[19:14:45 CET] <Chloe[m]> kierank: why are you waiting two hours?
[19:17:40 CET] <wm4> because just reverting a patch is offensive, no matter how wrong it is
[19:18:25 CET] <wm4> or whether he was allowed to apply the patch at all (it was pushed before the doubts of others were resolved and only a "probably ok" was given)
[19:18:58 CET] <Chloe[m]> ah ok, makes sense. (I didn't see it as offensive, but if other people think so then that's fine)
[19:21:45 CET] <cone-780> ffmpeg 03Michael Niedermayer 07master:709c87109dc8: avformat/movenc: Check frame rate before use.
[19:24:18 CET] <Chloe[m]> how does reverting a library version bump work? Is it bumped up one further?
[19:26:18 CET] <BBB> I agree with kierank that the patch is ridiculous and wrong
[19:26:26 CET] <BBB> even if it wasnt wrong, it would still be ridiculous
[19:26:37 CET] <BBB> (but its actually wrong because of what he pointed out it not being RGB)
[19:26:47 CET] <BBB> or, rather, fullrange
[19:27:46 CET] <kierank> whoops yeah
[19:29:03 CET] <BBB> its ok, we know what you mean
[19:29:24 CET] <jamrial_> then please reply to that thread stating this, to reduce the chances of carl starting a revert war
[19:30:26 CET] <kierank> well rgb implies fullrange but fullrange doesn't imply rgb
[19:32:23 CET] <durandal_1707> Chloe[m]: not at all, also something like that should not happen 
[19:34:07 CET] <Chloe[m]> the main reason I was wondering is because if it's a straight revert then you run the risk of having two versions of the same version (only in tree, but that's still an issue I think)
[19:34:11 CET] <Chloe[m]> s/tree/history/
[20:44:14 CET] <cone-780> ffmpeg 03Stefano Sabatini 07master:427a47abcdda: ffprobe: fix crash in case -of is specified with an empty string
[20:45:47 CET] <iive> and what is the correct way to extend ranged data to 16 bits?
[20:50:41 CET] <cone-780> ffmpeg 03Moritz Barsnick 07master:c493a531edfd: doc/bsfs: various improvements
[20:51:28 CET] <drv> this is unrelated to full range vs video range anyway
[20:54:18 CET] <ubitux> nevcairiel: were you able to entangle yourself from the merge madness?
[20:54:35 CET] <ubitux> untangle*
[20:56:58 CET] <Chloe[m]> ubitux: why does the EBU R128 filter have a video output?
[20:57:21 CET] <BBB> iive: just upshift and leave lower bits to zero
[20:57:45 CET] <BBB> iive: its kind of counterintuitive, but Im pretty sure its correct
[20:57:46 CET] <ubitux> Chloe[m]: because it's cool, you can monitor the evolution of the loudness of a stream
[20:57:51 CET] <ubitux> Chloe[m]: did you try it?
[20:58:00 CET] <iive> no it's not.
[20:58:17 CET] <BBB> its not counterintuitive? or its not correct?
[20:58:32 CET] <BBB> (or both?)
[20:59:27 CET] <ubitux> Chloe[m]: example from the doc: ffplay -f lavfi -i "amovie=input.mp3,ebur128=video=1:meter=18 [out0][out1]"
[20:59:28 CET] <drv> if anything is looking at the low bits of these formats, that code is the real bug (imo)
[21:07:21 CET] <jamrial_> ubitux: yeah, once he got past the avconv.c stuff it was a breeze. noops and onliners galore
[21:12:07 CET] <Chloe[m]> ubitux: hmm, I guess it's cool. Why couldn't it be integrated into the new ebur128 filter?
[21:12:26 CET] <jamrial_> hah, carl waited exactly two hours to send that reply
[21:13:02 CET] <kierank> I'm reverting
[21:13:15 CET] <ubitux> Chloe[m]: i have no objection to integrating it to the new filter, but i don't want the "old" ebur128 to depend on new code dumped randomly
[21:13:21 CET] <jamrial_> kierank: poke michaelni first
[21:13:48 CET] <kierank> why should I do that when I wasn't given the courtesy of having my objection acknowledged
[21:14:21 CET] <Chloe[m]> kierank: because you're not the maintainer either?
[21:14:29 CET] <kierank> the maintainer system is a joke
[21:14:38 CET] <llogan> it was "probably" reviewed
[21:15:12 CET] <jamrial_> kierank: because he's is indeed the maintainer. and he will listen to your objections, unlike carl
[21:15:18 CET] <kierank> he didn't
[21:16:43 CET] <ubitux> kierank is getting more acid with time
[21:17:02 CET] <durandal_1707> illusions 
[21:22:03 CET] <BBB> yo guys, some people (like me) are actually using ffv1 in production settings
[21:22:08 CET] <BBB> Im expecting kieran does so too
[21:22:14 CET] <BBB> its an international standard, after all
[21:22:20 CET] <jamrial_> michaelni: could you confirm if kierank and BBB's arguments against carl's patch are right or not?
[21:22:36 CET] <jamrial_> carl seems adamant about it being correct
[21:23:31 CET] <jamrial_> BBB: that's also true. ffv1 is supposedly being standarized, so this kind of change can't be done lightly
[21:23:55 CET] <BBB> Im certainly not happy about decoder behaviour changing for stuff I use in prod settings :)
[21:24:09 CET] <BBB> but I can simply not git update for a while; we dont all have that luxury
[21:25:14 CET] <BBB> (plus Im mostly using it for 8bpc, but thats a different issue :-p)
[21:26:14 CET] <JEEB> wtf that mail thread
[21:27:07 CET] <durandal_1707> the Carl code looks strange and explanation is weak imho 
[21:27:39 CET] <wm4> ubitux: not surprising
[21:27:49 CET] <JEEB> is that some PAL pix_fmt specific code because he keeps mentioning it? can't be seen from the context of the patch
[21:28:09 CET] <wm4> ffmpeg development is a total joke management-wise
[21:28:15 CET] <JEEB> because he keeps mentioning 10bit PAL pix_fmt (?!)
[21:28:21 CET] <wm4> it's pathetic and you should be ashamed
[21:28:28 CET] <JEEB> or well, gray
[21:29:14 CET] <ubitux> wm4: you're also part of the project you know
[21:29:31 CET] <Chloe> wasn't there a meeting earlier this year to sort it all out?
[21:30:02 CET] <jamrial_> we could ban carl if people actually voted in a relevant vote
[21:30:36 CET] <Chloe> It still comes down to 'who will do the bug tracker then' iirc
[21:30:46 CET] <wm4> ubitux: am I
[21:30:49 CET] <Chloe> or at least that was what was said last time this came up
[21:31:11 CET] <wm4> and you didn't notice how I was absent for months etc.
[21:31:31 CET] <ubitux> wm4: you have several commits, you have write permissions (afaik), you are part of the voting comittee, and you're generally active in the project
[21:31:56 CET] <ubitux> even if you're actively spreading toxicity on your bad days ;)
[21:31:57 CET] <jamrial_> Chloe: last time a vote showed up, things got muddled and nobody voted
[21:32:04 CET] <durandal_1707> I did do bugs, many of them on tracker 
[21:32:23 CET] <Chloe> durandal_1707: note that I'm not saying anyone doesn't
[21:33:24 CET] <durandal_1707> Carl contributions are mostly controversial most of time 
[21:33:32 CET] <BBB> Im confused
[21:33:36 CET] <BBB> so maybe I have an old checkout
[21:33:49 CET] <BBB> but for me, packed_at_lsb is always set for bits_per_raw_sample > 8 && bits_per_raw_sample < 16
[21:33:55 CET] <BBB> so I dont see when that code ever executes
[21:33:59 CET] <BBB> am I crazy?
[21:34:23 CET] <JEEB> so it's for 8-15 bps?
[21:34:26 CET] <JEEB> uhh
[21:34:28 CET] <JEEB> 9-15
[21:35:20 CET] <BBB> look at http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/ffv1dec.c;h=0719e2822d8ad645d5942f78a8529bcd62563ca7;hb=HEAD
[21:35:29 CET] <BBB> line 600-627
[21:36:09 CET] <BBB> thats the only cases where bits_per_raw_sample is between 9 and 15
[21:36:13 CET] <BBB> and they all set packed_at_lsb=1
[21:36:20 CET] <JEEB> hah
[21:36:20 CET] <wm4> now I'm engaging cehoyos
[21:36:22 CET] <wm4> just kill me
[21:36:31 CET] Action: JEEB RIPs wm4
[21:36:32 CET] <wm4> might as well try to convince a wall while hitting myself with a hammer
[21:36:41 CET] <BBB> oh I see its for grayscale only
[21:36:48 CET] <wm4> (this is what talking to some ffmpeg "devs" feels like)
[21:36:54 CET] <JEEB> yeah, he was mentioning gray
[21:37:07 CET] <BBB> I still think it should respect fullrange
[21:37:09 CET] <wm4> GRAY is considered YUV, so same rules
[21:37:18 CET] <BBB> theres sufficiently many people that transform gray by taking y plane from yuv
[21:37:25 CET] <BBB> (like, thats what I do)
[21:37:33 CET] <BBB> so it should at least respect the range flag
[21:37:37 CET] <wm4> well it is _actually_ not marked as rgb in ffmpeg's pixdesc
[21:37:37 CET] <JEEB> ye
[21:37:55 CET] <wm4> hm I don't think full vs. limited range has to do with this
[21:38:27 CET] <wm4> hm I guess my argumentation makes no sense for the 16 bit case, whatever, bye
[21:38:34 CET] <durandal_1707> pixel format should not have anything with range 
[21:39:01 CET] <JEEB> yes, they are orthogonal
[21:39:07 CET] <JEEB> if that was the right word for it
[21:39:46 CET] <wm4> if you have a 10 bit format and expand it to 16 bit, it will still have only 2^10 range
[21:39:56 CET] <wm4> and the LSBs ought to be 0
[21:40:17 CET] <durandal_1707> but/and swscale is big mess 
[21:40:31 CET] <wm4> (and full range vs. limited range still happens within the 2^10 range)
[21:40:49 CET] <durandal_1707> yes
[21:42:11 CET] <wm4> oh I see ffv1 supports only gray8 and gray16 anyway
[21:43:34 CET] <Chloe> huh, it's as simple as a shift? i.e. 10 0000 0000 -> 1000 0000 0000 0000
[21:43:44 CET] <JEEB> wm4: he added gray10
[21:43:51 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=commit;h=f8247c0ccebc2a153eb76a82961e4f6ca81e6f82
[21:44:16 CET] <wm4> hm
[21:44:38 CET] <wm4> so basically for gray10 the decoder adds noise to the LSBs?
[21:44:49 CET] <durandal_1707> and even with gray10 patch is still weird 
[21:44:52 CET] <wm4> while not for yuv410p10
[21:45:30 CET] <atomnuker> Chloe: not really, its better if you apply a dither after you shift
[21:45:50 CET] <atomnuker> but yeah, you can get away with just a shif
[21:45:58 CET] <atomnuker> *shift
[21:47:28 CET] <Chloe> 512/1024 -> 32768/65536, ah. ok, I see how this works
[21:49:09 CET] <Chloe> why is dithering better if an (expanding) shift is lossless?
[21:49:30 CET] <durandal_1707> both Carl recent 2 patches to ffv1 are very ugly imho 
[21:51:30 CET] <durandal_1707> if one encodes gray10 he should get gray10 back, not something else
[21:53:11 CET] <JEEB> Chloe: in real life your sources can have banding so that improves it as you widen the range
[21:53:30 CET] <JEEB> you usually also dither audio when you resample
[21:55:40 CET] <BBB> dithering makes sense when you reduce resolution (e.g. packing after applying a filter, or downsamplign from 10bit to 8bit)
[21:55:53 CET] <BBB> when strictly upsampling, I dont think theres much of a case for dithering
[21:55:57 CET] <JEEB> yes
[21:56:03 CET] <JEEB> when downsampling it makes much more sense
[21:56:26 CET] <BBB> and its true that swscale kinda sucks, the colorspace filter implements FSB dithering if you want
[21:56:39 CET] <BBB> its obviously not fast
[22:00:47 CET] <Chloe> chloe-: quit
[22:02:14 CET] <Chloe> I can see how dithering on upsampling would make sense, but not for downsampling. If you are already losing information, then aren't you losing more by dithering on an already compressed sample?
[22:04:50 CET] <atomnuker> you'll reduce banding if you dither when downconverting
[22:04:52 CET] <BBB> Chloe: see wikipedia ;)
[22:05:11 CET] <BBB> https://en.wikipedia.org/wiki/Dither
[22:05:12 CET] <Chloe> BBB: yeah I'm reading now
[22:05:26 CET] <BBB> Chloe: see pictures at bottom, going to 1bit makes the issue pretty clear and explains why dithering is useful
[22:05:33 CET] <BBB> 8bit makes the issue less severe but its still there
[22:10:11 CET] <Chloe> the 1bit example was very useful
[22:12:41 CET] <wm4> isn't "dithering" on upsampling literally just adding noise
[22:13:09 CET] <BBB> I dont know what youd dither to
[22:13:18 CET] <BBB> there is no error diffusion since there is no error
[22:13:22 CET] <wm4> yes
[22:13:29 CET] <drv> it's essentially implementing the multiplication for range conversion in fixed point
[22:13:34 CET] <wm4> so all you could do is adding noise
[22:13:37 CET] <BBB> yeah
[22:13:40 CET] <BBB> right
[22:13:45 CET] <BBB> I think were saying the same thing ;)
[22:14:06 CET] <BBB> its hard if theres no strict terminology that you have to abide by :-p
[22:28:43 CET] <Chloe> Only when writing the email does my client wrap, but after it sends it doesn't wrap. Weird.
[23:07:34 CET] <nevcairiel> ubitux: untangle? :) Skipped a few that didn't apply to FFmpeg.c without a lot of work, and bow there is a lot of more or less simple ones
[23:08:52 CET] <ubitux> nothing particularly blocking in current state?
[23:08:59 CET] <nevcairiel> Nah
[23:09:05 CET] <ubitux> ok :)
[23:09:08 CET] <ubitux> thanks for your work
[23:09:15 CET] <ubitux> again i'm sorry not to be of any help currently
[23:09:27 CET] <nevcairiel> I uploaded some new fate samples earlier so I can merge the new tests tomorrow
[23:09:53 CET] <nevcairiel> There is one or two h264 changes soon that may take some exploring, but no huge sets
[23:20:46 CET] <jamrial_> the two upcoming mp3 de/muxer commits will probably have to be noop'd. they clash with our implementation for the same thing
[23:21:39 CET] <jamrial_> wonder if theirs is more correct. it is after all stream trailing padding, so using packet side data to signal packet trailing padding may not be "proper"
[23:23:25 CET] <nevcairiel> I'll let someone fix that if its wrong, doesn't feel merge appropriate
[00:00:00 CET] --- Fri Nov 18 2016