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

[burek]

[02:18:16 CEST] <bismusus> I'm trying to encode this multisub opera video and burn a dvdsub track into it
[02:18:56 CEST] <bismusus> I've been using -filter_complex '[0:x] [0:y:z] overlay ' letters pertaining to stream name
[02:19:55 CEST] <bismusus> instead of burning in it seems to attach a sub track with nothing but the chapter name
[02:20:14 CEST] <bismusus> did something change before the documentation could catch up?
[11:36:17 CEST] <superware> with ffmpeg libav, is it possible to mux a private data stream into an mpeg2ts stream?
[11:50:42 CEST] <bismusus> I tried adding simple srt subs to another file using -vf subtitles=foo.srt, before it was picture subs but this time it isn't anything fancy at all: subs don't appear at all on mpv and on VLC there's a sub track with the chapter name
[11:51:07 CEST] <bismusus> does it matter to the filter that I'm picking a random minute with -ss and -t?
[12:02:28 CEST] <bismusus> turns out it does
[12:11:33 CEST] <bismusus> turns out that my problem is one of many caused by putting the -ss argument before the -i
[12:43:20 CEST] <c_14> bismusus: yeah, putting -ss before -i adjusts the timestamps of the file before it does anything else. either put the -ss after (so the timestamps are adjusted after doing everything else) or add -copyts (so they aren't adjusted)
[12:45:06 CEST] <samgoody> I need libfdk_aac on Ubuntu.
[12:45:24 CEST] <samgoody> From what I gather, that means I need to compile ffmpeg on my own.
[12:45:27 CEST] <samgoody> Is that correct?
[12:45:55 CEST] <samgoody> Or is there some more benign (for a newb. Since if I compile, I will forget to ever update it) way
[12:47:24 CEST] <DHE> licensing doesn't allow redistribution. yes, you'll have to build it yourself
[12:47:42 CEST] <DHE> which means you'll also need any other 3rd party extras you want (most notably libx264) for your build
[12:47:52 CEST] <samgoody> Actually, I guess I should first ask. For conversion from MP3 to AAC, is it really important to use libfdk_aac or is the internal free encoder good enough?
[12:48:33 CEST] <DHE> the latest version (3.3) is good enough. libfdk_aac is considered superior still, but stock is now acceptable
[12:49:00 CEST] <kerio> is the difference in any way relevant at 128kbps stereo
[12:49:07 CEST] <kerio> ?
[12:49:25 CEST] <kerio> i thought it was more about HE-AAC
[12:50:21 CEST] <samgoody> I am using 54Kbs - 96Kbs if that matters
[12:50:42 CEST] <DHE> samgoody: single channel? or stereo?
[12:51:05 CEST] <DHE> at those low bitrates you might want to start considering HE-AAC like kerio mentioned. which makes libfdk_aac more important
[12:51:28 CEST] <kerio> DHE: but the builtin encoder is fine at 128kbps stereo right
[12:52:01 CEST] <samgoody> stereo. I don't really understand audio, and don't understand the real difference between HE and LC
[12:52:06 CEST] <DHE> I think so. I'd conduct listening tests to be sure if it matters
[12:52:34 CEST] <DHE> I'm just a user who uses ffmpeg. I don't know nearly as much as some people think
[12:52:50 CEST] <samgoody> I have a bunch of video files created with an apparently buggy implementation of MP3 and they dont play audio when streaming.
[12:53:09 CEST] <samgoody> The internets say to reencode them to AAC, and ffmpeg makes that really easy
[12:53:22 CEST] <kerio> oh lmao
[12:53:38 CEST] <kerio> just do 128kbps honestly
[12:53:44 CEST] <DHE> that is technically correct
[12:53:50 CEST] <kerio> also if you're fine with chrome, just use opus
[12:54:00 CEST] <kerio> i mean it's fine for everything but ios
[12:54:04 CEST] <kerio> (and macos)
[12:54:18 CEST] <samgoody> But I known nothing about audio, but the incoming audio, according to itunes is  only 54K to 96K.
[12:54:29 CEST] <samgoody> hence my assumptions.
[12:54:32 CEST] <kerio> yes but
[12:54:37 CEST] <kerio> i mean
[12:54:42 CEST] <kerio> you're transcoding
[12:55:30 CEST] <kerio> from a bad source
[12:55:38 CEST] <kerio> the last thing you want is to add more loss
[12:55:57 CEST] <kerio> samgoody: ooh have you tried remuxing them?
[12:56:02 CEST] <kerio> it might help!
[12:56:33 CEST] <kerio> ffmpeg -i foo.mp3 -c:a copy bar.mp3
[12:56:52 CEST] <kerio> should be near instant
[12:57:26 CEST] <samgoody> That just fixes the MP3?
[12:57:48 CEST] <samgoody> That would be awesome. Gee, thanks for taking time to even help no-nothings like me
[12:57:54 CEST] <kerio> it will take everything from foo.mp3, copy the audio without transcoding, and put anything that fits into a mp3 in bar.mp3
[12:57:59 CEST] <squ> kerio: it will increase size with bad quality
[12:58:00 CEST] <kerio> it'll jumble it up a bit
[12:58:30 CEST] <kerio> maybe it'll help with streaming idk
[13:01:10 CEST] <samgoody> The audio file is mp4a.40.34
[13:01:45 CEST] <samgoody> Which is not supported by FF or Chrome. So w/o understanding remuxing, will that output a better MP3 that is then understand by the browsers?
[13:01:54 CEST] <kerio> wait what
[13:01:56 CEST] <kerio> that is not mp3
[13:02:01 CEST] <kerio> samgoody: can you upload this file somewhere?
[13:02:04 CEST] <squ> m4a should be supported
[13:02:07 CEST] <kerio> or is it private/confidential/stuff
[13:02:32 CEST] <kerio> alternatively, pastebin the output of `ffprobe path/to/your/file`
[13:03:06 CEST] <samgoody> Not confidential. Happy to upload. one min
[13:04:49 CEST] <squ> > The MP4 container format with the H.264 video codec and the AAC audio codec is natively supported by desktop/mobile Internet Explorer, Safari and Chrome
[13:05:06 CEST] <kerio> i'm just gonna open the link in safari and proclaim that it's perfectly fine if it plays btw :^)
[13:05:09 CEST] <samgoody> https://pastebin.com/gp18Dnsc
[13:05:26 CEST] <squ> I can tell you Chrome plays mp4a
[13:06:10 CEST] <kerio> oh so it's a video file
[13:06:45 CEST] <kerio> i'd honestly just try ffmpeg -i path/to/foo.mp4 -c:v copy -c:a copy bar.mp4
[13:06:54 CEST] <kerio> and see if bar.mp4 plays fine in browsers
[13:07:08 CEST] <kerio> because h264/mp3 should play fine anywhere, i think
[13:07:20 CEST] <kerio> hm maybe the h264 part is causing problems?
[13:09:11 CEST] <samgoody> Firstly, you are right: here is the file and it plays in the browser - https://therapistexpress.com/dev/videoplayers/transaudio_1.mp4
[13:09:44 CEST] <samgoody> However, when I try to stream that with Wowza, audio doesn't play. And when I rencode to AAC and stream with Wowza, audio does play
[13:09:54 CEST] <samgoody> Both when using HLS and Dash
[13:10:30 CEST] <samgoody> So, some very quick research implies that the issue is with the HLS handling of that format of audio in the browsers. I found a Chromium bug report, one sec
[13:10:36 CEST] <squ> what is Wowza
[13:11:02 CEST] <squ> samgoody: it means Wowza using video container which does not support mp3
[13:11:26 CEST] <kerio> the rapist express :thinking_face:
[13:11:59 CEST] <squ> I don't see why you should bug report Chrome
[13:12:07 CEST] <kerio> ah yes, HLS does not support mp3
[13:12:20 CEST] <kerio> so yeah, convert to aac
[13:13:25 CEST] <kerio> just do -c:a aac
[13:13:40 CEST] <samgoody> That's it? I dont need a bitrate?
[13:14:29 CEST] <samgoody> ffmpeg -i input.mp4 -c:v copy -c:a libfdk_aac output.mp4
[13:14:29 CEST] <samgoody> And should I use libfdk_aac
[13:14:31 CEST] <squ> copy the parameters close to input
[13:15:10 CEST] <squ> to not reduce quality, or increase size for bad quality
[13:15:27 CEST] <samgoody> Is there a way to have it figure out the optimal bitrate (which I assume is very close to original bitrate)?
[13:15:36 CEST] <kerio> that is a VERY bold assumption
[13:15:48 CEST] <squ> can't you look it up?
[13:15:59 CEST] <kerio> samgoody: just do 128kbps aac, relaly
[13:16:01 CEST] <kerio> really
[13:16:53 CEST] <squ> samgoody: https://trac.ffmpeg.org/wiki/Encode/AAC
[13:17:09 CEST] <samgoody> I have to reencode all of my old videos, in order to stream them. That is several hundred. Would rather just run a bash script. So just using 128kbps, if it won't ruin anything by being much larger than the original, and won't bloat the size crazily (as it is for streaming) is great.
[13:17:28 CEST] <samgoody> Will read the link, thanks.
[13:17:39 CEST] <squ> just do it now
[13:19:48 CEST] <squ> several hundred 3 minute sound files take an hour to encode
[13:20:44 CEST] <kerio> make sure to use -c:v copy
[13:20:59 CEST] <squ> yes
[13:26:26 CEST] <squ> samgoody: can help you with a script
[13:27:00 CEST] <squ> I've done it to copy source to destination with path/subpath structure
[13:28:18 CEST] <kerio> samgoody: why can't you just convert it to HLS with ffmpeg?
[13:28:46 CEST] <samgoody> would appreciate help with a script, but figured I should at least try on my own.
[13:29:20 CEST] <samgoody> kerio, what do you mean? HLS is just a streaming container format, that can take mpeg-2 or mp4, or at least that is how I undertsand it
[13:29:38 CEST] <kerio> yeah but ultimately it's a bunch of .ts and a .m3u8
[13:30:46 CEST] <kerio> ffmpeg can produce that
[15:22:28 CEST] <gaviriar> Hi There, I am curious about wether It is possible to compile FFMPEG for an ARM target on bare metal, i.e. without an OS.
[15:22:37 CEST] <BtbN> no
[15:22:55 CEST] <gaviriar> Was curious to know if this has ever been attempted, or wether it is possible?
[15:23:17 CEST] <BtbN> If you write an OS that supports everything ffmpeg needs, and has a full C toolchain, sure
[15:23:29 CEST] <BtbN> But why not use one that already exists, like, Linux?
[15:23:54 CEST] <gaviriar> well, I was thinking of using FFMPEG on a bare metal target.
[15:24:18 CEST] <BtbN> ffmpeg is not an OS
[15:25:39 CEST] <gaviriar> Sure, I am aware of that, but I was wondering if is it tightly coupled with the OS system libraries?
[15:25:50 CEST] <leif> Hey all, I am using FFmpeg's C API ot encode packets taht come out of a filtergraph. However, I am noticing that the number of audio samples is larger than the codec's framesize.
[15:26:23 CEST] <leif> Namely, i'm trying to encode aac, with a frame size of 1024 samples. All of the frames have 1024 samples, follwed by one lest than 1024, and one at 44100 samples.
[15:26:33 CEST] <leif> Has anyone seen this pattern?
[15:26:48 CEST] <leif> (Otherwise I will continue trying to make a more minimal example.)
[15:28:21 CEST] <leif> gaviriar: as far as I can tell, it is not tied to any particular os library, but it most certainly is tied to the existance of an OS library.
[15:28:40 CEST] <leif> (Although I'm new here, so I couldvery easily be wrong.)
[15:34:23 CEST] <leif> Anyway, I find it bizare that the frame size is 44100 samples, but only for the last frame...
[15:35:25 CEST] <leif> Oh, also, when I manually use an asetnsamples filter (set to 1024), the video will render, but the audio is delayed.
[15:38:43 CEST] <leif> ooh...actually, I just had an idea. Perhaps it's not the last frame, but one in the middle. (I'm using the acrosfade filter, and perhaps that doesn't set the output framesize the way I would expect it to.)
[15:39:03 CEST] <leif> Which would explain why using the asetnsamples filter would work.
[15:40:06 CEST] <leif> (Although the problem with using it is that the encoder won't know what frame size it needs until _after_ it calls avcodec_open2, but I can't call that until after I've already built the filtergraph. :/
[15:43:31 CEST] <leif> Oh derp, `av_buffersink_set_frame_size`... *facepalm* Anyway, thanks for being being my rubber ducks. :)
[15:44:32 CEST] <JEEB> :)
[15:44:39 CEST] <JEEB> always good to let it out once
[15:56:18 CEST] <DHE> gaviriar: something needs to feed it the data from whereever... network, camera, disk. I mean ffmpeg should work on DOS or something but that's still a (minimal) OS.
[16:06:51 CEST] <gaviriar> DHE: Ok thanks for the input, I guess I will have to dig into this a bit further. My guess is that the target device I plan to use has some minimal OS but ffmpeg may not support it out of the box?
[17:18:56 CEST] <kerio> gaviriar: i don't think libavcodec needs anything beyond a basic c library
[17:19:09 CEST] <kerio> however, it will also do nothing with your hardware
[17:37:59 CEST] <DHE> is open(filename, O_RDONLY) considered standard? I thought it was POSIX
[17:53:02 CEST] <roxlu> hey! I'm using the zeranoe downloads in my (win64) application. When I run my app I get a message "The procedure entry point av_dump_format could not be located in the dynamic link library". When I open my app with dependecy walker I do see av_dump_format listed. Am I doing something wrong?
[18:08:26 CEST] <roxlu> Ah.. I was linking with the .dll.a files instead of the .lib
[18:51:04 CEST] <The_8472> DHE, fopen would be C-standard. open /  O_RDONLY are posix, but windows' c library has something mimicking them. but idk if that's what ffmpeg uses
[18:58:31 CEST] <DHE> The_8472: it uses the latter. so the C library would have to be a bit better than historical ANSI-style C
[18:58:35 CEST] <DHE> but anyway...
[19:14:12 CEST] <mcgrew> I have an encoding question (I'm using the 2.6.8 api because redhat). I'm encoding a series of jpegs and raw audio into an MP4. Everything is working except that the video stream start time is non-zero (usually between 1-2 sec). I've verified that the ptd & dts of the first frame are zero, along with start_time of the AVStream. Does anyone have any other ideas where I could look to determine why this is happening?
[19:14:42 CEST] <mcgrew> pts, not ptd*
[19:22:08 CEST] <mcgrew> I'm using libx264 + libfdk_aac for the encoders in case that matters.
[19:40:58 CEST] <thebombzen> DHE: you should use fopen() anyway rather than the system call. There's a reason the standard C library exists
[19:43:33 CEST] <thebombzen> mcgrew:  libx264 and libfdk_aac have incompatible licenses, so in order to do that you need to build FFmpeg yourself and it's nonfree and unredistributable. If that's the case, is there a reason you're locked into the 2.6.8 API?
[19:44:06 CEST] <thebombzen> Specifically, libx264 is GPLed and libfdk_aac has a GPL-incompatible license.
[19:44:44 CEST] <DHE> thebombzen: normally I would agree, but ffmpeg is using open(), read() and so on rather than standard C library. so...
[19:45:11 CEST] <kerio> DHE: surely that's the ffmpeg command line tool, not ffmpeg as a whole
[19:45:37 CEST] <thebombzen> ffmpeg.c is not known for having beautiful code
[19:48:42 CEST] <DHE> kerio: libavutil/file_open.c has both methods in it, and that seems to be how the file protocol handles it
[19:50:07 CEST] <mcgrew> thebombzen: For now this isn't going to be distributed, but if that changes I'll bear it in mind. I suppose I could build against a later version of the API if that is the only solution, but that's the latest version on the Redhat version bieng used.
[19:50:12 CEST] <mcgrew> being*
[19:51:26 CEST] <mcgrew> It's much easier from a logistical standpoint to use that version if possible.
[20:56:52 CEST] <thebombzen> mcgrew: I'd recommend using the built-in AAC encoder anyway if you're going to be using the latest version of FFmpeg. At this point in git master it's actually better than fdk-aac
[20:57:23 CEST] <thebombzen> However 2.6.8 is ancient, so it's very possible that you're having issues because you're using an older version.
[20:57:46 CEST] <thebombzen> mcgrew: If you're interested in a legacy ABI, you might want to check out the 2.8 branch, which is still having major bugfixes ported today afaik.
[20:58:02 CEST] <thebombzen> Especially since if you're distributing binaries, you care more about the ABI than the API anyway.
[21:01:06 CEST] <thebombzen> mcgrew: But if the latest RHEL package is 2.6.8, that is pretty ancient. There's a good chance you're just experiencing this bug because you're using an older FFmpeg, not because you're misapplying the library.
[21:03:06 CEST] <thebombzen> for reference, RPM Fusion has the ffmpeg 2.8 branch in its RHEL7 "free" repository
[21:05:11 CEST] <thebombzen> http://download1.rpmfusion.org/free/el/updates/7/x86_64/repoview/index.html
[21:05:24 CEST] <mcgrew> thebombzen: I don't have much control over the server this will be running on, but I'll look into it. From my understanding ffmpeg is not shy about making breaking API changes, which is one of my concerns with moving to a newer version.
[21:06:03 CEST] <thebombzen> They are not super shy about it, but they do bump version numbers if they do. However, they do try a lot harder to preserve ABI compatibility
[21:06:30 CEST] <thebombzen> which means you might have extra work to keep up to date on the source-level compatibility, but the binary compatibility will be there, so your end users should not have to worry.
[21:07:08 CEST] <nicolas17> well, libavformat has changed ABI 56 times :P
[21:07:25 CEST] <thebombzen> depends on what you mean by "changed ABI
[21:07:40 CEST] <nicolas17> bumped soname
[21:07:55 CEST] <thebombzen> doesn't mean that the library is incompatible
[21:08:06 CEST] <BtbN> a soname bump means exactly that
[21:08:09 CEST] <nicolas17> that's the *whole point* of changing the soname
[21:08:27 CEST] <thebombzen> shrug
[21:08:42 CEST] <thebombzen> either way, there's a reason the 2.8 branch is still updated. git master might change a lot, but the branches shouldn't
[21:08:53 CEST] <BtbN> It's still updated so distros are happy
[21:09:10 CEST] <BtbN> Once no major distro uses 2.8 anymore, there won't be further backports
[21:09:12 CEST] <mcgrew> But to be clear the AAC encoder doesn't seem to be the issue, just that the h264 stream start is at ~1.5 sec, which throws video & audio out of sync.
[21:40:27 CEST] <thebombzen> mcgrew: yea, my comment was more that using internal AAC solves the license issue (and it's got better quality, if you are using a recent enough version)
[21:41:29 CEST] <thebombzen> As for the 1.5 second issue, I don't know. What happens if you try using libavfilter to insert a setpts=PTS-STARTPTS filter? I ask because if the issue is still occurring on the output of that filter, then it means it's probably an issue with the muxing. If this fixes it, then the issue is somewhere else.
[21:47:59 CEST] <mcgrew> I'm not sure. I'm not currently using libavfilter in any capacity and I imagine a lot of changes would be needed to use it.
[21:48:32 CEST] <DHE> for how easy that is to implement I woudln't bother with libavfilter
[21:49:50 CEST] <nicolas17> if you're using the API you don't need avfilter for that
[21:49:54 CEST] <nicolas17> just mess with the pts yourself
[21:56:28 CEST] <mcgrew> I've verified that the pts and dts of the first frame is 0. Is there another way to set the start_pts?
[21:56:49 CEST] <mcgrew> I also set AVStream::start_time to 0.
[22:06:30 CEST] <mcgrew> Also the pts & dts of the AVPacket are set to the pts of the AVFrame, which is 0 for the first frame.
[22:11:40 CEST] <DHE> you should set the pts to the AVFrame and then just use the pts/dts provided by the encoder in the AVPacket
[22:28:36 CEST] <mcgrew> That's what I was doing previously - I switched it back. Same result though.
[22:30:10 CEST] <mcgrew> Possibly related: ffprobe on my output video is reporting 23 less frames than it should have. This happens on 130 frame video and a 7k+ frame video.
[22:31:43 CEST] <mcgrew> Could this have something to do with keyframes?
[22:39:13 CEST] <mcgrew> Alright I'm giving up on this for now. I'll poke around on it more later. Thanks for the help.
[00:00:00 CEST] --- Tue Jul  4 2017