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

[burek]

[00:16] <Daemon404> i pushed the wrong version of my patch... fail @ me
[00:30] <relaxed> With my patch http://git.videolan.org/?p=ffmpeg.git;a=commit;h=a716006a7d6371a8f124be49d7ce59bcc28f9e53 , in ffmpeg you have "//    x4->params.b_open_gop     = !(avctx->flags & CODEC_FLAG_CLOSED_GOP);" commented out which renders "-flags -cgop" useless.
[00:33] <michaelni> relaxed, will be fixed in my next push
[00:35] <relaxed> michaelni: okay, just wanted to let you know.
[01:09] <saste> fuck i merged two ffprobe huge patches by chance
[01:23] <Daemon404> fun
[11:08] <saste> cia is down?
[11:12] <ubitux> hehe :)
[11:12] <ubitux> saste: yeah seems so :(
[11:18] <ubitux> saste: so will we be able to change the disposition thing before 0.12?
[11:18] <ubitux> with a section or something
[11:18] <saste> yes, patch should be trivial at this point
[11:19] <saste> i'm working on subsection selection, which is a bit tricky
[11:19] <saste> more work could be done to make the writer independent from ffprobe (and be usable outside ffprobe.c)
[12:52] <saste> ubitux: http://pastebin.com/Lt7Jdrq4
[12:52] <saste> note the "TAGS:" in place of "TAG:"
[12:54] <saste> that in order to make the default writer more generic
[12:55] <saste> the alternative would be to create [TAGS]...[/TAGS] inside the containing section
[12:55] <saste> (same for [DISPOSITION])
[12:59] <ubitux> saste: some section could be "inlined"
[13:00] <ubitux> "XXX:" vs "[XXX] ... [/XXX]"
[13:00] <ubitux> -> flag
[13:00] <ubitux> honored (in default) or not (in all the others)
[13:00] <saste> ubitux, it is what i'm doing with the default writer
[13:00] <saste> the problem is that i want to generalize the section prefix generation
[13:01] <saste> right now we adopt the rule: if tags -> prefix is "TAG:"
[13:01] <saste> generalizing it becomes: if nested section -> prefix is "PARENT_SECTION_NAME:CURRENT_SECTION_NAME:"
[13:02] <saste> so disposition => DISPOSITION:
[13:02] <saste> tags => TAGS:
[13:02] <saste> but this is breaking the output
[13:03] <saste> I could add a backward compatibility check, but I'm not eager of doing so
[13:04] <saste> default unfortunately is not the only writer which needs to be changed for the disposition thing
[13:04] <saste> only json and xml are already fine
[13:06] <burek> JEEB, demuxing a subtitle means being able to read it from file in contrast to reading the embedded subtitle stream from the source media?
[13:07] <burek> or what is the diff between demux and decode option in that table for subtitles
[13:07] <JEEB> not exactly sure about those wordings to be honest :s
[13:08] <JEEB> even if it can encode something it doesn't mean it can actually encode something else to it for example, you'd have to really look at the actual implementation regarding how much is implemented :s
[13:38] <saste> how can I escape a string with "_" in the wiki?
[13:59] <ubitux> saste: it's too bad if we can't keep compat :/
[14:00] <ubitux> afaict we only have to keep it for the default output
[14:00] <ubitux> burek: demuxing a subtitle means either spliting a file into "chunk" or extract the payload and timing from a mkv
[14:01] <ubitux> decoding a subtitle means basically interpreting the markup (like <i> tags in subrip, {\xxx} in ASS, etc)
[14:03] <burek> ubitux thx :)
[14:39] <saste> ubitux: do you have better ideas?
[14:39] <saste> i could add a check, but I prefer not to add unnecessary complexity, especially considering that only the default writer is affected by the change
[14:40] <saste> from time to time it should be expected to break syntax, especially now that we have releases
[14:41] <saste> minor changes are imho acceptable from time to time, especially if they reduce the maintenance burden on the developer
[14:48] <ubitux> the problem is about breaking compat with libav
[14:51] <ubitux> saste: what's your goal in the end with the writers?
[14:51] <ubitux> you want to expose the api for filters?
[14:52] <saste> ubitux: possible
[14:52] <saste> the long term goal is to decouple writers from ffprobe.c
[14:52] <saste> so i don't want special cases in writers code
[14:54] <saste> that would lead to more abstract/complex/slower code, but imo still shouldn't affect significantly operations
[14:54] <ubitux> well each writer has its own way of printing the data
[14:55] <ubitux> and in the default writer, the way to write the metadata is to use the "TAG" prefix
[14:55] <saste> yes that's because that was the only special case to handle when it was written
[14:56] <saste> but now the behavior can be generalized, tags are not special, they are only a "regular" section embedded in a "regular" section
[14:56] <saste> for which we can design a generic prefixing rule
[14:56] <saste> that's why TAG: => TAGS:
[14:58] <ubitux> isn't it possible for the default writer to just, in the default_init(), to just set a special def->prefix[ ] for the tags sections?
[14:59] <ubitux> and rest would likely be "generic"
[14:59] <ubitux> (on top of your last patch)
[14:59] <saste> ubitux, that's what i'm trying to avoid, no special casing
[15:00] <saste> the best would be to allow nesting [stream] ... [tags]...[/tags][/stream]
[15:00] <saste> since it would lead to much simpler and more natural code
[15:00] <saste> but i'm trying to preserve the structure of the layout
[15:01] <saste> which was designed with the rigid book/chapter/section in mind
[15:05] <ubitux> saste: maybe add a section_name -> callback map, so some writers could override the section priting in these particular cases
[15:06] <ubitux> so csv output could just void all the metadata printing, default could do a weird formatting, ...
[15:06] <ubitux> would that look sane to you?
[15:06] <ubitux> compact: {"tags", void_me}, default: {"tags", i_like_to_do_things_my_way}
[15:58] <saste> ubitux: again it is adding a special casing, while i think the code is already complex enough
[15:59] <saste> the advantage you have by keeping backward (and forkside) compatibility is imo outweight by the reduced genericity and by the added complexity
[16:20] <ubitux> i really don't really see the problem in having a special case for the default writer but well :)
[16:21] <ubitux> the cost of breaking compatibility with libav and so making it painful for the user making their scripts project-agnostic is imo higher
[16:23] <ubitux> after all, in the current situation, the exception only affect the default writer
[16:23] <ubitux> a "simple" option would be welcome btw, to strip off all metadata
[16:23] <saste> ubitux, and compact
[16:23] <ubitux> but well i still wonder how you plan to export this, so maybe this is what is bothering you
[16:24] <saste> ubitux, i'm trying to design it to be generic, so that if we need to export it (e.g. for writing log/statistics) it would be relatively painless
[16:24] <saste> also
[16:24] <ubitux> saste: ah right, they have common callbacks
[16:25] <saste> if people really want to parse the ffprobe output, they don't rely on compact/default
[16:25] <saste> they'd rather use json/xml or whatever
[16:25] <ubitux> it's pretty recent
[16:25] <saste> and from what i know avprobe and ffprobe issue different kind of output
[16:25] <saste> although more or less equivalent
[16:25] <saste> (but ffprobe has much more stuff)
[16:26] <saste> so the compatibility problem is really... a minor problem
[16:26] <ubitux> the default output is very easy to parse, and no escaping to care about (seek to '=' and get everything after)
[16:26] <ubitux> no idea
[16:27] <ubitux> i'd better wait for 0.12 before breaking it at least
[16:27] <saste> i can wait
[16:28] <saste> i'll have to break the output anywaty because of the disposition thing
[16:28] <ubitux> unless you patch the disposition thing before 0.12 :)
[16:28] <ubitux> which would be wise
[16:28] <saste> that require the compact/csv/default changes
[16:29] <ubitux> oh :(
[16:29] <saste> or i'll have to add more special casing code, which i'm not willing to do
[16:29] <ubitux> :)
[19:54] <michaelni> Tjoppen, do you have a minute to look at the mxf part of "[PATCH]Support more AVC-Intra files" ?
[19:56] <michaelni> it looks ok to me but iam not sure and if ok we should commit it asap so its in the next release
[20:30] <Daemon404> ffmpeg -i ~/test.mp4 -vcodec copy -an -bsf:v h264_mp4toannexb -f h264 ~/derp.h264
[20:30] <Daemon404> this no longer works for me ^
[20:33] <ubitux> what doesn't work?
[20:33] <Daemon404> the bsd
[20:33] <Daemon404> bsf*
[20:34] <Daemon404> $ file *h264
[20:34] <Daemon404> test3.wmv000.h264: JVT NAL sequence, H.264 video @ L 31
[20:34] <Daemon404> with_bsf.h264:     data
[20:34] <Daemon404> without_bsf.h264:  data
[20:34] <Daemon404> top = what its supposed to make
[20:49] <michaelni> Daemon404, with which revission did it last work ?
[20:51] <Daemon404> michaelni, good question
[20:51] <Daemon404> it might just not work in general
[20:51] <michaelni> seems all versions and forks i try produce "data" ...
[20:52] <Daemon404> ive had issues with that particular bsf in the past
[20:53] <Daemon404> [14:34] < MP4_maniac> iirc, ffmpeg could demux es in incorrect nalu order. possibly, it is the cause
[20:53] <Daemon404> maybe related
[21:01] Action: divVerent has a stupid question again
[21:02] <divVerent> is it "allowed" to reorder AVStreams after allocating, before writing the header?
[21:02] <divVerent> in my current code, I kinda can't avoid creating them in audio-first, video-last order
[21:02] <divVerent> and when using the "dvd" target (vob format + a few settings)
[21:02] <divVerent> then in this case it writes video files that dvdauthor refuses
[21:02] <divVerent> because the first VOBU contains no video
[21:02] <divVerent> I currently have a workaround to preallocate a stream, so I can force audio to become stream #1
[21:03] <divVerent> but if I later discover that I only want one stream, I'm still screwed
[21:03] <divVerent> so I am asking... is it "safe" to switch AVFormatContext->streams[0] and streams[1], and also switching their ->index values
[21:03] <divVerent> right before writing the header?
[21:04] <divVerent> or, is it actually a bug in the VOB muxer, and I shouldn't have to care about stream order? ;)
[21:04] <divVerent> I can reproduce this bug with the -map option too, and then create a vob that dvdauthor will refuse
[21:07] <divVerent> http://dpaste.com/806431/ - this BTW shows that stream order is apparently important
[21:08] <divVerent> now anyone who knows enough about the specs - is this a bug in dvdauthor, in ffmpeg, or both? ;)
[21:08] <divVerent> or does the DVD spec actually require video to come first
[21:18] <divVerent> this BTW is my "solution" that I am worried about: http://dpaste.com/806438/
[21:18] <divVerent> is this basically use or abuse :P
[21:21] <divVerent> (this takes place directly after allocating the 2nd stream, before writing header or encoding any data)
[22:02] <Tjoppen> michaelni: having mail troubles atm. I'll take a look tomorrow
[23:17] <ubitux> cbsrobot: did you have the opportunity to try the ebu r128 filter?
[23:18] <cbsrobot> not yet
[23:18] <cbsrobot> I didn't have time to sit down with my sounddesigner
[23:18] <cbsrobot> I'll try tomorrow
[23:19] <ubitux> thx :)
[23:19] <ubitux> i'll wait for after the 0.12
[23:20] <ubitux> so you have some time
[23:21] <saste> michaelni, where are you going to release 0.12?
[23:21] <cbsrobot> ping me tomorrow, if I don't ping you
[23:21] <cbsrobot> ^ubitux
[23:23] <ubitux> cbsrobot: sure ok :)
[23:32] <saste> michaelni, to me 0.12 or 1.0 makes no difference, that's just marketing ;-)
[23:32] <michaelni> saste, yes .... and 1.0 looks better ;)
[23:37] <ubitux> michaelni: please wait for tomorrow, i want the faststart in ;)
[23:38] <ubitux> saste: 1.0 will likely be some kind of long-term supported version
[23:38] <ubitux> so the ffprobe syntax will remain a long time
[23:38] <ubitux> are you ok with breaking "soon" the disposition thing?
[23:38] <ubitux> (and the tags?)
[23:38] <saste> ubitux, do you mean after the release?
[23:39] <ubitux> yes; it's like we had the new disposition thing for a few days
[23:39] <ubitux> but already in the "stable" release
[23:39] <ubitux> that will last forever, like 0.5
[23:39] <saste> that was my plan, seems the less worse solution
[23:39] <ubitux> i wonder if it wouldn't be better for 1.0 to drop revert (in that branch) the disposition
[23:39] <ubitux> so we won't break anything, just add things
[23:40] <ubitux> (in git/master)
[23:40] <saste> ubitux: it could be useful to have disposition in the release
[23:40] <saste> even if we'll break the syntax in git soon after the release
[23:40] <saste> so people can use the release for disposition stuff
[23:41] <saste> git will have a different syntax and will be more complete, but better than nothing
[23:41] <ubitux> and get comfortable with something stable but which is already deprecated?
[23:41] <saste> ubitux, i'm fine with either
[23:41] <ubitux> ok, well whatever then
[23:41] <ubitux> Daemon404: any opinion?
[23:41] <Daemon404> tl;dr
[23:41] <Daemon404> psl
[23:41] <Daemon404> pls*
[23:42] <ubitux> Daemon404: currently there is your ffprobe/disposition version recently added
[23:42] <ubitux> michael is going to release some kind of lts
[23:42] <ubitux> but we'll change the ffprobe/disposition syntax pretty soon in git/master
[23:42] <saste> lts... michaelni  is that the idea?
[23:43] <Daemon404> our releases are a joke
[23:43] <ubitux> even if it's not distro will interpret it as such
[23:43] <Daemon404> so are libav's
[23:43] <Daemon404> :/
[23:43] <saste> Daemon404, at least they are easy ;-)
[23:43] <ubitux> saste: "1.0" how can distro not be seduced?
[23:43] <ubitux> anyway
[23:43] <michaelni> ubitux, saste iam not really planing to support 1.0 longer than others
[23:44] <ubitux> remember debian and 0.5...
[23:44] <ubitux> we still have users with it
[23:44] <ubitux> :D
[23:44] <michaelni> i guess i should make a new release of the 0.5 branch then ...
[23:44] <ubitux> :D
[23:44] <Daemon404> debian uses libav
[23:44] <Daemon404> unless it has both
[23:45] <saste> or deprecate it altogether?
[23:45] <ubitux> Daemon404: anyway, the point was about either remove the disposition thing from 1.0, and make git/master hack the printing, with the idea of: 1.0: no-feature, git-master: new disposition feature with unstable syntax
[23:46] <ubitux> instead of 1.0: just released the disposition feature that will last forever, and git/master/2days-later: gonna break the syntax already
[23:46] <Daemon404> wasnt revertign my disposition commit for the tarball always the plan
[23:46] Action: Daemon404 /cares about tarball
[23:46] <ubitux> yeah that's what i was asking
[23:47] <ubitux> but it seems saste would like to see that feature in 1.0 anyway
[23:47] <saste> ubitux, i don't mind about releases, i mostly care about what i use (git master)
[23:47] <saste> so the question is, what's best for users?
[23:47] Action: Daemon404 sees he will have to s/tag/tags/ in his code
[23:48] <saste> since i don't know i'll let other people choose what they favor
[23:48] <ubitux> i think it's best for users willing the feature to expect changes while being forced to use git/master
[23:48] <saste> my only concern is that i want to work with maintainable/generic code
[23:48] <ubitux> instead of relying on the false-stable 1.0
[23:48] <saste> since that affects my own work
[23:48] <saste> even if that means to break syntax from time to time
[23:49] <ubitux> it's fine to break syntax from time to time in git/master
[23:49] <ubitux> but breaking just after we added it in the release sounds wrong to me
[23:49] <ubitux> no? :p
[23:50] <ubitux> it's not like i'm convinced or anything, it just feels weird to me :p
[23:50] <saste> ok so feel free to revert the new disposition feature, that would mean one feature less, but people after all managed to deal without it for years...
[23:50] <saste> so i'm ok with removing disposition support from the new release
[23:50] <saste> and keep the old TAG: syntax
[23:50] <ubitux> yes
[23:50] <ubitux> and start changing things after the release :)
[23:51] <Daemon404> eh
[23:51] <ubitux> basically we will break tags, and "add" disposition
[23:51] <Daemon404> why does that matter
[23:51] <Daemon404> make a branch
[23:51] <ubitux> instead of breaking two things
[23:51] <Daemon404> profit
[23:52] <ubitux> michaelni: i'm gonna push the faststart in ½ hour
[23:52] <Daemon404> faststart?
[23:52] <Daemon404> as in qt?
[23:52] <ubitux> michaelni: would you mind reverting 8e2a950b297b97605e97c454363f2f8555b004f0 in the 1.0 branch when you'll do the release?
[23:52] <ubitux> Daemon404: yes
[23:53] <Daemon404> ubitux, in what context?
[23:53] <ubitux> i ping two times the patch :(
[23:53] <ubitux> Daemon404: http://ffmpeg.org/pipermail/ffmpeg-devel/2012-September/131405.html
[23:53] Action: Daemon404 has been doing his job all day
[23:57] <michaelni> ubitux, ok, ill revert 8e2a950b297b97605e97c454363f2f8555b004f0 in 1.0 before tag+tar (unless there are objections)
[23:58] <ubitux> thanks :)
[00:00] --- Thu Sep 27 2012