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

[burek]

[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-symbolic-technology-theme-showing-a-welding-torch-tip-and-dashing-flame-burning-a-fixed-hard-disk-wi.jpg
[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