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

[burek]

[00:02] <cone-932> ffmpeg.git 03Clément BSsch 07master:ee7ee9b1b4c9: avcodec/mpeg12dec: fix vissible typo after 17c65651
[00:49] <Timothy_Gu> michaelni: you know you can scroll to the right, right?
[00:51] <Timothy_Gu> michaelni: I just tested on Nexus 7 with Chrome and iPhone 5s, the scrolling works.
[00:54] <michaelni> Timothy_Gu, on my old old android phone the scrolling works but it doesnt show the rest of the table
[00:54] <Timothy_Gu> what do you mean?
[00:55] <Timothy_Gu> horizontal or vertical?
[00:55] <michaelni> scrolling to the right
[00:57] <michaelni> depending on the orientation of the phone i can see differntly far to the right but its never the complete table
[00:58] <michaelni> Timothy_Gu, actually i can see the whole table when i zoom out 
[00:59] <Timothy_Gu> michaelni: well I can't reproduce the problem here.
[01:00] <Timothy_Gu> Here's how it should be: http://imgur.com/eoAbg9p
[01:00] <Timothy_Gu> http://imgur.com/RqBpus2
[01:00] <Timothy_Gu> What Android version are you using, and which browser?
[01:03] <michaelni> i dunno but i think its some old webkit thing
[01:04] <Timothy_Gu> probably. For the record I also tested with an iPhone 4s with iOS 6 and it works too.
[02:39] <jamrial> ubitux: i started to port the sad and vsad functions from me_cmp a month ago but got distracted with other things
[02:39] <jamrial> i can give you what i have if you were planning on doing the same
[03:24] <cone-575> ffmpeg.git 03Michael Niedermayer 07master:2e6fdcb7f3c8: avformat/tee: flip assigment direction
[05:15] <cone-575> ffmpeg.git 03James Almer 07master:d0f56ca07101: x86/hevc_deblock: improve 8bit transpose store macros
[06:09] <rcombs> what makes FDKAAC "nonzero"? https://github.com/mstorsjo/fdk-aac/blob/master/libFDK/src/FDK_bitbuffer.cpp#L29 I'm no expert, but I don't see anything making this GPL-incompatible
[06:10] <rcombs> erm, "nonfree"
[06:15] <jamrial> ubitux: http://www.agner.org/optimize/instruction_tables.pdf page 100
[06:15] <jamrial> apparently, both versions would be pretty much the same
[06:24] <j-b> rcombs: "You may use this FDK AAC Codec software or modifications thereto only for purposes that are authorized
[06:24] <j-b> by appropriate patent licenses."
[06:24] <j-b> rcombs: limitation of use, not compliant with GPLv2 paragraph 0
[06:26] <rcombs> ah, I missed that
[06:26] <rcombs> (they hid it in a separate section :/)
[06:26] <j-b> "You may not charge copyright license fees for anyone to use, copy or distribute the FDK AAC Codec software or your modifications thereto." is a possible violation of the GPL section 2 or 3
[06:27] <rcombs> isn't that almost the same as LGPL 2c?
[06:28] <j-b> well, I don't think so
[06:28] <j-b> because you're allowed to charge for distribution of GPL soft
[06:29] <rcombs> it specifically says "copyright license fees"; LGPL2 2c says "c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License."
[06:29] <j-b> licensed
[06:29] <j-b> not distribution
[06:29] <j-b> but I agree with you, that this is probably just a poor wording 
[06:29] <j-b> and could be ignored.
[06:30] <rcombs> as for the patent clause, I'm going to email them and ask about removing it, because it's probably really meant to be meaningless (i.e. doesn't say anything your own local law doesn't already)
[06:31] <j-b> GPLv2 3.b "for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code"
[06:31] <j-b> but there is still a cost
[06:32] <j-b> rcombs: that would be nice...
[06:32] <j-b> rcombs: but we asked many times
[06:32] <rcombs> so the question is whether the FDKAAC license's "no copyright license fee" is meant to include the cost of redistribution
[06:34] <j-b> this is one quetion
[06:34] <j-b> and the limitation of use, is another one
[06:35] <rcombs> and the bigger one :\
[06:35] <j-b> and we asked, fraunhoffer and Google
[06:35] <j-b> and nothing changed
[06:36] <rcombs> well, certainly no harm in asking again from a different position
[06:37] <j-b> rcombs: clearly
[06:50] <rcombs> well, sent off an email to Fraunhofer; if I don't hear back from them, I'll poke my developer advocate at Google and tell her that resolving the issue would improve audio quality in our Chromecast app
[07:06] <j-b> rcombs: you know that we discussed about this matter with Head Open Source @Google, right?
[07:07] <rcombs> well, now I know that :3
[07:09] <rcombs> j-b: did their response at the time seem more like "don't care" or "can't do anything"?
[07:13] <j-b> rcombs: can't do anything, use vo_aacenc
[07:13] <rcombs> welp
[08:11] <Timothy_Gu> rcombs: FFmpeg native AAC encoder with http://trac.ffmpeg.org/attachment/ticket/2686/aac-improvements-wip-v8g.patch is probably better than vo-aacenc
[08:11] <Timothy_Gu> even without iit t is better
[08:11] <rcombs> Timothy_Gu: yup, aware
[11:31] <cone-575> ffmpeg.git 03Stefano Sabatini 07master:ac1e3882cce5: doc/ffserver: merge paragraph starting with "What happens next?" with previous one
[11:41] <cone-575> ffmpeg.git 03Michael Niedermayer 07master:7dbc27dc1dd3: avcodec/takdec: move tmp declaration to where its used
[11:41] <cone-575> ffmpeg.git 03Michael Niedermayer 07master:4fed0198216d: avcodec/takdec: remove unused variable
[13:31] <kierank> rcombs: make them support opus on Chromecast :)
[13:54] <kierank> oh they do
[13:54] <kierank> then use opus =p
[13:58] <nevcairiel> how fast is the opus encoder?
[14:02] <kierank> it has no x86 asm
[14:02] <kierank> but it's audio
[14:07] <nevcairiel> currently I also stream mpegts in HLS in my chromecast setup, wonder what else I could use for live streaming that allows for opus usage easier
[14:08] <nevcairiel> maybe it does fragmented mp4
[14:21] <cone-575> ffmpeg.git 03Michael Niedermayer 07master:b4d525eb6346: avcodec/pnm: check buf[0] before using buf[1]
[14:33] <kierank> opus is only supported in web
[14:33] <kierank> m
[18:24] <cone-293> ffmpeg.git 03Michael Niedermayer 07master:fee982048e33: avformat/mux: flush after header writing, like after packets
[18:24] <cone-293> ffmpeg.git 03Michael Niedermayer 07master:6cdf409884bd: avformat/mpegtsenc: do not flush after everything
[18:35] <cone-293> ffmpeg.git 03Diego Biurrun 07master:7835c24e19d9: dv: Update DV-profile-related functions to current public API
[18:35] <cone-293> ffmpeg.git 03Michael Niedermayer 07master:b7f8d3de2c41: Merge commit '7835c24e19d9e1cb43fba5a02ce9d81d518f1300'
[18:46] <ubitux> michaelni: so it seems you got your lens correction filter you asked me when doing the vignette filter :))
[18:48] <cone-293> ffmpeg.git 03Diego Biurrun 07master:df507d5aa063: tiff: Replace deprecated PIX_FMT names by modern ones
[18:48] <rcombs> nevcairiel: late reply, but we totally cheat at Chromecast and stream MKV
[18:48] <cone-293> ffmpeg.git 03Michael Niedermayer 07master:149c1a26c4c1: Merge commit 'df507d5aa063c2ce31fac9f76c6f3bbe9a20c445'
[18:48] <michaelni> ubitux, :) havnt tried it yet though
[18:49] <rcombs> nevcairiel: they don't advertise support, but they use lavf for the demuxer and aren't picky about codecs, so H.264+AAC-in-mkv is fine
[19:05] <rcombs> also, just did a quick and highly-unscientific test, and found that libopus outperformed FDKAAC, but was beaten by ffmpeg's native AAC, in terms of speed
[19:05] <rcombs> (but it's audio, and all 3 encoded 22 minutes of stereo in less than 35 seconds, so it doesn't matter much anyway)
[19:06] <cone-293> ffmpeg.git 03Diego Biurrun 07master:c697c590fbf2: lcl: Disentangle pointers to input data and decompression buffer
[19:06] <cone-293> ffmpeg.git 03Michael Niedermayer 07master:2212bff9a276: Merge commit 'c697c590fbf296b1679b80c8f4071e4c8a6c884b'
[19:17] <cone-293> ffmpeg.git 03Diego Biurrun 07master:c6a1ac2dd980: vf_fps: Replace use of deprecated AVFilterBufferRef by AVFrame
[19:17] <cone-293> ffmpeg.git 03Michael Niedermayer 07master:e896a5bdd6c3: Merge commit 'c6a1ac2dd9808a4753dd005ab5747dda68ab454f'
[19:25] <cone-293> ffmpeg.git 03Diego Biurrun 07master:6a928293dd29: examples: filter_audio: Add missing mem.h header for av_freep()
[19:25] <cone-293> ffmpeg.git 03Michael Niedermayer 07master:f1d6fc779450: Merge commit '6a928293dd29c7f0dcf09107980a1d651c9957df'
[19:39] <kierank> rcombs: how do you know it uses lavf
[19:40] <kierank> oh it goes through chrome i guess
[19:45] <rcombs> kierank: yup, that and that it displays some lavf issues :3
[19:45] <cone-293> ffmpeg.git 03Diego Biurrun 07master:072916d903d3: filtfmts: Replace deprecated uses of AVFilterPad
[19:45] <cone-293> ffmpeg.git 03Michael Niedermayer 07master:85aaa4e6d571: Merge commit '072916d903d3a925bcd0c864f12254157cab63c1'
[19:46] <wm4> rcombs: what issues?
[19:46] <rcombs> e.g. if the first video frame is more than 5 seconds into the file, it plays black because it uses the default analyzeduration
[19:46] <wm4> how can it play "black"?
[19:47] <rcombs> wm4: as in, the <Video> remains solid black while the audio plays
[19:47] <wm4> but why? I'm pretty sure lavf doesn't generate black frames...
[19:48] <rcombs> no, that's just what Chrome does if it can't decode a video stream
[19:48] <wm4> ah
[19:48] <wm4> sounds reasonable
[19:48] <rcombs> same behavior you get if you put an audio file in a <video>, or give it a video file with no supported video streams
[19:55] <cone-293> ffmpeg.git 03Diego Biurrun 07master:bad81800bb51: avcodec: options: Add missing deprecation ifdefs around emu_edge
[19:55] <cone-293> ffmpeg.git 03Michael Niedermayer 07master:76aec9e6b4a2: Merge commit 'bad81800bb51f43d28d656abf5d45b477e3b3198'
[20:25] <ubitux> yay, automatic factorization of dct done \o/
[20:33] <ubitux> http://b.pkh.me/dct4.c http://b.pkh.me/dct8.c http://b.pkh.me/dct16.c http://b.pkh.me/dct32.c
[20:33] <ubitux> automatically generated ^
[20:34] <ubitux> (with scaling)
[20:34] <ubitux> i could try to replace with the floats with some constants, but that's not exactly simple to do
[20:34] <ubitux> anyway, i got what i needed
[20:35] <Mavrik> ooo.
[20:36] <nevcairiel> kierank: what about the AFD code in h264? Going to convert that as well to side data?
[20:36] <kierank> afaik there isn't afd h264 support
[20:36] <nevcairiel> Its in the code
[20:36] <nevcairiel> I saw it when I poked CC extract
[20:37] <nevcairiel> At least in FFmpeg, no idea about libav
[20:37] <kierank> ah only in ffmpeg
[20:37] <kierank> yeah
[20:38] <kierank> this is where my strategy of submitting to both projects breaks down
[20:48] <kierank> probably when libav is merged I'll submit an ffmpeg-only patch
[20:48] <kierank> sigh
[21:00] <cone-293> ffmpeg.git 03Diego Biurrun 07master:9f17685dfb70: avcodec: Deprecate unused defines and options
[21:00] <cone-293> ffmpeg.git 03Michael Niedermayer 07master:9400603140db: Merge commit '9f17685dfb70a73823aca16ad246ee3b831d1de8'
[21:33] <ubitux> yay, dctdnoiz almost twice as fast, even with 2 murders memcpy per block
[21:34] <ubitux> i wonder if i can somehow drop the scaling
[21:51] <BBB> memcpy is indeed murder, bad you!
[21:57] <ubitux> i'm fixing that
[22:01] <ubitux> it actually makes no difference in speed
[22:01] <ubitux> which is fun
[22:05] <wm4> memcpy was innocent all along!
[22:06] <ubitux> :)
[22:07] <ubitux> code is simpler so i'll keep without
[22:56] <kierank> michaelni: thanks
[22:56] <kierank> but not related to opus
[23:45] <cone-293> ffmpeg.git 03Michael Niedermayer 07master:e680c731a213: avcodec/avdct: Add get_pixels()
[23:45] <cone-293> ffmpeg.git 03Michael Niedermayer 07master:a7e87fef214c: avfilter/vf_spp: Use dct->get_pixels()
[00:00] --- Mon Aug  4 2014