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

[burek]

[00:01] <saste_> cbsrobot: also man -l doc/ffmpeg-filters.1 is your friend
[00:01] Action: ubitux prefers vim libavfilter/vf_ass.c
[00:02] Action: ubitux often secretly just open the source file for the options and see how they behave
[00:02] <cbsrobot> man: invalid option -- l
[00:02] <cbsrobot> man, version 1.6c
[00:02] <ubitux> man ./doc/ffmpeg-filters.1 ?
[00:02] <cbsrobot> well I do to
[00:02] <cbsrobot> yeah
[00:02] <cbsrobot> man works
[00:02] <cbsrobot> but vi is faster
[00:02] <saste> man -l works here since ages
[00:02] <ubitux> man works, but man should rest a bit
[00:03] <saste> woman doesn't work here, since ages
[00:03] <ubitux> No manual entry for woman
[00:04] <saste> no man for woman? weird
[00:05] <ubitux> saste: thx for the fate filters review
[00:05] <ubitux> btw, why is there 2 "saste"?
[00:05] <saste> my evil twin
[00:05] <ubitux> a fork?
[00:06] <cone-982> ffmpeg.git 03Clément BSsch 07ab981cab9381: fate: add hqdn3d filter test.
[00:06] <cone-982> ffmpeg.git 03Clément BSsch 07b5ffbcd0cd23: fate: add gradfun filter test.
[00:11] <ubitux> saste: btw, i noticed there is a small mem leak in lavfi/lavfutils.c while testing removelogo filter
[00:11] <ubitux> i don't remember what exactly, maybe a packet not destroyed or something
[00:13] <ubitux> ./ffmpeg -f lavfi -i 'color=c=black[a]; movie=tests/lena.pnm,scale=iw/2:ih/2[b]; [a][b] overlay=(W-w)/2:H-h-20' -frames:v 1 ref.png
[00:13] <ubitux> ./ffmpeg -f lavfi -i 'testsrc[a]; movie=tests/lena.pnm,scale=iw/2:ih/2[b]; [a][b] overlay=(W-w)/2:H-h-20' -t 10 test.mp4
[00:13] <ubitux> valgrind --leak-check=full ./ffmpeg_g -i test.mp4 -vf removelogo=ref.png -t 0.1 -f null -
[00:13] <ubitux> this should be enough to reproduce :p
[00:14] <ubitux> cbsrobot: so is vf subtitles working for you now?
[00:15] <cbsrobot> no
[00:15] <cbsrobot> still looking
[00:15] <ubitux> can you get me a backtrace or something?
[00:15] <cbsrobot> sure
[00:16] <ubitux> (and a sample maybe?)
[00:16] <cbsrobot> you need the registers ?
[00:17] <ubitux> a backtrace might be enough, with symbols :)
[00:17] <cbsrobot> http://pastebin.com/tTSnksuc
[00:18] <saste_> ubitux: maybe I have to free the packet?
[00:18] <ubitux> saste_: that's what i though as well
[00:18] <saste> ah another segment patch, it's killing me
[00:19] <cbsrobot> ubitux: an extract from the srt: http://pastebin.com/JEg6dPnW
[00:19] <cbsrobot> (didn't try it with the extract)
[00:21] <ubitux> works pretty fine with me :p
[00:21] <ubitux> valgrind doesn't notice anything&
[00:22] <ubitux> i do have some complains in print_report though...
[00:24] <cbsrobot> the whole srt: http://pastebin.com/vuL5rVHc
[00:25] <michaelni> ubitux, the split patch should be ok, theres a small chace it might leak though if the user app doesnt use free_packet
[00:26] <michaelni> well the chance is more than small in that case but i donno if any user app does that
[00:27] <cbsrobot> ubitux: when I convert it to ass and use -vf ass= it works
[00:29] <ubitux> cbsrobot: weird&
[00:33] <ubitux> am i the only one to get valgrind issues in ffmpeg:print_report with valgrind ./ffmpeg_g -f lavfi -i testsrc -frames:v 2 -c:v libx264 -f null - ?
[00:38] <ubitux> michaelni: apps not doing a free packet currently already leak, right?
[00:40] <michaelni> not neccesarily
[00:41] <michaelni> a app can cunstruct its own AVPacket and free the data if needed diffetrently
[00:43] <ubitux> so an app re-implementing its own av_free_packet, freeing the data and calling the destruct method, but not doing so on the side data?
[00:43] <ubitux> that sounds pretty evil :)
[00:45] <michaelni> it doesnt have to do it so complex, simply setting data and size of a AVPacket and leaving destruct NULL works
[00:46] <wm4> ubitux: some (most) applications just want to use ffmpeg decoders/demuxer, not use it as complete "framework"
[00:46] Action: ubitux reads "In both cases, the packet must be freed with av_free_packet() when it is no longer needed."
[00:46] <wm4> ubitux: which is actually quite reasonable, considering how often ffmpeg breaks APIs
[00:46] <ubitux> so you don't call av_free_packet() wm4? :)
[00:47] <wm4> the mplayers don't
[00:47] <wm4> not for the one passed to the decoder
[00:47] <wm4> (which is not the same packet pointer as the one received by libavformat)
[00:48] <wm4> they run av_init_packet(&pkt), set some fields, pass it to lavc, and that's it
[00:48] <wm4> not sure if it matters in your case...
[00:49] <saste> ubitux: feel free to send a patch for the leak of course...
[00:49] <saste> i suspect we have more of those leaks, e.g. in the examples
[00:49] <ubitux> saste: i won't for the lavfutils one :p
[00:49] <ubitux> saste: indeed :)
[00:50] <ubitux> wm4: my current use case is for muxing, i believe that doesn't apply here
[00:54] <cbsrobot> ubitux: what issues wit hvalgrind ?
[00:55] <ubitux> cbsrobot: http://pastie.org/5481417 this :p
[00:56] <durandal_1707> michaelni: ping
[00:59] <ubitux> erm i got issues with gradfun
[00:59] <ubitux> not fun.
[00:59] <cbsrobot> ubitux: I get http://pastie.org/5481439
[01:00] <durandal_1707> i found devastating commit that got merged
[01:04] <ubitux> the test is supposed to be bitexact
[01:04] <ubitux> :/
[01:04] <michaelni> durandal_1707, which commit ?
[01:05] <durandal_1707> michaelni: patch under way
[01:06] <durandal_1707> it probes how l reviewers are doing "good" job
[01:06] <durandal_1707> *proves
[01:06] <iive> is it cve worthy?
[01:06] <durandal_1707> cve?
[01:06] <durandal_1707> no it is for hall of shame
[01:06] <ubitux> security relevant
[01:06] <iive> security exploit.
[01:07] <iive> oh, so it is in the "this is even better" category.
[01:07] <durandal_1707> i'm too busy for fixing non-security bugs, i just have no time for security ones
[01:12] <ubitux> durandal_1707: if you're talking about the sed-fail for ff_get_buffer, it's not yet merged
[01:13] <durandal_1707> no, this one is very old
[01:13] <teratorn> commit hash or it didn't happen
[01:13] <ubitux> http://pastie.org/5481489 "snow is broken beyond repair, let's drop it"
[01:14] <durandal_1707> heh, i will push fix without sending it on ml
[01:14] <ubitux> well anyway, maybe i should fix my own crap now :)
[01:15] <iive> lgtm
[01:16] <durandal_1707> iive: of what?
[01:17] <iive> removing snow... maybe i should have said: "lgtm"
[01:21] <cone-982> ffmpeg.git 03Carl Eugen Hoyos 074e6f9db493f5: Set some audio stream properties in the vivo demuxer.
[01:22] <wm4> ubitux: about yadif, the mplayer2 version has some PTS fixes over the mplayer-svn version too
[01:23] <ubitux> we have a native yadif
[01:23] <ubitux> we don't use the mp wrapper for this
[01:25] <ubitux> ok i found the problem with valgrind
[01:26] <ubitux> enc->coded_frame->quality is undefined
[01:26] <cbsrobot> ubitux: sure the subtitle= works
[01:27] <ubitux> cbsrobot: huh? now it works?
[01:27] <cbsrobot> sumehow didint read git pull output
[01:27] <ubitux> !
[01:27] <ubitux> you evil
[01:27] <ubitux> i almost lost time looking deeper ;)
[01:27] <cbsrobot> but ab5497df1556 fixed it
[01:27] <ubitux> fortunately i have other issues to look for
[01:28] <cbsrobot> hehe ebur128 ?
[01:28] <cbsrobot> wild guess
[01:28] <ubitux> nope, the valgrind issue, and the failing gradfun fate test
[01:30] <durandal_1707> how you force fate to continues on failure (always forget this)
[01:30] <ubitux> -k
[01:31] <ubitux> like "kontinue"
[01:34] <ubitux> sorry for making fate red
[01:34] <ubitux> well, yellow.
[01:35] <cone-982> ffmpeg.git 03Michael Niedermayer 078bf16e677f5d: ffv1enc: allow encoding with 1 slice for CIF and smaller in version 3
[01:35] <durandal_1707> ubitux: is new look ready?
[01:35] <ubitux> for fate? no idea, ask burek 
[01:36] <ubitux> if you're talking about me, i'll go to the shower in a few hours
[01:37] <michaelni> ubitux, fate gradfun fails here with --disable-asm / yasm
[01:37] <michaelni> in case you dont know 
[01:37] <ubitux> oh it was the float in the code, ok
[01:37] <cone-982> ffmpeg.git 03Nicolas George 07d3835cb87714: lavf: compute probe buffer size more reliably.
[01:37] <cone-982> ffmpeg.git 03Nicolas George 07e74cd2f4706f: lavf: compute probe buffer size more reliably.
[01:38] <ubitux> obviously, if the asm behaves differently& mmh
[01:38] <ubitux> thx
[01:39] <durandal_1707> cone is repeating same commit with different hash
[01:40] <ubitux> because it was pushed on 1.0 and 0.11
[01:41] <durandal_1707> how i set diff in patch to have bigger span so diff is actully useful?
[01:42] <ubitux> -C ?
[01:43] <cbsrobot> not -U<n> ?
[01:43] <durandal_1707> but for format-patc
[01:45] <cbsrobot> not -U<n> ?
[01:52] <durandal_1707> patch on ml
[01:59] <ubitux> ok, two things strange: http://pastie.org/5481604
[01:59] <ubitux> this patch fixes all the valgrind issues
[01:59] <ubitux> which is weird, the AVFrame is in the local context which should be zero-ed
[01:59] <ubitux> but if i print the quality value just after the if else, i get some issues back
[02:03] <durandal_1707> ubitux: that patch have libx264
[02:04] <ubitux> durandal_1707 ?
[02:05] <ubitux> michaelni: should i disable asm for the test?
[02:05] <ubitux> or there is another trick?
[02:06] <michaelni> ubitux, dunno what causes the difference ?
[02:07] <cone-982> ffmpeg.git 03Paul B Mahol 0745326cb68440: pixdesc: fix broken yuva definitions
[02:07] <michaelni> i see 3 asm functions all or one cause the problem ?
[02:08] <michaelni> does the difference between asm and c also exist in libmpcodecs ?
[02:08] <ubitux> 'going to investigate
[02:14] <ubitux> seems like both assembly filter_line version produces the same output, but it is different that the C version, blur function is not affected
[02:30] <michaelni> ubitux, well you could investigate why they are different and maybe one can be chnaged or disable asm for the fate tests
[02:31] <ubitux> yes i'm trying to understand why they diverge
[02:31] <ubitux> i'll fix fate asap
[02:31] <michaelni> thx
[03:46] <cone-982> ffmpeg.git 03Michael Niedermayer 07599ae9995f2e: ff_emulated_edge_mc: fix handling of w/h being 0
[04:21] <ubitux> i may have found the problem
[04:29] <ubitux> first, i think the C version should use dc += x & 1, x++ instead of x++, dc += x
[04:29] <ubitux> instead of x++, dc += x & 1 sorry
[04:29] <ubitux> otherwise the DCs don't match
[04:31] <ubitux> at least that's one of the issue
[04:32] <ubitux> looking at the second mismatch now
[04:32] <ubitux> but there is less differences with that change already
[04:34] <ubitux> i wonder if the order of operation is defined with the comma btw
[05:09] <ubitux> ok the other issue might be related to something else
[05:36] <cone-982> ffmpeg.git 03Michael Niedermayer 079db3fb6ed8d3: oggdec: prevent codec from changing through ogg_replace_stream()
[05:50] <ubitux> the other problem seems related to some sign extension
[05:50] <michaelni> some sign extension ?
[05:52] <ubitux> yeah well, there is a ±1 mismatch with 'm' between C and ASM version; i think that's because the ASM is doing strange op in the negative domain
[05:52] <ubitux> still trying to understand how it works
[05:53] <michaelni> if theres some opcode that you dont know what exactly it does ... theres a relativly good reference somewhere on intel.com
[05:53] <ubitux> yes i have the full pdf no worry
[05:53] <michaelni> ok
[05:53] <ubitux> 4k pages :p
[05:54] <ubitux> it's the logic i don't get yet
[05:54] <ubitux> int m = abs(delta) * thresh >> 16;  this is identical
[05:54] <ubitux> then in asm there is a 0x7f-m
[05:54] <ubitux> it seems to be doing the max() thing in reverse
[05:54] <ubitux> then go back to the original value
[05:55] <ubitux> somewhere in the middle something goes wrong and there is a ±1 mismatch (sometimes/most of the time) between the final values
[05:55] <ubitux> it doesn't affect often the final result since it's shifted by 7 after
[05:56] <ubitux> but sometimes, it makes a difference, and it leads to a mismatch
[05:57] <ubitux> i think when this second issue is fixed both outputs (c & asm) should be identical
[05:57] <ubitux> i guess adding the fate test was useful :D
[05:59] <ubitux> m-0x7f sorry
[06:03] <ubitux> maybe that's because pmulhrsw is doing some rounding
[06:08] <michaelni> the mmxext code does not match the ssse3 code nor does either match C according to a quick test
[06:08] <ubitux> iirc mmx & ssse3 match
[06:08] <michaelni> not here
[06:09] <ubitux> i'm debugging with ssse3 here
[06:09] <michaelni> +0,          0,          0,        1,    76800, 0x3a5f8430 vs +0,          0,          0,        1,    76800, 0xb5da64f8
[06:09] <michaelni> also theres no pmulhrsw in mmxext
[06:09] <michaelni> but i didnt look at the code at all
[06:10] <ubitux> give me maybe an hour or two
[06:10] <ubitux> i'm a bit slow ;)
[06:10] <ubitux> anyway, the first issue can be fixed with:
[06:10] <ubitux> -    for (x = 0; x < width; x++, dc += x & 1) {
[06:10] <ubitux> +    for (x = 0; x < width; dc += x & 1, x++) {
[06:10] <ubitux> it reduces the diff a lot
[06:10] <ubitux> (not raw diff, not crc) 
[06:16] <ubitux> ok it's indeed at pmulhrsw that something differs
[06:42] Action: michaelni falls asleep
[06:46] <Compn> quick! while hes asleep! lets rename all of the api
[06:48] Action: ubitux falls asleep too
[06:49] <ubitux> i guess i'll let fate rest in yellow for a few more hours, sorry.
[06:51] <ubitux> anyway, something doesn't look correct
[06:52] <ubitux> pmulhrsw isn't really doing a m*m*delta >> 14
[06:53] <ubitux> it's more like ((((m*m)<<1) * delta) >> 15) + 1
[06:56] <ubitux> what does "vertically" means in "PMULHRSW multiplies vertically each signed 16-bit integer [...]"?
[07:04] <ubitux> i don't understand:
[07:04] <ubitux> xmm2: {0x5e88, 0x5e88, 0x5622, 0x4220, 0x5148, 0x4682, 0x4b08, 0x4c92}
[07:04] <ubitux> xmm1: {0x15a, 0x15a, 0x1bd, 0xfd3d, 0x1fc, 0xfd7c, 0x249, 0xfdc9}
[07:04] <ubitux> pmulhrsw %xmm2,%xmm1
[07:04] <ubitux> => xmm2: {0x100, 0x100, 0x12b, 0xfe93, 0x143, 0xfe9d, 0x157, 0xfead
[07:05] <ubitux> according to the documentation, i understand pmulhrsw like this:
[07:05] <ubitux> >>> hex((((0x5e88 * 0x15a) >> 14) + 1) & 0xffff)
[07:05] <ubitux> '0x200'
[07:05] <ubitux> but it's actually more like:
[07:05] <ubitux> >>> hex((((0x5e88 * 0x15a) >> 15) + 1) & 0xffff)
[07:05] <ubitux> '0x100'
[07:05] <ubitux> what did i miss?
[07:14] <ubitux> http://ubitux.fr/pub/pics/_pmulhrsw.png  i'm not smoking anything, right?
[07:14] <ubitux> oh maybe i should have read the following lines.
[07:17] <ubitux> so (((a*b)>>15)+1)>>1
[07:18] <Compn> smoking some things may shrink brain tumors...
[07:18] <ubitux> :)
[07:18] <ubitux> meh, still not enough to fix fate
[07:27] <ubitux> yepee it works.
[07:28] <wm4> non-interleaved avi seems to be broken again; shall I reopen ticket 333?
[07:28] <wm4> I get a/v desync at around 50 seconds in with ffplay
[07:28] <wm4> mplayer's demux_avi works
[07:28] <ubitux> i need to fix the mmx now&
[07:29] <wm4> test file is the same as in ticket 333
[07:29] <ubitux> wm4: please re-open yes
[07:29] <ubitux> i guess we will need a fate test for this
[07:39] <wm4> hm I guess I should actually re-open
[07:40] <ubitux> do you have enough rights?
[07:40] <ubitux> seems to, ok.
[07:40] <ubitux> nice nick & mail btw
[07:41] <wm4> throw away accounts
[07:46] <ubitux> -        m = m * m * delta >> 14;
[07:46] <ubitux> +        m = (((((m*m)<<1) * delta) >> 14) + 1) >> 1;
[07:46] <ubitux> not sure that's better, but it matches ssse3 code :p
[07:46] <ubitux> but it doesn't match mmx though, but the original code either
[08:27] <ubitux> i'll finish the mmx one after sleep
[08:27] <ubitux> night.
[09:26] <Tjoppen> has anyone else gotten mail from cherryplayer?
[09:40] <pettter> libavresample vs. libswresample, where should I go for the easiest upgrade-path (I use the now deprecated lavc API currently)
[09:41] <wm4> pettter: apparently, lately libswresample can be easily made API-compatible to libavresample by changing the function names
[10:14] <Tjoppen> libmlt is pretty cool - I wrote a program that loads renders its xml project format to stdout. plays perfectly in ffplay :)
[10:14] <Tjoppen> said xml came out of kdenlive. woop
[10:30] <wm4> the mmsh protocol seems to have a way to select which video/audio streams' packets should be sent over network (with "Pragma: stream-switch-entry=")
[10:30] <wm4> does ffmpeg not use this? (mplayer does)
[10:33] <wm4> ffmpeg just seems to request all streams, which might be stupid, as mms streams usually contain the same video encoded to multiple video streams in different quality for different bandwidths
[10:49] <cone-556> ffmpeg.git 03Nicolas George 07217b10de3f30: lavc/dvdsubdec: accept palette from options.
[11:28] <durandal_1707> huh, ffmpeg & ffprobe now reports strange start_time for streams
[12:12] <durandal_1707> l misnamed ffv1 as ff1
[12:15] <durandal_1707> OMG evil plan got pushed
[12:16] <nevcairiel> no it didnt
[12:16] <nevcairiel> just innocent preparation commits
[12:29] <durandal_1707> michaelni: block_align somehow changes start_time for stream that it is no more hidden and 0
[12:39] <durandal_1707> ah, got it, it is because pcm sets pts/dts using pos
[12:42] <durandal_1707> michaelni: is that really needed for pcm read packet to sets pts/dts(using packet pos) ?
[13:01] <wm4> it seems even ffplay demuxes the whole file when playing an audio file with picture attachment
[13:01] <wm4> is that correct? (I'm not really sure how this works)
[13:02] <durandal_1707> it try to look for more frames? i think that have been fixed
[13:02] <durandal_1707> wm4: what version you are using?
[13:04] <wm4> durandal_1707: git head... well, playing a mp3 with attachment shows "aq= 7742KB", which is about the size of the file
[13:04] <wm4> while playing a mp3 without any image shows just a few KB for aq
[13:06] <wm4> and since "aq" is apparently the total size of packets demuxed but not yet decoded, I assume it demuxed the whole file trying to find a video frame
[13:06] <durandal_1707> yes it is bad behaviour
[13:06] <michaelni> wm4, sounds like a ffplay bug
[13:07] <wm4> it makes me wonder how a video player is supposed to handle this at all (put a fixed limit on the packet queue?)
[13:08] <cone-556> ffmpeg.git 03Michael Niedermayer 0709de0ffeab37: vc1dec: Fix null pointer dereference in vc1_decode_skip_blocks()
[13:08] <durandal_1707> well first thing is that image in mp3 should not be treated as video stream
[13:08] <durandal_1707> by adding another media type
[13:09] <wm4> it seems sometimes there are actually files which contain just a dozen of images in the video stream as some sort of "slide show" additional to audio
[13:09] <durandal_1707> michaelni: i see nothing bad happening if i remove pkt->pts/dts code for pcm_read_packet
[13:10] <durandal_1707> wm4: what files?
[13:11] <wm4> it was a mp4 file... let me see if I can find it again
[13:13] <michaelni> i suspect marton is happy to fix these thing in ffplay if someone tells him about them ...
[13:13] <michaelni> thingS
[13:15] <cone-556> ffmpeg.git 03Michael Niedermayer 071fa2bdc90a4a: fate: disable vf_gradfun test
[13:17] <wm4> durandal_1707: found it: http://www.podtrac.com/pts/redirect.mp3/traffic.libsyn.com/rtpodcast/Rooster_Teeth_Podcast_191.m4a
[13:17] <wm4> this is basically audio + a picture slide show as video track
[13:17] <wm4> since the "video" frames are shown so long, the audio queue gets quite large at times
[13:18] <wm4> kind of similar to the attached picture case
[13:19] <durandal_1707> michaelni: i gonna push patch set that use pcm_read_packet with pts/dts code removed
[13:27] <durandal_1707> michaelni: can i get some feedback?
[13:28] <michaelni> about pcm timestamps, maybe its ok to remove maybe not i cant say without testing
[13:29] <durandal_1707> what should testing do?
[13:29] <durandal_1707> fate passed here
[13:30] <Compn> i guess make sure you can still encode/decode pcm to some various formats
[13:31] <durandal_1707> Compn: only raw pcm demuxer is affected and it works fine
[13:31] <durandal_1707> it outputs same timestamps
[13:31] <Compn> ok then :)
[13:31] <michaelni> durandal_1707, ffplay could be tested too, it displays time in its status line and that should stay correct when seeking
[13:34] <durandal_1707> i tested ffplay and it still works
[13:35] <michaelni> then it should be ok
[13:38] <cone-556> ffmpeg.git 03Diego Biurrun 0790153465b04b: fate: Add dependencies for bmp, cdxl, dfa, mp3
[13:38] <cone-556> ffmpeg.git 03Anton Khirnov 07cb45553f577f: Remove pointless #undefs of previously forbidden functions.
[13:38] <cone-556> ffmpeg.git 03Michael Niedermayer 0799efd5962672: Merge commit 'cb45553f577f8e0ebfe05d3287e1b6fa5859b967'
[13:41] <durandal_1707> michaelni: i think there are some fixes from me that can get into 1.0.1
[13:44] <durandal_1707> ah, than into 1.0.2?
[13:44] <michaelni> yes, for 1.0.1 its too late 
[13:45] <michaelni> feel free to push fixes to release/1.0
[14:05] <cone-556> ffmpeg.git 03Paul B Mahol 0793dc8ed0a113: pcmdec: move read_packet function to pcm.c so it can be shared with other demuxers
[14:05] <cone-556> ffmpeg.git 03Paul B Mahol 0715ab0393fd8f: avr: use ff_pcm_read_packet()
[14:05] <cone-556> ffmpeg.git 03Paul B Mahol 07a647eb5a8788: pvfdec: use ff_pcm_read_packet()
[14:05] <cone-556> ffmpeg.git 03Paul B Mahol 07c090b5427d89: audec: use ff_pcm_read_packet()
[14:05] <cone-556> ffmpeg.git 03Paul B Mahol 07acac16b5c783: soxdec: use ff_pcm_read_packet()
[14:05] <cone-556> ffmpeg.git 03Paul B Mahol 078ecf22ffb01e: rsodec: use ff_pcm_read_packet()
[14:05] <cone-556> ffmpeg.git 03Paul B Mahol 07880191637ff7: IRCAM demuxer & muxer
[14:05] <cone-556> ffmpeg.git 03Paul B Mahol 074c18562d0207: Ensoniq Paris Audio File demuxer
[14:13] <michaelni> durandal_1707, make: *** [fate-lavf-ircam] Error 1
[14:13] <michaelni> +2cfae025de1b13098ef84a5e7f9947aa *./tests/data/lavf/lavf.ircam
[14:13] <durandal_1707> where?
[14:13] <durandal_1707> what arch?
[14:14] <durandal_1707> it must be float, so looks like different test should be done
[14:14] <michaelni> intel core i7
[14:16] <durandal_1707> so comparing md5 file of float stored in file is not going to work, what other kind of test i have left....
[14:18] <michaelni> you could construct the written value with just integers
[14:18] <michaelni> no float no problem
[14:18] <michaelni> though i wonder why it fails
[14:19] <durandal_1707> different float implementations
[14:20] <durandal_1707> sample rate is stored as float in file
[14:23] <durandal_1707> i could use av_int2flt instead
[14:26] <michaelni> please do
[14:29] <durandal_1707> so float sr= av_int2flt(sample_rate); is good?
[14:32] <durandal_1707> it doesn't work
[14:36] <michaelni> durandal_1707, does this work : +    avio_wl32(s->pb, av_flt2int(codec->sample_rate)); ?
[14:36] <michaelni> produces this here: +2cfae025de1b13098ef84a5e7f9947aa *./tests/data/lavf/lavf.ircam
[14:38] <durandal_1707> nope that one produce same one which is already in master
[14:40] <durandal_1707> so just using test that does not check md5 of file would be best for now
[14:41] <michaelni> durandal_1707, is this intended: avio_skip(s->pb, 1008);  ?
[14:41] <michaelni> skip on write ?
[14:41] <durandal_1707> what it does not write 0 but something random :) ?
[14:42] <Tjoppen> sometimes you get garbage, IIRC
[14:42] <durandal_1707> so i need to invent own way to write 0
[14:42] <durandal_1707> sucks*
[14:43] <durandal_1707> or ffio_fill is what i need?
[14:45] <Tjoppen> that sounds about right
[14:46] <durandal_1707> lol, it corrupts here
[14:46] <durandal_1707> i have same md5 like michaelni 
[14:47] <michaelni> \o/
[14:49] <cone-556> ffmpeg.git 03Paul B Mahol 074727611d4893: ircamenc: 10l do not use avio_skip()
[15:16] <DEgITx> Hi, question about av_read_frame() . Is it good to use it twice? (first time for detection correct duration and nb_frames for some formats, second time for real demuxing). If yes and there no more relevant methods than how to reset offset of av_read_frame to start from begining?
[15:19] <ubitux> av_find_stream_info ?
[15:20] <ubitux> (gdb) p $mm0
[15:20] <ubitux> $8 = void
[15:20] <ubitux> :((
[15:25] <cone-556> ffmpeg.git 03Anton Khirnov 07594d4d5df3c7: lavc: add a wrapper for AVCodecContext.get_buffer().
[15:25] <cone-556> ffmpeg.git 03Michael Niedermayer 07874c5b02c411: Merge commit '594d4d5df3c70404168701dd5c90b7e6e5587793'
[15:38] <DEgITx> ubitux: avformat_find_stream_info already has used (if that was answer to me :) )
[15:40] <Mavrik> hey... how do I contribute a patch? Are the guidelines published anywhere?
[15:41] <ubitux> DEgITx: and you still need to demux a first frame to get some info?
[15:41] <ubitux> Mavrik: yes, on the contact page
[15:41] <ubitux> first 2 paragraph iirc
[15:41] <Mavrik> found it, thanks :)
[15:58] <cone-556> ffmpeg.git 03Anton Khirnov 07ff953fecffd3: lavc: set frame properties in ff_get_buffer().
[15:58] <cone-556> ffmpeg.git 03Michael Niedermayer 072f980cf39a14: Merge commit 'ff953fecffd3b9a616a046723fb9d4690be032a6'
[16:02] <DEgITx> ubitux: for example vp8 retrive nb_frames = 0 and duration = big negative unitialized value :) i'm trying to avoid that kind of thing and get normal duration, any of methods will be good for that. About first frame - yes packet contaion duration, so idea was to get duration from last packet.
[16:03] <cone-556> ffmpeg.git 03Michael Niedermayer 07d2a3f08dafed: lavc: move ff_init_buffer_info() down to ff_get_buffer()
[17:01] <cone-556> ffmpeg.git 03Anton Khirnov 07e57c4706e969: lavc: don't reuse audio buffers
[17:01] <cone-556> ffmpeg.git 03Michael Niedermayer 0783db6cb521c6: Merge commit 'e57c4706e969afa1f2384481b955ccd9494cddb5'
[17:07] <cone-556> ffmpeg.git 03Anton Khirnov 07387bef95d280: lavc: factorise setting buffer type in avcodec_default_get_buffer().
[17:07] <cone-556> ffmpeg.git 03Michael Niedermayer 07022553e87509: Merge commit '387bef95d28019c13c6805cfa4079e59948284e5'
[17:24] <cone-556> ffmpeg.git 03Anton Khirnov 07df9b9567518f: lavc: fix decode_frame() third parameter semantics for video decoders
[17:24] <cone-556> ffmpeg.git 03Michael Niedermayer 07fc1152de4103: Merge commit 'df9b9567518f2840d79a4a96b447ebe1aa326408'
[17:36] <cone-556> ffmpeg.git 03Janne Grunau 0754c7fe6d6844: raw demuxer: initialize end of partial packets
[17:36] <cone-556> ffmpeg.git 03Janne Grunau 0742060c703011: eamad: initialize padding of bitstream_buf through av_fast_padded_malloc()
[17:36] <cone-556> ffmpeg.git 03Janne Grunau 07c15fea7933b3: mimic: initialize padding of swap_buf through av_fast_padded_malloc
[17:36] <cone-556> ffmpeg.git 03Mans Rullgard 07da025d115a1a: fate: workaround for slighly broken 'test' shell builtin
[17:37] <cone-556> ffmpeg.git 03Michael Niedermayer 07835fd779a46d: Merge remote-tracking branch 'qatar/master'
[17:44] <michaelni> ubitux, the filter-hqdn3d test is failing on arm
[17:44] <michaelni> http://fate.ffmpeg.org/report.cgi?time=20121205141041&slot=arm7-cubox-gcc4.1
[18:03] <ubitux> i'm still on gradfun
[18:03] <ubitux> i've fixed the diff between ssse3 & c
[18:03] <ubitux> i'm looking into the mmx one
[18:03] <ubitux> i'll check hqdn3d after
[18:06] <michaelni> ubitux, "fixed diff" without slowdown ?
[18:06] <gnafu> Ooh, a CuBox FATE instance, eh?
[18:06] Action: gnafu hadn't noticed before.
[18:14] <ubitux> michaelni: it will likely cause a small slow down in the C version; i'm looking at the mmx one to see how they diverge and if they can be homogenized
[18:17] <michaelni> it might be simlper to just make the test fuzzy if its just +-1 differences
[18:17] <michaelni> or just test C
[18:18] <ubitux> yep sure, but i'd like to understand the diff before
[18:19] <ubitux> fuzz will work with video?
[18:20] <ubitux> i've a hard time debugging mmx code with gdb :p
[18:20] <ubitux> any way to properly display the register?
[18:21] <ubitux> i'm not able to print the fp registers stX in hexa
[18:21] <ubitux> p/x doesn't seem to print it as expected
[18:29] <michaelni> info all-registers
[18:30] <ubitux> yes, it prints the "raw", but i wasn't able to print a reg specifically
[18:37] <michaelni> info registers <register name>
[18:38] <ubitux> oh nice
[18:38] <ubitux> thx
[19:28] <cone-556> ffmpeg.git 03Paul B Mahol 074012cd6c4f19: lavc: fix decode_frame() third parameter semantics for rest of video decoders
[19:35] <kierank> http://www.stopp.se/lab/wp-content/uploads/2012/12/Stopp_ProRes_Test_Chart.pdf
[19:35] <cone-556> ffmpeg.git 03Michael Niedermayer 07b023392f348e: mpegvideo: remove #if/define PARANOID code
[19:35] <cone-556> ffmpeg.git 03Michael Niedermayer 079bb188da962e: j2k: avoid printf() useage in debug code
[19:35] <cone-556> ffmpeg.git 03Michael Niedermayer 077c2481f2d73a: j2kenc: remove duplicate debug functions
[19:35] <cone-556> ffmpeg.git 03Michael Niedermayer 07911c00e60fe1: motion_est: use av_log() in debug code
[19:35] <cone-556> ffmpeg.git 03Michael Niedermayer 076d7effa9bda0: mpegvideo_enc: use av_log() in debug code
[19:39] Action: juanmabc waits for adpcm_ima_amv encoding to pop on the logs :)
[19:41] <durandal_1707> kierank: what that chart means, almost everything is red
[19:42] Action: durandal_1707 juanmabc donate $$$$$
[19:43] <kierank> means there is a chroma shift with ffmpeg
[19:43] <durandal_1707> and libav?
[19:46] <michaelni> kierank, how can i reproduce the issue(s) ?
[19:47] <durandal_1707> all entries are for ffmpeg?
[19:50] <durandal_1707> well chroma shift happens probably because: our encoder(thare are two) is wrong or both our encoder and decoder (there are two) are wrong...
[19:52] <cbsrobot> kierank: when I output prores 422 hq colorbars from nuke and reimport them I get chroma shift
[19:52] <cbsrobot> but when I output tif it works
[19:52] <cbsrobot> now converting that tiff to prores 422 hq with ffmpeg there is no chroma shift
[19:53] <cbsrobot> I always thought it's the faut of the qt component
[19:58] <ubitux> michaelni: i think i found the difference for mmx
[19:59] <ubitux> it might be the dithering position
[19:59] <ubitux> it might just be doing an equivalent to dithers[x & 3]
[20:00] <iive> kierank: what kind of chroma shift? 1 or 1/2 pixel, left,right,up/down ?
[20:12] <kierank> michaelni: dunno, you'd probably need those programs
[20:12] <kierank> ask the authors i guess
[20:19] <Daemon404> hum
[20:19] <Daemon404> how does one seek to the last keyframe in a file when ->duration isnt accurate
[20:19] <Daemon404> (i.e. it's a chopped up file)
[20:20] Action: Daemon404 thought nevcairiel had some methosd
[20:20] <nevcairiel> one doesnt
[20:20] <Daemon404> :<
[20:20] <nevcairiel> for some reason, no-one developed a good api for reading and parsing backwards :d
[20:20] <Daemon404> :/
[20:23] Action: Daemon404 has an idea
[20:23] <Daemon404> inb4 failure
[20:26] <cone-556> ffmpeg.git 03Reimar Döffinger 0758df8befda61: av_assert should use AV_LOG_PANIC.
[20:30] <cone-556> ffmpeg.git 03Wolfram Gloger 07928346091a2e: mpegvideo_parser: fix buffer access beyond end
[20:30] <cone-556> ffmpeg.git 03Piotr Bandurski 07538196050197: wmaenc: add new line to some error messages
[20:32] <ubitux> michaelni: any idea how i could reproduce the hqdn3d failure?
[20:32] <ubitux> my guess is that it's a rounding problem in the float things in precalc_coefs
[20:40] <ubitux> michaelni: or maybe that's simply because it's missing a -idct simple or something?
[20:40] <ubitux> codec is jpeg, so maybe it has some effect
[20:49] <michaelni> ubitux, you could theoretically reproduce it with qemu and a matching arm cross compiler
[20:49] <michaelni> not very easy though
[20:50] <ubitux> yes, it's a pain :p
[21:01] <cone-556> ffmpeg.git 03Reimar Döffinger 0725fec8595d3a: avcodec: add ff_lock/unlock_avcodec functions.
[21:01] <cone-556> ffmpeg.git 03Reimar Döffinger 077feef7dbca5f: Acquire lock when initializing parsers.
[21:01] <cone-556> ffmpeg.git 03Reimar Döffinger 07dd154198b1af: Add assert that the avcodec lock is held when initializing static VLC tables.
[21:05] <cone-556> ffmpeg.git 03Paul B Mahol 07c5008135c2ec: dxa: signal EOF
[21:21] <cone-556> ffmpeg.git 03Paul B Mahol 070aabd35b62f6: lavf/dxa: return meaningful error codes
[21:32] <cone-556> ffmpeg.git 03Paul B Mahol 079f66531d4603: lavc/dxa: return meaningful error codes
[21:48] <cone-556> ffmpeg.git 03Paul B Mahol 079ef29af2e864: cafenc: do not include riff.h
[21:49] <michaelni> btw ubitux if you need something tested on arm, for hqdn3d, i can do that
[22:41] <ubitux> michaelni: does -idct simple help?
[22:42] <ubitux> maybe with -flags +bitexact, but not sure it has an effect in this case
[23:10] <cone-556> ffmpeg.git 03Clément BSsch 072273b3aaf9cc: swr: remove unused ONE define.
[23:13] <ubitux> pengvado: do you mind having a look to the "FATE gradfun" thread on ffmpeg-devel?
[23:16] <ubitux> i think you are the original author of that code
[23:23] <michaelni> ubitux, -idct simple fixes it on arm
[23:24] <michaelni> +fate-filter-hqdn3d: CMD = framecrc -idct simple -i $(SAMPLES)/smjpeg/scenwin.mjpg -vf hqdn3d -an
[23:25] <ubitux> nice
[23:25] <ubitux> do you commit or should i?
[23:31] <michaelni> ubitux, you can commit it
[23:33] <ubitux> ok will do in a moment
[23:35] <saste_> michaelni, more comments on resampling_audio.c?
[23:42] <cone-556> ffmpeg.git 03Clément BSsch 07d3451a9c0fed: fate/hqdn3d: add -idct simple.
[00:00] --- Thu Dec  6 2012