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

[burek]

[02:04] <wm4> oh shit I happened to open that test file with ssa-in-avi, and it worked
[02:05] <rcombs> can we pretend it didn't
[02:08] <wm4> well I think ubitux did awesome work
[02:09] <rcombs> oh, did it work on purpose
[02:10] <rcombs> wm4: also iirc when executing SeekHeads, matroskadec explicitly ignores anything that points at another SeekHead
[02:11] <wm4> heh
[02:11] <wm4> only if it points directly
[02:11] <wm4> but not if indirectly
[02:11] <rcombs> ah, joy
[02:11] <wm4> so this check is ineffective
[02:11] <wm4> and probably breaks legitimate use cases or something
[02:11] <rcombs> my patch was pretty much just "remove that check" iirc
[02:11] <rcombs> and it worked
[02:11] <wm4> maybe it should be applied
[02:12] <rcombs> but I'm still not sure if a SeekHead loop would break shit
[02:12] <wm4> it could read elements twice
[02:45] <cone-390> ffmpeg.git 03Michael Niedermayer 07master:3393cd85459c: avcodec/utils: check AVframe.format being set in avcodec_encode_video2()
[02:45] <michaelni> funman, added a check for AVFrame.format
[02:54] <cone-390> ffmpeg.git 03Michael Niedermayer 07master:eb74839caa2c: avutil/opt: Check av_parse_color() return value
[10:28] <ubitux> wm4: it shouldn't work, the patch from nevcairiel wasn't applied... :P
[12:21] <iFire> Just wondering if it reasonable for me to write an ispc backend https://ispc.github.io/ to https://github.com/FFmpeg/FFmpeg/blob/140f535517e93409b4718b25094528d2a367737e/libavcodec/proresenc_kostya.c
[12:22] <iFire> I wonder how dependent it is on ffmpeg supplied functions.
[12:23] <ubitux> iFire: if you want to add intel SIMD, you need to write ASM directly
[12:24] <ubitux> see the x86 directory in libavcodec typically
[12:24] <iFire> well ispc is a llvm based language
[12:24] <ubitux> see libavcodec/x86/proresdsp.asm
[12:25] <iFire> ubitux: maybe I can just replace the proresdsp with ispc code
[12:25] <iFire> no idea if it'll be slower or faster though
[12:25] <ubitux> that's not a good idea
[12:26] <ubitux> from a portability and consistency PoV at least
[12:26] <iFire> well there's an opencl backend in ffmpeg...
[12:26] <iFire> ubitux: your path to proresdsp does not exist
[12:27] <ubitux> opencl is gpu related
[12:27] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/proresdsp.asm;hb=HEAD
[12:29] <iFire> apparently github truncate lengthy directories
[12:31] <iFire> ubitux: is there a c fallback to that?
[12:31] <ubitux> of course
[12:32] <iFire> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/proresdsp.c;h=82d6009b58380148e16be05b1e7a64de5738985c;hb=HEAD
[12:32] <kierank> iFire: if you are interesting in optimising you are better off writing assembly directly as ubitux says
[12:32] <ubitux> iFire: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/proresdsp_init.c;hb=HEAD here is the overrid of the functions for asm
[12:33] <iFire> off the top of your head do you know if prores_ks is multithread capable?
[12:34] <iFire> uh parallelized*
[12:35] <iFire> kierank: I guess it's probably is a waste of time trying to rewrite the code if I don't even know if its faster... but it seemed like a thought made sleep deprived.
[12:46] <kierank> Is it possible to add API based FATE tests?
[12:57] <cbsrobot_> iFire: see http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/proresenc_kostya.c;h=5f432a97cd48269abfb24a95696dfe1d51ec9f2a;hb=HEAD#l1353
[12:57] <cbsrobot_> that's line 1353 : .capabilities   = CODEC_CAP_SLICE_THREADS,
[12:58] <cbsrobot_> and prores_aw on line 620: .capabilities   = CODEC_CAP_FRAME_THREADS | CODEC_CAP_INTRA_ONLY,
[13:41] <cone-37> ffmpeg.git 03Michael Niedermayer 07master:ace91616558f: avutil/opt: Check av_parse_video_rate()s return value
[14:02] <kierank2> smarter: are you going to FOSDEM?
[14:45] <smarter> kierank: maybe
[15:12] <kierank> smarter: if you wanted to present something about vp9/hevc that would be cool
[15:14] <smarter> hmm, I'll think about it
[15:22] <ubitux> kierank: API fate test?
[15:23] <ubitux> kierank: there are all kind of -test tools
[15:23] <ubitux> which are generally used for that
[15:23] <ubitux> git grep TESTPROGS typically
[15:24] <ubitux> kierank: look at the bottom of libavutil/opt.c for a good example
[15:25] <ubitux> and make libavutil/opt-test
[15:25] <ubitux> then tests/fate/libavutil.mak for the test
[15:26] <kierank> at some point I need to write a draw_horiz band
[15:26] <kierank> test and/or example
[15:49] <cone-37> ffmpeg.git 03Clément BSsch 07master:6153aa2d1e41: avcodec/jacosubdec: check strftime return value
[16:38] <kierank> BBB: do you know if the chroma 422 asm deblock functions are hard to write?
[17:48] <cone-37> ffmpeg.git 03Daniel Moran 07master:0ae37e460c34: avdevice/xcbgrab: Fix show_region rectangle
[17:48] <cone-37> ffmpeg.git 03Michael Niedermayer 07master:df6cdb23f00b: avcodec/utils: Check AVFrame width/height in avcodec_encode_video2()
[18:52] <BBB> kierank: for what codec? h264?
[18:52] <kierank> yes, h264
[18:53] <BBB> it depdsn on how you define hard
[18:53] <BBB> you need a certain skillset to write good assembly
[18:53] <BBB> most people dont have that skillset, even very talented engineers who are great at R or java or python
[18:53] <BBB> if youre good at assembly, I dont think its particularly specially difficult
[18:54] <kierank> I was asking more about whether the existing functions could be extended or if new ones would need to be written
[18:54] <BBB> right, I figured it was more applied
[18:54] <BBB> I would guess the existing ones can mostly be reused
[18:54] <kierank> I have to go now but I don't quite understand how the asm maps to the c
[18:54] <kierank> but I will ask in the coming days
[18:54] <BBB> they would be new functions ina  binary, but could probably mostly reuse existing macros, possibly with some additions to the macros
[18:55] <BBB> ok
[20:18] <cone-37> ffmpeg.git 03Michael Niedermayer 07master:e65849a70bfb: avformat/dashenc: make durations 64bit
[20:53] <cone-37> ffmpeg.git 03Michael Niedermayer 07master:b1c8dfc84eb0: doc/filters: Add ascii graphics to clarify what the currently implemented tinterlace modes do
[22:55] <cone-37> ffmpeg.git 03wm4 07master:6551acab6877: avformat/matroskadec: fix handling of recursive SeekHead elements
[22:56] <cone-37> ffmpeg.git 03Michael Niedermayer 07master:72c984432ecc: avformat/matroskadec: request a sample with recursive seek heads
[22:57] <rcombs> \o/
[22:59] <rcombs> wait a sec michaelni I have a sample
[23:01] <rcombs> is that asking for any file with seekheads at the end?
[23:01] <rcombs> (and a seekhead at the beginning pointing at the ones at the end)
[23:02] <wm4> matroska folks say that the standard _maybe_ doesn't require implementations to handle such seekheads
[23:03] <wm4> (yeah, no clear answer)
[23:03] <rcombs> https://www.dropbox.com/s/32ve4hp567ukikt/Maken-Ki%21%20-%20S01E02.mkv?dl=0 wm4 michaelni a sample a user submitted to me
[23:04] <wm4> rcombs: I'll take a look later
[23:04] <rcombs> cool
[23:35] <pross> opw admisions closed right? /topic somebody
[23:39] <cehoyos> pross: Feel free to change it.
[23:40] <cehoyos> michaelni: Is it ok for an input mjpeg sample to show [SAR 100:100 DAR 4:3] or should it be [SAR 1:1 DAR 4:3] ?
[23:44] <michaelni> cehoyos, does it cause a problem ? i guess the mjpeg simply stores 100:100
[23:46] <cehoyos> My question was: Do we require the input value to be reduced? I thought so but the console output in ticket 4163 shows that the output sar is always 1:1.
[23:47] <cehoyos> 100:100 has the advantage that an application could read it as resolution in dpi...
[23:51] <kierank> cehoyos: h264 requires a reduced value in many cases
[23:52] <nevcairiel> it might reduce it internally then, though
[23:54] <cehoyos> FFmpeg does reduce the aspect before sending to libx264, the question is if it is ok to store an unreduced input aspect ratio. But I believe it is even intended.
[23:56] <iive> imho, ratios should be reduced
[23:56] <iive> or they won't be ratios.
[23:57] <iive> using it for different purpose (dpi) is... bad hack.
[23:58] <cehoyos> For mjpeg, only resolutions are stored.
[00:00] --- Mon Dec  8 2014