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

[burek]

[10:21:17 CET] <cone-255> ffmpeg 03Matthieu Bouron 07master:33d69a90085d: lavc/ffjni: remove use of private JniInvocation API to retreive the Java VM
[13:25:37 CET] <cone-788> ffmpeg 03Paul B Mahol 07master:9f6e63f6f2f2: avfilter/vf_waveform: add >8 bit support for other filters
[13:25:37 CET] <cone-788> ffmpeg 03Paul B Mahol 07master:29d106e751be: avfilter/vf_waveform: remove mirroring from chroma filter
[14:14:12 CET] <JEEB> hmm, has anyone else seen movenc giving the first sample a bit over a double of duration?
[14:14:20 CET] <JEEB> in case of fragmented stuff
[14:19:37 CET] <wbs> JEEB: yes
[14:19:55 CET] <wbs> JEEB: and you should probably have a warning print in the log about it these days
[14:20:38 CET] <wbs> JEEB: tl;dr, please set AVPacket duration when muxing, if possible. otherwise the muxer will try to use some heuristics to guess it, or if it can't, it will end up zero, which will force this kind of fixup for the start of the next fragment
[14:24:08 CET] <JEEB> wbs: ID'm currently testing with ffmpeg cli, and it seems like I get this with fdk_aac and not with the aac encoder o_O
[14:24:32 CET] <JEEB> basically it was leading to a new fragment not starting with a sync sample
[14:24:48 CET] <JEEB> but it didn't happen if I had b-frames enabled
[14:24:54 CET] <JEEB> this is weird :D
[14:25:08 CET] <wbs> yes, your explanation is weird
[14:25:14 CET] <wbs> please come back when you have something I can reproduce
[14:25:36 CET] <JEEB> yeah, I was just minimizing my examples
[14:36:58 CET] <JEEB> wbs: http://up-cat.net/p/a8ba0579
[14:37:25 CET] <JEEB> so I set to have 5 second fragments and I have a static GOP length of 125 pictures in x264
[14:48:14 CET] <JEEB> feel free to hit my head if I am doing something stupid, but this seems pretty weird
[14:49:43 CET] <JEEB> (frag_keyframe enabled does the same, just for reference)
[14:54:00 CET] <wbs> JEEB: nothing wrong here, move along
[14:54:28 CET] <wbs> JEEB: the issue comes from the amount of timestamp adjusting/shifting due to b-frames and aac preroll
[14:54:51 CET] <JEEB> kind of was guessing it was something like that...
[14:55:05 CET] <wbs> say your stream starts at dts=-1, pts=0
[14:55:28 CET] <wbs> now due to avoid_negative_ts (since ismv doesn't really do edit lists), this is shifted into dts=0, pts=1
[14:55:39 CET] <wbs> or similar
[14:56:25 CET] <wbs> now if the audio preroll is much larger than one frame, it would shift all of it into e.g. dts=0, pts=2, since it all starts from dts=0 unless you have edit lists
[14:57:08 CET] <wbs> for ismv, without edit lists (and for dash) I guess your patch (a proper version of it, that is) that allows negative cts offsets and sync stuff to start with dts=pts=0, would be the simplest
[14:57:24 CET] <wbs> together with dropping enough audio before the audio encoder, to counter the added encoder delay
[14:57:54 CET] <JEEB> yeah... I tested my current patch and that was failing at something, so I moved to removing B-frames for now
[14:58:05 CET] <JEEB> and then I got this funky business :D
[15:02:07 CET] <JEEB> wbs: or you give a slightly different DTS for the audio in the "fragment's start DTS" thingy
[15:02:34 CET] <wbs> JEEB: no, that just messes things up even more
[15:03:01 CET] <wbs> JEEB: really, if you don't have edit lists, which you don't for ismv, make sure that your audio track starts at dts=pts=0
[15:03:17 CET] <JEEB> yeah
[15:04:49 CET] <omerjerk> I've another doubt regarding writing the floating point data to the output file from the decoder. 
[15:05:01 CET] <omerjerk> This is where we write it to the output - https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/alsdec.c#L1554
[15:05:27 CET] <omerjerk> wm4 said, I can write float values to *dest.
[15:06:10 CET] <wm4> of course you must fix the type and the output sample format
[15:07:20 CET] <nevcairiel> it probably sets sample_fmt somewhere
[15:07:33 CET] <nevcairiel> oh it already does
[15:07:35 CET] <omerjerk> but the data type of *dest is int
[15:07:36 CET] <omerjerk> https://ffmpeg.org/doxygen/2.7/structAVFrame.html#a1d0f65014a8d1bf78cec8cbed2304992
[15:07:37 CET] <nevcairiel> even to float
[15:07:42 CET] <omerjerk> yes it does.
[15:07:44 CET] <omerjerk> I saw that.
[15:07:56 CET] <nevcairiel> its an uint8_t*, which is our generic byte storage format
[15:08:12 CET] <omerjerk> yes. 
[15:08:18 CET] <nevcairiel> you would still just write float samples in there
[15:08:25 CET] <nevcairiel> with appropriate casts
[15:08:26 CET] <omerjerk> so how would I write float value to it ?
[15:08:49 CET] <nevcairiel> float *buffer = frame->data[0]; voila, you have a float buffer =p
[15:08:59 CET] <omerjerk> oh. 
[15:09:07 CET] <omerjerk> but how is this working ? :o
[15:09:19 CET] <nevcairiel> the interelave output macro would probably have to be re-worked to support floats
[15:09:37 CET] <omerjerk> yes. I know that.
[15:09:49 CET] <omerjerk> I'm more concerned about float *buffer = frame->data[0];
[15:09:51 CET] <nevcairiel> it could probably also be re-worked to use planar output and save a bit of re-shuffling, but thats a task for another day
[15:10:29 CET] <omerjerk> so it'll work, right ?
[15:10:37 CET] <nevcairiel> data[0] is just generic memory storage, it doesnt care what you put in there
[15:10:44 CET] <nevcairiel> what is in there is identified by the sample_fmt
[15:10:52 CET] <omerjerk> okay.
[15:10:53 CET] <wm4> well ff_get_buffer does care
[15:11:06 CET] <nevcairiel> if its AV_SAMPLE_FMT_FLT or whatever its name was, it will happily take float
[15:11:10 CET] <wm4> it allocates the required amount of memory by looking at the sample_fmt
[15:24:02 CET] <JEEB> wbs: so yeah, I guess I'm hosed for the time being until I get the negative CTS offsets properly implemented :D
[15:34:54 CET] <burnrice> hi, is there any rule, what do to when demuxing pseudo-formats that are only disguising already implemented container ?
[15:35:06 CET] <burnrice> e.g. kux (#4519), which in fact is flv, just with some offset
[15:35:19 CET] <burnrice> it could be done by creating new demuxer and redirecting data like:
[15:35:28 CET] <burnrice> int kux_read_packet(AVFormatContext *s, AVPacket *pkt) { return ff_flv_demuxer->read_packet(s, pkt);
[15:35:38 CET] <burnrice> but this is ugly, and causes problems, and probably not the way it should be done 
[15:35:52 CET] <burnrice> changing original flv file, to make it sensitive for this type of files defnitely works better, especially that in fact only two ifs are added
[15:36:38 CET] <burnrice> or maybe modify the original stream, and then somehow reinitialize whole open_input procedure (is it even possible?)
[15:41:22 CET] <JEEB> huh
[15:41:40 CET] <JEEB> -avoid_negative_ts 0
[15:42:44 CET] <JEEB> this seems to give me correct durations
[15:42:59 CET] <JEEB> need to check how badly it mutilates some other values, though
[15:50:42 CET] <jkqxz> Is that coreimage stuff actually wanting to use hwcontext?
[15:57:20 CET] <cone-788> ffmpeg 03Hendrik Leppkes 07master:a38627be6d61: avcodec/cbrt_data: include avutil/libm.h to unbreak compilation on systems without cbrt
[16:12:26 CET] <JEEB> huh, this actually seems to kind of do the thing in the perverse way of pushing down audio
[16:12:44 CET] <JEEB> so I have audio start 426667 ticks before video
[16:13:23 CET] <JEEB> need to see if this streaming server likes that
[16:34:22 CET] <cone-788> ffmpeg 03Carl Eugen Hoyos 07master:58fa69497873: lavf/http: Add httpproxy to the default protocol whitelist.
[16:38:26 CET] <cone-788> ffmpeg 03Carl Eugen Hoyos 07master:f1a3677c0f31: lavf/mxfdec: Fix Canopus essence element size.
[16:39:28 CET] <cone-788> ffmpeg 03Carl Eugen Hoyos 07release/3.0:9da31a03738f: lavf/http: Add httpproxy to the default protocol whitelist. (cherry picked from commit 58fa694978735e30f433f8ede6c7f808b9409919)
[16:46:12 CET] <JEEB> alright, this thing worked :D
[16:46:33 CET] <JEEB> wbs: so yeah, it's a mess but with -avoid_negative_ts 0 I get it working (it seems) without B-frames
[16:46:46 CET] <JEEB> which gives me time to implement the proper fix
[16:47:11 CET] <JEEB> the audio starts 0.04 s before video, which I think is the encoder delay
[16:58:56 CET] <kierank> I'm currently looking into storing WebVTT subtitles[1] in Matroska
[17:03:03 CET] <durandal_1707> why?
[17:03:38 CET] <kierank> that's a quote
[17:03:41 CET] <kierank> from the CELLAR mailing list
[17:05:04 CET] <wm4> but why
[17:05:26 CET] <wm4> google somehow managed to make the webvtt matroska mapping buttmad insane
[17:05:41 CET] <wm4> (the demuxer has to rewrite them to feed it to our "decoder")
[17:06:28 CET] <wm4> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/matroskadec.c;h=28bb77b4aeecc9a15f6f47bb2523e0a228f5b118;hb=HEAD#l2832
[17:11:28 CET] <atomnuker> why'd they choose something so limited like webvtt for archiving
[17:17:04 CET] <nevcairiel> if google already defined webvtt in webm, it would probably be insanely mad to assume  cellar would just adopt that, huh
[17:23:21 CET] <kierank> oh wow he knows how to use the bugtracker
[17:23:29 CET] <JEEB> wow
[17:26:54 CET] <durandal_1707> now your worst nightmare have just begun
[17:28:24 CET] <ubitux> maybe we could shadowban him
[17:29:42 CET] <mateo`> as long as he stops spamming the ml ...
[17:35:41 CET] <wm4> kierank: he appeared on the bug tracker first, where he insulted all ffmpeg developers
[17:35:53 CET] <wm4> only then he moved on to the ml
[17:38:50 CET] <JEEB> oh right
[19:03:47 CET] <dinux5> If anybody could tell me what should I do with the variable "coded_frame" which I found in an encoder file and has been deprecated.
[19:04:07 CET] <BtbN> remove it
[19:04:55 CET] <dinux5> But it has been used in few line of code and can not be removed straight away i think . :/
[19:05:04 CET] <dinux5> lines*
[19:05:18 CET] <nevcairiel> its usually kept for compatibility for some time
[19:05:25 CET] <nevcairiel> so just ignore it
[19:05:40 CET] <BtbN> an encoder shouldn't need it for anything, put it in deprecation-ifdefs if you want to stay compatible
[19:09:08 CET] <dinux5> Alright. Also libavcodec/mlp.h has filterParams struct which does not contain the members coeff_bits and coeff_shift which are present in bulk in the encoder.
[19:09:20 CET] <dinux5> How do I deal with those ?
[19:10:14 CET] <dinux5> What alternative to be used ?or should the functions using them be deleted right away ?
[19:10:29 CET] <nevcairiel> why do we even bother releasing release branches if the first thing every error reporter hears from carl is to get master instead? the latest release should still be considered a valid target for bug reports =p
[19:11:29 CET] <fritsch> +1 (not that I have a vote) :-)
[19:12:22 CET] <dinux5> I am actually working on my qualification task for OPW :)
[19:12:30 CET] <dinux5> need help.
[19:15:47 CET] <Compn> nevcairiel : no, releases are not valid for bugreports. in many cases bugs are fixed, especially from older releases
[19:16:12 CET] <Compn> if someone wants to change it, then we'd need more people working on trac bugs
[19:16:19 CET] <nevcairiel> Compn: thats nonsense, either we care about bugs in releases, or we shouldnt release them
[19:16:21 CET] <BtbN> well, if the release is still maintained, I'd still considder it a valid report
[19:16:41 CET] <nevcairiel> even more so if the release is what, a month old?
[19:16:43 CET] <BtbN> just not against master. Kind of like a backport-request, in the most simple cases.
[19:16:50 CET] <nevcairiel> and if its already fixed, you know what to backport
[19:16:52 CET] <Compn> yeah but lets say you backport the fix
[19:17:00 CET] <Compn> the distro would have to update the release
[19:17:13 CET] <Compn> how often does that happen ?
[19:17:19 CET] <nevcairiel> often
[19:17:21 CET] <Compn> *for non security fixes*
[19:17:21 CET] <BtbN> Don't they usualy do that?
[19:17:36 CET] <nevcairiel> there is usually security related things in there as well
[19:17:41 CET] <BtbN> I think Debian does pull in ffmpeg minor releases
[19:18:06 CET] <Compn> what about releases older than 3 months ?
[19:18:26 CET] <BtbN> If it's still maintained
[19:18:27 CET] <nevcairiel> the most recent releases from the still maintained releases branches
[19:18:57 CET] <nevcairiel> ie. 3.0 and 2.8.6, and whatever other branches are stiull up to date
[19:19:18 CET] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=MAINTAINERS;hb=HEAD#l574 it even lists which releases are maintained
[19:19:22 CET] <BtbN> aparently 3.0 is not
[19:19:24 CET] <Compn> we could ask carl to ignore reports made on release branches, if thats your complaint?
[19:20:16 CET] <BtbN> I don't see a problem with asking people to reproduce on master. But I'd still considder it valid if it works on master, but does not in some release branch.
[19:20:42 CET] <BtbN> And i think that's how it's handled already?
[19:20:51 CET] <nevcairiel> its a matter of timing as well, 3.0 is a month old, the likelyhood that something has been fixed is pretty low as it is =p
[19:21:25 CET] <Compn> i've seen and reported bugs that were fixed within a month before :P
[19:21:36 CET] <Compn> then told its unreproducable in master. updated to master... bug was fixed
[19:21:54 CET] <Compn> it does happen! :P
[19:22:26 CET] <Compn> but ok, i was just brainstorming , no problems
[19:22:45 CET] <Compn> should we update that maintained release list in maintainers file ?
[19:22:53 CET] <Compn>  'ave to ask michael :P
[19:23:00 CET] <jamrial> sure does. but it doesn't change the fact it's broken in that release and the fix should be backported, especially if the bug is a regression
[19:23:39 CET] <Compn> seems like a large maintainer burden
[19:24:11 CET] <nevcairiel> if you dont wnat to do th at, then you shouldnt even bother making releases at all
[19:24:11 CET] <Compn> merging, testing, backporting, fixing security bugs, issuing security fixes, testing again...
[19:24:18 CET] <jamrial> then saying you're "maintaining" releases would be false, if you're not fixing bugs as they are reported
[19:24:35 CET] <nevcairiel> having a branch thats essentially unmaintained but "appears" like a stable version is worse than just having master
[19:25:05 CET] <Compn> its not like we test branches much before release
[19:25:34 CET] <nevcairiel> first off, the rest of the world doesnt know that
[19:25:45 CET] <jamrial> we test them as much as any master snapshot, using fate on several systems, etc
[19:25:50 CET] <nevcairiel> and by limiting the amount of changes that go in to branches to be fixes, they get more stable over time
[19:25:55 CET] <Compn> right so they are the same as master, just old
[19:26:35 CET] <Compn> i dont have the answers
[19:26:43 CET] <nevcairiel> you never do, thats ok =p
[19:27:27 CET] <nevcairiel> but we as a project can't act like any other project and release "stable" versions, and then tell everyone that we dont really care about those versions
[19:27:32 CET] <Compn> so we need release maintainers, and  trac release maintainers
[19:27:34 CET] <nevcairiel> then we just shouldnt release any
[19:28:03 CET] <jamrial> Compn: yes, they have a frozen feature set, abi and api, which distros love. if you find a bug, you want that bug gone in the release and not get a "use master instead" as reply
[19:30:11 CET] <Compn> would be nice to have an iso with a random sampling of popular downstream products , with some kind of automated test to make sure a new release didnt break those programs. i dont know what the distros use to test such things.
[19:30:39 CET] <jamrial> just imagine if gcc every april said "we're making a release, branch has been made and is now frozen forever". you'd be stuck with crap like 4.9.0 for a whole year unless you use trunk which is essentially suicide until like december
[19:31:21 CET] <Compn> gcc is probably not a project we should follow. seeing how many times gcc changes have broken our build
[19:31:33 CET] <Compn> esp .0 releases
[19:31:43 CET] <nevcairiel> why not, what do you imagine how often new releases break downstream software :D
[19:32:20 CET] <Compn> gotta run, bbl
[21:40:20 CET] <Carll_> Hi
[21:40:23 CET] <Carll_> I would like to feed ffserver with some encoded packets.I'm using " av_interleaved_write_frame( format_out_ctx, outPacket ); " function to write a packet to an output media file. I can connect with the server with avformat_write_header( format_out_ctx, NULL ) function, and it is working fine (i think). If I pass that function, the server shows me " [POST] "/feed1.ffm HTTP/1.1" 200 4096 ""
[21:40:28 CET] <Carll_> But my problem is, the av_interleaved_write_frame() function doesn't feed the server.
[21:40:33 CET] <Carll_> Can anyone tell me what am i doing wrong? If somebody is willing to help me, I could send ffserver.conf and my C files.
[22:11:08 CET] <Carll_> someone?
[22:14:59 CET] <Compn> try ask in #ffmpeg , Carll_ ? 
[22:15:13 CET] <Compn> this channel is for development of ffmpeg
[22:15:18 CET] <Carll_> tried :/
[22:15:22 CET] <JEEB> but in general ffserver is only known by very few, so good luck
[22:15:32 CET] <Compn> try ask on mailing list ?
[22:15:45 CET] <JEEB> if you depend on it, you should either learn it by code so you can maintain it yourself or just run away
[22:16:08 CET] <Carll_> i would like to get the stream working on any media server, but i dont know if i am doing right.
[22:16:49 CET] <ubitux> awi
[22:16:51 CET] <ubitux> oups
[22:22:01 CET] <Carll_> Can someone help me please? The following command is working "ffplay -rtsp_flags listen -i rtsp://127.0.0.1:8090/live.sdp". It streams my desktop. 
[22:22:05 CET] <Carll_> But i would like to feed the server 
[22:22:14 CET] <Carll_> and it doesn't work
[22:23:20 CET] <JEEB> first of all this is the wrong channel for user support and second of all almost no-one knows anything about ffserver as already stated
[22:23:26 CET] <JEEB> you're better off asking the users' mailing list
[22:32:50 CET] <Mavrik> Should probably just delete ffserver from documentation, git and existence :P
[22:36:54 CET] <JEEB> IIRC the incoming API changes will pretty much break it, so after it goes through the period of deprecation warnings it will probably get removed - unless someone comes up and picks it properly
[22:37:37 CET] <wm4> Mavrik: +1
[22:37:45 CET] <wm4> but "they" will resist
[22:38:10 CET] <wm4> also, codecpar is still not merged...
[22:38:54 CET] <JEEB> yeah
[22:39:55 CET] <jamrial> git retcon ffserver
[22:44:54 CET] <nevcairiel> wm4: well you didnt fix it any further, so it sits there and wiats? :)
[22:55:58 CET] <cone-128> ffmpeg 03Michael Niedermayer 07master:c34250178ba2: avfilter/af_sofalizer: Fix "warning: ISO C90 forbids mixed declarations and code"
[23:14:13 CET] <cone-128> ffmpeg 03Paul B Mahol 07master:af5559ab6711: avfilter/vf_waveform: add graticule for chroma and flat filter
[00:00:00 CET] --- Tue Mar 15 2016