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

[burek]

[02:14] <cone-101> ffmpeg.git 03Michael Niedermayer 07release/1.2:4ce6d65b6fbe: Changelog: update for 1.2.8
[03:26] <cone-101> ffmpeg.git 03Michael Niedermayer 07release/1.2:59b2a9ef957e: remove VERSION file
[03:26] <cone-101> ffmpeg.git 03Michael Niedermayer 07release/1.2:0a64e9a0299b: version.sh: Print versions based on the last git tag for release branches
[03:46] <cone-101> ffmpeg.git 03Lukasz Marek 07fatal: ambiguous argument 'refs/tags/n1.2.8': unknown revision or path not in the working tree.
[03:46] <cone-101> Use '--' to separate paths from revisions
[03:46] <cone-101> refs/tags/n1.2.8:HEAD: lavu/log: add device category macros
[05:54] <jamrial> https://gcc.gnu.org/develop.html#num_scheme Oh boy
[05:54] <jamrial> everybody wants to be like chrome
[06:29] <mark4o> nobody wants an x.10 version number
[06:29] <mark4o> Except Apple, who can't get enough 10's ever since making X/10 part of the OS name OS X 10.10.
[07:57] <Kovensky> jamrial: so they're formalizing the notion that .0 releases are bad
[08:40] <plepere> good morning
[08:41] <nevcairiel> Morning
[09:50] <kurosu__> plepere, hi
[09:51] <kurosu__> plepere, are there plans for you to spend time submitting patches for idct ?
[09:51] <kurosu__> the transform_add is, if I'm not mistaken, a small stepping stone
[09:52] <kurosu__> plepere, I'd suggest adding small bits of the transforms, eg start with 4x4 dst/dct then 8x8
[09:53] <kurosu__> 16x16 and 32x32 are already large beasts in getting them to work in yasm
[09:54] <plepere> I can do that. :)
[09:55] <plepere> kurosu__, it seems that we have some ASM idct_dc functions
[09:55] <plepere> if that's the question
[09:56] <kurosu__> yeah, but the actual idct are useful/needed
[09:56] <kurosu__> what you have as intrinsics in openhevc is like 20-40% speedup, so that's a major thing missing
[09:56] <kurosu__> *full idcts
[09:57] <nevcairiel> after i applied the idct and sao intrinsics, final performance was over 100% faster than ffmpeg master today
[09:57] <plepere> yeah
[09:58] <plepere> but the problem is that intrinsics doesn't have a register limit, so it cheats quite well
[09:59] <kurosu__> nevcairiel, is that for toying around or do you plan to have the patched code used eg in some distributed software (not a license issue, just bug issues)
[09:59] <ubitux> 4x4 and 8x8 should not hit the register limit
[09:59] <nevcairiel> i'll probably have it in the distribution of my software, but those people report their problems to me anyway
[10:00] <kurosu__> nevcairiel, ok
[10:00] <kurosu__> is that using my branch or yours? I'm asking because of my proposed multithread api
[10:01] <plepere> Ok, I'll try to do the transforms. :)
[10:01] <kurosu__> so far I'm the only one having an interest/figures, and so I'm wondering if an improvement is seen on other more-than-2-cores systems
[10:01] <nevcairiel> kurosu__: i just applied the intrinsics
[10:02] <kurosu__> ok
[10:02] <nevcairiel> and manually at that, not picked from your tree
[10:03] <kurosu__> nevcairiel, so did I, it's not a merge from openhevc, just a hack job
[10:05] <nevcairiel> i applied the gcc pragmas, so i can still build the main code without the high sse requirements
[10:05] <nevcairiel> i hope gcc works properly with those options :P
[10:08] <nevcairiel> in a couple weeks i could possibly test the threading changes on a 6-core X99 platform, but considering the hardware isnt even available yet, it'll still be a bit
[10:12] <kurosu__> iirc sse4 is needed for hevc mc only for pextrw, and that's for small, hardly used, chroma partitions
[10:34] <__gb__> hi wm4, libva itself is not thread-safe, that part is delegated to the driver
[10:34] <__gb__> On the Intel HD Graphics side, there seems to be a render mutex held during output to X11. Though, that does not preclude anything to other bits/operations...
[10:36] <__gb__> wm4, anything specific to expose issues? on what display backend?
[11:35] <cone-383> ffmpeg.git 03Ben Hagen 07master:c9a5497a0b4d: avformat/cinedec: allow number zero in metadata
[12:21] <Daemon404> wm4, https://www.dropbox.com/s/hewentitmd4n0db/deb1.png
[12:21] <Daemon404> sigh.
[12:21] <Daemon404> definitely worth privately mailing me.
[12:24] <nevcairiel> debian folks are special kind of weirdos
[12:24] <Daemon404> https://www.dropbox.com/s/mxhpq93wfcul6nk/deb2.png
[12:25] <Daemon404> ^ i replied by trolling
[12:25] <Daemon404> ;)
[12:25] <Daemon404> (text looks weird cause im RDPing from a high dpi box to a server that i originally logged into from a low dpi box... :MS:)
[12:31] <Compn> Daemon404 : should have replied with, ' i added it to my TODO *Do Not Troll' :P
[12:32] <Daemon404> lol
[12:32] <Daemon404> dammit Compn 
[12:32] <Daemon404> that would have indeed been better
[12:53] <ubitux> /home/ux/fate/ffmpeg/libavcodec/mpegaudiodec_template.c:1546:1: internal compiler error: Segmentation fault
[12:53] <ubitux> ...
[12:53] <ubitux> ffs
[12:53] <Daemon404> haha.
[12:54] <ubitux> not sure what's going on here, i didn't change anything on the box
[12:55] <Daemon404> ubitux, it picked a lovely file to ICE on too
[12:55] <ubitux> :)
[13:03] <cone-383> ffmpeg.git 03Pavel Koshevoy 07master:6380f2e3670a: avfilter/atempo: Flush all buffered input samples
[13:19] <nevcairiel> could be worse, could be mpegvideo
[13:32] <BBB> Daemon404: I call this the last-word-theory
[13:33] <BBB> Daemon404: saw it a lot in gnome - as a thread grows longer, the usefulness of replies goes towards zero; but people will keep iterating the same general themes, because if youre the last response, youve won
[13:34] <Daemon404> fun
[13:34] <BBB> debian is just like that
[13:35] <BBB> I see a sine wave of reply-recursion, where after a week, Ive quite literally seen it all
[13:35] <Daemon404> have you heard the word of our Lord and savior, gerrit, BB?
[13:35] <Daemon404> BBB*
[14:01] <cone-383> ffmpeg.git 03Christophe Gisquet 07master:1467780772d6: huffyuvenc: add a non-deterministic option
[14:17] <BBB> Daemon404: I did! it prevents world hunger and saves bickering and infighting, just by means of a simple credo and policy: thy shallt review!
[14:17] <BBB> Daemon404: and voila, all evil vanishes!
[14:20] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:76a8cb9d7bcc: avcodec/proresenc_kostya: set initial max_slice_size based on frame_size_upper_bound
[14:20] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:f0e51be8d027: avcodec/proresenc_kostya: allocate 1 slice more to avoid triggering the reallocation warning when the used space is actually less than the allocated
[15:40] <cone-383> ffmpeg.git 03Paul B Mahol 07master:02dc75f218e9: avcodec/pafvideo: remove unused header
[15:40] <cone-383> ffmpeg.git 03Paul B Mahol 07master:9a07c15f4893: avcodec/pafaudio: use paf.h instead
[16:06] <alexfu> I've got the following code... http://pastebin.com/8rUVQxc0 and i get a stange warning at the bottom... not sure exactly what that means
[16:07] <Daemon404> it's exactly what it says.
[16:07] <Daemon404> https://www.ffmpeg.org/doxygen/trunk/group__lavc__core.html#gae80afec6f26df6607eaacf39b561c315
[16:07] <Daemon404> you are not passing what it is supposed to take.
[16:08] <alexfu> Daemon404: oh shoot. i thought i was passing a codec
[16:10] <alexfu> i'm actually surprised thats a warning
[16:13] <alexfu> is it possible to get a codec context from a newly allocated avformatcontext?
[16:13] <alexfu> i would assume format_context->streams[i]->codec->codec_type would only work if it has data in it
[16:14] <cone-383> ffmpeg.git 03rogerdpack 07master:ea97859c8c21: gdigrab: fix gdi object leak if using mouse
[18:01] <cone-383> ffmpeg.git 03Christophe Gisquet 07master:11a39bdf534a: wavpack: report if there is no bits left
[18:16] <cone-383> ffmpeg.git 03Christophe Gisquet 07master:2ba58bec20b0: wavpackenc: proper buffer allocation
[18:30] <kurosu__> what part of libav* would deal with conversion of rgb formats with different packings ?
[18:31] <kurosu__> I'm asking this because the ljpeg decoders selects RGB48 for any bitdepth >8, and then stores that in AVCodec's bits_per_raw_pixel
[18:31] <kurosu__> the conversion could maybe notice that this is only a repacking without resampling or intended bitdepth change
[18:31] <kurosu__> and thus copy this over to the output format
[18:32] <kurosu__> allowing anything to use that info
[18:32] <kurosu__> example: input is "Stream #0:0: Video: mjpeg, bgr48le(12 bpc, bt470bg), 1200x1200, 25 tbr, 25 tbn, 25 tbc"
[18:33] <nevcairiel> Any such conversions are in swscale presumably
[18:33] <kurosu__> output is "Stream #0:0: Video: ppm, rgb48be, 1200x1200, q=2-31, 200 kb/s, 25 fps, 25 tbn, 25 tbc"
[18:33] <kurosu__> at least the 12bpc information could be used
[18:33] <cone-383> ffmpeg.git 03Diego Biurrun 07master:86dfcfd0e30d: mov: Drop unused parameter from ff_mov_read_esds()
[18:33] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:b07dc81a9e35: Merge commit '86dfcfd0e30d6645eea2c63c1c60a0550e7c97ea'
[18:33] <nevcairiel> swscale isn't that smart
[18:33] <kurosu__> nevcairiel, I bet so, and I intended to only check that on ffmpeg's side
[18:34] <kurosu__> afaik, the scale filter seems used
[18:34] <nevcairiel> But if you're lucky it just reorders the bgr to rgb
[18:34] <nevcairiel> If you're unlucky, it goes through yuv
[18:34] <nevcairiel> sws is fun like that
[18:39] <cone-383> ffmpeg.git 03Diego Biurrun 07master:8bc52dbd9dff: vfwcap: Drop fallback VfW defines
[18:39] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:c18a3b3e8ef4: Merge commit '8bc52dbd9dffb1b2fa4a6aeed2d298d036b619b2'
[18:57] <kurosu__> that's probably doable in ffmpeg instead
[18:57] <kurosu__> as it's a reencoding issue
[19:02] <wm4> <__gb__> wm4, anything specific to expose issues? on what display backend? <- user reports weird behavior and crashes when using vaapi decoding and native vaapi output, but not when using GLX interop output (both on i965)
[19:02] <wm4> __gb__: and that started to happen since the decoder runs on a separate thread
[19:06] <__gb__> wm4, surprising, I would have actually expected the opposite case to happen :)
[19:07] <__gb__> though I remember a discussion on libav-devel and I was actually ok to remove the lavc side lock so that to expose bugs in driver
[19:07] <__gb__> so, it seems there are then. do you have a self-contained test case handy around?
[19:08] <__gb__> anyway, I have one around for FFmpeg/vaapi demonstration purposes, but not decoding in a separate thread yet
[19:09] <wm4> __gb__: no, I just have my player code (mpv), a rather big thing; but I'm not doing much special
[19:09] <wm4> though it's true that it's still possible that the error is on my side
[19:10] <__gb__> I will try to remember about it for my TODO, but no immediate promise :)
[19:10] <nevcairiel> In the not too far future I'll venture into that area as well.
[19:10] <nevcairiel> Fix all the bugs before!
[19:10] <nevcairiel> :D
[19:11] <cone-383> ffmpeg.git 03Diego Biurrun 07master:d456baafb68c: vc1: Add missing parentheses to conditions in vc1_decode_b_mb_intfr()
[19:11] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:580e81fca578: Merge commit 'd456baafb68cd80c0f537f1d843076e4dd853558'
[19:12] <nevcairiel> Although I'll probably stick to glx interop, don't feel like multiple outputs
[19:12] <wm4> I'm just very confused that something as fragile as GLX interop works well (you'd expect that it's harder to make it thread-safe)
[19:13] <__gb__> yes, exactly, and from a VA intel-driver perspective, there is no native support for GLX interop, so the default code in libva is used, which definitely is not thread-safe, iirc
[19:34] <alexfu> is there a way I can figure out the reason why avformat_open_input is failing? i.e is there a way to determine if the error is a file not found or file locked error?
[19:35] <llogan> i'm back now. thanks for keeping up with the mail queue.
[19:44] <SanJose_Kid_> hello
[19:44] <SanJose_Kid_> so an issue we're facing is there is no translation b_annexb to x264 in libavcodec - so it seems
[19:45] <SanJose_Kid_> were trying to stream x264 in Annex B format - any idea if this is supported ?
[19:45] <llogan> SanJose_Kid_: #ffmpeg is the channel for user support
[19:46] <SanJose_Kid_> i see - im pretty sure this might not be supposed by current system and would require patch / extension to framework
[19:46] <iive> check the bit stream filters
[19:46] <iive> bfs
[19:47] <J_Darnley> perhaps it is h264_mp4toannexb you are looking for
[19:49] <llogan> and x264 is an encoder, not a video format
[19:49] <J_Darnley> If you're actually encoding using x264 I thought it gave you annexb anyway (or at least an option)
[19:50] <SanJose_Kid_> thank you - great
[19:50] <SanJose_Kid_> sorry i assumed this was not supported and mentioned in this channel
[19:52] <SanJose_Kid_> thanks again
[19:54] <cone-383> ffmpeg.git 03Diego Biurrun 07master:14d2006ca6c0: pcm: Drop unused variable from DECODE_PLANAR macro
[19:54] <cone-383> ffmpeg.git 03Diego Biurrun 07master:6af2930222ee: pcm: Drop av_unused attribute from variable that is always used
[19:54] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:4042c8eee187: Merge commit '14d2006ca6c0e2b54784b93560f09e0e19c0a270'
[19:54] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:746095bc2981: Merge commit '6af2930222ee5d8ce19f3b999a78d85a3c457391'
[20:15] <cone-383> ffmpeg.git 03Diego Biurrun 07master:b977b287f61f: vsrc_movie: Avoid a variable indirection in movie_get_frame()
[20:15] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:b1cf83b3d4e8: Merge commit 'b977b287f61fea48ecd6251d54a26334213b7ec6'
[20:19] <alexfu> is there a way to debug avcodec_encode_video2? it fails (crashes the app) without any output
[20:22] <wm4> gdb?
[20:27] <alexfu> wm4: i tried that but it doesnt display anything
[20:28] <alexfu> nothing useful that is... all i get is "Program received signal SIGSEGV, Segmentation fault."
[20:29] <alexfu> hm
[20:31] <alexfu> can av_init_packet not accept NULL?
[20:33] <wm4> probably not
[20:41] <cone-383> ffmpeg.git 03Moritz Barsnick 07master:66d02d3ca626: align and correct messages regarding bitstream filters
[20:44] <alexfu> is this workflow correct? http://pastebin.com/CCQXhA1Y
[20:45] <alexfu> or am i missing something?
[20:53] <alexfu> damnit..  an invalid codec would probably cause a segfault in avcodec_encode_video2 right?
[21:04] <alexfu> any possible reason why when i call avcodec_alloc_context3(codec); passing in a MPEG-4 codec, the resulting codec context has an invalid codec?
[21:05] <wm4> also I think you need to open the codec for encoding, but not sure
[21:10] <alexfu> wm4: you seem to be correct
[21:20] <alexfu> wm4: do you know if the resulting AVCodecContext (from avcodec_alloc_context3) supposed to have a NULL codec?
[21:21] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:6ea69a8ffaea: avcodec/tiff: do not use photometric to detect pix_fmt
[21:21] <cone-383> ffmpeg.git 03Michael Niedermayer 07master:f0c0ae37c669: avcodec/tiff: Check that pix_fmt is a yuv variant for TIFF_PHOTOMETRIC_YCBCR
[21:26] <wm4> alexfu: don't know, maybe not
[22:54] <alexfu> does av_log simply write to stdout?
[22:55] <wm4> by default yes, there's a global log callback which you can set to override the beavhaior
[23:07] <alexfu> so i see a "08-19 17:04:40.030: I/FFMpeg(2593): Specified pixel format -1 is invalid or not supported
[23:08] <alexfu> sorry, i see a "Specified pixel format -1 is invalid or not supported" message right before avcodec_open2 errors out... any idea what that possibly means?
[23:10] <cone-383> ffmpeg.git 03Jon Morley 07master:18e70006e7d3: avcodec/adpcm: Fix incorrect AVSampleFormat for sample_fmts_s16p
[23:20] <alexfu> do you have to specify pixel format for an encoder?
[23:20] <alexfu> or is that automatic?
[23:36] <Compn> depends what you are doing, probably yes
[23:47] <michaelni> can i push "Re: [FFmpeg-devel] [PATCH] x86: hevc: adding transform_add" ? or someone else wants to comment? (james asked "Not sure if someone else wants to comment (Ronald?)")
[23:52] <cone-383> ffmpeg.git 03James Almer 07master:b4231b4fedc2: lavc/tiff: move unpack_yuv() above the deflate functions
[23:52] <cone-383> ffmpeg.git 03James Almer 07master:201a511bb9dd: lavc/tiff: add support for YUV deflate
[00:00] --- Wed Aug 20 2014