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

[burek]

[02:02] <ubitux> http://blog.lse.epita.fr/articles/38-emulating-the-gamecube-audio-processing-in-dolphin.html
[02:13] <highgod> Hi,I submit a patch to community, how can I know it has been processed?Thanks, I never submited before.
[02:26] <Compn> did you submit it via ffmpeg-devel mailing list or ffmpeg trac ?
[02:27] <highgod> ffmpeg-devel
[02:27] <Compn> it showed up on the list ?
[02:27] <highgod> ffmpeg-devel at ffmpeg.org
[02:27] <Compn> i mean, whats the subject ?
[02:28] <highgod> [FFmpeg-devel][PATCH] add code to make ffmpeg.exe can use dxva2 api
[02:28] <Compn> ok i see it :)
[02:29] <highgod> Thanks, if there are any problems, let me know, we will try to fix it thanks a lot @Compn
[02:30] <Compn> highgod : well i am not a programmer so i cant review it :)
[02:30] <Compn> did you run the ffmpeg patcheck script on it yet?
[02:32] <Daemon404> hey michaelni, when you merge the latest batch of libav commits, you need up update a file in the fate rsync repo too (they fixed one sample, kept the same name)
[02:32] <Daemon404> just a heads up
[02:33] <highgod> patcheck?where can I get it?
[02:33] <Daemon404> highgod, tools dir in ffmpeg repo
[02:38] <highgod> OK,I will check it, thanks
[02:40] <wm4> highgod: is this code taken from VLC?
[02:40] <Daemon404> it looks kinda hacky
[02:40] <Daemon404> like putting dxva specific stuff in pthreads.c
[02:40] <Daemon404> seems very wrong
[02:41] <wm4> vadxva2.c seems derived from VLC modules/codec/avcodec/dxva2.c
[02:41] <highgod> yes
[02:42] <highgod> I codes in pthreads.c,I want to make h264 decode faster
[02:43] <wm4> reminds me of the VDA mplayer hack (libavcodec/vda_h264.c)
[02:46] <highgod> If use the main thread to decode h264,it is slower than do it in this way.it is like the pre-h264 thread method I think.Also it improve the decode speed
[02:52] <cone-445> ffmpeg.git 03Michael Niedermayer 07master:56d09250ef44: nuv: dont try to copy an empty frame
[02:52] <cone-445> ffmpeg.git 03Michael Niedermayer 07master:a974adc3c78c: g729dec: check pitch_delay_int.
[02:52] <cone-445> ffmpeg.git 03Michael Niedermayer 07master:a286b04dafc4: configure/arm: print if thumb mode is enabled
[02:53] <llogan> highgod: please be patient for a review.
[02:55] <highgod> OK
[02:55] <highgod> Thanks
[03:47] <Daemon404> hmm
[03:47] <Daemon404> bb-netbsd$ ../ffmpeg/configure --enable-gpl --disable-neon --disable-armv6 --arch=armv5te --optflags=-O2 --samples=/home/daemon404/ff_fate --cc="ccache gcc"
[03:47] <Daemon404> this is getting an empty -mcpu= param
[03:48] <Daemon404> ccache gcc -mcpu= -E -o /tmp/ffconf.001326aa.o /tmp/ffconf.001404aa.c
[03:48] <Daemon404> cc1: error: missing argument to "-mcpu="
[03:49] <Daemon404> suppose i should use --cpu
[03:49] <Daemon404> not that i think it should be possible for configure to use an empty cpu string
[05:01] <cone-445> ffmpeg.git 03Michael Niedermayer 07master:ceb9f8d9271f: audioconvert: support simd code with specific alignment requirements.
[05:01] <cone-445> ffmpeg.git 03Michael Niedermayer 07master:d18706244f0c: audioconvert/arm: require alignment of 16
[06:01] <cone-445> ffmpeg.git 03Michael Niedermayer 07master:58f30175e1ed: mem: minor simplification of the alignment hack code
[06:16] <Zeranoe> So if FDK aac is nonfree, would I be breaking FFmpeg's license if I compiled with FDK and released the binaries with the FDK license along with it?
[06:47] <cone-445> ffmpeg.git 03Peter Ross 07master:5c78a8129c4b: sauce: test filetype correctly for datatype 5 (binary text)
[08:00] <nevcairiel> Zeranoe: as soon as you compile with --enable-nonfree you cannot distribute the binary anymore
[08:02] <juanmabc> could that be on countries where software patents apply only?
[08:03] <nevcairiel> this is about copyright, not patents
[08:03] <juanmabc> just wondering how extra distros repos package that
[08:05] <Zeranoe> nevcairiel: Thats unfortunate because a lot of my users are asking for FDK aac... 
[08:06] <nevcairiel> tell them to build it themself
[08:07] <Zeranoe> I guess thats always an option?
[11:04] <pross-au> anyone: what is 'hcscale()' in libswscale/swscale.c. why is it used?!
[11:34] <cbsrobot> Tjoppen: ping
[11:36] <cbsrobot> the duration and bitrate seem to be wrong for a op1a mxf with 5.1 pcm_s24le 48kHz file
[11:39] <wm4> pross-au: as fart as I know, the only persons who really know about swscale are michaelni, and BBB (found on #libav-devel)
[11:39] <wm4> oh I made a funny typo
[11:39] Action: wm4 goes hide in a corner
[11:41] <burek> :)
[11:45] <cbsrobot> Tjoppen ^
[12:25] <pross-au> wm4: for your sake, i hope that corner is well ventilated 
[12:25] <pross-au> thx
[13:27] <michaelni> pross-au, hcscale() is horizontal chroma scale
[13:47] <michaelni> Daemon404, updating the fate sample would break ffmpeg 1.0 "make fate" with enabled avr also masters fate-filter-asyncts does not pass pre merge
[13:48] <michaelni> is there some volunteer who wants to maintain asyncts in ffmpeg ?
[13:56] <cone-364> ffmpeg.git 03Luca Barbato 07master:be75fed9755c: vp6: properly fail on unsupported feature
[13:56] <cone-364> ffmpeg.git 03Justin Ruggles 07master:f266486b2e71: asyncts: fix flushing of final samples at EOF
[13:56] <cone-364> ffmpeg.git 03Justin Ruggles 07master:8083332c2de9: asyncts: use clipped delta value when setting resample compensation
[13:56] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:593f5c0f3c55: Merge commit '8083332c2de9ee189f96844ff4c2d9be1844116f'
[14:03] <cone-364> ffmpeg.git 03Justin Ruggles 07master:c143de40c3bf: asyncts: fix the asyncts behavior when using the first_pts option
[14:03] <cone-364> ffmpeg.git 03Justin Ruggles 07master:b35e5d985dd1: doc: improve documentation for the asyncts filter first_pts option
[14:03] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:b6e7041f90da: Merge commit 'b35e5d985dd12acf9a0aaa52334134edcf35d68e'
[14:36] <Tjoppen> cbsrobot: works in c581cb4
[15:21] <cone-364> ffmpeg.git 03Justin Ruggles 07master:0ee440fe38e2: asyncts: cosmetics: reindent
[15:21] <cone-364> ffmpeg.git 03Janne Grunau 07master:072be3e8969f: h264: set parameters from SPS whenever it changes
[15:21] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:b9d887c22546: Merge commit '072be3e8969f24113d599444be4d6a0ed04a6602'
[15:23] <Tjoppen> unsurprisingly the bisect seems to point to the recent audio pts patch as being the culprit of that ticket
[15:26] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:3b5c0f5e362f: h264: remove low_delay/has_b_frame setting code from nal loop
[15:32] <cbsrobot> Tjoppen: which commit
[15:34] <cone-364> ffmpeg.git 03Janne Grunau 07master:bd255f9feb4d: lavc: set frame parameters after decoding only if necessary
[15:34] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:86b4dc627769: Merge commit 'bd255f9feb4deea4c990e582f0ba3b90d7b64b4c'
[15:38] <Tjoppen> cbsrobot: 83cab07
[15:38] <Tjoppen> I just authored a fix
[15:38] <cbsrobot> saw it thanks
[15:38] <cbsrobot> ah cool
[15:38] <cbsrobot> thanks once more
[15:42] <cone-364> ffmpeg.git 03Janne Grunau 07master:6a27ae28f9bd: mpegvideo: treat delayed pictures as used
[15:42] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:2f265d908736: Merge commit '6a27ae28f9bde981e85c82cf5bf42c5f43fb6f13'
[15:42] <Tjoppen> patch sent to ML
[15:50] <cone-364> ffmpeg.git 03Janne Grunau 07master:0eae920c3c49: h264: initialize frame-mt context copies properly
[15:50] <cone-364> ffmpeg.git 03Janne Grunau 07master:0995ad8db4bc: x86inc: fully concatenate tokens to fix macro expansion for nasm
[15:50] <cone-364> ffmpeg.git 03Justin Ruggles 07master:c0dc57f1264d: asyncts: merge two conditions
[15:50] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:a01fe55077d9: Merge commit 'c0dc57f1264dad1e121772d03abdb9e14ed8857f'
[15:57] <cone-364> ffmpeg.git 03Justin Ruggles 07master:4e5a8878d583: asyncts: ignore min_delta only if first_pts is set
[15:57] <cone-364> ffmpeg.git 03Anton Khirnov 07master:8ab42021f253: ivi_common: make some functions and tables static.
[15:57] <cone-364> ffmpeg.git 03Anton Khirnov 07master:07acdd651d1e: ivi_common: use proper logging context in ivi_decode_blocks().
[15:57] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:be26232efa95: Merge commit '07acdd651d1e2f4cfa5f610e616e70e323bb69cd'
[16:05] <cone-364> ffmpeg.git 03Anton Khirnov 07master:deabb52ab4c1: ivi_common: check that scan pattern is set before using it.
[16:05] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:3c5c6b9d6136: Merge remote-tracking branch 'qatar/master'
[16:47] <Daemon404> michaelni, the "merge conflict" was A -> A|F
[16:55] <Daemon404> michaelni, if someone really needs to 
[16:56] <Daemon404> i can watch af_asyncts for merge mess-ups
[16:56] <Daemon404> otehr than that, i do not think it needs an "ffmpeg maintainer"
[17:05] <michaelni> Daemon404, fate-filter-asyncts fails with old and new files pre and post merge
[17:05] <Daemon404> it should not fail on the new file
[17:05] <michaelni> it does
[17:05] <michaelni> stddev:  313.97 PSNR: 46.39 MAXDIFF: 8978 bytes:   654352/   654326
[17:06] <Daemon404> let me grab the new file
[17:06] <michaelni> also i think none of our fate boxes tests it
[17:07] <Daemon404> i can add one
[17:07] <Daemon404> i use ffmpeg + asyncts
[17:07] <Daemon404> it's in my best interests to make sure it works
[17:11] <Daemon404> also still trying to get some tilera hardware
[17:11] <Daemon404> they arent very good at responding to emails
[17:17] <Daemon404> michaelni, hmm looks like the internal apis for lavfis work differently
[17:20] <Daemon404> yup.. therei think disocntinuities ight be handled diff
[17:21] <Daemon404> 26 bytes of extra silence mid-file
[17:22] <Daemon404> ubitux, any idea?
[17:26] <michaelni> libavformat/vocdec.c:160: internal compiler error: output_operand: invalid expression as operand
[17:27] <ubitux> Daemon404: nope, no idea sorry
[17:27] <Daemon404> :/
[17:31] <Daemon404> yup
[17:31] <Daemon404> [Parsed_asyncts_0 @ 0x292c7e0] Discontinuity - 82683 samples.
[17:31] <Daemon404> ^ ffmpeg output
[17:31] <Daemon404> [asyncts @ 0x23e1820] Discontinuity - -35 samples.
[17:31] <Daemon404> [asyncts @ 0x23e1820] Discontinuity - 82696 samples.
[17:31] <Daemon404> ^ avconv output
[17:32] <Daemon404> delta is ended up different
[17:33] <Daemon404> maybe the demuxer is producing diff pts
[17:35] <Daemon404> er, lemme pull libav and retest
[17:36] <Daemon404> yeah the -35 is gone after a pull of the fix
[17:36] <Daemon404> but i found the read difference now
[18:05] <Daemon404> ubitux && michaelni -- the flv demuxer is producing different pts
[18:06] <Daemon404> the filter itself is working as expected
[18:08] <Daemon404> $ diff -ur ../libav/libavformat/flvdec.c libavformat/flvdec.c | diffstat flvdec.c |  235 +++++++++++++++++++++++++++++++++++---------------------------- 1 file changed, 132 insertions(+), 103 deletions(-)
[18:08] <Daemon404> this looks fun :<
[18:13] <ubitux> :)
[18:13] <ubitux> could even be in lavf/utils!
[18:14] <Daemon404> yeah
[18:14] <Daemon404> but in any case
[18:14] <Daemon404> the filter itself is OK
[18:14] <Daemon404> what do you recommend to do about the fate test
[18:14] <Daemon404> new sample to cmp in fate rsync?
[18:16] <ubitux> i didn't follow, what's the issue?
[18:16] <ubitux> just make a different ref data?
[18:17] <Daemon404> the ref data in fate (.pcm file) is different
[18:17] <Daemon404> due to different pts
[18:17] <Daemon404> the ref on the rsync server
[18:18] <ubitux> the ref is in fate-suite? oO
[18:18] <ubitux> no idea, see with michael :p
[18:18] <Daemon404> and ive confirmed it isnt flvdec.c's fault
[18:18] <ubitux> are the pts better?
[18:18] <Daemon404> "better" ?
[18:18] <ubitux> more accurate? :p
[18:19] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:b2c2589ecf87: westwood_vqa: fix null pointer dereference
[18:19] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:6ca246555683: ass_split_section: dont overread array
[18:19] <Daemon404> how on earth would i even check that :)
[18:19] <ubitux> i have no idea :D
[18:19] <Daemon404> "Clearly this +/-12 pts is better"
[18:19] <ubitux> :)
[18:20] <Daemon404> i dont know who handles timestamp magic in ffmpeg
[18:20] <ubitux> michael
[18:20] <ubitux> ;)
[18:20] Action: Daemon404 poke michaelni 
[18:20] <michaelni> Daemon404, i can add a new file to the rsync server if thats the consenus about what should be done
[18:20] <Daemon404> michaelni, the filter itself works fine. ffmpeg just passes it different timestamps.
[18:21] <Daemon404> if you think ffmpeg's timestamps are correct, then update the ref
[18:21] <cone-364> ffmpeg.git 03Stefano Sabatini 07master:df5f9496e6f8: lavf/segment: add missing flags to segmenter option constants
[18:21] <cone-364> ffmpeg.git 03Stefano Sabatini 07master:ecebf6fc825a: lavf/segment: provide more debug feedback when a new segment starts
[19:12] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:e095c4ea6dad: fate: update asyncts reference
[20:05] <saste> anyone against removing the bloat from tool manual pages, and referring to the dedicated manual pages?
[21:47] <Daemon404> hmm
[21:47] <Daemon404> mxpeg fails on armv5te/netbsd
[21:47] <Daemon404> only test to fail
[22:00] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:a99c273a3f91: dnxhddec: fix CID changed check.
[22:00] <cone-364> ffmpeg.git 03Michael Niedermayer 07master:51fcf276f8ce: mp3on4: fix null pointer dereference
[00:00] --- Sat Dec 15 2012