[03:40:47 CET] <rsully> any recommendations (ffmpeg or not?) to combine a folder of mp3s into a single audio file with minimal quality loss? [03:40:55 CET] <rsully> no gap between songs or anything weird [03:45:12 CET] <furq> apparently you can do it with the concat demuxer and -c copy [03:45:33 CET] <llogan> you'll probably end up with a gap between songs if you concatenate with concat demuxer. [03:46:03 CET] <rsully> I'm looking at mp3wrap which is an interesting solution. Not sure if its a hack on the mp3 standard or not [03:46:22 CET] <rsully> but I assume concat would have problems with differing bitrates? which it sounds like mp3wrap somehow works around [03:46:53 CET] <rsully> yeah mp3wrap failed miserably [03:50:57 CET] <rsully> oh cool, bug id #1 is "does not work" https://sourceforge.net/p/mp3wrap/bugs/1/ [03:57:16 CET] <Kuukunen-> wouldn't gapless lossless concatenation be technically impossible...? [03:58:19 CET] <rsully> I'd guess so [03:58:33 CET] <rsully> but I am currently trying to compile vbrfix to see if this guide works http://lyncd.com/2011/03/lossless-combine-mp3s/ [04:06:45 CET] <rsully> surprising how undocumented this tool is [04:16:17 CET] <kepstin> gapless concatenation of mp3 files without re-encoding is unfortunately impossible [04:17:48 CET] <kepstin> since the way "gapless mp3 playback" works is to use metadata to know how many samples to throw away off the start and end after decoding [04:17:58 CET] <rsully> ah [04:18:14 CET] <rsully> what would you recommend then? lossy encode with highish bit rate to preserve detail? [04:18:28 CET] <kepstin> depends what you want to use the file for [04:18:46 CET] <kepstin> i mean, if you just need a single file that preserves all quality possible, throw it in a flac or whatever [04:19:22 CET] <rsully> i need it to put into final cut as a single audio clip [04:20:46 CET] <rsully> if it helps, all of the mp3 files are 320 CBR [04:22:15 CET] <kepstin> well, you could always just save to a wav or something that final cut can import [04:22:25 CET] <kepstin> then you only do one lossy encode on the audio during the final export [04:23:26 CET] <rsully> yeah might have to do that [04:26:03 CET] <rsully> kepstin would i need to use -f concat for that? [04:26:20 CET] <rsully> ffmpeg -f concat -i files.txt output.wav ? [04:26:42 CET] <kepstin> no, -f concat concats the streams before decoding. [04:26:47 CET] <kepstin> you need to concat them /after/ decoding [04:26:53 CET] <rsully> ah right [04:28:14 CET] <rsully> any pointer there? i've got the file names in files.txt [04:37:01 CET] <rsully> k i just converted all files to wav separately, then used -f on the wavs - should my output be fine or could i have done that better kepstin? [04:38:20 CET] <kepstin> rsully: that should work fine [04:39:05 CET] <kepstin> i probably would have output to raw audio and used >> shell redirects to concatenate the files, but that's just me ;) [04:41:44 CET] <rsully> hm what is considered raw audio? [04:41:50 CET] <rsully> isn't wav pcm? [04:42:35 CET] <kepstin> wav has a header [04:42:47 CET] <kepstin> "raw audio" is just the audio data with no headers [06:51:29 CET] <Fyr> atomnuker, Maybe you have an idea about PNS, but you obviously don't have an idea about signal processing. [06:51:51 CET] <Fyr> If you have a signal, then transform it into another with some frequencies being removed and some added, you will have a distorted signal with noise. Since distortion is small, the difference between signal and the signal with noise will give you noise. [06:52:04 CET] <Fyr> You owe me $10, because I know about delay and synchronized the signals. [06:54:46 CET] <Fyr> JEEB, highlight to you. [07:03:00 CET] <Fyr> an interesting thing that FFMPEG AAC adds some higher frequencies. [07:04:55 CET] <Fyr> they can be heard as chatter, https://youtu.be/ghO8N1s2Brc [07:12:28 CET] <durandal_1707> open bug report? [07:24:13 CET] <Fyr> those frequencies are distinctly seen in spectra. [07:24:41 CET] <durandal_1707> There is way to disable it? [07:24:49 CET] <Fyr> nope. [07:25:15 CET] <Fyr> not with standard FFMPEG features. [07:25:36 CET] <durandal_1707> isn't it pns? [07:26:31 CET] <Fyr> PNS must be silent to ear. [07:27:00 CET] <Fyr> moreover, FDK AAC doesn't have them, FFMPEG AAC does. [07:31:09 CET] <yongyung> I have a .mp4 source file that I'm reencoding with ffmpeg/x264. The source file seems to be 60 FPS, at least that's what VLC shows. If I use .mp4 as the container when re-encoding, the resulting file will also be exactly 60 FPS, shown by VLC. But if I use .mkv, the frame rate that gets shown is 60.0024 fps (ffprobe still shows 60 FPS). I thought it might just be a VLC bug, but just renaming the file to .mp4 doesn't change what VLC shows. [07:31:09 CET] <yongyung> Also, when I change the container with -c copy to .mp4, the frame rate that VLC shows is suddenly 59.991160 - and now even ffprobe shows the frame rate as 59.99. Any idea what's going on here? The ffmpeg container switch output is http://pastebin.com/SNze21v0 [07:35:08 CET] <yongyung> Fyr: Don't you think it's kinda pointless to make a youtube listening comparison when YT will reencode the audio anyway? [07:36:50 CET] <Fyr> yongyung, don't you see the message appended to the video description? [07:37:04 CET] <yongyung> Fyr: YouTube didn't even generate 256k AAC for that video, not even 160k opus, only 128k aac, ouch... [07:37:26 CET] <Fyr> it's not pointless since the original audio sounds almost the same. [07:38:09 CET] <Fyr> FFMPEG AAC adds higher frequencies, meanwhile FDK doesn't. [07:38:25 CET] <yongyung> Would've made more sense to just show the spectral analysis... [07:38:52 CET] <Fyr> right [07:39:08 CET] <Fyr> I'll post a picture later. [07:39:51 CET] <Fyr> ...or you can make it by yourself, since you've just downloaded the video. [07:42:39 CET] <yongyung> Spectral analysis of the files ffmpeg generates, not of what YouTube does to them^^ Although, if you send me the source .flac I can do it, I just can't compare it to libfdk_aac since I'm not compiling ffmpeg myself [07:43:11 CET] <Fyr> ok [07:44:33 CET] <durandal_1707> I only accept spectral analysis from ffmpeg itself [07:45:11 CET] <Fyr> do you have a grudge against audacity? [07:45:20 CET] <satinder_> Hi there have any one who have expertise in ffmpeg api development [07:45:23 CET] <satinder_> ?? [07:45:29 CET] <satinder_> I want help [07:45:39 CET] <Fyr> satinder_, #ffmpeg-devel ? [07:45:45 CET] <satinder_> ok [07:47:40 CET] <durandal_1707> Fyr: yes, its looking bad [07:48:16 CET] <Fyr> durandal_1707, then what is good-looking? [07:48:40 CET] <durandal_1707> Fyr: only ffmpeg output [07:53:21 CET] <yongyung> Holy shit the aac encoder is *horrible* lmao, I never tried it out but since they moved it from experimental to default I didn't think it's *that* bad [07:53:34 CET] <yongyung> Like, I just tried it out and it's OBVIOUSLY horrible even with 128k [07:53:48 CET] <yongyung> You can hear it within 2 seconds [07:53:50 CET] <yongyung> Jesus Christ [07:54:24 CET] <yongyung> It's the worst encoder I've ever heared in my life by a big margin [07:56:01 CET] <yongyung> Honestly it's so bad that can only be some sort of bug [07:56:43 CET] <kepstin> yongyung: are you sure you aren't accidentally using libvo-aacenc? :) [07:56:51 CET] <Fyr> =) [07:57:01 CET] <kepstin> vo-aacenc *is* actually that bad [07:57:24 CET] <yongyung> kepstin: I used -c:a aac on a ffmpeg version I *just* downloaded from https://ffmpeg.zeranoe.com/builds/ [07:57:47 CET] <yongyung> It also didn't want me to specify -experimental or -strict or whatever you had to do before [07:58:28 CET] <Fyr> yongyung, http://xtemp09.ucoz.net/result.flac [07:58:53 CET] <Fyr> durandal_1707, yongyung, JEEB, atomnuker, http://xtemp09.ucoz.net/result_spectrum.png [08:00:15 CET] <durandal_1707> That is not ffmpeg spectrum, its so low resolution [08:00:15 CET] <Fyr> see the high frequencies by yourselves. [08:00:48 CET] <durandal_1707> that's lowpass filter I guess [08:00:54 CET] <Fyr> durandal_1707, ok you have the original audio, perform spectral analysis by yourself. [08:01:34 CET] <Fyr> I did: [08:01:34 CET] <Fyr> $ ffmpeg -i input.wav -c:a aac -b:a 128k -f mp4 ffmpeg_aac_128k.m4a [08:01:34 CET] <kepstin> yeah, lowpass filter somewhere betweeen 14 and 40kHz is a standard part of most lossy encoders [08:01:46 CET] <Fyr> $ ffmpeg -i input.wav -c:a aac -b:a 32k -f mp4 ffmpeg_aac_32k.m4a [08:01:49 CET] <Fyr> and so on [08:02:08 CET] <Fyr> you can reproduce it by yourself. [08:02:31 CET] <Fyr> what, when FFMPEG AAC was introduced, nobody tried to compare it? [08:03:14 CET] <Fyr> it's the first thing I have done when I read the release announcement. [08:03:20 CET] <kepstin> Fyr: there's been lots of analysis done as it was being developed (and it's still under development) [08:03:20 CET] <durandal_1707> lowpass can be disabled [08:03:21 CET] <yongyung> Fyr, kepstin, durandal_1707: Here, listen for yourselves. The aac version is so bad you can here freaking *hissing* with 128k, even mp3 is nowhere near that bad https://drive.google.com/file/d/0B9W6HnKoRJNOS0lXdlNuSm1vUFE/view?usp=sharin... [08:03:48 CET] <Fyr> yongyung, are you using FFMPEG AAC? [08:03:57 CET] <yongyung> Fyr: Yeah, -c:a aac [08:04:11 CET] <kepstin> the native aac encoder is certainly the best aac encoder that can be enabled in a redistributable ffmpeg build, at least. [08:04:13 CET] <Fyr> I don't think that it's THAT BAD. [08:04:26 CET] <yongyung> Jesus it hurts my ears [08:04:32 CET] <Fyr> it's way better than libvoaac_enc. [08:04:47 CET] <durandal_1707> I think it only is good from 256k to higher [08:04:54 CET] <Fyr> yeah, me too. [08:05:05 CET] <Fyr> it need some developement. [08:05:11 CET] <yongyung> kepstin: Well it might be the best one, but... if it sounds that bad it's still basically useless [08:05:27 CET] <Fyr> maybe, next year or too it will be comparable to libfdkaac_enc. [08:05:39 CET] <yongyung> Well I mean, except for compability reasons there's no reason to use aac anyway so I'm not too sad about it [08:05:58 CET] <kepstin> it's apparently missing some significant vbr-related features still (it's cbr only iirc) [08:06:14 CET] <kepstin> (or at least the vbr mode is still experimental) [08:07:16 CET] <Fyr> hhhhhhhhhhissssssssssing [08:08:34 CET] <yongyung> durandal_1707: You're right btw, with 256k the hissing is almost completely gone. I still feel like I hear something but I can't get a 16/16 blind test right now [09:37:02 CET] <k_sze> If I have built ffmpeg in the usual way (e.g. as per http://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu), is there a way I can tell which commit my ffmpeg was built against? [09:37:20 CET] <k_sze> I mean, if I don't remember which commit I used. [09:37:44 CET] <Fyr> oh [09:45:17 CET] <yongyung> I have a .mp4 source file that I'm reencoding with ffmpeg/x264. The source file seems to be 60 FPS, at least that's what VLC shows. If I use .mp4 as the container when re-encoding, the resulting file will also be exactly 60 FPS, shown by VLC. But if I use .mkv, the frame rate that gets shown is 60.002400 fps (ffprobe still shows 60 FPS). I thought it might just be a VLC bug, but just renaming the file to .mp4 doesn't change what VLC shows. [09:45:17 CET] <yongyung> Also, when I change the container with -c copy to .mp4, the frame rate that VLC shows is suddenly 59.991160 - and now even ffprobe shows the frame rate as 59.99. Any idea what's going on here? The ffmpeg container switch output is http://pastebin.com/SNze21v0 [11:34:50 CET] <flux> yongyung, can you either provide access to the file or use MP4Box to produce some information about it? [11:39:33 CET] <flux> yongyung, the difference could be that the average FPS of the track is different from the track length including/excluding audio, or that some frame (ie. first or last) could be of different duration [11:45:56 CET] <flux> actually ffprobe is able to retrieve this information as well a bit more precisely. [11:47:39 CET] <yongyung> flux: If you tell me the command line I can see what happens ;) [11:48:47 CET] <flux> yongyung, do you run Linux? [11:49:32 CET] <yongyung> flux: No, but the command shouldn't change for windows? [11:50:19 CET] <flux> well, I was thinking of using some other commands as well than pain ffprobe [11:50:35 CET] <flux> but ffprobe -of compact -show_frames will dump information about each frame [11:50:42 CET] <flux> the field to watch for is pkt_pts_time [11:51:13 CET] <flux> you could compare the rows that both have stream_index=0 (assuming the first track is video) against the value in pkt_pts_time [11:55:37 CET] <yongyung> flux: The duration always varies between 0.017, 0.016 and 0.015 [11:57:01 CET] <flux> yongyung, and if you compare the durations between the original video and the resulting video, are they different? [11:58:27 CET] <flux> actually there's already a field pkt_duration_time.. [11:58:35 CET] <yongyung> flux: In the .mkv file they're all 0.016 as far as I can see [11:58:44 CET] <flux> but I was thinking if you compare the raw pkt_pts_times, do they drift apart? [11:59:48 CET] <flux> and do the videos have the same number of frames, and is their length in time the same (video duration is usually not indicated to this precision though) [12:02:45 CET] <yongyung> flux: The frames in the .mkv file aren't in order, pts_times are 0.0, 0.05, 0.044, 0.028, 0.111, 0.094 [12:03:23 CET] <yongyung> With the mp4 file they're 0.0, 0.017, 0.034, 0.05, 0.067, 0.084 [12:06:19 CET] <flux> well, the packets may not be in presentation order in the stream, so you could compare the ordered values [12:08:02 CET] <yongyung> Well, they're drifting I guess - The weird thing is, this is an OBS recording, if I record to .mp4 the file shows 60 FPS, if I record to .mkv the file shows 60.0024 FPS. Same effect as if I converted it. [12:45:04 CET] <atomnuker> Fyr: *I* wrote most of the encoder apart from the base, and *you* need to stop thinking like the main point of an audio encoder is perfect looking spectra [12:45:28 CET] <atomnuker> the encoder boosts PNS volume as the bitrate/lambda decreases [12:45:57 CET] <atomnuker> and for a very good reason: it sounds a lot better at lower bitrates [12:46:38 CET] <atomnuker> masking the more horrible quantization artifacts which appear at around the midrange [12:47:39 CET] <atomnuker> so at lower bitrates it's never about replicating the original spectrum 1 to 1 [12:50:19 CET] <Fyr> atomnuker, why then FFMPEG AAC encoder sounds like ass? [12:51:04 CET] <atomnuker> because the fdk people had years to tweak and tune their encoder [12:51:20 CET] <atomnuker> and I've worked on our encoder for just under a year now [12:51:47 CET] <atomnuker> should've heard what it sounded like back then [12:51:51 CET] <Fyr> then removal of -strict experimental was a bit hastily. [12:52:24 CET] <Fyr> I think that the native FFMPEG's encoder is a great deal. [12:52:25 CET] <atomnuker> I disagree - it is good enough for most people at bitrates of over 128k [12:52:29 CET] <Fyr> yes [12:52:36 CET] <Fyr> more than 256k I would say. [12:53:08 CET] <Fyr> when VBR is implemented, it will look like a candy. [12:53:29 CET] <Fyr> right now it needs polishing. [12:53:50 CET] <atomnuker> VBR makes everything more difficult [12:53:59 CET] <Fyr> it does. [12:54:22 CET] <atomnuker> and some people would *kill* us if it overshot [12:55:38 CET] <atomnuker> if you think you can do better: the more important code is right there in libavcodec/aaccoder.c [12:56:05 CET] <Fyr> atomnuker, why does FFMPEG's AAC add a delay when converting into M4A? [12:56:17 CET] <Fyr> the very first 0.02 seconds. [12:56:20 CET] <JEEB> all AAC encoders have encoder delay [12:56:26 CET] <atomnuker> ^^ [12:56:32 CET] <Fyr> and in the end it adds some points. [12:56:33 CET] <JEEB> why you don't get it with fdk-aac is the question [12:57:05 CET] <atomnuker> I did tests on that a few months ago and fdk-aac was 200msec behind the original track [12:57:09 CET] <Fyr> JEEB, fdk adds 0.000 seconds, the native encoder adds 0.02. [12:57:17 CET] <atomnuker> compared to the ~20 msec of the native encoder [12:58:05 CET] <Fyr> it means, when it's converted ten times, the delay will be 0.2 second. [12:58:13 CET] <JEEB> Fyr: there's definitely some monkey business going on then because both have encoder delay and both should mark it. I do know that last I tested the WAV output was the broken one [12:58:23 CET] <JEEB> which I think I went over with you before :P [12:59:16 CET] <JEEB> and then you supposedly noted that the random FFmpeg binary you were using hadn't written... the delay with one of the encoders? [12:59:25 CET] <JEEB> since you didn't have the start: xxx thing [13:04:53 CET] <Fyr> I think that stealing the algorithms and the code is a good thing. [13:05:44 CET] <Fyr> we should disassemble QAAC and steal everything from them. [13:08:04 CET] <furq> you first [13:14:05 CET] <JEEB> ok, just built the latest FFmpeg here and 1) the encoder delay is clearly marked and 2) the WAV output is still as weird as it always was with negative timestamps [13:14:28 CET] <JEEB> so if you care about that not being handled correctly, please fill a bug :P [13:14:34 CET] <Fyr> how is it weird? [13:14:52 CET] <JEEB> it outputs all the samples, it doesn't ignore stuff you're supposed to ignore [13:15:24 CET] <JEEB> I went through this once with another guy and it was due to how the command line app handles negative timestamps [13:15:48 CET] <JEEB> because you've got encoder delay, the first samples will start at a negative timestamp [13:15:58 CET] <JEEB> yet because WAV is an "output format" that doesn't suppor that... [13:16:19 CET] <JEEB> it will do the thing that was "designed" to give you all the samples [13:16:34 CET] <JEEB> if you used the API, then you would be just throwing those samples out [13:17:03 CET] <JEEB> like foobar2000 is doing [13:17:29 CET] <JEEB> and pretty much every other API user of the libavcodec library I think [13:33:07 CET] <absence> i've encoded a raw h264 stream using x264. when i try to mux it to mp4 using ffmpeg, i get piles of messages "pts has no value" [13:34:35 CET] <absence> i've gotten the same error when remuxing from MTS, and it was suggested that the MTS file was bad. but now i have a .264 file directly from x264, surely that should work? [13:35:29 CET] <JEEB> well, there really isn't much of the form of PTS in raw AVC. You will have to specify a frame rate unless ffmpeg catches a header that is often (ab)used for that [13:36:03 CET] <JEEB> (raw AVC and such are the rare cases where IIRC -r before -i works) [13:36:20 CET] <absence> JEEB: ffmpeg does detect the right frame rate though [13:36:21 CET] <JEEB> although I usually do raw AVC to mp4 with L-SMASH's muxer [13:36:31 CET] <JEEB> absence: and the output is or isn't fine? [13:36:36 CET] <absence> Stream #0:0: Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 1280x720, q=2-31, 50 fps, 50 tbr, 1200k tbn, 1200k tbc [13:37:09 CET] <absence> JEEB: i don't know yet, i'm just assuming something is wrong. last time i saw this i ended up with frames out of order [13:37:12 CET] <absence> and stuttering [13:37:39 CET] <JEEB> test it out with a simple command line ffmpeg -i hurr.264 -c copy out.mp4 [13:38:02 CET] <JEEB> if it does something wrong, file a bug and switch to using L-SMASH's muxer for the initial mux [13:39:56 CET] <absence> JEEB: btw there's also this message at the beginning: [mp4 @ 00000069ef4732a0] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly [13:41:31 CET] <JEEB> that is warning about internal code using something that has been marked deprecated [13:41:44 CET] <JEEB> it isn't something you'd worry about because you're not using the library [13:42:04 CET] <JEEB> Fyr: I can't replicate your results, both encoders mark encoder delay http://up-cat.net/p/10da2feb [13:42:48 CET] <absence> true, but it suggests that even if it runs right now, something is so wrong that in a future version it won't even try it. i'd really like to get to the bottom of this [13:42:48 CET] <Fyr> ok, I'll recheck this with the latest FFMPEG and post a bug report if I don't reproduce it. [13:44:01 CET] <JEEB> Fyr: and if I now decode these with the ffmpeg cli to WAV I expect both to have the encoder delay there because of the way negative timestamps are handled [13:44:37 CET] <Fyr> JEEB, i.e. the delay remains? [13:45:12 CET] <JEEB> i.e. the wav output doesn't get cut, because of a bug/feature in libavformat [13:45:29 CET] <JEEB> *that* IMHO should be where you should file a bug if you file one :P [13:45:31 CET] <Fyr> ='( [13:46:50 CET] <JEEB> and yup, I got exactly the same result [13:47:25 CET] <JEEB> ffaac has a smaller delay, thus ended up shorter after decoding to wav, and fdk-aac has a bigger one and thus ends up even larger :P [13:47:51 CET] <JEEB> but yeah, if you want this fixed you should file a bug against the WAV output [13:48:04 CET] <JEEB> since that is the component that is currently handling that delay wrong [13:50:15 CET] <JEEB> lemme try forcing the fdk-aac decoder if that got built, that might just be implicitly throwing out its own delay (but it should do it in both cases) [13:50:55 CET] <JEEB> which IMHO is even worse :D because it's not like the decoder can do anything else but assume things [13:53:13 CET] <JEEB> funky [13:53:24 CET] <JEEB> that actually seems to also output all samples [13:53:40 CET] <JEEB> Fyr: I have no idea how you got a wav out of ffmpeg that had the delay removed :DDD [13:53:51 CET] <JEEB> both ffaac and fdk-aac decoder output all samples it seems [13:54:00 CET] <JEEB> at least looking at the length of the output wav [13:54:22 CET] <Fyr> JEEB, ffmpeg -i X.m4a -ss 0.0232 -t XX -c:a pcm_s16le 1.wav [13:54:53 CET] <JEEB> uhh [13:55:05 CET] <JEEB> weren't you yesterday saying that with jus "ffmpeg -i file out.wav" [13:55:12 CET] <JEEB> was giving you no delay with fdk-aac? [13:55:37 CET] <JEEB> because supposedly only ffaac was creating that delay :P [13:55:37 CET] <Fyr> yes [13:55:51 CET] <JEEB> well I have right now shown that to be bollocks [13:55:57 CET] <Fyr> because libfdkaac_enc's delay was 0.0000 s [13:56:09 CET] <JEEB> http://up-cat.net/p/a4c1bfb1 [13:56:14 CET] <Fyr> I saw that. [13:56:14 CET] <JEEB> you can see the whole flow [13:56:19 CET] <JEEB> no, this is with decoding [13:56:23 CET] <JEEB> and decoding with fdk-aac [13:56:38 CET] <JEEB> so no matter which decoder you use, you get the length of all samples encoded, including the delay [14:02:35 CET] <JEEB> Fyr: so basically the only bug you should be filing is against the wav output :P [14:03:55 CET] <absence> JEEB: there are a bunch of old open tickets about this and related issues on trac, so i guess ffmpeg simply doesn't support muxing h264. with mp4 there's the deprecated warning, but with mkv or mts it simply stops with an error [14:04:35 CET] <JEEB> absence: so did you actually try the created file? [14:04:57 CET] <JEEB> the no pts warning is valid('ish) with raw AVC [14:04:57 CET] <absence> JEEB: the created mkv and mts files are empty [14:05:20 CET] <JEEB> please post your full command line and output on a pastebin'ish site that is not retarded [14:05:22 CET] <absence> JEEB: or well, "empty". less than 1kB [14:05:36 CET] <absence> which one isn't retarted? [14:06:33 CET] <JEEB> anything that doesn't require me to go through hoops [14:07:45 CET] <absence> JEEB: http://pastebin.com/quqVY1Wt [14:07:49 CET] <JEEB> thanks [14:08:52 CET] <absence> JEEB: if i mux to .mts the error is identical [14:09:16 CET] <JEEB> yeah, I guess they both check if there's a timestamp on the packets [14:09:20 CET] <absence> JEEB: the 264 file comes straight out of x264 [14:09:24 CET] <absence> no fancy options [14:09:31 CET] <JEEB> yeah, I understand [14:09:55 CET] <absence> JEEB: and i get the exact same problem if i read h264 from a .mts instead of from a .264 [14:10:05 CET] <JEEB> yeah, but that's completely different [14:10:19 CET] <JEEB> in that case either the mpegts demuxer or the input file is broken [14:10:49 CET] <JEEB> in this case it's just how the timestamps on a raw AVC streams are handled (or well, how the timestamps *aren't* created) [14:11:35 CET] <JEEB> you can either comment on an existing bug report or craft a bug report if there's not one specifically for muxing raw AVC into containers [14:11:51 CET] <JEEB> the mpeg-ts => something is a whole separate can of worms [14:12:04 CET] <JEEB> for now I recommend you create an initial mp4 with L-SMASH's muxer or so [14:12:17 CET] <JEEB> absence: or as I asked, did the mp4 you created work? [14:12:21 CET] <JEEB> with ffmpeg [14:12:26 CET] <JEEB> since you said that created a file fine [14:12:52 CET] <absence> JEEB: there are several open ones already, and they're like 4 years old [14:13:14 CET] <JEEB> for raw avc to containers? [14:13:22 CET] <JEEB> forget about the other case for now [14:13:41 CET] <absence> JEEB: yes [14:14:55 CET] <absence> https://trac.ffmpeg.org/ticket/1150 [14:14:57 CET] <absence> https://trac.ffmpeg.org/ticket/1598 [14:15:30 CET] <Fyr> ok, let's call it a day. [14:15:30 CET] <Fyr> JEEB, when people on #ffmpeg-devel try to close the bug, explain the details. [14:15:38 CET] <absence> JEEB: there are multiple open tickets for the other case too [14:15:48 CET] <absence> JEEB: not as old though, just two years [14:16:11 CET] <absence> https://trac.ffmpeg.org/ticket/3339 [14:16:13 CET] <JEEB> Fyr: funny enough your output doesn't seem to add anything to the duration :P [14:16:14 CET] <absence> https://trac.ffmpeg.org/ticket/3369 [14:16:33 CET] <JEEB> Fyr: so your ffmpeg build is borked or something, because the duration isn't longer with the WAV [14:16:41 CET] <absence> JEEB: the .mp4 it creates seems to work at a glance [14:17:19 CET] <absence> JEEB: whereas the .mkv and .mts are empty [14:17:42 CET] <JEEB> yea, the matroska case is at least simple enough. the muxer just doesn't take packets that haven't got a timestamp [14:18:05 CET] <JEEB> which can be explained by the raw avc "demuxer" not putting in all the values [14:18:18 CET] <JEEB> I would guess the mpeg-ts muxer also requires some fields to be set [14:19:16 CET] <absence> -fflags +genpts does nothing in all the cases. for which there is another open ticket :D (not complaining, but it is a bit funny) [14:19:42 CET] <JEEB> I don't even want to know what that does [14:20:12 CET] <absence> i think it generates the missing timestamps [14:20:19 CET] <absence> or is supposed to [14:20:20 CET] <JEEB> Fyr: OK, I'm just bad at this :P you never showed the source thing's actual length so yeah, it's all OK [14:20:48 CET] <absence> JEEB: the ticket suggests it's a "known limitation of our h264 decoder" [14:20:50 CET] <JEEB> this is definitely not something a user should expect so unless there's a big reason for pushing out all samples [14:25:37 CET] <JEEB> absence: that kind of flag is a huge hack and shouldn't be required with non-broken files [14:25:42 CET] <JEEB> so forget about genpts flag [14:53:45 CET] <absence> JEEB: it's usually presented as a workaround for the lack of timestamps on various forum posts and mailing lists, but it doesn't work anyway. maybe it used to [14:58:15 CET] <JEEB> absence: it can work in some rare occasions, maybe. it will try to come up with timestamps from thin air [14:58:24 CET] <JEEB> it shouldn't be needed with raw AVC anyways [15:06:28 CET] <wodim> is amv still not supported as an output format? [15:07:10 CET] <JEEB> which amv? [15:07:19 CET] <wodim> https://code.google.com/archive/p/amv-codec-tools/wikis/HowToConvertToAMV.wi... [15:07:31 CET] <JEEB> ok, so the chinese MJPEG AVI hack if I recall correctly [15:07:35 CET] <wodim> no clue [15:07:40 CET] <wodim> but yes [15:07:49 CET] <wodim> it's for a shitty pocket player [15:08:14 CET] <JEEB> anyways, no - it's not in the list that comes up when I run `ffmpeg -formats` [15:08:16 CET] <wodim> so there's that fork there but it's from 2007 [15:09:20 CET] <JEEB> also I'm not sure how much of "AMV" is actually custom, so you might be able to use MJPEG and raw PCM with those values [15:09:33 CET] <wodim> I'll give it a spin [15:09:34 CET] <JEEB> although not that I remember the details of that crappy container [15:09:41 CET] <JEEB> you should see the patches for it [15:09:59 CET] <wodim> top notch chinese engineering [15:10:00 CET] <JEEB> also if I recall correctly there's even multiple things called "AMV" [15:10:36 CET] <JEEB> https://code.google.com/archive/p/amv-codec-tools/wikis/AmvDocumentation.wik... [15:10:37 CET] <JEEB> oh yeah [15:10:48 CET] <absence> for a second i worried that someone had invented a specific format for "anime music videos" :D [15:11:05 CET] <JEEB> basically AVI with various parts of the file filled with shit [15:11:45 CET] <JEEB> ugh [15:11:59 CET] <wodim> maybe regular AVI would work? [15:12:13 CET] <JEEB> both the video and audio formats seem to be raped [15:12:18 CET] <wodim> it comes with amv [15:12:20 CET] <wodim> err [15:12:20 CET] <JEEB> unless the players now can handle proper MJPEG right [15:12:27 CET] <wodim> sorry I mean [15:12:33 CET] <wodim> the player comes with an amv file [15:12:37 CET] <wodim> this is what it looks like [15:12:37 CET] <wodim> Stream #0:0: Video: amv, yuvj420p(pc, bt470bg/unknown/unknown), 160x120, 16 fps, 16 tbr, 16 tbn, 16 tbc [15:12:41 CET] <wodim> Stream #0:1: Audio: adpcm_ima_amv ([1][0][0][0] / 0x0001), 22050 Hz, 1 channels, s16, 352 kb/s [16:53:25 CET] <voodster> hello, I want concat two webm with audio into one webm [16:53:42 CET] <voodster> command does not work as I want -> ffmpeg -vcodec copy -acodec copy -i one.webm -vcodec copy -acodec copy -i two.webm result.webm [16:54:01 CET] <voodster> I got only first file in result, how to map correctly it? [16:56:48 CET] <furq> voodster: https://trac.ffmpeg.org/wiki/Concatenate#demuxer [16:57:15 CET] <voodster> I have not 'ffmpeg -f concat' [16:58:57 CET] <voodster> ffmpeg -i "concat:input1.mpg|input2.mpg|input3.mpg" -c copy output.mpg // does not work correctly for me too, in output I get first file [16:59:16 CET] <furq> you can't use the concat protocol with webm [16:59:24 CET] <furq> if you don't have the demuxer then upgrade ffmpeg [16:59:47 CET] <furq> http://johnvansickle.com/ffmpeg/ if your distro package manager is stuck on 0.8 [17:00:23 CET] <`md> is opening h264/ac3/ts/http a non supported case for ffmpeg? [17:00:36 CET] <`md> i was under the impression it should work [17:00:45 CET] <`md> certainly works very well with vlc [17:02:59 CET] <Prelude2004c> hey guys.. question.. i have a gif image that i want to loop because i only have audio from a source and i want to create a video with audio/video [17:03:21 CET] <Prelude2004c> >> /home/ffmpeg/ffmpeg -i "$2" -stream_loop -1 -i $5 -pix_fmt yuv420p -c:v mpeg4 -c:a copy -r 25 -t 30 [17:03:23 CET] <Prelude2004c> what am i doing wrong here ? [17:03:46 CET] <Prelude2004c> the first input is my live audio stream.. my second is the png ( $5 ) that i want to loop to create the video [17:04:18 CET] <furq> stream_loop should be before the image, not the audio [17:05:05 CET] <furq> you probably also want -shortest [17:06:54 CET] <JEEB> `md: it should work [17:07:08 CET] <JEEB> how does it not work? [17:07:15 CET] <JEEB> (command line and terminal output if possible) [17:07:21 CET] <JEEB> (in pastebin'like) [17:09:38 CET] <Prelude2004c> -stream_loop -1 -i $5 that is the image [17:09:46 CET] <Prelude2004c> $2 is the audio [17:10:00 CET] <furq> oh [17:10:06 CET] <furq> how does it not work [17:12:28 CET] <voodster> furq: thanks a lot for a link with new binary ffmpeg [17:12:29 CET] <Prelude2004c> no idea... seems that it can't loop the input of the gif image [17:12:39 CET] <voodster> all works fine with it [17:12:46 CET] <furq> Prelude2004c: is it a gif or a png [17:12:51 CET] <Prelude2004c> gif. [17:12:57 CET] <Prelude2004c> and it does like 2 frames and exits [17:13:09 CET] <Prelude2004c> when i run just the gif on it's own it works and starts to create the video [17:13:38 CET] <Prelude2004c> soon as i try to introduce the external audio into the mix, it does 2 frames and just stops [17:19:56 CET] <Prelude2004c> anyone ? > /home/ffmpeg/ffmpeg -re -i "external http://audio source" -stream_loop -1 -i "/location/file.gif" -pix_fmt yuv420p -c:v mpeg4 -c:a copy -r 25 [17:22:50 CET] <`md> JEEB: for example https://pastee.org/486h [17:23:55 CET] <`md> JEEB: and then on another computer i tried this on, it keeps going on, but with lotsa decoding errors as well [17:24:12 CET] <`md> JEEB: just watching that url in vlc is perfectly fine tho [17:25:43 CET] <JEEB> might want to try with current FFmpeg, but as it shows the stuff itself works fine. are you using lavc decoding or hw decoding with VLC? [17:25:54 CET] <JEEB> also you could try mpv as another player that's based on libavformat+-codec [17:25:56 CET] <`md> lavc [17:26:58 CET] <JEEB> seems like you were pushing your stream to another http thingy and that one reset the connection [17:27:12 CET] <JEEB> av_interleaved_write_frame(): Connection reset by peer [17:27:41 CET] <JEEB> but yeah, I recommend building the latest FFmpeg master with libx264 to try that out [17:28:24 CET] <`md> JEEB: mpv seems to play it fine [17:28:35 CET] <JEEB> yeah, so I guess it's the pushing to another HTTP thingy that's the issue [17:28:37 CET] <`md> JEEB: not pushing [17:28:40 CET] <`md> JEEB: serving [17:28:46 CET] <JEEB> oh right, -listen 1 [17:28:54 CET] <JEEB> that might have all quirks of its own :D [17:29:14 CET] <JEEB> should just be "./configure --enable-gpl --enable-libx264" after you install libx264-dev [17:29:24 CET] <JEEB> unless that 14.04 x264 is way way too old [17:29:41 CET] <`md> i i get the same issues with file output btw [17:29:48 CET] <`md> so it is not the http serving component [17:29:52 CET] <`md> -i [17:30:00 CET] <JEEB> ok, can you then post that? [17:30:05 CET] <`md> sure hold on [17:34:20 CET] <Prelude2004c> hum.. ok seems that it works if i output to mp4 but does not work if i try and output HLS and segment any ideas ? [17:34:56 CET] <`md> JEEB: https://pastee.org/kk38d i aborted the process after about 1000 frames, otherwise it would have kept going [17:35:58 CET] <Prelude2004c> http://pastebin.com/KdPfTXxP >> can anyone help with what is wrong with it [17:36:24 CET] <Prelude2004c> i can't seem to output directly to HLS .. so i piped the output to another session and then segment but still does not like it as it gets stuck waiting for input [17:38:54 CET] <JEEB> `md: if it kept on going then it's fine [17:39:16 CET] <JEEB> getting those errors for a while is normal [17:39:17 CET] <`md> JEEB: yes it kept on going [17:39:37 CET] <`md> JEEB: well yea normally i would ignore them... but they amount to glitches [17:39:46 CET] <`md> in hte output [17:40:25 CET] <JEEB> if the input stream is supposed to have normal closed GOPs then something's breaking it along the way [17:40:48 CET] <JEEB> anyways, we should stop looking at it with this old version, you should get a current one built and we can see how that goes [17:40:53 CET] <JEEB> 2.5 is quite old by now [17:41:05 CET] <`md> JEEB: i am not 100% sure how gop closing is defined for dvb broadcasts [17:41:44 CET] <JEEB> in general they can have open gop, but you should generally have a random access picture every 0.5 second or so? [17:42:10 CET] <JEEB> so either it's a bug in this old version of FFmpeg, or the stream's being broken somewhere [17:42:31 CET] <`md> well the output is playable, but very glitchy [17:42:36 CET] <JEEB> I have done quite a bit of work with http inputs so in general those should work [17:42:48 CET] <`md> yea i should update ffmpeg [17:43:00 CET] <`md> gonna do that and report back [18:35:45 CET] <Prelude2004c> hey guys.. i am closer but.. still a problem [18:35:45 CET] <Prelude2004c> http://pastebin.com/vfE4xgL7 [18:36:15 CET] <Prelude2004c> seems that now ti plays video and audio from the outside source but !!! when the video ends on the input $5 everything just stops [18:36:20 CET] <Prelude2004c> i don't get it.. i have the stream_loop there [18:46:53 CET] <Prelude2004c> an anyone help me with video loop ? [18:49:49 CET] <durandal_1707> Prelude2004c: how long is video in frames? [18:50:10 CET] <Prelude2004c> 935frames [18:50:15 CET] <Prelude2004c> but the audio source goes on forever [18:50:28 CET] <Prelude2004c> so i want to loop the input video ( which is just a blank page that says " audio stream " ) [18:50:37 CET] <Prelude2004c> and then play the realtime audio [18:50:54 CET] <Prelude2004c> but the video/audio stop after the original video hits 935frames [18:51:18 CET] <Prelude2004c> so everything stalls as if it can't continue because the video is over.. i was assuminmg it would just loop forever and keep playing the realtime audio source [18:51:38 CET] <satinder___> Hi I am able write data in .ppm but I want write it on a file [18:51:45 CET] <satinder___> please any body help [18:53:26 CET] <durandal_1707> Prelude2004c: try loop filters? [18:53:42 CET] <Prelude2004c> um.. trying stream_loop -1 [18:53:46 CET] <Prelude2004c> doesn't go around for the input [18:54:28 CET] <Prelude2004c> > /home/ffmpeg/ffmpeg -i "$2" -stream_loop 10 -re -i $5 .. the whole thign stops soon as the first run of the -i $5 ends [18:54:40 CET] <Prelude2004c> exactly 935 frames [18:57:10 CET] <durandal_1707> if video is single frame you can use loop filter, otherwise paste full ffmpeg output [18:57:25 CET] <Prelude2004c> what loop filter ? [18:57:59 CET] <Prelude2004c> i have tried loop - 1 ( not recognized ) .. only one that seems to have worked was stream_loop without error.. but still doesn't loop [19:02:14 CET] <jkqxz> satinder___: You're going to have to be much clearer about what you actually want for anyone to be able to help you. Try asking a question with precise details about what you want to do rather than vaguely stating that you need help with something nebulous. [19:05:08 CET] <satinder___> No , I am doing this with using ffmpeg api not ffmpeg binary [19:06:15 CET] <satinder___> jkqxz : I am writing a c code for get encoded stream and decode it then write raw data on fifo or v4l2 node [19:06:52 CET] <satinder___> I get successfully video frames but not able to write it in a video stream file or node [19:06:59 CET] <satinder___> so can you help me [19:13:30 CET] <Filarius> hello, do anybody can help me to fix audio/video lag at beginning of video ? Logs http://pastebin.com/pUGbbfRf Video http://rghost.ru/7N6Bz42RS [19:13:55 CET] <Filarius> I trying to record HLS live stream [19:14:26 CET] <Filarius> I have same lag with video-audio re-encoding too [19:25:19 CET] <Prelude2004c> still trying to loop an input .. can anyone help ? [19:40:51 CET] <bencoh> Filarius: what if you just download/concat chunks? do you notice any lag? [19:47:11 CET] <durandal_1707> Prelude2004c: there are loop filters, read docs [20:14:23 CET] <Prelude2004c> yes i have been trying to use lavif and stuff [20:14:30 CET] <Prelude2004c> having problems with it too [21:53:24 CET] <Filarius> bencoh, maybe i'm too late. I just have short video, withour parts/chunks. Video is unique and separete item [22:36:31 CET] <bencoh> Filarius: is that hls? [23:18:33 CET] <_Vi> ffplay says something about uploading a file to "incoming" and sending to a mail list when I try to play this: https://oitofelix.github.io/mininim/game-play.png [23:19:37 CET] <c_14> _Vi: seems to work for me. What version do you have? [23:20:26 CET] <_Vi> ffmpeg version 2.7.1 Copyright (c) 2000-2015 the FFmpeg developers [23:21:24 CET] <_Vi> File converted to V_MPEG4/ISO/AVC mkv also looks broken (not fluent compared to if view using browser). [23:22:26 CET] <_Vi> The message is "[apng @ 0xbd3900] Blending with pixel format rgb24 is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.". Maybe the main part is "pdate your FFmpeg version to the newest one from Git."... [23:23:09 CET] <c_14> _Vi: try with a git build [23:57:03 CET] <_Vi> Works well with FFmpeg from git. [23:57:11 CET] <_Vi> What multimedia container (apart from png itself) can store apng? matroska and nut fails... [00:00:00 CET] --- Sun Mar 6 2016