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

[burek]

[00:02] <jamrial> it should be functional. we have fate tests for it. no idea if it's feature complete, though
[00:02] <jamrial> ask mraulet
[00:08] <ubitux> ass demuxer will soon output "mkv ass" packets
[00:08] <nevcairiel> i thought you wanted to get away from mkv ass
[00:08] <ubitux> then i'll work on making the decoded sub using that form
[00:08] <ubitux> nevcairiel: the opposite
[00:08] <ubitux> i don't want the decoded form to include the timestamps
[00:08] <nevcairiel> well no complaints here, directshow uses mkv-ass
[00:10] <nevcairiel> for the longest time ffmkv just converted everythign away from the mkv format tho
[00:10] <ubitux> yes, i fixed that
[00:10] <ubitux> since last major bump it now outputs the correct packet format
[00:20] <cone-934> ffmpeg.git 03Michael Niedermayer 07master:5312fb13b47c: RELEASE_NOTES: add version numbers
[01:22] <cone-934> ffmpeg.git 03Andreas Cadhalpun 07master:8f537420ae71: doc: mention in APIChanges that AVProbeData must be initialized due to the new mime_type field
[02:02] <cone-934> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:4c8be331bcd5: ffserver: use correct error for stream not found
[02:02] <cone-934> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:2638af2fc5ec: ffserver: drop custom skip_spaces() impl
[03:18] <cone-934> ffmpeg.git 03Andreas Cadhalpun 07master:365b9cf6245e: doc: mention important API changes in the RELEASE_NOTES
[07:31] <Timothy_Gu> ubitux, would you please apply parts of my release notes if you have time as I won't be able to finish it and michaelni is releasing it tomorrow? Thank you so much.
[07:35] <ubitux> Timothy_Gu: huh?
[07:35] <ubitux> you mean i have to split and reword what you started?
[07:40] <wm4> btw. I just realized I didn't post my PGS patch again
[07:40] <wm4> too late for 2.4?
[07:42] <ubitux> i don't see the branch created yet
[07:42] <ubitux> what pgs sub btw?
[07:42] <wm4> extracted bluray bitmap subs
[07:47] <ubitux> Timothy_Gu: anyway, working on it.
[07:47] <ubitux> wm4: ah, the .sup thing?
[07:50] <ubitux> Timothy_Gu: i don't know what's the state of the API/ABI in 2.4, but we bumped major so... i would guess a lot of things changed in both
[07:50] <wm4> ubitux: yes
[07:53] <ubitux> dunno, it will require a minor bump
[07:53] <ubitux> it's not branched out yet, but the library versions are already written to the RELEASE_NOTES
[07:54] <ubitux> that can be adjusted of course but well..
[07:54] <jamrial> ubitux: add a line about utf16 support to changelog/release_notes while at it since it wasn't done when the code was committed
[07:55] <ubitux> right
[07:55] <ubitux> i need help with the API/ABI stuff
[07:55] <ubitux> someone needs to summarize what happened
[07:55] <ubitux> we had a major bump, so API & ABI "broke", right?
[07:56] <jamrial> ABI yes, API sorta
[07:56] <jamrial> we dropped some deprecated functions with the bump
[07:56] <jamrial> check the link i posted some hours ago. they are listed there
[07:56] <ubitux> i'm pretty sure the FF_API_* stuff changed behaviours
[07:57] <ubitux> the bump at least made matroska output the correct ass packets :p
[08:00] <jamrial> wonder if people will stop reinventing the wheel (aka, rewritting their own demuxers) for their projects from now on, then :p
[08:01] <ubitux> there are a few missing features in our mkv demuxer / lavf api
[08:01] <jamrial> anyway yeah, the deprecated functions were all inside a couple FF_API_* that we didn't bother to postpone
[08:04] <rcombs> namely, editions and ordered chapters, and maybe segment linking as well
[08:04] <wm4> and these things are not trivial at all
[08:04] <rcombs> it's true!
[08:05] <wm4> although mpv would use the lavf demuxer even if the demuxer just exports ordered chapter metadata
[08:05] <wm4> (instead of implementing them fully)
[08:05] <rcombs> I have a patch laying around that adds support, but it's a bit of a mess
[08:05] <rcombs> and it's based on an old branch that was previously rejected
[08:14] <ubitux> i like how libav release not mention an api compatibility and in the same file says "A number of additional APIs have been introduced ..."
[08:15] <ubitux> notes*
[08:15] <wm4> ubitux: additional APIs don't mean breaking existing APIs
[08:15] <wm4> but I suppose adding mimetypes to AVProbeData is somewhat of a break
[08:16] <wm4> (it actually broke at least 1 application)
[08:16] <wm4> still pretty innocent
[08:16] <ubitux> "innocent" erm
[08:17] <wm4> technically there's no API break
[08:17] <wm4> but it went less "bumpy" than intended
[08:17] <wm4> oh wait, you said deprecated APIs are gone?
[08:20] <ubitux> it seems it is in FFmpeg but i haven't confirmed in Libav
[08:23] <ubitux> maybe they are
[08:25] <ubitux> so, will 2.4 be a LTS?
[08:30] <jamrial> don't we pretty much support every version to a certain extent?
[08:30] <jamrial> i mean, a month ago there was a point release of the 0.10 branch
[08:31] <ubitux> that's because it's branched out of libav 0.8 or something
[08:31] <ubitux> so the same commits are backported or something
[08:34] <ubitux> meh, using my pro address.
[08:41] <ubitux> ah i forgot some changes from Timothy_Gu 
[08:42] <ubitux> actually i forgot to actually check the diff
[08:57] <ubitux> ok, back to useful stop now
[08:57] <ubitux> rewarding stuff*
[09:24] <rcombs> so, iirc the thing that primarily prevented ordered chapter parsing from making it into ffmpeg master was discovering the segment files, because Matroska just gives you a UUID, rather than a filename or a path
[09:25] <rcombs> so the patch that added ordered chapters a while back was refused partially because it stuck directory listing in AVIO, and it was considered not to belong there
[09:34] <wm4> I don't appreciate it either if ffmpeg just randomly opens files
[09:35] <nevcairiel> well, anything else is plagued with huge complexity
[09:45] <ubitux> wm4: can be optional ofc
[09:45] <ubitux> but if ffmpeg/ffplay are able to do that transparently, that would be could
[09:45] <ubitux> it will mean we could have correct playback, and we could also use ffmpeg to stack up all the files into one
[09:46] <wm4> I'm still a bit of the opinion that piecing the segments is the job of code between player and demuxer, not in the demuxer
[09:49] <rcombs> wm4: so, when transcoding, you would have that job be handled by ffmpeg.c?
[09:49] <ubitux> just made the ass demuxer output ass packets, yay.
[09:49] <rcombs> ubitux: as in, with the timestamps stripped?
[09:49] <wm4> rcombs: ffmpeg.c simply could handle it as playlist (and could use the some code to concat files)
[09:49] <ubitux> rcombs: yes
[09:49] <rcombs> :D
[09:49] <ubitux> not a huge patch actually
[09:50] <wm4> ubitux: oh, nice
[09:50] <wm4> so there's only 1 packet format
[09:50] <ubitux> http://b.pkh.me/0001-avformat-assdec-output-ASS-packets.patch
[09:50] <rcombs> is matroskadec.c outputting that format as well, now?
[09:50] <ubitux> yes
[09:51] <rcombs> goody
[09:51] <ubitux> the only remaining ssa code stuff remains in... nut!
[09:51] <wm4> that's nuts
[09:51] <ubitux> but i don't want to care about
[09:51] <wm4> (hey, better than an ASS pun)
[09:51] <ubitux> haha
[09:54] <ubitux> ok it works nicely now
[09:54] <ubitux> the order from the original file is stored through readorder when doing ffmpeg -i input.ass -c copy output.mkv
[09:54] <ubitux> and it can be reconstructed properly when doing the other way around
[09:55] <ubitux> now i need to fix the decoded form in AVSubtitle->ass
[09:55] <ubitux> so it's also reconstructed properly when transcoding
[09:56] <wm4> you've probably broke concat of ass tracks
[09:56] <rcombs> how did that work?
[09:56] <rcombs> (concat demuxer?)
[09:57] <ubitux> wm4: mmh good point :)
[09:58] <ubitux> wm4: but that's true for many formats i would guess
[09:58] <ubitux> not sure what could be done about that
[09:58] <rcombs> how does that work with the header?
[09:58] <ubitux> it doesn't
[09:58] <ubitux> :D
[09:58] <wm4> ordered chapters have the same problem
[09:59] <rcombs> ubitux: move readorder to a field in AVSubtitle?
[09:59] <wm4> that's why ordered chapters sometimes work better in mpv than other players
[09:59] <rcombs> (except not, because that'd require a whole new packet format and that's a mess)
[09:59] <ubitux> rcombs: won't help for remuxing
[09:59] <rcombs> so, shift ReadOrder in the text when concatenating?
[09:59] <ubitux> which is the purpose of concat
[10:00] <ubitux> yes but where does this logic belong?
[10:00] <ubitux> an exception in concat demuxer?
[10:00] <ubitux> we probably need capabilities in codecs
[10:01] <rcombs> good question
[10:01] <ubitux> to say which packets are concat compliant
[10:01] <ubitux> and which aren't
[10:01] <rcombs> could have an API to provide offsetting?
[10:02] <ubitux> yeah maybe
[10:04] <rcombs> you'd need to know the maximum ReadOrder in the stream, though
[10:04] <rcombs> so you'd have to have read the whole thing
[10:05] <wm4> keep in mind that libass will drop packets with duplicate readorder
[10:05] <ubitux> there is something funny btw
[10:05] <ubitux> the matroska specs starts at readorder=1
[10:06] <ubitux> but every file i have here starts at 0
[10:06] <ubitux> so the code i wrote expect the readorder to start at 0 as well
[10:06] <ubitux> but if a matroska is muxed "properly", starting at readorder=1
[10:06] <wm4> matroska spec actually being correct? can't have that
[10:07] <ubitux> the muxer will wait until the end of the stream for the readorder entry 0
[10:08] <rcombs> ubitux: and then give up on 0 and start from 1?
[10:10] <wm4> the "spec" isn't very precise about this
[10:11] <wm4> I find the "1" only in an example
[10:11] <wm4> and mkvtoolnix uses 0 as base - I'd just assume it's an error
[10:12] <rcombs> can we at least assume nothing's dumb enough to go negative?
[10:22] <ubitux> rcombs: the muxer doesn't write the readorder, so there is just a stack orderered by those
[10:22] <ubitux> and the muxer waits for the next expected readorder in that stack
[10:22] <ubitux> and for every packet it tries to flush that stack as long as the expected readorder matches the readorder
[10:23] <ubitux> if there is a gap, it's waiting for more
[10:23] <ubitux> and at the end, it flushes the stack, wheither there is gaps or not
[10:25] <ubitux> can anyone have a look to the 0.6 branch cut?
[10:25] <ubitux> in doc/APIchanges
[10:26] <rcombs> what about it?
[10:26] <ubitux> i had to move it
[10:26] <ubitux> because it doesn't match what i found in 0.6 branch
[10:26] <ubitux> i suspect some nastiness
[10:27] <rcombs> I notice a few "NOTE: this was backported to 0.6"s
[10:27] <ubitux> grumbl
[10:27] <ubitux> indeed
[10:29] <wm4> 0.6, isn't that prehistoric?
[10:30] <ubitux> it is, but i was trying to have proper cuts in the APIchanges file
[10:30] <wm4> ah
[10:30] <wm4> oh
[10:30] <ubitux> but with backported changes, that's indeed confusing
[12:50] <cone-371> ffmpeg.git 03Clément BSsch 07master:b97e27082bb3: doc/APIchanges: attempt to split releases
[12:50] <cone-371> ffmpeg.git 03Michael Niedermayer 07master:fa1b5631964b: doc/APIchanges: Update hashes and dates
[12:59] <ubitux> so, i'm going to create a new sub struct
[12:59] <ubitux> in libavutil, and just for text subtitles
[13:00] <wm4> omg
[13:00] <ubitux> AVTextSubtitle { char *dialog; int64_t start; int64_t end; }
[13:00] <ubitux> do we need anything else?
[13:01] <wm4> format
[13:01] <ubitux> why?
[13:01] <wm4> because there are various subtitle formats
[13:01] <ubitux> it's for generic (ass) decoded markup
[13:01] <ubitux> every decoder will output this
[13:01] <ubitux> every text subtitles decoder*
[13:01] <wm4> you probably want to have more flexibility here
[13:01] <ubitux> indeed
[13:02] <wm4> so you're not stuck with ass if you find something better
[13:02] <ubitux> so a format for "ass" vs "text"
[13:02] <ubitux> alright, and maybe assv5 later
[13:02] <ubitux> fine with me
[13:02] <ubitux> what else?
[13:02] <wm4> but I'm still unsure what the general architecture should be, so I can't suggest much
[13:03] <wm4> e.g. using "decoders" to convert subtitles is not ideal, to say the least
[13:03] <ubitux> it works relatively well so far
[13:03] <wm4> not really
[13:04] <J_Darnley> Make the API private you you can change it as much as you like?
[13:04] <ubitux> it's for the user
[13:04] <wm4> ubitux: for example, you could argue an ASS decoder should take ASS as input, and output a list of bitmaps to blend as output
[13:04] <ubitux> it will be heap allocated through a helper so we can add field, but the 4 first field at least will be for public use
[13:05] <wm4> but then, to render srt, you'd have to chain 2 decoders (????)
[13:05] <ubitux> erm
[13:05] <ubitux> i don't think that logic belongs in the decoders
[13:05] <J_Darnley> A subtitle renderer shold definitely be separate
[13:06] <J_Darnley> As should an OCR module
[13:06] <wm4> J_Darnley: but vobsub and pgs also use decoders for packet->bitmaps
[13:06] <ubitux> the rendering is too close related to other stream (’ the video one)
[13:06] <ubitux> we'll make an AVBitmapSubtitles later
[13:06] <nevcairiel> if you're redesigning stuff, i want a renderer that can give me the subtitle bitmaps for me to do with as I please, not only one that is designed to render it directly onto the video
[13:07] <ubitux> for the bitmap sub codecs, or if you want a rasterizer codec
[13:07] <wm4> maybe nicolas george is right, and it should all just be a giant graph (actually he certainly is right, but it shouldn't be lavfi)
[13:07] <nevcairiel> ie. no avfilter
[13:07] <ubitux> now, i need comment for the closed caption stuff
[13:08] <ubitux> do we want to handle that here?
[13:08] <ubitux> (aka within the suggested AVTextSubtitles thing)
[13:08] <nevcairiel> if ffmpeg would provide a cc -> text decoder, i would certainly use it
[13:09] <wm4> don't CCs have 4 streams in one packet?
[13:12] <ubitux> so, how am i going to call the new av sub decode routine so it doesn't conflict with a potential dev from libav?
[13:12] <ubitux> who bets they're going to design a new subtitles api?
[13:12] <nevcairiel> of course they will
[13:12] <wm4> I haven't heard anything about such ideas
[13:12] <ubitux> :(
[13:12] <wm4> elenril is not interested in subs, so it won't happen either
[13:13] <wm4> koda was once interested in backporting subtitle stuff, but apparently gave up on that
[13:13] <wm4> I wouldn't worry
[13:13] <ubitux> ok
[13:21] <ubitux> is it better to have the start/end ts associated with a time base field, or people would prefer a AV_TIMEBASE ts, or ms or something?
[13:22] <ubitux> (having in tb field makes simplifications in internals and allow reducing the number of inaccuracy with the different rescaling)
[13:23] <wm4> like with packets and avframes, the timebase should probably be external?
[13:27] <ubitux> yeah it would be the stream tb i guess
[13:27] <wm4> if it ends up as ASS anyway, you could hardcode the ASS timebase
[13:27] <wm4> which is 10ms
[13:28] <ubitux> i don't want to
[13:28] <ubitux> just like you said, it can change in the future, i added a format field
[13:28] <ubitux> and assv5 will probably have a better resolution
[13:28] <ubitux> also, the ts isn't in the data anymore, so it can be expressed in any tb
[13:31] <nevcairiel> 10ms resolution? that seems kinda coarse
[13:31] <nevcairiel> cant even match video frames properly
[13:33] <wm4> yeah
[13:37] <saste> wm4, are you going to VDD?
[13:38] <wm4> no
[13:39] <saste> most irc people don't go to such meetings indeed
[13:40] <saste> so there won't be much to discuss, probably...
[13:40] <ubitux> does anyone mind if i add this to the RELEASE_NOTES? :
[13:40] <ubitux>    As usual, if you have any question on this release or any FFmpeg related
[13:40] <ubitux>    topic, feel free to join us on the #ffmpeg IRC channel (on
[13:40] <ubitux>    irc.freenode.net).
[13:41] <Compn> i dont
[13:42] <cone-371> ffmpeg.git 03Clément BSsch 07master:5eef7042d8a2: Changelog/RELEASE_NOTES: prepare for 2.4
[13:42] <ubitux> thx
[13:49] <rcombs> you don't mind, or you don't have any question on this release or any FFmpeg related topic?
[13:49] <rcombs> :P
[13:51] Action: ubitux bugs
[13:53] <Compn> simple binary answer to binary question
[15:43] <cone-371> ffmpeg.git 03Clément BSsch 07fatal: ambiguous argument 'refs/heads/release/2.4': unknown revision or path not in the working tree.
[15:43] <cone-371> Use '--' to separate paths from revisions
[15:43] <cone-371> refs/heads/release/2.4:HEAD: Changelog/RELEASE_NOTES: prepare for 2.4
[15:58] <cone-371> ffmpeg.git 03Andrew Stone 07release/2.4:04361427e65a: Revert "lavf: eliminate ff_get_audio_frame_size()"
[15:58] <cone-371> ffmpeg.git 03Anton Khirnov 07release/2.4:7dfccac20c0c: electronicarts: do not fail on zero-sized chunks
[15:58] <cone-371> ffmpeg.git 03Diego Biurrun 07release/2.4:e8f2823f0651: vsrc_movie: Adjust a silly typo from b977b287f61fea48ecd6251d54a26334213b7ec6
[15:58] <cone-371> ffmpeg.git 03Diego Biurrun 07release/2.4:d04fb118684f: error_resilience: Drop asserts from guess_mv()
[15:58] <cone-371> ffmpeg.git 03Diego Biurrun 07release/2.4:d2bad216f775: mpeg12enc: Add missing #include for PICT_FRAME
[15:58] <cone-371> ffmpeg.git 03Diego Biurrun 07release/2.4:63795fe5b967: setpts: Add missing inttypes.h #include for PRId64
[15:58] <cone-371> ffmpeg.git 03Diego Biurrun 07release/2.4:0263750a0db7: vfwcap: Add fallback define for HWND_MESSAGE
[15:58] <cone-371> ffmpeg.git 03Luca Barbato 07release/2.4:8c91414803e4: vc1: Fix the skip condition
[15:58] <cone-371> ffmpeg.git 03Anton Khirnov 07release/2.4:c2d6cc2971b3: mpegenc: limit the maximum muxrate
[15:58] <cone-371> ffmpeg.git 03Anton Khirnov 07release/2.4:7c4685507498: avconv: fix the muxrate values for -target
[15:59] <cone-371> ffmpeg.git 03Anton Khirnov 07release/2.4:e2a89f7f0f8f: avconv: fix parsing the AVOptions for -target
[15:59] <cone-371> ffmpeg.git 03Luca Barbato 07release/2.4:ee099059e71e: vc1: Initialize start_code_found to 0
[15:59] <cone-371> ffmpeg.git 03Luca Barbato 07release/2.4:e62f08ca8d6e: pulse: Add a wallclock option to be compatible with other other captures
[15:59] <cone-371> ffmpeg.git 03Anton Khirnov 07release/2.4:1f52f82a55a5: doc/APIchanges: fill in missing hashes and dates
[15:59] <cone-371> ffmpeg.git 03Vittorio Giovara 07release/2.4:5694831e0693: matroska: list supported extensions
[15:59] <cone-371> ffmpeg.git 03Vittorio Giovara 07release/2.4:110841c3ab1d: avcodec: add stream-level stereo3d side data
[15:59] <cone-371> ffmpeg.git 03Vittorio Giovara 07release/2.4:152e09fde7f6: matroskadec: parse stereo mode on decoding
[15:59] <cone-371> ffmpeg.git 03Vittorio Giovara 07release/2.4:5b740d1eaa63: matroskaenc: convert avstream stereo3d side data during encoding
[15:59] <cone-371> ffmpeg.git 03Diego Biurrun 07release/2.4:4cde8bae4927: license: Mention that vf_interlace is GPL, not LGPL
[15:59] <cone-371> ffmpeg.git 03Reinhard Tartler 07release/2.4:b5d4f49e3cb1: Prepare for 11_beta2 Release
[15:59] <cone-371> ffmpeg.git 03Michael Niedermayer 07release/2.4:480633c6c2e1: avcodec: fix missing doxygen comment marker
[15:59] <cone-371> ffmpeg.git 03Anton Khirnov 07release/2.4:9d3e69ae3013: Add release notes for 11.
[15:59] <cone-371> ffmpeg.git 03Diego Biurrun 07release/2.4:07b0ccf5116c: Mark 11 release in the changelog
[15:59] <cone-371> ffmpeg.git 03Sean McGovern 07release/2.4:7d8ebb877408: Fix RELEASE identification
[15:59] <cone-371> ffmpeg.git 03Diego Biurrun 07release/2.4:4f2d4b98fc98: doc: Fix syntax and logical errors in avconv stream combination example
[15:59] <cone-371> ffmpeg.git 03Diego Biurrun 07release/2.4:f851477889ae: Prepare for 11 release
[15:59] <cone-371> ffmpeg.git 03Michael Niedermayer 07release/2.4:547cad8c81c1: Merge commit 'f851477889ae48e2f17073cf7486e1d5561b7ae4' into release/2.4
[16:01] <cone-371> ffmpeg.git 03Michael Niedermayer 07master:da2186be81b5: MAINTAINERS: Add 2.4 to maintained releases, drop 2.3
[16:01] <cone-371> ffmpeg.git 03Michael Niedermayer 07release/2.4:66ac5b96e80a: MAINTAINERS: Add 2.4 to maintained releases, drop 2.3
[16:53] <cone-371> ffmpeg.git 03Michael Niedermayer 07master:68bca03951b3: doc/examples: remove unneeded NULL checks
[16:53] <cone-371> ffmpeg.git 03Michael Niedermayer 07master:808db3e68778: Changelog: add 2.4
[17:16] <cone-371> ffmpeg.git 03Michael Niedermayer 07master:b227be34db76: avcodec/mjpegenc: the AMV encoder doesnt support yuv422
[17:51] <cone-371> ffmpeg.git 03Michael Niedermayer 07release/2.4:c16e80ee3d1c: doc/examples: remove unneeded NULL checks
[17:52] <cone-371> ffmpeg.git 03Michael Niedermayer 07release/2.4:703bd3164736: Changelog: add 2.4
[17:52] <cone-371> ffmpeg.git 03Michael Niedermayer 07release/2.4:ace90ee26550: avcodec/mjpegenc: the AMV encoder doesnt support yuv422
[18:28] <ubitux> wm4: btw, now that i think about the concat & ass muxer with readorder
[18:28] <ubitux> i think it won't be hard to handle that situation
[18:29] <ubitux> the ass muxer need to be adjusted to handle discontinuities
[18:29] <ubitux> and doing this in a simple way is possible
[18:29] <ubitux> just keeping track of every occured readorder, and if you get it twice, you force-flush the current stack, and reset expected readorder, then go on this
[18:30] <ubitux> i'll eventually take the time to do that
[18:31] <ubitux> unrelated, what is public in AVCodec?
[18:31] <wm4> you still can't write the same readorders to the file
[18:31] <wm4> if you e.g. mux to mkv
[18:31] <ubitux> ah, finally found the public/private cut in the comments.
[18:32] <wm4> someone should also take the time to move non-public fields to an internal struct
[18:32] <ubitux> wm4: that's write, the mkv muxer needs adjustment
[18:32] <ubitux> right*
[18:36] <cone-371> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.4': unknown revision or path not in the working tree.
[18:36] <cone-371> Use '--' to separate paths from revisions
[18:36] <cone-371> refs/tags/n2.4:HEAD: avcodec/mjpegenc: the AMV encoder doesnt support yuv422
[19:09] <cone-371> ffmpeg.git 03Clément BSsch 07master:fcfa3ebed134: avcodec/utils: remove avcodec_ prefix for internal symbol
[19:21] <ubitux> 2.0 tag was added in the main line but not the following?
[19:37] <michaelni> n2.0 is exactly on the last commit that is in both release/2.0 and master
[19:39] <ubitux> and every other release was tagged within a commit in the branch itself?
[19:41] <michaelni> v0.8 is on libavs master branch and as we merge that also on ours
[19:42] <michaelni> the tag isnt though in our repo 
[19:46] <ubitux> i'm thinking of post n2.0
[19:46] <ubitux> like n2.1, n2.2, ..
[19:48] <michaelni> they are all after the branchpoints, you can see this with git log master..n2.1 vs. git log master..n2.0
[19:49] <ubitux> mmh i see
[19:50] <ubitux> ok
[20:00] <cone-371> ffmpeg.git 03Clément BSsch 07master:b24d74e44ae5: avcodec/microdvddec: indent fix
[20:29] <cone-371> ffmpeg.git 03Deb Mukherjee 07master:04b0dda85319: avcodec/libvpxdec: Adds decode support for formats other than 420
[20:34] <ubitux> we need to send srt and ssa decoders to hell
[21:21] <wm4> amazing, ffmpeg has public fields that are not public
[21:21] <wm4> e.g. AVFrame.channels
[21:21] <wm4> it's designated as public, but "Code outside libavcodec should access this field using:     * av_frame_get_channels(frame)"
[21:22] <BtbN> Just a deprecated way of accessing it, what's so special about it?
[21:23] <ubitux> michaelni: re: Ticket #3929 / b96d864 ’ don't we need http://pastie.org/9553303 as well?
[21:24] <ubitux> (no idea how to test)
[21:25] <michaelni> probably
[21:28] <wm4> ubitux: someone requested audio visualization of this kind: http://www.youtube.com/watch?v=tYfxYBmHTp8
[21:29] <ubitux> cute
[21:29] <nevcairiel> i assume those foreign chars are lyrics
[21:29] <wm4> yes
[21:29] <nevcairiel> looks like something milkdrop could potentially do
[21:30] <ubitux> sounds kind of complex for ending up in ffmpeg
[21:30] <ubitux> but maybe J_Darnley will propose something so user could write such thing :p
[21:30] <nevcairiel> should opengl milkdrop and make it a open-source library or stuff
[21:33] <J_Darnley> You rang?
[21:34] <J_Darnley> Well, avs might be able to some of that.
[21:34] <J_Darnley> I have seen moving block presets.
[21:35] <J_Darnley> Waves are easy.
[21:36] <J_Darnley> Text is not.  I'm ignoring the avs' only text renderer as it is a mess of windows API calls.
[21:39] <ubitux> J_Darnley: did you have time to look at eq btw?
[21:40] <J_Darnley> Oh
[21:40] <J_Darnley> no I completely forgot.
[21:40] <ubitux> :(
[21:40] <J_Darnley> I'm never good at remembering to do things.
[21:44] <J_Darnley> Hey, eq is only 240 lines
[21:45] <ubitux> eq2 about the same as well iirc
[21:45] <ubitux> and if you strip the asm there isn't much remaining
[21:46] <ubitux> the most boring parts are probably the filter boilerplate (doc/writing_filters.txt is your friend) and the documentation
[21:47] <J_Darnley> I think I've already got the boiler plate done into vf_example
[21:47] <J_Darnley> (there's something else I never finished)
[22:17] <J_Darnley> Does anyone here know the range of values the vf_eq allowed for brightness and contrast?  From the code I would guess -100 to +100.
[22:19] <J_Darnley> oh, I bet the mplayer docs can tell me.
[22:22] <J_Darnley> yes, -100 to +100
[22:24] <ubitux> you probably want to rescale that to -1 .. 1
[22:39] <J_Darnley> And use a float?  I'll put that on the todo list.
[23:17] <J_Darnley> Would ptrdiff_t be the right type to pass linesize/stride into a function so that I wouldn't have to sign/zero extend in an assembly function?
[23:18] <nevcairiel> yes
[23:18] <nevcairiel> linesize is the offset between two lines, ie. the difference, hence ptrdiff
[23:18] <nevcairiel> :)
[23:18] <J_Darnley> just checking.
[23:18] <J_Darnley> In that same situation, would size_t be the right type for width and height?
[23:19] <nevcairiel> technically yes, but if its inside ffmpeg, we still use int everywhere for that
[23:19] <J_Darnley> I know.  I'm just planning ahead, a little.
[23:23] <ubitux> J_Darnley: just keep it consistent :p
[23:27] <J_Darnley> yeah, on second thought, I won't.
[23:27] <J_Darnley> I'm using ints in an array index anyway.
[23:32] <J_Darnley> okay, that might be everything
[23:33] <J_Darnley> now for the makefile and allfilters
[23:35] <J_Darnley> Oh, I think I might be missing a few includes...
[23:46] <ubitux> ah, i just understood the meaning of "bi-directional" in the fribidi context
[23:46] <ubitux> it's simply that arabic text can be in 2 directions: right to left by default, but left to right for numbers
[23:47] <nevcairiel> yeah, its really annoying to handle
[23:47] <nevcairiel> $work has its own tiny bidi library
[23:48] <nevcairiel> had to fix some punctuation issues at one time, really learned a lot about bidi rendering that day
[23:48] <ubitux> bidi is not enough anyway, you need proper context shaping
[23:48] <ubitux> i wonder what's the purpose of this half-assed library
[23:48] <rcombs> ubitux: half-assed non-thread-safe library!
[23:49] <rcombs> (unless you're on a particularly recent version or passed a particular configure arg)
[23:50] <ubitux> no he didn't release yet
[23:50] <rcombs> yeah, so you'd have to be on git
[23:50] <ubitux> i doubt anyone is running a git of fribidi
[23:50] <rcombs> I am!
[23:50] <ubitux> haha
[23:50] <rcombs> (but it's me and about 6 other people, one being the fribidi developer and the other 5 being libass guys)
[23:51] <ubitux> why do you guys need the git of fribidi?
[23:51] <rcombs> because it's thread-safe!
[23:51] <ubitux> could just rebuild the stable version, but ok :)
[23:51] <ubitux> also, not present in any release
[23:51] <ubitux> i see "Support 4-byte UTF-8 sequences"
[23:52] <ubitux> it's kind of frightening for such library
[23:52] <rcombs> sure, but we were poking at it before figuring out that there was a configure option that'd solve the problem
[23:52] <ubitux> i wonder how it's handled in pango & friends
[23:53] <ubitux> i didn't check if pango builds the internal fribidi copy with it or not
[23:53] <rcombs> and now we have a hack that puts the relevant fribidi call behind a mutex, but only if your fribidi was configured to be non-threadsafe, which we can actually check at runtime
[23:54] <ubitux> btw, you do need fribidi even when you have hb, right?
[23:54] <rcombs> yup :|
[23:54] <ubitux> erm.
[23:55] Action: ubitux needs to figure out what exact task these 2 libraries do, and where they overlap
[23:55] <rcombs> when we first ran into this problem, I asked if we could just remove fribidi in favor of harfbuzz, and was saddened to find that we couldn't
[23:56] <J_Darnley> Oh damn!  There still isn't a per-plane size factor in pixfmt descriptions.
[23:58] <ubitux> J_Darnley?
[23:58] <ubitux> rcombs: remember what was missing?
[23:59] <rcombs> ubitux: no, I think zgreg was the one who knew the details on that
[23:59] <rcombs> my understanding was that they're 2 different libs that do entirely separate things, and you happen to need both to shape Arabic and such
[23:59] <rcombs> but I don't have an excellent understanding of the topic, so take that with a grain of salt
[00:00] --- Mon Sep 15 2014