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

burek burek021 at gmail.com
Sat Feb 16 02:05:02 CET 2013


[00:16] <cone-893> ffmpeg.git 03Vignesh Venkatasubramanian 07master:003be0a9c33e: Removing network.h from matroskadec.c
[00:16] <cone-893> ffmpeg.git 03rogerdpack 07master:12c71f648cbc: dshow: Fix MSVC support, remove av_export, which was apparently unneeded anyway.
[00:27] <cone-893> ffmpeg.git 03Michael Niedermayer 07master:8102a097a5ce: doc/APIchanges: List merge commit hashes and version numbers
[00:29] <cone-893> ffmpeg.git 03Stefano Sabatini 07master:772b949d8eea: examples/scaling_video: fix typo
[01:06] <Paranoialmaniac> michaelni: fiel atom is only in mov. at least, fiel atom is not defined in 14496-12(iso base media)/14 (mp4)/15 (avc), even if fiel atom is present in a non-mov file, reader shall ignore it
[01:09] <cone-893> ffmpeg.git 03Stefano Sabatini 07master:7ac3ccc5f238: lavfi/unsharp: use the same macros used in the original MP filter
[01:59] <michaelni> Paranoialmaniac, thanks!
[02:07] <Paranoialmaniac> undefined atoms under a certain brand shall be ignored by reader. they are just junk under that brand
[04:03] <cone-893> ffmpeg.git 03Michael Niedermayer 07master:4a6fa7963bd2: lavf: dont try to find fps for attached pictures
[08:40] <cone-466> ffmpeg.git 03Cyrille Faucheux 07master:75758f84def2: build: fixes a "can't cd to..." issue when installing shared libraries.
[09:07] Action: ubitux still trying to figure out what Nicolas really has in mind about the sub_charenc mode thing
[12:16] <cone-241> ffmpeg.git 03Diego Biurrun 07master:ab441e20ffdf: avutil: Move emms code to x86-specific header
[12:16] <cone-241> ffmpeg.git 03Diego Biurrun 07master:759a3a217783: configure: Move MinGW CPPFLAGS setting to libc section, where it belongs
[12:16] <cone-241> ffmpeg.git 03Diego Biurrun 07master:4db96649ca70: avutil: Ensure that emms_c is always defined, even on non-x86
[12:16] <cone-241> ffmpeg.git 03Michael Niedermayer 07master:61fbb4cd57d7: Merge commit '4db96649ca700db563d9da4ebe70bf9fc4c7a6ba'
[12:27] <cone-241> ffmpeg.git 03Diego Biurrun 07master:49fe280753e0: h264idct: Replace duplicate scan8 table by appropriate #include
[12:27] <cone-241> ffmpeg.git 03Michael Niedermayer 07master:048ecbd3f833: Merge commit '49fe280753e0f167ac3d9f227f0c0f7744501fc1'
[12:34] <cone-241> ffmpeg.git 03Diego Biurrun 07master:3594554a064d: sparc: dsputil: Simplify high_bit_depth checks
[12:34] <cone-241> ffmpeg.git 03Michael Niedermayer 07master:f98598942f7f: Merge remote-tracking branch 'qatar/master'
[13:24] <Shiz> >archlinux
[13:24] <Shiz> no wonder it failed
[13:31] <kode54> hah
[13:53] <ubitux> Shiz: libav moved some stuff again, no wonder it failed
[16:02] <Shiz> ubitux: you're not libav though, are you :-)
[16:15] <ubitux> kierank: give me an hour
[16:15] <kierank> no problem
[16:16] <ubitux> sorry for the delay, i'm trying to catch up with all i missed this month :)
[16:16] <ubitux> kierank: btw, you're using that filter?
[16:16] <Compn> Shiz : ffmpeg merges from libav, including their bugs :D
[16:16] <kierank> i am investigating using it
[16:16] <kierank> ubitux: the biggest issue of course is getting the amount to normalise by to volume
[16:17] <kierank> but i think that'll be doable in the latest libav merge
[16:17] <ubitux> can't you just use af volume as a second pass?
[16:17] <ubitux> doing a simple substraction
[16:17] <kierank> i am filtering in realtime
[16:17] <Shiz> Compn: I'm aware, it's just kind of hypocitic to bitch about libav if you merge their changes without apparently checking if it works for your own repo :)
[16:18] <ubitux> Shiz: this fate instance has for very particular purpose to test such thing
[16:19] <Shiz> ic
[16:19] <kierank> ubitux: do you know where it says what length you are meant to use per "time slice" of audio in the documents
[16:19] <Compn> libav has their own fate system too, http://fate.libav.org
[16:19] <ubitux> Shiz: bitching about the distro wasn't innocent either, it's a bit hypocrit to critic such behaviour
[16:19] <Compn> oh burn
[16:19] <ubitux> kierank: the 100ms and 3s?
[16:20] <ubitux> erm 400ms
[16:20] <kierank> are those segments the amounts of time that you then pass to the volume filter?
[16:20] <kierank> and normalise separately
[16:20] <ubitux> i don't know about the real time normalization
[16:21] <ubitux> i've really spent only 2 weeks on this :D
[16:21] <kierank> that's the part i don't quite understand about r128
[16:21] <kierank> r128 or atsc a/85 is going to be mandatory in some countries for realtime encoding
[16:21] <ubitux> i'd say adjust volume in 400ms windows
[16:22] <ubitux> based on the overall loudness
[16:22] <kierank> yeah
[16:22] <ubitux> (integrated)
[16:23] <ubitux> or maybe using the other loudness
[16:23] <ubitux> to get something smoother
[16:26] <mateo`> hi guys !
[16:27] <kierank> hello
[16:30] <mateo`> is there a way to force the number of threads of a decoder from a demuxer ?
[16:30] <mateo`> i'm trying to solve this ticket https://ffmpeg.org/trac/ffmpeg/ticket/1102
[16:32] <mateo`> the problem i'm facing is that i need to reconstruct a full frame from 2 jpeg2000 frame
[16:32] <mateo`> i have a current wip here https://github.com/mbouron/FFmpeg/commits/mxfdec_j2ki but it removes threading support from the libopenjpeg wrapper
[16:33] <mateo`> (and i'm not familiar at all with the threading api)
[16:38] <mateo`> any hints would be appreciated ;)
[16:40] <cone-462> ffmpeg.git 03David A. Sedacca 07master:de21e6736e36: lavfi/ebur128: fix channel weights
[16:40] <cone-462> ffmpeg.git 03sedacca at comcast.net 07master:b64de24fd7a5: lavfi/ebur128: advance pointer to samples
[16:41] <ubitux> erm, i should have checked the authorship
[16:41] <TimNich> :P
[16:42] <kierank> thanks
[16:48] <ubitux> 16:16:59 <+kierank> ubitux: the biggest issue of course is getting the amount to normalise by to volume
[16:48] <ubitux> 16:17:12 <+kierank> but i think that'll be doable in the latest libav merge
[16:48] <ubitux> what are you refering to?
[16:48] <ubitux> lavfi already has metadata injection
[16:48] <kierank> elenril said it may be possible with per frame metadata
[16:48] <ubitux> we actually can already do that given relatively little effort
[16:48] <ubitux> we already have them in buffer ref in lavfi
[16:48] <ubitux> so it's the sasme
[16:48] <ubitux> same*
[16:49] <kierank> well yes but that's going to become AVBuffer or something
[16:49] <kierank> to be unified
[16:49] <ubitux> currently it's copied at the AVFrame at the end
[16:49] <ubitux> the feature you need is already available
[16:49] <kierank> ok
[16:50] <ubitux> it's already used in two filters iirc
[16:50] <ubitux> silencedetect and scenedetect
[19:06] <cone-462> ffmpeg.git 03Stefano Sabatini 07master:0018221c03c2: doc: fix reference to ffmpeg-bitstream-filters.html page
[19:17] <cone-462> ffmpeg.git 03Hendrik Leppkes 07master:5ad43af9a62c: lavfi/kerndeint: use av_pix_fmt_desc_get instead of directly accessing the table
[19:53] <saste> ubitux: i'm benchmarking kerndeint vs. mp=kerndeint and noticing no serious difference (even without the linesize "optimizations")
[19:53] <saste> how was you testing it?
[19:54] <saste> also, do you have numbers to share?
[21:39] <BBB-work> who is "Owner	fate" on fate.ffmpeg.org?
[21:40] <BBB-work> (I'm looking for the owner of "http://fate.ffmpeg.org/report.cgi?time=20130215202302&slot=x86_64-msvc10-windows-native")
[21:41] <llogan> damnit roger
[21:43] <BBB-work> nevcairiel, Daemon404: is that one of you?
[21:44] <nevcairiel> thats mine
[21:44] <nevcairiel> why?
[21:44] <BBB-work> \o/
[21:44] <BBB-work> does that machine have avx?
[21:44] <nevcairiel> yes
[21:44] <BBB-work> uhm...
[21:44] <BBB-work> ok
[21:44] <BBB-work> so why does it pass?
[21:45] <BBB-work> I've been finding 2 avx-specific win64 bugs already
[21:51] <nevcairiel> i havent seen any issues recently
[21:54] <BBB-work> so one issue (patch coming sometime soon) is that h264 loopfilter uses redzone
[21:54] <BBB-work> win64 doesn't support that
[22:01] <Compn> BBB-work : any chance you can review the dxva2 patch on the list ?
[22:01] <Compn> everyone seems to ignore it :\
[22:03] <nevcairiel> because we hate it
[23:02] <BBB-work> Compn, dxva2? I don't even know what that is
[23:14] <BBB-work> (if you're asking me because it's windows; I have absolutely no love for windows, and don't ever use it; I keep msvs working for chrome :) )
[23:39] <cone-941> ffmpeg.git 03Michael Niedermayer 07master:5e947aeb5945: sws/x86: improve rounding for yuv2yuvX
[23:49] <saste> ubitux: ping kerndeint
[00:00] --- Sat Feb 16 2013


More information about the Ffmpeg-devel-irc mailing list