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

[burek]

[00:13] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:519ebb5ee5b8: rmdec: flush audio packet on seeking
[02:18] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:8152451b56ec: buffersrc: fix w/h error
[02:18] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:29e0357a1168: aasc: fix pointer vs value error
[02:26] <cone-204> ffmpeg.git 03Carl Eugen Hoyos 07release/0.10:12e4aefb80f4: Do not (re-)set libx264 parameter b_tff if interlaced encoding was not requested.
[02:26] <cone-204> ffmpeg.git 03Carl Eugen Hoyos 07release/0.11:b63dbe222021: Do not (re-)set libx264 parameter b_tff if interlaced encoding was not requested.
[02:26] <cone-204> ffmpeg.git 03Carl Eugen Hoyos 07release/0.9:8b597077ae1b: Do not (re-)set libx264 parameter b_tff if interlaced encoding was not requested.
[02:26] <cone-204> ffmpeg.git 03Carl Eugen Hoyos 07release/1.0:f49b2a9d088e: Do not (re-)set libx264 parameter b_tff if interlaced encoding was not requested.
[02:26] <cone-204> ffmpeg.git 03Carl Eugen Hoyos 07release/1.1:6f787aa79b59: Do not (re-)set libx264 parameter b_tff if interlaced encoding was not requested.
[02:26] <cone-204> ffmpeg.git 03Carl Eugen Hoyos 07release/1.2:fc5c81ce0a44: Do not (re-)set libx264 parameter b_tff if interlaced encoding was not requested.
[02:28] <ubitux> michaelni: speaking of w/h mixup
[02:28] <ubitux>         uint8_t *end   = start + (frame->height >> hsub) *
[02:28] <ubitux>                                  frame->linesize[planes[i]];
[02:28] <ubitux> this is from vf pad
[02:28] <ubitux> isn't height supposed to be shifted by vsub?
[02:29] <ubitux> (and same thing a bit later)
[02:31] <ubitux> i wonder if vf perms wouldn't be of help here
[02:32] <michaelni> "frame->height >> hsub" looks wrong
[02:32] <ubitux> the strange thing is, this part of the code is been covered, but just like last time the '&' wasn't spotted directly
[02:33] <ubitux> michaelni: indeed and you have it again a few lines below
[02:35] <michaelni> the problem with these bugs is probably that hsub==vsub most of the time
[02:36] <ubitux> i see.. :P
[02:36] <michaelni> so they get missed ...
[02:38] <ubitux> libavcodec/avcodec.h: * @param[out] v_shift store log2_chroma_w
[02:38] <ubitux> same in pixdesc
[02:38] <ubitux> (just comments)
[02:39] <ubitux> wonder if those are correct
[02:47] <fatpony> what is the meaning of that warning? is that even a valid spelling of speed loss?
[02:47] <fatpony> [swscaler @ 0x6334d0] Warning: data is not aligned! This can lead to a speedloss
[02:56] <michaelni> fatpony, your image data isnt aligned enough 
[02:56] <wm4> fatpony: swscale is a POS and wants the data pointers aligned (instead of taking care of it properly and handle unaligned parts gracefully)
[02:58] <ubitux> wm4: it doesn't seem a requirement from what i can tell
[02:58] <wm4> fatpony: https://ffmpeg.org/trac/ffmpeg/ticket/1854
[02:58] <ubitux> just a warning for maybe some slowdown
[02:59] <wm4> I'm not sure
[02:59] <michaelni> ubitux, yes
[02:59] <wm4> michaelni: does it fall back to the C path completely?
[02:59] <ubitux> sounds like a slowdown then
[03:01] <michaelni> wm4, it should not
[03:01] <michaelni> if it does id consider that a bug
[03:02] <michaelni> and i would fix that ASAP if someone found such a case
[03:03] <wm4> then what does it do?
[03:03] <wm4> use simd on unaligned data?
[03:03] <michaelni> yes
[03:04] <iive> it should fallback to mmx
[03:09] <RT|AO> "<+nevcairiel> i wonder if i should risk gcc 4.8 :P" # I already risked for it ;) http://roy.orz.hm/lavf-w32-nightlies/lavf-my130318-63ba8b8.7z , compiled with gcc version 4.8.0 20130314 (experimental) (rev, Built by MinGW-builds project)
[03:10] <cone-204> ffmpeg.git 03Michael Niedermayer 07release/1.1:21d568be179c: shorten: set invalid channels count to 0
[03:10] <cone-204> ffmpeg.git 03Luca Barbato 07release/1.1:97cc2f286f9e: shorten: K&R formatting cosmetics
[03:10] <cone-204> ffmpeg.git 03Luca Barbato 07release/1.1:0daf1428e829: shorten: report meaningful errors
[03:10] <cone-204> ffmpeg.git 03Luca Barbato 07release/1.1:88089eecfd7e: shorten: use the unsigned type where needed
[03:10] <cone-204> ffmpeg.git 03Xi Wang 07release/1.1:0b0e87bb544b: atrac3: avoid oversized shifting in decode_bytes()
[03:10] <cone-204> ffmpeg.git 03Xi Wang 07release/1.1:9d4355d90a6a: flacdec: simplify bounds checking in flac_probe()
[03:10] <cone-204> ffmpeg.git 03Xi Wang 07release/1.1:22c27e1f4a6f: lzo: fix overflow checking in copy_backptr()
[03:10] <cone-204> ffmpeg.git 03Anton Khirnov 07release/1.1:c50241080d75: vf_hqdn3d: fix uninitialized variable use
[03:10] <cone-204> ffmpeg.git 03Michael Niedermayer 07release/1.1:bd593a98dc41: Merge commit 'c50241080d7599c90fc8b4e74c5f8d62a4caae52' into release/1.1
[03:16] <cone-204> ffmpeg.git 03Anton Khirnov 07release/1.1:a0361a6c3090: vf_gradfun: fix uninitialized variable use
[03:16] <cone-204> ffmpeg.git 03Loren Merritt 07release/1.1:1e7f825a9b21: hqdn3d: Fix out of array read in LOWPASS
[03:16] <cone-204> ffmpeg.git 03Michael Niedermayer 07release/1.1:85a685ac0af4: Merge remote-tracking branch 'qatar/release/9' into release/1.1
[03:21] <cone-204> ffmpeg.git 03Clément BSsch 07master:76d1c07c890a: lavfi/ebur128: add metadata injection.
[03:46] <cone-204> ffmpeg.git 03Michael Niedermayer 07release/1.1:731902bd1951: rmdec: flush audio packet on seeking
[03:46] <cone-204> ffmpeg.git 03ArnoB 07release/1.1:69659389a3a4: dpxenc: fix data offset
[03:46] <cone-204> ffmpeg.git 03Michael Niedermayer 07release/1.1:3d5323a351a1: dnxhddec: return the correct number of bytes from decode_frame
[03:46] <cone-204> ffmpeg.git 03Michael Niedermayer 07release/1.1:9925dca11921: MAINTAINERS: update for 1.2
[03:46] <cone-204> ffmpeg.git 03Michael Niedermayer 07release/1.1:9b0d0fd3c47e: MAINTAINERS: mention that people are welcome to pick up and maintain older releases
[04:06] <cone-204> ffmpeg.git 03Clément BSsch 07fatal: ambiguous argument 'refs/tags/n1.1.4': unknown revision or path not in the working tree.
[04:06] <cone-204> Use '--' to separate paths from revisions
[04:06] <cone-204> refs/tags/n1.1.4:HEAD: lavfi/ebur128: add metadata injection.
[04:20] <wm4> ubitux: wouldn't it be the right time to fix the ASS packet format? I suggest adding a new codec for this (name it "ass" instead of "ssa")
[04:20] <ubitux> there is already a pending patch for thing
[04:20] <ubitux> doing exactly what you propose
[04:21] <ubitux> i need to get back to it but... as you may guess, i've already thousands of things in progress
[04:21] <ubitux> :p
[04:21] <ubitux> wm4: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-January/136825.html
[04:22] <ubitux> note that it's not a trivial change
[04:22] <ubitux> it's likely to break a few things
[04:22] <wm4> depends how much stuff in ffmpeg depends on it
[04:23] <ubitux> if it was only limited to FFmpeg it would already been solved
[04:23] <ubitux> the problem is about apps, compat, etc
[04:23] <wm4> what apps use ffmpeg for ASS subtitles?
[04:24] <ubitux> it will affects any app using AVSubtitle
[04:24] <ubitux> all the mplayer forks, and likely more apps such as xmbc etc
[04:24] <ubitux> also, libav compat.
[04:25] <wm4> didn't you change something about srt that broke libav compat there
[04:25] <wm4> also, shouldn't these subtitle decoders actually output ASS packets
[04:26] <wm4> or maybe we should follow uau's suggestion and remove ass_process_data() - and troll absolutely everyone
[04:27] <ubitux> <+wm4> also, shouldn't these subtitle decoders actually output ASS packets // that's kind of the next step, and that's even less trivial
[04:27] <ubitux> removing ass_process_data() will just break everything with no alternative
[04:28] <ubitux> that can be done, but not now
[04:34] <ubitux> wm4: i'll likely wait for the gsoc to start
[04:35] <ubitux> and see if someone pick the subtitles task (i'll rework the description soon)
[04:35] <ubitux> there is a high risk the student will get crazy though
[04:35] <wm4> well ok, (though, honestly I doubt anyone has such a high interest in cleaning up and reworking weird things as gsoc task)
[04:36] <ubitux> i'll hide it as "add subtitles support to lavfi"
[04:36] <wm4> xD
[04:36] <ubitux> that should setup a good enough trap
[04:37] <wm4> I hope you won't turn the subtitle decoders into lavfi filters... that would make them harder to use
[04:37] <ubitux> huh? no no
[04:37] <wm4> it sounds like a logical thing to do, though
[04:37] <ubitux> the idea is to change the ass decoded subtitles as styledsubtitles etc
[04:37] <ubitux> and then inject them into lavfi
[04:37] <ubitux> for hardsubbing and other crazy shit
[04:38] <ubitux> but i'm talking about the fun stuff right now
[04:39] <ubitux> some really non-fun and complex stuff is left to do
[04:41] <ubitux> as you may guess the ass thing is one of the problem, but that's not all
[04:41] <ubitux> the whole chain is kinda living in the past
[04:41] <ubitux> (look at the encoding process... it looks like code from 2000)
[04:41] <ubitux> (it actually mostly is)
[04:43] <Compn> yeah it doesnt have all that bt702 color code like the users demand! :P
[04:43] <ubitux> i'm talking about subtitles only :)
[04:43] <Compn> oh :P
[04:44] <Compn> so you made it out of the iconv insane asylum ?
[04:44] <ubitux> it seems it got solved by itself
[04:44] <ubitux> Carl fixed the build problem
[04:44] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:3dc25c3ab260: avutil/frame: document alignment and padding requirements
[04:44] <ubitux> and it was concluded that libiconv use can just die in hell
[04:44] <ubitux> users*
[04:45] <ubitux> or something like that
[04:46] <ubitux> michaelni: you didn't fix the "preferrance" typo (unless i was wrong)
[04:46] <ubitux> last sentence is a bit weird btw, but well.
[04:46] <Compn> does patcheck have a spell check too ?
[04:47] <Compn> :)
[04:47] <Compn> which only scans the /* comments */ of course
[04:47] <Compn> or av_logs
[04:47] <ubitux> it greps common typo iirc
[04:48] <cone-204> ffmpeg.git 03Michael Niedermayer 07master:fbd3ee91a59f: avutil/frame: typo
[04:48] <ubitux> thx
[04:49] <michaelni> about the last sentance feel free to reword anyway you feel is better
[04:49] Action: michaelni too tired :)
[06:35] <ubitux> so we have 6 mentored tasks
[06:35] <ubitux> that's not much
[07:29] <ubitux> maybe we should propose some assembly tasks into libavfilter
[07:29] <ubitux> would be nice to see some optimz for some filters
[09:22] <kierank> could optimise that new deinterlacer
[10:19] <durandal_1707> next release number is going to be 2.0 ?
[10:37] <nevcairiel> new deinterlacer?
[10:40] <durandal_1707> no, because of major bump
[10:40] <Tjoppen> spring cleaning?
[10:50] <Compn> durandal_1707 , nevcairiel is asking about [04:28] <kierank> could optimise that new deinterlacer
[10:56] <durandal_1707> what deinterlacer?
[10:57] <nevcairiel> whats what i asked. :P
[11:03] <kierank> nevcairiel: http://mdsh.com/wiki/jsp/Wiki;jsessionid=81D21AB0DF85786F558A5E4E6C642EC8?action=action_history&type=version&versionNumber=20&topic=FFmbc+0.7
[11:03] <kierank> the one in ffmbc
[11:04] <nevcairiel> too bad its gpl again
[11:06] <nevcairiel> which brings me back to the whole sillyness of the clause in the lgpl which allows converting to gpl, resulting in te original lgpl project not being able to backport changes
[11:06] <nevcairiel> whoever thought that up was just insane
[11:07] <Compn> or you could just use gpl and not care about people who use ffmpeg in a product 
[11:08] <Compn> a product that relies on lgpl rules 
[11:09] <Compn> i thought people wanted that deint from avisynth anyways
[11:19] <kierank> does drawtext only draw text on top of video?
[11:20] <kierank> could drawtext be used to convert srt to dvbsub?
[11:27] <wm4> kierank: I'd suggest repurposing vf_sub for this instead
[11:27] <wm4> vf_drawtext looks like it'd really suck at text rendering
[11:27] <wm4> at least for anything that isn't ascii or latin1
[11:28] <kierank> hmmm libass dependency
[11:28] <wm4> so what
[11:29] <kierank> another lib i have to keep track of
[11:29] <nevcairiel> yeah it uses libass for all font rastering
[11:40] <kierank> wm4: why do you think vf_drawtext will be bad for non-ascii/latin1
[11:41] <wm4> kierank: because text layout is hard, and vf_drawtext is the most naive thing possible
[11:43] <wm4> think stuff like right-to-left text or arabic and indic
[11:43] <av500> http://www.pango.org/
[11:43] <kierank> oh yeah i don't care about that
[11:43] <wm4> av500: yes using pango is one way to let this handle for you
[11:43] <wm4> libass uses harfbuzz (though that's an optional dependency), and pango uses harfbuzz for text layout too
[11:44] <av500> yeah, I used harfbuzz for arabic at work
[11:44] <wm4> which btw. is interesting too: pango is a text layout library, but text layout is so complex, they moved actual text layout into a separate lib (harfbuzz)
[11:44] <av500> hmm
[11:45] <av500> wasnt harfbuzz more about glpyh shaping
[11:45] <kierank> can pango do backgrounds?
[11:45] <av500> ?
[11:45] <kierank> having text on a coloured or transparent background
[11:45] <kierank> there are lots of random rules for blind people
[11:46] <wm4> av500: well yes, I guess that's true
[11:47] <av500> seems it evolved a lot since I used it
[11:47] <av500> I only used it to do the glyph replacing
[11:48] <av500> for the bidi stuff I used the code from unicode
[11:49] <wm4> libass uses it to layout text runs (or something like this)
[15:46] <cone-274> ffmpeg.git 03Clément BSsch 07master:c10b57973dff: lavfi/pad: fix horizontal/vertical shift confusion.
[15:46] <cone-274> ffmpeg.git 03Clément BSsch 07master:6abb554fd698: lavc,lavu: fix two doxy mixup between h/v chroma shift.
[15:47] <JEEB> hmm, it seems like the MSVC compat. layer doesn't convert -L into -LIBPATH
[15:47] <JEEB> oh well
[15:47] <JEEB> (although I guess converting stuff put into extra-ldflags is hard)
[16:03] <Daemon404> JEEB, why don't you just put it in %LIB% like the rest of the MSVC world
[16:05] <JEEB> fffuuuu %LIB%
[16:21] Action: nevcairiel does that in his msvc environment script
[16:44] <ubitux> michaelni: careful when merging the latest stuff from libav when it get pushed
[16:44] <ubitux> anton is changing the options support in lavfi
[16:45] <ubitux> and since he doesn't want to pick the shorthand thing, he goes for the AVOption order
[16:45] <ubitux> that can not work for us since we support options aliases for instances (or we would need to reorder them)
[16:46] <ubitux> might be worth contacting nicolas & saste as well, since nicolas was working on exporting properly the shorthands
[17:14] <Compn> honest question: does libav have a roadmap or something for when they stop changing, renaming and reinventing the api?
[17:14] <BBB-work> jeeB: configure converts that itself, IIRC
[17:14] <BBB-work> jeeb: so the compat layer isn't to blame here
[17:15] <av500> Compn: yes
[17:15] <av500> but its s3cr3t
[17:18] <Compn> maybe is good idea to freeze mplayers' ffmpeg version
[17:18] <iive> isn't it obvious? it would be changed until it have nothing in common with ffmpeg.
[17:21] <Compn> yes thats probably the overall goal
[17:21] <Compn> i guess the thing is to split up all of the files so the copyrights can be changed
[17:22] <Compn> even though thats not how copyrights work at all
[17:22] <Compn> hehe
[17:27] <BBB-work> asking libav questions in #ffmpeg is about as useful as republicans asking, at the republican convention, why democrats are so uncooperative towards their great goals (or vice versa)
[17:28] <BBB-work> I bet you someone is currently asking the same type of question about ffmpeg in #libav
[17:28] <BBB-work> Compn, ^^
[17:29] <ubitux> it's a strategy to spot spies
[17:29] <BBB-work> oo interesting
[17:29] <BBB-work> you mean like the commie-hunt in the 60s?
[17:30] <ubitux> please don't expose our plans
[17:30] <ubitux> they might be listenning
[17:32] <Compn> BBB-work : i could ask , should that be in #libav or #libav-devel ?
[17:32] <iive> BBB-work: would you expect republicans or democrats to give you a honest answer if you ask them directly?
[17:32] <av500> #libav-politics
[17:33] <Compn> both channels still have +s set? heh
[17:33] <Compn> er no nm
[17:33] <Compn> doing /whois on elenril doesnt show hes in either tho
[17:34] <ubitux> on freenode you need to be on the channel
[17:34] <ubitux> otherwise it doesn't show up in the whois
[17:34] <Compn> ah, thats annoying
[17:34] <nevcairiel> thats the personal "invisible" mode
[17:35] <Compn> BBB-work : anyways , i think i already know the answer when asking about mplayer. since mplayer uses all private functions not public ones, they are subject to change at whim
[17:35] <cone-274> ffmpeg.git 03Luca Barbato 07master:d1bec33b4609: asfenc: return error on negative timestamp
[17:35] <cone-274> ffmpeg.git 03Kostya Shishkov 07master:50c449ac24fb: iff: validate CMAP palette size
[17:35] <cone-274> ffmpeg.git 03Michael Niedermayer 07master:523c8e0503dc: Merge commit '50c449ac24fbb4c03c15d2e2026cef2204b80385'
[17:38] <Compn> maybe i'm just being a big pain 
[17:38] <Compn> let stefano ask elenril himsef :)
[17:49] <cone-274> ffmpeg.git 03Anton Khirnov 07master:ce0124acacd9: mpeg12: do not fail on zero dimensions in the sequence header.
[17:49] <cone-274> ffmpeg.git 03Anton Khirnov 07master:358628074c31: print_options: do not generate docs for options without enc or dec flags
[17:49] <cone-274> ffmpeg.git 03Michael Niedermayer 07master:330e44070666: Merge remote-tracking branch 'qatar/master'
[18:01] <cone-274> ffmpeg.git 03Michael Niedermayer 07master:0163ad66e124: mpeg2: 12LSB w/h of 0 is not allowed in compliant videos thus this also needs AV_EF_COMPLIANT
[18:01] <cone-274> ffmpeg.git 03Michael Niedermayer 07master:73ef12757b94: append_packet_chunked: remove outcommented code
[19:41] <cone-274> ffmpeg.git 03Michael Niedermayer 07master:cea3a63ba3d8: avutil/buffer: Fix race in pool.
[19:41] <cone-274> ffmpeg.git 03Elvis Presley 07master:58bc65952bc7: libavcodec/proresdec.h: fix license header
[19:43] <Daemon404> you cant stop the king
[20:48] <BBB-work> j-b, ping
[20:54] <cone-274> ffmpeg.git 03dronus 07master:fdca977a22d3: libavdevice sdl: added window_fullscreen option to switch SDL output into fullscreen mode
[20:55] <JEEB> ok, gotta love the difference of extra-cflags and extra-host-cflags
[20:55] <JEEB> http://up-cat.net/p/bb62b82e
[20:56] Action: JEEB goes and starts modifying the env variables
[20:56] <ubitux> saste: for you question from yesterday; yes i'm still on it, trying to understand the filter, so it takes a while, it's not trivial
[20:56] <JEEB> simpler than trying to make this work with --extra-*flags
[20:56] <nevcairiel> JEEB: you could've saved 5 hours just doing it in the first place :D
[20:57] <JEEB> yes, yes I know
[20:57] <JEEB> I started around 1400 and now it's 2157
[20:57] <JEEB> I'm just way too used to the fact that --extra-*cflags will work
[20:57] <JEEB> yet in this case although host and target are the same, they are not the same for the build system
[20:57] <JEEB> YAY
[20:58] <Daemon404> also you refused to use the LIB and INCLUDE env vars
[20:58] <Daemon404> as tated hours ago
[20:58] <Daemon404> <.<
[20:58] <JEEB> yes, because yunno this way seemed like the proper way to do it so far in all of my damn use cases
[20:58] <nevcairiel> hehe
[20:58] <Daemon404> extra-cflags is more proper than seetting up your env correctly
[20:58] <JEEB> instead of hitting it all with a big bat called env variables
[20:58] <Daemon404> i dont think so.
[20:58] <JEEB> yes, yes it is
[20:58] <JEEB> unless you want EVERYTHING to use the same env variables
[20:58] <JEEB> and I don't want
[20:59] <saste> ubitux, seems like nicolas will co-mentor the subtitles task :-)
[20:59] <JEEB> but in any case, I give up with this
[20:59] <JEEB> and just use the damn env variables
[20:59] <Daemon404> you mean like MS tells you to?
[20:59] <Daemon404> :)
[20:59] <JEEB> "Alternatively, you can try and use the --extra-cflags/--extra-ldflags configure options. "
[20:59] <ubitux> saste: nice
[20:59] <nevcairiel> noone said those tries would succeed
[20:59] <Daemon404> note "try"
[21:00] <JEEB> yes, yes I know
[21:00] <JEEB> damn it
[21:00] <ubitux> saste: i've updated the page a little tonight
[21:00] <JEEB> stop making me feel even dumber than I already do
[21:00] <ubitux> saste: i think the page is lacking some introduction for students
[21:00] <JEEB> I just want to push out some smoke
[21:00] <saste> ubitux, i see
[21:00] <nevcairiel> but its so much fun!
[21:00] <Daemon404> thats part of the internet experience!
[21:00] <saste> ubitux, i'll work on it, this week
[21:00] Action: Daemon404 stabs mpegts.c
[21:00] <ubitux> saste: btw, did you see the options patchset from anton... :)
[21:00] <nevcairiel> its even funnier because i already told you what to look at to fix the bug you were chasing
[21:00] <saste> i plan to send the application during this week
[21:01] <saste> ubitux, yes more refantoning, it never ends
[21:01] <ubitux> :(
[21:01] <Daemon404> nevcairiel, im poking the same thing
[21:01] <nevcairiel> haha, i like your word creation
[21:01] <Daemon404> too abd i have no idea what half this code does
[21:01] <Daemon404> since it's just :magicnumbers:
[21:01] <nevcairiel> what, the .ts file that eats all your memory?
[21:01] <Daemon404> yes
[21:01] <Daemon404> i found the loop its exploding on
[21:02] <nevcairiel> what i found is that it has a packet of stream 2 that it can't probe, and doesn't have enough packets in that stream to cancel probing, so it keeps reading
[21:03] <nevcairiel> its not even technically a mpegts specific thing
[21:03] <nevcairiel> except that mpegts just doesnt have global headers to identify streams in all cases
[21:04] <Daemon404> nevcairiel, its looping inside mpegts for me
[21:04] <Daemon404> not in the generic code
[21:04] <Daemon404> i dont see what youre seeing maybe
[21:04] <nevcairiel> mine was looping in ff_read_packet
[21:05] <nevcairiel> reading more and more into its packet list because it was still trying to probe
[21:05] <Daemon404> yes, but the actual infintie loop is in mpegts.c
[21:05] <nevcairiel> not here
[21:05] <Daemon404> q
[21:05] <Daemon404> fun
[21:06] <nevcairiel> it happily reads packets from mpegts, but puts them into its packet list in ff_read_packet, which grows over all bounds
[21:08] <Daemon404> hmm ineed i see it there
[21:09] <nevcairiel> easy fix would be to limit probing to some amount of X
[21:12] <wm4> ubitux: how is anton's new option system for lavfi?
[21:12] <wm4> ubitux: NIH and retarded, or actually good?
[21:13] <ubitux> both
[21:13] <Daemon404> >option system
[21:14] <Daemon404> overengineering much?
[21:14] <wm4> ah the best kind of change
[21:14] <ubitux> wm4: the dict thing is good
[21:14] <ubitux> but he made sure to break our shorthand thing
[21:14] <ubitux> so we can't keep command line compat 
[21:14] <Daemon404> all 3 users will eb heartbroken
[21:15] <wm4> I just wrote a vf_lavfi last week
[21:15] <wm4> now it'll be using deprecated shit
[21:15] <wm4> hurrr
[21:16] <ubitux> :)
[21:16] <wm4> #if FF_API_OLD_FILTER_OPTS everywhere
[21:43] <Compn> hey, the king is back :)
[21:43] <Compn> is he scared of ifruit?
[21:46] <ubitux> seems the fork decided to rewrite -avoid_negative_ts differently
[21:47] <iive> libnih
[21:49] <Daemon404> docs for -avoid_negative_ts are still misleadign and/o wrong
[21:49] <Daemon404> btw
[21:49] <Daemon404> and not in the man page at all
[21:49] <Daemon404> just sayin.
[21:49] <ubitux> yes, better re-write it differently then
[21:49] <ubitux> and it's in the man page
[21:49] <ubitux> @item avoid_negative_ts @var{integer} (@emph{output})
[21:49] <ubitux> Shift timestamps to make them positive. 1 enables, 0 disables, default
[21:49] <ubitux> of -1 enables when required by target format.
[21:49] <Daemon404> its not on http://ffmpeg.org/ffmpeg.html
[21:50] <ubitux> ffmpeg-formats
[21:50] <Compn> lol
[21:50] <ubitux> it's not a ffmpeg option
[21:50] <ubitux> it's a format specific option
[21:50] <Compn> Daemon404 : dont get them started re docs @ ffmpeg.org 
[21:50] <Compn> ubitux : any chance we can have one big document with all of the docs and options together ?
[21:50] <Compn> so we dont have to look at 14 different option pages ?
[21:50] <Daemon404> ubitux, i wouldnt have even known to check that
[21:51] <Daemon404> all i see is "see also <giant list of docs>"
[21:51] <Daemon404> not exacly useful.
[21:51] <ubitux> that's a format thing, you look at the format manpage
[21:51] <ubitux> Compn: idk, send a patch?
[21:51] <Compn> Daemon404 : like talking to a brick wall 
[21:51] <Compn> urrg
[21:51] <Daemon404> and i would know its a forma thing ... how?
[21:51] <Daemon404> MAGIC
[21:51] <Daemon404> a user would not.
[21:51] Action: Compn rather file bug report
[21:52] <ubitux> because timestamps are at format level?...
[21:52] <Daemon404> i should als note
[21:52] <Daemon404> EVERY oter man page
[21:52] <Daemon404> has
[21:52] <Daemon404> man <command>
[21:52] <Daemon404> which documents which args it can take
[21:52] <wm4> I wish ffmpeg had support for generating linear timestamps starting from 0
[21:53] <Compn> isnt that what -vf genpts is for ?
[21:53] <wm4> or at least a seek API that actually works with files with TS resets
[21:53] <Compn> or -vf setpts i mean
[21:53] <ubitux> Daemon404: ffmpeg [global_options] {[input_file_options] -i input_file} ... {[output_file_options] output_file} ...
[21:53] <ubitux> like this?
[21:53] <ubitux> (man ffmpeg)
[21:53] <michaelni> saste, someone is complaining about the manpage and missing options ...
[21:53] <Daemon404> michaelni, not missing
[21:53] <Daemon404> just poorly placed
[21:53] <wm4> Compn: lavfi doesn't support seeking
[21:53] <Daemon404> nobody is going t go "obviously it's a format option, and it's in man ffmpeg-format!"
[21:53] <Daemon404> if you think they will
[21:53] <saste> Daemon404, please file a ticket
[21:53] <Daemon404> yorue deluded.
[21:54] <Compn> wm4 : seek first > new file > then filter pts
[21:54] <Compn> until seek is implemented....
[21:54] <saste> in theory it would be possible to include all files in the same document
[21:54] <wm4> Compn: yeah, a great way to implement a media player
[21:54] <saste> but i have limited time
[21:54] Action: ubitux too
[21:55] <Compn> ok i put it in trac, maybe someone will look at it :)
[21:55] <Compn> wm4 : its new! brand new! its beta...
[21:55] <Daemon404> wm4, lavfi "isnt mature enough" yet!
[21:55] <Daemon404> seeking in 9 years maybe
[21:56] <Daemon404> its not liek seeking in lavfi would be useful
[21:56] <saste> Daemon404, and the alternative is, huge wall of text, no silver bullet, as everyone seems to believe
[21:56] <Daemon404> since lavf/lavf cant seek accurately
[21:56] <wm4> seeking just popped up because Compn suggested using -vf setpts for getting linear PTS
[21:56] <wm4> or whatever that filter is named
[21:56] <Daemon404> saste, even a note like "stuff related to timestamps can be found in ffmpeg-format(1)"
[21:56] <Daemon404> instead of "see <giant list of docs>"
[21:57] <Compn> Daemon404 : man ffmpeg-bigwalloftext then /timestmap
[21:57] <Compn> as soon as we get that settled.
[21:57] <Daemon404> wm4, i generally pass through the timestamps and handle it manually
[21:57] <Daemon404> all of ffmpeg's pts stuff is terrible
[21:57] <Compn> wm4 : whats wrong with your timestamps anyways that you need linear ?
[21:57] <Compn> what is the next tool in your chain that barfs on them ?
[21:58] <michaelni> Daemon404, unless you work on lavfi, you should not make predictions about when it will support something
[21:58] <saste> Daemon404, i wish people would spend less time complaining and more writing patches
[21:58] <wm4> Compn: libavformats seeking API becomes useless of PTS ranges overlap
[21:58] <Daemon404> michaelni, i was poking fun at the fact that people always say "its nto mature yet"
[21:58] <saste> but i'm deluded i know
[21:58] <Daemon404> when younger projects have already surpassed it
[21:58] <wm4> or actually just resets makes the seeking API useless, I think
[21:59] <Daemon404> fun with timestaps: ffprobe even outputs impossible things like dts==pts on streams with reodered frames (like mpeg2)
[21:59] <Daemon404> because thats totally not insane.
[21:59] <wm4> on the other hand, I'm not sure how this could even be handled without indexing the file first
[21:59] <Compn> sounds like needs reindexing if you have broken timestamps ?
[21:59] <Compn> are they broken or ?
[21:59] <Daemon404> wm4, you cant
[21:59] <ubitux> Daemon404: we can't keep track of all your complains on irc unless you report them just once in the trac
[21:59] <Compn> what is your sample really ?
[21:59] <Compn> lol
[22:00] <Daemon404> ubitux, mostly i cant be arsed to find my login
[22:00] <Daemon404> me loathes bug trackers with logins
[22:00] <wm4> Compn: chained ogg, .ts files, etc. are all things you can find in the wild that can have TS resets
[22:00] <ubitux> use pwgen and create a new account
[22:00] <Daemon404> for every bug?
[22:00] <Compn> there, ticket made.
[22:00] <ubitux> pwgen or keyboard hiting like wm4 
[22:01] <michaelni> Daemon404, theres a "remember me" checkbox on the login page, maybe that helps
[22:01] <ubitux> Daemon404: how many developers you need to help you organize yourself?
[22:01] <Daemon404> that only works until i clear my cookies
[22:01] <Daemon404> ubitux, what?
[22:01] <Compn> i got it
[22:02] <michaelni> use your name as password ? or do you forget that too?
[22:02] <ubitux> Daemon404: i mean, are we supposed to remember your account and password?
[22:02] <Compn> we just need a !bug irc bot
[22:02] <wm4> yeah, I don't think your inability to manage logins is a valid reason for not using a bug tracker
[22:02] <Compn> !bug Daemon404 is lazy and ffmpeg -xxx is broken
[22:02] <Compn> :)
[22:02] <Compn> irc bug tracker bot
[22:02] <Daemon404> wm4, my /care is
[22:02] <ubitux> and Carl is going to close it asap
[22:02] <Compn> haha
[22:02] <Compn> hes our fastest bug tester
[22:02] <wm4> dealing with cehoyos is a bit of work
[22:02] <ubitux> Daemon404: we seem to care enough to complain every day about lavfi/ffprobe/doc/whatever :p
[22:03] <Daemon404> i always thought carl was just a robot that said "please provided full uncut output"
[22:03] <Daemon404> even where it makes 0 sense
[22:03] <Daemon404> and then wroet codec specific hacks
[22:03] <Compn> for someone who dislikes trolls, you sure are trolling now
[22:04] <Daemon404> who said i dislike trolls?
[22:04] <iive> Compn: getting rid of rivals :P
[22:04] <Compn> hehe
[22:04] <Daemon404> anyway
[22:04] <Daemon404> i can file bugs right now for ffprobe, doc etc
[22:04] <Daemon404> no need to file lavfi
[22:04] <Daemon404> since it would just be "should not exist"
[22:05] <ubitux> yeah yeah we know the story
[22:05] <ubitux> but then just don't use it and let ppl who care have fun with it :p
[22:05] <Compn> theres a few people who troll because they like to develop competiting projects :)
[22:05] <ubitux> Daemon404 will tell you lavfi is not even competiting against vsynth etc
[22:06] <Daemon404> 1) i dont work on vsynth
[22:06] <wm4> I still don't understand why you'd rather port unwieldy big chunks of code instead of writing a vsynth bridge
[22:06] <Daemon404> wm4, NIH
[22:06] <ubitux> it's not "instead"
[22:06] <Daemon404> porting it all to lavfi is pretty retarded imho anyway
[22:07] <Daemon404> cause oyu have to constantly monitor upstream for fixes
[22:07] <Daemon404> and vice versa
[22:07] <Daemon404> you split the code into N codbases
[22:07] <Compn> mplayer panning to drop mpcodecs and switch to lavfi...
[22:07] <Compn> planning*
[22:07] <wm4> Compn: do they?
[22:07] <Compn> hey no one has a plan so i can make it up :D
[22:08] <Compn> theres only reimar left
[22:08] <wm4> last I checked their vf_lavfi has been broken through at least 2 API changes
[22:08] <Daemon404> Compn, liar
[22:08] <Daemon404> i see random chinese guys on mplayer-devel
[22:08] <cone-274> ffmpeg.git 03Clément BSsch 07master:4b35be3251d9: lavc: fix avpacket memleak with subtitles recoding.
[22:08] <ubitux> saste: any objection on the ebur128 metadata test?
[22:09] <saste> ubitux, i've not been following the thread
[22:09] <saste> i'll read it now
[22:09] <ubitux> just look at patch 3
[22:09] <ubitux> patch 1 is dropped, patch 2 is applied
[22:09] <Compn> wm4 : yes mplayer vf lavfi is broken, and since libav is doing changes i think will stay broken for a while
[22:10] <ubitux> Daemon404: wasn't ivtc and eedi3 ported from avisynth to vsynth?
[22:10] <ubitux> what was the motivation here since it is supposed to support avisynth plugins?
[22:11] <wm4> linuks support maybe?
[22:11] <wm4> avisynth isn't portable, vsynth is
[22:11] <wm4> so it makes lots of sense porting avisynth filters to vsynth
[22:11] <wm4> but lavfi?
[22:11] <ubitux> and i guess there is no "avisynth upstreams" for plugins?
[22:12] <Daemon404> ubitux, upstream is dead actually
[22:12] <ubitux> tritical stopped posting .zip on a forum?
[22:12] <wm4> from what I can see, most avisynth plugins are managed with the doom9 forum source code management system
[22:12] <Daemon404> wm4, the best VCS
[22:12] <Daemon404> forum zips
[22:12] <wm4> derp
[22:12] <ubitux> :)
[22:12] <Compn> does doom9 still have that terrible registration process ?
[22:12] <wm4> in any case, this proves the enormous stability of the avisynth interface
[22:12] <Compn> like you register and then wait 5 months 
[22:12] <wm4> something lavfi can't even dream of
[22:13] <ubitux> :D
[22:13] <Daemon404> wm4, if only avs didnt use the C++ abi ;)
[22:13] <Daemon404> and tie it to a specific compiler
[22:14] <Compn> does gstreamer have filters ?
[22:15] <Compn> is vsynth supposed to tie into gstreamer or what ?
[22:15] <wm4> gstreamer does have filters, but gstreamer is horrible
[22:21] <ubitux> it seems someone wants e70730045a22d053a64473df20886edfa4775e59 to be backported to 0.10
[22:22] <wm4> uh isn't that ancient
[22:22] <ubitux> 0.10 is ancient
[22:22] <ubitux> but it seems to be used on gentoo
[22:22] <ubitux> and a bugreport was opened
[22:22] <ubitux> (https://bugs.gentoo.org/show_bug.cgi?id=461028)
[22:23] <Daemon404> y u no work trac bot
[22:23] <Daemon404> i wanted to go ^
[22:24] <Daemon404> ^
[22:24] <ubitux> thx
[22:25] Action: ubitux downloads teh sample just because of the filename
[22:26] <Daemon404> FUCKING CARL
[22:26] <ubitux> ?
[22:26] <Daemon404> He asks te dumbest questions
[22:26] <Daemon404> the bug is abotu ffprobe
[22:26] <Daemon404> not ffmpeg
[22:27] <JEEB> ^^;
[22:27] <Daemon404> and if it was ffmpeg, i could use -copyts
[22:27] <Daemon404> (i think)
[22:28] <ubitux> cool telecined material
[22:31] <saste> ubitux, why there is no metadata in the last frame?
[22:32] <Daemon404> ubitux, it i standard broadcast mpeg2 from japan
[22:32] <Daemon404> most streams are like that
[22:33] <ubitux> saste: flushing maybe; i admit i didn't look closely
[22:33] <Daemon404> boy.. trac is slow
[22:33] <ubitux> Daemon404: 'got easy way to grab a stream somewhere so i can have fun too?
[22:33] <Daemon404> "grab a stream somewhere" ?
[22:34] <Daemon404> ubitux, not sure i understand what you mean
[22:34] <JEEB> the link is in the ticket
[22:34] <ubitux> Daemon404: i'm asking if there are some public broadcasting available outside japan
[22:34] <JEEB> oh
[22:35] <Daemon404> that specific stream is from JEEB
[22:35] <Daemon404> the lirary of JEEB
[22:35] <Daemon404> library*
[22:35] <JEEB> ubitux, as far as I know there are no other Japanese TV companies officially airing abroad than NHK World
[22:35] <JEEB> you can IIRC grab their satellite TV if you live in Taiwan
[22:35] <JEEB> I just put a box there
[22:35] <JEEB> as in Japan
[22:36] <JEEB> so I can get terrestial
[22:36] <Daemon404> >libswscale has unreasonable alignment constraints
[22:36] <Daemon404> lol
[22:36] <Daemon404> what constraints?
[22:36] <Daemon404> it works unaligned fine
[22:36] <Daemon404> just slow
[22:36] <ubitux> JEEB: ok, too bad :)
[22:37] <JEEB> if I had better hardware I'd probably try streaming
[22:37] <JEEB> I did some low-res testing with my AMD64
[22:37] <JEEB> and that worked OK
[22:38] <JEEB> but for 720p streams like what was around for madoka
[22:38] <JEEB> that'd need some more power :)
[22:42] <Daemon404> maybe ill just bite the bullet
[22:42] <Daemon404> an go through every since doc for ffmpeg
[22:42] <wm4> this doesn't exit after 3 seconds: ffplay -autoexit -t 3 -f lavfi 'mandelbrot,crop=201'
[22:42] <Daemon404> and its options
[22:42] <Daemon404> i must buy beer first
[22:42] <Daemon404> s/since/single/
[22:42] <ubitux> wm4: -t is supposed to work with ffplay?
[22:42] <wm4> why not
[22:42] <ubitux> oh indeed, it's in
[22:42] <wm4> it's in the fraking manpage
[22:43] <wm4> it just stops updating after 3 seconds
[22:43] <ubitux> it doesn't need the crop btw
[22:44] <wm4> oh, true
[22:44] <ubitux> maybe the lavfi device doesn't send a EOF or something
[22:45] <ubitux> -autoexit + -t indeed works with a file
[22:46] <saste> ubitux, ffplay-level bug
[22:46] <saste> not mandelbrot specific
[22:47] <ubitux> testsrc=d=5 ends it properly
[22:47] <saste> yes because in that case the device sends an EOF
[22:47] <saste> which doesn't happen with -t
[22:47] <wm4> anyway, since these all return unaligned data, they're useless
[22:56] <j-b> BBB-work: pong
[22:58] <saste> Daemon404, actually, carl is right
[22:58] <saste> the same issue is reproducible with ffmpeg -i INPUT -debut_ts -f null -
[22:58] <saste> so it's not ffprobe specific
[22:59] <saste> otoh i really don't know how the DTS are supposed to be
[22:59] <saste> but looks more like a libavformat issue
[23:00] <BBB-work> j-b, any news on dates for vdd?
[23:01] <xlinkz0> is ffmpeg.c considered to be fairly leak-free and well designed or does it rely on the fact that once the job is finished the OS will clean up after it?
[23:01] <saste> xlinkz0, mostly clean-free, since we rely on valgrind tests
[23:02] <saste> *leak-free
[23:02] <ubitux> speaking of valgrind they're kinda in the yellow on fate now
[23:03] <xlinkz0> saste: i plan to encapsulate most of it and instead of running the executable call the main function in different threads, there shouldn't be a problem with this right?
[23:03] <xlinkz0>  , between exe and call
[23:04] <xlinkz0> this means that, that code will be run endlessly inside a single process..
[23:05] <Daemon404> saste, DTS shoud be monotonically increasing in coded order
[23:05] <Daemon404> it's the decode timestamp
[23:06] <Daemon404> only pts should be monotonically increasing i presentation order
[23:06] <Daemon404> in*
[23:06] <Daemon404> but ffprobe says both are monotonically increasing in presentation order
[23:06] <Daemon404> which makes 0 sense, since coded order is different.
[23:07] <iive> Daemon404: are there any b-frames?
[23:08] <Daemon404> yes.
[23:08] <Daemon404> coded order != presentation order
[23:08] <Daemon404> for this stream
[23:08] <Daemon404> and thus teh DTS CANNOT be monotonically increasing in presentation order
[23:09] <saste> ffprobe -show_entries frame=pkt_pts,pkt_dts,pict_type  kyoani_cm_mechagirl.ts -of compact -select_streams v | less
[23:09] <saste> iive: yes
[23:11] <cone-274> ffmpeg.git 03Michael Niedermayer 07master:aafbfb1c2ea2: doc: try to improve avoid_negative_ts documentation
[23:14] <Daemon404> "AV sync, subtitle sync and relative timestamp
[23:14] <Daemon404> +differences are preserved compared to how they would have been without
[23:14] <Daemon404> +shifting."
[23:14] <Daemon404> what does that even mean
[23:15] <Daemon404> that doesnt answer most of teh question i posed
[23:15] <michaelni> Daemon404, where did the commit say it awnser them?
[23:15] <michaelni> give me a moment please :)
[23:16] <Daemon404> o ok
[23:21] <cone-274> ffmpeg.git 03Michael Niedermayer 07master:9c22039c158c: doc: Document the order in which avoid_negative_ts is applied compared to other timestamp options
[23:22] <Daemon404> ok so it is last
[23:31] <saste> uhm mixing formats and ffmpeg docs
[23:33] <Daemon404> you have a better way?
[23:33] <Daemon404> it's important to know which order they ar applied
[23:33] <Daemon404> and no it isnt obvious.
[23:44] <saste> Daemon404, what i suggest?
[23:44] <saste> probably a dedicated section about timestamp handling in ffmpeg would do it
[23:47] <Daemon404> saste, that could work, but it would still have to talk about options from both documents
[23:48] <saste> Daemon404, currently, i admit that the documentation fails at documenting how the options are applied to the various contexts
[23:48] <saste> which is very non trivial
[23:48] <saste> (i bet most devs indeed don't know how this work)
[23:48] <saste> and i'm lost in the code every time i need to look at it
[23:49] <saste> but it is ok to speak about formats options from ffmpeg.texi
[23:50] <saste> not very ok to speak about ffmpeg option in formats, since that options are used in other contexts, and mentioning ffmpeg specific options is just misleading/confusing
[23:50] <saste> also that calls for desynching, every time ffmpeg opts are changed
[23:50] <saste> which happens too often these times
[23:51] <Daemon404> i see
[23:51] <Daemon404> k
[00:00] --- Tue Mar 19 2013