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

[burek]

[01:59:12 CET] <cone-353> ffmpeg 03Carl Eugen Hoyos 07master:5a51ca2da7b7: lavc/hapenc: Use the correct printf length modifier for size_t arguments.
[04:53:02 CET] <MAN> hello guys
[04:53:47 CET] <Guest98985> have you ever tried to build ffmpeg with opus in android via cygwin??
[04:54:21 CET] <Guest98985> I encountered ERROR: opus not found using pkg-config message
[04:54:59 CET] <Guest98985> do you have any ideas?? I searched google but all solutions were failed
[08:25:50 CET] <cone-170> ffmpeg 03Rodger Combs 07master:8e6478b723af: lavf/segment: fix autobsf
[08:25:51 CET] <cone-170> ffmpeg 03Rodger Combs 07master:be28ce210d56: lavf/matroskaenc: fix uninitialized read
[08:25:52 CET] <cone-170> ffmpeg 03Rodger Combs 07master:1a958f4eb098: lavf/matroskaenc: don't try to modify the header when live-streaming
[08:25:53 CET] <cone-170> ffmpeg 03Rodger Combs 07master:d401c37ef503: tests/fate/avformat: add segment.c tests
[12:07:07 CET] <cone-170> ffmpeg 03Michael Niedermayer 07master:37138338ff60: avcodec/sunrast: Fix input buffer pointer check
[12:39:15 CET] <cone-170> ffmpeg 03Vittorio Giovara 07master:271afd632f4d: lavc: Add hevc main10 profile to ffmpeg cli
[16:34:36 CET] <cone-170> ffmpeg 03Michael Niedermayer 07master:a566c952f905: avformat/mpegtsenc: Add option to mark stream begin as discontinuous
[19:35:46 CET] <ubitux> so, we can go back to merges?
[19:41:00 CET] <jamrial> yeah. qsv is solved. only thing that remains is applying the filter that was noop'd
[19:41:06 CET] <nevcairiel> yeah, i was planning to work on things soon, unless someone beats me to it
[19:50:02 CET] <RiCON> jkqxz: i remember i told you about this error with enconding with default settings(?)
[19:50:04 CET] <jkqxz> RiCON:  (Oops, collision, sorry.)  I thought that -look_ahead 0 was always required on older CPUs?  It certainly wasn't my intention to change the CLI behaviour.
[19:51:14 CET] <RiCON> i didn't use qsv before, the "-look_ahead 0" was from zeranoe, iirc
[19:55:36 CET] <RiCON> looks like even from more than a year ago "-look_ahead 0" has been needed if using a pre-haswell cpu
[19:55:55 CET] <RiCON> so it's not a regression from the libav merge, i'd say
[19:56:58 CET] <jkqxz> Yeah, from the code I'm pretty sure that behaviour hasn't changed (look_ahead is set by default, that becomes want_la in select_rc_mode() and it chooses VBR with lookahead).
[19:57:44 CET] <RiCON> https://trac.ffmpeg.org/ticket/4831
[20:03:59 CET] <jkqxz> It did change QSV_VERSION_MINOR passed to MFXInit() down to 1, because we are really supporting the build-time feature set.
[20:05:08 CET] <jkqxz> That shouldn't change anything, though, unless they actually built against a different version of the headers.
[20:06:47 CET] <nevcairiel> someone that cares about qsv should really build runtime f eature detection instead of the hardcoded things
[20:09:30 CET] <jkqxz> Someone that cares about distributing qsv binaries?
[20:11:02 CET] <nevcairiel> i guess?
[20:11:13 CET] <nevcairiel> if i build with a new sdk that still doesnt say anything about my cpu features
[20:13:08 CET] <jkqxz> Hmm.  Not on Linux where they dump support immediately.  (Only have a Haswell?  Nope, buy a new CPU or use the old version.)
[20:13:30 CET] <nevcairiel> dont think it works like that on windows
[20:14:48 CET] <jkqxz> Yeah.  They even deign to let you run it properly on a Braswell, despite lack of AVX support.
[21:24:20 CET] <cone-170> ffmpeg 03James Almer 07master:bab6b606752e: avformat/matroskaenc: support writing Chroma Location elements
[21:24:21 CET] <cone-170> ffmpeg 03James Almer 07master:5cb57131d3bb: avformat/matroskaenc: use display aspect ratio for DisplayWidth and DisplayHeight when possible
[21:50:45 CET] <cone-170> ffmpeg 03Philip Langdale 07master:234d3cbf469e: crystalhd: Fix up the missing first sample
[21:50:46 CET] <cone-170> ffmpeg 03Philip Langdale 07master:b5d714f49394: crystalhd: Switch to new decode API and remove the insanity
[21:50:47 CET] <cone-170> ffmpeg 03Philip Langdale 07master:6cc390dd5a53: crystalhd: Revert back to letting hardware handle packed b-frames
[21:50:48 CET] <cone-170> ffmpeg 03Philip Langdale 07master:badce88fdf84: crystalhd: Remove trust_interlaced heuristic
[21:50:49 CET] <cone-170> ffmpeg 03Philip Langdale 07master:89ba55dc0dfa: crystalhd: We don't need the track the last picture number anymore
[21:50:50 CET] <cone-170> ffmpeg 03Philip Langdale 07master:13dbf77b8192: crystalhd: Remove h.264 parser
[21:50:51 CET] <cone-170> ffmpeg 03Philip Langdale 07master:0eb836942f5d: crystalhd: Keep NOPTS_VALUE so we know it's not there.
[21:50:52 CET] <cone-170> ffmpeg 03Philip Langdale 07master:3019b4f6480a: crystalhd: Loop for a frame internally where possible.
[21:50:53 CET] <cone-170> ffmpeg 03Philip Langdale 07master:a07c07e7aa62: crystalhd: Simplify output frame handling
[21:50:54 CET] <cone-170> ffmpeg 03Philip Langdale 07master:d0a9af851ee8: crystalhd: Update high level description
[22:07:29 CET] Action: ubitux is lost in the ffmpeg.c time base nightmare
[22:08:56 CET] <RiCON> jkqxz: obs-studio just enables RCs selectively by checking the cpu generation
[22:10:43 CET] <jkqxz> From cpuid?
[22:10:48 CET] <RiCON> yeah
[22:12:14 CET] <jkqxz> Hmm, I guess that works quite nicely.
[22:12:24 CET] <RiCON> basically checks if it's >= haswell, then adds from https://github.com/jp9000/obs-studio/blob/master/plugins/obs-qsv11/QSV_Encoder.h#L72-L82
[22:12:31 CET] <RiCON> (bsd/gpl code)
[22:12:52 CET] <jkqxz> Have to maintain the table, though.
[22:14:24 CET] <kwizart> anyone still using crystalhd ? is there a known repo for the driver now that it has been kicked out of the staging area ?
[22:15:00 CET] <RiCON> https://github.com/jp9000/obs-studio/blob/master/plugins/obs-qsv11/QSV_Encoder.cpp#L168-L228 (also bsd/gpl
[22:15:29 CET] <RiCON> yeah, just checks for haswell or older
[22:16:03 CET] <kwizart> philipl, ^ do you know anyone who maintain the crystalhd kernel driver still ? (it's not in staging anymore)
[22:29:36 CET] <cone-170> ffmpeg 03Andreas Cadhalpun 07master:f84ae3f04aa0: avformat: close parser if codec changed
[22:32:13 CET] <ubitux> so what's up with frame->pts
[22:32:29 CET] <ubitux> it's not the packet pts, it's rescaled?
[22:33:01 CET] <ubitux> (it definitely looks rescaled to me)
[22:34:55 CET] <ubitux> an encode function is only supposed to copy the frame pts to pkt pts; same for frame pkt_duration to pkt duration?
[22:39:19 CET] <ubitux> mmh seems i only have 2 tests failing remaining
[22:43:29 CET] <nevcairiel> ubitux: the question is "when", because frame pts behaves different depending on when its used
[22:43:40 CET] <nevcairiel> decoding it should be the pkt pts, encoding it should be in avctx timebase
[22:44:02 CET] <ubitux> apparently ffmpeg.c is doing some frame pts rescaling post filtering
[22:44:18 CET] <ubitux> but it wasn't doing it for the duration
[22:44:29 CET] <ubitux> and i needed that for subtitles apparently
[22:45:30 CET] <ubitux> now i have to deal with the cc/subcc stuff, and find a way to transcode dvb subs to fix it as well
[22:45:40 CET] <ubitux> (no fate test for this... shame)
[22:46:21 CET] <ubitux> otherwise, i'm mostly done, hopefully
[22:47:24 CET] <ubitux> i'm breaking lot of stuff apparently too :3
[23:20:18 CET] <nevcairiel> I better start merging all the things and break all your stuff again, then!
[23:25:20 CET] <ubitux> i'm very happy to rebase my work on top of a thousands of merge commit :)
[23:25:26 CET] <ubitux> (honestly)
[23:27:48 CET] <jamrial> speaking of thousands of merges, who was the one we had to poke about gitweb showing every single unrelated merge on every file's history?
[23:28:46 CET] <ubitux> you mean the videolan admin? thresh?
[23:29:10 CET] <jamrial> yeah, him
[23:40:02 CET] <philipl> kwizart: Nope. There's this: https://github.com/yeradis/crystalhd
[23:40:16 CET] <philipl> I use that but I'm carrying kernel patches for recent kernels. Probably should send a PR...
[23:43:33 CET] <kwizart> philipl, seems old, I've attempted to build it recently and it was broken, also I wonder if there is a need for a rebase from what was available in staging at that time
[23:44:41 CET] <kwizart> philipl, staging support was only about BCM70012 IIRC, I have 70015
[23:45:07 CET] <kwizart> there is already an unmerged pull request
[23:46:02 CET] <philipl> kwizart: Yeah. It doesn't work out-of-the-box anymore. I've got enough patches to work with a 4.8 kernel today.
[23:46:07 CET] <philipl> Let me publish my tree.
[23:48:33 CET] <philipl> ACtually: this guy is keeping a patched one going. Use his: https://github.com/dbason/crystalhd
[23:57:10 CET] <philipl> https://github.com/philipl/crystalhd
[23:57:23 CET] <philipl> I had to add another fix on top of the dbason tree.
[23:57:25 CET] <philipl> Fun times.
[00:00:00 CET] --- Thu Nov  3 2016