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

[burek]

[10:04:03 CET] <cone-244> ffmpeg 03Nicolas George 07master:bec8ea20c88e: lavfi/framequeue: avoid empty structs.
[13:32:34 CET] <cone-244> ffmpeg 03Paul B Mahol 07master:6d09d6edbc46: avcodec/magicyuv: add 10 bit support
[15:38:48 CET] <durandal_1707> michaelni: could you please review pixlet patch?
[17:08:26 CET] <durandal_1707> michaelni: post-processing can't be done before afaik
[17:19:15 CET] <michaelni> it can be added durig the last filter iteration but would need a seperate codepath, it maybe can be added to all low freq coeffs (fewer) bt that may affect precission
[17:20:49 CET] <michaelni> hmm, i see there are av_clip_int16() in there, so its probably not possible to add it to low stuff
[18:10:21 CET] <durandal_1707> BBB: have you found solution to that wmavoice issue?
[18:10:44 CET] <BBB> theres two issues, one is wmapro-in-wmavoice, the other is that were reading the bitstream twice
[18:10:47 CET] <BBB> which one do you mean?
[18:15:59 CET] <durandal_1707> both :)
[18:21:48 CET] <cone-506> ffmpeg 03Thomas Turner 07master:e303e3d4b972: avutil: Improved test coverage for avstring.c
[18:23:48 CET] <BBB> durandal_1707: so, the bitstream reading is relatively simple, I have a hack locally and am trying to make it pretty
[18:24:20 CET] <BBB> durandal_1707: the wmapro in wmavoice I dont remember exactly how it works, and what I tried from memory didnt give me anything audible, so Im currently looking back at the REed code to see if I can get any information on how its supposed to work
[18:31:59 CET] <durandal_1707> BBB: BTW I have strange gamma and contrast issue with pixlet? sounds familiar with wavelets?
[18:32:35 CET] <BBB> screenshot?
[18:34:27 CET] <durandal_1707> basically white is gray
[18:34:56 CET] <durandal_1707> black is black
[18:35:31 CET] <durandal_1707> perhaps they use log something colors
[18:35:42 CET] <kierank> clip it into limited range perhaps
[18:37:11 CET] <BBB> yeah, clipping plus adding base may help
[18:37:24 CET] <BBB> like, everything += 16
[18:53:34 CET] <durandal_1707> I do that already...
[19:02:45 CET] <kierank> into limited range?
[19:02:49 CET] <kierank> or just uint16_t
[20:26:48 CET] <durandal_1707> kierank: i get 32767 as max value
[20:57:32 CET] <BBB> durandal_1707: got a screenshot?
[21:00:23 CET] <BBB> durandal_17: got a screenshot?
[21:00:48 CET] <durandal_17> BBB: i can give you screenshot
[21:01:02 CET] <durandal_17> yuv is basically capped to 32767
[21:01:27 CET] <BBB> ehm
[21:01:32 CET] <BBB> thats very strange
[21:01:35 CET] <BBB> why 32767?
[21:01:39 CET] <BBB> 16bit is 0-65535
[21:01:48 CET] <BBB> is this a 15bit format? or is it signed? or whats going on
[21:02:02 CET] <durandal_17> its apple, everything is possible
[21:02:08 CET] <BBB> that wasnt my question
[21:02:11 CET] <Compn> big endian ? :P
[21:02:11 CET] <BBB> whats the format?
[21:02:19 CET] <durandal_17> yuv422 for sure
[21:02:25 CET] <BBB> thats 8bit
[21:02:30 CET] <BBB> where does the 32767 limit come from?
[21:02:42 CET] <durandal_17> this one uses 16bit coefficients
[21:02:58 CET] <kierank> I think you should use yuv420p10
[21:03:00 CET] <durandal_17> raw 16bit topleft pixel is stored uncompressed
[21:03:06 CET] <kierank> oh
[21:03:07 CET] <kierank> hmm
[21:03:20 CET] <BBB> increase resolution of the coefficients by 1 bit?
[21:03:39 CET] <BBB> (or use a different scalign factor in the wavelet)
[21:04:00 CET] <BBB> also note that the depth of the coefficients doesnt mean much about the output bitdepth
[21:04:08 CET] <BBB> like, you can easily output 8bpc vp9 into 10bits
[21:04:16 CET] <BBB> prores can also be output in a number of bitdepths
[21:04:22 CET] <BBB> youre just scaling the idct to the output bitdepth
[21:04:48 CET] <BBB> the fact that we output prores in 10bit (or is it 12?) is just an implementation detail, itd be trivial to rewrite it to output something else
[21:05:28 CET] <nevcairiel> the interesting questions would be either (a) whats the intended output bitdepth? or if we dont know that (b) what kind of precision do you actually get out of it realistically, no sense scaling it up much if you just end up with more noise
[21:05:38 CET] <BBB> ++
[21:08:22 CET] <durandal_17> here is shot: https://transfer.sh/LWiR1/mpv-shot0001.png
[21:08:36 CET] <durandal_17> top is pixlet, bottom is original
[21:16:29 CET] <BBB> your chroma dna luma are both scaled one bit too low or so
[21:17:02 CET] <BBB> the blackpoint of luma and graypoint of both chroma channels are fine
[21:17:16 CET] <BBB> but the whitepoint of luma and the black/white are scaled too closely to the origin point
[21:17:36 CET] <BBB> so Id just scale the coefficients by some factor (probably sqrt(2) or 2) before the wavelet
[21:17:51 CET] <BBB> (note how sqrt(2) is often the dc scaling factor in idcts, so this is not totally abnormal)
[21:50:22 CET] <durandal_17> BBB: i get artifacts if i multiply coeffs with 2 or sqrt(2)
[21:53:12 CET] <BBB> not surprisingly& is it possible you need a quantization table where not all coeffs use the same quantizer?
[21:58:14 CET] <durandal_17> i think I only need to change gamma
[22:15:00 CET] <BBB> is it true that decoders cant use AV_CODEC_CAP_DELAY and AV_CODEC_CAP_SUBFRAMES at the same time?
[22:16:31 CET] <wm4> what the hell is CAP_SUBFRAMES?
[22:18:53 CET] <nevcairiel> for audio codecs that can decode multiple audio frames from one packet
[22:22:33 CET] <BBB> my decoder does not appear to be called with NULL trailnig packets if I set CAP_DELAY
[22:22:44 CET] <BBB> do I need to do something else for it to be called with NULL packets?
[22:22:58 CET] <BBB> or is DELAY only implemented for video?
[22:23:08 CET] <nevcairiel> delay works for audio too
[22:24:12 CET] <nevcairiel> note that you get called w ith a packet with data=NULL, not a null packet
[22:27:13 CET] <BBB> oh right
[22:27:20 CET] <atomnuker> BBB: is that for the wma decoder or some other decoder?
[22:30:46 CET] <BBB> wma voice
[22:30:53 CET] <BBB> ah ok now it works
[22:31:09 CET] <BBB> ok I think if I do these two together, I get the same output as before without the bitstream checking
[22:31:19 CET] <BBB> also some warnings go away
[22:31:25 CET] <BBB> so thats probably a good thing
[22:50:30 CET] <BBB> patches sent to ML
[22:50:38 CET] <BBB> the first oen of my original set also still applies
[22:50:42 CET] <BBB> so its three patches in total
[22:51:16 CET] <BBB> Im still working out whats going on with the samples sent in that trac ticket, but Im not convinced yet that its actually wmapro
[22:51:31 CET] <BBB> like, with my fixed up bitstream parsing, all the warnings about wmapro in wmavoice go away
[22:51:51 CET] <BBB> (it still doesnt decode at all, but that may be something else, maybe tone related or whatever)
[23:13:00 CET] <durandal_17> nice
[23:14:28 CET] <atomnuker> why the need for CAP_SUBFRAMES though, opus can have multiple frames in a packet but it'll just spit out all the samples concatenated
[23:16:22 CET] <nevcairiel> some decoders decide not to do that and only decode the first frame and have the decode function called again
[23:23:36 CET] <BBB> re-sent it so its a full set and splits cosmetic stuff from other stuff
[23:23:41 CET] <BBB> this should be rather straightforward now
[23:24:18 CET] <BBB> atomnuker: implementation detail& we could indeed output everything concatenated, but this is easier for the way the decoder was implemented
[23:24:37 CET] <BBB> atomnuker: basically what nevcariel says; it can be changed but really why would you do that
[23:24:47 CET] <nevcairiel> historically some decoders also had trouble finding frame boundaries without decoding
[23:24:48 CET] <BBB> atomnuker: its not like performance matters for a shitty format like wmavoice ;)
[23:24:50 CET] <nevcairiel> so they use this
[23:25:07 CET] <nevcairiel> in case they get half-a-frame
[23:25:55 CET] <BBB> now that the decoder isnt crazy anymore
[23:26:11 CET] <BBB> maybe its fun to figure out why that trac thing doesnt decode, I honestly am a little confused...
[23:26:51 CET] <atomnuker> BBB: yeah, but really who uses wma voice?
[23:27:01 CET] <BBB> I know right
[23:29:48 CET] <atomnuker> no, I mean who uses wma voice?
[23:30:03 CET] <atomnuker> radio stations?
[23:30:29 CET] <BBB> I think nobody
[23:31:02 CET] <durandal_17> just to fill all tickets with odd files nobody ever use
[23:31:23 CET] <BBB> I think its a few radio stations& maybe some other things Ive seen *cough*
[23:31:29 CET] <BBB> probably some other stuff
[23:31:30 CET] <BBB> dunno
[23:35:04 CET] <llogan> how does he find these oddball samples 'n bugs?
[23:36:31 CET] <durandal_17> llogan: encoding them, he have nothing else to do...
[23:38:59 CET] <llogan> he has found many
[23:41:07 CET] <BBB> hm yeah something causes the samples to become nan
[23:41:23 CET] <BBB> and since the samples are used as history for the filter, it means everything is nan
[00:00:00 CET] --- Wed Dec 21 2016