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

[burek]

[00:05:46 CET] <atana> michaelni, where can I find the defination of bytestream2_put_le16() or usage?
[00:06:46 CET] <durandal_1707> atana: in bytesteam.h header
[00:07:09 CET] <durandal_1707> libavcodec/bytestream.h
[00:07:32 CET] <durandal_1707> its very trivial
[00:07:42 CET] <atana> It has just one macro line 
[00:07:51 CET] <michaelni> atana, yes libavcodec/bytestream.h is a mess
[00:08:17 CET] <durandal_1707> bytestream2_init_writer
[00:08:31 CET] <durandal_1707> its not mess
[00:08:43 CET] <durandal_1707> libswscale is mess
[00:09:32 CET] <michaelni> atana, some code that uses it is in libavcodec/sgienc.c, not sure if another example is better
[00:10:08 CET] <michaelni> atana, enother example is libavcodec/wavpackenc.c
[00:10:26 CET] <durandal_1707> macros are easy to grasp
[00:15:23 CET] <jarkko> when you do x265 encoding does the encoder take into account the whole video clip when it seeks for duplicate patterns or only between frames?
[00:15:58 CET] <jarkko> for example cartoons would think that some patterns are repeated a lot (think about simpsons)
[00:27:59 CET] <jarkko> http://video.stackexchange.com/questions/13164/encoding-422-in-10-bit-with-libx264
[00:41:38 CET] <J_Darnley> You need to compile it as 10-bit (or use the patches currently on their mailing-list)
[00:41:58 CET] <J_Darnley> Oh, look that's the first answer
[00:49:08 CET] <philipl> BtbN: change looks good
[00:52:01 CET] <michaelni> jkqxz, maybe this but maybe its a duplicate ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -i ~/videos/matrixbench_mpeg2.mpg -map 0:1 -map 1:1,0:2  -vframes 1 a.mp4
[00:52:29 CET] <michaelni> its easier to find the next issue after the existing one is fixed
[00:58:16 CET] <michaelni> jkqxz, i think this one is not a duplicate ./ffmpeg -i ~/tickets/1726/Mono.thd  test.wav
[00:58:40 CET] <michaelni> test.wav is stereo and the right channel is mute 
[01:09:34 CET] <jkqxz> The matrixbench one looks new.  During flush, receive_packet() is called on an encoder that never got opened, so it throws an error.
[01:21:04 CET] <jkqxz> <http://sprunge.us/XUNF> avoids the immediate error from doing things with uninitialised encoders, but the output is still different because it has decided not to write anything given the empty stream.
[01:27:45 CET] <jkqxz> Hmm, actually it's worse than that.  Setting -vframes to a higher (>128, say) value buffers until it barfs on holding too make packets in flight, never making the second stream at all.
[01:28:39 CET] <jkqxz> Maybe tomorrow.  Also the audio one: I agree the output is wrong, no idea where that extra channel is coming from.
[01:32:55 CET] <cone-388> ffmpeg 03Lou Logan 07master:1c049d5ffe08: doc/ffmpeg: document trailing "?" in map option
[02:57:15 CET] <kierank> atomnuker: staying in a shady motel with two double beds
[02:57:23 CET] <kierank> I had to sign something saying I wouldn't do weed
[03:05:45 CET] <tmm1> think i finally tracked down this videotoolbox hwaccel crasher
[03:19:43 CET] <tmm1> rcombs: i posted a patch for the hwaccel to the list
[03:20:51 CET] <tmm1> i still have one sample that works fine with your decoder, but fails miserably with the hwaccel
[04:04:43 CET] <cone-388> ffmpeg 03Michael Niedermayer 07master:8fa18e042ad2: avformat/http: Check for truncated buffers in http_connect()
[04:40:28 CET] <pfanous> I need to incorporate x264, x265, and openh264 into the build to support encoding, but configure complains it's not available
[04:41:04 CET] <pfanous> ./configure --arch=x86 --toolchain=msvc --prefix='install' --target-path='build' --enable-shared --enable-gpl --enable-version3 --enable-avresample --enable-nvenc --enable-libopenh264 --enable-libopenjpeg --enable-libx264 --enable-libx265
[04:44:22 CET] <pfanous> JEEB: Do I need to install packages to support x264, x265, and openh264? I notice it tries running pkg-config.
[04:47:02 CET] <pfanous> Anyone know where I can find packages for x264 x265 and openh264?
[04:52:58 CET] <rcombs> why do you want openh264
[06:25:06 CET] <wm4> jkqxz: haven't taken a look at that yet, will soon
[07:35:15 CET] <cone-981> ffmpeg 03Rostislav Pehlivanov 07master:373ee2c61871: opus_rc: add entropy encoding functions
[07:35:15 CET] <cone-981> ffmpeg 03Rostislav Pehlivanov 07master:d2119f624d39: imdct15: rename to mdct15 and add a forward transform
[07:35:15 CET] <cone-981> ffmpeg 03Rostislav Pehlivanov 07master:e538108c219d: opus_celt: move quantization and band decoding to opus_pvq.c
[07:35:15 CET] <cone-981> ffmpeg 03Rostislav Pehlivanov 07master:07b78340dd1e: opus_celt: rename structures to better names and reorganize them
[07:35:15 CET] <cone-981> ffmpeg 03Rostislav Pehlivanov 07master:5f47c85e5c96: opus: add a native Opus encoder
[07:35:16 CET] <cone-981> ffmpeg 03Rostislav Pehlivanov 07master:3a7f0055b445: doc/encoders: add documentation for the Opus encoder
[07:35:16 CET] <cone-981> ffmpeg 03Rostislav Pehlivanov 07master:965503d3543c: MAINTAINERS: add myself as mdct/opus maintainer
[07:41:21 CET] <atomnuker> TD-Linux: well, now you no longer have to wait to hear how it sounds, you can just compile git master, lol
[07:41:47 CET] <TD-Linux> atomnuker, very nice
[07:41:51 CET] <TD-Linux> will try right now
[07:57:44 CET] <wm4> <michaelni> jkqxz, i think this one is not a duplicate ./ffmpeg -i ~/tickets/1726/Mono.thd  test.wav <- and where do I get that sample?
[08:02:13 CET] <rcombs> atomnuker: what metric is opusenc outperforming the universe by?
[08:05:52 CET] <rcombs> also who should I yell at to try to get opus to support channel layouts other than its preset list
[08:09:42 CET] <atomnuker> some universe: ds^2 = -dt^2 + dx^2
[08:10:00 CET] <atomnuker> ffopus outperforming that universe (for a > 1): ds^2 = -dt^2 + a^2(t)dx^2
[08:10:49 CET] <rcombs> I failed calculus
[08:11:00 CET] <atomnuker> I guess get libopus's API and try extending the wrapper
[08:11:22 CET] <atomnuker> it supports ambisonics, it should support alot less exotic layouts
[08:14:28 CET] <rcombs> currently doesn't support 2.1 or 3.1, 6.0, or 7.0
[08:22:29 CET] <nevcairiel> as far as i can see opus only supports either mono/stereo (type 0), its preset list (type 1), or ambisonics (type 2)
[08:22:42 CET] <rcombs> yeah
[08:24:07 CET] <TD-Linux> you can either extend the channel layout list or add a new one
[08:25:22 CET] <rcombs> wtb something PCE-style except actually implemented in lavc
[08:25:37 CET] <TD-Linux> PCE?
[08:25:45 CET] <nevcairiel> the problem with type 1 is that it only supports one layout per channel count, as the number of channels doubles as index into the layout list
[08:25:47 CET] <TD-Linux> (well I guess you'd need a second mapping)
[08:26:19 CET] <TD-Linux> yeah easiest way would be type 2 with the layouts you listed
[08:26:46 CET] <nevcairiel> ideally it would code the layout somehow instead of creating yet another list of things
[08:26:57 CET] <nevcairiel> but not sure if its designed to allow coding an extra value
[08:27:03 CET] <rcombs> is the ambisonics mapping actually useful for that sort of thing
[08:27:05 CET] <TD-Linux> well then you get to handle weird nonsensical layouts like front left and rear left
[08:27:33 CET] <TD-Linux> ambisonics only makes sense if you need to runtime derive the channel layout, generally
[08:28:30 CET] <rcombs> meanwhile in happy funtimes I recalled while grepping through old logs about this issue: apparently the Girls und Panzer BDs have 2.1 audio but it's muxed as 3.0
[08:28:59 CET] <nevcairiel> the real fun part starts when you try to play this in a naive player
[08:29:27 CET] <nevcairiel> even if the layout is correct on the codec side, like, just tell the audio driver about the channel layout and let it do its thing
[08:29:29 CET] <nevcairiel> good luck with that
[08:29:36 CET] <nevcairiel> in my experience any non-standard layouts will just break
[08:30:01 CET] <nevcairiel> i have some code on my side to padd things like 2.1 or 3.0 up to the nearest standard, ie. 5.1 in this case, so that audio devices dont go insane
[08:30:01 CET] <wm4> rcombs: what does "muxed as" mean?
[08:30:26 CET] <rcombs> I don't have the BDMV but it seems like it's coded as 3.0 on the discs
[08:30:33 CET] <rcombs> since every encode has it as 3.0
[08:30:46 CET] <wm4> what codec?
[08:31:03 CET] <rcombs> BD audio is PCM with some padding and framing
[08:31:06 CET] <nevcairiel> there is no way any player would know it s hould be something else
[08:31:12 CET] <nevcairiel> so why would they do that
[08:31:19 CET] <rcombs> well, except when it's AC3 or such but in this case it's PCM
[08:31:35 CET] <wm4> oh, PCM
[08:31:46 CET] <wm4> possibly makemkv bug? lol
[08:31:54 CET] <nevcairiel> bdmv pcm also has very limited layouts
[08:32:07 CET] <rcombs> yeah, it doesn't have a 2.1 layout
[08:32:13 CET] <rcombs> so they muxed it as 3.0
[08:32:19 CET] <nevcairiel> actually it appears to have a 2.1
[08:32:22 CET] <TD-Linux> mixing down to 2.0 would have been a much saner choice
[08:32:22 CET] <rcombs> or, coded or whatever you want to call it
[08:32:33 CET] <rcombs> yeah
[08:32:41 CET] <nevcairiel> pcm-bluray has 2.1 and 3.0, both
[08:32:43 CET] <nevcairiel> oddly enoughj
[08:32:46 CET] <nevcairiel> -j
[08:32:53 CET] <rcombs> libavcodec/pcm-bluray.c acts like it doesn't?
[08:33:03 CET] <rcombs> seems to have 2 3.0s though
[08:33:12 CET] <rcombs> one stereo+center, one stereo+center back
[08:33:13 CET] <nevcairiel> it has AV_CH_LAYOUT_SURROUND (which is 3.0) and AV_CH_LAYOUT_2_1
[08:33:39 CET] <nevcairiel> oh 2.1 is back center, not sub
[08:33:48 CET] <nevcairiel> AV_CH_LAYOUT_2POINT1 is sub
[08:33:49 CET] <nevcairiel> so confusing
[08:33:54 CET] <rcombs> yeah that's wacky
[08:34:06 CET] <nevcairiel> i could check the BD spec if thats right
[08:34:08 CET] <nevcairiel> but i'm lazy
[08:34:11 CET] <TD-Linux> oh I assumed sub
[08:36:19 CET] <TD-Linux> if it's really pro logic style 2+rear then quadraphonic mapping with "mono" rear opus channel makes plenty of sense
[08:36:29 CET] <nevcairiel> hm yeah its correct, the only lfe layouts it has are 5.1 and 7.1
[08:37:26 CET] <TD-Linux> (afaik every pro logic receiver has had 2 rear output channels)
[08:37:39 CET] <nevcairiel> but coding a sub in the center or a rear center is just dumb, either make it 5.1 with silent channels or just downmix the sub, using wrong layouts will never get you anything good
[08:39:00 CET] <wm4> just downmix everything to stereo
[08:39:06 CET] <wm4> 2 ears etc.
[08:45:13 CET] <jkqxz> wm4:  Look in the numbered ticket on trac.
[08:46:44 CET] <wm4> jkqxz: there's a link to a shitty file hoster, and the file is deleted there
[08:47:20 CET] <wm4> oh wait I entered the wrong number
[08:47:30 CET] <wm4> got it
[08:48:49 CET] <nevcairiel> what I found not too long ago, carl mirrors many of the trac samples here http://samples.ffmpeg.org/ffmpeg-bugs/trac/ .. in case the file l ink died
[08:52:17 CET] <wm4> anyway, still messing with the first failure that was pointed out a while ago
[10:08:00 CET] <wm4> who (effectively) maintains decklink?
[10:08:12 CET] <wm4> I'm seeing it's the only thing that still uses AVFMT_RAWPICTURE
[10:08:26 CET] <nevcairiel> noone, i guess
[10:08:32 CET] <nevcairiel> but yeah getting rid of rawpicture would be nice
[10:09:02 CET] <nevcairiel> doesnt help that its a hardware device which you cant work on otherwise
[10:09:21 CET] <wm4> hm Marton Balint has the most/recent contributions to it
[10:23:29 CET] <nevcairiel> in any case we have two alternatives to rawpicture, one of those should be fitting for decklink ;)
[10:23:53 CET] <wm4> 2?
[10:25:55 CET] <nevcairiel> technically 3 if you count rawvideo, which is often not fitting for non-file based formats
[10:26:54 CET] <nevcairiel> there is wrapped_avframe from libav, and the one nicolas build
[10:27:34 CET] <wm4> the latter is?
[10:27:46 CET] <nevcairiel> trying to find it
[10:32:32 CET] <nevcairiel> it was called uncoded_frame or soemthing
[10:32:57 CET] <nevcairiel> av_write_uncoded_frame etc
[10:33:10 CET] <wm4> ew
[10:33:20 CET] <wm4> why did this even get in
[10:33:36 CET] <nevcairiel> usual tactics probably, keep discussing until opposition goes away
[10:33:48 CET] <nevcairiel> it was 3 years ago by now already
[10:34:44 CET] <nevcairiel> there is exactly one muxer that implements this API, uncodedframecrcenc
[10:34:48 CET] <nevcairiel> its not exactly in use
[10:35:01 CET] <wm4> and libavdevice things I suppose
[10:35:24 CET] <nevcairiel> oh yeah all those weird audio outdevs have it
[10:35:28 CET] <nevcairiel> alsa, pulse
[10:35:47 CET] <wm4> such BS
[10:35:48 CET] <nevcairiel> and xv and opengl video out
[10:36:15 CET] <nevcairiel> it requires the user to call an entire new API, which makes it really awkward
[10:36:30 CET] <nevcairiel> wrapped_avframe at le ast fits into existing flows, just "encode" into that
[10:36:43 CET] <wm4> or they could have just created a proper API for that
[10:36:50 CET] <wm4> instead of awkwardly abusing the muxer API
[10:37:28 CET] <nevcairiel> nicolas argument was that the existing API flow is meaningless and a separate API is much nicer
[10:37:33 CET] <nevcairiel> how could you even come up with that
[10:37:54 CET] <wm4> maybe because ffmpeg.c uses that trollol
[10:38:10 CET] <wm4> hm, except ffmpeg.c doesn't use uncoded stuff anyway
[10:38:15 CET] <wm4> so, really no arguments there
[10:38:29 CET] <nevcairiel> the argument for keeping the original API actually was that ffmpeg could then use it, since its designed around handling AVPackets
[10:38:33 CET] <nevcairiel> so now it doesnt get used
[10:38:44 CET] <nevcairiel> typical nicolas mail thread, really
[10:38:50 CET] <wm4> lo
[10:38:51 CET] <wm4> l
[10:39:00 CET] <wm4> head->wall
[10:39:25 CET] <nevcairiel> luckily the way its designed it hides away in some dirty corner of avformat and doesnt have to bother anyone
[10:39:37 CET] <nevcairiel> noone cares about lavd outdevs and two random functions in avformat
[10:39:50 CET] <wm4> I guess so
[10:40:19 CET] <wm4> and the rawpicture API came only to my mind because there are really weird special-cases for it in ffmpeg.c
[10:40:44 CET] <nevcairiel> yeah i had to leave it in there years back when libav removed it because it was still in use
[10:40:54 CET] <nevcairiel> although some of that use went away now, guess decklink is the last of it
[10:41:26 CET] <wm4> seems so
[10:42:10 CET] <wm4> "ret = avcodec_copy_context(ost->st->codec, ost->enc_ctx);" excuse me what
[10:59:29 CET] <nevcairiel> we can probably clean up a variety of things after your merge, i reckon a bunch of the lowres hacks should be able to go  because we can now work on real dimensions
[11:00:42 CET] <nevcairiel> previously we had to have the hack so the demuxer had the right size already to init things
[11:00:42 CET] <wm4> first I have to add new hacks to make all "use cases" work
[11:25:51 CET] <wm4> ah wtf is this
[11:26:18 CET] <wm4> I've tested this with debian's ffmpeg as reference (it's 3.2 or something)
[11:26:26 CET] <wm4> but ffmpeg git master gives yet another result
[11:26:32 CET] <JEEB> top kek
[11:26:36 CET] <wm4> debian (ffmpeg 3.2):  Output stream #0:1 (audio): 0 frames encoded (0 samples); 2 packets muxed (29 bytes); 
[11:26:46 CET] <wm4> git master:  Output stream #0:1 (audio): 0 frames encoded (0 samples); 0 packets muxed (0 bytes); 
[11:27:11 CET] <nevcairiel> where did it find 2 packets from 0 frames :D
[11:27:19 CET] <wm4> good question huh
[11:27:26 CET] <nevcairiel> what does your branch do
[11:27:34 CET] <wm4> I suspect merged side data or some crap in the flush packet (is that even possible)
[11:27:44 CET] <wm4> my branch fails encoding because the encoder is not flushed (or something)
[11:27:54 CET] <nevcairiel> but there is nothing to encode
[11:27:56 CET] <wm4> no frame decoded -> no filter -> no flushing
[11:27:59 CET] <nevcairiel> whats the wanted behavior then?
[11:28:10 CET] <wm4> correction: no frame decoded -> no filter -> no encoder -> no flushing
[11:28:19 CET] <wm4> probably encoding a file with an empty audio track
[11:28:26 CET] <nevcairiel> but why would that be wanted
[11:28:38 CET] <wm4> because michaelni pointed that out as a failure?
[11:28:46 CET] <nevcairiel> so whats the end result now, the track just never shwos up?
[11:28:47 CET] <wm4> I guess he wants that?
[11:29:02 CET] <wm4> encoding just fails
[11:29:37 CET] <nevcairiel> in any case this is just a change in error handling to some degree, there is no valid outcome either way
[11:30:12 CET] <nevcairiel> does the file have a video stream to go with that, and if yes, is it s till identical?
[11:30:25 CET] <wm4> with this it behaves like git master: http://sprunge.us/ZBRZ
[11:30:30 CET] <wm4> although I didn't check exactly
[11:30:37 CET] <wm4> both produce a file with only a video track
[11:30:49 CET] <wm4> when running "ffmpeg -i small.mpg -vframes 3 blah.m4a"
[11:31:09 CET] <nevcairiel> yeah thats just super ugly, if there are no audio frames it should just skip the audio track
[11:31:28 CET] <wm4> maybe
[11:31:42 CET] <nevcairiel> makes no sense to explicitly create an empty track
[11:31:51 CET] <nevcairiel> in my experience that even trips up various players
[11:31:55 CET] <nevcairiel> having an audio track without content
[11:32:50 CET] <jkqxz> There is something else going on which means it makes no progress on some streams.
[11:34:19 CET] <jkqxz> See the matrixbench one with two explicit streams above.  The immediate failure there is that it tries to flush an encoder which doesn't exist, but if you increase the number of frames to output it just buffers the first stream until it falls over, never making any progress on the second stream.
[11:35:17 CET] <nevcairiel> is that the pts schedulign th ing again?
[11:36:19 CET] <wm4> where's the matrixbench test file?
[11:36:21 CET] <wm4> or does any work
[11:36:29 CET] <jkqxz> Any file works.
[11:36:43 CET] <wm4> "Too many packets buffered for output stream 0:0."
[11:36:50 CET] <jkqxz> Yeah.
[11:36:50 CET] <wm4> that error I guess
[11:38:14 CET] <nevcairiel> that happens with any files and what circumstances? usign vframes?
[11:38:53 CET] <wm4> it happens without vframes too
[11:39:09 CET] <nevcairiel> so basically any simple transcode is broken? =p
[11:39:13 CET] <jkqxz> Anything with two video streams.
[11:39:21 CET] <nevcairiel> i see
[11:39:35 CET] <nevcairiel> that was the missing clue :)
[11:40:10 CET] <BtbN> Can someone enlighten me what takes care of correctly settings avctx->sw_pix_fmt? All I can find is "avctx->sw_pix_fmt = fmt[n - 1];" in ff_get_format, which hardcoded sets it to the last format in the list.
[11:40:31 CET] <nevcairiel> the last format has to be the sw fmt, thats how it should work
[11:40:41 CET] <jkqxz> BtbN:  Yes, that is it.  The hwaccel setup in the decoder has to set it up so that works.
[11:40:50 CET] <wm4> nevcairiel, jkqxz: easy fix http://sprunge.us/UFKd
[11:41:06 CET] <BtbN> That seems super weird and fragil
[11:41:09 CET] <BtbN> e
[11:41:17 CET] <wm4> tries to decode on the stream that is not initialized yet
[11:41:31 CET] <wm4> BtbN: sure
[11:43:23 CET] <nevcairiel> so it tries to prefer the first unintialized output stream then, to ensure all are valid?
[11:44:06 CET] <nevcairiel> seems sensible, i guess
[11:45:58 CET] <nevcairiel> libavs ost selection is quite different
[11:46:19 CET] <nevcairiel> they manually track the position instead of using cur_dts
[11:47:00 CET] <nevcairiel> although one might think a not-inistalized stream has cur_dts == NOPTS and therefor gets preferred
[11:47:01 CET] <wm4> well lets see whether this garbage passes fate
[11:49:50 CET] <nevcairiel> yeah cur_dts is initialized to AV_NOPTS_VALUE for output streams, no clue where it would get a value from then
[11:50:01 CET] <nevcairiel> probably some other weirdo code somewhere
[11:50:25 CET] <JEEB> ffmpeg.c has that stuff just before VSYNC code
[11:50:26 CET] <JEEB> I think
[11:52:34 CET] <wm4> fate passed
[11:53:04 CET] <wm4> nevcairiel: I don't even get why that is needed - I think it's backwards
[11:53:16 CET] <wm4> instead the muxer API should tell the user which stream is preferred next
[11:53:39 CET] <nevcairiel> well, with complex filtering and whatnot thats really complicated
[11:53:46 CET] <nevcairiel> plus the muxer doesnt know what kind of timestamps might come up
[11:53:47 CET] <wm4> (the muxer takes care of interleaving streams, so it does that anyway)
[11:53:55 CET] <wm4> complex filtering should provide the same
[11:54:10 CET] <BtbN> wm4, can I push some of the cuvid patches that are currently on the filter-merge branch? Or will that mess things up?
[11:54:32 CET] <wm4> for filtering the user should be able to 1. set which outputs need new data, 2. query which inputs should be fed with new data
[11:54:41 CET] <nevcairiel> you could probably simplify that patch btw by folding the ost->initialized check into the cur_dts retrieval and use INT_MIN when its not initialized yet
[11:54:42 CET] <wm4> BtbN: wait a moment I'll force-push to it
[11:54:51 CET] <BtbN> wm4, no, to ffmpeg master I mean
[11:54:55 CET] <nevcairiel> not sure if its much nicer, but no extra tracking var
[11:55:01 CET] <wm4> BtbN: oh, sure
[11:56:13 CET] <wm4> nevcairiel: actually (lol): http://sprunge.us/CaBQ
[11:56:23 CET] <wm4> slightly simpler
[11:56:27 CET] <nevcairiel> guess that works
[11:56:51 CET] <nevcairiel> hopefully that doesnt cause it to break on some streams that never get any input
[11:57:08 CET] <nevcairiel> but i guess the same problem would happen with the cur_dts check anyway
[11:57:12 CET] <nevcairiel> it would just stick
[11:57:42 CET] <BtbN> the cur_dts check that spams the console on higher logging levels right now?
[11:58:36 CET] <nevcairiel> anyway the extra check should be fine
[11:58:41 CET] <wm4> BtbN: whoops did I do that
[11:59:42 CET] <wm4> pushed my filter-merge branch again
[11:59:46 CET] <BtbN> "cur_dts is invalid (this is harmless if it occurs once at the start per stream)" that message I mean
[12:00:00 CET] <nevcairiel> it always spammed that to some degree
[12:00:06 CET] <nevcairiel> no clue if its gotten more on the branch
[12:00:08 CET] <wm4> BtbN: it's currently at AV_LOG_DEBUG, I might have set it to higher at some point in the patch
[12:00:40 CET] <wm4> also cur_dts is an internal field, lol
[12:01:24 CET] <wm4> good opportunity to add a muxer API that tells you which is the next stream?
[12:02:50 CET] <wm4> -        if (enc->codec_type == AVMEDIA_TYPE_AUDIO && enc->frame_size <= 1)
[12:02:50 CET] <wm4> -            continue;
[12:02:54 CET] <wm4> I forgot about this
[12:02:57 CET] <wm4> what does it do?
[12:03:07 CET] <nevcairiel> skip invalid audio streams i reckon
[12:03:11 CET] <nevcairiel> no clue
[12:03:17 CET] <nevcairiel> does frame_size==0 have any special meaning?
[12:03:28 CET] <nevcairiel> or 1 for that matter
[12:03:28 CET] <wm4> fate passed without it, and I don't need to remove it anyway
[12:03:32 CET] <wm4> so whatever.
[12:04:01 CET] <cone-775> ffmpeg 03Timo Rothenpieler 07master:be74ba648cf4: avcodec/nvenc: push cuda context before encoding a frame
[12:04:01 CET] <cone-775> ffmpeg 03Timo Rothenpieler 07master:b7d480f4312c: avcodec/cuvid: update hw_frames_ctx reference after get_format call
[12:04:01 CET] <cone-775> ffmpeg 03Timo Rothenpieler 07master:ce79410bba77: avcodec/cuvid: set width and height before calling get_format
[12:04:01 CET] <cone-775> ffmpeg 03Timo Rothenpieler 07master:b6f4f0b14b0f: avcodec/cuvid: add format mismatch debug logs
[12:04:12 CET] <wm4> BtbN: btw. did this fix the issue?
[12:04:18 CET] <wm4> I mean
[12:04:22 CET] <BtbN> yes
[12:04:28 CET] <wm4> did "avcodec/nvenc: push cuda context before encoding a frame" fix the encode failure with filter-merge
[12:04:43 CET] <BtbN> it did
[12:04:47 CET] <wm4> wonderful
[12:04:53 CET] <BtbN> And I wonder why it ever worked before
[12:05:24 CET] <BtbN> It either is some implicit cuda context magic in nvenc, or the other cuda stuff is leaking a context somehow, somewhere
[12:05:42 CET] <BtbN> But I went through all the cuCtxCreate and cuCtxPush calls, and every single one of them has a matching Pop
[12:05:59 CET] <BtbN> So I guess it's just the former
[12:06:16 CET] <wm4> weird
[12:06:40 CET] <wm4> also curse nvidia for using TLS stuff
[12:06:48 CET] <wm4> that's only slightly better than opengl
[12:06:57 CET] <BtbN> TLS stuff?
[12:06:57 CET] <nevcairiel> isnt opengl also basically TLS
[12:07:03 CET] <nevcairiel> thread-local storage
[12:07:04 CET] <BtbN> You mean the active context per thread?
[12:07:05 CET] <wm4> yeah, actually it's just as bad
[12:07:09 CET] <wm4> BtbN: yeah
[12:07:51 CET] <BtbN> I'd much rather pass the context to every single function call that needs it
[12:07:56 CET] <BtbN> way less likely to cause confusing shit
[12:08:45 CET] <wm4> agreed
[12:09:53 CET] <BtbN> Could emulate that behavior with a wrapper around each function that does push/pop around it
[12:09:57 CET] <BtbN> but that would be quite some overhead
[12:10:34 CET] <nevcairiel> i dont know how bad that would be for cuda, but for opengl that would be terrible performance
[12:10:48 CET] <nevcairiel> because poping the opengl context also flushes it typically
[12:11:09 CET] <BtbN> from the looks of it all Push/Pop does for CUDA is setting some TLS variable that's used by the other functions
[12:11:17 CET] <BtbN> So it's rather lightweight
[12:13:15 CET] <nevcairiel> for opengl you are best served by sticking to one thread and just keeping the context active, anyway
[12:13:38 CET] <BtbN> Yeah, OpenGL has its shared contexts for multi threaded loading and stuff
[12:13:57 CET] <wm4> there are extension mechanisms that avoid flushing in opengl
[12:14:00 CET] <nevcairiel> and even that should be used with great care and forethought
[12:14:04 CET] <nevcairiel> yeah i saw those
[12:14:15 CET] <wm4> I agree that opengl + thread = shit, though
[12:14:43 CET] <wm4> unfortunately, d3d11 + threads = also shit
[12:14:56 CET] <nevcairiel> all the graphics apis are
[12:15:06 CET] <nevcairiel> presumably d3d12 and vulkan fix some of those
[12:15:16 CET] <wm4> maybe
[12:15:16 CET] <nevcairiel> but i didnt look at those at all
[12:17:14 CET] <wm4> nevcairiel: I'm having trouble to get it skip the audio stream somehow
[12:17:23 CET] <wm4> so I guess I'll keep my terrible hack
[12:17:34 CET] <BtbN> Guess I'll put a av_log after every single cuCtxPopCurrent and find the one where the returned new context is not null.
[12:17:38 CET] <wm4> "Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument"
[12:17:48 CET] <wm4> it seems you basically have to make up something
[12:18:30 CET] <nevcairiel> maybe failing is fine? wouldnt want to w rite empty streams, so letting the user know about that doesnt seem too terrible
[12:19:04 CET] <wm4> heh
[12:19:08 CET] <wm4> michaelni: well?
[12:19:42 CET] <nevcairiel> whats the dataflow like, when do streams even get created in the output format?
[12:20:39 CET] <nevcairiel> i suppose right away?
[12:20:47 CET] <nevcairiel> but only have their headers written later
[12:20:57 CET] <nevcairiel> maybe that part should also be skipped
[12:21:03 CET] <nevcairiel> hm
[12:22:26 CET] <wm4> write_header is called as soon as all output streams are initialized
[12:22:50 CET] <wm4> but it definitely misses the codec params, it also printed "[ipod @ 0x56281dc37ce0] sample rate not set"
[12:23:08 CET] <nevcairiel> yeah because those are filled from the first frame now
[12:23:10 CET] <nevcairiel> which wasnt there
[12:23:12 CET] <wm4> so making sure a dummy filter graph is initialized almost seems best to me
[12:24:34 CET] <wm4> we could also just try using the codec params of a random input stream (if there are any)
[12:24:54 CET] <wm4> (might encoding from a lavfi source filter, or video->audio, etc.)
[12:25:13 CET] <nevcairiel> where do the output streams even get created, i dont see any avformat_new_stream in ffmpeg.c
[12:25:29 CET] <nevcairiel> oh its in _opt
[12:25:33 CET] <wm4> yeah.
[12:27:08 CET] <nevcairiel> i dunno, inventing fake infos for an empty stream doesnt seem any better then complaining to the user that the stream is empty
[12:28:09 CET] <wm4> I'm fine with removing this hack and letting michaelni's case fail
[12:29:54 CET] <nevcairiel> not creating empty streams even seems like a net gain to me
[12:30:03 CET] <nevcairiel> had some problems handling those in the past =p
[13:04:15 CET] <BtbN> nevcairiel, you happen to know how exactly cuCtxPopCurent works? Shouldn't it return NULL when no other context is on the stack?
[13:04:34 CET] <nevcairiel> i thought it returns the context it just popped off
[13:04:42 CET] <nevcairiel> ie. yours
[13:04:48 CET] <BtbN> ah, hm
[13:05:13 CET] <BtbN> doc says "Returned new context handle" so I thought it'd maybe return the new one
[13:05:36 CET] <nevcairiel> If successful, cuCtxPopCurrent() passes back the old context handle in *pctx. That context may then be made current to a different CPU thread by calling cuCtxPushCurrent().
[13:06:29 CET] <BtbN> hm, need to print the stack depth somehow then
[13:07:01 CET] <nevcairiel> you could pop again and see if  something happens
[13:07:01 CET] <BtbN> or cuCtxGetCurrent 
[13:07:14 CET] <BtbN> hm, true
[13:07:22 CET] <nevcairiel> not sure getcurrent exists
[13:07:24 CET] <BtbN> just poping again everywhere, and see if it's not null
[13:07:31 CET] <BtbN> CUresult cuCtxGetCurrent ( CUcontext* pctx )
[13:07:32 CET] <BtbN> exists
[13:07:37 CET] <BtbN> but is not wrapped in ffmpeg
[13:07:45 CET] <BtbN> so poping again is easier
[13:13:02 CET] <BtbN> I never get null
[13:14:12 CET] <wm4> BtbN: lol... "fuck"?
[13:14:23 CET] <wm4> as in, you can't know at all
[13:14:36 CET] <BtbN> well, I always get the actually valid context I just created
[13:14:55 CET] <nevcairiel> did you clear your dummy variable in  between
[13:15:04 CET] <nevcairiel> and the function always reports success too?
[13:15:10 CET] <BtbN> hm, no.
[13:15:13 CET] <BtbN> Yeah, it never fails
[13:18:24 CET] <BtbN> gonna wrap that GetCurrent call, seems more reliable as it doesn't mess with state
[13:33:25 CET] <BtbN> no, everything is in order. No context leak.
[13:33:38 CET] <BtbN> So it's just some internal magic in nvenc that makes it work on master.
[13:34:24 CET] <BtbN> Probably if there is only exactly one cuda context, it uses that?
[13:34:29 CET] <BtbN> But nothing about that changed, hm
[13:38:43 CET] <wm4> I thought you said it works now?
[13:38:55 CET] <BtbN> Yes, but I'm trying to figure out why it ever worked before.
[13:39:12 CET] <BtbN> Even on unpatched master, adding a GetContext right before EncodePicture in nvenc returns nil. So I guess it is just because of some divine magic in nvenc.
[13:41:38 CET] <wm4> I thought GetContext never returned null?
[13:41:53 CET] <wm4> (sorry I'm not quite up to recent developments here)
[13:42:06 CET] <BtbN> PopContext never does
[13:42:15 CET] <BtbN> so I added GetCurrent, and used that instead
[13:42:25 CET] <BtbN> and it's always properly returning null, so no context leak
[13:43:18 CET] <wm4> ok
[13:47:26 CET] <jamrial> atomnuker: nice, opus encoder :D
[13:48:04 CET] <jamrial> once it's finished and the experimental flag removed we could change the default codecs of some muxers like matroska
[14:33:39 CET] <durandal_1707> atomnuker: you broke mplayer build
[14:40:11 CET] <wm4> that's because mplayer NIH's ffmpeg's configure
[14:40:15 CET] <wm4> (nobody knows why)
[14:43:33 CET] <JEEB> :D
[14:47:23 CET] <RiCON> it was broken with the vaapi commits too
[14:48:11 CET] <wm4> it gets broken very often
[14:48:13 CET] <RiCON> might as well add FFmpeg commits hashes to mplayer commits
[14:48:35 CET] <RiCON> to say "hey, this worked back here in this hash"
[14:52:46 CET] <JEEB> or just use submodules that are hooked to a hash?
[14:53:40 CET] <RiCON> svn has submodules?
[14:55:01 CET] <nevcairiel> kind of if the other repo is also svn
[15:00:40 CET] <JEEB> oh, right
[15:00:43 CET] <JEEB> mplayer still in svn
[15:00:44 CET] <JEEB> rip
[15:32:53 CET] <BBB> durandal_1707: wrong channel
[15:33:03 CET] <BBB> :)
[15:55:14 CET] <michaelni> atana, do you have time to continue working on peakpoints ?
[15:55:38 CET] <michaelni> i mean the peakints filter not the points specifically
[15:55:49 CET] <michaelni> peakPOints
[16:01:21 CET] <RiCON> atomnuker: ffmpeg keeps instantly crashing with encoding https://i.fsbn.eu/instantcrash.flac to ffopus
[16:18:39 CET] <atomnuker> RiCON: can't replicate at any bitrate
[16:19:22 CET] <atomnuker> can you give me a gdb backtrace?
[16:33:52 CET] <atana> michaelni, Yes. I will continue after 30 min going for dinner.
[16:34:05 CET] <michaelni> atana, ok
[16:36:20 CET] <RiCON> atomnuker: https://i.fsbn.eu/EwPV.txt
[16:44:30 CET] <RiCON> atomnuker: bt full, not sure if more useful: https://i.fsbn.eu/9Q8G.txt
[16:51:31 CET] <atomnuker> must have broken something, valgrind's reporting uninitialized stuff
[16:56:12 CET] <jamrial> RiCON: consider using --enable-debug=gdb --disable-optimizations to get better backtraces
[17:04:12 CET] <wm4> michaelni: your answer to your failing test case with the merge-filter patches?
[17:07:22 CET] <michaelni> wm4, which  test case ? IIRC there were 3+ 
[17:07:50 CET] <wm4> the blah.-m4a one
[17:11:21 CET] <michaelni> wm4, i have a few things locally ill finish first then ill look at what that one was about
[17:12:28 CET] <RiCON> jamrial: thanks, i'll keep that in mind
[17:14:11 CET] <cone-775> ffmpeg 03Joel Cunningham 07master:8c8e5d5286bf: HTTP: improve performance by reducing forward seeks
[17:14:12 CET] <cone-775> ffmpeg 03Michael Niedermayer 07master:db3507a670ae: avcodec/hevc_parser: export framerate, remove one dependency on the decoder
[17:14:14 CET] <cone-775> ffmpeg 03Thomas Stephens 07master:5fe2b437023f: avformat/dashenc: Only use temporary files when outputting to file protocol
[17:15:27 CET] <wm4> michaelni: to make it short, we think it might be better to let encoding fail than creating a stream with no packets
[17:17:56 CET] <wm4> michaelni: also the one with the multiple videostreams should be fixed in my branch
[17:19:38 CET] <michaelni> wm4, the blah one seems not to fail with your branch
[17:21:37 CET] <wm4> michaelni: yes, but we think maybe it should fail
[17:27:28 CET] <michaelni> this could be quite annoying to the user, if for example it happens with a subtitle stream and there are no subtitles for the period of a encoded segment
[17:27:41 CET] <RiCON> jamrial: backtrace looks the same, do i need to remove "-O3 -march=native" from the CFLAGS too?
[17:27:58 CET] <atana> michaelni, what is second argument of bytesteam2_put_le() first in PutContext 
[17:28:03 CET] <wm4> michaelni: it doesn't happen with subtitle streams because they're not filter inputs
[17:28:04 CET] <atana> *us
[17:29:36 CET] <nevcairiel> subtitles also dont have any codec parameters (typically) that it might be missing
[17:29:41 CET] <michaelni> atana, first is PutByteContext *, 2nd is the value that is being stored
[17:29:48 CET] <nevcairiel> but without passing a frame through, we dont evne know the properties of the stream
[17:29:55 CET] <michaelni> as in the frequency of the peak for example
[17:30:04 CET] <jamrial> RiCON: odd, --disable-optimizations should remove the -O3
[17:30:04 CET] <nevcairiel> and empty audio and video streams can cause issues for players
[17:30:35 CET] <michaelni> the blah file seemed to only contain a video stream with a paket
[17:30:45 CET] <atana> michaelni, what is it's type? uint8_t * ?
[17:30:52 CET] <michaelni> nevcairiel, maybe i missed it but i saw no 2nd stream
[17:31:14 CET] <nevcairiel> you also wouldn't be able to mux very long files where one stream would be missing data, because the queues w ould run out of space
[17:31:26 CET] <nevcairiel> since it cant write the file headers before all streams are inited
[17:32:02 CET] <nevcairiel> (subtitles are exempt from that, i think)
[17:32:07 CET] <michaelni> atana, the uint8_t* array into which things are written is set with bytestream2_init_writer(), 
[17:32:08 CET] <jamrial> RiCON: but yes, that flag is what makes backtraces be full of <optimized out> lines
[17:32:26 CET] <michaelni> atana, bytestream2_put_be24() takes the PutByteContext and value to be writen into the array
[17:32:46 CET] <michaelni> be24/le16/... whatever they are all the "same"
[17:33:08 CET] <nevcairiel> michaelni: not sure which particular version of the file you are looking at now, but the problem we had was an empty audio stream that never had any data, iirc
[17:33:22 CET] <atana> so what should be type of second argument (any type)?
[17:33:42 CET] <michaelni> atana, int
[17:33:48 CET] <atana> ok
[17:34:17 CET] <michaelni> nevcairiel, when i looked the file actually written looked like it had only 1 stream (i did look with MP4box -v)
[17:34:27 CET] <michaelni> but maybe we are looking at different things
[17:35:13 CET] <nevcairiel> maybe movenc drops empty streams?
[17:35:48 CET] <nevcairiel> i didnt really check the resulting output file, just what ffmpeg said it did :D
[17:36:06 CET] <nevcairiel> (or failed at doing, depending which state of the patch we had)
[17:37:20 CET] <nevcairiel> but anyway even without the sample its a general question - if you try to encode some audio or video stream and it turns out to be empty in the output file, should that j ust silently  do something, or fail, as empty streams are kinda invalid?
[17:39:09 CET] <michaelni> i would say its user choice, having to manually remove streams to avoid failure on a random set of files can be quite annoying i imagine
[17:40:18 CET] <nevcairiel> wm4: i wonder if you can delete streams again if they never had any input
[17:40:28 CET] <nevcairiel> probably not 
[17:41:47 CET] <wm4> yeah, it seems like movenc drops empty streams
[17:42:52 CET] <wm4> changing the container to mkv gives an empty stream instead of missing stream
[17:43:07 CET] <nevcairiel> movenc can do that with its late header writing
[17:43:16 CET] <nevcairiel> other containers couldnt
[17:43:25 CET] <wm4> so I'll just sidestep the discussion and add another shitty hack to ffmpeg.c (i.e. keep the one in my branch)
[17:49:24 CET] <michaelni> wm4, in your branch src/ffmpeg.c:1866:21: error: void function 'flush_encoders' should not return a value [-Wreturn-type]
[17:50:45 CET] <BBB> kierank: do you still have your haswell ffdev machine?
[17:51:06 CET] <wm4> michaelni: whoops
[17:51:19 CET] <kierank> It is in pieces currently, we have others though
[17:53:13 CET] <wm4> michaelni: updated
[17:53:55 CET] <BBB> kierank: others by you or by other devs? and any haswell there?
[17:54:09 CET] <BBB> kierank: I have a student that wants to write avx2 assembly but he has a sandybridge machine
[17:54:23 CET] <BBB> trying to see if we can solve that
[17:55:31 CET] <wm4> aren't haswell or later systems easy to get by these days?
[17:57:31 CET] <Chloe> BBB: you teach? 
[17:57:49 CET] <BBB> gsoc student
[18:00:06 CET] <Chloe> Ah right 
[18:01:35 CET] <michaelni> btw talking about gsoc ... noone replied to my outreachy question on the ML, we could still try to get ffmpeg in for the "summer" 2017 round 
[18:16:12 CET] <RiCON> jamrial: yeah, removing -O3 worked
[18:16:20 CET] <RiCON> atomnuker: bt full with --disable-opts  https://i.fsbn.eu/FTDY.txt
[18:22:40 CET] <kierank> atomnuker: hello
[18:22:52 CET] <kierank> Look to your right
[18:26:19 CET] <BBB> lol
[18:26:20 CET] <durandal_1707> hello, its me
[18:30:35 CET] <kierank> atomnuker: do they have plugs where you are
[18:31:21 CET] <TD-Linux> kierank, there are power strips along the steps on the floor
[18:31:36 CET] <TD-Linux> (under the chair)
[18:36:28 CET] <kierank> Ok i see now it's some weird us power strip
[18:36:57 CET] <TD-Linux> kierank, the miracle of small outlets
[18:37:53 CET] <kierank> TD-Linux: https://www.youtube.com/watch?v=UEfP1OKKz_Q
[18:38:35 CET] <kierank> BBB: yes but it will require some port forwarding (but maybe we should put a machine on public ip instead)
[18:38:53 CET] <kierank> haswell, ivy and skylake
[18:39:02 CET] <BBB> ok cool
[18:39:54 CET] <kierank> not ivy, broadwell I mean
[18:45:50 CET] <BtbN> hm, my Server is only Ivy Bridge. Could have set up a shell account on there immediately.
[18:46:18 CET] <BtbN> But I think in AWS free tier, you get a server that's at least Haswell?
[18:46:28 CET] <BtbN> not an overly fast one though
[18:47:26 CET] <jkqxz> Also not a useful platform for testing anything performance-related, if that is the goal.
[18:48:43 CET] <kierank> we have a lot of machines, just behind our firewall
[18:52:49 CET] <atana> michaelni, what should be second argument (flag) for avpriv_open()?
[18:53:17 CET] <philipl> BtbN: regarding b7d480f4312c5ce7d8ce2f6eb7189f0d96ad5bde
[18:53:33 CET] <philipl> Shouldn't you ref the new one before unreffing the old context. Just in case they are the same and you're the last ref holder?
[18:53:37 CET] <philipl> I guess that's never true in practice.
[18:54:05 CET] <BtbN> If the ref in avctx and the local ctx are the same, something went wrong elsewhere
[18:54:24 CET] <philipl> fair.
[18:54:39 CET] <BtbN> even if it's not updated in between, there is a ref in avctx
[18:54:54 CET] <BtbN> Something went horribly wrong if cuvid thinks it owns the one thats in the avctx
[18:57:24 CET] <michaelni> atana, O_RDWR probably 
[19:34:07 CET] <atana> michaelni, O_RDWR is undefined. also do we need any specific header file for write and close function in context with ffmpeg lib?
[19:48:27 CET] <michaelni> atana, add #include <fcntl.h> for O_RDWR
[19:50:41 CET] <michaelni> atana, for avpriv_open() add #include "libavutil/internal.h"
[19:52:39 CET] <atana> write() and close() is not identified
[19:55:20 CET] <michaelni> atana, #if HAVE_UNISTD_H
[19:55:20 CET] <michaelni> #include <unistd.h>
[19:55:20 CET] <michaelni> #endif
[20:00:52 CET] <kierank> atomnuker: https://www.phoronix.com/scan.php?page=news_item&px=AV1-Codec-FOSDEM-2017
[20:00:59 CET] <kierank> congratulations, you made "moronix"
[20:05:35 CET] <RiCON> and they point to a 404
[20:09:54 CET] <TD-Linux> I forgot my cone hat at home
[20:16:14 CET] <durandal_170> michaelni: is there a way for demuxer to work with parser so it splits packets that are actually superpackets?
[20:17:45 CET] <durandal_170> stupid container stores multiple frames into one packet and multiplex audio with it
[20:30:38 CET] <durandal_170> it looks like it stores 25 nonkeyframes after each keyframe
[20:32:02 CET] <kierank> TD-Linux: outrageous
[20:32:15 CET] <TD-Linux> kierank, luckily it's easy to fetch
[20:32:22 CET] <michaelni> durandal_170, parsers can split stuff into packets if you set need_parsing, not sure thats what you meant
[20:35:29 CET] <llogan> TD-Linux: hat? I thought they were codpieces.
[20:36:14 CET] <TD-Linux> llogan, wizards exclusively wear heats.
[20:36:16 CET] <TD-Linux> *hats.
[20:36:38 CET] <kierank> I need to make it clearer that the hats are available to take
[20:36:55 CET] <TD-Linux> we will solve that @ lunchtime
[20:40:15 CET] <atana> michaelni, I have udpdated the repo. line 543 bytestream2_init_writer(pb, entry, buf_size); segfaults. valgrind says unintialized value of size 8. does pb needs to be initialized or allocated some memory? 
[20:46:16 CET] <michaelni> atana, entry needs to be large enough to hold everything. That is if you want to store the song name and artist as strings then it needs to be allocated with av_malloc() based on sum of the strlens of the songname and artist
[20:46:47 CET] <michaelni> strlen() + strlen() + size_of_everything_else
[20:48:30 CET] <michaelni> atana, also ','and ':' do not work as seperators of binary data, they are just small numbers and cant be distingished from the oter numbers
[20:49:06 CET] <michaelni> they are also a waste of space
[20:53:32 CET] <michaelni> atana, i see now you dont store things as strings, but a song_id of 1, so you dont need malloc() the array is ok but it needs to be bigger
[20:54:16 CET] <michaelni> atana, each value you store with bytestream2_put_le16() needs 2 bytes , the le16 means little endian 16bit aka 2 bytes
[20:55:32 CET] <durandal_170> michaelni: there are packets already. it have one big packet with concatenated frames and keyframe
[20:55:38 CET] <michaelni> 16+4+2 is too small, the 8 frequncies need 16, the 8 time values need 16, the seperators need 16 for each too if you store them 
[20:55:42 CET] <kierank> TD-Linux: can you wear a hat with me
[20:55:46 CET] <kierank> I don't want to wear it on my own
[20:57:31 CET] <durandal_170> kierank wears only hat and nothing else
[20:58:18 CET] <TD-Linux> kierank, absolutely
[20:58:39 CET] <atana> ok. what about the separator you said it can't be distinguished ? what's other alternative?
[20:59:27 CET] <michaelni> atana, atm this looks like it needs nothing, its all the same length, we may need something later
[21:00:21 CET] <michaelni> like a number that tells the number of entries following or a -1 as seperator of some things but its not needed with the data stored currently
[21:01:22 CET] <atana> should I remove separator ?
[21:01:32 CET] <atana> or leave it for now
[21:01:44 CET] <michaelni> atana, remove them its simper
[21:01:56 CET] <michaelni> atana, also the '\n'
[21:03:00 CET] <atana> yes
[21:08:40 CET] <michaelni> atana, also add O_APPEND to O_RDWR so its O_RDWR|O_APPEND i forgot about that
[21:08:53 CET] <durandal_170> michaelni: so there is no way to split this big packets into smaller pieces?
[21:09:36 CET] <michaelni> durandal_170, parser can split "packets" that come out of a demuxer into smaller packets 
[21:10:20 CET] <durandal_170> michaelni: i set needs parsing but it does not work
[21:11:33 CET] <michaelni> atana, PutByteContext *pb; should be PutByteContext pb; and the code should all use &pb
[21:13:08 CET] <atana> ok
[21:14:41 CET] <michaelni> atana, also minor "cosmetic cleanup" i suggest to replace "buf_size = 16+4+2;" by buf_size = sizeof(entry); that way it will be always the size use din the array declaration and harder to change one and forget the other
[21:20:42 CET] <jarkko> is this ever happening? https://bugzilla.mozilla.org/show_bug.cgi?id=563206
[21:20:55 CET] <michaelni> atana, you need something like avpriv_open(filename, O_RDWR|O_CREAT|O_APPEND, 0666); otherwise it doesnt work
[21:21:25 CET] <michaelni> atana, also i suggest "PPDB-%d" as filenames, thats easier to cleanup 
[21:21:37 CET] <michaelni> that is with rm PPDB-*
[21:21:52 CET] <atana> ok
[21:26:01 CET] <atana> so that makes length+1+5 (PPDB- len)
[21:31:03 CET] <michaelni> atana, you can compute length for  "PPDB-%d" too then its just the same length+1
[21:31:35 CET] <michaelni> atana, that is use  "PPDB-%d" in both snprintf
[21:31:56 CET] <atana> ok
[21:39:55 CET] <RiCON> BtbN, philipl https://www.techpowerup.com/230647/nvidia-releases-the-378-66-game-ready-drivers
[21:40:36 CET] <BtbN> Video SDK 8.0 isn't exactly new
[21:40:49 CET] <nevcairiel> of course it is, 8.0 isnt even released yet
[21:40:53 CET] <nevcairiel> latest is 7.1
[21:47:04 CET] <philipl> So, remembering that all the actual functionality is in the driver and not the sdk...
[21:47:15 CET] <philipl> That means vp9 10bit should work with those drivers.
[21:47:34 CET] <philipl> unless there's some different way of activating it from we do today for hevc 10bit.
[21:47:39 CET] <RiCON> how nice, thought it was a hardware limitation
[21:48:02 CET] <philipl> It is hardware dependent but the pascal stuff as the hardware. They just haven't shipped drivers until now.
[21:48:04 CET] <nevcairiel> dxva doesnt expose 10-bit vp9 with those, only on 1050  (Ti)
[21:48:14 CET] <nevcairiel> so presumably its not in all pascal cards
[21:48:22 CET] <philipl> we had this conversation last time :-)
[21:48:47 CET] <nevcairiel> well the point is, older drivers exposed it on the 1050 already
[21:48:48 CET] <philipl> Their web page states very clearly that it should work across all pascal hardware except GP100 (and maybe not GP102)
[21:48:51 CET] <nevcairiel> and these drivers changed nothing
[21:48:58 CET] <philipl> but no proof until the drivers do something
[21:49:21 CET] <philipl> nevcairiel: you tried this driver? No change?
[21:49:39 CET] <nevcairiel> i did, and no
[21:49:44 CET] <philipl> If it's positioned as an SDK feature, then they are only making the claim about cuvid.
[21:49:54 CET] <philipl> If you can be bothered, try with cuvid.
[21:49:59 CET] <philipl> or did you already?
[21:51:20 CET] <michaelni> atana, I think things will be easier if the code from "// get rid of invalid points" up to and including "p->size = mark_index;" is removed, that leaves -1 in the array, we use only f1 for the filename ATM and we want to store all 8 peak points
[21:52:06 CET] <nevcairiel> not through cuvid,  didnt have that infrastructure setup yet
[21:52:40 CET] <philipl> There's a new linux driver today too, but I can't check that until I get home. I don't expect it to be enabled though.
[21:53:29 CET] <philipl> BtbN: You have both linux and windows boxes to test with, don't you?
[21:53:35 CET] <atana> michaelni, then some peak points among 8 will have -1 value. is it ok?
[21:54:18 CET] <michaelni> atana, i think its simpler if we store exactly one fft window in each entry of the file, just 8 frequency values, some -1 yes
[21:54:31 CET] <atana> ok 
[21:54:55 CET] <michaelni> as is we store 8 but crossing over multiple  windows i think that would be harder to work with
[21:55:39 CET] <atana> michaelni, I have updated the repo.
[21:56:06 CET] <BtbN> philipl, Linux only with a fairly old GPU
[21:56:07 CET] <atana> also you mentioned about adding some variable in avoption
[21:56:21 CET] <atana> for lookup or storing
[21:57:15 CET] <atana> should one variable would be enough having 0 or 1 value for lookup or search respectively
[21:58:08 CET] <michaelni> atana, might be enough yes, 0,1
[21:58:22 CET] <atana> any name of variable?
[22:00:10 CET] <michaelni> atana, hmmm, "mode" should be fine
[22:11:51 CET] <durandal_170> atana: what is your repo?
[22:13:04 CET] <atana> durandal_170, https://github.com/atana1/FFmpeg
[22:26:35 CET] <tmm1> jkqxz: this "Hardware frame mapping" you landed on libav master would improve vf_hwupload performance right
[22:29:35 CET] <BtbN> nevcairiel, philipl: **** VP9 10/12 bit decode support is limited to select Pascal chips
[22:29:44 CET] <BtbN> HEVC should work on all
[22:31:52 CET] <jkqxz> tmm1:  Yeah, it can.  You can avoid a copy when some other operation can use the software-mapped frame.
[22:32:19 CET] <jkqxz> Though the real aim of that stuff is hardware mapping, which is not yet in.
[22:32:31 CET] <jkqxz> (That is, mapping between hardware APIs.)
[22:35:08 CET] <tmm1> oh cool
[22:47:52 CET] <tmm1> this old 3.10 kernel seems to be bottlenecking in hwupload somewhere
[22:47:59 CET] <tmm1> patch didn't help :\
[22:48:19 CET] <RiCON> BtbN: hevc10 was already tested to work fine
[22:48:23 CET] <RiCON> decoding, that is
[22:49:27 CET] <BtbN> Yeah, all about VP9 now
[22:52:20 CET] <jkqxz> tmm1:  Make sure you set the mapping mode.  If you're using it in place of hwupload then you probably want write+overwrite.
[23:06:36 CET] <rcombs> and don't use old 3.10 kernels
[23:53:33 CET] <nevcairiel> BtbN: guess that settles that discussion
[23:53:33 CET] <nevcairiel> only 1050 (Ti) for vp9-10
[23:53:34 CET] <BtbN> so they pulled that shit again
[23:53:34 CET] <nevcairiel> newer models getting newer features?  well not that unusual
[23:53:46 CET] <nevcairiel> they exchanged media blocks in the same series before
[23:53:51 CET] <BtbN> the lower end cards ending up with more features.
[00:00:00 CET] --- Wed Feb 15 2017