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

[burek]

[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