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

[burek]

[11:03:07 CEST] <cone-788> ffmpeg 03Clément BSsch 07master:1895e3a24fd5: ffmpeg: fix broken indent/style in write_frame
[11:10:01 CEST] <ubitux> i need help with the convert to codecpar in ffmpeg wrt bsf
[11:10:26 CEST] <ubitux> in ffmpeg.c we currently use av_apply_bitstream_filters() which is deprecated
[11:10:47 CEST] <ubitux> in favor of... ?
[11:11:02 CEST] <ubitux> i see a private api in lavf but that's all
[11:11:46 CEST] <ubitux> if we move to codecpar, how are we supposed to apply bsf using now unavailable avctx->codec; do we have an api using AVStream or codecpar?
[11:12:48 CEST] <ubitux> maybe the whole concept of bsf is not necessary anymore because automatically inserted?
[11:12:53 CEST] <ubitux> i would welcome a head up on this
[11:13:00 CEST] <ubitux> if anyone have a few minutes
[11:20:29 CEST] <BtbN> I think ffmpeg.c doesn't have to deal with it at all anymore. But I'm not 100% sure.
[11:21:32 CEST] <durandal_1707> didn't rcombs worked on this?
[11:22:42 CEST] <durandal_1707> i will push old joinfields filter as weave one
[11:24:24 CEST] <rcombs> ubitux: there are still some cases where auto-insertion isn't done (certain muxers), and some BSFs aren't meant to be auto-inserted
[11:26:07 CEST] <rcombs> there's no direct replacement for av_apply_bitstream_filters, and there probably shouldn't be
[11:26:19 CEST] <rcombs> since under the new API a BSF can in theory output multiple packets for one input packet
[11:26:31 CEST] <rcombs> so ffmpeg.c should iterate over BSFs and run them itself
[11:30:38 CEST] <ubitux> so, ideally how should it be?
[11:30:55 CEST] <ubitux> do we need a new api, do we need to drop that code, do we need to use the new api in a complete different way?
[11:43:20 CEST] <ubitux> i guess i'll keep the compat for now and see how things go
[11:50:36 CEST] <BtbN> Is it normal that a filter gets faster after running for a few seconds?
[11:51:02 CEST] <ubitux> which one?
[11:51:23 CEST] <ubitux> maybe it has a cache and starts reusing pre computed data
[11:52:06 CEST] <BtbN> Well, not a filter, my 420p10 to p010 conversion code
[11:52:25 CEST] <BtbN> the first few seconds it needs ~70ms per call, and then it drops to ~62ms
[11:52:44 CEST] <BtbN> uhm, 7.0 and 6.2
[11:58:47 CEST] <kierank> CPU frequency scaling most likely
[12:03:05 CEST] <ubitux> michaelni: what is 9098f0ecd7bfa8e971ab92bd0c244cb003ef43b2 fixing?
[12:05:40 CEST] <BtbN> is there anything else to converting from 8 to 10 bit than a << 2?
[12:19:38 CEST] <iive> BtbN: you want to fill the 2 extra bits with msb of the 8 bits. so 0x00->0x000, 0x80->0x808, 0xFF -> 0xFFF 
[12:27:41 CEST] <cone-788> ffmpeg 03Paul B Mahol 07master:3e1356f790b1: avfilter: add weave filter
[12:29:42 CEST] <durandal_1707> lgpl interlacer: -vf separatefields,select="eq(mod(n\,4)\,0)+eq(mod(n\,4)\,3)",weave
[12:37:07 CEST] <michaelni> ubitux, _IIRC_ some formats dont allow common factors and some formats have restrictions on how large num & den can be
[12:38:29 CEST] <michaelni> also if you just revert this, fate will break
[12:43:46 CEST] <ubitux> ok
[13:04:17 CEST] <BtbN> iive, so like this: t = *tsrc0++ << 8; *tdstY++ = t & (t >> 6); 
[13:05:05 CEST] <BtbN> hm, that collides with the P010 format. needs another &
[13:06:23 CEST] <BtbN> *tdstY++ = (t & (t >> 6)) & 0xFFC0;
[13:06:28 CEST] <BtbN> and it's an |, of course.
[13:12:56 CEST] <BtbN> no, this doesn't look right: http://imgur.com/CPn4dFt
[13:13:10 CEST] <BtbN> that what i'd have expected: http://imgur.com/rQbJjKI
[13:15:47 CEST] <BtbN> with just inp << 8 it looks as expected
[13:16:15 CEST] <iive> try with t=*tsrc0++; *tdstY++=( (t<<8)|t )&0xFFC0;
[13:17:07 CEST] <BtbN> so without prior <<8 of t i guess
[13:17:26 CEST] <cone-788> ffmpeg 03Davinder Singh 07master:367577dbe267: avfilter/vf_minterpolate: rename chroma log vars
[13:17:41 CEST] <BtbN> but yeah, I see the mistake
[13:17:55 CEST] <iive> 010 is actually P16 with some bits zeroed.
[13:19:23 CEST] <BtbN> yes
[13:21:10 CEST] <BtbN> that looks actually more correct than any other path
[13:21:29 CEST] <BBB> internet is so bad in ibis mitte (vdd hotel)
[13:21:54 CEST] <BBB> anyone have suggestions on improving wifi connectivity there?
[13:23:39 CEST] <BtbN> so, yuv420p -> p010 -> png looks better than yuv420 straight to png or yuv420p10 to png.
[13:24:57 CEST] <durandal_1707> BtbN: lies, give proof
[13:28:33 CEST] <BtbN> durandal_1707, https://btbn.de/images/test/
[13:30:26 CEST] <BBB> you should try disabling the direct conversion in swscale (its very old mplayer-age code that operates on a minimal number of bits) and see if that helps
[13:30:45 CEST] <BBB> its super-fast ;)
[13:31:39 CEST] <BtbN> which direct one?
[13:32:37 CEST] <BtbN> yuv420p to rgb24?
[13:34:17 CEST] <durandal_1707> argh, good old banding
[13:35:08 CEST] <iive> BtbN: are you sure you haven't misslabeled the 10bit and 8to10bit?
[13:35:13 CEST] <BBB> BtbN: yes
[13:35:22 CEST] <durandal_1707> BtbN: try allyuv source for fun
[13:37:20 CEST] <BtbN> iive, i just ran the commands in the cmd.txt again, so they should all be correct
[13:44:43 CEST] <BtbN> durandal_1707, https://btbn.de/images/test/ added the same tests, just for allyuv
[13:48:28 CEST] <BtbN> they don't look obviously bad
[14:01:47 CEST] <cone-788> ffmpeg 03Michael Niedermayer 07master:e4e4a9cad7f2: avformat/avidec: Fix infinite loop in avi_read_nikon()
[14:31:50 CEST] <BtbN> hm, the the direct yuv420p -> p010 conversion breaks fate.
[14:32:20 CEST] <BtbN> which is kind of expected i think, but there is no good way to fix it, as it will break diffrently on be/le platforms.
[14:34:16 CEST] <BtbN> that is, on platforms where be is native
[14:53:05 CEST] <durandal_1707> BtbN: check if destination is be or le variant
[14:53:19 CEST] <durandal_1707> on be or le arch
[14:53:26 CEST] <BtbN> and just don't offer the conversion on the wrong one?
[14:53:46 CEST] <durandal_1707> yes, or implement one...
[14:53:54 CEST] <BtbN> well, I implemented the native one
[14:54:13 CEST] <BtbN> guess I'll just switch to AV_RL16/WL16, and implement the LE one
[15:09:42 CEST] <BtbN> hm, it's notably slower that way
[15:10:03 CEST] <BtbN> from 6ms to 11ms
[15:12:08 CEST] <durandal_1707> support only native conversion
[15:12:38 CEST] <BtbN> yes, but doing so breaks fate, because the native direct conversion has a diffrent result than the indirect one
[15:13:35 CEST] <BtbN> so if I update fate for the new results on a le platform, it will break on all be platforms.
[15:17:00 CEST] <BtbN> I wonder why it is that much slower though. Shouldn't AV_RL16 on a le platform be a no-op?
[15:17:12 CEST] <BtbN> same for WL16
[15:33:01 CEST] <BtbN> hm, found a solution, but I don't like it.
[15:33:09 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/484ef960da65f0d28c3bd0b84b8a62661311a7fa
[16:04:57 CEST] <BtbN> this Ali guy on ffmpeg-devel should fix his reply button.
[16:05:40 CEST] <BBB> +100
[16:06:25 CEST] <BBB> I also wonder if its useful to use the mailinglist as hey I have all these ideas or I tested your patch and can you also implement my personal fave feature request X?"
[16:07:33 CEST] <BtbN> well, I actually implemented most of what he's talking about
[16:10:34 CEST] <BBB> including the yuv420p(8) to p010le?
[16:10:45 CEST] <cone-788> ffmpeg 03Paul B Mahol 07master:b5cf307d0f85: avfilter/vf_zscale: make possible to change chroma location
[16:10:52 CEST] <BBB> (please dont :-D)
[16:11:01 CEST] <BBB> durandal_1707: so, will you come?
[16:12:35 CEST] <durandal_1707> BBB: nope, i don't like some folks
[16:12:52 CEST] <BBB> :(
[16:13:10 CEST] <BBB> its not good if only a clique of people attends
[16:13:11 CEST] <BBB> the people attending should be our active developer community
[16:14:10 CEST] <BBB> try to come next year, just ignore the people you dont like, or smile at them, whatever works for you
[16:14:50 CEST] <BBB> BtbN: nice patchset btw, so p010 is really just nv12 right? (upshifted to HSB instead of LSB of the 16bit word)
[16:15:15 CEST] <BtbN> yes, it's 10bit NV12, with a stupid shift
[16:15:25 CEST] <BtbN> BBB, yes
[16:15:41 CEST] <BtbN> currently fighting fate because of that
[16:15:46 CEST] <JEEB> :)
[16:15:58 CEST] <BtbN> the problem is, the native implementation is _a lot_ faster than the one using AV_RL/WL
[16:16:11 CEST] <BBB> native?
[16:16:16 CEST] <BtbN> But with the native one, there is no way to not break fate on either be or le platforms
[16:16:29 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/484ef960da65f0d28c3bd0b84b8a62661311a7fa
[16:16:32 CEST] <BtbN> it now has both
[16:16:39 CEST] <BBB> the native should only be used for native to native
[16:17:15 CEST] <BtbN> yes, that's what I'm doing
[16:17:17 CEST] <nevcairiel> the pixfmts have native variants, so make sure to only use it when its native to native
[16:17:21 CEST] <BBB> I mean you can make it use AV_{R,W}L but thats insane
[16:17:23 CEST] <BBB> so why does fate break?
[16:17:23 CEST] <BtbN> that's not the issue
[16:17:35 CEST] <BBB> oh wait, I see
[16:17:41 CEST] <BBB> the md5 changes because of rounding
[16:17:45 CEST] <BBB> and which md5 changes depends on arch?
[16:17:47 CEST] <BtbN> the problem is, the results of the direct unscaled copy are slightly diffrent from the indirect conversion
[16:17:48 CEST] <BBB> (be or le)
[16:17:51 CEST] <BtbN> and..
[16:17:52 CEST] <BtbN> exactly
[16:17:54 CEST] <BBB> lol :D
[16:17:57 CEST] <BBB> that sucks
[16:18:09 CEST] <BBB> maybe you do have to do AV_R/WL in the fast variant also thwn
[16:18:12 CEST] <BBB> *then
[16:18:20 CEST] <BBB> or alternatively you can put it under if !bitexact
[16:18:29 CEST] <BtbN> Well, I have a solution now
[16:18:31 CEST] <cone-788> ffmpeg 03Michael Niedermayer 07master:7a6c288c2b5b: swscale/tests/swscale: add cpuflags option
[16:18:32 CEST] <BBB> (its kind of hacky)
[16:18:47 CEST] <BtbN> I use AV_WL/RL on be, and native on le
[16:19:01 CEST] <BtbN> That way the hash is the same on both, and le still has the fast implementation
[16:19:53 CEST] <BBB> wait
[16:20:17 CEST] <nevcairiel> just the way how the bytes are stored makes it different?
[16:20:18 CEST] <nevcairiel> that sounds w rong
[16:20:39 CEST] <BtbN> no, it's diffrent from the indirect swscale conversion, because it rounds diffrently or something
[16:20:53 CEST] <BtbN> and if le or be is diffrent depends on the arch, as it's allways for the native format
[16:21:00 CEST] <BtbN> so it either breaks fate on le or be platforms
[16:21:09 CEST] <BBB> are you suggesting AV_WL is slower than a direct read on x86?
[16:21:09 CEST] <BBB> because it should result in the same opcode
[16:21:09 CEST] <BBB> nevcairiel: because of the upshift
[16:21:09 CEST] <BBB> nevcairiel: requires native 16bit numbers
[16:21:09 CEST] <BBB> its not just a shuffle
[16:21:50 CEST] <BtbN> BBB, i just converted the function from direct writes to AV_RL/WL, and it doubled the time the function takes.
[16:22:45 CEST] <BtbN> from 6ms per call to 11ms
[17:37:16 CEST] <ubitux> michaelni: any idea how i'm going to move the discard stream thing in ffmpeg_opt.c:add_input_streams?
[17:37:23 CEST] <ubitux> (from codec to codecpar)
[17:37:34 CEST] <ubitux> i won't be able to query st->codec anymore
[17:37:53 CEST] <Prelude2004c> BtbN , you around ?  if so please message me
[18:16:34 CEST] <michaelni> ubitux, does it even need to access st->codec ?
[18:16:43 CEST] Action: michaelni doesnt remember
[18:17:20 CEST] <ubitux> i don't know, it's weird stuff introduced in 01ef127bf8556c934262f96d6876e4479bba9d5f
[18:17:44 CEST] <ubitux> it seems handled differently than other options
[18:20:04 CEST] <michaelni> maybe this was just for parsing the strings into enum
[18:31:12 CEST] <Prelude2004c> DHE, you around ?
[18:32:07 CEST] <cone-788> ffmpeg 03Paul B Mahol 07master:5dcd913ab51f: doc/filters: add weave example
[18:34:18 CEST] <DHE> Prelude2004c: intemittently
[18:38:14 CEST] <Prelude2004c> DHE, can you private message me. I tried but it's not allowed
[18:38:46 CEST] <DHE> that's just my own IRC script. it's designed to prevent unpleasant surprises
[18:39:37 CEST] <Prelude2004c> message me when you have a few min. I have a request you may be interested in
[18:40:15 CEST] <DHE> ...?
[19:03:04 CEST] <BBB> BtbN: before my internet crapped out again, I said this (not sure if you saw it)
[19:03:23 CEST] <BBB> <BBB> but make it non-native also
[19:03:23 CEST] <BBB> <BBB> theres no reason to do native only if you do AV_W/RL/B
[19:03:24 CEST] <BBB> <BBB> you can do yuv420p10be to p010le, yuv420p10le to p010le, yuv420p10le to p010be and yuv420p10be to p010be
[21:58:57 CEST] <cone-982> ffmpeg 03Michael Niedermayer 07master:f580719b1a24: swscale/swscale: Factor bottom to top handling
[21:58:57 CEST] <cone-982> ffmpeg 03Michael Niedermayer 07master:89ec11e09613: swscale/swscale: Try to fix rgb48Toxyz12() with slices
[21:58:57 CEST] <cone-982> ffmpeg 03Michael Niedermayer 07master:47bc1bdafb09: swscale/swscale_unscaled: Fix packed_16bpc_bswap() with slices
[00:00:00 CEST] --- Sat Sep  3 2016