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

[burek]

[00:01:15 CEST] <Compn> ZeroWalker : so you're building your own app ?
[00:01:29 CEST] <Compn> why not just list the devices yourself and then pass to ffmpeg api ?
[00:01:38 CEST] <Compn> er i guess thats complicated
[00:02:46 CEST] <ZeroWalker> that's what i am doing currently, it's messy, but it "works", but the format isn't crystal clear, hence the RGB24 BGR confusion
[00:02:53 CEST] <Compn> oh
[00:02:57 CEST] <Compn> mplayer lists devices
[00:02:59 CEST] <Compn> in dshow
[00:03:04 CEST] <Compn> maybe you can steal from it :P
[00:03:11 CEST] <nevcairiel> windows RGB is always BGR
[00:03:22 CEST] <ZeroWalker> well i can list devices fine
[00:03:23 CEST] <ZeroWalker> oh
[00:03:29 CEST] <ZeroWalker> why?
[00:03:38 CEST] <ZeroWalker> that's like, really confusing xd
[00:03:57 CEST] <Compn> er nevermind i'm dumb
[00:04:07 CEST] <nevcairiel> thats just how its defined
[00:04:09 CEST] <Compn> ZeroWalker : probably part of dshow spec
[00:04:15 CEST] <nevcairiel> RGB32 and RGB24 are both BGR order
[00:04:17 CEST] <Compn> which you should be reading... :P
[00:04:26 CEST] <nevcairiel> and if  it gives you a negative height, then its also upside down
[00:05:06 CEST] <rcombs>  <nevcairiel> RGB32 and RGB24 are both BGR order
[00:05:14 CEST] <rcombs> why do they call it that then :|
[00:05:23 CEST] <nevcairiel> because the format is called RGB :P
[00:05:51 CEST] <rcombs> I dunno, when it's in BGR order I call it BGR
[00:06:37 CEST] <ZeroWalker> haha yeah precisely rcombs!
[00:07:38 CEST] <ZeroWalker> Compn, and that spec is so messy, if it was possible i would just want to talk directly with the device to get the data, and not mess around with all the directshow layers as it's so messy (at least if you only want to get the data, if you wana do more stuff it makes sense)
[00:08:12 CEST] <rcombs> I forget if windows runs on any big-endian platforms but I wonder if it's backwards there
[00:08:22 CEST] <nevcairiel> it does not
[00:08:52 CEST] <nevcairiel> BE platforms basically dont exist anymore anyway
[00:09:12 CEST] <rcombs> what is there, some PPC variants?
[00:09:21 CEST] <rcombs> can't ARM technically run in BE mode but nobody does it?
[00:09:43 CEST] <nevcairiel> yeah like POWER8 or something, but thats such a rare platform, and I believe they can even run in LE now
[00:10:15 CEST] <nevcairiel> and nothing of value was lost
[00:11:03 CEST] <ZeroWalker> oh i thought that all PPC ran in BE
[00:11:24 CEST] <rcombs> I guess some random microcontrollers might be BE?
[00:11:59 CEST] <ZeroWalker> i would probably prefer BE cause it's more logical when seeing the memory. But i rather not change it now haha xd
[00:19:03 CEST] <J_Darnley> Shitty gnome/gtk programs!  That corner isn't 0,0 on Windows.
[00:23:24 CEST] <dcherednik> atomnuker: I understand it is float. But according to current implementation, samples is not scaled to (-1,1). Right?
[00:34:38 CEST] <dcherednik> atomnuker: Why I asked. I generate 1000 hz(-6db) + 21000 hz (-84db) signal, and got energy of last band 6db greater (approximately) than ath. Is it expected threshold?
[00:51:03 CEST] <ZeroWalker> is there any list of the Pixel Formats in string form (CLI)?
[01:01:15 CEST] <drv> ffmpeg -pix_fmts
[01:03:13 CEST] <Compn> ZeroWalker : [19:01] <drv> ffmpeg -pix_fmts
[01:03:33 CEST] <ZeroWalker> ah was looking at the codes, thanks
[01:11:05 CEST] <BBB> TD-Linux: in much the same way as an IPPPP stream isn't frame parallel decodeable in H.264 < what?
[01:11:47 CEST] <BBB> TD-Linux: why wouldnt IPP be frame parallel decodeable in h264? and how does ffh264 frame-mt work then?
[01:12:38 CEST] <BBB> (2d tiling and symbol adaptivity are good things btw)
[01:12:58 CEST] <TD-Linux> BBB, if each frame references the previous frame's pixels I don't see how you'd do frame mt
[01:13:28 CEST] <TD-Linux> unless ffh264 is doing sub frame synchronization
[01:13:28 CEST] <BBB> you wait until these pixels are reconstructed, as you do in any frame-mt scenario :)
[01:13:36 CEST] <BBB> of course it does sub-frame synchronization
[01:13:59 CEST] <TD-Linux> ah okay. I had assumed it relied on B frame structure without actually looking
[01:14:04 CEST] <BBB> nope
[01:15:03 CEST] <nevcairiel> that would probably not scale very well for  any bitstreams
[01:15:46 CEST] <TD-Linux> BBB, updated
[01:17:22 CEST] <TD-Linux> BBB, because ffvp9 didn't have vp9 tile threading, do you jump between the tiles to avoid stalling for an entire tile to complete?
[01:21:35 CEST] <BBB> TD-Linux: yes
[01:22:00 CEST] <BBB> TD-Linux: we do one sbrow for each tile within a set of tile columns within one tile row
[01:22:06 CEST] <BBB> (i.e. exactly what youd expect)
[01:22:22 CEST] <BBB> in encoders (but not decoders) you could probably mt for tile-rows also
[01:22:54 CEST] <BBB> the only dependency is reconstruction pixels (and some contexts which you really only need during post-r/d-frame bitstream writing), so you can just force not using any pred modes using top edge for that one row
[01:22:57 CEST] <TD-Linux> okay, thanks. sorry, I've been staring at libvpx too long :)
[01:23:01 CEST] <BBB> and then you get 2d tile mt in vp9 also
[01:23:15 CEST] <BBB> joy
[01:23:16 CEST] <BBB> :D
[01:23:51 CEST] <TD-Linux> BBB, with AV1 you don't need to do post bitstream writing anymore (but you still could)
[01:27:01 CEST] <TD-Linux> BBB, I think libvpx's recently added row-mt does what you're describing (but not lined up to tiles, as if you're doing post writing there's no reason to)
[01:27:27 CEST] <BBB> thats nice
[01:27:35 CEST] <BBB> (not having to do post-bitstream writing)
[01:27:54 CEST] <BBB> why is row-mt not lined up to tiles?
[01:28:17 CEST] <BBB> is it just b/c it doesnt matter where the separator is?
[01:28:21 CEST] <TD-Linux> you can also restart entropy coder on tile rows, so that's probably actually what you'd do
[01:28:22 CEST] <BBB> (from a mt pov)
[01:28:52 CEST] <BBB> so you *do* align it to tile row boundaries (for row-mt)?
[01:28:56 CEST] <BBB> or you do *not*?
[01:29:49 CEST] <TD-Linux> BBB, it's not aligned with tile boundaries for vp9 libvpx.
[01:30:07 CEST] <BBB> where is it aligned? :-p just halfway the frame?
[01:30:28 CEST] <BBB> or just at every n_sb_rows/n_row_mt_threads sbrow?
[01:30:29 CEST] <TD-Linux> not sure, I'd assume so (I haven't really looked at it in detail)
[01:30:37 CEST] <BBB> hmk
[01:30:59 CEST] <BBB> none of this matters from a compression perspective, although a dc-like prediction from top would be nice if the left intra predictor isnt very good
[01:31:03 CEST] <BBB> (h)
[01:34:09 CEST] <TD-Linux> for av1 it's not clear you'd want to do that vs just restarting the entropy coder every row (especially if you start with the last frame's cdfs)
[01:35:20 CEST] <BBB> every sbrow? or every tilerow?
[01:35:33 CEST] <TD-Linux> tilerow
[01:35:38 CEST] <BBB> right. that makes sense
[01:35:46 CEST] <BBB> every sbrow seems a little extreme
[01:35:53 CEST] <TD-Linux> (which you can't do in vp9)
[01:36:23 CEST] <BBB> right, its per-frame only
[01:36:38 CEST] <BBB> its why vp9 intra-only comparisons vs. hevc are so bad
[01:37:11 CEST] <BBB> (or at least its one of the main reasons)
[01:39:20 CEST] <ZeroWalker> hmm, shouldn't AVRational{100,3000} equal 30fps?
[01:41:27 CEST] <BBB> as time base? yes
[01:43:12 CEST] <ZeroWalker> well i set both fps and timebase, but for some reason the file ends up with 30.060fps
[02:16:25 CEST] <ZeroWalker> no ideas;o
[02:16:36 CEST] <BBB> not really, sorry :(
[02:18:43 CEST] <ZeroWalker> hmm, how does the fps system work, i mean i get the timebase part. but say for example
[02:19:15 CEST] <BBB> its very very complicated ;)
[02:19:16 CEST] <ZeroWalker> if i have the timebase in ms, and just feed it the current ms that the frame came, the end result will be a variable framerate
[02:19:39 CEST] <BBB> yes you dont want that, you need something more definitive than that
[02:20:14 CEST] <ZeroWalker> so i then assume if you always input a constant number, like 1 sample (which will be 1 frame) it will end up as a constant framerate
[02:20:28 CEST] <BBB> yes
[02:20:33 CEST] <ZeroWalker> even if i fed it 1000 frames in one second, it would still be, say 30fps right?
[02:21:37 CEST] <BBB> I think so
[02:22:51 CEST] <ZeroWalker> hmm, if that is the case, then the logical conclusion would be that the 100,3000 either isn't followed, or it does not equal 30fps for some reason
[12:17:21 CEST] <J_Darnley> I don't get it!  Why is this transform screwing up if I move the dsp init function slightly further out?
[12:17:40 CEST] <J_Darnley> And then why only on the border between slice rows?
[12:19:40 CEST] <J_Darnley> atomnuker: why does diracdec add 2 to the wavelet_idx parameter before passing it to ff_spatial_idwt_init()?
[12:24:16 CEST] <atomnuker> there was something, I can't remember, take a look at how the index is signalled in the encoder
[12:24:42 CEST] <J_Darnley> okay
[14:20:58 CEST] <J_Darnley> atomnuker: the answer to my question: the enum controlling the transform function selection has two Snow values before the 0 value in Dirac.
[15:01:38 CEST] <thardin> is carl not on irc these days?
[15:06:22 CEST] <BBB> thardin: not usually, but he reads the irc archives
[15:06:28 CEST] <BBB> thardin: when hes online, his nick is cehoyos
[15:08:12 CEST] <thardin> maybe I'll just put my thoughts here then: I'm giving a probe score of 10 if codec2 major version is outside expectations, does that seem reasonable?
[15:08:27 CEST] <thardin> plus an appropriate AVERROR_PATCHWELCOME
[15:08:36 CEST] <thardin> [codec2 @ 0x5566f3720ae0] Format codec2 detected only with low score of 10, misdetection possible!
[15:08:39 CEST] <thardin> [codec2 @ 0x5566f3720ae0] Major version 1 is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
[15:08:43 CEST] <thardin> /tmp/report2074-major.c2: Not yet implemented in FFmpeg, patches welcome
[15:12:46 CEST] <BBB> I dont know, sorry, if this is about something he said/suggested, best to discuss with him
[15:13:05 CEST] <thardin> alright, just tossing it out there
[15:14:50 CEST] <BBB> sorry :)
[15:15:59 CEST] <BBB> look at this beautiful code:
[15:16:02 CEST] <BBB>     if (av_codec_is_encoder(avctx->codec) &&
[15:16:02 CEST] <BBB>         avctx->codec_id == AV_CODEC_ID_MPEG1VIDEO &&
[15:16:03 CEST] <BBB>         avctx->height > 2800)
[15:16:04 CEST] <BBB>         thread_count = avctx->thread_count = 1;
[15:16:19 CEST] <thardin> but why
[15:17:15 CEST] <thardin> you'd think you'd want more threads the higher the resolution
[15:19:01 CEST] <JEEB> ....
[15:19:07 CEST] <JEEB> BBB: excuse me while I my eyes
[15:19:25 CEST] <BBB> hehehe
[15:19:26 CEST] <thardin> is there a test for that even?
[15:19:58 CEST] <BBB> sometimes open source is good
[15:20:01 CEST] <BBB> at least we can all see it
[15:20:55 CEST] <JEEB> yea
[15:21:50 CEST] <BBB> I bet its related to some fuzz
[15:21:59 CEST] <BBB> or timeout on a automatic test
[15:22:00 CEST] <BBB> or whatever
[15:22:46 CEST] <cbsrobot> BBB: sorry for the user question, but is it possible to tell colorspace filter, that the input is linear xyz ( with gamma 2.6) ? 
[15:23:00 CEST] <BBB> no
[15:23:09 CEST] <BBB> its possible to extend it to support that input
[15:23:14 CEST] <BBB> but right now it doesnt support it yet
[15:23:21 CEST] <cbsrobot> ok thanks
[15:23:24 CEST] <BBB> I can teach you how to extend the code to do that ;)
[15:24:00 CEST] <cbsrobot> I'll let you know when I have more time ...
[15:25:25 CEST] <BBB> okiedokie
[15:29:55 CEST] <jkqxz> 2800 is a relevant number for MPEG-1/2, so I could believe there is some not-entirely-stupid reason for that code.
[15:30:00 CEST] <jkqxz> (It's the point where slice start codes containing the position run out - above it you have to look inside the slice to work out where it goes.)
[15:30:48 CEST] <kierank> BBB: wtf
[15:31:32 CEST] <BBB> kierank: hehehehe
[15:31:42 CEST] <BBB> kierank: Im sure we can find more funny pieces of code before our beer
[15:33:07 CEST] <kierank> BBB: might need to be something stronger
[15:33:21 CEST] <BBB> whatever works for you :-p
[18:18:31 CEST] <cone-881> ffmpeg 03Michael Niedermayer 07master:d1bfa80ec464: avcodec/h264idct_template: Fix integer overflow in ff_h264_idct_add()
[18:18:32 CEST] <cone-881> ffmpeg 03Michael Niedermayer 07master:4ff94558f23a: avcodec/hevc_cabac: Check for ff_init_cabac_decoder() failure in cabac_reinit()
[21:36:58 CEST] <ZeroWalker> hmm, any ideas what might be the problem if sws_scale fails on one device with YUY2 720x576, but succeeds on another?
[21:37:25 CEST] <ZeroWalker> it fails with reading at bad memory basically, so i can only imagine the data being different somehow, which makes no sense
[21:53:18 CEST] <cone-259> ffmpeg 03Steinar H. Gunderson 07master:effd2e7291a1: speedhq: fix behavior of single-field decoding
[21:53:18 CEST] <cone-259> ffmpeg 03Steinar H. Gunderson 07master:45ffe4645e68: speedhq: add FATE tests
[21:53:18 CEST] <cone-259> ffmpeg 03Steinar H. Gunderson 07master:e67d6c37ee34: Add myself as speedhq maintainer, per request.
[22:52:58 CEST] <cone-259> ffmpeg 03James Almer 07master:cae2f1db107d: avcodec/htmlsubtitles: fix format specifier in av_bprintf calls
[00:00:00 CEST] --- Fri Aug  4 2017