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

[burek]

[00:00:16 CET] <J_Darnley> Well it wasn't in my old cygwin dir.  Lets try my older backups
[00:05:07 CET] <J_Darnley> Oh my.  Look at all that unfinished work.
[00:06:08 CET] <tmm1_> lol
[00:09:12 CET] <rcombs> <@BtbN>	libyami itself copies the frame, again. No wonder it's horribly slow.
[00:09:18 CET] <rcombs> BtbN: ^ where's the bit that does this?
[00:16:54 CET] <J_Darnley> tmm1_: I couldn't find it, sorry.
[00:17:04 CET] <tmm1_> J_Darnley: no worries, thanks for looking
[00:17:30 CET] <J_Darnley> I suggest you unroll, by hand, the various macros in the C version and see what they're doing.
[00:19:42 CET] <J_Darnley> I'm going to do the same and try to recreate what I think I drew.
[00:28:05 CET] <J_Darnley> Oh I think I remember now.  I think it was on a scrap of paper!
[00:32:29 CET] <nevcairiel> JEEB: I'll probably look into merging the remaining patches from libav after the holidays
[00:34:13 CET] <JEEB> ok, so if I want to post a patch in the mean time I could do that instead of reworking it to use the new libav thingamajigs instead of the lavc context from a muxer?
[01:25:49 CET] <J_Darnley> tmm1_: This is roughly what I had down on paper: http://users.telenet.be/darnley/ffmpeg/yadif.png
[01:26:33 CET] <J_Darnley> That is the main spatial check hidden in the CHECK macro
[01:27:38 CET] <tmm1_> interesting
[01:28:19 CET] <J_Darnley> Briefly put the score is the sum of the absolute differences represented by the red lines
[01:31:22 CET] <J_Darnley> I should have a more verbose text file following soon.
[01:32:12 CET] <tmm1_> cheers
[02:19:16 CET] <J_Darnley> tmm1_ http://users.telenet.be/darnley/ffmpeg/yadif.txt
[02:19:41 CET] <J_Darnley> (It is really a C file but I couldn't be bothered renaming it after I added the code.
[02:19:47 CET] <J_Darnley> )
[02:21:33 CET] <J_Darnley> :qall
[02:21:50 CET] <J_Darnley> :) wrong window
[02:38:34 CET] <tmm1_> J_Darnley:  this is great, thanks!
[02:51:50 CET] <cone-721> ffmpeg 03Stefan Pöschel 07master:470749703e3c: avformat/mpegtsenc: add flag to embed an AC-3/E-AC-3 ES the DVB way
[05:25:27 CET] <kierank> any ideas why this crashes http://pastie.org/private/vm3emeqh1hlzwobeq2z6da
[05:25:30 CET] <kierank> works fine with one table
[05:25:34 CET] <kierank> but reuse causes a problem
[05:28:02 CET] <kierank> michaelni: ping ^
[05:28:04 CET] <kierank> vlc code stuff
[05:53:57 CET] <rcombs> BtbN: ~poke~
[11:47:30 CET] <michaelni> kierank: unrelated to the crash but  int16_t  new_cfhd_vlc_level[NB_VLC_TABLE_18 * 2];24 <-- the 24 shouldnt be there 
[11:48:19 CET] <kierank> Yes saw that
[17:06:24 CET] <cone-007> ffmpeg 03James Almer 07master:ce4c85de6a40: x86/vf_maskedmerge: make ff_maskedmerge8_sse2 work on x86_32
[17:06:25 CET] <cone-007> ffmpeg 03James Almer 07master:0988c68cf9cd: x86/vf_blend: simplify using macros
[17:06:26 CET] <cone-007> ffmpeg 03James Almer 07master:02f428051a41: x86/vf_blend: make all functions work on x86_32
[17:06:27 CET] <cone-007> ffmpeg 03James Almer 07master:8dba3fb8fdcf: x86/vf_blend: add sse2 versions of blend_difference and blend_negation
[17:24:21 CET] <tapas_> i want to see how ffmpeg is autthenticating with rtmp server. how do i enable log for that ? 
[18:22:41 CET] <Daemon404> you must really enjoy pain, ubitux 
[18:54:53 CET] Action: TD-Linux is still mad about SanDisk ruining their Clip line with the Sport and Jam
[18:58:24 CET] <_6U54N0_> http://pastebin.com/mGxciMCJ
[19:00:33 CET] <cone-007> ffmpeg 03Paul B Mahol 07master:8cbb055760c7: avfilter/af_sofalizer: make virtual speaker positioning supports all channel layouts
[19:04:53 CET] <ubitux> Daemon404: re: srt? :)
[19:13:55 CET] <Daemon404> yes
[19:19:16 CET] <rcombs> BtbN: _poke_
[19:19:27 CET] <ubitux> well, if you look closely, you'll notice there isn't that much code
[19:19:44 CET] <ubitux> it's just about taking the good design decision
[19:19:49 CET] <ubitux> and know what to expect
[19:20:09 CET] <ubitux> anyway, i think this last iteration should solve a bunch of issues
[19:20:21 CET] <ubitux> rcombs: what happened to the ass stuff
[19:20:22 CET] <ubitux> ?
[19:20:36 CET] <rcombs> ubitux: all sitting around if you want it
[19:20:44 CET] <ubitux> well, why not push it?
[19:22:31 CET] <rcombs> which bits, I have like 4 ass-related patches
[19:22:43 CET] <rcombs> and have lost track of what complaints people had
[19:23:09 CET] <rcombs> (this is where something like GH pull requests would be useful)
[19:23:46 CET] <ubitux> i don't know :)
[19:24:17 CET] <rcombs> clearly I should send everything again
[19:26:28 CET] <cone-007> ffmpeg 03Paul B Mahol 07cfhd:HEAD: avfilter/af_sofalizer: make virtual speaker positioning supports all channel layouts
[19:27:03 CET] <ubitux> rcombs: and submit samples :p
[19:28:50 CET] <rcombs> good plan
[19:29:17 CET] <ubitux> why am i just notified about a commit in a (now inexistant) "cfhd" branch on ffmpeg-cvslog?
[19:29:22 CET] <ubitux> ^ kierank 
[19:29:43 CET] <kierank> wtf
[19:30:04 CET] <ubitux> or is it an hidden branch?
[19:30:14 CET] <kierank> not meant to be anything
[19:30:28 CET] <kierank> or even meant to be pushed
[19:30:44 CET] <ubitux> seems to be readable from git.videolan.org somehow
[19:30:46 CET] <ubitux> Merge branch 'cfhd' of https://github.com/kierank/ffmpeg-cfhd into cfhd
[19:30:50 CET] <ubitux> :p
[19:30:53 CET] <kierank> where, how?
[19:31:10 CET] Action: kierank wonders what he did to cause that
[19:31:13 CET] <ubitux> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=cdc285357f8a6abcf459759c4ed0963db5f6bf61
[19:31:19 CET] <ubitux> started from here
[19:31:26 CET] <ubitux> then went back to "parent"
[19:31:46 CET] <ubitux> but i don't see the branch in the list
[19:31:51 CET] <kierank> I don't know what I did
[19:32:18 CET] <ubitux> http://ubitux.fr/pub/pics/cfhd-kierank-cvslog.png
[19:32:25 CET] <ubitux> basically just got this 
[19:32:43 CET] <kierank> pushed to git.vo by accident I guess
[19:32:50 CET] <kierank> but it's not there
[19:32:51 CET] <ubitux> but it's not visible
[19:32:54 CET] <ubitux> yeah
[19:32:56 CET] <ubitux> :D
[19:33:42 CET] <kierank> Twas the night before christmas and kierank broke git
[19:34:20 CET] <JEEB> :D
[19:38:10 CET] <bencoh> :D
[19:43:07 CET] <jamrial> kierank: git push -n is your friend :P
[19:44:38 CET] <kierank> kieran at ubuntu:~/ffmpeg$ git push origin --delete cfhd -n
[19:44:39 CET] <kierank> error: unable to delete 'cfhd': remote ref does not exist
[19:44:39 CET] <kierank> error: failed to push some refs to 'git at source.ffmpeg.org:ffmpeg'
[19:45:51 CET] <jamrial> even if it existed, you can delete anything. you'd need to ask j-b for that
[19:45:55 CET] <ubitux> kierank: i'm wondering if videolan doesn't have a hook that delete the branch
[19:46:11 CET] <jamrial> *can't
[19:46:13 CET] <ubitux> and the mailer just got time to send one notification before it got trashed completely
[19:46:41 CET] <thresh> hey everyone
[19:46:54 CET] <thresh> please join me in shaming kierank 
[19:47:03 CET] <kierank> yeah a lump of coal for me tomorrow
[19:47:30 CET] <thresh> also there seems to be a lot of unreachable objects in ffmpeg git repo, and in order to fix that, a manual git gc / git prune / git repack might be needed
[19:47:36 CET] <ubitux> haha
[19:47:43 CET] <ubitux> thresh: we noticed
[19:48:08 CET] <thresh> so I'm kind of asking if you want me to launch git gc to "fix" stuffs
[19:49:30 CET] <jamrial> while it prevent people from pushing while it's running? not eveyone that may push something is online here right now
[19:50:53 CET] <jamrial> *will
[19:52:22 CET] <thresh> oh, I have no idea.  it should be fairly fast, though.
[19:53:19 CET] <ubitux> thresh: http://pastie.org/pastes/10651229/text
[19:53:25 CET] <ubitux> so what happened exactly?
[19:54:53 CET] <nevcairiel> Not like anyone is going to push right now, so feel free to gc it
[19:55:07 CET] <thresh> I'll do full backups first and I have to run now
[19:59:46 CET] <J_Darnley> lol, silly email "protection"
[20:31:19 CET] <cone-007> ffmpeg 03Ganesh Ajjanagadde 07master:26937fb416cd: swr/resample: use av_clip_int16 instead of av_clip
[20:58:19 CET] <cone-007> ffmpeg 03Michael Niedermayer 07master:052e692e85f5: avcodec/ac3dec: Print the value of out of range exponents
[20:58:20 CET] <cone-007> ffmpeg 03Michael Niedermayer 07master:4bec36f98c51: avformat/mpegts: consider stream_type 4 just a hint toward mp3 and not definite
[21:00:22 CET] <BtbN> rcombs, https://github.com/01org/libyami/blob/HEAD/vaapi/vaapiimage.cpp#L143
[21:00:56 CET] <BtbN> It also has to do that, as the data somehow has to get into the VAAPI Surface
[21:01:26 CET] <Daemon404> BtbN, that whole library reads so sloppy
[21:01:32 CET] <BtbN> another fun part I discovered is that libyami does not seem to support timestamps _at all_
[21:01:48 CET] <BtbN> While the input and output buffers do have a timeStamp field, the output timestamp is allways just 0
[21:02:03 CET] <BtbN> So there is absolutely no way to get any information about reordered frames or stuff
[21:02:10 CET] <Daemon404> BtbN, it's also missing a stupidly easy fats path
[21:02:15 CET] <BtbN> No idea how it should be possible to propperly use that library _at all_
[21:02:19 CET] <Daemon404> if srcstride == dststride -> memcpy whole thing
[21:02:35 CET] <Daemon404> unless it expects it to be zeroes
[21:02:36 CET] <Daemon404> or something
[21:02:53 CET] <BtbN> Well, VAAPI surfaces allways have a 32 byte alignment, so the dst stride basicaly never matches
[21:03:10 CET] <Daemon404> pretty sure we do 32 sometimes
[21:03:14 CET] <Daemon404> for some SIMD stuff
[21:03:20 CET] <Daemon404> avx was it?
[21:03:38 CET] <BtbN> In the current state, libyami is useless
[21:03:55 CET] <Daemon404> pretty sure j-b said somethign similar like 6 months ago
[21:03:58 CET] <BtbN> The only thing it might be usefull for is zero-copy transcoding, with both decoding and encoding happening in VAAPI Surfaces
[21:04:10 CET] <Daemon404> why use ffmpeg at all then
[21:04:16 CET] <BtbN> exactly
[21:04:46 CET] <BtbN> Anyway, I have a "working" libyami encoder here now: https://github.com/BtbN/ffmpeg/tree/yami
[21:04:54 CET] <BtbN> It's just missing one important part: Timestamps
[21:05:05 CET] <BtbN> Which libyami doesn't provide at all
[21:05:40 CET] <Daemon404> ... nice namespace for yami
[21:05:42 CET] <Daemon404> or lack thereof
[21:05:53 CET] <BtbN> exactly
[21:06:01 CET] <BtbN> it has a function which has the litteral symbol "encode"
[21:06:05 CET] <JEEB> lol
[21:06:19 CET] <JEEB> so that's what the earlier comments about such symbol were
[21:06:33 CET] <Daemon404> teh stuff about 'native display' is weird too
[21:06:37 CET] <Daemon404> for an encoder
[21:06:55 CET] <BtbN> Not realy, maps directly to VAAPI
[21:07:09 CET] <BtbN> https://github.com/01org/libyami/blob/master/capi/VideoEncoderCapi.h that's the entire encoding API. It's horrible.
[21:07:22 CET] <Daemon404> nice header name too
[21:07:31 CET] <Daemon404> generic name, no subfolder
[21:07:55 CET] <BtbN> And no pkg-config for that! I added that myself.
[21:09:00 CET] <rcombs> BtbN: ah, so no CPU->CPU internal copy, then
[21:09:14 CET] <BtbN> hm?
[21:09:31 CET] <rcombs> like, it doesn't memcpy() from one CPU-memory buffer to another
[21:09:45 CET] <BtbN> It would need some sse4 instructions to copy to the uswc vaapi buffer
[21:09:50 CET] <rcombs> just from the source buffer into a mapped GPU surface
[21:09:51 CET] <BtbN> In an efficient way
[21:09:55 CET] <BtbN> yes
[21:10:38 CET] <BtbN> It's so slow because plain memcpy into uswc memory is highly inefficient
[21:11:47 CET] <BtbN> But liyami is so bad that'd I'd prefer writing an encoder on top of plain vaapi for ffmpeg...
[21:11:58 CET] <BtbN> +b
[21:12:06 CET] <BtbN> And that's such a pain that I'd never do it.
[21:16:46 CET] <rcombs> well, shot off an email to my Intel contacts; maybe at least a few of those issues can be resolved
[21:20:09 CET] <Daemon404> IME nobody at intel knows anyone outside their area
[21:21:04 CET] <rcombs> and what area do you suppose I know people in :3
[21:21:13 CET] <Daemon404> ;p
[21:21:29 CET] <Daemon404> well intel also tends to have 5 teams doign similar things
[21:21:32 CET] <Daemon404> but not taling to eachother
[21:30:55 CET] <Mavrik> Sounds like a proper corporation.
[21:32:37 CET] <rcombs> BtbN: you mean SSE2 MOVNTDQ?
[21:33:16 CET] <BtbN> https://software.intel.com/en-us/articles/copying-accelerated-video-decode-frame-buffers
[21:33:17 CET] <BtbN> MOVNTDQA
[21:33:23 CET] <rcombs> isn't that for loads?
[21:33:31 CET] <BtbN> You need both, load and store
[21:33:44 CET] <rcombs> ah
[21:34:03 CET] <BtbN> basicaly you create a 4K buffer, and load and store into and out of it
[21:34:18 CET] <BtbN> And that makes the CPU cache that 4K buffer, which in turn makes the copy fast
[21:34:48 CET] <BtbN> There's basicaly a finished copy-function in that article
[21:34:52 CET] <BtbN> using intrinsics though
[21:35:01 CET] <BtbN> But translating it to yasm wouldn't be too hard i think
[21:35:52 CET] <rcombs> that example seems to be for copying from a GPU USWC buffer to a CPU one, though, so more useful for decoding
[21:36:14 CET] <BtbN> I think it should work in both directions
[21:36:21 CET] <rcombs> does doing basically the same step backwards stillyeah
[21:36:26 CET] <rcombs> *steps
[21:36:57 CET] <rcombs> is MOVNTDQA still useful when the input is WB system memory, though?
[21:37:37 CET] <BtbN> No idea
[21:37:44 CET] <BtbN> Would propably need a benchmark
[21:38:04 CET] <BtbN> But it's libyami which should take care of that
[21:38:26 CET] <rcombs> yeah
[21:39:39 CET] <BtbN> It's so sad that there's great hardware acceleration for a lot of stuff in all intel CPUs
[21:39:44 CET] <BtbN> but it's basicaly useless on Linux
[21:39:49 CET] <BtbN> QSV is a bad joke
[21:40:07 CET] <BtbN> Patching your kernel just to use their patches libva, with another abstraction layer on top?
[21:40:10 CET] <BtbN> *d
[22:07:26 CET] <cone-007> ffmpeg 03Michael Niedermayer 07master:b83d8be6bff7: swscale/utils: Fix intermediate format for cascaded alpha downscaling
[22:30:16 CET] <nevcairiel> Is that kernel patch still required in recent kernels?
[22:30:26 CET] <BtbN> Yes, they never upstreamed it
[22:30:36 CET] <nevcairiel> But the dispatcher media sdk library is equally a joke on linux
[22:31:08 CET] <nevcairiel> It contains zero Linux support, which is why FFmpeg has a huge hack to interface with a VAAPI device
[22:31:38 CET] <BtbN> The QSV stuff in ffmpeg should propably never have received any linux support
[22:31:43 CET] <nevcairiel> That said, QSV doesn't even work well on Windows
[22:31:50 CET] <BtbN> Now people are actualy messing with it.
[22:31:56 CET] <BtbN> QSV works great for me on Windows.
[22:32:03 CET] <nevcairiel> (In general, not FFmpeg specific)
[22:32:20 CET] <BtbN> OBS also supports it, since quite a while. Never had any issues using it.
[22:32:23 CET] <nevcairiel> Not at all for me, encodes often stall and just stop
[22:32:38 CET] <nevcairiel> Msdk goes into some endless device busy loop
[00:00:00 CET] --- Fri Dec 25 2015