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

[burek]

[00:00] <ubitux> j-b: if you need the video dumps of this course, let me know
[00:00] <ubitux> but only if you want them, because :effort:
[00:04] <j-b> I'll add the course
[00:05] <pippin> j-b: one mostly tend to come up with ad-hoc categorizations that makes sense in the context where one is using the filter :]
[00:05] <j-b> pippin: exactly my issue.
[00:07] <pippin> you can split according to technical signal processing criteria; and amount of dimensions taken into account - but that would often be less useful for actual use.
[00:12] <j-b> ubitux: btw, what is the format of subtitles in wtv files?
[00:12] <funman> .docx
[00:12] <j-b> I wish
[00:12] <ubitux> no idea
[00:12] <ubitux> i'm not sure i want to know though
[00:13] <ubitux> i see dvb subtitles code
[00:13] <ubitux> [~/src/ffmpeg]- grep -i 'codec.*subtitle' libavformat/wtvdec.c st->codec->codec_id = AV_CODEC_ID_DVB_SUBTITLE;
[00:13] <ubitux> only see this ^
[00:23] <ubitux> ok, reconstructing properly dvdsub, done.
[00:29] <funman> ubitux: seems to be dvbs indeed, but some samples seem to use other formats
[00:30] <kierank> "pid" based closed captions sometimes
[00:30] <ubitux> funman: dvb teletext then probably
[00:31] <funman> AV_CODEC_ID_DVB_TELETEXT
[00:31] <funman> dunno if our teletext decoder handles that
[00:31] <ubitux> st->codec->codec_id = !ff_guidcmp(subtype, mediasubtype_teletext) ? AV_CODEC_ID_DVB_TELETEXT : AV_CODEC_ID_EIA_608;
[00:36] <ubitux> ok so, still on vobsub story
[00:36] <ubitux> it seems the cases with timestamps going backward are related to those splitted spu packets
[00:37] <ubitux> i think i finally figured out most of the insanity out here
[01:39] <BBB> michaelni: works in my emulator (?) very weird
[01:40] <michaelni> BBB "make -j12 `make fate-list | grep vp8`" crashed with 1 or 2 randomly here each time
[01:43] <michaelni> do you have the patches in some branch somewhere so i can retest the exact same code you tested?
[01:45] <BBB> let me try...
[01:45] <BBB> https://github.com/rbultje/ffmpeg/tree/vp9
[01:46] <BBB> yeah it doesn't fail here
[01:46] <BBB> not sure what's going on
[01:53] <michaelni> seems passing here
[01:57] <BBB> so why does the patch fail but the tree pass?
[01:58] <BBB> should be identical code, minus the vp9 part in it
[01:59] <michaelni> i dunno, does it pass for you if you rebase the relevant patch(es) on master ?
[02:00] <BBB> let me try
[02:02] <BBB> trying now
[02:02] <BBB> takes a few minutes
[02:06] <michaelni> ive restested the local branch that crashed before, its passing now here too
[02:06] <BBB> hm...
[02:06] <BBB> odd
[02:07] <BBB> it passes here too fwiw
[02:07] <BBB> weird
[02:12] <michaelni> no crash even after multiple runs
[02:18] <michaelni> i guess in absence of better ideas, that means git push
[02:20] <michaelni> if you want me to push your rebased version instead of what i have (probably a good idea as mine was affected by that weird crash or it was PEBCAK issue) ...
[02:23] <BBB> michaelni: it merged without any offset issues here... let me rebase and make sure
[02:23] <BBB> I don't exactly have the latest tree, and I think you inverted some patch order here or there...
[02:26] <michaelni> I tried to apply patches ordered so that intermediates are fully working
[02:27] <michaelni> also i had a local hotfix for some h264 arm code that failed under qemu but not on real hw apparently but that shouldnt have affected the vp8 tests
[02:27] <michaelni> "hotfix" == disabling it
[02:28] <BBB> right no that shouldn't matter
[02:29] <BBB> let me try to rebase
[02:29] <BBB> so the patches are the armneon one and the emu-edge argument change one right?
[02:29] <BBB> and then after that ffvp9
[02:32] <michaelni> i only tested emuedge + neon fix
[02:34] <BBB> is any of the invidivual files different from my tree?
[02:34] <BBB> d<->v
[02:37] <BBB> michaelni: https://github.com/rbultje/ffmpeg rebased on latest head (both patches)
[02:37] <BBB> michaelni: seems to work for me
[02:38] <BBB> (for these 3 files on armneon/emulator)
[02:38] <BBB> michaelni: once they are in, I'll rebase ffvp9 and send a new version (if any changes are needed)
[02:41] <michaelni> seems the only difference to my tree is one newline and the hotfix
[02:43] <BBB> weird
[02:43] <BBB> well I'd just push it then
[03:11] <cone-323> ffmpeg.git 03Ronald S. Bultje 07master:f574b4da567c: vp8: use 2 registers for dst_stride and src_stride in neon bilin filter.
[03:11] <cone-323> ffmpeg.git 03Ronald S. Bultje 07master:face578d56c2: Rewrite emu_edge functions to have separate src/dst_stride arguments.
[03:58] <BBB> michaelni: ok, new ffvp9 patch (just with a merge issue in changelog) in my tree on github, branch master
[03:58] <BBB> michaelni: I can provide the fate test files if wanted
[03:58] <BBB> unless you're hoping for more review
[04:14] <michaelni> please provide he fate test files, ill upload them tomorrow (need sleep now ...)
[10:08] <ubitux> ok the insanity continues
[10:09] <ubitux> it seems the ts in the split packet are actually used to reorder them
[10:49] <ubitux> actually no it seems i have to read them by "stream order"
[10:49] <ubitux> and ignore ts
[11:37] <cone-589> ffmpeg.git 03Carl Eugen Hoyos 07master:d87ff555025e: Remove an incorrect and unneeded assert in the amr demuxer.
[12:17] <michaelni> ubitux, do you have further comments on "avcodec/tiff_common: add ff_tadd_bytes_metadata" ? should i change something or ok to push as is ?
[12:18] <ubitux> michaelni: no it's fine with me, no further comment
[12:18] <michaelni> ok thx
[12:34] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:7859e89ff0f9: avcodec/tiff_common: add ff_tadd_bytes_metadata()
[12:34] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:e40c96513efb: avcodec/exif: print bytes and undefined types as scalar lists
[12:34] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:5c4fc51d9b9f: Revert "fate: Force diff into text mode"
[13:09] <BBB> ubitux: can you upload the vp9 fate files to the server?
[13:10] <ubitux> i don't think i have write permissions
[13:10] <BBB> oh
[13:10] <ubitux> i usually ask michael
[13:10] <ubitux> less work for me too ;)
[13:10] <BBB> ok, I'll send them to him
[13:17] <BBB> done
[13:17] <BBB> kids-time now
[13:20] <BBB> ubitux: how's assmebly going btw?
[13:20] <ubitux> sorry didn't have time to continue
[13:20] <ubitux> i'm fighting with dvd & dvb subs on my free time...
[13:20] <ubitux> it's not fun but i don't like those bugs
[13:27] <BBB> doesn't ffmpeg have an infinite number of bugs, just like any other software project?
[13:27] <BBB> maybe I'm becoming too corporate :)
[13:28] <ubitux> at least one of those is because of me
[13:28] <ubitux> so it's in priority
[13:32] <Compnn> if you have urls to the samples i can put them on sample repo
[13:32] <Compnn> :P
[13:33] <luc4> Hi! I wrote this function: http://paste.kde.org/pb44c1418/. It implements a pixel format conversion from yuyv to argb manually or using ffmpeg. What I noticed, and surprised me a little is that the manual conversion is considerably faster than the ffmpeg algorithm. This is pretty weird. Any idea why? Maybe I'm using ffmpeg wrong? Maybe there is a faster algorithm than SWS_FAST_BILINEAR?
[13:43] <wm4_> luc4: I've heard more than once that swscale is slower than it should be, but it also could be that swscale is simply doing more work (as in better quality?) than yours, I'd wait to hear from michaelni 
[13:44] <wm4_> also, wasn't SWS_FAST_BILINEAR broken?
[13:45] <luc4> wm4_: sure, that is why I'm asking if I'm using it wrong, or if there is any way to make it faster and explain why the manual computation is faster.
[13:46] <luc4> wm4_: also, is that algorithm actually used to convert the pixel format when there is no resize?
[13:48] <michaelni> luc4, i dont think sws has a specific routine to do packed yuyv to argb so it converts yuyv first to planar yuv (yuyv isnt very common for video decoders ...)
[13:49] <michaelni> if thats the issue adding such unscaled special case shouldnt be hard, if thats a common convertion path for some use case
[13:51] <wm4_> michaelni: apple decoders output yuyv, apparently
[13:51] <luc4> michaelni: I see, so ffmpeg is inefficient in this case. I'll keep my implementation then. Ok, no problem. Maybe this better path may be added to ffmpeg? I'm using this cause usb cameras tipically use yuv.
[13:52] <pigoz> well, vda does. probably other stuff in coremedia does as well.
[13:52] <pigoz> (output yuyv)
[13:53] <michaelni> also calling sws_getContext() on each frame is not optimal
[13:53] <luc4> michaelni: it is static.
[13:53] <michaelni> right, sorry, missed that
[13:53] <wm4_> michaelni: I have some code that needs to convert images of varying sizes, what to do in that case?
[13:55] <michaelni> maybe sws_getCachedContext() could be used in that case
[13:56] <wm4_> I mean, the image size can change on every call (I believe sws_getCachedContext would merely detect changes, and then fully reinit)
[13:56] <michaelni> yes
[13:57] <michaelni> it reinits only when needed instead of always
[14:00] <luc4> michaelni: what about adding this to ffmpeg? Might be useful...
[14:01] <michaelni> yep thats what i meant by ".... adding such unscaled special case shouldnt be hard, ...."
[14:04] <luc4> michaelni: can you point me to where I should add this?
[14:05] <michaelni> mainly libswscale/yuv2rgb.c
[14:06] <michaelni> it will also need a 1 line change where ff_yuv2rgb_get_func_ptr() is called so its used for yuyv422
[14:09] <luc4> michaelni: thanks!
[14:13] <JEEB> luc4, it was a good idea to poke this channel, right? ;)
[14:13] <luc4> JEEB: right :-)
[14:17] <wm4_> michaelni: it's not really clear what settings sws_getCachedContext checks... for example it mentions that it doesn't check srcFilter and dstFilter; so how much equivalent is it compared to sws_init_context() on arbitrary parameter changes, even when done with av_opt_set_...?
[14:17] <luc4> michaelni: what about yuv420 to rgb conversion? Is that taking a long path as well?
[14:17] <wm4_> it's also not very orthogonal with sws_init_context()
[14:20] <michaelni> luc4, yuv420 (& planar yuv422) use the yuv2rgb code
[14:24] <michaelni> wm4_, it checks what you give it as arguments
[14:24] <michaelni> that is arguments mismatch context -> reinit
[14:25] <wm4_> ok so I could add a check in my code whether only the dimensions change, and then use that function to "update" to sws context
[14:28] <wm4_> ideally similar code should go into libswscale directly, but SwsContext really has lots of members...
[14:28] <BBB> Compn: I can fw you the email I sent to michael that explains where to get the saples, what's your email?
[14:31] <wm4_> michaelni: does sws_getCachedContext really need to free the previous context? I believe sws_init_context() can now do a full reinit
[14:31] <wm4_> or is that not the case?
[14:31] <michaelni> maybe
[14:32] <wm4_> because then one could add a sws_init_cached_context(SwsContext *sws); function
[14:32] <luc4> michaelni: ok, that code is pretty complex, maybe I could add a wish to the tracker?
[14:32] <wm4_> which internally checks for changes since last reinit
[14:34] <wm4_> hm doing that would probably work, but leak memory
[14:38] <michaelni> luc4, you certainly can, but code doesnt implement itself so i do prefer patches over wishes :)
[14:40] <luc4> michaelni: I understand of course, but I'm not an expert in pixel format conversion. The code is not completely clear to me.
[16:08] <wm4_> michaelni: AVFrame currently doesn't carry chroma position info?
[16:10] <Daemon404> i dont think anything in ffmpeg gives a crap about it?
[16:10] <wm4_> libswscale supports it
[16:15] <Daemon404> interesting
[16:29] <wm4_> #define SWS_PARAM_DEFAULT           123456
[16:29] <wm4_> sorry what
[17:09] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:a0fec71ebda1: avformat/mxfenc: instance number is just 24 bits
[17:09] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:28d35dbe9f57: avformat/mpegenc: fix muxrates AVOption maximum value
[17:09] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:8c1253c9349c: avformat/mpegenc: check, warn and clip VBV value to within syntactically possible values
[17:09] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:f2eb474a5a3d: avformat/mpegenc: check, warn and clip muxrate to syntactical possible values
[17:25] <michaelni> BBB, vp9 samples added to fate rsync
[17:54] <BBB> michaelni: ty; anything else needed for ffvp9 review?
[17:55] <BBB> j-b: you never explained why I received your hug
[17:57] <michaelni> BBB: not sure, i think it would be best if ubitux and you review each others code, as you know the code already
[17:57] <BBB> ubitux: ok with you?
[17:57] <j-b> BBB: for VDD money :)
[17:57] <BBB> (I already reviewed ubitux' patches as they were going in)
[17:57] <BBB> j-b: ah, you're welcome
[17:57] <j-b> BBB: I owe you a beer
[17:57] <j-b> or 2 :)
[17:58] <j-b> hopefully in NYC
[18:00] <BBB> I like beer
[18:00] <BBB> sounds good
[18:00] <BBB> I imagine vdd was fun?
[18:02] <j-b> BBB: I think so. People liked it
[18:02] <Daemon404> j-b in NYC???
[18:02] <Daemon404> when is this
[18:03] <j-b> Daemon404: I hope early next year
[18:03] <Daemon404> j-b, if you let me know when
[18:03] <Daemon404> i can use it a an excuse to work from our NYC office
[18:03] <Daemon404> for a little while
[18:03] <j-b> I would love to live there, actually
[18:03] <Daemon404> <.< >>>
[18:03] <Daemon404> i love nyc
[18:03] <Daemon404> but my SO hates it...
[18:03] <Daemon404> so ;)
[18:04] <j-b> change SO :)
[18:04] <Daemon404> lol
[18:04] <Daemon404> well also, the house centipedes in NYC horrify me
[18:04] <j-b> ;-)
[18:04] <Daemon404> i had them in my manhattan appartment
[18:05] <j-b> there are more than inhabitants in NYC?
[18:05] <Daemon404> http://en.wikipedia.org/wiki/Scutigera_coleoptrata
[18:05] <Daemon404> japanese call 'em gejigeji
[18:07] <BBB> house centipedes?
[18:07] <BBB> my god where did you live
[18:08] <BBB> you know there's acceptable high-end housing (ad affordable) right?
[18:08] <BBB> s/ad/and/
[18:08] <Daemon404> Chelsea
[18:08] <Daemon404> 19th and 9th
[18:08] <BBB> you guys are so willing to accept all horrors and pains just because you don't know any better
[18:08] <Daemon404> also because i was on intern salary
[18:08] <BBB> go out, see the world, visit 1000 open homes - you'll see you can get better
[18:08] <BBB> or if you don't know better, hire someone to explain it to you
[18:08] <Daemon404> and i stupidly chose to live in manhatta
[18:08] <Daemon404> n
[18:08] <BBB> you're not an intern any more
[18:08] <BBB> so that's a bad excuse
[18:09] <Daemon404> i would prefer brooklyn
[18:09] <BBB> j-b: come live in ny, it's awesome
[18:09] <Daemon404> somewhere liek park slope
[18:09] <BBB> brooklyn is nice also yes
[18:09] <Daemon404> or maybe astoria
[18:09] <BBB> park slope is expensive though
[18:09] <j-b> BBB: I'd like to.
[18:09] <BBB> but around there is nice yes
[18:09] <Daemon404> BBB, i actually prefer to have a nice largr house
[18:09] <BBB> park slope is more for if you have 4-5 kids in school-age (for public schools)
[18:10] <Daemon404> 2 floor + basement
[18:10] <Daemon404> cant get that in NYC so easil
[18:10] <Daemon404> y
[18:10] <BBB> Daemon404: oh, then try queens or long island :)
[18:10] <Daemon404> heh
[18:11] <Daemon404> im actually planning to live in the english countryside
[18:11] <Daemon404> (London is a craphole)
[18:13] <kierank> only where you live
[18:13] <Daemon404> perhaps
[18:13] <Daemon404> i do prefer a more rural area
[18:14] <Daemon404> and a nice large house
[18:14] <Daemon404> suitable for kids
[18:14] <BBB> I get the feeling daemon404 is misinformed about city-life because he doesn't know how to "get" it
[18:14] <BBB> anyway
[18:14] <BBB> battery park and park slope is good for kids
[18:15] <Daemon404> heh
[18:15] <Daemon404> i lived in park slope for a bit
[18:15] <kierank> lol kids
[18:15] <Daemon404> i didnt see any house id consider large enoug
[18:15] <BBB> I saw doutzen kroes yesterday in battery park
[18:16] <BBB> also can someone start reviewing ffvp9 for ubitux/me?
[18:16] <BBB> kierank: maybe you?
[18:16] <kierank> ok
[18:16] <BBB> if you think it looks roughly ok, that's fine, just say that as a review
[18:17] <Daemon404> i assume youve done soem minimal fuzz testing?
[18:17] <BBB> then at least we have some outside eyes (i.e. not ubitux or me) giving it a look
[18:17] <BBB> I'm doing ongoing fuzz testing, along with performance increments
[18:17] <BBB> but neither is finished yet
[18:18] <Daemon404> ive peeked at it a view times
[18:18] <Daemon404> but always decided i didnt have time at the moment to go over 10kloc
[18:20] Action: kierank watches gmail struggle with that email size
[18:31] <kierank> heh and chrome crashes
[18:36] <BBB> kierank: hehe :) use a text editor that has a "save" function ;)
[18:37] <kierank> i'm just going to copy and paste stuff
[18:38] <Daemon404> BBB, looking at it now
[18:38] <Daemon404> give me a few hrs
[18:39] <Daemon404> also it made my mail client hang for a minute when hitting reply
[18:39] <Daemon404> :D
[18:39] <Daemon404> j-b, ping me when you plan to head to NYC perhaps.
[18:39] <j-b> sure
[18:40] <j-b> if secret plan works, April
[18:40] <j-b> if it fails, before :)
[18:40] <Daemon404> oic
[18:40] <Daemon404> im in Canada for easter
[18:40] <Daemon404> so before/after works well
[18:42] <kierank> bit of a diego review but meh
[18:44] <Daemon404> uint8_t coef[4][2][2][6][6][11]
[18:44] <Daemon404> sexy
[18:45] <durandal_1707> what about adding structs?
[18:46] <j-b> VP9 \o/
[18:49] <Daemon404> yeah im trying to review it right now
[18:49] <Daemon404> a few technical issues so far...
[18:49] <Daemon404> gonna take me a while
[18:56] <durandal_1707> was decoder fuzzed at all?
[19:01] <BBB> durandal_1707: a little, not very extensively - it's being worked on (along with performance)
[19:02] <BBB> Daemon404: btw all of these dimensions are used, so yes you really need them all :)
[19:02] <BBB> and thanks for review
[19:13] Action: Daemon404 saves a draft and gets food
[19:32] <wm4_> michaelni: vf_scale calls sws_setColorspaceDetails after sws_init_context, is that valid?
[19:49] <durandal_1707> wouldn't sws_init_context overwrite what other one set?
[19:50] <wm4_> no
[19:50] <wm4_> but it does something with it
[19:50] <wm4_> (at least handling of special J* formats)
[20:19] <cone-589> ffmpeg.git 03Paul B Mahol 07master:5a47f12390d2: doc/demuxers: fix image2 examples
[20:37] <michaelni> wm4_, if it works and the docs dont say its not allowed then we probably have to consider it valid as other applications could use it that way too
[20:38] <wm4_> michaelni: I think it at least undoes the J* fallback
[20:38] <wm4_> c->srcRange |= handle_jpeg(&c->srcFormat);
[20:38] <wm4_> and this is the only place handle_jpeg is called
[20:38] <wm4_> sws_setColorspaceDetails doesn't do this
[20:39] <wm4_> although there's probably only one case where srcRange is read again after that point
[20:41] <wm4_> hm or two cases
[20:45] <michaelni> i guess that makes it invalid (in at least some corner cases)
[21:08] <ubitux> wm4_: ok i think i got it :)
[21:08] <wm4_> yay
[21:10] <ubitux> i need to cleanup my tree but it should be done in an hour or two
[21:26] <cone-589> ffmpeg.git 03Paul B Mahol 07master:61274193e3bf: avfilter/vf_rotate: use vsub for output plane height calculation
[21:32] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:4be0c6ed20f2: avcodec/tiff_common: fix bprint max sizes
[21:34] <ubitux> michaelni: automatic doesn't require finalize/free, but unlimited does, iirc
[21:35] <ubitux> michaelni: also you failed one chunk
[21:37] <michaelni> they all already had finalize
[21:37] <michaelni> unless i missed one
[21:37] <ubitux> ok
[21:37] <ubitux> -    av_bprint_init(&bp, 10 * count, AV_BPRINT_SIZE_AUTOMATIC);
[21:37] <ubitux> +    av_bprint_init(&bp, 10 * count, 100 * count);
[21:37] <ubitux> please fix this one though
[21:37] <ubitux> unless that's what you wanted?
[21:38] <ubitux> :)
[21:38] <BBB> michaelni: new patch will have one additional vp9 conformance sample
[21:38] <BBB> michaelni: so you know to update the fate ref files
[21:39] <michaelni> ubitux, i didnt think much about it but the double one doesnt use unlimited because i wanted to prevent really huge numbers from causing huge alloc and strings and metadata
[21:39] <michaelni> i can change it to unlimited if preferred
[21:40] <ubitux> no it's ok
[21:40] <ubitux> i thought it was a typo
[21:40] <ubitux> but yeah false alert, forget it
[21:40] <michaelni> BBB, do you have a url i can wget ?
[21:42] <BBB> vp90-2-03-deltaq.webm
[21:42] <BBB> same directory as the other ref files
[21:44] <michaelni> BBB uploaded
[21:45] <BBB> ty
[21:51] <durandal_1707> ubitux, saste: you ok with my dualinput simplification?
[21:51] <ubitux> i merely moved code with dualinput
[21:52] <ubitux> i didn't have much insight of it
[21:52] <ubitux> i'll make some review tonight when i'm done with vobsub
[21:52] <ubitux> hopefully in not much time
[21:59] <kierank> Paranoialmaniac: what is the point of avcc3
[21:59] <kierank> why can't they just write sps/pps in the video bitstream
[22:01] <Paranoialmaniac> kierank: ? avc3 allows conveying parameter sets in-bandly and putting filler data
[22:01] <kierank> why do they need the avc3 element?
[22:01] <Paranoialmaniac> avc3 is not an element. it's an identifier.
[22:01] <kierank> oh
[22:02] <Paranoialmaniac> like CODEC FourCC in AVI
[22:04] <Paranoialmaniac> avc3 uses the same decoder configuration avcC with avc1
[22:07] <kierank> oh i thought it was an avcc3 element
[22:07] <kierank> avcC3
[22:07] <kierank> Paranoialmaniac: what is avc2?
[22:08] <Paranoialmaniac> avc2 indicates aggregator and extractor nalu units may be present in the file
[22:08] <kierank> ah some scalable thing then
[22:09] <Paranoialmaniac> i think it is easy to add support of avc3 in libavcodec
[22:09] <Paranoialmaniac> maybe, just adding the identifier
[22:14] <Paranoialmaniac> libavcodec already can decode files conveying parameter sets in-bandly even if the stream is signaled as avc1. i had tested a file generated with mp4box which is out of spec obviously
[22:21] <ubitux> wm4_: ping
[22:22] <ubitux> wm4_: could you try this for me https://github.com/ubitux/FFmpeg/commits/vobsub ?
[22:22] <ubitux> it fixes all the issue i have with my samples
[22:22] <ubitux> so it will "probably" fix yours
[22:42] <cone-589> ffmpeg.git 03Martin Storsjö 07master:9277050e2918: vqf: Make sure sample_rate is set to a valid value
[22:42] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:554c22c71091: Merge commit '9277050e2918e0a0df9689721a188a604d886616'
[22:48] <cone-589> ffmpeg.git 03Martin Storsjö 07master:68ff9981283a: vqf: Make sure the bitrate is in the valid range
[22:48] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:b24f7cf95070: Merge commit '68ff9981283a56c731f00c2ee7901103665092fc'
[22:58] <cone-589> ffmpeg.git 03Martin Storsjö 07master:8d07258bb606: avidec: Make sure a packet is large enough before reading its data
[22:58] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:3a3ebc7c7dcc: Merge commit '8d07258bb6063d0780ce2d39443d6dc6d8eedc5a'
[23:03] <wm4_> ubitux: trying
[23:03] <cone-589> ffmpeg.git 03Martin Storsjö 07master:adc09136a4a6: xwma: Avoid division by zero
[23:03] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:17049bff64f2: Merge commit 'adc09136a4a63b152630abeacb22c56541eacf60'
[23:10] <wm4_> ubitux: appears to work! I see subtitles, and no more length 0 packets
[23:10] <ubitux> cool :)
[23:10] <ubitux> i'll submit the patchset in a moment, finishing the long explanation
[23:21] <cone-589> ffmpeg.git 03Martin Storsjö 07master:59480abce7e4: alac: Do bounds checking of lpc_order read from the bitstream
[23:21] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:9e58d46edf95: Merge commit '59480abce7e4238e22b3a4a904a9fe6abf4e4188'
[23:29] <ubitux> michaelni: so ok to drop the pascal/delphi faq entry?
[23:29] <ubitux> wm4_: patch on ml, hopefully it will be pushed soon
[23:29] <cone-589> ffmpeg.git 03Martin Storsjö 07master:28ff439efd23: mvi: Add sanity checking for the audio frame size
[23:29] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:2f8418b584d2: Merge commit '28ff439efd2362fb21e1a78610737f2e26a72d8f'
[23:29] <ubitux> wm4_: for the backport, i'll wait a bit
[23:29] <michaelni> ubitux, yes
[23:29] <ubitux> michaelni: k thx
[23:32] <ubitux> dvdsub fixed, now i need to figure out the problem with dvb ones
[23:32] <ubitux> :'(
[23:33] <cone-589> ffmpeg.git 03Clément BSsch 07master:e6273592e442: doc/faq: rework r_frame_rate entry.
[23:33] <cone-589> ffmpeg.git 03Clément BSsch 07master:eafb9c52e80c: doc/faq: remove Delphi/Pascal entry.
[23:33] <cone-589> ffmpeg.git 03Clément BSsch 07master:2e798c6ce0b4: doc/faq: remove indent in examples.
[23:33] <cone-589> ffmpeg.git 03Clément BSsch 07master:565fd3cc1a17: doc/faq: add @command{} in the tool debug entry.
[23:37] <cone-589> ffmpeg.git 03Clément BSsch 07master:a89e9ad1c862: swr: fix example code and doxy indent.
[23:45] <cone-589> ffmpeg.git 03Martin Storsjö 07master:d07aa3f02b73: riffdec: Add sanity checks for the sample rate
[23:45] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:5badcfe2200c: Merge commit 'd07aa3f02b73ab1371c13ac7898338380ca0932b'
[23:59] <cone-589> ffmpeg.git 03Martin Storsjö 07master:a9221e39600a: electronicarts: Add more sanity checking for the number of channels
[23:59] <cone-589> ffmpeg.git 03Michael Niedermayer 07master:7057cc861d10: Merge commit 'a9221e39600a31ee13e736e9e47743cde23f0280'
[00:00] --- Mon Sep 30 2013