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

[burek]

[00:08:32 CET] <rcombs> jkqxz: is vaapi deinterlacing reliably available on all systems that have it
[00:34:58 CET] <jkqxz> wm4:  The encoder might fail because it doesn't support the input, but it should be otherwise harmless.
[00:35:01 CET] <jkqxz> The Intel driver does silent magical conversions in some cases.
[00:35:31 CET] <wm4> woah
[00:35:36 CET] <wm4> "magical", "some cases"
[00:35:42 CET] <wm4> what's going on down there
[00:35:44 CET] <jkqxz> I'm not really sure with the AMD driver.  Doing nasty things (such as decoding a 4:2:2 MJPEG stream) unrecoverably nukes the GPU.
[00:35:49 CET] <jkqxz> (For me.)
[00:36:23 CET] <wm4> lol
[00:36:25 CET] <nevcairiel> AMD seems generally to be not that great with vaapi, eh
[00:36:53 CET] <jkqxz> Decoding normal 4:2:0 stuff, ok.  Everything else, not so much.
[00:37:21 CET] <jkqxz> rcombs:  Almost all.  Some of the older Intels can't do it.
[00:37:34 CET] <rcombs> :/
[00:38:03 CET] <jkqxz> Pre-Sandy Bridge.  You might prefer not to care about them.
[00:38:04 CET] <rcombs> is there an easy way to test that capability via lavfi? Like, trying to open the filter?
[00:38:59 CET] <wm4> systems that don't use the intel driver will also not support it
[00:39:07 CET] <jkqxz> I think it would fail on config_output in lavfi.
[00:39:30 CET] <jkqxz> It works fine in Mesa.  Not sure about platform support.
[00:40:03 CET] <rcombs> I need to read up on how to make the relevant lavfi calls to do that
[00:40:14 CET] <wm4> was thinking of the good old vdpau wrapper
[00:40:39 CET] <jkqxz> Ohyeah.  Which doesn't work with libva 2, so dead.
[00:41:49 CET] <gagandeep> kierank: when i was using av_log feature of ffplay, to find that data found when encountering tag of interlaced, i found the data was 0 in the log file, why?
[00:42:02 CET] <wm4> jkqxz: for some reason it still loads here, dunno why
[00:42:23 CET] <gagandeep> kierank:interlaced tag was given 63 in codec.h in cineform-sdk
[00:42:53 CET] <rcombs> I managed to build the AMD driver at a grand total of "only" 20MB
[00:45:05 CET] <jkqxz> I don't think anything stops it loading.  It probably works for some decoding too.
[00:47:06 CET] <atomnuker> rcombs: better than hundreds of megs or even a gig of proprietary crap
[00:47:35 CET] <rcombs> yeah, my first build was 60MB or so iirc
[00:48:04 CET] <nevcairiel> i dont care about size, i care about working
[00:48:39 CET] <rcombs> well, it also does that& sort of
[00:48:56 CET] <rcombs> I had to fuck with the profile settings because it doesn't support B-frames
[00:49:01 CET] <jkqxz> What are you running it on?
[00:50:53 CET] <rcombs> a, uh& "AMD Embedded R-Series RX-421BD Radeon R7"
[00:50:57 CET] <rcombs> according to cpuinfo
[00:54:07 CET] <jkqxz> Small APU, but reasonably recent so it should do H.265.  Fun.
[00:56:03 CET] <rcombs> it decodes H264, and then encodes it! And the output doesn't look entirely like poop!
[00:56:23 CET] <rcombs> I still need to see how well the RC actually works
[00:56:55 CET] <rcombs> and lol @ apparently there's some code for B-frames internally but it's not exposed to vaapi
[00:57:02 CET] <rcombs> (might be exposed via& OMX? But nope)
[00:57:31 CET] <nevcairiel> they have their AMF thing which is apparently coming to linux eventually
[00:59:56 CET] <jkqxz> Eventually, and probably in the proprietary driver.
[00:59:59 CET] <rcombs> love how even if I wanted to, I couldn't just use a system-provided driver, because VAAPI breaks ABI with every release
[01:00:19 CET] <rcombs> at least, not without also relying on system libva and libdrm and etc
[01:00:41 CET] <nevcairiel> do you want to ship libva? that seems extreme
[01:00:44 CET] <rcombs> which I then need either a hard dependency on, or some dispatcher
[01:00:49 CET] <rcombs> I already ship libva
[01:01:06 CET] <rcombs> on intel it's not too bad, the driver's only 5MB
[01:01:27 CET] <nevcairiel> hard-deps on libva dont seem so bad, on the distros i checked it doesnt pull in a nything but the runtime
[01:02:02 CET] <nevcairiel> and before i start messing with also providing drivers to match that..
[01:02:07 CET] <rcombs> >distros
[01:02:16 CET] <rcombs> I'm on platforms without package managers
[01:02:25 CET] <rcombs> (also platforms with package managers)
[01:02:28 CET] <nevcairiel> you're weird
[01:02:38 CET] <nevcairiel> doesnt every linux flavor have package management
[01:02:38 CET] <rcombs> sorry my users like shitty plastic boxes
[01:03:24 CET] <nevcairiel> at least if you're talking about x86 things that can actually run vaapi, its not like its some super cheapo arm box with some media chip
[01:04:07 CET] <rcombs> don't worry I have to work on those too
[01:04:19 CET] <rcombs> gonna have to do OMX
[01:04:32 CET] <rcombs> look forward to those patches
[01:04:38 CET] <nevcairiel> dont worry, we will block any attempts to get that shit in
[01:04:38 CET] <nevcairiel> :D
[01:04:56 CET] <rcombs> well actually some platforms are doing v4l2 these days
[01:04:58 CET] <rcombs> which is fine
[01:05:22 CET] <nevcairiel> didnt we actually drop omx a few years ago
[01:05:44 CET] <nevcairiel> or is that still there
[01:06:02 CET] <rcombs> I haven't bothered to try to contribute my MediaCodec work because android is such a trash fire that it only works on the 2 devices where I got the vendor to ship a library I call into to spin up the thread pool
[01:06:58 CET] <nevcairiel> oh its still there, but an encoder only, but i remember someone saying that it probably should've never existed because its bad
[01:07:17 CET] <tmm1> it's only been tested on rpi i think
[01:07:22 CET] <tmm1> and doesn't work very well there
[01:07:28 CET] <rcombs> I have a branch that's supposed to get it to work on other devices by calling an unstable C++ API
[01:07:32 CET] <rcombs> it involves this line: RefBase_decStrong((void*)((intptr_t)ProcessState + *(intptr_t*)(*(intptr_t*)ProcessState - 3 * sizeof(void*))), ProcessState);
[01:07:46 CET] <tmm1> lmao
[01:07:54 CET] <rcombs> nobody's managed to test it yet
[01:08:16 CET] <nevcairiel> the sad thing is that a company would actually be wiling to use  such code
[01:09:23 CET] <rcombs> I've tried to get the NDK people to just add the function
[01:09:29 CET] <rcombs> and they're like "sorry that's not supported"
[01:10:02 CET] <nevcairiel> maybe you shouldnt be doing that then!
[01:10:06 CET] <rcombs> so instead I get to dlsym(RTLD_DEFAULT, "_ZN7android12ProcessState15startThreadPoolEv")
[01:10:30 CET] <nevcairiel> and fix it every other android release?
[01:10:42 CET] <rcombs> they've never actually broken it as far as I can tell
[01:11:34 CET] <rcombs> I don't argue that this is a good idea
[01:11:42 CET] <rcombs> it's just the only option they've given me
[01:12:16 CET] <nevcairiel> I'm porting and cleaning up some old MTP code right now, not looking forward to finding out how many devices are still broken and will need all those crazy hacks back that i've not been porting over. We all have our demons
[01:13:05 CET] <rcombs> people are doing android on _headless boxes_
[01:13:32 CET] <tmm1> rcombs: what does that do exactly, does it connect your new process to the jvm somehow?
[01:13:51 CET] <rcombs> tmm1: just starts the thread pool that the IPC mechanism uses
[01:13:51 CET] <nevcairiel> what do they do with a headless box, play audio?
[01:13:57 CET] <rcombs> nevcairiel: nah NAS stuff
[01:14:08 CET] <nevcairiel> android seems like a dumb choice for that
[01:14:19 CET] <rcombs> this is apparently because it's the only thing with something resembling a standard video codec API for ARM
[01:14:33 CET] <rcombs> I mean, you could use OMX directly, but nobody wants to do that
[01:14:58 CET] <nevcairiel> if i wanted something to actually process video, i would never consider going arm
[01:15:00 CET] <nevcairiel> just saying
[01:15:02 CET] <rcombs> hopefully v4l2 will gain adoption and people will stop doing that
[01:15:05 CET] <rcombs> same
[01:15:22 CET] <nevcairiel> for a lightweight player, maybe
[01:15:27 CET] <nevcairiel> but server? nah
[01:15:31 CET] <rcombs> but I'm not a NAS vendor who complains about how putting 2GB of RAM in a product would add too much to BOM
[01:16:02 CET] <nevcairiel> i hope those crappy nas people pay you well for integration work =p
[01:18:06 CET] <nevcairiel> we tried to work with some nas companies before, and even did for a while, but they are just impossible
[01:30:47 CET] <gagandeep> kierank: why is data to the interlaced tag in avlog shown to be 0 ?
[01:31:13 CET] <gagandeep> kierank: wouldn't we get an interlaced flag instead of 0?
[01:46:19 CET] <gagandeep> kierank: nevermind, its progressive that is set and not interlaced
[01:47:13 CET] <gagandeep> so one can easily tell if the frame is interlaced or progressive
[01:55:13 CET] <_jamrial> shouldn't that panorama filter sent to the ml use the spherical frame side data?
[02:42:28 CET] <cone-306> ffmpeg 03Jérôme Martinez 07master:00035a6b4a9f: avcodec/ffv1enc: remove warning about transparency
[02:42:28 CET] <cone-306> ffmpeg 03Xiaohan Wang 07master:3386be16d513: ffmpeg: Fix stts_data memory allocation
[06:13:17 CET] <mistym> Anyone have advice on how to handle a format which requires advance information on the number of packets it will have?
[06:14:16 CET] <mistym> I'm writing a muxer for a format which has a sample table in the header, rather than in a trailer, and the header can't have extra padding at the end.
[06:49:33 CET] <mistym> I know that MOV/MP4 allows specifying the maximum MOOV size, but I don't believe I can safely have padding between the end of the sample table and the beginning of data.
[07:42:49 CET] <rcombs> mistym: write all the data, then determine the size of the header, then shift all the data back to make space, writing the header in the process
[07:43:54 CET] <rcombs> mistym: this is also what movenc does in the "faststart" case
[07:44:11 CET] <mistym> rcombs: Oh perfect, thanks! I was just about to ask if there was a good example to look at :)
[07:44:28 CET] <rcombs> what format, out of curiosity?
[07:44:41 CET] <mistym> Sega FILM.
[07:45:08 CET] <rcombs> huh, is that some retro console thing?
[07:45:12 CET] <mistym> Yup!
[07:45:18 CET] <mistym> It was used mainly on the Saturn, as a container for Cinepak video plus raw PCM or ADX ADPCM.
[07:45:26 CET] <rcombs> and a muxer! sounds like a fun project you've got going on
[07:45:38 CET] <rcombs> usually you just see demuxers for that sort of thing
[07:46:17 CET] <mistym> I'm working on fan translations of a few games that use the FILM format, so a muxer's going to be really useful. :) Especially since FFmpeg has fully-functional Cinepak and ADX encoders already.
[07:47:00 CET] <rcombs> oh hah, hope that all goes well for ya :)
[07:47:05 CET] <mistym> Thank you!
[09:54:40 CET] <bogdanc> @atomnuker I am interested in the ffmpeg Vulkan project
[09:54:56 CET] <bogdanc> what do you think about a contour detection filter?
[10:14:06 CET] <gagandeep> kierank: i am having difficulty understanding the difference b/w some files in cineform sdk
[10:14:24 CET] <kierank> ok
[10:14:43 CET] <gagandeep> kierank: like CFHDDecoder.cpp in DecoderSDK and SampleDecoder.cpp
[10:15:16 CET] <kierank> one is an example
[10:15:18 CET] <gagandeep> both have same function definitions and only differ in return type
[10:15:19 CET] <kierank> and one is the actual decoder
[10:15:48 CET] <kierank> ah no
[10:15:51 CET] <kierank> one is c and one is c++
[10:16:58 CET] <gagandeep> ok i will look into them with that perspective for the differences
[10:17:31 CET] <gagandeep> also did you know that for interlaced tag = -63 is responsible and for progressive videos it is set 
[10:17:59 CET] <gagandeep> i will have to seperate that tag for interlaced videos
[10:18:13 CET] <gagandeep> other wise it was put in unknown tag in log
[10:25:07 CET] <kierank> yes, part of the problem is understanding what all the tags do
[10:25:18 CET] <kierank> but cineformsdk will explain what is special about that file
[10:25:28 CET] <kierank> I guessed all of the tags in the past
[10:26:41 CET] <gagandeep> you guessed !?
[10:28:15 CET] <gagandeep> i mean it is good that they had placed comments against every tag otherwise just going by the tag name it wouldn't have been this easy for me!
[10:28:18 CET] <JEEB> yes, welcome to proprietary stuff
[10:28:26 CET] <JEEB> you don't exactly get docs on the format
[10:28:34 CET] <gagandeep> JEEB: \o/
[10:30:09 CET] <kierank> gagandeep: yes there was no open source cfhd at the time
[10:30:27 CET] <kierank> gagandeep: https://medium.com/@kierank_/reverse-engineering-the-gopro-cineform-codec-7411312bfe1c
[10:31:26 CET] <gagandeep> yeah i have read that but still i don't understand the kind of mess you mean by guessing o.O
[10:31:42 CET] <kierank> I just guessed what the tags mean
[10:32:29 CET] <gagandeep> i mean the kind of headache you must have had, i can only imagine
[10:32:59 CET] <gagandeep> for me even with all the documentation cineform sdk is not a walk in the park
[10:34:04 CET] <gagandeep> you had also written in requirements about assembly, so if i get selected will i be also doing something like what you were doing
[10:37:24 CET] <gagandeep> kierank
[10:37:55 CET] <kierank> yes
[10:38:30 CET] <gagandeep> is that the answer to my question?
[10:39:10 CET] <thardin> kierank: nice work
[10:39:18 CET] <kierank> gagandeep: yes
[10:39:22 CET] <kierank> well no
[10:39:25 CET] <kierank> there's no reverse enginereing
[10:39:30 CET] <kierank> it's all in the open sourced code
[10:39:39 CET] <kierank> but some of their code is assembly only
[10:40:06 CET] <gagandeep> ohhh...
[10:40:44 CET] <gagandeep> k, thanks kierank, will consult you if i run into some trouble
[10:41:01 CET] <kierank> thardin: thanks was two years ago though
[10:41:12 CET] <thardin> heh
[10:41:28 CET] <thardin> I'm not up to speed with the broadcast world these days
[10:41:40 CET] <thardin> blissfully ignorant one might say
[10:41:51 CET] <gagandeep> thardin:you need to do a clap on kierank's page
[10:41:56 CET] <gagandeep> heh
[10:42:07 CET] <kierank> thardin: cineform isn't really broadcast
[10:42:10 CET] <kierank> it's film stuff
[10:45:41 CET] <thardin> gagandeep: I have medium noscript'd so that's going to be difficult
[16:18:35 CET] <cone-527> ffmpeg 03James Almer 07master:c4cee261296c: avformat/mov: print the projection type when reporting it as unsupported
[17:18:41 CET] <thealexbarney> Speaking of ADX encoding, has ffmpeg's encoder been updated in the past few years? Last I checked it produced noisy audio in a lot of cases
[17:18:50 CET] <thealexbarney> (I think. Don't quote me on that)
[17:21:08 CET] <atomnuker> last commit which did anything to adxenc.c was in 2014
[17:25:30 CET] <thealexbarney> I'd have to check on ffmpeg's encoder when I have more time, but vgaudio's encoder produces the same output as the official encoder based on my testing
[17:26:35 CET] <atomnuker> its a 100 line encoder, not sure what could be different
[17:27:42 CET] <atomnuker> btw I'll hunt down the bugs in the atrac9 decoder this weekend
[17:31:24 CET] <cone-527> ffmpeg 03James Almer 07master:d168e78effd1: avcodec/extract_extradata: zero initalize the padding bytes in all allocated buffers
[17:58:13 CET] <durandal_1707> thealexbarney: encoder or decoder?
[17:58:33 CET] <thealexbarney> encoder
[18:04:07 CET] <durandal_1707> cant reproduce
[18:09:24 CET] <thealexbarney> I'll have to check later
[19:21:46 CET] <wyatt8740> Can someone recommend me a low-hanging fruit' to get used to ffmpeg API's? I
[19:22:15 CET] <wyatt8740> *I'm interested in making a decoder for QDMC audio but have no idea how to start or even if that's a good first project
[19:22:45 CET] <wyatt8740> (qdmc=QDesign Music Codec, used in this video http://web.archive.org/web/20000823075037id_/http://n64media.ign.com/media/previews/video/earthbound64spaceworldyo.mov)
[19:24:18 CET] <wyatt8740> oh, uh, maybe my ffmpeg is out of date. just looked through tracker and looks like that was done several months ago
[19:24:27 CET] <nevcairiel> i was just about to say, we have qdmc
[19:27:02 CET] <wyatt8740> lol, sorry
[19:27:21 CET] <wyatt8740> I was testing with mplayer which I forgot uses a baked-in ffmpeg libraryu
[19:27:23 CET] <wyatt8740> *library
[19:28:02 CET] <wyatt8740> still, i can't seem to get ffmpeg to dump the audio stream from that file; it says the file is 'incomplete.' Doesn't stop mplayer from playing the video portion strangely
[19:29:40 CET] <wyatt8740> nevermind, I got it. Still, are there any low-hanging fruits for someone who wants to try to write a decoder?
[19:37:30 CET] <wyatt8740> guessing most of that's already been taken
[19:38:18 CET] <jdarnley> There's probably still some obscure game formats that you could reverse engineer but I doub that counts as "low hanging"
[19:43:48 CET] <atomnuker> jkqxz: do you know if mapped (e.g. to some other API) vaapi frames are writeable?
[19:44:13 CET] <atomnuker> if I try to filter them in place I get a black screen (unless I hwdownload and the hwupload them)
[19:48:54 CET] <Compn> wyatt8740
[19:49:10 CET] <wyatt8740> hello there compn
[19:49:14 CET] <wyatt8740> i've seen you before
[19:49:50 CET] <Compn> wyatt8740 : http://trac.ffmpeg.org/ticket/5632
[19:50:00 CET] <Compn> maybe that would be 
[19:50:06 CET] <Compn> something simple to add
[19:50:32 CET] <Compn> decoder wise
[19:50:43 CET] <kierank> at the local flat earth society?
[19:50:53 CET] <wyatt8740> hmm
[19:51:06 CET] <wyatt8740> no, I can't remember where honestly kierank
[19:51:20 CET] <wyatt8740> but I know i've seen him/her on irc somewhere else
[19:51:45 CET] <wyatt8740> I actually have an amiga 500, so maybe this WOULD be a fun project
[19:52:23 CET] <Compn> or you can check out imagemagick or dcraw projects, there are a lot of image files that ffmpeg does not support yet
[19:52:30 CET] <Compn> if you wanted to do an image format
[19:52:50 CET] <jkqxz> atomnuker:  Yeah, mapped frames are writable if you mapped them for writing.
[19:53:25 CET] <atomnuker> hm, seems like even if I pass the frames through (so ff_filter_frame(outlink, in)) I get a black screen
[19:53:55 CET] <jkqxz> Try with mapping to software?  You can map, draw, unmap in lavfi (e.g. adding subtitles and things like that).
[19:54:24 CET] <wyatt8740> ah, an image format would probably be an easier first project
[19:55:04 CET] <atomnuker> jkqxz: yeah, uploading in software works, its just mapped from vaapi frames that doesn't
[19:56:00 CET] <jkqxz> I mean VAAPI -map-> write on the software frame -unmap-> VAAPI does work for you, right?
[19:56:19 CET] <atomnuker> hmm, the issue might be elsewhere, if I hwmap,hwdownload I get a black screen
[19:57:29 CET] <wyatt8740> compn: thanks for the suggestion
[19:57:39 CET] <jkqxz> OpenCL can do in-place modification of VAAPI frames too, though there is nothing currently in the codebase which uses it.
[19:57:42 CET] <durandal_1707> wyatt8740: add yafa to iff
[19:57:56 CET] <wyatt8740> yeah, I saw that it used iFF in the docs
[19:58:02 CET] <jkqxz> That is, it works with i965 + Beignet.
[19:59:03 CET] <atomnuker> jkqxz: it should, I saw a 2x performance increase if I did unsharp in place
[20:00:05 CET] <durandal_1707> so, is drmeter audio filter ready to push?
[20:00:16 CET] <atomnuker> it looked fine to me
[20:04:17 CET] <atomnuker> jkqxz: seems related to rgba vaapi formats, if I change scale_vaapi=format=rgba to yuv420p or nv12 it works
[20:04:25 CET] <atomnuker> is there anything special about rgba?
[20:04:54 CET] <atomnuker> mapping rgba vaapi frames works if I do filtering out of place
[20:40:59 CET] <jkqxz> atomnuker:  How would you do unsharp in-place?  Make the mask, global barrier, then apply it back to each pixel?
[20:42:58 CET] <jkqxz> I don't think there should be anything special about RGBA.  It might be linear rather tha tiled by default, or something like that?
[20:45:03 CET] <atomnuker> no, its definitely tiled here on my machine
[20:45:37 CET] <atomnuker> jkqxz: https://github.com/SaschaWillems/Vulkan/blob/master/data/shaders/computeshader/sharpen.comp
[20:46:00 CET] <atomnuker> though with resultImage == inputImage
[20:46:59 CET] <atomnuker> its still out of place but the out of place part happens inside the shader's workgroups, so you don't have to allocate another image externally
[20:47:44 CET] <jkqxz> That looks like the reads race with the writes.
[20:48:07 CET] <jkqxz> What stops image (x, y) being written before (x+1, y+1) has loaded?
[21:02:01 CET] <atomnuker> hm, good point, I didn't compare the output aside from "it looks unchanged"
[21:12:02 CET] <cone-061> ffmpeg 03Marton Balint 07master:3aaf97e7737c: avformat/mxfdec: fix opAtom audio demuxing
[21:12:02 CET] <cone-061> ffmpeg 03Marton Balint 07master:90756e67a0a1: avformat/mxfdec: use binary search in mxf_absolute_bodysid_offset
[21:12:02 CET] <cone-061> ffmpeg 03Marton Balint 07master:cf5ffe018394: avformat/mxfdec: do not allow more partitions than INT_MAX/2
[22:06:17 CET] <cone-061> ffmpeg 03Marton Balint 07master:8d37dd6ed3bc: avutil/parseutils: only accept full us duration, do not accept mss duration
[23:31:21 CET] <atomnuker> "Signed-off-by: Sasi Inguva <isasi at isasi.mtv.corp.google.com>" <- what kind of an email address is that
[23:31:58 CET] <nevcairiel> might be internal name inside google
[23:33:27 CET] <nevcairiel> mails at subdomains are not impossible, just uncommon
[00:00:00 CET] --- Sat Mar 10 2018