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

burek burek021 at gmail.com
Tue Jun 11 03:05:01 EEST 2019


[02:36:16 CEST] <nicolas17> can ffmpeg read a playlist that is just a list of filenames? or should I turn it into a proper concat script?
[02:43:36 CEST] <relaxed> nicolas17: https://webcache.googleusercontent.com/search?q=cache:KnDHyY6VAY4J:https://trac.ffmpeg.org/wiki/Concatenate+&cd=1&hl=en&ct=clnk&gl=us&client=firefox-b-1-d
[07:42:37 CEST] <PhantomOfNyx> Is there a way to prevent the bitrate spiking at all I've set both an vbv-bufsize vbv-maxrate and a rateol=1.0 and it still spikes happily to 12k bitrate under high activity
[07:42:49 CEST] <PhantomOfNyx> with me trying to limit it to 7k
[08:00:51 CEST] <PhantomOfNyx> Is there a way to prevent the bitrate spiking at all I've set both an vbv-bufsize vbv-maxrate and a rateol=1.0 and it still spikes happily to 12k bitrate under high activity I'm trying to limit the max cap to 7k under spikes but not having much luck
[18:07:01 CEST] <cousin_luigi> Greetings.
[18:07:45 CEST] <cousin_luigi> I have a 6 channel AC3 track and I would like to downmix it to 2 channels, but keep the AC3 format. How would you recommend I do that?
[18:08:58 CEST] <kepstin> cousin_luigi: use "-ac 2 -c:a ac3 -b:a 192K" in your output options (adjust bitrate to taste)
[18:09:27 CEST] <cousin_luigi> kepstin: I would like to keep it as the original, do I have to specify it?
[18:09:50 CEST] <kepstin> "keep as original" makes no sense when you're re-encoding and changing the number of channels
[18:10:33 CEST] <kepstin> like, most 5.1 ac3 content on dvds is something like 384kbit/s iirc? with fewer channels you don't need nearly that much.
[18:11:21 CEST] <kepstin> if you don't specify it, it'll use some default value, it won't attempt to keep anything from the source file.
[18:13:21 CEST] <cousin_luigi> kepstin: Right, thanks.
[18:21:28 CEST] <cousin_luigi> kepstin: It worked!
[18:21:29 CEST] <cousin_luigi> bbl
[19:22:43 CEST] <electrotoscope> I'm trying to add more information to the documentation for the "metadata" function in drawtext at https://ffmpeg.org/ffmpeg-filters.html#toc-Text-expansion
[19:22:48 CEST] <electrotoscope> I was confused, thinking all of the information that ffmpeg -show_frames can access would be available as "metadata", and from googling the problem for a few days and reading a bunch of blog posts and stack overflow threads I know I'm not the only one.
[19:22:52 CEST] <electrotoscope> Eventually I found out that "metadata" in this context means the lines shown in ffprobe [FRAME] data with "TAG:" in front of it.
[19:22:56 CEST] <electrotoscope> I wanted to write: The metadata accessible to this function must show up using @code{ffprobe -show_packets} formatted as TAG:[metadata_key]=[metadata_value].
[19:23:00 CEST] <electrotoscope> But someone commenting on https://trac.ffmpeg.org/ticket/7947 obviously didn't understand what I meant so it needs improvement
[19:23:12 CEST] <electrotoscope> What if I wrote something like: If what you're trying to read from a file doesn't show up with @code{ffprobe -show_frames} formatted as TAG:[metadata_key]=[metadata_value] then it won't be visible to this option.
[19:23:39 CEST] <electrotoscope> (i switched show_packets to show_frames since I think that's actually closer to the truth)
[19:30:29 CEST] <durandal_1707> electrotoscope: stuff you want to be TAG is simply not metadata
[19:32:26 CEST] <kepstin> electrotoscope: when you write it like that it sounds like you have causality backwards. It's just that in the default ffprobe output format, that's how it formats metadata.
[19:32:49 CEST] <electrotoscope> hmm
[19:33:28 CEST] <electrotoscope> Most frame data is not visible to this option. "metadata" in the context of this option refers to data that is visible to ffprobe etc etc
[19:33:31 CEST] <electrotoscope> is that better?
[19:33:48 CEST] <kepstin> no, because lots of the stuff visible in ffprobe is not metadata
[19:34:26 CEST] <electrotoscope> apologies
[19:34:27 CEST] <electrotoscope> Most frame data is not visible to this option. "metadata" in the context of this option refers to data that is visible to @code{ffprobe -show_frames} formatted as TAG:[metadata_key]=[metadata_value]
[19:34:29 CEST] <kepstin> the use of the word 'metadata' is pretty consistent in ffmpeg, refering to extra data, often user-provided, that's stored in the container alongside the actual stream
[19:35:05 CEST] <electrotoscope> yes but unfortunately it's not well documented, which is what I'm trying to improve. metadata outside of ffmpeg refers to data about data
[19:35:10 CEST] <durandal_1707> he is talking about frame metadata, and not sream metadata
[19:35:25 CEST] <durandal_1707> *stream
[19:35:37 CEST] <electrotoscope> @durandal_1707: to the best of my knowledge, stream metadata is not visible to drawtext
[19:35:48 CEST] <electrotoscope> or accessible to drawtext or exposed to drawtext or whatever the appropriate term is
[19:36:05 CEST] <durandal_1707> correct
[19:36:39 CEST] <Compusomnia> Why does the normalize video filter crop my video from 16:9 to 4:3, and how can I make it not do that?
[19:37:47 CEST] <furq> Compusomnia: paste the full command and output
[19:38:29 CEST] <electrotoscope> kepstin: Should I maybe write it as "The use of the term metadata in ffmpeg refers to extra data, often user-provided or generated live during decode by other filters, that's stored in the container alongside the actual stream"?
[19:38:30 CEST] <Compusomnia> To where? The pastebin link doesn't work for me.
[19:38:43 CEST] <kepstin> Compusomnia: use a different pastebin then
[19:39:42 CEST] <kepstin> we don't care where you paste it, as long as it's not in the chat.
[19:43:58 CEST] <Compusomnia> https://pastebin.com/3T2WbfAG
[19:44:55 CEST] <kepstin> hmm. is frame metadata used for /anything/ other than passing info between filters in libavfilter?
[19:46:09 CEST] <furq> some filters will log it
[19:46:17 CEST] <furq> idet for one
[19:46:25 CEST] <electrotoscope> you can write it out of a filter into a txt file
[19:46:40 CEST] <electrotoscope> or you can insert it into a concat list with file_packet_metadata key=value
[19:47:43 CEST] <furq> Compusomnia: the output is the same resolution and apparently the same sar/dar as the input
[19:47:50 CEST] <electrotoscope> and theoretically some camera somewhere might record it into the frame information and it would look like https://stackoverflow.com/a/34345153/1747979
[19:47:50 CEST] <furq> how does it appear to be cropped
[19:48:27 CEST] <electrotoscope> kepstin: perhaps I should just write "if you think you can read something from the file with this you're probably wrong"
[19:49:19 CEST] <Compusomnia> Yes, the actual video size stays untouched, but only the left 4:3 part of the video has any data. The right part is black.
[19:50:30 CEST] <electrotoscope> Compusomnia: perhaps reading the input file and output file in MediaInfo would shed some light on it?
[19:51:24 CEST] <furq> i don't think that would give you any information that the above paste wouldn't
[19:51:34 CEST] <furq> that sounds broken to me but then i've never used normalize
[19:53:24 CEST] <kepstin> hmm. i wonder if the filter has a bug in its handling of rgb24 vs. rgb0 and similar formats
[19:53:32 CEST] <kepstin> that would account for working on only 3/4 of the frame
[19:54:18 CEST] <kepstin> Compusomnia: can you re-run that with -v verbose -vframes 1 so I can see the fitler chain setup (including inserted scale filters)?
[19:57:58 CEST] <kepstin> it looks like the normalize filter is stepping horizontally by num_components bytes per pixel, but stuff like rgb0 has 3 components in 4 bytes, so it's using the wrong step value.
[19:58:28 CEST] <furq> that'd do it
[19:58:37 CEST] <Compusomnia> verbose output: https://pastebin.com/WWH6xHUf
[19:58:52 CEST] <kepstin> yep, bgr0
[19:58:54 CEST] <furq> Compusomnia: if you just want to work around it then -vf format=rgb24,normalize,format=yuv420p should work
[20:00:22 CEST] <kepstin> filter shouldn't be hard to fix, it just has to save the step value out of the AVComponentDescriptor and use that when incrementing over pixels.
[20:02:50 CEST] <Compusomnia> Your filter chain did in fact fix it, furq
[20:05:28 CEST] <Compusomnia> I guess this means I should submit a bug report?
[20:09:10 CEST] <kepstin> weird tho, i can't seem to reproduce this issue on ffmpeg 4.1
[20:10:21 CEST] Action: kepstin waits for his git ffmpeg to rebuild
[20:11:19 CEST] <furq> https://github.com/FFmpeg/FFmpeg/commit/ac551c54b13834f1ddf2b0f2196d6c8d817c4fcd#diff-3e9779fbc8739d4dc79c0646b90c5788
[20:11:22 CEST] <furq> that's the only commit since 2017
[20:11:30 CEST] <furq> that doesn't really seem like the culprit
[20:11:51 CEST] <kepstin> i wonder if something changed in ffmpeg's representation of pixel formats recently
[20:13:49 CEST] <eschie> I'm trying to create HLS files but having issues where the audio drops out after seeking.  Apple's 'mediastreamvalidator' errors saying "Different target durations detected" for the audio and video streams.  How to fix?
[20:16:36 CEST] <kepstin> like, i'd expect `ffmpeg -v verbose -f lavfi -i testsrc -vf format=bgr0,normalize -vframes 10 out.mkv` to show this issue, but it doesn't? v. strange.
[20:17:52 CEST] <Compusomnia> The pixel format straight out of my webcam is bgr24, if that makes any difference.
[20:19:03 CEST] <furq> ffv1 is always bgr0 internally iirc
[20:19:46 CEST] <furq> for rgb, i mean
[20:21:24 CEST] <furq> kepstin: i can reproduce it here on 4.1.3 by going via ffv1
[20:21:49 CEST] <kepstin> must be some quirk relating to buffer re-use then, i guess
[20:22:57 CEST] <furq> https://i.imgur.com/riBOM8j.png
[20:23:08 CEST] <furq> $ ffmpeg -f lavfi -i testsrc=d=1 -c:v ffv1 -f nut - | ffmpeg -y -i - -vf normalize -frames:v 1 out.png
[20:25:05 CEST] <kepstin> my guess is that you only see the black in the case where the frames given to the normalize filter are not writable, and so have to be copied.
[20:25:22 CEST] <kepstin> if the frames are writable you'll see the whole image, but only the left 3/4 will actually have been processed
[20:44:09 CEST] <exonintrendo> Ok, not sure if this is a realistic goal, but I want to build a basic video player that will let me view videos in my family's home video gallery. The videos are various formats from .mp4 and .mov depending on the device recording them. I want to be able to have ffmpeg transcode / create HLS files on demand when someone clicks on the video to view rather than creating the HLS files ahead of time to save space
[20:44:11 CEST] <exonintrendo> But I also want the user to be able to load up the video and have it start playing if they say scrub half way through (start transcoding / creating the HLS files from a given point in the video). Is this reasonably possible?
[20:45:47 CEST] <furq> exonintrendo: why use hls at all instead of just serving the mp4s
[20:53:18 CEST] <kepstin> well, you still need to do something about any video files that browsers can't play directly.
[20:53:34 CEST] <exonintrendo> furq i was just thinking of a good way to transcode for bandwidth purposes as i want playback to be fluid regardless if you're on LAN or not
[20:53:37 CEST] <kepstin> exonintrendo: honestly, i'd just go with "disk space is cheap, just pre-transcode everything"
[22:01:37 CEST] <lavaflow> I have two video files and I want to copy the audio tracks from the second into the first, keeping all audio and video tracks the first has
[22:02:01 CEST] <lavaflow> I'm trying: ffmpeg -i one.mp4 -i two.mp4 -map 0 -map 1:1 -c copy out.mp4
[22:02:49 CEST] <lavaflow> but that says: Argument two.mp4 provided as input filename, but one.mp4 was already specified
[22:03:07 CEST] <lavaflow> pretty sure I'm using -map wrong, can anybody help me out here?
[22:04:39 CEST] <lavaflow> ah crap I'm an idiot, nevermind
[22:04:49 CEST] <kepstin> lavaflow:i'm not sure what's up, that command shouldn't make that message. please pastebin the command and complete terminal output as you ran it.
[22:05:14 CEST] <lavaflow> kepstin: I was accidentally invoking ffprobe not ffmpeg, because I'm dumb
[22:05:22 CEST] <lavaflow> it's working now
[22:07:21 CEST] <kepstin> note that if you don't want to bother looking up exact stream indexes, "-map 1:a:0" would select the first audio track from the second input.
[22:10:16 CEST] <lavaflow> ah nice, thank you
[23:55:30 CEST] <brimestone> Anyone know where I can download an FFmpeg build for macOS 10.8.5
[23:56:18 CEST] <MoziM> kepstin: thanks! didn't know that, sorry for late response
[23:57:21 CEST] <MoziM> kepstin: i've already made the video and now i'm wondering if there's a way for ffmpeg to add an audio delay of 1400 ms to compensate... or am i better off just running the ffmpeg command to merge audio and video again using the native fps of 23.97?
[23:57:42 CEST] <kepstin> MoziM: i don't remember the context for this
[23:58:02 CEST] <MoziM> sorry one moment
[00:00:00 CEST] --- Tue Jun 11 2019


More information about the Ffmpeg-devel-irc mailing list