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

[burek]

[00:07:00 CET] <Chloe> wat. why can avctx->pkt_timebase.num be 0?
[00:09:46 CET] <atomnuker> single pictures?
[00:10:24 CET] <Chloe> It's teletext
[00:14:39 CET] <cone-657> ffmpeg 03Michael Niedermayer 07master:daccbe81a2be: avcodec/mjpegenc: Drop i_tex misuse, set itex/header bits correctly, fix 2pass encoding
[00:14:39 CET] <cone-657> ffmpeg 03Michael Niedermayer 07master:d23af72a0cb8: avcodec/tests/mjpegenc_huffman: Remove static in main() table
[00:14:39 CET] <cone-657> ffmpeg 03Michael Niedermayer 07master:b39129b68e77: avcodec/mjpegenc_huffman: remove unneeded header include
[00:14:39 CET] <cone-657> ffmpeg 03Michael Niedermayer 07master:f57665b3181d: avcodec/mjpegenc: Revert some differences in ff_mjpeg_encode_mb() relative to pre optimal huffman
[00:14:39 CET] <cone-657> ffmpeg 03Michael Niedermayer 07master:3e1507a9547a: avcodec/mjpegenc: Bypass the 2 pass encoding when optimal tables are not requested
[00:45:15 CET] <JEEB> how bad does this look? https://github.com/jeeb/ffmpeg/commit/8ccc29646f981ee755d6850a97697e41ef24f8c6
[00:47:06 CET] <JEEB> not sure I like the way I'm creating the track name but I couldn't think of a much better way :V
[00:48:46 CET] <atomnuker> michaelni: thanks, is there anything left to fix with the mjpeg huffman patch you noticed?
[00:50:36 CET] <michaelni> atomnuker, i just tried to make it not fail with 2pass or threads, with optimal tables enabled 2pass should work but slice threads will not
[00:51:03 CET] <michaelni> so that could be improved
[00:51:19 CET] <michaelni> also there likely is more that can be improved
[00:52:30 CET] <michaelni> i still have a patch locally i need to push
[00:53:59 CET] <atomnuker> JEEB: " lang ? lang->value : "und"," <- und?
[00:54:30 CET] <JEEB> undefined
[00:54:40 CET] <JEEB> it's used in the systemLanguage tag as well
[00:56:33 CET] <JEEB> so I get video_eng, audio_und here without any relevant disposition from a simple matroska file
[00:56:41 CET] <michaelni> atomnuker, btw, different subject but i see "FFA1 Codec Research" idea has several "TBA", ideally the page should have few or no placeholders and be good looking when google reviews it
[00:58:00 CET] <atomnuker> I'm thinking of changing it, it might be too difficult
[00:58:50 CET] <JEEB> atomnuker: I thought about not including the undefined case there but then I would have to use snprintf or so to append the underscore to the language tag
[00:59:19 CET] <JEEB> as in, having just "audio" or "video", which are the default values in smooth streaming as well
[01:00:21 CET] <JEEB> such simple string manipulation seems rather herp derp in C unless you're dealing with "one string" "second string", which makes simple concatenation simple
[01:01:02 CET] <JEEB> I guess I'll sleep over it
[01:06:25 CET] <cone-657> ffmpeg 03Michael Niedermayer 07master:ce6e7a2db1a4: avcodec/mjpegenc: Simplify by moving assert into ff_mjpeg_encode_huffman_close()
[07:37:24 CET] <wm4> Chloe: pkt_timebase is normally optional
[07:38:12 CET] <wm4> misguided ffmpeg development that doesn't care about its own API probably changed that to a degree
[07:38:32 CET] <wm4> Libav doesn't even have the field
[11:07:19 CET] <wm4> BtbN: so I'll prepare my ffmpeg.c filter patches and send them now
[12:14:33 CET] <cone-770> ffmpeg 03Matt Wolenetz 07master:9bbdf5d921ef: lavf/mov.c: Avoid OOB in mov_read_udta_string()
[12:14:34 CET] <cone-770> ffmpeg 03Matt Wolenetz 07master:36aba43bd5fa: lavf/mov.c: Avoid heap allocation wraps in mov_read_{senc,saiz}()
[12:35:18 CET] <cone-770> ffmpeg 03Carl Eugen Hoyos 07master:3ea9773793ab: lavc/mjpegenc_common: Remove an unused variable.
[12:41:34 CET] <cone-770> ffmpeg 03Carl Eugen Hoyos 07master:74c576957ae1: lavf/movenc: Remove two unused variables.
[12:46:06 CET] <cone-770> ffmpeg 03Matt Wolenetz 07release/3.2:927e59b74acc: lavf/mov.c: Avoid OOB in mov_read_udta_string()
[12:46:07 CET] <cone-770> ffmpeg 03Matt Wolenetz 07release/3.2:d4b731e271ba: lavf/mov.c: Avoid heap allocation wraps in mov_read_{senc,saiz}()
[13:45:34 CET] <nevcairiel> wm4: how did you avoid the subtitle precision changes in the rescaling change?
[13:46:59 CET] <wm4> by moving down a line of code by 2 lines
[13:47:18 CET] <wm4> "ost->mux_timebase = ost->st->time_base;"
[13:47:26 CET] <nevcairiel> interesting
[13:47:50 CET] <wm4> so basically after initializing the encoder I think?
[13:47:59 CET] <wm4> I don't know why it works or why it wasn't done before
[14:05:13 CET] <BtbN> I'm pretty sure this series will break obscure usecases. But it's a well needed change.
[14:06:57 CET] <BtbN> Also, I'm tempted to CC the usual @nvidia.com people to that series, so they can maybe investigate at the driver level what is going on.
[14:16:48 CET] <BtbN> I also wasted way too much time trying to fix 10bit h264 decoding.
[14:17:05 CET] <BtbN> Well... it can only do that for hevc/vp9
[14:17:21 CET] <nevcairiel> the hardware just doesnt do that, what did you try to fix
[14:27:56 CET] <BtbN> Pixel format selection, I suspected some nv12 having creept in there somewhere still.
[14:28:02 CET] <BtbN> But turns out it all works fine
[14:35:53 CET] <BtbN> it also doesn't make sense that nvenc wants to be initialized before cuvid. The two don't interact in any way, as the frame is MemCopied to plain device memory.
[14:36:46 CET] <nevcairiel> i wouldnt think that this order is the important part, but that the device memory is also mapped at the point nvenc is initialized
[14:37:05 CET] <nevcairiel> can you just like skip the first frame, do future frames then work?
[14:37:21 CET] <cone-770> ffmpeg 03Carl Eugen Hoyos 07n3.2.4:HEAD: lavf/movenc: Remove two unused variables.
[14:37:35 CET] <BtbN> the memory nvenc gets is never mapped
[14:37:45 CET] <BtbN> it's just cuMemcpy2D'd to in cuvid
[14:38:06 CET] <nevcairiel> well its allocated before nvenc is created anyway
[14:38:12 CET] <nevcairiel> maybe it doesnt like that
[14:38:22 CET] <BtbN> cuvid allocates the output frame, maps the decoded frame, copies over, unmaps the frame, and then sends out the allocated one
[14:38:48 CET] <BtbN> so maybe I should just test making that error non-fatal?
[14:40:55 CET] <nevcairiel> wouldnt exactly be a solution, but maybe give some insight
[14:42:30 CET] <BtbN> nah, all the frames fail
[14:42:36 CET] <BtbN> the later ones with a NV_ENC_ERR_NO_ENCODE_DEVICE though
[15:10:15 CET] <J_Darnley> Hi all.  What instructions are availble to extract/move the high dqword from xmm into low dqword xmm?  I know punpckhqdq, or a shift.  Any suggestions?
[15:12:07 CET] <atomnuker> pshufb :)
[15:12:22 CET] <J_Darnley> Well, yeah.
[15:12:38 CET] <nevcairiel> probably more appropriate shuffles as well
[15:12:50 CET] Action: J_Darnley goes to check agner's docs on shift instructions
[15:15:59 CET] <BtbN> hm, found a small bug in nvenc.c while I was at it, but sadly no effect
[15:16:07 CET] <J_Darnley> ah dq shift does use p5
[15:26:18 CET] <J_Darnley> Isn't there some sort of "extract high packed single" instruction?
[15:27:12 CET] <Gramner> J_Darnley: punpckhqdq if it's avx or within the same register, pshufd if sse4 (due to it being slow on earlier cpus), otherwise movhlps
[15:27:35 CET] <Gramner> it's all p5 though
[15:28:05 CET] <J_Darnley> Thanks
[15:28:20 CET] <Gramner> basically https://git.videolan.org/?p=x264.git;a=blob;f=common/x86/x86util.asm;hb=90a61ec76424778c050524f682a33f115024be96#l293
[15:28:38 CET] Action: J_Darnley curses at his browser
[15:29:48 CET] Action: J_Darnley check's ffmpeg's file
[15:30:55 CET] <Gramner> doubt it's in there, but I wrote that macro in x264 and will agree to relicense it as LGPL if you want to steal it
[15:31:37 CET] <J_Darnley> Thanks, I will keep that in mind but I will get my code working first
[16:15:21 CET] <BBB> J_Darnley: do you mean movhlps?
[16:16:02 CET] <BBB> </late>
[16:16:32 CET] <J_Darnley> :)
[16:23:22 CET] <j-b> durandal_1707: another one? :D
[16:25:39 CET] <durandal_1707> j-b: do you want vlc to play atrac9 files?
[16:25:49 CET] <j-b> durandal_1707: sure
[16:25:53 CET] <j-b> durandal_1707: do you wnat money?
[16:26:30 CET] <durandal_1707> yes, who doesnt? :)
[16:26:48 CET] Action: j-b 
[16:27:07 CET] <durandal_1707> no way
[16:31:14 CET] <BBB> J_Darnley: movhlps moves the high half of a source xmm reg into the low half of the dest xmm reg; I believe it leaves the to half untouched. so if you have xmm1=abcdefghijklmnop in bytes low to high and do movhlps xmm2, xmm1, the bottom half of xmm2 will now be abcdefgh, which you seemed to be asking for
[16:32:07 CET] <J_Darnley> thank you
[16:32:10 CET] <BBB> J_Darnley: this is indeed similar to punpckhqdq, but its different in that it leaves the top half untouched
[16:32:23 CET] <BBB> if you want to move it to memory, use movhps
[16:34:36 CET] <Gramner> the fact that it leaves the top half unchanged also means it has a dependency on that register which can be an issue depending on the circumstances if you don't care about the top half. plus it's a float instruction so it has a bypass delay on some cpus when used on integer data
[16:38:46 CET] <atomnuker> bypass delay?
[16:39:25 CET] <Gramner> transitioning between int and float simd domains adds a 1-3 cycle latency on some cpus
[16:40:07 CET] <Gramner> which is why there are separate instructions for the same thing, e.g. movaps and movdqa
[16:40:33 CET] <wm4> huh that sounds pretty low
[16:40:40 CET] <wm4> did older CPUs have much higher delays?
[16:40:45 CET] <wm4> for float vs. int in general
[16:41:22 CET] <Gramner> there's also movapd which in hindsight was completely useless because there is no cpu in existence which has separete float and double domains
[16:42:29 CET] <Gramner> I don't remember exact numbers for individual cpus, I guess agner has them written down somewhere if you care enough to search
[16:43:30 CET] <Gramner> but basically just avoid using the "wrong" type of instruction unless there's a reason for doing so and you'll be fine
[16:54:34 CET] <user128> hi, ffmpeg currently does not support amr-wb+ codec (codec id is "sawp"). the source for encoder / decoder is available at https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1451. I wonder how hard it will be to add support for this codec to ffmpeg.
[16:59:11 CET] <JEEB> user128: make a feature request @ trac.ffmpeg.org
[17:00:10 CET] <user128> JEEB, thanks, will do it.
[17:05:32 CET] <cone-770> ffmpeg 03Paul B Mahol 07master:ba632efa93ef: avcodec/qdmc: silence gcc 6.2.0 warning
[18:38:04 CET] <kierank> wm4: did we ever find out who apart from michaelni is on ffmpeg-security
[18:38:13 CET] <wm4> not me
[18:38:16 CET] <kierank> I'd laugh if it is old mplayer people
[18:38:19 CET] <wm4> also, I'm still not on that ML
[18:38:28 CET] <Shiz> me
[18:38:30 CET] <Shiz> it is me
[18:38:31 CET] <wm4> (or whatever it is)
[18:38:52 CET] <kierank> As far as I can tell it is an alias to michaelni at gmx
[18:40:25 CET] <Shiz> lol
[18:40:55 CET] <jamrial> j-b: https://git.videolan.org/?p=vlc.git;a=blob;f=src/input/demux.c;h=58234724bcac45d987c1ccbdf51790951a97bd5e;hb=HEAD#l591 is wrong
[18:41:08 CET] <jamrial> a value of 1 for that flag means there is no footer
[18:41:31 CET] <j-b> jamrial: I'm not sure I understand
[18:41:44 CET] <jamrial> http://wiki.hydrogenaud.io/index.php?title=Ape_Tags_Flags
[18:42:29 CET] <jamrial> that code is checking for that flag to skip 32 extra bytes, accounting for the presence of an APE tag footer
[18:42:29 CET] <j-b> jamrial: https://git.videolan.org/?p=vlc.git;a=commit;h=4423fed572febf03aeee8152071dc4af8e530174 is incorrect, then?
[18:42:31 CET] <jamrial> but it's checking it wrong
[18:42:33 CET] <nevcairiel> sounds to me like he says the interpretation is the wrong way around
[18:43:25 CET] <jamrial> 1 means no footer, so no need to skip those extra 32 bytes. 0 is what means there's a footer
[18:44:07 CET] <j-b> jamrial: thx, I will check
[18:44:09 CET] <jamrial> j-b: only the flags&(1<<30) part i guess. the int -> uint is ok
[18:44:19 CET] <j-b> jamrial: thx.
[18:44:40 CET] <jamrial> no prob. just found a similar problem in ffmpeg, so i'm about to send some patches
[18:44:53 CET] <jamrial> we have been creating ape tags with wrong flags the whole time :p
[18:45:12 CET] <jamrial> the apev2 spec is weird because it tries to be compatible with apev1
[18:45:19 CET] <j-b> i_size = GetDWLE( &p_peek[8+4] ) + ( (flags&(1<<30)) ? 32 : 0 )
[18:45:24 CET] <j-b> is what we used to have
[18:46:36 CET] <j-b> jamrial: so it should be inverted?
[18:46:38 CET] <jamrial> that's the same as the current code. (flags&(1<<30) ? 32 : 0) adds 32 bytes if the flag evaluates to 1, when it should only if it evaluates to 0
[18:46:46 CET] <jamrial> yeah
[18:46:53 CET] <j-b> what a stupid spec
[18:47:22 CET] <nevcairiel> doesnt seem too bad, the default case is having a footer, and later a flag was added to skip it in some cases
[18:47:24 CET] <jamrial> it is. for header presence flag, 1 means present, 0 absent. for footer, 1 absent, 0 present
[18:47:39 CET] <jamrial> yeah, the flags field was a zeroed reserved field in apev1
[18:47:59 CET] <j-b> jamrial: ok
[18:48:02 CET] <jamrial> so to remain compatible, apev2 needs to have a zeroed flag field means the same structure as apev1
[18:48:26 CET] <jamrial> that means footer is present but header is not
[18:54:41 CET] <atana> michaelni: the paper says '[1]. A time-frequency point is a candidate peak if it has a higher energy content than all its neighbors in a region centered around the point.' so you mean this region is context window of 64 (-+64) not the bins itself?
[19:10:35 CET] <Chloe> kierank: who runs the mail?
[19:10:53 CET] <Chloe> is it only michaelni who runs the mail*
[19:20:11 CET] <michaelni> atana, yes, for example a point at lets say [90] should be the max in 90-64..90+64 not just 64..128
[19:24:34 CET] <atana> michaelni: if bins are 0-64, 64-128, 128-192 , 192-256, 256-320, 320-384, ... then max point from 2 bin[say 90] should be tested against max point not in 1st and 3rd bin, but in 90-64 and 90 + 64 as they are in +-64  window i.e. neighbors?
[19:25:02 CET] <michaelni> yes
[19:26:50 CET] <michaelni> atana, btw its great you are on IRC, i belive this is more efficient to move the project forward!
[19:27:14 CET] <atana> so similarly find all such valid points in one fft range? and these are constellation points
[19:28:50 CET] <atomnuker> is that for ffv1?
[19:29:14 CET] <michaelni> atana, yes, i would suggest to use that, its simpler and given time remaining is limited ...
[19:29:27 CET] <atana> If this is the case then cpt size is not pre-defined as some points could be invalid
[19:29:36 CET] <michaelni> atomnuker, peakpoints filter
[19:29:59 CET] <michaelni> atana, yes
[19:30:09 CET] <atomnuker> ah, outreachy
[19:31:45 CET] <atana> I see. I will make the changes then.
[19:32:24 CET] <michaelni> ok, dont hesitate to ping me if you have any question or doubt or anything
[19:33:02 CET] <atana> when size of cpt is not pre-defined so should I make a linked list?
[19:33:16 CET] <atana> *make it a ..
[19:33:47 CET] <jamrial> j-b: actually, https://git.videolan.org/?p=vlc.git;a=blob;f=src/input/demux.c;h=58234724bcac45d987c1ccbdf51790951a97bd5e;hb=HEAD#l585 is wrong as well, it's reading the item count field as if it were the flags field
[19:34:06 CET] <j-b> jamrial: actually everything is wrong in that function
[19:34:16 CET] <michaelni> atana, id suggest just mark the invalid entries with -1
[19:34:27 CET] <jamrial> it's also not accounting for header size, yes :p
[19:34:38 CET] <atana> michaelni: ok
[19:34:42 CET] <jamrial> the spec is a tad too vague admitedly
[19:35:12 CET] <michaelni> atana, if the -1 cause any complexity you could just do a pass over the cpt array and remove them, should be easier than changig the data structure and also faster
[20:10:25 CET] <BBB> michaelni: anyone on ffmpeg-security should be a maintainer. interest is not a good reason to be on there. but this will get political very quickly so good luck on getting that to be practical
[20:10:55 CET] <BBB> michaelni: more practically, yes wm4 and kierank should be on it (in fact, anyone with access to the static analysis should be on ff-sec also IMO)
[20:11:24 CET] <kierank> I don't even care whether I am on it any more
[20:11:36 CET] <kierank> I care that it is not transparent who is on it
[20:11:40 CET] <jamrial> BBB: maintainers here refers to people with a line in the "MAINTAINERS" file. IMO, that shouldn't be a requirement
[20:12:00 CET] <jamrial> it should be active, trust worthy and ideally long standing contributors
[20:12:08 CET] <BBB> thats fine also
[20:12:12 CET] <jamrial> neither wm4 or kierank are "maintainers", for example
[20:12:29 CET] <BBB> maybe theyre not in MAINTAINERS
[20:12:35 CET] <BBB> however, they are project maintainers to me
[20:13:05 CET] <michaelni> if the MAINTAINERS file is inaccurate it should be corrected
[20:14:30 CET] <jamrial> it's not
[20:14:33 CET] <jamrial> ok, it sorta is, but that's not the point
[20:14:50 CET] <durandal_1707> im maintainer of everything i touch
[20:15:01 CET] <kierank> michaelni: please grow up and tell us who is on the list
[20:15:09 CET] <BBB> durandal_1707: I second that
[20:15:22 CET] <jamrial> the point is, people that fit the above criteria don't necessarely have a line in that file as they don't maintain any specific module
[20:15:56 CET] <BBB> people who are actively contributing to a module may be maintaining it in practice without having an official title
[20:16:01 CET] <jamrial> true
[20:16:02 CET] <BBB> who maintainers h264?
[20:16:08 CET] <BBB> maintains*
[20:16:12 CET] <durandal_1707> i request full powers and immunity from prosecutions
[20:16:26 CET] <BBB> Ive done tons of work on it& but I dont have a title I think
[20:16:38 CET] <BBB> the only reason Im maintainer for ffvp8/9 is because I touched it first
[20:16:39 CET] <kierank> I am the supreme grand Knight commander
[20:16:48 CET] <BBB> I beleive yuvi is maintainer of vp8, but hes really not :)
[20:17:14 CET] <jamrial> that's where the "innacurate" part of the file comes into play :p
[20:17:15 CET] <BBB> anyway
[20:17:26 CET] <BBB> I agree it makes sense for it to be public whos on ff-sec
[20:17:40 CET] <BBB> getting new people on ff-sec shouldnt be so political
[20:18:40 CET] <michaelni> if the maintainer list is inaccurate and isnt fixed and people want the nowhere written maintainer list to be used as criteria that may lead to disagreements and confusion
[20:19:10 CET] <Chloe> I think not being transparent on ff-sec leads to more disagreements and confusion
[20:19:51 CET] <durandal_1707> i am the supreme grand Knight field marshal
[20:21:15 CET] <michaelni> Chloe, is it really not transparent or did just noone ask before ?
[20:22:17 CET] <Chloe> Transparent implies that we shouldn't have to ask to know--and does it really matter? As long as it's made transparent now, there shouldn't any further issues.
[20:22:23 CET] <kierank> durandal_1707: ok you outrank me
[20:23:24 CET] <durandal_1707> lol
[20:24:35 CET] Action: kierank bows down to durandal_1707
[20:29:27 CET] <kierank> michaelni: because nobody asked that made it ok?
[20:29:46 CET] <kierank> Nobody asked about who had commit access either
[20:30:06 CET] <kierank> Nobody queried all the random people being given git push
[20:30:10 CET] <kierank> It's a terrible argument
[20:32:38 CET] <kierank> Anyway I am bored of FFmpeg childishness, holidays time
[20:33:08 CET] <nevcairiel> sounds to me like you are being childish right now
[20:33:08 CET] <michaelni> kierank, how should i know what people want to know if they dont ask?
[20:34:30 CET] <Chloe> michaelni: this is a silly argument. You now know what people want, why cant this be done?
[20:35:07 CET] <michaelni> Chloe, why cant what be done ?
[20:35:33 CET] <jamrial> i still don't get why this subject blew up like this
[20:36:06 CET] <michaelni> iam also puzzled about this a bit
[20:38:11 CET] <Chloe> michaelni: it can be done? you haven't made any indication that it can be done. (and if you have, and I've missed it: 1) sorry for missing that 2) why hasn't it been done yet? adding another email to a list of aliases cant take more than 5 minutes. In-fact this whole conversation has probably taken longer than it would have taken to add people's emails)
[20:38:15 CET] <nevcairiel> because some people that call everyoen else childish were rather childish =p
[20:38:43 CET] <jamrial> Chloe: what michaelni said is that (supposedly) nobody asked for who's in the alias at first. this afaik started with people wanting to get in
[20:38:49 CET] <nevcairiel> Chloe: people dont say what the f' they want, they just complain that everything is terrible
[20:39:07 CET] <jamrial> now, should the list of people in the alias made public? I'd say yes
[20:39:39 CET] <jamrial> but the core of the issue here is who should get in the alias
[20:40:33 CET] <Chloe> nevcairiel: wm4 made it clear he wanted to be added, I dont think wm4 complained either (about this).
[20:41:22 CET] <jamrial> yes, he did. that's why the discussion regarding who should get in started
[20:49:40 CET] <J_Darnley> Damn.  This code is ugly but it at least it works.
[20:49:41 CET] <durandal_1707> michaelni: just add them to list, they not gonnaa share exploits
[20:51:09 CET] <durandal_1707> J_Darnley: what code?
[20:51:09 CET] <rcombs> I also think it's probably good for the lists of who gets -sec emails and who has push access to be available, but it doesn't seem like anyone's done anything worth shouting about
[20:51:23 CET] <J_Darnley> Another h264 loop filter function
[20:51:31 CET] <rcombs> I'd also like to be on -sec though
[20:53:10 CET] <jamrial> rcombs: commit push wise there were some questionable things, but nothing damaging
[21:08:27 CET] <durandal_1707> i gonna push atrac advanced lossless decoders
[21:09:10 CET] <Chloe> Still trying to fix transcoding DVB TT to DVB sub, I've fixed the issue with the colours by forcing the rasteriser to only output 8 (added it as an option). But the timestamps seem to be extremely broken, it only seems to occur when writing the packet out though. It hits the "Application provided invalid, non monotonically increasing dts" because of (what I
[21:09:10 CET] <Chloe> think is only) out of order packets being sent. I can think of two solutions to this (though I'm not entirely sure how to do either): 1) dont send the second empty packet somehow (not sure the impact this will have on other stuff) 2) somehow fix the timestamps.
[21:10:08 CET] <JEEB> the empty teletext stuff generally is pushed out to post an "end time" for the subtitle 
[21:10:22 CET] <JEEB> but why does it end up having a timestamp that's smaller than the previous packet's?
[21:10:59 CET] <atomnuker> durandal_1707: it only decodes the lossy part of the lossless format, right?
[21:12:05 CET] <durandal_1707> yes
[21:12:52 CET] <Chloe> -fix_sub_duration seems to fix it mostly but it's still kinda off
[21:13:32 CET] <atomnuker> durandal_1707: I think there should be a warning, like "Only decoding lossy part of ATRAC3+"
[21:13:36 CET] <atomnuker> on init
[21:14:42 CET] <atomnuker> or better "Only decoding lossy part of ATRAC3+, fully lossless decoding not supported yet"
[21:34:16 CET] <jamrial> not really. for the longest time our dca decoder would decode the lossy code of dts-hd streams
[21:34:21 CET] <jamrial> and without any warning
[21:35:48 CET] <RiCON> the only hint that it wasn't lossless is that the lossy part had only 6 channels
[21:36:52 CET] <jamrial> and that it decoded as flt
[21:44:04 CET] <jamrial> s/code/core
[22:36:02 CET] <cone-265> ffmpeg 03James Almer 07master:e8d6fef3161f: avformat/apetag: fix flag value to signal footer presence
[22:36:02 CET] <cone-265> ffmpeg 03James Almer 07master:84d874a680ff: avformat/apetag: account for header size if present when returning the start position
[22:36:02 CET] <cone-265> ffmpeg 03James Almer 07master:33ab1d4c6f6a: avformat/apetag: reorder some code to improve readability
[22:45:41 CET] <pfanous> avpriv_exif_decode_ifd for H.264 decoding?
[22:46:22 CET] <pfanous> exit
[22:46:23 CET] <pfanous> qui
[22:46:25 CET] <pfanous> quit
[23:02:45 CET] <michaelni> atana, you need 2 passes over the data to find the local maxima efficiently, first find the maxima of each 64 entry bin as before then in a 2nd loop after "for (freq = 0; freq < p->windowSize; freq++) {...}" check each and discard what isnt a local maxima
[23:03:19 CET] <michaelni> if you mix the 2 loops then you could check 1024 cases against 128 in worst case, thats slow
[23:03:51 CET] <michaelni> if you do it in 2 passes then the first loop checks 1024 cases and the 2nd checks 16*128
[23:03:58 CET] <michaelni> thats fewer checks
[23:12:43 CET] <BtbN> hm, I don't get what nvenc is unhappy about.
[23:13:00 CET] <BtbN> Absolutely everything seems as it should
[23:13:32 CET] <BtbN> There is only one shared cuda context between all. The same frames (cudevptr wise) are passed around, dimensions match, everything
[23:24:38 CET] <wm4> would it be less of a mess to try implementing the hw_device_ctx API?
[23:30:38 CET] <BtbN> There is no real mess, that's the thing.
[23:30:45 CET] <BtbN> In fact, there is now less mess than before.
[23:32:04 CET] <BtbN> I'm starting to think this is unrelated to the hwaccel stuff
[23:32:10 CET] <BtbN> But some other parameter that changed
[23:35:16 CET] <iive> BtbN: what's the problem. aka how do you know nvenc is unhappy?
[23:35:33 CET] <BtbN> well, EncodePicture returns error 10, out of memory.
[23:35:45 CET] <BtbN> Which just makes no freaking sense.
[23:35:53 CET] <BtbN> It's not a function that allocates memory.
[23:36:57 CET] <BtbN> And it only happens with that ffmpeg.c series applied. And only if direct cuvid->nvenc or cuvid->npp->nvenc transcoding.
[23:37:07 CET] <BtbN> cuvid->hwdownload->nvenc is fine
[23:39:43 CET] <iive> what does the ffmpeg.c series change/touch?
[23:39:58 CET] <BtbN> well, everything?
[23:40:13 CET] <BtbN> It changes the initialization order of things to something that's actually sane
[23:40:17 CET] <nevcairiel> mostly just the order of the init
[23:41:07 CET] <BtbN> basically makes things wait for the previous chain element to output a frame?
[23:41:35 CET] <nevcairiel> yeah, it inits the following components if all information is actually known
[23:41:45 CET] <nevcairiel> instead of going by the guessed values and falling over if those are wrong
[23:42:55 CET] <iive> initializations that are done in the nvidia driver?
[23:43:08 CET] <BtbN> and from as far as I see, it succeeds at doing that.
[23:43:12 CET] <BtbN> Everything looks in order
[23:43:19 CET] <BtbN> Except for nvenc failing.
[23:46:37 CET] <BtbN> if it's actually just initializing nvenc after cuvid that causes this...
[23:46:45 CET] <iive> maybe the init order is insane, because it is the only one working?
[23:46:52 CET] <iive> well, test it.
[23:47:01 CET] <BtbN> how would I test it?
[23:47:04 CET] <nevcairiel> no, its insane because it was easier this way =p
[23:47:51 CET] <nevcairiel> initing the output before the input is fully initialized is just silly, you couldnt know the full and final output infos yet
[23:47:53 CET] <BtbN> Can only revert the series, to find it working again.
[23:48:00 CET] <iive> BtbN: reorder them? hardcode some guessing values if you have to.
[23:48:16 CET] <BtbN> you don't just reorder them
[23:48:54 CET] <iive> well, how was it done before?
[23:49:13 CET] <BtbN> ffmpeg.c initialized the encoder first... for some weird reason
[23:49:31 CET] <BtbN> Causing a lot of hacks to guess format values
[23:49:46 CET] <nevcairiel> which made no sense, since it had to guess a l ot of values instead of using the actual values it would know later
[23:50:45 CET] <BtbN> I'm not yet ready to blame a weird driver bug though. Right now I suspect some other input parameter that changed but I didn't check yet.
[23:51:11 CET] <iive> are encoder and decoder using different ... methods? aka encoding using dedicated dsp, while decoding using cuda?
[23:51:15 CET] <nevcairiel> we have some hexdump functions you could use to just dumb whatever structs and diff for changes
[23:51:25 CET] <nevcairiel> dump*
[23:51:44 CET] <iive> BtbN: have you tried distclean and rebuild from scratch?
[23:51:58 CET] <BtbN> I only do clean builds.
[23:52:09 CET] <BtbN> This happens reliably on two machines.
[23:52:13 CET] <iive> no ccache.
[23:52:28 CET] <BtbN> One being Windows using MSVC2015, and one on Linux
[23:54:38 CET] <philipl> BtbN: so there's no practical way to hack in reversed initialisation to test this?
[23:54:40 CET] <iive> BtbN: is it possible to run a multiple instances of nvenc?
[23:54:43 CET] <philipl> just to prove it?
[23:54:56 CET] <BtbN> philipl, it doesn't seem so, no.
[23:55:03 CET] <BtbN> iive, 2
[23:55:07 CET] <nevcairiel> philipl: not really, its like the base architecture
[23:55:11 CET] <BtbN> soft-limit enforced by the driver
[23:55:28 CET] <nevcairiel> logging would show if its loaded multiple times
[23:55:45 CET] <iive> BtbN: what error do you get when you hit the limit?
[23:56:23 CET] <BtbN> it fails to open the session
[23:56:49 CET] <BtbN> If the input dimensions were bad it would fail while mapping/allocating the frames.
[23:56:52 CET] <BtbN> Which also doesn't happen
[23:57:20 CET] <BtbN> The EncodePicture function does not allocate any external buffers. It gets the input buffer, and it also gets the output buffer as parameters.
[23:57:24 CET] <BtbN> Both are pre-allocated.
[23:57:25 CET] <iive> yeh, i was thinking if it tries to use the same dsp for decoding, thus using one instance.
[23:57:39 CET] <nevcairiel> no, decoding is separate entirely
[23:58:08 CET] <nevcairiel> and even then, before the patch it worked, and decoding and encoding still run parallel then
[23:59:02 CET] <JEEB> wbs: how does this look to you? (yes, I'm still poking at the funky world of MS-SSTR) https://github.com/jeeb/ffmpeg/commit/167e0ed04a668bd070aa5839ec17d04a926ce24a
[00:00:00 CET] --- Sat Feb 11 2017