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

[burek]

[04:33:45 CET] <ac_slater> hey guys. I'm streaming some real-time video over UDP via ffmpeg. I have two machines connected via ethernet (no switch). `ffmpeg` on A, and `ffplay` on B. On B, I see an initial network latency of ~1second. Within about 5 minutes, this grows to ~20 seconds. My encoder (x264) is reporting over 1x encoding speed. Any clue?
[04:34:00 CET] <ac_slater> I get that there should be some network+encoding latency, I just didnt think it would grow
[04:34:18 CET] <ac_slater> (the video bitrate is only 500Kbit/s ... very low)
[05:48:53 CET] <votz> Because ffprobe doesn't support seeking, ffmpeg is used to stream copy a subtrack of the video with -copyts -vsync 0. Then ffprobe is used on that stream copied subsection. Unfortunately the keyframe pts values do not match exactly -- they're slightly different, despite -copyts and -vsync 0. What causes this?
[09:04:15 CET] <votz> How can IDR frames be differentiated from non-IDR I-frames with ffprobe?
[09:38:39 CET] <klaxa> votz: with ffprobe -show_frames
[09:38:50 CET] <klaxa> IDR frames will be keyframes (afaik)
[09:39:03 CET] <klaxa> most of the time they are i think
[17:47:43 CET] <MarkusDB1> ffplay seems really fast, but is there an "easier" to install option on mac os x?
[17:50:25 CET] <JEEB> if you need a player I really recommend you go for mpv rather than ffplay, as ffplay is just supposed to be a simple player implementation on top of the libraries + SDL
[17:51:51 CET] <MarkusDB1> yeah I guess that's why it's so superfast =)
[17:52:19 CET] <MarkusDB1> JEEB: You know the best mpv alternative for mac?
[17:52:32 CET] <JEEB> mpv works just fine on OS X as well
[17:53:08 CET] <MarkusDB1> mpv.io?
[17:53:17 CET] <JEEB> yes, it has homebrew formulas and all that
[17:53:39 CET] <MarkusDB1> cool. I try it out. My goal is really low latency streaming. And vlc is not user friendly for that
[17:53:53 CET] <MarkusDB1> ffplay worked great.. but my target audience will not want to mess with that
[17:54:03 CET] <JEEB> the latency really depends on the demuxer etc buffering
[17:54:12 CET] <MarkusDB1> yeah I know
[17:54:21 CET] <MarkusDB1> but vlc's defaults is kinda bad
[17:54:33 CET] <chungy> Why wouldn't mpv be "superfast"
[17:54:40 CET] <JEEB> mpv will also use the same libraries as ffplay on the background
[17:54:45 CET] <MarkusDB1> great
[17:54:54 CET] <JEEB> but yes, parameters can differ although they can also be tweaked
[17:55:02 CET] <MarkusDB1> chungy: dunno, I'm noobing around this currently
[17:55:07 CET] <MarkusDB1> chungy: bare with me
[17:55:20 CET] <JEEB> read the fine manual and ask questions on the related IRC channel when the time comes, basically
[17:55:27 CET] <MarkusDB1> great
[17:55:34 CET] <MarkusDB1> thanks!
[18:06:08 CET] <votz> klaxa: both IDR frames and non-IDR frames are marked with key_frame=1
[18:06:26 CET] <votz> As far as I can tell, there's no way to differentiate them.
[18:14:55 CET] <JEEB> votz: yeah - I don't think you can differentiate the picture types too easily... the decoder of course itself knows, but yeah
[18:15:25 CET] <JEEB> there should be a flag that should only be 1 with sync samples (IRAPs), but it can of course be that it isn't exactly correct
[18:30:23 CET] <votz> JEEB: How else can ffmpeg or ffprobe be used to enumerate the pts values of IDR frames in a video?
[18:31:04 CET] <JEEB> you can't. the closest is the "this picture is a seekable one" which is not always correct, but often is
[18:31:26 CET] <JEEB> but if your thing shows that flag for all pictures then you're hitting one of those things to "fix" broken samples
[18:31:30 CET] <JEEB> or just a bug
[18:31:51 CET] <votz> What do you mean by 'one of those things to "fix" broken samples'?
[18:32:44 CET] <JEEB> something that supposedly enabled seeking in a file that a user was complaining wouldn't seek but should be according to him seekable... but that's just a guess :P
[18:32:53 CET] <JEEB> it could just be a honest incorrect usage of the flag
[18:33:14 CET] <JEEB> but as I said, there IIRC is no API to get the AVC/HEVC specific picture types currently
[18:33:47 CET] <JEEB> the best you can get is the one flag (don't remember its name but it was badly named anyways) which is supposed to tell if you can seek to it or not
[18:34:03 CET] <JEEB> it could have been that exact one you've poked
[18:37:53 CET] <votz> If you're curious, here's the default output for an IDR I-frame and a non-IDR I-frame. http://paste.ubuntu.com/14924042/
[18:39:49 CET] <votz> Looking for that flag you speak of to see if that helps. Otherwise, what options are there? Is the IDR information stored in the SPS or PPS NALU?
[18:40:38 CET] <JEEB> aren't those just parameter sets? the actual picture containing (was it VCL?) NAL units would have that info as they come by
[18:41:19 CET] <votz> I believe so, but I'm not 100% positive. I'm just digging at the bottom of the barrel for some solution.
[18:41:35 CET] <JEEB> the HEVC parser did actually output what it finds if you enable debug logging, but that isn't an API in any way or form :D
[18:41:43 CET] <votz> The fundamental problem to solve is this: find the nearest IDR frame before and after some timestamp
[18:41:49 CET] <JEEB> which was useful when I was hacking up HEVC-in-matroska
[18:42:32 CET] <JEEB> is that AVC or HEVC btw?
[18:42:48 CET] <votz> so you say, what's the nearest IDR frame before and after 10.38s? And then [run stuff] to find that the nearest IDR frame before 10.38s is 10s and nearest after is 15s.
[18:42:58 CET] <votz> AVC
[18:43:00 CET] <ac_slater> Hey all. Has anyone got a clue why MPEGTS with (only) AVC would pause for ~30ms every seconds?
[18:43:33 CET] <JEEB> ok, so there's only IDR + the weird-ass open gop / intra refresh cases
[18:43:56 CET] <JEEB> HEVC really made that simpler to parse because they added more picture types that are seekable
[18:44:25 CET] <JEEB> (IRAP being the umbrella term, which then contains IDR and the rest)
[18:44:40 CET] <votz> Unfortunately re-encoding to HEVC isn't an option
[18:44:49 CET] <JEEB> yeah, I'm not saying that :P
[18:45:17 CET] <JEEB> just saying that finding random access pictures in AVC can be "fun", since you can have non-IDR pictures which are still supposed to be seekable
[18:45:36 CET] <votz> Can you think of a clever solution? Like use ffmpeg's seeking twice to seek to those IDR frames at 10s and 15s (as an example)?
[18:46:08 CET] <votz> What denotes seekable keyframe or not? Whether frames after the keyframe reference frames before the keyframe or not?
[18:46:28 CET] <JEEB> IDR is the most clear one
[18:46:35 CET] <JEEB> since it kills off all references
[18:46:52 CET] <JEEB> then there's I pictures with recovery points
[18:47:14 CET] <JEEB> which is what is used with open gop
[18:47:59 CET] <JEEB> right, so recovery point is a SEI message
[18:48:20 CET] <JEEB> i wonder if lavf/lavc takes that stuff into mention at all
[18:49:14 CET] <votz> Are frames that ffprobe marks as key_frames 'seekable' in that sense? That is, no frame after a key_frame will reference a frame before that key frame?
[18:49:31 CET] <votz> In other words, is it safe to stream copy a slice of the video starting at that seekable key_frame, even if it's not an IDR frame?
[18:49:59 CET] <foonix> i think you have good chance to find 'seekable' key_frame when there's P frame before
[18:54:02 CET] <JEEB> votz: no, that is not necessarily seekable. which leads to stuff working like this https://ffmpeg.org/pipermail/libav-user/2012-July/002509.html
[18:57:08 CET] <JEEB> votz: you could make a question-type issue on the tracker I guess? although we basically currently lack any APIs to get those format-specific picture types :)
[18:58:58 CET] <votz> JEEB: I've been using an old version of avprobe that, strangely/luckily, only reports IDR frames as key frames. This is libav 11.4.
[18:59:27 CET] <JEEB> uhh, that doesn't sound good
[18:59:34 CET] <votz> But that version is too old to support seeking: avprobe v11.4 doesn't have -read_intervals
[18:59:55 CET] <JEEB> can you post a sample of an affected clip?
[18:59:56 CET] <votz> Thus, I devised a hack: stream copy a section around the desired point with -copyts and then run avprobe 11.4 on that subsection
[19:00:20 CET] <votz> But I then bumped into another problem: for whatever reason, the pts values are not *exactly* the same
[19:01:45 CET] <votz> Example: http://paste.ubuntu.com/14926732/
[19:02:20 CET] <votz> you'll notice the difference between the IDR frames is identical, but their absolute pts values is not.
[19:03:04 CET] <votz> So, a different potential solution: why wouldn't a subtrack stream copied with -copyts have *exactly* the same pts values?
[19:03:32 CET] <JEEB> what container is it?
[19:04:10 CET] <JEEB> also there of course can be a difference in how the pts gets calculated between Libav and FFmpeg >_>
[19:04:14 CET] <votz> The original video is h264 in MP4, the stream copied subtrack with -copyts is mpegts
[19:04:28 CET] <JEEB> if possible, keep the same container
[19:04:34 CET] <JEEB> mpeg-ts's time base is different
[19:04:58 CET] <JEEB> close, but it can have some differences depending on the picture rate
[19:05:08 CET] <JEEB> or well, not close but a pretty large timebase
[19:05:12 CET] <JEEB> I think it was 90000 ticks or something
[19:06:15 CET] <votz> And it's an ancient libav, too. I lucked out and had an old static build on hand. And -- for whatever reason -- avprobe 11.4 only prints IDR frames as key frames.
[19:06:51 CET] <JEEB> considering that Libav still hasn't released 12 IIRC it's not really "ancient" :P
[19:07:04 CET] <votz> Fair point
[19:07:20 CET] <votz> Perhaps an old ffprobe behaves the same way. I didn't test.
[19:07:55 CET] <JEEB> quite possible. it would be interesting to see where the change would end up bisected
[19:08:44 CET] <votz> Do any other h264/mp4 tools come to mind that can both seek and print IDR frames?
[19:08:45 CET] <JEEB> but yeah, that sounds like something you could make an issue about if you know that only IDR pictures are supposed to be seekable in that file
[19:09:12 CET] <JEEB> not IDR, but l-smash's boxdumper can print mov-style container's contents out
[19:09:23 CET] <JEEB> that includes seekable points
[19:09:38 CET] <JEEB> sync samples they were called, I think
[19:10:37 CET] <votz> Wait. Backing up. Maybe I misunderstood you before. Are non-IDR, seekable keyframes safe to stream copy from? Safe in the sense that P-frames that come after the seekable, non-IDR keyframe will *not* reference frames before said seekable, non-IDR keyframe?
[19:11:10 CET] <votz> Because, thinking about it, if that was the case -- and a frame after a seekable keyframe can reference frames before the seekable keyframe -- that frame would be broken after seeking
[19:11:43 CET] <JEEB> non-IDR intra pictures only mean that you have an intra picture. if you have a recovery point SEI there as well then it's an open gop stream and you can seek to it
[19:12:36 CET] <JEEB> personally if your input is in mp4 I would take a look at how it looks in boxdumper
[19:12:57 CET] <JEEB> what pictures are noted as sync samples
[19:14:53 CET] <votz> Right. but ffprobe differentiates between I-frames and key_frames
[19:15:19 CET] <votz> When ffprobe reports a key_frame, is it safe to stream copy from that frame? Or can frames stream copied after that key_frame be corrupted b/c they reference a frame before the key_frame?
[19:15:41 CET] <JEEB> that depends on completely how that flag is used
[19:16:25 CET] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264.c#L1543
[19:16:51 CET] <JEEB> also https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264.c#L1722
[19:18:12 CET] <votz> So that answers it. Every key_frame (as reported by ffprobe) should be safe to stream copy from.
[19:18:58 CET] <JEEB> according to those points, yes. but if you think you have too many points marked like that?
[19:19:23 CET] <votz> Not sure. But it's strange that ffprobe and avconv 11.4 report different IDR frames.
[19:19:57 CET] <votz> One explanation is that ffprobe reports SEI related key_frames, while avprobe does not (only reporting true IDR frames).
[19:20:01 CET] <votz> That would explain the difference
[19:20:04 CET] <JEEB> sure
[19:20:18 CET] <votz> s/avconv 11.4/avprobe 11.4/
[19:20:22 CET] <JEEB> I would be surprised if you would see such in normal mp4 files tho
[19:20:31 CET] <JEEB> you don't usually see open gop content
[19:20:44 CET] <JEEB> not to mention a mix of IDR and open gop random access points
[19:20:58 CET] <JEEB> are the samples something you can share?
[19:21:53 CET] <votz> Yes, but later. I have to run in 5 minutes.
[19:22:01 CET] <JEEB> ok
[19:22:38 CET] <votz> I'll try to catch you later in here or #libav.
[19:23:48 CET] <votz> For now, thank you for your time, help and input.
[19:24:38 CET] <votz> I'm going to play around with subtrack copying to mp4 instead of mpegts and seeking with avprobe.
[19:24:48 CET] <votz> The former might solve the -copyts problem.
[19:25:28 CET] <votz> And/or all keyframes marked as such by ffprobe may indeed be safe to be stream copied, even if avprobe 11.4 only reports a subset of the ones ffprobe reports as key frames.
[19:25:52 CET] <votz> Anyhow, thank you again for your time and help. I'll catch you here or in #libav later.
[19:43:38 CET] <ac_slater> Hey all. Has anyone got a clue why MPEGTS with (only) AVC would pause for ~30ms every second? I'm permuting some mpegts options like muxrate, etc, but I havent been able to fix it. Clues? I've tried a bunch of input sources, v4l2, lavfi testsrc, rawvideo, etc. My encoder is x264 baseline.
[19:56:23 CET] <ac_slater> players include vlc, mpv, and ffplay
[22:33:53 CET] <___dewey> Hi all, I want to save a AVSubtitleType SUBTITLE_BITMAP to disk but I cant find out how to properly do that with the AVSubtitleRects that Im receiving.
[22:34:28 CET] <___dewey> does any of you know of a good tutorial/example which I could learn from?
[22:57:19 CET] <nathdwek> Hi there I have a small question regarding versioning
[22:58:51 CET] <nathdwek> I get libav*56 on F23; but to build another tool, I need libav*54. This isn't too big of an issue, the only thing is I can't figure how git tags/branches are linked to the shared objects numbering.
[22:59:02 CET] <JEEB> they aren't :)
[22:59:35 CET] <JEEB> I recommend you take a look at the history of the file defining the API version
[22:59:49 CET] <JEEB> and take the last revision with the API version you require
[22:59:50 CET] <nathdwek> Ok so if I compile from source, how can I make sure I build the 54 ones and not the 56 ones?
[23:00:09 CET] <nathdwek> Ok thanks (sorry didn't read your first answer)
[23:00:39 CET] <JEEB> also a lot of the libraries don't actually share the version
[23:00:47 CET] <nathdwek> It would be awesome if you had a quick link for me
[23:02:41 CET] <Mavrik> I think JEEB is friendly enough to just do the compile for you ;)
[23:02:58 CET] <nathdwek> O I got it it's pretty well documented in doc/apichanges
[23:03:32 CET] <nathdwek> great, thanks. By curiosity, any reason for this weird way of doing things? Why not semver?
[23:03:43 CET] <JEEB> it is semver
[23:03:57 CET] <JEEB> there's a major, minor and micro version for each library
[23:04:24 CET] <JEEB> and major is used in the file name
[23:04:29 CET] <nathdwek> yeah I meant for the tagging
[23:04:45 CET] <JEEB> because every library has its own versioning?
[23:04:57 CET] <JEEB> which aren't matched because a change in X doesn't mean Y has changed
[23:04:58 CET] <nathdwek> I'll see myself out
[23:05:13 CET] <nathdwek> Thanks a lot
[23:05:17 CET] <JEEB> basically releases just mean a branched out version
[23:05:21 CET] <JEEB> at point X
[23:06:13 CET] <JEEB> if it was a single library it'd probably have a single versioning :P
[23:06:56 CET] <nathdwek> Yeah actually if you see it as a suite of stuff it kinda make sense
[23:07:31 CET] <nathdwek> We should just ticket git to enable...let's call it submodule-tree-tagging.js
[23:11:33 CET] <JEEB> and yeah, it's a collection of eight things right now as far as I can see. some really young (libswresample, libavresample) and some older like libavcodec/-format
[23:23:11 CET] <Phr33d0m> hi, is there any current work (or experimental patch) on nvresize? I've found a patch provided by nvidia but it's obsolete by now and it's huge for me to adapt it...
[00:00:00 CET] --- Sun Feb  7 2016