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

[burek]

[03:25] <CIA-41> ffmpeg: 03Michael Niedermayer 07master * re47d979cab 10ffmpeg/libavformat/asfdec.c: 
[03:25] <CIA-41> ffmpeg: asfdec: ignore too tiny indexes
[03:25] <CIA-41> ffmpeg: Fixes Ticket1521
[03:25] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:50] <CIA-41> ffmpeg: 03rogerdpack 07master * r47682ddc22 10ffmpeg/configure: 
[03:50] <CIA-41> ffmpeg: more verbose error messages at configure time
[03:50] <CIA-41> ffmpeg: Signed-off-by: rogerdpack <rogerpack2005 at gmail.com>
[03:50] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:51] <CIA-41> ffmpeg: 03Sebastien Zwickert 07master * r7f3dfd2010 10ffmpeg/libavcodec/ (vda.c vda.h vda_h264.c vda_internal.h version.h): 
[03:51] <CIA-41> ffmpeg: vda: support synchronous decoding.
[03:51] <CIA-41> ffmpeg: Note that the symbols used to run the hardware decoder in asynchronous mode
[03:51] <CIA-41> ffmpeg: has been marked as deprecated and will be dropped at a future version dump.
[03:51] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[03:51] <CIA-41> ffmpeg: 03Sebastien Zwickert 07master * r1bfa349a8d 10ffmpeg/libavcodec/ (Makefile vda.c vda_h264.c vda_internal.h): 
[03:51] <CIA-41> ffmpeg: vda: merge implementation into one file.
[03:51] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[06:32] <ramiro> hi
[06:35] <Daemon404> hi ramiro 
[06:35] <ramiro> I need to compress some data that I get from a gps module. it's 5 fields with some 25 bits (signed) each. after the first trackpoint, I get that the following points increment by 1 second and the rest of the values might change by ~100 each. what's the simplest delta coding I can do to use very little space in saving the next points?
[06:35] <ramiro> (I know this is unrelated to ffmpeg, but I'm sure someone will come up with a great idea =)
[10:10] <ubitux> note: i setup a valgrind/drd instance the other day; just like helgrind it detects threading issues
[10:11] <ubitux> it seems to detect a few less issues, but it's mostly similar to helgrind
[10:32] <saste> michaelni: my build change enabled compilation of POD pages
[10:33] <saste> and unveiled a bug in the build of print_options
[11:01] <ubitux> btw, am i wrong or prores encoder in libav is: more than 5x slower, lower quality, almost 2x bigger, and with the same bugs as the original prores encoder in ffmpeg?
[11:21] <saste> where should I put documentation for filters like asetpts/setpts?
[11:21] <saste> multimedia filters?
[11:23] <ubitux> you want to keep them together?
[11:23] <ubitux> wherever you place them, i think it would be nice to have a FAQ example or something, where they're used to slowdown or accelerate a video
[11:23] <ubitux> that's a common issue
[11:24] <ubitux> (doing timelapse or so)
[11:24] <ubitux> though, i don't know if some frame would be drop with a high acceleration
[11:26] <saste> ubitux: IIRC there is both a slowdown and a speedup example in the docs
[11:26] <saste> but the problem is that now they are documented in "Video filters"
[11:26] <ubitux> yeah, but harder to find than in the faq
[11:26] <ubitux> or maybe on the wiki
[11:26] <saste> asetpts doesn't belong there
[11:26] <saste> there is already an entry in the wiki
[11:27] <ubitux> ah, ok my bad then :)
[11:27] <saste> i don't mind if we add an entry in the wiki
[11:27] <saste> *in the FAQ
[11:27] <saste> a complex example involving asetpts, setpts, atempo, asyncts would be nice
[11:33] <CIA-41> ffmpeg: 03Nicolas George 07master * r17e40236cb 10ffmpeg/libavcodec/dvdsubenc.c: dvdsubenc: set frame size in extradata.
[11:33] <CIA-41> ffmpeg: 03Nicolas George 07master * re4f4d99df8 10ffmpeg/ffmpeg_opt.c: 
[11:33] <CIA-41> ffmpeg: ffmpeg: make -s work for subtitles too.
[11:33] <CIA-41> ffmpeg: Some codecs allow to encode the frame size and some players use it.
[11:33] <CIA-41> ffmpeg: 03Nicolas George 07master * rb1511e00f6 10ffmpeg/libavformat/utils.c: 
[11:33] <CIA-41> ffmpeg: lavf: probe PGS subtitles definition.
[11:33] <CIA-41> ffmpeg: The resolution is in the packets, so decoding must happen.
[11:33] <CIA-41> ffmpeg: Since most other formats do not set the dimension, make it
[11:33] <CIA-41> ffmpeg: a special case for PGS. If other codecs were to have the
[11:33] <CIA-41> ffmpeg: same requirement, using a CODEC_CAP would be preferred.
[11:33] <CIA-41> ffmpeg: 03Nicolas George 07master * r0cad101ea1 10ffmpeg/ (doc/ffmpeg.texi ffmpeg.c ffmpeg.h ffmpeg_opt.c): 
[11:33] <CIA-41> ffmpeg: ffmpeg: add an option to fix subtitles durations.
[11:33] <CIA-41> ffmpeg: With this option, transcoding DVB subtitles becomes possible.
[11:33] <CIA-41> ffmpeg: 03Nicolas George 07master * r2dedd8f496 10ffmpeg/libavcodec/dvdsubenc.c: (log message trimmed)
[11:33] <CIA-41> ffmpeg: dvdsubenc: make it usable for transcoding.
[11:33] <CIA-41> ffmpeg: DVD subtitles packets can only encode a single rectangle:
[11:33] <CIA-41> ffmpeg: if there are several, copy them into a big transparent one.
[11:33] <CIA-41> ffmpeg: DVD subtitles rely on an external 16-colors palette:
[11:33] <CIA-41> ffmpeg: use a reasonable default one, stored in the private context,
[11:33] <CIA-41> ffmpeg: and encode it into the extradata, as specified by Matroska.
[11:33] <CIA-41> ffmpeg: 03Nicolas George 07master * r690ef618b1 10ffmpeg/ (ffmpeg.c tests/ref/fate/sub-movtextenc): 
[11:33] <CIA-41> ffmpeg: ffmpeg: copy subtitles frame dimensions.
[11:38] <ubitux> yepee~ \o/
[11:57] <CIA-41> ffmpeg: 03Nicolas George 07master * r9bb936a80e 10ffmpeg/libavcodec/ (Makefile codec_names.sh utils.c): lavc: reimplement avcodec_get_name with descriptors.
[11:57] <CIA-41> ffmpeg: 03Nicolas George 07master * r2d3acbfe8c 10ffmpeg/libavcodec/ (avcodec.h utils.c): lavc: add const to AVCodecContext.codec_descriptor.
[11:59] <CIA-41> ffmpeg: 03Nicolas George 07master * r67a804b9ac 10ffmpeg/libavcodec/dvdsubenc.c: dvdsubenc: reindent after recent commit.
[12:12] <CIA-41> ffmpeg: 03Nicolas George 07master * r271ddb116c 10ffmpeg/libavfilter/ (audio.c avfilter.h video.c): (log message trimmed)
[12:12] <CIA-41> ffmpeg: lavfi: use min_perms and rej_perms for out pads.
[12:12] <CIA-41> ffmpeg: There are several reasons for doing that:
[12:12] <CIA-41> ffmpeg: 1. It documents the code for the reader and helps find
[12:12] <CIA-41> ffmpeg:  inconsistencies and bugs.
[12:12] <CIA-41> ffmpeg: 2. For rej_perms, it guarantees the change will be done
[12:12] <CIA-41> ffmpeg:  even if the output reference can be created by several
[12:12] <CIA-41> ffmpeg: 03Nicolas George 07master * r082b745d33 10ffmpeg/doc/filter_design.txt: filter_design: document ownership and permissions.
[13:14] <saste> can someone explain what checkheaders is good for?
[13:14] <ohsix> checking headers :p some targets have some really weird headers, maybe?
[13:14] <saste> how checkheaders is going to help?
[13:15] <ohsix> gcc does a similar thing, it checks the system headers and where it has to change them it keeps a private copy
[13:15] <ohsix> i have no idea
[13:23] <CIA-41> ffmpeg: 03Andrey Utkin 07master * ra32fa21d17 10ffmpeg/libavfilter/af_asetnsamples.c: 
[13:23] <CIA-41> ffmpeg: lavfi/asetnsamples: push as many frames as ready
[13:23] <CIA-41> ffmpeg: Signed-off-by: Stefano Sabatini <stefasab at gmail.com>
[14:03] <ubitux> saste: i guess if the header is public, it helps the app using the header not adding the system headers that header would require
[14:04] <ubitux> not sure i'm clear enough
[14:04] <ubitux> it checks if the header has stdint.h when using uint32_t for instance
[14:05] <ubitux> so if the app doesn't need stdint.h for a given file, it won't need to add that include just to use our header
[14:05] <ubitux> about checking headers for local files, i'm not sure it has much benefits
[14:05] <ubitux> except it's somehow more correct
[14:06] <saste> got it thanks
[14:16] <ubitux> saste: i wrote a quick hack script to do a ffmpeg-segment-list to hls-playlist, do you think it would be worth putting it in tools/ as a PoC or something?
[14:21] <CIA-41> ffmpeg: 03Sebastien Zwickert 07master * r0e05908c95 10ffmpeg/libavcodec/Makefile: 
[14:21] <CIA-41> ffmpeg: vda: fix make checkheaders.
[14:21] <CIA-41> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[14:29] <saste> ubitux: hls == m3u8?
[14:30] <saste> i was thinking about implementing it natively in segment (-segment_list_type m3u8)
[14:31] <ubitux> yes
[14:31] <ubitux> the script is less than 30 lines, plus docu & example
[14:31] <ubitux> well anyway, will submit, it's not perfect, just a PoC
[14:32] <saste> ubitux: i also had to use a similar script at some point
[14:32] <saste> so i wonder, since this is a common requirement, if we should rather have it integrated in C
[14:32] <ubitux> no idea, i'm going to look at hds now
[14:33] <ubitux> will submit the script in a moment
[14:33] <ubitux> here we go.
[14:34] <saste> eheh i wrote it in perl
[14:34] <ubitux> ;)
[14:37] <saste> ubitux: http://pastebin.com/nRawqwQJ
[14:38] <ubitux> is the manpage really at the end of the script?
[14:39] <ubitux> or it's supposed to be another file? :P
[14:40] <ubitux> interesting
[14:40] <saste> it's the real thing, through some perl mod magic
[14:40] <ubitux> fun :)
[14:40] <ubitux> looks like you have a more advanced script
[14:40] <ubitux> why the rounding btw?
[14:41] <ubitux> iirc you can have floats
[14:41] <saste> uhm... the last time i checked the (rather clumsy) spec it was only mentioning seconds
[14:41] <ubitux> lemme check
[14:42] <ubitux> curl 'https://devimages.apple.com.edgekey.net/resources/http-streaming/examples/bipbop_4x3/gear1/prog_index.m3u8'
[14:42] <ubitux> this is an example from 3rd point on https://developer.apple.com/resources/http-streaming/
[14:44] <ubitux> but well, it's still a draft
[14:44] <saste> uhm i read the somewhat official docs, it was an RFC-like document from apple
[14:44] <ubitux> "duration" is an integer or floating-point number in decimal positional notation that specifies the duration of the media segment in seconds.
[14:44] <ubitux> from http://tools.ietf.org/html/draft-pantos-http-live-streaming-08
[14:45] <ubitux> so i guess it's ok to have a float
[14:45] <saste> yep
[14:45] <ubitux> saste: the first version had int only
[14:46] <saste> uh... was it recently updated?
[14:46] <saste> i wrote that in January, so maybe this explains it
[14:47] <ubitux> it was a int only until version 5
[14:47] <ubitux> afaict
[14:47] <ubitux> version 4 expired in dec 7 2010
[14:48] <ubitux> 19 nov 2010, v5 adding float
[14:48] <ubitux> well anyway
[14:48] <ubitux> should be correct
[14:48] <ubitux> but i most likely need to add a version thing
[14:48] <saste> i'm fine with either scripts (mine needs to be updated)
[14:48] <saste> but then we should consider to implement m3u8 in C
[14:48] <ubitux> sure
[14:49] <ubitux> i'd like to see another playlist format before
[14:49] <saste> that's should be fairly straightforward
[14:49] <ubitux> so we can have a slight overview of what kind of support we need
[14:49] <saste> which one?
[14:50] <ubitux> i'd like to look at http://www.adobe.com/products/hds-dynamic-streaming.html ; not sure what kind of playlist it has, if any
[14:50] <ubitux> also, maybe it would be worth looking at dash
[14:50] <ubitux> and eventually the microsoft one
[14:50] <ubitux> something like hss iirc
[14:51] <saste> uhm adobe/apple/ms
[14:51] <ubitux> yeah
[14:51] <ubitux> :D
[14:51] <saste> each one with a different format basically doing the same stuff
[14:52] <ubitux> you also have the MPEG one
[14:52] <ubitux> DASH
[14:52] <ubitux> https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP
[14:52] <ubitux> :D
[14:52] <ubitux> i have no idea how all of them work thought
[15:09] <ubitux> wow filter for events
[15:09] <ubitux> fun
[15:12] <ubitux> it would really great if ffmpeg could be frame exact...
[15:13] <ohsix> that makes seeking Hard(TM)
[15:14] <ubitux> i started some kind of indexing stuff a while ago
[15:14] <ubitux> so you would use a first pass to generate an index file that could be specified for exact seeking later
[15:16] <ohsix> how often are seeks done, can't you just do it the expensive way and keep a trace of most of what you did to do it?
[15:17] <av500> in worst case you need to parse the whole file
[15:17] <av500> if you start it and seek to end-1
[15:19] <ohsix> so you can't even hope to guess at how to start decoding frames at an arbitrary position?
[15:20] <av500> not for mpeg
[15:20] <av500> there is no inline info
[15:20] <av500> even timestamps can jump around randomly
[15:20] <ohsix> so not in all cases
[15:20] <av500> i mean, you can jump in randomly and find a frame, but you have no idea what frame # that is
[15:21] <ohsix> you can't build the index while things are playing, so at least if you seek backwards it can be accurate & cheap?
[15:21] <av500> sure
[15:21] <av500> you can always build an index
[15:21] <av500> aka read the whole file
[15:22] <av500> thats basically like remuxing it to something with index
[15:22] <ohsix> how much do you typically get to skip when you read each frame, just to the next frame?
[15:23] <av500> yep
[15:24] <ohsix> can ffmpeg handle frame, time and other bitstream specific seek types?
[15:25] <ohsix> a frame seek might be expensive but it's not often needed, could just do it th ehard way if that's what someone wants, and make sure the time seek is fast and deterministic
[15:39] <CIA-41> ffmpeg: 03Mans Rullgard 07master * r8ec0204ee4 10ffmpeg/libavcodec/x86/ (cabac.h h264_i386.h): (log message trimmed)
[15:39] <CIA-41> ffmpeg: x86: cabac: allow building with suncc
[15:39] <CIA-41> ffmpeg: This fixes two issues preventing suncc from building this code.
[15:39] <CIA-41> ffmpeg: The undocumented 'a' operand modifier, causing gcc to omit a $ in
[15:39] <CIA-41> ffmpeg: front of immediate operands (as required in addresses), is not
[15:39] <CIA-41> ffmpeg: supported by suncc. Luckily, the also undocumented 'c' modifer
[15:39] <CIA-41> ffmpeg: has the same effect and is supported.
[15:40] <CIA-41> ffmpeg: 03Mans Rullgard 07master * r87fa05a0da 10ffmpeg/libavutil/arm/intmath.h: 
[15:40] <CIA-41> ffmpeg: ARM: intmath: use native-size return types for clipping functions
[15:40] <CIA-41> ffmpeg: This avoids having the compiler redundantly mask the values to
[15:40] <CIA-41> ffmpeg: the smaller size.
[15:40] <CIA-41> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[15:40] <CIA-41> ffmpeg: 03Mans Rullgard 07master * r480178a295 10ffmpeg/libavfilter/x86/yadif_template.c: (log message trimmed)
[15:40] <CIA-41> ffmpeg: x86: yadif: fix asm with suncc
[15:40] <CIA-41> ffmpeg: Under some circumstances, suncc will use a single register for the
[15:40] <CIA-41> ffmpeg: address of all memory operands, inserting lea instructions loading
[15:40] <CIA-41> ffmpeg: the correct address prior to each memory operand being used in the
[15:40] <CIA-41> ffmpeg: code. In the yadif code, the branch in the asm block bypasses such
[15:40] <CIA-41> ffmpeg: an lea instruction, causing an incorrect address to be used in the
[15:40] <CIA-41> ffmpeg: 03Mans Rullgard 07master * rc8252e80eb 10ffmpeg/libavcodec/x86/mlpdsp.c: (log message trimmed)
[15:40] <CIA-41> ffmpeg: x86: mlpdsp: avoid taking address of void
[15:40] <CIA-41> ffmpeg: This code contains a C array of addresses of labels defined in
[15:40] <CIA-41> ffmpeg: inline asm. To do this, the names must be declared as external
[15:40] <CIA-41> ffmpeg: in C. The declared type does not matter since only the address is
[15:40] <CIA-41> ffmpeg: used, and for some reason, the author of the code used the 'void'
[15:40] <CIA-41> ffmpeg: type despite taking the address of a void expression being invalid.
[15:40] <CIA-41> ffmpeg: 03Boris Maksalov 07master * rcee03436e6 10ffmpeg/libavcodec/proresenc.c: 
[15:40] <CIA-41> ffmpeg: proresenc: use the edge emulation buffer
[15:40] <CIA-41> ffmpeg: Prevents reading past the end of frame buffer.
[15:40] <CIA-41> ffmpeg: Signed-off-by: Luca Barbato <lu_zero at gentoo.org>
[15:40] <CIA-41> ffmpeg: 03Mans Rullgard 07master * r90540c2d5a 10ffmpeg/libswscale/x86/rgb2rgb_template.c: (log message trimmed)
[15:40] <CIA-41> (62 lines omitted)
[17:20] <CIA-40> ffmpeg: 03Michael Bradshaw 07master * ra22c996a85 10ffmpeg/ (6 files in 3 dirs): 
[17:20] <CIA-40> ffmpeg: Add ICO muxer
[17:20] <CIA-40> ffmpeg: Signed-off-by: Michael Bradshaw <mbradshaw at sorensonmedia.com>
[17:20] <CIA-40> ffmpeg: Reviewed-by: Peter Ross <pross at xvid.org>
[17:20] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:20] <CIA-40> ffmpeg: 03Boris Maksalov 07master * rf0cbab2ac7 10ffmpeg/ (3 files in 2 dirs): 
[17:20] <CIA-40> ffmpeg: prores_kostya: fix incorrect picture_size field.
[17:20] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:20] <CIA-40> ffmpeg: 03Boris Maksalov 07master * rc8e186fa7b 10ffmpeg/libavcodec/proresenc_kostya.c: 
[17:20] <CIA-40> ffmpeg: prores_kostya: implement interlaced encoding.
[17:20] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:23] <teratorn> is vf_overlay the only place in ffmpeg where alpha blending is implemented?
[17:24] <ubitux> vf alphamerge ptet
[17:24] <ubitux> s/ptet/maybe/
[17:25] <teratorn> ok thanks!
[17:25] <teratorn> we're looking to do some advanced compositing
[17:26] <teratorn> prob going to write our own - not sure what else is out there
[17:26] <ubitux> what kind of compositing filter you would like to write?
[17:26] <teratorn> do you have any idea if it's possible to accelerate alpha blending with SIMD instructions?
[17:26] <teratorn> I guess it should be ? 
[17:27] <teratorn> ubitux: overlays with transparency. transition effects. that sort of thing
[17:27] <ubitux> don't ask me for simd, but ffmpeg & libavfilter should have anything you need
[17:27] <teratorn> well we might do some simd
[17:27] <teratorn> if it's feasible
[17:27] <ubitux> s/anything/everything/
[17:27] <teratorn> ;)
[17:27] <ubitux> check libavfilter/x86, we have a little subset iirc
[17:27] <teratorn> I'm not sure how flexible the effect filters are in ffmpeg :)
[17:27] <teratorn> or how many there are.. need to review it :)
[17:27] <teratorn> oh, very awesome
[17:28] <ubitux> i'd recommend to discuss your filter on ffmpeg-devel at some point
[17:28] <teratorn> ok, thanks
[17:28] <teratorn> that is probably a good idea
[17:28] <teratorn> we need real-time (during live encoding) control over the filters though
[17:28] <ubitux> because if you're willing to submit it, it might avoid you going on the wrong track
[17:28] <teratorn> I'm unsure how appropriate ffmpeg filter framework is (I don't know anything about it)
[17:28] <ubitux> like writing a new filter where modifying overlay would be more appropriate for instance
[17:29] <teratorn> I would be hopeful to opensource it I just have to get permission :)
[17:29] <ubitux> lavfi has some command filter injection
[17:29] <ubitux> so you should be able to do what you want, somehow
[17:29] <teratorn> right
[17:29] <teratorn> I was thinking it might be easier to start with an existing filter
[17:29] <ubitux> teratorn: if you want to maintain your filter on your own you will really have trouble
[17:29] <ubitux> because lavfi is changing regularly
[17:30] <ubitux> also, the api is not really public
[17:30] <ubitux> so you will have surprise each time you upgrade your ffmpe
[17:30] <teratorn> we need 1) very good performance 2) good flexibility (3 layer blending. main layer + layer mask + brush or other overlay
[17:30] <teratorn> ubitux: hmm, really?
[17:31] <teratorn> well, that is +1 for merging it then :)
[17:31] <teratorn> from a business perspective
[17:31] <teratorn> hmmph.
[17:31] <ubitux> from a business perspective, it will avoid a huge maintainance burden
[17:31] <teratorn> yeah, I'm already kind of used to dealing with ffmpeg HEAD
[17:31] <ubitux> also, it will allow some review from people knowing the code
[17:31] <teratorn> right. or we could write our own compositing
[17:32] <ubitux> and eventually, your filter will revolutionize the world
[17:32] <teratorn> haha
[17:32] <ubitux> ;)
[17:32] <ubitux> ah also, it promotes the company
[17:32] <teratorn> do you work for a video company btw?
[17:32] <teratorn> sure
[17:32] <ubitux> somehow
[17:32] <teratorn> I'm all about open sourcing a lot of what we do
[17:33] <teratorn> and the management is on board generally
[18:14] <d4> hi, why does avcodec_find_decoder( ... ) always returns NULL even why I put a valid decoder in it like CODEC_ID_MPEG1VIDEO or CODEC_ID_H264 for example
[18:14] <nevcairiel> usually because the decoder was not compiled in your version of the library
[18:15] <nevcairiel> but what do you mean with "even a valid id", what did you expect from an invalid id? :p
[18:16] <d4> ehm also null 
[18:16] <d4> :P
[18:16] <d4> Am I correct that I am posting this question in the wrong channel though?
[18:17] <d4> I thought most decoders are standard compiled with ffmpeg
[18:19] <d4> It returns NULL with any codec id
[18:20] <nevcairiel> did you call avcodec_register_all() ?
[18:21] <nevcairiel> also yes, this is not the channel for api usage questions
[18:21] <d4> yeah I said that on the user channel but they complained about asking coding questions there I'm having a discussion that they are wrong lol
[18:21] <d4> and thanks that was a stupid mistake..
[18:24] <d4> 18:20 < nevcairiel> did you call avcodec_register_all() ?
[19:02] <CIA-40> ffmpeg: 03upsuper 07master * r068c8ce19c 10ffmpeg/libavcodec/version.h: 
[19:02] <CIA-40> ffmpeg: remove duplicated code
[19:02] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:02] <CIA-40> ffmpeg: 03Michael Niedermayer 07master * r70f0ffa1ed 10ffmpeg/libavcodec/bmv.c: 
[19:02] <CIA-40> ffmpeg: bmv_videodec: fix out of array read
[19:02] <CIA-40> ffmpeg: Fixes Ticket1373
[19:02] <CIA-40> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:26] <ubitux> btw, what happened to ffvp8?
[19:27] <ubitux> is it only for decode?
[19:28] <ubitux> mmh ok, ffvp8 was refering to the decoding only
[19:32] <j-b> you mean xvp8?
[19:35] <ubitux> i don't think so
[19:36] <ubitux> i was wondering how to get a faster vp8 encode
[19:36] <ubitux> i thought the references to the "fast ffvp8" was about an encoder, but it was actually the decode
[19:36] <ubitux> and libvpx doesn't seem to support threading :(
[19:38] <gnafu> It did the last time I tried it.
[19:39] <ubitux> oh?
[19:39] <ubitux> i don't get any performance increase
[19:44] <gnafu> Well, I don't know about performance increases, but I know it can use multiple threads and that I have set it to do such :-D.
[19:44] <gnafu> Though it should be faster; I think it was when I tried it.  It depends on the other settings, I guess.
[21:04] <^prelude^ZZz> hi there.
[21:04] <^prelude^ZZz> im capturing some data with ffmpeg.. and it is just acopy and vcopy and after some time it exists with No more inputs to read from,. anyone know why ? its a live channel why would it be existing.
[21:11] <msmithng> ^prelude^ZZz: probably want to ask this in #ffmpeg
[21:16] <saste> ^prelude^ZZz: and post pastebin (on #ffmpeg)
[21:32] <dilaroga> michaelni: thank you for applying vda patches
[21:32] <dilaroga> michaelni: I just pushed a better way to allocate the vda frame that you can merge into the main repo
[21:32] <dilaroga> https://github.com/dilaroga/ffmpeg-vda/commit/02f12de1c25789913b72c98c5bda3d521ede7b8b
[21:33] Action: Daemon404 bets j-b is following this patchset
[21:35] <dilaroga> j-b will get its patch too ;)
[00:00] --- Wed Aug 15 2012