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

[burek]

[00:00:22 CEST] <cone-152> ffmpeg 03Paul B Mahol 07master:443c9fab57fa: avfilter/vf_gblur: add sigmaV option, different vertical filtering
[00:33:26 CEST] <friki> "-timecode hh:mm:ssSEPff" -> it's just a metdata at the start of the video or keep sending timecode every frame?
[00:50:58 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vi3L5
[00:50:58 CEST] <KGB> 13FFV1/06master 14f5e2924 15Reto Kromer: typos...
[01:24:50 CEST] <cone-152> ffmpeg 03Michael Niedermayer 07release/3.0:815a4439c384: avcodec/rawdec: Fix bits_per_coded_sample checks
[01:24:51 CEST] <cone-152> ffmpeg 03Michael Niedermayer 07release/3.0:ca92adafb0ef: avformat/swfdec: Fix inflate() error code check
[01:24:52 CEST] <cone-152> ffmpeg 03Michael Niedermayer 07release/3.0:93534cd642dd: avcodec/indeo2: check ctab
[01:24:53 CEST] <cone-152> ffmpeg 03Michael Niedermayer 07release/3.0:d794d97d9603: avcodec/cfhd: Increase minimum band dimension to 3
[01:24:54 CEST] <cone-152> ffmpeg 03Michael Niedermayer 07release/3.0:4ab41164d238: avcodec/diracdec: Check numx/y
[01:24:55 CEST] <cone-152> ffmpeg 03Michael Niedermayer 07release/3.0:fe7366ee93c8: libavcodec/wmalosslessdec: Check the remaining bits
[01:24:56 CEST] <cone-152> ffmpeg 03Michael Niedermayer 07release/3.0:2858f77fd460: avformat/wtvdec: Check pointer before use
[01:24:57 CEST] <cone-152> ffmpeg 03Michael Niedermayer 07release/3.0:cd91aaa4cc59: avcodec/aacenc: Tighter input checks
[01:24:58 CEST] <cone-152> ffmpeg 03Michael Niedermayer 07release/3.0:1b47c278a606: avformat/utils: End probing if the expected codec surpasses AVPROBE_SCORE_STREAM_RETRY
[01:24:59 CEST] <cone-152> ffmpeg 03Michael Niedermayer 07release/3.0:1d90326f95a7: avformat/avidec: Fix infinite loop in avi_read_nikon()
[01:40:41 CEST] <AnonBaiter> that's... a lot of fixes
[02:18:07 CEST] <philipl> BtbN: reviews sent
[02:18:19 CEST] <philipl> sorry, repeat.
[02:19:37 CEST] <philipl> BtbN: So, if I'm trying to do CUDA->GL interop in mpv, where the GL renderer deals with each plane in a separate texture, it seems like I need to register each GL texture separately and then do two cuda copies, one for each plane from the contiguous buffer that cuvid gives us.
[02:19:49 CEST] <philipl> Does that sound right? The documentation here is severely inadequate.
[02:20:50 CEST] <philipl> The cheap way out is to do post-processing in cuda (like the vdpau mixer) and display the argb result as a single texture.
[03:06:15 CEST] <cone-152> ffmpeg 03Michael Niedermayer 07release/3.0:3512ed3622e1: Changelog: update
[03:17:22 CEST] <Chloe> AnonBaiter: just backports
[03:22:28 CEST] <AnonBaiter> oh
[03:40:45 CEST] <jamrial_> http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Netflix-Finds-x265-20-More-Efficient-than-VP9-113346.aspx
[03:46:18 CEST] <cone-152> ffmpeg 03Paul B Mahol 07n3.0.3:HEAD: avfilter/vf_gblur: add sigmaV option, different vertical filtering
[03:46:21 CEST] <Chloe> jamrial_: how was vdd?
[03:47:10 CEST] <jamrial_> Chloe: i didn't attend
[03:47:44 CEST] <Chloe> err, sorry, I was thinking of kierank.
[03:48:20 CEST] <Chloe> jamrial_: also, apparently there was something on that netflix post at vdd, so I thought you may have gone. :)
[09:23:27 CEST] <cone-809> ffmpeg 03Franklin Phillips 07master:cefce6e2c1e3: avformat/hlsenc: fix incomplete write of subtitle HLS playlist
[09:23:27 CEST] <cone-809> ffmpeg 03Michael Niedermayer 07master:880d8e88ee74: MAINTAINERS: Replace AvxSynth Team by Stephen Hutchinson for avisynth.c
[10:11:38 CEST] <cone-809> ffmpeg 03Paul B Mahol 07master:e7bc9623e577: avcodec/pnmdec: fix undefined behaviour
[10:16:32 CEST] <cone-809> ffmpeg 03Carl Eugen Hoyos 07master:f077ad69c682: lavc/avpacket: Fix undefined behaviour, do not pass a null pointer to memcpy().
[10:46:14 CEST] <ubitux> meh, no AVClass in AVStream :((
[10:46:41 CEST] <nevcairiel> why would it need one, there is no "private" implementation behind it
[10:49:05 CEST] <ubitux> i'm having issues with the discard flag
[10:49:29 CEST] <ubitux> apparently we have a way to tell demuxer to not even output certain packets
[10:49:36 CEST] <ubitux> (AVStream.discard)
[10:50:31 CEST] <ubitux> currently ffmpeg_opt map a user string option (discard) to the the AVDiscard enum value
[10:50:57 CEST] <ubitux> ...using AVOption mechanism present in lavc
[10:51:11 CEST] <ubitux> to do that, it uses AVStream.codec
[10:51:20 CEST] <ubitux> and the av_opt api
[10:51:36 CEST] <ubitux> AVStream.codec is going away, and i need a solution to that
[10:51:52 CEST] <ubitux> if AVStream had an AVClass i could use the av_opt api directly on it
[10:52:22 CEST] <nevcairiel> why would it uses the codec thing to match avstream things
[10:52:38 CEST] <ubitux> because it needs to do string ’ AVDiscard enum mapping
[10:53:16 CEST] <ubitux> (cli options are not AVOption)
[10:53:41 CEST] <ubitux> AVStream.discard is an AVDiscard
[10:53:50 CEST] <ubitux> user discard is a string
[10:56:48 CEST] <nevcairiel> you could define an avclass thats not part of the struct, just for option matching
[10:58:37 CEST] <ubitux> mmh avcodec_get_class() maybe?
[10:59:01 CEST] <nevcairiel> why not define one for avstream instead of using something unrelated
[10:59:35 CEST] <ubitux> i'll have to duplicate the entries
[10:59:41 CEST] <ubitux> not sure i want to do that
[11:06:30 CEST] <ubitux> mmh it works, nice.
[11:20:30 CEST] <ubitux> i don't want to port ffserver stuff in ffmpeg*.c
[11:20:35 CEST] <ubitux> (to codecpar)
[11:21:12 CEST] <nevcairiel> do what we did and put it under deprecation marks, and if noone comes up with a replacement in the two years its just dead
[11:22:30 CEST] <ubitux> "what we did"  what are you refering to?
[11:22:45 CEST] <ubitux> i see no existing deprecation guard
[11:22:47 CEST] <nevcairiel> there is plenty ffserver related stuff in avcodec
[11:22:50 CEST] <hapie> Hello everyone, Recently I migrated my code to latest ffmpeg 3.1.3 and facing somme issues with av_read_frame constantly returning error -104 for some audio streams. Do you guys know what's going on here?
[11:22:53 CEST] <nevcairiel> which was impossible to port to codecpar
[11:22:59 CEST] <nevcairiel> so it uses deprecated api
[11:23:15 CEST] <hapie> Other streams are working just fine. I think -104 is ECONNRESET error
[11:24:05 CEST] <hapie> @nevcairiel Any idea on av_read_frame -104 ECONNRESET error?
[11:25:34 CEST] <hapie> @ubitux any idea?
[11:56:31 CEST] <ubitux> hapie: no
[11:56:50 CEST] <hapie> oh ok :(
[11:57:04 CEST] <hapie> I am using ffserver to stream mp3 files
[11:57:16 CEST] <ubitux> alright now, what are we going to do about all the codec->{time_base,ticks_per_frame,r_frame_rate} madness in ffmpeg.c?
[11:57:27 CEST] <ubitux> (transcode_init())
[11:57:45 CEST] <ubitux> michaelni: any idea how we're going to move this to codecpar?
[11:58:36 CEST] <ubitux> we're in a stream copy case, so it's using ost->st->codec
[12:00:14 CEST] <ubitux> hapie: ffserver is going away, if you want to maintain you'd better send patches asap
[12:01:51 CEST] <hapie> @ubitux It's working for me on ubuntu server. Problem is in latest ffmpeg 3.1.3 which is getting ECONNRESET "connection reset by peer" as return value of av_read_frame
[12:02:32 CEST] <hapie> I am new to ffmpeg, not sure that I can write patches for ffserver with my current knowledge :(
[12:02:50 CEST] <ubitux> then you're on the wrong channel, support is at #ffmpeg
[12:03:09 CEST] <ubitux> if you're not planning to maintain it, you'd better not use it as it's going to disappear soon
[12:03:24 CEST] <hapie> oh ok :)
[12:10:00 CEST] <hapie> @ubitux can you tell me if http protocole is not https we shift to tls ?   reference http.c
[12:10:31 CEST] <michaelni> ubitux, i dont know. Iam not interrested in codecpar. I tried fixing issues but people rejected the patches, I asked for alternative solutions but people didnt care, so its the people that will fix it or it just wont work
[12:11:14 CEST] <ubitux> great, so stallmate, no more merge, and we keep thousands of deprecated warnings all over
[12:11:18 CEST] <ubitux> :(
[12:13:10 CEST] <michaelni> its no stallmate
[12:13:46 CEST] <michaelni> if someone wants codecpar, he can do the work, if noone wants to do it we maybe should conside to more a different direction
[12:14:32 CEST] <wm4> how about you make ffmpeg.c less mad instead
[12:14:50 CEST] <BtbN> So it was merged from libav, but nobody actually wanted it?
[12:15:27 CEST] <ubitux> wm4: it means finding a solution to problems we fixed and libav ignored
[12:15:43 CEST] <wm4> which problems?
[12:16:05 CEST] <ubitux> stuff in avi/mov stream copy at least apparently
[12:16:24 CEST] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg.c;h=d8584070a9f313bd9d890361dc62f1407d171357;hb=HEAD#l2912
[12:16:29 CEST] <ubitux> all of this basically
[12:16:36 CEST] <ubitux> which i have no idea how to move to codecpar
[12:16:56 CEST] <ubitux> it's using fields not found in codecpar
[12:17:08 CEST] <wm4> lol wild format-specific hacks
[12:17:24 CEST] <ubitux> simplest is probably to add time_base and ticks_per_frame to codecpar
[12:18:15 CEST] <ubitux> but i'm not really in the mood to look for architecture redesign on issues i don't really understand
[12:18:17 CEST] <durandal_1707> check if those hacks are still relevant
[12:18:33 CEST] <ubitux> yes they are, this stuff is regularly maintained
[12:18:35 CEST] <michaelni> iam in favor of moving needed fields to codecpar but iam not sure others agree
[12:20:14 CEST] <ubitux> do we have a better place or alternatives? why do we need timing information at codec level?
[12:20:29 CEST] <ubitux> how reliable is it and how better could it be?
[12:20:44 CEST] <ubitux> could we have it handled at lavf format instead?
[12:22:28 CEST] <ubitux> anyway, it's one of the last thing i have to change to move ffmpeg to codecpar and move on with the merges
[12:24:14 CEST] <wm4> I'd question why the API user has to care about this stuff at all
[12:24:44 CEST] <ubitux> the api users are not the only users
[12:25:51 CEST] <ubitux> anyway, as a video player you obviously don't care about this, but stream copy is an issue we want to solve at least in the cli (and maybe some api users would care if they did that)
[12:49:22 CEST] <wm4> doesn't matter that I maintain a video player
[12:49:47 CEST] <wm4> if I want to implement some sort of encoder, I do not want to have to copy ridiculous hacks from ffmpeg.c just to make it work
[12:49:57 CEST] <wm4> that's just my perspective of an API user
[12:50:29 CEST] <BtbN> Having format specific hacks in ffmpeg.c and not in the format/codec itself is indeed strange
[13:01:32 CEST] <michaelni> ubitux, would it work to move the code from ffmpeg into libavformat ? (would avoid needing this for API users and it might have access to internal fields still) but i didnt RTFS atm
[13:03:44 CEST] <BtbN> So codedpar does not have time_base? That seems kind of strange.
[13:04:29 CEST] <nevcairiel> it has framerate, which time_base was really abused for most of the time
[13:04:45 CEST] <nevcairiel> a codec-level timebase is often just a very confusing concept
[13:05:13 CEST] <BtbN> so as that code is reading from framerate fields, isn't that what it's supposed to set instead?
[13:06:39 CEST] <ubitux> note that there is also r_frame_rate
[13:07:30 CEST] <ubitux> michaelni: well, lavf can't access st->codec either so..
[13:07:50 CEST] <ubitux> i mean, st->codec is going away
[13:08:20 CEST] <ubitux> there is ofc the issue that it's being accessed from ffmpeg.c
[13:08:28 CEST] <ubitux> but the main problem is that it's using st->codec
[13:08:42 CEST] <ubitux> and not stream properties or codec parameters
[13:16:09 CEST] <JEEB> hmm, would it make any sense to start supporting the udp://SOURCE@MULTICAST:PORT source specific multicast syntax in the udp input module? of course it would support only a single source unlike the ?source=VAL,VAL one which lets you set multiple sources
[13:42:01 CEST] <BtbN> they all look the same to me oO
[13:42:46 CEST] <BtbN> except for the first one(super).
[14:27:32 CEST] <DHE> JEEB: '@' already has a specific purpose for http-type URLs, so wouldn't that be confusing?
[14:40:13 CEST] <JEEB> ok
[14:40:17 CEST] <JEEB> won't do that then
[14:45:40 CEST] <Chloe> In a device, how would I 'nop' AVPackets so that nothing gets encoded to the output, but the output doesnt just freeze
[15:04:27 CEST] <ubitux> if there are no suggestion wrt {time_base,ticks_per_frame,r_frame_rate} i'll just add them to codecpar and be done with it
[15:06:41 CEST] <ubitux> btw, looking at the avi code for now
[15:06:48 CEST] <ubitux> we are in a stream copy case
[15:07:14 CEST] <ubitux> which means the only thing that could use it would be the avi muxer; but nothing in the lavf/avienc seems to work on st->codec
[15:07:21 CEST] <ubitux> as it's been ported to codecpar
[15:08:12 CEST] <ubitux> and the part of lavf/movenc using it are under deprecation flag
[15:08:22 CEST] <ubitux> so i guess i could just drop that?
[15:23:47 CEST] <ubitux> i conform that FATE passes without the avi check, so i guess i could drop that one for a start
[15:23:53 CEST] <ubitux> michaelni: any objection?
[15:46:46 CEST] <nevcairiel> i just dont see how those are really needed on a codec level
[15:48:51 CEST] <nevcairiel> if its stuff provided by avi demux or needed by avi mux, why arent they format/stream level things?
[15:51:37 CEST] <nevcairiel> extending a clean struct like codecpar wth format-specific hacks is just not a good thought, imho
[16:05:25 CEST] <ubitux> they pass fate if i drop them
[16:10:58 CEST] <wm4> what is this ffprobe demuxer shit
[16:11:03 CEST] <wm4> what are you doing
[16:13:13 CEST] <kierank> wm4: wb
[16:14:17 CEST] <durandal_1707> wb?
[16:17:16 CEST] <wm4> not sure if "back", what I pick up from here is the same frustrating crap as always
[16:25:50 CEST] <Chloe> durandal_1707; wb -> welcome back
[16:30:09 CEST] <Chloe> Anyone see my question?
[16:32:19 CEST] <ubitux> consume the packet but don't do anything with it?
[16:32:52 CEST] <ubitux> (maybe by returning pkt.size? i don't remember)
[16:33:44 CEST] <wm4> Chloe: I don't understand the question
[16:47:34 CEST] <Chloe> ubitux: that's what I was thinking but for some reason it doesn't work, it's probably not related to the AVPacket actually
[17:25:58 CEST] <philipl> The cheap way out is to do post-processing in cuda (like the vdpau mixer) and display the argb result as a single texture.
[17:26:07 CEST] <philipl> bah. ignore.
[20:03:06 CEST] <michaelni> ubitux, patches for fate tests sent, should i push them ?
[20:28:24 CEST] <roxlu> Can I ask libswresample related questions here? 
[20:28:36 CEST] <roxlu> oh ... nvm :) 
[22:34:45 CEST] <bearded_gentleme> Hello dev over lords!
[23:05:32 CEST] <durandal_1707> ubitux: comments for palette?
[00:00:00 CEST] --- Tue Sep  6 2016