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

[burek]

[03:12:46 CEST] <rcombs> does anyone have up-to-date listening test results of AppleAAC vs ffAAC?
[03:26:37 CEST] <Compn> rcombs : did apple change their encoder ?
[03:27:01 CEST] <Compn> or you mean a new test after atomnuker's changes
[03:27:09 CEST] <Compn> hmm i am not sure if double blinds have been done after that
[03:27:17 CEST] <Compn> does hydrogenaudio handle those?
[03:27:53 CEST] <Compn> http://wiki.hydrogenaud.io/index.php?title=Hydrogenaudio_Listening_Tests#AAC_Tests
[03:28:00 CEST] <Compn> doesnt look like they've done any tests in a while
[03:28:06 CEST] <Compn> you may want to ask them to do an updated one
[03:29:03 CEST] <Compn> https://hydrogenaud.io/index.php/topic,111085.0.html
[03:29:10 CEST] <Compn> oh they are more active on the forum than the wiki
[03:29:14 CEST] <Compn> maybe atomnuker knows too
[03:32:14 CEST] <Compn> that thread is just one guys' audio tests on his own files
[03:32:30 CEST] <Compn> vs fdk aac
[03:35:17 CEST] <JEEB> kamedo was the guy who also posted tests on the trac
[03:36:09 CEST] <JEEB> while the patch set was still in development. but that's just fdk-aac and ffaac. and fdk-aac can't be distributed as binary
[03:38:19 CEST] <rcombs> Compn: yeah I meant after atomnuker's changes
[03:38:35 CEST] <rcombs> the only stuff I've seen is from partway through development
[03:39:22 CEST] <rcombs> also, has anyone ever compared with Microsoft's encoder?
[04:06:55 CEST] <cone-541> ffmpeg 03Michael Niedermayer 07master:cfd1ecdc0bb0: avcodec/asvdec: Check buf_size
[04:06:55 CEST] <cone-541> ffmpeg 03Michael Niedermayer 07master:2002436b0c91: avcodec/xsubdec: Check that RLE coded image and colors fit in the buffer
[04:06:55 CEST] <cone-541> ffmpeg 03Michael Niedermayer 07master:9726e9f80934: avcodec/ffv1dec_template: Fix runtime error: signed integer overflow: 202 + 2147483615 cannot be represented in type 'int'
[04:06:55 CEST] <cone-541> ffmpeg 03Michael Niedermayer 07master:504d5804ac53: avcodec/g723_1: Fix runtime error: signed integer overflow: -1013481472 + -1139123755 cannot be represented in type 'int'
[04:40:28 CEST] Action: Compn just hopes aac goes away one day
[04:40:35 CEST] <Compn> like ogg and ra
[07:44:37 CEST] <thebombzen> fdk-aac isn't nonfree, right?
[07:44:44 CEST] <thebombzen> I thought its license was just GPL-incompatible
[07:58:23 CEST] <rcombs> depends if you define "nonfree" as "GPL-incompatible" or not
[09:20:55 CEST] <thebombzen> well I mean you can distribute binaries of fdk-aac
[09:21:01 CEST] <thebombzen> just not ffmpeg binaries linked to it
[09:21:22 CEST] <thebombzen> which makes it basically the same if you want to use ffmpeg, but slightly different in the US where laws are weird and bad
[09:41:25 CEST] <thebombzen> Also, a bit overdue, but I made the SSH crash ticket. I listed is as "normal priority" because I'm unsure what the standards are for higher or lower priority
[09:43:29 CEST] <thebombzen> are they published anywhere or do they play it by ear
[10:14:05 CEST] <ubitux> so i got no answer for the dashenc thing
[10:14:18 CEST] <ubitux> who maintains our dash stack?
[10:15:33 CEST] <JEEB> wbs I think created it originally
[10:17:03 CEST] <BtbN> Is there a hw pixel format that's an OpenGL texture?
[10:17:30 CEST] <wm4> BtbN: no
[11:12:12 CEST] <BtbN> What happened to the libav effort to make cuvid a classic hwaccel?
[11:12:25 CEST] <nevcairiel> it still exists somewhere
[11:12:56 CEST] <BtbN> Cause I'm thinking about doing that myself otherwise
[11:15:18 CEST] <nevcairiel> its mostly done just has a few open questions
[11:15:28 CEST] <nevcairiel> like, how to properly implement the delay so its not crawling slow
[11:15:49 CEST] <wm4> BtbN: you should probably get in touch with elenril
[11:48:00 CEST] <cone-588> ffmpeg 03Timo Rothenpieler 07master:a1652aca7e89: avcodec/nvenc: remove unnecessary alignment
[11:58:46 CEST] <cone-588> ffmpeg 03Timo Rothenpieler 07release/3.3:3bc5e427e4da: avcodec/nvenc: remove unnecessary alignment
[11:58:53 CEST] <wm4> do transport streams really not store a framerate?
[12:00:25 CEST] <nevcairiel> of course not, they store no metadata
[12:00:34 CEST] <nevcairiel> the codec might, of course
[12:00:56 CEST] <cone-588> ffmpeg 03Timo Rothenpieler 07release/3.2:1f76235dd450: avcodec/nvenc: remove unnecessary alignment
[12:01:22 CEST] <wm4> trying to make utils.c detect the framerate of a .ts file correctly (mediainfo gets it right, of course)
[12:01:59 CEST] <nevcairiel> there is the timestamp-based heuristic which often works ok-ish, but of course TS and its 90kHz timestamps distort that as well to some degree
[12:04:40 CEST] <cone-588> ffmpeg 03Max Justicz 07master:3766aa7343c4: avcodec/fmvc: Fix use of uninitialized memory when the first frame is not a keyframe
[12:04:54 CEST] <cone-588> ffmpeg 03Timo Rothenpieler 07release/3.1:8c021166d194: avcodec/nvenc: remove unnecessary alignment
[12:06:01 CEST] <wm4> who pushed 3766aa7343c4?
[12:06:04 CEST] <wm4> it was not on the ML
[12:06:44 CEST] <nevcairiel> git stores the commiter in the commit info
[12:07:29 CEST] <wm4> something similar was reported to ffmpeg-security, but no patch
[12:07:40 CEST] <wm4> so much for "patches should be submitted to the mailing list"
[12:07:52 CEST] Action: wm4 adds another entry to his list of ffmpeg development bullshit
[12:13:49 CEST] <durandal_1707> wm4: ffmpeg development is da best
[12:19:01 CEST] <atomnuker> trivial commits like that don't need to go through the ml
[12:19:56 CEST] <atomnuker> I too have been sent random one-line patches before
[12:49:21 CEST] <kierank> wm4: only reliable way is from the codec
[12:49:50 CEST] <wm4> is that generally signaled in stuff muxed into ts?
[12:50:06 CEST] <kierank> in the main yes
[12:52:59 CEST] <kierank> I've seen evil ateme files set the time_scale (note not framerate) to 1/27000000
[12:53:04 CEST] <kierank> but that was many years ago
[12:53:32 CEST] <wm4> well this has to work with the cesspool that is fate+av_find_streaminfdo
[13:20:41 CEST] <wm4> I can't comprehend this - so it checks against a list of "standard framerates", and considers 24.5 fps "better" than 25 fps?
[13:22:06 CEST] <wm4> ah no, I made some mistake here
[13:28:46 CEST] <cone-588> ffmpeg 03Matthieu Bouron 07master:224bb46fb857: lavc/mediacodec_wrapper: fix local reference leaks
[13:28:46 CEST] <cone-588> ffmpeg 03Matthieu Bouron 07master:fb3228bee8fe: lavc/mediacodec_wrapper: do not declare JNIAMedia{Codec,CodecList,Format}Fields on the stack
[13:28:48 CEST] <cone-588> ffmpeg 03Matthieu Bouron 07master:37de7f71758b: lavc/ffjni: add missing '\n'
[13:34:33 CEST] <ubitux> git.videolan.org down?
[13:35:03 CEST] <mateo`> did I just break it ?
[13:35:41 CEST] <wm4> fate passes on this pig
[13:51:26 CEST] <cone-588> ffmpeg 03Matthieu Bouron 07release/3.3:2fb25e2dd6ff: lavc/mediacodec_wrapper: fix local reference leaks
[13:51:27 CEST] <cone-588> ffmpeg 03Matthieu Bouron 07release/3.3:cbae648eb8b2: lavc/mediacodec_wrapper: do not declare JNIAMedia{Codec,CodecList,Format}Fields on the stack
[13:51:28 CEST] <cone-588> ffmpeg 03Matthieu Bouron 07release/3.3:3e38bf95c537: lavc/ffjni: add missing '\n'
[13:54:35 CEST] <cone-588> ffmpeg 03Matthieu Bouron 07release/3.3:6ee4b20f4ae3: lavf/mov: make invalid m{d,v}hd time_scale default to 1 instead of erroring out
[15:43:34 CEST] <BBB> J_Darnley: happy to assist with idct if you need help :)
[15:44:11 CEST] <J_Darnley> Can you help right now?
[16:06:42 CEST] <J_Darnley> Well, maybe later.  See ya'll later
[16:25:40 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:620b452a118a: avcodec/aacdec_fixed: Fix multiple runtime error: shift exponent 127 is too large for 32-bit type 'int'
[16:25:41 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:948b54763b6c: avcodec/lagarith: Fix runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
[16:25:42 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:fb75ad79cb8a: avcodec/celp_filters: Fix runtime error: signed integer overflow: 1892453989 + 381702783 cannot be represented in type 'int'
[17:04:12 CEST] <BBB> J_Darnley: Im here, sorry
[17:04:13 CEST] <BBB> ask
[17:13:51 CEST] <BBB> J_Darnley: also feel free to email to the list and I can respond there
[17:30:15 CEST] <ubitux> in the ps aac function, is it ok to assume n > 4 all the time?
[17:30:47 CEST] <ubitux> it seems currently optimized ASM functions do assume that
[17:31:27 CEST] <ubitux> (note: i'm writing some aarch64 code for this stuff and i'm wondering of the assumptions i can make)
[17:35:06 CEST] <KGB> [13FFV1] 15dericed opened pull request #66: Definitions (06master...06definitions) 02https://git.io/vHt47
[17:35:06 CEST] <jamrial> ubitux: afaik, only ps_stereo_interpolate needs to check n
[17:36:55 CEST] <ubitux>  ok
[17:36:58 CEST] <jamrial> stereo_interpolate, rather
[17:40:35 CEST] <jamrial> btw, if you find a sample that sets ps->enable_ipdopd, send it my way
[17:47:01 CEST] <ubitux> yeah i saw that it's optimized nowhere
[17:51:26 CEST] <michaelni> wm4, the change 3766aa7343c4 was on ffmpeg-security in the form of english text posted by its author
[19:31:39 CEST] <peloverde> jamrial: al_sbr_ps_04_new.mp4
[19:36:13 CEST] <jamrial> peloverde: cool, thanks!
[19:37:45 CEST] <jamrial> ubitux: ^ in case you're interested
[19:38:46 CEST] <peloverde> available at ftp://mpaudconf:adif2mp4@ftp.iis.fhg.de/mpeg4audio-conformance/compressedMp4/
[19:43:24 CEST] <BBB> I think I finally fixed my disconnect problem
[19:43:40 CEST] <BBB> as in, I believe my computer no longer disconnects from IRC after a few minutes of inactivity
[19:43:51 CEST] <BBB> \o/
[19:44:17 CEST] <BtbN> You added support for PING/PONG to your client?
[19:45:48 CEST] <BBB> BtbN: no, a mac update added a new power savings feature to put my HD to sleep when the display goes to sleep (I specifically have it set up to not put network to sleep)
[19:45:54 CEST] <BBB> and that disconnects the client, apparently
[19:46:25 CEST] <BtbN> sounds more like it puts the whole machine into suspend?
[19:46:35 CEST] <BBB> probably
[19:46:43 CEST] <BBB> I dont know how to translate apple marketing speak into reality
[19:46:49 CEST] <BBB> theres no literal dictionary for that conversion
[19:47:09 CEST] <BtbN> just need some bouncer somewhere, so your client can freely disconnect
[19:47:20 CEST] <BBB> I used to have one, but it got donged
[19:47:30 CEST] <BBB> and too lazy to set up a new one
[20:06:41 CEST] <jamrial> heh, love when you write an entire asm function and it works the first time you try it
[20:07:22 CEST] <nevcairiel> i think thats always suspicious
[20:07:53 CEST] <jamrial> yes, which is why i added a bullshit instruction so it would crash :p
[20:08:01 CEST] <jamrial> to confirm it was actually running the code
[20:09:25 CEST] <jamrial> anyway, 2x speed up for stereo_interpolate_ipdopd with sse3
[20:10:01 CEST] <jamrial> anyone wanting to play that sample will love the saved cycles, because i don't know if there's any other aac file out there that will
[20:10:58 CEST] <wm4> adding an instruction that outputs corrupted data is better than making it crash
[20:11:09 CEST] <wm4> because a crash means it's run, not necessarily that the result is used
[20:11:25 CEST] <nevcairiel> well for dsp functions it kinda is
[20:20:12 CEST] <ubitux> jamrial: thx, stolen :)
[21:03:08 CEST] <pfelt> afternoon all.  i'm looking at cleaning up some warnings in declink_dec and am having issues with av_dup_packet() and changing to av_packet_ref().  i'm positive that i'm not understanding the code, but i'm not finding any good help via google on understanding how this new call is supposed to work.
[21:03:27 CEST] <pfelt> what's the best way to come up to speed on this referencing model?
[21:40:46 CEST] <BBB> pfelt: whats the specific issue youre having?
[21:41:38 CEST] <BBB> pfelt: its possible that declink actually requires you to copy the data to an external buffer and that using ref (which doesnt copy) would therefore change behaviour/
[21:41:39 CEST] <BBB> ?
[21:50:08 CEST] <pfelt> bbb: decklink input (decklink_dec.cpp) pulls frames off the card for ingestion into ffmpeg.  i'm converting the call to av_dup_packet() to av_packet_ref() per documentation.  i was segfaulting in static int avpacket_queue_put(AVPacketQueue *q, AVPacket *pkt) , but i think i figured the right syntax out. 
[21:50:57 CEST] <pfelt> i find it a bit difficult to understand the code here to ensure that i'm soing the right thing, but it is running now without segfaulting.  only question is, am i leaking memory now since i didn't add an unref() anywhere
[21:51:36 CEST] <pfelt> overall the patch is pretty small
[21:54:43 CEST] <BBB> if you can run it for an hour and memory usage is table
[21:54:46 CEST] <BBB> youre probably fine
[21:54:47 CEST] <BBB> ;)
[21:54:54 CEST] <pfelt> hehe
[21:55:09 CEST] <pfelt> yeah.  i've got a stream pulling from one DL card and outputting on another
[21:55:55 CEST] <pfelt> with av_dup_packet() who was supposed to do a free on the packet?
[21:56:13 CEST] <pfelt> or i guess, what funcitons could be used to free a packet that has been "duped"
[22:00:04 CEST] <BBB> I think the input device is supposed to return a reference
[22:00:09 CEST] <BBB> and then whatever called will unref
[22:00:14 CEST] <BBB> so if you return a reference thats fine
[22:00:32 CEST] <BBB> so av_read_frame()s caller (e.g. ffmpeg.c, or a custom application using lavf) will do the unref
[22:01:25 CEST] <pfelt> ok.  then i *might* be good with this patch
[22:02:07 CEST] <pfelt> how did dup work before?  it seems like it took a single arg of the packet and returned an int
[22:14:13 CEST] <BBB> pfelt: I believe it simply re-allocated the packet in-place
[22:14:19 CEST] <BBB> not 100% sure though
[22:14:26 CEST] <BBB> maybe realloc if n_refs > 1?
[22:56:50 CEST] <atomnuker> nice to see some simd where you can be sure there will be mod 4 vector sizes
[22:57:23 CEST] <atomnuker> me and iive have been getting many gray hairs and slower-than-c simd because its a pain to handle otherwise
[22:59:31 CEST] <rcombs> who should I bother for listening tests? Kamedo?
[23:01:36 CEST] <atomnuker> yes
[23:02:02 CEST] <rcombs> is he usually on IRC? (under that nick?)
[23:02:56 CEST] <atomnuker> nope, just ask him on twitter or hydrogenaudio
[23:05:32 CEST] <rcombs> @kamedo2?
[23:13:50 CEST] <nevcairiel> what are you improving that needs tests?
[23:15:36 CEST] <atomnuker> rcombs: yes
[23:16:15 CEST] <rcombs> nevcairiel: afaik there haven't been tests since atomnuker's AAC improvements were completed, and I'm not aware of any tests comparing the Windows AAC encoder against anything else
[23:16:44 CEST] <nevcairiel> the last tests were in january 2016, since then not that much changed anymore
[23:17:37 CEST] <atomnuker> nope, not much has since then
[23:18:03 CEST] <rcombs> are they not linked in that thread?
[23:19:27 CEST] <rcombs> last comments I saw in there mentioned that the tests linked were on an out-of-date patch
[00:00:00 CEST] --- Wed May 24 2017