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

[burek]

[00:03:32 CET] <jkqxz> Other decoders do just write those fields with the stream values directly, as you're observing for MJPEG.
[00:03:56 CET] <Sesse>     Stream #0:0, 10, 1/1000: Video: mjpeg, 1 reference frame, yuv422p(tv, bt470bg/bt709/iec61966-2-1, progressive, center), 1280x720 [SAR 1:1 DAR 16:9], 0/1, 1k fps, 120 tbr, 1k tbn, 1k tbc (default)
[00:04:00 CET] <Sesse> still center :-/
[00:04:10 CET] <jkqxz> (VP9: <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp9.c;h=acf3ffc9e73045530488daf12e839ff02b428bb6;hb=HEAD#l424>, H.265: <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/hevcdec.c;h=10bf2563c060b8c80da4124ea27b86b5d5979c78;hb=HEAD#l337>.)
[00:04:40 CET] <Sesse> hm, this is odd, even if I remove that setting, it still gets out as cente
[00:04:42 CET] <Sesse> r
[00:04:57 CET] <thardin> git grep the_thing
[00:05:16 CET] <Sesse> wondering if I'm not running the code I expect to
[00:05:41 CET] <Sesse> indeed, was running the wrong binary :-)
[00:05:42 CET] <Sesse>     Stream #0:0, 10, 1/1000: Video: mjpeg (Baseline), 1 reference frame, yuv422p(tv, bt709/bt709/iec61966-2-1, progressive, left), 1280x720 [SAR 1:1 DAR 16:9], 0/1, 1k fps, 120 tbr, 1k tbn, 1k tbc (default)
[00:05:46 CET] <Sesse> much better
[00:05:58 CET] <Sesse> that's with the conditional setting
[00:06:00 CET] <Sesse> and it passes FATE
[00:06:45 CET] <thardin> great. now make a FATE test :]
[00:07:07 CET] <thardin> so you can be sure your fix doesn't accidentally break in the future
[00:10:00 CET] <jkqxz> And maybe change the docs in avcodec.h?  This seems quite dubious if decoders are acting in different ways here.
[00:10:10 CET] <thardin> that too
[00:11:38 CET] <jkqxz> Perhaps an avcodec flag to say "I have colour information from the demuxer, don't overwrite it".  That might be a big pain to change if a lot of decoders overwrite it unconditionally, though (small sample suggests they do).
[00:12:01 CET] <Sesse> why would you need a flag?
[00:12:09 CET] <Sesse> I mean, setting it to something that isn't _UNSPECIFIED is already that flag
[00:13:04 CET] <jkqxz> That breaks on a change from foo to unspecified.
[00:13:23 CET] <Sesse> no, not really
[00:13:24 CET] <jkqxz> And I'm not sure people will want to trust demuxers.
[00:13:54 CET] <jkqxz> (Since I bet a lot of things get default values there, too.)
[00:14:03 CET] <Sesse> yes, that's a worse problem
[00:14:16 CET] <Sesse> although a demuxer shouldn't really
[00:14:29 CET] <Sesse> a decoder makes sense, a demuxer doesn't
[00:15:49 CET] <jkqxz> That sounds like an argument for the flag being off by default :P
[00:16:48 CET] <Sesse> you keep introducing this flag that I don't understand what is supposed to do :-)
[00:17:49 CET] <jkqxz> Indicate that the decoder shouldn't overwrite the colour information with whatever it actually finds in the stream, I guess.
[00:18:07 CET] <Sesse> and who would set this flag?
[00:18:12 CET] <Sesse> the demuxer? the user? the decoder?
[00:18:33 CET] <jkqxz> The user.
[00:18:37 CET] <Sesse> sounds unlikely to happen
[00:18:48 CET] <jkqxz> It would solve your specific problem!
[00:19:36 CET] <Sesse> well, so would just overriding the information in avctx directly from my application
[00:20:36 CET] <Sesse> it has the exact same set of problems: one would have to know somehow out-of-band when the incoming stream is such a stream, and it won't look right in any video players
[00:37:11 CET] <Sesse> ok, patch sent to ffmpeg-devel@, we'll see what happens
[01:37:12 CET] <cone-205> ffmpeg 03Michael Niedermayer 07master:09ec182864d4: avcodec/msmpeg4dec: Skip frame if its smaller than 1/8 of the minimal size
[01:37:12 CET] <cone-205> ffmpeg 03Michael Niedermayer 07master:d6f4341522c3: avcodec/wmv2dec: Skip I frame if its smaller than 1/8 of the minimal size
[01:37:12 CET] <cone-205> ffmpeg 03Michael Niedermayer 07master:953bd58861ad: avcodec/msvideo1: Check for too small dimensions
[02:29:49 CET] <philipl> BtbN: did you sign up for the video sdk 9 preview?
[10:27:04 CET] <BtbN> philipl, nope, don't really see a point to that.
[10:36:50 CET] <durandal_1707> what is about trac maintance it is becoming useless, it is 100% unavailable
[15:04:22 CET] <cone-366> ffmpeg 03Gyan Doshi 07master:6ea3cf1b6f18: doc: libmodplug
[19:10:14 CET] <durandal_1707> why mxf store width/height aligned to 16?
[19:11:03 CET] <JEEB> durandal_1707: does it really? I just thought people liked to include VANC data and then you'd have crop information in MXF
[19:11:32 CET] <JEEB> https://github.com/jeeb/ffmpeg/commits/mxf_adventures
[19:11:37 CET] <JEEB> I did at some point poke at it
[19:14:21 CET] <durandal_1707> michaelni: #5405 is ffv1 bug
[19:30:26 CET] <durandal_1707> atomnuker: are you alive?
[19:47:51 CET] <atomnuker> durandal_1707: no, I'm merely existing atm
[22:13:23 CET] <durandal_1707> atomnuker: doing anything ffmpeg related recently?
[22:15:41 CET] <atomnuker> I started writing a music player a week ago but gave up because dbus APIs are undocumented crap and I really wanted a single instance to manage playlists
[22:16:42 CET] <atomnuker> and creating random named pipes in /tmp isn't nice
[22:16:57 CET] <durandal_1707> atomnuker: that is not ffmpeg related in any way, where is opus fix? where is mdct/fft work? where is vulkan support?
[22:17:24 CET] <atomnuker> hey it did use lavf and lavc to decode, I got that much done
[22:17:47 CET] <durandal_1707> use mpv with lua, you noob!
[22:18:28 CET] <atomnuker> no such extension exists and managing playlists there is uncomfortable
[22:19:08 CET] <durandal_1707> nope, you have no skills
[22:21:13 CET] <atomnuker> yeah, I could have written a lua script for it, but where's the fun in that
[22:22:29 CET] <atomnuker> vulkan support is depending on whether mesa fixes their stuff, since chaining semaphores instead of blocking the pipeline at each stage crashed the gpu
[22:23:08 CET] <atomnuker> last I treid in... whenever that was it did that, but maybe now with the recent improvements and support for the dmabuf_modifier extension it all works now
[22:23:24 CET] <j-b> 'tsup?
[22:25:23 CET] <atomnuker> I think the nicest way to fix opusenc is to change afq to take initial_padding into account, if the initial_padding is indeed what causes the issue
[22:28:38 CET] <atomnuker> I'll get around to doing all that, give me a few days to finish hollow knight first, I've held off on playing it since april
[22:29:32 CET] <durandal_1707> NOOOOOOO
[22:30:54 CET] <j-b> hollow knight is really cool.
[22:31:25 CET] <durandal_1707> ony kids play games ^
[22:33:23 CET] <kierank> spiderman is great as well
[22:34:22 CET] <durandal_1707> powderman
[23:12:26 CET] <cone-339> ffmpeg 03Michael Niedermayer 07master:2c64a6bcd280: avcodec/ppc/hevcdsp: Fix build failures with powerpc-linux-gnu-gcc-4.8 with --disable-optimizations
[23:17:04 CET] <ubitux> is it on purpose that yuv’rgba gives different result than yuv’bgra with sws in bilinear? (after byte swapping)
[23:17:19 CET] <ubitux> it doesn't happen with any other interp (bicubic, spline, guauss, whatever)
[23:17:41 CET] <ubitux> i need to either disable x86 optims, use +full_chroma_int, or a different interpolation
[23:18:16 CET] <ubitux> i'm getting off-by-one most of the time, with a larger diff for green (around off by 2)
[23:18:17 CET] <durandal_1707> silly mmx code?
[23:18:38 CET] <ubitux> well, it's due to yuv2rgb32_1 apparently
[23:19:00 CET] <ubitux> i'm guessing it's related to "note this is not correct (shifts chrominance by 0.5 pixels) but it is a bit faster"
[23:19:21 CET] <durandal_1707> ah, lets guess author
[23:19:55 CET] <ubitux> note that i'm not even getting why i interpolation has a place here since there is no resize, only resampling
[23:20:28 CET] <ubitux> like, i'm surprised to get different always a different result depending on the interpolation i pick
[23:20:34 CET] <ubitux> even though i'm doing a yuv2rgb
[23:20:55 CET] <durandal_1707> yea
[23:20:58 CET] <ubitux> and of course even more surprised to get different results with a different byte swapping
[23:21:24 CET] <ubitux> and average of +2 on the green component if i pick rgba or bgra sounds pretty bad to me
[23:21:48 CET] <ubitux> michaelni: any idea?
[23:24:41 CET] <durandal_1707> just rewrite that code
[23:29:41 CET] <nevcairiel> ubitux: afaik sws discards some input chroma samples unless you set one of those mysterious flags, so it treats it like 420 or something and then uses one of its  cheap interpolation methods
[23:30:00 CET] <nevcairiel> its really full of awful logic
[23:30:44 CET] <nevcairiel> +full_chroma_inp would be the flag to preserve full yuv input
[23:30:54 CET] <nevcairiel> assuming your image was not subsampled in the first place, of course
[23:31:46 CET] <nevcairiel> actually that one is for rgb to yuv
[23:31:51 CET] <nevcairiel> the _int one is for yuv to rgb
[23:31:53 CET] <nevcairiel> its all dark magic
[23:32:15 CET] <nevcairiel> why it would ignore input data is beyond me
[23:32:18 CET] <nevcairiel> by default even
[23:33:45 CET] <ubitux> yeah that's the flag i mentioned
[23:34:05 CET] <ubitux> and the one i'll probably use
[23:34:36 CET] <ubitux> the thing is, output are still different with different interpolation
[23:34:39 CET] <ubitux> even with that flag
[23:34:46 CET] <ubitux> so yeah it fixes my bgra/rgba mismatch
[23:34:52 CET] <nevcairiel> your input is 444?
[23:34:56 CET] <ubitux> but i'm not sure what interpolation i'm supposed to pick
[23:35:07 CET] <ubitux> yuvj440p
[23:35:09 CET] <ubitux> (jpg)
[23:35:15 CET] <nevcairiel> well rgb is always 444
[23:35:19 CET] <nevcairiel> so that needs some interpolation
[23:35:33 CET] <ubitux> mmh ok i see
[23:35:37 CET] <ubitux> makes sense
[23:35:47 CET] <nevcairiel> how does 440 look again
[23:35:52 CET] <nevcairiel> half height i think?
[23:35:53 CET] <BtbN> rgb420 when?
[23:36:12 CET] <BtbN> who needs green and blue at full res anyway
[23:36:14 CET] <michaelni> ubitux, differences between rgba/bgra id say qualify as a bug or at least unintended
[23:36:34 CET] <ubitux> i guess you want a repro case / ticket?
[23:36:57 CET] <michaelni> i want a patch :)
[23:37:09 CET] <ubitux> it's not yet xmas
[23:37:13 CET] <ubitux> ;)
[23:37:22 CET] <michaelni> np, i can wait ;)
[23:37:54 CET] <nevcairiel> a tiny fix patch is all we get for xmas?
[23:37:59 CET] Action: michaelni has too many bugs to look into :(
[23:38:01 CET] <nevcairiel> I want a better sws with code i can actually understand
[23:40:26 CET] Action: jamrial waves at ubitux
[23:42:58 CET] Action: ubitux waves back
[00:00:00 CET] --- Thu Dec  6 2018