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

[burek]

[00:02] <ubitux> durandal_1707: are you on cvslog?
[00:02] <CIA-119> ffmpeg: 03Mans Rullgard 07master * r0595334892 10ffmpeg/libavcodec/x86/fft_mmx.asm: 
[00:02] <CIA-119> ffmpeg: x86: fft: elf64: fix PIC build
[00:02] <CIA-119> ffmpeg: In a 64-bit PIC build, external functions must be called
[00:02] <CIA-119> ffmpeg: through the PLT.
[00:02] <CIA-119> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[00:02] <CIA-119> ffmpeg: 03Hendrik Leppkes 07master * rea1c5011b3 10ffmpeg/libavcodec/dxva2_h264.c: 
[00:02] <CIA-119> ffmpeg: dxva2_h264: fix signaling of mbaff frames
[00:02] <CIA-119> ffmpeg: The MBAFF flag may only be signaled if we're actually dealing with
[00:02] <CIA-119> ffmpeg: a full frame, and not singular fields, as it can happen in mixed content.
[00:03] <CIA-119> ffmpeg: Signed-off-by: Martin Storsjö <martin at martin.st>
[00:03] <CIA-119> ffmpeg: 03Carl Eugen Hoyos 07master * rfbcaceb1ff 10ffmpeg/libavformat/mov.c: 
[00:03] <CIA-119> ffmpeg: mov: do not try to read total disc/track number if data atom is too short.
[00:03] <CIA-119> ffmpeg: Fixes bug 308.
[00:03] <CIA-119> ffmpeg: Signed-off-by: Anton Khirnov <anton at khirnov.net>
[00:03] <CIA-119> ffmpeg:  lavfi: remove 'opaque' parameter from AVFilter.init()
[00:03] <CIA-119> ffmpeg:  mov: do not try to read total disc/track number if data atom is too short.
[00:03] <CIA-119> ffmpeg:  avconv: fix -force_key_frames
[00:03] <CIA-119> ffmpeg:  dxva2_h264: fix signaling of mbaff frames
[00:03] <CIA-119> ffmpeg: 03Anton Khirnov 07master * ra5e8c41c28 10ffmpeg/libavfilter/ (44 files): 
[00:03] <CIA-119> ffmpeg: lavfi: remove 'opaque' parameter from AVFilter.init()
[00:03] <CIA-119> ffmpeg: It is not used in any filters currently and is inherently evil. If
[00:03] <CIA-119> ffmpeg: passing binary data to filters is required in the future, it should be
[00:03] <CIA-119> ffmpeg: done with some AVOptions-based system.
[00:03] <CIA-119> ffmpeg: 03Anton Khirnov 07master * r19ad567311 10ffmpeg/avconv.c: 
[00:03] <CIA-119> ffmpeg: avconv: fix -force_key_frames
[00:04] <CIA-119> ffmpeg: parse_forced_keyframes() relies in encoder timebase being set, so call
[00:04] <CIA-119> ffmpeg: it from transcode_init() after it is known.
[00:04] <burek> er.. which of these "ffmpeg -codecs | grep -i jpeg" is a jpeg still image?
[00:04] <burek> mjpeg only?
[00:06] <ubitux> afaik mjpeg are just like cat *.jpg
[00:06] <ubitux> durandal_1707: anyway, if you missed it, http://ffmpeg.org/pipermail/ffmpeg-cvslog/2012-June/051932.html
[00:07] <burek> ok, thanks
[00:44] <burek> ok, I started the page that will contain all the formats with their supported media types in it https://ffmpeg.org/trac/ffmpeg/wiki/SupportedMediaTypesInFormats
[00:44] <burek> if you feel something is wrong, please correct it and feel free to add formats that you know for sure what do they support
[00:45] <burek> maybe there is an array defined in ffmpeg for this exact thing?
[00:47] <CIA-119> ffmpeg: 03Anton Khirnov 07master * r8d900aa4d0 10ffmpeg/libavfilter/ (avfiltergraph.c avfiltergraph.h graphparser.c version.h): lavfi: remove disabled FF_API_GRAPH_AVCLASS cruft
[00:47] <CIA-119> ffmpeg: 03Anton Khirnov 07master * r6c1e065bd4 10ffmpeg/libavfilter/ (af_resample.c avfilter.h version.h): lavfi: remove disabled FF_API_SAMPLERATE64 cruft
[00:47] <CIA-119> ffmpeg: 03Anton Khirnov 07master * r0b3b958135 10ffmpeg/libavfilter/ (Makefile buffersrc.c version.h vsrc_buffer.h): lavfi: remove disabled FF_API_VSRC_BUFFER_ADD_FRAME cruft
[00:47] <CIA-119> ffmpeg: 03Anton Khirnov 07master * r5e88b96f37 10ffmpeg/libavfilter/ (avfilter.c avfilter.h version.h): lavfi: remove disabled FF_API_DEFAULT_CONFIG_OUTPUT_LINK cruft
[00:47] <CIA-119> ffmpeg: 03Anton Khirnov 07master * r1961e46c15 10ffmpeg/libavfilter/ (avfilter.c avfilter.h formats.c formats.h version.h video.c): lavfi: remove disabled FF_API_FILTERS_PUBLIC cruft
[00:47] <CIA-119> ffmpeg: 03Michael Niedermayer 07master * r5916bc4658 10ffmpeg/: (log message trimmed)
[00:47] <CIA-119> ffmpeg: Merge commit '1961e46c15c23a041f8d8614a25388a3ee9eff63'
[00:47] <CIA-119> ffmpeg: * commit '1961e46c15c23a041f8d8614a25388a3ee9eff63':
[00:47] <CIA-119> ffmpeg:  lavfi: remove disabled FF_API_FILTERS_PUBLIC cruft
[00:47] <CIA-119> ffmpeg:  lavfi: remove disabled FF_API_DEFAULT_CONFIG_OUTPUT_LINK cruft
[00:47] <CIA-119> ffmpeg:  lavfi: use proper FF_API guards for different deprecated functions
[00:47] <CIA-119> ffmpeg:  lavfi: remove disabled FF_API_VSRC_BUFFER_ADD_FRAME cruft
[00:47] <CIA-119> ffmpeg: 03Anton Khirnov 07master * r205e90249a 10ffmpeg/libavfilter/avfilter.c: lavfi: use proper FF_API guards for different deprecated functions
[01:14] <durandal_1707> ubitux: why would i be on cvs log?
[01:14] <j-b> michaelni: 69bf775e9 is broken IMVHO
[01:16] <durandal_1707> ubitux: http://lists.libav.org/pipermail/libav-devel/2012-June/029906.html
[01:16] <Compn> j-b : how?
[01:16] <Compn> if you could explains
[01:16] Action: Compn finding a lot of devels giving a lot of bad bugreports
[01:17] <j-b> r = _vscprintf(format, va);
[01:17] <j-b> without doing a check on vscprintf check...
[01:18] <j-b> and, of course, it breaks mingw32
[01:20] <durandal_1707> is it fine to remove all this stupid get_buffer() failed logs?
[01:21] <michaelni> j-b, iam not sure i understand (id fix it if i do), but best mail nicrolas, he isnt on IRC
[01:22] <j-b> michaelni: well, vscprintf is not defined in all Mingw
[01:22] <michaelni> ahh
[01:22] <j-b> so, it breaks many implemetations.
[01:22] <michaelni> missing confogure check ?
[01:23] <j-b> probably, indeed
[01:23] <michaelni> ill forward this to nicolas, maybe he has a better idea because
[01:23] <durandal_1707> if init of decoder fails is close still called?
[01:23] <michaelni> a ciónfigure check would still mean the return value would then be wrong again
[01:24] <michaelni> when its not available
[01:27] <michaelni> durandal_1707, no i dont think its called
[02:07] <CIA-119> ffmpeg: 03Anton Khirnov 07master * rcb81e29138 10ffmpeg/libavfilter/avfilter.h: 
[02:07] <CIA-119> ffmpeg: lavfi: reorder AVFilterBuffer fields.
[02:07] <CIA-119> ffmpeg: Place related fields together, remove holes.
[02:07] <CIA-119> ffmpeg: 03Anton Khirnov 07master * rf14e685609 10ffmpeg/libavfilter/avfilter.h: 
[02:07] <CIA-119> ffmpeg: lavfi: reorder AVFilterBufferRef fields.
[02:07] <CIA-119> ffmpeg: Place related fields together, remove holes.
[02:07] <CIA-119> ffmpeg: 03Anton Khirnov 07master * r9618080512 10ffmpeg/libavfilter/avfilter.h: 
[02:07] <CIA-119> ffmpeg: lavfi: reorder AVFilter fields.
[02:07] <CIA-119> ffmpeg: Place related fields together, remove holes, move private fields to the
[02:07] <CIA-119> ffmpeg: end and mark them as private.
[02:07] <CIA-119> ffmpeg: 03Anton Khirnov 07master * r83ba22392d 10ffmpeg/libavfilter/avfilter.h: 
[02:07] <CIA-119> ffmpeg: lavfi: reorder AVFilterLink fields.
[02:07] <CIA-119> ffmpeg: Move private fields to the private section, remove holes.
[02:07] <CIA-119> ffmpeg: 03Anton Khirnov 07master * rb8c632a720 10ffmpeg/avconv.c: avconv: don't include vsrc_buffer.h, which doesn't exist anymore
[02:07] <CIA-119> ffmpeg: 03Martin Storsjö 07master * r39dba5aa1b 10ffmpeg/libavformat/ (network.h sctp.c tcp.c udp.c): (log message trimmed)
[02:07] <CIA-119> ffmpeg: network: Include unistd.h from network.h
[02:07] <CIA-119> ffmpeg: This heaader is required for close() for sockets in network
[02:07] <CIA-119> ffmpeg: code. For winsock, the equivalent function is defined in the
[02:07] <CIA-119> ffmpeg: winsock2.h header.
[02:07] <CIA-119> ffmpeg: This avoids having the HAVE_UNISTD_H in all files dealing with
[02:07] <CIA-119> ffmpeg: raw sockets.
[02:07] <CIA-119> ffmpeg: 03Ronald S. Bultje 07master * re64bceeac0 10ffmpeg/ (configure libavformat/os_support.c): 
[02:07] <CIA-119> ffmpeg: configure: Check for sys/time.h
[02:07] <CIA-119> ffmpeg: Apparently this include is needed on some systems for building the
[02:07] <CIA-119> ffmpeg: poll fallback (for the timeval struct for select?), but it isn't
[02:07] <CIA-119> ffmpeg: available on all systems. Thus only include it if it exists.
[02:08] <CIA-119> ffmpeg: network: Don't redefine error codes if they already exist in errno.h
[02:08] <CIA-119> ffmpeg: Since the errno.h values don't match the error codes that winsock
[02:08] <CIA-119> ffmpeg: returns, map the winsock error codes to the errno ones, to make
[02:08] <CIA-119> ffmpeg: sure explicit checks against AVERROR(x) match.
[02:08] <CIA-119> (49 lines omitted)
[10:53] <ubitux> http://dev.w3.org/html5/webvtt/
[10:53] <ubitux> seriously
[10:53] <ubitux> fuck them all.
[10:53] <ubitux> they're stupid or what...
[10:54] <av500> ubitux: yes
[10:54] <av500> ask j-b
[10:54] <ubitux> mmh, @google again
[10:54] <ohsix> what are they supposed to do?
[10:54] <ubitux> i hate this company more every day
[10:55] <ubitux> ohsix: re-use an existing one?
[10:55] <ohsix> which one
[10:55] <ubitux> they don't even support SRT properly on youtube
[10:55] <ubitux> (they print <i> tags in the subtitles....)
[10:56] <ubitux> ohsix: subrip is fine, ass as well, TED use some json based one, ...
[10:56] <ubitux> i mean they are tons of them
[10:57] <ohsix> would be nice if there was a requirements section
[10:57] <ohsix> it is pretty dumb to not use an existing one, unless you can't
[10:57] <ubitux> and again they are using smil based crap :(
[10:57] <ohsix> smil is used on phones for everything
[10:59] <ubitux> anyway, one more subtitles format to add on my todo list
[10:59] <ubitux> hopefully it will never be used
[11:00] <ohsix> looks like programmatic access is paramount
[11:00] <ubitux> it seems to be used by video.js
[11:01] <ohsix> at least in the context it'll be seen most, google will probably support it with code as well :]
[11:01] <JEEB> I think nielsm talked with W3C on as6, but I don't think it went anywhere as the first alpha implementation of as6 was made just a month+ ago
[11:02] <JEEB> (and the talks were had 1.5-2 years ago
[11:02] <ubitux> do you know if as6 will be backward compatible with ass?
[11:03] <JEEB> it will have some similarities, but it will also try to basically be better spec'd and somewhat of a different format. Not sure if nielsm released his working drafts yet. The only real docs on it I've seen on it was the readme file that came with the "crashes more than works" test implementation
[11:04] <JEEB> http://www.animereactor.dk/aegisub/as6render-20120521_1000.rar
[11:05] <ohsix> these things, very important
[11:05] <JEEB> if you want more info on as6 I recommend poking nielsm on it
[11:06] <j-b> ubitux: very
[11:06] <ubitux> :(
[11:06] <JEEB> I think he didn't want to release specs publically yet to try and stop what happened with the AS5 which was never really born as random people started implementing non-finished specs
[11:07] <JEEB> (and AS5 was IIRC "stuff on top of ASS" instead of a new format, but I must confess I never even checked the as5-related stuff in aegisub's svn repo)
[11:07] <ohsix> does it do css3, lul
[11:07] <ubitux> :D
[11:08] <ubitux> SAMI supports 100% of CSS2
[11:08] <ubitux> this makes SAMI a superior subtitles format
[11:10] <ohsix> it's all about context tho
[11:10] <JEEB> https://privatepaste.com/157ca0ccd0 <- the readme of as6render
[11:10] <ohsix> that stuff never just lives in a typed resource on a webpage, it's always munged and shuffled about
[11:11] <ohsix> people aren't using it to subtitle anime, they're using it for the hearing impaired
[11:12] <j-b> SAMI is crap
[11:12] <j-b> WebVTT is beyond crap
[11:12] <ubitux> :)
[11:12] <j-b> and Anime formats are bad.
[11:12] <av500> :)
[11:12] <ohsix> so there's one true format, why do they still need webvtt
[11:13] <j-b> there is not one true format.
[11:13] <ubitux> NIH
[11:13] <ubitux> xkcd/927
[11:13] <ohsix> what about not fit for purpose
[11:14] <JEEB> anyways, I hope something comes up of AS6 or there is a better alternative found -- so that people can move on from the mess that was created by Gabest
[11:14] <JEEB> (never going to happen, I know)
[11:14] <j-b> We need a new format, indeed.
[11:14] <j-b> and WebVTT is not the solution.
[11:14] <JEEB> indeed
[11:14] <ubitux> a new format? oO
[11:15] <ubitux> ASS is fine, AS6 will just help covering more stuff
[11:15] <JEEB> ASS is not fine because the spec is vsfilter
[11:15] <ohsix> their requirements are probably different from yours
[11:15] <ubitux> JEEB: the specs could be written
[11:15] <JEEB> and by now various vsfilter versions disagree with each other, too
[11:15] <ohsix> specs don't mean compliance
[11:15] <ubitux> also, there are already implementations
[11:16] <JEEB> yes, which is why ASS is being used atm
[11:16] <j-b> ubitux: no, ASS is not fine.
[11:16] <ohsix> w4m
[11:16] <ubitux> j-b: except the timing issue, i don't see why
[11:16] <j-b> ubitux: it is a bad format, not complete, and not even specified
[11:17] <ubitux> then we should just improve the documentation
[11:17] <JEEB> also, hands up who here remembers CoreCodec's XML'ization of ASS?
[11:17] <j-b> with a lot, and I mean a lot of unspecified behaviour
[11:17] <ubitux> implementation are used and working for most of the stuff
[11:17] <j-b> Moreover, it is non-streamable
[11:17] <j-b> and near impossible to parse.
[11:17] <ohsix> does it support css3
[11:17] <j-b> aka crap
[11:18] <j-b> it is a fun toy, but not a serious format.
[11:18] <ubitux> why isn't it streamable? we are able to make ass packets in mkv
[11:18] <j-b> right. Cut a ASS file in 2.
[11:18] <ubitux> you just need to sort the dialogues by pts and put the header stuff somewhere
[11:18] <j-b> play both.
[11:18] <ubitux> j-b: i don't understand; just dup the header?
[11:20] <ohsix> it's all bad, give up
[11:20] <j-b> it is bad.
[11:21] <ohsix> for the purpose of discussion, since bad hasn't been defined, i'll define it as good
[11:21] <ubitux> :)
[11:22] <j-b> We need a strong format, that is streamable, correctly parseable by browsers and players and boxes, that can allow any cool style, and can be used for timed-text information
[11:22] <ohsix> i don't, i need one that is readable
[11:22] <j-b> why?
[11:23] <av500> j-b: I dont need one, I can understand english and I dont watch anime :)
[11:23] <j-b> av500: :)
[11:23] <ohsix> vision and foreign language impaired
[11:23] <ubitux> what is a "strong" format?
[11:23] <ubitux> a streamable format, except formats like SAMI or microdvd supporting the "last-to-the-next-event" feature, most of them are
[11:24] <ubitux> parseable by browsers? seriously no
[11:24] <ohsix> i also don't care where it is on the frame or what it obscures, or how clever people can be with it; it's for the suboptimal case of me not being able to hear it at all, or to understand it
[11:24] <ubitux> it means SMIL based crap
[11:24] <ubitux> it's a hell
[11:24] <ubitux> overhead, unreadable, stupid, etc
[11:24] <ohsix> it's not bad if you _are_ a browser :]
[11:24] <j-b> ubitux: you are dellusional.
[11:24] <ubitux> "any cool style" ’ no& see how much pain it is to implement this
[11:25] <ubitux> look at the time it took to dev libass, and how much problems it raises..
[11:25] <j-b> it took a lot of time because ASS is crap
[11:25] <j-b> doing the same for USF was very faster to do.
[11:25] <ubitux> lol usf
[11:25] <ubitux> :D
[11:25] <JEEB> lol USF
[11:26] <ubitux> doing a rendering engine for subtitles is hell
[11:26] <ubitux> font issues, vector stuff, etc
[11:26] <j-b> then, don't take any format.
[11:26] <ubitux> no, we just need to have a common rendering system
[11:26] <ubitux> we have one, and it's libass
[11:26] <ohsix> yes, rendering them is crazy hard
[11:26] <ubitux> we should use it for all the subtitles
[11:27] <j-b> you are confusing the worlds need and yours.
[11:27] <ubitux> actually, that's already the case
[11:27] <ohsix> more like cairo and pango \m/
[11:27] <j-b> and because of answers like yours, we got WebVTT
[11:27] <ohsix> what, heh
[11:27] <j-b> and it will be a major format, that we will need to live with.
[11:27] <ubitux> [ffmnpeg] % ./configure --enable-webkit --enable-cairo --enable-js
[11:27] <ohsix> they wrote it for their requirements
[11:27] <ubitux> yepee
[11:28] <ubitux> j-b: i never requested webvtt
[11:28] <j-b> you just did.
[11:28] <j-b> 11:24 <@ubitux> parseable by browsers? seriously no
[11:28] <ubitux> then use json
[11:28] <ubitux> at least it's a sane base
[11:28] <ohsix> eh
[11:28] <j-b> of course, it needs to be json or xml based. Without header, or with repeatable header.
[11:29] <ubitux> without header?
[11:29] <ubitux> and with aa lot of styles?
[11:29] <ubitux> i think you are dreaming
[11:29] <ubitux> i don't see the point of dropping the header
[11:29] <j-b> try to read my sentence.
[11:29] <j-b> just try.
[11:29] <ohsix> style can be separate, the wonders of html
[11:30] <ubitux> j-b: isn't ASS header repeatable?
[11:30] <j-b> maybe, but it does not fit, because of under-specification and because of parsable format.
[11:31] <ohsix> if you have your own requirements it might be a good start to write them down :] nevermind specifications
[11:31] <j-b> I do not have requirements. I just look a bit at the industry
[11:31] <j-b> and I've been at EBU, IETF, W3C meetings
[11:31] <ubitux> the industry doesn't care, they use bitmap subtitles anyway
[11:31] <ohsix> then you don't need a new anything
[11:32] <ohsix> aside from the size, what's wrong with bitmap subtitles? :D
[11:32] <ubitux> no particular issues
[11:32] <ohsix> aside from not being machine readable, or always legible, or really any standard
[11:32] <ubitux> except that it's hard to convert them to text  ;)
[11:33] <ubitux> of course it has a lot of benefits
[11:33] <ubitux> since it doesn't require your dvd player to use fontconfig
[11:33] <j-b> of course, it does not fit the accessibility requirement.
[11:33] <ubitux> sure, it's another issue
[11:33] <ohsix> not being machine readable is a huge downside
[11:34] <j-b> well, it just ruled-out bitmaps
[11:34] <ubitux> maybe you can name the bitmaps with the text subtitles content for accessibility ;)
[11:34] <ubitux> you should be able to do that with mxf
[11:34] <ubitux> muxing named-png's for subtitles
[11:34] <ohsix> you could just do regular vbi sub text too
[11:34] <ubitux> well anyway
[11:35] <ubitux> the industry will just invent N more subtitles formats
[11:35] <ubitux> needing N more rendering engines
[11:35] <ohsix> when
[11:35] <ubitux> no one will ever implement
[11:35] <ubitux> except by wrapping them around libass
[11:35] <ubitux> problem solved by itself.
[11:39] <ohsix> shrug, i dunno what they're supposed to do if nothing that currently exists meets their requirements, even if they may with negligable effort; you have to deal with the people too :p it probably works in their favor that people dislike it on its face
[11:41] <ubitux> they should just help writing the ASS specifications, and define a way of muxing it in JSON, just like matroska defined a way of muxing it in MKV
[11:42] <ubitux> ’ re-use the existing, limit the insane from-scratch rewriting, and help the current situation instead of trashing it even more
[11:42] <ohsix> that takes time
[11:42] <ubitux> less than rewriting a specification
[11:43] <ubitux> and wait for partial implementation
[11:43] <ohsix> plus there's personalities involved that would cause problems
[11:43] <ohsix> there's nto a lot the webkit(/apple/google) & mozilla guys do halfway with that sort of thing
[11:44] <ubitux> ok let me help you: {"header": "[ASS+ Style v42]...", {"events": {"pts": "00:01:02.012", "duration: "00:00:10.000", "text": "..."}, {"dialogue": ...
[11:44] <ubitux> here you have it
[11:44] <ubitux> you just need a json parser and here we go.
[11:45] <ohsix> do we cite the webpage or whatwg
[11:45] <ohsix> s/webpage/irc log
[11:45] <ubitux> is that much complicated than rewriting a spec from scratch with no idea what they are doing?
[11:46] <ohsix> how do you know they have no idea what they're doing? at the very least they know what they need or want subtitles for, and how it has to work to facilitate that usage
[11:46] <ubitux> look at the result
[11:46] <sandsmark> ubitux: much less satisfying for the ego, though :p
[11:46] <ubitux> do you think SAMI, RT or webttv are sane?
[11:46] <ubitux> or even USF...
[11:47] <ohsix> i have no opinion, other than i know the workflow & how things are typically employed in a browser
[11:49] <ohsix> i don't think i'd propose it for some streamable or embeddable subtitle format for general use outside of a browser either
[11:50] <ohsix> that would make it way more than what it currently is
[11:50] <ubitux> well, xml & json are not that streamable
[11:50] <ubitux> a plain text like subrip is though
[11:50] <ubitux> (oh it's implemented everywhere already.)
[11:50] <ubitux> ohsix: a parser is not that a problem
[11:50] <ubitux> the problem is mostly about styles
[11:51] <ubitux> or the decoder part if you prefer
[11:51] <ohsix> i'm sure there's a discussion on the w3c/whatwg lists about this, i don't know what their requirements actually were and why they aren't able to use subrip, or anything else
[11:51] <ubitux> you could define multiple way of muxing ASS
[11:51] <ohsix> is ass plaintext?
[11:52] <ubitux> we already know how to mux ASS in the MKV, we could define a "json format" to mux them (see above) or a plaintext one
[11:52] <ubitux> sure
[11:52] <ohsix> that seems silly when you can just come up with something that's html-alike, stylable, uses familiar elements
[11:57] <ohsix> it's kind of disjointed to venture out of that sort of thing for browser use, unless it's a completely binary something you're not supposed to really touch; but tell the browser to do things with it
[11:57] <ubitux> video & audio are already binary, i wonder what's the problem with muxing non-browser-compliant subtitles
[11:58] <ohsix> timing and styling in the dom or with javascript would be inflexible and dumb with a binary format
[11:58] <ohsix> if something is actually multiplexed with the video i don't see why it couldn't be subrip or anything else, but this isn't that
[13:29] <burek> sweet :) http://en.wikipedia.org/wiki/Comparison_of_container_formats
[14:17] <av500> asf does not support b-frames, interesting
[14:17] <av500> vc1 with b-frames in ASF works fine....
[14:18] <JEEB> as far as I know ASF is just fine with b-frames
[14:18] <JEEB> it's not AVI after all
[14:18] <JEEB> tl;dr "lol wikipedia" most probably
[14:19] <JEEB> http://wiki.multimedia.cx/index.php?title=Microsoft_Advanced_Streaming_Format I lol'd at the "There are 2 versions of ASF"
[14:20] <JEEB> > 1.0, the used and unpublished format > 2.0, the published and unused format
[14:20] <Compn> lol
[14:26] <JEEB> also, oh boy @ the ASF version 2's specs
[14:26] <JEEB> lots o' pretty colors
[14:27] <av500> the specs from M$ match more or less the files I have
[14:27] <av500> dunno if that is 1 pr 2
[14:27] <av500> or
[14:35] <jesk> ok, i got it to manage inserting free in front of mdat
[14:35] <jesk> but it seems there is no application which wants to make use of free :D
[14:35] <jesk> all i tried will rewrite anyway
[14:35] <JEEB> unsurprising
[14:35] <jesk> \o/
[14:37] <jesk> JEEB, could you explain me why this isn't suprising you? :-)
[14:37] <JEEB> because no-one was adding arbitrary extra free space into their files
[14:38] <JEEB> and thus no-one even implemented that possible use case
[14:38] <jesk> but all will remove free :D
[14:38] <jesk> brilliant
[14:38] <JEEB> yes, because in most cases it is just useless cruft)
[14:39] <JEEB> it's not mpeg-ts we're talking about which has a set mux rate (which will be filled with null packets to reach that goal)
[14:39] <jesk> this useless cruft could help to reduce tagging time from hours to seconds, but instead all are ore interested in saving Kilobytes :D
[14:40] <JEEB> I do understand your point, but most people either don't tag, or tag during their initial mux
[14:41] <jesk> from code point of view this shouldn't be much effort to implement, right?
[14:42] <jesk> i would guess that the implemented rewrite is 10 times more code
[14:43] <jesk> but i'am just big mouth without clue
[14:43] <jesk> oh I forgot: 
[14:44] <jesk> iTunes is honouring free 
[14:44] <jesk> one of ten I tried
[14:45] <jesk> but iTunes won't fetch anything automatically
[14:47] <JEEB> well, I'm surely not against people implementing that stuff, but you just have to understand that the use case has been rather small until now which hasn't really made anyone before implementing it
[14:48] <JEEB> in most cases it's just mux with tags -> do an index move to the beginning
[14:49] <jesk> as I understand MP4 is an very advanced container format with very poor support, although its there for yeeears
[14:49] <jesk> but could be wrong
[14:50] <av500> jesk: just adding free at the front does not help if the MOOV atom is at the end
[14:50] <JEEB> no-one fully implements the ISO media container :)
[14:50] <jesk> but chance is there anyway that I just missed the right tool which could this magic
[14:51] <jesk> av500, true, but AtomicParsley seems to work fine with placing moov at the front
[14:52] <jesk> /and/ place free behind it
[14:52] <JEEB> jesk, my short opinion on the container can be condenced into http://forum.doom9.org/showpost.php?p=1580058&postcount=3
[14:54] <jesk> i had look at the specification from Apple
[14:54] <jesk> its overloaded with details on all those atom types
[14:54] <jesk> the whole idea about is is very hard to get out of the spec
[14:55] <jesk> would be cool if there would be at least one OSS reference implementation
[14:56] <JEEB> other than libavcodec, there are two or so still upkept mov/mp4/ISO media container implementations
[14:56] <JEEB> GPAC and L-SMASH
[14:56] <jesk> Loyal to Spec of Mpeg4 and Ad-hoc Simple Hackwork. 
[14:57] <jesk> never heard about L-SMASH
[14:57] <JEEB> it's a newer thing, started in 2011 or so because GPAC was getting way too huge and derpy, as well as failing with various things
[14:58] <jesk> so its worth a look
[14:59] <JEEB> definitely
[14:59] <jesk> hopefully it will compile on my mbp :)
[14:59] <JEEB> it's somewhat raw from certain sides (like the raw stream muxer being separate from the remuxing app)
[14:59] <JEEB> yeah, it should
[14:59] <JEEB> it doesn't have many dependencies
[15:00] <JEEB> I've used the boxdumper tool at times to troubleshoot certain files
[15:02] <jesk> those mp4 gurus should unify and build ninja-mp4-toolsuite
[15:03] <JEEB> I think GPAC is quite hardened on their position and all :)
[15:06] <jesk> gpac is brilliant in deleting free, just adding is missing :)
[15:07] <jesk> oh yah l-smash builds without gap
[15:09] <jesk> boxdumper seems a lot like AtomicParsley
[15:09] <jesk> just more verbose
[15:11] <jesk> cool stuff
[15:15] <jesk> impressive how man chunks there are
[22:58] <ubitux> saste: do you mind commenting on '[PATCH 4/6] documentation: change "Libavfilter" link to "Filters".' ?
[22:58] <ubitux> i'm going to push half the patchset, but i'm still unsure about this patch
[23:02] <CIA-119> ffmpeg: 03Michael Bradshaw 07master * r54942c2383 10ffmpeg/libavcodec/avcodec.h: 
[23:02] <CIA-119> ffmpeg: lavc: clarify docs for avpkt->destruct
[23:02] <CIA-119> ffmpeg: avcodec_encode_audio2 docs are ambiguous about avpkt->destruct and imply
[23:02] <CIA-119> ffmpeg: it gets reset.
[23:02] <CIA-119> ffmpeg: Signed-off-by: Michael Bradshaw <mbradshaw at sorensonmedia.com>
[23:02] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:03] <CIA-119> ffmpeg: 03Eric Petit 07master * rf1136b2b10 10ffmpeg/libavformat/udp.c: 
[23:03] <CIA-119> ffmpeg: udp: fix occasional crash on shutdown
[23:03] <CIA-119> ffmpeg: Wait until the thread is down before destroying the fifo
[23:03] <CIA-119> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[23:18] <jesk> is there any common reason why ffserver ignores any http request to it?
[23:19] <jesk> port is open, but that's all.
[23:34] <ubitux> saste: well anyway, i did a s/libavfilter/filtering/, i'll push soon
[00:00] --- Thu Jun 28 2012