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

[burek]

[02:02] <cone-526> ffmpeg.git 03Lukasz Marek 07master:ffe50a92a8aa: lavc/tiff_common: add const to silent warnings
[02:02] <cone-526> ffmpeg.git 03Lukasz Marek 07master:a91d9e4b6355: lavc/ffv1enc: add const to silent warning
[02:24] <cone-526> ffmpeg.git 03Peter Ross 07master:b8664c929437: avcodec/vp8dsp: add VP7 idct and loop filter
[02:38] <michaelni> Skyler_, should i revert 23a8c63452009df21b3f184936b343593d4ccb04 (x86inc: Extend FMA_INSTR functionality) and apply "Warn about not supported emulation of some XOP instructions. Also add pmacsdql emulation." from x264 ?
[02:40] <michaelni> i think it would be best if a 5th argument, that is a temporary for emulation could be specified
[02:41] <Skyler_> yeah, that might be a better solution than both, but in that case we should move it out of x86inc and into x86util and capitalize it
[02:41] <Skyler_> because its semantics don't match the original instruction
[02:41] <Skyler_> e.g. like PALIGNR vs palignr
[02:50] <michaelni> ok, ive replied that to James Almer, maybe he will implement it (Re: [FFmpeg-devel] [PATCH 1/2] x86inc: Extend FMA_INSTR functionality)
[03:00] <J_Darnley> michaelni: I sent two updated patches to the list.
[03:00] <J_Darnley> After fixing what I think is the problem with 1of7 I had to change/merge 6of7
[03:00] <J_Darnley> And now, goodnight everyone
[04:17] <cone-526> ffmpeg.git 03Anton Khirnov 07master:f758ea6e99af: buffersink: document special error codes returned from av_buffersink_get_frame
[04:17] <cone-526> ffmpeg.git 03Anton Khirnov 07master:ba7dfe5c50b2: lavfi doxy: add buffer{src,sink}.h to the main lavfi doxy group
[04:17] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:efe4a06929a8: Merge commit 'f758ea6e99af6ebd24bbe222898a921c222e5593'
[04:17] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:baaa6d6785bc: Merge remote-tracking branch 'qatar/master'
[06:52] <cone-526> ffmpeg.git 03Michael Niedermayer 07master:d601106ab128: avcodec/x86/lossless_videodsp: fix w type
[12:32] <JEEB> hmm, was there there an easy way to picture thread intra-only encoders @ ffmpeg?
[12:32] <JEEB> IIRC some flag?
[12:40] <cone-776> ffmpeg.git 03Paul B Mahol 07master:709746b6affb: avfilter/af_compand: do not leak frames on error
[12:49] <BBB> JEEB: I believe you mark the AVCodec as intra-only
[12:49] <BBB> JEEB: see examples in allcodecs.c
[12:55] <JEEB> allcodecs.c ? that's just the general types and their registration
[12:56] <JEEB> don't see anything specific to intra there
[13:01] <Compn> what do you mean picture thread ?
[13:01] <Compn> list threaded intra-only encoder ?
[13:02] <JEEB> what's usually called 'frame threaded' :P
[13:03] <JEEB> I've just switched to the ISO/IEC way of calling a picture a picture, because it can be a field or a frame
[13:03] <Compn> oh you want to add frame threading to an encoder ?
[13:03] <JEEB> yes
[13:03] <JEEB> I hear there's a flag for intra-only things
[13:03] <JEEB> that you can just add and have it JustWork
[13:04] <Compn> is_threaded ? :P
[13:04] <Compn> i dont even know which encoders are intra only
[13:04] <Compn> so /me crawls back under his rock
[13:25] <J_Darnley> JEEB: The place that flag would be, if it exists, is in the AVCodec struct
[13:25] <JEEB> yeah
[13:25] <J_Darnley> The capabilities field which marks lossless in the flac encoder I have open
[13:26] <JEEB> I know the caps for decoders at least, but I guess I'll have to look up the struct-related info again
[13:27] <nevcairiel> JEEB: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=bb7a7111562b3c488be2ee1c41a39a913eed6497
[13:28] <nevcairiel> so basically, just set caps, make sure it works in all modes :p
[13:28] <JEEB> ah
[13:28] <JEEB> that's quite simple enough
[13:28] <JEEB> danke schön
[13:28] <nevcairiel> its a bit ugly that such codec specific checks are in frame_thread_encoder
[13:28] <nevcairiel> but i assume ut doesnt need any
[13:28] <JEEB> it shouldn't at least
[13:40] <cone-776> ffmpeg.git 03Lukasz Marek 07master:776cda748d08: lavc/motion_est: remove unused variable
[15:55] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:59279bf21fb0: avcodec/huffyuvenc: only allocate stats_out when it will be used
[15:55] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:f7459bcfc5b5: avcodec/frame_thread_encoder: restructure huffyuv checks
[15:55] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:3c7220fc605c: avcodec/frame_thread_encoder: warn about huffyuv limitations
[16:56] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:042ab7c49ee3: doc/doxy-wrapper.sh: fix execute flags
[16:56] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:ed1a6878564a: avcodec/lossless_videodsp: add_hfyu_left_prediction_int16_c: fix harmless integer overflow
[17:29] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:d46ef4012948: avcodec/fic: fix slice checks
[17:29] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:1db8bc56488c: avcodec/fic: clear slice_data
[18:51] <michaelni> ubitux, there seem to be a few fate boxes where sub2video fails
[18:51] <michaelni> iam not sure why, i tried to reproduce on one but there seems a random componet to it
[18:52] <michaelni> bisect lead to nothing usefull
[18:52] <michaelni> the issue also disappeared when i added a av_log()
[18:53] <michaelni> and didnt come back after removing the av_log () ...
[18:55] <ubitux> http://fate.ffmpeg.org/log.cgi?time=20140215165351&log=test&slot=x86_64-freebsd8.2-gcc4.4.6
[18:55] <ubitux> the diff is weird
[18:55] <ubitux> wouldn't that be related to threading btw?
[18:56] <ubitux> also, i didn't write the sub2video thing, Nicolas did
[18:58] <michaelni> ill mail nicolas
[19:01] <cone-776> ffmpeg.git 03Christophe Gisquet 07master:133b34207c2c: x86: float dsp: unroll SSE versions
[19:07] <cone-776> ffmpeg.git 03Christophe Gisquet 07master:5a48caa34b0c: dca: replace some memcpy by AV_COPY128
[20:31] <J_Darnley> Dammit git!  Where did those last three commit go?
[20:34] <JEEB> git reflog?
[20:35] <J_Darnley> Yes a quick search pointed me to that tool
[20:37] <J_Darnley> Now I need to read how to get them back
[20:37] <JEEB> depends on what exactly you want to do
[20:37] <JEEB> if you just want to 'Cancel everything I did and go back to revision asfah!!'
[20:37] <JEEB> then git reset --hard hash
[20:38] <wm4> look at the reflog, look at the commit which look like what you need, and cherry pick them
[20:38] <wm4> git reset --hard is a great way to wipe all your work
[20:38] <JEEB> and yes, you can look the history with git log hash
[20:38] <JEEB> and cherry-pick commits from it with git cherry-pick hash
[20:38] <wm4> I'd just use gitk (gitk <hash>)
[20:39] <wm4> gitk is pretty nice for getting an overview of the commit history etc.
[20:39] <J_Darnley> Ah cherry-pick sounds like what I want
[21:03] <cone-776> ffmpeg.git 03Christophe Gisquet 07master:9ae8e23188fc: dcadsp: scan coefficients linearly instead.
[21:04] <cone-776> ffmpeg.git 03James Darnley 07master:91126dc481a4: flacdsp_lpc_template: add comment to explain the CONFIG_SMALL code
[21:32] <cone-776> ffmpeg.git 03Vittorio Giovara 07master:dc971acf4aa3: h264_parser: use enum values in h264_find_frame_end()
[21:32] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:f3a862935d68: Merge remote-tracking branch 'qatar/master'
[22:02] <BBB> michaelni: you're just applying the idct patch for vp7 right, not the decoder itself
[22:03] <BBB> michaelni: the decoder needs some more work and tuning, it slows down ffvp8 quite a bit, which isn't acceptable; the idct functions are all inlined (plus the vp8 versions have simd) so their speed is unaffected, so that patch itself is fine
[22:03] <michaelni> didnt apply the decoder because of the speedloss mentioned in the therad
[22:03] <BBB> ok, cool
[22:03] <BBB> thanks
[22:03] <BBB> I think in the dsp functions the if (vp7) is inlined so it's ok
[22:03] <BBB> I didn't check 100% b/c all vp8 is x86 simd'ed anyway so it's not very relevant
[22:36] <cone-776> ffmpeg.git 03Michael Niedermayer 07master:b818637b8494: avcodec/hevc_ps: Use get_bits_long() in decode_vui()
[23:21] <ubitux> anyway idea why libav wants to export rotation metadata as... packet side data?
[23:22] <ubitux> it's injecting random side data in every packets instead of just a stream metadata (which has various benefits like being exported to ffprobe)
[23:22] <ubitux> ...unless i'm missing something
[23:23] <ubitux> it seems janne propose the metadata solution but it was rejected with "I do not think it's worthwhile adding a metadata entry too."
[23:23] <ubitux> i'm pretty concerned about the side data overhead and uselesness
[23:23] <nevcairiel> the reasoning was that it can change and stuff
[23:23] <nevcairiel> kinda silly if you ask me
[23:24] <ubitux> how can it change?
[23:24] <ubitux> it's tkhd
[23:24] <ubitux> it's parsed once
[23:24] <nevcairiel> for mov sure
[23:24] <nevcairiel> but you know, future formats!
[23:24] <ubitux> and we have frame metadata for that if needed
[23:24] <ubitux> why the hell would that be at packet level
[23:25] <ubitux> filters will never access those side data
[23:25] <ubitux> metadata has the benefit to be eventually populated up to lavfi to be rotated
[23:26] <ubitux> well i guess i'll ask for a revert of that commit if it gets merged
[23:29] <nevcairiel> the metadata approach is superior if you ask me, because I can get it right away after opening the file, and dont have to wait for the first frame to be demuxed, it works so much better in so many setups
[23:29] <ubitux> what i don't understand is that no one on libav side seems to realize how insane it is, even after several patch iterations
[23:29] <nevcairiel> (in fact it perfectly fit into my existing metadata reading function without  any troubles)
[23:30] <ubitux> and actually, the original patch was picked from ffmpeg, and then changed (NIH?) into this
[23:30] <ubitux> i don't get it
[23:31] <nevcairiel> like i said, someone complained that it could change mid-stream and the user should always get the up to date value, or something
[23:31] <ubitux> lol
[23:31] <ubitux> ok
[23:31] <nevcairiel> not that i agree, but thats what i remember reading one time
[23:32] <ubitux> was that on irc or ml?
[23:32] <nevcairiel> irc probably
[23:32] <nevcairiel> i read way less of their ml discussions
[23:35] <ubitux> ah i actually just missed a discussion about that
[23:36] <ubitux> it's indeed all about "future proof" rotation
[23:36] <ubitux> lol that's so stupid
[23:36] <ubitux> whatever
[23:40] <iive> aren't there mechanism for lavf to signal change of parameters?
[23:40] <iive> it happens a lot with dvb mpeg-ts.
[23:40] <iive> isn't...
[23:40] <ubitux> if the rotation happens to be frame specific, we could just add it in addition to the stream rotation metadata
[23:40] <ubitux> in mov you would probably have both information anyway
[23:41] <ubitux> there is really no point in trying to predict the future with insanity like this
[23:41] <iive> unneeded flexibility is the mother of all bloat.
[23:43] <cbsrobot> how can I run a specific fate test ?
[23:43] <ubitux> make fate-foobar
[23:44] <cbsrobot> thanks
[23:44] <cbsrobot> is this documented ?
[23:44] <cbsrobot> or am I blind
[23:47] <ubitux> it's easily guessable by seeing the test running i guess
[23:47] <ubitux> fate is all about make rules
[23:48] <nevcairiel> there is also make fate-list to get a list of all targets which you can grep through for example
[23:48] <cbsrobot> yeah I read that and I knew there was a way
[23:48] <cbsrobot> I just did not know how it was done
[23:48] <cbsrobot> now it's all clear
[00:00] --- Sun Feb 16 2014