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

[burek]

[00:00] <ohsix> saste: apitrace is pretty good, and multithread debugging ... well you've already lost if you've got into that hole
[00:00] <sware> when this build is done, I am writing vs plugins to make it faster 
[00:00] <sware> aka converting structs 
[00:00] <Daemon404> sware, there are more annoying problems
[00:00] <sware> like?
[00:00] <sware> casting ?
[00:00] <Daemon404> if you e.g. want to use the inline asm
[00:00] <ohsix> there's not anything that's critically missing, but 10% extra work is 10% extra work.
[00:00] <sware> I talked with michaelni yesterday
[00:00] <nevcairiel> i should poke BBB again about his pre-processor script to convert it to msvc compatible code
[00:00] <sware> he said the inline asm isn't entirely neccesary
[00:00] <sware> but, I can convert between at&t and intel syntax if it is 
[00:01] <ubitux> good luck with x = (AVRationnal){a,b} and stuff
[00:01] <sware> that's handled
[00:01] <Daemon404> sware, if you have to... please port to an external yasm file :)
[00:01] <sware> by a func av_create_rational();
[00:01] <Daemon404> everyone beneits
[00:01] <ubitux> and as parameter
[00:01] <Daemon404> benefits*
[00:01] <saste> jonathan blow just gave up at some point and left the port to an ex loki dev (icculus / Ryan C. Gordon), who did a good job
[00:01] <sware> AVRationals are easy lol
[00:01] <sware> I did the same for softfloat and movatom
[00:01] <ubitux> sware: what about av_ts2str()?
[00:02] <Daemon404> saste, also in regards to that blog post
[00:02] <ohsix> there are real problems with the implementation quality of something like openal on linux that people aren't even aware of :<
[00:02] <sware> ubitux: (char[AV_TS_MAX_STRING_SIZE]){0} was the issue
[00:02] <Daemon404> the #1 peoblem ive come up against is lolglibc
[00:02] <ubitux> sware: yes :)
[00:02] <nevcairiel> in any case, converting everything by hand is a silly plan, you'll have so many issues keeping your source synced to the master because of all the merge conflicts all the time
[00:03] <sware> ubitux: pretty simple.....
[00:03] <sware> that's all fixed, libavformat is built already 
[00:03] <Daemon404> teh SANER thing to do
[00:03] <Daemon404> would be to use icl
[00:03] <Daemon404> like x264 does
[00:03] <ubitux> or annoy Microsoft.
[00:03] <Daemon404> ubitux, 0 people care
[00:03] <ubitux> all of this because Microsoft doesn't want to pay 2-3 guys for a month
[00:03] <Daemon404> ms gains NOTHING from supporting c99
[00:03] <sware> building with mingw is pathetic
[00:03] <ubitux> Daemon404: people do actually care
[00:03] <sware> half the instructions out there don't even work now
[00:03] <nevcairiel> Microsoft cares about C++, C is not important for them
[00:04] <ohsix> they gain c99
[00:04] <ubitux> regularly someone complains about microsoft not supporting the C
[00:04] <sware> and the ffmpeg forum doesn't even have one entry on how to build with mingw
[00:04] <Daemon404> ubitux, PAYING people?
[00:04] <Daemon404> big companies?
[00:04] <Daemon404> lolol
[00:04] <sware> so everyone is just using the prebuilt binaries
[00:04] <Daemon404> sware, ./configure && make
[00:04] <ubitux> Daemon404: i don't think that's really a problem for microsoft to pay a few nerd to port the c++ msvc features to the c
[00:04] <sware> if you guys support mingw so much, you should at least give better directions on how to build with it heh
[00:04] <nevcairiel> building with mingw64 really isnt hard, download one of the pre-built mingw environments, run configure, run make, done
[00:04] <Daemon404> ubitux, you are delusional tehn.
[00:05] <Daemon404> nevcairiel, i actually provide prebuilt binaries/sdk for all of libav's point releases too.
[00:05] <ubitux> it's a problem because they are afraid ppl will realize how much C is better than c++, and will ask for using the MS api in C then
[00:05] <ubitux> :p
[00:05] <Daemon404> but not for ffmpeg as it has too many damn point releases concurrently
[00:05] <Daemon404> ubitux, please get your head out of GNU's ass.
[00:05] <ubitux> :D
[00:05] <sware> so why do you guys hate the idea of an msvc port, just as an antimicrosoft rant ?
[00:06] <JEEB> lawl
[00:06] <Daemon404> sware, im for it
[00:06] <Daemon404> but your approach is bad
[00:06] <sware> the manual approach ?
[00:06] <nevcairiel> i hate the idea of an manual port, because its unmaintainable
[00:06] <JEEB> yeah
[00:06] <sware> it's not maintainable
[00:06] <Daemon404> sware, converting structs make them annoyign as hell
[00:06] <Daemon404> for example
[00:06] <Daemon404> it's a maintainability thing
[00:06] <sware> I hate the idea of it too, I've spent the last four days porting swscale, avutil, and avformat
[00:06] <ubitux> and it's far from error-free
[00:06] <sware> lol
[00:07] <Daemon404> ubitux, some sort of proproc (perl) script to convert structs, inline asm, could be nice.
[00:07] <nevcairiel> BBB was working on a pre-processor script for google that will do all the modifications to make it build, sadly priorities seemed to have shifted and its not completely done yet
[00:07] <ubitux> ("oups i just forgot one NULL, i only have 412 NULL and i need 413")
[00:07] <Daemon404> nevcairiel, i said that already :P
[00:07] <JEEB> yeah, I hope BBB finishes it one day
[00:07] <sware> the reason I'm doing it manually right now
[00:07] <Daemon404> JEEB, just like he finished xvp8
[00:07] <ubitux> ("oups the struct was re-ordered and i didn't realized that")
[00:07] <Daemon404> oh wait
[00:07] <sware> is because I want to see what has changed since my last built
[00:07] <sware> from november
[00:08] <Daemon404> the only reason to build ffmpeg with msvc is for debugging
[00:08] <Daemon404> which admittedly
[00:08] <sware> so that when I write the vs plugins to do things automatically, I won't miss anything or make any mistakes
[00:08] <Daemon404> is a damn good reason
[00:08] Action: ubitux likes av_log debugging
[00:08] <nevcairiel> I wouldnt build a release version with it, it'll probably just be slow(er) then a gcc build
[00:08] <nevcairiel> ubitux: then you have never used a good debugger :p
[00:08] <sware> lol
[00:09] <ubitux> nevcairiel: i have colors with av_log, that's all i need to!
[00:09] <Daemon404> nevcairiel, most linux folks pish-posh ms;s debugger away
[00:09] <Daemon404> but yeah
[00:09] <Daemon404> it is the best
[00:09] <Daemon404> period.
[00:09] <ubitux> i never liked debuggers
[00:10] <ubitux> maybe because i didn't find a good one
[00:10] <nevcairiel> but yeah, being able to do JIT debugging inside avformat/avcodec would really make some things so much easier for me
[00:10] <Daemon404> because you use linux and they all suck
[00:10] <JEEB> Anything that comes close to MSVS's debugger is pretty much just qt creator's gdb crap. And that still pales in comparison.
[00:10] <sware> well
[00:10] <sware> thanks for the tip about AVDictionary
[00:10] <sware> avformat is building now 
[00:10] <sware> on to libavcodec 
[00:10] <Daemon404> nevcairiel, you can if you disable inline am and use icl
[00:10] <Daemon404> and like pain
[00:11] <nevcairiel> icl costs like .. alot
[00:11] <ubitux> i don't see much interest in debuggers
[00:11] <Daemon404> nevcairiel, welll... internet
[00:11] <Daemon404> ubitux, you must enjoy pain...
[00:12] <Daemon404> pritnf debugging can only take you so far
[00:12] <ubitux> the only thing where i use them is for assembly, but doesn't happen much
[00:12] <Daemon404> it's not efficiently, and its annoying
[00:12] <Daemon404> -y
[00:12] <ubitux> i find it more efficient :p
[00:12] Action: Daemon404 thinks ubitux has been fossing too long
[00:13] <ubitux> once in a while i use gdb to get a crash traceback
[00:13] <ubitux> but generally valgrind is more useful
[00:13] <Daemon404> valgrind is useful
[00:13] <Daemon404> but has a shit ui
[00:13] <ubitux> sometimes i use gdb to put a watchpoint, but that's all
[00:13] <nevcairiel> how is adding a bunch of log messages more useful then just adding a breakpoint and looking into the variables yourself?
[00:13] <ubitux> what's wrong with valgrind UI? oO
[00:13] <ubitux> valgrind ./blah, can't be simpler :p
[00:14] <Daemon404> nevcairiel, talking to linux folks about things liek usability and guis, and stuff like that
[00:14] <Daemon404> is a dead end
[00:14] <Daemon404> :/
[00:14] <ubitux> nevcairiel: it prints the "path history"
[00:14] <ohsix> fwiw, ms supporting "C" and "C++", i don't think they even support c++ very well, it's basically com interop for them; but they've put a vanishingly small larger amount of effort into it
[00:14] <Compn> Daemon404 likes his visual basic guis :)
[00:14] <Daemon404> yes cue the haters
[00:15] <Compn> why bring this canard up all of the time
[00:15] <Compn> lets talk subtitles or filters or something
[00:15] <ubitux> ah you meant the "valgrind GUI" Daemon404?
[00:15] <ohsix> being king of the shitpile isn't a victory btw
[00:15] <ubitux> (kcachegrind and stuff?)
[00:16] <ubitux> Daemon404: anyway, it's basically different methods
[00:16] <ohsix> printf debugging can act as a set of assertions while you're reasoning about what's going on, the problem is modifying the code to do it, and doing it again when you have fixed the problem
[00:17] <ubitux> i believe there is no good user-friendly debugger on linux because really no one care about
[00:17] <ohsix> you can do assertions that aren't modified constantly and get most of the benefit
[00:17] <Daemon404> ubitux, "theres no good user-friendly X on linux" 
[00:17] <Daemon404> where X is any number of thigs
[00:17] <Daemon404> ;)
[00:17] <ohsix> user friendly is a red herring
[00:17] <saste> btw: anyone interested in experimenting with gdb python scripting (adding pretty printers and stuff for libav*)?
[00:17] <Daemon404> ohsix, usable then
[00:17] <ohsix> you can't be friendly enough to my grandmother for her to figure out a debugger
[00:18] <ubitux> :D
[00:18] <ubitux> that's really the point
[00:18] <ohsix> +1 to not caring
[00:18] <ubitux> it's important to have user friendly stuff for non-programming stuff
[00:18] <ubitux> but for developers stuff, let's be honest, no one care :p
[00:19] <nevcairiel> so i conclude, linux users are not capable of using debuggers, hence none exist?
[00:19] <nevcairiel> :D
[00:19] <ohsix> if you are in the depths of sometehing looking at variables trying to figure out what they are with absoloutely no hint of how you got there then you have another problem
[00:19] <ohsix> i rarely need to use gdb, nothing is that complex
[00:20] <ohsix> i mainly use it to invoke things in the program to investigate what has happened
[00:20] <Daemon404> ohsix, how about when a codebase like ffmpeg crashes
[00:20] <Daemon404> inside, oh say, lav filters
[00:20] <saste> nevcariel: linux devs are too hardcore to use debuggers, they just read assembly (you see, the matrix...)
[00:20] <Daemon404> that is nontrivial to find
[00:20] <ubitux> valgrind gives a good traceback
[00:21] <ohsix> Daemon404: not my code base, if i did have to do it i'd  be adding assertions the whole way, so it would fail early
[00:21] <Daemon404> ohsix, crashes INSIDE ffmpeg
[00:21] <ohsix> it depends on the project if that is acceptable, it usually is
[00:21] <nevcairiel> sadly the ms debugger gets confused when the crash is in any library it doesnt have debug infos about
[00:21] <Daemon404> nevcairiel, it can print a disasm
[00:21] <Daemon404> same as any other debugger
[00:21] <JEEB> yeah
[00:21] <ubitux> then let's use another debugger
[00:21] <nevcairiel> sure, but unless thats a very specific yasm file, it wont help
[00:21] <ohsix> it crashes in a function, functions call other functions, i don't get the "inside ffmpeg" distinction?
[00:21] <sware> sorry one other thing
[00:22] <ohsix> do you mean when the stack is ruined by something bad?
[00:22] <sware> libavformat\rtpdec_h263_rfc2190.c doesn't have an enc_name for it's RTPDynamicProtocolHandler
[00:22] <ohsix> like, the hard problems that even a gui debugger isn't going to help you with
[00:22] <Daemon404> ohsix, so you would go inster asserts inside ffmpeg's internal functions
[00:22] <Daemon404> rather than use a debugger.
[00:22] <sware> which causes an error in debug built 
[00:23] <sware> giving it one fixes it, is there one that I can give it ?
[00:23] <ohsix> i'd do both, i said, in the process of debugging, if i had to; i would add assertions and verify my preconceptions or api contracts along the way, where they were lacking; and the problems are typically very obvious
[00:24] <ohsix> the assertions can stay there after i find the bug, which is different from printf debugging; but at the root of it they're both assertion based
[00:24] <michaelni> sware, does "" work as enc_name ?
[00:24] <sware> one sec
[00:24] <ohsix> failing early isn't desirable in some projects though, and it can be hard to find out what the api contract really is if they weren't setup like that in the first place
[00:25] <sware> michaelni: yes. empty works. Thanks 
[00:25] <nevcairiel> whats wrong with just using NULL as the name? thats what the structure there implies
[00:26] <nevcairiel> works fine for gcc
[00:26] <ohsix> anything that took an "object" and more than one operand with an "interesting" semantic should have assertions, that doesn't mean all internal leaf functions ;]
[00:26] <michaelni> nevcairiel, its enc_name[50] not *enc_name
[00:27] <ohsix> re: supporting msvc, why not just improve mingw? isn't it comparable effort?
[00:27] <nevcairiel> how odd, i would've figured its const char*
[00:27] <michaelni> dont ask me why its whatever[50] ...
[00:27] <sware> throws "COFF format cannot statically initialize 'var' with number byte(s) of an address" if it's null 
[00:28] <sware> I just didn't want to give it an innappropriate name
[00:28] <ubitux> mmh deshake filter is missing an explicit dep to lavc in the configure
[00:29] <michaelni> ubitux, add one 
[00:29] <ubitux> i was looking on how to add a lavc dep for my patch, and willing to seek how it was done for the deshake filter
[00:29] <nevcairiel> ohsix: if by improve mingw you mean making mingw-gcc output msvc compatible debug symbols, good luck with that, the format isn't that well documented :P
[00:29] <ohsix> Daemon404: the best part about asserts is you can compile them out :] you get a crazy unverifiable ball of muck when you do, but that's what you've got already in most cases, but then you can compile them back in and run a failing program with it
[00:29] <ubitux> now i don't know where to look for :p
[00:29] <nevcairiel> mingw works just perfectly, it just doesnt allow debugging with windows tools
[00:30] <ohsix> nevcairiel: ah, i didn't mean that, but that is interesting
[00:30] <ohsix> i'll have to look into that
[00:30] <ohsix> i'd be really surprised if there wasn't a tool already that converted dwarf/stabs/whatever into a pdb and stripped the original
[00:31] <nevcairiel> also, once you're done adding all these asserts to ffmpeg, you'll have forgotten which bug you wanted to fix :)
[00:31] <sware> The anti msvc sentiment is strong in this one :)
[00:31] <ohsix> no i wouldn't, it would still be on bugzilla with my  name on it :]
[00:31] <ubitux> mmh deshake_filter_deps="avcodec"
[00:31] <ubitux> should do the trick.
[00:31] <michaelni> ubitux, yes, j
[00:31] <michaelni> s/j//
[00:32] <ohsix> i could always rebase my assert version and keep it private, but that wouldn't make it much more novel than printf debugging with respect to the doing and undoing of changes
[00:32] <ohsix> and you can script asserts with gdb :]
[00:33] <ohsix> it takes a while to figure out what's really going to help you in gdbinit, but you can basically have the program interrogated any time you start it in gdb, check for common problems and whatnot
[00:34] <CIA-119> ffmpeg: 03Clément BSsch 07master * r5c3f79198c 10ffmpeg/configure: lavfi/deshake: add libavcodec dependency (dsputil).
[00:57] <CIA-119> ffmpeg: 03Michael Niedermayer 07release/0.11 * rd108d0804a 10ffmpeg/Changelog: 
[00:57] <CIA-119> ffmpeg: Changelog, spell out the CVEs that where fixed.
[00:57] <CIA-119> ffmpeg: there are some holes in the list as some things have been fixed
[00:57] <CIA-119> ffmpeg: in previous releases already.
[00:57] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:57] <CIA-119> ffmpeg: (cherry picked from commit aeb2dea80256379e38cdd5f5e86ae70de8ef5346)
[00:57] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:57] <CIA-119> ffmpeg: 03Michael Niedermayer 07release/0.11 * r982caeac3e 10ffmpeg/libavfilter/af_aresample.c: 
[00:57] <CIA-119> ffmpeg: af_aresample: fix pts, they where off by a packet in the -async >0 case.
[00:57] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:57] <CIA-119> ffmpeg: (cherry picked from commit be97675e6cf686900ea4ff39251cec94cfe4109c)
[00:57] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:57] <CIA-119> ffmpeg: 03Alexis Ballier 07release/0.11 * r51157dab37 10ffmpeg/tests/fate/video.mak: 
[00:57] <CIA-119> ffmpeg: Fix tests without fate samples.
[01:14] <CIA-119> ffmpeg: 03Carl Eugen Hoyos 07master * rab7d6cb8f7 10ffmpeg/ (libavcodec/raw.c libavcodec/rawdec.c libavformat/riff.c): 
[01:14] <CIA-119> ffmpeg: Support decoding fourcc YVYU.
[01:14] <CIA-119> ffmpeg: Based on work by ami_stuff.
[01:14] <CIA-119> ffmpeg: Fixes ticket #1352
[01:41] <ubitux> saste: nice
[01:41] <ubitux> i'll review your ffprobe patches in ~10 hours :)
[01:42] <saste> no hurry
[01:42] <ubitux> when my brain will be available again
[03:44] <ubitux> can we assume the video buffers in lavfi are 16-aligned?
[03:45] <ubitux> (so i can use dspcontext.sad[0] unconditionnally)
[04:42] <Tjoppen> michaelni: uh.. I think so
[09:40] <RobertNagy> in ffplay "queue_picture" is "frame_delay = av_q2d(is->video_st->codec->time_base);" rly correct?
[09:40] <RobertNagy> shouldn't it look at the filter graph time_base?
[09:40] <RobertNagy> and also it seems to assume that 1 frame == 1 pts, which isn't always the case
[11:48] <michaelni> ubitux, see AV_PERM_ALIGN, but i think some filters dont test for it that should
[11:48] <ubitux> mmh ok, thx
[11:50] <ubitux> it would be nice if vf fps was doing motion compensation instead of duplicating frames.. :x
[11:51] <michaelni> yes
[13:26] <ubitux> michaelni: "audio filters support in libavfilter and avconv"  should we s/avconv/ffmpeg/ or just remove that entry?
[13:27] <ubitux> maybe "complete audio filtering in libavfilter and ffmpeg"?
[13:27] <ohsix> is it part of a series? why not as-is
[13:27] <ubitux> ?
[13:28] <ohsix> nevermind, i forgot there was a tool called avconv/ffmpeg
[13:29] <ubitux> there are two issues with the sentence
[13:29] <ubitux> first avconv instead of ffmpeg, but also the audio support we have since long ago :p
[13:30] <ohsix> oic
[13:53] <burek> -af? :))
[13:55] <burek> oh.. now I know what does this button do :S
[13:57] <ubitux> burek: yes -af is new, that's why i'm proposing "complete audio filtering in libavfilter and ffmpeg"
[13:58] <burek> cool :)
[14:57] <michaelni> ubitux, feel free to reword it as you prefer
[14:58] <ubitux> ok
[14:58] <ubitux> done
[15:00] <michaelni> ubitux, i think its in Changelog in master & release/0.11 too (from where i copied it)
[15:02] <ubitux> the changelog has a lot of avconv entries
[15:02] <ubitux> (the file)
[15:10] <michaelni> true but that latest entry is definitly wrong
[15:28] <CIA-119> ffmpeg: 03Clément BSsch 07master * r80bf2b6e84 10ffmpeg/Changelog: Changelog: fix wrong/inaccurate entries.
[15:44] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r65212e3ed9 10ffmpeg/libavformat/mxfdec.c: 
[15:44] <CIA-119> ffmpeg: mxfdec: remove unused last_index_duration
[15:44] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:44] <CIA-119> ffmpeg: 03Vitor Sessak 07master * r2fd5e70869 10ffmpeg/libavcodec/x86/ (fft.c fft.h fft_3dn2.c fft_mmx.asm): 
[15:44] <CIA-119> ffmpeg: x86: use new schema for ASM macros
[15:44] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:44] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * rfcd08262fd 10ffmpeg/ (7 files in 3 dirs): 
[15:44] <CIA-119> ffmpeg: tests and tools: cleanup ffmpeg reference
[15:44] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[15:44] <michaelni> ubitux, thx
[15:46] <ubitux> i won't mess with the branches though
[16:06] <CIA-119> ffmpeg: 03Marton Balint 07master * ra687acbbf0 10ffmpeg/ffplay.c: 
[16:06] <CIA-119> ffmpeg: ffplay: dont destroy packet queues on stream change
[16:06] <CIA-119> ffmpeg: This fixes occasional segfaults caused by lock request of the packet queue from
[16:06] <CIA-119> ffmpeg: the reader thread.
[16:06] <CIA-119> ffmpeg: Also don't allow to put frames into the queue when it's aborted, and don't try
[16:06] <CIA-119> ffmpeg: to fill the queue with frames when it is aborted.
[16:06] <CIA-119> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[16:06] <CIA-119> ffmpeg: 03Marton Balint 07master * rc2e8691c07 10ffmpeg/ffplay.c: 
[16:06] <CIA-119> ffmpeg: ffplay: flush codec buffers before freeing filters
[16:06] <CIA-119> ffmpeg: We do this to ensure that input_get_buffer is not called from a
[16:06] <CIA-119> ffmpeg: frame_worker_thread of a multithreaded decoder when we already freed the
[16:06] <CIA-119> ffmpeg: filters.
[16:06] <CIA-119> ffmpeg: Fixes occasional segfaults on video stream change.
[16:06] <CIA-119> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[16:39] <ubitux> burek: having an eval for the volume filter would be nice indeed
[16:39] <ubitux> i'm not sure how well we could do that with the volume filter though
[16:39] <ubitux> since it can supports dB unit
[17:32] <CIA-119> ffmpeg: 03Marton Balint 07release/0.11 * rf8f5db3b70 10ffmpeg/ffplay.c: (log message trimmed)
[17:32] <CIA-119> ffmpeg: ffplay: dont destroy packet queues on stream change
[17:32] <CIA-119> ffmpeg: This fixes occasional segfaults caused by lock request of the packet queue from
[17:32] <CIA-119> ffmpeg: the reader thread.
[17:32] <CIA-119> ffmpeg: Also don't allow to put frames into the queue when it's aborted, and don't try
[17:32] <CIA-119> ffmpeg: to fill the queue with frames when it is aborted.
[17:32] <CIA-119> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[17:32] <CIA-119> ffmpeg: 03Clément BSsch 07release/0.11 * r1ed0a61ea8 10ffmpeg/Changelog: 
[17:32] <CIA-119> ffmpeg: Changelog: fix wrong/inaccurate entries.
[17:32] <CIA-119> ffmpeg: (cherry picked from commit 80bf2b6e841e51ed1cb073dc0e460749ac19284f)
[17:32] <CIA-119> ffmpeg: Conflicts:
[17:32] <CIA-119> ffmpeg:  Changelog
[17:32] <CIA-119> ffmpeg: 03Marton Balint 07release/0.11 * rc7c82acf96 10ffmpeg/ffplay.c: (log message trimmed)
[17:32] <CIA-119> ffmpeg: ffplay: force exit when filter configuration fails
[17:32] <CIA-119> ffmpeg: Switching to visualization instead of exiting ffplay is a bit more tricky, so
[17:32] <CIA-119> ffmpeg: just exit for now.
[17:32] <CIA-119> ffmpeg: Fixes ticket 38.
[17:32] <CIA-119> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[17:32] <CIA-119> ffmpeg: (cherry picked from commit 7315e40a24e85e7f141db77951a4b14375fde55a)
[17:32] <CIA-119> ffmpeg: 03Clément BSsch 07release/0.11 * r9f2905d299 10ffmpeg/configure: 
[17:32] <CIA-119> ffmpeg: lavfi/deshake: add libavcodec dependency (dsputil).
[17:32] <CIA-119> ffmpeg: (cherry picked from commit 5c3f79198c016980b8bd5e876761eb42341c3cec)
[17:32] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[17:32] <CIA-119> ffmpeg: 03Marton Balint 07release/0.11 * rf6c3fe94da 10ffmpeg/ffplay.c: (log message trimmed)
[17:32] <CIA-119> ffmpeg: ffplay: flush codec buffers before freeing filters
[17:32] <CIA-119> ffmpeg: We do this to ensure that input_get_buffer is not called from a
[17:32] <CIA-119> ffmpeg: frame_worker_thread of a multithreaded decoder when we already freed the
[17:32] <CIA-119> ffmpeg: filters.
[17:32] <CIA-119> ffmpeg: Fixes occasional segfaults on video stream change.
[17:32] <CIA-119> ffmpeg: Signed-off-by: Marton Balint <cus at passwd.hu>
[17:32] <CIA-119> ffmpeg: 03Marton Balint 07release/0.11 * r727749d30f 10ffmpeg/ffplay.c: 
[17:32] <CIA-119> ffmpeg: ffplay: fix stream cycling if audio decoding fails
[23:02] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r875851294f 10ffmpeg/libavformat/avienc.c: 
[23:02] <CIA-119> ffmpeg: avienc: create xsub in avi files that are closer to whats in the wild
[23:02] <CIA-119> ffmpeg: Fixes ticket1332
[23:02] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:27] <ubitux> michaelni: OK for me about repositories, thanks
[23:27] <ubitux> (for mine of course)
[00:00] --- Mon May 28 2012