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

burek burek021 at gmail.com
Thu Jul 23 02:05:01 CEST 2015


[00:58:40 CEST] <edoceo> Is one pixel format better/faster than another?  Maybe one format is more lossless?
[00:59:25 CEST] <Mavrik> Uhm
[00:59:40 CEST] <Mavrik> Different pixel formats lose different amount of data (and compress differently).
[00:59:50 CEST] <Mavrik> Of course, you're dependant on what your player supports.
[01:00:05 CEST] <Mavrik> YUV420P is pretty much the only widely supported pixel format.
[01:10:59 CEST] <edoceo> My player is ffmpeg, I just need a high quality (and hopefully fast) format for ffmpeg to process, then at the end I make widely compatible format
[01:11:23 CEST] <Mavrik> What are you grabbing?
[01:11:29 CEST] <edoceo> Like, I have N number of source videos, I process and stitch together with ffmpeg, then finalise
[01:11:40 CEST] <edoceo> Most of the source video is from webcams
[01:11:50 CEST] <edoceo> some is recorded browser sessions
[01:12:09 CEST] <edoceo> Output eventually is scaled/cropped to 640x480
[01:12:14 CEST] <Mavrik> Avoid conversions of pixel format then, you probably have yuv420 anyway
[01:12:40 CEST] <Mavrik> Depending on speed size, use losless x264 (slower) or huffyuv (faster) for intermediate storage
[01:12:53 CEST] <Mavrik> Encode output to H.264 in YUV420p for maximum compatiblity
[01:13:36 CEST] <edoceo> Yea, most of the source webm files are yuv420p
[01:16:34 CEST] <Mavrik> Yeah, you're going to need better equipment than webcams to get YUV444 or something :)
[01:16:51 CEST] <edoceo> Cool, so now I have an unknown pixel format issue
[01:16:58 CEST] <edoceo> I use this command to make a grid: http://edoceo.io/paste?p=rqyZO0
[01:17:37 CEST] <Mavrik> unknown pixel format issue?
[01:17:38 CEST] <edoceo> But when I ffprobe I get this: http://edoceo.io/paste?p=bjCvDu  [matroska,webm @ 0x68a2a0] Could not find codec parameters for stream 0 (Video: mpeg2video, 640x480): unspecified pixel format
[01:18:39 CEST] <Mavrik> That might be a bug.
[01:18:57 CEST] <Mavrik> since I see nothing wrong with your command line
[01:19:03 CEST] <Mavrik> Can you try with 2.7.1 ffmpeg?
[01:19:12 CEST] <Mavrik> grab one of the static builds
[01:20:59 CEST] <edoceo> The command I sent has my local version but I also get the error from a recent static: ffmpeg version N-63893-gc69defd Copyright (c) 2000-2014 the FFmpeg developers
[01:21:14 CEST] <Mavrik> hrmf.
[01:21:54 CEST] <Mavrik> does the output play?
[01:22:00 CEST] <Mavrik> might just be an analyze issue
[01:22:26 CEST] <edoceo> Does not play, but there was a newer static than what I had, so gimmie a second
[01:23:42 CEST] <edoceo> That latest static still has the issue
[01:24:21 CEST] <edoceo> v: ffmpeg version N-48359-g6b96c70-static
[01:24:43 CEST] <Mavrik> Might wanna report it then.
[01:24:59 CEST] <edoceo> Can I force a pix_format for input so it woudl know?
[01:25:11 CEST] <Mavrik> yes, add -pix_fmt before -i
[01:27:18 CEST] <edoceo> Ok, I'll know in about 30 minutes if that work, thanks!
[01:43:59 CEST] <edoceo> If I put -pix_fmt before -i I get: Option pixel_format not found.
[03:00:10 CEST] <blurider1> If I compile ffmpeg with NEON support for ARM CPUs, will it work on cpus without NEON support?
[03:03:00 CEST] Last message repeated 1 time(s).
[08:56:18 CEST] <kelnoky> just wanted to make an alias for an ffmpeg command I use frequently, however it doesnt seem to work with the output "-vcodec: No such file or directory". what did I do wrong here: alias louder='ffmpeg -i $1 -vcodec copy -af volume="4.0" $2'
[08:57:42 CEST] <pzich> kelnoky: is this bash? you can't use parameters in bash aliases
[08:57:56 CEST] <kelnoky> pzich: yeh, it is and oh....
[08:58:03 CEST] <kelnoky> I just want something so simple
[08:58:09 CEST] <pzich> a simple solution is to write a function, ala http://stackoverflow.com/a/7131683
[08:58:23 CEST] <kelnoky> someone suggested I use a function, but even with a tutorial article on it I dont get it :D
[08:59:01 CEST] <kelnoky> hm
[08:59:04 CEST] <pzich> it's just: louder() { ffmpeg -i $1 -vcodec copy -af volume="4.0" $2 }
[08:59:10 CEST] <kelnoky> that answer is better than the tutorial I had though
[08:59:19 CEST] <kelnoky> yeh, I think I got it now
[09:00:05 CEST] <kelnoky> thanks!
[09:00:09 CEST] <pzich> np
[09:00:33 CEST] <pzich> also, quote your arguments if you want to handle whitespace and other special chars correctly
[09:01:54 CEST] <kelnoky> ah, so if my filenames had whitespaces or other stuff in it
[09:01:58 CEST] <kelnoky> ok, thanks
[09:02:08 CEST] <pzich> the second answer has an example, if you need it
[09:02:11 CEST] <kelnoky> single quotes or double quotes?
[09:02:17 CEST] <kelnoky> ' or "
[09:02:19 CEST] <pzich> double, single won't expand the arguments
[09:02:22 CEST] <kelnoky> ok
[09:02:27 CEST] <pzich> you'll get a literal '$1'
[09:02:40 CEST] <kelnoky> it works :)
[09:43:53 CEST] <bse__> i'm trying to convert a security camera video (mxg format) to mp4, for easy access in a webbrowser. the video is at 5 to 10 fps (varying). ideally i'd like to ignore the timestamps in the input video and encode it frame-by-frame to mov (no duplication, no dropping). though whatever i try, i keep dropping frames. i'm stuck with ffmpeg 0.8.17 (debian wheezy). any ideas for a -vf i could try?
[09:45:35 CEST] <chungy> wheezy doesn't even have ffmpeg, it's libav pretending to be ffmpeg. Either way, the release is ancient and you should probably upgrade :P
[09:47:53 CEST] <bse__> yea :/ should try harder to convince my boss
[09:48:29 CEST] <chungy> can build ffmpeg manually if you have a compiler and all
[09:51:25 CEST] <bse__> loooots of dependencies iirc... but worth looking into, good idea thx
[10:01:58 CEST] <DHE> not THAT many dependencies. third party codecs, yes if you want them. x264 is a big one. otherwise ffmpeg will tolerate most dependencies missing and build with stock codecs only
[10:04:18 CEST] <termos> is there an easy way for either ffprobe or ffmpeg to dump the onMetaData so I can view it?
[10:07:19 CEST] <termos> aha, flvmeta seems to do it but it only accepts files not rtmp streams
[10:22:16 CEST] <Marko> Hello does anybody know value range of libschroedinger -q:v parameter?
[10:24:36 CEST] <xerox> I wondered if there was an ffmpeg channel, so happy there is one :)
[10:25:33 CEST] <xerox> is it possible to have ffmpeg not print out the version+build options+library versions every time it's launched, but still have the various Input, Output, Stream mapping, and progress output? Can't quite find a loglevel that does that.
[10:27:16 CEST] <chungy> -hide_banner
[10:27:31 CEST] <xerox> chungy: oh sweet thank you!
[11:10:16 CEST] <woew> hi, I need to convert a 24 fps source to 25 fps with identical runtime (by repeating select frames). As a bonus I want to burn in correct timecode (@25 fps). How can I do it?
[11:12:11 CEST] <woew> Target is PAL DVD so the conversion to 25 fps would be implicit in my call (-target pal-dvd)?
[11:18:17 CEST] <QQ> Hello. I have a simple question: I have a few lossy files and I want to add a silence in them without losing quality. I found out I can create a new file with the "adelay" filter, and it works perfectly. My question is: does ffmpeg reencode the lossy file (mp3 or ac3) to add the silence when I use the adelay filter, or it copies the audio stream without reencoding it? Do I lose quality or not? Thanks a lot for any help!
[11:39:51 CEST] <chungy> QQ: ffmpeg will reencode and you will lose quality. You probably want more specialized tools (like mp3splt/mp3wrap) for this...
[11:40:23 CEST] <QQ> Thank you for your answer.
[14:09:39 CEST] <CustosL1men> hi
[14:10:25 CEST] <CustosL1men> I'm trying to build something that needs avcodec_get_context_defaults, avcodec_alloc_context and avcodec_open
[14:10:40 CEST] <CustosL1men> but these are not present in 2.6.3
[14:10:44 CEST] <CustosL1men> when last were they present
[14:11:07 CEST] <JEEB> see the apichanges file and hope that was documented in there
[14:13:18 CEST] <AstralStorm> hello, I'm having some trouble with aac (native) encoder initial padding
[14:13:37 CEST] <AstralStorm> it seems that it's not handled correctly - my output is longer by exactly one frame
[14:13:49 CEST] <AstralStorm> ffmpeg 2.7.1
[14:14:10 CEST] <techtopia> your better of demuxing source audio
[14:14:25 CEST] <AstralStorm> I'm not demuxing anything - import is done in audacity :)
[14:14:31 CEST] <techtopia> encoding with nero'd aac encoder or qaac
[14:14:38 CEST] <techtopia> then remux into encoded video
[14:14:43 CEST] <JEEB> AstralStorm: are you outputting wav with ffmpeG?
[14:14:54 CEST] <AstralStorm> no, I'm encoding mpeg 4 aac with libavcodec/libavformat
[14:15:07 CEST] <JEEB> yes, but how are you reading that encoded thing into audacity?
[14:15:13 CEST] <AstralStorm> ... import? :)
[14:15:29 CEST] <JEEB> and what does that do?
[14:15:39 CEST] <AstralStorm> audacity can handle aac, no idea how
[14:15:47 CEST] <JEEB> probably through lavf/lavc
[14:15:58 CEST] <JEEB> but I wouldn't be surprised if it ignores the encoding delay
[14:16:00 CEST] <AstralStorm> I'm assuming audacity is handling it correctly... maybe badly
[14:16:05 CEST] <JEEB> please file an issue with audacity
[14:16:25 CEST] <AstralStorm> how can I check if the pts are correct?
[14:16:44 CEST] <AstralStorm> according to mpeg 4, the initial padding frame should have negative pts
[14:16:53 CEST] <JEEB> yes
[14:17:05 CEST] <JEEB> and I almost forgot to ask your container, but I guess this is MPEG-4 Part 12?
[14:17:10 CEST] <JEEB> aka mp4
[14:17:36 CEST] <AstralStorm> yes
[14:17:37 CEST] <JEEB> anyways, if the format can note the container delay in some way, the decoded timestamp should be negative in lavc
[14:18:12 CEST] <AstralStorm> I'm assuming ffmpeg command line util will decode it fine now
[14:18:14 CEST] <AstralStorm> let's see
[14:18:27 CEST] <JEEB> if you decode with ffmpeg into wav that will not be correct
[14:18:30 CEST] <JEEB> funny enough
[14:18:47 CEST] <JEEB> because wav is considered a thing that can't take negative timestamps, so the timestamps are moved to begin from zero :D
[14:18:56 CEST] <JEEB> instead of cutting samples from the beginning
[14:19:03 CEST] <AstralStorm> uhm, shouldn't ffmpeg just eat the samples while decoding then?
[14:19:10 CEST] <AstralStorm> produce no output
[14:19:38 CEST] <JEEB> I only remember that a few months ago if you decoded into wav it would move the timestamps and conserve all of it
[14:19:48 CEST] <AstralStorm> oh my
[14:19:48 CEST] <JEEB> which is incorrect and leads to the wav files becoming longer with each generation
[14:19:55 CEST] <iive> Raz-:  join #ffmpeg-devel
[14:20:13 CEST] <Raz-> iive, okay will do
[14:25:41 CEST] <AstralStorm> let's see if faad does the right thing
[14:26:10 CEST] <AstralStorm> nope, faad says it's longer too
[14:26:10 CEST] <JEEB> faad doesn't as far as I know really read much encoding delay information at all
[14:26:18 CEST] <JEEB> it might just cut off a predetermined amount
[14:26:28 CEST] <JEEB> or nothing
[14:26:33 CEST] <AstralStorm> nah, faad -i said 8.021s instead 8s
[14:27:16 CEST] <AstralStorm> maybe the decoder does the right thing... or maybe libavcodec/libavformat writes wrong ADTS
[14:27:43 CEST] <AstralStorm> file says this: testpts.aac: MPEG ADTS, AAC, v4 LC, 48 kHz, stereo
[14:27:48 CEST] <JEEB> oh raw aac
[14:27:55 CEST] <JEEB> that has no way of actually signaling encoder delay
[14:27:57 CEST] <AstralStorm> not raw aac, *mpeg adts*
[14:28:14 CEST] <JEEB> well yes, that is usually noted as "raw aac"
[14:28:17 CEST] <AstralStorm> ahha
[14:28:38 CEST] <AstralStorm> ok, so I'll change the extension to m4a, potentially libavformat will guess mpeg-4 part 12 format
[14:28:40 CEST] <JEEB> there's two ways of having the AAC bit stream and that's one of them
[14:28:55 CEST] <JEEB> the other was whatever some broadcasters use in MPEG-tS
[14:29:46 CEST] <JEEB> the whole encoder delay thing was really messy until rather recently, and even then you have to assume that the decoder doesn't drop anything by itself and you can just use the information from the container
[14:30:04 CEST] <AstralStorm> hmm, so av_guess_format guesses raw aac for .aac
[14:30:10 CEST] <AstralStorm> pretty interesting choice
[14:30:24 CEST] <JEEB> because it's not specified in the bit stream itself, so pretty much all of the commercial things just cut off an arbitrary amount of the output
[14:30:44 CEST] <JEEB> in containers then you can handle it better, but you have to hope that the decoder doesn't cut anything off in that case
[14:30:52 CEST] <JEEB> lavc doesn't but I have no idea about other things
[14:31:35 CEST] <JEEB> also when you demux a stream into a raw bit stream, and then remux into mp4 or so you naturally lose the encoder delay since it can't be noted in the raw bit stream (AFAIK)
[14:32:14 CEST] <JEEB> L-SMASH's muxer should be able to mux aac while you set the encoder delay, if you need a simple app to create samples with
[14:32:21 CEST] <JEEB> I mean, simpler than ffmpeg :D
[14:33:11 CEST] <AstralStorm> doesn't ADTS actually have position information?
[14:34:02 CEST] <JEEB> I don't remember it having any kind of encoder delay / PTS thing
[14:34:09 CEST] <Paranoialmaniac> none
[14:34:18 CEST] <JEEB> well there you have it from the horse's mouth
[14:34:46 CEST] <JEEB> you can pretty much think of it as one type of raw bit stream for AAC
[14:35:39 CEST] <AstralStorm> indeed, ADTS doesn't have anything
[14:36:04 CEST] <AstralStorm> maybe one could trick it by setting the length to 0
[14:36:11 CEST] <AstralStorm> but I bet that's wrong and broken
[14:36:28 CEST] <AstralStorm> however, why libavformat guesses raw aac for .aac?
[14:37:17 CEST] <JEEB> uhh, that just makes sense?
[14:37:33 CEST] <JEEB> dot-aac should be raw AAC bit stream
[14:37:57 CEST] <JEEB> just like dot-hevc or dot-264 are for raw HEVC or AVC
[14:39:24 CEST] <AstralStorm> hmm ok
[14:39:56 CEST] <AstralStorm> I'll set it to .m4a and see
[14:45:00 CEST] <AstralStorm> which ffmpeg protocol do I need for MPEG-4 Part 12?
[14:45:10 CEST] <AstralStorm> as it is, ffmpeg says no URL protocols
[14:45:18 CEST] <AstralStorm> I've enabled only a few obvious ones
[14:54:00 CEST] <AstralStorm> hmm, it's not a protocol issue, seems there's no m4a muxer
[14:54:10 CEST] <AstralStorm> there's m4v and mp4 ones
[14:54:17 CEST] <JEEB> m4a should go through movenc methinks
[14:54:58 CEST] <AstralStorm> yes, but seems av_guess_format(nullptr, filePath, nullptr) w/ extension m4a doesn't find it
[14:55:14 CEST] <AstralStorm> and then libavformat grumbles about missing protocol
[14:55:20 CEST] <AstralStorm> there's also "ipod" muxer
[14:55:25 CEST] <AstralStorm> I think m4a goes through that
[14:55:40 CEST] <JEEB> not sure... lemme check what ffmpeg does when you try to output "m4a"
[14:56:09 CEST] <JEEB> ah yes
[14:56:14 CEST] <JEEB> seems to go through that one
[14:56:24 CEST] <JEEB> Output #0, ipod, to 'test.m4a':
[14:56:42 CEST] <AstralStorm> I didn't disable any muxers... is it not enabled by default?
[14:57:25 CEST] <JEEB> it should be
[15:04:02 CEST] <AstralStorm> oh, maybe it's trying to add rtp hint track
[15:05:53 CEST] <AstralStorm> I didn't specifically enable that though
[15:19:22 CEST] <AstralStorm> I'm not sure, but it seems there's a bug in av_match_name
[15:23:16 CEST] <Niska_> Hi i'm traing to play an m3u8 resource but aftware retriving the playlist the connection seems to be closed for ffplay
[15:23:27 CEST] <Niska_> Probably i need to keep the http connection alive to play the m3u8 segments
[15:23:38 CEST] <Niska_> If i don't use -headers $'Connection: keep-alive\r\n' the connection it is closed before the playlist download is completed
[15:53:35 CEST] <Swinehorn> hey guys. I'm compiling ffmpeg with VS2013 (--toolchain=msvc), and I want add libfdk-aac. Unfortunately fdk-aac doesn't have VS solution, I compiled .lib files by MinGW but this lib file is not valid for linking with ffmpeg
[15:54:33 CEST] <Swinehorn> can you please advice, cow to make compatible fdk-aac .lib file ?
[16:11:47 CEST] <xerox> I have an H.264 stream that is weird at about a minute from the end, the player dies when playing, but if I skip after it still plays but does not update the time, what tools can I use to see what the problem is and maybe fix it?
[16:13:44 CEST] <xerox> actually this happens in different files, is there a way to use ffmpeg to "straighten them up"? make the seeking work, e.g.
[16:15:07 CEST] <kepstin-laptop> xerox, if it's just a muxing problem, you could try using ffmpeg to remux the file, e.g. 'ffmpeg -i file.mp4 -c copy file-copy.mp4'
[16:15:26 CEST] <xerox> kepstin-laptop: funnily enough, I have already did that, except from flv to mp4
[16:15:39 CEST] <xerox> (indeed copying the audio and video streams)
[16:15:45 CEST] <kepstin-laptop> that won't help if any of the data in the streams themselves is messed up tho :/
[16:15:51 CEST] <xerox> yeah :(
[16:16:32 CEST] <xerox> ffmpeg seems to be able to do about a trillion different things, so I thought it was worth asking if maybe a sanity check for h264 was in there, somehow
[16:19:26 CEST] <kepstin-laptop> If you just want to check to see if ffmpeg sees any issue decoding a file, you can do something like 'ffmpeg -i file.mp4 -an -f rawvideo /dev/null'
[16:19:49 CEST] <xerox> is it possible to start from a specific timestamp?
[16:20:04 CEST] <kepstin-laptop> that'll decode the file and print any messages the decoder has
[16:20:19 CEST] <kepstin-laptop> sure, use -ss (probably as an input option, which means before the -i)
[16:20:46 CEST] <xerox> it's an hour long so even if it's fast it is probably easier to skip :D
[16:21:34 CEST] <kepstin-laptop> hmm. actually, would be faster to do "-f null -" instead of "-f rawvideo /dev/null" :)
[16:21:58 CEST] <xerox> they seem about as fast
[16:23:39 CEST] <xerox> it's very intense on the cpu, decoding this fast
[16:23:58 CEST] <AstralStorm> actually data itself should be fine
[16:24:03 CEST] <AstralStorm> what matters is pts/dts
[16:24:18 CEST] <xerox> I got some rrors!
[16:24:34 CEST] <AstralStorm> -c copy is not good enough, you need to remux it
[16:25:03 CEST] <xerox> http://pastebin.com/raw.php?i=z2AP4CQF
[16:26:15 CEST] <xerox> (this is on a 16 minute one)
[16:26:46 CEST] <kepstin-laptop> AstralStorm, not sure what you mean, -c copy does remux it. (it won't change any ptd/dts values tho)
[16:27:00 CEST] <AstralStorm> exactly, and you need to recalculate them
[16:27:09 CEST] <kepstin-laptop> xerox, looks like the video stream's actually corrupt in that file :/
[16:27:19 CEST] <xerox> is there anything that can be done?
[16:27:47 CEST] <kepstin-laptop> xerox, if you think the ffmpeg error recovery result looks ok, you could try re-encoding the video, I suppose.
[16:27:57 CEST] <xerox> sometimes I do get similar warnings when I go through the flv->mp4 remux
[16:28:08 CEST] <xerox> as in it says something about non-monotonous something
[16:28:16 CEST] <xerox> but it never made them unplayable before
[16:28:58 CEST] <kepstin-laptop> xerox, in this case, it looks like the non monotonic pts is a side-effect of the decoder hitting an error, not the main problem itself.
[16:29:59 CEST] <xerox> ok
[16:32:41 CEST] <xerox> thank you for the information, much appreciated
[16:43:17 CEST] <AstralStorm> hmm, about encoding some more with libavformat and broken aac encoder
[16:43:31 CEST] <AstralStorm> seems I get to set negative dts too
[16:43:55 CEST] <AstralStorm> but should I set pts to negative or to AV_NOPTS_VALUE?
[17:40:25 CEST] <AstralStorm> hmm, ffplay and avplay handle negative pts and dts correctly in MPEG-4
[17:40:41 CEST] <AstralStorm> almost no other applications do
[17:40:46 CEST] <blurider> How do I compile ffmpeg with neon support for HEVC?
[17:41:03 CEST] <AstralStorm> if there is any, --enable-neon will do
[18:00:50 CEST] <elon> I want to blend/overlay three or more equal-resolution and equal-length videos; here's an example of what I'm trying to accomplish: http://www.gfycat.com/ClumsyDesertedDassierat . In the docs, I found two video filters that might be able to accomplish said task, "blend" and "overlay", but I'm not really sure which of the two I should look in to. Can anyone point me in the right direction? (links to relevant docs/forum posts are fine too!)
[18:05:47 CEST] <durandal_1707> elon: its not completely obvious but looks both are or something similar is used can't tell from sample
[18:07:47 CEST] <blurider> AstralStorm: thanks. compiling now.
[18:25:12 CEST] <bencc> what container can I use for capturing a vp8 and opus RTP streams?
[18:30:51 CEST] <kepstin-laptop> bencc, probably matroska would make sense.
[18:38:34 CEST] <bencc> kepstin-laptop: mkv?
[18:52:38 CEST] <AstralStorm> well, it seems the aac native encoder in 2.7.1 is pretty meh quality :)
[18:52:48 CEST] <AstralStorm> well, compared to excellent fdkaac
[18:55:06 CEST] <JEEB> there have been some improvements lately + there's even bigger patches on the trac, waiting for the author to post a final version on the mailing list
[19:00:19 CEST] <AstralStorm> nice
[19:00:42 CEST] <AstralStorm> funny thing, my ISO-compatible files are misdecoded everywhere... except by faad :)
[19:01:09 CEST] <AstralStorm> fdkaac encoded file with -G 1 and 2 is also misdecoded by faad
[19:02:58 CEST] <Niska_> Can avplay keep-alive http connection?
[19:06:43 CEST] <AstralStorm> you mean ffplay?
[19:06:49 CEST] <AstralStorm> I don't think so
[19:07:07 CEST] <AstralStorm> the native aac encoder seems to be using long blocks almost always
[19:09:20 CEST] <Niska_> AstralStorm: Yes ffplay
[19:21:59 CEST] <nyuszika7h> why does vf=subtitles take like 2-3 minutes every time before the encode starts?
[19:45:07 CEST] <Hi-Angel> While building ffmpeg from source, I am getting a bunch of undefined references in the linking step :/
[19:45:27 CEST] <AstralStorm> Hi-Angel: we take no responsibility for broken environments :)
[19:46:05 CEST] <Hi-Angel> AstralStorm, well, since the «configure» step worked just fine, it seems the problem with ffmpeg
[19:46:22 CEST] <AstralStorm> nope, configure step in ffmpeg is some pretty dumb script
[19:46:30 CEST] <AstralStorm> it does what it's told and looks only at headers
[19:46:58 CEST] <AstralStorm> it's not autoconf
[19:50:03 CEST] <Hi-Angel> AstralStorm, either way, the undefined references are refer to function of ffmpeg, like «av_log» — so it's a problem not with my environment.
[19:51:18 CEST] <AstralStorm> that is interesting; which ffmpeg version?
[19:51:30 CEST] <AstralStorm> also which linker?
[19:51:31 CEST] <Hi-Angel> 2.7
[19:52:11 CEST] <Hi-Angel> Hm, I guess the linker is ld. I am not sure, should I mention it, but I compiling with «-flto»
[19:52:18 CEST] <AstralStorm> yes, you should've
[19:52:23 CEST] <AstralStorm> that's potentially not supported
[19:52:58 CEST] <Hi-Angel> Ah, the linker is «gcc»
[19:54:12 CEST] <Hi-Angel> Not supported? Why? o.o Aren't it is the performance critical app, which ought to be one of the first to be compiled with -flto?
[19:54:27 CEST] <Hi-Angel> s/app/libs
[19:55:01 CEST] <kepstin-laptop> my experience with ffmpeg is that it does compile with -flto on 64bit linux, but it probably depends on which options you have enabled.
[19:56:03 CEST] <Hi-Angel> kepstin-laptop, well, nothing especial, «-O3 -march=native -flto -fno-stack-protector». But okay, let me try recompile without «flto»
[19:57:30 CEST] <kepstin-laptop> do note that when using -flto you probably have to make sure it's using the linker plugin when running ar,ranlib, etc.
[19:57:49 CEST] <kepstin-laptop> oh, no, i was mistaken, doesn't work with lto for me
[19:58:40 CEST] <Hi-Angel> 9
[19:58:53 CEST] <kepstin-laptop> the errors I get are apparently due to lto not handling inline assembly well, i think
[19:59:29 CEST] <Hi-Angel> Is it undefined references?
[20:13:40 CEST] <Hi-Angel> Yay, without «-flto» it built _____
[20:22:16 CEST] <Hi-Angel> Hm… Interestingly, I found in the «configure» options an option «--enable-lto». I'll try to use, let's see what happen
[20:26:07 CEST] <OneSync1983> hello
[20:26:20 CEST] <OneSync1983> Good day/evening everyone
[20:27:27 CEST] <OneSync1983> I'm kind of new here so, i don't know the exact rules to follow around here
[20:28:36 CEST] <c_14> Ask your question, if you have console output upload it to a pastebin service.
[20:29:12 CEST] <OneSync1983> Oh great! Well i have one question
[20:29:49 CEST] <OneSync1983> Is it possible to trim a video on a certain audiolevel threshold?
[20:30:44 CEST] <c_14> What do you mean? Cut the video so it stops when it reaches a certain audio volume?
[20:31:51 CEST] <OneSync1983> exactly, so i have a audio fade-out but the video can already be black at that point. So -blackdetect doesn't solve it for me i think
[20:34:48 CEST] <Niska_> Hi I've a very low probe score on an m3u8 segment Probing mpegts score:-1094995529 can avoid probing or directly forcing it
[20:34:59 CEST] <c_14> OneSync1983: maybe silenceremove with -shortest
[20:37:21 CEST] <OneSync1983> c_14: okay i will look into that
[20:40:11 CEST] <OneSync1983> But are both of my streams not the same length at origin?
[20:41:30 CEST] <OneSync1983> I thought something more in the way of detecting a certain audio level, which also could be used to trim audio files. But then also use this calculation to trim the entire file
[20:42:06 CEST] <Niska_> Why ffplay doesn't probe mp4 pointed in m3u8
[20:42:16 CEST] <c_14> Yes, silenceremove will find the "silence" at the end of the audio file, and -shortest should then cut the video stream at that point.
[20:43:15 CEST] <OneSync1983> Oh that sound great indeed!
[20:44:16 CEST] <OneSync1983> Thanks for your thinking c_14
[20:47:30 CEST] <Hi-Angel> Yay, compilation with «--enable-lto» works fine! But after I tried to use the build lib, I am getting in a player «h264 aren't supported»; what? :/
[20:47:56 CEST] <c_14> Decoding h264?
[20:48:27 CEST] <c_14> That should work unless you explicitly disabled things in your configure.
[20:48:32 CEST] <c_14> Are you sure it's linking correctly?
[20:48:45 CEST] <Hi-Angel> Yep.
[20:48:59 CEST] <c_14> To which question?
[20:50:36 CEST] <Hi-Angel> I haven't disabled it; to be honest I don't even see anything h264 related except of options that seems to refer to a side tools, or libs… Not sure… And yes, it likied correctly, at least with no errors
[20:51:15 CEST] <c_14> There's stuff like --disable-protocol --disable-codec etc. also --disable-all and --disable-everything
[20:51:57 CEST] <Hi-Angel> I only used «--disable-programs» and «--disable-docs»
[20:52:30 CEST] <c_14> Is your program linking statically or dynamically?
[20:52:46 CEST] <kepstin-laptop> enabling lto build disables some of the inline assembly
[20:52:50 CEST] <Hi-Angel> It is a shared lib «libavcodec»
[20:52:56 CEST] <kepstin-laptop> dunno whether that affects the h264 decoder.
[20:53:17 CEST] <c_14> kepstin-laptop: It might slow it, it shouldn't disable it.
[20:53:23 CEST] <Hi-Angel> Okay, anyway, is there a way to enable it explicitly?
[20:53:34 CEST] <c_14> --enable-decoder=h264
[20:53:41 CEST] <Hi-Angel> Okay, thank you!
[20:53:50 CEST] <c_14> configure should tell you if it's enabled though
[20:56:02 CEST] <Hi-Angel> Hm… Yep, I see — with the old options configure shows in the list of enabled decoders «h264»
[20:56:53 CEST] <Hi-Angel> Okay, I'll try then recompile without lto.
[21:13:45 CEST] <Bertl> greetings! is there a simple way to check the actual framerate (i.e. the FPS) with ffplay?
[21:14:17 CEST] <Bertl> i.e. not the framerate given in the movie, but the framerate achieved when playing it back?
[21:22:29 CEST] <kepstin-laptop> actual fps is a tricky subject, since many formats support variable-framerate streams
[21:23:59 CEST] <kepstin-laptop> could probably do something with ffprobe and the -show_frames option, then calculate the average time between pts values with a script of some sort.
[21:25:21 CEST] <Hi-Angel> Interesting thing: while with flto the «libavcodec.so» is H11Mb, without flto it is& 50 Mb! D:
[21:26:28 CEST] <Bertl> kepstin-laptop: the reason I want to check is that I'm currently testing playback with a 60Hz movie and it looks a little odd and jerky
[21:26:54 CEST] <Bertl> but ffplay does not complain that the decoding would be too slow or something like that
[21:27:08 CEST] <Bertl> actually it doesn't say anything unusual
[21:27:09 CEST] <kepstin-laptop> Bertl, that's more likely to be an issue with synchronizing the frame updates to the video card display refresh. Are you on linux?
[21:27:22 CEST] <Bertl> yes, Linux it is
[21:27:46 CEST] <kepstin-laptop> what graphics card? Have you tried mplayer/mpv/whatever with an opengl video output?
[21:27:59 CEST] <Bertl> ati with glamor
[21:28:20 CEST] <Bertl> mplayer is too slow to decode it, I failed to mention, it is also 4k :)
[21:28:55 CEST] <kepstin-laptop> ... hmm, you're probably not gonna have a great experience with that. I never got the open source ati drivers with glamor to get smooth video going even on my 7850.
[21:30:12 CEST] <kepstin-laptop> hmm. or maybe i'm getting different computers confused. it either wasn't smooth or i didn't get working vsync at all - one or the other.
[21:31:14 CEST] <Bertl> so how would that ffprobe/-show_frames work?
[21:31:37 CEST] <kepstin-laptop> (i'm not sure how mplayer would be 'too slow to decode it', since mplayer and ffplay should both be using the same ffmpeg libraries to do the decoding)
[21:32:02 CEST] <Bertl> probably I'm using the wrong mplayer options :p
[21:32:22 CEST] <Bertl> at least mplayer tells me that my system is too slow to play the movie
[21:32:35 CEST] <kepstin-laptop> Bertl, when you use ffprobe -show_frames it should include the pts value for each frame. You could feed that output into a script that calculates the average delta and maybe the std dev.
[21:33:08 CEST] <Bertl> so I run that in parallel to the ffplay, yes?
[21:33:14 CEST] <kepstin-laptop> the std dev value would tell you if there's a lot of timing jitter with the frames. if it's low, the video's ok so it's a display problem
[21:33:25 CEST] <kepstin-laptop> you'd pipe the output of ffprobe into a script, yeah
[21:33:32 CEST] <kepstin-laptop> dunno if there's an easier way to do that.
[21:34:41 CEST] <kepstin-laptop> but if mplayer, which should in theory be using the same decoder as ffplay, is printing the 'your system is too slow' message, that means that the video decoder isn't keeping up with the audio speed
[21:34:47 CEST] <kepstin-laptop> so it would be displaying at <60fps
[21:35:01 CEST] <kepstin-laptop> (could be anything in the video path, really)
[21:35:17 CEST] <kepstin-laptop> i dunno how good the a/v sync in ffplay is, it might just not have noticed the issue.
[21:36:09 CEST] <Bertl> I think the problem with mplayer is, that in my distro, without special options, it uses 100% of one CPU, where ffplay OTOH, uses all CPUs evenly
[21:37:18 CEST] <kepstin-laptop> huh, weird. that means that it's either explicitly disabling the multithreaded decoder, is using a different version of ffmpeg (or maybe even libav, depending on distro), or is bottlenecking somewhere else (bad video output selected maybe?)
[21:37:42 CEST] <Bertl> maybe, how to debug?
[21:37:49 CEST] <Bertl> (probably wrong channel :)
[21:51:39 CEST] <dami0> is there a way to output to standard output when recording/
[21:51:41 CEST] <dami0> ?*
[21:57:11 CEST] <BtbN> -
[21:58:54 CEST] <dami0> i tried that, it just died
[22:01:05 CEST] <dami0> oh, i googled and it turns out i need to specify format. derp.
[22:01:10 CEST] <dami0> thanks
[22:16:26 CEST] <EO_> Why is the -timeout option not being respected?  http://pastebin.com/Yf1Wt0qL
[22:17:40 CEST] <EO_> It's documented as being available here: https://www.ffmpeg.org/ffmpeg-all.html#http
[22:20:28 CEST] <bencc> can ffmpeg handle webrtc packets (after DTLS decryption)?
[22:21:26 CEST] <BtbN> EO_, the documentation seems to be wrong on that parameter.
[22:21:37 CEST] <BtbN> There is no timeout option in the http format.
[22:21:55 CEST] <EO_> :(
[22:23:25 CEST] <EO_> I'm looping over a cheap webcam which can sometimes hang on an HTTP request...and that kills the whole video stream.  Timeout would have been perfect.
[22:24:33 CEST] <BtbN> use curl or something for the http, and just pipe it into ffmpeg
[22:25:11 CEST] <EO_> ffmpeg can take a continuous stream of concatenated JPEG data on stdin?
[22:25:23 CEST] <BtbN> it can take everything it would download via http from stdin
[22:25:29 CEST] <EO_> neato!
[22:25:40 CEST] <BtbN> you might have to tell it what it is though, if it's not obvious
[22:26:36 CEST] <EO_> On another subject, have you guys had to deal with cheap chinacam x264 encoded streams?  If so, any advice on options to make the streams not present errors all the time?
[22:27:26 CEST] <BtbN> chinacam x264?
[22:27:27 CEST] Action: EO_ is doing jpeg snapshot looping because the x264 stream decodes atrociously in ffmpeg and vlc...
[22:28:38 CEST] <EO_> yeah...lemme paste you some sample errors
[22:32:05 CEST] <BtbN> you mean h264 i guess?
[22:32:24 CEST] <EO_> yes.  sorry about lag, had to kill a spider.  :)
[22:38:04 CEST] <EO_> http://pastebin.com/2DXJy231 <-- there.  this is a sample chinacam experience.  both of mine behave like this (different models).
[22:38:32 CEST] <BtbN> that looks like one royaly broken h264 stream
[22:38:43 CEST] <BtbN> if it comes from a hardware camera, i don't think there's much you can do about it
[22:40:46 CEST] <EO_> yeah, I'm doing a "-c copy" sample right now.  Even in that mode it's complaining about missing RTP packets!
[22:41:04 CEST] <EO_> What's weird is the software they ship with these decodes the stream perfectly.
[22:41:09 CEST] <EO_> (ActiveX plugin)
[22:42:12 CEST] <BtbN> Well, missing RTP packets don't have anything to do with h264
[22:42:24 CEST] <BtbN> if it's missing half of the streams package, of course the image is broken
[22:47:32 CEST] <EO_> yeah, I guess I need to diddle a bit more to see how much of this is transport errors and how much is encoding errors.
[23:22:12 CEST] <manfromafar> haaaa time to learn the cli encoding methods and how to get everything nice and neat
[00:00:00 CEST] --- Thu Jul 23 2015


More information about the Ffmpeg-devel-irc mailing list