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

[burek]

[00:53] <cone-879> ffmpeg.git 03Andreas Cadhalpun 07master:d5e802609a00: doc: document the addition of the AVProbeData.mime_type field and it's implications
[00:53] <cone-879> ffmpeg.git 03Andreas Cadhalpun 07master:bcac0f401001: lavf/format.c: use AVPROBE_SCORE_MIME instead of AVPROBE_SCORE_EXTENSION for matching mime types
[01:32] <llogan> once again FFmpeg distracts me from my boring work and now I'm behind.
[01:33] <llogan> oh well. it's friday and I have a keg and liver to kill.
[01:34] <llogan> FFmpeg Dev Days at my dumpartment.
[08:21] <ux> erm do we really want the "Behaviour changes" section to document API changes?
[11:28] <pross> vp10: http://www.cnet.com/news/googles-web-video-ambitions-run-into-industry-reality/
[11:30] <wm4> maybe they should have written a spec after all
[11:30] <wm4> ""Our goal is to get codec development to Web speed," he said." wat
[11:31] <nevcairiel> google doesnt really care about wide-spread adoption, they are happy if they can use it to save bandwidth with youtube -> chrome/android :p
[11:32] <wm4> (that last code in combination with the intention to release a new codec all 2 years)
[11:32] <wm4> s/code/quote/
[11:32] <J_Darnley> How are they going to make video useful on a mobile without anytime for someone to make a HW decoder?
[11:33] <nevcairiel> phones are getting faster and faster every year, which also means energy requirements for software decoding are going down
[11:33] <J_Darnley> Perhaps this time they'll get their alpha channel correct.
[11:33] <pross> a new codec ever 18 months. quantity over quality :) its good to see the on2 monkeys are still running things
[11:34] <wm4> J_Darnley: did they decide yet which of the 3 methods to use?
[11:34] <J_Darnley> Although I have no idea why a video would want one.
[11:35] <pross> J_Darnley: gif successor
[11:36] <nevcairiel> i've actually seen that happen quite o ften recently, people starting to post small webm's instead of terrible-quality gifs
[11:38] <J_Darnley> I don't see why that requires an alpha channel.  All these gifa that should be videos are square.  Usually because that are from videos.
[11:39] <pross> VP10 will have spherical coordinate system :)
[11:39] Action: J_Darnley wonders WTF is going wrong with his typing lately.
[11:47] <rcombs> J_Darnley: it's useful within a production process
[11:49] <rcombs> e.g. for overlay animation
[11:50] <wm4> because video production will use lossy formats...?
[11:50] <J_Darnley> Don't you have a "pro" codec that for that?
[11:50] <rcombs> wm4: yes, actually
[11:50] <rcombs> but it's usually ProRes or similar
[11:51] <rcombs> the only use for alpha in video I can think of is& pre-rendered subtitle typesetting
[11:51] <rcombs> *consumer video
[12:17] <JEEB> lol at that VP10 article
[13:27] <ubitux> the article doesn't mention that unless you have the infrastructure of google you can't actually bench vp9 properly
[13:28] <ubitux> encoding 4k with libvpx? see you next year
[13:28] <ubitux> maybe they improved the performances since last time though
[13:28] <wm4> yeah, and practical HEVC encoders will be around much sooner than Vp9
[13:31] <JEEB> practical HEVC encoders are pretty much here now, even if x265 is crappy it has kind of climbed over the fence
[13:33] <cone-641> ffmpeg.git 03Michael Niedermayer 07master:8572dbc5dbeb: avcodec/ac3en: use FF_ALLOC(Z)_ARRAY()
[14:37] <ubitux> any idea when does the readorder really matters in ass muxed in mkv?
[14:37] <ubitux> for the rendering itself it shouldn't make any difference, right? (that's the purpose of layer)
[14:38] <ubitux> i suppose that's just in order to reconstruct the .ass file identically if necessary?
[14:38] <wm4> ubitux: it also matters for rendering... somehow
[14:38] <ubitux> how so?
[14:39] <ubitux> isn't Layer for that purpose?
[14:39] <wm4> if you have two events at the same times (same start/end TS), the one with the higher order is visible
[14:39] <wm4> sure you can use layer to disambiguate this
[14:39] <ubitux> mkv/ass has both
[14:40] <wm4> but you can still write a subtitle file that doesn't use layer and has such overlapping events
[14:41] <ubitux> mmh.
[14:41] <ubitux> ok.
[14:42] <wm4> not sure why it's stored in the file though
[14:42] <ubitux> ReadOrder is mkv specific
[14:42] <wm4> yes, but why does it have it
[14:43] <wm4> it's somewhat useful to eliminate duplicate events though
[14:43] <wm4> but in theory you wouldn't need it; you could recreate it on demuxing
[14:43] <ubitux> i would guess it's in order to reconstruct the original .ass
[14:43] <ubitux> typically if you stack OP,ED and then other events
[14:44] <ubitux> and if you want to reconstruct the original .ass not based on the ts but that original file order
[14:44] <wm4> oh right, muxing in mkv would force monotonic timestamps
[14:44] <ubitux> for esthetic purpose
[14:44] <wm4> while an ass file can arbitrarily shuffle them
[14:45] <ubitux> i'm trying to consider making the .ass demuxer outputs ASS packets (the mkv muxed form)
[14:50] <ubitux> saste: no opinion on the lavfi/ass patchset?
[14:51] <ubitux> michaelni: do we use that AV_LOG_LEVEL granularity somewhere else?
[14:51] <ubitux> i'm not exactly comfortable using that
[14:54] <wm4> what lavfi/ass patchset?
[14:55] <wm4> ubitux: for the libass log level thing, note that many log levels are rarely used or unused
[14:55] <wm4> I don't think trying to map them to libav* ones in an overly sophisticated manner will help with anything
[14:55] <ubitux> < wm4> what lavfi/ass patchset? // the 3 small patches you seem to have found just now
[14:55] <ubitux> wm4: that's my thought as well
[15:16] <cone-641> ffmpeg.git 03Clément BSsch 07master:d86cf4a91de2: avformat/vobsub: fix NULL dereference
[15:23] <michaelni> ubitux, dunno, but intermediate levels where definitly intended to be usable
[15:25] <ubitux> ok
[15:25] <ubitux> for ass that's hardly testable anyway
[15:25] <ubitux> these intermediate levels are not used so far
[15:32] <cone-641> ffmpeg.git 03Clément BSsch 07release/2.3:148d9cd12227: avformat/vobsub: fix NULL dereference
[15:34] <ubitux> olol just found a mkv in my samples that has the Dialogues with timestamps
[15:34] <wm4> ubitux: huh?
[15:35] <ubitux> mmh my bad
[15:36] <wm4> relief!
[15:36] <ubitux> yeah
[15:37] <ubitux> i was in my backport state
[15:37] <ubitux> where the demuxed was fucking the packets :p
[15:37] <ubitux> demuxer*
[15:39] <ubitux> ffprobe -show_packets -show_data e
[16:34] <ubitux> nice the latest notice from freenode
[16:42] <J_Darnley> If there is a breach perhaps that is a fake message which is now capturing password changes.
[16:44] <wm4> J_Darnley: nice one
[16:44] <J_Darnley> paranoia++;
[16:45] <J_Darnley> :)
[16:45] <J_Darnley> I changed my password anyway.  What can they get out of the old or new random strings?
[16:46] <JEEB> hm?
[16:46] <J_Darnley> If you didn't get the message...
[16:46] <JEEB> oh
[16:47] <J_Darnley> [Sat 16:33] -tomaw- [Global Notice] Earlier today the freenode infra team noticed an anomaly on a single IRC server. We have identified that this was indicative of the server being compromised by an unknown third party.
[16:47] <JEEB> finally found it in the backlog of #ffmpeg
[16:47] <JEEB> xchat being useful and pushing notices from servers to a random channel's log
[16:47] <J_Darnley> I won't bother with the rest for now
[16:47] <wm4> JEEB: not hexchat?
[16:48] <J_Darnley> Yeah, mIRC isn't any better.  My message was in #lua
[16:48] <JEEB> no, not hexchat. I'm using the official builds due to a moment of rage back in '07 or so
[16:48] <JEEB> when I actually went and bought a license for it
[16:49] <Case> J_Darnley: I'm sure mirc has config for that. My global notices always go to server window
[16:49] <J_Darnley> hmm
[16:50] <Case> Options -> IRC and there "Show in active"
[16:50] <Case> untick everything and they appear in server window
[16:51] <Case> at least that's my assumption
[16:51] <Case> I have only checkmark on Whois
[16:51] <J_Darnley> ditto
[16:53] <J_Darnley> are they "ctcp" ?
[16:54] <J_Darnley> Ifo then it might be in under the "Events" button on that page.
[16:54] <J_Darnley> *if so
[16:56] <Case> now I'm actually not sure if I get global notices in server window all the time or if I just happen to have it active every time global notice comes
[16:56] <Case> when I'm not actively following anything I go to server window so it's easy to spot any channel that has activity
[17:15] <cone-934> ffmpeg.git 03Michael Niedermayer 07master:b11d1889ef60: avcodec/bmp_parser: fix parsing a single bmp which has a fsize < its header
[17:58] <cone-934> ffmpeg.git 03Michael Niedermayer 07master:3c6d824b8002: avcodec/bmp_parser: simplify
[17:58] <cone-934> ffmpeg.git 03Michael Niedermayer 07master:ceb2fe027fec: avcodec/bmp_parser: delay frame end detection to the next header or EOF
[18:17] <ubitux> is "\n" (0x5C 0x6e) really supported in ASS?
[18:17] <ubitux> (and not "\N")
[18:21] <wm4> ask vsfilter
[18:22] <JEEB> #irrational-typesetting-wizardry might be useful, on rizon
[18:22] <JEEB> nielsm/jfs and friends :3
[18:22] <ubitux> i have a mkv with those at least
[18:41] <JEEB> 2: No word wrapping, wide lines will extend beyound the edges of the screen. Both \n and \N force line breaks.
[18:41] <JEEB> looking at @ http://docs.aegisub.org/3.2/ASS_Tags/
[18:42] <JEEB> <Plorkyeran> it's treated as \N in one wrapping style and as a space in all others
[18:42] <JEEB> <Plorkyeran> i.e. it's dumb and useless
[18:43] <JEEB> <jfs> yes the \n versus \N really dates back to the SSAv3 to SSAv4 transition, as far as I understand
[18:43] <ubitux> haha
[18:43] <ubitux> ok
[18:44] <JEEB> basically old SSA didn't have automatic line wrapping
[18:44] <JEEB> so old scripts were full of linebreaks
[18:45] <JEEB> <jfs> but to let subbers take advantage of automatic breaking without changing scripts, the \n break was made into an ignored code except in one particular mode
[19:06] <kepstin> hmm, looks like my K6 w/mmx box is in working order with a linux distro installed. I guess I should set up FATE on it and see how long it takes to run :)
[19:09] <J_Darnley> At least it has mmx!
[19:12] <kepstin> no 3dnow tho; it's one of the older k6 models.
[19:14] <kepstin> that's hilarious; the linux distro installed on it is gentoo.
[20:33] <cone-934> ffmpeg.git 03Clément BSsch 07master:b96d864fd685: avcodec/mjpegdec: Fix chroma width rounding
[21:08] <ubitux> michaelni: can i ask for the assenc patch i just sent to be part of 2.4?
[21:09] <ubitux> just to be clear, it allows to reconstruct .ass files perfectly from mkv's
[21:09] <ubitux> (it reorders the line as they were originally)
[21:09] <ubitux> lines
[21:12] <michaelni> ubitux, it will be part of 2.4 if its pushed before we branch release/2.4
[21:12] <michaelni> or if its backported
[21:12] <ubitux> that's why i'm asking for a special review before you branch out ;)
[21:12] <ubitux> (you're the author of the assenc afaik)
[21:13] <ubitux> (libav just released 11)
[21:19] <jamrial> just wondering, since this version is the one that may make it to debian, how about making it ffmpeg 3.0 instead of 2.4?
[21:19] <jamrial> it's also the first version after we bumped major for all libraries
[21:19] <ubitux> you sound quite optimistic jamrial 
[21:20] <ubitux> it's been dying on the "NEW" queue for almost 6 months and you think something is going to change?
[21:20] <jamrial> i did say may :P
[21:20] <ubitux> :)
[21:20] <ubitux> that's too much optimism already
[21:20] <ubitux> joke aside, i'm fine with 3.0 but the changelog will be quite poor for a major release
[21:21] <jamrial> true, it's too close to 2.3 after all
[21:26] <jamrial> wm4: utf16 support isn't mentioned in changelog. it probably deserves a line
[21:35] <michaelni> ubitux, review sent
[21:38] <michaelni> ubitux, also if the entries are almost sorted often then keeping track of the last element of the linked list and adding there should be faster  than searching through the whole list
[21:38] <michaelni> i think the code searches from the start for inserts
[21:38] <ubitux> yeah right
[21:39] <michaelni> might be good enough instead of a change of the data structure to something else
[21:40] <michaelni> i dont really know how badly these elements are sorted normally
[21:41] <ubitux> maybe i should start from the end instead
[21:41] <ubitux> i can give you a real case example of the evolution of the list, just a moment
[21:45] <ubitux> michaelni: http://pastie.org/pastes/9551335/text
[21:48] <ubitux> but actually from the start looks like the best thing to do
[21:48] <ubitux> because that's likely where you add it
[21:50] <ubitux> there is one case though where it might matters
[21:50] <ubitux> is when the ReadOrder starts at 1
[21:50] <ubitux> and the muxer has to wait until every single Dialogue is cached
[21:51] <ubitux> in this case, every events will have to be added at the end
[21:51] <ubitux> i guess we can add an initial check for that
[21:52] <ubitux> like "is it to be added at the end?" with fallback start lookup from the beginning
[21:52] <michaelni> there are many options, you also could start the search from where the last element was inserted
[21:53] <michaelni> that would help with cases like 1 4 7 9    2 3 5 8 10   6 
[21:54] <ubitux> in the common use case i pasted above it's the least optimal
[21:54] <ubitux> like, adding 43 when you have "59 60 61 62 63 64 65 66 67 68 69 70 71"
[21:54] <ubitux> ah mmh wait
[21:54] <ubitux> my bad
[21:54] <ubitux> 59 wasn't the latest added
[21:54] <ubitux> yeah right, i guess i can do that
[21:55] <michaelni> theres also libavutil/tree.h
[21:55] <michaelni> or you could write a splay tree implementation
[21:55] <michaelni> nearly infinite options :)
[21:55] <ubitux> won't that be totally overkill?
[21:55] <michaelni> yes
[22:05] <ubitux> michaelni: so something along those lines would be fine with you? http://pastie.org/9551362
[22:05] <ubitux> mmh missing something.
[22:07] <ubitux> fixed @ http://pastie.org/9551365
[22:07] <ubitux> so looking from last added to the end, then beginning to last added
[22:13] <michaelni> ubitux, looks fine from a quick look
[22:13] <ubitux> cool
[22:13] <ubitux> then please poke me before you plan to branch out 2.4
[22:14] <cone-934> ffmpeg.git 03Michael Niedermayer 07master:296cd9c43277: avformat/mpegts: Improve probe heuristic by considering the overall frequency of 0x47 headers
[22:14] <ubitux> (thank you)
[22:16] <michaelni> ubitux, i intend to make the branch today or tomorrow, that is intend that does not mean i will
[22:17] <michaelni> that is assuming i dont run into any major issues
[22:18] <ubitux> ok, i'll push in the next hour then
[22:23] <michaelni> ok
[22:38] <cone-934> ffmpeg.git 03Michael Niedermayer 07master:8407cbbfc942: Fix "passing argument 1 of av_free discards const qualifier from pointer target type"
[22:38] <cone-934> ffmpeg.git 03Michael Niedermayer 07master:52c85b194b2d: avdevice/lavfi: dont assign variables to themselfs
[22:44] <ubitux> Command:This is a "command" event, which means SSA will execute the specified program as a background task.
[22:44] <ubitux> omg
[22:45] <iive> ubitux: is that a joke?
[22:46] <ubitux> iive: http://moodub.free.fr/video/ass-specs.doc
[22:46] <ubitux> that file name is already a joke, but well.
[22:47] <ubitux> Sound:			This is a "sound" event, which means SSA will play the specified .wav file.
[22:47] <ubitux> Movie:			This is a "movie" event, which means SSA will play the specified .avi file.
[22:47] <Compn> so many people have problems with the word 'ass' :P
[22:47] <ubitux> i like those as well btw
[22:50] <J_Darnley> it just means "donkey"...
[22:51] <ubitux> Compn: "ass", "specs" and "doc" are the jokes
[22:56] <ubitux> does anyone know if there are mkv with other event than Dialogues muxed in?
[22:56] <ubitux> such as Comment
[23:08] <Timothy_Gu>  ubitux: WIP release notes: https://gist.github.com/TimothyGu/cadf487de75189e49b4e
[23:09] <Timothy_Gu> I find it kinda hard to pick out the "most exciting features" in 2.4
[23:10] <ubitux> just a moment, i'll have a look
[23:10] <Timothy_Gu> UTF-16? dctdnoiz? Icecast?
[23:11] <ubitux> no need to make a paragraph on that
[23:11] <ubitux> just tell that we released 2.3 very recently so the Changelog is short
[23:11] <Timothy_Gu> What's the difference between dctdnoiz and owdenoise and hqdn3d?
[23:11] <ubitux> but OTOH this release is meant to be LTS (need confirmation from michael) if debian follow it
[23:11] <Timothy_Gu> Ok
[23:12] <ubitux> dctdnoiz is DCT based, with an original color correlation, owdenoise is wavelet based, and hqdn3d is... old/dunno
[23:13] <cone-934> ffmpeg.git 03Clément BSsch 07master:89d42da5c62c: avformat/assenc: honor ReadOrder
[23:13] <ubitux> Timothy_Gu: you can add that ffmpeg now reconstruct .ass files from .mkv in original order now
[23:13] <ubitux> :p
[23:15] <ubitux> Timothy_Gu: please drop the AVProbe thing from that file
[23:15] <ubitux> it really doesn't belong here at all
[23:16] <Timothy_Gu> OK...
[23:18] <jamrial> Timothy_Gu: you're missing a couple things present in changelog, like h261/h265 in RTP or LZMA compression in TIFF
[23:19] <jamrial> also, "FFmpeg 2.4 is API-, but not ABI-compatible with the previous major release" is not exactly true http://upstream-tracker.org/compat_reports/ffmpeg/2.3.3_to_current/src_compat_report.html#Withdrawn
[23:31] <ubitux> Timothy_Gu: you might want to look for asm contributions
[23:31] <ubitux> and summarize them in a sentence
[23:31] <ubitux> iirc there is at least idet that got some improvements asm wise
[23:32] <nevcairiel> hevc got transform_add asm, it makes no big dent in overall decoding time, but if you want to mention stuf...
[23:32] <cone-934> ffmpeg.git 03Michael Niedermayer 07master:36ea35bbc0e3: avformat/utils: free s->pb for image2 as it can be used with and without a file
[23:34] <jamrial> IMO, better wait until we get sao and idct in the tree to do that
[23:34] <ubitux> still no idct? really? :(
[23:36] <jamrial> it's written as intrinsics in openhevc
[23:36] <ubitux> is plepere working on this or someone else?
[23:36] <jamrial> sao as well, but plepere already ported it to yasm (or is in the middle of it). he hasn't posted it to the ml yet, though
[23:36] <jamrial> parts of it at least
[23:37] <nevcairiel> i was surprised how much sao asm really helped the performance, didnt expect that really
[23:37] <jamrial> https://github.com/OpenHEVC/FFmpeg/commits/rext
[23:45] <nevcairiel> hm, the x265 lead keeps advertising their own hevc decoder and always downplays ffmpeg, implying it lacks features and whatnot (although he doesn't say it, but he always makes a point to say stuff like"and ours even supports 10-bit"), its really annoying me sometimes :P
[23:48] <JEEB> yeah, MCW seems to have a history of marketing bullshit uber alles
[23:52] <cone-934> ffmpeg.git 03Michael Niedermayer 07master:c2a7607a1ca6: RELEASE_NOTES: Add next versions name (Fresnel)
[23:52] <jamrial> did he imply we don't support 10bit? because we do. 9 and 12bit as well, even...
[23:53] <nevcairiel> well i read it that way anyway, if you compare your decoder to ffmpeg one line above, and in the next line write "we support the full spec, including 10-bit", i read it that way
[23:53] <nevcairiel> did i lie to him in claiming that we support RExt btw? i saw a bunch of changes and new pixel formats, but i'm not 100% sure its actually entirely functional
[00:00] --- Sun Sep 14 2014