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

[burek]

[00:31] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * ra189475c8e 10ffmpeg/libavcodec/dvdec.c: 
[00:31] <CIA-41> ffmpeg: dvdec: switch to av_assert
[00:31] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:31] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r70bcdfb39f 10ffmpeg/libavcodec/g723_1.c: 
[00:31] <CIA-41> ffmpeg: g732_1: reduce difference to qatar
[00:31] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:31] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rd673a3f4a9 10ffmpeg/libavcodec/motion_est_template.c: 
[00:31] <CIA-41> ffmpeg: motion_est_template: switch to av_assert
[00:31] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:34] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r668c873bed 10ffmpeg/libavformat/matroskadec.c: 
[02:34] <CIA-41> ffmpeg: matroskadec: check element size against stream limit in ebml_parse_elem()
[02:34] <CIA-41> ffmpeg: Fixes Ticket1195
[02:34] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[02:36] <michaelni> Daemon404, did you see https://ffmpeg.org/trac/ffmpeg/ticket/1218 ? (zerocodec issue)
[02:37] <Daemon404> ive seen it, and you wont like the answer
[02:37] <Daemon404> the binary vfw codec behaves different on different versions of windows
[02:37] <Daemon404> when it isnt busy crashing
[02:37] <Daemon404> because its a buggy piece of crap
[02:38] <Daemon404> i dont really think its possible to 'fix' it
[02:38] <Daemon404> (for example, if you dont pass it the right colorspace, it crashes)
[02:42] <ohsix> when you say different versions of windows, do you mean as reported by GetVersionEx? cuz when you're hosting the dll you can change that
[02:43] <Daemon404> ohsix, no i physically trie on an xp 32-bit machine and a 64-bit win7 machine
[02:43] <Daemon404> tried*
[02:43] <Daemon404> but thats all i tested
[02:43] <ohsix> oh you don't mean with a dll loader, you meant on windows, nevermind
[02:43] <Daemon404> yeah i instaleld the vfw codec on windows
[02:44] <ohsix> there's always going to be exceptional crap you have to keep a list of when you're handling binary stuff :<
[02:44] <Daemon404> installed*
[02:44] <Daemon404> my problem is
[02:44] <Daemon404> theres no way to 'fix' the ffmpeg decoder
[02:46] <ohsix> there's no implied or marked bitmap orientation?
[02:46] <Daemon404> you mean in the container?
[02:47] <Daemon404> no.
[02:47] <ohsix> on windows different stuff implies a bottom up bitmap, so you can end up with flipped pictures
[02:47] <Daemon404> if you look at the bug report, he tried the sample i made on win7 on whatever he had
[02:47] <Daemon404> and it displays upside down
[02:47] <Daemon404> so the 'official' decoder doesnt handle it either
[02:48] <michaelni> Daemon404, if it cant be fixed, please close the ticket with a short explanation and whatever resolution (wontfix/invalid/?) you consider correct
[02:48] <Daemon404> michaelni, OK
[02:48] <ohsix> is sample-zeco known to be encoded correctly
[02:48] <Daemon404> i encoded it on win 7, and it idsplays  correctly on win 7
[02:49] <ohsix> if he uses different output color spaces does it change
[02:49] <Daemon404> stuff on xp displays upside down on win 7
[02:49] <Daemon404> and suff from win 7 upside down on xp
[02:49] <Daemon404> there's only one colorspace.
[02:49] <ohsix> ok
[02:49] <ohsix> so is it the sampe dll on xp and 7?
[02:49] <Daemon404> yup.
[02:50] <Daemon404> the xp behavior is probably 'correct'
[02:50] <Daemon404> since win7 didnt exist when it was written
[02:50] <ohsix> and there's no source or documentation
[02:50] <Daemon404> no
[02:50] <Daemon404> i RE'd it
[02:50] <Daemon404> and the "docs" are a japanese blog post
[02:50] <Daemon404> which doesnt have any info like that
[02:51] <ohsix> that's fine, the dll doesn't even know win7 is hosting it; and win7 should be mindful of flipping the pictures when it decided to do something different
[02:51] <ohsix> you re'd the format, right? not what the dll might conditionally do based on the windows version or who calls it?
[02:51] <Daemon404> not that i could find
[02:51] <ohsix> someof those codecs have code that actually checks what's reading it and act differently
[02:51] <ohsix> (like if they were broken in premier or whatever)
[02:52] <Daemon404> the binary fails between versions too
[02:52] <Daemon404> so technically ours is doing the same
[02:52] <Daemon404> (lulz)
[02:52] <Daemon404> when you look at the compression scheme used though, youll understand it was designed by an idiot.
[02:52] <Daemon404> not even any prediction
[02:52] <ohsix> if i open it in ida i'm going to be looking at other things :>
[02:53] <Daemon404> :P
[02:53] <Daemon404> go4it
[02:53] <Daemon404> Patches Welcome
[02:53] <Daemon404> i hope to never touch that abomination of a dll again
[02:53] <Daemon404> <.<
[02:53] <Daemon404> >.>
[02:53] <ohsix> i can't help but think he'd know about bitmap orientation, but if you just left it alone i don't know, you need to mark it
[02:53] <Daemon404> also dont try and pass it any sort of rgb. it just crashes.
[02:54] <Daemon404> i think you give these people too much credit :P
[02:54] <ohsix> it's possible in xp that the _encoder_ gets the bitmap one way, and the output uses another way
[02:54] <Daemon404> teh guy basically hooked up zlib to a vfw interface
[02:54] <ohsix> if the encoder doesn't mark the picture orientation it won't be preserved
[02:54] <Daemon404> is there even a way to mark that in an avi container?
[02:54] <Daemon404> if so, i dont think we have a flag for it
[02:54] <ohsix> i don't think you mark it in the container, but i think there is also a way to do that
[02:55] <Daemon404> theres nothing in the  bitstream at all
[02:55] <Daemon404> and it relies on the keyframe flag in the container
[02:55] <ohsix> that's probably what's going on then
[02:55] <ohsix> input orientation isn't recorded anywhere, output orientation can only be guessed
[02:56] <Daemon404> that still means tehres no way to 'fix' it
[02:57] <ohsix> right
[02:57] <ohsix> it's a reason to never fix it, too
[02:58] <Daemon404> my reason is because nobody actually uses iyt
[02:58] <Daemon404> it*
[02:58] <Daemon404> its about as obscure as they come
[02:58] <ohsix> you cant infer it from the version or anything either, unless he is all like, with version 3 all bitmaps are top down!
[02:58] <Daemon404> lol
[02:58] <Daemon404> version isnt stored either 
[02:59] <Daemon404> just fyi
[02:59] <Daemon404> the entire bitstream is literally just a deflated hunk of data
[02:59] <Daemon404> with dumb interframe compression
[02:59] <ohsix> is this a "refreshingly simple api" because it's one driver entry? http://wiki.multimedia.cx/index.php?title=Microsoft_Video_For_Windows_API
[03:00] <ohsix> cuz the msgproc interface kind of blows
[03:00] <Daemon404> usuallt i open the DriverProc function
[03:00] <Daemon404> look for ICM_DECOMPRESS
[03:00] <Daemon404> follow it
[03:00] <Daemon404> and set the proper struct times liek ICDECOMPRESS *
[03:01] <Daemon404> which contains all the useful things like BITMAPINFOHEADER
[03:01] <ohsix> frame topness is indicated in the sign for biHeight http://msdn.microsoft.com/en-us/library/windows/desktop/dd183376%28v=vs.85%29.aspx
[03:01] <ohsix> does it store the frame height as a signed number?
[03:01] <Daemon404> i cannot remember off the top of my head
[03:01] <Daemon404> libavcodec always sees a positive # tho afaik
[03:01] <ohsix> ok, it'd be cool to confirm, cuz you could say for a fact that it's junk and can't work, and here's why
[03:02] <Daemon404> ill have to read its avi demuxer
[03:02] <Daemon404> to see if we even support it
[03:02] <Daemon404> mind you.. even teh binary decoder gets it wrong... but were already less unstable that it so no big deal
[03:03] <ohsix> well the binary decoder can't get it right unless it assumes the bitmap orientation
[03:03] <Daemon404> it can check biHeight
[03:03] <ohsix> to the encoder, it can be delivered top down or bottom up, if it's not recorded it will be wrong in usually the top down case
[03:04] <Daemon404> ive see ndecoderts that check it
[03:04] <Daemon404> i need to fix a possible memleak in zerocodec.c as well
[03:04] <Daemon404> so ill check this out when i do
[03:04] <Daemon404> thanks for the tip, ohsix 
[03:05] <ohsix> np, most people get caught off guard on the bottom up bitmap stuff, it's a holdover from Targa card acceleration (the first type ever supported)
[03:06] <ohsix> it's just an extension of knowing about that
[03:06] <Daemon404> i know about bottom up bitmaps
[03:06] <Daemon404> but ive NEVER seen it for a yuv colorspace
[03:06] <Daemon404> only ever rgb or bgr
[03:08] <ohsix> yea, it's weird, but if it's not marked somewhere it's essentially random on the output
[03:09] <ohsix> and i think it's legal to have yuv bottom up, but i don't know the implications or anything
[03:09] <Daemon404> probably
[03:09] <Daemon404> ive just never seen it in the wild
[03:10] <ohsix> right, it's a decent place to decide that they're just top down
[03:11] <Daemon404> michaelni, do you want me to rebase / fix my license file patch and send a v2 for you?
[03:14] <Daemon404> lol ohsix 
[03:14] <Daemon404> st->codec->height= FFABS(st->codec->height);
[03:14] <Daemon404> ^ we handle it so well
[03:15] <durandal_1707> :))))
[03:15] <Daemon404> memcpy(st->codec->extradata + st->codec->extradata_size - 9, "BottomUp", 9);
[03:15] <Daemon404> what sort of hack is this?
[03:15] <Daemon404> O_o
[03:15] <Daemon404> appending BottomUp to extradata?!
[03:16] <Daemon404> yeah OK im going to fix this to use a proper flag.
[03:16] <ohsix> i don't know anything about that, it's highly possible it's a valid thing to do
[03:16] <ohsix> ohh you mean extradata in ffmpeg
[03:16] <Daemon404> yeah
[03:16] <ohsix> can you just make height signed? :D
[03:16] <Daemon404> to pass it to teh decoder
[03:16] <Daemon404> thats likely break stuff
[03:16] <ohsix> or all bitmaps top down
[03:16] <Daemon404> id rather just set a flag
[03:16] <Daemon404> liek we do for keyframes
[03:17] <ohsix> it almost certainly will, but it's an implicit flag, people would have to handle it
[03:17] <Daemon404> ill replace any code relying on teh extradata hack
[03:17] <Daemon404> and it should be fine
[03:18] <ohsix> if people just copy abs() from seeing it in other codecs they might not ever get to know why they might be negative :p
[03:19] <ohsix> (and the info gets lost)
[03:19] <Daemon404> http://git.videolan.org/?p=ffmpeg.git;a=commit;f=libavformat/avidec.c;h=31f2616db86fb50174bc053f26c14db7c03e3685
[03:21] <Daemon404> libavcodec/rawdec.c:    if((avctx->extradata_size >= 9 && !memcmp(avctx->extradata + avctx->extradata_size - 9, "BottomUp", 9)) ||
[03:21] <Daemon404> libavdevice/dshow.c:                    memcpy(codec->extradata, "BottomUp", 9);
[03:21] <Daemon404> libavdevice/vfwcap.c:                memcpy(codec->extradata, "BottomUp", 9);
[03:21] <Daemon404> libavformat/avisynth.c:                      memcpy(st->codec->extradata, "BottomUp", 9);
[03:22] <Daemon404> libavformat/mtv.c:    st->codec->extradata       = av_strdup("BottomUp");
[03:22] <Daemon404> looks like it's plausible to fix it 
[03:22] <Daemon404> not a lot of things use it
[03:22] <Daemon404> but before that
[03:22] <Daemon404> lets see if it's set in zerocodec!
[03:27] <michaelni> Daemon404, yes, please rebase it
[03:29] <Daemon404> michaelni, sent
[03:30] <durandal_1707> michaelni: what would cause parser which do spliting to use bunch of memory (like all file is stored in memory) ?
[03:34] <Daemon404> ohsix, [zerocodec @ 0x1d4d6a0] ExtraData Size: 0
[03:34] <Daemon404> for both clips
[03:34] <Daemon404> so no, its not even being set
[03:35] <ohsix> is extradata an ffmpeg thing or an avi thing
[03:35] <durandal_1707> demuxer
[03:35] <Daemon404> ah wait
[03:35] <Daemon404> >st->codec->codec_tag==0
[03:36] <Daemon404> its only checking when theres no codec tag
[03:37] <Daemon404> yeah.. even fi i remove that, it gets set for both clips
[03:37] <Daemon404> so zerocodec really is just a broken piece of crap
[03:43] <ohsix> so is biHeight stored in the container or the codec data? in either case is the sign being preserved by zerocodecs encoder/decoder?
[03:44] <Daemon404> container
[03:44] <Daemon404> set by the codec at encode time
[03:44] <Daemon404> or app or w/e
[03:54] <Daemon404> humm, looks likereimar's patch might have fixed the memleak too
[03:57] <durandal_1707> michaelni: enabling debug log shows that crap values for pts/dts, why this happens?
[03:59] <ohsix> someone should tip off the zerocodec guy about the picture orientation at least, bbl
[04:01] <michaelni> durandal_1707, i dont know at all
[04:02] <durandal_1707> parser is trivial, it scans for 2 16bit sync ids and that is packet
[04:03] <Daemon404> ohsix, its long abandoned
[04:03] <durandal_1707> RIP
[04:04] <durandal_1707> michaelni: seting pts seems to resolve it ....
[04:07] <michaelni> btw about mp2 VBR it looked to me that twolame and everyone else has a different idea on the packet length by 1 byte
[04:08] <durandal_1707> hmm. so it is twolame bug..
[04:10] <michaelni> the difference only happened for the larger of 2 packet lengthes and i didnt debug it beyond seeing the difference
[04:10] <michaelni> so its likely a twolame bug but not 100% certain
[04:10] <Daemon404> ah there is a memleak... <3 valgrin d
[04:29] <CIA-41> ffmpeg: 03Derek Buitenhuis 07master * r878b3f2a24 10ffmpeg/LICENSE: 
[04:29] <CIA-41> ffmpeg: LICENSE: Document all GPL files
[04:29] <CIA-41> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[04:29] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[05:59] <ohsix> Daemon404: maybe ffmpeg could at least mark it so it decodes correctly if encoded with ffmpeg, srhug
[05:59] <Daemon404> no encoder
[05:59] <Daemon404> and i have no interesting in writing one
[05:59] <Daemon404> as simple as it is
[05:59] <ohsix> ah
[06:00] <durandal_1707> can we please forget it. please!
[06:00] <Daemon404> i already have.
[06:00] <Daemon404> i fixed a memleak instead
[06:00] <ohsix> bug can be closed now too, so it's even more forgotten
[08:59] <ubitux> michaelni: thx for fixing ticket 1195, but how come mplayer wasn't affected by this?
[08:59] <ubitux> also, it seems ffplay isn't ignoring the error, but that's not really important
[09:53] <CIA-41> ffmpeg: 03Alexander Strasser 07master * r56977eefd8 10ffmpeg/tests/ (Makefile fate/probe.mak): (log message trimmed)
[09:53] <CIA-41> ffmpeg: fate: Rename FATE_SAMPLES make file variable to FATE_EXTERN
[09:53] <CIA-41> ffmpeg:  Restore functionality to set the samples directory via the
[09:53] <CIA-41> ffmpeg: FATE_SAMPLES environment variable . This is broken since commit
[09:53] <CIA-41> ffmpeg: 63dcd16 was merged.
[09:53] <CIA-41> ffmpeg:  Additionally the name FATE_EXTERN is more suited as the current
[09:53] <CIA-41> ffmpeg: FATE_SAMPLES make file variable does not carry the name of the
[13:30] <michaelni> ubitux, i suspect mplayers avio context implementation behaves slightly different than ffmpegs
[13:41] <ubitux> ok
[15:27] <ubitux> saste: if i need multiple intermediate buffer within a video filter, it seems i can't run multiple ff_get_video_buffer()
[15:27] <ubitux> normal?
[15:28] <saste> why??
[15:28] <ubitux> because it crashes :))
[15:28] <ubitux> pretty strange
[15:28] <ubitux> but i'm doing this in input config_props() so maybe that's the problem
[15:30] <saste> ubitux: no you can't do that
[15:30] <saste> you can ask for buffers only after the filtergraph has been configured
[15:30] <ubitux> :(
[15:30] <ubitux> ok
[15:31] <saste> but you can create buffers *locally*, or cache them when start_frame() is called the first time
[15:32] <ubitux> what do you mean by creating buffers locally?
[15:32] <saste> you don't request buffers to the next filter, you create them locally
[15:33] <ubitux> i'm doing multiple myctx->fooref = ff_get_video_buffer(inlink, AV_PERM_WRITE, inlink->w, inlink->h);
[15:33] <saste> i think this is what default_get_video_buffer does
[15:33] <ubitux> ok
[15:33] <ubitux> will look
[15:50] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rae0312ab2e 10ffmpeg/libavcodec/h264_ps.c: 
[15:50] <CIA-41> ffmpeg: h264: print num_reorder_frames in debug output
[15:50] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:50] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rc91ca5b95d 10ffmpeg/libavformat/utils.c: 
[15:50] <CIA-41> ffmpeg: lavf: move has_decode_delay_been_guessed() up to make it accessible to earlier functions
[15:50] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:50] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rb288b4c63f 10ffmpeg/libavformat/utils.c: 
[15:50] <CIA-41> ffmpeg: has_decode_delay_been_guessed: adjust value for has_b_frames=0
[15:50] <CIA-41> ffmpeg: needed for a mkv file
[15:50] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:51] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r2107009e7d 10ffmpeg/libavformat/ (avformat.h utils.c): 
[15:51] <CIA-41> ffmpeg: lavf: move nb_decoded_frames out of info.
[15:51] <CIA-41> ffmpeg: This way the variable is available outside find_stream_info
[15:51] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:51] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r3e1cf49676 10ffmpeg/libavformat/utils.c: 
[15:51] <CIA-41> ffmpeg: compute_pkt_fields: do not attempt to calculate dts when the delay hasnt been estimated.
[15:51] <CIA-41> ffmpeg: Fixes ticket1242
[15:51] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[16:32] <saste> burek: why do you do that? are you testing the logger?
[16:32] <burek> I needed a link quickly and if I do it on #ffmpeg, people will think I'm refering the link to some of them :)
[16:41] <ubitux> http://ubitux.fr/pub/pics/edgedetect.png yepee.
[16:43] <burek> :)
[16:51] <ubitux> i'm wondering how i could overlay the edge on the original image
[16:52] <ubitux> like vf edgedetect,makethewhitered,overlay=transparent=black
[17:01] <saste> ubitux: lutyuv=a=y/yrange*255
[17:03] <saste> uhmmno it can't work... you need an eval filter
[17:03] <ubitux> :(
[17:04] <ubitux> you mean like geq ? :)
[17:07] <saste> yes
[17:14] <saste> alternatively: alphamerge
[17:56] <saste> gosh what's the point of commits like 3e1ff8eb27e547c330af if they are not documented??
[17:59] <ubitux> :)
[19:49] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rafa6afcc9f 10ffmpeg/libavformat/mpeg.c: (log message trimmed)
[19:49] <CIA-41> ffmpeg: mpegdemux: remove redundant dvd audio code
[19:49] <CIA-41> ffmpeg: This is almost a revert of: (the file from the report still works)
[19:49] <CIA-41> ffmpeg: commit 80e58c6153249a40e47a20326b7626cbe0fcabd3
[19:49] <CIA-41> ffmpeg: Author: Benoit Fouet <benoit.fouet at free.fr>
[19:49] <CIA-41> ffmpeg: Date: Wed Feb 11 11:09:36 2009 +0000
[19:49] <CIA-41> ffmpeg:  Allow demuxing of audio substreams stored as 0x06 type.
[19:50] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rce7cf600be 10ffmpeg/libavformat/mpeg.c: 
[19:50] <CIA-41> ffmpeg: mpegdemux: move private stream 1 handling out of mpegps_read_pes_header
[19:50] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:50] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * r759901f817 10ffmpeg/libavformat/mpeg.c: 
[19:50] <CIA-41> ffmpeg: mpegdemux: support MLP/AOB
[19:50] <CIA-41> ffmpeg: Fixes issue1731
[19:50] <CIA-41> ffmpeg: Based-on-patch-by: carl
[19:50] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[21:09] <CIA-41> ffmpeg: 03Philip Langdale 07master * r2daaf77698 10ffmpeg/ (8 files in 5 dirs): (log message trimmed)
[21:09] <CIA-41> ffmpeg: movtextenc: 3GPP TS 26.245 Timed Text Encoder.
[21:09] <CIA-41> ffmpeg: This change introduces a basic encoder for 3GPP Timed Text subtitles,
[21:09] <CIA-41> ffmpeg: also known as TX3G, Quicktime subtitles, or "movtext" in the existing
[21:09] <CIA-41> ffmpeg: code.
[21:09] <CIA-41> ffmpeg: This initial change doesn't attempt to write styling information,
[21:09] <CIA-41> ffmpeg: and just writes the plain text of the subtitles. I intend to add
[21:09] <CIA-41> ffmpeg: 03Philip Langdale 07master * r18175ca9b2 10ffmpeg/libavformat/ (movenc.c movenc.h): (log message trimmed)
[21:09] <CIA-41> ffmpeg: movenc: Handle need for extra packets to express subtitle duration.
[21:09] <CIA-41> ffmpeg: As packet duration is not stored inherently in MPEG4 containers,
[21:09] <CIA-41> ffmpeg: subtitles have their duration expressed by storing an additional
[21:09] <CIA-41> ffmpeg: empty packet with a pts matching the desired end time of the real
[21:09] <CIA-41> ffmpeg: subtitle. Additionally, it is generally expected that all streams
[21:09] <CIA-41> ffmpeg: start at time = 0, so an empty packet needs to be inserted at the
[21:09] <CIA-41> ffmpeg: 03Philip Langdale 07master * r7b24be557f 10ffmpeg/libavformat/srtdec.c: 
[21:09] <CIA-41> ffmpeg: avformat/srtdec: Write duration into packet from srt demuxer.
[21:09] <CIA-41> ffmpeg: The current demuxer does not bother to write packet durations,
[21:10] <CIA-41> ffmpeg: which makes it impossible to remux into a new format.
[21:10] <CIA-41> ffmpeg: Signed-off-by: Philip Langdale <philipl at overt.org>
[21:10] <Daemon404> michaelni, zerocodec fixes pushed to my github. can be merged.
[21:18] <michaelni> philipl, libavcodec/movtextenc.c:24:21: fatal error: movtext.h: No such file or directory
[21:19] <philipl> Again. Damn it.
[21:19] <philipl> That stupid file is in my local tree. Sorry
[21:21] <CIA-41> ffmpeg: 03Philip Langdale 07master * r82de3e16a8 10ffmpeg/libavcodec/movtextenc.c: 
[21:21] <CIA-41> ffmpeg: movtextenc: Remove dangling reference to movtext.h
[21:21] <CIA-41> ffmpeg: This is a reference that leaked in from my future work to
[21:21] <CIA-41> ffmpeg: support styling.
[21:21] <CIA-41> ffmpeg: Signed-off-by: Philip Langdale <philipl at overt.org>
[21:23] <michaelni> philipl, thx
[21:25] <CIA-41> ffmpeg: 03Derek Buitenhuis 07master * rd6124d0d14 10ffmpeg/libavcodec/zerocodec.c: 
[21:25] <CIA-41> ffmpeg: zerocodec: Cosmetics
[21:25] <CIA-41> ffmpeg: Be consistent with error messages and code formatting.
[21:25] <CIA-41> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[21:25] <CIA-41> ffmpeg: 03Derek Buitenhuis 07master * rfcf550c2cb 10ffmpeg/libavcodec/zerocodec.c: 
[21:25] <CIA-41> ffmpeg: zerocodec: Fix memleak in decode_frame
[21:25] <CIA-41> ffmpeg: If there was a failure inflating, or reinitializing
[21:25] <CIA-41> ffmpeg: the zstream, the current frame's buffer would be lost.
[21:25] <CIA-41> ffmpeg: Signed-off-by: Derek Buitenhuis <derek.buitenhuis at gmail.com>
[21:25] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * rf85746509c 10ffmpeg/: 
[21:25] <CIA-41> ffmpeg: Merge remote-tracking branch 'dwbuiten/master'
[21:25] <CIA-41> ffmpeg: * dwbuiten/master:
[21:25] <CIA-41> ffmpeg:  zerocodec: Fix memleak in decode_frame
[21:25] <CIA-41> ffmpeg:  zerocodec: Cosmetics
[21:25] <CIA-41> ffmpeg: Merged-by: Michael Niedermayer <michaelni at gmx.at>
[22:16] <CIA-41> ffmpeg: 03Nicolas George 07master * r8ef740ce01 10ffmpeg/libavfilter/ (avfilter.h video.c): (log message trimmed)
[22:16] <CIA-41> ffmpeg: lavfi: use a new field for automatic buffer copy.
[22:16] <CIA-41> ffmpeg: The code currently use cur_buf as the target of the copy,
[22:16] <CIA-41> ffmpeg: but cur_buf can be cleared by the filter if it has given
[22:16] <CIA-41> ffmpeg: the reference away or stored it elsewhere as soon as start_frame.
[22:16] <CIA-41> ffmpeg: The code still relies on the fact that the reference is not
[22:16] <CIA-41> ffmpeg: destroyed until end_frame. All filters currently follow that condition.
[22:16] <CIA-41> ffmpeg: 03Nicolas George 07master * r8d6eed7b56 10ffmpeg/libavfilter/avfilter.h: lavfi: document the constraints on incoming frames.
[22:16] <CIA-41> ffmpeg: 03Nicolas George 07master * r88fc1438c6 10ffmpeg/ (Changelog doc/ffmpeg.texi ffmpeg.c): 
[22:16] <CIA-41> ffmpeg: ffmpeg: insert bitmap subtitles as video in filters.
[22:16] <CIA-41> ffmpeg: With this feature, it becomes possible to perform commonly
[22:16] <CIA-41> ffmpeg: requested tasks, such as hardcoding bitmap subtitles.
[22:16] <CIA-41> ffmpeg: This will be reverted once libavfilter has proper support
[22:16] <CIA-41> ffmpeg: for subtitles. All the changes have the string "sub2video"
[22:16] <CIA-41> ffmpeg: in them, it makes it easy to spot the parts.
[23:54] <CIA-41> ffmpeg: 03Sean McGovern 07master * r3693608023 10ffmpeg/libavcodec/wmaprodec.c: 
[23:54] <CIA-41> ffmpeg: wmapro: prevent division by zero when sample rate is unspecified
[23:54] <CIA-41> ffmpeg: This fixes Bugzilla #327:
[23:54] <CIA-41> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[23:54] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * r98d0d19208 10ffmpeg/libavcodec/lagarith.c: (log message trimmed)
[23:54] <CIA-41> ffmpeg: lagarith: pad RGB buffer by 1 byte.
[23:54] <CIA-41> ffmpeg: For left HFYU prediction, we predict from the buffer buf+1 using 8- or
[23:54] <CIA-41> ffmpeg: 16-byte reads. This means that aligning the buffer by 16 bytes is in
[23:54] <CIA-41> ffmpeg: itself not sufficient, because if the width itself is 16- or 8-byte
[23:54] <CIA-41> ffmpeg: aligned, the buffer will not be padded, and thus a read of size 16 at
[23:54] <CIA-41> ffmpeg: buf+1 will overflow boundaries at the right edge. Padding the buffer by
[23:54] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * rda6505ad2f 10ffmpeg/libavcodec/x86/dsputil_yasm.asm: (log message trimmed)
[23:54] <CIA-41> ffmpeg: dsputil: make add_hfyu_left_prediction_sse4() support unaligned src.
[23:54] <CIA-41> ffmpeg: This makes add_hfyu_left_prediction_sse4() handle sources that are not
[23:54] <CIA-41> ffmpeg: 16-byte aligned in its own function rather than by proxying the call to
[23:54] <CIA-41> ffmpeg: add_hfyu_left_prediction_ssse3(). This fixes a crash on Win64, since the
[23:54] <CIA-41> ffmpeg: sse4 version clobberes xmm6, but the ssse3 version (which uses MMX regs)
[23:54] <CIA-41> ffmpeg: does not restore it, thus leading to XMM clobbering and RSP being off.
[23:54] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * r66adb7ce1b 10ffmpeg/libavcodec/wmaprodec.c: 
[23:54] <CIA-41> ffmpeg: Revert "wmapro: prevent division by zero when sample rate is unspecified"
[23:54] <CIA-41> ffmpeg: This reverts commit 36936080239ba9e162f9f5d0f722ce579cb606cf. It was
[23:54] <CIA-41> ffmpeg: already applied; no idea why it didn't error out while re-applying it.
[23:54] <CIA-41> ffmpeg: 03Ronald S. Bultje 07master * r4a8143e73c 10ffmpeg/libavcodec/x86/fft_mmx.asm: 
[23:54] <CIA-41> ffmpeg: fft: 3dnow: fix register name typo in DECL_IMDCT macro
[23:54] <CIA-41> ffmpeg: Signed-off-by: Diego Biurrun <diego at biurrun.de>
[23:54] <CIA-41> ffmpeg: 03Mans Rullgard 07master * re6cd698955 10ffmpeg/libavcodec/arm/vp8dsp_armv6.S: 
[23:54] <CIA-41> ffmpeg: ARMv6: vp8: fix stack allocation with Apple's assembler
[23:54] <CIA-41> ffmpeg: In the GNU assembler, a relational expression, bizarrely, has the
[23:54] <CIA-41> ffmpeg: value -1 if true, whereas in Apple's it is +1. This patch makes
[23:54] <CIA-41> ffmpeg: sure the correct expression is used in both cases.
[23:54] <CIA-41> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[23:54] <CIA-41> ffmpeg: 03Diego Biurrun 07master * r0c3ff1982c 10ffmpeg/libavcodec/x86/dct32_sse.asm: x86: dct32: port to cpuflags
[23:54] <CIA-41> ffmpeg: 03Mans Rullgard 07master * r9829a81bcd 10ffmpeg/libavcodec/arm/vp56_arith.h: (log message trimmed)
[23:54] <CIA-41> ffmpeg: ARM: vp56: allow inline asm to build with clang
[23:54] <CIA-41> ffmpeg: The clang integrated assembler does not support pre-UAL syntax,
[23:55] <CIA-41> (25 lines omitted)
[00:00] --- Sun Aug  5 2012