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

[burek]

[00:42:02 CEST] <rcombs> https://forums.developer.apple.com/thread/63513 bahahahaha
[00:43:22 CEST] <JEEB> :D
[00:43:31 CEST] Action: JEEB is waiting for sierra to install
[00:44:34 CEST] <rcombs> it took like 3 posts to convince them that yes that's what it's doing
[00:45:01 CEST] <JEEB> ufufu
[00:45:01 CEST] <rcombs> had to actually point at the exact lines of disassembly doing it
[00:45:06 CEST] <JEEB> :D
[00:45:15 CEST] <rcombs> apparently literally nobody ever tested this API
[00:45:42 CEST] <rcombs> hope nobody was relying on the broken behavior 'cause if so you'll crash in 10.12
[04:30:05 CEST] <jamrial> ubitux, nevcairiel: ok so, before this patch bitstream filters would be initialized when they were first needed instead of the entire chain initialized all at once inside this new init_output_bsfs() function
[05:07:36 CEST] <jamrial> before: write_frame() calls av_apply_bitstream_filters(), which inits the first filter in the chain and takes the stream's extradata (from a tmp avctx), filters the first packet and copies the potentially modified extradata back to the avctx
[05:07:51 CEST] <jamrial> av_apply_bitstream_filters() then proceeds to do the same for the rest of the filters in the chain. Inits them taking the extradata in the avctx (last modified by the previous filter), filters their first packet and copies the extradata back to avctx
[05:08:22 CEST] <jamrial> this results in the stream's extradata propagated through all the bitstream filters after being processed by both init() and the first filter() call from each of them. write_frame() in ffmpeg.c then copied the extradata to the muxer
[05:08:39 CEST] <jamrial> after: init_output_bsfs() inits the whole filter chain but without filtering any packet, propagating the extradata through all of them but only as modified by their init() functions. the extradata is copied to the muxer there, and never again.
[05:09:08 CEST] <jamrial> aac_adtstoasc creates the asc extradata in the first packet and not init(), so with my patch above said extradata is copied to the muxer, and much like before fate passes.
[05:09:22 CEST] <jamrial> but in a filterchain scenario (say, -bsf:a aac_adtstoasc,noise) the aac_adtstoasc extradata would never make it to the next filter, which is the one that should ultimately propagate the extradata to the muxer
[05:10:49 CEST] <jamrial> so the solution? find a way to propagate the extradata as modified by the first filter() call for each bitstream filter
[05:11:51 CEST] <jamrial> maybe by making it work like before, init and filter first packet at the same time for each filter, meaning no init_output_bsfs()
[05:12:23 CEST] <jamrial> this could be within ffmpeg.c or by making a new av_apply_bitstream_filters() + av_bitstream_filter_filter() function that doesn't use the old api
[05:14:36 CEST] <jamrial> also, i noticed we have a bsf list API that looks really cool
[05:15:18 CEST] <jamrial> just made ffmpeg.c use it and works wonders, but it also inits all the filters at the same time and doesn't propagate extradata after the first filter() call
[05:15:57 CEST] <jamrial> using it however simplified the ffmpeg.c code considerably
[05:18:53 CEST] <jamrial> we could ask Jan Sebechlebsky (the author) to make it propagate the extradata after the first filter() call
[05:25:40 CEST] <jamrial> http://pastebin.com/QxP0h07z <--- ffmpeg.c using the bsf list API
[08:39:09 CEST] <cone-432> ffmpeg 03Carl Eugen Hoyos 07master:c54eef46f990: lavc/avpacket: Fix undefined behaviour, do not pass a null pointer to memcpy().
[08:57:02 CEST] <cone-432> ffmpeg 03Carl Eugen Hoyos 07release/3.1:6fc29572fbf8: lavc/avpacket: Fix undefined behaviour, do not pass a null pointer to memcpy().
[10:58:15 CEST] <BtbN> michaelni, so you think av_find_best_stream should still take hardware decoders into account?
[11:00:17 CEST] <BtbN> Well, yeah, if the codec in the stream already is a hw decoder, it definitely should
[11:11:17 CEST] <BtbN> Can I fill the gaps in AV_CODEC_CAP_*? Or should I add new ones at the very end?
[11:13:12 CEST] <iive> there is no gap...
[11:13:19 CEST] <iive> ;)
[11:13:30 CEST] <BtbN> well, 1 << 2 and 1 << 4 don't exist.
[11:13:38 CEST] <ubitux> BtbN: can't we rely on the parser for the probing instead?
[11:14:07 CEST] <iive> BtbN: what flag do you want to add?
[11:14:16 CEST] <BtbN> "Don't use this codec for probing"
[11:14:34 CEST] <iive> is that hardware related?
[11:14:54 CEST] <BtbN> Well, it primarily affects hardware decoders, but it's not strictly hardware related
[11:15:15 CEST] <BtbN> ubitux, what do you mean?
[11:15:35 CEST] <ubitux> i mean that the probe should not need a decoder
[11:15:41 CEST] <ubitux> just a parser
[11:15:52 CEST] <ubitux> but that's a general issue to fix so you can ignore me
[11:16:08 CEST] <BtbN> Wouldn't that mean that ffmpeg would need a parser for every single format it has a decoder for?
[11:16:12 CEST] <iive> BtbN: what other codecs you don't want to be used for probe?
[11:16:30 CEST] <ubitux> BtbN: if there is a parser we use it, otherwise we use the decoder?
[11:16:31 CEST] <BtbN> iive, for example the openh264 one would be a potential candidate.
[11:16:46 CEST] <iive> why?
[11:17:04 CEST] <BtbN> Because the internal decoder/parser yields more information
[11:17:09 CEST] <iive> because it have less feature support than ff h264?
[11:17:44 CEST] <BtbN> But what would be the difference if it was hardware-only?
[11:17:49 CEST] <iive> but what if ffmpeg is compiled with ff h264 disabled? 
[11:18:12 CEST] <iive> BtbN: one of "missing" flags is hwaccel
[11:18:51 CEST] <BtbN> It would just use whatever avcodec_find_decoder returns in that case.
[11:19:27 CEST] <BtbN> it's not meant as a "stirctly don't ever use this for probing". More like a "prefery anything else for probing"
[11:19:42 CEST] <iive> the thing here is that you want to have priority and test order, instead of flag
[11:20:09 CEST] <BtbN> But I'd be fine with a hwaccel capability as well
[11:20:14 CEST] <BtbN> it solves my issue just fine :D
[11:21:11 CEST] <iive> i'm not really sure if it does, because e.g. ff h264 should be flagged as hwaceel , because it "could" provide acceleration.
[11:21:57 CEST] <BtbN> I wouldn't use the CAP_HWACCEL for the native ones
[11:22:16 CEST] <BtbN> they are a special case. I'd use the hwaccel cap for self-contained hwaccel decoders, like cuvid or nvenc
[11:22:26 CEST] <BtbN> and qsv
[11:22:46 CEST] <iive> so, basically decoders that don't have parsers?
[11:23:17 CEST] <BtbN> They do have parsers, how would they parse the data otherwise?
[11:23:36 CEST] <BtbN> The native one is just better, and avoids spinning up multiple hardware decoder instances, which might be limited.
[11:23:44 CEST] <iive> but they don't provide the parsed information to you/ffmpeg
[11:24:00 CEST] <BtbN> At least cuvid does, but not as much information as the native one.
[11:24:38 CEST] <BtbN> Using cuvid for probing works fine though. So primary idea here is to avoid spinning up another instance of cuviddec that's just sitting around doing nothing
[11:25:42 CEST] <iive> new noprobe flag is better idea than hwaccel.
[11:26:37 CEST] <iive> but imho ubitux is right, the correct solution is to use parsers.
[11:26:53 CEST] <BtbN> AV_CODEC_CAP_AVOID_PROBE is what I'd call it
[11:27:09 CEST] <iive> maybe probing?
[11:27:33 CEST] <iive> but yeh, avoid is ok.
[11:27:46 CEST] <BtbN> rewriting avformat_find_stream_info to use parsers if available would be a quite a big change
[11:28:04 CEST] <BtbN> There also isn't a format agnostic probing API, so it would be a lot of codec specific code
[11:28:26 CEST] <BtbN> Using the native decoder to probe the stream seems like an ok solution to me
[11:29:15 CEST] <iive> yes.
[11:29:29 CEST] <ubitux> note the h264 parser doesn't depend on the decoder anymore
[11:29:39 CEST] <ubitux> (contrary to the horror we added in hevc)
[11:29:47 CEST] <BtbN> yeah, but there's also HEVC, VP8, VP9, mpeg2, ...
[11:29:48 CEST] <iive> i think that some of the recent changes in h264 were separating the parsing code and making the decoder use it internally.
[12:31:07 CEST] <mifritscher> hi
[12:31:29 CEST] <kierank> hi
[12:37:45 CEST] <mifritscher> fate hasn't its own channel, has it?
[13:19:26 CEST] <wm4> a notification channel for issues and fate would be good
[13:19:35 CEST] <cone-432> ffmpeg 03Timo Rothenpieler 07master:6d9a46e884d0: avformat/utils: force native h264 decoder for probing
[13:19:40 CEST] <wm4> and for git too
[13:20:01 CEST] <wm4> BtbN: also that's not really a solution, is it...
[13:20:14 CEST] <BtbN> wm4, it's a crash fix
[13:20:29 CEST] <wm4> a quite ridiculous one
[13:20:52 CEST] <wm4> the avpriv function should at least check whether it's really the h264 decoder, and error out if it isn't
[13:21:00 CEST] <BtbN> the probing code assumes the native h264 decoder is used. So it either has to stop doing that, or make sure it's actually using it.
[13:21:43 CEST] <mifritscher> wm4: I don't meant the results of automated fate runs, but creating new test ;-)
[13:39:18 CEST] <BtbN> Is adding a new codec cap flag a minor or micro bump?
[13:43:14 CEST] <wm4> mifritscher: I don't think so, that would be in scope of this channel
[13:50:12 CEST] <rcombs> BtbN: avformat_find_stream_info already uses parsers if available, and in fact already doesn't open the decoder if the parser exports all the data it's looking for
[13:50:23 CEST] <rcombs> just, no current parsers export everything it wants
[13:51:52 CEST] <mifritscher> wm4: ok, thanks :-) Im going to try to port the existing ffserver test to fate
[13:52:18 CEST] <mifritscher> btw, I'm the guy with the cygwin problem - so I can be contacted here as well ;)
[13:52:47 CEST] <rcombs> the biggest problem is that find_stream_info expects a (pixel|sample) format to be exported, and it doesn't really make sense to do that in a parser, since that's dependent on the decoder you end up using
[13:53:28 CEST] <rcombs> it'd be nice to have some way to export information about the planes (bit depth, color space, subsampling) separately from an actual pix_fmt
[13:54:34 CEST] <BtbN> Hmm... so is it actually an issue that find_stream_info would probe yuv420p for h264, while cuvid outputs nv12?
[13:54:36 CEST] <BtbN> It seems to work fine.
[13:55:26 CEST] <rcombs> I don't know if it causes any problems (maybe something around filter renegotiation?)
[13:55:31 CEST] <rcombs> it's just semantically weird
[13:55:47 CEST] <BtbN> At least ffmpeg.c doesn't seem to mind.
[13:56:07 CEST] <nevcairiel> the filter stuff should hopefully be fixed in the future when ffmpeg.c stops relying on the avformat infos so much
[13:56:51 CEST] <nevcairiel> and i dont see a problem with parsers producing pix_fmt info as long as it uses the native formats and not some packed variants that some other decoders might use
[13:59:53 CEST] <wm4> nevcairiel: well, the avformat infos are apparently an API feature
[14:00:32 CEST] <nevcairiel> well anything in codecpar is fine, but one shouldnt complain if an alternate decoder then produces a different pixfmt
[14:00:45 CEST] <nevcairiel> but like I said, an incoming merge from avconv fixes that by delaying filter init until later
[14:05:07 CEST] <wm4> which is why a parser should really take care of this
[16:00:12 CEST] <v995> hi everyone.. i would like to know how to start contributing to ffmpeg for the Outreachy internship..
[16:01:51 CEST] <Chloe> hi v995, I assume you've seen? https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12 In particular the getting started, and qualification tasks sections
[16:08:43 CEST] <philipl> BtbN: you ok with the header patches?
[17:05:07 CEST] <BtbN> philipl, i'm perfectly fine with that, but I kind of don't want to decide about bundling more headers on my own.
[17:06:22 CEST] <philipl> BtbN: Doesn't seem like anyone else cares to express an opinion.
[17:06:50 CEST] <BtbN> yeah. I'd merge some of those commits though, otherwise it seems fine.
[17:07:20 CEST] <philipl> Sure, I can do that. I'd keep the base change that adds the files, but I can merge the other three.
[17:07:55 CEST] <philipl> If you're ok with it, I can squash them and push myself. Otherwise I can re-send.
[17:08:19 CEST] <ubitux> jamrial: saw your messages from yesterday
[17:08:29 CEST] <ubitux> do you plan to send a patchset for this?
[17:09:04 CEST] <ubitux> how should we proceed? i'd really like to be able to go ahead with the merges
[17:09:06 CEST] <Chloe> SDL vote tally day today, right?
[17:29:36 CEST] <jamrial> ubitux: i'm trying to implement this, yes
[17:29:55 CEST] <jamrial> Chloe: yes
[17:30:24 CEST] <nevcairiel> did anyone actually cast a clear vote against that? All i remember is a bunch of discussion and whatnot, dont remember seeing carl cast a clear vote, for example
[17:32:48 CEST] <jamrial> yes, there were about four clear votes in favor of dropping sdl1
[17:33:33 CEST] <jamrial> wm4: ^ if you want to vote, do it asap
[17:35:34 CEST] <wm4> vote what
[17:35:41 CEST] <wm4> can I even vote
[17:36:22 CEST] <Shiz> i vote in favor
[17:37:23 CEST] <Chloe> Shiz: you cant vote (and neither can I)
[17:37:33 CEST] <Shiz> watch me
[17:37:41 CEST] <Chloe> >.<
[17:38:10 CEST] <Chloe> wm4: for/against dropping sdl1
[17:38:46 CEST] <wm4> that's still going on?
[17:39:21 CEST] <Chloe> it was a week vote
[17:39:35 CEST] <nevcairiel> ends today, so yeah
[17:41:31 CEST] <jamrial> wm4: yes, you can
[17:51:40 CEST] <jamrial> ubitux: is this this bsf stuff a blocker for further merges for that matter?
[17:51:52 CEST] <jamrial> you may be able to resume them while i try to implement this properly
[17:52:07 CEST] <jamrial> the codecpar commit was the real blocker afaik
[17:57:14 CEST] <ubitux> mmh i can try the merge again, but that bsf stuff is part of getting rid of the remaining codec uses
[17:57:36 CEST] <ubitux> which is probably required to go ahead sanely wrt the merge
[18:00:01 CEST] <jamrial> ubitux: alright
[18:02:49 CEST] <Chloe> jamrial: I'm going to remove the SDL1 compat stuff, and resend. I think it's pretty clear that dropping SDL1 won. (unless you'd like me to wait?)
[18:03:28 CEST] <jamrial> is all the sdl1 code ported? both outdevs and ffplay?
[18:03:41 CEST] <Chloe> everything is
[18:03:59 CEST] <jamrial> ok, wait until after i close the voting
[18:04:24 CEST] <mifritscher> how critical / how high is the priority for a broken fate test in current git?
[18:06:02 CEST] <mifritscher> 3.1.3 works, current git throw an error in lavf-aiff (I've a diff, but the aivf-aiff.err is empty)
[18:06:09 CEST] <Chloe> mifritscher: probably better to fix it sooner rather than later
[18:06:45 CEST] <mifritscher> Chloe: so I should write something to the ffmpeg-devel list?
[18:07:10 CEST] <Chloe> if you have a patch, otherwise just put it on trac as a regression. 
[18:08:57 CEST] <mifritscher> no, I have no patch, original unchanged git master ;-)
[18:09:09 CEST] <Chloe> I mean, if you have a fix.
[18:09:19 CEST] <mifritscher> yes ;-)
[18:09:41 CEST] <mifritscher> in the meantime, is there a quick way to disable the test or let fate not abort?
[18:10:01 CEST] <mifritscher> (besides make -i)
[18:10:17 CEST] <Chloe> not sure, but if there's a particular test you want to run then you could do make fate-testname
[18:10:45 CEST] <mifritscher> ah, thanks for the hint!
[18:10:56 CEST] <Chloe> I'm doing a fate test now, I find it odd that the aiff fate fail wasnt found earlier, also considering it doesnt look like there was much done to aiff
[18:10:56 CEST] <mifritscher> yes, I want to write a few tests
[18:14:18 CEST] <mifritscher> http://pastebin.com/RdT1mTXr <- the output
[18:21:32 CEST] <mifritscher> hmm, it seems to be the first test
[18:21:55 CEST] <Chloe> it passes for me
[18:22:10 CEST] <Chloe> try a make clean, reconfigure, and then make
[18:22:55 CEST] <mifritscher> yes, I'm doing this now
[18:23:09 CEST] Action: mifritscher wants to have a faster computer
[18:23:54 CEST] <Chloe> me too :)
[18:24:07 CEST] <Chloe> takes ~10 minutes to compile ffmpeg
[18:24:21 CEST] <Chloe> I generally make myself a cup of tea while I wait
[18:25:06 CEST] <mifritscher> 5 minuts für configuring, 20 minutes for compiling
[18:37:52 CEST] <mifritscher> while I'm waiting: what should I do with the rtsp-server in the ffserver.c? Is there an idea how to integrate it into libavformat ?
[18:40:20 CEST] <wm4> was ffmpeg originally GPL? when did it switch to LGPL?
[18:40:48 CEST] <BtbN> philipl, feel free to push.
[18:41:59 CEST] <wm4> -Gerard Lantau (glantau at yahoo.fr).
[18:41:59 CEST] <wm4> +Fabrice Bellard.
[18:42:00 CEST] <wm4> xD
[18:42:31 CEST] <wm4> so according to git blame, since 2002
[18:43:31 CEST] <mifritscher> ok, make clean didn't help
[18:44:27 CEST] <Chloe> mifritscher: git diff, check if nothing is actually changed.
[18:48:35 CEST] <Compn> wm4 : lol, yeah he didnt want his name on it :D
[18:48:38 CEST] <mifritscher> git diff shows nothing, git status shows only fate-suite/ and tests_fate_config (which isn't used)
[18:48:53 CEST] <Compn> wm4 : i think diego helped with finding devs for relicensing gpl>lgpl long ago
[18:49:00 CEST] <Compn> you should ask him for emails too
[18:49:25 CEST] <Compn> probably ancient emails by now
[18:50:04 CEST] <Chloe> mifritscher: make fate-lavf-aiff V=1
[18:50:19 CEST] <Chloe> check what command its running then the whack it in gdb (or similar)
[18:56:07 CEST] <mifritscher> uwah, I think I got the problem. It seems that fate expects to use an installed version of ffmpeg instead of using the one in the current directory
[18:57:12 CEST] <mifritscher> it uses the one in the current directory regarding to the command line (/home/michaelfritscher/ffmpeg/ffmpeg/ffmpeg <parameters>, but I think in this situation old librariers are used instead of the ones in the current directory -> peng
[18:57:21 CEST] <mifritscher> seems to work now
[18:57:23 CEST] <mifritscher> thanks!
[19:01:18 CEST] <Chloe> I dont think it should be using the system's ffmpeg
[19:01:29 CEST] <Chloe> (although maybe I'm wrong)
[19:05:35 CEST] <mifritscher> it is not using the systems ffmpeg, but the systems libav* it seems(!)
[19:10:31 CEST] <wm4> ffmpeg uses libav* library names
[19:10:50 CEST] <wm4> nevermind, I thought this was a Libav issue
[19:10:55 CEST] <mifritscher> ;-)
[19:11:13 CEST] <mifritscher> so, I'm going home now - letting the test run alone :-)
[19:11:21 CEST] <durandal_1707> everybody fine with movenc sar patch?
[19:32:14 CEST] <JEEB> have you checked -12 just in case?
[19:32:43 CEST] <JEEB> if there's no related limitations you can have yer pasp :)
[19:32:59 CEST] <JEEB> not sure where it is useful of course, but still
[19:39:59 CEST] <philipl> BtbN: thanks.
[20:05:49 CEST] <jamrial> there, mail sent. if i fucked up the count please let me know
[20:14:10 CEST] <Chloe> that mail took a long time to come through
[21:15:56 CEST] <durandal_1707> JEEB: are you talking to me?
[21:16:00 CEST] <JEEB> yes
[21:16:54 CEST] <JEEB> basically 14496-12 is the last thing to speak, and if it doesn't limit pasp in that sense then it's OK to put it there. it's just that tkhd's width and height will override pasp, so as long as those are set correctly all's a gooden
[21:52:07 CEST] <durandal117> is this, dynoverlay patch, some joke?, it have most weird identation i have ever seen
[21:53:50 CEST] <ubitux> html mailer replacing n spaces with 1?
[21:55:33 CEST] <durandal117> ubitux: really? I want to know smart mailer name
[21:55:53 CEST] <ubitux> just an hypothesis, i dunno
[22:22:43 CEST] <Compn> looks like camelcase 
[22:22:46 CEST] <Compn> durandal_1707
[22:23:10 CEST] <Compn> someone should reply with the correct K&R thing
[23:04:27 CEST] <jamrial> ubitux: i think i got it
[23:06:01 CEST] <jamrial> also made sure option parsing for the filters still works
[00:00:00 CEST] --- Fri Sep 23 2016