[00:00] <saste> BTW i'll push ffescape if no one will review/comment in a day [00:01] <saste> people is having an hard time at getting how to escape weird filenames [00:01] <llogan> The Escapist. [00:01] <saste> maybe i should put an escaping intro in filters.texi [00:02] <saste> saste houdini [00:02] Action: llogan recalls some problem with commas in file names...maybe. [00:02] <saste> look ma, i can escape a filename tied to a filterchain [00:03] <saste> llogan: you have to keep in mind that there are two levels of escaping [00:03] <saste> plus the shell escaping [00:04] <cone-609> ffmpeg.git 03Clément BSsch 07a96b39de6225: lavf/srtdec: simplify start/end computation. [00:04] <cone-609> ffmpeg.git 03Clément BSsch 0760d9ee1b75b3: lavc/utils: make sub decode consistent with A/V. [00:04] <cone-609> ffmpeg.git 03Clément BSsch 074d46fd0b3ed1: lavc: add AV_PKT_DATA_SUBTITLE_POSITION side data type. [00:04] <cone-609> ffmpeg.git 03Clément BSsch 07c27b3816e4a7: srt: make the demuxer output SubRip packets. [00:04] <ubitux> commits with "long" descriptions like you seem to appreciate saste ^ [00:05] <saste> well why don't you write lavf/srt then? ;-) [00:06] <ubitux> cause it was a bit related to codec [00:06] <saste> also my religion is against the trailing dot in the first line [00:06] <ubitux> (ok that's a lame excuse) [00:06] <ubitux> ok :( [00:07] <saste> all trasgressors burn in hell for 2^20 years [00:07] <saste> (which is infinitely better than burning in hell for all the eternity) [00:08] Action: ubitux feels lucky [00:13] <cone-609> ffmpeg.git 03Clément BSsch 07fd090a5d0923: lavf/srtenc: simplify timing printing. [00:13] <cone-609> ffmpeg.git 03Clément BSsch 072ecf9492ff3b: lavf/srtenc: set codec to subrip by default. [00:30] <cone-609> ffmpeg.git 03Michael Niedermayer 07aa4782134459: cmdutils: remove writes in never read variable [00:30] <cone-609> ffmpeg.git 03Michael Niedermayer 0758c2c17f1dd2: mov_probe: use correct variable [00:47] <michaelni> ubitux, saste theres a new memleak in lavfi.c (CID739866) [00:47] <saste> new? [00:47] <saste> michaelni, i still have no coverity account [00:48] <ubitux> saste: http://ubitux.fr/pub/pics/_lavfi-leak.png [00:49] <ubitux> saste: have you really checked your spambox? [00:50] <michaelni> saste, nothing in your spam folder ? [01:01] <llogan> i see no saste in "owners" [01:02] <llogan> oh, duh. that's different [01:02] <llogan> i don't know. </ignorant> [01:04] <saste> fuck i deleted all spam by chance [01:05] <saste> but i checked before and couldn't find anything related to "coverity" [01:05] <Daemon404> nice job [01:07] <saste> ok but *that* fix is easy [01:11] <michaelni> saste, ive requested a new account to be created for your gmail address and a seperate one for your poste.it address [01:11] <michaelni> i hope one will go through [01:12] <saste> and yet none arrived... i'll check my poste.it account (i'm not even sure it is still enabled, they were going to close email support) [01:14] <michaelni> well, its just one 2 minutes since so ... [01:39] <cone-609> ffmpeg.git 03Michael Niedermayer 070008e0d6321d: cmdutils: fix unclosed file on error [01:39] <cone-609> ffmpeg.git 03Michael Niedermayer 07ed68085104c2: asfdec: fixed signedness in comparission [01:39] <cone-609> ffmpeg.git 03Michael Niedermayer 074a2297294fa2: qt-faststart: check return of ftello() [01:39] <cone-609> ffmpeg.git 03Michael Niedermayer 07a1af505d6640: roqaudioenc: remove dead code [01:39] <cone-609> ffmpeg.git 03Michael Niedermayer 07fa48da1ee9ce: ffmpeg: fix null ptr deref in psnr printing code [01:52] <llogan> what is the "dmo" in "ffmpeg-dmo" in debian-multimedia? [02:00] <Daemon404> DMO on windows is directshow related [02:00] <Daemon404> no idea what it means for linux [03:00] <durandal_1707> michaelni: why voc demuxer split packets into smaller ones, this makes seeking almost impossible to implement [03:03] <michaelni> i dont know/remember without searching/reading old ML threads, maybe the packets where too large or maybe theres no reason [03:04] <durandal_1707> max possible packet size is 16mb [03:05] <michaelni> thats a bit large [03:05] <michaelni> for audio [03:12] <durandal_1707> michaelni: so how than to make seeking possible? [03:15] <michaelni> if the packets really are that large, then some index can be build that stores whatever [03:15] <michaelni> is needed [03:17] <durandal_1707> and there are functions that can store at least one int per index? [03:27] <durandal_1707> michaelni: the only thing required is the remaining size of chunk for each packet - and i do not see nice way to store it [03:28] <michaelni> you could store the whole packets in the index so the packet size is the remaining size [03:30] <durandal_1707> index is AVIndexEntry? [03:42] <michaelni> probably easiest to use, but something else could be used too in theory [04:17] <cone-609> ffmpeg.git 03Michael Niedermayer 071a535fc477cd: fate: reenable some recently lost audio tests [04:17] <cone-609> ffmpeg.git 03Michael Niedermayer 07d312ffdd79bd: mpegvideo: fix lowres on field pictures [08:22] <nevcairiel> ubitux: how would msys figure out that it needs to replace a string you printed into a file? [08:24] <nevcairiel> it only translates the path if its calling a win32 app, it doesnt translate it when calling a msys builtin [08:26] <nevcairiel> easiest solution would be to just fix the code in the fate script that tries to detect an absolute path [08:27] <nevcairiel> why not simply check if the path exists, and if it does be happy [08:27] <nevcairiel> if it doesnt, try to check if we need to pretent the context [08:27] <nevcairiel> prepend* [08:28] <nevcairiel> that way i could specify a real windows path, and wouldnt need msys conversion [08:53] <ubitux> < nevcairiel> it only translates the path if its calling a win32 app, it doesnt translate it when calling a msys builtin // "ffmpeg.exe" is treated differently than "ls.exe"? [08:55] <nevcairiel> actually, yes [08:55] <nevcairiel> ls.exe is a msys app, while ffmpeg.exe in those fate machines is a native win32 app [08:56] <ubitux> and so, ls.exe /d/foo/bar will receive "/d/foo/bar", while ffmpeg.exe will receive "d:\foo\bar"? pretty weird [08:57] <nevcairiel> pretty much [08:57] <ubitux> mmh. [09:00] <ubitux> nevcairiel: printf '#!/bin/sh\nprintf $@' > ffprintf && chmod +x ffprintf && ./ffprintf '/d/foo/bar' [09:00] <ubitux> what does this print? [09:00] <ubitux> does it needs to be a program? [09:01] <ubitux> if i do the same with a ffprintf.c built with mingw, will it print "d:\foo\bar"? [09:03] <ubitux> printf '#include <stdio.h>\nint main(int ac,char**av){if(ac==2)puts(av[1]);return 0;}' > ffprintf.c && gcc ffprintf.c -o ffprintf && ./ffprintf '/d/foo/bar' [09:03] <ubitux> i'd be curious about what happens in this case [09:05] <ubitux> and sure if you think we should fix the absolute path detection, why not [09:05] <ubitux> unfortunately i can't help much here [09:07] <nevcairiel> the first prints /d/foo/bar [09:07] <nevcairiel> as does the second [09:07] <ubitux> huh? [09:08] <ubitux> then when is supposed to happen the replace? [09:08] <nevcairiel> when you call a win32 app [09:08] <nevcairiel> let me build the second with msvc [09:10] <nevcairiel> build with msvc, the second outputs d:/foo/bar [09:10] <nevcairiel> like i expected [09:10] <ubitux> right ok [09:10] <ubitux> so. [09:11] <ubitux> if i add this stupid ffputs to the tools [09:11] <ubitux> it will work, right? :) [09:12] <ubitux> (yes I know it's ugly) [09:15] <nevcairiel> if that tool is build with msvc during the fate process, it will do what you want [09:16] <ubitux> i guess all the tools are [09:16] <ubitux> at least i hope so :p [09:16] <nevcairiel> one would think so [09:16] <nevcairiel> what else would be there to build it [09:16] <nevcairiel> anyway, meeting [13:26] <cone-621> ffmpeg.git 03Martin Storsjö 07c44cef978bd5: smoothstreamingenc: Don't assume streams start from timestamp 0 [13:26] <cone-621> ffmpeg.git 03Mans Rullgard 07d4c99513f412: configure: generalise 64-bit test [13:26] <cone-621> ffmpeg.git 03Mans Rullgard 072acda282eb8e: configure: detect mips64 automatically [13:26] <cone-621> ffmpeg.git 03Mans Rullgard 0756203596aea3: configure: detect ppc64 automatically [13:26] <cone-621> ffmpeg.git 03Mans Rullgard 07a6e9d6497739: configure: detect parisc64 automatically [13:26] <cone-621> ffmpeg.git 03Diego Biurrun 075bac2d0c3020: avutil: Move memcpy_backptr() to mem.c [13:26] <cone-621> ffmpeg.git 03Diego Biurrun 072a91ada8282f: avutil: Make LZO decoder code configure-time selectable [13:26] <cone-621> ffmpeg.git 03Michael Niedermayer 07aa604e8e33ae: Merge remote-tracking branch 'qatar/master' [13:46] <nevcairiel> ubitux: ignore the path replacement issue for now, its a purely fate thing, no-one sane should be calling a msvc ffmpeg.exe with a absolute msys-style path [13:46] <nevcairiel> i'll figure otu a way to adjust my fate setup with relative path or something [13:46] <nevcairiel> only remaining problem is the colon parsing [13:49] <ubitux> this one is solved [13:49] <ubitux> but ok, i'll wait for your patch [14:00] <cone-621> ffmpeg.git 03Michael Niedermayer 07da4e4d65f456: aacdec: reorder multiuplications to make code safer against too large input values. [14:00] <cone-621> ffmpeg.git 03Tomas Härdin 075c108092a34e: mxfenc: Write MultipleDescriptor ref in Preface [14:15] <durandal_1707> it is possible to dynamicaly (while reading packets) adding seek index entries? [14:16] <nevcairiel> it is, i believe some demuxers also do that [14:37] <nevcairiel> ubitux: tada! http://fate.ffmpeg.org/report.cgi?time=20121025123604&slot=x86_32-msvc10-windows-native [14:37] <nevcairiel> just some path values shuffled around and suddenly it works [14:38] <ubitux> yay [14:38] <ubitux> magic [14:38] <divVerent> I hope this %3a thing is a bug in FATE ;) [14:38] <ubitux> yes [14:39] <ubitux> i have the issue with the shared box as well [14:39] <nevcairiel> its somewhat irritating that i had to set a target path [14:39] <nevcairiel> but if i dont, it uses a msys style path there [14:39] <nevcairiel> and we're back where we started =p [14:40] <nevcairiel> ok updating config for the 64-bit fate instance, and everything is good [14:41] <ubitux> did you have to patch anything in the tests? [14:41] <nevcairiel> no [14:41] <nevcairiel> it was just some terrible interaction between all the different scripts involved [14:42] <nevcairiel> next i should setup a shared msvc box, but the damn aac encoder still doesnt compile [14:43] <nevcairiel> i should use those new fancy fate macros to add a dependency so i can just turn it off [14:44] <ubitux> i don't understand how it can work [14:44] <ubitux> :D [14:45] <ubitux> but ok [14:45] <nevcairiel> what work? [14:45] <ubitux> "movie='d:\foo\bar'" becoming "movie=d:\foo\bar" [14:45] <ubitux> i wonder how you solved that [14:46] <nevcairiel> i have no idea [14:46] <nevcairiel> all i did was make sure its actually d:\foo\bar and not /d/foo/bar [14:47] <ubitux> :/ [14:47] <ubitux> you didn't kept my patch in, right? [14:48] <ubitux> that's insane how can it work.. [14:49] <nevcairiel> clean head, no patch [14:49] <nevcairiel> the only changes i did was to my script that runs fate and the fate config script [14:49] <nevcairiel> just changed the parameters for samples and target_path [14:50] <ubitux> ok& [14:50] <ubitux> then i don't get it [14:50] <ubitux> :D [14:50] <nevcairiel> maybe the sample is passed with a relative path now? [14:50] <nevcairiel> because my SAMPLES is relative [14:50] <ubitux> oh. [14:50] <nevcairiel> "../../samples" to be precise [14:51] <ubitux> that's the reason yes [14:51] <ubitux> right ok [14:51] <ubitux> you're just avoiding the issue then :p [14:51] <nevcairiel> yay me [14:51] <nevcairiel> :P [14:51] <ubitux> :)) [14:52] <nevcairiel> supporting absolute windows style path in single quotes should still work, i guess [14:52] <ubitux> it doesn't work [14:52] <ubitux> except in an external file [14:52] <nevcairiel> i know, but it should [14:52] <nevcairiel> ;) [14:53] <ubitux> it might work with double escaping [14:53] <ubitux> like saste pointed out the other day [14:54] <ubitux> nevcairiel: anyway, thanks for the workaround [14:54] <nevcairiel> couldnt let my fate box being broken all this time [14:57] <ubitux> is there any way to communicate from the encoder to the muxer? [14:58] <nevcairiel> side data? :D [14:58] <nevcairiel> its just a avpacket afterall [14:58] <ubitux> yeah but i don't have the packet in the encoder.. [14:58] <ubitux> well, subtitles& [14:58] <nevcairiel> oh subtitles [14:58] <ubitux> !#$% [14:59] <nevcairiel> a/v got avpackets in their encoders..... :p [15:00] <ubitux> i guess i'll have to create a new function encode function [15:10] <cone-621> ffmpeg.git 03Paul B Mahol 07296f9c2b3bc2: dsicinav: return meaningful error code [15:50] <cone-621> ffmpeg.git 03Paul B Mahol 07d8245c3bcdd1: dsicinav: return proper error code in case of malloc failure [15:50] <kriegerod> In my app the video muxing process is of non-monotonic intensity, but "bursty". I mux portions from one keyframe to next one at once. Output is often transmitted by UDP, and output stream has high peaks of bitrate, which leads to loss. I think about adding functionality of smoothing output bitrate for UDP URLProtocol. Could anybody help with algorithm? [15:54] <Tjoppen> VBV [15:54] <Tjoppen> though I don't know how to use it [15:59] <michaelni> setting maxrate and bufsize enabled VBV [16:12] <mateo`> is there a formula to compute the buffer size for mpeg2video ? [16:13] <kriegerod> VBV must be an algorithm? Could you please say what this abbrev stands for, because i cant google it [16:14] <michaelni> video buffer verifier [16:14] <michaelni> also you can leave the buffer size 0 with latest ffmpeg and it will try to pick something reasonable [16:15] <michaelni> but basically the maxrate specifies the maximum bandwith that should be used the the bufferf size the maximum latency/delay [16:15] <michaelni> s/the the/and the/ [16:27] <cone-621> ffmpeg.git 03Justin Ruggles 07d7de11260bd1: ac3dec: ensure get_buffer() gets a buffer for the correct number of channels [16:27] <cone-621> ffmpeg.git 03Michael Niedermayer 079a76b7375eaa: avsdec: Set dimensions instead of relying on the demuxer. [16:27] <cone-621> ffmpeg.git 03Anton Khirnov 079e575e54a057: dfa: check that the caller set width/height properly. [16:27] <cone-621> ffmpeg.git 03Paul B Mahol 0712941dbe2cc7: dfa: convert to bytestream2 API [16:27] <cone-621> ffmpeg.git 03Kostya Shishkov 072281ac9ffd28: dfa: add some checks to ensure that decoder won't write past frame end [16:27] <cone-621> ffmpeg.git 03Kostya Shishkov 07d0267ecf768b: dfa: use more meaningful return codes [16:27] <cone-621> ffmpeg.git 03Anton Khirnov 070c19855539d7: dfa: improve boundary checks in decode_dds1() [16:27] <cone-621> ffmpeg.git 03Kostya Shishkov 07965302c9f336: indeo: check custom Huffman tables for errors [16:27] <cone-621> ffmpeg.git 03Kostya Shishkov 07911c250aef9f: factor out common decoding code for Indeo 4 and Indeo 5 [16:27] <cone-621> ffmpeg.git 03Kostya Shishkov 07e0daa15a96cf: indeo: track tile macroblock size [16:27] <cone-621> ffmpeg.git 03Kostya Shishkov 07b561618014a2: indeo: clear allocated band buffers [16:27] <cone-621> ffmpeg.git 03Kostya Shishkov 07c5ec19085978: indeo: check for invalid motion vectors [16:27] <cone-621> ffmpeg.git 03Michael Niedermayer 07fe8243d7a9e3: Merge commit 'c5ec1908597824e93bbe20137ac9662f84f3cb07' into release/0.10 [16:38] <cone-621> ffmpeg.git 03Anton Khirnov 07332555f66049: ivi_common: make ff_ivi_process_empty_tile() static. [16:38] <cone-621> ffmpeg.git 03Anton Khirnov 070815d9174c48: indeo4/5: check empty tile size in decode_mb_info(). [16:38] <cone-621> ffmpeg.git 03Michael Niedermayer 07dc8371b2b12f: indeo5dec: Make sure we have had a valid gop header. [16:38] <cone-621> ffmpeg.git 03Janne Grunau 073efe6becc79b: indeo5: prevent null pointer dereference on broken files [16:38] <cone-621> ffmpeg.git 03Michael Niedermayer 075c413648c148: indeo5: check tile size in decode_mb_info(). [16:38] <cone-621> ffmpeg.git 03Anton Khirnov 071c8e2561b489: indeo3: fix out of cell write. [16:38] <cone-621> ffmpeg.git 03Michael Niedermayer 0714bba214fa9a: lagarith: check count before writing zeros. [16:38] <cone-621> ffmpeg.git 03Michael Niedermayer 076744eee1e5bf: wmaprodec: check num_vec_coeffs for validity [16:38] <cone-621> ffmpeg.git 03Anton Khirnov 070582b8e3eabb: avidec: use actually read size instead of requested size [16:38] <cone-621> ffmpeg.git 03Michael Niedermayer 072bc1e4fcb96c: indeo4: update AVCodecContext width/height on size change [16:38] <cone-621> ffmpeg.git 03Michael Niedermayer 072051adbfa008: cavsdec: check for changing w/h. [16:38] <cone-621> ffmpeg.git 03Anton Khirnov 0715c2e8027f48: wav: do not fail on empty INFO tags [16:38] <cone-621> ffmpeg.git 03Michael Niedermayer 0736487066ee04: Merge commit '15c2e8027f4827018608badb1bff1294af1810e4' into release/0.10 [16:42] <j-b> michaelni: if a user wants to use min/max, and no rc-buf-size, well, maybe VLC is not the right too [17:02] <ludde> When muxing a .ts file, are you allowed to split a single h264 frame into two separate PES packets? [17:03] <av500> yes [17:04] <av500> erm [17:04] <av500> not sure [17:04] <av500> :) [17:04] <ludde> ok :) [17:05] <michaelni> ludde, normally anything can be split in multiple PES packets, if you want to be 100% sure check the spec about h264 in ts [17:05] <av500> but I think you dont need to have frames strictle aligned to PES start [17:05] <ludde> michaelni: do you know the number of that spec? [17:06] <ludde> which frame does the PTS in the PES refer to, if the PES is not right before the frame? [17:06] <michaelni> H.222 is one mpeg systems something the other but their content should be the same [17:06] <JEEB> doesn't a recent enough H.222/MPEG-TS spec cover that? I think I saw quite a few references in a recent'ish version of the mpeg-ts spec [17:06] <JEEB> (towards H.264) [17:07] <michaelni> the PTS in PES refers to the first AU that comences in that PES [17:07] <nevcairiel> there is Annex B in 14496 Part 10, which covers how the h264 bitstream should be formed, dunno if it mentions such information as well [17:08] <JEEB> yes, there's that too but that's general info IIRC [17:08] <ludde> would this be valid .tse: [17:08] <ludde> sorry, .ts: [17:09] <ludde> Ts Packet 1: <PES HEADER FOR THE PPS/SPS STUFF> PPS/SPS STUFF> <INITIAL DATA OF FRAME 1> [17:09] <ludde> Ts Packet 2: <PES HEADER FOR FRAME 1> <MORE DATA OF FRAME 1> [17:10] <ludde> or worse: [17:10] <cone-621> ffmpeg.git 03Michael Niedermayer 07592ba6781558: alsdec: Check k used for rice decoder. [17:10] <cone-621> ffmpeg.git 03Michael Niedermayer 070f81057c1251: alsdec: Check that quantized parcor coeffs are within range. [17:10] <cone-621> ffmpeg.git 03Thilo Borgmann 07c5f9c272e9df: alsdec: Fix out of ltp_gain_values read. [17:10] <cone-621> ffmpeg.git 03Mans Rullgard 07c28e1c12adf4: alsdec: remove dead assignments [17:10] <cone-621> ffmpeg.git 03Thilo Borgmann 07dc5283dffcd4: alsdec: fix number of decoded samples in first sub-block in BGMC mode. [17:10] <cone-621> ffmpeg.git 03Michael Niedermayer 073c55bf1201ac: vc1dec: check that coded slice positions and interlacing match. [17:11] <cone-621> ffmpeg.git 03Sean McGovern 07a2d4d9f4fbe1: wmapro: prevent division by zero when sample rate is unspecified [17:11] <cone-621> ffmpeg.git 03Anton Khirnov 075acd1c6561c0: avidec: return 0, not packet size from read_packet(). [17:11] <cone-621> ffmpeg.git 03Anton Khirnov 07141d4ed6c091: cmdutils: avoid setting data pointers to invalid values in alloc_buffer() [17:11] <cone-621> ffmpeg.git 03Ronald S. Bultje 0779fb7bc667dd: h264: fix deadlocks on incomplete reference frame decoding. [17:11] <cone-621> ffmpeg.git 03Justin Ruggles 075920d00d7417: libvorbis: fix use of minrate/maxrate AVOptions [17:11] <cone-621> ffmpeg.git 03Justin Ruggles 0724025cc0b972: libvorbis: use VBR by default, with default quality of 3 [17:11] <cone-621> ffmpeg.git 03Anton Khirnov 07be209bdabb11: vf_pad: don't give up its own reference to the output buffer. [17:11] <cone-621> ffmpeg.git 03Michael Niedermayer 07d6a55ab016f0: Merge commit 'be209bdabb11c59de17220bdbf0bf9c9f7cc16f5' into release/0.10 [17:19] <ludde> can you assume that the whole PES header always fits in a single .ts packet? [17:20] <nevcairiel> isnt a pes header rather short? [17:20] <ludde> yes, but it may contain padding [17:27] <cone-621> ffmpeg.git 03Franz Brauße 07443f1463c0e1: smacker audio: sign-extend the initial 16-bit predicted value [17:27] <cone-621> ffmpeg.git 03Anton Khirnov 07d792be5681b4: yuv4mpeg: return proper error codes. [17:27] <cone-621> ffmpeg.git 03Anton Khirnov 070b923a2b72c1: vf_pad/scale: use double precision for aspect ratios. [17:27] <cone-621> ffmpeg.git 03JindYich Makovi ka 079822e3aa52d1: h264: avoid stuck buffer pointer in decode_nal_units [17:27] <cone-621> ffmpeg.git 03Luca Barbato 070f3381ad5bff: mpegaudiodec: fix short_start calculation [17:27] <cone-621> ffmpeg.git 03Alex Converse 078076d32f3092: tiffenc: Check av_malloc() results. [17:27] <cone-621> ffmpeg.git 03Reinhard Tartler 07ca8c814970a9: Prepare for 0.8.4 Release [17:27] <cone-621> ffmpeg.git 03Anton Khirnov 07a0f6c93f52f8: lavc: remove stats_out from the options table. [17:27] <cone-621> ffmpeg.git 03Reinhard Tartler 072c8ce46250ff: Update Changelog for the 0.8.4 Release [17:27] <cone-621> ffmpeg.git 03Mans Rullgard 076365b43295a0: svq3: replace unsafe pointer casting with intreadwrite macros [17:27] <cone-621> ffmpeg.git 03Michael Niedermayer 07988910a277f1: Merge remote-tracking branch 'qatar/release/0.8' into release/0.10 [17:27] <ubitux> mmh it's missing the branch! [17:46] <burek> Can any developer give an answer to this question: http://ffmpeg.gusari.org/viewtopic.php?f=13&t=705 [17:47] <burek> if you don't want to register on the forum, just answer here, I'll copy/paste it [17:48] <av500> he was here yesterday [17:48] <av500> [17:48:22] <frank_stl> Hi, We are developing one ffmpeg feature. So the update of ffmpeg is important to us. Just wondering does anybody know what is expected date of next ffmpeg version release? [17:48] <av500> [17:49:58] <saste> frank_stl, one release every 6 months more or less, which feature are you implementing? [17:49] <burek> oh I see, ok :) thanks [17:53] <michaelni> and the 6 month is still wrong [17:56] <av500> lets repeat it a few times then :) [19:40] <cone-621> ffmpeg.git 03Martin Ettl 07cc72d52dc1ed: ffserver: fix printf argument type [19:45] <durandal_1707> ubitux: you work on supporting caption tracks? [19:46] <cone-621> ffmpeg.git 03Nicolas George 0777a72d348519: lavfi/vf_fps: allow to set the rounding method. [19:51] <ubitux> durandal_1707: not right now [19:51] <ubitux> why? [19:52] <JEEB> if anyone wants an excersize in masochism you could try implementing ARIB STD-B 24 captions [19:54] <ubitux> i belive the priority would be teletext and the 6xx/7xx (i don't remember the numbers) [19:55] <JEEB> naturally, since USfags use those [19:55] <ubitux> but i have other projects in mind :p [19:55] <ubitux> i'd better design the AST sub rect type [19:56] <ubitux> and then insert that stuff in lavfi [19:56] <JEEB> there are a couple of half-baked ARIB caption implementations, but nothing has gotten to the mainstream things yet [20:00] <cone-621> ffmpeg.git 03Alexis Ballier 07ce028ab9a798: Restore installation of libavutil/lzo.h after 2a91ada8282f18d2807abee5188225bba1b19bda [20:03] <durandal_1707> seems i cant fined pts/dts when transcoding pcm in wav to wav or any other format [20:03] <durandal_1707> s/fined/fix [20:18] <cone-621> ffmpeg.git 03Nicolas George 0748ec8b25a7de: lavfi/af_volumedetect: print stats in uninit(). [21:06] <durandal_1707> what speech codec support 8k,12k and 16k sample rate? [21:12] <gnafu> durandal_1707: Opus does, doesn't it? Also, it looks like Speex does 8 and 16. [21:15] <durandal_1707> zvr files i'm exploring appears to use g729 like codec - which use 8k only AFAIK while file is in 16k [21:29] <cone-621> ffmpeg.git 03Janne Grunau 07cc88dacc1aa3: g722enc: fix size argument in memset [21:29] <cone-621> ffmpeg.git 03Janne Grunau 07c279e37e901e: flashsv: propagate inflateReset() errors [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 070b9d46434894: swscale-test: fix freeing of uninitialized variable [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 07ba10ea845f41: asrc_aevalsrc: Fix use of uninitialized pointer inside av_strtok() [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 077450a0215ae2: ffprobe: fix use of uninitialized pointer in av_strtok() [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 078a525e4d18c5: av_tempfile: fix leak in error case [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 07d12bf6fc9e7e: libvpxenc: fix memleak on error path [21:29] <cone-621> ffmpeg.git 03Paul B Mahol 07c9df500190ee: bmp: unbreak non BMP_RGB compression for v4 and v5 [21:29] <cone-621> ffmpeg.git 03Paul B Mahol 07e6dfaf7bb89a: truemotion2: remove unreachable code [21:29] <cone-621> ffmpeg.git 03Paul B Mahol 0746c1e5de58ac: yop: check return value of avformat_new_stream() [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 07f2d56c2eebe6: motion_est: more complete SAB diamond size check [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 078b64036038e2: aacsbr: change order of operation to prevent out of array read [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 073038e2041e87: ffserver: prevent nb_streams from becoming too large [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 077a0e5a63d01b: vf_fade: fix memleaks of args [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 07db4903f4e4b5: ffv1: avoid checking a double for equality [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 07c09b4dde3776: wtvdec: fix memleak on error [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 07fa73f547a023: jpegls: fix off limit [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 0735b15a0da849: jpegls: increase run_index to 4 [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 0712801f969bf5: trasher: check seek return value. [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 0793a0dd8358ee: ffeval: avoid folding EOF onto a valid char [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 07de4606a5b798: pp: avoid overflow in w*h [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 07cff9f07d391f: ffv1: make sure gob_count is not 0 [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 07400b23beab0a: dnxhddata_ Fix mixup of sizeof() and array elements in ff_dnxhd_find_cid() [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 07e6fa08f14efd: flashsv: check deflateInit() return value [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 0775a11e950fc4: mpegvideo: fix motion_val checks [21:29] <cone-621> ffmpeg.git 03Thilo Borgmann 077f1fb8d2a367: alsdec: fix clipping of weightings for MCC decoding [21:29] <cone-621> ffmpeg.git 03Michael Niedermayer 075b5e61a0bf0d: noise_bsf: fix division by 0 [21:30] Action: michaelni notes that cone does not list the branch commits get pushed to [21:36] <funman> michaelni: you should ask thresh [21:39] <cone-621> ffmpeg.git 03Stefano Sabatini 07b19bfd6c9f42: lavd/lavfi: fix leak in case of failure [21:40] <durandal_1707> what is going on? heads should get ripped of and necks ... [22:10] <ubitux> saste: hey :) [22:10] <ubitux> saste: in the showspectrum patch comment, you were talking about negatic logic [22:11] <ubitux> what were you talking about? [22:12] <saste> if (!expr) { ... } else ... rather than if (expr) { ... } else [22:12] <ubitux> oh, ok. [22:13] <ubitux> saste: do you mind if i keep the local variable to "sliding" and just rename the option to "slide"? [22:13] <michaelni> saste, did you get your coverity account ? [22:14] <saste> ubitux, i prefer a consistent "slide", but do as you want provided you keep an external consistent interface [22:14] <saste> michaelni, no [22:15] <michaelni> did you check both mail addresses ? [22:15] <michaelni> the accounts definitly have been created [22:19] <cone-621> ffmpeg.git 03Clément BSsch 0713d26716fb58: lavfi/showspectrum: add sliding mode. [22:22] <saste> michaelni, nothing, in both accounts [22:25] <michaelni> saste, try the "forgot password button" on http://scan5.coverity.com:8080 [22:25] <michaelni> username should be saste for gmail and saste2 for poste.it [22:26] <michaelni> if that fails too ill mail them [22:26] <michaelni> also keep in mind the coverity mails tend to get marked as spam [22:32] <cone-621> ffmpeg.git 03Michael Niedermayer 0736982b361672: Update for 0.10.6 [22:33] <saste> michaelni, bingo [22:37] <saste> michaelni, 39747d87d09079371b75092ba979ca460536f646 is broken in many ways [22:38] <saste> checking for a literal string in a filtergraph is just wrong [22:38] <saste> also, why was it added? [22:39] <saste> also, a scale algo is not a flag, we should really fix that [22:39] <michaelni> because fate fails on all non x86 platforms without it (see 2d11ee4bfc7cf8c04e40782fc73d72a3d4f0e246) [22:40] <michaelni> you should be able to reproduce the failure with --disable-asm [22:40] <ohsix> hashes are awesome [22:41] <saste> for the lavfi device i suggest to implement a lavfi option, -scale_sws_flags [22:41] <michaelni> ohsix, b6e158edf34b64b2baf154f7a9e6c46a [22:41] <ohsix> i meant the other ones :p you can google them and they pretty much always reference the same thing, too [22:42] <ohsix> as a general principle, that's pretty handy [22:42] <saste> also adding flags to the scale args in the application/filtergraph code is brittle [22:42] <saste> we need a better mechanism [22:43] <michaelni> if we add it to the lavfi device its still missing when something else uses it [22:43] <saste> we could even access the filtergraph field from the scale filter [22:47] <saste> i'd keep generic filtergraph options separated from the filtergraph description [22:47] <saste> if not, embedding the options in the filtergraph text and doing a strstr is not correct, anyway [22:48] <michaelni> you could add a AVDictionary to the graph and a filter that just puts its args there so a setglobal=swsflags;abcd would do the trick [22:49] <saste> michaelni, AVDictionary? for what purposes? [22:49] <saste> what should it store [22:50] <michaelni> flags for autoinserted filters [22:50] <michaelni> for example [22:50] <michaelni> scale is one [22:50] <michaelni> resample another [22:50] <michaelni> there might be more in the future [22:50] <saste> uhm something like scale=sws_flags=... [22:51] <saste> scale is the key, the auto-inserted options may be the values [22:51] <saste> migth work [22:51] <saste> also we may need to specify the instance name of a filter [22:52] <michaelni> i dont see why [22:52] <saste> so that the user can properly send command to a given specific instance [22:52] <saste> suppose you have many instances of the same filter, and you want to send a command at a specific one [22:52] <michaelni> its about global falgs [22:52] <michaelni> flags [22:53] <saste> relying on the automatically assigned name (parsed_scale_ etc) is not robust [22:53] <michaelni> if you want flags for a specific instance one could just put a scale=... there [22:53] <saste> no i mean with *commands* [22:53] <michaelni> also "scale=sws_flags=..." needs thought, that syntax is not good [22:53] <michaelni> double = = i mean [22:53] <saste> i agree [22:54] <saste> also if you want to specify more options, that would require a third level of escaping [22:55] <saste> e.g scale=iw*2:ih*2:sws_opts='sws_flags=+bitexact:sws_algo=lanczos' [22:56] <saste> that's getting easily clunky [22:57] <saste> ubitux: i want to rename asetnsamples to asetframesize [22:57] <saste> never liked that name [22:58] <cone-621> ffmpeg.git 03Paul B Mahol 0743f662d9bf69: lvfdec: cosmetics: fix identation [22:58] <michaelni> sws_opts='sws_flags=+bitexact:sws_algo=lanczos' <--- this is sick [22:59] <michaelni> sws_flags=+bitexact+lanczos [22:59] <saste> algo != flag [22:59] <saste> algo should be set like a constant, it is semantically not a flag [23:00] <michaelni> then its [23:00] <michaelni> sws_flags=+bitexact:sws_algo=lanczos [23:00] <michaelni> but not [23:00] <michaelni> sws_opts='sws_flags=+bitexact:sws_algo=lanczos' [23:01] <saste> how are we doing in aresample? [23:01] <saste> scale takes additional options which are not forwarded to the sws context [23:01] <ubitux> saste: i don't like asetframesize that much, but whatever [23:02] <saste> so you need to embed sws options into a separate "value", but maybe i'm wrong [23:02] <saste> that in the case you need more options to set, right now we only set the flags [23:03] <saste> ubitux: why not? [23:04] <michaelni> theres no need to seperate the 2levels, either the option is handled by vf_scale.c or sws [23:05] <saste> michaelni, i suppose that's possible, if there is no conflict possibility [23:05] <michaelni> well we are controling both vf_scale and sws so i guess we should manage not to make the 5 options in vf_scale conflict with the 5 in sws [23:07] <saste> michaelni, a general namespacing system may be useful, especially for the movie where we may want to specify codec/format/proto options in a transparent way [23:07] <michaelni> the whole escaping thing is mad [23:08] <saste> michaelni, ? [23:08] <michaelni> the only escaping that should be needed should be for the shell when parameters like strings or filenames need excaping [23:10] <michaelni> and for the end character(s) in strings or filenames [23:10] <saste> michaelni, there are special chars in the filtergraph (;,) and in the filter description (: for separating options) [23:10] <saste> right now we have two levels of escaping, that sucks but I can't see how you can improve things [23:11] <saste> note that alternative syntaxes (e.g. avisynth) don't have this problem [23:12] <ubitux> saste: because i find frame size very vague [23:12] <ubitux> size is not a number of samples, it's more like a byte size [23:12] <saste> ubitux, the thing is that i plan to add a size option [23:13] <saste> so you can say: asetframesize=z=10KiB [23:13] <ubitux> aclip? :) [23:13] <saste> it still make sense to say: asetframesize=n=1000 [23:13] <saste> but saying: asetnsamples=z=10KiB doesn't [23:16] <michaelni> saste, if avisynth doesnt have this problem then quite obviosuly it can be improved [23:16] <saste> michaelni, both syntaxes have their strong points ;-) [23:17] <saste> the ffgraph syntax was designed to express *simple* graphs on the command line [23:17] <saste> avisynth syntax was designed to be read from a file, where no shell escaping issues occurr, and where you don't need to keep it short [23:18] <saste> we could add another alternative syntax (ffsynth?) [23:19] <ohsix> ffgst [23:20] <michaelni> its hard to argue about this without seeing examples of ffgraph (with whitespace +\n), avisynth and soem proposal of a new syntax or chnages to ffgraph [23:20] <ohsix> why is the shell escape thing even a consideration when you're trying to make something comprehensible [23:52] <cone-621> ffmpeg.git 03Paul B Mahol 0704a585f054ea: fraps: use meaningful error codes [23:56] <cone-621> ffmpeg.git 03Stefano Sabatini 0715f52e50fe37: tools: add ffescape utility [00:00] --- Fri Oct 26 2012