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

[burek]

[00:00] <ubitux> ah indeed, looks broken in the tickets
[00:00] <ubitux> "DatabaseError: database disk image is malformed"
[00:00] <ubitux> doesn't sound good
[00:00] <cehoyos> https://ffmpeg.org/trac/ffmpeg/report/1 fails
[00:22] <BBB-work> Daemon404, ?
[00:22] <Daemon404> the webm site doesnt even link to tarballs
[00:22] <Daemon404> for libvpx
[00:22] <Daemon404> just git
[00:23] <Daemon404> one could infer that it means "just use git"
[00:29] <BBB-work> maybe ask jk8 on #vp8
[00:30] <BBB-work> I'm not sure
[00:30] <BBB-work> I thought they were linked to somewhere
[00:30] <Daemon404> ok
[00:30] <Daemon404> wrt the first thing: can ffmpeg encode webp?
[00:30] <Daemon404> if not i may add it (maybe)
[00:32] <BBB-work> I thought I saw a patch at some point
[00:32] <BBB-work> I'm not sure it was ever committed
[00:32] <BBB-work> pascal submitted it long long ago
[00:32] <Daemon404> ic
[00:33] <Daemon404> maybe ill just use libwebp directly
[00:33] <Daemon404> im using ijg anyway
[00:34] <ubitux> ffmpeg can decode some webp natively so far (i know you want encoding)
[01:34] <Compn> someone actually WANTS to make a webp file ?
[01:34] Action: Compn makes with the jokes
[01:44] <saste> http://pastie.org/7991269
[01:45] <ubitux> hehehe
[02:36] <cone-784> ffmpeg.git 03Clément BSsch 07master:716dbc7e13c1: lavf/allformats: align nit for tee muxer.
[08:41] <nevcairiel> so weird, on my local dev system a fate test fails with gcc 4.8.1, but on my fate box the same test succeeds
[08:51] <nevcairiel> hm, apparently using --cpu=i686 triggers it, silly gcc
[09:27] <burek> is there anyone willing to help a little bit regarding some kind of memory leak, while using ffmpeg libraries through the code: http://ffmpeg.gusari.org/viewtopic.php?f=16&t=939
[10:26] <cone-319> ffmpeg.git 03Alex Smith 07master:14fb9d3d8ccf: configure: Separate commonalities in msvc and icl flags
[10:26] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:b919a8d3a385: Merge commit '14fb9d3d8ccf5f50180aabdb1afe8b570fea3d28'
[10:32] <cone-319> ffmpeg.git 03Alex Smith 07master:60f09c04d80a: configure: icl: Merge -Qdiag-error parameters
[10:32] <cone-319> ffmpeg.git 03Kostya Shishkov 07master:33f64fd5d588: indeo4: expand allowed quantiser range
[10:32] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:0c2f673ed28a: Merge remote-tracking branch 'qatar/master'
[10:59] <cone-319> ffmpeg.git 03James Almer 07master:c485c835fef4: avutil/crc: Dont limit CRC32 standard tables
[11:48] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:6cbd0241f216: jpeg2000dec: optimize dequantization_float()
[11:48] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:dc60061bb6e3: jpeg2000dec: optimize dequantization_int()
[11:54] <ubitux> michaelni: did you see the dep issue with j2k?
[11:55] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20130601015031&slot=x86_64-archlinux-gcc-random
[11:58] <cone-319> ffmpeg.git 03Carl Eugen Hoyos 07master:f1c8413dc7db: Fix compilation with --disable-everything --enable-encoder=jpeg2000
[11:58] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:35cf069aeaba: Merge remote-tracking branch 'cehoyos/master'
[11:59] <michaelni> ubitux, i didnt but carl did :)
[12:01] <ubitux> hehe
[12:15] <cone-319> ffmpeg.git 03Clément BSsch 07master:7ba04b3c4835: lavfi/pixdesctest: fix chroma subsampling with odd sizes.
[12:15] <cone-319> ffmpeg.git 03Clément BSsch 07master:1fb52bf92076: lavfi/mptestsrc: fix chroma subsampling with odd sizes.
[12:50] <nevcairiel> hm, jpeg2000 seems to crash now on a dcinema sample that worked before ... lets see whats wrong
[12:59] <nevcairiel> it also seems slower then a week ago
[13:07] <michaelni> nevcairiel, slower ? can you find our which commit caused it ?
[13:08] <nevcairiel> i was able to play a 24 fps sample nearly properly, was like 20 fps or so, not is barely 10
[13:08] <nevcairiel> not=now
[13:08] <nevcairiel> also, jpeg2000_dec_cleanup crashes if s->tile is NULL
[13:08] <nevcairiel> i will try to find the speed thing
[13:09] <michaelni> nevcairiel, how do i reproduce the crash?
[13:09] <nevcairiel> i have a file called PopcornCombo_Video.mxf, when i play that with one thread, it goes boom, i forgot where i got it
[13:10] <nevcairiel> for some reason, multiple threads do not crash
[13:10] <Compn> race condition?
[13:14] <michaelni> can you share the file or how can i reproduce without the file? i could of course just add a null check but i want to make sure i understand the issue fully before 
[13:22] <nevcairiel> http://www.d-cine.net/trailers/Promos/CandyBar/PopcornCombo_advertisement_DCP.zip
[13:22] <nevcairiel> thats the sample i used
[13:22] <nevcairiel> its slightly huge
[13:22] <nevcairiel> 2k dcinema and all
[13:24] <nevcairiel> i also used that one for benchmarking
[13:29] <nevcairiel> hm odd, ffmpeg doesnt seem to crash it, my own app does though
[13:30] <nevcairiel> guess more digging needed
[13:50] <ubitux> mmh there is a bug in the av packet split data code
[13:58] <ubitux> oh i get it
[13:58] <ubitux> the padding is not 0 in the data
[14:03] <ubitux> michaelni: does this make any sense? http://pastie.org/7992868
[14:18] <michaelni> ubitux, does make sense but please make sure you dont write over the original size
[14:18] <michaelni> theoretically there should be padding after the original size that you could write into
[14:18] <michaelni> but its a easy to make mistake to forget the padding on allocation
[14:19] <ubitux> ah i already send the patch
[14:19] <ubitux> michaelni: you mean i should check that there is actually some padding allocated and/or check if it's zero?
[14:20] <ubitux> or just check if it's zero? (just memcpy?)
[14:20] <michaelni> you cant check that its allocated or what its value is
[14:20] <ubitux> actually, memmove
[14:20] <ubitux> if it's not allocated it's a bug IMO
[14:21] <ubitux> if demuxers are using av packets utils it should not happen
[14:21] <michaelni> yes but you would be adding a security issue if you wrote into it
[14:21] <michaelni> and it was not allocated
[14:22] <michaelni> what i meant was to only zero the bytes that fell into the packet size
[14:22] <ubitux> ok, i see
[14:22] <michaelni> the ones after it should (in absece of a bug be zero already)
[14:23] <ubitux> ok so no memmove necessary, just a size check
[14:23] <ubitux> i'll add a av_log warning though if that happens
[14:23] <ubitux> unless you object
[14:24] <ubitux> ah wait i misunderstand
[14:24] <michaelni> nevcairiel, i cant reproduce the null ptr issue, also nothing with address sanitizer
[14:25] <michaelni> if you can reproduce it maybe adding a few av_log to see how/where tile becomes NULL and the numX/Ytiles is not 0 would be interresting
[14:27] <ubitux> michaelni: so if the side data occupying the pkt->data is < FF_INPUT_BUFFER_PADDING_SIZE not all the padding will be filled, right?
[14:27] <ubitux> this doesn't sound like a reliable behaviour
[14:27] <nevcairiel> michaelni: there was a related log message, [jpeg2000 @ 10FF04C0] SOC marker not present
[14:28] <nevcairiel> but i'll do more investigation later
[14:28] <michaelni> ubitux, wrong, the other padding bytes must have been filled by the original packet allocation
[14:29] <ubitux> ooh indeed
[14:42] <cone-319> ffmpeg.git 03Michael Niedermayer 07master:9054e7252968: jpeg2000: make sure s->numXtiles / s->numYtiles are reset when tile is deallocated
[14:42] <michaelni> nevcairiel, maybe my last comit fixed the null ptr issue
[15:13] <cone-319> ffmpeg.git 03Clément BSsch 07master:151b4947e5d2: lavc/avpacket: fill padding area on side data split.
[15:13] <cone-319> ffmpeg.git 03Matthew Heaney 07master:8f75ba9926c6: lavf/webvttdec: save cue id and settings as side data
[15:13] <cone-319> ffmpeg.git 03Clément BSsch 07master:07f6a66bf553: lavf/webvttdec: factorize identifier and settings side data code.
[15:29] <ubitux> BBB-work: don't want to invite Matthew here?
[15:30] <ubitux> also, i guess he's planning to add webvtt muxing into webm?
[16:42] <saste> michaelni, can I proceed with my mcdeint plan?
[16:57] <burek> guys, how do you feel about swig support in ffmpeg? http://en.wikipedia.org/wiki/SWIG
[17:00] <saste> burek, do you want to help?
[17:00] <burek> always
[17:00] <saste> i'm currently working on lua scripting in libavfilter and would take time
[17:01] <saste> using swig for extensive libav* scripting also would be a possibility, but i have not enough experience to assess the feasibility
[17:01] <burek> i'm familiar with lua
[17:01] <burek> i can help perhaps
[17:02] <saste> burek, lua <-> c interfacing?
[17:02] <saste> something like passing an AVFrame around from C to lua and back?
[17:02] <burek> more in lua programming, but i can check tutorials for interfacing too
[17:02] <saste> well get to go now, we'll talk about it later
[17:02] <burek> ok
[17:13] <michaelni> saste you always timeout when i want to reply
[17:13] <michaelni> reply sentt to ml
[17:17] <ubitux> :)
[17:21] <nevcairiel> michaelni: crash is fixed
[17:21] <nevcairiel> also, this is so confusing, when i disable threading i get a lot of [jpeg2000 @ 10020B40] SOC marker not present
[17:21] <nevcairiel> when i use two threads
[17:22] <nevcairiel> nothing
[17:22] Action: nevcairiel shakes head
[17:22] <JEEB> o_O
[17:22] <JEEB> how can...
[17:22] <JEEB> I don't...
[17:23] <nevcairiel> guess its debugging time
[17:24] <nevcairiel> not to mention that i really thought single threaded performance was above 2 fps at some point
[17:24] <nevcairiel> but that i will test
[17:29] <Compn> nevcairiel : frame or slice threading ?
[17:29] <nevcairiel> frame
[17:31] <nevcairiel> hm
[17:32] <nevcairiel> all i can think of that would explain this is that there is somehow garbage or otherwise unused data at the end of the frames
[17:32] <nevcairiel> the threaded decoders by definitiion always consume the full frame
[17:32] <nevcairiel> the single threaded consumes whatever the decoder says it consumers
[17:32] <nevcairiel> -r
[17:32] <nevcairiel> so apparently it gets called with some half-frame
[17:33] <nevcairiel> because i actually handle those return values
[17:36] <cehoyos> Compn, nevcairiel: Could you look at ticket 2616? Is it really impossible to encode alpha with VirtualDub?
[17:37] <nevcairiel> i have zero experience with virtualdub
[17:42] <TheRyuu> cehoyos: impossible to encode alpha meaning what exactly?
[17:44] <cehoyos> That is my question;-)
[17:44] <JEEB> I don't think vdub kills off alpha in any way?
[17:44] <JEEB> if the source has it
[17:44] <cehoyos> We have a sample that is said to contain transparency information but we know that the information is just "being opaque".
[17:45] <cehoyos> What we would need - imo - is a sample with the same type of transparency information but with actual transparency in the source - see ticket 2616
[17:45] <cehoyos> But I cannot explain ami_stuff how to encode this because I know nothing about VirtualDub...
[17:45] <TheRyuu> vdubmod from 10 years ago had a bug that converted everything interally to yuy2
[17:46] <TheRyuu> but any remotely recent virtualdub will handle alpha fine
[17:46] <TheRyuu> s/handle/should/
[17:46] <TheRyuu> err
[17:46] <TheRyuu> s/will/should/
[17:46] <TheRyuu> provided it is what I think it is
[17:47] <TheRyuu> you just have to be sure to use fast recompress so virtualdub does not touch it
[17:50] <TheRyuu> unless I'm misunderstanding something in which case I could be talking about the wrong thing right now
[17:50] <cehoyos> Perhaps you could test with http://www.matrox.com/video/en/support/windows/vfw_software_codecs/downloads/softwares/version1.0/build33/ ?
[17:50] <TheRyuu> I'm not sure I follow the ticket
[17:54] <TheRyuu> what uses 'matrox mpeg2 iframe with alpha codec', sounds like something some capture card would use although I'm not sure what the alpha is for
[17:54] <Compn> cehoyos : i have zero clue about alpha stuff
[17:55] <Compn> nor vdub...
[17:55] <Compn> i mean vdub+alpya
[17:56] <cehoyos> TheRyuu: Afaict, it is a codec that you can download to use with vfw-compatible sofware (I don't see how you could capture transparency)
[17:56] <TheRyuu> perhaps I just need to understand why
[17:57] <TheRyuu> because right now I don't get it
[17:57] <Compn> i think matrox uses its own encoder software with that codec
[17:57] <Compn> probably unsupported if using vdub
[17:57] <cehoyos> There is a mpeg2video-"compatible" codec that does not just encode yuv422 but yuv422 plus transparency information.
[17:58] <cehoyos> The additional information in the bitstream is "visible" (artefacts) when decoding with libavcodec, goal 1 is to avoid the artefacts when decoding such samples.
[17:58] <TheRyuu> I've really only ever dealt with rgb32 lags
[17:58] <Compn> cehoyos : whats it look like in other mpeg2 decoders ?
[17:59] <cehoyos> Goal 2 - imo - would be to decode the transparency information (that may be impossible without specification), but this is probably impossible if we already know that the sample does not contain actual transparency.
[17:59] <cehoyos> So my question is: Can somebody use the codec  - http://www.matrox.com/video/en/support/windows/vfw_software_codecs/downloads/softwares/version1.0/build33/ - to encode a sample of which we know that it contains transparency?
[18:00] <cehoyos> If one of you is able to use VirtualDub (I am not) it should be easy to take a RGB32 sample and encode it with this codec.
[18:00] <Compn> ok i will try :P
[18:00] <Compn> do you have an alpha sample i can use ?
[18:00] <Compn> or easy way to generate one
[18:01] <Compn> (vdub likes avi input)
[18:01] <Compn> not flv or mp4 or mkv...
[18:01] <cehoyos> One link is in the ticket, you can use ffmpeg -i input -vcodec png out.mov to produce a more compatible file
[18:01] <cehoyos> There is (at least) another file on samples, but I did not find it yesterday (one that is not vp6a)
[18:01] <cehoyos> Try ffmpeg -i vp6a-sample -vcodec png out.avi
[18:02] <Compn> do we have any alpha fate tests? :P
[18:02] <cehoyos> If that does not work, I will look for another useful codec.
[18:02] <Compn> you sure that will retain alpha in avi ?
[18:02] <Compn> ehe
[18:02] <cehoyos> What's wrong with the link in the ticket?
[18:02] <cehoyos> http://samples.ffmpeg.org/FLV/flash_with_alpha/
[18:03] <Compn> that link
[18:03] <Compn> or vd_... ?
[18:03] <Compn> which video should i try 
[18:03] <Compn> i mean
[18:04] <cehoyos> Please open http://samples.ffmpeg.org/FLV/flash_with_alpha/ then download one (1) of the videos there and try to convert to png in avi
[18:04] <cehoyos> I can provide a command line if you tell me which of the videos you downloaded (I cannot decide)
[18:04] <Compn> well i think theres still a problem with the larashadow
[18:05] <Compn> let me see if it works in flash player real quick
[18:05] <Compn> argh what was the name of that flash player
[18:05] <Compn> 3rd party one
[18:06] <cehoyos> larashadow works fine with ffmpeg....
[18:06] <Compn> whats it look like ?
[18:06] <cehoyos> But perhaps your screen doesn't succeed in display transparency information (mine neither)?
[18:06] <Compn> lol?
[18:06] <cehoyos> *ing (?)
[18:06] <Compn> i tested in ffplay
[18:06] <Compn> should i test in ffmpeg ?
[18:07] <cehoyos> Yes, afair, ffplay (also) does not succeed in displaying transparency information, the reason is the SDL does not support it, the reason being that no screens support it;-)
[18:07] <Compn> lol
[18:08] <Compn> using ffmpeg on larashadow i still dont get anything
[18:08] <Compn> with -vcodec png or not
[18:10] <Compn> i unfortunately have to go soon, so i wont be able to finish this
[18:11] <Compn> is there no way to display transparencies in ffmpeg or mplayer ? :P
[18:11] <Compn> ffplay / mplayer that is
[18:11] <cehoyos> ffmpeg -f lavfi -i testsrc=s=310x449 -i laraShadow_dl.flv -filter_complex overlay -t 20 out.avi (still working on the ffplay command line)
[18:12] <BBB> ubitux: well that's his own choice right?
[18:13] <Compn> cehoyos : oh, neat :)
[18:15] Action: Compn afk
[18:15] <Compn> bbl
[18:15] <ubitux> BBB: huh, sure :))
[18:16] <cehoyos> Filter-experts, why does the following not work? ffplay -i laraShadow_dl.flv -an -vf testsrc=s=310x449,overlay
[18:16] <ubitux> try to put '[in]' just before overlay
[18:16] <cehoyos> ubitux: You probably know my answer wrt auto-detection, but I am currently trying to fix a (nearly important) bug in configure, not a bug in the general behaviour
[18:17] <cehoyos> Compn: Thanks to ubitux: ffplay -f lavfi -i testsrc=s=310x449 -vf movie=laraShadow_dl.flv,[in]overlay
[18:17] <Compn> cehoyos : neat! :)
[18:18] <cehoyos> (But I don't understand why it only works with testsrc as input and lara as movie input but not with lara as input and testsrc as filter)
[18:18] <ubitux> cehoyos: right, but i was asking about your patch actually; i still don't know what's the expected behaviour
[18:18] <ubitux> the issue only appears when it is explicited, right?
[18:19] <cehoyos> I am just trying to fix the current behaviour, if this is not a regression (I don't know - yet), we could change it, but this should be discussed, atm, I am - as said - trying to fix a nasty bug.
[18:19] <ubitux> what is the current behaviour?
[18:19] <ubitux> auto detect or no?
[18:19] <ubitux> are you changing it while fixing the bug?
[18:19] <Compn> cehoyos : anyways, which command line to generate a sample from larashadow so i can put it to vdub? i have to go now, but will run it later
[18:22] <cehoyos> ubitux: No, I am - explicitely - NOT changing current behaviour, if this patch were about changing current behaviour, I would say so to make it clear and to give people the chance to discuss. The patch is only about fixing ticket #2624 (which I consider nearly important) as said in the mail iirc. I will now test if the current behaviour is a regression (and withdraw my patch in that case).
[18:23] <ubitux> cehoyos: you still don't answer my first question, what is the current behaviour?
[18:23] <cehoyos> TheRyuu: Does ami_stuff's jpg maybe indicate that he is using an ancient VirtualDub version?
[18:24] <cehoyos> ubitux: As configure --help explains, current behaviour is to only enable on "--enable-libcdio" (I did not yet test for a possible regression, will do in a moment)
[18:26] <ubitux> cehoyos: ok, that was not obvious because there is no "[no]"
[18:26] <ubitux> in that case, the "die" is correct, and your patch is fine
[18:27] <cehoyos> ubitux: Not a regression, and please note that auto-detection is impossible / would be a major change / would be contrary to what we do for x11grab
[18:28] <ubitux> i'm not asking for auto-detection
[18:28] <ubitux> but since that check is mixed with the other auto-detected stuff
[18:28] <ubitux> and is making a die
[18:29] <ubitux> i was just making sure it was not auto-detected
[18:29] <ubitux> its current position in the configure and the help on top was not so obvious about that
[18:29] <ubitux> that was my entire point :p
[18:29] <cehoyos> But how is this point related to ticket 2614 ?
[18:30] <cehoyos> (Assuming there is no regression)
[18:30] <cehoyos> .. which I had not tested before you suggested testing
[18:30] <ubitux> the ticket didn't mention if it was auto detected
[18:30] <cehoyos> Sorrry, 2614
[18:31] <ubitux> and it *LOOKED* like it was auto-detected
[18:31] <ubitux> in which case your patch would have break it
[18:31] <cehoyos> Lets assume for a moment it were auto-detected:
[18:31] <cehoyos> The user specifies "--enable-libcdio" which should make no difference if it were autodetected (or do you disagree?)
[18:31] <ubitux> (because calling die if auto-detected would break every configure run where there is no cdio)
[18:31] <cehoyos> The user runs "make" and make fails.
[18:32] <cehoyos> What would that change about the ticket?
[18:32] <ubitux> nothing about the ticket but the commit would have introduced a regression
[18:32] <ubitux> (aka breaking when library not found while trying to auto detect)
[18:33] <ubitux> but that was just hypothesis and your patch looks fine, so don't bother too much about it
[18:33] <cehoyos> I know I should be careful with the following sentence because I sent a patch yesterday that definitely did not work (but it was late and I wrote "please review" because I expected it to be more difficult) but I honestly (usually) test my patches and if you cannot test that patch without uninstalling cdio(-devel), so somehow I don't know how this should happen...
[18:33] <cehoyos> s/if/since
[18:40] <cehoyos> To answer my question above, the following works fine: ffplay laraShadow_dl.flv -vf testsrc=s=310x449[o],[o][in]overlay
[18:43] <ubitux> you should use a ';' instead of a ',' here
[18:43] <ubitux> or remove the [o]
[18:44] <cehoyos> You mean it should not work?
[18:44] <ubitux> yes
[18:44] <cehoyos> But it works;-((
[18:44] <ubitux> it's like you're feeding overlay with 3 sources
[18:44] <ubitux> but since two of them are identical maybe the framework overunderstand you
[18:44] <cehoyos> Removing the "[o]" does not work - or do I misunderstand?
[18:45] <ubitux> i guess you did that to swap?
[18:45] <cehoyos> (What do you mean with "or remove the [o]"?)
[18:45] <cehoyos> What command line do you mean with "or remove the [o]"?
[18:45] <ubitux> testsrc=s=310x449,[in]overlay or testsrc=s=310x449[o];[o][in]overlay
[18:45] <ubitux> but i guess that's not the same?
[18:45] <ubitux> (like not the same one being the overlay)
[18:45] <cehoyos> And I also fail to use ";"
[18:46] <ubitux> huh?
[18:46] <cehoyos> "testsrc=s=310x449[o];[o][in]overlay" does not work here (error message)
[18:47] <cehoyos> As said, testsrc=s=310x449,[in]overlay does not work / does not do what I wanted it to do
[18:47] <ubitux> dunno i didn't follow really the point
[18:47] <ubitux> it looks like you're using what you want to overlay as input
[18:47] <ubitux> which seems not reasonable
[18:48] <cehoyos> I originally had "ffplay laraShadow_dl.flv -vf .... and I did not succeed in displaying what I wanted.
[18:48] <cehoyos> So I changed to "ffplay -f lavf -i testsrc ... -vf ..." and it worked fine
[18:48] <ubitux> what's the goal?
[18:48] <cehoyos> Then I found how to use ffplay: "ffplay laraShadow_dl.flv -vf testsrc=s=310x449[o],[o][in]overlay"
[18:48] <cehoyos> which works.
[18:48] <ubitux> overlay a testsrc on the flv?
[18:49] <cehoyos> "ffplay laraShadow_dl.flv -vf testsrc=s=310x449,[in]overlay" is what I had originally (it works, but is not what I wanted)
[18:49] <ubitux> ah, you want to overlay laraShadow_dl.flv on testsrc?
[18:49] <cehoyos> "ffplay laraShadow_dl.flv -vf testsrc=s=310x449[o];[o][in]overlay" fails because it needs more """
[18:49] Action: ubitux is lost
[18:50] <cehoyos> Yes, I am not interested in overlaying testsrc over a semitransparent movie ;-)
[18:50] <ubitux> you need to quote the vf in case you use ';' of course, since it's a shell separator
[18:50] <cehoyos> I did not yet understand the advantage of ";" over ",", could you explain again?
[18:51] <ubitux> by "it works, but is not what i wanted", what do you mean?
[18:51] <ubitux> cehoyos: ';' separate "independant" subgraphs
[18:51] <ubitux> ',' is a "sucessive" separator (the output is directly linked to the next one)
[18:51] <cehoyos> I did not want to overlay testsrc over a semi-transparent movie, but I wanted to overlay a semi-transparent movie over testsrc.
[18:52] <cehoyos> I originally only succeeded with ffplay -f lavfi -i testsrc
[18:52] <ubitux> well
[18:53] <ubitux> in that case you need to -f lavfi testsrc=s=310x449 -vf 'movie=laraShadow_dl.flv, [in] overlay'
[18:53] <cehoyos> If only two filters are used, how does it make a difference if the subgraphs are independant?
[18:54] <cehoyos> [18:17] <cehoyos> Compn: Thanks to ubitux: ffplay -f lavfi -i testsrc=s=310x449 -vf movie=laraShadow_dl.flv,[in]overlay
[18:55] <ubitux> using your command line with a picture as overlay will make ffplay "freeze"
[18:55] <ubitux> (with ',' or ';' of course)
[18:55] <ubitux> such filtergraph doesn't make that much sense
[18:56] <ubitux> having your main input as a overlay of another one is tricky
[18:56] <ubitux> you should use the movie= trick like you did, or use ffmpeg & -filter_complex
[18:58] <ubitux> <@cehoyos> If only two filters are used, how does it make a difference if the subgraphs are independant? // if you do "foo [A], [A][B] bar" this basically: "foo [A]; [A][A][B] bar"
[18:59] <cehoyos> In that case, why does it work at all? Shouldn't it overlay A over A?
[18:59] <ubitux> my guess is that it "works" because the 2 "[A]" are recognized as the same input
[19:00] <cehoyos> I start to understand, thank you!
[19:01] <ubitux> see "2." and "4.1" in filters documentation
[19:02] <cehoyos> Concerning the freezing: That looks quite useful to me (as expected with ffplay)
[19:03] <cone-56> ffmpeg.git 03Carl Eugen Hoyos 07master:f514b5dff769: Fix libcdio-paranoia detection.
[19:17] <cone-56> ffmpeg.git 03Clément BSsch 07master:534f1a282193: lavc/avcodec: decodimg ’ decoding.
[19:24] <ubitux> aren't users allowed to set AVCodecContext->time_base for decoding
[19:24] <ubitux> ?
[19:24] <nevcairiel> thats usually set by the codec, isnt it
[19:24] <ubitux> actually, it's set by lavf
[19:25] <ubitux> mmh
[19:25] <nevcairiel> codecs with timing information in the bitstream also set it at least
[19:26] <ubitux> the mpv developers want to demux their own subtitles AVPacket and use our decoders
[19:26] <ubitux> and our subtitles decoders are using the avctx->time_base to rescale the subtitles
[19:27] <ubitux> the subtitles pts*
[19:27] <ubitux> so how are they supposed to do that, if they're not setting avctx->time_base themselves?
[19:27] <nevcairiel> why do the subtitle decoders rescale timestamps?
[19:27] <nevcairiel> because of in-band timing information?
[19:28] <ubitux> they need the ts in 1/100 tb for the decoded subtitles
[19:28] <nevcairiel> dont the demuxers usually extract that and put into AVPacket?
[19:28] <ubitux> nevcairiel: no, this is finally fixed
[19:28] <nevcairiel> "fixed"? I like having timing info in AVPacket
[19:29] <ubitux> wtf?
[19:29] <ubitux> the timing is indeed in the AVPacket, but in the appropriate fields (pts, duration)
[19:30] <nevcairiel> thats what i meant
[19:30] <ubitux> and in the stream time base (which differs)
[19:30] <ubitux> ok
[19:30] <ubitux> i thought you mean as part of the payload :)
[19:30] <nevcairiel> nah
[19:30] <ubitux> (which was the case until recently)
[19:30] <nevcairiel> but then i dont understand why the decoders need to fuzz with the timestamps
[19:30] <nevcairiel> and not do like the audio/video, and just pipe the timings through
[19:31] <ubitux> because the decoded subtitles needs the rescaled timestamps (the decoded data contains that timestamps)
[19:40] <ubitux> lol @ optimize "a bit"
[21:21] <saste> cehoyos, please mention the commit hash when you close a ticket
[21:21] <saste> this saves a lot of time later when someone stumble upon an old bug
[21:21] <Daemon404> saste, "fixed in HEAD"
[21:21] Action: Daemon404 runs
[22:38] <cone-32> ffmpeg.git 03Stefano Sabatini 07master:3a2b9911bffe: lavfi/mp/mcdeint: avoid uninited data read
[22:38] <cone-32> ffmpeg.git 03Stefano Sabatini 07master:e89182fc9452: lavfi: port mcdeint filter from libmpcodecs
[22:38] <cone-32> ffmpeg.git 03Stefano Sabatini 07master:5fa252b212d1: tests: add mcdeint tests
[22:38] <cone-32> ffmpeg.git 03Stefano Sabatini 07master:ec34963276fc: lavfi/mp: drop mcdeint wrapper
[22:43] <cehoyos> saste: Do you have commit rights for mplayer svn?
[22:46] <saste> i never remember, i don't think
[22:46] <saste> if i have, i don't know how to commit
[22:49] <cehoyos> You don't know as in "svn commit libmpcodecs/vf_mcdeint.c" ?
[22:49] <cehoyos> Do you have a patch that I could commit?
[22:50] <saste> cehoyos, I think 3a2b9911bffeffc3fc0541df3b4f6d492e122714 can be applied as is
[22:50] <saste> if not i can try to patch mplayer locally
[22:54] <cehoyos> saste: Hunk #1 FAILED at 115.
[22:56] <Compn> i think i tried to get saste to have svn commit  :P
[22:57] <saste> Compn, why? I'm not even an user
[22:57] <saste> i just use it occasionally for testing purposes
[22:58] <cehoyos> Compn: If Paul appears, please point him to ticket 2620 - thank you!
[23:18] <ubitux> saste: one less, nice :)
[23:19] <saste> ubitux: do you claim some of the remaining?
[23:19] <ubitux> yes i'm working on spp (sometimes)
[23:20] <ubitux> so it might be possible to drop fspp, spp, pp7 and uspp after it's ported
[23:22] <saste> nice
[23:22] <Compn> those are some good filters :)
[23:32] <saste> cehoyos,  http://pastie.org/7994332#11
[23:58] <cone-32> ffmpeg.git 03Marton Balint 07master:b764b53aae37: ffplay: decrease video picture queue size to 3
[23:58] <cone-32> ffmpeg.git 03Marton Balint 07master:f2175a628b79: ffplay: factorize clock functions
[23:58] <cone-32> ffmpeg.git 03Marton Balint 07master:5b492720ad90: ffplay: if playing only audio or video only, show the master clock diff in status line
[23:58] <cone-32> ffmpeg.git 03Marton Balint 07master:e341cb1102c0: ffplay: fix compute_target_delay to better handle frames with long durations
[23:58] <cone-32> ffmpeg.git 03Marton Balint 07master:35b2f30fd119: ffplay: only update pts if not redisplaying a frame
[23:58] <cone-32> ffmpeg.git 03Marton Balint 07master:97e42551e468: ffplay: use more sane frame timer resetting logic
[23:58] <cone-32> ffmpeg.git 03Marton Balint 07master:3b6f1526c69b: ffplay: use 0 frame delay if redisplaying an already displayed frame
[23:58] <cone-32> ffmpeg.git 03Marton Balint 07master:87917a328320: ffplay: do not allow wider window than 16383
[23:58] <cone-32> ffmpeg.git 03Marton Balint 07master:30d724bdfde5: ffplay: detect when the created overlay buffers are not valid for the wanted overlay height
[23:58] <cone-32> ffmpeg.git 03Michael Niedermayer 07master:c28aafe6c048: Merge remote-tracking branch 'cus/stable'
[00:00] --- Sun Jun  2 2013