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

[burek]

[00:03:06 CEST] <horox> test file: http://openartist.org/magiclantern/10bit.MLV
[00:03:16 CEST] <michaelni> jamrial, 740e557d6eac3b579dfed53ed92ae70e2089c77c breaks build with shared libs
[00:03:38 CEST] <michaelni> libavfilter/libavfilter.so: undefined reference to `FcPatternAddString'
[00:06:31 CEST] <jamrial> michaelni: should i revert? i thought adding a _suggest for an external lib seemed odd
[00:09:06 CEST] <jamrial> i'm going to revert. the change is pointless anyway
[00:10:34 CEST] <michaelni> jamrial, sure, it looked odd to me too, i just didnt reply as i havnt tested yet if it works with it revretd bt at least build works
[00:11:51 CEST] <cone-080> ffmpeg 03James Almer 07master:8f2ab1806352: Revert "Merge commit '66988320794a107f2a460eaa71dbd9fab8056842'"
[00:11:58 CEST] <jamrial> michaelni: done, thanks for pointing it out
[00:17:44 CEST] <cone-080> ffmpeg 03Martin Storsjö 07master:3bc5b28d5a19: arm: vp9itxfm: Avoid .irp when it doesn't save any lines
[00:17:45 CEST] <cone-080> ffmpeg 03Martin Storsjö 07master:58d87e0f49bc: aarch64: vp9itxfm: Restructure the idct32 store macros
[00:17:46 CEST] <cone-080> ffmpeg 03James Almer 07master:0c224ce231c8: Merge commit '58d87e0f49bcbbc6f426328f53b657bae7430cd2'
[00:19:55 CEST] <cone-080> ffmpeg 03Alexandra Hájková 07master:f7ec7f546f00: wma: Convert to the new bitstream reader
[00:19:56 CEST] <cone-080> ffmpeg 03James Almer 07master:0e56321aef0b: Merge commit 'f7ec7f546f0021d28da284b024416b916b61c974'
[06:17:31 CEST] <Ahti333> wm4 i replied to your mail on ffmpeg-devel, but couldn't get the headers right (i posted the patch without being subscribed initially): http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216885.html
[08:21:13 CEST] <LongChair> jkqxz: sorry for the lag, yeah those changes look fine, feel free to squash, and push :)
[08:22:44 CEST] <kurosu> I feel the consensus on the bitstream cache is libav version will not be merged
[08:23:12 CEST] <kurosu> For sake of not changing *all the things*
[08:23:59 CEST] <kurosu> But I somewhat prefer libav version
[08:24:35 CEST] <kurosu> Maybe legacy one will lend itself better to combining with a 32b version
[08:26:01 CEST] <kurosu> That cache mostly affects high bitrate codecs, ie mostly lossless or near
[08:27:36 CEST] <kurosu> So, not a real need (otherwise someone would have committed the time)
[08:47:18 CEST] <nevcairiel> paul send patches for optionally adding a cache to our reader, but it still had soem conflicts that were not resolved yet, iirc
[10:29:43 CEST] <ubitux> so we're going to add another VT hwaccel instead of a proper decoder?
[10:30:04 CEST] <ubitux> VT as hwaccel is close to pointless
[10:30:13 CEST] <ubitux> the performances are way below what we can expect
[10:33:24 CEST] <ubitux> tmm1: ^
[10:33:37 CEST] <nevcairiel> i dont see anyone submitting a better solution to the ML
[10:34:21 CEST] <ubitux> a decoder with basic reordering is way better in practice
[10:34:35 CEST] <nevcairiel> besides the code to support hevc in the VT code we already have seems pretty simple
[10:34:47 CEST] <ubitux> it's day and night wrt speed since you can enable async
[10:35:26 CEST] <ubitux> and you can't reach real time with some footage if you don't enable it 
[10:35:52 CEST] <nevcairiel> (also, hwaccels have many other advantages, you automatically get the full sei/metadata handling from the software decoders, which full hardware decoders generally *always* lack)
[14:15:47 CEST] <Chloe> How can we remove the sdl2, opengl and caca output devices? libavdevice doesnt need visual output devices which serve no purpose other than having multiple things which do the same thing. The SDL2 and opengl output devices are covered by the functionally in ffplay, and caca is just... well, caca--does anyone actually use it apart from just testing it for the lulz
[14:18:48 CEST] <JEEB> second call for comments on back-ports http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216816.html , http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216699.html
[14:23:21 CEST] <wm4> Chloe: deprecate, remove
[14:30:57 CEST] <Chloe> wm4: I guess a av_log in the header function of each device is good enough to 'deprecate' them?
[14:36:24 CEST] <wm4> Chloe: hm probably yes
[14:36:41 CEST] <wm4> not familiar with how "devices" get deprecated
[14:37:51 CEST] <Chloe> in my experience they dont
[14:38:02 CEST] <Chloe> gonna change that though
[14:38:12 CEST] <Chloe> I reckon it's good enough just to print out a warning
[15:23:24 CEST] <Chloe> Mmh i missed the xv device 
[15:23:46 CEST] <Chloe> I guess I can add it after I get a response 
[15:51:46 CEST] <wm4> I'm always amazed by how much people like trash
[15:52:30 CEST] <durandal_1707> lavd is not trash, its just bad design
[16:16:40 CEST] <cone-906> ffmpeg 03Tobias Rapp 07master:f102a4efcef3: avfilter/f_metadata: avoid trailing whitespace in filter output
[16:16:41 CEST] <cone-906> ffmpeg 03Tobias Rapp 07master:bee01ee2ba2e: fate: add tests for psnr and ssim filter
[17:00:23 CEST] <Chloe> durandal_1707: yes, and output devices dont fit in
[17:00:33 CEST] <Chloe> Lavd needs a rethink entirely
[17:00:45 CEST] <Chloe> Removing bullshit outdevs is the first step
[17:04:18 CEST] <Chloe> durandal_1707: what's 'NAK' mean? 
[17:04:40 CEST] <mateo`> Not Ack -> Not ok
[17:07:26 CEST] <Chloe> Right so what do you want changed 
[17:12:53 CEST] <wm4> "please add a new API and rewrite everything"
[17:46:18 CEST] <cone-906> ffmpeg 03Diego Biurrun 07master:0ce3761c781f: configure: Add stdlib.h #include to CPPFLAGS check helper functions
[17:46:19 CEST] <cone-906> ffmpeg 03Diego Biurrun 07master:71a49fe25f2e: configure: Use cppflags check helper functions where appropriate
[17:46:20 CEST] <cone-906> ffmpeg 03James Almer 07master:407a7547dad5: Merge commit '0ce3761c781f2c2de40a5a8a99563878804f47cc'
[17:46:21 CEST] <cone-906> ffmpeg 03James Almer 07master:e00e8639b22a: Merge commit '71a49fe25f2e4468fbbadbebef8d073b1b3cc1a5'
[17:48:17 CEST] <cone-906> ffmpeg 03Diego Biurrun 07master:a25dac976a44: Use bitstream_init8() where appropriate
[17:48:18 CEST] <cone-906> ffmpeg 03James Almer 07master:79ebf1e19b9e: Merge commit 'a25dac976a4478331e4db86d44c3db4456c93eff'
[18:09:00 CEST] <cone-906> ffmpeg 03Josh de Kock 07master:56d2154b72fb: lavd: remove deprecated dv1394 device
[18:26:08 CEST] <ubitux> wm4: in the end, i just copied avframe stuff, and it seems to be enough; https://github.com/ubitux/FFmpeg/compare/export-udta
[18:26:17 CEST] <ubitux> i haven't handled the side data format transfer yet though
[18:26:57 CEST] <wm4> please no
[18:27:06 CEST] <wm4> not another half-assed copy of the side data code
[18:27:14 CEST] <ubitux> ?
[18:27:29 CEST] <wm4> we had so much issues with this and there's no end in sight, and your addition adds another set of duplicated functions
[18:28:21 CEST] <ubitux> there are abi issues if i "factor them all"
[18:28:31 CEST] <ubitux> they lie in different libraries
[18:29:06 CEST] <wm4> you don't have to replace the existing code... that's obviously much harder
[18:29:55 CEST] <ubitux> then i'm not sure what you are asking me to do
[18:30:08 CEST] <ubitux> what's half assed here?
[18:31:48 CEST] <BBB> didnt we have a native daala decoder submitted at some point?
[18:31:52 CEST] <BBB> or am I misremembering?
[18:32:29 CEST] <BBB> yes; [RFC 1/3] daaladec: Implement a native Daala decoder
[18:32:35 CEST] <BBB> atomnuker: why isnt that in? :-p
[18:32:54 CEST] <jamrial> because it's obsolete by now? :p
[18:33:03 CEST] <wm4> ubitux: I hoped you'd add a generic side data list struct or so, which could be used in the future for other cases where we need side data, or to replace the existing side data mess eventually
[18:33:05 CEST] <BBB> omg the Q&A in that patchset is amazing (in 20/20 hindsight)
[18:33:07 CEST] <BBB> Q: What about AOMedia and the IETF?
[18:33:08 CEST] <BBB> A: There's a (high) chance that the current libdaala codebase will be
[18:33:09 CEST] <BBB>    used, and thus this decoder will continue tracking whatever becomes
[18:33:09 CEST] <BBB>    of libdaala.
[18:33:18 CEST] <BBB> (side note: they did not use libdaala :-p)
[18:33:32 CEST] <wm4> ubitux: in that aspect duplicating the side data stuff yet again is half-assed :)
[18:33:39 CEST] <BBB> Q: What if libdaala dies and AOMedia/IETF come up with something
[18:33:40 CEST] <BBB>    completely different (unlikely).
[18:33:40 CEST] <BBB> A: This decoder will continue tracking whatever they come up with [..]
[18:33:49 CEST] <BBB> atomnuker: so did you continue tracking?
[18:35:41 CEST] <ubitux> wm4: so you want yet another implementation of side data?
[18:35:55 CEST] <wm4> ubitux: yes, but this time a reusable one
[18:36:00 CEST] <wm4> think AVSideDataList
[18:36:19 CEST] <wm4> and AVFormatContext would have a "AVSideDataList *side_data;" field
[18:37:27 CEST] <ubitux> ok
[18:38:04 CEST] <atomnuker> BBB: nope, the used the libvpx codebase because no one had strong feelings about which codebase to use except hardware guys who thought it would be quicker since its more complete
[18:38:14 CEST] <atomnuker> hindsight is always 20/20, no?
[18:38:29 CEST] <BBB> of course, but its fun to go back in time and look at what we said back then ;)
[18:38:49 CEST] <atomnuker> or didn't say in this case
[18:38:57 CEST] <BBB> yeah
[18:39:22 CEST] <wm4> jamrial: do you have an idea how such a new generic side data API should handle side data element sizes?
[18:40:48 CEST] <jamrial> is the way the existing packet/frame side data does it inadequate?
[18:41:39 CEST] <wm4> it's pretty roundabout
[18:41:47 CEST] <wm4> and most side data types have only 1 size
[18:42:10 CEST] <wm4> but I'm worried that the side data impl doesn't always have the side data element structs available
[18:42:30 CEST] <wm4> because the impl. is in libavutil, and various side data could be defined in the other libs
[18:43:14 CEST] <wm4> we could do the following: 1. require all side data type structs to be defined in libavutil, 2. have the side data impl. know about _all_ of them
[18:43:34 CEST] <wm4> so the side data allocator could be part of the side data impl.
[19:30:45 CEST] <ldts> wm4: hi
[19:31:49 CEST] <ldts> wm4: can you hold v2 of the patch that I just sent please? I talked to the venus developer and a dummy size of 0 on the buffer should not be used (the kernel will raise a warning which I didnt notice since I didnt have my console enabled); apparetly the driver needs to be fixed
[19:32:16 CEST] <ldts> wm4: will send v3 properly fixed now
[19:32:45 CEST] <wm4> k
[19:33:15 CEST] <wm4> I'm amazed that this requires discussion with a developer of a certain codec - shouldn't this be part of the kernel API/ABI instead?
[19:41:52 CEST] <ldts> wm4: the v4l2 core changed recently ; it used to accept null size as an eos
[19:42:30 CEST] <ldts> wm4: then it changed to the flag and it raises a warning on the console when size 0 is used to let the driver developer know that such a driver should be fixed
[19:43:39 CEST] <ldts> wm4: this means that the data in the buffer carrying the flag should be valid if possible (not an issue if it is not...so bytesize=1 is what most people use)
[19:44:34 CEST] <ldts> wm4: which leads to my question, is there any way in ffmpeg to identify the last frame from the stream with valid data? then I wont have to send a dummy buffer...
[19:44:58 CEST] <wm4> no, unless you buffer a packet to see whether EOF will come
[19:45:35 CEST] <wm4> what would a buffer with bytesize=1 contain?
[19:46:06 CEST] <ldts> wm4: it would contain nothing, no real data 
[19:46:36 CEST] <ldts> wm4: just works around the kernel warning when 0 is used (I dont like doing it)
[19:46:39 CEST] <wm4> so maybe a (uint8_t)0?
[19:47:24 CEST] <ldts> wm4: as data?
[19:48:48 CEST] <wm4> I mean as buffer contents
[19:49:20 CEST] <cone-906> ffmpeg 03Carl Eugen Hoyos 07master:dc522cfa0789: lavf/version: Bump minor after dv1394 removal.
[19:49:20 CEST] <wm4> it's 1 byte, but what is the value of that byte?
[19:52:02 CEST] <ldts> wm4: I guess it can be anything - testing on my end it doesnt make any difference; I think the cleanest as you said is to buffer the input data and set the flag properly on the last valid buffer.
[19:52:45 CEST] <ldts> wm4: however that will not work on drivers not using the flag....
[19:53:25 CEST] <ldts> wm4: but I think ffmpeg should just follow the API and those drivers that fail should be updated.
[19:55:24 CEST] <wm4> my guess would be that the drivers try to parse any input as Annex B data
[19:55:37 CEST] <wm4> anyway, I don't understand why bytesize=0 is not accepted
[19:56:54 CEST] <ldts> wm4: it is accepted but the v4l2 kernel maintainers want to move away from it so you get a nasty warning in the console
[19:56:57 CEST] <ldts> https://hastebin.com/qomonitacu.xml
[19:57:51 CEST] <wm4> why do they want to move away from it?
[19:59:32 CEST] <ldts> ldts:  I believe it is the thought of having a dummy buffer pushed to the driver to indicate EOS...makes sense to me as well - it seems wrong 
[20:00:08 CEST] <ldts> wm4: it makes much more sense that the last buffer with valid data should carry the flag
[20:01:05 CEST] <ldts> wm4: I'll try to do this buffering on my end (I hope it is not too nasty)
[20:01:45 CEST] <wm4> that increases the latency by 1 frame for absolutely no reason
[20:02:05 CEST] <wm4> in general a demuxer or application won't really know whether a frame is the last one
[20:02:27 CEST] <wm4> especially in ffmpeg it just doesn't work this way
[20:02:51 CEST] <wm4> I don't see how a 1 byte dummy buffer is better than just a 0 sized buffer either
[20:03:11 CEST] <ldts> ldts: agreed...then maybe I should send the dummy (with byte=1 to avoid the kernel warning) and re-open the discussion with the kernel maintainers?
[20:03:42 CEST] <wm4> yeah
[20:03:46 CEST] <ldts> wm4: 1 byte just works around the warning...it is not accepted either but does the trick since the hardware will handle it
[20:04:16 CEST] <ldts> wm4: ok. will reopne the thread - can I add you to it?
[20:04:39 CEST] <wm4> sure, but note I'm not subscribed to any kernel mailing list
[20:05:25 CEST] <ldts> ldts: ok. will keep you updated. gtg now
[20:05:42 CEST] <ldts> wm4: will send v3 later today with byte size = 1
[20:17:22 CEST] <cone-906> ffmpeg 03James Almer 07master:55cc0bccf357: Revert "Merge commit 'a97563c889fefd81ad6b3758471434d8c2e2e550'"
[20:30:41 CEST] <kurosu_> who is interested in yadif and/or edited it? elenril@#libav-devel may want rewriting it
[20:41:53 CEST] <durandal_1707> why rewrite?
[20:43:18 CEST] <iive> there are improved deinterlacers
[20:46:54 CEST] <iive> kurosu: what is the target of the yadif rewrite by elenril? better looking C code? improved speed? better algorith/working/results?
[20:46:55 CEST] <BtbN> And because of that you re-write an existing one?
[20:47:11 CEST] <BtbN> I wasn't aware of any issues with yadif.
[20:47:28 CEST] <BtbN> Except for some tied to the algorithm, and changing the algorithm of a pre-existing deinterlacer seems weird
[20:47:52 CEST] <kurosu> Just notes saying rewrite
[20:48:49 CEST] <kurosu> Last I actually heard from him sounded more conservative, like bugfix
[20:49:19 CEST] <kurosu> Hence the 'may'
[20:49:55 CEST] <iive> what bugs?
[20:50:00 CEST] <kurosu> I think the filter can badly overread under conditions in libav
[20:50:34 CEST] <kurosu> This might have been fixed in ffmpeg, I wouldn't know
[20:50:56 CEST] <iive> the original yadif was designed to overread, but I think that the ffmpeg port takes care of that.
[20:51:42 CEST] <kurosu> In any case, if anyone cares, I'll leave it up to inquire
[20:52:03 CEST] <iive> what does that mean?
[21:09:12 CEST] <jamrial> iive: that if you care about yadif, you may want to discuss or keep track of what elenril plans to do
[21:09:31 CEST] <iive> hahaha
[21:17:48 CEST] <cone-906> ffmpeg 03Kaustubh Raste 07master:deeaaba1ab1e: avcodec/mips: preload data in hevc sao edge 45 degree filter msa functions
[21:17:49 CEST] <cone-906> ffmpeg 03Kaustubh Raste 07master:ed1586b921d7: avcodec/mips: Removed generic function call in avc intra msa functions
[21:17:50 CEST] <cone-906> ffmpeg 03Kaustubh Raste 07master:10ab5534e043: avcodec/mips: Improve avc weighted mc msa functions
[21:17:51 CEST] <cone-906> ffmpeg 03Kaustubh Raste 07master:b8854e2439c3: avcodec/mips: Improve avc chroma vert mc msa functions
[21:17:52 CEST] <cone-906> ffmpeg 03Kaustubh Raste 07master:6796a1dd8c14: avcodec/mips: Improve avc put mc 20, 01 and 03 msa functions
[21:18:49 CEST] <jkqxz> LongChair:  Thanks, looking at it now.
[21:23:54 CEST] <LongChair> cool :)
[21:53:18 CEST] <cone-906> ffmpeg 03Diego Biurrun 07master:9127ac5ebc94: configure: Add name parameter to require_pkg_config() helper function
[21:53:19 CEST] <cone-906> ffmpeg 03James Almer 07master:d1256750e896: Merge commit '9127ac5ebc941d5e54828a91e5072c876be8ec42'
[22:35:16 CEST] <feliwir> hey, why does AVFrame contain 2 data pointers when decoding audio?
[22:35:26 CEST] <feliwir> what is the meaning of each?
[22:35:42 CEST] <JEEB> if it's planar audio then you have the channels separate
[22:36:15 CEST] <nevcairiel> planar would be the only case where you get multiple, so yeah, channels
[23:08:29 CEST] <feliwir> JEEB, it is planar
[23:08:40 CEST] <feliwir> but how would i play that back with OpenAL :(
[23:09:09 CEST] <JEEB> if you need interleaved you either use libswresample which has an optimized thing around, or do your own
[23:11:20 CEST] <feliwir> ok, guess that's the way to go then
[23:14:27 CEST] <wm4> if you were to simulate 3D audio with openal, planar would actually be more convenient because you could feed each plane directly to an openal buffer
[23:14:48 CEST] <JEEB> true
[23:43:14 CEST] <tmm1> i'm trying to figure out how to add a configure check for kCMVideoCodecType_HEVC
[23:43:19 CEST] <tmm1> it's an enum value.. should i use check_type ?
[23:45:01 CEST] <wm4> hm I guess you want check_code
[23:45:08 CEST] <wm4> which takes an arbitrary statement
[23:45:29 CEST] <cone-906> ffmpeg 03Lionel CHAZALLON 07master:f3aefb3e1c3c: lavc: Add support for RockChip Media Process Platform
[23:49:50 CEST] <tmm1> hmm, and then what? define some flag?
[23:50:25 CEST] <jkqxz> What's wrong with check_type?
[23:51:13 CEST] <jkqxz> Oh, enum value doesn't work there.  Ignore that.
[23:51:50 CEST] <wm4> there are plenty of examples, e.g. check_code cc linux/videodev2.h "int i = V4L2_PIX_FMT_MPEG1;" && enable mpeg1_v4l2_m2m
[23:51:51 CEST] <tmm1> look like check_func_headers was used before (260ea7a7b3)
[23:52:28 CEST] <tmm1> but that got rewritten into a runtime check.. that's probably what I should do too
[23:53:09 CEST] <BBB> wm4: what wrong with prores?
[23:53:16 CEST] <BBB> prores is awesome
[23:53:27 CEST] <BBB> its stupid. its simple. its braindead. its awesome
[23:53:37 CEST] <wm4> forcing half range
[23:53:41 CEST] <wm4> that's so backwards
[23:53:53 CEST] <BBB> :D its 12-bit so its not like it matters much in precision
[23:57:15 CEST] <kierank> wm4: half range?
[23:57:52 CEST] <wm4> I mean tv/mpeg/whatever range
[23:58:08 CEST] Action: kierank repeats same argument as at vdd
[23:58:15 CEST] <kierank> clipping is bad
[23:58:22 CEST] <kierank> tv range is necessary 
[00:00:00 CEST] --- Thu Sep 28 2017