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

[burek]

[00:00:02 CEST] <cone-555> ffmpeg 03Paul B Mahol 07master:6d7c63588c81: avfilter/vf_overlay: add x86 SIMD
[00:14:15 CEST] <cone-555> ffmpeg 03Paul B Mahol 07master:ab1114a0f5b3: avfilter/vf_convolution: rewrite so it doesn't use temp buffers
[03:07:35 CEST] <kierank> ma
[03:07:40 CEST] <kierank> bleh
[03:11:35 CEST] <BBB> kierank: thank you for that link
[03:11:41 CEST] <BBB> I can now live a happy, worry-free life
[03:11:46 CEST] <kierank> BBB: ?
[03:12:02 CEST] <kierank> the one with all the random guessing?
[03:12:04 CEST] <BBB> I know that no matter what I do, all code I write in my life will not be the worst ever written
[03:12:19 CEST] <BBB> even if I were a blind monkey typing drunk, it would be better than that
[03:13:00 CEST] <kierank> trying to do anything with the mpeg4/h263 codebase is very difficult
[03:25:04 CEST] <kierank> BBB: https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/h263dec.c;h=eae29fa438e3b6b5adadbbe5d94363e2303ef7ee;hb=HEAD#l166
[03:25:06 CEST] <kierank> also that
[03:27:26 CEST] <jamrial> it may be ugly, but it's probably parf of what made ffmpeg support all kinds of fucked up divx/xvid video back when those were everywhere
[03:28:00 CEST] <kierank> sure, but could be documented
[03:28:08 CEST] <kierank> e.g what file does it fix and why
[03:31:58 CEST] <Compn> well it helps that divx was a hacked msmpeg4 asf codec
[03:32:08 CEST] <Compn> and then b-frames were never meant to be put in .avi
[03:32:32 CEST] <Compn> and then everyone including skal made his/her own mpeg4 codec :P
[03:33:06 CEST] <Compn> so of course we supported playing back all of those codecs
[03:52:20 CEST] <rcombs> xvid claims a patent on the packed b-frame technique
[03:52:38 CEST] <rcombs> which is dumb because it has little technical value
[03:52:48 CEST] <rcombs> if I'd invented that I sure wouldn't be publicly claiming credit for it
[04:12:05 CEST] <BBB> oops ;)?
[04:34:51 CEST] <Compn> i saw the oops :D
[08:06:07 CEST] <cone-271> ffmpeg 03Rodger Combs 07master:6f119dc32176: lavf/dashenc: don't call flush_init_segment before avformat_write_header
[08:06:07 CEST] <cone-271> ffmpeg 03Jan Ekström 07master:48684d26057a: lavf/dashenc: require experimental mode to be enabled for WebM
[08:06:07 CEST] <cone-271> ffmpeg 03Jan Ekström 07master:bad42e9b4092: lavf/dashenc: pass standards compliance value to the internal context
[09:26:04 CEST] <cone-271> ffmpeg 03Paul B Mahol 07master:0f0d468fbcf1: avfilter/vf_overlay: exclude nv12/nv21 formats from x86 asm check
[10:06:42 CEST] <vishnu_nk> Hi Can anyone tell me of there is a way to change the program id of a TS file using ffmpeg?
[10:13:42 CEST] <funman> 
[11:00:48 CEST] <BtbN> hm, nvidia sending in an entire a53 parser for cuviddec. That stuff is one of the primary reasons the nvdec hwaccel exists
[11:06:21 CEST] <JEEB> lol
[11:06:34 CEST] <JEEB> yea, that sounds like awful duplication of functionality
[11:22:38 CEST] <durandal_1707> wm4: i gonna push improved y4m patch, if you do not mind
[11:24:18 CEST] <JEEB> oh hey, we got a person who had actually utilized WebM with dashenc
[11:24:25 CEST] <JEEB> so it might have not been crashing in 3.4
[11:24:39 CEST] <JEEB> I'm asking him if it gives him usable files with current master
[11:24:51 CEST] <JEEB> if it does, then 48684d26057a can be reverted
[11:34:06 CEST] <cone-271> ffmpeg 03Paul B Mahol 07master:3a96534ed9dd: avfilter/vf_convolution: add horizontal/row mode
[11:34:07 CEST] <cone-271> ffmpeg 03Paul B Mahol 07master:c8c2fb097777: avfilter/vf_convolution: unbreak roberts filter
[12:58:52 CEST] <cone-271> ffmpeg 03Paul B Mahol 07master:943f7902e6f7: avfilter/vf_neighbor: add >8 depth suppport
[13:58:50 CEST] <moreentropy> hi.
[13:59:15 CEST] <JEEB> ohai
[13:59:24 CEST] <moreentropy> about the DASH bug: I just compiled & deployed ffmpeg master, at least my DASH/WebM/OPUS audio-only streams are working again
[13:59:58 CEST] <moreentropy> Player: https://www.eldoradio.de/broadcast/player/
[14:00:01 CEST] <moreentropy> Manifest: http://sender.eldoradio.de/chunks/dash/eldoradio.mpd
[14:01:26 CEST] <JEEB> if you get time, please test with some sort of small video stream with vp9/8 (vp9 was forcibly made non-webm by the akamai person some time ago because webm mode crashed)
[14:01:42 CEST] <JEEB> like, you can just make a small video source based on the audio
[14:01:49 CEST] <JEEB> durandal_1707 knows all about those filters
[14:02:15 CEST] <JEEB> (also site:ffmpeg ffmpeg-all.html)
[14:02:19 CEST] <JEEB> *site:ffmpeg.org
[14:02:31 CEST] <moreentropy> ok, I can try that later today, that streaming server is not my day job ;)
[14:02:50 CEST] <JEEB> that's OK, I have my $dayjob as well
[14:05:47 CEST] <durandal_1707> there is no way to debug why vs plugin does not load?
[14:28:50 CEST] <Compn> haha
[14:28:54 CEST] <Compn> -c copy is the best :D
[14:32:56 CEST] <cone-271> ffmpeg 03Paul B Mahol 07master:5abcf45d752d: avformat/yuv4mpegdec: simplify math
[14:45:33 CEST] <durandal_1707> ubitux: the edgedetect filter, even links canny, but it is more toy filter
[14:45:51 CEST] <durandal_1707> it supports only gray for some reason, the other mode is just toy
[14:46:36 CEST] <ubitux> yeah well, edge detect concept in itself isn't really useful
[14:46:45 CEST] <ubitux> as a building block for other filters it might make sense though
[14:53:11 CEST] <durandal_1707> ubitux: yes, but edgedetect filter is really toy, you can not build useful mask with default mode
[14:53:21 CEST] <ubitux> maybe
[14:53:23 CEST] <ubitux> what's your point?
[14:53:38 CEST] <durandal_1707> it should operate on all planes for start
[14:53:43 CEST] <durandal_1707> not just gray
[15:06:50 CEST] <durandal_1707> ubitux: i already wrote one patch for this
[15:07:06 CEST] <ubitux> i don't plan to work on edgedetect so yeah, sure, feel free to contrib
[15:07:29 CEST] <durandal_1707> also add planes option and more pixel format support
[17:35:00 CEST] <wm4> BtbN: maybe we should just remove the old cuda decoder wrapper
[17:35:43 CEST] <cone-271> ffmpeg 03Michael Niedermayer 07master:e03bf251d878: avcodec/mpeg4videodec: Move decode_studiovisualobject() parsing in the branch for visual object parsing
[17:35:44 CEST] <cone-271> ffmpeg 03Michael Niedermayer 07master:177133a0f4b4: avcodec/mpeg4videodec: Split decode_studio_vol_header() out of decode_studiovisualobject()
[18:12:57 CEST] <BtbN> wm4, it still has features that would be lacking if it's missing
[18:13:09 CEST] <wm4> too bad for nvidia?
[18:13:11 CEST] <BtbN> and it's also still faster than the nvdec one for decoding to software frames
[18:13:14 CEST] <BtbN> by quite a bit
[18:13:25 CEST] <wm4> at least they'll have an incentive to add support
[18:13:35 CEST] <wm4> instead of using our project as code dump (and we maintain it then)
[18:13:41 CEST] <BtbN> it's primarily deinterlacing
[18:14:04 CEST] <BtbN> And the nvdec one needs some work to get rid of the useless extra copy it does when doing swdecode
[18:45:31 CEST] <BtbN> Can there be more than one AV_FRAME_DATA_A53_CC?
[18:45:58 CEST] <JEEB> I think someone made a commit that enabled that
[18:46:13 CEST] <JEEB> with a function that gets the next side data of a specific type
[18:47:25 CEST] <BtbN> Cause right now, the nvidia patch iterates over all side data, and uses the last one it finds
[18:47:36 CEST] <BtbN> and I'm tempted to just add a break; so it uses the first, and probably only one
[18:48:28 CEST] <BtbN> also, I wonder why they iterate over it manually. Isn't that what av_frame_get_side_data is for?
[18:48:48 CEST] <BtbN> yes, it very much is.
[18:51:02 CEST] <atomnuker> I think there's only one of a side data type allowed per frame
[18:53:38 CEST] <JEEB> yes, currently I think explicitly or implicitly we limit it to one
[18:54:07 CEST] <JEEB> and I seem to have lost the github URL to the fork that did the multiple thing
[18:54:32 CEST] <BtbN> https://bpaste.net/show/e6e4b1df6e8e this should be reasonable though? Or am I missing something?
[18:59:49 CEST] <atomnuker> yeah, looks fine
[19:35:25 CEST] <kurosu> ubitux, (slowpoke) your simd stuff looks like lossless video left prediction, which is on 8b; still worth looking at?
[19:38:52 CEST] <ubitux> kurosu: are you refering to my f(ABCD,BCDE)={A+B A+B+C A+B+C+D A+B+C+D+E} question?
[19:49:25 CEST] <jamrial> [15:30:11 CEST] <BBB> I believe jamrial wrote the vp9 bsf
[19:49:33 CEST] <jamrial> no, i didn't. elenril did
[19:50:13 CEST] <jamrial> wm4 then enabled it for the decoder, in place of the parser
[19:50:19 CEST] <jamrial> but in any case, the issue (if any) seems to be in either decode.c or pthread_frame.c
[19:50:40 CEST] <wm4> uh we just did what Libav did
[19:50:50 CEST] <wm4> (when they fixed the issue we fixed years ago in a different way)
[19:50:55 CEST] <jamrial> the vp9 superframe split bsf is the only one that outputs more than one packet per input packet
[19:51:26 CEST] <jamrial> something in the generic code doesn't play nice with that
[19:51:27 CEST] <wm4> anyway I suspect there's something fishy going on but I haven't taken a close lok
[19:51:30 CEST] <wm4> *look
[19:51:57 CEST] <jamrial> every other decoder uses the null bsf (basically, nothing) and that's one packet in, one packet out
[19:54:58 CEST] <wm4> sure
[19:56:32 CEST] <atomnuker> wm4: you wanted to deprecate parsers in favor of bsfs, right?
[19:56:47 CEST] <wm4> maybe
[19:57:00 CEST] <wm4> the BSF API would have to get extended a bit
[19:57:17 CEST] <wm4> but in theory it's what we want: N packets in, M packets out
[20:03:02 CEST] <BBB> why?
[20:03:14 CEST] <BBB> whats the advantage (in a push mechanism) between 1:M and N:M?
[20:03:31 CEST] <JEEB> -34
[20:04:03 CEST] <wm4> BBB: parsers often reassemble packets, so we definitely need it for data flow
[20:04:11 CEST] <wm4> some input packets are just random byte ranges
[20:04:45 CEST] <BBB> and a bytes_consumed + sub-packeting mechanism isnt sufficient for that?
[20:04:47 CEST] <wm4> parsers are for retrieving codec information, but also for assembling proper packets in some cases
[20:04:51 CEST] <jamrial> then make parsers stop splitting packets, and leave that task fr bsfs
[20:04:59 CEST] <wm4> BBB: that'd also be possible
[20:05:12 CEST] <wm4> BBB: then the input would be an AVBufferRef
[20:05:17 CEST] <BBB> yes
[20:05:20 CEST] <wm4> but then some parsers need input timestamps
[20:05:31 CEST] <wm4> (the parser API passes them separately)
[20:05:36 CEST] <wm4> so why not just use AVPacket
[20:06:05 CEST] <wm4> also other metadata like side data, packet duration, or packet positions
[20:06:19 CEST] <wm4> many parsers just pass through packets while "analyzing" them in the first place
[20:10:37 CEST] <durandal_1707> ubitux: i sent patch for lut3d too
[20:15:06 CEST] <wm4> gawd pages of code that are a single macro
[20:35:20 CEST] <durandal_1707> wm4: you use 80x25 ?
[20:56:02 CEST] <durandal_1707> becuase there is barely half page of macros
[21:58:57 CEST] <cone-506> ffmpeg 03Paul B Mahol 07master:f43fd68f2807: avfilter/drawutils: add support for full range
[00:00:00 CEST] --- Fri May  4 2018