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

[burek]

[03:06:25 CEST] <cone-656> ffmpeg 03Michael Niedermayer 07master:c1173437fc3e: avcodec/ffv1enc: Fix storing RGB48 without explicitly set level
[05:09:49 CEST] <cone-656> ffmpeg 03Michael Niedermayer 07master:85d23e5cbc9a: avcodec/interplayvideo: Check side data size before use
[05:15:07 CEST] <philipl> http://imgur.com/a/6rhiY
[05:47:42 CEST] <TD-Linux> wow I never realized those were physical cards
[05:56:13 CEST] <Compn> that looks like a small case
[06:37:19 CEST] <Matador> Hows it goin ?
[06:40:16 CEST] <Matador> Anyone want to squash a huge bug and save the planet ? :)
[06:45:40 CEST] <Compn> which one ? qsv ?
[06:46:01 CEST] <Compn> theres a patch to fix it on the ml
[06:50:19 CEST] <Matador> nice
[06:50:40 CEST] <Matador> should fix a few bugs like.. https://trac.ffmpeg.org/ticket/5848
[06:51:54 CEST] <Matador> this is going to save the world
[06:52:53 CEST] <Matador> Intel CPU h264.. using ~50% CPU encoding standard h264 720p sort of thing.. using ~50 watts roughly (1/2 the TDP)
[06:53:11 CEST] <Matador> qsv uses few watts gpu, and < 10% CPU same setting
[06:53:24 CEST] <Matador> like 30-40 watt savings per encode
[06:56:31 CEST] <rcombs> somehow I doubt the world's primary consumer of power is QSV encodes
[06:57:31 CEST] <Matador> Many people use transcoding even though they dont even know it
[06:57:44 CEST] <Matador> like OBS, Wirecast, Handbrake, Adobe programs, etc..
[06:58:24 CEST] <Matador> Whoever is responsible for solving QSV crash in ffmpeg, gets all the praise and a $$ financial bounty from me
[07:02:24 CEST] <rcombs> hear that, jkqxz?
[07:02:52 CEST] <Matador> just checkin the threads now
[07:03:18 CEST] <rcombs> actually that reminds me of something
[07:03:37 CEST] <Compn> Matador : i think jkqxz is the one who posted the patch 
[07:04:18 CEST] <rcombs> michaelni: I think I offered a bounty on an swscale thing years ago, and then you pointed out there was already an option for what I wanted, and I walked it back
[07:04:32 CEST] <rcombs> if you think that was unfair I can pay out whatever I originally offered
[07:05:21 CEST] <Matador> I'm checkin Compn 
[07:05:28 CEST] <Matador> because there are a few patches
[07:06:15 CEST] <Matador> I'm seein a patch from "Nablet Developer"
[07:07:41 CEST] <rcombs> the Developer family has produced many great engineers for generations
[07:08:05 CEST] Action: Compn going sleep sleep
[07:08:07 CEST] <Compn> nigh
[07:08:36 CEST] <Matador> so I guess I should try a new build
[07:26:36 CEST] <rcombs> if a decoder receives a drain packet, then is flushed, should it be able to be used again afterwards (with new data)?
[07:26:47 CEST] <rcombs> or if it's flushed, then receives a drain packet
[07:26:50 CEST] <rcombs> (i.e. size=0)
[07:31:34 CEST] <Compn> huh sam zoy guy made a patch
[07:43:33 CEST] <philipl> Compn: mini itx case so i didn't have a slot for the adapter. had to use the u.2 connector.
[10:34:02 CEST] <rcombs> oh, I wonder if an issue wm4 had a patch for
[12:51:02 CEST] <wm4> rcombs: no
[12:51:30 CEST] <rcombs> OK, separate seeking issue
[13:10:07 CEST] <michaelni> rcombs, i dont remember and no i dont think its unfair and It happens all the time btw, just recently someone ofered me 5k for some feature we already have IIRC. Of course if you want to donate something ...
[13:10:41 CEST] <rcombs> hah, nice
[13:46:36 CEST] <cone-402> ffmpeg 03Carl Eugen Hoyos 07master:134233972e79: lavc/utvideoenc: Set bits_per_coded_sample for rgba.
[16:49:57 CEST] <ubitux> M_PI is not available in C11, wuut
[16:50:20 CEST] <bencoh> how is it called now? :/
[16:50:45 CEST] <ubitux> it doesn't exist
[16:50:48 CEST] <bencoh> wtf
[16:51:28 CEST] <nevcairiel> does it have M_TAU? :D
[16:53:25 CEST] <bencoh> hm, apparently it wasn't supposed to be in c99 either, so we're all just abusing compiler-specific sugar
[16:58:26 CEST] <atomnuker> the fortran way is to just #define M_PI (atan(1)*4)
[17:12:46 CEST] <Chloe> ubitux: none of the standards define M_PI iirc
[17:13:25 CEST] <ubitux> yeah, unfortunately
[17:30:30 CEST] <iive> yeh, new C standards put all kinds of crap, but having a PI ...
[17:31:33 CEST] <bencoh> huhu ...
[18:25:20 CEST] <DHE> slightly off-topic, is there documentation online about the H264 bitstream format? I want to write my own bsf for h264.
[18:28:44 CEST] <nevcairiel> The spec has all you need
[19:26:11 CEST] <Compn> DHE : do you need a copy of the spec?
[19:27:42 CEST] <DHE> Compn: I guess..
[19:55:24 CEST] <ubitux> the specs is free afaik
[19:56:05 CEST] <ubitux> https://www.itu.int/rec/T-REC-H.264
[19:57:15 CEST] <DHE> the old versions have links, but the current "in force" version doesn't on my screen..
[19:57:32 CEST] <ubitux> do you really need the "current"?
[19:58:11 CEST] <DHE> ... probably not
[20:03:07 CEST] <tmm1> rcombs: did you have a WIP patch for videotoolbox decoder + reordering frames?
[21:12:36 CEST] <rcombs> tmm1: I had one that used timestamps, but that doesn't help for streams that lack those
[21:19:09 CEST] <BBB> DHE: also, feel free to ask questions in this channel (or in #x264dev), theres a fair number of devs with h264 experience here
[21:20:44 CEST] <tmm1> rcombs: would be interested in trying it out if you have it available somewhere
[21:21:25 CEST] <rcombs> tmm1: might be very out of date: https://gist.github.com/3b30aa3f2e68dbe726d63a19319c601e
[21:27:31 CEST] <tmm1> rcombs: thanks
[21:31:32 CEST] <DHE> BBB: thanks, I'm hoping that being able to break the stream down into SEI fragments (if that's the term) will meet my needs.
[21:33:31 CEST] <ubitux> for subtitles negociation (query formats) in lavfi; should we have something filter that supports text|bitmap?
[21:36:41 CEST] <ubitux> i guess that will do
[21:53:06 CEST] <rcombs> ubitux: I don't quite understand the question
[21:53:37 CEST] <rcombs> ubitux: are you asking if there should be a filter that converts text subs to a series of bitmaps? (seems sane enough)
[21:54:22 CEST] <ubitux> the question is on what basis the filters will decide whether they support or not the given input subtitles (and what they can output)
[21:54:46 CEST] <ubitux> similar to pix fmt for video, i was guessing filter will just say "i support text" "i support bitmap" "i support both"
[21:55:01 CEST] <ubitux> not sure what to do about teletext yet though
[21:55:14 CEST] <ubitux> one of/the only one without caps
[21:55:34 CEST] <rcombs> maybe teletext should export two AVCodecs
[21:55:54 CEST] <rcombs> one for decoding as text and one for as bitmaps
[21:56:40 CEST] <rcombs> ubitux: what do you think of the concept of having a pair of filters for text->bitmap (libass) and bitmap->text (tesseract)?
[21:57:17 CEST] <ubitux> i'm fine with that but i belive the text->bitmap will be [V][S] ’ [V]
[21:58:04 CEST] <rcombs> yeah, generally, but I think it'd be good to have the rendering separable from the overlaying
[21:58:24 CEST] <rcombs> so that if we want to do overlay directly onto hardware surfaces, the subtitles filter doesn't have to handle that itself
[21:58:34 CEST] <ubitux> yes, it might be useful to have a [S] ’ [V] which outputs bitmaps of different size too
[21:58:45 CEST] <ubitux> i did that with the api a while ago, i would love to do it thanks to lavfi
[21:58:53 CEST] <ubitux> (to extract every subtitle "picture")
[21:59:43 CEST] <rcombs> relatedly: is there a format available that matches what libass outputs (series of [alpha-only bitmap + RGBA color]), rather than series of RGBA bitmaps?
[22:00:32 CEST] <ubitux> i don't understand the question
[22:00:56 CEST] <rcombs> so, imagine that you're trying to blend subtitles into a hardware surface-backed frame
[22:01:19 CEST] <rcombs> libass outputs a series of alpha-only bitmaps, each with an RGBA color value
[22:01:48 CEST] <rcombs> if you're going to do a text->bitmap filter, and then a separate blend-bitmaps-into-hardware-surface filter
[22:02:21 CEST] <rcombs> then blending the alpha-only bitmaps into a single RGBA bitmap to send to the second filter would usually be inefficient
[22:02:47 CEST] <rcombs> it'd (usually) be faster to just have the second filter take the alpha-only bitmaps and upload those
[22:02:54 CEST] <rcombs> this is what mpv does
[22:02:58 CEST] <rcombs> for playback
[22:04:14 CEST] <rcombs> does that make sense?
[22:10:22 CEST] <ubitux> not sure: decoders output alpha-only bitmaps, don't they? they can't blend it themselves. then there is nothing else than libass doing rasterization. so yeah, maybe a libass filter would take text and output directly into the final surface (so the filter would take both in text and in video)
[22:17:05 CEST] <rcombs> ubitux: my issue with doing it in the subtitles filter is that the process for blending might be significantly different depending on the frame type (software, VAAPI, DirectX, etc&)
[22:17:30 CEST] <rcombs> which is fine if there are routines for this exposed somewhere (drawutils?)
[22:17:50 CEST] <rcombs> I just don't want to have to duplicate all that code everywhere that wants to draw stuff efficiently
[22:17:59 CEST] <ubitux> but didn't you say libass can output there directly?
[22:18:13 CEST] <ubitux> s/output there/blend on these surfaces/
[22:18:23 CEST] <rcombs> libass outputs alpha-only bitmaps; it doesn't know anything about hardware surfaces
[22:18:56 CEST] <ubitux> i thought it had blending code, but i guess i'm confused with mpv?
[22:19:09 CEST] <ubitux> (where is the blending code asm?)
[22:19:33 CEST] <ubitux> vf overlay handles the blending relatively fast but no asm so far iirc
[22:19:37 CEST] <rcombs> I've been looking into doing RGBA blending within libass, but that's down the line, and won't be the most efficient option in all cases
[22:20:34 CEST] <rcombs> (I look forward to getting rid of sub2video; that's often a significant perf hit right now)
[22:20:52 CEST] <ubitux> i should have the lavfi part "soon"©
[22:21:01 CEST] <ubitux> then i'll have to deal with encoding
[22:21:08 CEST] <ubitux> and the chain is complete
[22:23:41 CEST] <ubitux> non working code (at all) @ https://github.com/ubitux/FFmpeg/compare/subtitles-frame-tmp
[22:23:54 CEST] <ubitux> but it gives an overview
[22:24:12 CEST] <ubitux> sub frame with ref counting should be working, lavfi structure soon in place
[22:24:20 CEST] <ubitux> anyway.
[22:32:31 CEST] <ubitux> mmh, so we configure the input graph before opening the codec context
[22:32:34 CEST] <ubitux> that's interesting
[22:55:31 CEST] <jamrial> ubitux: if you mean in ffmpeg.c, the upcoming merges afaik shake that up a bit
[23:07:24 CEST] <ubitux> i'm patiently waiting then
[23:17:56 CEST] <cone-567> ffmpeg 03Yogender Gupta 07master:f524275ef938: avfilter/scale_npp: fix passthrough mode
[23:36:44 CEST] <michaelni> btw, anyone wants to write release notes for 3.2 ?
[23:39:20 CEST] <llogan> "See Changelog"
[00:00:00 CEST] --- Wed Oct 26 2016