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

[burek]

[00:04:27 CET] <kierank> wm4: hahahahaha
[00:04:36 CET] <kierank> michaelni goes and proves your point
[00:05:00 CET] <kierank> we deliberately don't merge our internal pixel procecssing code because it doesn't fit into ffmpeg
[00:05:04 CET] <kierank> and then we get
[00:05:06 CET] <kierank> "why have these changes not been submitted to ffmpeg-devel ?
[00:05:06 CET] <kierank> These changes from a very quick look, look clean"
[00:05:24 CET] <kierank> that repo is truly truly awul
[00:05:36 CET] <kierank> but at the time was the only way we could do it
[00:06:57 CET] <wm4> is this all libswscale code? well what can I say, michaelni maintains this sub-lib
[00:07:05 CET] <kierank> no it's not in swscale
[00:07:23 CET] <wm4> ok
[00:07:26 CET] <kierank> we have 5 broadcast specific pixel formats and we convert (nearly) all combinations
[00:10:20 CET] <kierank> but anyway it's going into upipe
[00:10:37 CET] <kierank> note that none of these pixel formats except v210 which ffmpeg has exist in the file world
[00:10:49 CET] <kierank> and only exist in a very very very niche hardware world
[00:11:13 CET] <cone-065> ffmpeg 03Tom Butterworth 07master:48f0e41c3068: doc/encoders: add documentation for the Hap encoder
[00:49:17 CET] <cone-065> ffmpeg 03Lou Logan 07master:872b35890395: doc/encoders: sort list into alphabetical order
[00:49:31 CET] <DHE> so I made a bitstream filter, would ffmpeg be interested in it? it strips closed captions out of an H264 video stream (requires annexb format)
[00:50:23 CET] <rcombs> DHE: just removes them, or exports them in some way?
[00:50:48 CET] <CFS-MP3> Strip? As a subtitles guy I got chills
[00:51:02 CET] <CFS-MP3> out of curiosity, what's the real life usage?
[00:51:44 CET] <rcombs> yeah, does it deal with a particular problem (buggy decoders?), or just save some bandwidth?
[00:51:57 CET] <rcombs> (not that saving bandwidth isn't a worthy goal, just a bit less appealing)
[00:52:40 CET] <rcombs> I'd love to have a way to get captions out of an H264 stream and stick them in their own AVStream
[00:54:47 CET] <CFS-MP3> what's the correct, non-hackish, way to pass data from a avfilter to avformat? Specifically what I need is to send stats generated for example from showinfo (let's say, number of each frame type) to segment so the .csv can include said stats 
[00:58:15 CET] <rcombs> packet side-data or metadata?
[00:58:20 CET] <rcombs> erm, *frame
[01:06:52 CET] <DHE> CFS-MP3: the short term goal is to troubleshoot a video player with some kind of memory leak
[01:13:03 CET] <DHE> rcombs: it works on the packet itself, identifying the SEI containing subtitles and removing the NAL
[01:13:41 CET] <rcombs> ah, makes sense
[01:15:52 CET] <CFS-MP3> rcombs frame - such as 4000 I frames, etc
[01:16:26 CET] <CFS-MP3> the need I have is more specific but this is the architectural problem I have. Other things, such as exporting to json, is trivial 
[01:19:17 CET] <DHE> rcombs: also the bandwidth "saved" works out to somewhere around 40 bytes per frame. so, not really worth it.
[01:19:28 CET] <rcombs> yeah, figures
[01:19:54 CET] <wm4> rcombs: you could it do like mpv... which feeds them back to the demuxer once the decoder gets them
[01:20:15 CET] <rcombs> wm4: or parser, optimally
[01:20:31 CET] <wm4> the problem is AFAIK frame rordering
[01:20:35 CET] <wm4> *reordering
[01:20:55 CET] <rcombs> it seems like we might need some general-purpose H264 reordering infrastructure anyway
[01:21:06 CET] <rcombs> for e.g. VideoToolbox
[01:22:23 CET] <rcombs> DHE: so, I'm not sure if this is really worthwhile to have as an individual filter, but it seems reasonable as a component of a general filter to make adjustments to H.264 bitstreams, or as its own if we had general-purpose infrastructure for that
[01:35:24 CET] <kierank> wm4: 
[01:35:24 CET] <kierank> ye
[01:35:25 CET] <kierank> s
[01:40:25 CET] <wm4> would what rcombs suggested be reasonable?
[01:40:57 CET] <rcombs> jkqxz has some relevant code laying around, I believe?
[01:49:55 CET] <kierank> wm4: in a bsf probably
[01:50:09 CET] <kierank> not sure if all the reordering types are easy to process though
[02:07:24 CET] <DHE> it makes sense, but at this time we only have 2 h264 bitstream filters: convert to annexb, and strip CC (which as I wrote it requires annexb format)
[02:16:28 CET] <jamrial> DHE: Anton wrote a bsf to extract NALs and make them available as extradata
[02:17:00 CET] <jamrial> you could try extending it instead of adding a separate bsf
[02:17:25 CET] <DHE> interesting...
[02:17:44 CET] <DHE> well, in my situation I have the tool I need for the job that needs doing, so I'll likely stick with this for myself. we'll see about upstream merging...
[02:18:15 CET] <DHE> thing is, I need to REMOVE the nals, not just examine them. my video ends up being a little bit smaller
[09:41:11 CET] <nevcairiel> why is everything in ffmpeg.c working so backwards in comparison to avconv.c .. figured out one thing, and the next one is conceptually incompatible, again!
[09:45:22 CET] <nevcairiel> since everything is supposed to be initialized as late as possible now, ie. filters only after the first frame is decoded, encoders after that, it now conflicts with the filter graph not knowing the audio frame size early enough because the encoder isnt open yet, and our filtering uses "push" mode for some reason that forces frames through the graph right away
[09:50:01 CET] <nevcairiel> after hitting roadblock after roadblock i'm inclined to go back to the thought of skipping and re-implementing it carefully and properly later, instead of inside a merge
[10:25:40 CET] <wm4> nevcairiel: huh, why would the filter code need audio frame size?
[10:56:17 CET] <nevcairiel> wm4: because you can tell it how big the audio frames are supposed to be it spits out, so it can directly match the encoders requirements
[10:56:47 CET] <nevcairiel> and you dont need an extra fifo in your own code
[10:58:37 CET] <wm4> wat
[10:58:53 CET] <wm4> afaik lavfi can't do this
[10:58:59 CET] <nevcairiel> of course it can
[10:59:14 CET] <nevcairiel> AVFilterLink has parameters to define min and max audio frame size
[10:59:24 CET] <nevcairiel> if both are the same, its a fixed size
[10:59:39 CET] <nevcairiel> and the generic lavfi code fifos the audio for you
[11:00:01 CET] <nevcairiel> and buffersink has an API to set these values to user-provided data
[11:02:12 CET] <wm4> not seeing such a thong, unless it's very new
[11:02:20 CET] <nevcairiel> nah its old
[11:02:43 CET] <nevcairiel> av_buffersink_set_frame_size controls the frame size for the buffersink
[11:03:41 CET] <nevcairiel> AVFilterLink.min_samples/max_samples control the size each link can receive
[11:04:34 CET] <nevcairiel> which generally makes sense, audio algorithms often have size requirements, ie. a minimum  block size, soimetimes also a max
[11:11:54 CET] <wm4> ah looked at buffersrc only
[13:09:23 CET] <jkqxz> I'm not sure what to do with that VAAPI-VP8 patch.  Backporting it to the legacy infrastructure seems like madness to me.
[13:31:43 CET] <BtbN> jkqxz, it also adds new stuff which is already flagged with attribute_deprecated, which seems kinda odd
[13:34:02 CET] <BtbN> jkqxz, on top of it, it's also incomplete.
[13:34:10 CET] <jkqxz> That bit is just wrong, but I don't think the patch will use it anyway (it's for the old-old version, the same field in FFVAContext is also there).
[13:34:20 CET] <jkqxz> Yes, it's missing the important file.
[13:34:48 CET] <BtbN> Also, the modification of vp8.c/h should be moved to a seperate patch imo
[13:35:37 CET] <BtbN> I tried to do the same thing a while ago
[13:35:42 CET] <jkqxz> It was in the original, not sure why it's squashed.
[13:35:54 CET] <BtbN> and gave up because the VP8 implementation is just crazy in VAAPI
[13:36:14 CET] <BtbN> And when I tested it, it was slower than software decoding, so I didn't bother.
[13:38:37 CET] <jkqxz> VP8 decode is fine, tbh (the segmentation / entropy coding state bit was a right pain to get right, but otherwise it's like every other hwaccel).
[13:39:22 CET] <BtbN> the ffmpeg code is not at fault for that
[13:39:30 CET] <BtbN> I had that essentialy working before as well
[13:39:50 CET] <BtbN> But dropped it when it used more CPU and still got a lower framerate than plain ffmpeg software decoding.
[13:40:37 CET] <jkqxz> Hmm, odd.  Maybe the Intel driver sucked at the time you did it - I found it to be fine.
[13:41:25 CET] <jkqxz> (That was only three months ago.)
[13:45:13 CET] <jkqxz> Maybe the best thing to do would be to cherry-pick the hw_frames_ctx version now, then VP8 merges trivially.  I would need to update vp9 and hevc to do it, but that's straightforward (and has to be done anyway at some point).
[13:52:19 CET] <jkqxz> I suppose it depends on what time constraints the Intel person has.  I was happy to wait for normal merges; if they aren't (which looks true given the encode merges send at the same time) then picking the whole series of cherries in a consistent way is surely better than weird backporting.
[14:08:36 CET] <jkqxz> BtbN: wm4:  Any opinion on that?  I think you are the only people here with a direct interest in it.
[14:09:33 CET] <BtbN> It seems only logical to add VP8 to VAAPI, and from a quick look at it, the patch generally seems fine.
[14:09:46 CET] <BtbN> If it's not in the way of anything, I don't see a reason not to merge it
[14:11:33 CET] <jkqxz> I was more meaning the libav merges themselves, of which this is a weird case because it's picked from something more recent and backported to an older version of the infrastructure.
[14:32:15 CET] <nevcairiel> would the new infra work without the changes to ffmpeg.c for the reinit stuff?
[14:34:30 CET] <jkqxz> Yes, it's independent.
[14:34:56 CET] <jkqxz> (The new lavc can work with old ffmpeg, too.)
[14:36:09 CET] <nevcairiel> i assume this one and the follow ups ? https://git.libav.org/?p=libav.git;a=commit;h=123ccd07c55ccf075cc5daf5581237fbccb86bdb
[14:36:58 CET] <jkqxz> Yes.
[14:37:34 CET] <nevcairiel> nothing really preventing you to cherry-pick a set if you want to
[14:38:25 CET] <nevcairiel> in any case I should really just call t his ffmpeg/avconv set and skip the huge breaking commit, there is no sane way to simply adapt the changes in the scope of a merge either way
[14:38:30 CET] <jkqxz> Is there a way to do a proper cherry-pick which will actually preserve the history?
[14:41:10 CET] <jkqxz> BtbN:  Does cuvid->nvenc transcode work if you use the 'format=nv12|cuda,hwupload' workaround?  (For a suitable value of nv12 if it isn't that.)
[14:44:14 CET] <jkqxz> nevcairiel:  Yes, that's probably fair.  (The qsv change won't be sufficient, but I'll work out how to fix it up afterwards to not be entirely broken.)
[14:44:40 CET] <nevcairiel> our filtering infra is way too different
[14:48:41 CET] <jkqxz> Adding 'format=sw_format|hw_format,hwupload' at the front of any looks-like-hw transcode path may well be enough to work in the hwcontext world.  (And I will only cry a little bit about the reinit.)
[14:48:49 CET] <nevcairiel> lets see if i can get cuvid working again without manual hackery in the merge stage
[14:49:10 CET] <jkqxz> And *_transcode_init() should die in all cases.
[14:52:38 CET] <nevcairiel> that was always a huge hack
[14:57:15 CET] <jkqxz> Do just ignore qsv unless you have some important reason not to; I can do that testing and fix it up afterwards.
[14:57:37 CET] <jkqxz> And thank you for all your work on this :)
[14:57:39 CET] <nevcairiel> just need to grab a cuda sdk to actually see if cuvid works again
[14:57:56 CET] <nevcairiel> our hwcontext_cuda.h doesnt work with the dynlink headers in the video sdk, apparently
[15:07:55 CET] <wm4> jkqxz: hm so the problem is that people want to implement features, and doing it properly would require libav merges that haven't happened yet?
[15:09:35 CET] <jkqxz> Not quite.  The problem is that people want to pick libav merges which depend on older ones without taking the older ones.
[15:10:09 CET] <jkqxz> Maybe not want.  Have done, possibly without realising.
[15:10:21 CET] <wm4> huh
[15:10:28 CET] <wm4> that's too much for my tiny confused brain
[15:17:02 CET] <jkqxz> The choice is between (a) do nothing now, wait for normal merges, possibly annoy the guy who proposed it; (b) merge the proposed backport now, trample it later; (c) cherry-pick the proper changes now.
[15:20:16 CET] <wm4> (c) seems fine if it doesn't cause too much chaos
[15:20:28 CET] <wm4> normally I'd say (a), but the merges are so behind
[15:24:56 CET] <jamrial> the merge backlog is misleadingly bloated anyway. tons of noops
[15:25:37 CET] <jamrial> like, easily 15 vp9 commits from Ronald that we already implemented years ago for example
[15:25:52 CET] <wm4> heh
[15:26:01 CET] <nevcairiel> after the avconv set there is a lot of easy stuff to catch up on
[15:26:07 CET] <nevcairiel> its just been blocked on many complex sets
[15:29:17 CET] <nevcairiel> speaking of, this branch has 3 merges of the commits leading up to the blocking merge that should be implemented properly instead of merged somehow, https://github.com/Nevcairiel/FFmpeg/commits/merge-avconv .. if anyone wants to test beyond fate
[15:29:31 CET] <nevcairiel> (cuvid is still broken, w orking on that)
[15:31:41 CET] <ubitux> jamrial: the "noop" are always tricky, because you have to check if there isn't any cosmetics, small fixes or whatever in these commits
[15:33:42 CET] <jamrial> ubitux: yeah, but they are not blockers like codecpar, new bsf api and now this
[15:33:56 CET] <ubitux> yeah, sure :)
[15:34:06 CET] <jamrial> annoying, sure, but it's a matter of finding the lines with diego'd indentations and deal with them :p
[16:16:39 CET] <nevcairiel> i must be dumb today, i cant get ffmpeg to link against the cuda library, no matter what combination i try, it just fails to link, even with msvc builds <.<
[17:26:28 CET] <wm4> ah I know why that one happens
[17:30:52 CET] <kierank> wm4: swresample?
[17:33:19 CET] <wm4> actually I was wrong
[17:33:33 CET] <wm4> I have no idea wtf is going on there and I'm not interested in it either
[18:31:19 CET] <wm4> wasn't openssl API use supposed to be fixed in ffmpeg master?
[18:33:14 CET] <wm4> libavformat/rtmpdh.c fails to compile because it accesses a field of struct DH, which is apparently opaque now
[18:36:46 CET] <rcombs> huh, I also thought that was supposed to be fixed
[18:39:25 CET] <wm4> rcombs: it works if you have GMP or GCRYPT enabled
[18:39:59 CET] <wm4> these take priority over using openssl for crypto primitives
[18:43:50 CET] <michaelni> nevcairiel, "git merge Nevcairiel/merge-avconv"  fails with  ./ffmpeg -i tickets//1167/j.asf test.avi
[18:46:56 CET] <michaelni> https://trac.ffmpeg.org/attachment/ticket/1167/j.asf
[18:47:23 CET] <nevcairiel> michaelni: thanks, i'll check later
[18:47:41 CET] <michaelni> np, also please ping me when theres a new revission to test
[20:21:18 CET] <jkqxz> nevcairiel:  I get <http://sprunge.us/acDe> as another small timing change.
[20:21:54 CET] <nevcairiel> on fate? how odd
[20:23:12 CET] <nevcairiel> oh thats probably the one that uses iconv, i dont have that on windows
[20:26:30 CET] <jkqxz> That would do it.  Do you want me to do anything, or shall I just leave it with you?
[20:26:45 CET] <nevcairiel> nah its fine, i have a dev linux box anyway
[20:27:35 CET] <jkqxz> Ok, sure.  I'm going to look at vaapi and qsv next.
[20:27:50 CET] <nevcairiel> qsv is definitely broke
[20:27:50 CET] <nevcairiel> :D
[20:30:39 CET] <nevcairiel> i wonder if it shouldnt skip the commit with the timing changes as well, its rather directly related to the one i'm skipping anyway and will need changes in the future when its re-implemented
[20:31:01 CET] <nevcairiel> which might make it cleaner to avoid that mess
[20:43:02 CET] <jkqxz> It is completely separable, so sure?
[20:43:13 CET] <jkqxz> I don't see that it matters much, though.
[20:44:04 CET] <nevcairiel> its probably fine either way
[00:00:00 CET] --- Sat Nov 12 2016