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

[burek]

[00:02:40 CEST] <FishPencil> Might be an x265 issue, but I get https://paste.debian.net/plainh/eb39ffa1 when trying to build FFmpeg with x265
[00:07:00 CEST] <Compn> what ver ffmpeg , FishPencil ? 
[00:07:17 CEST] <Compn> looks like x265 problem
[00:07:21 CEST] <Compn> try make clean and rebuild
[00:07:34 CEST] <Compn> also this channel is for developing, try #ffmpeg for questions...
[00:18:45 CEST] <FishPencil> Compn: latest ffmpeg head, and latest x265 head. both were built fresh, and will do
[10:40:46 CEST] <mateo`> rcombs: do you have a branch somewhere i can use to test/review the heif support ?
[11:36:16 CEST] <paveldimow> q
[12:12:59 CEST] <jkqxz> ZhongLi:  Yeah, sorry about that collision.  The range one could be applied anyway, but given that it now checks properly against VAConfigAttribEncQualityRange I'm not sure how useful it is (the older drivers only have a 0-2 range, anyway).
[17:09:52 CEST] <cone-957> ffmpeg 03Carl Eugen Hoyos 07master:898ea658c8a4: lavc/g726: Add a little-endian G.726 encoder.
[19:12:42 CEST] <wm4> fate is not failing with master, right?
[19:15:54 CEST] <jamrial> wm4: it is on netbsd
[19:16:14 CEST] <jamrial> other targets are fine
[19:16:58 CEST] <jamrial> bah, clang since version 5 is miscompiling mjpeg, but that's been a thing for a while
[19:17:15 CEST] <jamrial> i don't think anyone reported that to llvm yet
[19:19:34 CEST] <wm4> seems like this was an unclean build tree (as in stale .o or .d files)
[19:39:54 CEST] <jya> to the h264 experts. What do you think of this code https://github.com/video-dev/hls.js/blob/master/src/demux/tsdemuxer.js#L495-L515 ; it assumes that every non-IDR slice with a type of I slice or SI I slice is a keyframe
[19:40:26 CEST] <nevcairiel> that depends how you define keyframe
[19:41:40 CEST] <jya> one I can start decoding from I guess
[19:41:48 CEST] <jya> or feed to a decoder and I get a frame out
[19:42:20 CEST] <BtbN> Usually called IDR frame I guess
[19:42:49 CEST] <jya> yes, IDR. But in various streams encountere, there's no IDR NAL of any kind
[19:43:13 CEST] <nevcairiel> any I frame is not a clean recovery point
[19:43:51 CEST] <jya> like http://212.143.237.109:1935/ws40-v01-video/mp4:36651.mp4/playlist.m3u8 , it starts with an IDR, and nothing after that. Just SEI recovery points regularly spaced
[19:44:08 CEST] <jya> and indeed, you can start decoding from those just fine
[19:45:10 CEST] <BtbN> The linked code is for NDR frames.
[19:45:13 CEST] <BtbN> I have no idea what that even is.
[19:45:18 CEST] <jya> oh, and while on SEI recovery point, H264 spec (D.1.7 Recovery point SEI message syntax) are there particular values indicating you can't really recover from there ?
[19:45:26 CEST] <jya> non-IDR
[19:45:32 CEST] <jya> (I assume)
[19:46:00 CEST] <wm4> <jya> one I can start decoding from I guess
[19:46:00 CEST] <wm4> <jya> or feed to a decoder and I get a frame out
[19:46:04 CEST] <wm4> these are different things too
[19:48:26 CEST] <nevcairiel> the rules when you can start h264 decoding and when you get a clean frame out are not that easy
[19:48:40 CEST] <jya> wm4: in 99% of the streams I've seen, they are one and the same
[19:48:54 CEST] <nevcairiel> SEI recovery points for example mean you have to feed it a bunch of frames until you get a clean result - the SEI tells you how many.
[19:49:09 CEST] <BtbN> If the extradata is stored externally, I think I and IDR are similar, if not the same
[19:49:22 CEST] <nevcairiel> thats not true
[19:49:29 CEST] <nevcairiel> reference frames can span over I frames
[19:49:31 CEST] <nevcairiel> IDR is a clean reset
[19:49:35 CEST] <jya> BtbN: as it would be with avc1
[19:50:00 CEST] <nevcairiel> ie. a P frame right after an I frame could still reference frames from before this I frame
[19:50:57 CEST] <jya> the issue for my purpose, is that when demuxing data, I get a start time and a duration. you want those times to match as much as possible
[19:51:56 CEST] <jya> nevcairiel: alright, then i change my definition of a keyframe, to a frame where the ffmpeg demuxer would have keyframe flag set to 1 :)
[19:52:52 CEST] <wm4> that would be "one I can start decoding from", or often "something random"
[19:53:45 CEST] Action: wm4 specifiably remembers ffmpeg's mkv demuxer breaking seeking in some correct webm files to "fix seeking" in broken files
[19:58:01 CEST] <jya> i guess, I need some kind of method that can determine when the keyframe information found in the container is broken, and only override that info from there.
[19:58:38 CEST] <jya> maybe assuming that I always want recovery_frame_cnt = 0
[19:59:27 CEST] <jya> ah! https://www.ffmpeg.org/doxygen/3.1/structH264SEIRecoveryPoint.html#a8012e2f9dace6155e00b654652ca8c99 " Frames having recovery point are key frames. "
[20:03:06 CEST] <JEEB> yea, SEI+I are flagged as "key frame" (random access point)
[20:21:00 CEST] <jya> JEEB: good point, maybe I should also look if there's a I-Frame that follows
[20:21:39 CEST] <jya> though, I'm sure there are streams out there with no such data, and it's expected to need a few frames before something valid comes out
[20:22:23 CEST] <JEEB> yea, many containers really lack a mechanism of noting intra refresh
[20:22:42 CEST] <JEEB> as in, "you can start everywhere as long as you are X pictures before the point you want to get to"
[20:22:52 CEST] <jya> my problems here is really for hls (mpeg-ts) streams converted into MP4
[20:27:22 CEST] <BtbN> yay, getting ma CPU replaced.
[20:28:47 CEST] <wm4> the real problem is the web and their funny protocols
[20:29:09 CEST] <BtbN> just stream in mp4 directly
[20:29:16 CEST] <BtbN> makes hls.js a whole lot less insane
[20:43:22 CEST] <jya> BtbN: for adaptative streaming, hls is super simple to implement as opposed to dash players
[20:43:37 CEST] <jya> as far as content providers are concerned
[20:43:50 CEST] <BtbN> HLS supports fragmented mp4
[20:44:01 CEST] <BtbN> Which removes most of the insanity hls.js is doing
[20:44:42 CEST] <jya> BtbN: mp4 hls streams are almost unheard of. First is super new, and everyone has been deeply involved with ts anyway
[20:44:50 CEST] <BtbN> YouTube uses them
[20:44:57 CEST] <jya> the crazy thing with HLS, is that segments aren't required to start with a keyframe
[20:45:09 CEST] <JEEB> DASH doesn't require that, either
[20:45:10 CEST] <JEEB> AFAIK
[20:45:20 CEST] <JEEB> the first sample doesn't have to be a RAP
[20:45:21 CEST] <jya> on mobile maybe, you can't stream HLS with youtube from desktop
[20:45:41 CEST] <BtbN> as long as you indicate in the key-segments in the playlist, I don't see an issue with that
[20:45:43 CEST] <jya> JEEB: it used to, though to ease compatibility with HLS, that was removed from the spec
[20:45:58 CEST] <BtbN> I think hls.js supports fmp4 in hls just fine. And I'd much rather use that insteas of remuxing ts in JavaScript
[20:46:39 CEST] <jya> and for quite a while, chrome was buggy and failed to correctly play any streams not starting with keyframe. so people started to tag every single frames as keyframe. that caused heaps of issues. Hence, why in FF, I had to stop relying on the mp4 sample tables to determine of a frame was a keyframe or not
[20:47:12 CEST] <JEEB> jya: ah right. I remember my friend herping a derp at google for that bug
[20:47:15 CEST] <jya> BtbN: but the fact is, even if hls.js does support it, there are almost no content using fmp4 
[20:47:46 CEST] <BtbN> why would that matter? ffmpeg can produce it just fine
[20:48:02 CEST] <RiCON> nginx-vod-module too, a fork at least
[20:48:07 CEST] <jya> because people play what's available on line, and not produce their own content?
[20:48:24 CEST] <BtbN> If they play what's available online it's most likely an mp4 anyway
[20:48:34 CEST] <BtbN> Only ever seen HLS being used for livestreams
[20:51:28 CEST] <jya> BtbN: you'd be surprised.
[20:51:55 CEST] <jya> plenty of content provider only care about hls, and use stuff like HLS.js to play their content
[20:52:48 CEST] <jya> Dailymotion, TED, NYJ, etc
[20:53:01 CEST] <wbs> BtbN: for content to be played on iOS (within an app), apple mandates that it uses hls (so that it can play on lower bitrate connections etc)
[20:53:34 CEST] <wbs> so due to ios, "everybody" has to have hls, and once you have that, hls.js is a pretty neat way to not have to provide the same content in too many other formats
[20:53:38 CEST] <jya> BtbN: with mobile exploding, HLS is the best common denominator. Have HLS, and you can stream everywhere to any clients
[20:56:15 CEST] <BtbN> I'd still rather create HLS with fmp4.
[21:14:39 CEST] <wbs> BtbN: that's only supported on ios >= 10 (which otoh has got a pretty big marketshare), but not e.g. on android, so it's not at all the same common denominator
[21:22:10 CEST] <JEEB> doesn't exoplayer support it?
[21:22:20 CEST] <JEEB> which pretty much all mobile playback apps use on android
[21:29:49 CEST] <wbs> well that's probably doable, and with hls.js you could do that in a browser as well, but not just straight in a <video>
[21:30:07 CEST] <BtbN> you can, in Safari and MS Edge!
[23:20:51 CEST] <cone-343> ffmpeg 03Michael Niedermayer 07master:bc488ec28aec: avcodec/me_cmp: Fix crashes on ARM due to misalignment
[00:00:00 CEST] --- Tue Aug 22 2017