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

[burek]

[00:29:00 CEST] <Chloe> michaelni: that looks like a really cool project, I tried doing something like that, before I even knew what ffmpeg was, in Go. I'd be interested to see how it goes
[00:29:50 CEST] <nevcairiel> dont we have a fingerprint filter already
[00:30:28 CEST] <nevcairiel> or was that never finished
[00:30:35 CEST] <nevcairiel> i remember seeing something a while ago
[00:50:24 CEST] <cone-125> ffmpeg 03James Almer 07master:8063978bfc86: avformat/matroskaenc: don't write a FlagInterlaced element if it would write the default value
[00:58:27 CEST] <michaelni> nevcairiel, i dont think we have a native one. Theres one that can be used throgh a external lib
[01:08:13 CEST] <nevcairiel> maybe it died on the ML, i faintly remember there being some sort of fingerprinting thing following some industry standard, which some people d idnt like because the standard is crap
[01:08:16 CEST] <nevcairiel> maybe it was for video
[07:02:36 CEST] <vikasmahato0> Hello, I am new to Open Source. I want to contribute to ffmpeg's codebase. Can anyone help me get started?
[07:13:40 CEST] <vikasmahato> Can anyone help me getting started with contributing to ffmpeg
[10:00:38 CEST] <cone-331> ffmpeg 03Matthieu Bouron 07master:a458ed65b5d1: lavc/mediacodecdec: remove first output buffer timing debug log
[10:00:38 CEST] <cone-331> ffmpeg 03Matthieu Bouron 07master:cfa3c2655ac2: lavc/mediacodecdec: rename dequeued_buffer_nb to output_buffer_count
[11:59:10 CEST] <Chloe> They didn't stay long :/
[12:16:00 CEST] <cone-331> ffmpeg 03Rostislav Pehlivanov 07master:230178dfe25e: aacenc: use the decoder's lcg PRNG
[12:18:25 CEST] <atomnuker> I'm not sure the dist approximation on the noise coeffs is right, but the system and how it interacts with the coder is very finely tuned
[12:19:43 CEST] <atomnuker> IMO the MPEG4 specs should have defined a slope which to code in the bitstream to somewhat model the noise
[12:21:26 CEST] <atomnuker> or better yet just a very low order LPC (which you could get for free if the TNS system wasn't per entire window)
[12:22:54 CEST] <atomnuker> that way you could also permit PNS on short windows since you wouldn't shave off as much information as you do with a flat distribution
[12:24:24 CEST] <atomnuker> (though I bet many AAC decoders just use a hardcoded table of random values for the noise)
[12:26:20 CEST] <atomnuker> fun fact: using PNS for all windows and going below 3khz will yield 20kbit/sec with a very comprehensible sound to the original
[12:27:43 CEST] <atomnuker> despite the insanely huge steps on the PNS volume quantization
[12:40:53 CEST] <cone-331> ffmpeg 03Carl Eugen Hoyos 07master:fe8959bbece4: lavf/riffenc: Always write unexpected channel_mask.
[13:52:33 CEST] <Compn> >chinaffmpeg.org
[13:59:23 CEST] <Chloe> Compn: where's that from?
[13:59:26 CEST] <Chloe> oh... lol ok
[14:10:21 CEST] <Compn> Chloe : contributor email addy
[14:10:33 CEST] <Compn> :)
[14:24:05 CEST] <Chloe> yeah
[16:46:52 CEST] <cone-331> ffmpeg 03Philip Langdale 07master:b5f45208fbe5: crystalhd: Fix handling of PTS
[16:46:53 CEST] <cone-331> ffmpeg 03Philip Langdale 07master:03d6d5f3760e: crystalhd: Use mpeg4_unpack_bframes to avoid buggy crystalhd handling
[17:09:53 CEST] <philipl> I know that the crystalhd hardware is pretty much completely irrelevant these days, but I decided to have a go at moving the decoder to the new m:n api and by doing so I was able to rip out all of the insane heuristics and workarounds I put in to make it 'work' in the 1:1 api. Obviously this would break compatibility if pushed, but the old situation was so fragile that pragmatically speaking, you 
[17:09:59 CEST] <philipl> couldn't really say it worked before.
[17:10:16 CEST] <nevcairiel> didnt you say it basically didnt work before anyway
[17:10:25 CEST] <nevcairiel> since we broke it with recent changes
[17:10:32 CEST] <philipl> Turns out that was just in the 1:1 context.
[17:10:33 CEST] <nevcairiel> (more or less recent)
[17:10:39 CEST] <philipl> I fixed those issues
[17:11:06 CEST] <philipl> So yes, before the last three changes I pushed for it, it flat out didn't work.
[17:11:19 CEST] <philipl> With those changes, it's back to as working as it was 5 years ago.
[17:11:27 CEST] <nevcairiel> hardware things are the most likely to really benefit from the m:n api, that was one of the main goals it was build for
[17:11:28 CEST] <philipl> With the pending new API changes, it actually works.
[17:11:48 CEST] <philipl> Yeah. Night and day with this stuff.
[17:12:13 CEST] <philipl> So question is really, can I just push these changes and break compatibility or do we need to keep 1:1 api support for contractual reasons.
[17:12:18 CEST] <philipl> I don't want to support both.
[17:12:31 CEST] <nevcairiel> its up to you if you want to move it over, it will certainly keep working with ffmpeg, but API users might need to migrate to the new API
[17:13:02 CEST] <nevcairiel> maybe wait with pushing until ffmpeg 3.2 was branched
[17:13:11 CEST] <philipl> If that's acceptable, that's what I'll do.
[17:13:29 CEST] <philipl> (Works great with mpv using the new api)
[17:14:01 CEST] <nevcairiel> clearly there is an argument here that it just never worked right without this
[17:14:05 CEST] <nevcairiel> so its a clear advantage
[17:14:15 CEST] <philipl> absolutely.
[17:18:21 CEST] <nevcairiel> other hw things would equally like to switch over i'm sure, but their "emulation" works OK so far with some extra buffering, so tehy dont bother
[17:19:11 CEST] <nevcairiel> can switch when we're closer to the cut-off for the old API
[17:19:36 CEST] <philipl> Ok.
[19:01:55 CEST] <philipl> So, who's supposed to be responsible for interpolating timestamps for something like h.263 in an avi where 2 out of 3 frames have no timestamp in the container?
[19:24:51 CEST] <BtbN> philipl, isn't avi timestamp-less anyway, and just cfr?
[19:26:48 CEST] <JEEB> I guess he's talking about b-frame packing where a single "frame" has multiple coded samples
[19:26:59 CEST] <JEEB> and yes, AVI is DTS only and CFR
[19:29:42 CEST] <philipl> yeah
[19:30:52 CEST] <philipl> Anyway, point being that good ol crystalhd doesn't work out timestamps for you (cuvid does)
[19:31:11 CEST] <philipl> If I return NOPTS, mpv interpolates well enough (with a lot of warnings)
[19:33:14 CEST] <BtbN> just make one up based on the framerate I'd say
[19:33:21 CEST] <BtbN> cuvid has code for that.
[19:34:36 CEST] <philipl> That's my plan
[19:36:36 CEST] <lordPoseidon> hello I am a user of FFMpeg, I know C and C++ language, I want to help in the contribution, what should I study about the FFMPEG in order to know its internals
[19:37:03 CEST] <JEEB> there's so much stuff you should look into what you want to improve within the project first
[19:39:03 CEST] <lordPoseidon> JEEB: OK, I what other libraries of the C im supposed to know, I know some amount of C and C++ standard library
[19:39:05 CEST] <JEEB> and of course the first step is to compile FFmpeg
[19:39:31 CEST] <lordPoseidon> yes it was easy, I have done it 
[19:39:34 CEST] <lordPoseidon> I have make it
[19:39:51 CEST] <lordPoseidon> from source from the github mirror
[19:41:04 CEST] <JEEB> cool
[19:41:08 CEST] <lordPoseidon> what extra I need to know, I also know the 8086 assembly, I am a CSE student, and an aspiring GSOC candid next yr
[19:41:29 CEST] <JEEB> I'd say you're good to start poking around
[19:41:42 CEST] <JEEB> personally my adventures into FFmpeg start with "X works badly"
[19:41:53 CEST] <JEEB> and then I try to improve that X
[19:41:53 CEST] <lordPoseidon> OK
[19:42:23 CEST] <lordPoseidon> So is it possible to understand the stuff, I want to ask where to learn first
[19:42:45 CEST] <philipl> (gdb) p avctx->pkt_timebase 
[19:42:46 CEST] <philipl> $1 = {num = 125, den = 125874}
[19:42:46 CEST] <philipl> (gdb) p avctx->framerate 
[19:42:46 CEST] <philipl> $2 = {num = 0, den = 1}
[19:42:51 CEST] <JEEB> it should be possible to try and look things up
[19:42:52 CEST] <philipl> *sigh*
[19:43:03 CEST] <JEEB> as you start looking into things
[19:43:21 CEST] <JEEB> you could read up a generic multimedia primer but I'm actually not sure if it would help you much if at all
[19:43:29 CEST] <JEEB> it really depends on what you want to poke
[19:43:30 CEST] <lordPoseidon> JEEB: OK, thx sir, I start moving around the code, study it
[19:43:37 CEST] <lordPoseidon> ok
[19:43:53 CEST] <JEEB> of course the nr1 problem is if you haven't found anything wrong with FFmpeg :D
[19:43:59 CEST] <JEEB> then you don't have an agenda
[19:44:36 CEST] <lordPoseidon> ok
[19:44:53 CEST] <lordPoseidon> I use it to convert videos usually ;-)
[19:45:11 CEST] <JEEB> I think there are some lists of projects etc
[19:45:24 CEST] <JEEB> which could help you see if you can find something specific to poke
[19:45:40 CEST] <lordPoseidon> OKs thx, for your help, I see thx again
[19:47:02 CEST] <BtbN> philipl, the avi demuxer definitely should have set that.
[19:47:09 CEST] <BtbN> also investiage the timebase field
[19:48:36 CEST] <philipl> BtbN: and yet, here we are. :-)
[19:49:35 CEST] <philipl> (gdb) p avctx->time_base
[19:49:35 CEST] <philipl> $3 = {num = 0, den = 1}
[19:50:28 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/avidec.c#L691 
[19:52:47 CEST] <nevcairiel> decoders should just forward timestamps from the input
[19:52:51 CEST] <nevcairiel> so: dont worry about it
[19:54:38 CEST] <philipl> well, the timestamp is NOPTS. As I said, mpv seems to handle it fine, although it warns every time.
[19:54:52 CEST] <JEEB> yeah, I'm not sure if decoders are the place where you should start putting container specific hacks into
[19:55:47 CEST] <philipl> The cuvid library does seem to interpolate. I stuck some debug output in there and BtbN avoids setting an input timestamp on NOPTS, but the library/hardware returns a meaningful (correct) value on output.
[19:56:39 CEST] <philipl> I'm happy to ignore it and ask wm4 if he really wants to warn on every frame
[19:56:47 CEST] <BtbN> How does that even work? Multiple frames per packet?
[19:56:57 CEST] <philipl> BtbN: how does what even work?
[19:56:59 CEST] <BtbN> Or rather, how did that work before, with the old api
[19:57:23 CEST] <BtbN> Well, there are multiple frames per input packet, right?
[19:57:28 CEST] <philipl> Yes.
[19:57:36 CEST] <philipl> SO, this pattern of incomplete timestamps was always there.
[19:57:38 CEST] <BtbN> And how did the old 1:1 API handle that?
[19:57:48 CEST] <philipl> going back long enough in time, everything seemed to work and I never paid attention.
[19:58:17 CEST] <philipl> Then when I went back to it this month, it was all busted and my attempt to let the hardware handle unpacking bframes didn't work anymore.
[19:58:43 CEST] <BtbN> I still don't understand how having multiple frames in the same packet worked with the old API.
[19:58:49 CEST] <philipl> I replaced that with the bsf and told it to return '0' for the NOPTS frames and empirically it worked.
[19:58:57 CEST] <philipl> the hardware could handle it
[19:59:00 CEST] <JEEB> BtbN: usually a parser would handle it
[19:59:14 CEST] <JEEB> so you had a parser separate the samples or so
[19:59:23 CEST] <JEEB> at least that's how it's done for some formats
[19:59:25 CEST] <philipl> That's what I'm doing now.
[19:59:34 CEST] <BtbN> So the packages were split before being fed to the decoder?
[19:59:55 CEST] <philipl> That's today. I can't honestly tell you how it worked out fine 5 years ago.
[19:59:57 CEST] <JEEB> at least there's a framework for that in lavc, yes
[20:00:09 CEST] <JEEB> and demuxer can request that
[20:00:25 CEST] <BtbN> it seems to be a codec thing rather than a decoder one
[20:02:36 CEST] <jamrial__> nevcairiel: do you think it would be ok to drop our qsv changes and put it in the exact same state as libav so merges can resume?
[20:02:42 CEST] <jamrial__> i'm not sure what the nablet developers changed in our tree, but i doubt libav's current code is non working
[20:03:07 CEST] <jamrial> they haven't replied to two of my emails. same with one by michaelni
[20:03:24 CEST] <jamrial> so they aren't exactly maintaining it in any timely manner
[20:04:16 CEST] <nevcairiel> imho libavs is currently in a better state even
[20:04:24 CEST] <nevcairiel> with one exception, it doesnt support mjpeg or something
[20:04:31 CEST] <nevcairiel> (but who cares)
[20:05:11 CEST] <jamrial> then imo lets just do that. if Ivan Uskov or any other nablet developer shows up again they can resume their custom changes
[20:06:31 CEST] <Chloe> This sounds like a good idea
[20:08:37 CEST] <BtbN> Is there anything I can do for ffmpeg_cuvid.c so it doesn't break when the merges?
[20:10:29 CEST] <nevcairiel> i'll let you know when i figure it out
[20:10:53 CEST] <nevcairiel> dont think you can pre-emptively fix it
[20:15:41 CEST] <jkqxz> jamrial:  I was planning on looking at qsv in the next few days if noone else did.  My plan was mostly that, with maybe attempting to merge some changed features.
[20:16:09 CEST] <jkqxz> (qsv encode in ffmpeg currently segfaults immediately on Linux.)
[20:20:00 CEST] <nevcairiel> some of the core functions are quite different, imho going back to a common base is a good idea, even if its one big noisy change
[20:20:09 CEST] <philipl> BtbN: So, the missing framerate/timebase data is related to using the new API
[20:20:10 CEST] <nevcairiel> we do have some more encoding options that may be worth keeping
[20:20:28 CEST] <philipl> cuvid also gets empty/unset values
[20:20:47 CEST] <philipl> h263dec does not. I think decode_video2 does some stuff that isn't done in the new API path
[20:24:28 CEST] <BtbN> Am I missing something, or is that >= 0 there wrong: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libx264.c#L296
[20:24:41 CEST] <BtbN> x4->forced_idr is a bool opt, that defaults to -1
[20:24:53 CEST] <BtbN> so setting it to either true or false both forces idr?
[20:25:35 CEST] <BtbN> why is it even a tri state bool?
[20:29:50 CEST] <philipl> BtbN: Now I understand. Before my change to use the new API, the avctx framerate/timebase fields were populated and mpv used them to interpolate without complaining.
[20:30:02 CEST] <philipl> after switching to the new API, those fields are all garbage, so it complains a lot.
[20:30:05 CEST] <philipl> mystery solved.
[20:36:08 CEST] <BtbN> I kind of feel like that force_idr logic in libx264 was intended to work diffrently than it does now
[20:36:23 CEST] <BtbN> like, -1, the default, means live the encoder alone, 0 means intra, 1 means idr
[20:37:42 CEST] <jamrial_> BtbN: it was probably changed into an bool av_opt_type at some point
[20:37:56 CEST] <BtbN> even as an int it would have not worked propperly
[20:38:00 CEST] <jamrial_> afaik bool is a relatively new addition to AVOption
[20:38:14 CEST] <BtbN> even setting it to 0 enables forced idr
[20:38:29 CEST] <BtbN> the tri-state is entirely unused, with -1 meaning false, and everything else true
[20:41:14 CEST] <philipl> BtbN: Ok, forget that. That's the difference between probing and opening for decode.
[20:41:17 CEST] <philipl> So no idea.
[20:50:27 CEST] <BtbN> philipl, have you tried setting the new AVOID_PROBING flag on it?
[20:50:50 CEST] <philipl> BtbN: Yes, I'm already setting that.
[20:51:15 CEST] <philipl> I want to say this is some difference in mpv but need to debug more
[20:51:23 CEST] <philipl> h263dec returns NOPTS, for sure.
[20:54:34 CEST] <cone-400> ffmpeg 03Timo Rothenpieler 07master:30c558750374: avcodec/nvenc: add support for forcing intra/idr frames
[21:12:01 CEST] <jayridge> Hi. I submitted a patch for RTSPS. I made the requested changes from the ffmpeg-devel list and sent them back. Should I be doing anything else? This is my first patch. Thank you. https://patchwork.ffmpeg.org/patch/817/
[21:18:55 CEST] <Compn> jayridge : is there any server we can test it on ?
[21:19:02 CEST] <Compn> maybe just ping it...
[21:19:30 CEST] <jayridge> I can set something up
[21:19:36 CEST] <Compn> that would be nice
[21:20:11 CEST] <jayridge> ok i will work on that
[21:21:59 CEST] Action: Compn runs before he has to test a patch
[21:22:00 CEST] <Compn> lol
[21:36:27 CEST] <philipl> BtbN: continuing down the rabbit hole. with h263dec, mpv is using dts to work out timestamps. With crystalhd, dts is unset.
[21:39:40 CEST] <philipl> Yeah, so decode_video2 will copy the pkt dts to the output frame because it can. with new APi that's obviously not possible.
[21:39:47 CEST] <philipl> I guess it becomes decoder's responsibility?
[21:42:25 CEST] <BtbN> It can't, because of reordering and delay and stuff
[21:42:29 CEST] <BtbN> for cuvid I had to workaround that.
[21:47:35 CEST] <philipl> Well, decode_video2 copies the current input packet dts to current output frame. You can emulate that with a fifo.
[21:48:06 CEST] <philipl> I feel like I'd rather interpolate pts :-P
[21:49:58 CEST] <BtbN> I workarounded it doing it, by setting stuff to NOPTS again
[21:50:04 CEST] <BtbN> with reordering and stuff it's just plain bad
[21:51:55 CEST] <philipl> If cuvid wasn't interpolating pts for you, then this h.263 stuff would get the same warnings from mpv.
[21:52:41 CEST] <BtbN> I still don't see where interpolating PTS would be neccesary. There allways was one input packet per output frame, so it has a pts available.
[21:53:02 CEST] <philipl> With avi, there is no input pts
[21:53:23 CEST] <philipl> and with new API there is no dts carried over to output
[21:53:28 CEST] <philipl> so you have no values at all
[21:54:20 CEST] <BtbN> so there are packets without a PTS coming in, and it just works?
[21:54:27 CEST] <philipl> with cuvid, yes.
[21:55:07 CEST] <philipl> You are a sane man and so you don't test with avi but it's doing this magic for you.
[21:59:35 CEST] <BtbN> I'd guess it happens when you pass a frame without the PKT_TIMESTAMP flag in between
[21:59:43 CEST] <BtbN> must have been designed just for that case
[22:01:34 CEST] <philipl> I think so.
[22:08:11 CEST] <RiCON> BtbN: re: force_idr, could have something to do with both ways you can force x264 to use an IDR frame depending on open gop settings
[22:09:28 CEST] <BtbN> RiCON, hm?
[22:09:58 CEST] <BtbN> currently, by default of -1, it forces an intra frame. If setting force_idr to either 0 or 1, it forces an intra frame. Which over all doesn't make much sense.
[22:11:05 CEST] <RiCON> http://www.chaneru.com/Roku/HLS/X264_Settings.htm#qpfile
[22:12:53 CEST] <BtbN> shouldn't that completely override that setting anyway?
[22:18:48 CEST] <RiCON> nevermind, understood the check now
[22:19:20 CEST] <BtbN> hm?
[22:59:39 CEST] <cone-400> ffmpeg 03Carl Eugen Hoyos 07master:932bbfc5d8ae: configure: Use LDEXEFLAGS in check_ld().
[23:27:29 CEST] <cone-400> ffmpeg 03James Almer 07master:dc781459cc1a: avformat/matroska: fix MatroskaVideoFieldOrder enum values
[00:00:00 CEST] --- Thu Oct 13 2016