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

[burek]

[00:28] <BBB> plepere: x86/vp9dsp_init.c
[00:29] <BBB> plepere: top of the file
[02:20] <cone-645> ffmpeg.git 03James Almer 07master:7fd64e3e36f7: x86/synth_filter: add synth_filter_fma3
[03:01] <cone-645> ffmpeg.git 03Marton Balint 07master:d08bb065f2ac: mpegts: use goto out instead of break on truncated or invalid pmt tables
[03:54] <cone-645> ffmpeg.git 03Michael Niedermayer 07release/1.2:5e01cd3b697e: dnxhdenc: fix mb_rc size
[03:54] <cone-645> ffmpeg.git 03Michael Niedermayer 07release/1.2:e925fd215f9f: avcodec/vmnc: Check  that rectangles are within the picture
[03:54] <cone-645> ffmpeg.git 03Michael Niedermayer 07release/1.2:ca9d302519b6: avcodec/takdec: always check bits_per_raw_sample
[03:54] <cone-645> ffmpeg.git 03Michael Niedermayer 07release/1.2:b3cc4bd18f3c: avcodec/vc1: reset fcm/field_mode in non advanced header parsing
[03:54] <cone-645> ffmpeg.git 03Justin Ruggles 07release/1.2:bb683ebdba9b: samplefmt: avoid integer overflow in av_samples_get_buffer_size()
[03:54] <cone-645> ffmpeg.git 03Michael Niedermayer 07release/1.2:11b14d0e63f8: avcodec/wmalosslessdec: fix mclms_coeffs* array size
[03:54] <cone-645> ffmpeg.git 03Michael Niedermayer 07release/1.2:a57d29a50c7a: avformat/mpegtsenc: Check data array size in mpegts_write_pmt()
[03:54] <cone-645> ffmpeg.git 03Michael Niedermayer 07release/1.2:ab31a9ee4af5: avcodec/msrle: use av_image_get_linesize() to calculate the linesize
[03:54] <cone-645> ffmpeg.git 03Michael Niedermayer 07release/1.2:9085cdd67799: avcodec/ansi: fix integer overflow
[03:54] <cone-645> ffmpeg.git 03Michael Niedermayer 07release/1.2:b580bae53ac7: avcodec/snow: split block clipping checks
[03:55] <cone-645> ffmpeg.git 03Michael Niedermayer 07release/1.2:ddcccababe34: avcodec/utvideoenc: fix slice_bits size
[04:02] <cone-645> ffmpeg.git 03Michael Niedermayer 07release/1.2:e63346f7e8d3: update for 1.2.6
[04:25] <cone-645> ffmpeg.git 03Marton Balint 07fatal: ambiguous argument 'refs/tags/n1.2.6': unknown revision or path not in the working tree.
[04:25] <cone-645> Use '--' to separate paths from revisions
[04:25] <cone-645> refs/tags/n1.2.6:HEAD: mpegts: use goto out instead of break on truncated or invalid pmt tables
[07:48] <ubitux> > First of all: where is VP9? There isnt. Why? Because after a whole week it still didnt finish encoding.
[07:48] <ubitux> heh.
[07:49] <wm4> does ffmpeg plan to add a vp9 encoder?
[07:49] <wm4> or is that left to google
[07:49] <ubitux> an encoder is a lot of work
[07:49] <ubitux> a lot of /continuous/ work
[07:51] <ubitux> not sure we have enough manpower for that
[12:06] <ubitux> funman: i don't understand why don't you change the check in configure.ac by not using pkg config?
[12:07] <ubitux> like making two different requirements
[12:07] <funman> ubitux: go for it
[12:07] <ubitux> funman: also, isn't the requirement for avcodec pretty high?
[12:07] <ubitux> i mean, is there any libav release with those versions?
[12:08] <funman> i doubt it
[12:08] <funman>   PKG_CHECK_MODULES(AVCODEC,[libavcodec >= 53.34.0 libavutil >= 51.22.0], [
[12:08] <ubitux> mmh in that case
[12:08] <ubitux> how can that compile with libav?
[12:08] <funman> ?
[12:09] <ubitux> 53.34.0 had that vdpau code?
[12:09] <funman> no
[12:09] Action: wm4 wonders when there will be finally different pkg-config versions for libav and ffmpeg
[12:09] <funman> vdpau has higher requireemnts yes
[12:09] <funman>   PKG_CHECK_EXISTS([libavutil >= 0.52.4 libavcodec >= 55.26.0], [
[12:09] <ubitux> ah indeed that's below, ok
[12:11] <ubitux> funman: is that important to have it in 2.1.x?
[12:12] <ubitux> (it was "working" previously?)
[12:13] <funman> ?
[12:14] <ubitux> funman: i mean, if you disable the check properly (by that i mean you add the appropriate version check for ffmpeg in configure), it will disable that vdpau code for 2.1.x
[12:14] <ubitux> would that be ok?
[12:14] <funman> is the current code not OK ?
[12:15] <ubitux> what do you mean by current code? the code you imported from recent versions?
[12:15] <ubitux> i'm just wondering if it's more important to have the feature+hackfix vs nofeature+properfix
[12:18] <funman> i think it's not important at all
[12:18] <funman> lot of fuss for nothing
[12:48] <Keestu> dear all,  i am build ffmpeg in android, when i use --enable-pthreads, looks like it is unable to lik pthread_cancel .
[12:49] <Keestu> i m using android ndk  r9b 
[13:15] <plepere> I hope that this time my code is good enough so I can go on something else. :p
[13:25] <plepere> hey BBB, my body is ready for your critics.
[13:25] <kurosu_> plepere: have you setup the START/STOP_TIMER macros to see how the changes are helping?
[13:26] <kurosu_> Maybe it is less important now, but I suspect the initial round helped
[13:26] <plepere> kurosu_, no, I'm going to see how that works. :) you've written a little thing about it in a reply IIRC.
[13:27] <kurosu_> yeah, I think it really helps keeping motivation, and it also helps justifying your own choices and/our reject parts of reviews :D
[13:27] <kurosu_> *and/or
[13:27] <plepere> ok
[13:28] <kurosu_> but as I said, it may be small timing changes now
[13:29] <plepere> I'm going to try it now, so I know how to use it another time
[13:30] <ubitux> START_TIMER\n//code...\nSTOP_TIMER("generally_the_func_name_ssse3_but_anything_is_fine")
[13:30] <ubitux> then ffmpeg -threads 1 -i ... -f null -
[13:30] <kurosu_> plepere: btw, are you ever using m10/m9 (m10 might, depending on parameters, not sure)
[13:31] <plepere> kurosu_, I'm using this logic : m0 -> m7 is input, m15 -> m11 are filters
[13:32] <plepere> in 4-tap I use less registers
[13:32] <plepere> unless it's hv.
[13:32] <kurosu_> ok anyway the reg count seems ok, so probably x264asm is smart enough to know how to allocate them
[13:33] <kurosu_> it's just that if m9/m10 are unused it's less regs used to declare
[13:34] <BBB> plepere: lol
[13:34] <plepere> I think I'm never declaring the m registers correctly in the cglobal...
[13:34] <BBB> I'm still reviewing the actual functions
[13:34] <BBB> it gets a little more fuzzy at this point because it's just so much code
[13:34] <BBB> but anyway
[13:34] <kurosu_> plepere: it's minor declaring more (useless backing and restoring) but less could crash
[13:35] <kurosu_> (not minor if you don't want to avoid loosing a few cycles for nothing)
[13:35] <BBB> why does hevc_put_hevc_epel_hv2_8 use PEL_STORE6?
[13:35] <BBB> I'm so confused
[13:36] <plepere> errr, it shouldn't
[13:36] <plepere> it's in hevc_put_hevc_epel_hv%1_%2 which calls     PEL_STORE%1      dst, m0, m1
[13:42] <plepere> damn, I messed-up my patches. :/
[13:44] <cone-536> ffmpeg.git 03Rémi Denis-Courmont 07master:eeaf4f3b8781: av_vdpau_get_profile: mask out H.264 intra profile flag
[13:44] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:a44a27b5c817: Merge commit 'eeaf4f3b87815cbae4c12856cfaafb3a2dae8e0c'
[13:45] <plepere> ok, the timers work. :)
[13:45] <plepere> it's a nice thing to know
[13:46] <nevcairiel> the timer macros are really a easy way to benchmark :)
[13:46] <plepere> I'll use that to bench ASM vs intrinsics. :D
[13:47] <kurosu_> the timers can have side effect, but really, like nevcairiel said; I can't imagine applying small changes without this to confirm
[13:49] <plepere> well I really want the current code to be validated so I can try to do qpel hv in asm and how to make the mc + weighted done together.
[13:51] <kurosu_> yeah, you might actually need to undo things :)
[13:51] <cone-536> ffmpeg.git 03Reinhard Tartler 07master:5ddc9f505231: configure: enable PIC on s390(x)
[13:51] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:5abbeefd5e64: Merge commit '5ddc9f5052316608799b932c604f9e7561f8ce24'
[13:51] <kurosu_> anyway, with those macrofests, I usually end up decompiling just to try and spot stupid things
[13:55] <cone-536> ffmpeg.git 03Luca Barbato 07master:e995cf1bccc6: avfilter: Add missing emms_c when needed
[13:55] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:e3c93f1f84a3: Merge remote-tracking branch 'qatar/master'
[13:56] <plepere> yes, I might undo things, but having this batch of code validated would be a good base to start from.
[13:57] <plepere> kuro : what editor do you use to extend the ASM macros ?
[13:58] <BBB> gdb
[13:58] <BBB> in gdb prompt, run disass functionname
[13:59] <plepere> ok. nice
[14:00] <kurosu_> I have this in my ~/.gdbinit
[14:00] <kurosu_> display/i $pc define da disass $pc-32,$pc+32 end
[14:00] <kurosu_> arg, didn't keep the eols
[14:01] <plepere> BBB. I messed up. You need to fuse the 2 patches to see the good asm. :/
[14:02] <plepere> I see your mail about loop_init whih is gone.
[14:14] <ubitux> wm4: i can't reproduce the seek issue
[14:14] <ubitux> wm4: i tried -ss 10 -c copy -y out.ogg, works the same
[14:15] <ubitux> more text flood though
[14:16] <wm4> try with ffplay
[14:16] <ubitux> i see a problem with ffplay indeed
[14:16] <wm4> probably depends on the seek flags
[14:16] <ubitux> i guess you can reproduce with mpv?
[14:16] <ubitux> (aka not ffplay specific)
[14:16] <wm4> yes, it was reported by a mpv userr
[14:17] <ubitux> ok
[14:18] <ubitux> wm4: please at least provide a command to reproduce next time
[14:18] <ubitux> i know you just want to provoke carl but well... :)
[14:18] <wm4> "ffplay file.ogg"
[14:18] <wm4> then click with mouse somewhere
[14:19] <wm4> that was hard
[14:19] <ubitux> you should have mentioned it, it wasn't obvious
[14:20] <wm4> I didn't expect anyone to test seeking with ffmpeg.c
[14:20] <BBB> plepere: can you resend one single asm patch instead of several? it's hard to know what to do with so many
[14:20] <wm4> but yes, it's true that I might have been more detailed if cehoyos didn't own the bug tracker
[14:20] <BBB> anyway
[14:20] <BBB> I'll first finish qpel review then I'll start back at the beginning
[14:22] <BBB> hm i'll skip qpel
[14:22] <BBB> it's identical to epel
[14:22] <BBB> so same comments
[14:22] <BBB> ok I'll wait for new patch and re-review
[14:22] <BBB> enjoy the comments so far, hope they help
[14:30] <plepere> yes, they help quite a bit.
[14:30] <cone-536> ffmpeg.git 03Christophe Gisquet 07master:93c4cd618cd2: ra144enc: fix use of scalarprod_int16
[14:30] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:100e8f8b67b4: avcodec/ra144enc: avoid calling emms when the SSE2 version is used
[14:30] <plepere> I'm trying to make a C wrapper for high width
[16:11] <cone-536> ffmpeg.git 03Jason Hsu 07master:8fb4dba89d7b: doc/examples/remuxing: dont use the input codec_tag, it may be invalid tor the output
[16:24] <plepere> 860 lines left in my ASM. :)
[16:53] <nevcairiel> :)
[17:31] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:12b97dd37573: avformat/oggparsevorbis: dont use invalid granules
[17:37] <wm4> <3
[19:03] <ubitux> michaelni: we should update APIChanges with our versions more often
[19:03] <ubitux> courmisch is complaining about that
[19:04] <wm4> yeah I found that pretty useful when I found out about that
[19:04] <wm4> but then I saw only Libav did this properly
[19:05] <wm4> (marking releases in the file)
[19:06] <ubitux> michaelni: ideally when libav update the file, we should do the same with our version 
[19:07] <ubitux> since you actually have to merge the version, the APIChanges should be updated as well
[19:08] <ubitux> don't we have a script btw?
[19:08] <michaelni> my script only works if the entry contains a git hash
[19:08] <michaelni> libav omits these hashes often
[19:10] <michaelni> ubitux, also speaking of ommited hashes, there are plenty ommited ones for .100 versions
[19:13] <michaelni> ubitux, just tried my script, but it found no new entries that have just a libav git hash
[19:13] <ubitux> ok
[19:13] <ubitux> then what about updating the APIChanges files when you get a version.h conflict?
[19:14] <ubitux> (if there is a conflict it's probably bumped and documented in the APIChanges)
[19:14] <ubitux> it should be too much trouble
[19:14] <ubitux> because the versions we are documenting currently are wrong
[19:14] <ubitux> that's not very cool for users
[19:15] <ubitux> (wrong in the sense that they don't match the one in the project)
[19:16] <michaelni> i should update them when theres a conflict, lets see if i forget next time theres one
[19:17] <ubitux> thank you
[19:17] <ubitux> i suppose courmisch is trying to get the version for ffmpeg' vdpau introduction
[19:18] <ubitux> and so he's rage-complaining, which i can understand
[19:59] <JEEB> Skyler_, you might want to chime in on the 8x8 lossless decoding patch on the ML before anyone pushes it in case it's the thing that breaks x264's 8x8dct in lossless (which was written when JM and the spec were less working)
[19:59] <JEEB> didn't check the patch myself yet, but 1) fixes lossless to match JM and 2) 8x8 remind me of that
[20:01] <JEEB> http://ffmpeg.org/pipermail/ffmpeg-devel/2014-March/155228.html
[20:02] <Skyler_> I'm not subscribed to the ML
[20:02] <Skyler_> how do I reply
[20:02] <Skyler_> and yes, that is the thing that breaks it
[20:03] <J_Darnley> I think you can click on the sender link at the top of the page
[20:03] <Skyler_> that will break lossless decoding on all historical x264 lossless files
[20:03] <nevcairiel> maybe it shouldn't have created out of spec files then :D
[20:04] <nevcairiel> i suppose someone could come up with a hack to support both versions and detect x264 encodes
[20:04] <JEEB> the problem was that IIRC the spec was vague and JM didn't work back then
[20:04] <JEEB> and then it was like a couple of years later when it was found out
[20:05] <JEEB> and the only implementations of the lossless profile already had done it the x264 way
[20:05] <Skyler_> yeah, x264 was literally the first encoder to implement the lossless profile fully
[20:05] <Skyler_> as far as I know
[20:05] <Skyler_> JM's implementation was bugged and incomplete
[20:05] <Skyler_> so it was impossible to verify that x264's interpretation of the spec was correct
[20:08] <JEEB> but yeah, it'd be nice of course if it was possible to make both types decode nicely
[20:08] <JEEB> but not sure what kind of hacks that'd take .-.
[20:11] <nevcairiel> not sure if there arent any encoder version shims already in the code
[20:11] <nevcairiel> there is h->x264_build
[20:12] <nevcairiel> where it parses the sei that x264 puts into the stream
[20:12] <nevcairiel> could duplicate the implementation and switch based on that
[20:13] <nevcairiel> I dont suppose there are plans to fix x264?
[20:13] <Skyler_> "fixing" x264 breaks compatibility with the decoders
[20:13] <Skyler_> it's a catch-22
[20:14] <nevcairiel> spec compliance is worth it if you ask me
[20:18] <saigono> Greetings! Question about developing muxer/demuxer should be asked here or on #ffmpeg? 
[20:18] <nevcairiel> didn't someone suggest once to simply stop encoding the 8x8 thingys in lossless mode to workaround the issue  :D
[20:18] <JEEB> saigono, developing stuff within libavformat itself would be here
[20:18] <JEEB> nevcairiel, yeah
[20:18] <JEEB> not using 8x8dct should fix it
[20:18] <Skyler_> I guess I could accept a patch for that, really
[20:19] <Skyler_> I guess I'm a little embarrassed I botched it the first time :p
[20:19] <Skyler_> and iirc the "correct" version has worse compression
[20:19] <Skyler_> (albeit totally marginal)
[20:22] <saigono> So, I got a question %) What value should I return in 'read_packet' if i know, that current packet is the last one in file?
[20:50] <Compn> saigono : can ask here if its for ffmpeg :)
[20:51] <saigono> Compn: already asked :)
[21:17] <michaelni> ubitux, see ML for a APIChanges with more versions & hashes filled in
[21:19] <nevcairiel> saigono: if its still a valid packet, you dont return anything special. the next call would then return eof
[21:26] <ubitux> michaelni: will look, thanks
[21:34] <cone-536> ffmpeg.git 03Diego Biurrun 07master:3741aa37c2a0: x86: cabac: Use correct #includes to make header compile standalone
[21:34] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:146b476ba0c9: Merge commit '3741aa37c2a0d0717faff74a5c4cc357d16f6d1d'
[21:38] <michaelni> ubitux, btw, which APIChanges entries exactly where needed / missing about VDPAU ?
[21:40] <ubitux> 2013-11-14 - 31c09b7 / 728c465 - lavc 55.26.0 - vdpau.h
[21:40] <ubitux> this entry
[21:40] <ubitux> but it's fine for now, courmisch fixed all of that properly in vlc
[21:58] <cone-536> ffmpeg.git 03Janne Grunau 07master:cbddee1cca0e: arm: hpeldsp: prevent overreads in armv6 asm
[21:58] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:a74bab7079d7: Merge remote-tracking branch 'qatar/master'
[22:19] <cone-536> ffmpeg.git 03Michael Niedermayer 07master:91550f46cd3f: doc/APIchanges: fill in missing version for "2013-11-14 - 31c09b7 / 728c465 - lavc 55.26.0 - vdpau.h"
[22:49] <cone-536> ffmpeg.git 03Andrey Myznikov 07master:9deecdf85f0c: Fix pthread-related compile errors in iec61883.c
[22:55] <ubitux> michaelni: mmh why does libav' libavutil have a major > to our?
[22:55] <ubitux> what magic is this?
[22:55] <j-b> magic
[22:55] <ubitux> did we avoid breaking the api/abi somehow?
[23:02] <michaelni> yes
[23:02] <michaelni> see libavutil/lls*
[23:03] <ubitux> ah the lls thing, i remember now
[23:06] <ubitux> ill have a closer look to the apichanges diff, feel free to push now if you can't wait
[23:06] <ubitux> 'night
[23:06] <michaelni> ubitux, night, sleep well
[00:00] --- Thu Mar  6 2014