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

[burek]

[00:13:22 CEST] <atomnuker> jamrial_: huh, I thought url_feof was just forgotten to be removed since it's been more than 2 years
[00:13:28 CEST] <atomnuker> oh well
[00:14:15 CEST] <jamrial_> atomnuker: it was less than 2 years old back during the last major bump, so it was postponed
[00:14:23 CEST] <jamrial_> should be gone in the next
[00:18:35 CEST] <jamrial_> atomnuker: i also meant the whole libavformat.v change, not just url_feof
[00:19:30 CEST] <jamrial_> stopping exporting all those functions is an abi break
[00:20:59 CEST] <jamrial_> if you for example try to run ffserver from 3.1 with libavformat from 3.2, which is a valid scenario, it would crash and burn if you remove those exports
[00:21:31 CEST] <jamrial_> although you're also removing ffm de/muxer, mmh
[00:21:49 CEST] <jamrial_> guess those can't go until the next major bump either...
[00:22:03 CEST] <nevcairiel> the avformat changes should probably be tied to a major bump
[00:22:09 CEST] <jamrial_> yeah
[00:25:55 CEST] <jamrial_> just remove ffserver and its references in documentation and build system. leave the ffm de/muxers and the ffmpeg_opt.c stuff as is
[00:26:44 CEST] <llogan> atomnuker: nit: missed "@item FFM (FFserver live feed)  @tab X @tab X" in doc/general.texi
[00:27:35 CEST] <jamrial_> llogan: not if the libavformat stuff is going to be left in place :p
[00:28:36 CEST] <jamrial_> sucks we forgot about this until the very last minute...
[00:28:52 CEST] <llogan> i just saw "delete mode 100644 libavformat/ffmdec.c" and assumed it was going away... missed your "can't go" message
[00:31:50 CEST] <atomnuker> jamrial_: so -override_ffserver can't be removed either?
[00:33:19 CEST] <jamrial_> it's an ffmpeg.c option, to help "demuxing" ffm files, right?
[00:34:32 CEST] <atomnuker> I guess, yeah
[00:34:50 CEST] <jamrial_> then yeah, can't be removed until ffm de/muxer are removed
[00:36:14 CEST] <jamrial_> someone else with more knowledge about all this ffserver stuff should chime in, anyway
[00:38:41 CEST] <llogan> the problem is that there is nobody who knows ffslerver
[00:41:02 CEST] <jamrial_> michaelni: ^ would that ffmpeg_opt.c code work or be of use if we remove ffserver but leave ffm de/muxer (since that can't be removed without a major bump)?
[00:41:25 CEST] <jamrial_> hell, who knows if it's even working right now after the codecpar conversion...
[01:41:38 CEST] <Chloe> does the avfoundation screen capture not work for anyone else on sierra?
[01:45:30 CEST] <Chloe> oh no, looks like it was mpv being broken not ffmpeg
[01:47:32 CEST] <wm4> yay
[01:53:45 CEST] <Chloe> seems backwards :P a git pull + recompile seemed to fix it though
[03:23:09 CEST] <cone-045> ffmpeg 03Rodger Combs 07master:f53c26c694c9: lavfi/vf_overlay: support NV12 and NV21
[04:20:13 CEST] <Zeranoe> jkqxz: How goes the QSV stuff?
[04:25:57 CEST] <rcombs> looks like I broke autobsf in the segment muxer for some use-cases
[04:26:22 CEST] <rcombs> oops
[04:26:29 CEST] <rcombs> how can I make tests for this thing
[04:39:14 CEST] <cone-045> ffmpeg 03Stephen Hutchinson 07master:bf1439363555: avisynth: fix Planar RGB output
[08:16:42 CEST] <rcombs> OK, wrote some tests for segment.c
[11:24:58 CEST] <BtbN> that hls playlist indeed looks ok. Did someone break hls?
[11:29:42 CEST] <nevcairiel> hls breaks all the time
[11:31:43 CEST] <BtbN> granted, the mpegts it points to looks very broken. But it doesn't even seem to try looking at that
[12:13:03 CEST] <DHE> the .ts file doesn't appear to start on a proper keyframe boundary. that seems to make my local copy of ffmpeg unhappy...
[12:13:24 CEST] <DHE> at least I think so...
[14:50:24 CEST] <RiCON> jkqxz: hevc is crashing ffmpeg/mpv
[14:52:10 CEST] <RiCON> h264/mpeg2/vc1 are working fine but at least with that sample vc1 is still spamming "[ffmpeg/video] vc1_qsv: A decode call did not consume any data"
[14:57:42 CEST] <jkqxz> Hmm.  Backtrace for crash?
[14:57:42 CEST] <jkqxz> Yeah, VC-1 gives me that spam as well.  Demoting the message or a hacky workaround (ignore very small packets?) might be the way to go, but it would be helpful if a VC-1-knowing person (assuming any exist) could have a look at it and determine where the disagreement about the frame boundaries is coming from.
[15:53:57 CEST] <RiCON> i'd never installed any sdk explicitely
[15:54:09 CEST] <jkqxz> I'm not sure what to do with this.  The plugin must have loaded successfully to get there, but then it crashes when you try to use it?
[15:59:59 CEST] <jkqxz> Maybe we can call MFXVideoDECODE_Query() before _Init(), but I don't see why that should behave any differently.  (It's not like _Init() is documented as invoking undefined behaviour if any of the parameters are incorrect - it even explicitly says that it checks for support.)
[16:06:38 CEST] <RiCON> is there any way to change the SDK location?
[16:17:43 CEST] <RiCON> the sw plugin is only installed with the sdk, while the hw one with the drivers?
[16:19:02 CEST] <nevcairiel> that sounds about right, the sw one doesnt come with drivers
[16:26:21 CEST] <RiCON> the sw.dll should actually be found in the PATH, so i'm stumped why it's still trying hw.dll with -load_plugin hevc_sw
[16:29:08 CEST] <jkqxz> Put a breakpoint on MFXVideoUSER_Load() and have a look at the uid argument?
[16:52:30 CEST] <michaelni> atomnuker, ive a headache today, so really i probably wont do to much on the computer except maybe doing the release as i said yesterday  but my oppinion is to not remove ffserver. But whatever you do you should talk with reynaldo who is maintainer of ffserver
[16:58:58 CEST] <atomnuker> michaelni: fair enough, I'll apply it some time after the release unless someone else (you or reynaldo) have something to say about the patch on the ML
[16:59:31 CEST] <jkqxz> RiCON:  Yes, but without the "()".
[17:28:58 CEST] <jamrial> if "after thorough deliberation" we decided to drop it and even write a news entry about this, i'm kinda baffled we forgot to actually make it effective
[17:29:46 CEST] <atomnuker> blame me for not bothering to make a patch :/
[17:29:59 CEST] <atomnuker> could it say "release 3.3" instead?
[17:33:27 CEST] <jamrial> atomnuker: release numbers are not decided until they are made
[17:33:27 CEST] <jamrial> it could be 4.0, or 3.3
[17:42:04 CEST] <atomnuker> jamrial: then just append "(delayed for after the release of 3.2)" or similar?
[18:04:04 CEST] <atomnuker> jamrial: yeah, that makes good sense, wouldn't have to edit the previous news item
[18:04:08 CEST] <atomnuker> (though still someone has to write one, and since usually no one does it I'll wait until after the release and write one)
[18:25:57 CEST] <cone-511> ffmpeg 03Stephen Hutchinson 07n3.2:HEAD: avisynth: fix Planar RGB output
[20:22:49 CEST] <atomnuker> reynaldo: see what me and jamrial wrote, also since it won't be getting removed in 3.2 but in master and eventually in the release after 3.2 there'll be plenty of chance to hear from people using it, if any
[20:27:35 CEST] <reynaldo> atomnuker: Im following the thread and would' rather reply there as needed. My point in case its not clear enough is: move yes but no removal before it happens, the patch fixes nothing and breaks master for anyone using ffserver
[20:27:49 CEST] <reynaldo> there are users offering to help as recently as september this year iirc
[20:29:16 CEST] <jamrial> reynaldo: why wasn't this brought up when it was discussed, when the news entry patch was sent to the ML, and when it was commited?
[20:31:14 CEST] <BtbN> Aparently nobody is willing to maintain ffserver. So the only logical next step is to get rid of it.
[20:31:37 CEST] <BtbN> If somebody still wants it, it can be easily recovered from git history
[20:31:42 CEST] <reynaldo> jamrial: it was brought up I think
[20:32:36 CEST] <wm4> reynaldo: the whole problem with ffserver is that it's extremely intrusive and in its current form has specific code in libavformat
[20:32:42 CEST] <jamrial> reynaldo: where? i at least don't see it in the news entry patch thread
[20:32:48 CEST] <wm4> so I'm not sure how you'd move that to public API
[20:37:28 CEST] <reynaldo> wm4: I know about the problem but I honestly thing the work behind it can be put to some use
[20:37:37 CEST] <reynaldo> think/
[20:38:05 CEST] <reynaldo> it is my intention to put time on it, seems michael is willing to help too
[20:38:33 CEST] <wm4> well this has been going on for moths...
[20:38:38 CEST] <wm4> months even
[20:38:53 CEST] <BtbN> there was even some highly motivated guy planning to revive ffserver
[20:38:59 CEST] <BtbN> haven't heard of him since
[20:39:41 CEST] <reynaldo> BtbN: that was barely a month ago and he wasnt meet with encouragement
[20:39:47 CEST] <reynaldo> 2 months maybe
[20:40:12 CEST] <reynaldo> wm4: the project for a decade+_ and we are still here ;)
[20:40:50 CEST] <reynaldo> besides, I relly like the general idea of having the apps on a separate repo
[20:41:04 CEST] <reynaldo> there can be an staging area there for apps that still need porting work
[20:41:16 CEST] <reynaldo> (which might help the transition happen faster)
[20:41:41 CEST] <atomnuker> reynaldo: then what's the problem with removing it from master and in the meanwhile do the work of putting it in a separate repo
[20:41:43 CEST] <reynaldo> I just oppose the removal while that is not in place
[20:41:59 CEST] <reynaldo> atomnuker: you just dont do things that way, you are breaking master without a solution
[20:42:02 CEST] <reynaldo> while would you do that
[20:42:02 CEST] <atomnuker> that way thing sill move faster, and we could finally work on improving lavf and removing the ffm muxer/demuxer
[20:42:06 CEST] <reynaldo> whats there to gain
[20:42:07 CEST] <reynaldo> ?
[20:42:24 CEST] <atomnuker> lavf
[20:42:27 CEST] <reynaldo> atomnuker: looks at my "staging tree" idea over there ^
[20:42:46 CEST] <reynaldo> looks/look/
[20:42:59 CEST] <atomnuker> besides, master may be broken but the most up to date release wouldn't be
[20:43:24 CEST] <atomnuker> and no one in their right minds would use an unstable release for a serious day to day streaming
[20:43:26 CEST] <reynaldo> theres no justification in place, you are breaking master for no apparent gain
[20:43:41 CEST] <wm4> how come the pressure is always on those who don't want to keep ffserver, instead of those who want to keep it
[20:43:47 CEST] <reynaldo> atomnuker: we are talking ffmpeg, there are indded ppl using master
[20:43:49 CEST] <atomnuker> reynaldo: breaking master so we can start improving libavformat
[20:44:03 CEST] <atomnuker> otherwise we're stuck and we're never going to do anything
[20:44:09 CEST] <ubitux> i'm against moving the tools outside the repository for now
[20:44:15 CEST] <ubitux> it will make life harder for the merges
[20:44:16 CEST] <jamrial> broken how?
[20:44:19 CEST] <ubitux> which is already a PITA
[20:44:26 CEST] <ubitux> btw, ffserver is hindrance to the merge too
[20:44:38 CEST] <ubitux> so i'm fine with having it dead in another repository
[20:44:45 CEST] <atomnuker> ubitux: that's why we start doing them one at a time, with ffserver which doesn't have an analogue in libav
[20:44:49 CEST] <reynaldo> so the merges, libav merges ?
[20:44:53 CEST] <reynaldo> ubitux ^
[20:44:56 CEST] <ubitux> yes libav merges
[20:45:20 CEST] <reynaldo> now thats a real argument for the rmeoval of ffmpeg :)
[20:45:34 CEST] <reynaldo> "libav did it before"
[20:45:38 CEST] <mateo`> oh come on
[20:45:43 CEST] <reynaldo> ffserver, I mean
[20:45:46 CEST] <wm4> durr
[20:45:46 CEST] <ubitux> it's not about copying libav
[20:45:53 CEST] <ubitux> it's about making the merges work
[20:46:12 CEST] <ubitux> i'm not even sure ffserver still works with the move to codecpar
[20:46:19 CEST] <reynaldo> I cant continue this right now, will be around latter though and keep an eye on the thread
[20:46:26 CEST] <reynaldo> thanks for keeping it cool guys
[20:46:28 CEST] <jamrial> this discussion is months late...
[20:46:35 CEST] <ubitux> we're not going to keep ffserver reynaldo 
[20:46:41 CEST] <reynaldo> hope we can make it to the end without sting rays
[20:46:44 CEST] <ubitux> the discussion already happened
[20:46:50 CEST] <wm4> indeed we've already decided ffserver is to be removed
[20:46:56 CEST] <wm4> (unless someone "updates" it)
[20:47:02 CEST] <wm4> (which didn't happen)
[20:47:14 CEST] <reynaldo> leaving but can someone point here to when was that decided?
[20:47:19 CEST] <reynaldo> leaving for real now
[20:47:49 CEST] <ubitux> look at the news
[20:47:49 CEST] <ubitux> on ffmpeg.org
[20:47:49 CEST] <jamrial> reynaldo: i replied with a couple links
[20:47:51 CEST] <jamrial> there were discussion also here on irc, months ago as well
[21:05:21 CEST] <DHE> No patch suggestions, or should I just post it to the mailing list to see what people think?
[21:10:08 CEST] <jamrial> DHE: can't that be achieved with  the option added in  commit 4493390?
[21:10:21 CEST] <jamrial> in any case, sending the patch to the ml is always the best idea
[21:29:45 CEST] <DHE> jamrial: That's for per-filter threads. but the filter pipeline as a whole has its own thread count and that's where it hurts
[21:33:45 CEST] <DHE> and I've experimented and wasn't able to find a way to get option into the pipeline
[21:46:55 CEST] <jamrial__> DHE: as i said, send it to the ml. it will get more exposure there
[00:00:00 CEST] --- Fri Oct 28 2016