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

Fri Dec 6 03:05:03 EET 2019

[14:54:06 CET] <ButtDog> Anyone know any solutions for getting media info similar to ffprobe, in a webbrowser? I've tried mediainfo.js but with no luck.
[16:25:31 CET] <ncouloute> I'm getting "h264_mp4toannexb filter failed to receive output packet" when trying to concat some clips together using the concat demuxer. It used to work on very old version of ffmpeg. (N-51511-g599866f from 2013)
[16:33:58 CET] <kepstin> (preferrably from both ffmpeg versions so we can compare)
[16:34:19 CET] <ncouloute> okay
[17:03:36 CET] <ncouloute> FFMPEG 2013 N-51511-g599866f output: https://paste.ee/p/MMuIF FFmpeg 4.2.1 output: https://paste.ee/p/wgXWp Wouldnt let me use pastebin too long. Have to purchase pro. Pastie seems like the site is dead.
[17:08:54 CET] <BtbN> looks like what you're trying to concat is either invalid or broken.
[17:08:56 CET] <kepstin> ncouloute: hmm, looks like one of your input files in the playlist has no video frames
[17:09:10 CET] <BtbN> *incompatible
[17:10:02 CET] <kepstin> anyways, the old version of ffmpeg skipped it, that's probably what the "[h264 @ 007b2e20] no picture " message is from
[17:10:10 CET] <kepstin> but the new version gives an error
[17:10:20 CET] <kepstin> the old version probably predates the auto-inserted bsfs
[17:28:36 CET] <ncouloute> Thing is the actual file has both video clips in it on the older version
[17:31:12 CET] <ncouloute> So it may report no video. it is actually still stitching it together with the old version. New version just has the first clip in the MP4
[17:33:33 CET] <ncouloute> You can tell that by the frame= line at the end and the time=. An I actually can see the file
[17:41:39 CET] <kepstin> ncouloute: does running "ffmpeg -i <whatever> -c copy something.mp4" work when run individually on each input file?
[17:46:11 CET] <ncouloute> nope
[17:46:51 CET] <ncouloute> I will most likely have to reenode each? I though the demuxer was doing that. I guess it stitches it together and then decodes after if not copying
[17:48:58 CET] <kepstin> ncouloute: that's strange. what's the output of the failed ffmpe on the individual input file?
[17:49:16 CET] <kepstin> like, frmp mp4 source to mp4 dest, that should always work with -c copy
[17:49:29 CET] <kepstin> unless the source file is busted somehow
[17:50:15 CET] <kepstin> but yes, the concat demuxer does not decode (it's a demuxer not a decoder). It concatenates the still-encoded video streams then sends the combined result to a decoder
[17:50:37 CET] <kepstin> (which is why it can't work if the videos have different codecs, or sometimes even different settings in the same codec)
[17:50:43 CET] <ncouloute> So there is no error on the actual copy command. When I try to concat I get the same error.
[17:51:45 CET] <kepstin> and both of these video files are from the same camera?
[17:54:19 CET] <ncouloute> yes a DJIN drone camera
[17:54:59 CET] <kepstin> I'd really expect the concat demuxer to work on that, it's very strange. does it break if you switch the order of the two files?
[17:55:05 CET] <ncouloute> One of their Mavik cameras.. Dont know the exact model.. Interesting thing is smoe of the clips work others dont
[17:55:17 CET] <ncouloute> let me try that
[17:56:23 CET] <ncouloute> Still errors out when switching the order.
[17:56:34 CET] <void09> I need to join several mp4 files into one mkv, while generating a chapter for each of them. any way to have ffmpeg handle the time intervals but provide chapter title info from outside ?
[17:57:10 CET] <kepstin> ncouloute: hmm. probably not gonna get further with debugging unless you can provide some sample files (probably open a ticket on trac). Someone familiar with h264 bitstreams will have to take a look.
[17:57:26 CET] <kepstin> ncouloute: also test with latest git build instead of the 4.2.1 release first, just in case
[17:57:54 CET] <kepstin> possible this is a bug that's already been fixed :)
[17:59:39 CET] <kepstin> void09: i don't know of any way to have ffmpeg automatically generate chapter metadata on file boundaries when concatenating.
[18:00:07 CET] <void09> so i must generate it myself..
[18:00:25 CET] <ncouloute> I was about to say. if that existed I would love that.
[18:00:29 CET] <void09> get times with mediainfo, in miliseconds.. add them up.. blah
[18:00:49 CET] <ncouloute> I know the mkv tools set can do that
[18:01:12 CET] <JEEB> the problem is that concatenation can be done on N levels in FFmpeg :P because nobody wanted to do it in ffmpeg.c
[18:01:22 CET] <JEEB> so you have the concat protocol, demuxer and filter
[18:01:38 CET] <JEEB> the only thing that can create chapters is the demuxer
[18:02:03 CET] <JEEB> now, if ffmpeg.c did concatenation
[18:02:18 CET] <JEEB> and knew where the files switched, then it could do it too
[18:02:19 CET] <JEEB> :P
[18:03:47 CET] <kepstin> honestly, adding it to the concat demuxer would be nice
[18:04:02 CET] <kepstin> could even add some new stuff to the playlist format for chapter metadata to set names and stuff
[18:04:49 CET] <JEEB> apparently someone already wanted some of that stuff, since there's segment_time_metadata
[18:04:59 CET] <JEEB> which apparently adds metadata to the side data of the read AVPacket
[18:05:20 CET] <JEEB> so you get the start time and duration of the segment
[18:05:30 CET] <JEEB> (and that this is the packet where that begins)
[18:06:03 CET] <JEEB> also I'm not 100% sure how the chapter stuff worked in FFmpeg
[18:06:25 CET] <JEEB> you'd in theory have to update it as you hit EOF with each segment you're concatenating
[18:07:07 CET] <ncouloute> You can get that info with ffmpeg.c ? The way I get the start and stop times is by reading the debug log....which is not the best
[18:07:33 CET] <JEEB> ffmpeg.c gets that info, but it is most likely not utilized for anything
[18:08:35 CET] <JEEB> http://up-cat.net/p/6e84a652
[18:08:37 CET] <JEEB> only references
[18:08:52 CET] <JEEB> apparently there's a filter that utilizes the value
[18:09:34 CET] <JEEB> thos values are available just fine to API clients, of which ffmpeg.c is one
[18:09:39 CET] <ncouloute> yeah the segment filter or flag? I remember using that to create clips that are 1 gop each. thinking that would fix another isuse lol
[18:10:49 CET] <JEEB> select filter is what does something with that stuff :P
[18:10:59 CET] <JEEB> didn't check the context so no idea how exactly
[18:11:28 CET] <kepstin> hmm. chapters only exist at the format context level, and it looks like code would expect them not to change after the file is open, so if the concat demuxer was gonna do chapters it would either need durations set in the playlist file, or it have to open all the files at the start, and they'd have to all have defined lengths.
[18:12:41 CET] <ncouloute> One of the issues with parsing the debug log. Is the debug log info is not giving me the right PTS info when using the fps filter with the concat demuxer. It will say "Read frame with in pts 93263, out pts 9317" if you dont use the concat filter it gives the right out pts so I'm thinking it cant calculate the PTS across multiple files? Its giving me some sort of offset or frame count?
[18:13:51 CET] <kepstin> ncouloute: the out pts on the fps filter is the pts after framerate conversion, i'm not sure what you're asking about
[18:14:38 CET] <kepstin> I'm not sure how pts works with the concat demuxer, I'd expect it to offset the second file so the pts continues after the end of the first file.
[18:15:17 CET] <ncouloute> sorry its not the fps filter
[18:15:36 CET] <ncouloute> well idk what it is tbh it says [Parsed_fps_0 @ 06876540]
[18:15:40 CET] <kepstin> that demux output you pasted is the fps filter
[18:15:45 CET] <kepstin> debug output*
[18:16:05 CET] <kepstin> but i dunno why you have that or what you're doing, since you pasted neither the command line nor the complete output of ffmpeg.
[18:16:32 CET] <ncouloute> gotcha... I'll get on that
[18:16:51 CET] <kepstin> the "out pts" in the fps filter debug output is the pts that the frame will have in the output file (modulo any additional conversion to container timebase done during muxing)
[18:17:14 CET] <kepstin> the "in pts" is the pts the frame had when it was sent to the fps filter's input
[18:17:22 CET] <kepstin> note that they are very likely to be in different timebases
[18:19:16 CET] <kepstin> (fps filter always sets the output timebase to the inverse of the framerate it's converting to, so output pts values will always go up by 1 each frame)
[18:22:13 CET] <ncouloute> I didnt know that. That is why I have the 1 frame offset. Interesting
[18:24:33 CET] <kepstin> note that if you're using an old ffmpeg version, you should always make sure to convert to constant fps *before* the concat filter, since the concat filter was only recently fixed to work correctly if the inputs have different framerates
[18:25:59 CET] <kepstin> old being, uh, anything but git master, I don't think that fix has made it to a release yet.
[18:26:02 CET] <kepstin> should be in 4.3
[18:27:40 CET] <kepstin> (if the first input is detected as vfr, the concat filter was ok, it's only an issue if the first input was cfr)
[18:28:07 CET] <ncouloute> that will be useful for me.
[18:35:16 CET] <ncouloute> Here is the full command with output: https://paste.ee/p/DjHxM
[18:54:23 CET] <Aison> Hello :-) I just detected this: https://scottlinux.com/2016/09/17/video-stabilization-using-vidstab-and-ffmpeg-on-linux/
[18:54:25 CET] <Aison> vidstab
[18:55:23 CET] <Aison> Is it somehow possible to keep the "main object" in the center of the video?
[18:58:18 CET] <ncouloute> All I care about is the output files PTS. So I just need to know what the fps filters out pts time base would be. If I set it to 60000/1001 fps. I would think I could just divide it by 1001 and get the PTS_TIME. Although that math doesnt check out. Its closer to the concat PTS value after the -> but moved around a few frames
[19:03:06 CET] <kepstin> ncouloute: the fps filter resets the output pts to start at 0 by default
[19:03:56 CET] <kepstin> other than that, it's a straightforwards conversion of input pts to output timebase, with configurable rounding behaviour
[19:05:23 CET] <kepstin> if multiple input frames map to the same output pts, the last frame is output. if an input frame is duplicated, the duplicates will fill the timestamps up until the next frame appears.
[19:06:30 CET] <kepstin> hmm actually, i might be wrong about it resetting pts to start at 0
[19:06:44 CET] <kepstin> in this case your input pts started at 0, so the output pts did as well
[19:08:43 CET] <kepstin> ncouloute: if you set fps=60000/1001, then the output timebase is 1001/60000. But note that the fps filter's output timebase/pts is not necessarily the timebase/pts used in the output file, since many formats cannot save arbitrary timebases
[19:09:07 CET] <kepstin> so an extra conversion is often done during the muxing step to a timebase that the output container supports
[19:10:59 CET] <ncouloute> I think learning ffmpeg api might be easier. I really just need the start and stops times... I convert to cfr. It's going to be harder to walk through this log and figure out whats duplicated and whats dropped. For the most part I've been fine just using the data after the concat -> but if fps filter has to duplicate a frame then it gets off
[19:13:39 CET] <kepstin> hmm? it's pretty straightforwards. you just have to follow the pts through the concat then through the fps
[19:13:46 CET] <kepstin> e.g. [concat @ 06c65ac0] file:1 stream:1 pts:3643 pts_time:6.07167 dts:3602 dts_time:6.00333 -> pts:8567 pts_time:14.2783 dts:8526 dts_time:14.21
[19:13:51 CET] <kepstin> then [Parsed_fps_0 @ 0784a1c0] Read frame with in pts 8567, out pts 856
[19:14:39 CET] <kepstin> although that still doesn't account for any conversions done during muxing step.
[19:18:28 CET] <ncouloute> There shouldnt be any of that if I have -muxpreload 0 -muxdelay 0 ? I'm muxing to a MP4 AVC/AAC
[19:18:58 CET] <kepstin> i'm not familiar with exactly what timebases mp4 container supports.
[19:19:15 CET] <ncouloute> The "Writing frame with pts 20 to pts 21" line should account for any duplication correct?
[19:19:24 CET] <ncouloute> nope it doesnt
[19:19:38 CET] <ncouloute> well idk actually the  dupicated frame line shows up after
[19:19:46 CET] <kepstin> duplicates fill the space after each frame until the next frame
[19:20:29 CET] <kepstin> so if you have a frame with "out pts 856" then another with "out pts 858", then you know that the space inbetween, 857, is a duplicate of the previous frame.
[19:21:24 CET] <kepstin> and you'll also have a line "Writing frame with pts 856 to pts 857" in that case.
[19:22:09 CET] <kepstin> (note that debug output is not a stable api, and can be changed at any time, so if your parse breaks on updates, well, too bad)
[19:22:52 CET] <kepstin> the current debug output of the fps filter is just what I happened to find useful for debugging the fps filter itself when i rewrote it a while ago :)
[19:27:49 CET] <ncouloute> Yeah so that math checks out. I guess I had the wrong timebase initially. These calculation should account for the go up 1 frame you were talking about before? (fps filter always sets the output timebase to the inverse of the framerate it's converting to, so output pts values will always go up by 1 each frame)
[19:41:03 CET] <kepstin> (the reason the duplicates are done like that is because of how video playback works - a frame is displayed starting at its pts value, and is then held until the next frame is displayed or the file ends)
[19:49:27 CET] <ncouloute> Regarding the "h264_mp4toannexb filter failed to receive output packet" issues. I should submit a bug ticket for that with the video in question.
[21:19:24 CET] <ncouloute> I had to move location. Should I submit a bug for that "h264_mp4toannexb filter failed to receive output packet" issue. I was hoping more info would be in the log =/
[21:35:19 CET] <BtbN> It's not a bug, it just means your input is broken.
[22:52:30 CET] <ncouloute> Yeah, I understand that. I was hoping there was a way to correct it without having to reencode the file. It used to work on previous version of ffmpeg. I guess not it just quits on error instead of trying to do it anyways.
[00:00:00 CET] --- Fri Dec  6 2019