[00:00] <durandal11707> what changes size? [00:01] <ubitux> durandal11707: stsc samples list being insanely big with mov muxing in some cases [00:01] <ubitux> because of 1-2-1-2-1-2 interleaving [00:01] <ubitux> ’ http://pastie.org/7729610 [00:04] <durandal11707> is that problem of change in interleaving or? [00:07] <ubitux> it's something related to audio [00:47] <durandal11707> so lavfi assumes everything is cfr? [01:08] <cone-907> ffmpeg.git 03Michael Niedermayer 07master:7f138310fbef: ffv1enc: favor version 3 over 2 unless -strict -2 is set [01:21] <durandal11707> michaelni: why av_memdump? [01:30] <michaelni> durandal11707, its done at a few places, could simplify code [01:32] <durandal11707> yes, i will leave "doc" review to someone else [04:31] <highgod> Hi, michaelni, are you online [04:31] <michaelni> yes [04:34] <highgod> about the opencl on apple, we have no environment, I think I can submitted a patch, can you review it and ask someone who has the apple platform to test? thanks [04:57] <michaelni> highgod, you could ask one of the 2 people who submitted opencl / osx patches to test [05:09] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:0fb64da63fb7: avformat: Add black ops audio demuxer [05:17] <highgod> OK, got it [07:17] <highgod> Hi, I want to ask a question, is there any method that can capture sound from the sound card? thanks [07:20] <funman> highgod: alsa [07:21] <funman> try ffplay -f alsa hw:0,0 [07:22] <highgod> is there any source code? [07:23] <highgod> I want capture the sound from the sound card, not the file. [07:23] <funman> libavdevice/alsa*.c [07:23] <funman> i don't know source code which uses it though but i expect it's not too difficult to use with libavformat [07:24] <highgod> both windows and linux? sorry I have no knowledge about sound,hehe [07:26] <funman> well no the l in alsa means linux [07:26] <funman> there's directshow (which is windows) code apparently though [07:28] <highgod> is there any code in ffmpeg to use directshow? [07:29] <funman> avformat_open() ? with AVInputFormat set properly. sorry can't help you more than that [07:30] <funman> avformat_open_input i mean [07:32] <highgod> funman:I don't get what your mean [07:33] <highgod> do you konw any code of using directshow to capture sound? Or can we use the win32 api directly? [07:35] <funman> nope [07:36] <highgod> ??:) [07:43] <highgod> funman:can you paste the command more detail? ffplay -f alsa hw:0,0 out.wav? [07:43] <highgod> is it ok [07:44] <funman> if you want to convert use ffmpeg, not ffplay [07:47] <highgod> I want to capture the sound from the device, not the file, so if I use ffmpeg, dose the out put is just trascode from the source file? [09:58] <xlinkz0> does avcodec_decode_video2 always get frames in order of pts? [10:01] <funman> 'get' ? [10:03] <xlinkz0> uhm, return? [10:03] <funman> yes [10:03] <xlinkz0> thanks [11:00] <highgod> how can I compile alsa? Unknown input format: 'alsa' [12:03] <cone-737> ffmpeg.git 03Anton Khirnov 07master:cf679b947672: hls, segment: fix splitting for audio-only streams. [12:03] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:54056c149333: Merge commit 'cf679b9476727a237c8006c685ace18acba149ab' [12:16] <cone-737> ffmpeg.git 03Luca Barbato 07master:26a44143efb5: avplay: remove a warning [12:16] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:5fd254c4f6db: Merge commit '26a44143efb513a602542fb59aee87b1fc62af51' [12:24] <cone-737> ffmpeg.git 03Luca Barbato 07master:c14010541035: oma: K&R formatting cosmetics [12:24] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:2ac6d6b7cdd4: Merge commit 'c14010541035454b4d3ad08399d70423be4e0c87' [12:41] <cone-737> ffmpeg.git 03Diego Biurrun 07master:03b052c023e1: fate: Invoke standard lavfi tests through fate-run.sh [12:41] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:506ebdac2a32: Merge commit '03b052c023e1f58d879cb7eeb6421ed39262d39d' [12:41] <michaelni> hmm, where is saste ... [12:42] <michaelni> ubitux, (and saste), you may want to update your lavfi tests to use fate-run.sh too [13:05] <cone-737> ffmpeg.git 03Diego Biurrun 07master:28663511c99b: fate: Invoke pixdesc lavfi tests through fate-run.sh [13:05] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:191430a28f6a: Merge commit '28663511c99b3cdaf9387a15032259879474f5f4' [13:06] <michaelni> saste: <michaelni> ubitux, (and saste), you may want to update your lavfi tests to use fate-run.sh too [13:07] <ubitux> ok [13:09] <saste> well i'm going to kill mp=tinterlace [13:10] <ubitux> with fire [13:14] Action: michaelni imagines someone with a blowtorch and a opened up hdd [13:15] <ubitux> http://us.123rf.com/400wm/400/400/prill/prill1110/prill111006243/11014172-sy... [13:23] <cone-737> ffmpeg.git 03Stefano Sabatini 07master:dfb3de21d896: doc/filters: apply various general fixes to vidstabdetect docs [13:23] <cone-737> ffmpeg.git 03Stefano Sabatini 07master:75070d9fa0b2: lavfi/transpose: apply grammar consistency fixes to transpose dir option [13:23] <cone-737> ffmpeg.git 03Stefano Sabatini 07master:04001767728f: lavfi/mp: remove mp=tinterlace wrapper [13:25] <ubitux> ok now could tinterlace be compatible with interlace, so we can alias them? [13:25] <saste> ubitux, how is not compatible? [13:26] <ubitux> dunno, maybe behaviour changes, options name mismatches, etc [13:26] <ubitux> btw, http://lucy.pkh.me/diff/diff-filters.html [13:26] <saste> ubitux: btw ping on lavfi/testsrc: add support for color interactive command [13:26] <saste> i'm using it to test zmq [13:26] <ubitux> ok, lemme check [13:26] <saste> lacks documentation [13:30] <saste> 17 filters left [13:34] <ubitux> well i believe a bunch of them are useless [13:34] <ubitux> 5-6 max i'd say [13:40] <cone-737> ffmpeg.git 03Diego Biurrun 07master:b963f021b603: fate: Invoke pixfmts lavfi tests through fate-run.sh [13:40] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:124244ec48c1: Merge commit 'b963f021b603509b5159873de4919dec441d0782' [13:46] <cone-737> ffmpeg.git 03Diego Biurrun 07master:1b6f84a98665: h264_refs: Do not print check_opcodes() return value [13:46] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:65af5e815a7a: Merge commit '1b6f84a98665a15130e969fd6b460a05d50090c1' [14:00] <cone-737> ffmpeg.git 03Luca Barbato 07master:a943a132f36f: aac: check the maximum number of channels [14:00] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:514940773196: Merge remote-tracking branch 'qatar/master' [14:05] <cehoyos> A propos FATE: I cannot reproduce the build problem on ia64 with gcc-4.4 and gcc-4.7 (and --enable-shared --enable-small) on real hardware [14:15] <michaelni> cehoyos, does it work without --enable-small as well ? [14:15] <cehoyos> Yes [14:16] <cehoyos> michaelni: Concerning a ticket that I will open soon (desync with ffplay): If the timebase for an input sample is 417083/10000000, is there a chance for ffmpeg to see that it is actually 24000/1001 ? [14:16] <cehoyos> (= Should I open an enhancement request to recognise 417083/10000000 as 24000/1001 or is this just a broken file? Note that the file probably is broken.) [14:17] <cehoyos> The input file is mpeg4-in-ogg and I want to reencode to mpeg4 [14:17] <michaelni> enhancement request seems appropriate [14:18] <cehoyos> That makes three tickets for one sample afaics [14:25] <michaelni> cehoyos, if you have access to a ia64, can you setup a fate client on that ? [14:26] <michaelni> the cause of the issue on fate is likly a buggy cross compilker [14:28] <nevcairiel> the gcc is kinda old doing it, but in general cross compiling should be fine, how well qemu then emulates the actual fate execution is another matter [14:29] <cehoyos> michaelni: The computer is already running fate, I would expect to loose my login if I suggest a second client ;-( [14:33] <cehoyos> nevcairiel: I had to leave after opening ticket 2441, you had a question about the sample (your sample) that I did not understand. Do you remember? [14:34] <nevcairiel> nothing of consequence, i was mostly wondering which part of the file you managed to cut to make it reproduce, but was only curiousity [14:35] <michaelni> nevcairiel, it fails during linking not qemu [14:36] <cehoyos> I am just curious what you meant with "which part of the file": I chose the part that allowed to reproduce the problem... (or do I misunderstand?) [14:36] <nevcairiel> and i was wondering which part that was, because i didnt find it =p [14:36] <nevcairiel> but it doesnt matter [14:37] <cehoyos> Or in other words: I was curious why you didn't cut the sample ;-) [15:05] <michaelni> cehoyos, i upgraded ia64 binutils, maybe that will fix it [15:06] <cehoyos> Good idea! [15:08] <funman> cehoyos: btw https://trac.videolan.org/vlc/ticket/8453 is closed (i noticed you added yourself to cc list) [15:11] <michaelni> BuxiNess, Theres possibly a memleak in jpeg2000dec see (http://fate.ffmpeg.org/report.cgi?time=20130428054135&slot=x86_64-archlinux-gcc-valgrindundef) [15:12] <ubitux> i don't get why gif leak btw [15:13] <ubitux> it seems the extradata ref is lost somewhere [15:13] <ubitux> actually, side_data sorry [15:14] <BuxiNess> michaelni, I have and idea form where it comes ( unitialzed data from valgrind) I'll propose a patch [15:14] <cehoyos> funman: I was wondering if this problem was FFmpeg-related somehow: After all, I cannot reproduce it with MPlayer. [15:17] <cehoyos> funman: Or is this just the "planar" issue? In this case, I find the ticket badly named (and missing information). [15:17] <michaelni> BuxiNess, also the jpeg2000 dcinema test is broken on big endian as the checksums from xyz12be of course differ from xyz12le [15:19] <BuxiNess> michaelni, yes that big endian imply some modif in swscale as I understood. kinda blacl magic for me :-) [15:35] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:f5cca47fdec0: sws: extend packed_16bpc_bswap code to handle planar formats [15:38] <funman> cehoyos: nope it was a vlc issue related to demuxers giving wrong pts [15:38] <funman> same pts for consecutive audio packets [15:44] <cehoyos> So it was not libavcodec-related at all? [15:51] <funman> it was libavcodec-vlc-module related [15:52] <funman> and now i'm chasing a bug in same libavcodec-vlc-module related to video [15:52] <cehoyos> Which one? [15:53] <funman> https://trac.videolan.org/vlc/ticket/8320 [15:55] Last message repeated 1 time(s). [15:56] <cehoyos> Did you also test compilation with FFmpeg? [15:57] <funman> not yet [15:58] <funman> cannot load module `/home/fun/.local/vlc/lib/vlc/plugins/codec/libavcodec_plugin.so' (/home/fun/.local/ffmpeg/lib/libavcodec.so.55: version `LIBAVCODEC_54' not found (required by /home/fun/.local/vlc/lib/vlc/plugins/codec/libavcodec_plugin.so)) [15:58] <funman> i need to recompile :/ [15:59] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:7f17e0ff6a2b: sws: add 16bit gbrp formats to packed_16bpc_bswap() [15:59] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:2fa08abdb636: sws: enable xyz12, this for now is just for swaping between le and be [15:59] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:b4fc2a10df3c: fate: fix jpeg2000 on big endian [16:00] <funman> cehoyos: yep, same problem [16:00] <nevcairiel> michaelni: won't sws behave very inconsistently when it claims input/output support, but conversion is actually not supported? [16:01] <nevcairiel> i would rather see fate fail for a while then such inconsistent api [16:01] <michaelni> the fate failure could "hide" other failures [16:01] <funman> we have timestamps jumping backwards in output.. [16:02] <nevcairiel> BE machines are a niche segment as it is, i still think this half-broken api is a good idea [16:02] <nevcairiel> *not a good idea [16:02] <michaelni> i think we should add full xyz support instead of discussing how to deal with its lack [16:03] <nevcairiel> of course, but until thats done, sws is basically half-broken when a xyz file is used [16:03] <michaelni> and before it was fullly not working with xyz [16:04] <nevcairiel> which is better imho, now it will accept a xyz input, and what does it do when i ask it to output yuv? [16:04] Action: michaelni doesnt get why nevcairiel does NOT want it fixed [16:04] <michaelni> its not much work to add full xyz support [16:04] <nevcairiel> i think the behaviour now is worse then the old one [16:05] <nevcairiel> because its inconsistent [16:05] <nevcairiel> so what does sws do when i give it xyz and ask for yuv? [16:05] <nevcairiel> before, it would just refuse, because xyz was no valid input format [16:06] <michaelni> nevcairiel, why do you want to discuss this instead of me working on fixing it completely ? [16:07] <michaelni> ubitux, btw did you succeed with xyz input support ? [16:08] <nevcairiel> because i think its important to be aware that inconsistent api is worse then not having xyz support at all [16:08] <michaelni> ok i wont fix it then [16:08] <ubitux> michaelni: no i didn't look much [16:08] <ubitux> i asked on the fork side if anyone was working on it, but i was ignored [16:09] <ubitux> and since i saw some ppl contributing to sws for that i let them do their work [16:10] <funman> it seems reordered_opaque is not what we want [16:16] <michaelni> nevcairiel, patch on ML to support partially supported formats [16:20] <funman> cehoyos: and fixed! [16:22] <cehoyos> funman: Does it work with FFmpeg now as well? [16:23] <funman> sure [16:25] <funman> cehoyos: btw you know of our points competition? [16:25] <funman> i'm looking at https://trac.videolan.org/vlc/ticket/8486 now and i notice you were on that bug too ^_^ [16:40] <ubitux> michaelni: about xyz, shouldn't we just apply the xyz filter? [16:43] <michaelni> what does that do ? [16:44] <ubitux> pixel convertion from yuv/rgb to xyz and the other way around iirc [16:44] <ubitux> but yeah it belongs in sws [16:45] <michaelni> yeah 1-3h work to add it to sws i guess [16:45] <michaelni> the altarnative with partial support in sws, inserting a filter different from sws for xyz, is ALOT more work [16:47] <BuxiNess> nevcairiel, I know matrix from XYZ to RGB, but to YUV AFAIK they are not ... [16:57] <cehoyos> funman: What is the points competition? [16:58] <funman> cehoyos: http://mailman.videolan.org/pipermail/vlc-devel/2013-April/092841.html [17:33] <beastd> funman: Do you also compile VLC for Windows? If yes do you compile on Windows or cross-compile? [17:34] <funman> beastd: cross compile [17:34] Action: funman thinks this answers the first question as well [17:35] <beastd> funman: ye,s thx. seems cross compiling will be easier. [17:35] <funman> http://wiki.videolan.org/Win32Compile [18:15] <cehoyos> funman: Do you have write access to /incoming ? [18:15] <cehoyos> Could you delete alac_encoding_error_* ? [18:19] <funman> why? [18:20] <cehoyos> The uer uploaded private samples, I cut the relevant part and attached it to the ticket [18:20] <funman> alac_encoding_error_white_noise_burst.* ? [18:21] <cehoyos> Yes. [18:21] <funman> done [18:21] <cehoyos> Merci! [18:21] <funman> :) [18:23] <cehoyos> I don't know if hdd space is an issue: You may delete 2263-slow-ss-full.mkv, we copied it (and have a 2MB sample now) [18:23] <funman> Filesystem Size Used Avail Capacity Mounted on [18:23] <funman> /dev/disk4 931Gi 376Gi 554Gi 41% / [18:23] <funman> should be ok ^_^ [18:32] <zimbatm> ubitux: getting closer: https://gist.github.com/zimbatm/5473549#file-bisect-2-txt [18:33] <zimbatm> over time ffmpeg producing 5350 then 5390 then 6728 moov headers [18:33] <zimbatm> i'm now bisecting to find what caused the jump to 6k [18:33] <ubitux> ok :) [18:34] <zimbatm> thanks for listening :) [18:35] <ubitux> np ;) [18:44] <BBB> fyi recent (dev) versions of libclang will crash c99-to-c89, this is a bug in libclang, they intend to have it (libclang) fixed in a few days [18:45] <BBB> in case you get any bug reports [18:45] <ubitux> i think the main bug right now is: http://download.videolan.org/pub/contrib/c99-to-c89/ [18:46] <BBB> that one seems fixable [18:46] <funman> yeah some files have been disappearing from the ftp for some reason.. [18:46] <BBB> and there's no logs of who removed what from where? [18:46] <funman> not that i know [18:46] <BBB> enable logs [18:46] <BBB> and ban the funny guy removing random files [18:47] <BBB> also disclose it publicly to make it impossible for mr. funny guy to ever find a job again [18:47] <funman> it wasn't me :( [18:47] <ubitux> and force him to contribute to mplayer instead of vlc as a punishment [18:47] <BBB> i said funny guy, not funny man :) [18:47] <funman> j-b: ping, how would you like to contribute to mplayer? [18:48] <BBB> lol [18:48] <JEEB> ouch, c99conv binaries removed? [18:48] <ubitux> :D [18:48] <BBB> chrome has binaries also [18:48] <BBB> use these [19:03] <funman> j-b: any news about the files getting deleted from ftp ? [19:39] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:42a7938cca14: fate: temporary disable jpeg2000 test to avoid fate breakage from next commits [19:39] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:45f1cf88a85c: sws: remove hack to support partial convert / xyz bswaping [19:39] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:0c47c9028be2: sws: support xyz input [19:39] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:24ec7a5e049e: sws: Check for malloc failure of rgb0_tmp [19:39] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:54429142c596: fate: re-enable jpeg2000 test with rgb48le [19:40] <michaelni> nevcairiel, xyz input support added to sws, hack removed [19:41] <ubitux> yay [19:41] <ubitux> :) [19:43] <ubitux> nice.. [19:45] <BuxiNess> nice ! [19:48] <j-b> nice [19:50] <ubitux> michaelni: for the blue is this correct? [19:50] <ubitux> [2][0] [1][2] [2][2] ’ i think it might be [2][0] [2][1] [2][2] [19:56] <ubitux> (the xyz2rgb_matrix indexes for blue) [19:57] <michaelni> ubitux, can be, i just took that from vf_xyz2rgb, didnt check it [19:58] <michaelni> ubitux, do you want to change it or should i ? [19:59] <ubitux> no don't change it [19:59] <ubitux> it might be correct [19:59] <ubitux> even thought it intuitively looks incorrect [20:00] <michaelni> the colors look better IMHO with the change [20:00] <ubitux> ah? :p [20:02] <ubitux> might be worth contacting the author about that thing [20:07] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:cb23b06e5e26: sws: fix typo in xyz2rgb matrix use. [20:09] <michaelni> BuxiNess, you had a typo in the matrix indexes in xyz2rgb, not sure where it came from, if it was from Matthias Buercher then he probably should be informed about that, i dont know his email address [21:32] <cehoyos> Is ;5:A0=4@ asking for H264 or H265 encoding? [21:37] <JEEB> since H.265 is not used by anything yet (barely an ITU-T recommendation since like two weeks), I'd guess H.264 [21:41] <cehoyos> JEEB: I don't think so.... [21:45] <JEEB> it's the "used on channels" guy, right? [21:45] <JEEB> I'm pretty sure there are zero channels that use HEVC/H.265 at this moment [21:45] <JEEB> he either wants AVC/H.264 or he is very confused [21:48] <ubitux> "This year will be the presentation of the technology" [21:48] <ubitux> "latest technology" [21:48] <ubitux> i'm not sure that's h264 he's refering to [21:48] <nevcairiel> he seems generally very much confused [21:48] <ubitux> :D [21:50] <JEEB> yes, that he is [21:54] <cehoyos> That was my point... [22:51] <zimbatm> ubitux: fc09bf57a60d4c4a6d339b204b3282337067c06d [22:52] <zimbatm> that's the commit that increased the moov size [22:52] <zimbatm> not really sure why though :p [22:52] <ubitux> heh, it's supposed to reduce the size [22:52] <ubitux> michaelni, what have you done @_@ [22:52] <zimbatm> since Nov 29 [22:52] <ubitux> thank you for the bisect [22:53] <zimbatm> do you want the details ? [22:53] <ubitux> i'm not particularly interested in fixing it myself [22:53] <zimbatm> yw, i love running bisects when there is a script doing all the job for me :) [22:53] <zimbatm> ok i'll file a ticket then [22:53] <zimbatm> thanks for listening again :) [22:53] <ubitux> yes, having the regression hash is very helpful, thanks [22:55] <cbsrobot> what's the problem with it ? [22:55] <ubitux> it increases some table sizes in some cases [22:55] <cbsrobot> well and ? [22:55] <ubitux> it increases alot© [22:56] <cbsrobot> ah ok [22:56] <ubitux> (while the commit is supposed to reduce the size afaict) [23:06] <cehoyos> zimbatm: It appears to me that the effect is intended or do I misunderstand? (What about the filesize?) [23:07] <ubitux> cehoyos: it *increases* in some cases [23:07] <zimbatm> hmm i should have kept all versions of the video, the bisect is overriding [23:07] <zimbatm> but the moov header is larger than before for sure [23:08] <cehoyos> ubitux: I thouight a part of the file increases its size (while the file as a whole gets smaller) [23:08] <ubitux> how so? [23:08] <zimbatm> https://gist.github.com/zimbatm/5473549#file-bisect-3-txt [23:08] <ubitux> cehoyos: the muxed data shouldn't change [23:10] <zimbatm> i'm making another run around 77e0c7584b595edcec7bf393c0e77dbcfe2a8cb4 since it got smaller again at that time [23:10] <zimbatm> and going to include the file size [23:10] <zimbatm> i'll be back in a couple of hours :p [23:10] <cehoyos> ubitux: I don't think the muxed data changed. (or did it?) [23:11] <ubitux> of course [23:11] <zimbatm> cehoyos: the muxed data is acopy and vcopy [23:12] <zimbatm> unless you're talking about the container stuff which i don't really understand [23:12] <ubitux> cehoyos: one table might get smaller but causes a large increase of another [23:13] <cehoyos> What about the output file size? [23:13] <ubitux> cehoyos: the size of a moov is only defined by the size of its header [23:13] <ubitux> mov* [23:14] <ubitux> everything is defined in the header [23:14] <ubitux> the a/v data is just a data blob which won't really be affected by the content of the header [23:14] <ubitux> all the header contains the timing, offsets, etc [23:15] <ubitux> and this header is larger, because of one table being insanely big in some situation [23:15] <ubitux> the rest of the file won't change [23:19] <zimbatm> the problem really is that the whole header needs to be loaded before http streaming can start [23:20] <zimbatm> when it's 4 or 8MB is can make quite a slow start [23:21] <zimbatm> i have also looked into compression but it doesn't seem to be supported by all the players [23:21] <zimbatm> and chunking neither [23:39] <cehoyos> zimbatm: Is the problem not reproducible with a 2MB input sample? [23:40] <cehoyos> And I suggets you remove yourself from CC [23:51] <cone-737> ffmpeg.git 03highgod0401 07master:df9117921ac3: lavu/opencl: add check version and platform [23:52] <zimbatm> cehoyos: maybe, initally i wanted to keep all the moov from the original intact in case it would give some ideas [00:00] --- Mon Apr 29 2013