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

[burek]

[00:30] <cone-965> ffmpeg.git 03Michael Niedermayer 07ae52eb7fc742: lavu: add av_clip64()
[00:31] <cone-965> ffmpeg.git 03Michael Niedermayer 0790d4b07063b3: mathemathics: update copyright years
[00:31] <cone-965> ffmpeg.git 03Michael Niedermayer 0703e44bcb3ff1: ffmpeg: trivial simplification
[00:31] <cone-965> ffmpeg.git 03Michael Niedermayer 078766ad9eb1b0: lavu: add av_rescale_delta()
[00:31] <cone-965> ffmpeg.git 03Michael Niedermayer 07a9d97e1b0af6: ffmpeg: use av_rescale_delta() on the audio filter input
[01:01] <llogan> j-b: how does videolan manage donations via paypal?
[01:26] <stclaws> Hi, I heard that ffmpeg now includes it's own rtmp implementation that does not use librtmp. Could anyone tell me where in ffmpeg the source is for that implementation?
[01:27] <Compn> you cant find the rtmp.c file ?
[01:27] <Compn> ffmpeg/libavformat/rtmp.c
[01:27] <Compn> er rtmp*
[01:27] <Compn> not rtmp.c
[01:28] <Compn> theres a bunch of rtmp files there
[01:28] <Compn> llogan : i'm guessing vlc has its own non-profit , i think
[01:29] <Compn> stclaws : what are you planning to do with ffmpeg rtmp code? :)
[01:29] <Compn> drop rtmpdump/librtmp and use ffmpeg for xbmc or something ?
[01:31] <stclaws> Compn: Well, we are receiving a live rtmp stream from a fms server that we want to re-encode. The problem is that the incoming stream sometimes switches sources (we scripted the fms server like that to make a kind of "video mixer"), at which point ffmpeg thinks the stream has ended and closes it. So I have to figure out a way to keep it going no matter what. 
[01:32] <Compn> ah
[01:32] <Compn> stclaws : well, if you can make your rtmp stream public, you might want to ask kostya about it, since he maintains that code
[01:32] <Compn> libav maintains it mostly as well (fork of ffmpeg)
[01:32] <stclaws> Sure
[01:33] <Compn> you can find there #libav-devel or kshishkov is kosya , if you want to pm him
[01:33] <stclaws> Great. Thanks. 
[01:33] <Compn> but feel free to stick around here if you want 
[01:34] <cone-965> ffmpeg.git 03Michael Niedermayer 07fe573d1a9b74: sws_allocVec: check length validity
[01:34] <cone-965> ffmpeg.git 03Michael Niedermayer 07e823e7367754: sws_getGaussianVec: check variance and quality
[01:34] <Compn> stclaws : does librtmp / rtmpdump handle your stream? 
[01:35] <Compn> if not, you may want to pass the rtmp url to hyc , who is author of that lib
[01:35] <Compn> or pass it to rtmpdump mailing list
[01:35] <Compn> when in doubt, make bugreport :)
[01:36] <stclaws> Well, I tried with rtmpdump also, but then I thought it may be simpler to use what's in ffmpeg itself 
[01:36] <stclaws> Same problem with rtmpdump btw
[01:36] <Compn> thats strange
[01:37] <Compn> did you set the live stream param in your fms ?
[01:37] <Compn> to keep it like 'one big stream' ?
[01:37] <stclaws> yes
[01:37] <Compn> well i'm out of ideas then
[01:37] <Compn> good luck
[01:38] <stclaws> I messed around a bit with the code in rtmpdump and managed to make it continue the input when the stream switched, but it still closed the outgoing stream. And I am just too ignorant to figure out how to fix that. 
[01:39] <stclaws> What is that "live" switch doing anyway? I could not find any details about it. 
[01:39] <Compn> ah, i was going to say, if rtmpdump worked that you could just pipe it to ffmpeg
[01:40] <Compn> did you set the live switch in ffmpeg or rtmpdump when checking your stream ?
[01:40] <stclaws> Yes, that's what I first planned
[01:40] <stclaws> rtmpdump
[01:40] <Compn> i mean you did rtmpdump --live ....
[01:40] <stclaws> yes
[01:40] <Compn> i dont remember what live switch does
[01:41] <Compn> did you read rtmp spec ?
[01:41] <stclaws> yes but it just says something very brief
[01:41] <stclaws> like "it then treats the stream as live" :)
[01:41] <Compn> haha
[01:42] <Compn> theres some info and other implementations here > http://wiki.multimedia.cx/index.php?title=RTMP
[01:42] <Compn> but i dont see what live does there either
[01:42] <Compn> lol @ adobe nonsense
[01:43] <stclaws> So I guess mr kshishkov is my man then :)
[01:45] <stclaws> Thanks
[01:46] <Compn> no problem
[03:07] <izaakschroeder> was wondering if anyone here is the expert on the m2ts container format (and possibly AAC/h.264 codecs); managed to capture what looks like RTP traffic over wireshark that contains what looks like an m2ts; however ffmpeg fails to recognize it after dumping from wireshark. the stream is from a M$ mediaroom system which i have no control over (iptv stb)
[03:08] <izaakschroeder> any pointers on what i can do or who i can talk to about this kind of thing
[03:12] <izaakschroeder> can provide 5 sample dumps from various channels including HD/non-hd
[04:02] <cone-965> ffmpeg.git 03Michael Bradshaw 07c430cb49fdc9: Update my email address
[04:02] <cone-965> ffmpeg.git 03Michael Niedermayer 072bcbdd845690: lavu: add more doxy to av_rescale_delta
[04:02] <cone-965> ffmpeg.git 03Michael Niedermayer 071909dbf11da0: ffmpeg: use av_rescale_delta() for audio stream copy
[04:34] <cone-965> ffmpeg.git 03Xidorn Quan 07c25e9292ba5b: fix a compiling error with llvm-gcc
[05:10] <izaakschroeder> :(
[05:12] <Compn> izaakschroeder : possibly michael or mru
[05:13] <Compn> izaakschroeder : its best if you upload those samples, make bugreport on the bug tracker
[05:13] <Compn> and stick around here to bug devels when they are active
[05:13] <Compn> mru may be found in #libav-devel , but not here
[05:14] <Compn> izaakschroeder : its better if you give us the rtp stream urls themselves
[05:14] <Compn> ffmpeg can read rtp
[05:14] <Compn> i'm guessing you are sniffing some kind of iptv and you dont have urls ?
[05:14] <Compn> oop, you said that already :)
[05:58] <izaakschroeder> yeah
[05:58] <izaakschroeder> sorry
[05:58] <izaakschroeder> Compn: that's right :)
[05:58] <izaakschroeder> someone filed the same kind of "issue" in 2010
[05:58] <izaakschroeder> i'll see if i can get the link for you
[05:58] <izaakschroeder> Compn: http://roundup.libav.org/issue2572
[05:58] <izaakschroeder> that describes  it pretty much
[05:59] <izaakschroeder> Compn: it doesn't look like anything has happened since though
[06:03] <izaakschroeder> Compn: in fact it doesn't look like the bug even ever got noticed
[06:28] <Compn> izaakschroeder : well, both ffmpeg and libav abandoned the roundup
[06:28] <Compn> so yeah you should re-report it to ffmpeg trac and libav bugzilla
[06:41] <izaakschroeder> Compn: mm ok; what other relevant info can i include to be helpful? do you want the raw wireshark data? just the RTP contents?
[06:42] <izaakschroeder> Compn: and whereabous does michael hangout if im to get ahold of him?
[06:42] <Compn> michaelni is michael
[06:42] <Compn> probably just not awake right now
[06:42] <izaakschroeder> Compn: aahh ok :>
[06:42] <izaakschroeder> is there a preference between him or mru?
[06:43] <ohsix> worst question ever
[06:43] <Compn> lol
[06:43] <Compn> izaakschroeder : mru is mpegts guy iirc
[06:44] <Compn> i dont know if either of them wants to help you reverse engineer iptv tho
[06:44] <Compn> i cant speak for them
[06:44] <izaakschroeder> Compn: thankies 
[06:44] <izaakschroeder> Compn: probably not
[06:44] <izaakschroeder> Compn: but some direction for me would be helpful
[06:44] <Compn> there are other people who like to reverse engineer things
[06:44] <Compn> but to do that they need .... access to the rtp streams
[06:44] <izaakschroeder> well i can help with that if they're willing to coordinate a little
[06:44] <Compn> maybe if you mail your hardware to them haha
[06:45] <Compn> :P
[06:45] <Compn> well put that info into your bugreports
[06:45] <Compn> and goods lucks
[06:45] Action: Compn sleeps
[06:45] <izaakschroeder> thanks for all your help :)
[07:13] <kierank> izaakschroeder: link doesn't work
[07:17] <izaakschroeder> kierank: the roundup link?
[07:17] <kierank> the dropbox one
[07:18] <izaakschroeder> kierank: ooh was probably old; are you interested in the files? i can send them
[07:18] <izaakschroeder> kierank: not those files, but ones i've captured
[07:18] <kierank> i just want to see what they look like in wireshark
[07:18] <izaakschroeder> kierank: sure just give me a minute i'll find a spot to post them
[07:18] <izaakschroeder> kierank: there's some interesting bits
[07:20] <kierank> i am on a train on 3g so i won't be able to download them
[07:20] <izaakschroeder> kierank: ooh ok; would you like the link for when you are home then?
[07:21] <kierank> maybe
[07:22] <izaakschroeder> ^_^
[07:22] <izaakschroeder> so what's your involvement in this project mr kierank 
[07:23] <kierank> very little
[07:23] <kierank> just work on mpegts a lot
[07:25] <izaakschroeder> oohh
[07:26] <izaakschroeder> well that is mighty timely
[07:26] <izaakschroeder> do you like the format? or is it merely out of necessity?
[07:37] <kierank> well it is mandatory for television transmissions
[07:39] <izaakschroeder> interesting 
[07:39] <izaakschroeder> do you work in the tv industry?
[07:53] <kierank> i guess
[08:10] <izaakschroeder> oh
[08:11] <izaakschroeder> well watcha dooo
[13:32] <michaelni> izaakschroeder, are the files you speak of available somewhere to download ? if not please upload them somewhere so developers can take a look (you can upload them to our ftp if you dont have a better place, see http://ffmpeg.org/bugreports.html)
[13:32] <izaakschroeder> michaelni: i can do that for you :)
[13:32] <izaakschroeder> give me couple of minutes
[13:33] <michaelni> ok, dont forget telling me the filename or url afterwards so i can also find them :)
[13:33] <izaakschroeder> will let you know in 4 minutes when it finishes uploading :)
[13:39] <izaakschroeder> michaelni: here you go! http://www.mediafire.com/?i3crfeg60d66h57
[13:40] <izaakschroeder> michaelni: those are about 20s captures from channels 4,5,6,601,602,603
[13:40] <izaakschroeder> the first 3 being non-HD, the latter 3 being HD
[13:42] <izaakschroeder> let me know if you need anything else :)
[14:08] <kierank> nice troll
[14:13] <michaelni> izaakschroeder, iam no wireshark expert but looking at these dumps wireshark is claiming a 50% packet loss for the RTP streams, if thats true that would explain why it doesnt work
[14:16] <ohsix> *should* in a post should permanently mark it wishlist :p
[14:16] <nevcairiel> sometimes carls template answers are just braindead stupid
[14:16] <nevcairiel> cant someone use libswscale without the issue appearing with the ffmpeg application?
[14:19] <ohsix> that is pretty dumb
[14:19] <ohsix> on who is it incumbent to prove it doesn't happen?
[14:20] <Compn> hrm ?
[14:21] <Compn> carl is like #1 bug sorter, you can complain about his methods, but until i see you guys review 100s of bugs ... welll
[14:22] <ohsix> at least the scanline one shouldn't be dismissed; but who's job is it to prove it happens or doesn't, in order to resolve the report; you presume that it does happen if someone reports it
[14:23] <Compn> in that report, carl is asking for a simple sample with benchmarks that shows the slow swscale vs the simd optimized swscale
[14:24] <Compn> carl is trying to help the user create a bugreport which can be read, understand, and help the developer / maintainer of that code quickly and easily fix the bug
[14:24] <Compn> a random 'xxx is slow' bugreport is not the best kind of bug for a devel to work on
[14:24] <nevcairiel> the problem is if you use swscale yourself, and not the ffmpeg application, you just cant give him what he asks for
[14:25] <Compn> you could provide a link to your code / binary and a testcase which shows the problem nevcairiel
[14:25] <Compn> but obviously, ffmpeg reports against git master are best
[14:26] <nevcairiel> its just the assumption that you must be using the application instead of the libraries directly that bugs me most of the time =p
[14:26] <Compn> well, i guess you didnt read the rules on reporting bugs using trac ?
[14:26] <nevcairiel> but they dont make sense for all cases
[14:26] <Compn> bugs against the libs , not using ffmpeg but your own custom code, go to libav-users list 
[14:26] <Compn> :P
[14:27] <Compn> but yeah
[14:27] <Compn> its not perfect
[14:27] <Compn> have to ask michael if he wants custom code bug reports, and if so, we should change the rules
[14:28] <nevcairiel> if you have decode failures or something like that you can usually reproduce it with ffmpeg, but some use-cases are just not covered by it
[14:29] <Compn> yeah i agree
[14:29] <Compn> but when you work on ffmpeg code, and someone comes along with a bugreport that says you have to compile xxx program with yyy libs and then hunt for a testcase yourself to debug the problem ... well
[14:30] <Compn> thats a lot of wasted time for devels
[14:30] <Compn> do you think michael should spend his time compiling other peoples code to debug a problem ?
[14:30] <Compn> i'm seriously asking for a solution to this
[14:31] <Compn> gcc requires small testcases for gcc bugs
[14:31] <Compn> so this isnt a new concept
[14:32] <Compn> you cant just say 'ffmpeg makes gcc crash' ... you have to copy and paste the crashing code to a new file for gcc devs
[14:32] <Compn> i'm not saying their methods are the best either
[14:32] <nevcairiel> providing simplified test cases is OK, its just the usual "ffmpeg uncut output or gtfo" comments that i don't like =p
[14:32] <Compn> alright  :)
[14:33] <ohsix> it may be obvious, but it's also not communicated very well when you say that :]
[14:35] <Compn> after all that ,it takes me 10 seconds to write up a nicer reply to bugreporter
[14:35] <Compn> so there
[14:39] <Compn> ohsix : to answer your question... its the age old bikeshed about bugreports
[14:39] <Compn> should devs spend time looking at every report , no matter how bad the info is? or should users be asked to fill out more info ?
[14:44] <ohsix> there's that should word again
[14:44] <ohsix> the presumption is that the software wants to be improved upon
[14:45] <ohsix> if there's a defect, _then_ you can decide who as to provide the required information in the negative or the affirmative
[14:45] <ohsix> which is what i was asking, cheyos or whatever his name is can basically prove in the affirmative that the report happens or doesn't happen with some investigation; invalidating the report because it hasn't been done is stupid
[14:47] <ohsix> just mark it NEEDINFO, and let it die if the reporter doesn't think it's important enough to elaborate
[14:48] <ohsix> that you collect bugs at all implies that it's mostly incumbent on you to do the work required :p
[14:48] <Compn> isnt that what carl said in https://ffmpeg.org/trac/ffmpeg/ticket/1853#comment:1 ?
[14:48] <Compn> ohsix : how would you find the bug in that report ?
[14:49] <Compn> start reading rawdec.c ? or is the bug in swscale ? 
[14:49] <ohsix> you could trivially prove that it happens, i've always been speaking to #1853
[14:49] <Compn> or is the bug in the users code because hes not free'ing something ?
[14:49] <ohsix> always/only
[14:50] <Compn> well i think carl is saying that he doesnt know how to prove it happens
[14:50] <Compn> thats why he asked
[14:51] <Compn> carl doesnt know everything :)
[14:51] <ohsix> unless he's the only one that will ever be able to solve the problem, it's probably an inappropriate response
[14:51] <ohsix> not responding to a bug is ok
[14:51] <Compn> no
[14:51] <ohsix> much like not speaking when you can't improve a bad situation
[14:51] <Compn> users then complain that 'ffmpeg never responded to my bug'
[14:51] <Compn> and they stop reporting bugs
[14:52] <ohsix> that will always be their problem
[14:52] <Compn> damned if you do, damned if you dont
[14:52] <ohsix> a response on a bug doesn't mean shit if it's never addressed
[14:53] <ohsix> not really, you include an implied user in this :p people that don't provide enough information or don't know how to will often not come to know how to do that without an intense amount of attention
[14:53] <Compn> well at least they could say that , then the developer would know hes on his onw
[14:53] <Compn> own*
[14:54] <Compn> 'i dont know how to reproduce' is a common theme
[14:54] <Compn> which is acceptable
[14:54] <ohsix> yep, that's why triage marks something NEEDINFO and doesn't come to any sort of conclusion
[14:55] <ohsix> if the information is never produced, you have to wait for a coincidence, or have users keep trying the series hoping it doesn't happen anymore
[14:55] <ohsix> it's baaaad
[14:55] <Compn> yeah but 'needsinfo' doesnt specify what info is needed
[14:55] <Compn> so there.
[14:55] <Compn> carl specified what was needed
[14:56] <Compn> gdb, valgrind, etc
[14:56] <ohsix> it doesn't need to; if it's not supplied and the state changed the bug can be expired, it's up to the reporter to investigate
[14:56] <ohsix> carl basically said he needed proof of what he was saying
[14:56] <Compn> you assume the user knows what to imply
[14:56] <ohsix> as it's stated it's perfectly plausible that it happens, even without verification
[14:56] <Compn> er the user knows what info to report i mean
[14:56] <ohsix> right, after NEEDINFO they know the bug state is changed
[14:57] <ohsix> people don't follow up on bugs, but the people that do ask what sort of information can get further attention
[14:57] <ohsix> people that aren't even going to respond to bug mail can't be asked to test changes, so fuck them
[14:58] <ohsix> (and depending on your sign off procedure, you probably need them to do that)
[14:59] <Compn> you're making a lot of assumptions 
[14:59] <ohsix> always have the user start the clock, and know the timetable, they are very important to the process
[14:59] <ohsix> eh
[14:59] <ohsix> i'm assuming they want their problem fixed (implied by them reporting it)
[15:00] <ohsix> i'm assuming they cooperate in order for the process to be able to continue
[15:00] <ohsix> those two aren't always true, but the "omg respond to everything" just wastes your time when it isn't
[15:00] <Compn> so you just want carl to mark bugs as 'needinfo' then ?
[15:01] <ohsix> there's a manpower aspect to it, but there's also the issue that a few people might take it upon t hemselves to do everything, it's bad for them and it's bad for the people they interact with
[15:01] <Compn> i think carl is doing a very good job at the reports 
[15:02] <Compn> its a lot of work for anyone to fix bugreports up for devels
[15:02] <Compn> maybe we're talking about different things
[15:02] <Compn> and i am missing the point
[15:03] <ohsix> an acceptable resolution for that bug would also be deciding if it was ok/expected for the padding to possibly be clobbered
[15:03] <ohsix> which would take some discussion
[15:04] <ohsix> the report is basically: it happens, and i think it's not supposed to do that. you don't need to really have him prove that it happens to investigate that it might, or decide if it's ok or expected
[15:04] <Compn> who reported the bug anyhow
[15:04] <Compn> this guy and his 7pixel video / image files
[15:05] <ohsix> no idea, he reported that cluster of them
[15:05] <Compn> a user with a lot of corner cases and not a lot of info about it
[15:05] <Compn> worst kind of user :P
[15:05] <Compn> ehe
[15:06] <ohsix> he said edge cases are very important on one of them
[15:06] <Compn> thats what the worst kinds of users always say
[15:06] <Compn> 'help me play this corrupted incomplete-downloaded file!' 
[15:06] <Compn> theres only one file of this kind and it would take 3 weeks to play 3 frames from it
[15:07] <ohsix> i don't think #1853 even needed to be replied to, if i was interested in it i'd add it to my own watch list, or investigate immediately, otherwise i'd see it again eventually
[15:07] <ohsix> i don't think you could call them a bad user
[15:07] <Compn> yeah but i blame the user :)
[15:07] <ohsix> the error message about 7x4 and stuff pretty much say it's invalid, he says it should work
[15:08] <Compn> at least he reported the bugs seperately
[15:08] <ohsix> the message is sort of an indication that it has been decided what will be supported, so that can either be a lack of documentation or no actual discussion having taken place, and in that case he's asking for refinement, information about whether it's correct, he's asserting that it's not
[15:08] <ohsix> right
[15:09] <cone-126> ffmpeg.git 03Janne Grunau 07154ff81870ce: h263: avoid memcpys over array bound in motion vector caching for obmc
[15:09] <cone-126> ffmpeg.git 03Diego Biurrun 0774e742d6ad09: doxygen: Drop some pointless entries from PREDEFINED macros list
[15:09] <cone-126> ffmpeg.git 03Diego Biurrun 0713bbefd57e8d: doxygen: Add av_alloc_size to list of predefined macros
[15:09] <cone-126> ffmpeg.git 03Diego Biurrun 0720015379a46a: cook: cosmetics: Better name for ccpl COOKSubpacket member
[15:09] <cone-126> ffmpeg.git 03Diego Biurrun 07f23b4a068230: cook: cosmetics: Better names for joint_decode() function parameters
[15:09] <cone-126> ffmpeg.git 03Diego Biurrun 078a61ba0e8194: cook: Remove senseless maybe_reformat_buffer32() function
[15:09] <cone-126> ffmpeg.git 03Diego Biurrun 07707f58f515ee: cook: Remove some silly Doxygen comments
[15:09] <cone-126> ffmpeg.git 03Diego Biurrun 0787cdd7c6949e: ivi_common: Drop unused function parameter from decode_band()
[15:09] <cone-126> ffmpeg.git 03Diego Biurrun 07ca7f59119b8a: doc: git-howto: Clarify comment about pushing series of commits
[15:09] <cone-126> ffmpeg.git 03Mans Rullgard 071aa07aa21c4e: configure: fix tests for 2-arg math functions
[15:09] <cone-126> ffmpeg.git 03Michael Niedermayer 0795760b33e7a4: Merge remote-tracking branch 'qatar/master'
[15:09] <ohsix> there are a lot of bugs like that that are fuzzy, you can just decide that it's invalid, mark the bug invalid and document the valid sizes; or you can decide it's valid and fix it, either way you go you have a str8 line to a fix, they are pretty decent reports in that regard, even if they are just his opinion of what is correct behaviour (and barring documentation saying otherwise, he might as well be correct in that thinking)
[15:10] <Compn> you know how it works around here
[15:10] <Compn> if you want to review bugs, reopen, mark invalid, or whatever , do it
[15:10] <Compn> getting people to change their habits never works
[15:11] <ohsix> right, i'm not volunteering; so you can take what i say for whatever :p
[15:11] <Compn> :)
[15:11] <ohsix> but as a pure decision to be made, #1853 is "decidable" and you don't need a follow up to start working on it
[15:12] <ohsix> if there are people that just triage bugs that can sometimes not work well, they won't always be able to see that
[15:12] <Compn> you assume his guess that the problem is in swscale
[15:12] <Compn> was correct
[15:12] <Compn> :P
[15:12] <ohsix> he wouldn't have something as specific as an overwrite into padding without having tested it already or confirming it
[15:13] <ohsix> he goes so far as to say if it's a subimage it can ruin the outer content, which is probably the scenario where he encountered it
[15:13] <Compn> you have a lot of faith in anonymous bugreporters 
[15:13] <ohsix> there's enough information to presume it's correct and start work in proving that it isn't, or modifying the documentation to say that it may happen
[15:14] <ohsix> not really, he's extremely specific already
[15:14] <ohsix> again, just on the one bug
[15:14] <Compn> he said 'sometimes'
[15:14] <Compn> you cant document a sometimes
[15:14] <ohsix> he could be operating on the principle that writing into padding is undesirable from some other situation, but he said it happened
[15:15] <nevcairiel> his problem is that he doesnt have padding, so it overwrites real pixels =p
[15:15] <Compn> yeah hes not padding it
[15:15] Action: Compn hasnt a clue about any of this
[15:15] <Compn> ehe
[15:15] <ohsix> COMPLETELY UNUSABLE
[15:16] <thegeek> if it's true it should at the very least be documented
[15:16] <ohsix> if i got a reply like that, not knowing who the guy was, i'd probably be pissed; or sizing up what proof is going to be acceptable to this likely arbiter of usable or unusuable
[15:16] <ohsix> if i find out the proof is going to be onerous, when i explained a completely frank premise; i'd probably decide not to do it
[15:16] <Compn> well why dont you message the bugreporter and find out how he feels about carls reply
[15:16] <Compn> you are concern trolling now
[15:17] <ohsix> i've been consistent, i said bugs don't need to be replied to; i said that reply was worse than no reply, i said the original report was very actionable and the initial response is nonsensical
[15:17] <Compn> took a while for me to realize it :)
[15:18] <ohsix> so if it's trolling to feel around the point i'm trying to make, that's fine; but i had it all in mind when i started the conversation
[15:18] <Compn> -now
[15:18] <Compn> you are concerned for other people, concern troll
[15:18] <ohsix> i'm concerned for myself
[15:18] <Compn> heh
[15:19] <ohsix> i told you how i would react if i had a similarly clear bug report, and got that type of response
[15:19] <ohsix> "completely unusuable" is wrong
[15:19] <Compn> i'll concede it
[15:20] <Compn> hard to find a completely unusable bugreport :)
[15:20] <ohsix> "this may be a serious bug", if you presume he'd report it because he's experienced it, and he's investigated it enough to know that filing a bug is appropriate, is kind of making light of it
[15:20] <Compn> but you know that english isnt carls first language
[15:20] <Compn> nor is english the first language for most people in the project ...
[15:21] <ohsix> i know
[15:21] <Compn> even fabrice is french
[15:22] <Compn> my english isnt great and i'm an american!
[15:22] <Compn> (joke against americans haha)
[15:22] <ohsix> the only reason i'm pretty good at reading ESL language butchering is from people that are american speaking or writing extremely poorly :p
[15:23] <ohsix> what were you referring to earlier about requirements for filing bugs, is an invocation of ffmpeg that exhibits the errors required even when you target libswscale for the bug?
[15:24] <Compn> the bugreporting rules mention giving an example using ffmpeg 'full uncut output' 
[15:25] <Compn> or did you mean something else ?
[15:25] <ohsix> a separate but important aspect to that _is_ probably using the libraries outside of ffmpeg; since people are supposed to be able to, getting ffmpeg to do it might not do it, or requiring ffmpeg to do it might make a valid bug unreportable
[15:25] <Compn> do i think that the libs of the project should be bugreported using ffmpeg output ? where possible, yes
[15:25] <ohsix> right, the way i read it i couldn't tell if it was a requirement, you said "valid"
[15:26] <Compn> we've had a few people who find bugs in the libs, using custom code, but when asked if they can reproduce it with ffmpeg, either they can, and give us an ffmpeg report, or they cant,  and find a bug in their own code
[15:26] <Compn> so asking users to check if reproducable in ffmpeg solves some problems sometimes
[15:26] <ohsix> right but a bug shouldn't be invalidated if that can't happen, it just easily facilitates reproduction for a developer; if libswscale can be used by itself you'd want it to work for things libswscale purports to do even if ffmpeg doesn't
[15:26] <Compn> by 'valid' i dont mean its a requirement, just that it makes for a better bugreport
[15:26] <ohsix> ok
[15:26] <Compn> valid in that , a devel will be more likely to look at a report
[15:27] <Compn> if it has full uncut ffmpeg output
[15:27] <Compn> i think carl does not mark bugs invalid if its missing the info
[15:27] <ohsix> you're basically saying it will get more attention if it's trivially reproducable
[15:27] <Compn> he will mark bugs invalid if no reply within 6 months and no more info ...
[15:27] <Compn> yes
[15:27] <Compn> not more attention
[15:27] <ohsix> right, ok
[15:28] <Compn> but actually get fixed, if its reproduceable
[15:28] <ohsix> well, a quick fix does seem like more attention
[15:28] <Compn> yeah
[15:28] <ohsix> considering how many other bugs are seemingly ignored; it depends on how you handle bugs tho
[15:29] <ohsix> this is all academic, you understand what i'm saying; "may" and a judgement on the usability of the bug without seemingly being able to understand the actual posts content is worse than not replying at all
[15:30] <Compn> but you cant prove that its worse or better
[15:30] <Compn> scientifically
[15:30] <Compn> you are guessing
[15:30] <ohsix> what exactly am i guessing?
[15:30] <ohsix> that no reply would be less annoying to the guy reporting it?
[15:30] <Compn> yes
[15:31] <ohsix> ok, i don't remember the name of the principle; but if you say nothing you have no way of insulting someone that isn't internal to their own perception
[15:31] <ohsix> they may be annoyed that they feel ignored,  but they will be really annoyed if you tell them to fuck off
[15:31] <Compn> thats a principle, its not a scientific fact
[15:31] <Compn> its just a theory :)
[15:31] <ohsix> the first response is entirely up to them
[15:32] <Compn> have you reported bugs to projects and been ignored ?
[15:32] <Compn> have you reported bugs to projects and been told your bug was invalid ?
[15:32] <Compn> which one did you fight ?
[15:32] <Compn> :)
[15:32] <Compn> if you want to prove this its easy
[15:33] <Compn> count the bugs , find the ones where carl has replied, count how many of those got more info
[15:33] <ohsix> i know i wasn't ignored, but they may have been rhetorical, or i wasn't able or willing to test a new version, or there wasn't anything that someone could do about it
[15:33] <Compn> vs the bugs where no one replied , and how many of the bugs that no reply got more info
[15:33] <Compn> then compare the bugs together and see which one wins out
[15:33] <ohsix> i haven't been told a bug was invalid where it approached a problem that wasn't decided in the project
[15:34] <Compn> bonus if you count unreplied bugs and fixes vs replied bugs and fixes
[15:34] <ohsix> here's a simple way to explain the theory about ignoring reports, there is only one person involved if you do, there is 2 or more involved, possibly making the situation worse if you do
[15:35] <ohsix> s/worse if you do/worse if you don't
[15:35] <Compn> would it be better if michael just replied 'cant reproduce' ?
[15:35] <ohsix> it's not implied that the response will make the situation worse, but it's a possibility if you end up seemingly responding in a way that professed no understanding of what the reporter wrote in his post
[15:35] <Compn> which happens ... a lot
[15:36] <Compn> i get your theory, i get it, i just think its wrong
[15:36] <ohsix> the guy made an assessment about the bug being useful, the reporter doesn't care, and his assessment is objectively wrong
[15:36] <ohsix> it is a useless response
[15:37] <Compn> he asked for more info
[15:37] <Compn> thats not useless
[15:37] <Compn> thats exactly what you want
[15:37] <Compn> now you could say 'parts of his reply were useless'
[15:37] <ohsix> he didn't ask for anything pertinent to the actual bug reported, and he made a value judgement that is wrong
[15:38] <Compn> asking for a valgrind is pertinent
[15:38] <ohsix> value judgement has no place when people are providing you information, presumably in good faith; that you are both interested in, to improve your shared interest
[15:38] <ohsix> he already ran valgrind, or a test that used libswscale that showed the problem
[15:38] <ohsix> he wouldn't have discovered it if he hadn't
[15:38] <Compn> then it shouldnt be a problem for him to report that information
[15:38] <nevcairiel> considering he said it overwrites his actual pixels, and not said it crashes, valgrind wouldnt show anything
[15:39] <Compn> shhhhhhhhhh :P
[15:39] <nevcairiel> or are we talking about something else now? :P
[15:39] <Compn> no same bug
[15:39] <Compn> arguing over one sentence for 30 minutes
[15:39] <ohsix> he doesn't _need_ to provide that information for it to be looked into, he says he doesn't know the case in which it happens, and his assessment of what may be happening
[15:40] <Compn> how do you know it isnt sdl causing problems on odd-resolution video ?
[15:40] <ohsix> it's plausible that it is happening, and he wouldn't be reporting it if he didn't notice it in some way
[15:41] <Compn> and that the overwriting is something else in ffmpeg
[15:41] <Compn> but that he says is swscale
[15:41] <Compn> how do you know its not the decoder ?
[15:41] <ohsix> how does he know it is swscale?
[15:41] <Compn> correct
[15:41] <Compn> how do you even know if hes using swscale ?
[15:42] <nevcairiel> because he said so? :D
[15:42] <Compn> you believe users like that ?
[15:42] <ohsix> how does he know, he could be some boob that just said he was because he heard of this swscale something somewhere
[15:42] <Compn> we get people in #mplayer talking about windows media player ....
[15:42] <nevcairiel> it depends, you can usually judge by the way its written if he knows what he is talking about, or if he is just talking nonsense
[15:42] <ohsix> he has very specific information, and a hypothetical situation that is probably close to what he is actually doing and seeing the problem
[15:42] <Compn> they can use irc, but cant read a topic explaining #mplayer to be for the project hosted at mplayerhq.hu
[15:43] <ohsix> you can of course fake that, but if there's no tell, they're either a reallllly good fake, or they know what they're talking about, and you can take it at face value; but the response for both is exactly the same, and you shouldn't really be deciding if he's a good fake :p
[15:44] <Compn> you dont even know if hes using git
[15:44] <Compn> or if hes using 5 year old swscale
[15:44] <ohsix> over time, when you speak to him more about the problem or with proposed solutions, if he's able to keep up with the bug context, he still knows what he's talking about
[15:44] <ohsix> heh
[15:44] <Compn> ohsix : thats why we ask for ffmpeg output, to see what version libs they are using
[15:44] <Compn> because bug may already be fixed
[15:44] <Compn> thats what makes it valid
[15:44] <ohsix> he could be,  but why wouldn't you try a new version if you were using libswscale and found out it had a bug, then what you'd be reporting is it doesn't work on x, does work on y
[15:44] <Compn> that they verify they use recent ffmpeg version.
[15:44] <Compn> or recent lib versions.
[15:44] <ohsix> it's more likely he's using a distro package,  btu those still aren't 5 years old
[15:45] <nevcairiel> on debian they might
[15:45] <ohsix> then you'd be like "this patch fixed that" and he'd go to debian to get it into the package
[15:47] <ohsix> it is kind of weird he didn't include a version tho
[15:47] <Compn> even ffmpeg devels get screwed by a system ffmpeg once in a while
[15:47] <ohsix> TBH i thought it was someone trolling about swscale sucking originally
[15:48] <ohsix> given the name and the number of them closely filed together
[15:49] <Compn> its just someone whos frustrated with his code who finally makes a dumb account to report a bug
[15:49] <ohsix> you get some context about what he was actually doing on the 7x4 one, with ffmpeg output
[15:49] <ohsix> unless your documentation is perfect that frustration isn't always incumbent on the 3rd party
[15:50] <Compn> i mean frustrated it doesnt work
[15:50] <Compn> not pining the blame on anyone
[15:50] <Compn> pinning
[15:50] <ohsix> documentation is unambiguous and you may be doing things in a way that is actually undecided by the people implementing the api, but you happen to touch it
[15:50] <ohsix> s/unambiguous/ambiguous/
[15:51] <Compn> no one is arguing the docs cant be updated
[15:51] <ohsix> the best kind of documentation is the kind that elides a bunch of stuff because you need to know the outer discipline :] people come in without familiarity with that outer discipline and fuck everything up
[15:51] <ohsix> that's just a digression into the typical and real documentation problems i've seen with people consuming them, nothing to do with ffmpeg's documentation in particular
[15:53] <ohsix> i've no killer or absurd examples to offer though :[
[15:54] <ohsix> the alsa documentation is ambiguous in places, and there is a lot of presumed knowledge of clocks and other stuff to get things correct
[15:54] <ohsix> most people bodge it and do ok, though how to even do that isn't in the documentation per-se; but they do already know what write() means
[15:54] <Compn> ohsix : the thing is, people that know exactly where the pixels are being overwritten can give line numbers usually :P
[15:55] <thegeek> man, you guys;P
[15:55] <ohsix> yea i'm not going to speculate about what he's done anymore
[15:55] <ohsix> i'm pretty sure he's actually seen some dirt when using large strides to overlay images tho, just like in the report :p
[15:57] <Compn> thegeek : so whats up with you ?
[15:57] <thegeek> :)
[16:41] <cone-126> ffmpeg.git 03Michael Niedermayer 077de21960292c: sws: fix extreem downscaling
[17:03] <cone-126> ffmpeg.git 03Michael Niedermayer 07733f85b7ae02: sws: improve error messages
[17:03] <cone-126> ffmpeg.git 03Michael Niedermayer 07425c30ddae3e: sws: loose the minimum dimension checks
[17:53] <cone-126> ffmpeg.git 03Reimar Döffinger 075f9cbad60372: Port MPlayer fixes for coverity issues in libmpcodecs.
[20:04] <m4t> hi, for some reason av_open_input_stream seems to not set AVFormatContext->pb, so it is 0x0 and causes segfaults when its called later by ff_get_guid(pb, &g) or ff_id3v1_read(AVFormatContext *s)
[20:05] <PwrSurge> When I try to use ffmpeg, i get [mjpeg @ 0x438ab0] Could not parse framerate: 25. 
[20:06] <PwrSurge> any idea what would cause framerate parsing to fail?
[20:38] <m4t> doh i figured it out
[20:39] <m4t> it was hitting if (pb && fmt && fmt->flags & AVFMT_NOFILE
[20:40] <m4t> and not setting ic->pb = pb;
[20:48] <ubitux> specifications on a wiki? WTF
[21:06] <durandal_1707> is it true that multithreaded slice decoding of h264 depends on how file was encoded?
[21:09] <durandal_1707> michaelni: how to handle overflow in caf demuxer patch? The only way I see is to abort if size is too big.
[21:16] <durandal_1707> ubitux: vampires
[21:19] <ubitux> i don't have silver bullets :(
[21:23] <durandal_1707> on google page "you do not use modern browswer...." - yea right
[21:25] <michaelni> slice decoding needs slices on the encoder side to be enable, some formats have mandatory slices, mpeg2 is one
[21:26] <michaelni> if some value overflows 64bit, yes header parsing should probably fail
[21:27] <michaelni> if such a file is valid we need the file probably to know what to do
[21:30] <Daemon404> [15:23] <@durandal_1707> on google page "you do not use modern browswer...." - yea right <-- what do you use?
[21:30] <Daemon404> inb4 opera or lynx
[21:33] <durandal_1707> Daemon404: opera and elinks
[21:33] <Daemon404> figured
[21:33] <Daemon404> standard BSD user browsers
[21:34] <m4t> i have some code that uses AVFMT_NOFILE but also wants to set AVIOContext
[21:34] <m4t> how does that work?
[21:36] <durandal_1707> what is audio codec 0xA100 as riff tag?
[21:39] <cone-126> ffmpeg.git 03Michael Niedermayer 07f44be0da946c: ff_h263_decode_init_vlc: fix order of operations to avoid failure with 2 threads
[21:40] <cone-126> ffmpeg.git 03Michael Niedermayer 076c8d259ab13f: msmpeg4dec: fix init code to not fail when called from 2 threads at the same time.
[21:40] <izaakschroeder> michaelni: i was curious about the packet loss also; however it happens every time i attempt capture of data and there's no perceivable loss when watching the actual content on the TV while it's being captured at the same time. am i missing something?
[21:41] <durandal_1707> hah found it: 0xA100 is Comverse Infosys Ltd. G723.1
[21:43] <ZiNC> Hey.
[21:43] <durandal_1707> there is bunch of G.* codecs, which one of them is so relevant that FFmpeg should have support it?
[21:44] <ZiNC> Will a non-ffmpeg question, but audio related, be frowned upon? :)
[21:46] <durandal_1707> i HATE when someone beats me
[21:47] <Daemon404> yeah what an asshole. he should have known you were working on a one line change and not done it.
[21:49] <durandal_1707> I'm deeply sorry, but I cannot share such opinion(s) with you
[21:50] <m4t> nobody?
[21:50] <Daemon404> i wonder if they have sarcasm over there in croatia
[21:50] <Daemon404> <_<
[21:50] <m4t> would it help if i just put up a link to the source file im working with?
[21:50] <m4t> https://code.google.com/p/squeezeslave/source/browse/squeezeslave/trunk/squeezeslave/src/slimaudio/slimaudio_decoder_aac.c
[21:51] <m4t> i don't see how AVFMT_NOFILE will work with read callbacks specified in a custom AVIOContext
[21:51] <michaelni> durandal_1707, i didnt push it yet, i can wait if you want ?
[21:52] <durandal_1707> michaelni: nah, i'm dumb and slow
[21:54] <michaelni> m4t, your code looks broken
[21:54] <m4t> not my code, but yeah
[21:54] <m4t> trying to unbreak it
[21:55] <michaelni> you cant change the structs rturned by av_find_input_format()
[21:57] <michaelni> and i dont know why the code is  doing that ...
[22:25] <Compn> durandal_1707 : you see twocc list on wiki.multimedia.cx  ?
[22:25] <Compn> it has them all listed...
[22:30] <m4t> weee
[22:30] <m4t> i fixed it!
[22:30] <m4t> :D
[22:30] <m4t> aac: probe ok name:aac lname:raw ADTS AAC
[22:31] <m4t> took 5 hrs :/
[22:31] <m4t> http://pastebin.com/dvnrnZxS
[22:35] <durandal_1707> what is that?
[22:36] <durandal_1707> michaelni: you lost commit rights or what?
[22:41] <cone-126> ffmpeg.git 03Piotr Bandurski 072ef26b5e7337: riff: support 0xa100 TwoCC
[22:43] <j-b> where is this 4790b7f1c44f98e35f3b806468fa615f5930a5b3.wav ?
[22:44] <durandal_1707> j-b: link to big zip is on bug report
[22:44] <funman> http://ffmpeg.org/trac/ffmpeg/ticket/1856
[22:46] <durandal_1707> it is full of 3ga files with missing moov atom
[22:46] <j-b> yep
[22:46] <j-b> because it smells like a forum issue reported on VLC last few days
[22:48] <durandal_1707> j-b: you know some relevant speech codec that should be supported but it is not?
[22:49] <j-b> durandal_1707: is there anything relevant that ffmpeg does not support, to be honest?
[22:50] <j-b> durandal_1707: the biggest issues I see are people using Stupid stuff from broadcasting and some G72x variants
[22:50] Action: Daemon404 slaps j-b with mxf
[22:52] <j-b> oh yeah
[22:52] <j-b> and Let's put 16 channels of raw audio in mov, even if those are in fact 4 different tracks
[22:53] <Daemon404> hah
[22:53] <Daemon404> yes
[22:53] <Daemon404> dont they have some sort of metadata track
[22:53] <j-b> of course
[22:53] <j-b> but the answer is: fuck you, use multiple tracks
[22:53] <Daemon404> :3
[22:53] <j-b> they usually do not like this answer
[22:54] <ubitux> it's because it's lacking a "e" in the sentence
[22:54] <nevcairiel> people always find some braindead way to create stupid files
[22:54] <ubitux> "fuck you e use multiple tracks"
[22:54] <ubitux> see? much better.
[22:54] <Daemon404> nevcairiel, im not sure people who write 'pro' video tools are 'people'
[22:55] <Daemon404> i heard avid exclusively hires demons
[22:55] <cone-126> ffmpeg.git 03Clément BSsch 076078bd802471: lavf/showspectrum: fix unaligned rdft data.
[22:55] <nevcairiel> those pro tools are the worst
[22:55] <nevcairiel> some engineer thought he was mighty smart
[22:55] <j-b> durandal_1707: jokes aside, i don't really know. The Voxware was annoying though
[22:56] <ubitux> durandal_1707: you're looking for some codecs to implement?
[22:56] <Daemon404> voxware metasound or optimfrog
[22:56] Action: Daemon404 runs
[22:56] <ubitux> durandal_1707: i think mpeg-4 audio specs have a lot of unimplemented ones
[22:57] <Daemon404> mainly libav* lacks ER AAC LD
[22:57] <nevcairiel> some people kept bugging me last about about LD support
[22:57] <Daemon404> nevcairiel, i get bugged for it too
[22:57] <nevcairiel> s/about/week/
[22:57] <Daemon404> and i keep telling them
[22:57] <Daemon404> "dont upload LD to a vidoe sharing site"
[22:57] <Daemon404> "it makes no sense"
[22:57] <nevcairiel> someone insisted i should use the frauenhofer codec because it supports LD
[22:57] <Daemon404> the decoder?
[22:58] <nevcairiel> yea
[22:58] <Daemon404> thats not even legal
[22:58] <nevcairiel> thats what i told him
[22:58] <Daemon404> faad also supports it
[22:58] <Daemon404> but.. meh
[22:58] <j-b> durandal_1707: iSaC ?
[22:58] <j-b> Siren?
[22:58] <nevcairiel> i also told him that LD doesnt make sense in any files, except if its a dump of some speech stream
[22:59] <nevcairiel> but users are users
[22:59] <Daemon404> nevcairiel, for me, users wanna upload recordings of conference calls
[22:59] <Daemon404> or they accidentally check LD in final cut
[22:59] <Daemon404> or smth
[22:59] <nevcairiel> wonder if LD would be that complicated to support
[23:00] <nevcairiel> not that i know anything about aac
[23:00] <Daemon404> alex said if he could get a weekend free, he could do it
[23:00] <Daemon404> im holding out hope.
[23:00] <nevcairiel> he hasnt been really all that active lately
[23:00] <j-b> durandal_1707: G.7xx, AMR-dtx ?
[23:01] <nevcairiel> i guess we can be lucky that people dont come with aac ssr files
[23:06] <cone-126> ffmpeg.git 03Michael Niedermayer 07189fbcede89b: tak_parser: check ff_combine_frame() return code
[23:06] <cone-126> ffmpeg.git 03Michael Niedermayer 070f943ed3c8e5: swfenc: zero fifo after freeing
[23:08] <durandal_1707> ubitux: i have list for REing small audio codecs but imho it is nothing really important: QDMC, zvr (some speech variant, appears to not be used anymore) and that is it
[23:13] <durandal_1707> j-b: you have any samples for G.7xx ?
[23:16] <j-b> which one ?
[23:16] <durandal_1707> any 
[23:17] <durandal_1707> michaelni: wav demuxer have problems with codecs like G.723_1 and imc: you get bunch of warnings with -f framemd5, and i cannot locate source of the problem
[23:23] <michaelni> how can it be reproduced?
[23:47] <j-b> durandal_1707: g718, I think so
[00:00] --- Sun Oct 28 2012