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

[burek]

[00:01:50 CET] <BBB> and & fixed
[00:02:05 CET] <BBB> happy guys?
[00:02:10 CET] <BBB> because Im going home now
[00:03:25 CET] <nevcairiel> if anything wmavoice is happy, so much attention, its not used to this!
[00:16:46 CET] <BBB> nevcairiel: maybe it should learn to be a ore appreciative codec, its not the cleverest one out there, eve
[00:17:00 CET] <llogan> wiener_denoise was too small
[00:17:06 CET] <BBB> *even lossless codecs are more useful than this one, its acting up like a spoiled brat ;)
[00:17:21 CET] <BBB> anyway enough bad jokes about silly codecs
[01:32:07 CET] <cone-098> ffmpeg 03Andreas Cadhalpun 07master:319438e2f206: swscale: save ebx register when it is not available
[02:51:46 CET] <blue_misfit> can anyone give me some info about what async (the protocol) would be used for?
[03:38:27 CET] <cone-098> ffmpeg 03Thomas Turner 07master:9f76ad2a4643: avutil: Added selftest for libavutil/audio_fifo.c
[03:38:28 CET] <cone-098> ffmpeg 03Michael Niedermayer 07master:54931fd0fb82: avutil/random_seed: Use uint64 instead of uint8 for struct to avoid potential alignment issues
[03:53:17 CET] <crelloc> copy
[04:25:45 CET] <rcombs> so lavf/isom.c identifies codec ID 0x69 as MP3, when in fact it could be MP1 or MP2
[05:29:21 CET] <rcombs> erm, sorry, 0x6B
[06:07:18 CET] <Compn> rcombs : do you mean it could be mp1, mp2 or mp3 ?
[06:07:26 CET] <rcombs> yeah
[06:07:41 CET] <Compn> you have samples where this is a problem ?
[06:07:48 CET] <Compn> he asked, expecting the answer to be yes
[06:07:57 CET] <Compn> or you have the spec open ?
[06:09:00 CET] <Compn> i guess then just add the duplicate lines like is done for 0x69
[06:09:35 CET] <Compn> as long as you comment in the spec chapter, patch lgtm...
[06:10:19 CET] <rcombs> I have one sample
[06:10:38 CET] <Compn> do you happen to know the name of the offending software that created such sample ?
[06:11:03 CET] <rcombs> looked at the spec, and all it says is 11172-3
[06:11:24 CET] <rcombs> which is just MPEG-1 Part 3, i.e. audio
[06:11:37 CET] <rcombs> yeah, it was lavf
[06:12:02 CET] <Compn> is it a bug in our movenc 
[06:12:16 CET] <rcombs> I think it probably isn't
[06:13:20 CET] <rcombs> lemme ask the person who encoded it, but I'm guessing they remuxed this from another MOV file, and the whole time lavf thought it was MP3
[06:17:16 CET] <rcombs> oh interesting
[06:17:25 CET] <rcombs> Compn: see mov_write_esds_tag; it explicitly writes 0x6B for MP2 and MP3
[06:17:39 CET] <rcombs> but afaict this is perfectly up-to-spec
[17:46:34 CET] <Zeranoe> Perhaps an unsurprising result, but a conclusive result non the less: https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=2&t=4837
[17:59:02 CET] <kierank> Zeranoe: do you have standard deviations
[17:59:22 CET] <Zeranoe> kierank: I'll get them
[18:06:56 CET] <nevcairiel> considering the other two are basically wrappers around w32 api, unsurprising indeed
[18:10:59 CET] <Zeranoe> About to ditch Excel and calculate these in Bash
[18:11:34 CET] <JEEB> something like python is better for any sort of maths and to keep you more sane than insane
[18:11:50 CET] <Zeranoe> This is true
[18:12:09 CET] <JEEB> personally I just wouldn't dare to think about doing maths in bash or batch :)
[18:12:28 CET] <Zeranoe> It's not bad in a pinch
[18:20:48 CET] <wm4> these use the vista primitives, right?
[18:21:16 CET] <wm4> we should ditch the XP compat already, or hide it behind a configure switch
[18:21:25 CET] <wm4> if idiots want to use XP, let them suffer, not us
[18:21:38 CET] <JEEB> I thought the vista APIs were actually slower?
[18:21:58 CET] <JEEB> because the abstraction somehow ends up doing you overhead or whatever
[18:28:09 CET] <Zeranoe> Assuming Excel didn't freak out in the background, the standard deviation was around 2 sec
[18:28:45 CET] <JEEB> btw, was there any way of libavformat sending signals to the rest of things?
[18:29:02 CET] <JEEB> so that the API user can be warned of required decoder re-init or whatever
[18:31:15 CET] <kierank> JEEB: lol no, text only ofc
[18:31:34 CET] <JEEB> alrighty
[18:31:56 CET] <JEEB> but at least some sort of text-based thing I guess?
[18:32:22 CET] Action: JEEB is still crazy enough to think about fixing PID switches
[18:43:15 CET] <wm4> JEEB: decoder reinit would be handled decoder-internally
[18:43:25 CET] <wm4> you probably mean stream switching or something?
[18:44:08 CET] <JEEB> depends on if the PID switch it left for the API user to handle or if the demuxer should handle it itself
[18:44:20 CET] <JEEB> also re-init might sometimes mean initializing a different decoder
[18:44:30 CET] <JEEB> because I heard PID switches can mean format switches
[18:44:49 CET] <JEEB> and not only stream config switches, which is supported by many decoders
[18:45:08 CET] <JEEB> although I've not seen any PID switches where the video or audio format completely changes
[18:46:16 CET] <nevcairiel> broadcasts typically avoid switching format
[18:46:30 CET] <wm4> JEEB: different format would mean different AVStream
[18:46:37 CET] <JEEB> yea
[18:50:25 CET] <kierank> JEEB: ahahahaha
[18:50:26 CET] <kierank> you are insane
[18:50:40 CET] <kierank> the pid stuff is so complicated
[18:50:52 CET] <kierank> if you do ./ffmpeg -i on a random live feed all the pids are jumbled
[18:50:57 CET] <kierank> because it just ignores PMT and probes
[18:51:03 CET] <JEEB> yup
[18:51:57 CET] <JEEB> (I know the fun side-effects of the whole "let's support MPEG-TS without PMT" thing)
[18:52:15 CET] <bencoh> :]
[18:52:39 CET] <kierank> support mp4 without moov as well
[18:52:48 CET] <JEEB> I did not hear that
[18:53:10 CET] <JEEB> or wait, movie fragments
[18:53:20 CET] <JEEB> yes, I will keep telling myself it's just movie fragments we support
[19:40:32 CET] <durandal_17> anyone here knows intrinsics well?
[19:56:04 CET] <durandal_17> BBB: you?
[19:56:35 CET] <BBB> uhm...
[19:56:41 CET] <BBB> what does know mean?
[19:57:03 CET] <durandal_17> knowing what it does with few input numbers
[20:00:14 CET] <BBB> why dont you ask a specific question and Ill let you know if I know
[20:03:21 CET] <durandal_17> BBB: i have function from pixlet decompiler which postprocess luma stuff
[20:03:35 CET] <BBB> ok
[20:14:01 CET] <durandal_17> BBB: https://paste.ubuntu.com/23665287/
[20:14:27 CET] <BBB> what is that
[20:15:38 CET] <blue_misfit> Zeranoe, thank you for all you do!
[20:15:53 CET] <durandal_17> BBB: thats pixlet luma postprocessing
[20:16:13 CET] <durandal_17> similar to chroma where it shifts by 1 to left
[20:16:48 CET] <BBB> ok
[20:16:53 CET] <BBB> so step 1, the input is signed 16bit
[20:16:57 CET] <BBB> so -32768 to +32767
[20:17:11 CET] <BBB> it clips it to 15bit (non-negative)
[20:17:25 CET] <durandal_17> but its locked to -1024 to 32767
[20:17:30 CET] <BBB> then converst it to 32bit
[20:17:46 CET] <BBB> then to float
[20:19:24 CET] <durandal_17> it does something strange with sqrt()
[20:19:50 CET] <BBB> it compares that to v31, which is a1.m128_f32[0] * *(double *)&v11.m128_u64[0] from line 37
[20:20:18 CET] <BBB> i.e. (double)((1 << wanted) - 1) / 255.9980468675494 * sqrt((double)a7)
[20:20:28 CET] <durandal_17> wanted is 15
[20:21:11 CET] <durandal_17> a7 is 2048
[20:21:17 CET] <BBB> & very strange
[20:21:21 CET] <BBB> anyway
[20:21:43 CET] <BBB> it multiplies the float pixels by v14 and v15
[20:22:04 CET] <BBB> v14 is 1.0 / a1.m128_f32[0];, so it converts it to [0.0,1.0 range]
[20:22:16 CET] <BBB> v15 is (float)a7 / v12;
[20:23:12 CET] <BBB> then depending on the comparison, it takes v14 or v15 and merges that back
[20:23:32 CET] <BBB> so it seems like it converts to some gamma-corrected scale or whatever
[20:23:36 CET] <BBB> dont know exactly
[20:23:44 CET] <BBB> but it seems like gamma application (like TRC)
[20:25:38 CET] <BBB> then convert back to 32bit int, sub is_32768 (?), pack to 16bit, add word_196B0, add v30 and store into the original pixel array
[20:25:42 CET] <BBB> thats all
[20:26:26 CET] <BBB> v30 = a8
[20:26:34 CET] <BBB> does that make sense?
[20:29:23 CET] <durandal_17> yes. a8 is -32768
[20:41:47 CET] <durandal_17> BBB: looks like just doing y * y in 0-1 range does it
[20:42:40 CET] <BBB> if its smaller than some value
[20:43:00 CET] <BBB> you can just input an array of values into that function and see what it does
[20:43:06 CET] <BBB> but to me, this means the values are not 16bit, but 15bit
[20:44:14 CET] <durandal_17> codec provides 16bit rgb(a) output
[21:05:19 CET] <durandal_17> and is more like float format than anything else
[21:40:49 CET] <cone-168> ffmpeg 03Paul B Mahol 07master:9933579a9be7: avfilter/vf_psnr: add gray10 and gray12 support
[22:47:19 CET] <cone-168> ffmpeg 03Michael Niedermayer 07master:fd1fcb59dcdb: avformat/img2dec: Remove dead code from psd_probe()
[23:05:38 CET] <Zeranoe> I'm getting lots of reports of hangs when using x264. I haven't been able to reproduce it yet, but I feel like something must have changed
[23:09:44 CET] <Compn> cant test, wont run on vista :P
[23:09:53 CET] <Compn> (or xp)
[23:10:13 CET] <Zeranoe> lol
[23:10:50 CET] <Compn> well :P
[23:11:11 CET] <Zeranoe> I know I'm going to end up building an FFmpeg with debug symbols for GDB. I wont include MFX/QSV, so others (with vista/xp) can test
[23:11:38 CET] <Compn> yeah we dont need that qsv crap on vista/xp :P
[23:11:53 CET] <Zeranoe> No one needs that QSV crap, it's crap
[23:12:13 CET] <Compn> any of your users use it? why not disable...
[23:12:22 CET] <Zeranoe> Some apparently do
[23:12:27 CET] <Zeranoe> some=many
[23:13:39 CET] <Compn> ok no problem then
[23:13:43 CET] <Compn> just making sure. :)
[23:15:35 CET] <Zeranoe> And of course I'm not going to be able to reproduce this hang using the methods sent to me...
[23:20:17 CET] <rcombs> gotta go fast
[23:23:14 CET] <Zeranoe> Rocking -p veryfast
[23:23:58 CET] <Zeranoe> I feel like my i7-4790K is going to handle anything I throw at it. I need a crappy CPU maybe
[23:24:20 CET] <fritsch> Zeranoe: try a jellyfish sample
[23:24:28 CET] <fritsch> 120 Mbit/s
[23:24:35 CET] <Zeranoe> fritsch: A what...
[23:25:27 CET] <fritsch> http://jell.yfish.us/media/jellyfish-250-mbps-4k-uhd-h264.mkv
[23:25:33 CET] <fritsch> you wanted something your CPU cannot decode
[23:25:36 CET] <fritsch> and h264
[23:25:37 CET] <fritsch> try that
[23:26:15 CET] <fritsch> infact you asked for a slow cpu, I gave you something that makes you feel having a slow cpu
[23:26:40 CET] <Zeranoe> I'm intrigued
[23:27:15 CET] <Zeranoe> Does the preset matter?
[23:27:50 CET] <fritsch> sorry, cannot parse that question with the given ctx.
[23:28:21 CET] <Zeranoe> Does -preset veryslow or -preset veryfast tax more
[23:28:43 CET] <fritsch> the first one
[23:29:28 CET] <Zeranoe> Immediate hang, nice
[23:30:11 CET] <fritsch> perhaps try the 160 Mbit/s first?
[23:32:49 CET] <Zeranoe> I can't tell if the hang is CPU related or simply trying to allocate the memory
[23:34:24 CET] <Zeranoe> Looking at 4GB memory usage to work with those
[23:34:29 CET] <fritsch> I also can't but you asked above to "get some trouble", and as helpfull person I thought to help you
[23:34:46 CET] <Zeranoe> fritsch: Thank you
[23:35:01 CET] <fritsch> :p
[23:40:46 CET] <Zeranoe> fritsch: Those files did it, thanks a lot, I can reproduce this now
[23:40:53 CET] <fritsch> cool
[00:00:00 CET] --- Thu Dec 22 2016