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

[burek]

[00:00] <ubitux> please suggest something that would be useful for you
[00:00] <ubitux> since you might be the first user of it
[00:00] <wm4> the first user? that sounds like a threat
[00:01] <ubitux> well you seem interested in messing with subtitles so..
[00:03] <ubitux> wm4: your fix seems to work
[00:04] <ubitux> audio is now broken just as expected
[00:04] <ubitux> thx :)
[00:13] <cone-88> ffmpeg.git 03Michael Smith 07release/1.1:1fa37f2bfa0f: proresdec: support mixed interlaced/non-interlaced content
[00:13] <cone-88> ffmpeg.git 03Reinhard Tartler 07release/1.1:82c3792a3084: update Changelog
[00:13] <cone-88> ffmpeg.git 03Reinhard Tartler 07release/1.1:2c23237cb4ed: Prepare for 9.7 Release
[00:13] <cone-88> ffmpeg.git 03Luca Barbato 07release/1.1:aaeef7fa0d6e: mjpegdec: properly report unsupported disabled features
[00:13] <cone-88> ffmpeg.git 03Dale Curtis 07release/1.1:406632d1ef44: avformat/utils: Keep internal and external av_read_frame() packets in sync.
[00:13] <cone-88> ffmpeg.git 03Michael Niedermayer 07release/1.1:8c118207ea0b: Merge commit 'aaeef7fa0d6ebb1a3668894e67a70cd5084ce4f4' into release/1.1
[00:17] <durandal_1707> can someone add multithread audio frame decoding/encoding?
[00:21] <kierank> decoding and encoding depends on the state of the completed previous frame
[00:21] <kierank> for audio
[00:22] <cone-88> ffmpeg.git 03Jindrich Makovicka 07release/1.1:7f451cb01f9f: mpegvideo: allocate sufficiently large scratch buffer for interlaced vid
[00:22] <cone-88> ffmpeg.git 03Luca Barbato 07release/1.1:9eecf633f701: jpegls: return meaningful errors
[00:22] <cone-88> ffmpeg.git 03Reinhard Tartler 07release/1.1:582aec49892d: jpegls: factorize return paths
[00:22] <cone-88> ffmpeg.git 03Luca Barbato 07release/1.1:0af5a774ebc9: jpegls: check the scan offset
[00:22] <cone-88> ffmpeg.git 03Michael Niedermayer 07release/1.1:cff8d01e1517: Merge commit '0af5a774ebc96ae9018926dc8b276c7f39767e3e' into release/1.1
[00:22] <durandal_1707> kierank: what?
[00:22] <kierank> for mdct codecs you need to do frame overlap
[00:22] <kierank> which requires the previous frame to be completed afaik
[00:23] <durandal_1707> i do not talk about such codecs
[00:23] <durandal_1707> i talks about codecs for which frame multithreading makes sense
[00:23] <michaelni> for mdct frame i depends on input i-1 and i but in general not i-2
[00:24] <kierank> ok
[00:46] <cone-88> ffmpeg.git 03Luca Barbato 07release/1.1:c340319559bf: wavpack: validate samples size parsed in wavpack_decode_block
[00:46] <cone-88> ffmpeg.git 03Luca Barbato 07release/1.1:510a96a2116a: ljpeg: use the correct number of components in yuv
[00:46] <cone-88> ffmpeg.git 03Luca Barbato 07release/1.1:7923a25fdda9: mjpeg: Validate sampling factors
[00:46] <cone-88> ffmpeg.git 03Luca Barbato 07release/1.1:aed12df7fe65: mjpegdec: validate parameters in mjpeg_decode_scan_progressive_ac
[00:46] <cone-88> ffmpeg.git 03Anton Khirnov 07release/1.1:10f77c165c3b: pixdesc: mark gray8 as pseudopal
[00:46] <cone-88> ffmpeg.git 03Michael Niedermayer 07release/1.1:683cbbb72142: Merge commit '10f77c165c3b3e881bb174a0f57dd62083639072' into release/1.1
[00:56] <cone-88> ffmpeg.git 03Luca Barbato 07release/1.1:93fbf034c94c: wavpack: check packet size early
[00:56] <cone-88> ffmpeg.git 03Michael Niedermayer 07release/1.1:f908e3ce92a6: Merge commit '93fbf034c94caf7ddfecd3c1947e3139fef6bfca' into release/1.1
[01:01] <cone-88> ffmpeg.git 03Luca Barbato 07release/1.1:5ba83e90919c: wavpack: return meaningful errors
[01:01] <cone-88> ffmpeg.git 03Michael Niedermayer 07release/1.1:30394adc4482: Merge commit '5ba83e90919cdeef38e2b5343b48f3f367292564' into release/1.1
[01:04] <ubitux> "Optimized Source code (100% asm)"
[01:04] <ubitux> woot
[01:11] <durandal_1707> if not SIMD ignore
[01:13] <ubitux> i see some psubusb
[01:14] <ubitux> and misc punpcklbw, packuswb and friends
[01:14] <ubitux> not that much though
[01:15] <durandal_1707> your next filter(s)
[01:16] <ubitux> nope
[01:17] <ubitux> i've already a queue of filters
[01:17] <ubitux> and wm4 wants me to work on subtitles :(
[01:17] <ubitux> and i have another big project in progress :(
[01:17] <wm4> well, not really, it's fine for now
[01:17] <cone-88> ffmpeg.git 03Luca Barbato 07release/1.1:7251de30322a: wavpack: use bytestream2 in wavpack_decode_block
[01:17] <ubitux> ETOOMUCHTHINGSTODO
[01:17] <cone-88> ffmpeg.git 03Michael Niedermayer 07release/1.1:4c052a7b8b0a: Merge commit '7251de30322aff5660e571856132dc6c7256fe94' into release/1.1
[01:18] <Daemon404> man
[01:18] <Daemon404> i gotta say
[01:18] <Daemon404> i hate the 9000 "merge <hash>"
[01:18] <Daemon404> :|
[01:18] <wm4> Daemon404: that's what you get for collaborating with the enemy
[01:18] <ubitux> merging is the best way to keep authorship
[01:18] <Daemon404> ubitux, merging one commit at a time
[01:18] <ubitux> (and hashes)
[01:18] <Daemon404> creates a shitload of noise
[01:19] <Daemon404> it used to be qatar/master
[01:19] <ubitux> Daemon404: i guess that's because if another developer is committing something michael has to redo the merge
[01:19] <Daemon404> heh.
[01:36] <ubitux> oh the C code is LGPL
[01:43] <ubitux> the code is pretty sick haha
[01:43] <ubitux> it looks like generated code
[01:43] <wm4> what code exactly?
[01:43] <ubitux> http://b.pkh.me/hq4x.cpp
[01:44] <wm4> ah
[01:44] <wm4> is that useful for video related stuff?
[01:44] <ubitux> yeah
[01:44] <Daemon404> was this by chance an avs plugin
[01:44] <ubitux> wm4: http://www.hiend3d.com/hq4x.html
[01:44] <cone-88> ffmpeg.git 03Alexandra Khirnova 07release/1.1:4f6fbe47a9f7: vmdav: convert to bytestream2
[01:44] <cone-88> ffmpeg.git 03Michael Niedermayer 07release/1.1:2a3954818121: Merge commit '4f6fbe47a9f784373c277870d9d4989762873bf1' into release/1.1
[01:44] <ubitux> http://b.pkh.me/hq2x.cpp and http://b.pkh.me/hq3x.cpp are similar
[01:45] <wm4> ubitux: yeah but, pixel art <-> video??
[01:45] <wm4> or does this actually make postage stamp sized 2001 video watchable?
[01:45] <ubitux> what about a pixel art session game recording?
[01:45] <wm4> eh
[01:46] <wm4> well, you'd probably enable scaling in the emulator
[01:46] <ubitux> we already have superx2sai 
[01:46] <ubitux> which is a bit similar
[01:46] <wm4> was that ported from mplayer?
[01:46] <Daemon404> eh
[01:46] <ubitux> possibly yes
[01:46] <Daemon404> he tas video guys )emulator videos)
[01:46] <Daemon404> would kill you
[01:46] <wm4> I remember having removed that thing half a year ago :)
[01:46] <Daemon404> pointresize or die
[01:46] <Daemon404> etc
[01:46] <ubitux> wm4: so we save it ;)
[01:47] <wm4> funny how this stuff makes it back through the backdoor in ffmpeg
[01:47] <ubitux> :D
[01:47] <ubitux> it was ported by Stefano in March 2012
[01:48] <ubitux> anyway, the filter is pretty interesting
[01:48] <ubitux> i think we can make a relatively simple & slow version without that much effort
[01:48] <ubitux> but i have other priorities
[01:48] <ubitux> i hate when ppl makes me want to write more stuff
[01:48] <ubitux> :(
[01:50] <wm4> ubitux: btw. is there any way to find out whether subtitle demuxers use the subtitle queue?
[01:50] <ubitux> mmh
[01:50] <wm4> it would be useful to find out whether everything should be read in advance
[01:51] <ubitux> in theory, every text sub demuxer should use it
[01:51] <wm4> hm or maybe I can work that around
[01:51] <ubitux> do you have a subtitles demuxer which does not use it in mind?
[01:51] <wm4> image subs
[01:51] <ubitux> yeah right
[01:51] <ubitux> but in text ones?
[01:52] <wm4> not that I can't think of any
[01:52] <ubitux> (do we have any independent image sub format except vobsub?)
[01:52] <wm4> except those 80 MB .ass scripts
[01:52] <ubitux> wut
[01:52] <wm4> I know
[01:52] <Compn> lol
[01:52] <wm4> I got it as "heavy" test case from someone
[01:52] <Compn> wm4 : can you share it with us ?
[01:52] <ubitux> that's gonna rape the demuxer
[01:52] <Compn> probably ffmpeg has artificial limits on subs
[01:52] <Compn> :\
[01:53] <wm4> not sure if I can, but it's one of the examples where mplayer2/mpv/ffmpeg do fine and mplayer freezes to death
[01:53] <wm4> (sorry)
[01:53] <Compn> can you ask your source if they can share it wiht us
[01:53] <Compn> i know its prob private anime scriptor and they hate sharing :D
[01:53] <ubitux> replace stars and hearts with dicks and it should be ok to share it
[01:54] <Compn> wat
[01:54] <ubitux> i guess they make an abusive usage of ass vectors?
[01:54] <wm4> actually it's only 73 MB
[01:54] <ubitux> Compn: workarounding fanfag copyrights ;)
[01:54] <Compn> ubitux : i'm guessing they paint each character with 23 images :P
[01:54] <wm4> here's an example line: {\blur3\alpha&H33&\move(521,40,509,0)\clip(535,37,537,39)\t(\clip(523,-3,525,-1))\t(0,787,\1c&HFFFFFF&\3c&HFFFFFF&\alpha&HFF&)}mu
[01:55] <wm4> multiply by roughly 400000 lines
[01:55] <ubitux> :D
[01:55] <ubitux> i hope it's beautiful
[01:55] <Compn> does it even play realtime ?
[01:55] <Compn> whats ass rendering speed nowdays
[01:55] <ubitux> i guess it was generated by aegisub with some scripting thing?
[01:56] <Compn> takes a whole i7 core just for sub renders ...
[01:56] <wm4> ubitux: you can ask lachs0r
[01:57] <wm4> this is the script: http://tmp.srsfckn.biz/snss-opfx-romaji.7z
[01:57] <wm4> starts about 1 or 2 minutes in
[01:59] <ubitux> ah exactly that, template scripting in Comment
[02:00] <wm4> and this is why vsfilter guys scatter the source code with intrinsics
[02:00] <wm4> tons of intrinsics
[02:01] <cone-88> ffmpeg.git 03Luca Barbato 07release/1.1:5a8dcc993dac: vmd: return meaningful errors
[02:01] <cone-88> ffmpeg.git 03Luca Barbato 07release/1.1:dbaf3f7b0bc9: vmd: drop incomplete chunks and spurious samples
[02:01] <cone-88> ffmpeg.git 03Michael Niedermayer 07release/1.1:d6373f158697: Merge commit 'dbaf3f7b0bc9e99dff8e06bd29fcb3e84eebfe7c' into release/1.1
[02:01] <wm4> there should be ffassrender, optimized by Michael Niedermayer
[02:02] <ubitux> ass rendering should be optimized in libass, not ffmpeg
[02:02] <wm4> nobody wants to
[02:03] <ubitux> what we could optimize though, is the blending
[02:03] <wm4> definitely
[02:03] <ubitux> but as you can see, we are not that much developers :(
[02:17] <iive> build it and they will come.
[02:17] <ubitux> huh?
[02:17] <ubitux> build what?
[02:18] <cone-88> ffmpeg.git 03Luca Barbato 07release/1.1:5a01ab0e62c9: vmd: use the PALETTE_COUNT constant uniformly
[02:18] <cone-88> ffmpeg.git 03Michael Niedermayer 07release/1.1:f86b2e4f499a: Merge commit '5a01ab0e62c95a60b4848744e623640f5dafe23b' into release/1.1
[02:21] <cone-88> ffmpeg.git 03Paul B Mahol 07master:e2f89f78048b: tta: move GetBitContext out of private context
[02:21] <cone-88> ffmpeg.git 03Paul B Mahol 07master:0f740fea856b: tta: use interger instead of pointer to iterate output samples for 24-bit case
[02:21] <cone-88> ffmpeg.git 03Paul B Mahol 07master:a44d39ae4201: wavpack: remove redundant error log message
[02:21] <cone-88> ffmpeg.git 03Paul B Mahol 07master:d2021f74ed5e: jpeg2000dec: remove redundant error log message
[02:26] <iive> ubitux: it is actually an abuse of meme... j/k
[02:26] <ubitux> oh :(
[02:29] <durandal_1707> ubitux: on what are you doing now?
[02:31] <ubitux> watching animes
[02:31] <ubitux> otherwise, various pending stuff, mainly swf now, but i plan to finish spp too
[02:32] <cone-88> ffmpeg.git 03Luca Barbato 07release/1.1:5fed47b94f88: vmd: refactor the inner decode loop
[02:32] <cone-88> ffmpeg.git 03Michael Niedermayer 07release/1.1:f08b0ff051c3: Merge remote-tracking branch 'qatar/release/9' into release/1.1
[02:32] <ubitux> durandal_1707: what about you?
[02:34] <durandal_1707> top secret
[02:35] <ubitux> i hope it's awesome
[02:35] <wm4> I'm shuffling old mplayer code around, how awesome is that
[02:35] <ubitux> :)
[02:58] <cone-88> ffmpeg.git 03Michael Niedermayer 07release/1.1:2fae70db2ac2: vmdav: Try to fix unpack_rle()
[03:29] <cone-88> ffmpeg.git 03Nicolas George 07master:fc82f4a1f8aa: ffmpeg: ignore EOF when pushing frames to filters.
[03:29] <cone-88> ffmpeg.git 03Nicolas George 07master:50a4d076ce63: lavfi/trim: mark link closed on EOF.
[03:29] <cone-88> ffmpeg.git 03Michael Niedermayer 07master:2976e2a102cd: Merge remote-tracking branch 'cigaes/master'
[04:10] <Compn> wm4 : for mplayer or for mplayer2? :P
[04:15] <ubitux> for the 3rd
[10:51] <cehoyos> burek: Are you sure it is generally known how many frames are to come in a video stream until EOF?
[10:51] <av500> I dont think so
[11:01] <burek> cehoyos, how does ffmpeg's fade filter know where is start_frame ?
[11:13] <cehoyos> It counts?
[11:14] <cehoyos> (I did not look at the code, that is just how I imagine it could work.)
[11:30] <burek> there, you have your answer how it will know how many frames are to come
[11:31] <cehoyos> Sorry, I don't understand: Assuming it does not know how many frames are to come, where should it start counting?
[11:31] <burek> count() - number_of_frames_provided_by_user ?
[11:32] <cehoyos> What is count() in your equation?
[11:33] <saste> burek, the filter doesn't know when the stream will finish
[11:33] <burek> total number of frames
[11:33] <saste> what in case the stream is live for example?
[11:34] <burek> is it so hard to detect if it's a live stream or not
[11:35] <cehoyos> How should the filter know the total number of frames for a stream that is not a live stream?
[11:35] <burek> ask developers, not me
[11:50] <cone-975> ffmpeg.git 03Diego Biurrun 07master:46ce9ded96ff: tiff: K&R formatting cosmetics
[11:50] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:7cb5467a5201: Merge commit '46ce9ded96ffcb798b03da894cdb5fdac376a6ee'
[12:04] <cone-975> ffmpeg.git 03Diego Biurrun 07master:f0ce1d9909ef: cpu: Restructure code to avoid pointless ret variable indirection
[12:04] <cone-975> ffmpeg.git 03Diego Biurrun 07master:9f84ed8cc3ed: nsvdec: Remove commented-out debug cruft
[12:04] <cone-975> ffmpeg.git 03Diego Biurrun 07master:c011ceef78ea: swscale: ppc: Remove commented-out define cruft
[12:04] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:45a73d2b472f: Merge commit 'c011ceef78eae66039efc66d9551a7146e08838a'
[12:30] <cone-975> ffmpeg.git 03Kostya Shishkov 07master:0aed0bfc62b2: vmd: fix mode 3 decoding
[12:30] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:c3660c361822: Merge commit '0aed0bfc62b273a780a2bfba3be56039fccd7423'
[12:40] <cone-975> ffmpeg.git 03Kostya Shishkov 07master:31980b6abdd8: vmd: decode videos with no LZ buffer size provided - they might not need it
[12:40] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:5c43f3ddea40: Merge commit '31980b6abdd8ffb6953472a7a6b59f3aa5762c31'
[12:44] <cehoyos> durandal_1707: How will the fade filter know when to start with fade?
[12:44] <durandal_1707> never
[12:45] <cehoyos> So how can ticket 2631 be implemented?
[12:45] <ubitux> it needs the total number of frames in advance, which means either a 2 pass system, or an unreliable system limited to very a few formats
[12:46] <ubitux> s/a few/few/
[12:46] <durandal_1707> cehoyos: ever heard of bugs than never get fixed?
[12:46] <cehoyos> I don't understand...
[12:46] <durandal_1707> just live with that
[12:47] <ubitux> ...or it needs a queue of N frames
[12:47] <cehoyos> Just to make sure there is no misunderstanding: You believe that ticket 2631 cannot be implemented but you set it to open?
[12:47] <ubitux> EMEMBOMB
[12:47] <cehoyos> ubitux: Yes, I wanted to ask why this can't be done?
[12:47] <ubitux> it's not that it can't be done
[12:48] <ubitux> it's just that it will require quite some work
[12:48] <cehoyos> (It is how I would have implemented it but I wasn't sure if I miss something.
[12:48] <ubitux> and will possibly need API redesign
[12:48] <cehoyos> The API does not allow to queue n frames?
[12:48] <cehoyos> How does yadif queue a frame?
[12:48] <ubitux> no, this is OK
[12:48] <durandal_1707> it needs 2-pass (extra decoding) and it will be slow...
[12:48] <durandal_1707> queue eats memory
[12:49] <ubitux> queueing a frame can be done, but in this case it will explode pretty quickly
[12:49] <cehoyos> 2-pass sounds as if the user could simply specify the frame number
[12:49] <cehoyos> ubitux: So what?
[12:49] <durandal_1707> so unless you have infinite ammount of it, its bad
[12:49] <ubitux> above 100 frames you start to have a high risk of membomb
[12:49] <ubitux> so it has a very limited usage
[12:49] <cehoyos> The same membomb you get with h264-16ref-16k resolution
[12:50] <ubitux> this one is unlikely
[12:50] <cehoyos> And since 45 frame were suggested in the ticket, this should work or do I miss something?
[12:50] <cehoyos> Which one is unlikely?
[12:50] <saste> ubitux: we could implement a finite queue in fade
[12:50] <ubitux> 45 is suggested because that's from the doc
[12:50] <michaelni> 16ref-16k probably violates some profile/level limits 
[12:50] <saste> the problem is that frame counting also sucks, since you want to work with time units rather than with frame numbers
[12:51] <ubitux> cehoyos: 16k is more unlikely than "fade based on the last minute: (30*60) frames"
[12:51] <cehoyos> It's ticket 1900...
[12:51] <saste> so it's not impossible in first pass, but it would be complicate and would be limited anyway
[12:53] <cehoyos> ffmpeg -f lavfi -i testsrc -vframes 1800 out.yuv -> 400MB
[12:53] <cehoyos> I don't find that dramatic (especially compared to ticket 1900)
[12:54] <cone-975> ffmpeg.git 03Kostya Shishkov 07master:2d66a58ccde0: Go2Webinar decoder
[12:54] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:e5cdf9c03b1e: Merge commit '2d66a58ccde05e764594bd7e5f0f9244634d0b2c'
[12:54] <cehoyos> Correction: This is the same magnitude as 1900
[12:55] <ubitux> huh, why does this testsrc example requires 400MB?
[12:55] <cehoyos> out.yuv: 400MB
[12:55] <ubitux> why would that be in memory all at once?
[12:56] <cehoyos> That is the amount of memory needed (at least!) to store (30*60) frames
[12:56] <ubitux> ah, yes, that's huge, just to make a simple "1 minute from the end" effect
[12:56] <ubitux> and testsrc has a very low resolution
[12:57] <ubitux> people are more likely to work with 720 p
[12:57] <ubitux> or above
[12:57] <durandal_1707> usually user fades just for few seconds
[12:58] <ubitux> how much memory is "a few seconds" with a 720p input? :)
[12:58] <ubitux> i'm not saying it should not be implemented that way
[12:58] <cone-975> ffmpeg.git 03Martin Storsjö 07master:9683e37cd5c5: movenc: Change the track struct name to match the typedef
[12:58] <ubitux> but adding such code will have a very limited usage
[12:58] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:3da711119340: Merge remote-tracking branch 'qatar/master'
[12:58] <cehoyos> So to sum it up: Everybody except me thinks that this should not be implemented and everybody except me wants the ticket to stay open. Am I missing something?
[12:59] <ubitux> i would like to have some comments before closing it
[12:59] <durandal_1707> both ways : two pass and queue could be available....
[12:59] <cehoyos> So where are the hundreds of Webinar samples now when we need them?
[12:59] <cehoyos> LOL
[12:59] <durandal_1707> cehoyos: if you want it closed, than close is as wontfix
[12:59] <cehoyos> But it's me who thinks that it could be implemented...
[13:00] <cehoyos> You set it to "open"
[13:02] <saste> cehoyos, i would keep it open with a few remarks about what is complicate about it
[13:02] <saste> a partial solution is possible, even if not perfect
[13:03] <cehoyos> Then please add a few remarks about what is complicate about it
[13:03] <ubitux> saste: so, are you going to port http://b.pkh.me/hq4x.cpp ?
[13:04] <saste> ubitux, why should I?
[13:04] <saste> currently i'm working on porting sab
[13:04] <ubitux> because you're a cool guy
[13:05] <ubitux> ah, that's good too
[13:05] <ubitux> another blur filter, heh
[13:05] <ubitux> is that to blur motion?
[13:06] <saste> ubitux, i still don't know what it's good for, and mplayer docs say nothing as usual
[13:06] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:6507d86f07b3: jpeg2000dec; optimize output sample convert a bit
[13:07] <durandal_1707> stop porting useless filters
[13:07] <ubitux> how is this filter useless?
[13:08] <saste> durandal_1707, why, mcdeint is cool
[13:08] <durandal_1707> nobody uses that
[13:08] <saste> sab i don't know, but are not we supposed to port all mp filters?
[13:08] <ubitux> microchip_ does
[13:10] <ubitux> oh it seems to be a blur that "merge shapes:
[13:10] <ubitux> -:+"
[13:10] <saste> i wanted to port eq/eq2, the problem is that they're GPLed and there is no much hope to relicense them
[13:11] <saste> having a GPL-only eq filter sounds stupid
[13:11] <durandal_1707> lol, they are lut tables
[13:11] <cehoyos> But if you don't want to write a LGPL'd one, it is still much better than no eq filter, or am I wrong?
[13:12] <durandal_1707> i could write one, if i cared
[13:12] <ubitux> saste: funny how the effect of sab is not that far from hqx filters :P
[13:19] <ubitux> sounds like one of the most important ticket so far ^
[13:19] <ubitux> meh, seems i already +1 it
[13:20] <ubitux> 7 votes for #2078, wut
[13:21] <cehoyos> Yes, this is among the highest requested tickets.
[13:21] <ubitux> and then ts muxing :))
[13:22] <cehoyos> Which one is this?
[13:23] <cehoyos> 1598 is "h264 timestamps"
[13:23] <ubitux> i was just coming accross #1150, and i saw some mpegts in #2227 so i made a dubious shortcut ;)
[13:24] <cehoyos> 1150 and 2078 are probably duplicates
[13:24] <cehoyos> People like to vote for 2227 but nobody wants to test ;-))
[13:25] <durandal_1707> people asked for help how to apply patch and got 0 help
[13:26] <cehoyos> Yes, I am so sorry, I was too busy lately to scan Michael's emails from February 3rd for a patch...
[13:26] <ubitux> <@cehoyos> 1150 and 2078 are probably duplicates // so scores need to be cumulated!
[13:27] <cehoyos> Or to search http://news.gmane.org/gmane.comp.video.ffmpeg.devel for "ticket2227"
[13:28] <cehoyos> 502 also looks a little suspicious...
[13:28] <cehoyos> And certainly 2398
[13:29] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:96b71a6ec509: avcodec/jpeg2000dwt: merge rescaling with interleave in 9/7 float IDWT
[13:29] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:8a266aaaacc0: avcodec/jpeg2000dwt: merge rescaling with interleave in 9/7 int IDWT
[13:30] <cehoyos> durandal_1707: CFDecode2.ax
[13:31] <durandal_1707> link?
[13:33] <cehoyos> You could ask Compn but Steinar H. Gunderson probably knows
[14:29] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:7e99d528f95a: ffv1enc: Check return value of av_frame_ref()
[14:29] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:6952e2f82a8a: h264_ps: fix memleak in ff_h264_decode_picture_parameter_set()
[14:29] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:d8c10324eda7: jpeg2000: Fix Unintended sign extension in malloc arguments of cblk.
[14:48] <michaelni> durandal_1707, do you think stat() is a good function name in af_astats?
[14:48] <michaelni> it seems confusing coverity
[14:48] <durandal_1707> rename then
[14:48] <durandal_1707> its really bad name
[14:49] <michaelni> ok, what name should i use ?
[14:50] <Compn> audio_stats at least :P
[14:50] <Compn> or whatever astats does
[14:51] <ubitux> do_stat() :p
[14:51] <ubitux> update_stat()
[14:52] <michaelni> ubitux, ok
[14:53] <durandal_1707> calc_compn_stat()
[14:53] <michaelni> isnt that a bit long ?
[15:00] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:234f76ae7deb: jpeg2000: Fix unintended sign extension in malloc arguments of prec
[15:00] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:bbf43c70dd43: jpeg2000dec: assert that curtileno is valid when used
[15:00] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:bbae6521136b: tiff: fix memleak
[15:00] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:7e7d09090731: avfilter/af_astats: rename stat()
[15:04] <michaelni> durandal_1707, CID1026746/7 (coverity claims division by zero in af_astat)
[15:04] <durandal_1707> michaelni: its stupid
[15:05] <durandal_1707> it thinks user likes to filter audio with 0 channels
[15:09] <michaelni> if its false positive, please close as false positive
[15:10] <durandal_1707> ENOTIME
[15:10] <durandal_1707> i added frame threading for audio decoder and i get segv at end
[15:25] <damir__> hello
[15:29] <michaelni> ubitux, coverity found in vf_lut3d CID1026774/5
[15:29] <burek> enotime :)
[15:33] <ubitux> michaelni: a bit busy right now, i'll try to have a look later
[15:33] <michaelni> ubitux, ok thx
[15:34] <durandal_1707> i got coverity reports in mail, but no code that i maintain...
[16:01] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:3ed56b3b3992: avfilter/process_options: fix memleak
[16:01] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:43487bc5c10a: avfilter/vf_mcdeint: free frame on error
[16:16] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:0722b4d08cd6: matroskadec: favor av_freep()
[16:16] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:2fe4b6210c4b: matroskadec: fix memleak of pkt_data
[16:16] <cone-975> ffmpeg.git 03Michael Niedermayer 07master:c8faa4748446: avformat/network: check the return value from setsockopt()
[16:35] <ubitux> oh, fixed aac.
[16:39] <JEEB> suddenly you fixed something
[16:39] <JEEB> 'grats
[16:40] <nevcairiel> are there really that many devices that benefti from fixed point implementations so much?
[16:40] <nevcairiel> apparently, mips
[16:40] <av500> and the CPU in your toaster
[16:40] <nevcairiel> its not supposed to play audio!
[16:41] <kierank> the cpu in your musical birthday card
[16:42] <nevcairiel> i hate those things
[20:20] <wingrime> hello, I from linux-sunxi , I do RE for HW decoder CedarX (allwinner a10) and have some questions
[20:24] <wingrime> about IQ - matrix generation
[20:28] <Compn> wingrime : cool.
[20:28] <Compn> wait around, i think everyone is not here atm
[20:28] <Compn> probably night time
[20:29] <wingrime> Compn: time zones realy different from most
[20:31] <durandal11707> is question related to FFmpeg development?
[20:34] <wingrime> qusetion are: where in ffmpeg code there is IQ matrix generation for mpeg/jpeg
[20:34] <wingrime> ?
[20:38] <cone-540> ffmpeg.git 03Xidorn Quan 07master:4a023d5b5313: vda_h264_dec: remove check_format
[20:38] <cone-540> ffmpeg.git 03Michael Niedermayer 07master:e4bf3a97de9c: Merge branch 'master' of https://github.com/upsuper/ffmpeg-vdadec
[20:42] <michaelni> wingrime, for jpeg: grep quant_matrixes libavcodec/mjpegdec.c
[20:43] <wingrime> michaelni: thanks a lot
[20:45] <michaelni> for mpeg1/2 see load_matrix() and surrounding code
[20:46] <wingrime> michaelni: as I undersand, mpeg constan two values iq and min_iq , that must be expanded to two matrices 8x8 , I right here ?
[21:08] <michaelni> wingrime, i dont think i understand you, mpeg has 8x8 quantization matrixes
[21:15] <wingrime> michaelni: it also questionable for me , our hw decoder in mpeg4 case recive two numbers (min_iq and iq) for input, in jpeg case hw decoder need two 8x8 matrix (AC and DC (?)).  It possilbe use generated (not stored) matrxes for mpeg4 (are there standart)?
[21:24] <cone-540> ffmpeg.git 03Paul B Mahol 07master:b4d4ef55294f: flacdec: use init_get_bits8()
[21:29] <michaelni> wingrime, mpeg4 (asp) supports 2 different quantization modes one uses 8x8 matrixes
[21:53] <ubitux> hehe 3d lut to the rescue ^ 
[21:55] <durandal11707> there is not unscaled gbrX -> rgb48 
[21:56] <durandal11707> just gbr(8)p one
[21:57] <durandal11707> and no, i'm not touching libswscale unless i'm paid
[22:04] <wm4> lol
[22:18] <ubitux> hehe webvtt in webm
[22:18] <durandal11707> where?
[22:18] <ubitux> on the ml just now
[22:18] <ubitux> there are some serious awesomeness on the ml today
[22:19] <ubitux> vf sab, audio dec threading, fixed aac & ac3 dec, and now webvtt in webm
[22:19] <matthewjheaney> webvtt-in-webm info here: http://goo.gl/qhl0m
[22:19] <ubitux> it's like christmas
[22:19] <ubitux> matthewjheaney: oh so you're here, hi :)
[22:21] <matthewjheaney> Oh yes, I'm here.  Howdy, chat denizens. 
[22:21] <wm4> webvtt - how to even make srt complicated and fucked up
[22:21] <ubitux> haters gonna hate
[22:22] <matthewjheaney> I make no judgment of such things.  We have to implement the spec we're given.
[22:22] <ubitux> matthewjheaney: may i ask what's next after this?
[22:22] <ubitux> (assuming that's ffmpeg related)
[22:22] <matthewjheaney> webvtt muxer
[22:23] <ubitux> oh, cool ok
[22:23] <matthewjheaney> And after than, modifying the mkv demuxer to extract the webvtt track.
[22:23] <wm4> are there samples for webvtt in webm yet?
[22:24] <ubitux> is there any other webm producers than ffmpeg?
[22:24] <wm4> google has their own muxer AFAIK
[22:24] <matthewjheaney> We've been using libwebm/sample_muxer to make such files.  With the ffmpeg patch I just submitted, you can use ffmpeg directly.
[22:25] <matthewjheaney> Here at Google we've been using libwebm and the DirectShow components.
[22:25] <ubitux> do you do some kind of hardsubbing?
[22:29] <matthewjheaney> Just softsubs, I think.
[22:29] <ubitux> ok
[22:30] <wm4> I wonder if youtube will move away from its external subs?
[22:30] <ubitux> that would be nice.
[22:31] <ubitux> if i could get my subtitles into the webm files directly when downloading the videos :)
[22:31] <ubitux> arg i really need to inject subtitles in libavfilter to get the muxed sub displayed with ffplay
[23:02] <wm4> ubitux: [text @ 0x8ae4980]Invalid UTF-8 in decoded subtitles text; maybe missing -sub_charenc option
[23:02] <wm4> ubitux: can't it just pass-through the text if it's broken? why does it even care about the encoding?
[23:05] <ubitux> how can a decoding be pass-through?
[23:05] <ubitux> Nicolas insisted on aborting when the charset what incorrect
[23:06] <ubitux> so decoders aren't fed with invalid data
[23:06] <ubitux> s/what/was/
[23:06] <wm4> I'd rather have slightly broken subs than no subs at all
[23:06] <wm4> decoders should be able to cope with ivnalid data
[23:06] <ubitux> they will likely be all broken
[23:06] <ubitux> i could add an option to force it
[23:06] <ubitux> if you insist on that
[23:08] <ubitux> wm4: see first 2 lines: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-April/141905.html
[23:08] <wm4> eh, transcoding perspective again
[23:09] <ubitux> maybe it should be done at encoding though.
[23:12] <wm4> if I test with MicroDVD_capability_tester.srt, the first line sticks for 40 seconds with ffmpeg, while it's visible only for 5 seconds with mplayer
[23:13] <wm4> hm I guess ffmpeg behavior is more correct, somehow
[23:13] <wm4> but who knows
[23:14] <ubitux> note that the .srt has been renamed to .sub (same file, just kept for previous fate tests)
[23:32] <wm4> wow mplayer's subreader.c produces complete garbage for some formats
[23:33] <ubitux> wm4: most subreader.c code is designed as a "text heuristic finder"
[23:33] <wm4> heh
[23:33] <ubitux> or "tag stripper"
[23:33] <wm4> it produces random lookign results for SAMI
[23:33] <wm4> I wonder how that happens
[23:33] <ubitux> so yeah with most complex formats, it works for the most common cases only
[23:33] <wm4> but I'd rather not investigate
[23:33] <ubitux> did you look at realtext? :)
[23:34] <wm4> that too
[23:34] <wm4> OTOH I don't think libavcodec has a XML parser for this stuff
[23:34] <ubitux> it's better though.
[23:34] <wm4> OTOH^2, these formats aren't really XML, just pseudo-HTML
[23:34] <ubitux> there is a good enough tag walker in ffmpeg
[23:35] <ubitux> pseudo-broken-HTML yes
[23:35] <wm4> ubitux: since you unfortunately had a close look at subreader.c, are its post processing capabilities (like adjusting timing) actually worth saving?
[23:36] <ubitux> i don't remember that
[23:36] <ubitux> and it wasn't a close look
[23:36] <wm4> :)
[23:36] <wm4> more like running screaming, I suppose
[23:36] <ubitux> well, it was mostly to get a list of all the format to support
[23:37] <ubitux> if you look closely, vlc has a relatively similar code, to support most of those subs as well
[23:37] <ubitux> i think they added some, but again, didn't look much
[23:45] <ubitux> wm4: i wonder if i won't do a mix of both solutions for internal sub representation
[23:45] <wm4> such as?
[23:45] <ubitux> aka an AST for decoders and encoders, but serialization in AVSubtitles for users
[23:45] <ubitux> meaningful text serialization of course
[23:46] <ubitux> typically in AVSubtitles->rects[0]->text
[23:46] <ubitux> (serialization could be done with or without styles)
[23:46] <cehoyos> michaelni: Is it possible that there is no direct patch from gbrp -> rgb ? (Ticket 2633) I am not sure where to look.
[23:48] <cehoyos> ubitux: Did you test the sample from 2632? I have a suspicion the user decided to upload a sample that does not allow to actually reproduce the problem but I may miss something.
[23:49] <ubitux> iirc the sample is enough to see that the sub streams are not recognized
[23:49] <ubitux> but indeed the extract has not sub to show
[23:49] <cehoyos> Which program shows subtitles?
[23:49] <ubitux> i didn't test with vlc as suggested
[23:49] <ubitux> so i don't know if any player show them
[23:50] <cehoyos> Did you test any player / did any player show subtitles?
[23:51] <ubitux> no
[23:52] <ubitux> i tested with my usual players, and i don't think the sample is supposed to show subtitles at that moment
[23:52] <ubitux> the streams are just marked as unknown
[23:52] <cehoyos> In this case, I do not consider it a very useful sample;-(
[23:53] <ubitux> yes
[23:56] <michaelni> cehoyos, see ff_get_unscaled_swscale() (if it sets some converter) also you can add a gbrp ->rgb converter there if we have none
[23:57] <cehoyos> ;-)
[23:57] <nevcairiel> there should be an unscaled gbrp -> rgb converter, for 8-bit at least
[23:57] <cehoyos> (I remember that I wasn't entirely happy about the dpx patch back then, iirc it didn't fix anything.)
[23:58] <michaelni> cehoyos, its easy to add such unscaled special case converters the hard stuff is the scaled ones
[23:59] <cehoyos> Apparently, it is 8-bit only;-(
[23:59] <nevcairiel> should be easy to extend/copy it for 16-bit
[00:00] --- Tue Jun  4 2013