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

[burek]

[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=sharing
[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.wiki
[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.wiki
[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