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

[burek]

[00:43:24 CEST] <cone-957> ffmpeg 03Paul B Mahol 07master:e9770b40b17f: avfilter/vf_datascope: let user change background opacity
[00:58:32 CEST] <cone-957> ffmpeg 03Paul B Mahol 07master:21de33dd83ca: fate: add swaprect
[01:13:45 CEST] <cone-957> ffmpeg 03Burt P 07master:91117fc9f196: af_hdcd: fix bounds check in hdcd_envelope()
[02:49:49 CEST] <cone-957> ffmpeg 03Steven Liu 07master:fff4df7fba4f: MAINTAINERS: Add myself for hlsenc
[02:49:50 CEST] <cone-957> ffmpeg 03Steven Liu 07master:1da00be009aa: avformat/segment: give a warning message for remove initial_offset option
[03:43:38 CEST] <tmm1> michaelni: it doesn't look like output_ts_offset is creating the same output as initial_offset
[03:49:55 CEST] <jamrial> BBB: you should have committed that vp9 in mp4 patch when you approved it, because someone else just sent the same thing again :p
[04:16:53 CEST] <michaelni> tmm1, what is different and why ?
[04:17:31 CEST] <BBB> jamrial: ok will push
[04:18:36 CEST] <BBB> jamrial: actually
[04:18:39 CEST] <BBB> jamrial: can you push?
[04:18:42 CEST] <BBB> or can someone push?
[04:18:48 CEST] <BBB> my tree is old and Im about to go to bed
[04:21:17 CEST] <BBB> Ill see if I can compile in less than a few minutes
[04:24:01 CEST] <cone-957> ffmpeg 03Matthew Gregan 07master:7b3bc365f992: avformat/mov: Enable stream parsing for VP9.
[10:30:41 CEST] <BtbN> philipl, pts rescaling?
[10:31:00 CEST] <BtbN> ZNC is acting up, so there's a good chance I miss offline-conversations at the moment.
[11:17:20 CEST] <cone-149> ffmpeg 03Michael Niedermayer 07master:752e6dfa3ea9: avcodec/ccaption_dec: Use simple array instead of AVBuffer
[11:37:43 CEST] <ubitux> OutputStream.frame_rate, InputStream.framerate
[11:37:49 CEST] <ubitux> heh.
[11:40:58 CEST] <mateo`_> see also bitrate versus bit_rate
[12:00:17 CEST] <cone-149> ffmpeg 03Paul B Mahol 07master:ac3f9be330f3: fate: add weave
[12:00:18 CEST] <cone-149> ffmpeg 03Paul B Mahol 07master:653ca058079c: avfilter/vf_weave: do not leak unused frame
[12:54:47 CEST] <cone-149> ffmpeg 03Paul B Mahol 07master:5556392b3b3c: fate: add hstack and vstack
[13:10:22 CEST] <durandal_17> kdenlive is stealing lgpl code from us
[13:21:23 CEST] <thardin_> isn't kdenlive gpl?
[13:21:54 CEST] <thardin_> gplv2 even
[13:35:36 CEST] <durandal_170> yes
[13:37:25 CEST] <thardin_> so?
[13:47:47 CEST] <durandal_17> thardin_: they should use our API not steal code
[13:49:58 CEST] <durandal_17> why for some filter i get better speed when using threads=4 instead of threads=0 on 4 core cpu?
[13:54:06 CEST] <thardin_> it's not theft tho
[14:16:07 CEST] <durandal_17> thardin_: no, it isn't...
[14:26:05 CEST] <cone-149> ffmpeg 03Paul B Mahol 07master:7055b28d988a: avfilter/vf_datascope: cleanup code a little
[14:35:22 CEST] <wm4> durandal_17: that's why I keep thinking a simple multimedia plugin infrastructure (that isn't as complex as gstreamer or not too simple like ladspa/frei0r) would be great for open source
[14:59:15 CEST] <thardin_> personally I'd like something without endless layer of abstraction or stealing the control flow from the user
[14:59:30 CEST] Action: thardin_ looks at lavf
[14:59:35 CEST] <thardin_> lavfi even
[16:04:15 CEST] <philipl> BtbN: so, the timestamp rescaling you do in cuvid.
[16:04:36 CEST] <philipl> i see a lot of mkv files where the time base is 0/1.
[16:04:52 CEST] <philipl> obviously, this causes the rescaling to zero out everything.
[16:05:31 CEST] <philipl> Given that the timestamp field is long long, it can hold the raw value. why not just pass it through?
[16:06:26 CEST] <philipl> In crystalhd, the hardware did mangle pts so i ended up maintaining a mapping and passing token values through the hardware to map back after decoding.
[16:06:31 CEST] <BtbN> because the timebase cuvid uses is documented
[16:07:09 CEST] <philipl> Well, then you need a story for when the time base is 0 :-)
[16:07:33 CEST] <BtbN> Fix the source of a zero timebase. That shouldn't happen.
[16:08:31 CEST] <philipl> I'm seeing that reported for all vp8/9 and hevc mkvs i have.
[16:08:44 CEST] <BtbN> Sounds like something is wrong with the mkv demuxer then
[16:08:48 CEST] <philipl> only h.264 ones work
[16:08:50 CEST] <philipl> yeah
[16:09:05 CEST] <BtbN> a lot of stuff depends on the timebase to be somewhat sensible
[16:09:30 CEST] <philipl> iirc, mpv has its own mkv demuxer.
[16:09:34 CEST] <nevcairiel> you should really use pkt_timebase for rescaling anyway
[16:09:39 CEST] <nevcairiel> and not avctx->time_base
[16:09:42 CEST] <nevcairiel> those could be wildly different
[16:09:52 CEST] <nevcairiel> do note however that pkt_timebase is also not guaranteed to be set
[16:09:53 CEST] <philipl> i'll check that.
[16:10:07 CEST] <nevcairiel> (although if you use avformat -> avctx, that one is always set)
[16:10:12 CEST] <nevcairiel> but third-party things might not
[16:10:46 CEST] <philipl> ok. I'll check the mpv demuxer. they use avformat for everything else.
[16:10:54 CEST] <BtbN> nevcairiel, the pkt timebase is no longer available when the frames come out of cuvid though
[16:11:03 CEST] <nevcairiel> of course it is, its part of avctx
[16:12:11 CEST] <nevcairiel> in any case, using avctx->time_base is just wr ong
[16:12:13 CEST] <BtbN> And what's diffrent from time_base with that one then?
[16:12:32 CEST] <nevcairiel> pkt_timebase corresponds to the timebase of the avstream, ie. the timebase the packet timestamps use
[16:12:48 CEST] <nevcairiel> while avctx->time_base might be some internal timebase of the codec, unrelated to the demuxed timestamps
[16:13:02 CEST] <nevcairiel> (hence why its often unset)
[16:13:10 CEST] <BtbN> and pkt_timebase can still be 0 though?
[16:13:23 CEST] <nevcairiel> if the user-code doesnt set it, sure
[16:13:44 CEST] <nevcairiel> it needs to be set to the timebase of the timestamps you feed avcodec
[16:13:57 CEST] <BtbN> I assume at least ffmpeg does that.
[16:13:59 CEST] <nevcairiel> but its not used by many things, since often timestamps are passed 1:1
[16:14:00 CEST] <nevcairiel> yes
[16:14:31 CEST] <BtbN> Hm, so I'll just hope cuvid doesn't barf if the timestamps it gets are not in the documented timebase
[16:14:57 CEST] <nevcairiel> that i have never tested since their timebase matches the dshow timebase, so i never had problems with that :D
[16:15:16 CEST] <BtbN> it should just pass them through, but who knows
[16:17:02 CEST] <nevcairiel> quicksync gets all kidns of crazy ideas if you try to just pass through timestamps instead of rescaling them
[16:17:10 CEST] <nevcairiel> but quicksync uses mpegts timebase i think (90kHz)
[16:18:01 CEST] <BtbN> cuvid uses something wierd
[16:18:27 CEST] <nevcairiel> 100ns is what MS ues everywhere
[16:19:16 CEST] <BtbN> I'll just print a warning if pkt_timebase is 0, and pass the timestamps untouched
[16:19:36 CEST] <philipl> Thanks.
[16:20:03 CEST] <nevcairiel> at least with ffmpeg pkt_timebase is always set, so that should give you an improvement either way
[16:20:24 CEST] <BtbN> not if it doesn't care about the timebase
[16:20:40 CEST] <BtbN> cause then it's just converting back and forth with the wrong timebase, and it has no effect
[16:22:48 CEST] <nevcairiel> if its zero weird things might happen, tho
[16:23:03 CEST] <nevcairiel> so at least those cases get fixed
[16:23:42 CEST] <BtbN> well, if its zero the calculation for the resulting timestamp is a 0
[16:24:39 CEST] <BtbN> Can I expect pkt_timebase to be set during decode init?
[16:24:47 CEST] <nevcairiel> should
[16:24:48 CEST] <BtbN> For printing the warning, that is.
[16:36:13 CEST] <BtbN> philipl, https://github.com/BtbN/FFmpeg/ that should work
[16:36:40 CEST] <cone-149> ffmpeg 03Matthieu Bouron 07master:bf011695fd3a: lavc/hevc: store VPS/SPS/PPS data
[16:48:11 CEST] <philipl> BtbN: it does work. ship it.
[16:48:45 CEST] <cone-149> ffmpeg 03Clément BSsch 07master:6d6077024716: tests/fate/ffmpeg: regroup stream copy tests under a fate-streamcopy rule
[16:51:31 CEST] <cone-149> ffmpeg 03Thilo Borgmann 07master:4d48add89b2c: lavc/alsdec: use get_bitsz() to simplify reading of the mantissa
[16:52:56 CEST] <ubitux> michaelni: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg.c;h=d8584070a9f313bd9d890361dc62f1407d171357;hb=HEAD#l2958
[16:53:02 CEST] <ubitux> this check is causing me trouble
[16:53:20 CEST] <ubitux> can i have an example that break when i drop it?
[16:53:37 CEST] <ubitux> (so far it passes fate-streamcopy)
[17:06:36 CEST] <ubitux> michaelni: patch on the ml btw
[17:06:48 CEST] <mateo`_> jamrial: yes it does reuse the simple parser from hevc_parser.h (I've stated it in the compose message)
[17:07:26 CEST] <ubitux> we need to kill that ADVANCED_PARSER in lavc/hevc_parser.c
[17:08:00 CEST] <mateo`_> jamrial: and explained why I've copied some bits of it
[17:12:24 CEST] <ubitux> that's up to the hevc parser to start using that new function
[17:12:47 CEST] <ubitux> but the maintainer needs to that parser first
[17:13:48 CEST] <michaelni> ubitux if i comment 2958&9 out the an example that fails is: ./ffmpeg -i matrixbench_mpeg2.mpg  -r 24000/1001 -t 4 -vcodec copy ref.ts
[17:14:05 CEST] <jamrial> mateo`_: missed that, nevermind then
[17:14:12 CEST] <ubitux> michaelni: ok, thanks, looking at it
[17:14:45 CEST] <ubitux> (michaelni: fate test welcome! :P)
[17:14:56 CEST] <ubitux> that shit is going to break regularly if not tested
[17:15:25 CEST] <michaelni> yes, ill try to add one later today
[17:15:34 CEST] <michaelni> remind me if i forget
[17:15:35 CEST] <mateo`_> jamrial: no worries and I'm not against porting hevc_parser.c to use it later on
[17:16:02 CEST] <ubitux> michaelni: thanks
[17:23:19 CEST] <ubitux> michaelni: the md5 differs but both look fine
[17:23:45 CEST] <ubitux> same size, playback looks ok
[17:24:24 CEST] <ubitux> well, a few byte less without the check
[17:29:20 CEST] <michaelni> ubitux, http://trac.ffmpeg.org/ticket/2211 might be a better testcase
[17:29:57 CEST] <ubitux> looks nice
[17:30:06 CEST] <michaelni> ./ffmpeg -r 14 -i ~/tickets/2211/sample.h264 -vcodec copy test-14fps.avi
[17:30:30 CEST] <michaelni> 14 fps, 14 tbr, 14 tbn, 28 tbc vs50 fps, 50 tbr, 50 tbn, 100 tbc (with your patch)
[17:31:18 CEST] <ubitux> we don't have such sample in fate?
[17:31:45 CEST] <michaelni> dunno
[17:58:19 CEST] <cone-149> ffmpeg 03Timo Rothenpieler 07master:132adf73af31: avcodec/cuvid: use pkt_timebase instead of time_base
[17:58:20 CEST] <cone-149> ffmpeg 03Timo Rothenpieler 07master:b91e0e59874d: avcodec/cuvid: check for and warn about invalid pkt_timebase
[18:54:44 CEST] <durandal_170> where's Compn?
[19:10:23 CEST] <wm4> <BtbN> and pkt_timebase can still be 0 though? <- until not long ago, mpv passed through double float timestamps by reinterpret-casting them to int64_t, and not setting a timebase
[19:45:25 CEST] <cone-149> ffmpeg 03Lou Logan 07master:915abab25c5b: doc/filters: add missing palette* options
[00:00:00 CEST] --- Sat Sep 10 2016