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

[burek]

[00:02] <cone-864> ffmpeg.git 03Nicolas George 07ca4872e8878d: lavf/sbgdec: use proper constants for av_log().
[00:29] <cone-864> ffmpeg.git 03Stefano Sabatini 07fa4ead1d6692: doc: move codec options and descriptions to a dedicated manual page
[00:29] <cone-864> ffmpeg.git 03Stefano Sabatini 07f62abbf3b794: doc: move filters documentation to dedicated manual page ffmpeg-filters
[00:29] <cone-864> ffmpeg.git 03Stefano Sabatini 07e903cb419473: doc: add libswresample.texi and ffmpeg-resampler.texi files
[01:20] <cone-864> ffmpeg.git 03Michael Niedermayer 07e6305f763131: mov: set flags to indicate that byte wise seeking is not supported.
[02:45] <cone-864> ffmpeg.git 03Michael Niedermayer 0748cbdaea1576: smacker: fix smacker_decode_header_tree() empty vlc table init
[13:24] <durandal_1707> if read_header fails is read_close still called?
[13:49] <michaelni> durandal_1707, no, its not, but i think it was discussed a few time that this should/could be changed
[14:47] <cone-97> ffmpeg.git 03Michael Niedermayer 078f507feecbe9: avfiltergraph: add AVOption table
[14:47] <cone-97> ffmpeg.git 03Peter Ross 07fdd71cf04c4f: iff decoder: initialise HAM line decoder with first palette entry
[15:05] <cone-97> ffmpeg.git 03Stefano Sabatini 07c70ec631c928: lavu/opt: add av_opt_ accessors for pixel/format/image size options
[15:05] <cone-97> ffmpeg.git 03Stefano Sabatini 07be2c0bc94974: configure: prefer "resampling" in the libswresample pkg-config description
[15:59] <cone-97> ffmpeg.git 03Stefano Sabatini 0726c531cc223d: lavu/opt: fix range shown in set_format() log message
[17:31] <ubitux> anyone willing to make a proper api for subtitles encoding? :(
[17:36] <durandal11707> you can't?
[17:37] <ubitux> i don't want to
[17:37] <ubitux> it's a pain :p
[17:37] <ubitux> but i need it :(
[17:37] <ubitux> no one helps me :'(
[17:38] <durandal11707> why it is pain?
[17:39] <ubitux> you need to change the encoders to use an api such as bprint because they can't guess the final size
[17:39] <ubitux> you also need to keep the old api working
[17:39] <ubitux> and stuff like that
[17:40] <wm4> what is subtitle "encoding" other than muxing?
[17:40] <ubitux> markup encoding
[17:40] <ubitux> wm4: codecs deal the styles/markup
[17:41] <ubitux> formats with the timing and stuff
[17:41] <wm4> wait, is this about having a generic internal subtitle representation with styling?
[17:41] <ubitux> yes that's what i'm working on
[17:41] <wm4> oh dear
[17:41] <ubitux> right now the internal subtitle representation is ASS
[17:41] <ubitux> i need to keep compat with this btw, i think i found a way
[17:42] <ubitux> but with the current state of the encoding api, it's a real pain
[17:42] <ubitux> :(
[17:43] <ubitux> wm4: related: http://ffmpeg.org/pipermail/ffmpeg-devel/2012-September/130474.html and more recently: http://ffmpeg.org/pipermail/ffmpeg-devel/2012-November/134607.html
[17:46] <wm4> ubitux: why not try to avoid all this useless complexity, and add converters for formats where it makes sense (like srt->ass), and use pure text for the rest?
[17:47] <ubitux> because there are too much different markups
[17:47] <ubitux> and there will be more
[17:48] <ubitux> we already have some "converters"
[17:48] <ubitux> the more we add, the more messy it gets
[17:49] <wm4> what's the purpose of subtitle conversion at all?
[17:50] <ubitux> what's the purpose of video conversion at all?
[17:51] <ubitux> most of the use case i see right now is convert from [anything] to ASS or SRT
[17:51] <ubitux> but webvtt comes into play, and we might need one
[17:52] <ubitux> if you want to convert some advanced ass file to a webvtt file for the web for instance
[17:52] <ubitux> webvtt has a few things ass doesn't have, and the reverse is true as well
[17:53] <wm4> and what will you do in this case?
[17:53] <ubitux> the encoder will ignore the styles it doesn't know how to honor
[17:53] <ubitux> the abstract subtitles is pretty handy for this
[17:54] <ubitux> we have already something re-parsing the ass markup to do this
[17:54] <ubitux> but it really is hard to maintain, and doesn't work that well
[17:54] <ubitux> especially to manage global styles for instance
[17:56] <wm4> I'd just convert everything to flat text (possibly with minor markup) and leave it at that
[17:57] <wm4> not like trying to handle more complicated format specific feature will actually work
[17:58] <ubitux> it will ease encoders work
[17:58] <ubitux> if at some point libass is adding support for a new awesome subtitles markup, or just add new things
[17:58] <ubitux> (such as ruby char like we have in webvtt)
[17:59] <ubitux> we would be able to make the encoder output them easily
[17:59] <ubitux> we won't be able to do that in the current form
[17:59] <ubitux> since the packet are decoded to ass and directly sent to libass by the apps
[17:59] <wm4> I don't really think general format conversion is the job of ffmpeg; this is a bit too high level
[17:59] <wm4> what's next, converting BD menus to DVD menus?
[17:59] <ubitux> general format conversion is exactly the job of ffmpeg IMO
[18:01] <wm4> video formats
[18:01] <wm4> and audio
[18:01] <ubitux> why not subtitles?
[18:02] <ubitux> if players want to use ffmpeg to decode subtitles, it's nice if they are decoded with a maximum of information kept from the source
[18:02] <wm4> because it opens a can of worms
[18:02] <ubitux> and also, to offer them the ability to encode them to ass or something else to be sent to libass/whatever is nice
[18:03] <ubitux> and we need to deal with encoding too, i hope nicolas will work on this :p
[18:04] <ubitux> wm4: so you'd better keep a miserable support for subtitles? :)
[18:04] <wm4> ubitux: well, correct ass demuxing would be a nice start to better support
[18:04] <ubitux> i would already have done if i could
[18:04] <ubitux> unfortunately, that's far from easy for several reasons
[18:05] <ubitux> main one being compat, and the other one the fork which won't be able to follow
[18:05] <ubitux> and thus app adding #ifdery
[18:05] <nevcairiel> stop worrying about them, they dont worry about you =p
[18:05] <ubitux> nevcairiel: i worry about apps
[18:06] <nevcairiel> give apps reasons to use ffmpeg by providing superior features
[18:06] <nevcairiel> ignore politics
[18:06] <ubitux> breaking things is not going to give any reason to use ffmpeg
[18:06] <wm4> ubitux: whatever you do, please do not try to implement a ffmpeg native subtitle rasterizer; it won't end well
[18:06] <ubitux> i just can't change the current output of subtitles decoders
[18:07] <saste> wm4: why?
[18:07] <ubitux> wm4: why?
[18:07] <ubitux> :))
[18:07] <ubitux> wm4: it's almost already done you know
[18:07] <ubitux> i just have a headaches to not break anything during integration
[18:07] <wm4> oh well...
[18:08] <saste> ubitux: "integration"? are you porting libass code?
[18:08] <ubitux> no no
[18:08] <ubitux> i mean make the decoders rasterize is one thing, but the output must not change
[18:08] <ubitux> i mean, they must keep to fill the ass field as well
[18:08] <ubitux> otherwise it will break apps
[18:08] <ubitux> (that's one thing)
[18:09] <wm4> so there'll be text and bitmaps at the same time?
[18:09] <ubitux> no
[18:09] <ubitux> well, you can.
[18:09] <ubitux> rasterize wasn't the correct word sorry
[18:10] <ubitux> forget this, i meant make the text subtitles output an AST
[18:10] <ubitux> not making any rasterization
[18:10] <ubitux> see graph on http://ffmpeg.org/pipermail/ffmpeg-devel/2012-September/130474.html
[18:10] <nevcairiel> rasterize is the word that means converting text into images, so not that? :p
[18:10] <ubitux> yeah not that.
[18:10] <ubitux> i meant abstract representation of the event, instead of a string
[18:10] <ubitux> (the ASS line like currently)
[18:16] <wm4> ubitux: so, does that mean the application can create an encoder to convert AVSubtitle2 subtitles from one format to another?
[18:16] <uau> ubitux: subtitles are different enough that anything relevant to them (other than the lowest level of demuxing) can be handled in a library separate from libavcodec without losing any significant "synergy"
[18:16] <uau> and IMO they should, rather than bloating everything together in the same project
[18:22] <saste> uau, adopting the same logic we should have two distinct libavcodec, one for audio and one for video
[18:23] <saste> subtitles -> image rendering is another matter, and maybe it should stay in a separate lib
[18:23] <saste> (libavsubrend?)
[18:24] <nevcairiel> avrasterizer
[18:25] <durandal11707> why av in it?
[18:25] <saste> branding reasons
[18:25] <nevcairiel> could make it swrasterizer, even if i never understood the sw* prefix :p
[18:26] <saste> SoftWare?
[18:27] <uau> saste: separate libraries for audio and video might not be a bad idea
[18:27] <uau> but it's a bit late to change that now
[18:27] <uau> while it's not too late for subtitles
[18:30] <saste> uau, I'm not sure, from an high level point of view A/V/S codecs are not very different, so they benefit from a unified interface
[18:32] <uau> that's too high level to be relevant to practice
[18:33] <cone-97> ffmpeg.git 03Stefano Sabatini 07252746d05265: lavu/imgutils: add consistency checks to av_image_copy_plane()
[18:40] <durandal11707> so too support subtitles one would need to start from 0 ?
[18:46] <cone-97> ffmpeg.git 03Peter Ross 072d954ccd84e6: rawdec: use av_image_check_size
[18:46] <cone-97> ffmpeg.git 03Peter Ross 07a246a603bf81: avrndec: use av_image_check_size
[18:46] <cone-97> ffmpeg.git 03Peter Ross 0733181975b5ac: mpsmpeg4: use av_image_check_size
[19:07] <ubitux> wm4: decoders would output the "AVSubtitle2", and then the app would encode it to whatever markup its rasterizer needs (so plain text if mplayer osd or printf, ass if libass, maybe nothing if it has its own one, etc)
[19:11] <ubitux> now it's likely the decoders will continue to output also ass for a while, since most apps might not want to do the "encoding step"
[19:12] <wm4> what decoders output ass for non-ass subtitles?
[19:12] <ubitux> all of them
[19:13] <ubitux> remember, that's the internal representation.
[19:13] <ubitux> even the raw text decoder is actually outputing ass subtitles
[19:14] <ubitux> because ass is supposed to be the format with the most features, and because apps can just send them to libass directly
[19:17] <uau> i wonder if zgreg would be willing to drop support for the mangled ffmpeg packet format from libass
[19:18] <ubitux> uau: i really don't mind changing this you know
[19:18] <ubitux> but it will break everything.
[19:19] <ubitux> michaelni: btw, any comment on the ass demuxer? (and the patches it depends on)
[19:19] <ubitux> (afaik you're the maintainer)
[19:21] <ubitux> uau: it will be fairly easy to just make the ass demuxer output real ass packets, the lavf demuxer output them verbatim as well, and make the muxers deal with "muxed" ass
[19:21] <wm4> uau> i wonder if zgreg would be willing to drop support for the mangled ffmpeg packet format from libass <- this doesn't make any sense
[19:21] <uau> wm4: how so?
[19:21] <ubitux> the problem is, if apps are using ass_process_data(), on pkt->ass it will break them
[19:21] <ubitux> (i mean unconditionnally)
[19:21] <wm4> even mplayer originally used the function you're probably referencing for some purpose other than ffmpeg interop
[19:22] <wm4> and why would this function be dropped? not like it causes trouble
[19:22] <ubitux> wm4: ass_process_data() isn't that useful
[19:22] <ubitux> it's useful if you're reading line by line an .ass thought 
[19:22] <ubitux> but i can make the ass demuxer output proper packets instead so&
[19:23] <ubitux> uau: so anyway, what do you propose?
[19:24] <wm4> hm actually I'm not so sure what libass originally provided this function for
[19:24] <ubitux> maybe add a demuxer option?
[19:24] <uau> wm4: aurelien added ass_process_data to libass explicitly because he wanted to add his stupid mangled subtitle format to ffmpeg
[19:24] <uau> it was not there for any "natural" reason
[19:25] <ubitux> maybe i'll add an option to the mkv demuxer
[19:25] <ubitux> (and ass demuxer)
[19:25] <wm4> still, it's a rather small function, why remove it?
[19:26] <wm4> just to accelerate politics inside of ffmpeg?
[19:26] <ubitux> wm4: to force ffmpeg to change its format
[19:26] <wm4> :/
[19:26] <ubitux> again, i'm fine changing it, but i see no easy way without breaking things
[19:26] <ubitux> and of course if you want your player to also work with old ffmpeg or libav, you'll be fucked as well
[19:27] <ubitux> i'm not sure libav can change it that easily btw, since they are lacking quite a bunch of timing changes
[19:27] <cone-97> ffmpeg.git 03Stefano Sabatini 07cf6c6134cd61: doc: add libswscale.texi and ffmpeg-scaler.texi files
[19:52] <michaelni> ubitux, i dont think iam ass demuxer MAINTAINER, except by lack of anyone else actively doing it.
[19:52] <ubitux> aren't you the author? :p
[19:52] <michaelni> maybe :(
[19:53] <ubitux> :)
[19:53] <michaelni> if you or uau want to take over maintainership of the ass demuxer i sure have no objections
[19:54] <ubitux> i think uau concern is about something else
[19:54] <ubitux> it's all about the fact that our subtitles decoders output a ass markup as if they were line from a ass file
[19:54] <wm4> ubitux: in general, I think it'd be preferable to keep all subtitles in their "most native" format as possible
[19:55] <ubitux> wm4: then just demux them.
[19:55] <wm4> ubitux: if there's a separate library that can do generic subtitle conversion, that can be separate
[19:55] <ubitux> ffmpeg is all about conversion
[19:55] <ubitux> if you don't want convert, just demux the subtitles
[19:55] <ubitux> it will do exactly what you want
[19:55] <wm4> ubitux: and creating a generic internal format that is a superset of all other subtitle formats sounds like it'll be a big mess
[19:55] <ubitux> it's already the case
[19:56] <ubitux> it's all "FFmpeg's ASS"
[19:56] <wm4> ubitux: most attempts to convert subs using more special features will probably fail to produce usable results
[19:56] <ubitux> it works here, and it will be better with what i'm doing
[19:56] <ubitux> what you want is just a demuxer
[19:56] <wm4> ubitux: what I'm trying to say: if there's such an internal format, it should be actually internal of a separate subtitle conversion library
[19:56] <ubitux> and we already do this
[19:57] <wm4> ubitux: which can take packets in proper subtitle formats as in/output
[19:57] <wm4> k
[19:57] <ubitux> our demuxers split the subtitles into events, put the timing & duration info in the packet, the text/markup is unmodified
[19:57] <ubitux> that's what you want
[19:58] <ubitux> now i also want people to be able to convert properly these subtitles, that's why i'm writing this
[19:58] <ubitux> instead of our current ass-hacks
[19:58] <ubitux> wm4: moving the internal representation outside is complicated to make the link with codecs
[19:59] <wm4> what I can see happening is that everyone is suddenly using (or somehow supposed to be using) that internal representation, even if that wasn't planned for
[19:59] <ubitux> it supposed to.
[20:38] <durandal11707> ubitux: i cant disable metadata
[20:38] <cone-97> ffmpeg.git 03Stefano Sabatini 0751e9f58e1c9c: lavu/opt: add support for reading pixel and sample format through av_get_int()
[20:38] <cone-97> ffmpeg.git 03Stefano Sabatini 07e55c3857d20b: lavc/utils: check return value of avcodec_fill_audio_frame() for < 0
[20:45] <ubitux> durandal11707: mmh ?
[20:50] <durandal11707> ubitux: the only way to disable encoder tag is to use bitexact flag
[20:50] <ubitux> oh, isn't that one of the few fields added by FFmpeg?
[20:52] <ubitux> (the only one?)
[22:40] <cone-97> ffmpeg.git 03Michael Niedermayer 07579d21f777ea: tga: check palette size earlier.
[23:05] <cone-97> ffmpeg.git 03Michael Niedermayer 07b5b9686615e2: imc: flush decoder
[23:06] <cone-97> ffmpeg.git 03Carl Eugen Hoyos 07d643dd5c55c9: Support switching field order when decoding frwu.
[23:18] <cone-97> ffmpeg.git 03Ivan Pozdeev 07329b8f85b048: doc/encoders: add a note for x264 options that use colon
[23:57] <cone-97> ffmpeg.git 03Stefano Sabatini 07b473c9937ebe: lavu/samplefmt: return the size of the allocated samples buffer at the next bump
[00:00] --- Mon Nov 26 2012