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

[burek]

[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