[00:03] <J_Darnley> Which country has a timezone of GMT-10224? [00:03] <J_Darnley> (yes, I did have that calculated) [00:03] <ubitux> maybe the moon [00:04] <J_Darnley> :) [00:17] <jamrial> well, dc set the bar so high everything else feels a bit disappointing [00:18] <jamrial> still, all six are faster than their ssse3 counterparts [00:18] <jamrial> i'll send a patchset to the ml later [00:40] <tmm1> how can i run a subset of the fate tests locally? [00:43] <tmm1> ah, make fate-list to get a list of targets and make target [01:57] <cone-70> ffmpeg.git 03Michael Niedermayer 07master:c3417ed7fd92: swscale/utils: Add check that ensures that the hardcoded struct offsets are valid [02:43] <michaelni> Skyler_, is the use of the per level reference frame num reducing code in "http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/176739" (its based on a few lines of af2a4ecd7bcefc97c8aa83913c9a2980206f9cd0 from you) under LGPL in libavcodec/libx264.c ok ? [02:44] <Skyler_> zYes [02:44] <Skyler_> Yes [02:51] <michaelni> thx [03:08] <cone-70> ffmpeg.git 03Michael Niedermayer 07master:0aac9b76bc77: avcodec/libx264: Implement reference frame count limiting based on level [06:22] <cone-419> ffmpeg.git 03Michael Niedermayer 07master:14e2e40f3b5b: avfilter/vf_hqdn3: use av_malloc_array() [06:22] <cone-419> ffmpeg.git 03Michael Niedermayer 07master:6ab37221c8ee: avfilter/vf_removelogo: use av_malloc_array() [07:51] <cone-419> ffmpeg.git 03Clément BSsch 07master:bc2e39c4cc35: avfilter/lut3d: move the scale calc out of the inner loop. [09:10] <ubitux> note: it seems audacity is considering dropping ffmpeg support because 1) no one to update their code 2) api is changing too much 3) gst has ff/av support [09:11] <ubitux> see http://bugzilla.audacityteam.org/show_bug.cgi?id=606#c2 and https://ffmpeg.org/pipermail/libav-user/2014-May/006791.html [09:12] <wm4> oh yeah that's sad [09:13] <wm4> they're considering gst because ffmpeg is moving too much [09:13] <wm4> can't they use ffms2? afaik that has audio support [09:13] <wm4> oh, they need encoding [09:14] <wm4> would be so great if ffmpeg just had a simple and stable high-level API [09:15] <thardin> hmm, I do use audacity [09:15] <wm4> maybe we should even consider turning ffmpeg.c/ffplay.c into a library [09:15] <wm4> (not that that'd be a great idea, but it could lead to quick success without too much work) [09:16] <wm4> ubitux: also this was 2013 [09:16] <ubitux> my distro is packaging a "compat ffmpeg" (aka ffmpeg 0.10) just (almost) for audacity :p [09:16] <wm4> more than 6 months ago [09:16] <ubitux> the mail is recent though [09:16] <wm4> yeah [09:17] <ubitux> there are exactly 4 packages that needs the old ffmpeg version here [09:17] <ubitux> sorry, 5 [09:17] <wm4> audacity, and which others? [09:17] <ubitux> audacity, motion, synfig, openscenegraph and xjadeo [09:17] <ubitux> i think openscenegraph is the only relevant one with audacity [09:18] <ubitux> but maybe i'm wrong [13:38] <BBB> plepere: if you need help with using these macros, feel free to ask me (or any of the x264 people in here, or ubitux would know also, probably michaelni also) [14:01] <cone-419> ffmpeg.git 03Anton Khirnov 07master:a738540366c9: lavf: properly document the distinction between flags and ctx_flags [14:01] <cone-419> ffmpeg.git 03Michael Niedermayer 07master:6a72260e6baf: Merge commit 'a738540366c9b114949b7914c0d08e2c28982cfb' [14:02] <ubitux> did i miss a question? [14:04] <compn> [08:38] <plepere_> BBB : I'm trying to use the x86util.asm transpose code instead of the one defined in hevc_deblock.asm [14:04] <compn> was the last message i saw [14:04] <compn> yesterday? [14:04] <BBB> yes [14:05] <BBB> basically "if you have questions about x86util.asm/x86inc.asm, ask any of these people" [14:14] <cone-419> ffmpeg.git 03Janne Grunau 07master:7e90133f6420: build: do not append $(FFLIBS-) to $(FFLIBS) if $(NAME) is not defined [14:14] <cone-419> ffmpeg.git 03Michael Niedermayer 07master:dbd1fdd21400: Merge commit '7e90133f6420b1c53652f972b9561600822881ee' [15:07] <plepere> BBB : thanks. I'll ping you if I need anything, but I think that there are some important problems in the code that need resolving. [15:07] <plepere> for instance, I can replace TRANSPOSE8x8W as it is in store, but not in the load. [15:29] <Daemon404> [14:17] < tsieg> RiCON: btw CyanogenMod merged FFmpeg into Android: http://review.cyanogenmod.org/#/c/63444/ [15:29] <Daemon404> lul [15:30] <wm4> what is that even about [15:31] <wm4> I see something about libstagefright [15:31] <Daemon404> the message is a mess [15:33] <nevcairiel> sounds like they have a a module to use ffmpeg through libstagefright to decode all sorts of media otherwise not supported [15:33] <Daemon404> ffmpeg has libstagefright support [15:33] <wm4> I thought libstagefright was for the other way around [15:33] <Daemon404> maybe libstagefright can call ffmpeg to call libstagefright [15:33] <Daemon404> wm4, its both. [15:34] <nevcairiel> the ffmpeg module is mostly to get to the hardware decoder, isnt it [15:35] <compnn> i thought libstagefrieght called omx hw ? [15:35] <compnn> ;P [15:41] <Daemon404> we need to go deeper [15:58] <cone-419> ffmpeg.git 03Michael Niedermayer 07master:0fdc3cd86fdd: avutil/version: add FF_CONST_AVUTIL53 [15:58] <cone-419> ffmpeg.git 03Michael Niedermayer 07master:acb6f3af4fce: avutil/fifo: delay addition of const from 78d3453c4a2efef9bc079e8f3458653beafcf990 until next major ABI bump [15:58] <cone-419> ffmpeg.git 03Michael Niedermayer 07master:3690393f681d: avutil/dict: delay addition of const from e12a73246d8ce7d0fc4036522688934e26de4bb1 until next major ABI bump [16:00] <ubitux> huh, how can this cause build errors? [16:03] <michaelni> assigning function pointers and them misatching is one way [16:03] <ubitux> mmh ok [19:04] <Voicu> hello, does anyone know how to make a callback for an avio context in java? [19:05] <Voicu> I'm trying to extend avformat.Read_packet_Pointer_byte_int but I get a "invalid indirect reference" [19:05] <Voicu> when the callback gets called [19:08] <cone-419> ffmpeg.git 03batguano999 07master:434ba17b22c6: configure: add encoding to --enable-libopus doc. [20:34] <cone-419> ffmpeg.git 03Peter KováY 07master:973de9ebf879: avcodec/hevc: fix outputted AVFrame.key_frame [20:35] <nevcairiel> this can't be right, certainly there can be I frames which are not key frames [20:39] <Daemon404> yes [20:39] <Daemon404> many times actually. [20:39] <compnn> depends on codec ? [20:39] <Daemon404> types* [20:42] <muken> wtf [20:42] <nevcairiel> compnn: it clearly says which codec we're talking about, pay attention! [20:45] <compnn> bah [20:46] <compnn> like anyone has actually read the entire hevc spec :P [20:49] <Daemon404> even h264 had nonkeyframe I frames [20:51] <Paranoialmaniac> because of multiple references... [21:41] <cone-419> ffmpeg.git 03Michael Niedermayer 07master:56193d33be93: avformat/http: remove never twice executable loop [21:43] <wm4> so, an I frame which is not key frame means a frame following the I frame could have references to frames before that I frame? [21:47] <michaelni> yes [21:47] <michaelni> i should have fixed the commit message better [21:47] <michaelni> no question its not always correct after the patch [21:48] <michaelni> but before every was marked as keyframe [21:49] <wm4> but in lavf, "keyframe" should mean "you can start decoding from here" [21:51] <michaelni> yes [21:52] <Paranoialmaniac> that is a bit wrong since we mark frame with recovery point sei as a keyframe [21:52] <Daemon404> yeah, and open-gop-style h264 doesnt seek properly [21:53] <Daemon404> its been a bug for many years [21:53] <Daemon404> not that there's a "good" way to do that unless you keep an index of what references what [21:53] <Daemon404> like a d2v file does [21:54] <michaelni> "you can start decoding from here" doesnt mean that this very packet contains a fully decodeable and artifact free frame [21:55] <michaelni> so in the recovery point case theres a bit to feed into the decoder first before the first "clear" image can come out [21:56] <michaelni> also about h264, if anyone has testcases that show artifacts when seeking, iam interrested [21:56] <michaelni> ive fixed all that have been reported IIRC [21:58] <Paranoialmaniac> leading frames after a keyframe in output order are always decoded incorrectly when seeking :P [21:58] <michaelni> about hevc, just to make sure i dont misunderstand anyone, do you agree that patch was ok to apply and just not a complete solution to the keyframe value or is there some issue iam missing and i shuld revert ? [21:58] <Plorkyeran> for recovery points it'd be very helpful if lavf actually reported the recovery duration [21:59] <Plorkyeran> there's a field on the context with a comment claiming it's the recovery duration [21:59] <Plorkyeran> but it's never set [22:00] <Daemon404> is it possible to set that for PIR too? [22:00] <Paranoialmaniac> we need parse frames to get the recovery duration unless the container has it [22:00] <Daemon404> which would be all P, no? [22:00] <Plorkyeran> the recovery duration is a SEI field [22:00] <Plorkyeran> which is already parsed [22:00] <Plorkyeran> and then discarded [22:00] <Paranoialmaniac> no. the duration is not given by the sei [22:01] <Plorkyeran> sei_recovery_frame_cnt [22:02] <Plorkyeran> is the recovery duration in frames [22:02] <Paranoialmaniac> recovery point sei tells us frame_num (avc) or poc (hevc) which completes the recovery [22:02] <Paranoialmaniac> not duration [22:02] <Plorkyeran> those are equivalent if you know where you are in the stream [22:03] <Paranoialmaniac> but how do you know that without parsing [22:04] <Plorkyeran> what? [22:04] <Plorkyeran> if you have values from the sei fields then you're parsing stuff [22:05] <Paranoialmaniac> you can't know the duration until you get corresponding frame_num or poc [22:05] <michaelni> Daemon404, do you have a Hevc PIR sample ? [22:05] <Plorkyeran> that's fine [22:06] <Plorkyeran> I am okay with having to parse the entire file to be able to seek accurately in it (because that's pretty unavoidable) [22:10] <Daemon404> michaelni, i meant h264 PIR [22:14] <michaelni> hmm, yes its possible to extract the recovery frame count for h264 PIR, not the duration though without reading ahead [22:14] <Daemon404> michaelni, we (and Plorkyeran) always preindex the file [22:14] <Daemon404> just fyi [22:15] <Plorkyeran> I'm not terribly concerned about the form the data comes in [22:15] <Plorkyeran> anything vaguely sane would be useful [00:00] --- Thu May 15 2014