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

[burek]

[00:30] Action: klaxa is listening to Louise (CV: Kugimiya Rie) - Gomen ne
[07:08] <stephanedev> hi everyone. i wrote some code using ffmpeg C API to stream a video generated in real time over RTP, but on the decoding side, there are ~2s of latency.
[07:09] <stephanedev> does anyone know how to get rid of that latency?
[07:10] <stephanedev> is it due to my use of avformat_open_input which may scan the received stream to guess the format?
[07:10] <stephanedev> avformat_open_input is called with the sdp file generated by the encoding side
[07:11] <stephanedev> codec is vp8
[07:12] <stephanedev> i have found several articles related to the ffmpeg command line parameters but i am having a hard time finding anything about how to get rid of this latency when using the ffmpeg C API
[07:18] <stephanedev> when streaming the output of the libvpx encoder over tcp and then decoding it, there is no latency
[07:20] <stephanedev> from what i have read, i would think the latency occurs on the decoding side which buffers some input to guess the stream format. is it correct?
[07:34] <gudy> Hi, I'm running ffprobe on a ts segment, and I'm not seeing the same number of video frames compared to video packets. In particular, the first packet of type video has the "K" flag, but the first video frame is not a key frame (and their pts differ). It seems that the first few video frames are not being considered. What could explain that ?
[10:28] <Bor0> hello, I'm experiencing the same exact issue as http://stackoverflow.com/questions/14452817/strange-sound-produced-by-ffmpeg-and-sdl. could anyone give a hint about it?
[10:51] <mxmx> who is alive?
[10:52] <durandal_1707> noone
[10:53] <mxmx> heh
[10:59] Action: relaxed kills durandal_1707 
[11:02] <mxmx> so i changed my mind, i rather add a png image to the video instead a subtitle
[11:03] <mxmx> "movie=logo.png" <-- can logo.png be a path to the image?
[11:03] <durandal_1707> yes
[11:03] <mxmx> "movie=/path/to/image.png"?
[11:04] <durandal_1707> yes
[11:05] <mxmx> ok
[11:32] Last message repeated 1 time(s).
[11:32] <mxmx> what is wrong with this command
[11:32] <mxmx> ffmpeg -i video.mp4 -vf "movie=/home/www-data/mysite.com/public_html/include/settings/logo.png [logo]; [in][logo] overlay=main_w:main_h [out]" -acodec libmp3lame -ar 22050 -ab 32 -f flv video.flv";
[11:46] <relaxed> hmm, the bot is gone.
[11:46] <relaxed> mxmx: paste your command and all output to pastie.org
[11:51] <mxmx> ok sec
[11:56] <mxmx> http://pastie.org/6086277
[11:58] <relaxed> that's impossible to read, try again
[11:58] <mxmx> i am using putty and thats how it displays it
[11:58] <mxmx> sec
[11:59] <mxmx> yeah its stupid putty
[12:00] <mxmx> these are teh error messges tough
[12:00] <relaxed> Then `command` 2>ffmpeg.log  (and upload to dropbox or something.
[12:00] <mxmx> http://pastie.org/6086299
[13:12] <theos> so i finally compiled x264 and everything else :D
[13:13] <theos> now i have to learn how to use it properly for max compression
[13:15] <JEEB> 1) encode 2500-5000 frame clips with crf values starting from 23, and going up if it still looks good enough for you, and down if it looks bad for you - until you hit the magical "highest value that still looks good for you" crf value
[13:15] <JEEB> 2) pick the slowest -preset you can still manage time-wise
[13:15] <JEEB> 3) ???
[13:15] <JEEB> 4) profit
[13:15] <JEEB> yes, that's it
[13:17] <theos> hi JEEB :)
[13:18] <JEEB> and yes, the outlook of the same crf value will be somewhat different between settings (presets), but the tweaking you might or might not need should be relatively small
[13:20] <JEEB> and for the ~1-2 minutes of input you'll probably want to learn about -ss and -t , the first one lets you seek and then -t limits how long will be encoded
[13:20] <theos> is msmpegv2 better?
[13:21] <JEEB> what?
[13:21] <theos> i assume h264 is vcodec?
[13:21] <JEEB> H.264 is a format, called h264 in the libavcodec/ffmpeg limbo. libx264 is an encoder for it
[13:21] <theos> or should i rtfm?
[13:21] <theos> oh
[13:22] <JEEB> and no, there are no better encoders than libx264 for lossy, and at times nowadays even for lossless encoding
[13:22] <theos> wont ffmpeg use x264 by default
[13:23] <JEEB> to be honest, no idea -- they have now some defaults depending on the type of container you start outputting to, but I've never trusted ffmpeg's automatic selection of "what you probably want"
[13:23] <theos> says Stream #0:0 -> #0:0 (mpeg4 -> mpeg4)  Stream #0:1 -> #0:1 (mp3 -> libmp3lame)
[13:24] <JEEB> so the mpeg4 (MPEG-4 Visual, what xvid and divx "conformed" to) encoder got used and audio got re-encoded with lame into mp3
[13:25] <JEEB> sounds like you tried to output into the avi container
[13:25] <JEEB> at least defaults-wise
[13:25] <theos> yes i tried "ffmpeg -i input.avi output.avi" :D
[13:25] <JEEB> yes, don't do that, in the worst case you will get mpeg-1 at 200kbps rubbing its balls against your face
[13:26] <theos> so what should i use?
[13:26] <JEEB> I would prefer you to move to some container that can handle b-frames properly, and then just set video and audio formats to whatever you need
[13:27] <JEEB> ffmpeg -i input.derp -c:v libx264 -crf 23 -preset medium -c:a copy out.mkv
[13:27] <JEEB> now take a look at the first four lines I listed
[13:28] <theos> increase crf and decrease 1 when its  not looking good?
[13:28] <theos> ah its called libx264 :/ i was using h264 and it was giving error
[13:28] <JEEB> also use -ss to seek to some timestamp that has content in it, and -t to then limit it to a couple of minutes so you can actually do some testing
[13:29] <JEEB> h264 is the name for the internal decoder methinks, libx264 is the library that handles H.264 encoding, which you can build ffmpeg with
[13:31] <theos> can the output be avi too?
[13:31] <JEEB> in theory yes, but I will bludgeon you to hell for it. AVI does not take b-frames in well, and that was found out with MPEG-4 Visual already. But at the time we had no alternatives, really -- so people pretty much got used to hacking b-frames into AVI
[13:31] <JEEB> let's not continue that shit in the 21st century, thank you
[13:32] <theos> haha ok. so mkv is a good option?
[13:32] <JEEB> use mkv, mp4 or flv -- whatever floats yer boat. As long as it's not AVI
[13:32] <theos> thanks a lot :)
[13:32] <JEEB> that said, both mp4 and flv tend to limit audio formats and don't support most commonly used subtitle track formats, so mkv is the current "supermarket of containers"
[13:33] <theos> so mkv it is!
[13:35] <DEATH> 9 out of 10 pirates use MKV
[13:35] <DEATH> Even hardware makers acknowledged it
[13:35] Action: theos hides
[13:35] <DEATH> Only Apple and Microsoft continue to ignore it with extreme prejudice
[13:36] <theos> i dont use either of those ^^
[13:36] <DEATH> Samsung likes MKV
[13:36] <burek> can ffmpeg use something like this: ffmpeg -f image2 -i image%03d.tiff -c copy output.WHAT ?
[13:36] <theos> i have a samsung android phone if that counts :)
[13:37] <burek> meaning is there any video format that stores tiff images in the video, just like jpegs can be saved in mjpeg
[13:37] <JEEB> burek, I would guess that's possible, but I have no idea what container takes in tiff
[13:37] <JEEB> try mkv?
[13:37] <JEEB> lol
[13:37] <burek> :)
[13:37] <burek> ok, ill just re-encode :) its safer :)
[13:37] <JEEB> yeah
[13:37] <theos> does h264 have an audio codec?
[13:37] <JEEB> it's a video format
[13:37] <theos> :(
[13:38] <theos> should i use mp3 for audio?
[13:38] <JEEB> MPEG-4 family does have an audio format, but to be honest if your input is mp3 you might as well keep it that way
[13:38] <JEEB> aka -c:a copy
[13:38] <JEEB> aka "just copy the audio from the input"
[13:38] <theos> yes i understand copy. thanks :)
[13:39] <theos> its 160kbps though. 128kbps is enough for me. but i dont think it will have much difference on the output
[13:39] <JEEB> yes, that kind of difference is miniscule compared to the video bit rate
[13:39] <JEEB> and it will not make an already highly compressed audio clip any better
[13:40] <burek> try aac+ to get as low as 32 kbps ^^
[13:40] <theos> is it lossless?
[13:40] <burek> right..
[13:40] <burek> :D
[13:40] <theos> :)
[13:42] <JEEB> in general I tend to just copy audio tracks over if they're not grossly oversized compared to what they are -- as in, lossy tracks in pretty much all cases will just get copied over, if it's something lossless (PCM from DVDs or BDs, or TrueHD etc. from the BDs) I encode it with whatever I deem good enough for that job [aotuv's vorbis, fdk-aac's AAC, some lossless format possibly?]
[13:42] <JEEB> also, depends highly on wtf the stuff will get played on
[13:43] <DEATH> Good luck getting "hardware players" to recognize Vorbis or FLAC, heh
[13:43] <JEEB> surprisingly both are supported in some things
[13:43] <JEEB> but do note that I don't even know what the person is encoding for
[13:43] <JEEB> and neither do you
[13:46] <DEATH> Yeah
[13:46] <DEATH> PC playback with MPC-HC = encode any format you like
[13:46] <DEATH> MPC-HC or other good software player
[13:46] <DEATH> I'm having great fun with Samsung TV vs "acquired" encodes
[13:47] <DEATH> Some H.264 configs just won't decode
[13:50] <someone-noone> hello! What is syntax for <rational> values?
[13:51] <theos> i use my pc for every multimedia purpose
[13:55] <theos> why is the output file longer than the input file? :) conversion isnt complete. maybe it will get fixed
[16:55] <Diogo> hi i having problems using ffmpeg and threads..
[16:55] <Diogo> ffmpeg -threads 1 (guarantees that only one thread is running)?
[16:56] <Diogo> i'm having one more than one thread
[17:05] <Diogo> i'm doing something wrong?
[17:33] <kittonian_> morning all
[17:35] <kittonian> i am trying to figure out the command line to turn an MKV into an M4V for AppleTV3 while converting DTS surround sound to AC3 surround sound at a bitrate 640
[17:35] <kittonian> i've been using Handbrake and most of the time it works just fine, but there are some files that Handbrake will not work with for some reason
[17:46] <kittonian> will this accomplish what I'm searching for? ffpmeg -i input.mkv -c:v libx264 -crf 18 -acodec ac3 -ac 6 -ab 640k output.m4v
[17:48] <Mavrik> if you're trying to re-encode video and audio to H.264/ac3 then yes
[17:48] <Mavrik> :)
[17:48] <Mavrik> why are you reencoding video though?
[17:49] <kittonian> trying to convert an MKV with DTS surround sound into an M4V for Apple TV 3
[17:49] <Mavrik> ah
[17:49] <Mavrik> there's probably no need to reencode video
[17:49] <Mavrik> (afaik AppleTV can handle pretty much any H.264)
[17:49] <kittonian> i've been using Handbrake to do it but on some MKV files it doesn't output correctly
[17:50] <Mavrik> so replace "-c:v libx264 -crf 18" with "-codec:v copy"
[17:51] <kittonian> will that make sure the video quality isn't touched?
[17:51] <kittonian> that's my goal
[17:51] <kittonian> i'm trying to have the highest quality video and audio possible in an ATV3 compatible file
[18:16] <frnk1> does anyone here knows a codec to make ffmpeg _demodulate_ a wav file containing the recorded sound of e.g. a modem connection/fax/datasette
[18:17] <frnk1> i'm not that familiar in whistling modem sounds like the terminatrix in T3, but there might only be some parameters, and then some bytestream, txt-file, should result
[18:18] <kittonian> Mavrik: hmm, got an error using -codec:v copy but my string seems to be working
[18:19] <Mavrik> "an error"
[18:19] <Mavrik> ?
[18:19] <kittonian> Could not write header for output file #0 (incorrect codec parameters ?): Operation not permitted
[18:20] <Mavrik> the actual error is probably written a line or few higher
[18:20] <kittonian> Stream #0:0: Video: vc1 (WVC1 / 0x31435657), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 23.98 fps, 90k tbn, 48003.07 tbc (default)
[18:20] <kittonian>     Stream #0:1(eng): Audio: ac3 (ac-3 / 0x332D6361), 48000 Hz, 5.1, fltp, 640 kb/s (default)
[18:20] <kittonian> Stream mapping:
[18:20] <kittonian>   Stream #0:0 -> #0:0 (copy)
[18:20] <kittonian>   Stream #0:1 -> #0:1 (dca -> ac3)
[18:28] <gudy> Hi, I'm running ffprobe on a ts segment, and I'm not seeing the same number of video frames compared to video packets. In particular, the first packet of type video has the "K" flag, but the first video frame is not a key frame (and their pts differ). It seems that the first few video frames are not being considered. What could explain that ?
[18:39] <Mavrik> gudy: it's quite possible the decoder drops input frames until it gets an I-frame
[18:40] <Mavrik> are you looking at frames (After decode) or packets (before decode)?
[18:52] <casimiro> Hi all, I am trying to broadcast through UDP an mpeg-ts received from TCP. For what I have tested, I need to parse the incoming stream in order to deliver the mpeg packets correctely. I have tried to implement the parse by my self, but it's getting too complicated. I would like to know if anybody could give me some lead in how to use libav to do such parse.
[18:53] <Mavrik> casimiro: do you have to do anything else besides pass-through of mpeg-ts?
[18:54] <casimiro> No
[18:54] <Mavrik> well, you could probably just do
[18:54] <Mavrik> ffmpeg -i <your tcp input> -codec copy -f mpegts udp://<output-ip>:<output-port>
[18:56] <casimiro> Thank you Mavrik! But actually I am developing a program to do that. Do you know if I could have something similar with some lib ?
[18:56] <Mavrik> yeah, you can use libavformat calls to do that
[18:56] <Mavrik> casimiro: grab ffmpeg source and check doc/examples/demuxing_muxing.c
[18:57] <Mavrik> that's essentialy what you have to do
[18:57] <casimiro> Thank you so much for your help!
[19:02] <gudy> Mavrik: both
[19:03] <gudy> Mavrik: so the first video packet has the "K" flag, but will not show up as a video frame
[19:05] <gudy> here are the frames : http://pastebin.com/bBvi7q3X
[19:05] <gudy> and the packets : http://pastebin.com/pt1BBAVa
[19:24] <kittonian> is there a difference between -codec:v copy and -vcodec copy?
[19:27] <JEEB> kittonian, -c:v and -codec:v are a newer way of setting it
[19:41] <kittonian> JEEB: cool thanks
[19:41] <kittonian> i'm trying to figure out why when i set -crf 18 it still shows q=23 during encoding
[19:41] <JEEB> probably unrelated
[19:42] <JEEB> as long as libx264 outputs crf=18 , all's fine
[19:42] <kittonian> i read through the docs and it said to use -qp instead of -crf
[19:42] <JEEB> -qp should never be used by end users
[19:42] <kittonian> oh ok
[19:42] <JEEB> or well, it can be used with other encoders than libx264
[19:42] <JEEB> it's constant quant
[19:42] <JEEB> which is what that q probably shows
[19:42] <JEEB> libx264 on the other hand
[19:42] <JEEB> has something better
[19:42] <JEEB> crf
[19:42] <kittonian> gotcha
[19:43] <JEEB> before you basically either had 2pass abr or 1pass constant quant
[19:43] <JEEB> now you have 1pass crf which takes the better sides of both
[19:43] <JEEB> one pass, but still distributes bits better than just setting a constant quantizer \o/
[19:44] <JEEB> thus being the closest to "constant quality" we've ever been
[19:44] <kittonian> makes sense
[19:44] <kittonian> i'm trying to convert an MKV with DTS surround to an M4V for Apple TV3 but retain the highest possible video and audio quality.
[19:44] <kittonian> right now i'm using | ffmpeg -i input.mkv -c:v libx264 -crf 18 -acodec ac3 -ac 6 -ab 640k output.m4v
[19:45] <JEEB> if the input is something that the apple tv3 can play back as-is without re-encoding, then that'd be the best way
[19:45] <JEEB> but that would depend on what exactly is in there :)
[19:46] <JEEB> anyways, I'd recommend going over with -c:v copy once
[19:46] <JEEB> (and audio being re-encoded)
[19:46] <kittonian> i tried -codec:v copy and it returned an error and wouldn't work
[19:46] <JEEB> k
[19:46] <kittonian> i would love to not have to transcode the video. that was my goal
[19:47] <kittonian> and it's already in h.264 format
[19:47] <JEEB> yeah, the problem becoming in what profile/level the apple tv3 likes its stuff
[19:47] <kittonian> ffmpeg threw the error - Could not write header for output file #0 (incorrect codec parameters ?): Operation not permitted
[19:47] <JEEB> oh
[19:47] <JEEB> would probably want to pastebin the whole log there
[19:50] <kittonian> http://pastebin.com/wmvZiAd0
[19:51] <JEEB> [ipod @ 0x7feac2843e00] track 0: could not find tag, codec not currently supported in container
[19:51] <JEEB> Stream #0:0: Video: vc1 (Advanced) (WVC1 / 0x31435657)
[19:51] <JEEB> so yeah, that's VC-1
[19:52] <kittonian> i'm not familiar with VC-1
[19:52] <JEEB> which actually /does/ have mappings for "mp4"-style containers but I'd still be surprised if your Apple thingy could play it :)
[19:52] <kittonian> i assume that's a different codec than H.264
[19:52] <JEEB> it's a format from Microsoft that tried to be royalty-less for a moment and got onto both HD-DVD and Blu-ray specs
[19:52] <kittonian> ahh
[19:52] <JEEB> ...and then promptly got itself dragged into a patent pool of MPEG-LA's
[19:53] <JEEB> Warner Bros IIRC have a long history regarding using VC-1 with their discs
[19:53] <JEEB> basically VC-1 is Windows Media Video 3 on steroids
[19:54] <kittonian> hmm, interesting. alright, well, do you see anything I should be doing to improve video and/or audio quality (as well as speed of transcoding) in my command line?
[19:54] <kittonian> oh, and i want to ensure that it doesn't screw with the picture at all (i.e. exact same pixel dimensions, no cropping, etc.)
[19:54] <kittonian> in Handbrake i was doing it strict
[19:55] <JEEB> ffmpeg doesn't do that by default, unlike many other things it might poke if you don't set them (such as codecs f.ex.)
[19:55] <JEEB> crf keeps the quality more or less constant with those settings so quality wise as long as you're around the highest crf value that still looks good to you, you should be fine
[19:55] <JEEB> 23 is the default and if it looks good you go higher, and if it looks bad you go lower
[19:56] <kittonian> from what i've read 18 is visually lossless
[19:56] <JEEB> depends on who is looking at it and what the resolution is etc.
[19:56] <kittonian> this is all 1080p movie stuff
[19:56] <JEEB> then i'd say you're on the very low end of the line
[19:57] <JEEB> as in, you could raise it gratuitiously by a few before you would get anything else but a free minification
[19:57] <JEEB> also, regarding compression/speed settings x264 has you covered: http://mewiki.project357.com/wiki/X264_Settings#preset
[19:57] <kittonian> ok, so i'm more than safe
[19:57] <JEEB> you can set these with -preset
[19:57] <JEEB> yes, you're safe but you might be wasting a nice amount of bits
[19:58] <kittonian> and do i no longer need the -f mp4 directive?
[19:58] <kittonian> i've seen that in a couple of examples but i'm not using it
[19:58] <JEEB> if your output file name includes mp4 or m4v, nope
[19:59] <JEEB> ffmpeg looks it automagically
[19:59] <kittonian> great. that's handy
[19:59] <kittonian> the only other thing had to do with the -profile option
[19:59] <JEEB> yeah, profile/level (and making sure not too many refs get used)
[19:59] <kittonian> i looked at atv3's specs and it says high or main with high quality audio is supported
[20:00] <kittonian> but apple's specs don't even mention that it supports AC3 surround at 640k
[20:00] <kittonian> and it does just fine
[20:00] <JEEB> looking at every apple device since the 3GS (not looking at the apple tvs), they've all actually supported high profile, level 4.1 content
[20:00] <kittonian> and is that the default?
[20:00] <JEEB> just that itunes usually barfed at it
[20:01] <JEEB> libx264's default is high profile, yes -- and the level is set by your preset's settings
[20:01] <kittonian> since i didn't use a preset, should i be setting the level directly?
[20:01] <JEEB> basically profile = feature set, and level = how much memory the decoder needs to decode, reference frame count
[20:01] <JEEB> uhh
[20:01] <JEEB> default is preset=medium
[20:01] <JEEB> then you can set it to be either faster or slower
[20:01] <kittonian> what's the better way to do it?
[20:01] <JEEB> ?
[20:02] <kittonian> for better looking/sounding output
[20:02] <JEEB> huh
[20:02] <kittonian> or does that not have anything to do with it
[20:02] <kittonian> sorry, trying to wrap my head around all of this
[20:03] <kittonian> the reason i asked is that i read that slower yields better results
[20:03] <kittonian> but if this literally just has to do with computing power than i guess it doesn't matter
[20:03] <JEEB> 1) find your highest, still looking fine crf value 2) pick the slowest preset that is still fast enough for you 3) look at the limitations of your playback device/application and set profile/level accordingly 4) since libx264 doesn't limit the amount of reference frames used to the level's, set it if needed
[20:05] <kittonian> i guess the reference frames is what's throwing me off here. not sure what that should be
[20:05] <JEEB> 1) sets the visual look 2) sets the compression ratio and encoding speed 3) limits 2's feature set 4) makes you limit the amount of reference frames that can be used to the levels
[20:05] <JEEB> reference frames are the amount of frames a frame can reference for predictive encoding, more means better compression
[20:05] <JEEB> also more means more memory usage
[20:06] <JEEB> for whatever reason libx264 itself doesn't limit itself if you set a level
[20:06] <JEEB> (the command line x264 encoder actually does)
[20:06] <JEEB> so you have to set the maximum amount of reference frames if you want to actually adhere to the level
[20:07] <kittonian> so medium is a good compromise between everything?
[20:07] <JEEB> it's a default, offers good enough stuff in general while not being overtly slow
[20:07] <JEEB> then the user can easily set it to something either faster or slower while getting more or losing some compression
[20:08] <kittonian> isn't less compression always the better quality output?
[20:08] <JEEB> no?
[20:08] <JEEB> better compression means less size for pretty much the same output
[20:09] <kittonian> ahh
[20:09] <kittonian> that's cool
[20:09] <kittonian> i'm from the audio world and you always want as little compression as possible to retain the highest quality
[20:09] <kittonian> just getting into the video side of things
[20:09] <JEEB> no, you don't want as little compression as possible, you want the least loss of information
[20:10] <JEEB> and that's the same with video, basically. Least loss of information while still compressing things
[20:10] <kittonian> ok, so what would your perfect world scenario command line be for Blu-Ray quality outputs?
[20:11] <kittonian> without a concern for disk space as I have huge drives
[20:11] <JEEB> well since crf sets more or less the quality level, if you have no concern towards the quality level, you might just as well set some faster preset then
[20:12] <JEEB> (the quality given by a certain crf value differs between settings because the algorithms that lead to the certain rate factor start differing)
[20:12] <JEEB> (but of course the difference usually isn't too big)
[20:13] <kittonian> hmm, ok
[20:13] <JEEB> the idea really isn't harder than 1) find your highest crf value that still looks good 2) find the preset of your choice regarding the compression/speed ratio 3) check what limitations whatever you're encoding for has 4) set profile/level/x264opts ref=NUMBER as needed per the limitations
[20:14] <kittonian> i noticed one example i found referenced -threads 0 as the way to use all the computing power possible and greatly speed up encoding times
[20:14] <JEEB> that is the default now
[20:14] <kittonian> oh, great
[20:14] <JEEB> and it just sets threads to 'auto' in x264
[20:14] <kittonian> though from my pastebin it seems -threads=6 is what is set
[20:14] <JEEB> which is 1.5 the amount of virtual cores
[20:15] <JEEB> anyways, select crf value and preset as you like (you can encode 2500-5000 frame sequences of actual content to test)
[20:16] <JEEB> -ss seeks and -t sets the amount of time to encode
[20:16] <JEEB> encode a minute or two for testing a few times and you should find out
[20:16] <kittonian> ok
[20:16] <kittonian> right now i'm only getting 6FPS on a 4-core mac pro
[20:16] <JEEB> then if your thing can handle high profile/level 4.1 you don't really have to set profile as high profile is the default, and level 4.1 is -level 41
[20:17] <kittonian> i think i read that ATV3 can only handle level 4
[20:17] <kittonian> 4.0
[20:17] <JEEB> then -level 4 for that
[20:17] <JEEB> and you'll have to limit reference frames to that and the resolution you're using... lemme go look up the numbers
[20:19] <JEEB> ok, so level 4 has a MaxDpbMbs of 32768
[20:19] <JEEB> macroblock width and height of 1920x1080 is 120x68
[20:19] <JEEB> thus the amount of macroblocks in a single frame is 8160
[20:20] <JEEB> 32768 / 8160 = 4.something, thus 4
[20:20] <JEEB> so -x264opts ref=4
[20:20] <JEEB> would limit the encoder to four reference frames at a time
[20:21] <JEEB> I've been thinking of implementing the automatic limitation of reference frames to the level you select into the libavcodec's libx264 wrapper
[20:21] <JEEB> so it does the same as x264's cli encoder
[20:23] <kittonian> this is interesting
[20:24] <kittonian> just read that even though apple doesn't officially support high profile 4.1 people are playing back without issue
[20:24] <kittonian> on both atv2 and atv3
[20:24] <kittonian> but not atv1
[20:25] <JEEB> yes, the first one was atrocious
[20:25] <JEEB> it only played baseline profile
[20:25] <JEEB> anyways, 4.1 has the same MaxDpbMbs limit
[20:28] <kittonian> ok, well i guess i'll see whether or not it'll work when it's finished
[20:28] <kittonian> if it doesn't and i need to do it again with different settings for high profile 4, is this the command? ffmpeg -i input.mkv -c:v libx264 -crf 18 -level 4 -x264opts ref=4 -acodec ac3 -ac 6 -ab 640k output.m4v
[20:28] <JEEB> yes
[20:29] <JEEB> also do note that itunes has its own limitations so if you have to go through it, that's a whole separate can of worms
[20:29] <kittonian> i have to import the movie to the itunes library but itunes doesn't play back any of the movies properly. only atv3 plays them fine
[20:30] <JEEB> depending on how nazi itunes is about that kind of stuff nowadays (it used to outright block >main profile stuff with the 3GS f.ex., while 3GS and newer phones could play high profile level 4.1 stuff JustFine)
[20:30] <kittonian> i'm really hoping the jailbreak comes soon so i can just play the MKV files directly
[20:30] <JEEB> you might be fine or might have to use something else to transfer the files over
[20:31] <kittonian> you can't use anything else on a non-jailbroken atv. you have to use itunes on a computer and then connect that computer to the atv over ethernet sharing (wi-fi is very choppy)
[20:32] <kittonian> i've been considering building a standalone HTPC with the latest XBMC installed to replace atv3 but i can't get netflix unless i run windows and use some crappy add-on
[20:33] <kittonian> i really appreciate all the help. thank you
[20:40] <gudy> when I run ffprobe on .ts segment with h264 content in it, -show_frames and -show_packets do not see the same number of video frames / packets. What could explain that ?
[20:47] <saste> gudy: one packet can contain several audio frames
[20:48] <saste> for video it should be the same number
[20:48] <saste> unless you have problems decoding them
[20:48] <saste> in that case you have frames < packets
[20:49] <Hammerhead2011-S> Hi All, I have a rtsp stream coming into VLC and transcoded to rtp(rtsp) out on port "xxxx"/blah.mov
[20:49] <gudy> saste: thanks, how can I find out what is wrong with a video frame ?
[20:49] <Hammerhead2011-S> totem in Linux plays the stream no problem. Windows(Quicktime player) plays it for about 1 minute then stops. no error just stops.
[20:50] <saste> gudy, check the log
[20:50] <Hammerhead2011-S> I'm trying to keep the stream size smaller...encoding to FLV triples the size of the stream...
[20:50] <gudy> saste: things like this : [h264 @ 0x100bc5280]no picture ?
[20:50] <gudy> (that's from mplayer)
[20:50] <saste> gudy, yes
[20:51] <gudy> is there a way to get more info on what went wrong ?
[20:51] <Hammerhead2011-S> transcoded using h264 BTW
[20:51] <saste> gudy, -loglevel
[20:51] <gudy> with mplayer, of ffprobe ?
[20:51] <saste> ffprobe
[20:51] <Hammerhead2011-S> The feed is from a video camera....My question....is there an easier way to do this?
[20:54] <gudy> saste: "./ffprobe -loglevel 9 -analyzeduration 10000000 -i input.ts" doesn't output anything ...
[20:56] <saste> gudy, asking on irc is not a substitute for the fine manual
[20:56] <saste> you're not decoding, unless you select -show_frames
[20:57] <gudy> ok, thanks
[21:06] <gudy> saste: thanks, that helped. I'm now down to "[h264 @ 0x7fd6fb000000] mmco: unref short failure" which I'm trying to find out what it could be
[21:06] <saste> gudy, bingo
[21:07] <saste> corrupted stream
[21:08] <gudy> mmmm
[21:09] <gudy> this is an HLS stream
[21:09] <gudy> the first problem is that there is a massive audio/video sync problem (segments are 10 seconds long, and audio/video frames are 3.5 seconds appart)
[21:10] <gudy> and then, most segments will lack a key frame at the beginning, however, the key frame seems to be there, but simply invalid ...
[21:13] <saste> gudy, how are you creating the segments?
[21:16] <gudy> I am not creating the segments
[21:16] <gudy> I am getting them from a partnet
[21:16] <gudy> and my player doesn't like them too much
[21:16] <saste> gudy, which player?
[21:16] <gudy> the default android hls player
[21:17] <saste> did you try with an I* device?
[21:17] <gudy> on android 4.0
[21:17] <saste> also i'm curious, which android player?
[21:17] <gudy> well, the player will play
[21:18] <saste> also you should ask your partner to validate the HLS stream using the apple (proprietary) tools
[21:18] <saste> most segments will lack a key frame at the beginning, however, the key frame seems to be there, but simply invalid ... < what do you exactly mean?
[21:18] <gudy> here's the output with both packets and frames enabled
[21:18] <gudy> http://pastebin.com/D7mgwe1j
[21:19] <gudy> I mean that there is a video packet which is supposed to contain a video key frame
[21:20] <gudy> if you look at the log I've pasted, first "FRAME" is after a bunch of video packets
[21:21] <saste> gudy, a decoding problem
[21:26] <gudy> how likely is it a bug in the stream vs a bug in ffmpeg's h264 decoder ?
[21:29] <saste> gudy, H.264 decoder is very well tested
[21:30] <saste> seems more likely a bug in the stream/encoder
[22:07] <stephanedev> hi everybody. do you have any hint on how to reduce latency when using ffmpeg C API?
[22:08] <stephanedev> i am talking about latency when streaming using rtp
[22:09] <stephanedev> is it due to the encoder, the decoder, or both?
[22:10] <stephanedev> from what I have read, i think there may be some option to pass to the encoder so that it does not buffer frames
[22:26] <boot> hello, is there another option to record the desktop and games besides x11grab?
[22:29] <stephanedev> boot: why? is there anything wrong with x11grab?
[22:31] <boot> I'm using KDE and have an ATI with proprietary divers, they don't play well together. So by default KDE disable direct rendering mode. If I have a game in fullscreen ffmpeg only records a black screen...
[22:34] <stephanedev> boot: on linux, x11grab is the only option i know of to grab the desktop. but i have very little experience with ffmpeg command-line tool so my answer is not authoritative at all
[22:38] <saste> boot, dshow, vfw on windows
[22:38] <saste> ah kde
[22:38] <saste> no what's wrong with x11grab?
[22:38] <boot> explained above
[22:39] <saste> i see
[22:39] <boot> i'm reading it might be a codec issue, i'll try a different one
[22:39] <saste> i think it's related to x11
[22:39] <saste> so nothing related to codec
[22:49] <stephanedev> when using avcodec_open2, is there some generic option (i.e. not codec dependent) i can pass in the dictionary that will prevent the encoder from buffering frames?
[22:50] <stephanedev> something along ("tune", "zerolatency")?
[22:50] <saste> stephanedev, don't think so
[22:50] <saste> you need to find a specific solution for each encoder
[22:51] <stephanedev> saste: thank you for your answer. does it mean it is impossible to create a rtp video streamer without latency which would be codec-agnostic?
[22:52] <saste> stephanedev, in principle, no
[22:52] <saste> in practice, yes
[22:52] <saste> since you're not going to support all the possible codecs but just a subset
[22:52] <saste> so you need to find meaningful options for each different codec
[22:53] <stephanedev> yes that's how i understood your "in practice answer"
[22:55] <stephanedev> is there any document (other than the source code) describing codec options that can be passed in the dictionary?
[22:57] <saste> stephanedev, ffmpeg-codecs(1)
[22:57] <saste> and you can do ffmpeg -h fullhelp to get a short description of all the private options
[22:59] <stephanedev> saste: thank you again for your help. is ffmpeg-codecs a man page?
[22:59] <saste> stephanedev, check also the docs on the website
[23:02] <stephanedev> i have been looking at the ffmpeg doxygen doc and manual but maybe i missed it
[23:02] <stephanedev> i'll check the output of ffmpeg -h full
[23:12] <stephanedev> saste: thank you very much. i found the document providing all the available options so i will try to play with them to hopefully get rid of this latency
[23:12] <saste> http://ffmpeg.org/ffmpeg-codecs.html
[23:12] <saste> mostly incomplete, but better than nothing
[23:12] <saste> (and patches are welcome)
[23:12] <stephanedev> yes that's the one i am looking at :)
[23:52] <Keshl> Blah. How do I find a video's framerate with ffmpeg? x.x
[23:52] <Keshl> I feel like I'm mis-reading the output of "ffmpeg -i video.flv" -- Is "25 tbr" what I'm looking for?
[23:55] <stephanedev> Keshl: what about ffprobe <your_video_file> and then looking at the fps value for each stream?
[23:58] <Keshl> stephanedev: ... <.< So now I know ffprobe exists.
[23:58] <Keshl> stephanedev: It's not saying it.
[23:59] <Keshl> Same output as ffmpeg, still no useful information. xwx
[23:59] <Keshl> I'm expecting either 15, 24 or 30 and I'm not seeing those numbers anywhere.
[23:59] <stephanedev> can you paste the command output to pastebin.com?
[00:00] --- Fri Feb  8 2013