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

[burek]

[00:03] <ubitux> it's nice to see someone working on ffplay :)
[01:07] <cone-32> ffmpeg.git 03Paul B Mahol 07master:58b36959dd09: tta: use get_unary()
[01:07] <cehoyos> saste: Patch applied, thank you!
[02:04] <cone-32> ffmpeg.git 03Michael Niedermayer 07master:5711e4fd111a: fate: use TARGET_SAMPLES in mcdeint tests
[10:35] <cone-552> ffmpeg.git 03Kostya Shishkov 07master:de421b208578: use my full first name instead of short one in copyrights
[10:35] <cone-552> ffmpeg.git 03Luca Barbato 07master:28306e6d620c: network: factor out bind-listening code
[10:35] <cone-552> ffmpeg.git 03Michael Niedermayer 07master:4d4f5911d312: Merge commit '28306e6d620c109ddd672f7243adfbc2bbb3b18f'
[11:07] <burek> darwin machines all seem to be dead?
[11:07] <burek> since the early May
[11:09] <nevcairiel> ever since the server move, maintainer needs to update ssh key
[11:18] <cone-552> ffmpeg.git 03Luca Barbato 07master:f849a77e6795: network: factor out connect-listening code
[11:18] <cone-552> ffmpeg.git 03Michael Niedermayer 07master:54ddbb477b78: Merge remote-tracking branch 'qatar/master'
[11:42] <burek> does ffserver re-encodes the feed it gets from ffmpeg or it just broadcasts it?
[11:52] <burek> for example, shoutcast and icecast are 2 most popular audio broadcasting servers, which just broadcast the feed they get, without any re-encoding and stuff, which simplifies the entire model.. things they do is mostly buffering and broadcasting.. so maybe there is a chance to do the same thing in FFmpeg to somehow simplify ffserver and make it more maintainable..
[11:54] <cone-552> ffmpeg.git 03Michael Niedermayer 07master:a40370661dd0: use Kostyas full name in copyrights
[11:54] <cone-552> ffmpeg.git 03James Almer 07master:682b2273e851: lavu: Add SHA-2 512 hashing
[12:50] <ubitux> burek: afaik ffserver doesn't really do encoding; it communicates with ffmpeg to make it do the encode
[12:50] <burek> ubitux, im not quite sure if that's the case, since docs are not that extensive
[12:51] <burek> for example, if you have 2 <Stream> elements, one as mjpeg video, another as x264 video, does ffserver tell ffmpeg to send those 2 video streams through ffm format or what?
[12:52] <ubitux> i think so
[12:52] <ubitux> grep avcodec_encode ffserver.c  nothing.
[12:53] <burek> i've seen people doing something like: ffmpeg -i input -c:v codec -f ffm http://localhost:8090/feed1.ffm
[12:53] <burek> and docs didn't really help me understand what happens in that case
[12:53] <burek> so i figured it re-encodes on its own :s
[12:54] <ubitux> maybe one is ignored
[12:54] <ubitux> (or maybe it's encoded twice by ffmpeg?)
[12:54] <ubitux> but you are right on one point, ffserver needs more love
[12:54] <ubitux> and we need a maintainer
[13:10] <burek> why is cehoyos so difficult person?
[13:10] <burek> did he get married early or what? :)
[13:13] <ubitux> dunno what's the point he's making in #2623
[13:15] <Compn> he is king of the trac
[13:16] <Compn> i hate and or never use those automated crash reports
[13:16] <Compn> i never send them in because they all take ram dumps :\
[13:24] <cone-552> ffmpeg.git 03Michael Niedermayer 07master:09d6beee2496: avutil/sha512: Reshuffle Maj() operands
[13:26] <michaelni> ubitux, i think carls point is that the automated crash dumps would not contain debug symbols and thus be close to useless
[13:27] <ubitux> well, it will be as useful as the -report option i guess
[13:27] <ubitux> not that i particularly care about such system
[13:29] <michaelni> hmm, if the crash dumps would only be enabled when debug symbols exist and they would include all input files then they might be usefull but iam not sure if its a good idea
[13:33] <burek> the point is not about his own opinion, but rather by the fact he is kinda strange person who likes to keep "his trac" clean, closing as much issues as he possibly can, without giving it a chance to be commented on by any other developer
[13:34] <burek> it's kinda pointless.. and it leads to a clean trac with no issues opened in the future, but with the broken product.. since no user will want to post anything anymore there
[13:38] <michaelni> closing an issue doesnt really prevent people from commenting nor from reopening the issue
[13:39] <michaelni> if you disagree with carl closing it its probably best you reopen it
[13:40] <burek> it just sends the wrong message to the reporter, that's all and i don't want to get involved into arguing with him about such actions, since it didn't make any sense in the past also, so it's a waste of time imho
[13:42] <michaelni> if you consider it a waste of time to reopen you are litterally saying you agree with him that closing was good :)
[13:42] <burek> i guess
[13:43] <burek> if nobody else cares, why should i
[13:43] <burek> but now i kinda start realizing why ffmpeg forking happened in the first place
[13:46] <michaelni> burek, cehoyos as both of you are here now, please resolve your ticket #2623 disagreements
[13:47] <Compn> michaelni : well whats your opinion of auto crash reports ?
[13:47] <Compn> could we make ffmpeg stream copy a .crash to ffmpeg ftp? :)
[13:47] <Compn> but yeah stripped binaries wont help anything 
[13:47] <michaelni> Compn, i wish i knew what my oppinon is on it
[13:47] <Compn> :)
[13:48] <Compn> burek : how are we going to get anything useful from a bunch of stripped ffmpeg releases ?
[13:50] <burek> well, imho, the proper approach would be to investigate how the other software developers have done it and just copy the same idea.. obviously it is possible, it just needs some research
[13:51] <burek> but, it's better to just close the issue, without even considering any alternatives, it will help people sleep better i guess
[13:53] <cehoyos> Some points, not necessarily limited to ticket 2623:
[13:54] <Compn> burek : sounds good 
[13:55] <cehoyos> I am deeply convinced that trac is not the right place for random ideas. Those ideas (no matter if they are useful and helpful or not) worsen the signal-to-noise ratio of trac and do not help the actual issues (and I agree that both FFserver and bug reports are real issues): They do not bring us one (not even a tiny one) step nearer to a solution, but imo, by worsening the SNR, they make solving the problem (a tiny bit) 
[13:55] <cehoyos> more difficult.
[13:55] <Compn> where do you want random ideas ? wiki ?
[13:56] <Compn> trac wiki or multimedia wiki ?
[13:56] <burek> cehoyos, what do you suggest then, where should enhancements/feature requests be posted?
[13:56] <Compn> i dont mind, as long as you tell us where they should go :)
[13:56] Action: Compn afk for while
[13:56] <michaelni> isnt priority=wish enough to seperate random ideas out already ?
[13:58] <cehoyos> At one point, we (not we, but for the sake of this discussion: we) had changed FFmpeg to distribute non-stripped binaries by default. This was objected by several people, and additonally configure by default produced stripped binaries for many years. Since nobody ever reported this as a problem (but it was immediately objected when changed), I don't think it is likely a good idea to change it. (Please note that I have no 
[13:58] <cehoyos> strong personal opinion on this, I am just reporting the likely agreement among the developers and distributors:)
[13:59] <cehoyos> burek: feature requests should be reported on trac, but both "please rewrite FFserver" and "please invent a bug reporting automatism that is completely unrelated to the current FFmpeg binaries" are not feature requests, they are random ideas.
[14:00] <michaelni> if people want, i think i can easily add a type="random idea"
[14:00] <cehoyos> micihaelni: I think you are wrong, several "wishes" are very important, but they are now buried under a large number of ideas that are - afaict - very unlikely to ever get implemented, and if they get implemented, I doubt it will be because of the ticket in trac.
[14:00] <cehoyos> michaelni: That will not improve the SNR imo
[14:01] <burek> the problem i see here is that cehoyos is self-proclaimed person who decides which feature suggestions are random ideas (bad) and which are true feature suggestions (good)
[14:02] <burek> so, im not gonna comment any more on this issue, because i see no point in answering such statements as above
[14:04] <cehoyos> Wow, that were only the technical issues, I just wanted to start with the personal "attacks", and even rereading above I can't find anything "self-proclaiming"
[14:08] <cehoyos> There is of course a point mostly unrelated to the above: Ticket 228 was opened against FFserver, and at the time, I still hoped somebody else would work on those tickets, this turned out not to be true;-( When I pulled together all my strength and reproduced several FFserver tickets (closed one or two as "fixed") and tried to reproduce 228. I failed, mostly because my usage knoledge of FFserver is extremely limited. So I 
[14:08] <cehoyos> asked in the ticket to explain how I can reproduce the ticket (I am always very interested even to reproduce fixed tickets with older versions to find the fixing commit). The answer was " I don't have the same environment as I had back then, so I can't (easily) check what you ask" which seems extremely difficult to believe because nothing in the ticket indicates that it is environment-specific (and nothing in the answer 
[14:08] <cehoyos> indicates that burek even tested again).
[14:09] <michaelni> what IS a feature request ? For example IMHO if Smith wants to use ffmpeg for something and cant thats a feature request. Also if the developers who work on bugreports want to get automated crash reports that too is a feature request. But here its really a well meant suggestion from someone not benefiting himself from if that is implemented. I dont agree with quickly trying to get rid of such suggestions but i do see at lea
[14:09] <michaelni> st to some extend that this differs from normal feature requests
[14:10] <cehoyos> In the years since, he opened a very large number of tickets, not only "ideas". Many of them lacked nearly all information to reproduce and this week, two long-term developers completely failed to understand the tickets (costing them a lot of time). So yes, I am biased against these tickets, but I unfortunately see nothing in todays tickets that could change my opinion.
[14:11] <cehoyos> And I will of course remove my adming and developer rights myself from trac (assuming this is possible) if this is wanted by either michaelni or other developers.
[14:13] <burek> Nobody is asking you to "return your crown"
[14:13] <burek> what am I trying to do here is to make you aware of your actions
[14:13] <burek> that are not producing anything good in the long run
[14:13] <burek> i appreciate your work on the trac and i know its a big job to do so
[14:14] <burek> but i dont approve when you bounce of a reporter as quickly as you can
[14:14] <cehoyos> A few feature requests (nearly all unimportant): 1333, 1009, 959, 896, 1832, 1847, 2565, 2176, 2086 and many more
[14:14] <burek> which happened a lot with your tickets closure
[14:14] <cehoyos> They look very, very different from the tickets opened today.
[14:15] <cehoyos> The funny thing is: Don't you realize that your are the only "user" that constantly opens tickets that nobody can work on / that Michael and Clement misunderstand?
[14:15] <burek> just to reply to your complaints about ffserver, i really don't have the same environment, since we had that machine completely reformatted and we now use the completely different thing on it, so I can't reproduce exactly the same compiled version of ffserver + webcam input + alsa version
[14:15] <cehoyos> It surprisingly happens usually with tickets opened by you: Are you really sure that is only my fault?
[14:15] <burek> i didn't say that just to bounce you off
[14:16] <michaelni> there are multiple people whos reports i dont understand
[14:16] Action: ubitux is known for not understanding much things TBH
[14:16] <cehoyos> There is not alsa in this ticket, please stop claiming this!
[14:16] <burek> oh man, let me check that ticket again..
[14:17] <burek> also, this: In the years since, he opened a very large number of tickets, not only "ideas". Many of them lacked nearly all information to reproduce and this week, two long-term developers completely failed to understand the tickets (costing them a lot of time).
[14:17] <burek> did you really not see they didn't read the issue as a feature request
[14:17] <burek> so they failed to understand it's an unimplemented feature
[14:17] <burek> rather than me having anything to do with that?
[14:18] <cehoyos> For the two tickets in question, you both did not just not understand the tickets, you both completely misunderstood them in a way that made you (at least in the case of Clement) "work" on them for some time without any chance to succeed because what you were working on was not what the ticket was about.
[14:18] <cehoyos> burek: Who is "they"?
[14:18] <cehoyos> Sorry, the developers.
[14:18] <burek> "two long-term developers"
[14:18] <ubitux> note that having a trace of closed random feature request is cool as a reference, so the ticket can be pointed out to users requesting it; "go ahead, feel free to re-open this ticket"
[14:19] <ubitux> which is nicer than "please fill a ticket with your request but it will be likely closed"
[14:19] <cehoyos> This was not the important part of the sentence: The important part is that you wrote several times that you do not "want" (sorry if this is not the right word, I am not a native speaker) to add the information, we should search for it.
[14:19] <ubitux> so burek just have to take the burden of having his tickets closed :p
[14:20] <burek> 228 is the ticket that had its first reply after a year and a half
[14:20] <burek> see the history
[14:20] <cehoyos> And I already explained why, see above
[14:21] <burek> and given that i was a novice user back then, i didn't provide the full output log, so i had no way of knowing how to exactly reproduce the same thing after a year and a half
[14:21] <burek> is that answer good enough to close that ticket finally?
[14:21] <cehoyos> And yes, I am willing to search for the commit that fixed the ticket (as I did on many reports), but so far, I failed to reproduce (probably because contrary to you I don't really know how to use FFserver)
[14:21] <burek> im just trying to say i wasnt telling you i dont want to give you more details
[14:21] <burek> i just hadnt had a way to do that
[14:22] <cehoyos> And the reason for my anger about this ticket is not that you don't know how to reproduce anymore but that you claimed it is impossible because of the "environment"
[14:22] <cehoyos> That was of course not 228, but another ticket that I did not want to search, I'll do it now.
[14:23] <ubitux> burek: there is an important things; developers need to be able to reproduce the bugs easily, or have access to enough information to guess the problem, otherwise the ticket will just rot open and will just stand there because no one can really look at it
[14:23] <ubitux> burek: and the best way to deal with that is IMO to close it and wait for someone with more information to re-open it when necessary
[14:24] <cehoyos> For example ticket 2357
[14:24] <cehoyos> (A particular good example, first because I wasn't the only one pissed off and because you claimed you had given a link when you had not.)
[14:25] <ubitux> burek: and in this situation, i believe it's *good* to have that ticket, *and* having it closed
[14:25] <ubitux> but that's just my opinion :p
[14:25] <burek> cehoyos, honestly.. one mistake and you claim all that above on that ticket?
[14:25] <burek> just because i pasted a wrong url?
[14:26] <cehoyos> You honestly want me to search for more tickets from you that are missing all information? Sorry, I spend my time with a lot of useless things, but there are limits.
[14:26] <burek> ubitux, it's ok, im used to it, so its amuzing to me really :) im just saying all that because people from the forum have ranted on me for sending them on the trac where they were "welcomed" like that :)
[14:26] <cehoyos> And again: No, the problem was not the broken link, the problem was that you claimed you had given all information and that you refused to add more.
[14:27] <burek> cehoyos, you might be paranoid of some sort..
[14:27] <cehoyos> ubitux: See, that is exactly what I mean!
[14:27] <burek> you keep saying things that are not present in those tickets you provide..
[14:27] <cehoyos> Could you elaborate: I believe I did not understand the last sentence.
[14:28] <burek> like for example now, you say that i've said "you claimed you had given all information and that you refused to add more." when in fact i said: I'm not experiencing this issue, I'm just relaying the forum post. Please read it.
[14:28] <burek> what's your point exactly?
[14:28] <ubitux> cehoyos: i guess you could just try to sound nice when closing it so it doesn't sound like "FFmpeg dev are angry at users reporting bugs"
[14:29] <cehoyos> I am only angry at burek because it "amuses" him to distract FFmpeg developers.
[14:29] <burek> no, you amuze me, with your attitude :)
[14:29] <burek> other people normally explain what they mean
[14:29] <burek> only you consider yourself self-explanatory with whatever you do
[14:29] <cehoyos> burek: Again, this is exactly my point: Do not open tickets that you cannot reproduce (except if there is a technical reason, but that is not the case here)
[14:29] <burek> that's what amuzes me
[14:30] <burek> and this is the reason why i said earlier i should stay off the trac
[14:30] <burek> this became personal actually and it's best to calm everything down
[14:30] <cehoyos> burek: Could it be that I tried for several tickets to explain to you which information is necessary, but because it amuses you so much, you decided not to add this informaiton in later tickets?
[14:31] <burek> name one?
[14:31] <cehoyos> 445
[14:32] <cehoyos> 446
[14:33] <burek> ?
[14:33] <burek> what about 445?
[14:33] <burek> i provided you with what you asked
[14:33] <cehoyos> 614
[14:33] <burek> 446 also contains full output log
[14:33] <burek> what is your point actually?
[14:33] <cehoyos> But not when you opened tickets later, on the contrary, you first asked why it is not fine to post tickets with network input to find out later that even Michael doesn't understand such reports.
[14:34] <cehoyos> My point is that in this discussion here you have claimed several things that are plain wrong
[14:34] <cehoyos> I asked you to add information in 445, you added it
[14:34] <cehoyos> I asked you to add information in 446, you added it
[14:34] <burek> then why didnt you explain these things to me and told me what exactly was wrong, so i could fix it and maybe provide a better output?
[14:34] <cehoyos> I asked not to use external libraries in 614
[14:35] <burek> instead of just closing the ticket
[14:35] <cehoyos> I asked - definitely - again and again not to use network input for issues that are reproducible with file input
[14:35] <cehoyos> How did you open later tickets: Without information, using external libraries, using network input
[14:36] <burek> well im not a trac master as yourself so i didnt read numerous of your replies where you "again and again" said something
[14:36] <cehoyos> And now you claim I started not to be nice to you when closing tickets opened by you
[14:36] <cehoyos> And that is my fault??
[14:36] <burek> you could have just copy/paste some frequent requirement
[14:36] <burek> instead of just closing tickets and pissing people off
[14:36] <burek> not giving an explanation for it
[14:37] <cehoyos> Please note that here on irc, I was repleatedly accused of copy/pasting my messages (which isn't true, I like writing), and that I should stop doing this;-)
[14:37] <cehoyos> It is really very, very easy:
[14:37] <burek> you're justing making all this intentionally confusing to show myself as an ignorant person who deliberately pisses you off, when in fact that's a complete nonsense
[14:38] <burek> just*
[14:38] <cehoyos> Unfortunately, this discussion gives absolutely no indication that it is nonsense=-(
[14:38] <burek> if i pissed you off, that was usually because you were ignorant to spend a few lines explaining what pissed you off and what is missing in a ticket
[14:38] <cehoyos> (although I would of course love that to be true)
[14:39] <cehoyos> So I was ignorant in 445, 446 and 614? You just said, I should have copy/pasted what I wrote there, so I don't understand...
[14:39] <burek> well, we covered that there was nothing wrong with 445 and 446
[14:39] <burek> you asked for more info, i provided, you closed the tickets
[14:40] <cehoyos> Please remember that I wrote you several emails via pm: I told you how important samples are, but we still don't have the sample from ticket 2587
[14:40] <burek> actually 445 provided michaelni with enough info to fix the issue
[14:40] <burek> which really makes me wonder what's your point with 445?
[14:41] <cehoyos> I asked you to tell the user with the drm problem that we cannot / do not support drm for numerous reasons, you convinced him to open a ticket and managed to have me in a light were I am not helpful
[14:41] <burek> there is no DRM word in 445?
[14:41] <cehoyos> The point is that you claimed above I never asked for "more information" but I was always closing tickets opened  from the beginning, which is  not true
[14:42] <cehoyos> And yes, 445 is not the drm ticket, this is another ticket (I suspect it was the one when I started to close tickets from without asking for more information)
[14:42] <burek> what is your point with 445?
[14:43] <cehoyos> I asked for more information, you gave, you later opened other tickets with missing information, I asked again, after some time I stopped asking. You claimed above that I had this attitude from the beginning which is not true
[14:44] <cehoyos> Sorry, I have to work on "real" (read: reproducible reports) tickets now (2623: Wow, this is a very good example for a ticket that I did not close although it was missing all information)
[14:44] <cehoyos> and this one is a little difficult for me
[14:45] <burek> well, have fun, and as i said, this lost its meaning a long time ago, but i hope you got some amuzing time as well now :) so i guess we might call it even from now on
[14:47] <cehoyos> Why even?
[14:48] <burek> oh man.. never mind.. :beer: :)
[15:02] <cehoyos> michaelni: Should the fix for 2538 get backported?
[15:09] <burek> let me ask here
[15:10] <burek> what is needed to create an "official" ppa for ubuntu packages of ffmpeg
[15:11] <cehoyos> Do you mean a ppa on your (or another FFmpeg-friendly) server that is listed on some collection of ppa's?
[15:11] <ubitux> cehoyos: we want to replace the jon's ppa for ubuntu
[15:11] <ubitux> because they are too out-dated
[15:11] <cehoyos> Sounds like a good idea, but is there anything "official" about them?
[15:12] <ubitux> we link to them
[15:12] <ubitux> in the download page
[15:12] <ubitux> so a bunch of users are sticked with 0.10
[15:12] <cehoyos> Yes, I understand, I just wasn't sure if "official" meant "FFmpeg-official" or "Ubuntu-official"
[15:13] <ubitux> ppa isn't really "official" in the ubuntu sense afaik anyway
[15:13] <cehoyos> That was my question
[15:28] <michaelni> cehoyos, if the fix (they are 2 commits) applies cleanly and works sure backport is a good idea
[15:33] <cehoyos> 2625 is a regression and fixed in current git head, so I ask the same question again soon;-)
[15:33] <cehoyos> *will
[15:54] <SATALIN> hi, who know haw i can play and save to local storage my stream  with use ffmpeg??
[15:57] <ubitux> this is the development channel, not for user support
[15:57] <ubitux> and please don't ask op in private, you're not favored over other users, unless you want to pay
[15:57] <ubitux> also, your question is too vague to expect any answer
[16:00] <SATALIN> ubitux: ok, sorry but i develop on java using native ffmpeg and  it very importent for me
[16:00] <ubitux> this is for FFmpeg development, not API usage
[16:02] <SATALIN> very tnx, tp
[16:02] <cehoyos> michaelni: Is it ok to backport 1ef82cc to fix ticket 2625 ?
[16:06] <SATALIN> ðóññêèå åñòü?
[16:35] <cone-746> ffmpeg.git 03Paul B Mahol 07master:379ad9788b80: tiff: planar rgb
[16:47] <cehoyos> durandal_1707: Does compilation succeed for you?
[16:49] <durandal_1707> it doesn't?
[16:51] <cone-746> ffmpeg.git 03Carl Eugen Hoyos 07master:a4b5863eeac0: Fix compilation of libavcodec/tiff.c
[16:52] <cehoyos> It hopefully does now
[16:52] <cehoyos> (I did not run fate either)
[16:53] <michaelni> cehoyos, 1ef82cc should be ok to backport if it works
[16:55] <cone-746> ffmpeg.git 03Claudio Freire 07release/0.10:dfcf910569e7: AAC encoder: Fix rate control on twoloop.
[16:55] <cone-746> ffmpeg.git 03Claudio Freire 07release/0.11:f6bca606f176: AAC encoder: Fix rate control on twoloop.
[16:55] <cone-746> ffmpeg.git 03Claudio Freire 07release/1.0:be66531ee27c: AAC encoder: Fix rate control on twoloop.
[16:55] <cone-746> ffmpeg.git 03Claudio Freire 07release/1.1:c320f9f5e998: AAC encoder: Fix rate control on twoloop.
[16:55] <cone-746> ffmpeg.git 03Michael Niedermayer 07release/1.2:f2361593ca1b: mpegvideo: implement ff_put_h264_chroma_mc1 & ff_avg_h264_chroma_mc2
[16:55] <cone-746> ffmpeg.git 03Claudio Freire 07release/1.2:9af68f8d1f3d: AAC encoder: Fix rate control on twoloop.
[16:55] <cehoyos> michaelni: Tested and pushed, thank you. lowres 3 on arm applied cleanly to 1.2, I am uncertain if it should be applied to older branches.
[17:03] <cehoyos> BuxiNess: Hi, do you want to investigate ticket 2612? And I believe Michael sent a patch for you to review;-)
[17:03] <cehoyos> The one with the "small" perfomance improvement iirc
[17:24] <cone-746> ffmpeg.git 03Paul B Mahol 07master:2e67dde954d0: tta: move code that will be shared with encoder to separate file
[17:24] <cone-746> ffmpeg.git 03Paul B Mahol 07master:514cb9bb9281: tta encoder
[17:43] <BuxiNess> hi I'll review 2612, and interesting patch also!
[18:17] <wm4> ubitux: where does the subtitles iconv stuff live? or am I not remembering correctly that there was some support for setting encoding
[18:18] <ubitux> avctx->sub_charenc
[18:18] <wm4> oh, so it's only in the decoders
[18:18] <ubitux> yes it's done before decoding
[18:18] <ubitux> charset convert is done on the packet data
[18:19] <ubitux> before sending it to the decoder
[18:19] <wm4> also there are things like utf-16 .ass files
[18:19] <wm4> (libass and mplayer's subreader.c can read these if codepage is provided)
[18:19] <ubitux> yes, we don't support it at demuxer level yet
[18:20] <ubitux> because our subtitles demuxers are assuming ascii compliant
[18:20] <ubitux> we need to do the decoding pre-demuxing too
[18:20] <ubitux> basically, you need to add a mode in sub_charenc_mode
[18:21] <ubitux> (currently there is do_nothing, auto and pre_decoder)
[18:21] <wm4> well, it would have to be in libavformat, no?
[18:22] <ubitux> yeah, right
[18:22] <wm4> but you could probably get away with adding support for just urf-16 (since everything else follows ascii for 7 bit)
[18:23] <ubitux> it doesn't make this simpler
[18:23] <wm4> I think detecting utf-16 is quite simple and reliable (unlike other encodings)
[18:24] <ubitux> there is a probing issue too
[18:24] <wm4> yes
[18:25] <wm4> pre-decoding conversion might still be needed, though
[18:25] <wm4> there might be insane container formats which don't use utf-8
[18:25] <wm4> for subs
[18:26] <ubitux> i think i got once a sami file in utf-16 too
[18:26] <wm4> actually mplayer's subreader.c autodetects
[18:27] <wm4> one user had a problem with ass files not showing formatting, and it turned out it was because libass didn't read the utf-16 file, but subreader.c did :)
[18:27] <wm4> that was confusing
[19:15] <cone-746> ffmpeg.git 03Michael Niedermayer 07master:636c2dd4389d: avutil/sha: reorder Maj arguments
[19:27] <wm4> ubitux: I don't get why ass conversion decoders add a style but not playresx/y
[19:33] <wm4> for some formats it doesn't really matter (except for the ugly warning libass will print), but decoders which will print \pos this really should be added
[19:46] <ubitux> maybe because we don't have that information
[19:47] <ubitux> i suppose
[20:02] <wm4> ubitux: well, how did you test the microdvd tags then?
[20:02] <wm4> I mean it must be using some resolution, whether it's a fixed one or the video resolution
[20:08] <wm4> ubitux: and the style is not really needed... libass has a default style AFAIK
[20:10] <ubitux> i don't remember having issues testing the microdvd tags
[20:10] <ubitux> but it's been a while now
[20:11] <wm4> libass sets a default script resolution
[20:12] <wm4> and outputs a message like "[ass] Neither PlayResX nor PlayResY defined. Assuming 384x288"
[21:09] <wm4> ubitux: do you plan to make the subtitle decoders output the matroska packet format too?
[21:09] <ubitux> it would be nice
[21:09] <ubitux> but that might be a little tricky
[21:09] <wm4> yeah, this will cause trouble because of the readorder field
[21:10] <ubitux> the main problem is the multiple lines from SSA packets
[21:11] <ubitux> (one packet ’ multiple decode)
[21:11] <ubitux> backward compat & friends, you know the story
[21:11] <wm4> in my opinion the main problem is seeking
[21:12] <wm4> because I don't want to flush the already added subtitles on seeking
[21:13] <ubitux> also, i would like to have more bitmap subtitles format, and possibly support for teletext before starting to change the subtitles api
[21:14] <ubitux> (so we can have a maximum of use case to avoid changing it 10 times)
[21:14] <ubitux> but the most important thing right now would be to have subtitles in lavfi :(
[21:15] <ubitux> it would unleash so much possibilities...
[21:15] <ubitux> unfortunately it means quite some changes in api, and again, you know the story
[21:15] <wm4> if that happens, subtitle converters should probably be filters
[21:17] <ubitux> ??
[21:17] <ubitux> you mean text <-> bitmap?
[21:17] <wm4> no, text<->text
[21:17] <ubitux> :/
[21:18] <wm4> it would be natural
[21:18] <ubitux> lavfi will receive decoded subtitles
[21:18] <wm4> and text<->bitmap would fit in naturally as well
[21:18] <ubitux> and output decoded subtitles
[21:18] <ubitux> just like audio & video
[21:19] <ubitux> and there is no convert to do to decoded subtitles
[21:21] <wm4> not sure why you disagree
[21:21] <wm4> lavfi has a lot of strange filters, like turning audio into images of waveforms
[21:21] <wm4> converting subtitles is much closer to converting pixel formats or so
[21:21] <wm4> so it seems to fit rather well as filter
[21:21] <wm4> unlike as decoders
[21:22] <ubitux> the convert is already done by our "convertion" system
[21:22] <Daemon404> [15:21] <+wm4> so it seems to fit rather well as perl script
[21:22] <Daemon404> ftfy
[21:22] Action: Daemon404 runs
[21:22] <ubitux> lavfi will help hardsubbing easily
[21:23] <ubitux> or making various treatement to the color of bitmap subtitles
[21:23] <ubitux> that sort of things
[21:23] <wm4> system("echo " + subtitle_data " + | yourscript");
[21:23] <Daemon404> mostly what i intend to use it for
[21:23] <Daemon404> is converting things to webvtt
[21:23] <ubitux> but to integrate subtitles properly in lavfi, you have to follow the same model as audio & video
[21:23] <Daemon404> and nothing more
[21:23] <ubitux> aka feed it with decoded subs
[21:23] <wm4> uh
[21:23] <ubitux> Daemon404: only demuxing (and partial decoding) is supported by webvtt 
[21:24] <ubitux> by ffmpeg*
[21:24] <wm4> your "decoded" subs are not much different from unencoded subs
[21:24] <Daemon404> so far.
[21:24] <wm4> err, undecoded
[21:24] <ubitux> they are completely different IMO
[21:24] <wm4> ubitux: btw. it appears smi is popular in korea
[21:24] <ubitux> they have a common markup, which is pretty relevant
[21:24] <wm4> because it can do ruby or something
[21:24] <wm4> and ass can't
[21:24] <Daemon404> wm4, and china
[21:24] <Daemon404> SAMI~
[21:24] <ubitux> webvtt also has ruby, and we don't support it
[21:25] <Daemon404> webvtt has inline css
[21:25] <Daemon404> so there's that
[21:25] <wm4> so you need a html renderer?
[21:25] <wm4> vf_webkit when?
[21:25] <Daemon404> :D
[21:25] <ubitux> you need a different rasterizer than libass yes
[21:25] <wm4> (it could decode video too)
[21:25] <Daemon404> wm4, or vf_blink
[21:25] <ubitux> and that's where having subtitles in libavfilter will help
[21:25] <wm4> we could also hack ruby into libass
[21:25] <Daemon404> wm4, i think baptiste did exactly that
[21:25] <Daemon404> for hulu
[21:26] <wm4> ubitux: are you still pursing your subtitle AST idea?
[21:26] <wm4> Daemon404: wtf
[21:26] <ubitux> wm4: i don't know, i'm busy with tons of other things
[21:26] <ubitux> and i was hoping for some help from nicolas but he doesn't seem much motivated anymore
[21:27] <ubitux> subtitles really are a pita
[21:27] <Daemon404> ubitux, maybe that google guy will
[21:27] <Daemon404> (lol yeah right)
[21:27] <ubitux> Daemon404: yeah :D
[21:27] <ubitux> i would love to
[21:27] <wm4> so is webvtt supposed to be embedded in webm?
[21:27] <Daemon404> no
[21:27] <ubitux> yes they wrote a draft for that
[21:27] <Daemon404> oh?
[21:28] <Daemon404> i thought it was always a separate tag
[21:28] <Daemon404> in html5
[21:28] <wm4> so you can click links and shit in your video player?
[21:28] <Daemon404> wm4, when they webvtt people showed off webvtt at VDD in 2012
[21:28] <Daemon404> it crashed 2 of 3 browsers iirc
[21:28] Action: ubitux is waiting for embedded gif or webm into your webvtt subs in webm
[21:28] <wm4> awesome
[21:28] <Daemon404> and didnt render right in any
[21:28] <wm4> progress
[21:28] <Daemon404> aybe it was 1 of 3
[21:29] <Daemon404> ubitux, all i can think of is niconico
[21:29] <Daemon404> and its horrible comments flying over the video
[21:29] <Daemon404> The Future.
[21:29] <ubitux> :D
[21:29] <ubitux> well having subtitles into webm will be quite nice
[21:29] <Daemon404> i still think webvtt is on crack
[21:29] <Daemon404> for allowing css
[21:29] <ubitux> ah sure, we agree on that :)
[21:30] <wm4> why not use srt
[21:30] <Daemon404> webvtt IS srt
[21:30] <wm4> I'm even fine with the pseudo-html tags in it
[21:30] <Daemon404> a subset of it
[21:30] <ubitux> not xml-based!!!
[21:30] <Daemon404> with css.
[21:30] <wm4> ok then we can just hope it becomes a failure (and fortunately that's likely)
[21:30] <Daemon404> i dunno
[21:30] <ubitux> no it will be used
[21:30] <Daemon404> we're planning to support it
[21:30] <Daemon404> and so is youtube obviously
[21:31] <wm4> then fuck
[21:31] <ubitux> the main problem is the rendering
[21:31] <wm4> webkit
[21:31] <ubitux> because players rely on... libass to render every subs
[21:31] <Daemon404> brb adding webkit support to vsfilter
[21:31] <wm4> i'm probably not even joking
[21:31] <ubitux> wm4: that will be possible when subtitles are in libavfilter
[21:31] <ubitux> "cleanly"
[21:31] <ubitux> hopefully
[21:32] <Daemon404> ubitux, i look forward to 100 mb static linked ffmpegs
[21:32] <Daemon404> with webkit
[21:32] <ubitux> :D
[21:32] <wm4> fortunately I've fucked up the mplayer core enough that I can support this now
[21:32] <ubitux> wm4: btw, so about the AST thing
[21:32] <ubitux> wm4: you would propose a FF markup in text instead?
[21:33] <ubitux> (so potentially extendable to any markup)
[21:33] <wm4> actually I think it might be the best not to have an "universal" format
[21:33] <wm4> just like we don't have universal pixel formats or sample formats
[21:33] <ubitux> we have rawvideo.
[21:33] <ubitux> and raw audio (pcm)
[21:33] <ubitux> well, we *need* a universal format, at least internally
[21:33] <ubitux> because that's the only way to do convertion
[21:34] <wm4> then how does the universal format handle bitmap subs? *troll*
[21:34] <ubitux> and well having a FF markup can solve quite some issues, and that's easier than the AVStyledSubtitles API i was suggesting
[21:34] <ubitux> wm4: i'm talking about text-based only, and eventually teletext/closedcaptions
[21:35] <wm4> having N formats with N=2 or so won't be a problem, you only need N^2-N converters
[21:35] <ubitux> currently the "common" format is SSA
[21:35] <ubitux> and we reach the limits
[21:35] <wm4> because I can predict that the "universal" format will be horrible, no matter how well designed
[21:36] <wm4> for reference, ASS and webvtt are already horrible
[21:36] <ubitux> yes
[21:36] <ubitux> webvtt can definitely not be our internal representation
[21:36] <ubitux> ass is a bit too limited
[21:36] <ubitux> extending it is not IMO a good idea
[21:37] <ubitux> having a "ffmpeg dialect" for ass will only bring hater
[21:37] <ubitux> styled subtitles (the !text C-structure abstraction project) is one solution
[21:37] <ubitux> but possibly not really handy
[21:37] <ubitux> the other solution is indeed what you suggested a while ago
[21:38] <wm4> what?
[21:38] <ubitux> having a ffmpeg random markup for decoded subs
[21:38] <wm4> I think that's better than an AST in C
[21:38] <wm4> but then there's the sad story if mpsub
[21:39] <ubitux> keep in mind that the purpose is not to invent a new formats
[21:39] <ubitux> it's really mainly used for internal purpose, and eventually api users
[21:40] <ubitux> or people who want a single code to support every subtitles formats
[21:40] <ubitux> (and i don't plan to create a muxer for such markup)
[21:40] <ubitux> (and i think i will oppose to it as much as i can)
[21:40] <ubitux> so well yeah if you think that's a good idea i can work on that
[21:41] <ubitux> wm4: why do you think that's a better idea than the AST in C?
[21:45] <wm4> ubitux: it's human readable and extensible, and everyone knows how to manipulate text... on the other hand the C AST will be clumsy (especially wrt. to memory management and union access and such things), with a big API and hard to manipulate
[21:46] <ubitux> ok
[21:46] <ubitux> well then that's simpler for me
[21:46] <ubitux> i think i can use the AVSubtitles->text field for that :)
[21:47] <ubitux> (which is currently unused)
[21:47] <ubitux> or maybe it could be used for raw text without style
[21:47] <wm4> of course the format should be optimized for simple parsing & manipulation, and I'm not sure what exactly it would look like
[21:47] <wm4> btw. does Libav still demux srt with timecodes in the text?
[21:47] <ubitux> of course.
[21:48] <ubitux> ok so mmh
[21:48] <wm4> then I need to NIH a srt demuxer or something
[21:48] <ubitux> you already have one
[21:48] <ubitux> no?
[21:48] <wm4> only subreader.c
[21:48] <wm4> which is a POS
[21:49] <wm4> and also not a demuxer (separate code path for loading -sub files)
[21:51] <ubitux> you won't like the idea but you can just error out "unsupported by your libav{format,codec}"
[21:51] <wm4> yeah, no
[21:53] <ubitux> :)
[21:53] <ubitux> well you can rewrite everything present in ffmpeg if you want but well, that kill the purpose of what you are trying to do
[21:54] <ubitux> anyway so, for the internal string, let me think of something...
[21:55] <ubitux> you will love [TAG=key1=value1:key2=value2] right? :)
[21:55] <ubitux> reminds you something? ;)
[21:58] <wm4> ew
[21:59] <wm4> hm I see there's the problem of supporting arbitrary binary strings
[21:59] <wm4> unless you restrict them willingly
[21:59] <wm4> (stuff like font names)
[22:00] <wm4> ubitux: my main goal is cleaning up the mplayer shit, and make things a bit more cleaner and well working than before
[22:00] <wm4> exchanging subreader.c for a very small number of custom reimplemented sub demuxers sounds like a good deal
[22:01] <wm4> trying to get Libav pick up these changes is probably hopeless too
[22:03] <ubitux> well, there is quite some work about subtitles to port before using a subrip codec
[22:30] <ubitux> cehoyos: i'm not so fond of this ^
[22:30] <ubitux> ./configure --disable-filters --enable-filter=drawtext should error out
[22:32] <cehoyos> ubtiux: If you want to change configure (and afaict, this is a major change), then please do so, but this isn't related to drawtext or libfreetype but to how the configure script works (since forever), see for example ./configure --disable-demuxers --disable-zlib --enable-demuxer=mov
[22:32] <ubitux> yeah well maybe a ticket rename would have been more appropriate
[22:33] <cehoyos> Sorry, wrong example (another one to follow).
[22:34] <cehoyos> ./configure --disable-decoders --disable-zlib --enable-decoder=dxa
[22:39] <michaelni> BuxiNess, more jpeg2000 patches on ffmpeg-devel to review ...
[22:40] <ubitux> "Tha fate tests"
[22:41] <ubitux> michaelni: is the second patch any faster?
[22:48] <ubitux> microchip_: complete ffmpeg output missing, cehoyos will get mad at you
[22:48] <microchip_> well, i'll edit it
[22:49] <ubitux> also, you should add a sample
[22:49] <ubitux> or provide a way to generate one
[22:49] <michaelni> ubitux, 2nd should be faster too yes
[22:49] <ubitux> michaelni: testsrc and aevalsrc are your friends
[22:49] <ubitux> arh microchip_ ^
[22:49] <ubitux> michaelni: ok :)
[22:49] <cehoyos> michaelni: Concerning ticket 1182, the avi sample was cut and contains no index, does that mean the "frame sync error" message (and the broken video frames because of seeking to a non-keyframe) are expected and can only be fixed by remuxing?
[22:50] <ubitux> BuxiNess: START_TIMER / STOP_TIMER?
[22:50] <microchip_> ubitux: use any sample with -vf fps and you'll hear no sound
[22:51] <ubitux> microchip_: i have some sound here.
[22:51] <microchip_> nothing here and i tested with mplayer, vlc and xine
[22:52] <cehoyos> icrochip_: Please provide a sample or explain how to produce one as explained by ubitux
[22:53] <ubitux> microchip_: works pretty fine here
[22:53] <ubitux> at least with my sample
[22:53] <microchip_> cehoyos: strange, if i use -f dvd, i have sound. Without it, i don't
[22:54] <microchip_> hmm
[22:54] <BuxiNess> michaelni, cool again
[22:54] <ubitux> microchip_: can you share your input to start with?
[22:54] <ubitux> microchip_: and then your output eventually
[22:54] <BuxiNess> boring work to finish tonight, i'll review it tomorrow
[22:55] <BuxiNess> ubitux, ok i'll try that
[22:55] <microchip_> ubitux: sure, in here or in the bug report?
[22:56] <ubitux> microchip_: better in the bug report, but i don't mind testing right away if you share here
[22:56] <microchip_> ubitux: ftp://teambelgium.net:8082/pub/jlo_sample.mpg
[22:56] <cehoyos> microchip_: Please post all information related to tickets (and especially the information necessary to reproduce a ticket) inside the ticket, only use external resources for sample files
[22:56] <microchip_> cehoyos: ok
[22:57] <microchip_> cehoyos: if i use -f dvd, i have sound. Without it, no sound :S
[22:57] <cehoyos> microchip_: ==> PASV ... couldn't connect to 192.168.0.240 port 30014: No route to host
[22:57] <microchip_> not sure what's going on
[22:58] <michaelni> cehoyos, concerning 1182, i dont know, the warning is expected, maybe theres some trick to avoid it but is that warning a problem at all ?
[22:58] <cehoyos> The warning is the ticket...
[22:58] <ubitux> microchip_: i have sound
[22:58] <microchip_> hmm
[22:58] <microchip_> ubitux: even without -f dvd ?
[22:58] <ubitux> i copy pasted your command
[22:58] <ubitux> changing the sample with the one you provided
[22:58] <microchip_> ok
[22:58] <ubitux> do you have sound with ffplay at least?
[22:59] <microchip_> i guess then it's invalid report, cehoyos you can close it
[22:59] <microchip_> ubitux: no
[22:59] <ubitux> well it should play
[22:59] <ubitux> and that is very weird if it doesn't
[22:59] <ubitux> just to be sure
[22:59] <ubitux> i used: ./ffmpeg -i ~/samples/jlo_sample.mpg -c:v mpeg2video -b:v 3500k -c:a ac3 -b:a 192k -vf fps=fps=29.970 -y out.mpg
[22:59] <cehoyos> Contrary to what everybody seems to believe here, I prefer to understand what is going on before closing a ticket: Could you upload the sample somewhere?
[22:59] <cone-88> ffmpeg.git 03Michael Niedermayer 07master:de488525e593: tools/ffeval: Check return value of av_expr_parse_and_eval()
[22:59] <cone-88> ffmpeg.git 03Michael Niedermayer 07master:c1075d6af72c: tools/ffhash: close file handle on error
[22:59] <microchip_> oh, i have an old ffplay, i just saw :(
[23:00] <microchip_> cehoyos: sure, one moment
[23:00] <ubitux> ah yeah well make sure your players are using ffmpeg
[23:00] <ubitux> :)
[23:02] <microchip_> cehoyos: https://mega.co.nz/#!jJIQ3AZI!Iocptgt40WI9UHC8wwYpaEC4B2NPiAscH-gb_5jkJhM
[23:09] <cehoyos> microchip_: For which ffplay version does playback of the output file fail (no sound)?
[23:09] <microchip_> cehoyos: didn't test with ffplay yet, only with mplayer, vlc and xine
[23:09] <cehoyos> [22:59] <microchip_> ubitux: no <-- ??
[23:10] <microchip_> cehoyos: it's an old ffplay which segfaults
[23:10] <cehoyos> Which version segfaults?
[23:10] <ubitux> well upgrade your ffplay?
[23:10] <ubitux> mplayer works fine here
[23:10] <microchip_> cehoyos: have to recompile ffmpeg as i don't have ffplay from git (my current ffmpeg version)
[23:10] <cehoyos> Which version segfaults?
[23:11] Last message repeated 1 time(s).
[23:11] <microchip_> cehoyos: the old ffplay from 1.0.6
[23:11] <microchip_> cehoyos: don't worry about that, i know why it segfaults
[23:11] <microchip_> "library configuration mismatch"
[23:12] <ubitux> mpegts muxer needs more love :(
[23:13] <cehoyos> microchip_: ffplay 1.0.6 works fine here with out.mpg
[23:13] <cehoyos> ubitux: How is this related to the mpegts muxer?
[23:14] <ubitux> it was off topic
[23:14] <cehoyos> ubtiux: How is the bug in MPlayer's mpeg demuxer related to FFmpeg's mpegts muxer?
[23:14] <cehoyos> Sorry.
[23:14] <ubitux> i was sad looking at https://ffmpeg.org/trac/ffmpeg/ticket/2622
[23:14] <cehoyos> But you are certainly right
[23:14] <ubitux> and then i clicked the mpegts keyword
[23:14] <ubitux> and then i was even more sad :(
[23:15] <ubitux> and then i remembered the project name :(
[23:15] <cehoyos> I don't think many of the open mpegts tickets are muxer related.
[23:15] <ubitux> and so sadness became sorrow
[23:15] <ubitux> dunno
[23:16] <cehoyos> The problem with the muxer - iiuc - is that it does not always produce valid streams but stream analyzers are expensive and people with stream analyzers are not very interested in working on FFmpeg (afaiu).
[23:16] <ubitux> it's just sad :(
[23:16] <ubitux> well
[23:16] <cehoyos> Many of them are either: H264 timestamp bug or broken / half-broken mpegts samples
[23:16] <ubitux> if it could at least work for ff* that would be good enough for a start :)
[23:17] <cehoyos> And I just realize: The two or three "desync on ts" tickets are also h264 timestamp issues (afaict)
[23:18] <cehoyos> Or in other words: The "real" problems are not on trac ;-(
[23:18] <cehoyos> Except maybe 912 but that does not help either!
[23:19] <cone-88> ffmpeg.git 03Michael Niedermayer 07master:69ce34c796dd: tools/qt-faststart: Fix unintended sign extension of atom_size
[23:19] <cone-88> ffmpeg.git 03Michael Niedermayer 07master:582f36ca3fb1: tools/qt-faststart: Fix unintended sign extension of current_offset
[23:22] <cehoyos> microchip_: It should be possible to test with WMP, I don't remember atm in which cases it accepts program streams from FFmpeg
[23:23] <cehoyos> (Or a DVD hardware of course)
[23:23] <microchip_> cehoyos: i'll try tomorrow, now i go to bed :)
[23:24] <cehoyos> ubitux: What is the default demuxer of your MPlayer version for program streams?
[23:25] <ubitux> ah my bad i indeed have no sound with that mplayer
[23:26] <cehoyos> works with -demuxer lavf
[23:26] <cehoyos> Could you test -psprobe ?
[23:26] <ubitux> ?
[23:26] <cehoyos> I suspect it could work with mplayer -psprobe
[23:26] <cehoyos> s/could/should
[23:26] <cehoyos> (but not svn=
[23:26] <cehoyos> (but not svn)
[23:27] <ubitux> doesn't helpp
[23:27] <ubitux> you can't test?
[23:28] <cehoyos> I test svn, I guess / remember you don't have svn
[23:28] <ubitux> SVN-r36285-4.8.0
[23:29] <cehoyos> Sorry, that was a misunderstanding: Does it work with the player that you normally use?
[23:29] <ubitux> yes
[23:29] <cehoyos> And that one is using the native demuxer?
[23:29] <cehoyos> And that one is not using lavf by default?
[23:29] <ubitux> mplayer2 and mpv are using lavf
[23:30] <ubitux> that's why it works
[23:30] <cehoyos> And is there a -demuxer mpegps ?
[23:30] <ubitux> yes and i get no sound when using it in mplayer2
[23:31] <ubitux> though, --demuxer=mpegps in mpv actually works
[23:31] <ubitux> but maybe that's a bug ;)
[23:31] <cehoyos> I C
[23:31] <ubitux> wm4: can you confirm --demuxer=mpegps actually use mpegps demuxer, or lavf?
[23:32] <cehoyos> The console output should look quite different
[23:32] <wm4> ubitux: it should, look what it says in the line with "Detected file format: "
[23:32] <ubitux> it shows lavf
[23:32] <ubitux> but i have an old mpv here, possibly fixed
[23:32] <ubitux> 'going to update
[23:33] <wm4> can you post full and uncut console output?
[23:33] <ubitux> wm4: sure, http://pastie.org/7998133
[23:34] <ubitux> you should print the version by default btw
[23:34] <wm4> not sure how that happened
[23:34] <ubitux> maybe you want a -v output?
[23:34] <ubitux> i'm upgrading anyway
[23:35] <wm4> but I don't quite remember the semantics of -demuxer anyway, maybe it tries other formats if one fails definitely
[23:45] <ubitux> still using lavf with the latest
[23:51] <wm4> ubitux: ok some "forgotten" code is forcing it to lavf
[23:51] <wm4> oops
[23:52] <wm4> since DVD uses mpegps and I made dvd playback use lavf
[23:53] <ubitux> i hope you fix that soon so i can break the playback of that mpeg file
[23:54] <ubitux> wm4: btw, i think using the key=value:key2=value2 thing for subtitles tags might not be such a bad idea, since we have a public parser for this iirc (into AVDictionary)
[23:58] <wm4> ubitux: ok should be fixed
[23:59] <wm4> ubitux: I think using the AVDictionary parser would negate the idea of a simple format, since then every user would have to duplicate all of the AVDictionary parser's bells and whistles
[23:59] <wm4> here's another messy idea: make the format a binary stream (but uh I actually don't like this)
[00:00] --- Mon Jun  3 2013