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

[burek]

[01:48:32 CEST] <atomnuker> so it turns out debian no longer packages libschroedinger
[01:49:06 CEST] <llogan> the user didn't complain i guess
[01:49:10 CEST] <atomnuker> so there's but one way to encoder something dirac(-related) on debian
[01:49:20 CEST] <nevcairiel> its still in stable
[01:49:23 CEST] <atomnuker> *encode
[01:50:42 CEST] <nevcairiel> dont think dirac is that common of a usecase though
[01:51:45 CEST] <atomnuker> what if you wanted to know what people of the past 2 decades thought the future of video encoding would look like?
[02:08:14 CEST] <nevcairiel> should open a museum of video coding history
[03:38:45 CEST] <wm4> why the fuck do we have AVFrame.pkt_size
[03:39:50 CEST] <wm4> jamrial: were there any specific problems with this merge other than the pkt_size idiocy? (whose solution looks a bit dangerous)
[03:40:11 CEST] <jamrial> the one i pushed to my repo?
[03:40:32 CEST] <jamrial> the side data split thing was kinda annoying, but i worked around it
[03:40:39 CEST] <jamrial> should be gone with the major bump anyway
[03:41:53 CEST] <wm4> the side data splitting should actually become easier
[03:42:03 CEST] <jamrial> wm4: if copying pkt->size is not a good idea, we could do a full packet ref instead of just copy_props. it will mean copying the whole packet data, so kinda slow
[03:42:04 CEST] <wm4> because we no longer have to store a pointer to that packet
[03:42:46 CEST] <wm4> well the packet should be refcounted, so that would be cheap - on the other hand, it'd be better not referencing a potentially huge packet just because
[03:43:11 CEST] <wm4> the packet size could be a separate field in the internal struct, but that could cause more pain later on (potentially=
[03:44:01 CEST] <wm4> personally I'd prefer not having all these dumb AVRame.pkt_ fields, that just break with certain decoders anyway
[03:46:31 CEST] <wm4> apparently pkt_size was added for https://trac.ffmpeg.org/ticket/2027
[03:47:08 CEST] <jamrial> yeah, it was the ffprobe tests that failed without that change/hack
[03:47:23 CEST] <wm4> jamrial: so even though I have a strong opinion of this, I don't mind if you push your merge as-is...
[03:57:41 CEST] <jamrial> wm4: ok, will push it then
[03:59:09 CEST] <jamrial> regarding the commit that comes after that one, i got it mostly working as far as i could test
[03:59:16 CEST] <jamrial> what i couldn't test were crystalhd and cuvid decoders which are the only ones that actually use the new api, and need to be adapted for this change
[04:01:48 CEST] <wm4> not sure how that changes anything for the new API?
[04:02:00 CEST] <wm4> oh you mean the commit after that one
[04:02:07 CEST] <jamrial> it removes send_packet from avcodecinternal
[04:02:08 CEST] <jamrial> yeah
[04:03:00 CEST] <jamrial> the one ubitux and i asked if you could handle. i can push what i got to the above repo if you want to look at it
[04:03:07 CEST] <jamrial> i pretty much threw shit at the wall until something stuck :P
[04:04:03 CEST] <wm4> I sure wish merge commits were easier to read
[04:04:17 CEST] <jamrial> err, AVCodec, not AVCodecInternal sorry
[04:04:31 CEST] <jamrial> wm4: git diff prevcommit..currcommit
[04:04:48 CEST] <wm4> that's not 3-way
[04:04:52 CEST] <jamrial> or use github, which shows you the actual changes rather than the combined mess
[04:04:56 CEST] <jamrial> ah
[04:07:11 CEST] <jamrial> wm4: just pushed it
[04:07:37 CEST] <jamrial> 061a0c14bb merge to my repo, i mean
[04:12:46 CEST] <wm4> could you test cuvid? I think only philipl can test crystalhd
[04:14:35 CEST] <jamrial> no, i don't have nvidia hardware
[04:15:26 CEST] <jamrial> nevcairiel, philipl and BtbN might
[04:15:48 CEST] <wm4> I can test cuvid too, I think
[04:18:36 CEST] <jamrial> with the merge as i pushed it, the only difference i saw was with this one badly cut mpegts h264+aac file that dropped one frame when i tried to decode both streams at the same time
[04:19:28 CEST] <wm4> cuvid fails
[04:20:24 CEST] <wm4> ah you simply removed the send_packet callback
[04:20:34 CEST] <jamrial> yeah, i knew it would not work as is
[04:21:09 CEST] <jamrial> especially since according to the documentation Anton wrote, decoders using the new API need to call ff_decode_get_packet() themselves
[04:21:24 CEST] <wm4> yep
[04:21:36 CEST] <wm4> supposedly that should be a pretty simple conversion, I'll try it
[04:27:03 CEST] <wm4> too bad the bsf commit doesn't come first
[04:27:48 CEST] <jamrial> the one that adds autobsf to decoders?
[04:29:47 CEST] <wm4> yes
[04:35:22 CEST] <wm4> appears to work: http://sprunge.us/cWaE
[04:37:25 CEST] <wm4> maybe this is better: http://sprunge.us/JaGE
[04:38:27 CEST] <wm4> there's probably a way to make this more elegant
[04:38:47 CEST] <wm4> with autobsf some simplifications can be made anyway (probably)
[04:40:12 CEST] <jamrial> ok, amended the merge and pushed it
[04:40:30 CEST] <jamrial> crystalhd remains, and probably some more testing/reviewing than just fate
[04:40:59 CEST] <wm4> well I hope it doesn't get stuck in merge limbo for weeks
[04:42:05 CEST] <wm4> philipl: also, the generic avcodec code can now emulate the old API even if the decoder implements only the new API
[04:42:21 CEST] <wm4> philipl: so with that and autobsf, you should be able to drop a good chunk of code from cuvid.c
[05:15:53 CEST] <wm4> so does anyone know what the codec parameters frame_size field is important for when decoding?
[05:16:22 CEST] <wm4> avformat_find_stream_info() treats it as one of the required fields (like samplerate etc.)
[07:56:50 CEST] <alevinsn> ctx
[07:56:53 CEST] <alevinsn> oops
[08:51:38 CEST] <Dirk23> quit
[08:54:05 CEST] <maximilian> Hello everybody. I´m new to ffmpeg - I´m trying to decode an proprietar rtsp stream which contains an unusual h264 codec. I´ve to cut the first 16bytes from every data package send by the stream. With a progam live "openRTSP" there is an option to fit my needs. Is there anything similar in ffmpeg?
[09:20:25 CEST] <wm4> maximilian: can it be detected? if so, it'd probably be a change in the ffmpeg rtsp code?
[09:21:22 CEST] <maximilian> What do you mean with detected? Can you tell me where i can find the rtsp code? Maybe i can place some debug messages and find the code i´ve to change.
[10:26:29 CEST] <uau> wm4: IMO that the send API documentation has an inaccuracy is pretty clear - "will require you to call avcodec_receive_frame() multiple times afterwards before you can send a new packet" is not in fact true if it can return EAGAIN on first call
[10:28:55 CEST] <wm4> you could do s/will/might
[12:32:20 CEST] <nevcairiel> wm4: i dont think frame_size is particularly crucial, but its a clear sign that audio probing finished because its not a field typically provided outside of decoders, or something
[12:33:54 CEST] <wm4> the actual case was... complicated
[12:39:36 CEST] <cone-823> ffmpeg 03Brett Harrison 07master:6442e4ab3cab: avfilter/vf_drawtext: added expr evaluation to drawtext fontsize
[14:20:16 CEST] <funman> [SWR @ 0x14ba820] Rematrix is needed between 16 channels and 0 channels but there is not enough informatio
[14:20:19 CEST] <funman> n to do it
[14:20:28 CEST] <funman> no it's not needed
[14:35:59 CEST] <nevcairiel> your input has 16 and output 0 channel? sounds like some missing config
[15:45:54 CEST] <durandal_1707> thoughts about deflicker filter?
[15:49:39 CEST] <wm4> durandal_1707: hard to tell without any description, screenshots, demo videos, comparison with state of the art, etc.
[15:50:10 CEST] <wm4> your patch basically looks like an intransparent code dump
[15:51:29 CEST] <durandal_1707> wm4: because you are supposed to do ot and try it
[15:53:12 CEST] <durandal_1707> underlaying algo should be very trivial
[15:54:26 CEST] <durandal_1707> and to compare with others i need to buy propiertary software
[16:35:10 CEST] <BBB> michaelni: how do we mark students?
[16:38:08 CEST] <michaelni> i think ATM theres only the "want to mentor" button, admins will be able to select projects 18:00 (CEST)
[16:38:36 CEST] <nevcairiel> do you know already how many slots we have?
[16:38:48 CEST] <michaelni> 7 Slots Allocated
[16:39:06 CEST] <nevcairiel> neat thats q uite a lot
[16:43:24 CEST] <BBB> how do I reach thilo?
[16:46:11 CEST] <nevcairiel> mail  probably
[16:46:42 CEST] <BBB> I get an error from his provider that the mailbox is full
[16:46:55 CEST] <nevcairiel> from the mail he put on the gsoc page?
[16:47:33 CEST] <BBB> yes
[16:47:38 CEST] <kierank> durandal_1707: ask Dave ricr
[16:47:39 CEST] <kierank> Rice
[16:47:48 CEST] <kierank> It's the answer to all weird shit problems
[16:47:53 CEST] <nevcairiel> he sent mails to the ML in march still, so he was still alive then
[16:48:19 CEST] <nevcairiel> hm same mail address
[16:49:11 CEST] <BBB> maybe his provider is excessively crappy?
[16:50:07 CEST] <nevcairiel> it looks rather crappy
[16:55:57 CEST] <BBB> wtf you have to pay for it?
[16:56:04 CEST] <BBB> why oh dear lord
[17:07:20 CEST] <michaelni> BBB, btw if you still search for a way to contact thillo, then try asking carl, he might have his phone # for sending sms
[17:11:28 CEST] <BBB> carl isnt on IRC either :-/
[17:12:58 CEST] <durandal_1707> he is on trac
[17:20:19 CEST] <cone-823> ffmpeg 03Sasi Inguva 07master:87071478b4a7: tests/fate-run.sh: Show packet flags for fate gapless tests.
[18:13:27 CEST] <BBB> michaelni: how long do we have to assign students/slots?
[18:14:39 CEST] <michaelni> BBB until another organization assigns a slot to the student we want or April 24, 2017 at 18:00 (CEST)
[18:50:49 CEST] <j-b> BBB: number of slots are given?
[18:51:07 CEST] <BBB> yes
[18:51:12 CEST] <BBB> (says michaelni)
[19:16:27 CEST] <alevinsn> Is there still a flurry of activity surrounding the 3.3 release or has that died down?
[19:17:54 CEST] <jamrial> it's been released already
[19:19:53 CEST] <alevinsn> right, but it seems that there still continues to be some 3.3-related activity on the e-mail list
[19:21:16 CEST] <alevinsn> maybe it is unrelated
[19:21:39 CEST] <alevinsn> I just want to give the 3.3 release enough time before pinging the various patches that I've submitted to the e-mail list again
[19:30:15 CEST] <jamrial> alevinsn: no, there's no 3.3 activity in the ml
[19:30:27 CEST] <jamrial> the release was made days aog. the branch will get some backported fixes as needed for the point releases as usual, but that's about it
[19:30:49 CEST] <jamrial> if you submitted patches and didn't get a review in several days then just ping them
[19:31:28 CEST] <jamrial> development is always in the master branch
[19:35:03 CEST] <alevinsn> ok, thanks
[19:45:44 CEST] <alevinsn> jamrial:  Thought I'd get your opinion on a C/C++ thing
[19:45:54 CEST] <alevinsn> There are some defines that do something like
[19:46:18 CEST] <alevinsn> #define BLAH (AVRational) { 1, TIME_BASE_ETC }
[19:46:29 CEST] <alevinsn> and you use it like
[19:46:33 CEST] <alevinsn> time_base = BLAH;
[19:46:54 CEST] <alevinsn> that doesn't work on MSVC for C++ files and complains with the same error that broke the Coverity build
[19:47:07 CEST] <alevinsn> what I don't understand is, why even have the (AVRational) cast?
[19:47:18 CEST] <alevinsn> it works without the cast
[19:47:53 CEST] <alevinsn> at least with MSVC C++, but it seems like it would work without the cast in general
[19:49:25 CEST] <nevcairiel> some cases need the cast
[19:49:35 CEST] <nevcairiel> if you u se it for a function argument i think
[19:54:25 CEST] <nevcairiel> but compound literals like that are generally not valid in C++ i think
[20:49:51 CEST] <borgmann> Ronald?
[20:50:49 CEST] <borgmann> rsbultje?
[20:52:10 CEST] <kierank> BBB: ^
[20:53:04 CEST] <BBB> borgmann: hi!
[20:53:13 CEST] <borgmann> Thanks!
[22:55:57 CEST] <BtbN> Will the decklink thing be fixed, or should I disable its coverity testing?
[23:04:13 CEST] <funman> BtbN: what's broken?
[23:04:37 CEST] <BtbN> funman, building the decklink cpp stuff with higher assert levels
[23:04:58 CEST] <funman> is that on fate or somewhere?
[23:05:16 CEST] <BtbN> https://travis-ci.org/FFmpeg/FFmpeg-Coverity/builds/223654343#L1135
[23:05:23 CEST] <funman> thanks
[23:05:28 CEST] <BtbN> it happens on every build with decklink enabled and assert level >1
[23:05:51 CEST] <funman> was going to say bad things about C++
[23:06:13 CEST] <nevcairiel> using syntax thats invalid for c++ isnt c++s fault =p
[23:06:17 CEST] <BtbN> Aparently just requiring a higher C++ standard would fix it, from what I read?
[23:06:22 CEST] <nevcairiel> no
[23:06:26 CEST] <nevcairiel> we already use newer standards
[23:06:57 CEST] <BtbN> well, there was a patch which broke the build, it should either be fixed or reverted
[23:07:17 CEST] <nevcairiel> its a debug build, don't go crazy
[23:07:55 CEST] <RiCON> it also breaks a non-debug build, but only if you include libzvbi
[23:08:01 CEST] <RiCON> so not too serious either
[23:08:03 CEST] <BtbN> There's a fix in the ml already, but it kind of was forgotten.
[23:10:03 CEST] <nevcairiel> libzvbi probably can't be fixed other then disabling it in this combination
[23:10:51 CEST] <nevcairiel> (to be fair its also not a new "breakage", before you couldn't build with decklink and w32threads at all, now you can)
[23:11:13 CEST] <nevcairiel> if you build with pthreads it probably still works, i would hope
[23:13:20 CEST] <BtbN> the coveirty build is on Linux, gcc. No w32pthreads involved.
[23:13:40 CEST] <BtbN> or do you mean only zvbi?
[23:14:07 CEST] <nevcairiel> zvbi
[23:28:03 CEST] <jamrial> BtbN: it wasn't forgotten, just sorta disliked for chaging a c header to work when included from c++ sources
[23:32:01 CEST] <BtbN> hm, will anything change about this soon? Otherwise I'll just disable decklink in the builds for now.
[23:39:00 CEST] <cone-122> ffmpeg 03Carl Eugen Hoyos 07master:b6a839624534: lavc/motion_est: Fix undefined negative left shifts.
[23:39:00 CEST] <cone-122> ffmpeg 03Carl Eugen Hoyos 07master:c6aaf0840cf9: lavf/mov: Only copy extradata if it exists.
[23:54:31 CEST] <cone-122> ffmpeg 03Michael Niedermayer 07master:164758a831b1: tools/target_dec_fuzzer: Fuzz video decoder related fields in context.
[00:00:00 CEST] --- Thu Apr 20 2017