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

[burek]

[00:30:39 CET] <cone-088> ffmpeg 03Carl Eugen Hoyos 07master:e6cbe3ffef8b: configure: Fix webm_dash_manifest demuxer standalone compilation.
[01:44:11 CET] <michaelni> nevcairiel, kfreebsd should be fixed
[02:57:19 CET] <cone-088> ffmpeg 03Mark Harris 07master:1b4fbf808082: avformat/icodec: ico probe with unknown data
[02:57:20 CET] <cone-088> ffmpeg 03Mark Harris 07master:56e2cd9c042e: avformat/icodec: Fix crash probing fuzzed file
[04:59:53 CET] <llogan> kierank: just in case nobody else mentioned it, and if you're up at this hour, trac is down.
[05:00:18 CET] <llogan> i would restart stuff myself, but i am unable to connect
[05:01:56 CET] <michaelni> llogan, what happened?
[05:02:07 CET] <llogan> unknown
[05:02:22 CET] <llogan> i can ping the machine but that's it.
[05:02:49 CET] <michaelni> if trac is down when google looks at our ideas page then we are disqualified
[05:02:55 CET] <michaelni> for gsoc
[05:03:15 CET] <llogan> when will they look at it?
[05:04:04 CET] <michaelni> 20-26 IIUC
[05:04:55 CET] <llogan> would they really be that dismissive if the server is down?
[05:05:07 CET] <michaelni> yes
[05:05:50 CET] <llogan> i suppose we can make a copy on multimedia.cx and inform them of the new address.
[05:06:20 CET] <llogan> or request that they look after tomorrow
[05:06:28 CET] <michaelni> if you can make a copy somewhere, it surely doesnt hurt to make one
[05:09:13 CET] Action: Compn tries fixing wikipedia article again
[05:09:34 CET] Action: llogan tried to remember stupid password
[05:09:44 CET] <llogan> ..and username
[05:09:52 CET] <Compn> why bother just make another or edit without name
[05:10:31 CET] <llogan> lol. "unknown error in PHP's mail() function"
[07:59:14 CET] <kierank> Works here
[09:49:49 CET] <michaelni> kierank, check mail, its possibly a failing disk
[09:57:03 CET] <michaelni> anyway, ill go back to bed, just woke up and checked IRC, trac seems working currently
[11:17:17 CET] <wm4> claws' shitty behavior is getting unacceptable, what should I do...
[11:18:06 CET] <wm4> like it decides to redownload 40000 mail headers instead of letting me read mails
[11:23:23 CET] <flux> seems like you have three options: 1) file a bug report 2) fix it yourself 3) switch programs :-).
[11:25:50 CET] <wm4> 1 does nothing, 2 would likely require rewriting the thing or they would have fixed it after all these years
[11:27:11 CET] <flux> there's also a fourth option, split your 40k mails into multiple folders :)
[13:18:39 CET] <BBB> wm4: Im not sure I understand your comment
[13:18:52 CET] <BBB> wm4: are you suggesting zero-sized packets *are* a good way to signal skips, or not?
[13:19:07 CET] <wm4> that they're not
[13:19:18 CET] <BBB> ok, so, how shall I do it then?
[13:19:29 CET] <wm4> well I guess everything is ok if the decoder explicitly handles this
[13:19:35 CET] <wm4> and can't confuse it with an actual flush
[13:19:36 CET] <BBB> its for muxing
[13:19:41 CET] <wm4> oh
[13:19:46 CET] <BBB> so decoders arent part of it
[13:19:49 CET] <wm4> then nevermind, it probably doesn't apply there
[13:19:53 CET] <BBB> its the interaction between an app and the muxer
[13:20:12 CET] <BBB> app says heres a packet and the bsf says hold on a moment, dont write this yet
[13:20:16 CET] <BBB> Id like a way to do that
[13:20:25 CET] <BBB> maybe I should just redesign BSFs
[13:20:45 CET] <BBB> their current API is kind of pathetic
[13:21:16 CET] <BBB> (parsers arent any better btw)
[13:21:19 CET] <wm4> so does the bsf want to output another packet?
[13:21:24 CET] <wm4> or just not output a packet yet
[13:21:34 CET] <wm4> i.e. do 2 input packets become 1 output, or the other way around
[13:21:37 CET] <BBB> this particular BSF wants to merge two packet into 1
[13:21:43 CET] <wm4> ok
[13:22:14 CET] <BBB> but we have no way for a call to BSF.filter() to signal that there should be no further actual output to the muxer
[13:22:25 CET] <wm4> in theory you could have a flag in AVBitStreamFilterContext for compatibility...
[13:22:33 CET] <BBB> and to make matters worse, ffmpeg.c has all kind of hacks around it also :(
[13:22:52 CET] <wm4> sure sucks
[13:22:59 CET] <wm4> we should converzt everything to gstreamer
[13:23:15 CET] <wm4> s/gstreamer/lavfi/
[13:23:30 CET] <wm4> (a clean API would literally work like a filter)
[13:23:49 CET] <BBB> push or pull?
[13:24:49 CET] <wm4> state machine
[13:25:16 CET] <wm4> feed input until it outputs something, then read output until it needs input again
[14:49:30 CET] <pengvado> ubitux: every pixel depend on the previous. but png operates on packed rgba. 4 colorplanes is enough to fill an mmxreg.
[14:50:59 CET] <cone-327> ffmpeg 03Rostislav Pehlivanov 07master:029c069c6d98: vc2enc: add support for Haar wavelet transforms
[15:38:09 CET] <jya> quick question. after upgrading to FFmpeg 3.0; For the DTS decoder, rather than getting FLTP format, I get S32P with bits_per_sample = 24. Does that make that a S24P and is that LSB or MSB? the weird thing is that regardless of that, the value returned for each decoded sample is > 2^24
[15:43:39 CET] <kierank> 8 bits of lsb padding
[15:43:57 CET] <kierank> the opposite to video but I guess that's the convention in audio
[15:44:32 CET] <jya> ok so sample >> 8
[15:44:39 CET] <kierank> Yes
[15:45:11 CET] <jya> hmmmm... so code was correct... i still get something very noisy.
[15:45:44 CET] <jya> i can distinguish dialog etc... but there's lot of whitish noise over it
[15:45:59 CET] <nevcairiel> it might be different if we actually had a S24P format, but since its all in S32P we have to have the audio in the msb otherwise it would be super quiet when using "naive" logic (ie. ignoring bits_per_sample)
[15:46:57 CET] <J_Darnley> suddenly it makes a little sense.
[15:47:02 CET] <jya> the 8 bits aren't 0 in there, not sure if that indicates that something else is happening with those samples
[15:51:51 CET] <BBB> jya: why not just convert it to fltp with libswresample?
[15:52:05 CET] <BBB> jya: or do you want to send s24p straight to the soundcard?
[15:53:13 CET] <jya> BBB: I'm resyncing FFmpeg on mythtv; there we check what the audio card support and request libavcodec so that there's minimum amount of conversion occurring
[15:53:43 CET] <BBB> aha ok
[15:54:17 CET] <jya> since resyncing to 3.0, my DTS sample sound crap, the only difference I can see is that in 2.8, I used to get FLTP, and now I get S32P with bits_per_raw_sample = 24
[15:54:43 CET] <BBB> and if you read it as s32p and ignore bits_per_raw_sample?
[15:54:45 CET] <BBB> does it work then?
[15:54:50 CET] <BBB> (so as if it were 32 bit)
[15:55:09 CET] <jya> even when I request fltp, I still get S32P out with this decoder (I'm testing on mac, which support fltp so I would prefer fltp)
[15:55:21 CET] <BBB> typically decoders only output one format
[15:55:25 CET] <jya> that's the first thing I tried, but it still sound crap
[15:55:28 CET] <BBB> conversion is in libswresample
[15:55:35 CET] <BBB> ok, I dont know then I guess, sorry :(
[15:56:09 CET] <jya> sample_fmts for the dcadec was updated and in 2.8 had fltp only, now it has S16P, S32P and FLTP
[15:56:38 CET] <jya> seems to always set avctx->sample_fmt = AV_SAMPLE_FMT_S32P; in the init 
[15:56:50 CET] <nevcairiel> the output depends on the type of dts file
[15:56:59 CET] <nevcairiel> it doesnt honor any requests, it gives you what the file contains
[15:57:29 CET] <jya> nevcairiel: I was definitely getting fltp with the previous dcadec
[15:57:50 CET] <nevcairiel> thats irrelevant, the decoder was entirely replaced with a new one
[15:58:01 CET] <jya> nevcairiel: hmmmmm ffprobe gives me Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 1536 kb/s (default)
[15:58:33 CET] <jya> so maybe it is fltp, and AVCodecContext incorrectly states S32P
[15:58:45 CET] <jya> it's 2AM it doesn't help me seeing things clearly
[16:00:54 CET] <nevcairiel> I use the decoder myself, I'm quite sure it works correctly
[16:01:14 CET] <jya> ok.. that's good to know... 
[16:01:17 CET] <nevcairiel> you arent reading the sample_fmt once and then never looking at it again, are you? because it can and will change
[16:01:43 CET] <wm4> ideally you'd only ever look at AVFrame.format
[16:02:02 CET] <nevcairiel> as you noted, it always inits to s32p, but thats really only because it has no clue what kind of format its going to be
[16:02:09 CET] <nevcairiel> so it could be s32p, s16p or fltp
[16:02:49 CET] <jya> ok.. if I force it as FLTP now it plays fine...
[16:03:00 CET] <jya> hmmm what's going on
[16:03:08 CET] <JEEB> sounds like you're reading the uninitialized value
[16:03:18 CET] <JEEB> or well, initial initialization
[16:03:22 CET] <JEEB> before actual decoding
[16:03:31 CET] <JEEB> as opposed to the decoded avframe
[16:04:26 CET] <jya> that's old mythtv code, it has a special callback when the format changes... it may not be called (and that indicate I screwed my resync). mythtv maintains its own fork . mostly because of the mpegts demuxer 
[16:08:29 CET] <jya> would need to one day propose all the mythtv changes back to ffmpeg; lots of support for extra type of subtitles, dsmc etc
[16:09:27 CET] <nevcairiel> usually such projects have rather hacky changes, ie. it work for their use case (tv) but may have problems with other stuff, of course maybe mythtv is different =p
[16:10:24 CET] <jya> it's certainly is hacky :)
[16:10:45 CET] <jya> we had to handle change of stream content well before ffmpeg had something 
[16:10:59 CET] <wm4> I never understood the need for private ffmpeg forks
[16:12:07 CET] <jya> wm4: IIRC (though I joined the mythtv project only circa 2008). most of the changes myth did to support change of stream, subtitles etc.. always got knocked back when they tried to submit the changes upstream
[16:12:11 CET] <jya> in the end they gave up
[16:12:35 CET] <nevcairiel> being able to hack together some quick solution without having to worry about it working everywhere is attractive for many =p
[16:14:17 CET] <jya> the project is slowly dying unfortuantely, not many devs left... reworking the stream change to work with the proper ffmpeg API would require a big change... no one is willing to spend the time on it
[16:16:53 CET] <jya> nevcairiel: the AVFrame.format after decoding is 8 which appears to be AV_SAMPLE_FMT_S32P
[16:17:02 CET] <jya> so no FLTP there either
[16:17:35 CET] <nevcairiel> 8 is FLTP
[16:18:03 CET] <nevcairiel> S32P is 7
[16:18:14 CET] <jya> ah yeah, I was off by one :)
[16:19:51 CET] <jya> allright, will look into it tomorrow ... thank you for your help... it does look like it's not detecting the change of stream. That or the previous decoder returned FLTP right after setup, so we initialised the audio output properly 
[16:32:52 CET] <jya> allright, got it to work... we monitor the AVCodecContext format change, that seems to happen after we decode a return the first frame. So the first sample looks bad, fine after that.
[16:33:53 CET] <wm4> huh?
[16:34:01 CET] <wm4> so just wrong order of operation?
[16:35:17 CET] <jya> wm4: one day I'll update for the new API, for now it's just being kept alive :)
[17:06:45 CET] <atomnuker> the asm framework doesn't make much sense to me right now
[17:06:49 CET] <atomnuker> cglobal ssd_int8_vs_int16, 3, 3, 3, pix1, pix2, size
[17:07:02 CET] <atomnuker> so the function takes 3 arguments, uses 3 registers
[17:07:11 CET] <atomnuker> but what's the thrid '3' for?
[17:07:28 CET] <nevcairiel> 3 simd regs
[17:07:33 CET] <nevcairiel> gprs and simd  are separate
[17:08:36 CET] <atomnuker> huh, odd, the function only uses eax
[17:09:24 CET] <atomnuker> also at the end it does INIT_MMX mmx SSD_INT8_VS_INT16 INIT_XMM sse2 SSD_INT8_VS_INT16
[17:09:36 CET] <atomnuker> so it defines 2 functions for sse2 and mmx
[17:09:52 CET] <atomnuker> but it still only uses mmx (mm#) registers
[17:10:15 CET] <nevcairiel> first things first, it only uses eax explicitly for the return value
[17:10:27 CET] <nevcairiel> all other regs are hidden behind symbolic names from the parameters
[17:10:32 CET] <nevcairiel> pix1, pix2 and size
[17:10:38 CET] <nevcairiel> pix1q, sizeq in the code
[17:10:44 CET] <nevcairiel> q is the size of the register to access
[17:11:26 CET] <atomnuker> so the numer of general purpose registers needs to be at least the # of arguments
[17:11:40 CET] <nevcairiel> not necessarily, you can also access arguments from stack
[17:11:46 CET] <nevcairiel> but if you have enough gprs, sure
[17:12:22 CET] <nevcairiel> then, m# is the syntax to access the native simd register type depending on which init function you called
[17:12:27 CET] <nevcairiel> mm# would be for mmx explicitly
[17:12:33 CET] <nevcairiel> so with INIT_MMX m#
[17:12:38 CET] <nevcairiel> so with INIT_MMX m# expands to mm#
[17:12:44 CET] <nevcairiel> with INIT_XMM it expands to xmm#
[17:13:01 CET] <nevcairiel> so you can declare mmx/sse variants without much duplication
[17:13:32 CET] <nevcairiel> its a lot of macro magic :)
[17:25:32 CET] <atomnuker> why does yasm prevent me from doing vmovdqa [dataq+(locq*32)], ymm1 ?
[17:25:40 CET] <atomnuker> dataq+locq works
[17:27:15 CET] <kierank> stop using that notation as nevcairiel says
[17:27:22 CET] <kierank> use mova and mm1
[17:27:32 CET] <kierank> the macros do all of this for you
[17:29:01 CET] <atomnuker> ...he did not say anything about not using that notation
[17:29:24 CET] <kierank> 4:12 PM <"nevcairiel> then, m# is the syntax to access the native simd register type depending on which init function you called
[17:29:24 CET] <kierank> 4:12 PM <"nevcairiel> mm# would be for mmx explicitly
[17:29:42 CET] <kierank> obviously I mean m1*
[17:29:50 CET] <atomnuker> so how am I supposed to access a pointer?
[17:30:58 CET] <kierank> mova [dstq], m0 or whatever
[17:38:13 CET] <jkqxz> The offset multipler in a load like that is limited to 1, 2, 4, or 8 because of the encoding, anyway.
[19:00:11 CET] <nevcairiel> Frame-reordering in H.264 can never go beyond GOP boundaries, right? Even in Open-GOP, it could only reference an earlier frame, but not cause anything to re-order beyond the boundary?
[19:09:38 CET] <kierank> nevcairiel: I think no
[19:19:17 CET] <jkqxz> Why not?  It's not like GOPs are actually a thing in H.264 - the only real restriction is that you can't reorder too far, and MMCOs let referencing be completely arbitrary.
[19:20:40 CET] <nevcairiel> well the video type this really concerns are all blu-ray compatible encoded, where this is luckily all a bit stricter
[19:21:45 CET] <kierank> blu-ray has weird open-gop
[19:23:24 CET] <nevcairiel> initial tests show that my logic should be fine
[19:23:34 CET] <nevcairiel> lets finish this and run it through more samples
[19:32:11 CET] <jamrial> fuck integer 32bit scalarproduct where the result is 64bits
[20:28:11 CET] <pengvado> nevcairiel: h264 can't reorder across an IDR-frame (and you would never want to either). however, in open-GOP it actually has no concept of GOPs at all, and can reorder across I-frames.
[20:29:25 CET] <JEEB> so in theory you could have a sync point sei and then an I-picture + things that in theory could be reordered on both sides of that I-picture?
[20:29:50 CET] <JEEB> (not sure I got the name of the SEI correctly)
[20:30:03 CET] <pengvado> yes
[20:30:08 CET] <JEEB> ok
[20:40:23 CET] <jkqxz> H.265 makes some of this relationship explicit.  In particular, RASL frames are specifically those that cause trouble in the case you stated: they follow an I-frame (CRA or whatever) in decoding order but precede it in display order, and also depend on something before the I-frame in decoding order.
[20:43:13 CET] <jkqxz> (RASL being the NAL unit type, so you can skip it immediately in the seeking case.  For the same case in H.264 you need to decode more to work out that you won't be able to use it.)
[21:10:51 CET] <ubitux> wm4: flags2 +sub_ass_reset_readorder_on_flush sounds good to you?
[21:11:51 CET] <ubitux> pengvado: ok so just parallelizing color planes, thx
[21:15:43 CET] <ubitux> wm4: actually, i'll swap the logic of the flag meaning so it doesn't have to be set by default (i'm afraid of ppl resetting flags2 without honoring its current/default value)
[21:17:40 CET] <ubitux> will go for flags2 +ass_ro_flush_noop -> do not reset ASS ReadOrder field on flush
[21:18:35 CET] <wm4> ubitux: sounds good
[21:18:48 CET] <wm4> (what does "ro" mean?)
[21:18:52 CET] <ubitux> readorder :(
[21:18:58 CET] <wm4> lol ok
[21:19:31 CET] <wm4> btw. a new libass with API to disable the RO check was just released
[21:19:42 CET] <wm4> or at least will be released shortly
[21:21:54 CET] <ubitux> ah
[22:57:19 CET] Action: ubitux just realized our subrip encoder is producing fucking ass alignment tags
[22:57:29 CET] <ubitux> no nononooo nuifufufewwde12d1
[22:57:35 CET] <JEEB> \o/
[22:57:47 CET] <ubitux> on fucking purpose moreover
[22:57:59 CET] <ubitux> srt_print(s, "{\\an%d}", alignment);
[22:59:41 CET] <wm4> lol
[23:00:12 CET] <wm4> well there are people who put microdvd tags into srt
[23:01:16 CET] <ubitux> anyway, i'm finally getting the timing fix as a nice side effect of the patchset
[23:09:24 CET] <ubitux> last steps: test zvbi, document, and deprecate the whole timing thing.
[23:09:34 CET] <ubitux> such an adventure..
[23:10:18 CET] <wm4> how is zvbi different here?
[23:13:35 CET] <kierank> Zvbi is a bit "special"
[23:13:53 CET] <kierank> It's a crazy library in many ways
[23:14:15 CET] <wm4> it's part of the big club, huh
[23:17:02 CET] <llogan> kierank: looks like trac is down again. are you still working on it?
[23:17:06 CET] <ubitux> wm4: zvbi isn't covered by fate (it's a lib, we can't test the wrapper because of this), it's crafting sub events itself in the AVSubtitle and doing weird shit wrt timings, ...\
[23:17:23 CET] <ubitux> it also has a text and bitmap mode
[23:18:02 CET] <kierank> llogan: no
[23:18:21 CET] <ubitux> i'd love to get rid of it tbh
[23:18:22 CET] <kierank> Works for me
[23:19:48 CET] <llogan> now it's working here too, but it must have been down for at least 5-15 mins because i got an alert
[23:19:55 CET] <ubitux> wm4: i see a bunch of mplayer commits... you're still monitoring its activity? most of it probably don't apply to mpv anymore though
[23:20:32 CET] <wm4> mplayer commits usually affect code that is either removed or rewritten in mpv
[23:21:00 CET] <ubitux> yeah, not a surprise, but i saw a sudden peak of activity
[23:21:03 CET] <ubitux> so just wondering
[23:21:33 CET] <rcombs> ubitux: oh, the timing fix as in that one from the ML a while back with SRT timestamps getting rounded off?
[23:21:45 CET] <ubitux> rcombs: yes
[23:21:47 CET] <ubitux> it's fixed
[23:21:52 CET] <rcombs> cool
[23:22:05 CET] <kierank> llogan: ah that was me
[23:23:27 CET] <ubitux> rcombs: https://github.com/ubitux/FFmpeg/compare/ass-2016
[23:23:32 CET] <ubitux> see fate changes
[23:23:46 CET] <ubitux> (yes cc are still "broken")
[23:24:23 CET] <llogan> kierank: would you like me to add your email and/or mobile to CC for the alerts regarding trac.ffmpeg.org? they would come from the stupidly named "statuscake" service.
[23:24:30 CET] <rcombs> ubitux: cool
[23:25:09 CET] <rcombs> ubitux: btw, are you up for a sample showing some caption_dec issue
[23:25:32 CET] <ubitux> mmh, you'd better ask tmm1 for a fix, but i'm curious about the issue
[23:25:36 CET] <ubitux> :)
[23:25:43 CET] Action: rcombs finds link
[23:25:59 CET] <kierank> llogan: yes
[23:26:09 CET] <kierank> I have an alert too possibly using the same site
[23:29:54 CET] <rcombs> ubitux: http://puu.sh/nfl6E/4fcc73d8cf.wtv
[23:32:15 CET] <ubitux> what's the issue?
[23:32:37 CET] <ubitux> ffmpeg finds 3 events for this
[23:33:40 CET] <ubitux> and part of the 4th
[23:34:23 CET] <ubitux> (trying ffmpeg -f lavfi -i "movie=4fcc73d8cf.wtv[out0+subcc]" -f ass -)
[00:00:00 CET] --- Sun Feb 21 2016