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

[burek]

[00:01] <cone-273> ffmpeg.git 03Peter Ross 07ed27ed9f4f72: iff: DEEP RLE 32-bit decoder
[00:17] <saste> michaelni, what's your opinion about lib*.texi and component manuals?
[00:17] <saste> should we retain lib*.texi if we decide to add e.g. codecs, filters, etc. etc.?
[00:18] <saste> I tend to dislike too many manuals, so I lean towards removing the lib*.texi pages, but I may change idea
[00:34] <michaelni> saste, iam not really a docs person, i only care about it in so far as to keep merging easy for me or you doing the merging, about the docs itself
[00:35] <michaelni> maybe someone like llogan, beastd or someone else would be better to ask
[00:51] <llogan> whatever makes the information most accessible or easiest for the users is most important to me, but of course i don't have to deal with merging.
[00:53] <saste> llogan: provided that libav doesn't adopt the same doc layout, the new docs are not affected by merges
[00:53] <saste> i won't delete the current files exactly for that reason
[00:55] <Compn> could always talk to diego
[00:57] <llogan> you work on the docs more than anyone, AFAIK. i feel as if "you know what you doing".
[00:57] <Compn> you mean saste? :)
[00:58] <llogan> yes
[00:58] <saste> llogan, sometimes I need someone else to judge a design, that provides external validation
[00:59] <saste> also I'm lazy, and I don't want to rush a solution which will need to be revisited later
[01:00] <Compn> theres the problem
[01:00] <Compn>  the devs never read the manual
[01:00] <Compn> have to ask the users saste :)
[01:01] <saste> Compn, I do it all the time, whenever I forget how stuff works
[01:01] <saste> what i mostly dislike right now is that the tools manual pages are huge walls of text
[01:01] <saste> making them more modular should help developers, as well as users
[01:02] <saste> that has also drawbacks, but in general should be easier on the reader
[01:02] <llogan> how would you organize it?
[01:02] <saste> llogan, I wrote several proposals on ML
[01:03] <llogan> ah, i've been away lately. i need to catch up.
[01:06] <llogan> saste: what are the drawbacks?
[01:07] <saste> sometimes you *want* a huge page
[01:07] <saste> so you don't have to go back and forth around several dedicated pages, and it's easier to cross-reference
[01:08] <saste> but my opinion is that the benefits overweight the cons in this case
[01:11] <Compn> no one reads mplayer manual because its huuuuuuuuge :)
[04:06] <cone-300> ffmpeg.git 03Michael Niedermayer 07aed128f07d14: 4xmdec: fix integer overflow, null ptr dereference
[04:06] <cone-300> ffmpeg.git 03Michael Niedermayer 07cf5f4c516963: aacsbr: check sample_rate before using it, fix division by 0
[10:05] <durandal_1707> michaelni: libav is touching planar code in pcm and using memcpy in native to native cases, does that make sense? wouldn't memcpy be slower that current code?
[10:07] <durandal_1707> not mentioning fact about extremly buggy first implementation
[10:10] <durandal_1707> michaelni: btw is it ok to push s8 planar patch that moves code from 8svx to pcm.c where it is more natural place?
[10:10] <durandal_1707> 8SVX_RAW codec is not used by lavf and i gonna push patch that deprecates its bits
[10:46] <cone-209> ffmpeg.git 03Paul B Mahol 07a5e382ad7ffd: 4xm: return error code if decode_init() failed
[10:51] <durandal_1707> we do not need to support borken software
[12:07] <durandal_1707> saste: ok to get rid of 8svx raw?
[12:08] <saste> durandal_1707, I don't follow that code since ages, let me have a look
[12:19] <saste> funny I even have my name in the copyright for 8svx
[12:23] <durandal_1707> you added 8svx_raw but then ruggless added same decoder with different name s8_planar
[12:24] <durandal_1707> i want to move that code to right place : pcm.c
[12:27] <durandal_1707> michaelni, ubitux, saste: link to ffmpeg.arrozcru.org should be removed from documentation - it is spreading wrong information
[12:40] <cone-209> ffmpeg.git 03Paul B Mahol 07da8242e2d6f8: 8svx: move pcm_s8_planar decoder to pcm.c
[12:53] <ubitux> what do you mean by spreading wrong information?
[12:53] <durandal_1707> it mentions link, when you visit that link, it states that is abandoned
[12:54] <durandal_1707> but that linked page links to other pages with stale info about building on windows
[12:54] <ubitux> the link should be changed to http://ffmpeg.zeranoe.com then, right?
[12:54] <ubitux> maybe http://ffmpeg.zeranoe.com/forum/ then?
[12:54] <durandal_1707> ubitux: see #ffmpeg
[13:26] <ramiro> durandal_1707: hi
[13:27] <durandal_1707> ramiro: aloha
[13:27] <ramiro> durandal_1707: you are correct, ffmpeg.arrozcru.org is too outdated and spreading wrong information
[13:27] <ramiro> i will take it down shortly
[13:27] <ramiro> michaelni, saste: will you please remove it from the documentation?
[13:29] <saste> ramiro, will do
[13:29] Action: durandal_1707 oh that was really fast
[13:29] <saste> should I replace with zeranoe forum?
[13:35] <ramiro> saste: i'll ask him first, is that ok?
[13:36] <durandal_1707> who is him?
[13:36] <ramiro> durandal_1707: http://ffmpeg.zeranoe.com/
[13:36] <saste> ramiro, ok, although I believe he's already the official "windows support" guy, we link to its windows build page IIRC
[13:37] <ramiro> oh, right =)
[13:37] <ramiro> then I guess it's ok
[13:48] <michaelni> hi ramiro, ill leave it to you and saste to remove, update or whatever ... 
[13:49] <michaelni> durandal_1707, memcpy might be faster than plain C loop copying
[13:51] <michaelni> in theory gcc could recognize this and use a memcpy() on its own, but it seems it doesnt
[13:53] <durandal_1707> is it slower?
[13:53] <cone-209> ffmpeg.git 03Justin Ruggles 0779b7747556db: vorbisdec: use float planar sample format
[13:53] <cone-209> ffmpeg.git 03Justin Ruggles 07c9d0f4506f10: pcmdec: use planar sample format for pcm_s16le_planar
[13:53] <cone-209> ffmpeg.git 03Justin Ruggles 077c278d2ae410: alacenc: support 24-bit encoding
[13:53] <cone-209> ffmpeg.git 03Michael Niedermayer 0770c0f13a9a40: Merge commit '7c278d2ae410a64bdd89f1777026b4b963c30a1a'
[13:54] <michaelni> durandal_1707, the code gcc generates for plain C sure is slower than a call to a optimized memcpy
[13:55] <durandal_1707> michaelni: you merged crappy code from libav for planar le16
[13:55] <michaelni> a optimized memcpy can copy 8 or 16 bytes at a time, the plain c code does 2 bytes 
[13:57] <Tjoppen> oughtn't it use memcpy() as long as you set restrict?
[13:59] <durandal_1707> michaelni: if "optimized memcpy" is never triggered it should not be used at all
[14:00] <durandal_1707> michaelni: your merge introduced bug on big-endian
[14:00] <durandal_1707> and i dislike libav code
[14:00] <michaelni> durandal_1707, yes, i just saw :(
[14:02] <durandal_1707> michaelni: what about reverting(by not using git revert) that?
[14:03] <durandal_1707> though there is fix on libav for this i see no point in merging their code if our already supported planar sample format
[14:05] <durandal_1707> i will add myself as maintainer for pcm.c
[14:05] <durandal_1707> and bunch of other files i wrote
[14:07] <michaelni> durandal_1707, ill revert, please benchmark and if faster add memcpy after that
[14:09] <durandal_1707> michaelni: well i use clang
[14:09] <cone-209> ffmpeg.git 03Michael Niedermayer 072d232f8b887f: pcm: revert from libavs planar code to durandals.
[14:09] <durandal_1707> but will try memcpy
[14:10] <michaelni> durandal_1707, also try restrict maybe clang or gcc use memcpy on their own that way as Tjoppen suggested
[14:11] <durandal_1707> michaelni: it is not my code, i just wrote macro
[14:12] <durandal_1707> actually it is, and very old one
[14:22] <cone-209> ffmpeg.git 03Paul B Mahol 0700e02366a5ae: pcmenc: use ENCODE macro for pcm_s8
[14:41] <cone-209> ffmpeg.git 03Justin Ruggles 073e6c2a67a12d: FATE: rename ALAC tests from alac-* to alac-16-*
[14:41] <cone-209> ffmpeg.git 03Justin Ruggles 07b353321caa22: FATE: add 24-bit ALAC tests
[14:41] <cone-209> ffmpeg.git 03Michael Niedermayer 076dadb0e425a4: Merge remote-tracking branch 'qatar/master'
[14:52] <durandal_1707> michaelni: i do not see reference files
[14:53] <durandal_1707> ignore, those are not encoder tests
[14:53] <saste> Zeranoe, you OK if I replace arrozcru with zeranoe.com in doc/platform.texi?
[15:00] <cone-209> ffmpeg.git 03Stefano Sabatini 0799a30ad56d6a: doc/platform: replace link to site arrozcru.org with link to ffmpeg.zeranoe.com
[15:24] <cone-209> ffmpeg.git 03Michael Niedermayer 0707a866282f08: oggdec: fix memleak on header parsing failure
[16:08] <cbsrobot> lol @ ticket #1934
[16:12] <ubitux> Carl is pretty patient :)
[16:12] <ubitux> especially given the nice "PS" note
[16:14] Action: Daemon404 checks
[16:14] <Daemon404> heh
[16:15] <Daemon404> guy has a point tho
[16:15] <Daemon404> (if it is indeed the case)
[16:15] <av500> about the IDIOTS?
[16:15] <Daemon404> nice troll hat
[16:16] <av500> :)
[16:16] <Compn> what
[16:16] <Compn> i asked him what option
[16:16] <ubitux> Daemon404: afaiu the default pix format just changed
[16:16] <Daemon404> oic
[16:16] <Compn> we like keeping backwards compat if possibles
[16:16] <Daemon404> lol
[16:16] <ubitux> and the default pix fmt makes the files kinda unplayable for players who don't support it
[16:16] <Compn> ubitux : no, the user mentioned his ffpresets broke
[16:17] <Daemon404> libav* api is teh leats backwards compat api ever
[16:17] <Compn> unrelated bug to pixfmt
[16:17] <ubitux> ah? ok
[16:38] <burek> when i run "ffmpeg -f v4l2 -i /dev/video0 -c:v libx264 -f mpegts udp://..." I get a lot of "DTS 1353425865817757, next:166665 st:0 invalid dropping"
[16:39] <burek> but when i set -crf 30 for example, it stops..
[16:39] <burek> what is wrong actually?
[16:39] <burek> i mean it stops with those invalid droppings and works correctly
[16:39] <burek> cpu is merely at 6%
[16:40] <burek> hm, now it works with -crf 23 too
[16:40] <Compn> is that the smallest you can get your command line 
[16:40] <burek> it seems this is random.. i hate these situations
[16:40] <Compn> is it udp or v4l problem
[16:41] <burek> im not sure how to investigate it
[16:41] <Compn> the DTS looks like a timestamp issue 
[16:41] <Compn> well try -f to null and remove udp stuff
[16:41] <burek> ok
[16:41] <Compn> could be mpegts muxer
[16:41] <burek> now it works with -crf 14 :)
[16:42] <burek> wow it froze with -f null -
[16:42] <Compn> erm
[16:42] <Compn> probably you want to output to devnull
[16:42] <Compn> not stdout...
[16:42] <burek> -f null outputs to /dev/null right?
[16:42] <burek> so - gets ignored i guess
[16:42] <Compn> i dont know
[16:43] <burek> i had to reboot it :( it really froze
[16:43] <Compn> yikes :D
[16:43] <Compn> sorry bout that
[16:43] <Compn> i'm guessing the timestamps from v4l dont play nice with mpegts muxer
[16:44] <Compn> so you will need to use a diff -f or maybe -vf fixpts 
[16:44] <Compn> i'm going afk bbl
[16:44] <Compn> it could also be x264, dunno
[16:44] <Compn> that isnt a helpful error line
[16:45] <Compn> doesnt specify whats failing
[16:50] <burek> ok, thanks a lot
[16:50] <burek> ill try to investigate
[16:51] <burek> and submit a bug report
[16:51] <burek> if i figure out whats wrong
[16:51] <ubitux> burek: btw, the fate server is not up-to-date with the fate project
[16:52] <ubitux> we use a pretty old version of fate
[16:52] <ubitux> (project is at http://git.mansr.com/?p=fate;a=summary)
[16:53] <burek> ubitux, i checkedout what we use at fate.ffmpeg.org i guess
[16:53] <ubitux> yes, but it might be upgraded at some point
[16:54] <ubitux> and the new version (unused) might have the features you are looking for
[16:54] <ubitux> (i don't really read your mail yet though)
[16:54] <ubitux> it's being used on libav if you want to have a look
[16:54] <burek> is there a reason why we are using old version
[16:55] <ubitux> ask baptiste
[16:55] <burek> who is baptiste
[16:55] <ubitux> Baptiste Coudurier
[16:55] <ubitux> grep the source for the mail
[16:55] <burek> oh ok
[16:55] <ubitux> i think the main reason was that the local format changed
[16:56] <burek> well, if we upgrade fate server, we'll have to upgrade all the fate clients, right?
[16:56] <ubitux> and it might have break when upgrading
[16:56] <ubitux> fate clients are what you have on the git repository
[16:56] <saste> ubitux: any comment on the ffprobe patch(es)?
[16:57] <ubitux> saste: i'll comment on the documentation and ffprobe patches tonight
[16:58] <ubitux> burek: it might require some maintainance which baptiste may not want to do 
[16:59] <burek> well
[16:59] <burek> in that case it's better imho to work with what we have
[16:59] <burek> if it works so far
[16:59] <burek> no need to look for trouble :)
[16:59] <burek> if it works well enough*
[17:00] Action: ubitux wouldn't be against an upgrade for a better looking output
[17:00] <ubitux> :)
[17:01] <ubitux> burek: your mail suggest some changes to the fate server
[17:01] <ubitux> and if so, it would be better to work with the upstream
[17:01] <ubitux> but good luck with Måns
[17:01] <burek> no no
[17:01] <burek> not changes
[17:01] <burek> ive looked into that perl code once
[17:01] <burek> and no more
[17:02] <burek> :)
[17:02] <burek> that wasn't written by a web programmer obviously
[17:02] <burek> but that aside, i had a wish to make something faster, without necessairly upgrading fate server
[17:02] <av500> mans would see that as a compliment in fact
[17:03] <burek> couple of scripts that trigger on client's submission, generating static pages, that's all
[17:03] <ubitux> burek: yes, adding hacks to make a potential upgrade harder?
[17:03] <burek> ummm not quite
[17:03] <ubitux> where you would put those scripts>
[17:03] <ubitux> ?
[17:03] <burek> on the hard disk :D
[17:03] <ubitux> which one?
[17:03] <ubitux> and where?
[17:04] <ubitux> run how?
[17:04] <burek> easy :) first of all, I would just "hack" the part where the client has finished his submission of data to the fate server
[17:04] <burek> on the server-side obviously
[17:04] <burek> making just a simple trigger, nothing more
[17:05] <burek> that's all for the hacking part
[17:05] <burek> the rest is just tools/scripts which generate needed layouts
[17:05] <burek> it wouldn't depend at all on the server's code any more
[17:06] <burek> btw, how do fate clients submit their data? ftp? or through some custom tcp connection
[17:06] <ubitux> ssh
[17:07] <burek> even better
[17:07] <ubitux> with a | tar
[17:08] <burek> I could change it to | trigger | tar
[17:08] <burek> :)
[17:09] <ubitux> see tests/fate.sh
[17:09] <burek> will do, just to finish something first
[17:13] <burek> so, it tars it at the client side
[17:14] Action: ubitux doesn't remember the details
[17:14] <ubitux> possibly just a way to pipe the data
[17:14] <burek> test -n "$fate_recv" && $tar report *.log | gzip | $fate_recv
[17:14] <burek> if fate_recv is what i think it is, then it is done at client-side
[17:14] <burek> but not a biggie
[17:15] <burek> we'll unzip it :)
[17:15] <burek> it's important that we just do it once, not at every page request
[17:15] <ubitux> fate_recv is in the configuration of the profile
[17:15] <ubitux> burek: see http://lucy.pkh.me/fate-configs/ for some config file examples
[17:16] <michaelni> <burek> is there a reason why we are using old version <----- baptiste tried to upgrade a while ago, but everything stoped working
[17:16] <ubitux> yeah, "the format changed"
[17:17] <ubitux> no idea what he was really talking about though
[17:17] <ubitux> i guess it needed to reset the results
[17:17] <ubitux> or something.
[17:18] <durandal_1707> how i can measure number of operations that code is doing?
[17:18] <michaelni> durandal_1707, START/STOP_TIMER
[17:24] <burek> ok, well, if it is submitting results from configure/compile/tests (plus maybe some additional data), we can upgrade it at some time in the future, but for now, i think just speeding up this what we have will already help
[17:25] <burek> at least i hope it will
[17:26] <ubitux> did you check if the problem wasn't fixed with recent versions?
[17:27] <burek> what's the point if we can't upgrade to it
[17:28] <ubitux> i don't think it's impossible to upgrade
[17:28] <ubitux> i also think it's better to upgrade if the problem is solved upstream instead of adding workarounds which might complexifies merges
[17:28] <ubitux> but i'm not the maintainer of the fate server :)
[17:29] <burek> where can i check the latest version
[17:29] <ubitux> i gave the url a few minutes ago
[17:30] <ubitux> /lastlong mansr
[17:30] <ubitux> /lastlog mansr
[17:30] <ubitux> there isn't that much code btw
[17:32] <burek> does that new version have all the info you (developers) need at fate server?
[17:33] <ubitux> i guess so
[17:35] <burek> well, even better then :)
[17:35] <burek> you just upgrade it all and I can go out and have fun instead :D
[17:36] <ubitux> so we're back to the original topic
[17:36] <ubitux> you need to deal with that with baptiste, who is the owner of the box
[17:36] <burek> i don't :)
[17:36] <burek> i don't even need fate since i'm no developer :)
[17:41] <michaelni> ubitux, which single bug does updating the fate server solve ?
[17:41] <burek> offtopic: <Davstern15> Can I use ffmpeg.exe to add a piece of metadata into a PNG?
[17:42] <ubitux> michaelni: the ugly output maybe ;)
[17:43] <ubitux> michaelni: maybe it solves the problem with unrolling large outputs too when the screen is not large enough (but i need to check)
[17:43] <ubitux> it gives more information, is integrated nicely with the site
[17:43] <ubitux> maybe it solves the slowness problem burek was talking about
[17:44] <ubitux> it allows to open the commit directly too
[17:44] <ubitux> that kind of stuff
[17:44] <ubitux> i guess there are other benefits, but i'm not browsing the libav's fate enough to tell
[17:46] <burek> to be honest, im even happier i dont have to do anything :)
[17:46] <michaelni> so all problems stay, all effort to fix it is killed and all work stays on the sholders of who has not enough time to do it
[17:47] <michaelni> last year i considered to rewrite fate server but i didnt find the time
[17:48] <ubitux> yeah we kinda talk about that :)
[17:49] <ubitux> it might be overkill when all we might need is just some little maintainance on our box
[17:49] <michaelni> fateserver is fundamentally flawed
[17:49] <ubitux> ah?
[17:49] <michaelni> it decompresses and parses hundreads of megabytes of data per pageload
[17:50] <michaelni> i dont think upgrading fixes this
[17:50] <michaelni> i think libavs just works better because they have a faster box
[17:51] <michaelni> if iam wrong well hell we should upgrade then but sofar noone said that iam wrong ...
[17:57] <ubitux> i don't think it will really hurt to upgrade, but i won't insist much on this since i can't do anything about it :p
[18:01] <durandal11707> michaelni: mamcpy with clang is faster
[18:02] <durandal11707> 1.9-4 times
[18:37] <ubitux> burek: anyway, don't take my suggestions as absolute truths, i was just talking about potential different paths
[18:38] <ubitux> i clearly won't stop you from contributing to fateserver or a new system
[18:38] <ubitux> just trying to avoid you to waste some time pointlessly if a simpler solution was available 
[19:18] <cone-209> ffmpeg.git 03Paul B Mahol 07f17f759544bc: pcmdec: use memcpy() when possible for planar decoders
[19:18] <cone-209> ffmpeg.git 03Paul B Mahol 07dd59f0125df0: add some planar PCM encoders
[19:20] <cone-209> ffmpeg.git 03Peter Ross 076253cee497ff: the hyperlink to the Developer's Certificate of Origin no longer works; use Linux kernel hyperlink
[19:20] <cone-209> ffmpeg.git 03ChanMin Kim 074293464705d0: lavf/segment: do not copy codec_tag when not available
[19:25] <tg2> Hey guys, trying to debug an odd "av_interleaved_write_frame(): Broken pipe" error that I get from ffmpeg when trying to output to stdout 
[19:25] <tg2> anybody want to look at a pastie and see if they can shed som elight?
[19:26] <durandal11707> tg2: if this is bug report it on trac
[19:29] <tg2> ok I'll do some more testing
[19:30] <tg2> was just looking for a more technical explaination of the above error
[19:30] <ubitux> durandal11707: it would be nice if the pcm code could have a better coverage
[19:30] <tg2> I don't get it when using flv container, but with mpegts I do - it's piping identically
[19:31] <durandal11707> ubitux: what is missing?
[19:31] <ubitux> dunno, i'm looking at http://lucy.pkh.me/ffmpeg-coverage/ffmpeg/libavcodec/pcm.c.gcov.html
[19:31] <tg2> lol
[19:31] <ubitux> might not be up-to-date
[19:31] <ubitux> also, maybe adpcm stuff might require it as well
[19:33] <durandal11707> adpcmenc is missing trellis coverage
[19:34] <durandal11707> pcm is missing unsigned stuff, lxf and pcm_dvd of more important 
[19:41] <durandal11707> ubitux: i already did planar stuff, now adding unsigned stuff
[19:59] <cone-209> ffmpeg.git 03Michael Niedermayer 077cca237ddd1f: swr: general doxy text about swr and example code.
[20:06] <cone-209> ffmpeg.git 03Michael Niedermayer 07156a75a4594e: swr-doxy: elaborate on swr_get_delay() and the timebase
[20:06] <durandal_1707> is there any very popular game format we do not support?
[20:11] <kierank> bink
[20:12] <nevcairiel> but bink works, at least the files i tested
[20:12] <kierank> iirc there are one or two bugs
[20:13] <kierank> did report htem to kostya but i can't remember if he fixed
[20:16] <durandal_1707> i plan to write brstm support
[20:17] <nevcairiel> btw durandal_1707, this sample contains a DTS express stream http://files.1f0.de/samples/amergang.sample.m2ts - since you asked yesterday i think
[20:18] <nevcairiel> its the 4th audio stream, the one the probing function probably complains about =p
[20:23] <durandal_1707> nevcairiel: but didn't you send patch that fixes this?
[20:29] <cone-209> ffmpeg.git 03Clément BSsch 07186942a5e356: swr: fix a few typo in the public header.
[20:31] <cone-209> ffmpeg.git 03Paul B Mahol 0750a9530bc405: fate: increase pcm coverage
[20:33] <ubitux> thx durandal_1707 :)
[20:34] <nevcairiel> durandal_1707: i only made the parser split the frames, not decode anything in it
[20:37] <durandal_1707> nevcairiel: right
[20:40] <nevcairiel> DTS Express does not have anything much in common with normal  DTS, specifically it does not have a "core" DTS frame, it consists of only a HD-type frame, and our decoder just cant read that, so it complains about missing stream information
[20:40] <nevcairiel> anyway, you asked for a sample, so there it is :)
[20:41] <ubitux> saste: reviewing the ffprobe work, give me an hour or two
[20:42] <durandal_1707> nevcairiel: yes, and thank for that
[20:42] <durandal_1707> *s
[20:53] <durandal_1707> anybody writing w64 muxer?
[21:04] <durandal_1707> lol zork decoder is still broken
[21:16] <cone-209> ffmpeg.git 03Michael Niedermayer 07391f323615e8: rc: fix 10l typo in  rc_max_available_vbv_use calculation
[21:55] <cone-209> ffmpeg.git 03Clément BSsch 0752b7823b737d: swr: include stdint.h instead of inttypes.h.
[21:59] <ubitux> michaelni: your escaping suggestion makes me wonder if we could express the filtergraph in a lisp dialect :)
[22:00] <nevcairiel> with millions of )))))))))?
[22:01] <ubitux> do you prefer the millions of \\\\\\ ?
[22:01] <ubitux> "dt=t=%{lt\\\\:\\\\\\'%H\\\\:%M}"
[22:01] <ubitux> \o/
[22:02] <nevcairiel> the parser is flawed to need this in the first place
[22:02] <nevcairiel> thats what you get from C string parsing, tbh
[22:04] <nevcairiel> i like micheals idea though, it looks simple
[22:04] <nevcairiel> michael's*
[22:04] <cone-209> ffmpeg.git 03Carl Eugen Hoyos 07b1e190d0fddb: Correctly signal EOF when demuxing caf files.
[22:04] <cone-209> ffmpeg.git 03Carl Eugen Hoyos 07d513fb1c7532: Add -skip_initial_bytes option.
[22:39] <cone-209> ffmpeg.git 03Clément BSsch 07cc88734c3c2e: lavf/srtdec: trim line break event separators from packet.
[22:42] <ubitux> saste: anything else you need review for?
[22:44] <saste> ubitux: you may want to comment on the RFC about documentation layout
[22:45] <ubitux> i did already, right?
[22:45] <ubitux> ah you replied mmh, sorry
[22:55] <ubitux> saste: anything else?
[22:56] <cone-209> ffmpeg.git 03Stefano Sabatini 073d52083a274e: ffmpeg: rework debugging timestamp logs in process_input()
[22:56] <cone-209> ffmpeg.git 03Stefano Sabatini 07b6c05879eaea: lavf/segment: consistently use "seg" in segment_start()
[22:56] <cone-209> ffmpeg.git 03Stefano Sabatini 072b31aa88955a: lavf/segment: unbreak behavior for segment muxer
[22:56] <cone-209> ffmpeg.git 03Stefano Sabatini 075a1ac463e02a: lavf/segment: do not pre-increment segment_idx value
[22:56] <cone-209> ffmpeg.git 03Stefano Sabatini 078b6aeb1fcdd9: lavf/segment: fix value for the M3U8 EXT-X-MEDIA
[23:06] <ubitux> heh i almost missed the tee pseudo muxer from Nicolas
[23:06] <ubitux> sounds fun
[00:00] --- Wed Nov 21 2012