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

[burek]

[00:01:39 CET] <paolo_> I'm feeding ffserver with a native mjpeg stream from a webcamera:   ffmpeg -f video4linux2 -input_format mjpeg -video_size 640x480 -i /dev/video0 -c:v copy http://localhost:8090/feedSistema.ffm   <---- unfortunately, it forces a re-encoding from mjpeg to mjpeg. I don't understand why: s it a bug?  If I replace the http url of ffserver with "myfile.avi" it works correctly and doesn't re-encode the input stream.... 
[00:01:40 CET] <paolo_> where can be the issue ?
[00:16:35 CET] <Compn> possibly you need to fix ffserver config
[00:16:39 CET] <Compn> but this is an #ffmpeg question
[00:16:49 CET] <Compn> this channel #ffmpeg-devel is for development...
[00:22:40 CET] <paolo_> Compn: already asked there, a member of the channel answered:  [23:56] <furq> i don't think there's a way to not transcode with ffserver
[00:23:30 CET] <paolo_> [23:56] <furq> also ffserver is bad and unmaintained
[00:23:30 CET] <paolo_> is i true?
[00:26:57 CET] <JEEB> yes
[00:27:07 CET] <JEEB> there is barely any real maintainership for ffserver
[00:27:15 CET] <JEEB> and almost nobody knows how to use it
[00:27:36 CET] <JEEB> for most use cases there are much better alternatives
[00:33:14 CET] <Compn> oh thats what 
[00:33:50 CET] <faLUCE> ?
[00:36:59 CET] <Compn> i think what you want is for ffmpeg to save to a file
[00:37:35 CET] <Compn> then serve it http with a real web server like lighttpd
[00:38:08 CET] <Compn> that way ffmpeg copies it to hd directly
[00:38:34 CET] <Compn> faLUCE  ^^
[00:39:01 CET] <faLUCE> Compn: no, I don't think it's a good solution
[00:39:16 CET] <faLUCE> a better solution would be to pipe vlc from ffmpeg
[00:39:41 CET] <faLUCE>    ffmpeg -i livestream -f asf - | vlc -  <---- pipe to vlc.  But I need to pipe two instances of vlc with one instance of ffmpeg, which does two different encoding of the same input.... what is the syntax?
[00:39:59 CET] <faLUCE> vlc will be the streamer
[02:52:31 CET] <j-b> kierank: you are a god.
[02:52:52 CET] <j-b> Sesse: what are those?
[02:58:21 CET] <wm4> what happened that he is god
[07:25:14 CET] <atomnuker> huuuuh, av_mod_uintp2() has optimizations, and I've always used & ((1 << bits) - 1) in all my code
[13:05:56 CET] <cone-033> ffmpeg 03softworkz 07master:9488032e10b7: libavformat/avio: Add avio_get_dyn_buf function
[13:51:13 CET] <atomnuker> bofh_: are you going to try to SIMD the fft15 function?
[14:25:08 CET] <bofh_> atomnuker: I just finished the second part (the rotates) right now. Testing and posting.
[14:25:53 CET] <atomnuker> so you've done the 5-point FFTs?
[14:26:06 CET] <atomnuker> (did you implement those as a macro? you should)
[14:26:07 CET] <cone-033> ffmpeg 03Clément BSsch 07master:27627c281e66: lavfi/selectivecolor: add a link to algorithm explanations
[14:26:17 CET] <ubitux> https://news.ycombinator.com/item?id=13343990
[14:26:26 CET] <ubitux> if interested in an article about the filter ^
[14:26:27 CET] <atomnuker> bofh_: no point in triplicating code
[14:27:03 CET] <bofh_> atomnuker: ooh, good point. no, I never got around to the transforms at the top, I wanted to do the rotations at the bottom first and then look at imdct15's pre-twiddle.
[14:27:22 CET] <atomnuker> I'd start with the 5-point FFTs
[14:27:32 CET] <bofh_> this was largely based on what perf-events told me was bad (i.e. cpu cycles spent, L1d cache misses from)
[14:28:00 CET] <bofh_> yeah those would be the simplest.
[14:28:05 CET] <atomnuker> bofh_: also feel free to modify the sign/twiddles if you're more comfortable
[14:28:18 CET] <atomnuker> btw I did get a forward mdct to run
[14:28:45 CET] <atomnuker> but I still have a few bugs in the encoder and some junk to remove
[14:29:25 CET] <bofh_> oh, so it's easy to base an inverse MDCT on a forward FFT, my local tree does it for the ffmpeg mdct. All you need to do is rearrange soem instructions in the post-rotate. If you are okay with an xorps of overhead, you can then actually use the same postrotate for both forward MDCT and inverse half-MDCT.
[14:29:41 CET] <bofh_> encoder? as in CELT/libopus?
[14:29:49 CET] <atomnuker> and also pull a scaling factor out of my ass because we use different twiddles and for some reason 68.5 works well but I don't like it because it's not related to anything
[14:30:17 CET] <atomnuker> bofh_: no, I wrote my own encoder
[14:30:23 CET] <atomnuker> without using any libopus code
[14:30:29 CET] <atomnuker> from scratch
[14:30:39 CET] <bofh_> atomnuker: oh, an independent CELT encoder effort
[14:30:45 CET] <bofh_> iiiiiiiiiiiinteresting.
[14:31:01 CET] <atomnuker> but I need fast transforms
[14:31:31 CET] <atomnuker> like really fast 120 sample transforms, because I'll be doing analysis that way
[14:31:52 CET] <bofh_> I can't imagine how one would do that without looking at the code... it feels like the CELT psymodel differs a lot in details, and the Opus folk love providing those in code form only (in snippets of code in the RFCs and docs)
[14:31:57 CET] <atomnuker> before stitiching the samples into 1x whatever framesize my psychoacoustic system decides
[14:32:01 CET] <bofh_> 120-sample DCT or 120-sample FFT?
[14:32:10 CET] <bofh_> is this for the pitch lookahead search?
[14:33:12 CET] <atomnuker> bofh_: DCT-IVs or maybe mdcts, depends on how stable things look at 2.5ms/1.25ms
[14:33:30 CET] <atomnuker> no pitch lookahead, no pitch postfilter support yet
[14:34:10 CET] <atomnuker> bofh_: not really, opus doesn't use psychoacoustics that much at all
[14:34:35 CET] <atomnuker> did you notice there's no way to reduce the bits in a single band?
[14:35:00 CET] <atomnuker> so there's nothing really adaptive in libopus in terms of what goes in a band
[14:35:10 CET] <atomnuker> apart from is band tonal -> yes -> boost
[14:35:14 CET] <bofh_> so, I don't mean for the postfilter, I mean the pitch delay coefficients used to make the short block offset of the transform not suck
[14:35:43 CET] <atomnuker> bofh_: what are you talking about?
[14:35:47 CET] <atomnuker> there's a preemphasis filter
[14:36:05 CET] <atomnuker> there's a pitch frequency emphasis filter
[14:36:35 CET] <atomnuker> then there's coarse energy, bit alloc, fine energy, bands, anticollapse bit, final energy and that's it
[14:37:02 CET] <bofh_> fine energy is what I'm talking about
[14:37:23 CET] <atomnuker> what about it, you either do it properly or you don't
[14:37:46 CET] <atomnuker> you don't, energy's slightly off and your X band appears more boosted
[14:37:57 CET] <atomnuker> (which is what I was fighting to fix a few hours ago)
[14:39:41 CET] <bofh_> (also that observation doesn't surprise me at all, given that iirc the founding concept behind CELT is that total energy is always preserved in each critical band, even at the cost of spectral details)
[14:40:06 CET] <atomnuker> that's what makes it so good at low bitrates
[14:40:15 CET] <atomnuker> you only need the energy to make something comprehensible
[14:40:50 CET] <atomnuker> and even transient-y music sounds okay at 15kbps full-bandwidth at 15 kbps
[14:41:46 CET] <atomnuker> but really no point in messing with the energy since it's not coupled to the quality of a band
[14:42:00 CET] <atomnuker> this isn't scalefactor aac/mp3 territory
[14:42:21 CET] <bofh_> (yeah, I wonder if there was a sane way to do a transform blockswitching-type thing. like the reason for the length of the CELT transform is low delay, I don't think it's been shown to be good or bad psychoacoustically, and it'd be interesting to find out...)
[14:42:58 CET] <atomnuker> bofh_: it'll mainly help at higher bitrates
[14:43:00 CET] <bofh_> on that note, I'm curious if one could use this to squeeze a bit more coding efficiency out of low-bitrate AAC.
[14:43:16 CET] <atomnuker> nope, AAC has 1 framesize
[14:43:23 CET] <atomnuker> and a transient flag
[14:43:56 CET] <atomnuker> opus is hugely better with the treatment of transients
[14:44:06 CET] <atomnuker> it'll rearrange the coefficients to be linear
[14:44:10 CET] <atomnuker> during quantization
[14:44:11 CET] <bofh_> well I was more talking about having the psymodel preprocess the input audio before it hits the quantizer so the quantizer will distort scalefactors less because the spectral coefficients compress better.
[14:44:16 CET] <bofh_> that sort of stuff.
[14:44:44 CET] <atomnuker> bofh_: we kinda do that already
[14:44:51 CET] <atomnuker> in AAC
[14:45:01 CET] <bofh_> I'm not expecting it to be better at transients ever, that won't happen. I'm just curious if one can make it degrade a bit more gracefully.
[14:45:44 CET] <atomnuker> bofh_: nope, I know what you're thinking of and it's what I thought long and hard on before I wrote out my plan for the psychoacoustic system
[14:46:05 CET] <bofh_> ahh
[14:46:28 CET] <bofh_> you mean current ffmpeg-aacenc, or your opus encoder?
[14:46:28 CET] <atomnuker> anyway, in AAC we apply an LPC on the coefficients
[14:46:45 CET] <atomnuker> (they're both mine, the former a bit less but still mostly mine)
[14:47:03 CET] <bofh_> (heh, true)
[14:47:22 CET] <atomnuker> we then transmit the LPC coefficients for the decoder to apply the inverse
[14:47:23 CET] <bofh_> yeah, I'm familiar with that, I'm just curious if it can be improved upon.
[14:47:37 CET] <bofh_> I know how TNS works :p
[14:47:45 CET] <atomnuker> not really, it helped slightly with high frequency non-transients
[14:48:07 CET] <atomnuker> but you're better of just transienting because masking
[14:49:12 CET] <bofh_> Errm... wouldn't a loud transient be something that wouldn't really be masked?
[14:49:52 CET] <bofh_> or am I understanding you backwards?
[14:50:13 CET] <atomnuker> no, it's a source of masking, it'll mask the lower frequency sounds down to a certain point
[14:50:52 CET] <bofh_> ohh.
[14:50:56 CET] <atomnuker> and you'll want to make it sound loud, consistent for its duration to be able to mask
[14:51:24 CET] <atomnuker> and it's even better if it's non tonal
[14:51:54 CET] <atomnuker> since PNS works really really well with non tonal high frequency transients spanning most of the high frequency bands
[14:52:00 CET] <atomnuker> e.g. a cymbal
[14:52:40 CET] <atomnuker> it does not, however, work for synths, so we have very complicated and convoluted conditions with which to decide when to enable PNS
[14:52:57 CET] <atomnuker> with the tipping points being lambda dependent
[14:53:03 CET] <bofh_> honestly I'd better describe a cymbal as wideband non-tonal transients, it just so happens it's sufficiently wideband that you can replace the highband ones with randomness and your ear won't notice much.
[14:53:32 CET] <atomnuker> that's exactly what I said, it's non tonal
[14:53:53 CET] <bofh_> okay, yes.
[14:54:11 CET] <atomnuker> bofh_: also CELT has no lambda
[14:54:18 CET] <bofh_> huh
[14:54:58 CET] <atomnuker> well, libopus has no lambda
[14:55:04 CET] <atomnuker> libcelt probably doesn't either
[14:55:35 CET] <atomnuker> I'll bring one back
[14:55:48 CET] <atomnuker> kicking and screaming I'll have a lambda value
[14:55:52 CET] <JEEB> \o/
[14:56:03 CET] <atomnuker> it's a small price to pay for having true VBR support in opus
[14:56:52 CET] <atomnuker> it'll be a cludge but there shall be a global how-well-am-i-doing lambda value
[14:58:01 CET] <atomnuker> which will directly affect everything
[14:58:24 CET] <atomnuker> and IS will not just be some function of bitrate, but of distortion and of rate as well
[14:58:29 CET] <bofh_> doesn't CELT as currently implemented meet bitrate constraints solely by varying the parameters for the adaptive CELP codebook? (the one that's referred to as "innovation data", inexplicably)
[14:59:00 CET] <atomnuker> not sure which celt you're looking at but opus won't do that
[14:59:58 CET] <atomnuker> quantization is "here's how many bits you have, if above 32 split, else convert to pulses, feed that to the PVQ search, output them, feed them to icwrs, encode the index"
[15:00:42 CET] <atomnuker> (also do a rotation for spreads non equal to NONE after pvq search)
[15:01:00 CET] <atomnuker> s/after/before
[15:02:58 CET] <atomnuker> if the division has a remnant, put that in a reservoir where bands can steal from to make themselves even
[15:03:32 CET] <atomnuker> if that has a remnant use it to make the energy values more accurate (final energy quantization)
[15:04:19 CET] <atomnuker> which if it happens means you're wasting bits and you shouldn't be using such a high bit count for the frame
[15:04:55 CET] <atomnuker> a concept which has a direct mapping to what a lambda value should regulate not to happen
[15:06:21 CET] <atomnuker> (icwrs converts the pulses to an index value in the huge PVQ tables, hence the 32 bit limit per band to not make the tables humongous)
[15:06:43 CET] <atomnuker> there was an experiment with 64 bits but it didn't work out
[15:06:54 CET] <atomnuker> and besides band splitting is so ridiculously powerful
[15:07:17 CET] <atomnuker> since during quantization on a transient your coefficients will get rearranged
[15:07:58 CET] <atomnuker> so from f1,f2,f3,f4...f8,f1,f2,f3...f8 to f1,f1,f1,f1....f2,f2,f2,f2
[15:08:02 CET] <atomnuker> in a single band
[15:08:08 CET] <atomnuker> and since you split the bands
[15:08:19 CET] <atomnuker> you also control how many bits to fall into each band
[15:08:27 CET] <bofh_> https://git.xiph.org/?p=opus.git;a=blob;f=celt/celt_encoder.c;h=77de1b6ea5b9b42b60eb61f91e734937942a8289;hb=HEAD#l2052 onwards is what I was referring to
[15:08:29 CET] <atomnuker> that's what the theta value does
[15:08:49 CET] <atomnuker> so you can control how many bits you spend on transients _as_it_is_happening_
[15:09:02 CET] <bofh_> oh, so that's what the ICWRS is for.
[15:09:03 CET] <atomnuker> that's beyond huge
[15:09:17 CET] <bofh_> uh. wow.
[15:09:24 CET] <atomnuker> yah, wow
[15:10:00 CET] <atomnuker> so transients are almost never a bad choice since you can merge bands in a frame using TF switching
[15:10:08 CET] <atomnuker> (at the cost of extra leakage)
[15:10:34 CET] <bofh_> oh.
[15:11:23 CET] <atomnuker> but you'll merge the calm bands in a transient to spend more bits on the transient which will mask
[15:12:03 CET] <atomnuker> and you can still go further and apply the inverse to bands during all frames in a transient
[15:12:17 CET] <atomnuker> and get increased time resolution
[15:12:33 CET] <atomnuker> _for_2.5_ms_frames
[15:12:47 CET] <bofh_> so it turns out doing more coding in the time domain at key moments in your song is far more useful that I'dve anticipated. by, like, a lot.
[15:12:54 CET] <bofh_> s/song/audio clip/
[15:13:13 CET] <bofh_> jesus
[15:13:20 CET] <atomnuker> moderation is the key however
[15:13:33 CET] <atomnuker> signalling those things isn't free
[15:13:54 CET] <atomnuker> band boosts cost alot, TF switching isn't that cheap
[15:13:59 CET] <atomnuker> and its rather inflexible
[15:14:23 CET] <atomnuker> since per each transform size per whether the transient is on you have 2 choices
[15:14:56 CET] <atomnuker> and they're either: merge in time domain, merge in frequency domain or (just once for a 960 trasnform) do nothing
[15:15:12 CET] <atomnuker> and how much you merge is hardcoded in the table
[15:15:25 CET] <bofh_> how much do band boosts cost signal-entropy wise? I wouldn't expect that to be many bits per boost.
[15:15:44 CET] <atomnuker> 6 bits for the first band boost, 1 for each subsequent
[15:15:52 CET] <atomnuker> +2 for each new band
[15:15:57 CET] <atomnuker> +1 for any boost on that one
[15:16:01 CET] <bofh_> 1 bit for each subsequent does not sound like much at all. I was guessing two.
[15:16:25 CET] <atomnuker> it can be alot
[15:16:34 CET] <atomnuker> especially if your frames are small
[15:16:41 CET] <bofh_> (sorry, I've read the paper on CELT but haven't looked too much at implementation details until a few months ago, then last week :P)
[15:16:55 CET] <bofh_> well I guess it's a lot if you're working at <10kbit bitrates
[15:17:15 CET] <atomnuker> no, as in trasnsform sizes
[15:17:35 CET] <atomnuker> the cost of coding the header, tf switching, pitch filter
[15:17:47 CET] <atomnuker> that's all constant
[15:17:55 CET] <atomnuker> so as your transform size reduces and you code less sound per packet
[15:18:09 CET] <atomnuker> your packet frequency increases
[15:18:42 CET] <atomnuker> and your bitrate's fixed too so you still get the same size shared amongst all packets
[15:19:02 CET] <atomnuker> which need to have a header and at least a coarse energy to be able to sound like anything
[15:19:29 CET] <atomnuker> so that makes flexible frame sizes only an option at higher bitrates
[15:19:33 CET] <bofh_> this sounds like you'd quickly reach a point where your transform is too short to encode tonal information, and the signal would start rapidly sounding awful unless you reset that process. but I can't imagine doing that without audible artifacts either...
[15:19:41 CET] <bofh_> (what am I missing?)
[15:20:03 CET] <atomnuker> the anticollapse bit, as a first resort
[15:20:18 CET] <atomnuker> and the do_not_skip flags, as a last resort
[15:21:04 CET] <atomnuker> the do_not_skip flags (per band starting from top to bottom) (they're not mentioned in the docs and the ffmpeg decoder refers to them as such) is 1 bit per band
[15:21:14 CET] <atomnuker> until you signal a 1
[15:21:32 CET] <atomnuker> in which case all bands with a zero signalled are skipped
[15:21:40 CET] <atomnuker> you cannot always code this flag
[15:22:02 CET] <atomnuker> if there are not enough bits in a band to make it not sound like junk, you'll be able to signal it
[15:22:23 CET] <atomnuker> if you do, each time you signal a zero the bits for that band are allocated to other bands
[15:22:29 CET] <atomnuker> and the band will be silent
[15:22:41 CET] <bofh_> so what do you do in that scenario on the decoder? silence or PRNG matched to the band energy?
[15:22:42 CET] <atomnuker> unless the spread has been set to aggressive
[15:22:50 CET] <bofh_> ah. the first.
[15:22:55 CET] <atomnuker> in which case it'll insert noise
[15:23:13 CET] <atomnuker> and that's the only case in which it will insert noise
[15:23:43 CET] <atomnuker> which is thankfully free and unlike AAC will have the exact energy of the coefficients it replaced
[15:23:58 CET] <atomnuker> (damn log2 horrid limited crappy PNS quantiztion)
[15:24:21 CET] <bofh_> ugh, don't remind me.
[15:24:24 CET] <atomnuker> "0 - silence" "1 - I hear noise" "10 - MY EARS"
[15:24:40 CET] <cone-033> ffmpeg 03softworkz 07master:20e8be0c20c7: avformat/matroskaenc: Regression fix for invalid MKV headers
[15:24:47 CET] <atomnuker> 255 - HDR EXTENDED GAMMA CURVE MLG PRO NOSCOPE 360
[15:27:06 CET] <atomnuker> nevertheless it is still a useful tool
[15:27:13 CET] <atomnuker> I have a half written blog post about it
[15:28:08 CET] <atomnuker> ffaac is fascinatingly good at using it especially for low bitrate 48kbps encodings
[15:28:49 CET] <atomnuker> fdkaac won't touch PNS nor TNS more than a few frames in 5 MINUTES
[15:29:44 CET] <atomnuker> bofh_: yeah, the VBR in opus is built in such a way harpsichords will result in 2x the specified bitrate
[15:33:55 CET] <cone-033> ffmpeg 03foo86 07master:000638431ccc: avcodec/dca: add support for 20-bit XLL
[15:35:54 CET] <atomnuker> initially I planned to use power of two transforms and interpolating the values to a 2.5ms grid
[15:36:01 CET] <atomnuker> (for the analysis)
[15:36:17 CET] <jamrial> what uses 20-bit dts xll anyway?
[15:36:45 CET] <jamrial> dts-in-wav seems to use 14-bit dts core
[15:36:47 CET] <jamrial> what a weird format
[15:37:13 CET] <atomnuker> then I looked at some odd back and forth transforms (gabor, s-transform, sttf, all used in geology) but I decided to just stick with what I had
[15:38:33 CET] <atomnuker> I was planning to modify the coefficients in the transforms to then convert back to hopefully easier to code samples and then back through the opus FFT
[15:39:27 CET] <atomnuker> but it's just absolutely not worth it, won't lead to any gains and on the scale of crazy things it's close to monty's "prime frame sized non-lapped FFT" codec
[15:39:55 CET] <atomnuker> (which considering how slow DFT is probably won't be realtime on like 90% of modern machines)
[15:47:32 CET] <atomnuker> ubitux: that seems insanely powerful, especially for color correction
[15:48:57 CET] <ubitux> yes it's used a lot actually
[15:49:29 CET] <ubitux> i have designers friends who love this tool
[16:23:53 CET] <ubitux> https://www.youtube.com/watch?v=E1cUata2bVg
[16:23:56 CET] <ubitux> we need a source filter like this
[16:24:05 CET] <ubitux> to drive codecs nuts
[16:31:54 CET] <atomnuker> we have a dca encoder?
[16:32:40 CET] <atomnuker> ...WHICH USES ITS OWN FFT FUNCTION?
[16:33:20 CET] <RiCON> ubitux: sure drives my eyes nuts
[16:35:01 CET] <atomnuker> durandal_1707: why does dcaenc use its own mdct?
[16:35:41 CET] <atomnuker> (which it mistakenly calls fft)
[16:36:13 CET] <atomnuker> oh its an integer mdct
[16:36:23 CET] <atomnuker> typedef struct { int32_t re; int32_t im; } cplx32;
[16:36:50 CET] <atomnuker> still, our mdct is templated and should work with integers
[16:38:07 CET] <durandal_1707> patch needed
[17:05:50 CET] <Sesse> ubitux: fwiw, through the cracks is so intense in bitrate that it causes intel quicksync to create invalid h264
[17:07:33 CET] <JEEB> ubitux: yeah demos like that are great :D
[17:16:05 CET] <Compn> https://github.com/petersn/video-compression-lab/blob/master/lab.html
[17:16:34 CET] <Compn> anyone seen this mit class lab on ffmpeg?  neato
[17:16:58 CET] <Compn> actually kind of explains how to add decoder to ffmpeg even
[17:17:05 CET] <Compn> michaelni ^^^
[17:17:23 CET] <JEEB> I was thinking of handling such a course at cs.helsinki.fi like three years ago, but then I got into $dayjob
[17:18:50 CET] <Compn> wonder if we could get professor multimedia mike to help polish the course... encourage new developers.... 
[17:27:28 CET] <cone-033> ffmpeg 03Paul B Mahol 07master:fd010406c039: avformat/riff: extend MagicYUV fourcc list
[17:32:59 CET] <Compn> j-b : is there a vlc uni course ? ^^
[17:36:46 CET] <atomnuker> 35db psnr across all frames for such a huge compression would be difficult
[17:37:30 CET] <atomnuker> unless you could copy code or beter yet init an avcodeccontext for h264 and just wrap around encoding that :)
[17:56:50 CET] <jamrial> trac wars
[18:19:03 CET] <KGB> [13FFV1] 15dericed closed pull request #29: WIP narrative explanation on Slice (06master...06WIP-adding-narratives) 02https://git.io/v1175
[18:27:58 CET] <Sesse> kierank: I've always got the alpha for shq1/shq3/shq5 going (in my non-ffmpeg) decoder now... the bitstream reading is correct now, but there's something in either the actual levels or in my handling of the prediction
[18:30:42 CET] <durandal_1707> what is different?
[18:33:51 CET] <KGB> [13FFV1] 15dericed opened pull request #37: add NumBytes definition (06master...06numbytes) 02https://git.io/vMCGy
[18:36:10 CET] <durandal_1707> Compn: when you gonna add ffqdmc decoder to MPlayer?
[18:36:25 CET] <KGB> [13FFV1] 15dericed opened pull request #38: more verbose descriptions of assignment operators (06master...06assignments) 02https://git.io/vMCG7
[18:41:56 CET] <kierank> Sesse: have you tried skipping the transform
[18:42:04 CET] <Sesse> kierank: there's no transform
[18:42:07 CET] <kierank> ah
[18:42:08 CET] <kierank> ok
[18:42:12 CET] <Sesse> nor zigzag
[18:42:19 CET] <kierank> good
[18:42:25 CET] <Sesse> there is for shq7/shq9
[18:42:28 CET] <Sesse> prediction is just sub from previous row
[18:42:31 CET] <Sesse> afaics
[18:42:33 CET] <Sesse> still, something is wrong
[18:43:03 CET] <Sesse> the deltas look ok-ish, but when I put it together, it doesn't work
[18:44:55 CET] <kierank> how are you verifying the alpha?
[18:45:36 CET] <kierank> not sure if ffmpeg alpha requires some kind of bias
[18:46:53 CET] <Sesse> visually
[18:47:00 CET] <Sesse> it's not part of ffmpeg yet
[18:47:02 CET] <Sesse> I just write it out as a pnm
[18:47:05 CET] <Sesse> or, pgm
[18:47:41 CET] <kierank> ah
[18:48:09 CET] <Sesse> shq7/shq9 alpha works fine
[18:48:13 CET] <Sesse> that's just encoded exactly as luma
[18:50:23 CET] <KGB> [13FFV1] 15dericed opened pull request #39: add references to introduction (06master...06references-in-intro) 02https://git.io/vMCZz
[18:52:56 CET] <durandal_1707> Sesse: show unpredicted-raw output
[18:53:55 CET] <Sesse> durandal_1707: https://home.samfundet.no/~sesse/shq3_alpha_unpredicted.png
[18:55:53 CET] <durandal_1707> and how alpha plane should look like?
[18:56:02 CET] <Sesse> I don't have a reference
[18:57:07 CET] <Sesse> well, I could decode the shq7 one
[18:57:18 CET] <Sesse> it won't be bit-exact, but look correct
[18:58:28 CET] <durandal_1707> hmm, it uses something block based because left prediction is slow
[18:58:48 CET] <Sesse> https://home.samfundet.no/~sesse/shq7_alpha.png
[18:58:54 CET] <Sesse> yes, it predicts 16 by 16 elements
[18:58:59 CET] <Sesse> in a vector
[18:59:14 CET] <Sesse> from the previously decoded 16-vector
[18:59:38 CET] <Sesse> also across blocks, obviously
[19:01:18 CET] <Sesse> also note that this is interlaced, so there are two independent fields
[19:39:44 CET] <Sesse> fixed
[19:40:15 CET] <Compn> durandal_1707 : added qdmc
[19:40:47 CET] <Sesse> https://home.samfundet.no/~sesse/shq3_alpha_2.png
[19:59:10 CET] <Compn> i put the shq samples in samples/V-codecs/
[19:59:18 CET] <Compn> in case anyone wants to check them
[19:59:26 CET] <Compn> thx to blb for the samples
[20:07:56 CET] <KGB> [13FFV1] 15dericed opened pull request #40: define abs log2 min functions (06master...06define-more-functions) 02https://git.io/vMCWv
[20:11:17 CET] <Compn> i think the shq codec was one of the few that didnt load with mplayer, no matter how hard i tried :\
[20:13:48 CET] <Sesse> how can you try more or less hard :-)
[20:15:50 CET] <Compn> depends on the levels of banging head against keyboard
[20:15:58 CET] <Compn> i've busted a lot of keyboards over the years.
[21:16:06 CET] <durandal_1707> michaelni: could you add joint tables to utvideo?
[21:16:43 CET] <durandal_1707> that's major cpu usage
[21:18:08 CET] <Compn> ... people care about utvideo ?
[21:18:55 CET] <JEEB> yes
[21:19:10 CET] <Compn> says the japanese 
[21:19:18 CET] <Compn> japanese video codec
[21:19:20 CET] <Compn> biased!
[21:19:23 CET] <JEEB> ut video is an OSS thing that has modules for all major things
[21:19:32 CET] <Sesse> the japanese people say oD
[21:19:36 CET] <JEEB> vfw/dshow/mf/QT
[21:20:02 CET] <JEEB> and lavc of course
[21:20:05 CET] Action: Compn never seen utvideo in the wild
[21:20:12 CET] <Compn> sure it exists... somewheres
[21:20:18 CET] <JEEB> it's usually used in editing workflows
[21:20:28 CET] <Compn> anime rips 
[21:20:45 CET] <Compn> or do you mean professional usage ?
[21:20:49 CET] <JEEB> yes
[21:21:05 CET] <JEEB> because it can be used on windows/os x and ffmpeg
[21:21:11 CET] <JEEB> and it is lossless
[21:21:21 CET] <Compn> yeah like most lossless codecs :P
[21:21:44 CET] <JEEB> well, d'oh
[21:22:00 CET] <JEEB> it was a comparison to thkngs like prores etc
[21:22:19 CET] <JEEB> of course those are o9k times more popular
[21:22:56 CET] <JEEB> but you can just stop making bad anime fuckery jokes when you can just look at doom9 and see that people are using it
[21:23:40 CET] <JEEB> a) it is lossless and b) umezawa made modules for all major media frameworks
[21:27:03 CET] <JEEB> Compn: if ffv1 had similar amount of modules to be used, it would most likely have gotten used instead. and I see possibly that the standardization will help with it
[21:28:58 CET] <Compn> i'm just trolling man
[21:29:02 CET] <Compn> sorry :D
[21:32:53 CET] <Sesse> #define MAX_RUN    64
[21:32:53 CET] <Sesse> ooh, that' sfun
[21:33:00 CET] <Sesse> given that for me, MAX_RUN is 128 and MAX_LEVEL is 256 :-P
[21:36:17 CET] <kierank> Sesse: I am not sure what that does
[21:36:26 CET] <kierank> certainly for cineform I had way larger runs and levels
[21:36:28 CET] <Sesse> kierank: for the 2D VLCs
[21:36:34 CET] <Sesse> it's one VLC that gives you both
[21:36:44 CET] <Sesse> but I doubt anyone cares much about SHQ1/3/5 performance, so I can just split them
[21:37:03 CET] <kierank> ah that's what I did
[21:41:38 CET] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vMCBH
[21:41:38 CET] <KGB> 13FFV1/06master 142e864f6 15Dave Rice: add NumBytes definition
[21:43:25 CET] <rcombs> lolcineform
[21:43:36 CET] <rcombs> does anyone actually use that on purpose
[21:43:54 CET] <rcombs> afaik it's mostly people who imported GoPro footage using the provided app and didn't realize it reencodes
[21:44:02 CET] <kierank> yes
[21:57:42 CET] <KGB> [13FFV1] 15dericed opened pull request #44: use uniquely named tmp file per output (06master...06fix-for-make--j12) 02https://git.io/vMCRW
[22:08:47 CET] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vMC0f
[22:08:47 CET] <KGB> 13FFV1/06master 147c0fb14 15Dave Rice: use uniquely named tmp file per output...
[22:12:05 CET] <KGB> [13FFV1] 15michaelni closed pull request #38: more verbose descriptions of assignment operators (06master...06assignments) 02https://git.io/vMCG7
[22:17:19 CET] <KGB> [13FFV1] 15dericed opened pull request #45: Bump to draft version 01 (06master...06bump-to-draft-version-01) 02https://git.io/vMC08
[22:17:30 CET] <durandal_1707> what I need to patch in MPlayer loader to get it to print called function address?
[22:20:07 CET] <kierank> can't you step in gdb
[22:20:20 CET] <kierank> or make it print function tree
[22:26:44 CET] <durandal_1707> how?
[22:27:35 CET] <kierank> https://stackoverflow.com/questions/311948/make-gdb-print-control-flow-of-functions-as-they-are-called
[22:30:31 CET] <KGB> [13FFV1] 15dericed opened pull request #46: Spacing and grammar (06master...06spacing-and-grammar) 02https://git.io/vMCEI
[23:11:11 CET] <durandal_1707> kierank: that's not helpfull as I play with old wine code in MPlayer
[23:15:21 CET] <Compn> didnt Sesse write some code for mplayer loader ? hmm
[23:16:48 CET] <durandal_1707> I think I need to touch  assembly
[23:17:57 CET] <Compn> what you trying to do with the loader? 
[23:18:00 CET] <Compn> get shq codec working ?
[23:19:08 CET] <Sesse> Compn: yes, a few years back
[23:19:17 CET] <Sesse> to get prores and cineform working
[23:19:21 CET] <Sesse> both of which now are in ffmpeg
[23:20:13 CET] <Compn> yeah, Sesse is the one to aks
[23:24:20 CET] <durandal_1707> I'm working on ClearVideo, and need to know what functions from what dll it calls
[23:24:36 CET] <Sesse> Compn: rotfl, no
[23:24:40 CET] <Sesse> Compn: that was what, seven years ago
[23:24:41 CET] <Sesse> +
[23:24:42 CET] <Sesse> ?
[23:24:47 CET] <Compn> Sesse : the code hasnt changed lol
[23:24:54 CET] <Sesse> Compn: it's not like I remember anything of it
[23:25:01 CET] <Compn> like riding a bike
[23:25:07 CET] <Sesse> computers don't work that way
[23:26:06 CET] <Sesse> how much do you remember from history class in high school? :-P
[23:27:58 CET] <Compn> i mean, with your skills, you could relearn quick
[23:28:05 CET] <Compn> you tamed the beast 2x before
[23:28:22 CET] <Sesse> doesn't mean I can answer questions on IRC offhand
[23:28:42 CET] <Compn> yeah i didnt mean that
[23:28:47 CET] <Compn> i meant ask sesse to relearn it :D
[23:33:57 CET] <Sesse> int LOADER_DEBUG=1; // active only if compiled with -DDETAILED_OUT
[23:33:57 CET] <Sesse> //#define DETAILED_OUT
[23:33:57 CET] <Sesse> static inline void dbgprintf(char* fmt, ...)
[23:33:59 CET] <Sesse> probably what you want
[23:35:51 CET] <kierank> BBB: there, sent my huge mpegvideo questions email
[23:47:54 CET] <KGB> [13FFV1] 15michaelni closed pull request #46: Spacing and grammar (06master...06spacing-and-grammar) 02https://git.io/vMCEI
[00:00:00 CET] --- Sun Jan  8 2017