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

[burek]

[00:05] <cone-896> ffmpeg.git 03rogerdpack 07master:d01234419b61: dshow: allow selecting devices by an alternative name (workaround for devices with symbols in them), allow specifying capture pins by name and alternative (unique) name
[00:05] <cone-896> ffmpeg.git 03rogerdpack 07master:e620eee88c4f: dshow: miscellaneous tweaks
[00:05] <cone-896> ffmpeg.git 03rogerdpack 07master:8eb5b5ec6f58: dshow: use non deprecated api
[00:05] <cone-896> ffmpeg.git 03rogerdpack 07master:b76a0e24f9ef: dshow: drop initial audio packets with weird timestamps
[00:05] <cone-896> ffmpeg.git 03rogerdpack 07master:ec81ad21c1f8: dshow: introduce support for crossbar [multiple input selectable] devices
[00:05] <cone-896> ffmpeg.git 03rogerdpack 07master:5d72cf0f6416: dshow: add options for allowing filter popup configuration dialogs to be presented to the user
[00:05] <cone-896> ffmpeg.git 03rogerdpack 07master:a35da0920d78: dshow: some devices only list themselves under "Video sources" but actually have both video and audio output pins, so make the audio pins accessible by video source name.
[00:05] <cone-896> ffmpeg.git 03rogerdpack 07master:b587ec00f7b6: dshow: fix docu escapes
[00:05] <cone-896> ffmpeg.git 03Michael Niedermayer 07master:76241c911510: Merge remote-tracking branch 'rdp/dshow_crossbar'
[00:37] <rock> Hi, Which is the best Mpeg2 TS analyzer ?
[00:38] <rock> I would like to pass in Apple HLS URL and analyze the stream
[01:06] <cone-896> ffmpeg.git 03Jean First 07master:1f13348f7d10: lavc/libopenjpegenc: move opj_setup_encoder to libopenjpeg_encode_frame
[01:24] <compn> rock : analyzer for what ? conformaty ? errors ? 
[01:24] <compn> you just want to record the stream ?
[01:37] <rock> comp: it is for conformaty and errors
[01:39] <rock> what would be ideal is one software that takes all the different stream protocols and finds out errors
[01:39] <rock> I could not find one
[01:39] <rock> I did find  quite a few for Apple HLS , but need to find out which one is the best
[01:41] <rock> I would need detail analysis of mpeg2 also
[01:42] <compn> rock : i dont know of any tools like that, unfortunately :(
[01:42] <compn> but someone else here may know of some
[01:42] <compn> wait around for a better answer , or ask on the mailing list
[01:43] <rock> thanks compn, will do .
[06:31] <cone-832> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:e97545646af7: ffserver: reflow http_vlog()
[06:31] <cone-832> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:7d3857b7ab59: ffserver: reindent http_vlog()
[06:31] <cone-832> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:eadd66a4aff7: ffserver: reflow handle_connection()
[06:31] <cone-832> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:197acee767dd: ffserver: reindent handle_connection()
[06:31] <cone-832> ffmpeg.git 03Reynaldo H. Verdejo Pinochet 07master:2699a3781675: ffserver: reflow find_stream_in_feed()
[09:54] <filterSAC> i'm writing a simple width and height change filter of a video can anyone give me some idea about that how can i do that ,can anyone give me some algorithm of that?
[13:03] <filterSAC> can anyone give me suggession how i understand vf_scale.c filter
[13:12] <cone-832> ffmpeg.git 03Christophe Gisquet 07master:ba6888c0e3b5: ffmpeg_opt: expand format for strftime
[13:38] <cone-832> ffmpeg.git 03Michael Niedermayer 07master:c651a1aaecb5: doc/APIchanges: Fill in remaining missing hashes
[14:27] <cone-832> ffmpeg.git 03Michael Niedermayer 07master:1296dc6025de: avutil/pixdesc: rewrite AV_PIX_FMT_FLAG_PSEUDOPAL documentation
[14:33] <ubitux> i'm doing an upsampling from 5 to 8 bits with (x*8423 + (1<<9))>>10
[14:33] <ubitux> is it ok or something better should be used?
[14:34] <ubitux> (not involving dithering here)
[15:28] <ubitux> what's best for the gif muxer: delay the writing of the header to the first write_packet call, or seek into the header to update the global palette at the first write_packet call?
[15:28] <ubitux> i suppose the former is better so it can work with non seekable output
[15:28] <nevcairiel> anyone wager a guess how often i want to stab myself when I try to add a new pixel format to swscale?
[15:29] <ubitux> haha
[15:29] <nevcairiel> its just a fancy 10/16bit yuv format, shouldnt be too bad, right <.<
[15:30] <kierank> which format?
[15:30] <nevcairiel> P010, ie. NV12 in with 10-bit
[15:30] <nevcairiel> the hevc 10-bit hw decoders output that
[15:30] <kierank> should already be in as NV16
[15:30] <kierank> sorry NV20
[15:31] <kierank> oh 4:2:0
[15:31] <kierank> meh
[15:31] <nevcairiel> the docs said that was 4:2:2
[15:31] <nevcairiel> yea :p
[15:31] <nevcairiel> P210 is 4:2:2
[15:31] <kierank> ok there's no nice name for 4:2:0
[15:31] <kierank> nv15 i guess
[15:31] <nevcairiel> i've never seen those numbers used
[15:31] <kierank> yeah i kind of made them up a bit
[15:31] <nevcairiel> MS uses NV12, but the others they call P010, P210, P whatever
[15:32] <kierank> but nv12 is a thing
[15:32] <nevcairiel> or P016 for full 16-bit
[15:32] <nevcairiel> the special part abut P010 is that it has the values in the high-bits
[15:32] <nevcairiel> unlike anything ffmpeg uses
[15:33] <nevcairiel> (which is kinda handy, as P010 and P016 are practically the same then, except more precision)
[15:33] <wm4> well, ffmpeg does with audio formats
[15:34] <nevcairiel> I bet the pixel format descriptor cannot even describe this properly :D
[15:34] <wm4> but for video, padding the high bits is apparently preferred, because it makes it easier to write ricer asm
[15:34] <nevcairiel> unless I just pretend its 16-bit
[15:34] <wm4> ah, who knows how the hell this pixel format descriptor works...
[15:34] <nevcairiel> i should probably just pretend its 16-bit
[15:34] <wm4> that should work just fine
[15:35] <nevcairiel> MS guarantees that the low bits are zero'ed
[15:35] <nevcairiel> especially for the reason to be lazy and only use one codepath for both 10 and 16 bit
[15:35] <wm4> ffmpegs own machinery will try not to convert it to ffmpeg native 10 bit, though, it'll try to keep it 16 bits
[15:36] <nevcairiel> well personally i wont really care
[15:36] <wm4> neither do I
[15:37] <wm4> I wonder how high bit depth vdpau works, though
[15:37] <wm4> or vaapi
[15:37] <nevcairiel> dont ask me
[15:37] <wm4> but the feeling of not caring is too string
[15:37] <wm4> *strong
[15:38] <nevcairiel> in dxva the driver tells you which kind of surface format it supports
[15:38] <nevcairiel> and the nvidia driver spits out P010 for the main10 hevc decoder
[15:40] <wm4> but P016 is still like nv12, but with 2 bytes per component, right?
[15:40] <nevcairiel> yes
[15:40] <nevcairiel> its otherwise the same
[15:40] <nevcairiel> and P010 is just the same with the 6 lower bits guaranteed zero
[15:41] <wm4> seems like ffmpeg calls this nv20
[15:41] <nevcairiel> i think thats 422
[15:41] <wm4> or nv16
[15:42] <nevcairiel> nv16 is 422 8-bit
[15:42] <nevcairiel> or at least in the non-ffmpeg world it is
[15:42] <wm4> oh
[15:42] <wm4> right
[15:42] <wm4> so it doesn't support P016?
[15:42] <nevcairiel> nope
[15:43] <wm4> and libswscale supports only nv12/21 (it's getting quite behind here...)
[15:44] <nevcairiel> once I have the 10-bit decoding actually working i will probably need to add p010/p016 support to swscale for the rest of my code to not break in some cases
[15:44] <nevcairiel> (or i convert in my own code to a format swscale understands, but thats not ideal)
[17:18] <kierank> nevcairiel: i don't envy you
[17:18] <kierank> working on swscale
[17:36] <wm4> RFC: should API users be allowed to ask API user-questions on #ffmpeg-devel and the mailing list?
[17:36] <wm4> without us telling them to "fuck off" (even if we do in a nice way)
[17:51] <kurosu> nevcairiel, so that nvidia 960 gtx does have a hw hevc decoder? I guess up to something like 4Kx2K 30fps?
[17:51] <nevcairiel> it decodes 80mbit 4kx2k at over 100 fps
[17:51] <kurosu> nice
[17:52] <kurosu> I guess people at tradeshows will no longer need openhevc then :D
[17:52] <nevcairiel> 10-bit support as well, although no speed numbers there yet, but i don't expect any big differences to 8-bit, thats just how hardware rolls
[17:53] <kurosu> unless you output to something through a bus
[17:54] <nevcairiel> yeah the double memory requirement is the only difference there really
[17:54] <kurosu> I'm not quite sure what the point of 10bits already in hw, seeing how the whole chain is probably several years from that
[17:54] <nevcairiel> well Blu-ray 4K will be 2160p @ 10-bit
[17:55] <nevcairiel> so being able to decode that is nice
[17:55] <nevcairiel> (and coming at the end of this year to consumer stores near you)
[17:56] <kurosu> so will the DVB new standard (or whatever it is called) but that's probably a bit later
[17:56] <kurosu> what's the chroma format on those btw? 4:2:0 (ie main10 hevc)
[17:56] <nevcairiel> yes
[17:56] <kurosu> ?
[17:56] <kurosu> ok
[17:56] <nevcairiel> with optional HDR metadata in SEI messages
[17:56] <nevcairiel> whatever these are
[17:57] <kurosu> (c) Dolby
[17:57] <nevcairiel> was some SMPTE spec listed, which i didnt bother to look up
[17:57] <kurosu> errr, (c) and $$$ Dolby, sorry
[17:57] <kierank> nevcairiel: do you want real world high 10 samples?
[17:58] <nevcairiel> some rumors mentioned SHVC layers with extra bitdepth as an optional feature, but i couldnt confirm that yet
[17:58] <kurosu> so they were serious
[17:58] <kierank> main 10 i mean
[17:58] <kurosu> but I thought the base layer would be avc in that case
[17:58] <kurosu> for legacy support purposes
[17:58] <nevcairiel> kierank: i have a few test recordings from various satellite broadcasts, but if you have anything handy, i always like test files
[18:00] <kurosu> http://www.display-central.com/free-news/display-daily/dolby-discusses-hdr-encoding/ <- something like that for HDR (actual HDR content mapped to 10bits through an EOTF)
[18:00] <nevcairiel> dolby is in video now too?
[18:00] <nevcairiel> i guess i just never paid attention to that
[18:02] <nevcairiel> i wonder if our decoders here will ever do those HDR things, or if its just a reason for more people to buy blu-ray players
[18:02] <kierank> it's a reason for people to buy new tvsd
[18:03] <kierank> only 10-20% of them sit close enough to notice 4k
[18:03] <kierank> so they need to be sold something else
[18:05] <nevcairiel> if it gives us more life-like images, i'm all for that. It would just be a shame if a PC could never produce an image like this
[18:05] <kurosu> the purpose of hdr is to be able to have both very low-luminosity and high-luminosity at the same time
[18:06] <kurosu> but afaik, no valid screen is availabe except in research circles, and they most often burn your eyes with a few hours
[18:06] <nevcairiel> but if this info could just be applied to the YUV or RGB info, then it would just be .. so this metadata has to be of other uses, and probably needs to reach the TV somehow
[18:07] <kurosu> exactly
[18:07] <nevcairiel> .. which makes it so much harder for a PC to ever do that
[18:07] <kurosu> I think dolby was mentioning how a few companies were starting to think about it
[18:07] <kurosu> toshiba iirc
[18:08] <kierank> nevcairiel: that's what the bbc proposal does
[18:08] <kierank> it uses the 235->255 excursions
[18:08] <kierank> kurosu: they also have insane power consumption which the EU will not allow
[18:08] <kurosu> http://www.whathifi.com/news/ces-2015-4k-hdr-quantum-dot-and-dolby-vision-explained <- something like that
[18:09] <kurosu> the platform is dubbed "Dolby vision"
[18:09] <nevcairiel> i hear SMPTE ST 2084 and ST 2086 mentioned in the context of Blu-ray 4K
[18:09] <nevcairiel> *heard
[18:09] <kurosu> but that's tradeshow guys speaking, the technical guys are saying "we are far from being able to produce that at a reasonable price"
[18:10] <kurosu> a bit like oled, maybe
[18:10] <nevcairiel> all these things talk about needing a much brighter screen, which does indeed seem like its not going to be available cheap any time soon
[18:10] <nevcairiel> like, talking about 4000nits
[18:11] <kierank> the eu will not allow 4000 nits full stop
[18:12] <nevcairiel> The cost of this powerful clarity is four times as many LEDs and a liquid cooling system to keep it running. 
[18:12] <nevcairiel> :D
[18:12] <kurosu> err, is "4000 nits full stop" that a pun or?
[18:12] <wm4> wtf
[18:12] <wm4> liquid cooled displays?
[18:12] <kierank> kurosu: translated into american 4000 nits period
[18:12] <nevcairiel> wm4: at those brightness levels, it produces loads of heat
[18:13] <nevcairiel> I would be happy with proper 10-bit displays that cover BT.2020 properly
[18:13] <nevcairiel> but even that is years out
[18:13] <kurosu> kierank, yeah, but people sometimes do nits <-> f-stops
[18:13] <kierank> ah
[18:13] <kurosu> hence my remark
[18:16] <kurosu> anyway, in case you didn't know, it's quite likely we won't see many openhevc updates
[18:17] <nevcairiel> its been rather quiet on their side for a while already
[18:18] <jamrial> OpenHEVC? it has seen some development in the past few months. last i checked they added neon asm
[18:19] <jamrial> x86 is still mostly intrinsics. after plepere left the yasm ports stopped
[18:19] <jamrial> there's is an (unfinished i think) sao yasm port in the tree, though
[18:20] <nevcairiel> its unfortunate noone really cares (yet), but maybe that will change over time when popularity and content availibilty picks up
[18:21] <nevcairiel> right now there still is zero content, so why would anyone bother :d
[18:22] <jamrial> as long as encoding takes a milenia for a 1080p video, i don't see any content being created in the foreseeable future outside of blu-ray 4k :p
[18:22] <nevcairiel> 4k broadcast will happen, and doesnt netflix to 4k? i guess they still use avc?
[18:25] <kurosu> I don't think there will be much care for sw decoders
[18:25] <kurosu> by the time content is widely distributed, most new devices and pcs sold will have hw decoding
[18:34] <ubitux> weird gif is weird. if you use a global palette you are forced to define a transparent color
[18:34] <ubitux> but if you use a local palette, then it can be not transparent
[18:34] Action: ubitux confused
[18:35] <wm4> well this format is how old? 20 years?
[18:36] <wm4> actually 28 years
[18:36] <ubitux> it's also funny that for the local palette, even if you say there is no transparent color, you have to set a value anyway
[18:37] <ubitux> because otherwise the block is "too small" (even though there is a mechanism of size/end of block, but it's actually fixed size)
[18:38] <ubitux> i wonder if i should still put the 0x1f (??) color index as transparency if i don't find any transparent color in the palette
[18:39] <ubitux> (looks like a 5 bit resolution index..)
[18:41] <ubitux> mmh maybe the per block transparency bit is also refering to the global one
[18:53] <cone-582> ffmpeg.git 03Hendrik Leppkes 07master:77140279d330: hevc: pass the full HEVCNAL struct to decode_nal_unit
[18:53] <cone-582> ffmpeg.git 03Michael Niedermayer 07master:15848c623d18: avdevice/dshow_crossbar: Avoid mixing declarations and statements
[19:42] <kurosu> nevcairiel, "Hardware Accelerators require access to the escaped bitstream." <- that's dxva API I guess? Maybe that could be optional? (no idea if that's actually worth it)
[19:44] <kurosu> otherwise, I guess that'll interest a lot of people
[19:44] <kurosu> I can't much comment more than that on that patchset, though
[20:22] <cousin_luigi> Greetings.
[20:24] <nevcairiel> kurosu: all HW APIs require that, at least on H264 they did, I don't think this will be different now
[20:25] <nevcairiel> for sending a bitstream to an external parser, it kinda makes sense to keep the escapes in it
[20:26] <cousin_luigi> Pray, what does the asm bit in libavutil/arm/timer.h do?
[21:04] <wm4> cousin_luigi: probably similar to rdtsc on x86
[21:04] <wm4> a cycle counter
[21:04] <wm4> (guessing here)
[21:07] <cousin_luigi> wm4: what happens if it's not defined? Is it replaced by some high-level routine?
[21:08] <wm4> it sets the macro AV_READ_TIME and there's some ifdef hell in timer.h to handle it
[21:10] <cousin_luigi> wm4: I have a patch in a build script for opensuse and I wondered if it was still needed.
[21:10] <jamrial> cousin_luigi: yes, gethrtime or mach_absolute_time if available
[21:10] <cousin_luigi> wm4: http://pastebin.com/raw.php?i=KBHWS6e2 <- it builds anyway
[21:10] <cousin_luigi> jamrial: oh I see.
[21:10] <cousin_luigi> Better keep it then?
[21:12] <jamrial> if possible then yeah
[21:13] <cousin_luigi> ok thanks
[23:11] <cone-388> ffmpeg.git 03Philip Langdale 07master:ff0c559329bd: nvenc: Propagate desired number of reference frames.
[23:25] <yayoi> Hi, I am adding threading to colormatrix and made a small improvement from 32 to 35 fps
[23:25] <yayoi> and I am not sure if I should finish the patch or no. 
[23:25] <BBB> slicing?
[23:26] <yayoi> yes
[23:26] <ubitux> BBB: there is only slice threading in lavfi
[23:27] <BBB> that sounds acceptable? although Id prefer frame threading in lavfi :)
[23:27] <yayoi> it is in libavfilter yes
[23:33] <wm4> sounds very minor, but on the other hand the patch is probably simple?
[23:34] <yayoi> yes
[23:34] <yayoi> i just added slicing.. and i only did one so far.. 
[23:35] <yayoi> out of three that i can add slicing for colormatrix
[23:36] <yayoi> i did slicing for process_frame_uyvy422
[23:36] <yayoi> but there are still yuv420p
[23:36] <yayoi> and yuv422p
[23:37] <yayoi> so i wonder that i should keep going or not.. since it is not much performance gain
[23:44] <wm4> you're probably bottlenecked by something
[23:44] <wm4> memory bandwidth? the way you test it?
[23:45] <ubitux> colormatrix isn't very complex so that's not exactly surprising
[23:48] <yayoi> the patch is looks like this right now
[23:48] <yayoi> http://pastie.org/9857820
[23:48] <yayoi> the way i tested is 
[23:48] <yayoi> ./ffmpeg -f lavfi -i testsrc=hd1080 -vf format=uyvy422,colormatrix=bt709:smpte240m -f null -
[23:53] <yayoi> how i know memory bandwidth?
[00:00] --- Sun Jan 25 2015