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

burek burek at teamnet.rs
Sun Jan 19 03:05:02 EET 2020


[00:08:46 CET] <fyr> hi I'm using -ss and -to with -c copy to cut segments out of footage that has multiple audio tracks, but only the first audio track gets copied into the copy
[00:08:55 CET] <fyr> how can I map the other audio tracks?
[00:12:30 CET] <pink_mist> probably by some -map invocation
[00:13:01 CET] <fyr> hn
[00:17:59 CET] <fyr> using -c:v copy -c:a:0 copy -c:a:1 copy doesn't work
[00:20:26 CET] <furq> -map 0
[00:20:28 CET] <furq> to copy all streams
[00:23:01 CET] <fyr> thanks +1
[00:23:33 CET] <fyr> i cut a load of footage up then deleted the original files without realising it hadn't copied the audio streams with -c copy
[00:23:43 CET] <fyr> kinda not expected
[01:55:15 CET] <DHE> fyr: the default behaviour is to select 1 video and 1 audio stream. I think it's intended to assist in the common case of swapping an audio stream by simply inputting a video file and then its replacement audio file
[01:55:45 CET] <fyr> interesting thanks
[06:30:44 CET] <Beam_Inn> for this command: `fmpeg -i v.mp4 -i a.wav -c:v copy -map 0:v:0 -map 1:a:0 new.mp4`, I'm trying to trim and place the audio.
[06:30:55 CET] <Beam_Inn> do I need a separate set of commands?
[06:36:41 CET] <Beam_Inn> https://superuser.com/questions/716320/ffmpeg-placing-audio-at-specific-location looking at this code, they're using multi-line code which is where it gets confusing for me.
[06:36:51 CET] <Beam_Inn> can't ffmpeg all be done on a single line?
[06:38:00 CET] <nicolas17> that is a single command
[06:38:06 CET] <nicolas17> sp:it into lines to fit in the stackoverflow reply
[07:07:01 CET] <Beam_Inn> oh.  yeah, it just doesn't seem like i can split commands on windows without getting errors.  but this command works to the purpose i was seeking
[09:15:53 CET] <void09> can anyone explain how ffmpeg handles time ranges ? I'm thinking -ss is inclusive ( "[" ) while -to is exclusive ( ")" )  ?
[11:16:58 CET] <void09> anyone know how to extract dvsub subtitles and if they can be later imported in any player ?
[11:17:05 CET] <void09> dvbvsub* (from .ts file)
[11:18:33 CET] <JEEB> what do you mean with "extract"
[11:20:47 CET] <void09> just that :)
[11:20:54 CET] <void09> extract to a file that contains just the subtitles
[11:21:16 CET] <void09> but I am not sure if they have a specialized container format for them
[11:21:31 CET] <void09> like .idx/.sub is for dvd subs
[11:21:47 CET] <JEEB> not that I know
[11:22:17 CET] <JEEB> I mean, there's a demuxer for raw dvbsub which I am not sure how well it works :P
[11:22:29 CET] <JEEB> but I bet that would derp up the timestamps rather well
[11:23:00 CET] <JEEB> since while I think the dvbsub things have their own offset timestamps, the actual PTS of the container packet is the primary thing
[11:24:07 CET] <void09> fmpeg -i "movie.mkv" -map 0:5 -vn -an -scodec copy -f rawvideo dvbsub.dat
[11:24:36 CET] <void09> found this command in a post, and it produced a 14.5MB file, seems about right. but it does not seem to be recognised by video players
[11:25:13 CET] <JEEB> not surprising, raw dvbsub doesn't even have an extension set for it
[11:25:23 CET] <JEEB> ffmpeg -f dvbsub -i blah.dat might do something
[11:25:35 CET] <JEEB> but also I wouldn't be surprised if the timings were all over the place at that point
[11:27:16 CET] <void09> it doesn't have an extension ? how did you check?
[11:27:43 CET] <void09> with  -f dvbsub: "[NULL @ 0x55a1f970b780] Requested output format 'dvbsub' is not a suitable output format"
[11:27:43 CET] <JEEB> FF_DEF_RAWSUB_DEMUXER(dvbsub, "raw dvbsub", dvbsub_probe, NULL, AV_CODEC_ID_DVB_SUBTITLE, AVFMT_GENERIC_INDEX)
[11:27:53 CET] <void09> oh, in the code, ok
[11:27:58 CET] <JEEB> yes -f dvbsub on the output side won't work
[11:27:59 CET] <JEEB> there is no muxer
[11:28:08 CET] <JEEB> as in the example I posted, it was *before* -i
[11:28:10 CET] <JEEB> so demuxing :P
[11:28:17 CET] <JEEB> since it has no extension (which is the parameter after the _probe)
[11:28:34 CET] <void09> oh i didn't see it was before -i
[11:28:58 CET] <void09> not sure how it would help, ffmpeg already detects that stream as dvbsub
[11:29:05 CET] <JEEB> also you can figure it out with -demuxer=dvbsub and compare it with -demuxer=matroska
[11:29:11 CET] <void09> so explicitly telling it it's dvbsub .. ?
[11:29:12 CET] <JEEB> it has no "common extensions"
[11:29:22 CET] <JEEB> void09: yes. the probe probably fixes it for you with the .dat file
[11:29:35 CET] <JEEB> which is a semi-controversial feature. since for various formats the probing gets... murky
[11:29:49 CET] <JEEB> of course it also means that if someone renames a .ts file to .mp4 it will usually just work :P
[11:30:18 CET] <JEEB> but due to probing you can also get random "mp3" streams because if you receive zero bytes for a probe => mp3
[11:30:32 CET] <void09> ffmpeg -f dvbsub -i "movie.mkv" -map 0:5 -vn -an -scodec copy dvbsub2.dat
[11:30:37 CET] <void09> Segmentation fault (core dumped)
[11:30:38 CET] <void09> lol
[11:30:43 CET] <JEEB> nice
[11:30:53 CET] <JEEB> you told it to read mkv as dvbsub
[11:30:59 CET] <void09> you said so :P
[11:31:10 CET] <JEEB> I meant for reading the .dat file if that was not obvious
[11:31:13 CET] <void09> oh damn, i didn't read until the end
[11:31:23 CET] <void09> second time i do that on that line lol
[11:31:30 CET] <void09> first i just read -f dvbsub
[11:31:38 CET] <furq> void09: you can mux just a dvbsub stream into mkv
[11:31:41 CET] <void09> then i did not read the actual extension
[11:31:43 CET] <furq> it works with mpv --sub-file
[11:31:53 CET] <furq> probably nothing else though
[11:32:04 CET] <JEEB> anyways, the tl;dr is taht there is no standard timestamp-keeping "subtitle format" for dvbsub
[11:32:11 CET] <JEEB> you can technically write out the packets
[11:32:13 CET] <void09> furq: so extract it raw to .dat, and mpv --sub-file sub.dat ?
[11:32:22 CET] <furq> i don't think that's what i said
[11:32:24 CET] <JEEB> and that can technically be read with lavf
[11:32:30 CET] <JEEB> but that's the end of it :P
[11:32:52 CET] <void09> furq: i already muxed it with mkvtoolnix, but i want to extract it, i don't want to keep a whole video file just for subs
[11:33:17 CET] <JEEB> then I just recommend you put it into matroska without any other stream
[11:33:18 CET] <JEEB> :P
[11:33:33 CET] <JEEB> if you really just want to keep the dvbsub stream
[11:34:02 CET] <void09> right, that works with mkvtoolnix, produces a .mks
[11:34:20 CET] <furq> i had no idea that was even an extension
[11:34:22 CET] <void09> I did not try the --sub-file route, just drag and drop, which attemps to open the file in mpv
[11:34:24 CET] <furq> good to know i guess
[11:35:18 CET] <furq> if mks is an actual thing it might be worth an mpv feature request to check if a matroska input is subtitle-only
[11:35:41 CET] <void09> YES!
[11:35:47 CET] <furq> shouldn't be too hard to detect
[11:35:53 CET] <void09> so i can drag and drop it
[11:35:57 CET] <furq> right
[11:36:03 CET] <JEEB> it's a thing that mkvtoolnix will write with subtitle-only, yes
[11:36:07 CET] <void09> cause who launches movies from command line with arguments
[11:36:50 CET] <JEEB> but obviously mks is not really utilized much because it's matroska and thus you can just mux  your streams
[11:37:24 CET] <furq> yeah i've never seen it before
[11:37:27 CET] <furq> it's an official recommendation though
[11:37:28 CET] <void09> yeah well, this is for archiving/distribution for further processing etc purposes, not for muxing
[11:37:44 CET] <furq> so you at least have something you can point to in the feature request without the devs thinking you're nuts
[11:37:50 CET] <furq> https://matroska.org/technical/specs/subtitles/index.html
[11:38:00 CET] <furq> not that the extension matters obviously
[11:39:02 CET] <void09> oh look, mpv already recognizes and uses the external .mks sub file if the video file name matches
[11:39:12 CET] <void09> and they're in the same folder, obviously
[11:39:13 CET] <furq> neat
[11:39:19 CET] <furq> drag and drop not working seems like an oversight then
[11:39:30 CET] <void09> omg drag and drop works
[11:39:43 CET] <void09> I remember it didn't.. sometime last year when i checked
[11:39:59 CET] <furq> oh damn
[11:40:05 CET] <furq> i guess the extension does matter then
[11:40:18 CET] <JEEB> yea I don't think mpv does some probing for that
[11:40:20 CET] <furq> i tried it with mkv a minute ago and it didn't work
[11:40:24 CET] <furq> but it works after renaming
[11:40:29 CET] <void09> maybe it was vlc and i remember wrongly
[11:40:41 CET] <JEEB> so it's 100% based on extensions or so I bet :P
[11:40:44 CET] <void09> vlc is indeed a little siller and stops playback trying to open the new .mks video lol
[11:40:46 CET] <JEEB> since d&d generally is opening
[11:40:47 CET] <furq> well it's obviously not based on probing
[11:40:58 CET] <furq> all i did was rename the file
[11:41:07 CET] <JEEB> yes, that is what I meant :P
[11:41:13 CET] <JEEB> I just didn't look at the code and thus "I don't think"
[11:41:42 CET] <furq> well i meant it must just be based on extensions
[11:41:54 CET] <furq> can't think of any other magic that would be happening there
[11:42:31 CET] <void09> hm there seems to be a problem though
[11:42:44 CET] <JEEB> furq: that is what I meant
[11:42:54 CET] <void09> ah nevermind, no problem
[11:42:55 CET] <JEEB> I just noted that I didn't say it was doing that because I didn't look at the code
[11:43:06 CET] <JEEB> but I was pretty sure it was just a list of extensions
[11:43:07 CET] <JEEB> :P
[11:44:05 CET] <void09> hm there seem to be no donation page for mpv
[11:48:43 CET] <void09> so conclusion, there's no dvbsub muxer in ffmpeg. luckily mkvtoolnix does the job
[11:52:28 CET] <furq> you can mux into mkv with ffmpeg
[11:55:07 CET] <void09> 14.6 MB mkv with ffmpeg vs 6.8MB mks with mkvtoolnix
[11:55:46 CET] <BtbN> sounds like you had higher quality encoder settings in ffmpeg than mkvtoolnix.
[11:55:55 CET] <BtbN> Cause the muxing-overhead is identical
[11:56:06 CET] <JEEB> or no compression of samples/extradata or whatever
[11:56:26 CET] <BtbN> to more than double the file size?
[11:56:30 CET] <BtbN> My guess is a missing -c copy
[11:56:32 CET] <JEEB> or mkvtoolnix drops packets
[11:56:47 CET] <JEEB> yea, no idea :P
[11:56:53 CET] <JEEB> and not too interested in starting to compare whatever he did
[11:57:29 CET] <void09> ffmpeg -i "movie.mkv" -map 0:5 -vn -an -scodec copy dvbsub.mkv
[11:57:48 CET] <JEEB> mkvtoolnix could just be dropping duplicated configuration packets etc
[11:57:51 CET] <JEEB> but yea, dunno
[11:58:04 CET] <void09> yeah i found mkvtoolnix to try to optimize stream size
[11:58:11 CET] <void09> like, it gets rid of h264 metadata
[11:58:24 CET] <BtbN> Well, with -vn, there is no h264 to be had
[11:58:35 CET] <void09> it was just an example.
[11:58:42 CET] <void09> I am trying to extract dvbsubs here BtbN
[12:00:49 CET] <void09> hah, mpv adds subtitles to audio files too, if they match names
[12:11:29 CET] <void09> alright. so my previous question was about time ranges handing in ffmpeg
[12:11:47 CET] <void09> <void09> can anyone explain how ffmpeg handles time ranges ? I'm thinking -ss is inclusive ( "[" ) while -to is exclusive ( ")" )  ?
[12:17:07 CET] <void09> JEEB:  ? :)
[12:20:14 CET] <void09> just to be clear, "ffmpeg -ss A -to B", and "ffmpeg -ss B -to C" should not have any overlapping frames, right ? (assuming raw video, and no keyframe hassle
[13:08:23 CET] <void09> hmm
[14:14:28 CET] <void09> hello
[14:15:28 CET] <durandal_1707> void09: please state your issue
[14:16:07 CET] <void09> durandal_1707: found a video that is seeked/cut differently by ffmpeg if given the same end timestamp but different start timestamp
[14:17:16 CET] <void09> ffmpeg -i file.mkv -ss 00:02:15.844 -to 00:02:16.845 -crf 0 short.mkv - produces correct result
[14:17:45 CET] <void09> ffmpeg -i file.mkv -ss 00:01:59.619 -to 00:02:16.845 -crf 0 long.mkv - produces a result with +1 frames at the end vs short.mkv (and thus wrong)
[14:18:14 CET] <void09> any ideas how we can get to the bottom of this?
[14:18:32 CET] <void09> or if that behaviour is to be expected in some scenarios ? video is a remux of a bluray
[14:38:30 CET] <void09> durandal_1707: can I send you the video to take a look at ?
[14:53:20 CET] <durandal_1707> only if you pay me for consulting time
[14:55:59 CET] <void09> ok, let's go to #ffmpeg-corporate-consulting
[15:13:42 CET] <void09> This page is a list of those FFmpeg developers that are available for employment or consulting. The FFmpeg project highly recommends these people to be hired by your business. All developers on this list maintain some code in FFmpeg, which serves as a testimony for their competence. By hiring one of these developers, your business can also (indirectly) support the development of FFmpeg.
[15:13:45 CET] <void09> oh you were serious, lol
[15:45:35 CET] <mosasaur> I'm trying to cut some ads from the middle of a large .mp4 video. But I've run into a few problems, first there is a trim command that seems to do the opposite of what I want: it selects single pieces of what I want to keep, instead of cutting stuff out from the middle, second, I have found no way to do this operation without re-encoding, which is slow and uneccesarily causes me headaches about how to get the same quality out as existed in the
[15:45:35 CET] <mosasaur> source file. My question is, this seeming to be a relatively common operation, is there some userscript that I can use for this, or, maybe even a standard command? Failing that, where should I start reading to understand the situation better, especially with the respect to the re-encoding, is that really necessary and unavoidable?
[16:04:40 CET] <Soni> does ffmpeg support many rates of DSD decoding?
[16:06:51 CET] <void09> mosasaur: I
[16:07:04 CET] <void09> mosasaur: I've been cutting videos for a while now, it's a bitch :(
[16:07:12 CET] <void09> did you try avidemux ?
[16:07:37 CET] <durandal_1707> Soni: yes
[16:08:12 CET] <Soni> so it can handle everything from DSD64 to DSD512?
[16:09:11 CET] <durandal_1707> Soni: yes, but note that DSD512 uses very high sample rate
[16:10:02 CET] <Soni> durandal_1707: I'm just mixing 8 DSD64 streams together in a very crappy way.
[16:11:17 CET] <mosasaur> void09: thanks. Checking that out now :)
[16:12:11 CET] <void09> mosasaur: there's programs that can cut to precise frame , by encoding the part to the nearest keyframe, but I don't know of any free one
[16:12:22 CET] <void09> videoredo is a commercial one that can do that
[16:12:53 CET] <JEEB> there was one using libav* APIs
[16:13:07 CET] <void09> JEEB: find it please ? :) i'm interested
[16:13:43 CET] <JEEB> it's been a while since I've last opened that github project
[16:13:49 CET] <JEEB> so I don't think I have it in my current history
[16:13:56 CET] <void09> search terms then ?
[16:14:46 CET] <void09> mosasaur: otherwise if you don't have keyframes exactly where the non-commercials part begins, you will have to "cut" the video using mkv chapters. not sure if mp4 supports that
[16:15:06 CET] <void09> and I never got perfect results, unfortunately
[16:15:14 CET] <mosasaur> void09: I've been playing around a bit with ffmpeg-python, if there's a way to find the nearest frame I could trim there, though I think the re-encoding requirement doesn't start with the trim command but with the concat command
[16:15:16 CET] <JEEB> mov/mp4 is where the basis of what became virtual timelines in matroska
[16:15:37 CET] <JEEB> so yes, edit lists in mov/mp4 it's even more powerful
[16:16:14 CET] <JEEB> the problem is that most things don't want to support above simple edit lists since they're not exported nicely out of lavf and the google-written support is kind of awful
[16:16:25 CET] <JEEB> mpv f.ex. just disables google's advanced edit list support
[16:16:55 CET] <JEEB> mov/mp4 is also where the whole segment linking thing came from
[16:17:06 CET] <JEEB> where you can link specific samples and all kind of insane stuff
[17:03:48 CET] <void09> so no chance in finding that github repo JEEB ?
[17:04:56 CET] <durandal_1707> JEEB is busy with real life issues right now
[17:05:17 CET] <JEEB> I decided to not use my time in trying to find it, also I might have mistaken it with the thing generating a new mp4 index with stuff
[17:08:12 CET] <JEEB> in theory making such an application just requires you to parse the currently utilized parameter sets and see if you can replicate content so that it matches that. of course means that you can't just randomly support whatever encoder, but if you keep to libx264 or so, you can write mappings
[17:08:17 CET] <JEEB> then indexing and other stuff
[17:08:28 CET] <JEEB> just requires time and interest in the problem
[17:23:33 CET] <void09> I am not really that interested in it. I am interested in lossless cuts with chapters to cut over the few frames of extra video
[18:03:30 CET] <LFSVeteran> One simple command:
[18:03:31 CET] <LFSVeteran> AVFormatContext **input_format_context;
[18:03:32 CET] <LFSVeteran> avformat_open_input(input_format_context, "http://192.168.2.12:8000/stream", NULL, NULL);
[18:03:32 CET] <LFSVeteran> exit(1);
[18:03:39 CET] <LFSVeteran> causes segmentation fault
[18:51:28 CET] <kepstin[c]> LFSVeteran: that happens when you pass uninitialized pointers to C code, yes
[18:52:02 CET] <kepstin[c]> hmm, actually, i need to double-check how exactly the open_input api is specified
[18:52:49 CET] <kepstin[c]> but I think what you want is `AVFormatContext *input_format_context = NULL; then avformat_open_input(&input_format_context, ...)`
[18:53:26 CET] <kepstin[c]> notice that your code only has a single pointer, and it's initialized
[18:53:47 CET] <kepstin[c]> and then you pass the address of your pointer to open_input, and that will update your pointer to point at a newly allocated context.
[19:14:12 CET] <LFSVeteran> *input_format_context = NULL;
[19:14:12 CET] <LFSVeteran> avformat_open_input(input_format_context, "http://192.168.2.12:8000/stream", NULL, NULL);
[19:14:12 CET] <LFSVeteran> exit(1);
[19:14:17 CET] <LFSVeteran> same result
[19:19:13 CET] <Soni> ah yes $(printf 'NAME=%q ffmpeg -i "$NAME" converted/"$NAME".flac \n' *.*)
[21:27:16 CET] <LFSVeteran> hmm
[21:27:18 CET] <LFSVeteran>         AVFormatContext *input_format_context;
[21:27:18 CET] <LFSVeteran>         input_format_context = NULL;
[21:27:20 CET] <LFSVeteran> goes well
[21:27:23 CET] <LFSVeteran> but
[21:27:33 CET] <LFSVeteran>         AVFormatContext **input_format_context;
[21:27:33 CET] <LFSVeteran>         *input_format_context = NULL;
[21:27:34 CET] <LFSVeteran> fails
[21:44:38 CET] <DHE> LFSVeteran: you haven't allocated the pointer yet, so that's expected.
[21:44:42 CET] <DHE> that's just basic C
[21:45:13 CET] <DHE> normally you would only have such a data type (AVFormatContext**) as a parameter type to a function
[21:45:56 CET] <LFSVeteran> indeed, I never used **, looks weird to me
[21:46:14 CET] <LFSVeteran> Changed the code to the first option
[21:46:32 CET] <LFSVeteran> less change for trouble
[21:47:17 CET] <LFSVeteran> now checking why avformat_open_input fails to open
[22:31:51 CET] <LFSVeteran> avformat_open_input complains about Invalid data found when processing input, the same ffmpeg does if I specify only the URL : ffmpeg  -i http://192.168.2.12:8000/stream
[22:32:05 CET] <LFSVeteran> if I specify the format to ffmpeg it goes well: ffmpeg -f s32le -i http://192.168.2.12:8000/stream
[22:32:06 CET] <JEEB> LFSVeteran: there's usually two reasons to use ** (address of a pointer to a memory address). either a) when you want to modify a *var of your calling code (you take a memory reference to where that memory location is kept) , or b) if you have a list of pointers
[22:32:51 CET] <JEEB> LFSVeteran: yea if one cannot guesstimate the format from the URL or easily probed, then you have to force the format
[22:32:56 CET] <JEEB> as in, demuxer
[22:33:26 CET] <LFSVeteran> I guess I have to use the third parameter?
[22:33:39 CET] <LFSVeteran> avformat_open_input(&input_format_context, "http://ip:port/stream", NULL, NULL) > avformat_open_input(&input_format_context, "http://ip:port/stream", fmt, NULL)
[22:34:30 CET] <LFSVeteran> how to fill fmt
[22:34:34 CET] <JEEB> I think it was one of the parameters, yes
[22:35:34 CET] <JEEB> it's an AVInputFormat that you need
[22:35:46 CET] <JEEB> https://svn.ffmpeg.org/doxygen/trunk/avformat_8h.html
[22:35:50 CET] <JEEB> ctrl+F AVInputFormat
[22:35:58 CET] <JEEB> and I bet you will find a few functions returning one for you
[22:36:09 CET] <JEEB> and one of the functions takes in that short name of the demuxer
[22:36:39 CET] <JEEB> you just check that you find that and don't get a nullptr back
[22:36:48 CET] <JEEB> and if you're OK you feed it to avformat_open_input
[22:55:24 CET] <LFSVeteran> https://pastebin.com/igv7PF8Y
[00:00:00 CET] --- Sun Jan 19 2020


More information about the Ffmpeg-devel-irc mailing list