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

[burek]

[00:00:00 CET] <wm4> seems like you have to parse the whole file
[00:00:23 CET] <microchip_> wm4: enjoying mpv, btw. thx! ;)
[00:00:44 CET] <wm4> k
[00:01:14 CET] <wm4> parsing the whole file as in skipping over all frames, skipping being relatively simple
[00:01:15 CET] <j-b> wm4: not sure.
[00:07:23 CET] <wm4> I guess there's no other way than practically demuxing the entire file
[00:07:26 CET] <wm4> what a vile format
[00:25:31 CET] <philipl> BtbN: I think cuvid/nvenc transcoding is broken again.
[00:25:44 CET] <philipl> the frame width/height values are reaching nvenc as 0/0
[00:26:44 CET] <philipl> i thought it was a problem doing p010 transcoding but now I see nv12 doesn't work either
[00:27:33 CET] <wm4> rocky merge seas
[00:41:59 CET] <cone-763> ffmpeg 03Andreas Cadhalpun 07master:fdb8c455b637: mxfdec: fix NULL pointer dereference in mxf_read_packet_old
[00:42:48 CET] <jya> BBB: the avx2 idct optimisation, how much would you expect this to improve performance playback? I can't say I notice much difference with our benchmark test... I may gain 1 extra decoded frame per second (on this machine, that translates to 219fps vs 220fps)
[00:43:00 CET] <jya> and that may just be standard variation
[00:48:28 CET] <michaelni> philipl, fate-source is failing due to compat/cuda/dynlink_*
[00:49:04 CET] <michaelni> random example: http://fatebeta.ffmpeg.org/report/x86_32-mingw-w64-dll-windows-native/20161122232300#failed_tests
[00:55:45 CET] <cone-763> ffmpeg 03Michael Niedermayer 07master:4e5049a2303a: avformat/mpeg: Adjust vid probe threshold to correct mis-detection
[01:01:03 CET] <philipl> BtbN: I think that one's for you :-)
[01:10:07 CET] <Kuroe> [22:52:16]  <rcombs>	(I'm doubtful many people will spend money on TV for the sake of object audio)
[01:10:13 CET] <Kuroe> you'd be surprised...
[01:10:50 CET] <Kuroe> People lap up buzzwords, and if something has more of them then it must be better--and they only want the best ofc.
[01:12:22 CET] <TD-Linux> object audio from 2 speakers?
[01:13:19 CET] <wm4> obviously you want to use it with a VR headset, with audio mixed according to head direction, in realtime
[01:14:08 CET] <TD-Linux> I mean, that is presumably what google is doing, but they are using ambisonics not object based
[01:14:16 CET] <TD-Linux> because it is actually possible to sanely record ambisonics
[01:15:24 CET] <TD-Linux> also YT HDR is actually HDR10, not HLG
[01:15:42 CET] <TD-Linux> (also HDR10 mandates HEVC so it's the VP9 equivalent)
[01:21:56 CET] <cone-763> ffmpeg 03Andreas Cadhalpun 07master:946ecd19ea75: smacker: limit recursion depth of smacker_decode_bigtree
[01:21:56 CET] <cone-763> ffmpeg 03Andreas Cadhalpun 07master:de4ded06366e: rmdec: validate block alignment
[01:21:57 CET] <cone-763> ffmpeg 03Andreas Cadhalpun 07master:dbefbb61b785: sbgdec: prevent NULL pointer access
[01:31:12 CET] <microchip_> sorry guys, shouldn't have started this who AC-4 thing... but I'm curious about new audio/video things :)
[01:31:18 CET] <microchip_> whole*
[02:02:37 CET] <cone-763> ffmpeg 03Michael Niedermayer 07master:2f935baa7d86: avutil/opt: Add AV_OPT_TYPE_UINT64
[02:02:38 CET] <cone-763> ffmpeg 03Michael Niedermayer 07master:69f7dd3524d9: avcodec/options_table: make channel_layouts uint64
[02:38:01 CET] <BBB> jya: what kind of machine?
[02:59:46 CET] <jya> It's a MacPro, Xeon E5 8 core, 3GHz
[03:00:13 CET] <jya> BBB: AVCodecContext is configured with a thread count of 7
[03:00:27 CET] <BBB> what year mac pro?
[03:00:31 CET] <BBB> what chipset?
[03:21:40 CET] <drv> the latest Mac Pro has an Ivy Bridge Xeon, so no AVX2
[03:29:21 CET] <cone-763> ffmpeg 03Sam Hocevar 07master:3115550abe96: doc/examples/muxing: Fix av_frame_make_writable usage
[03:46:43 CET] <BBB> drv:I expected sth. like that, just wanted to make sure
[03:46:51 CET] <BBB> jya: try the new macbook pro (2015 or 2016)
[03:58:43 CET] <jya> BBB: how would they make a difference there?
[03:58:58 CET] <jya> the E5 is a v4 intel, it has full avx2 support
[03:59:00 CET] <BBB> the cpu supports avx2, unlike yours :-p
[03:59:08 CET] <BBB> there are no macbook pros with avx2
[03:59:18 CET] <BBB> er
[03:59:22 CET] <BBB> there are no mac pros with avx2
[03:59:27 CET] <jya> no?
[03:59:49 CET] <BBB> cat /proc/cpuinfo|grep -i avx2
[03:59:50 CET] <BBB> ?
[04:00:03 CET] <BBB> or as a control: cat /proc/cpuinfo|grep -i avx
[04:01:06 CET] <jya> ah right
[04:02:17 CET] <BBB> sorry
[04:02:28 CET] <BBB> good excuse to get a new macbook pro? ;)
[04:02:35 CET] <jya> gonna see the difference on my laptop (i-6700hq)
[04:02:53 CET] <jya> I have a gigabyte laptop with the same processors as in the new macbook pro
[04:03:04 CET] <jya> and twice the battery size for almost the same weight :)
[04:04:14 CET] <BBB> nice
[04:04:27 CET] <jya> (gigabyte aero 14)
[04:08:02 CET] <rcombs> above the FAA limit?
[04:36:21 CET] <jya> rcombs: nope, just under
[04:37:07 CET] <jya> I doubt anyone would ever check anyway. I've taken my electric unicycle on board once (260Wh battery) 
[04:40:12 CET] <rcombs> there are two limits
[04:41:01 CET] <rcombs> one that you can only have 2 of beyond (100Wh), and one that you can't have any of beyond (160Wh)
[04:41:46 CET] <rcombs> you're right that nobody checks individual packs, but selling things with batteries past the limit is liable to get you some questions from regulators
[04:55:54 CET] <cone-763> ffmpeg 03James Almer 07master:42ae9c66545e: fate: update fate-source ref file
[04:57:21 CET] <jamrial> philipl, BtbN: pushed the above fix for fate-source since it was painting the whole fate page yellow
[05:15:09 CET] <Compn> do any of you take precautions for the possibility of a cell phone battery burning a hole near your sensitive parts ?
[05:15:26 CET] <Compn> like removable pockets or fire extinguisher ?
[05:19:14 CET] <rcombs> I own fire extinguishers, but don't really take specific precautions against phone fires
[05:19:27 CET] <rcombs> they're so extremely unlikely unless you own a Samsung
[05:19:46 CET] <rcombs> far less likely than any number of other household fire scenarios
[05:19:55 CET] <rcombs> (yes I know it's not all Samsung models)
[05:19:57 CET] <Compn> i hear garage fires are common
[05:20:09 CET] <Compn> due to automobile fires
[05:20:21 CET] <rcombs> yup
[05:20:26 CET] <rcombs> you get a lot due to smoking materials
[05:20:29 CET] <Compn> faulty wiring too
[05:20:36 CET] <rcombs> often those are literal trash fires
[05:20:47 CET] <rcombs> kitchen fires are the most common, though
[05:21:34 CET] <rcombs> you get a few per year due to candles
[05:22:02 CET] <rcombs> Compn: http://www.nfpa.org/~/media/images/research/report-page-graphics/homestructurefires.jpg
[05:22:54 CET] <rcombs> cooking equipment fires are relatively unlikely to kill you, since you tend to be alert and in the room when it starts
[05:23:01 CET] <rcombs> and thus in a good position to put it out
[05:23:45 CET] <rcombs> smoking or heating equipment fires kill more people because they often go up while people are asleep, and/or start in a different room
[05:24:39 CET] <rcombs> btw, for li-ion fires, ABC dry-chem might do the job, but it's not always reliable in that scenario, and your best bet is dowsing with water
[05:24:54 CET] <rcombs> CO2 is not likely to be effective there
[09:38:04 CET] <wm4> wat.... https://github.com/kuscsik/FFmpeg/commit/2e260e4e8e5432d44551c0923cc59bda69e337ae
[09:40:19 CET] <wm4> (this adds a macro-block packed "nv12t" pixfmt for v4l)
[12:15:47 CET] <Kuroe> is h261 always 4:2:0 only?
[12:17:53 CET] <jkqxz> Yes.
[12:20:54 CET] <thardin> so it seems
[12:22:52 CET] <thardin> aw, firefox doesn't support h.261
[13:10:47 CET] <wm4> trying to come up with a way to make libswresample do better upmix
[13:10:59 CET] <wm4> by adding data from other channels, instead of just silence
[13:11:22 CET] <wm4> but it's complicated
[13:11:46 CET] <nevcairiel> upmixing is hard
[13:11:50 CET] <wm4> especially because upmix and downmix can happen at the same time
[13:11:52 CET] <nevcairiel> just copying channels sounds rather weird
[13:12:17 CET] <wm4> I thought about doing the same thing that downmix does
[13:12:20 CET] <nevcairiel> any good upmixers use more smart tools
[13:12:27 CET] <wm4> aha
[13:12:41 CET] <wm4> such as?
[13:14:22 CET] <nevcairiel> phase shifts at least
[13:15:12 CET] <wm4> huh, what for
[13:17:49 CET] <nevcairiel> as if i fully understand the audio theory, i just know that copying stereo into other channels sounds odd and doesn't give much of an impression of surround
[13:19:58 CET] <wm4> the question is whether it's better or worse than just silence
[13:20:06 CET] <nevcairiel> imho worse
[13:20:07 CET] <nevcairiel> :)
[13:20:17 CET] <cbsrobot_> wm4: I guess you already saw http://forum.doom9.org/archive/index.php/t-152034.html
[13:21:01 CET] <cbsrobot_> I tried all the profiles Selur posted and in general the grezen is satisfying
[13:21:26 CET] <nevcairiel> arent they mostly posting downmix profiles there
[13:21:40 CET] <cbsrobot_> just search for "grezen" on this page and you will see the sox example
[13:23:41 CET] <nevcairiel> at least there is a delay in those conversions, that makes it sound a bit more real
[13:24:27 CET] <nevcairiel> but its not something swr can do
[13:24:31 CET] <wm4> durandal_1707: well, there you have a filter request ^
[13:26:09 CET] <nevcairiel> you can probably do that with complex lavfi things
[13:26:11 CET] <nevcairiel> just not in one filter
[13:27:37 CET] <wm4> now if only lavfi had something like functions that can build certain filter sub-graphs
[13:27:45 CET] <wm4> instead of this inflexible madness
[13:31:33 CET] <wm4> I suppose one could just create a filter which creates a "private" second filter graph
[13:40:35 CET] <Kuroe> wm4: lavfi lavfi filter!
[13:47:32 CET] <wm4> I mean lavfi doesn't have a good separation between use cases (what a user wants to do to a video) vs. low level mechanism (what filters actually do)
[13:47:42 CET] <wm4> so you end up with ridiculous filter graph strings
[13:48:06 CET] <wm4> just to do something which should be simple
[13:54:53 CET] <durandal_1707> wm4: i did smth like that,  private filtergraph filter, named it conditional 
[14:09:50 CET] <durandal_1707> those up mixes on doom9 use reverbs 
[15:37:19 CET] <MZ_> Hello, I have a question about x264. the absence of references and documentation take me here. Can I ask you here? I know it is off-topic but I do not know where can I ask (on #x264 noone answered me)
[15:37:44 CET] <MZ_> I cannot understand what the last parameter of  x264_encoder_encode funciton is for. ( x264_picture_t* pic_out )     thank you in advance
[15:46:25 CET] <BBB> I think its the reconstructed image
[15:47:28 CET] <MZ_> BBB, but I've the original image and I'm encoding it. Why I need to have back again the same image?
[15:47:45 CET] <iive> it might be optional
[15:47:46 CET] <BBB> it gives you the pts/dts/poc of the output image
[15:47:48 CET] <bencoh> you'd still need it to get the dts
[15:47:53 CET] <BBB> it allows you to do encoder/decoder comparison
[15:47:59 CET] <iive> aka, if you want to check how much uglier is the encode
[15:48:02 CET] <BBB> theres a whole bunch of reasons why youd want the output
[15:48:06 CET] <bencoh> (or opaque, or any field that you might need)
[15:49:11 CET] <MZ_> ok, so it can be the decompressed ( compressed ( originalImage ) ) ? and isn't it more time consuming? 
[15:49:23 CET] <kierank> No because the encoder is doing it anyway
[15:49:32 CET] <MZ_> ok, thank you a lot!
[15:49:34 CET] <kierank> In order to use the exact reference frame
[15:49:50 CET] <BBB> pic_out is indeed decompress(compress(original_image))
[15:49:58 CET] <BBB> but without having to do the decompression manually
[15:50:03 CET] <BBB> since the encoder already had to do it anyway
[15:50:23 CET] <BBB> it also sets frametypes (is_keyframe) etc. if youre interested in that for container purposes
[15:50:46 CET] <BBB> (pic_out->b_keyframe)
[15:52:45 CET] <MZ_> ok, and I've another question.  Encoding in H.264 it may be the case that some frame exploit information redundancy with future frame. How it can be possible that anytime I call the encoder_encode function it generates the encoded data?
[15:53:21 CET] <nevcairiel> it doesnt
[15:53:36 CET] <nevcairiel> if you use a mode that would use future data, it would d elay  output
[15:54:09 CET] <MZ_> oh ok, but the output remain ordered?
[15:54:20 CET] <nevcairiel> yes
[15:54:28 CET] <nevcairiel> in decoding order, not input order
[15:55:02 CET] <bencoh> (meaning input order != encoded order)
[15:55:16 CET] <MZ_> yes, I'm thinking about that now...
[15:55:32 CET] <bencoh> (which is why dts != pts, btw)
[15:55:38 CET] <nevcairiel> when you decode, you get the same order back from the decoder as your input images used to be
[15:55:46 CET] <nevcairiel> in the middle between those, there can be reordering
[15:58:39 CET] <MZ_> I'm a little confused. On the web i found this snippet: http://pastebin.com/TxvXHx8j   each time this function is called, a frame is decoded.  This is only because the parameters are setted so that no interFrame redundancy is exploited?
[15:59:33 CET] <BBB> if !frame_finished return false
[15:59:49 CET] <BBB> so if you decode frame 0, then frame 2, on frame 2, frame_finished will be false and no frame was output
[16:00:03 CET] <BBB> then when frame 1 is decoded, it will return frame 1, and then later on subsequent calls it will actually return frame 2
[16:00:08 CET] <BBB> (which was cached internally)
[16:00:21 CET] <BBB> this is called delay :)
[16:00:37 CET] <funman> so i guess no other changes are needed
[16:00:37 CET] <MZ_> ok, it was quite simple. sorry
[16:00:49 CET] <funman> hm this is not my shell window, is it?
[16:01:39 CET] <MZ_> ok, thank you a lot!
[16:02:39 CET] <MZ_> you've really helped me. but why there is not a documentation?
[16:03:13 CET] <BBB> its an opensource project
[16:03:20 CET] <wm4> BBB: no excuse at all
[16:03:27 CET] <kierank> x264.h is heavily documented
[16:03:37 CET] <BBB> kierank: pic_out is undocumented :-p hes right
[16:03:38 CET] <wm4> ok, user error
[16:03:43 CET] <wm4> ok, not user error
[16:03:46 CET] <BBB> :D
[16:04:01 CET] <wm4> if you can't take 1 minute to document your API your API is probably shit
[16:04:22 CET] <BBB> MZ_: wm4 is right, its not a valid excuse, but as a practical matter, youll often find that not all opensource projects have excellent documentation; Im not saying thats how it should be, Im jut saying thats unfortunately how it is
[16:04:23 CET] <wm4> (too complicated, does too many things, does nothing well-defined, etc.)
[16:04:38 CET] <BBB> MZ_: if you want to contribute to x264 and fix/improve their documentation, I think theyd really appreciate it
[16:05:29 CET] <MZ_>  heavily documented.... looking in encoder_encode function you will not find that you have to copy the nals before recall the function. It is written in the struct definition.... I damn for it XD
[16:07:14 CET] <MZ_> BBB, yes but maybe i need to study a lot for doing that... I know nothing about that :(
[16:07:38 CET] <BBB> a small patch to add copy nals and pic_out is for & wouldnt require too much study
[16:07:45 CET] <BBB> Im not saying fix everything; just fix this small thing
[16:08:43 CET] <MZ_> BBB, yes you're right. I'll do it!
[16:09:39 CET] <bencoh> I suppose most people willing to use x264 end up reading either x264 implementation or other projects (ffmpeg, vlc, ...) wrapper code ...
[16:09:53 CET] <kierank> x264.c
[16:09:53 CET] <bencoh> (I personally did back then)
[16:09:57 CET] <bencoh> kierank: yeah :)
[16:10:13 CET] <kierank> but x264.c is quite complex actually
[16:13:39 CET] <BBB> MZ_: cool! tnx
[16:13:58 CET] <wm4> bencoh: just like most people trying to use the ffmpeg API will probably look at some other project
[16:14:03 CET] <wm4> or try to use the broken ffmpeg examples
[16:14:14 CET] <BBB> and then scream on stackoverflow that its not working
[16:15:18 CET] <wm4> these stackoverflow posts will get old fast
[16:20:08 CET] <MZ_> is there a way to know, foreach nal, at what frame refers to? suppose I've a counter that count all input frames
[16:21:32 CET] <kierank> pts
[16:21:47 CET] <kierank> and perhaps i_frame, if that's still there
[16:22:01 CET] <kierank> i think I use the opaque flag for that
[16:24:08 CET] <MZ_> I'm looking at x264_nal_t struct. where can I see the opaqueFlag?
[16:29:15 CET] <bencoh> wm4: indeed
[16:29:25 CET] <BBB> MZ_: x264_picture_t->opaque
[16:30:25 CET] <MZ_> so, first I set the opaque in the picture_t and than, after decoding, I will have the flag again?
[16:31:10 CET] <bencoh> yup
[16:31:46 CET] <bencoh> (but that part is actually documented in .h ;)
[16:34:18 CET] <MZ_> bencoh, I found this: /* private user data. copied from input to output frames. */ void *opaque; 
[16:34:26 CET] <MZ_> but how many bytes can I use?
[16:34:39 CET] <bencoh> the opaque is the pointer
[16:34:56 CET] <bencoh> the void* is copied. not the pointed data
[16:37:01 CET] <MZ_> but... the sizeof(void*) is platform dependent... I'm confused about that
[16:37:18 CET] <nevcairiel> does that matter? you know the size on your platform
[16:37:38 CET] <nevcairiel> its always the size of a pointer, so you can allocate whatever much data you need to pass
[16:38:24 CET] <MZ_> ok, so if I use ffmpeg to decode, how can I read that value whatever size it have?
[16:40:01 CET] <nevcairiel> i dont know whats so confusing about that, its a pointer to data you allocated, so you would know how to read it
[16:40:50 CET] <nevcairiel> and it doesnt get passed through to the decoder
[16:41:00 CET] <nevcairiel> its only for encoding
[16:41:22 CET] <nevcairiel> you pass it in x264_picture_t, and when you get the picture back out in an encoded form, the same value is given to you
[16:41:37 CET] <nevcairiel> so you c ould use it to associate some extra data with the picture and have x264 track it for you
[16:42:02 CET] <MZ_> ah! I was looking for a something to know, foreach nal at what frame belong. Because I need it on the receiver side
[16:42:36 CET] <MZ_> also, in the frame is good. But I need it on the receiver machine
[16:42:51 CET] <nevcairiel> it doesnt go into the encoded image, no
[16:44:02 CET] <MZ_> so there is not a way to add some kind of information to be sent to the decoding machine?
[16:44:30 CET] <kierank> there is poc
[16:44:45 CET] <kierank> but identifying frame is out of scope
[16:45:29 CET] <MZ_> where can I find something about poc? (i looked in the x264.h but I didn't find it)
[16:46:15 CET] <kierank> it's a bitstream field
[16:46:26 CET] <kierank> there's also timecode but we don't implement that
[16:48:08 CET] <MZ_> kierank, what does it means "it's a bitstream field"? sorry but I've missed the meaning
[16:48:23 CET] <kierank> there is a field in the h264 data stream that's an incrementing counter
[16:48:41 CET] <kierank> but frame identification is something you should do somewhere else
[16:50:09 CET] <MZ_> ok, now I will start coding without taking into account this problem. I will look at that later, thank you again
[19:03:59 CET] <cone-728> ffmpeg 03Paul B Mahol 07master:b96a6e2024fa: avfilter/vf_zscale: add support for some recent new additions
[20:52:31 CET] <philipl> BtbN: My change broke the transcoding. Setting the pix formats in the callback is too late.
[20:52:41 CET] <philipl> Not sure what the solution should be.
[20:52:56 CET] <BtbN> it worked when I tested it?
[20:53:06 CET] <philipl> What can I say.
[20:55:04 CET] <BtbN> hm, doesn't the pre-parser already give information about the bit depth?
[20:55:09 CET] <BtbN> So it is already known at init time?
[20:56:12 CET] <philipl> It's more subtle than that.
[20:56:20 CET] <philipl> The sw_pix_fmt doesn't need to be right.
[20:56:31 CET] <philipl> I'm not sure what the minimum set of information required is yet.
[20:56:58 CET] <BtbN> so it is enough to decide wether it is CUDA frame output or not?
[20:57:14 CET] <philipl> I think so
[20:57:45 CET] <BtbN> so just call ff_get_format in init, with only NV12 as option, and it will upgrade to a 10 bit format later on
[20:57:50 CET] <philipl> The hw sub fmt set in ffmpeg_cuvid decides on NV12
[20:57:56 CET] <philipl> Yes. That's what I think will work
[20:58:53 CET] <BtbN> also keep in mind the hack ffmpeg_cuvid.c does
[20:59:08 CET] <BtbN> it hardcodes the sw_format to NV12, so that's what filters and stuff might expect
[20:59:19 CET] <philipl> Yes, the hack is the thing that actually controls it.
[20:59:27 CET] <philipl> If I change the hack to P010, I can do 10bit->10bit transcoding.
[20:59:49 CET] <BtbN> do we already know the bit depth at the time it sets it to NV12?
[21:00:04 CET] <philipl> Dunno. I need to see when the callback fires relative to that.
[21:08:45 CET] <cone-728> ffmpeg 03Michael Niedermayer 07release/3.2:e9f3cc7fc784: avcodec/ass_split: Change order of operations in ass_split_section()
[21:08:46 CET] <cone-728> ffmpeg 03Michael Niedermayer 07release/3.2:dff4f58107cd: avformat/mpeg: Adjust vid probe threshold to correct mis-detection
[21:12:27 CET] <jkqxz> BtbN:  Do you have any interest in the VAAPI H.265 scaling list patch from yesterday?  (You wrote that file.)  If not, I would just apply it as-is - it works on Skylake for me.
[21:13:38 CET] <BtbN> https://patchwork.ffmpeg.org/patch/1380/ this?
[21:13:53 CET] <BtbN> ah, no, that's the encoder.
[21:14:19 CET] <BtbN> ah, this: https://patchwork.ffmpeg.org/patch/1526/
[21:15:21 CET] <philipl> BtbN: So, the decoder won't know the underlying format until the callback, and that happens inside the first decode_packet call. That's way to late for transcode initialization. By that point, nvenc has already allocated its surface pool.
[21:15:41 CET] <BtbN> So that's what was wrong with SLIST content, interesting.
[21:15:56 CET] <BtbN> jkqxz, yeah, feel free to apply.
[21:16:56 CET] <philipl> BtbN: Hmm. So nvenc_register_surface looks like its being lazy.
[21:17:02 CET] <philipl>     reg.bufferFormat       = ctx->surfaces[0].format;
[21:17:15 CET] <philipl> Why not map from the frame's actual format?
[21:17:53 CET] <jkqxz> BtbN:  Ok, will do soonish.  Thank you!
[21:21:12 CET] <BtbN> philipl, because it was written before that would have made sense, as it was allways NV12
[21:32:07 CET] <philipl> BtbN: So, roughly speaking, that register_surface call should get the sw_format from the frames_ctx. That value is correct today.
[21:32:22 CET] <philipl> In practice, it doesn't immediately work if the ffmpeg_cuvid.c value isn't the same. Dunno why yet
[21:35:14 CET] <philipl> the answer to that is likely the profile init. That looks at the pix_fmt early when it's not necessarily correct.
[21:36:38 CET] <philipl> Yeah. so the value in ffmpeg_cuvid.c dictates the profile, I think. And then if the frames are mismatched later, you get an 'invalid param' error back at registration time
[21:37:04 CET] <philipl> also setting of pixelBitDepthMinus8
[21:44:05 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/5d621f439885397245ef185e0e95fa65a516e043
[21:44:14 CET] <philipl> That fixes the regression. Doesn't help make 10bit transcode work
[21:45:19 CET] <BtbN> does the sw path still work, with switching to a non-NV12 format later on?
[21:45:49 CET] <philipl> Yes. I've tried it out. I can do a 10bit transcode without hwaccel (with or without that change)
[22:07:11 CET] <BtbN> I guess it's the best solution for now. But does the h264/hevc parser not write the information about the bit depth somewhere, so it can just be used directly?
[22:07:57 CET] <nevcairiel> you cant rely on input data
[22:08:12 CET] <nevcairiel> h264/hevc can be called without anything set
[22:08:37 CET] <BtbN> you can't rely on it, but you can use it was hint for the initial format
[22:08:43 CET] <BtbN> *as
[22:08:46 CET] <nevcairiel> seems ugly
[22:08:49 CET] <nevcairiel> fix ffmpeg.c instead
[22:08:50 CET] <nevcairiel> :D
[22:15:52 CET] <atomnuker> BBB: I'll send a new patch to remove ffserver soon
[22:16:09 CET] <BBB> I dont think the patch is the issue
[22:16:15 CET] <BBB> the issue is people keep bikeshedding the patch
[22:17:45 CET] <durandal_1707> it's awesome feature every body understand
[22:19:14 CET] <llogan> it's a dingleberry that we just can't shake
[22:20:21 CET] <atomnuker> BBB: only reynaldo did
[22:21:12 CET] <philipl> BtbN: You could, of course, make it the user's problem and add an explicit command line option.
[22:22:19 CET] <BtbN> Nah
[22:23:13 CET] <philipl> You good for me to push the regression fix?
[22:23:21 CET] <BtbN> yep
[22:23:30 CET] <BtbN> For now it at least gets working what worked before
[22:23:35 CET] <philipl> Yep
[22:23:53 CET] <cone-728> ffmpeg 03Philip Langdale 07master:dd10e7253abf: avcodec/cuvid: Restore initialization of pixel format in init()
[22:25:09 CET] <philipl> BtbN: we might need to restructure nvenc to push as much initialization as possible to when the first frame is received.
[22:25:53 CET] <BtbN> hmm
[22:26:07 CET] <BtbN> I'll have a look at that stuff tomorrow, don't really have too much time right now.
[22:26:21 CET] <philipl> sure
[22:36:21 CET] <cone-728> ffmpeg 03Wan-Teh Chang 07master:29fb49194bed: avutil/cpu: remove the |checked| static variable
[22:36:22 CET] <cone-728> ffmpeg 03Wan-Teh Chang 07master:d84a21207ea8: avutil/tests: Add cpu_init.c to check whether the one-time initialization in av_get_cpu_flags() has data races.
[22:40:10 CET] <cone-728> ffmpeg 03Jun Zhao 07master:584eea5bf3e4: lavc/vaapi_hevc: fix scaling list duplicate transfer issue.
[23:07:48 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/c16a86222f611efda85d7ec46e0439182ce67421
[23:08:30 CET] <BtbN> oh, nice. When did they get rid of that?
[23:16:12 CET] <philipl> I guess in 7.0
[23:16:20 CET] <philipl> although I'm only testing now with 7.1 (375.xx)
[23:16:29 CET] <philipl> if you're still running on a 7.0 driver, you could check.
[23:17:29 CET] <BtbN> 375 everywhere as well
[23:17:35 CET] <philipl> oh well.
[23:17:58 CET] <philipl> It seems like the kind of change you'd make in a major update :-P
[23:18:23 CET] <BtbN> I'd send it to the ML, as the people who originally introduced might want to say something about it.
[23:18:27 CET] <BtbN> +it
[23:18:43 CET] <philipl> As in the nvidia folks? I added the de-compensation code originally.
[23:18:57 CET] <BtbN> Wasn't that quite a bit of discussion originally?
[23:19:13 CET] <BtbN> Don't remember who participated anymore
[23:19:36 CET] <philipl> yes, but that was around whether it was right to de-compensate in a decoder as a matter of principle. I won out pointing out that the compensation in the deocder was equally inappropriate.
[23:20:30 CET] <philipl> anyway, I'll send it. Doubt we'll see a response.
[23:21:03 CET] <BtbN> Yeah, should be fine to push in a day or two.
[23:31:02 CET] <jya> BBB: i know it's not your code, but if there's one who knows it you :) Still about the vp9 alpha channel. You mentioned that libvpx simply took both data (plain and alpha) and simply output a decoded yuva
[23:31:22 CET] <jya> but the vpx_codec_decode simply takes a pointer to the data+size. 
[23:32:39 CET] <jya> oh it seems it's just how the libvpx ffmpeg decoder does it
[23:43:02 CET] <nevcairiel> iirc the alpha part was added by the google guys to our libvpx wrapper
[23:43:08 CET] <nevcairiel> but yeah its handled in there, not in vpx
[23:52:31 CET] <BBB> jya: yes, thats what I meant
[23:52:55 CET] <BBB> jya: so if you see ffvp9 as equivalent to libvpx, then the fflibvpx wrapper is what firefox should do to get the alpha channel, if that makes any sense ;)
[23:53:38 CET] <jya> BBB: yeah, we only use ffmpeg to use with ffvp9. We have a separate libvpx decoder that uses it directly
[23:54:14 CET] <BBB> dont you use ffvp8 and fftheora also?
[23:55:01 CET] <jya> nope
[23:55:10 CET] <jya> oh, we do use ffvp8
[23:55:17 CET] <BBB> I thought so
[23:55:19 CET] <jya> we use libtheora directly
[23:55:23 CET] <BBB> oh
[23:55:34 CET] <BBB> well, I dont know how ffmpegs theora decoder compares to libtheora TBH
[23:55:43 CET] <BBB> I mean, that format is so old, I wouldnt mind if it just died :-p
[23:55:54 CET] <jya> remember that all those decoders (opus, libvpx, openh264, vorbis etc) long predate our use of ffmpeg
[23:55:59 CET] <BBB> yeah
[23:56:14 CET] <jya> and we still use libvpx for webrtc
[23:56:18 CET] <BBB> right
[23:56:35 CET] <BBB> I wish I could be bothered to write reference frame management and error resilience/recovery in ffvp8/9
[23:56:37 CET] <jya> the webrtc folks had concerned about latency in ffvp9 as we only use it in multi-threaded mode
[23:56:56 CET] <BBB> ffvp8 implements slice threading, so thats just a setup thing
[23:57:01 CET] <BBB> ffvp9 doesnt implement tile threading yet
[23:57:39 CET] <jya> I'd be keen to remove libvpx alltogether
[23:57:41 CET] <BBB> but obviously right now libvpx is the tested baseline
[23:57:45 CET] <BBB> you need an encoder
[23:57:52 CET] <jya> maintaining two sets of code to do a similar thing is a bit silly
[23:57:57 CET] <jya> and that
[23:58:12 CET] <jya> i mean maintaining two code path
[00:00:00 CET] --- Thu Nov 24 2016