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

[burek]

[00:11:41 CEST] <cone-940> ffmpeg 03Michael Niedermayer 07master:3b1233539509: swscale/x86/hscale_fast_bilinear_simd: Remove ancient out-commented debug code
[01:05:59 CEST] <cone-940> ffmpeg 03wm4 07master:72e7553125e6: pngdec: set correct range
[01:19:19 CEST] <cone-940> ffmpeg 03wm4 07master:b697b297b77f: id3v2: do not export APIC description if empty
[02:25:59 CEST] <yvear> does anyone know why libdcadec won't work on individual streams? does this bug have a ticket? http://pastebin.com/aw0H0vuB
[02:27:54 CEST] <yvear> only works by -c:a libdcadec -i ... which is undesirable b/c it decodes all streams as dts
[02:54:36 CEST] <jamrial> yvear: if with -c:a:0 libdcadec it doesn't use libdcadec at all during decoding then yeah, that's probably a bug
[02:54:39 CEST] <jamrial> open a ticket for it
[02:55:27 CEST] <jamrial> nonetheless, you could recompile with --disable-decoder=dca so libdcadec is the only decoder available
[02:56:40 CEST] <rcombs> perhaps libdcadec should be positioned before dca in allcodecs.c
[02:56:58 CEST] <rcombs> (IIUC that would make it be used by default, which seems sane enough to me)
[02:57:10 CEST] <rcombs> (if you built ffmpeg with it, it figures you probably want it used)
[03:01:11 CEST] <yvear> rcombs, that would be great yes
[03:12:07 CEST] <BBB> wow kostya is really angry dude
[03:12:15 CEST] <BBB> Im reading some of his more recent blog posts
[03:12:21 CEST] <BBB> hes like the devil
[03:18:46 CEST] <rcombs> https://gist.github.com/16146a3c86bac5ff20fc anybody wanna check my channel mappings before I send this
[03:23:43 CEST] <atomnuker> uuh that function looks bad
[03:23:57 CEST] <atomnuker> what if a file has 7 channels
[03:24:45 CEST] <atomnuker> then s->channel_configuration would get set to 0
[03:25:10 CEST] <rcombs> atomnuker: yeah, and then we'd refuse to encode
[03:25:34 CEST] <atomnuker> int channel_configuration; looks redundant
[03:25:37 CEST] <rcombs> atomnuker: though in theory we should be able to proceed and write a PCE indicating the channel layout in that case
[03:26:27 CEST] <rcombs> and channel_configuration should be based on channel layout, not on channel count
[03:27:23 CEST] <atomnuker> yep
[03:27:53 CEST] <rcombs> but I think that change belongs with adding PCE support
[03:29:35 CEST] <atomnuker> though since s->channel_elements only gets used when writing to the bitstream it'll probably be better to move everything related to put_audio_specific_config()
[03:30:27 CEST] <atomnuker> wait, no, nevermind, better to have a seperate variable
[03:32:56 CEST] <rcombs> I figured I'd make channel_configuration its own member to keep track of what we're actually writing to channel_configuration
[03:33:17 CEST] <rcombs> and if it's 0 then, as per the spec, we should write a PCE with the actual channel layout
[03:33:31 CEST] <rcombs> (but since we don't support that yet we bail)
[03:36:41 CEST] <atomnuker> I might get around to doing that in the summer, so yeah, that variable might get used in the future
[03:43:11 CEST] <atomnuker> keeping the function but putting an assert when channels == 7 might be the best for now
[03:47:14 CEST] <rcombs> atomnuker: eh, channels == 7 doesn't indicate a logic error, it indicates the user passed in something bad
[03:47:25 CEST] Action: rcombs -> out for a bit
[03:50:46 CEST] <atomnuker> yeah, a check and an error message is what I meant
[03:51:20 CEST] <yvear> @jamrial, what bug priority should this be? it should be a quick fix
[04:38:06 CEST] <jamrial> yvear: normal, unless it's a regression, in which case important
[05:05:10 CEST] <rcombs> can anyone with a 7.1-channel setup confirm my channel mappings are correct, though?
[05:06:32 CEST] <rcombs> http://puu.sh/hFu7K/a1cc82806f.mkv
[12:01:15 CEST] <kierank> Daemon404: how's it going
[12:13:02 CEST] <wm4> is today smpte troll day
[13:44:27 CEST] <j-b> 'morning
[14:25:20 CEST] <cone-786> ffmpeg 03hSÇ 07master:b6d8afd8208a: configure: replace arch loongson with arch extra list loongson
[14:34:37 CEST] <cone-786> ffmpeg 03hSÇ 07master:ba1f56ae9bac: configure: remove loongson check inline asm and mips dependent
[15:39:38 CEST] <cone-786> ffmpeg 03Ronald S. Bultje 07master:c97d30f02f34: vp9: de-duplicate some functions that are identical between 10/12 bpp.
[16:06:12 CEST] <haasn> https://www.ffmpeg.org/doxygen/2.5/pixfmt_8h.html#ad4791ea14975f098b649db7fcd731ce6
[16:06:21 CEST] <haasn> why does ffmpeg specify both AVCOL_TRC_BT2020_10 and AVCOL_TRC_BT2020_12?
[16:06:39 CEST] <haasn> There's just one BT.2020 gamma curve, the specification just suggests rounded values with good enough precision for 10 and 12 bit applications
[16:06:44 CEST] <nevcairiel> probably because some video standard made a difference there
[16:06:55 CEST] <haasn> There was an update to BT.2020 about a month ago clarifying this
[16:07:23 CEST] <haasn> https://0x0.st/jz.png
[16:09:15 CEST] <nevcairiel> this enum is supposed to match the values used in h264/h265, and they define two entries for BT.2020, with index 14 and 15
[16:10:27 CEST] <nevcairiel> which according to the h265 standard is really just the same as 709 or 601
[16:10:53 CEST] <haasn> Then the H.264/H.265 specifications don't really make sense after the update
[16:11:15 CEST] <haasn> The unique combination of gamma curve + bit depth already uniquely identifies the exact constants
[16:11:51 CEST] <nevcairiel> fact remains, our enum wants to mirror the exact values used in h264/265, so it has to include both
[16:20:17 CEST] <nevcairiel> who the f' uses gray decoding
[16:31:26 CEST] <haasn> nevcairiel: Interesting, the update of the H.265 standard eliminates this ambiguity
[16:32:46 CEST] <haasn> It now defines 1, 6, 14 and 15 as all being aliases for the one true curve, and uses the exact numbers in its definition
[16:33:52 CEST] <wm4> nice, more values that mean the same
[16:34:11 CEST] <haasn> exactly
[16:34:58 CEST] <haasn> more aliases which we all ignore in mpv because it's irrelevant information either way :p
[18:10:04 CEST] <cone-786> ffmpeg 03Giorgio Vazzana 07master:23e6cf832ff6: lavd/v4l2: fix typo
[20:01:16 CEST] <jamrial> ^ maybe rf64 should be set to "auto" as default
[20:31:28 CEST] <BBB> haasn: I dont think theres a single user that uses these values for display purposes
[20:31:36 CEST] <BBB> haasn: or if there is, I would love to see what they do with it
[20:31:48 CEST] <BBB> (and no, printing that text to a label is not a display purpose :) )
[20:32:01 CEST] <BBB> </ate>
[20:32:03 CEST] <BBB> </late>
[20:33:48 CEST] <haasn> BBB: We use them for display purposes in a big cascading switch block that has case AVCOL_TRC_BT709: case AVCOL_TRC_BT2020_10: case AVCOL_TRC_BT2020_10: /*etc*/ return MP_TRC_BT1886;
[20:34:29 CEST] <BBB> do you use MP_TRC_BT1886 to setup the monitor/window?
[20:34:30 CEST] <haasn> Because every standard that uses those for OETF (BT.601, BT.709, BT.2020) specifies or is covered by BT.1886's output transfer
[20:34:51 CEST] <haasn> BBB: we use it to set up the mapping from source (YUV) to display
[20:35:37 CEST] <BBB> Im positively shocked
[20:35:41 CEST] <BBB> (thats a compliment :) )
[20:35:53 CEST] <BBB> I always assumed clients just ignored that stuff
[20:35:57 CEST] <BBB> (like chrome does...)
[20:36:02 CEST] <haasn> No, we use it if it's there
[20:36:10 CEST] <haasn> Most of the time it isn't, though, so we have to have a very good guessing algorithm :/
[20:38:19 CEST] <BBB> default: return MP_TRC_BT1886
[20:42:10 CEST] <cone-786> ffmpeg 03Michael Niedermayer 07master:982e7bbfa6b5: avcodec/vc1: Skip chroma operations if CODEC_FLAG_GRAY is set
[23:10:43 CEST] <cone-786> ffmpeg 03Giorgio Vazzana 07master:28f20d2ff487: lavd/v4l2: produce a 0 byte packet when a dequeued buffer is flagged with V4L2_BUF_FLAG_ERROR
[00:00:00 CEST] --- Sat May  9 2015