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

[burek]

[09:23:10 CET] <djcj> Linking ffmpeg against fdk-aac makes it non-free. However, would it instead be possible to load it via dlopen() or by using a wrapper library similar to libdvdread and libdvdcss? And if yes, would it still be (L)GPL? That's just something I've been wondering for a while.
[09:28:18 CET] <thardin> just using dlopen() to load the exact same function pointers seems like something that is "spiritually" identical to dynamic linking
[09:30:27 CET] <thardin> in either case it's only a problem if you're redistributing
[09:31:16 CET] <nevcairiel> did anyone ever try to cheat that  by shipping a compiler :d
[09:32:21 CET] <thardin> the real question you'd need to ask yourself is "could I handle a lawsuit if someone got upset at this?"
[09:32:38 CET] <Mavrik> And probably "is the builtin AAC perhaps even good enough for me?"
[09:32:44 CET] <thardin> that too
[09:32:51 CET] <thardin> I hear it's gotten better in recent years
[09:33:40 CET] <Mavrik> As far as I've read through the ticket, it's currently supposed to be better than the FAAC and VO-AACENC so it can't be that terrible :)
[09:33:53 CET] <atomnuker> it's better than fdk-aac for some audio now
[09:34:00 CET] <nevcairiel> beating those two aint hard, they are both extremely bad
[09:34:22 CET] <atomnuker> and it will be non-experimental soon
[09:34:59 CET] <Mavrik> True, but bunch of people still used them. Hence the question - maybe it's just good enough :)
[09:35:05 CET] <djcj> I don't have good speakers, so I probably won't hear much of a difference anyway.
[09:42:55 CET] <djcj> <nevcairiel>: did anyone ever try to cheat that  by shipping a compiler :d << I would assume one could ship compiled ffmpeg object code of everything that doesn't include FDK header files, so that only the fdk parts needed to be compiled by the user.
[09:43:32 CET] <djcj> But of course you could also simply use the fdk command line tool in combination with ffmpeg.
[11:00:06 CET] <BAWSTi>  Hi, I'm currently trying to get ffmpeg to work in my android application. If I want to use the command "ffmpeg -i input.wav -f mp2 output.mp3" can I do something like "ffmpeg -i /Download/input.wav -f mp2 /Download/output.mp3"??
[11:20:36 CET] <rcombs> anyone know how complex eac3 7.1 en/decoding would be?
[11:20:49 CET] <nevcairiel> that depends
[11:21:00 CET] <nevcairiel> do you speak of actual eac3, or the bastardization used on blu-rays
[11:21:17 CET] <ubitux> libavfilter/af_volume.c:    av_opt_free(vol);
[11:21:19 CET] <ubitux> why ^
[11:21:52 CET] <rcombs> nevcairiel: good question
[11:22:18 CET] <rcombs> the Apple TV can decode 5.1 or 7.1 AAC, but it mixes it down to stereo for output :|
[11:22:21 CET] <nevcairiel> because 7.1 "eac3" on blurays is actually 5.1 ac3 and 4ch eac3 thats supposed to augment the ac3 stream
[11:22:49 CET] <nevcairiel> i would think proper 7.1 eac3 might actually work already
[11:22:51 CET] <rcombs> so for 5.1 it needs AC3 and for 7.1 it needs eac3
[11:22:53 CET] <nevcairiel> the blu-ray thing just doesnt
[11:23:02 CET] <rcombs> it refuses right now
[11:23:13 CET] <rcombs> since 7.1 isn't in ff_ac3_channel_layouts
[11:24:09 CET] <rcombs> (have I mentioned passthrough audio is bad and dumb)
[11:24:24 CET] <rcombs> (why does spdif even exist in HDMI)
[11:25:47 CET] <wm4> HDMI is a standard designed to torture souls
[11:25:58 CET] <wm4> multichannel PCM does not work well with it
[11:26:11 CET] <nevcairiel> i wouldnt really count the audio passthrough things to its biggest problems
[11:27:33 CET] <nevcairiel> that PCM is so annoying to handle is another matter
[11:27:57 CET] <nevcairiel> my solution was to remap all uncommon PCM streams to the 3 common channel layouts, that seems to avoid 99.9% of the problems
[11:28:12 CET] <nevcairiel> (stereo, 5.1, 7.1)
[11:28:51 CET] <wm4> this doesn't really work on OSX for me, and on windows there are problems too
[11:29:06 CET] <wm4> such as windows allegedly only outputting stereo even in exclusive mode
[11:29:18 CET] <wm4> (if the audio settings are not set to multichannel)
[11:29:43 CET] <nevcairiel> never heard of such problems
[11:30:58 CET] <wm4> and OSX apparently forces a single channel layout for all multichannel things
[11:31:37 CET] <wm4> (I really should have a receiver that shows the damn channel layout, and can take 7.1)
[11:32:47 CET] <nevcairiel> my experiences with receivers is that they just see a channel count and  apply whatever default layout they know
[11:33:05 CET] <nevcairiel> but i couldnt tell if thats maybe the GPUs HDMI implementation being terrible
[11:33:07 CET] <wm4> sigh
[11:33:44 CET] <nevcairiel> my personal movie viewing setup was changed to avoid as much HDMI as possible two years ago
[11:33:54 CET] <nevcairiel> only use gpu->tv  hdmi for the image now
[11:34:05 CET] <wm4> and for audio?
[11:34:08 CET] <nevcairiel> usb dac
[11:34:15 CET] <wm4> stereo?
[11:34:22 CET] <nevcairiel> nah multichannel
[11:36:18 CET] <nevcairiel> but the audio being a problem wasnt even the main reason, i kept running into problems where the HDMI handshake would do weird things and the image would occasionally flicker on/off
[11:36:40 CET] <nevcairiel> receiver may have been at fault, but instead of hoping a new one fixes it, better get rid of it entirely
[11:38:12 CET] <nevcairiel> got a decent usb dac and some entry-level amplifier, and never looked back
[12:06:52 CET] <durandal_1707> what to use instead of deprecated AVPicture?
[12:17:45 CET] <durandal_1707> ubitux: remnant from merges?
[12:18:45 CET] <rcombs> AVFrame?
[12:20:10 CET] <rcombs> nevcairiel: apparently 7.1 eac3 involves dependent substreams, which lavc can't decode either
[12:20:21 CET] <rcombs> though I'm not sure they're that technically complex
[12:28:41 CET] <cone-319> ffmpeg 03Paul B Mahol 07master:c89e075d5a66: avcodec: add Interplay ACM decoder
[12:28:42 CET] <cone-319> ffmpeg 03Paul B Mahol 07master:cb7a00da2112: avformat: add acm demuxer
[13:31:22 CET] <Daemon404> https://www.reddit.com/r/programming/comments/3r90iy/facebooks_code_quality_problem/cwmndms
[13:31:42 CET] <Daemon404> (please dont dogpile on replies, i already wrote one)
[13:33:03 CET] <nevcairiel> how can you even care about someone thats named 1337Gandalf
[13:33:27 CET] <Daemon404> that is a valid point
[13:37:10 CET] <J_Darnley> but he must be an elite programming wizard!
[13:37:30 CET] <JEEB> lol @ 1337gandalff
[13:44:11 CET] <rcombs> &wat
[13:57:35 CET] <kierank> didn't realise gcc 4.6 was that bad
[14:07:01 CET] <wm4> make: *** No rule to make target 'libavcodec/pixblockdsp_template.c', needed by 'libavcodec/pixblockdsp.o'.  Stop.
[14:07:28 CET] <nevcairiel> did you bisect again without make clean
[14:08:09 CET] <wm4> I just pulled
[14:08:40 CET] <wm4> why does this problem happen and why can't it be fixed without running clean
[14:08:49 CET] <J_Darnley> I think there is a *.d file saying that the *.o depends on *.c which no longer exists.
[14:09:01 CET] <nevcairiel> because make
[14:09:17 CET] <wm4> I never have this problem in my own make based build system
[14:12:04 CET] <nevcairiel> you probably dont use such arcane things as C template files
[14:13:11 CET] <andoma> Doesn't -MP solve this issue?
[14:26:26 CET] <Daemon404> hmm
[14:26:32 CET] <Daemon404> finally found a hex editor i want on linux
[14:26:38 CET] <Daemon404> and it segfaults whe ni turn on modify mode
[14:26:40 CET] <bencoh> ?
[14:26:46 CET] <Daemon404> ?
[14:26:55 CET] <bencoh> which one?
[14:26:59 CET] <Daemon404> beye
[14:27:10 CET] <Daemon404> it seems to be a hiew clone (my preferred windows hex editor)
[14:27:16 CET] <Daemon404> hiew doesnt run under wine.
[14:28:10 CET] <bencoh> you can try ht (http://hte.sourceforge.net/)
[14:28:38 CET] <Daemon404> looks reasonable; ill give it a try
[14:28:49 CET] <rcombs> guh, decoding eac3 is going to be awkward
[14:29:11 CET] <Daemon404> (the beye code is horrendous btw)
[14:29:13 CET] <rcombs> and encoding probably will be too, thanks to 1:1 API
[14:29:35 CET] <rcombs> apparently you're supposed to have 2 packets per frame for 7.1
[14:29:36 CET] <nevcairiel> its actually not 1:1
[14:29:40 CET] <rcombs> fine n:1
[14:30:06 CET] <nevcairiel> are you sure eac3 7.1 cant just be sone packet
[14:30:16 CET] <nevcairiel> this two packet business sounds like the blu-ray shenanigans
[14:30:21 CET] <Daemon404> the api already hands decoding N:1 via got_frame, no?
[14:30:25 CET] <Daemon404> handles*
[14:30:28 CET] <nevcairiel> yes
[14:30:35 CET] <Daemon404> whats the issue then
[14:31:06 CET] <rcombs> dependent substreams (read: the additional channels past 5.1) go in a separate eAC3 frame
[14:31:37 CET] <Daemon404> you cant work that into the existing N:! api?
[14:31:39 CET] <Daemon404> N:1*
[14:31:46 CET] <rcombs> I could for decoding
[14:32:01 CET] <Daemon404> i dont think you want to use our ac3 encoder.
[14:32:20 CET] <nevcairiel> ac3enc isnt that bad on quality
[14:32:36 CET] <Daemon404> also i hit this exact issue tryingto add interlaced hevc encoding
[14:32:40 CET] <Daemon404> which is 1:N
[14:32:51 CET] <nevcairiel> you would've been shot for allowing that, anyway
[14:32:58 CET] <nevcairiel> dodged a bullet there!
[14:33:09 CET] <Daemon404> kierank would dive in front of me
[14:33:41 CET] <nevcairiel> interestingly the BT.2020 specification specifically says that all BT.2020 content must be progressive
[14:34:13 CET] <rcombs> hmm, I think the actual matroska file has both frames in a single packet
[14:34:17 CET] <Daemon404> technically true for interlaced hevc....
[14:34:18 CET] <Daemon404> technically.
[14:34:19 CET] Action: Daemon404 runs
[14:34:20 CET] <rcombs> so for encoding it might be easy
[14:34:30 CET] <rcombs> and for decoding I just need to make the parser not split them up
[14:34:56 CET] <nevcairiel> if you make that work with the base frame ac3 and the extended frame eac3, then you will also fix blu-ray =p
[14:35:11 CET] <rcombs> nevcairiel: that's actually not hard
[14:35:49 CET] <bencoh> interlaced hevc? oh come on ...
[14:35:54 CET] <nevcairiel> except that in blu-ray the base is 5.1 and the extended is 4 channel, which are supposed to override the 2 surround channels from the base and add the two others
[14:36:06 CET] <nevcairiel> backwards compat hellö
[14:36:10 CET] <rcombs> nevcairiel: that's more or less how regular eac3 works
[14:36:52 CET] <rcombs> just, with the independent substream in the regular AC3 bitstream format instead of the eAC3 one
[14:37:03 CET] <nevcairiel> i suppose
[14:37:31 CET] <nevcairiel> i probably have some old bluray sample with that setup around if you want it at some point
[14:37:32 CET] <rcombs> 7.1 eac3 is one 5.1 eac3 frame and then a 4-channel dependent substream frame
[14:37:51 CET] <rcombs> I mean, I think you could technically have it be 2-channel
[14:37:59 CET] <rcombs> but afaict that's not common
[14:38:26 CET] <rcombs> you could technically have 2 entirely separate mixes
[14:38:37 CET] <rcombs> by having 8 channels in the dependent frame
[14:38:46 CET] <rcombs> the later ones override the previous ones
[14:39:15 CET] <rcombs> and it's technically legal to have multiple completely independent mixes in a single bitstream but I have no idea why you would want that
[14:40:42 CET] <thilo> do we have a corresponding AV_PIX_FMT for something like this: 'l10r': Packed Little Endian ARGB2101010 
[14:42:58 CET] <rcombs> should probably make the ac3 parser keep reading until it sees another independent frame with ss=0
[15:21:44 CET] <Daemon404> bencoh, keybindings are a bit funky and the build system is strange, but ht seems reasonable.
[15:22:25 CET] <bencoh> :)
[15:23:39 CET] <Daemon404> its missing a bit from hiew/beye i like (virtual offsets), but i can live with that efor editing isobmff files.
[15:32:27 CET] <J_Darnley> That was a strange operation.
[15:32:58 CET] <J_Darnley> I just pulled a large number of changes from git and this was shown:
[15:33:00 CET] <J_Darnley> rename libavcodec/pixblockdsp_template.c => libavfilter/x86/vf_stereo3d_init.c (56%)
[15:34:08 CET] <nevcairiel> thats probably just the copyright header that git used for a rename =p
[15:36:49 CET] <rcombs> is a rename actually a first-class operation in git, or it it just a deletion and a creation with similar contents?
[15:37:57 CET] <nevcairiel> its not a first-class operation
[15:38:10 CET] <nevcairiel> various tools have rename detection to try to track that and show nicer diffs
[15:38:20 CET] <rcombs> figured
[15:38:43 CET] <rcombs> so yeah, probably copyright header in common
[15:38:52 CET] <Daemon404> i guess thats how the "track between renames" feature for gitblame works then
[15:38:58 CET] <Daemon404> i thought it might have actual rename support.
[15:40:41 CET] <nevcairiel> at least I think it doesn't
[16:38:18 CET] <philipl> BtbN: Trawling through my logs - you said that nvidia are already exposing vp9 through the new dxva?
[16:38:44 CET] <BtbN> No idea, don't think I said that.
[16:38:58 CET] <BtbN> Intel does, via some strange VAAPI hybrid driver.
[16:39:28 CET] <philipl> It was nevcairiel.
[17:00:59 CET] <philipl> nevcairiel: So nvidia already has a driver out with vp9 dxva? I didn't expect it to happen so quickly.
[17:01:46 CET] <nevcairiel> philipl: none that works
[17:01:48 CET] <nevcairiel> intel does though
[17:04:37 CET] <nevcairiel> the latest nvidia driver exposes the dxva device, but it doesnt work
[17:06:49 CET] <j-b> same here
[17:06:54 CET] <j-b> works on intel, fails on nvidia
[17:07:36 CET] <nevcairiel> there should be a new nvidia driver this week, maybe it works then
[17:14:26 CET] <nevcairiel> another problem is that to compile it you need a pre-release windows sdk, so I have been waiting to push the patch to the ML until the final visual studio update comes out  including the new sdk
[17:14:33 CET] <nevcairiel> which should be around in two weeks
[17:39:11 CET] <canaar> Hey guys, in ffserver.c, in the bandwidth computation function, it does this :
[17:39:27 CET] <canaar> stream->bandwidth = (bandwith + 999) / 1000
[17:39:33 CET] <canaar> what is it done for?
[17:40:14 CET] <nevcairiel> rounding
[17:40:54 CET] <ubitux> why not 500?
[17:41:04 CET] <thardin> ceil()
[17:41:09 CET] <thardin> in integer form
[17:41:34 CET] <canaar> How does it round, and what is the need for rounding @nevcairiel?
[17:42:16 CET] <nevcairiel> clearly the variable wants a bandwidth in a magnitude lower, say in kbit instead of bit, and some kind of defined rounding is just good form
[17:43:04 CET] <canaar> Okay
[17:43:19 CET] <nevcairiel> in this case the author choose to use ceil
[19:06:15 CET] <cone-319> ffmpeg 03James Almer 07master:a97f1e7bd085: fate: update fate-source ref file
[20:19:25 CET] <sh4rm4^bnc>  i got a copy of a ffserver's .ffm file which has evidence of a crime. is it possible to rip the video data out of it ?
[20:20:10 CET] <sh4rm4^bnc> trying to play it with ffplay yields a bunch of
[20:20:11 CET] <sh4rm4^bnc> [ffm @ 0xf183a0] invalid stream index 167
[20:20:11 CET] <sh4rm4^bnc> [ffm @ 0xf183a0] invalid stream index 132=    0KB sq=    0B f=0/0   
[20:20:11 CET] <sh4rm4^bnc> [ffm @ 0xf183a0] invalid stream index 32
[20:20:11 CET] <sh4rm4^bnc>     nan M-V:    nan fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0   
[20:22:21 CET] <wm4> (you should ask such questions on #ffmpeg)
[20:25:09 CET] <peloverde> The best thing about the VP9 dxva spec is the author
[20:27:21 CET] <fritsch> lol
[20:27:25 CET] <fritsch> who is the author?
[20:27:45 CET] <atomnuker> "Yongjun Wu and Gary J. Sullivan"?
[20:28:24 CET] <atomnuker> the Gary Sullivan?
[20:28:40 CET] <JEEB> oh that guy
[20:28:46 CET] <fritsch> h263 guy
[20:29:30 CET] <nevcairiel> he works for microsoft, he is involved with all dxva specs
[20:30:04 CET] <wm4> why is it funny
[20:30:58 CET] <fritsch> that's not funny ...
[20:31:09 CET] <fritsch> I read it like: the spec is badly written
[20:31:25 CET] <nevcairiel> nah the dxva specs are usually quite complete
[20:31:40 CET] <fritsch> "20:25 <@peloverde> The best thing about the VP9 dxva spec is the author" <- commenting on this
[20:32:12 CET] <wm4> well I'm assuming it's not really "good" at all
[20:32:26 CET] <wm4> err, referring to the "best"
[20:32:50 CET] <peloverde> I know he works on all the dxva specs, but I just find it amusing because if I had to characterize one person as "Mr (or Ms) HEVC" it would be him. 
[20:33:05 CET] <JEEB> ye
[20:33:11 CET] <JEEB> he's on all those specs
[20:33:15 CET] <nevcairiel> he was also quite involved with the AVC specs
[20:33:17 CET] <nevcairiel> but yeah
[20:33:40 CET] <nevcairiel> if your job involves writing dxva specs, you also gotta do it for other codecs =p
[20:35:07 CET] <nevcairiel> but the spec was fine, as good as it can be considering it has no vp9 spec to reference, so it references the libvpx code instead
[20:38:42 CET] <jamrial> hopefully vp10 addresses this. seeing the bitstream permanently affected because of libvpx bugs that weren't fixed in time was awful
[20:38:55 CET] <peloverde> There are dxva specs for formats that have neither public source nor public specs (WMV8)
[20:39:25 CET] <nevcairiel> i never read those parts
[20:39:38 CET] <nevcairiel> its in the same document as the vc1 spec, but i skipped over the wmv8 parts
[20:40:09 CET] <nevcairiel> it was from the crazy time when they still offered partial acceleration, which noone used
[20:40:56 CET] <nevcairiel> the wmv dxva spec is quite long and convoluted, it describes a lot of codec concepts
[20:41:04 CET] <llogan> michaelni, Compn: I'll be gone from Nov 4-14. can you deal with the ML queue while I'm gone?
[21:10:14 CET] Action: durandal_1707 managed to decode stereo xma2
[21:14:04 CET] <Compn> llogan : sure
[22:09:39 CET] <kierank> atomnuker: ping
[22:18:42 CET] <durandal_1707> multichannel xma2 is pure shit
[22:24:13 CET] <cone-319> ffmpeg 03Ganesh Ajjanagadde 07master:03f5bcd92123: avfilter/vf_rotate: correct log message
[22:31:54 CET] <cone-319> ffmpeg 03Ganesh Ajjanagadde 07master:265f83fd3597: avutil/common: add FFDIFFSIGN macro
[22:31:55 CET] <cone-319> ffmpeg 03Ganesh Ajjanagadde 07master:92e483f8ed70: all: use FFDIFFSIGN to resolve possible undefined behavior in comparators
[23:26:11 CET] <kierank> should we apply to google code-in
[23:26:42 CET] <JEEB> it just needs a long pre-recorded list of tasks I think
[23:26:51 CET] <JEEB> if that can be arranged it could work
[23:27:30 CET] <kierank> you don't need that to apply
[23:28:26 CET] <JEEB> true that
[00:00:00 CET] --- Wed Nov  4 2015