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

[burek]

[00:26] <cone-885> ffmpeg.git 03Arwa Arif 07master:627d2a7628fe: avfilter/vf_eq: Add process_command to eq.
[00:36] <saste> michaelni, please don't apply patch without letting me to review them
[00:36] <saste> that patch is a bit pointless
[00:37] <saste> now what, should I revert it?
[00:40] <michaelni> saste, whats the problem with the patch ? also why did you not review in the last 26h ?
[00:41] <saste> michaelni, i was going to review it today, i have other things in my life apart ffmpeg
[00:41] <saste> michaelni, about the patch, what's the point of using expressions?
[00:41] <saste> especially given that there are no useful parameters in the expression
[00:41] <michaelni> its easy to add usefull parameters now
[00:42] <saste> michaelni, no, because you have to recompute the LUT at each frame
[00:44] <michaelni> yes, is there a problem iam missing ?
[00:44] <michaelni> the LUT is 256 entries a HD frame has a few orders of magnitude more pixels
[00:45] <michaelni> even a 640x480 frame has more than 1000 times more pixels than the LUT has entries
[00:50] <saste> michaelni, yet you have to recompute it for each frame, while before it was recomputing it just once
[00:50] <saste> for example if we add time dependant parameters, it has to be recomputed every time
[00:51] <michaelni> recomputation would only be needed when a value changes
[00:51] <saste> also the patch could be better, for example for what regards code duplication
[00:51] <saste> michaelni, it's the usual problem, you can't tell in advance if an expression will change, assuming there variable parameters
[00:52] <michaelni> dont hesitate to ask arwa to factor code out or improve it in any way, i just dont want to let students wait days for a review
[00:52] <saste> unless you force to recompute values just once (when the expression is inited, or the command is sent, as in overlay IIRC)
[00:53] <saste> michaelni, 26 hours is not "days"
[00:53] <michaelni> the expression can be evaluated and if its value changed the LUT recomputed
[00:53] <saste> anyway, next time give me more time, like two days (which is the common practice for regular contributions)
[00:55] <michaelni> iam a little unhappy about that the whole opw round is just 3 month, if each patch review round takes 2days that could add up to alot
[00:56] <michaelni> i mean a lot of time the student is waiting for a reply
[00:58] <saste> michaelni, the mentee is supposed to be working on more tasks at the same time
[00:58] <saste> this avoids that she's stuck while waiting for feedback
[00:59] <saste> i tried to make this clear to my mentee at the beginning of the project
[01:09] <michaelni> ill try to wait a bit longer with applying patches in the future, but i think quick responses are important and other developers should help reviewing patches and awnserig questions ..
[01:15] <compn> you guys are working hard :D
[03:32] <cone-885> ffmpeg.git 03Michael Niedermayer 07master:6c91afe4973f: avcodec/snowdec: Fix avmv_index increment
[11:44] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:588361dd2660: avcodec/dca: move remaining tables to dcadata
[12:27] <cone-867> ffmpeg.git 03Kevin Wheatley 07master:31c7c0e15697: avformat/movenc: Move avid DNxHD padding to the correct spot
[13:28] <cone-867> ffmpeg.git 03Hendrik Leppkes 07master:28bf05e7b50e: hlsenc: remove the AVIOContext for the playlist from the muxer context
[16:00] <rcombs> kek, I've got a file that regresses in 9fbc613f
[16:00] <rcombs> which adds a check for the return value of an avio_seek
[16:08] <rcombs> hmm, that's quite odd
[16:09] <rcombs> I'm having an "I don't know why this works" moment
[16:25] <rcombs> oh hah
[16:28] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:f015d3d53916: MAINTAINERS: Add Oleksij as maintainer for DSS*
[16:31] <rcombs> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-February/169170.html there we go
[16:36] <rcombs> I feel slightly silly for not realizing that earlier; didn't realize avio_seek returned the new offset
[16:40] <nevcairiel> its probably not the only problem with avio_seek error checks
[16:41] <nevcairiel> seems like an easy thing to get wrong
[17:07] <rcombs> vqf_read_seek does it&
[17:07] <rcombs> `git grep '= *avio_seek'` turns up a bunch
[17:46] <ubitux> does anyone knows why there is a packet queue in ffplay?
[17:46] <ubitux> i mean, it may sound stupid but, while i can understand the need for a frame queue
[17:46] <ubitux> i wonder what's the goal of the packet queue
[17:46] <ubitux> is it because there are 2 different threads for demuxing and decoding?
[17:47] <nevcairiel> does it have both queues?
[17:47] <ubitux> yes
[17:47] <ubitux> each frame queue has a packet queue
[17:47] <nevcairiel> i guess for threads makes sense
[17:48] <nevcairiel> too much blockage if you try to hand them off to the decoder right away without a queue
[17:48] <michaelni> we need a 256x256 pixel logo for gsoc
[17:49] <ubitux> lena!
[17:49] <ubitux> (or hitler)
[17:53] <michaelni> uploaded and better logos are welcome
[17:54] <Daemon404> if you only read the last two lines, this is a lovely convo
[17:54] <Daemon404> fyi, you wont be accepted for gsoc...
[17:54] <Daemon404> vlc, x264, libav, ffmpeg
[17:54] <Daemon404> all banned
[17:55] <rcombs> waaai
[17:55] <nevcairiel> you would wish google had the decency to actually say that instead of silently handing out bans
[17:56] <Daemon404> internally, a certain someone passed around that we were racists
[17:56] <Daemon404> or so i heard
[17:56] <rcombs> :|
[17:56] <Daemon404> (said we used the N word or something)
[17:56] <Daemon404> i know you guys love politics.
[17:57] <rcombs> and here I was expecting it to be something like "not wanting to take sides between ffmpeg and libav"
[17:57] <nevcairiel> all open-source multimedia is driven  by racists, there is a french guy involved afterall, how could you miss it!
[17:57] <Daemon404> thats racist
[17:57] <ubitux> :o
[17:58] <ubitux> well now that i started pasting hitler picture i can understand the argument
[17:58] <nevcairiel> lol
[17:58] <Daemon404> lawl
[18:29] <compn> racist lol
[18:30] <compn> wait
[18:30] <compn> i do remember someone railing against the developers from china and india ... :P
[18:32] <j-b> Daemon404: I ain't racist, I dislike assholes :)
[18:32] <compn> but we've been working with people from all countries, races and creeds. i dont see how a few prejudice devels taint an entire project of devels. :P
[18:32] <Daemon404> j-b, you chose the wrong profession then
[18:32] Action: Daemon404 runs
[18:33] <j-b> Daemon404: :)
[18:46] <cone-867> ffmpeg.git 03Rodger Combs 07master:62e95757d574: wtvdec: fix integer overflow resulting in errors with large files
[19:12] <compn> maybe we should make a portrait of ffmpeg devels from around the world
[19:12] <compn> :P
[19:12] <compn> >pastey face white people
[19:12] <compn> shh
[19:13] <compn> oh we did get the group photo at vdd
[19:13] <compn> somewhat represenative.
[19:14] <compn> i keep thinking wm4 is from china, not sure why
[19:14] <rcombs> confusing him with xy?
[19:47] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:d4936d28a11f: avformat/asfdec: Use 64bit ret to avoid overflow
[19:47] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:0e3d6e17dea7: avformat/apngdec: Use 64bit ret to avoid overflow
[20:30] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:d1923d15a354: avformat/idcin: Use 64bit for ret to avoid overflow
[20:30] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:12987f89007e: avformat/gxf: Use 64bit for res to avoid overflow
[20:49] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:80a851aa5ef2: avformat/apngdec: Use 64bit for ret to avoid overflow
[20:49] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:26c0cc154e06: avformat/mvdec: Use 64bit for ret to avoid overflow
[21:14] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:d44e0d8b9307: avformat/wtvdec: Use 64bit for ret to avoid overflow
[21:14] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:cb0868718068: avformat/vqf: Use 64bit for ret to avoid overflow
[21:14] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:0f55bc29d415: avformat/omadec: Use 64bit for ret to avoid overflow
[21:23] <cone-867> ffmpeg.git 03Martin Storsjö 07master:ba2e07909b84: rtpdec_vp8: Set the keyframe flag
[21:23] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:de4ae9fb643e: Merge commit 'ba2e07909b848e583245856a59d0fe1dd08f917e'
[21:28] <michaelni> BtbN, as you are maintainer of nvenc you get OP in #ffmpeg-devel
[21:28] <michaelni> if there are other maintainers who dont have OP, please ping me
[21:30] <cone-867> ffmpeg.git 03Martin Storsjö 07master:8bdbf49c6f4d: rtpdec_h264: Include the right header for AV_RB16
[21:30] <BtbN> btw., i noticed a libva based h264 encoder on some GSoC task list, i'm, very slowly at the moment, working on that. Has someone already started with that? Don't want to sabotage the task or something.
[21:30] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:2130ed3312d4: Merge commit '8bdbf49c6f4d9473183a3c45ec70d611eb6183cd'
[21:31] <Daemon404> i dont think anyone has.
[21:32] <michaelni> BtbN, maybe you want to mentor that task (in case we get accepted and find a qualified student aka not too likely) ?
[21:33] <michaelni> it doesnt have a mentor ...
[21:34] <michaelni> BtbN, if you want to mentor it or anything else, feel free to add yourself to the wiki 
[21:35] <BtbN> libva still raises too many question for me.
[21:35] <iive> is that vaapi?
[21:35] <michaelni> ahh, ok
[21:35] <BtbN> iive, yes
[21:35] <BtbN> I'm not even sure if it's a good GSoC task, libva is an abomination of a library/api.
[21:35] <michaelni> BtbN, maybe you want to mentor some other task ?
[21:36] <iive> i remember you were complaining about h264 decoder
[21:36] <BtbN> I'm usualy complaining a lot whenever i use that lib.
[21:36] <iive> :)
[21:37] <BtbN> One example: You have to generate the sps and pps bitstream yourself.
[21:37] <BtbN> And then pass the buffer to libva
[21:38] <iive> yes, I think that was the complain I heard from you. You need about 1000 lines of code to do that.
[21:38] <BtbN> yes, it's horrible.
[21:38] <BtbN> The code for that is basicaly done and can be copied from an earlier project, but i somehow hoped they did something about that.
[21:38] <BtbN> Doesn't look like it though
[21:39] <iive> btw, i assume that this is not hardware limitation? it is something that should be improved in vaapi or the gallium backend?
[21:40] <BtbN> It's a pure libva issue
[21:40] <cone-867> ffmpeg.git 03Martin Storsjö 07master:7650caf013f4: rtpdec_h264: Use av_realloc instead of av_malloc+mempcy
[21:40] <BtbN> libva/the driver should do that.
[21:40] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:5346b57ee719: Merge commit '7650caf013f45ebebf128855735a0c6350836ea4'
[21:40] <iive> i'm asking if it is not better to fix that in the library, since it should be open source.
[21:41] <BtbN> That library consist primarily of half-binary shader assembly.
[21:41] <BtbN> The library itself does nothing, the intel driver does all the work.
[21:41] <iive> huh?
[21:42] <iive> do you mean that intel doesn't even have dedicated video decoding schematic on their GPU and use generic shaders for that?
[21:42] <BtbN> There is a lot of C code, too. But it basicaly just re-arranges the input data, and passes it to the shaders.
[21:43] <BtbN> No, there is dedicated hardware.
[21:43] <BtbN> But it's aparently controlled via shaders
[21:43] <iive> that sounds like a lot of fun.
[21:44] <BtbN> http://cgit.freedesktop.org/vaapi/intel-driver/tree/src/shaders/vme/intra_frame_gen9.g9b
[21:44] <BtbN> files like that are also a lot of fun
[21:44] <iive> is the file with gpl header?
[21:44] <iive> or rather mit
[21:45] <BtbN> i'd guess that's a compiled binary version of http://cgit.freedesktop.org/vaapi/intel-driver/tree/src/shaders/vme/inter_frame_gen8.asm
[21:45] <BtbN> but as there is no documentation about that, i can only guess
[21:46] <iive> aren't intel gpu shaders documented?
[21:46] <BtbN> propably
[21:46] <BtbN> but you realy shouldn't have to know about that stuff to use their library.
[21:47] <BtbN> As bad as nvidias license stuff is, nvenc is a realy good api, specialy when compared to libva.
[21:48] <cone-867> ffmpeg.git 03Martin Storsjö 07master:bb8c6ac840af: rtpdec_h264: Make a parameter pointer const
[21:48] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:48e661b30b94: Merge commit 'bb8c6ac840afa69dd37860fdf85da9f4cf1e0ae4'
[21:49] <iive> well, the problem is more that vaapi supports a little more than intel
[21:49] <iive> when you have only one hardware that works with your api, the driver issues kind of leak into the api.
[21:50] <BtbN> Well, vdpau, even though it doesn't provide encoding functionaly, is also way better and less pain to use than libva.
[21:52] <iive> indeed.
[21:53] <iive> but it also have some creep in it. e.g. forgot the term... it doesn't store a context, so in event of switch you have to restart decoding.
[21:55] <cone-867> ffmpeg.git 03Martin Storsjö 07master:176903ce833c: rtpdec_h264: Return immediately on errors in h264_handle_packet_stap_a
[21:55] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:ac7128a90f53: Merge commit '176903ce833ce7469f411640e9748a0d549b5285'
[21:57] <BtbN> yes, it also has some strange stuff. But stuff you can work with.
[21:58] <iive> and it is also fully supported by gallium on radeon cards.
[21:58] <BtbN> gallium/mesa isn't involved at all with libva btw.
[21:58] <BtbN> the libva-intel-driver directly opens /dev/dri/cardX
[21:58] <BtbN> Or does so through X
[21:59] <iive> i was talking about vdpau
[22:00] <iive> I also see vaapi listed in the supported API tables for radeon.
[22:00] <BtbN> yes, mesa is doing... something with vaapi.
[22:01] <BtbN> i heard rumors about them wanting to replace vdpau with it
[22:01] <BtbN> i realy hope that doesn't happen
[22:01] <iive> well, subscribe to mesa maillist.
[22:01] <wm4> huh
[22:01] <wm4> wtf
[22:01] <wm4> must be intel's doing
[22:02] <wm4> I wouldn't mind if vaapi became as capable as nvidia's vdpau, and nvidia switched to vaapi
[22:03] <wm4> but as it is, I get tons of problems with vaapi fucking up in some way, and never with nvidia's blob
[22:03] <BtbN> xbmc/kodi also has a ton of issues with it
[22:03] <cone-867> ffmpeg.git 03Martin Storsjö 07master:a335ed767161: rtpdec_h264: Remove an unnecessary check
[22:03] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:d19ca4b2eae2: Merge commit 'a335ed767161c6da2815371177cfd5e40f78e5b7'
[22:04] <BtbN> iirc they ended up pulling the decoded frames from it as early as possible, not even trying to use their OpenGL interop
[22:04] <BtbN> Cause it's fundamentaly broken
[22:05] <BtbN> I tried to implement libva based deinterlacing to xbmc for a while. It worked somewhat, but nobody was able to tell me how to propperly invoke vaapi to do the more complex deinterlacing modes. 
[22:05] <nevcairiel> i cant stop laughing at linux hw video access
[22:05] <nevcairiel> its so pathetic
[22:06] <BtbN> It only works flawless with nvidias binary driver.
[22:06] <BtbN> Kind of sad
[22:06] <nevcairiel> my problem is that i need to start caring eventually :(
[22:07] <BtbN> on windows, the Intel QuickSync encode api is well done and easy to use.
[22:07] <BtbN> And their driver supports OpenGL 4+
[22:07] <nevcairiel> for decoding and deinterlacing you just use dxva2/d3d and it works on every hardware pretty well
[22:08] <iive> do you have idea what is the situation with embedded chipsets, arm used for tablet/phones/etc
[22:08] <nevcairiel> they all have proprietary APIs
[22:08] <BtbN> Most of them use OpenMAX, some have v4l2 drivers though
[22:08] <iive> hum, gallium also seems to list openmax as supported api.
[22:09] <iive> it also list that openmax is supported for encoding video.
[22:09] <BtbN> On the RPi, you can use the de/encoder via omx
[22:12] <cone-867> ffmpeg.git 03Martin Storsjö 07master:46ad9ac9641d: rtpdec_h264: Move a leftover comment into h264_handle_packet_stap_a
[22:12] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:dc6eadaa458a: Merge commit '46ad9ac9641d1fe8292ec1f46bbd2e4456621ca7'
[22:16] <wm4> BtbN: opengl interop works for me... sort of, except when it doesn't
[22:16] <wm4> intel's stuff is really shit
[22:17] <wm4> they have libva functions that natively render video, but that doesn't always work either (plus it's shit)
[22:17] <wm4> goddammit intel
[22:17] <BtbN> wm4, the "opengl interop" in libva is kind of bad. Pulling the frame to system ram and manualy uploading it to a texture, then convert it YUV->RGB with a shader outperforms it.
[22:18] <wm4> BtbN: really... then I should also do this
[22:18] <wm4> what does xbmc use to copy the video? there are 2 methods, 4 is you count the need to do special GPU memcpy in some cases
[22:18] <wm4> (or maybe 3 in the latter case)
[22:19] <BtbN> vaDervicePicture/vaMapBuffer based iirc
[22:19] <BtbN> *Derive
[22:19] <wm4> BtbN: do you have any evidence for the claim that gl interop is slow? (before I drop all of my code)
[22:19] <BtbN> We tested it for xbmc, it's been a while though. The function in libva was obviously not optimal though
[22:20] <BtbN> i'll look for it again, if it's still that way
[22:20] <BtbN> http://cgit.freedesktop.org/vaapi/libva/tree/va/glx/va_glx.h is what you are using?
[22:21] <wm4> yes
[22:21] <nevcairiel> gb claims that shouldnt be used anymore, and egl is preferred over glx .. but thats annoying if your other code is glx
[22:21] <wm4> also the egl method is completely undocumented
[22:22] <wm4> I never found out how it works
[22:22] <wm4> also I discussed it with them on #wayland once, log: http://sprunge.us/aKgG
[22:22] <BtbN> a lot of stuff in libva is poorly documented
[22:24] <BtbN> yes, the glx interop stuff is still the same old code
[22:24] <cone-867> ffmpeg.git 03Peter Meerwald 07master:df0891fc8f32: libavresample: Annotate AARCH64 init function with av_cold
[22:24] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:7b7f8d3ed03d: Merge commit 'df0891fc8f32db3ced797cd6ebff9492fda01b99'
[22:25] <BtbN> We noticed it was slow because it was so slow that it couldn't handle 60 fps on some systems.
[22:25] <nevcairiel> slower then copying to CPU? that must be a terrible design
[22:27] <BtbN> Their YUV to RGB conversion, even though i still can't find it, must be kinda bad.
[22:27] <wm4> vdpau interop doesn't have to go over X (at least not api-wise)
[22:27] <BtbN> yes, vdpau interop is an actual OpenGL extension
[22:27] <BtbN> It doesn't work on egl with nvidia binary yet though, but they are working on that.
[22:31] <BtbN> wm4, basicaly, what the glx interop does is: It internaly creates another X drawable, then uses vaPutSurface to put the VA Surface to that drawable. Then it uses the GLX_ext_texture_from_pixmap extension to map that surface to a texture. Then it creates an fbo for your target texture. Then it renders the mapped texture of the drawable into that fbo. It renders using OpenGL imediate mode btw.
[22:32] <cone-867> ffmpeg.git 03Peter Meerwald 07master:b8d18a94376c: libavcodec: Don't use av_cold annotation in twinvq header file
[22:32] <cone-867> ffmpeg.git 03Michael Niedermayer 07master:0a1146a59a1c: Merge commit 'b8d18a94376c44dac9523dc3317259a30fc92f8b'
[22:32] <BtbN> somewhere in that chain the YUV frame gets converted to RGB, no idea where.
[22:34] <wm4> heh
[22:34] <wm4> sounds roundabout
[22:34] <wm4> I'm pretty sure vaPutSurface converts
[22:34] <BtbN> tracing vaPutSurfaces leads you deep into the va-intel-driver, and you end up in binary shader code.
[00:00] --- Sat Feb 21 2015