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

[burek]

[00:15:18 CEST] <cone-425> ffmpeg 03Michael Niedermayer 07master:4351c288b984: ffplay&cmdutils:Factor get_rotation() code out
[00:15:19 CEST] <cone-425> ffmpeg 03Michael Niedermayer 07master:800df6a849c8: ffmpeg_filter: use get_rotation()
[00:39:33 CEST] <haasn> nevcairiel: BtbN: What do these Crv, Cbu, Cgu, Cgv constants stand for and how do I calculate them? For example, in the mpv code, the VÔR component (which I would assumed corresponds to Crv) is calculated as 2 * (1-lr)
[00:39:52 CEST] <haasn> which is 1.5748 for BT.709
[00:41:34 CEST] <haasn> I cannot get that to agree with 117504
[00:42:17 CEST] <haasn> I tried multiplying by 2^16, by 2^15, by (235/255)·2^16, by (235/255)·2^15, by (219/255)·2^16 and by (219/255)·2^15
[00:43:13 CEST] <haasn> None of them are even remotely close
[00:44:29 CEST] <BtbN> There is not one clear answer on how to convert YUV to RGB
[00:44:39 CEST] <BtbN> there are several diffrent standards for that
[00:44:47 CEST] <BtbN> you are propably just comparing diffrent ones
[00:44:52 CEST] <haasn> But they are all mathematically equivalent; either that or one implementation is wrong
[00:44:58 CEST] <BtbN> Nope, they aren't.
[00:45:20 CEST] <haasn> ?
[00:45:36 CEST] <BtbN> There are two "major" ones, and a few more other ones.
[00:46:39 CEST] <BtbN> http://www.fourcc.org/fccyvrgb.php has a bit of information about it
[00:47:28 CEST] <haasn> https://0x0.st/QK.png doesn't seem to provide any ambiguity on how the linear mapping works
[00:48:00 CEST] <BtbN> That's the BT.709 definition of YUV. But there are other ones.
[00:48:24 CEST] <haasn> there are other definitions of Bt.709?
[00:49:15 CEST] <BtbN> Other definitions of YUV.
[00:49:24 CEST] <haasn> What relevance do they have to BT.709?
[00:49:49 CEST] <BtbN> They have relevance for other formats and codecs.
[00:50:03 CEST] <haasn> But if you're converting BT.709 images, then surely the only correct code ffmpeg should be following is the BT.709 specification?
[00:50:26 CEST] <BtbN> Sure, and so it does?
[00:50:48 CEST] <haasn> I can find no evidence to support that. The code is cryptic and my best attempts to reproduce the numbers have failed
[00:51:02 CEST] <haasn> Well, I can find no evidence to support it based on the code alone
[00:53:22 CEST] <kierank> swscale being cryptic
[00:53:24 CEST] <kierank> say it isn't so
[00:53:57 CEST] <haasn> All of this started from my attempt to fix a bug in swscale (cannot convert BT.2020-NCL video, let alone BT.2020-CL), but I think I've reached the conclusion that it's probably easier to ditch swscale and implement my own yuvÔrgb conversion functions
[00:54:41 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/HEAD/libswscale/utils.c#L691 does something with those coeffs
[00:55:12 CEST] <BtbN> I'd guess they are just shifted fixed point representations of the official coefficients
[00:56:15 CEST] <Compn> haasn : got sample file that does not convert properly ?
[00:56:31 CEST] <Compn> you could just report it and hope michaelni fixes it :P
[00:56:38 CEST] <kierank> BtbN: that's rgb to yuv
[00:56:42 CEST] <kierank> not yuv to rgb
[00:56:51 CEST] <haasn> Compn: for Bt.2020, tes
[00:56:52 CEST] <haasn> yes*
[00:56:56 CEST] <BtbN> but it uses the same coefficients
[00:57:02 CEST] <kierank> no
[00:57:04 CEST] <Compn> haasn : can you share it, upload i mean
[00:57:11 CEST] <kierank> btbn: because rgb to yuv is hardcoded to 601
[00:57:16 CEST] <BtbN> in fact, it's the only code i found that uses them at all, or i failed to parse the code for that symbol
[00:57:20 CEST] <kierank> whereas the opposite allows you choose
[00:57:23 CEST] <kierank> to choose
[01:02:22 CEST] <haasn> Compn: http://www.nand.wakku.to/ramps.tar.xz this has a set of color ramps that I generated a while back, with source code for generation. Long story short, the interesting ones are 709_709.mkv, 2020_2020nc.mkv and 2020_2020c.mkv, in that they should all display identically in their native colorspace (ie. ignoring the difference in color gamut)
[01:02:34 CEST] <haasn> For example, mpv with color management disabled, renders them as follows:
[01:03:47 CEST] <haasn> (I've stripped the color space information for easy comparison): 709_709.mkv https://0x0.st/QP.png  2020_2020nc.mkv https://0x0.st/QZ.png  2020_2020c.mkv https://0x0.st/QN.png
[01:04:29 CEST] <haasn> As you can see, they're all virtually identical, ignoring the fact that the bands are in different positions, and the fact that BT.2020-C has less noticeable subsampling artifacts
[01:05:05 CEST] <haasn> Now, using the mpv screenshot functionality, which takes the same image (including the correct colormatrix information), passes it through swscale's YUV->RGB conversion, and saves the result; I get these results:
[01:05:41 CEST] <haasn> 709_709.mkv https://0x0.st/Qq.png  2020_2020nc.mkv https://0x0.st/Qb.png  2020_2020c.mkv https://0x0.st/Qc.png
[01:06:02 CEST] <haasn> BT.709 matches 1:1 as it should
[01:06:11 CEST] <haasn> but for the BT.2020 samples, it falls back to BT.601 or whatever internal default
[01:08:00 CEST] <haasn> (I can prove this by using --vf=format=colormatrix=bt.601 in mpv to fool it into thinking the source was BT.601 instead: I get this output for the 2020_2020nc.mkv clip https://0x0.st/QT.png and this output for the 2020_2020c.mkv clip https://0x0.st/QA.png )
[01:08:46 CEST] <haasn> for BT.2020-NCL, it's an easy fix: just add another line to that table with the correct parameters
[01:09:11 CEST] <haasn> easy in theory, hard in practice because I cannot find a single documented formula anywhere describing how to get from the coefficients in the BT recs to the numbers used in the source code
[01:10:40 CEST] <haasn> for BT.2020-CL, the fix is most likely complicated
[01:10:59 CEST] <BtbN> The much more confusing thing is I can't find any piece of code that uses these coefficients
[01:11:31 CEST] <kierank> haasn: ask michaelni 
[01:12:53 CEST] <haasn> BtbN: they're used in filter_frame (line 444) of libavfilter/vf_scale.c, does that help?
[01:14:26 CEST] <haasn>     case MP_CSP_BT_709:     return SWS_CS_ITU709; <- whoa, what are *those* constants?
[01:14:41 CEST] <kierank> mplayer cruft
[01:15:28 CEST] <haasn> I' mean the SWS_CS_ITU709; this is confusing - doesn't it use AVCOL_SPC_BT709?
[01:15:56 CEST] <haasn> Either that or the two constants agree internally, because looking at the documentation of the table, the comments match 1:1 with the order of the AVCOL_SPC_ coefficients
[01:16:42 CEST] <haasn> they're defined in swscale.h
[01:17:35 CEST] <haasn> Are they just convenient aliases? nothing inside ffmpeg seems to use it
[01:18:04 CEST] <haasn> Instead all ffmpeg-internal code just uses the AVCOL_SPC_* constants (eg. from the int colorspace parameter)
[01:21:19 CEST] <haasn> BtbN: Ah, it looks like swscale operates like this 1. get the colorspace table entry using sws_getCoefficients, 2. pass this to sws_setColorspaceDetails
[01:21:36 CEST] <haasn> So that's where the missing link is in connecting that table to the rest of the code, it happens in external code
[01:23:07 CEST] <BtbN> ah
[01:41:46 CEST] <haasn> BtbN:     c->vrCoeff = roundToInt16(crv * 8192) * 0x0001000100010001ULL;
[01:41:57 CEST] <haasn> (Do I even want to begin thinking about this code?)
[01:42:43 CEST] <haasn> and then it applies some other weird stuff like     c->yuv2rgb_v2r_coeff = (int16_t)roundToInt16(crv << 13);
[01:43:22 CEST] <haasn> and then there's a nightmare of a switch(bpp)
[02:01:28 CEST] <jamrial> haasn: that first line putting an int16 value four times inside an int64
[02:02:57 CEST] <jamrial> odd seeing that outside of simd code
[02:05:26 CEST] <Prelude2004c> hey ... anyone know what is a very good playout server for video ?
[02:37:35 CEST] <cone-425> ffmpeg 03Andreas Cadhalpun 07master:eb9fb508b0e0: matroskadec: use uint64_t instead of int for index_scale
[09:08:13 CEST] <wm4> haasn: the SWS aliases are there because libswscale didn't want to depend on libavcodec
[09:08:33 CEST] <wm4> which is pointless now, because the AV constants are in libavutil now, on which sws depends anyway
[09:09:07 CEST] <wm4> so I think a patch which defines the SWS constants to the AV ones might be accpepted (if they're still compatible)
[09:41:18 CEST] <j-b> 'morning
[09:44:08 CEST] <BBB> hi j-b
[10:35:19 CEST] <rcombs> How do I patch KDE2 under FreeBSD?
[10:35:33 CEST] <nevcairiel> KDE2 is still something that exists?
[14:32:57 CEST] <cone-168> ffmpeg 03Michael Niedermayer 07master:3dfbdb328ed9: avcodec/ffv1dec: Check quant table symbols more completely
[14:32:58 CEST] <cone-168> ffmpeg 03Michael Niedermayer 07master:03baa861eae4: avcodec/ffv1dec: More completely check micro_version
[14:32:59 CEST] <cone-168> ffmpeg 03Michael Niedermayer 07master:d43cd6b08ed5: avcodec/ffv1dec: Check chroma shift parameters
[14:44:02 CEST] <ubitux> i'm trying to debug a seek with ffmpeg but the ts seems to be adjusted for some reason
[14:44:24 CEST] <ubitux> ffmpeg -ss 50 -i media.mkv -af ashowinfo -f null - // this shows pts starting at 0
[14:44:29 CEST] <ubitux> why, and how to avoid that?
[14:44:39 CEST] <ubitux> (i'm trying to check the accuracy of the seek wrt to audio)
[14:45:11 CEST] <Daemon404> -copyts -vsync passthrough
[14:46:29 CEST] <ubitux> thanks
[16:02:07 CEST] <kierank> so mpeg-2 is broken when using the api
[16:02:07 CEST] <kierank> but works in lavf 
[16:02:07 CEST] <kierank> and ffmpeg
[16:02:07 CEST] <kierank> how do I report this bug
[16:02:11 CEST] <kierank> bencoh: ^
[16:02:44 CEST] <Daemon404> i assume you must provide a small test program
[16:03:11 CEST] <Daemon404> usually when i see things like that, it's cause i didn't know some proper magical order and/or incantation
[16:12:22 CEST] <nevcairiel> kierank: mpeg2 broken how? I use lavc without lavf through the API just fine
[16:12:35 CEST] <kierank> From what I understand the first GOP is broken
[16:12:45 CEST] <kierank> it's reproducable with VLC apparently (when set to use avcodec)
[16:12:51 CEST] <kierank> bencoh may be able to explain more
[16:13:50 CEST] <wm4> kierank: sample?
[16:14:17 CEST] <nevcairiel> I do use the parser for all mpeg2 content before lavc though, if that matters somehow
[16:14:41 CEST] <Daemon404> probably
[16:25:55 CEST] <cone-168> ffmpeg 03Andreas Cadhalpun 07master:e54540655f22: matroskadec: check s->streams[k] before using it
[16:25:56 CEST] <cone-168> ffmpeg 03Michael Niedermayer 07master:5d309d309108: avformat/matroskadec: Use tracks[k]->stream instead of s->streams[k]
[16:35:14 CEST] <bencoh> wm4: http://www.dvdloc8.com/dolbydtsclip.php?clipid=2
[16:35:37 CEST] <bencoh> (that's the Dolby Broadway clip)
[16:36:53 CEST] <bencoh> playing it with vlc-2.2.1/libavcodec shows an artefact (here it's a grey image) at the begining
[16:38:44 CEST] <bencoh> (that's a quick way to reproduce it, I guess we'll need to send a sample)
[16:38:49 CEST] <bencoh> (a program sample)
[16:42:52 CEST] <nevcairiel> I assume someone verified that the clip actually does start properly on a GOP boundary
[17:28:31 CEST] <nevcairiel> hey look, a system based on a 12-year old debian
[17:29:54 CEST] <Daemon404> :D
[17:56:48 CEST] <cone-168> ffmpeg 03Michael Niedermayer 07master:f320f2f4c639: cmdutils: Ask for a sample in case a odd rotation angle is encountered
[18:04:15 CEST] <bencoh> nevcairiel: more than that, we have a different behaviour with older ffmpeg
[18:14:14 CEST] <cone-168> ffmpeg 03Carl Eugen Hoyos 07master:d90f91c1c85d: lavf/mxfenc: Write correct interlaced flag when muxing dnxhd.
[18:14:15 CEST] <cone-168> ffmpeg 03Carl Eugen Hoyos 07master:8ad04d24c82e: lavf/apngenc: Fix png remuxing by using default extension apng.
[18:14:16 CEST] <cone-168> ffmpeg 03Carl Eugen Hoyos 07master:0bca6182b26a: lavfi/cropdetect: Fix cropdetect for > 8 bit input.
[18:14:17 CEST] <cone-168> ffmpeg 03Michael Niedermayer 07master:783e94cb1190: Merge remote-tracking branch 'cehoyos/master'
[18:25:54 CEST] <drwx> 28/04/2015 12:41 < drwx> hi, could anyone look at this bug? https://trac.ffmpeg.org/ticket/2975
[18:25:57 CEST] <drwx> 28/04/2015 12:41 < drwx> also, https://trac.ffmpeg.org/ticket/4487 looks like a duplicate
[20:36:05 CEST] <Compn> drwx : i'm guessing different bugs as the first one isnt using copy
[20:36:16 CEST] <Compn> drwx : also i'd like to see the first bug with updated ffmpeg output :P
[20:38:07 CEST] <Compn> and possibly with pts fixing filter applied :P
[20:38:12 CEST] <Compn> or latest x264
[21:39:06 CEST] <cone-168> ffmpeg 03Andreas Cadhalpun 07master:0eec40b713ee: avidec: check for valid bit_rate range
[21:46:11 CEST] <haasn> Anybody know what the difference is between AVCOL_TRC_IEC61966_2_1 and AVCOL_TRC_IEC61966_2_4?
[21:47:03 CEST] <haasn> is the latter just for xvYCC?
[23:18:46 CEST] <cone-168> ffmpeg 03Michael Niedermayer 07master:b4cc7d67f564: avfilter/vf_cover_rect: clip rectangle if it is partly outside the input
[23:41:24 CEST] <cone-168> ffmpeg 03James Almer 07master:079b7f6eacc0: vp9: add profile names
[23:42:10 CEST] <j-b> a1m
[23:42:12 CEST] <j-b> oops
[23:53:59 CEST] <BBB> jamrial: Im still not happy about the names, the problem is that the typical use case is to render them right? so you get profile: main or profile: profile 0, which is redundant
[23:54:04 CEST] <BBB> (it should be: profile: 0)
[23:54:22 CEST] <BBB> I know this is not the most important thing in the world right now
[23:55:35 CEST] <nevcairiel> personally i show them as "vp9 profile 0", still reads odd, but what can you do
[23:56:44 CEST] <BBB> give them real names
[23:56:47 CEST] <BBB> :-p
[23:56:50 CEST] <BBB> anyway
[23:56:53 CEST] <BBB> thats a google problem
[23:56:57 CEST] <nevcairiel> inventing names that noone else uses doesnt help either
[23:57:00 CEST] <BBB> Im pretty sure they call 2/3 high bitdepth"
[23:57:07 CEST] <BBB> but I dont think profile 1 has a name
[23:57:28 CEST] <nevcairiel> steal h264 names, and call it range extension
[23:57:38 CEST] <BBB> I was considering calling it main and ext
[23:57:42 CEST] <BBB> and then high bitdepth main/ext
[23:58:19 CEST] <BBB> Ill try to add profile 2/3 this week, cant promise but I have some time for it
[23:58:43 CEST] <jamrial> BBB: ah, didn't think about that. i saw the ffmpeg output showing "codec: vp9 (Profile 0)" and thought it was good
[23:59:18 CEST] <jamrial> it can be changed to simply 0, or just go with main/ext as you said
[23:59:24 CEST] <jamrial> both are fine by me
[00:00:00 CEST] --- Tue May  5 2015