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

[burek]

[00:52:07 CET] <kierank> any idea how to reset the dc predictor in mpeg4video dec?
[00:56:55 CET] <kierank> mpegvideoenc is insane
[01:24:19 CET] <kierank> michaelni: ping
[01:26:49 CET] <kierank> what does int (*decode_mb)(struct MpegEncContext *s, int16_t block[6][64]); // used by some codecs to avoid a switch()
[01:26:50 CET] <kierank> mean?
[01:26:52 CET] <kierank> switch what?
[01:27:11 CET] <kierank> hardcode the function in order ot avoid a switch(chroma_format)?
[01:27:13 CET] <iive> switch {case}
[01:28:19 CET] <iive> mpeg2 mpeg4asp and wmv1/2 use different decode_mb
[01:29:07 CET] <kierank> mpeg4videodec sets this but doesn't call it
[01:38:25 CET] <iive> h263dec uses it, so does error_resilence
[02:16:11 CET] <kierank> michaelni: am I right in saying the code assumes that there is one slice per row of MBs?
[02:24:41 CET] <BBB> kierank: omg poor you
[02:24:49 CET] <BBB> kierank: youre not actually working on mpegvideoenc are you?
[02:25:15 CET] <kierank> I want to fix https://trac.ffmpeg.org/ticket/4447
[02:25:36 CET] <kierank> implement mpeg-4 sstp
[02:28:43 CET] <michaelni> kierank, the mpeg4 decoder supports arbitrary slice sizes, so does mpeg1 & 2. The encoders should too but i think not as 1 thread per slice but its all long ago that i worked with the code
[02:28:56 CET] <kierank> but there's nowhere for the slice header to be decoded
[02:29:06 CET] <kierank> ret = s->decode_mb(s, s->block);
[02:29:14 CET] <kierank> if (ret == SLICE_END) {
[02:29:21 CET] <kierank> but where should one decode the slice header?
[02:29:46 CET] <kierank> and it's all hardcoded to 4:2:0
[02:30:39 CET] <michaelni> ff_mpeg4_decode_video_packet_header()
[02:31:03 CET] <michaelni> terminology is from the spec IIRC
[02:31:09 CET] <kierank> yes but studio profile adds a slice header
[02:31:15 CET] <kierank> and there's nowhere to decode it
[02:33:59 CET] <michaelni> where is that header documented ?
[02:34:38 CET] <kierank> in the latest version of the spec
[02:34:59 CET] <kierank> https://usercontent.irccloud-cdn.com/file/SEEjO79P/ISO_IEC_14496-2_2004(e).pdf
[02:35:06 CET] <kierank> I've implemented the bitstream: https://github.com/kierank/ffmpeg-sstp
[02:35:23 CET] <kierank> but I can't get the dc coeff decode and ac coeff decode to fit into all of this stuff
[02:45:28 CET] Action: michaelni see field pictures in mpeg4, not want to touch this, no no no
[02:46:27 CET] <kierank> the samples on the ticket are progressive
[02:46:50 CET] <kierank> mpeg-4 doesn't have mbaff so i think it's not too bad anyway if we get interlaced samples
[02:48:39 CET] <michaelni> mpeg4 does have something quite similar to mbaff and we support it, adding field pictrures really was dumb from the comitee IMHO
[02:49:25 CET] <kierank> it has mpeg-2 style "mbaff, no?"
[02:49:49 CET] <kierank> I have implemented all the studio header parsing
[02:50:04 CET] <michaelni> yes it probably can be called mpeg2 style
[02:51:17 CET] <kierank> StudioSlice() is my problem
[02:51:28 CET] <Compn> is there any other open source decoder that supports this ? just curious... xvid ? etc
[02:51:58 CET] <kierank> it's a layer between VOP and MB
[02:52:06 CET] <kierank> which the code doesn't have
[02:53:13 CET] Action: Compn mumbles something about putting wrapper lib in ffmpeg and then waiting for someone to pay to get it in lavc...
[03:00:46 CET] <rcombs> fuck mbaff though
[03:01:20 CET] <rcombs> (fuck field pictures more)
[03:07:45 CET] <kierank> fuck 1080p25
[03:07:52 CET] <kierank> blurry as hell
[03:22:25 CET] <Compn> fuck interlaced
[03:23:32 CET] <BBB> woohoo Im not the only one that hates interlacin
[03:24:15 CET] <Compn> i think most people here do heh
[03:27:10 CET] <kierank> I am not sure whether to merge studioslice with vop or with mb
[03:27:51 CET] <kierank> or how to get it into that
[03:32:03 CET] <kierank> I don't know where the dc predictor is reset
[03:36:43 CET] <TD-Linux> kierank, when I was in the tate modern art museum I was surprised how much 50hz crts flicker compared to 60hz
[03:46:59 CET] <kierank> hmmm maybe it's not a predictor as such
[03:47:02 CET] <kierank> just used for ER
[03:47:18 CET] <kierank> but something doesn't make sense
[04:23:41 CET] <kierank> michaelni: where is the dc predictor reset for intra blocks in a new slice?
[04:23:43 CET] <kierank> I can't find that
[04:30:17 CET] <michaelni> i hope iam not telling you something wrong, its a while ago, but i think it isnt reset, ff_mpeg4_pred_dc() instead checks for slice borders
[04:33:24 CET] <kierank> but how does it know where the slices end
[04:33:44 CET] <kierank> pretty sure it has to make shape assumptions
[04:33:59 CET] <kierank> or maybe mpeg-4 asp has some stuff to aid
[04:34:38 CET] <kierank> this resync_mb_x stuff isn't in sstp
[04:41:34 CET] <rcombs> http://inta.re
[04:46:27 CET] <kierank> michaelni: and do you know how the hardcoded number of 1024 is derived
[04:46:40 CET] <kierank> I will need to get rid of dozens of hardcoded values
[04:48:23 CET] <kierank> 2 ^ (bits_per_pixel+dct_precision+intra_dc_precision-1)
[04:48:45 CET] <kierank> but you set it to 1024
[04:48:49 CET] <kierank> so I'm missing 3
[04:48:51 CET] <kierank> in the exponent
[04:53:33 CET] <kierank> ah it's different
[04:53:34 CET] <kierank> never mrind
[04:54:55 CET] <michaelni> 1024 probably is the dc value after dequat
[04:55:32 CET] <michaelni> i need to go afk now (for sleeping :)
[04:55:35 CET] <kierank> same
[04:55:43 CET] <kierank> night, will ask more q's tomorrow
[04:55:53 CET] <michaelni> night 
[11:02:52 CET] <wm4> can somebody point out where av_vdpau_bind_context is defined if ffmpeg is compiled without vdpau?
[11:07:29 CET] <fritsch> wm4: https://lists.freedesktop.org/archives/mesa-dev/2016-December/138472.html
[11:07:37 CET] <fritsch> trivial - the rest continues to work as is
[11:08:01 CET] <wm4> fritsch: saw that (I'm CCed on that email thread)
[11:08:06 CET] <wm4> is that really all that's needed?
[11:08:29 CET] <wm4> also, disabling vdpau in ffmpeg gets me "undefined reference to `av_vdpau_bind_context'"
[11:08:29 CET] <fritsch> VAAPI changes: https://github.com/fritsch/kodi-agile/commit/ee41bc539fa4dd1f69ddc1f5ca98d26371b483cc
[11:08:49 CET] <fritsch> wm4: yes, that's all - you need to patch the kernel for the defines
[11:09:17 CET] <fritsch> those color formats are (in retrospective) very easy to implement, cause you just need to define the "structure" the memory shall have
[11:09:23 CET] <fritsch> and this memory sharing is generic
[11:09:53 CET] <fritsch> +   { __DRI_IMAGE_FOURCC_R16, __DRI_IMAGE_COMPONENTS_R, 1,
[11:09:53 CET] <fritsch> +     { { 0, 0, 0, __DRI_IMAGE_FORMAT_R16, 1 }, } },
[11:10:00 CET] <fritsch> these things here are the important part
[11:10:17 CET] <fritsch> and that's it no memory handling, nothing
[11:12:52 CET] <wm4> Libav have 10 bit handling in the generic vaapi context creation code too (unmerged in ffmpeg)
[11:24:10 CET] <fritsch> wm4: what does that mean? As we don't seem to miss somehting :-)
[11:27:05 CET] <wm4> jkqxz: what part of the "old" vaapi API has been deprecated?
[16:34:24 CET] <cone-975> ffmpeg 03Paul B Mahol 07master:334fad364530: avfilter/vf_ssim: add >8 bit depth suppport
[16:36:25 CET] <jkqxz> wm4:  struct vaapi_context is removed completely (excepting backward compatibility during the deprecation period).  lavc then does everything which the user used to have to provide through it.
[16:37:21 CET] <wm4> jkqxz: so it's not possible to provide the vaapi context yourself anymore?
[16:38:14 CET] <jkqxz> So the user just provides the output frames in an AVHWFramesContext: lavc picks the device out of it, creates its own VAAPI stuff on that device and decodes into those frames.
[16:38:57 CET] <jkqxz> It's there for backward compatibility now, but will be removed later.
[16:39:08 CET] <wm4> ok that breaks API users like mpv and kodi once the deprecation is finished, CC fritsch 
[16:39:52 CET] <jkqxz> Yes, but there's plenty of time to do it.
[16:40:11 CET] <wm4> for now I can't even start working on it, lol
[16:40:41 CET] <jkqxz> I was intending to send patches to fix at least mpv and vlc once it's merged in ffmpeg.
[16:41:21 CET] <jkqxz> (I've half done the merge, maybe I should finish it soon so that we don't get too far out of sync.)
[16:41:34 CET] <wm4> I can do mpv (I plan to put an entire new source file in place)
[16:42:01 CET] <wm4> since the old API use will annoyingly have to be in place for a few years
[16:42:54 CET] <jkqxz> Don't you mandate pretty-much-current lavc (whichever one) on your master branch?
[16:43:31 CET] <wm4> no
[16:43:42 CET] <wm4> until recently it was compatible back to ffmpeg 1.6 or so
[16:43:43 CET] <wm4> *2.6
[16:43:48 CET] <wm4> (1.6 would be too crazy)
[16:44:04 CET] <jkqxz> Oh.  That sounds like an immense bundle of fun.
[16:45:26 CET] <wm4> recently I bumped to latest ffmpeg/libav releases, the commit removing the compat stuff did: 22 files changed, 10 insertions(+), 278 deletions(-)
[16:46:58 CET] <JEEB> right, forgot they finally made the libav 12 release
[17:33:48 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/pull/242/files uhm...
[17:34:08 CET] <BtbN> Failed at reading that very text
[17:39:19 CET] <J_Darnley> Probably some stupid bot making idiotic corrections (like wikipedia)
[17:39:41 CET] <kierank> nice torrll
[17:40:09 CET] <wm4> kierank: Hanlon's razor
[17:41:52 CET] <fritsch> i think the patch is wrong
[17:41:54 CET] <fritsch> :-)
[17:42:05 CET] <fritsch> but at least the title says it correctly
[18:45:53 CET] <cone-975> ffmpeg 03Zhou Xiaoyong 07master:5b74ebe93723: avcodec/mips: version 1 of vc1dsp optimizations for loongson mmi
[18:45:54 CET] <cone-975> ffmpeg 03Pavel Koshevoy 07master:6b517a194da4: lavc: Fix ticket 6024, truncated mode decoding
[19:50:25 CET] <Compn> anyone want a 4k prores 422 sample? its only 16gb...
[19:50:41 CET] <Compn> 4096x3072
[20:19:04 CET] <cone-975> ffmpeg 03Jay Ridgeway 07master:295601bba302: avformat/tls: add tls url_get_file_handle
[20:27:13 CET] <durandal_1707> Compn: what's in it?
[21:18:18 CET] <Compn> durandal_1707 : captain ron 35mm trailer (4k scan)
[21:21:59 CET] <durandal_1707> Compn: is it special somehow?
[21:28:37 CET] <Compn> durandal_1707 : its got kurt russel in it, otherwise its a fun film. but no, not special
[21:30:23 CET] <Compn> i dont really feel like downloading and uploading it anyway
[21:30:25 CET] <Compn> so nevermind :D
[21:55:42 CET] <durandal_1707> Compn: find pixlet samples, not from xiph?
[21:56:05 CET] <durandal_1707> I already havery one from xiph it's 3.6gb
[21:56:53 CET] <atomnuker> Compn: sure, I'll have it, got any way to send it?
[22:30:17 CET] <TD-Linux> we have pixlet samples?
[22:30:51 CET] <TD-Linux> oh you were referring to meridian
[23:48:42 CET] <Compn> those mac video people are stingy with samples
[23:48:52 CET] <Compn> but if you need them write up a ffmpeg.org entry requesting them
[23:49:03 CET] <Compn> im sure we get a few if we post to our front page
[00:00:00 CET] --- Sun Dec 18 2016