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

[burek]

[00:03:46 CEST] <Angus> it seems the server that hosts the ffmpeg doxygen just died
[00:11:12 CEST] <kierank> durandal_1707: yes I agree
[00:46:47 CEST] <michaelni> Angus, http://ffmpeg.org/doxygen/trunk/index.html works fine here
[04:34:27 CEST] <jamrial> ubitux: are your fate clients dead? they haven't updated in two days
[08:30:27 CEST] <ubitux> michaelni: mmh no didn't see, will have a look
[08:56:29 CEST] <kurosu> kierank, isn't transport stream "encapsulable" in yet another layer (IP?) which can be encapsulated again in ts (GSE?) ? Disclaimer: this is likely gibberish
[08:56:52 CEST] <kurosu> I'm not siding with Carl, on the contrary, but that's more for personal education
[10:35:47 CEST] <cone-748> ffmpeg 03wm4 07master:66dd21d50be1: avcodec/utils: split side-data in new decode API too
[11:10:06 CEST] <wm4> is there a way to make x264 write a crop rectangle? I see that it has a crop video filter, but that's useless
[11:17:33 CEST] <b_amabo> kierank: I have build afl on my ubuntu machine, but i seem to be missing the command to compiling the source in fffuzz folder which I clone from: https://github.com/OpenBroadcastSystems/fffuzz. Any heads up?
[11:26:02 CEST] <jkqxz> wm4:  It's crop_rect in the x264 parameters.  ffmpeg libx264 doesn't support it directly, but something like '-x264opts crop-rect=0,0,0,8' works.
[11:26:20 CEST] <wm4> ah thanks
[11:28:04 CEST] <nevcairiel> man gnu infrastructure is slow today, even more so then usual, even downloading tarballs fails from their main site, guess i need to change my script to some mirror
[11:31:13 CEST] <wm4> aw x264 refuses non-mod2 crop
[11:31:33 CEST] <nevcairiel> because it sane? :)
[11:31:57 CEST] <wm4> there's no reason why crop should be mod-2
[11:32:48 CEST] <nevcairiel> except that its a pain in the behind if its not, because you have to crop after rgb conversion, which adds a lot of complexity
[11:32:48 CEST] <jkqxz> There is with 4:2:0.  Try 4:4:4?
[11:33:09 CEST] <wm4> well 4:4:4 is generally supported by sw decoders only
[11:33:53 CEST] <rcombs> ~subsampling~
[11:34:20 CEST] <rcombs> I'm reminded of http://inta.re
[11:38:34 CEST] <jkqxz> The crop variables which you actually write in the SPS in H.264 are divided by the subsampling.  You just can't express odd cropping at all.
[11:39:00 CEST] <nevcairiel> i know hevc does that, i guess h264 as well then huh
[11:39:47 CEST] <wm4> hm is that so
[11:40:46 CEST] <rcombs> "crop in macropixels" I guess
[11:41:03 CEST] <wm4> jkqxz: hm seems so
[11:41:34 CEST] <wm4> (the ffmpeg jpeg decoder can output non-mod2 sizes anyway)
[11:41:39 CEST] <nevcairiel> somehow i feel like i have seen odd cropping in h264 before
[11:42:04 CEST] <nevcairiel> but maybe it was interlaced 420 with mod2 cropping, which is once again problematic then
[11:42:14 CEST] <nevcairiel> since fields then have odd height
[11:42:40 CEST] <rcombs> http://inta.re
[11:42:54 CEST] <jkqxz> Look at H.264 section 7.4.2.1.1, CropUnitX and CropUnitY.
[11:43:08 CEST] <wm4> rcombs: I don't get it
[11:43:26 CEST] <rcombs> ZETTAI DAME
[11:43:26 CEST] <jkqxz> (It also includes a fiddle for interlaced.)
[11:43:57 CEST] <rcombs> ("absolutely useless")
[11:45:34 CEST] <nevcairiel> maybe i'm just remembering wrong and it just wasnt h264
[11:50:08 CEST] <fritsch> rcombs: did you have a chance to test vtb with the interlaced h264?
[11:50:15 CEST] <rcombs> not yet
[11:50:34 CEST] <fritsch> oki, no hurry - i am just interested as I could not find public specs
[11:51:44 CEST] <rcombs> the only docs for videotoolbox are the headers, a WWDC transcript, and I think a tech note or two
[11:55:15 CEST] <wm4> rcombs: that's definitely worse than microsoft
[11:55:24 CEST] <rcombs> yup
[11:55:43 CEST] <rcombs> audiotoolbox is _generally_ pretty well-documented
[11:57:20 CEST] <rcombs> but there are some odd quirks, at least one function that's internally broken because someone misplaced a & (it takes a void*, but to get it to work you have to pass in `*(int*)pkt->data`), and a few features that just aren't documented at all
[11:57:47 CEST] <fritsch> lol about that bug
[11:59:23 CEST] <rcombs> (it reads the first 4 bytes)
[12:07:07 CEST] <Carlrobertoh> Could please anybody help me out? I'm able to capture screen with codec h.264 and save it on disk as test.h264 file. But if i want to save it on disk as test.mp4 then it doesn't play the video.
[12:09:32 CEST] <Carlrobertoh> Also, the .mp4 video can be played in MPlayer but cannot played in VLC.
[12:10:29 CEST] <Carlrobertoh> Also if I use ffmpeg command line tool to encode .h264 byte-stream to mp4 then it works like a charm
[13:23:01 CEST] <Compn> Carlrobertoh : ask in #ffmpeg , this channel is for development
[13:28:16 CEST] <cone-579> ffmpeg 03Michael Niedermayer 07release/2.8:2a158602273f: avformat/ffmdec: Check pix_fmt
[13:28:16 CEST] <cone-579> ffmpeg 03Michael Niedermayer 07release/2.8:4e4afe29b989: avcodec/motion_est: Attempt to fix "short data segment overflowed" on IA64
[14:06:13 CEST] <cone-579> ffmpeg 03Michael Niedermayer 07release/2.8:da4ea9716173: Changelog: update
[14:22:07 CEST] <cone-579> ffmpeg 03wm4 07n2.8.7:HEAD: avcodec/utils: split side-data in new decode API too
[14:25:52 CEST] <wm4> wut, how is the new decode api in an old release?
[14:27:09 CEST] <wm4> must be some sort of irc bot glitch
[14:27:35 CEST] <nevcairiel> it glitches the message on tags, yes
[14:27:55 CEST] <nevcairiel> uses last master commit for the message for some reason
[15:25:19 CEST] <Daemon404> ubitux, feel free to do some merges this weekend
[15:25:25 CEST] <Daemon404> im traveling till monday
[16:48:09 CEST] <durandal_1707> michaelni: why is irc operator status lost?
[17:21:01 CEST] <BBB> durandal_1707: he probably didnt identify with nickserv
[17:23:12 CEST] <durandal_1707> BBB: I'm talking about users who identified and have voice
[17:33:12 CEST] <BBB> hm, strange
[19:30:54 CEST] <michaelni> f*cking ISP
[19:30:59 CEST] <kurosu> kierank, could you provide a command-line to generate a realistic vc2 bitstream where vlc reading is costly ?
[19:43:25 CEST] <durandal_1707> I'm fine if new reader is faster but I dislike unnecessary long renames
[19:44:24 CEST] <kurosu> durandal_1707, what do you mean? as in function names? or in number of patches?
[19:45:07 CEST] <durandal_1707> names
[20:30:45 CEST] <kurosu> anyway, that's unlikely to be the only issue - it's a codecpar situation again
[20:31:55 CEST] <kurosu> but the situation can be incrementally fixed, though
[20:55:49 CEST] <kylophone> I've built ffmpeg_g, but it's still linking to a libavfilter without debug symbols. Is there a config flag or something to build debug versions of the libs?
[20:57:10 CEST] <wm4> --disable-stripping AFAIK
[20:57:16 CEST] <wm4> and yes this is dumb
[20:57:56 CEST] <wm4> kurosu: not comparable at all, since the old bitstream reader can just exist forever
[21:07:46 CEST] <jamrial> wm4: --disable-stripping skips stripping ffmpeg after being copied from ffmpeg_g. the libraries afaik are not supposed to be stripped as part of the building process
[21:08:10 CEST] <BtbN> sounds like it's using some random libraries from somewhere else on your system.
[21:09:32 CEST] <wm4> eh
[21:10:01 CEST] <wm4> why can't ffmpeg just be debuggable out of the box
[21:10:17 CEST] <DHE> it is
[21:10:34 CEST] <DHE> if you just run configure without args, you'll get an ffmpeg_g with full debug symbols all the way through the libav* components
[21:10:59 CEST] <DHE> as BtbN said, it sounds like it pulled in libav* from elsewhere. like maybe /usr/lib ?
[21:14:15 CEST] <Compn> also this is #ffmpeg question
[21:16:58 CEST] <kylophone> `--disable-stripping' seems to work for this.
[21:18:23 CEST] <kylophone> DHE: Running configure without flags seems like a weird solution. What if you wanted to debug something that required a configure flag to be built?
[21:18:46 CEST] <DHE> *thunk*
[21:19:11 CEST] <kierank> kurosu: anything high bitrate
[21:19:37 CEST] <kierank> 5gbit/s 4k
[21:30:49 CEST] <kurosu> wm4, sure, I even mentioned that afterwards, but I was thinking of the large amount of things to port
[21:32:20 CEST] <kurosu> kierank, I was more thinking of a command-line but nevermind - you'll do it if that interests you
[21:33:26 CEST] <kurosu> I think it will work pretty much everywhere when vlc parsing is costly - my test on ffmpeg's huffyuv show around 10% improvement
[21:48:54 CEST] <durandal_170> Nope, too much busy
[21:51:51 CEST] <kurosu> kierank, huffyuvdec is mostly macros - and there are several occurrences of a reader loop, but dirac/vc2 might be less easy to translate
[21:52:30 CEST] <kurosu> iirc, some golomb reading is the most costly part at those bitrates, so it should likely be the main focus
[21:53:20 CEST] <kurosu> Compn, yes, it's an all-intra codec, so frame multithreading is almost free
[21:54:18 CEST] <kurosu> I thought there were slices in ffvhuff, but it appears not - no big deal except for low delay decoding
[22:06:03 CEST] <Angus> hmm. [swscaler @ 0x8e2c60] vdpau_h264 is not supported as output pixel format
[22:06:35 CEST] <Angus> I assume av_read_frame can't be used with a vdpau_h264 AVPixelFormat?
[22:09:29 CEST] <kurosu> actually, dirac looks more bothersome
[22:13:41 CEST] <Angus> oh, it's this that's spewing out the error: sws_getContext
[22:36:03 CEST] <wm4> Angus: libswscale doesn't support GPU surfaces
[22:36:13 CEST] <wm4> Angus: and this has nothing to do with av_read_frame at all
[22:37:04 CEST] <wm4> Angus: on ffmpeg git, you can use av_hwframe_transfer_data() to get a GPU surfaces in CPU
[22:37:14 CEST] <wm4> well, to copy it to CPU memory
[22:44:16 CEST] <rcombs> (kinda makes sense that _sw_scale wouldn't support hardware surfaces)
[22:46:24 CEST] <wm4> some say it should
[22:57:33 CEST] <Angus> does vdpau_get_buffer do the same thing as av_hwframe_transfer_data?
[22:57:40 CEST] <wm4> no
[22:57:44 CEST] <wm4> not at all
[22:58:02 CEST] <wm4> vdpau_get_buffer allocates a new GPU surface from a pool
[22:58:16 CEST] <Angus> Ah.
[22:58:29 CEST] <wm4> av_hwframe_transfer_data copies a GPU surface's data to a CPU surface (but it can allocate the memory for the CPU memory for you)
[22:59:37 CEST] <Angus> so calling the VDPAU function should go: avformat_open_input->avformat_find_stream_info->avcodec_find_decoder->setup Codec->avcodec_open2->vdpau_init->av_hwframe_transfer_data?
[23:00:27 CEST] <wm4> 1. you shouldn't use the AVStream.codec for decoding (copy it with avcodec_copy_context to a new AVCodecContext instead)
[23:00:46 CEST] <wm4> 2. you need to set the get_format and get_buffer and some more fields yourself, see ffmpeg_vdpau.c
[23:03:45 CEST] <jsebechlebsky> Hi, could someone confirm me, that I can replace av_copy_packet and av_dup_packet simply by av_packet_ref ? 
[23:04:54 CEST] <Angus> wm4: does this look reasonable to you?
[23:04:54 CEST] <Angus> http://pastebin.com/3apNxkhQ
[23:05:16 CEST] <Angus> (if you ignore the codec copying thing)
[23:05:47 CEST] <Angus> pCtx replaces InputStream
[23:06:09 CEST] <wm4> looks like a start, also you don't need av_dict_get
[23:06:46 CEST] <Angus> alrighty
[23:12:14 CEST] <Angus> wm4: the git vdpau_retrieve_data calls av_hwframe_transfer_data
[00:00:00 CEST] --- Sat Apr 30 2016