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

burek burek021 at gmail.com
Wed Nov 19 02:05:02 CET 2014


[00:02] Action: llogan is done waiting for console output and gets to work
[00:03] <diegoviola> so how to increase subtitle size
[00:03] <compstomp> Just my two cents, if you're using VLC to playback you can just do so there
[00:04] <sacarasc> compstomp: If you compile fdk with one prefix, but tell ffmpeg to look in a different place, then you're going to get that problem.
[00:04] <sacarasc> That's what llogan was saying.
[00:05] <compstomp> The prefixes for both compilations were the same though :/
[00:05] <sacarasc> "--prefix="$HOME/Software/ffmpeg/ffmpeg_build", but your ffmpeg --extra-*flags are pointing to $HOME/ffmpeg/ffmpeg_build/include"
[00:06] <compstomp> I realize I fixed a backup I made not the original. Will check back. Thanks again!
[01:16] <compstomp> Hi all, I am having trouble linking x265 compiled from source into ffmpeg.  Here is the complete console input / error output: http://pastebin.com/YhKSSpJh
[01:19] <compstomp> the accompanying config.log: http://pastebin.com/Hrh6VqeZ
[01:26] <c_14> Does "$HOME/Software/fmpeg/ffmpeg_build/lib/pkgconfig" contain x265.pc ?
[01:26] <compstomp> it doesn't for some reason
[01:27] <c_14> Well, that's your problem.
[01:27] <compstomp> although curiously enough, a previous try at this did result in it being there
[01:27] <c_14> Where are you installing x265?
[01:27] <c_14> ie, where in the world is x265.pc
[01:28] <compstomp> http://pastebin.com/hYzR3SfS
[01:28] <compstomp> I must somehow be setting the flags wrong with cmake
[01:29] <c_14> Well, nah. It's easy then. you wrote ffmpeg with one f in the PKG_CONFIG_PATH variable
[01:29] <c_14> try adding another one
[01:30] <diegoviola> how many threads can ffmepg use?
[01:31] <compstomp> gah! so simple. Thanks! will check back
[01:31] <c_14> diegoviola: depends on the encoder
[01:32] <c_14> Usually some funky fraction of the resolution.
[01:32] <diegoviola> isn't ffmpeg the encoder?
[01:32] <compstomp> encoder as in codec
[01:32] <c_14> Nah, ffmpeg is a wrapper.
[01:33] <compstomp> libx264..etc
[01:33] <c_14> Well, a wrapper as well as a few other nice things.
[01:34] <compstomp> c_14, did you see anything that might have indicated why x265.pc might have absconded off into the darkness?
[01:34] <c_14> Did you check the missing f thing?
[01:36] <compstomp> Yep have corrected that. But that is an a script called after the completion of compiling x265. Isn't that a biproduct of the x265 compilation?
[01:40] <c_14> Try with -DLIB_INSTALL_DIR=$HOME/Software/ffmpeg/ffmpeg_build/lib
[01:41] <compstomp> And keep all existing flags or drop one?
[01:41] <c_14> Keep them.
[01:41] <c_14> Shouldn't hurt.
[01:42] <compstomp> kk, much appreciated.  Will take quite awhile for my old laptop to compile again but will be back with the results
[01:44] <compstomp> Before trying again, is it perhaps wring to be setting the current binary dir? Should I instead be setting the EXECUTABLE_OUTPUT_PATH?
[01:48] <c_14> Just use the bin dir one
[01:48] <compstomp> does the -DLIB_INSTALL_DIR= not require the :PATH= syntax?
[01:49] <compstomp> system is 32 bit Linux Mint 17 if that is relevant
[01:49] <c_14> eh, it might
[01:50] <c_14> tbh I usually just use the funky ncurses ui thingy
[01:56] <compstomp> Probably worth trying that route just to see if I can get it to work, but really would like some zero interaction scripts for posterity.  Cmake just now starting so probs another 25 min + of compilation. If you're not still around then, thanks for your help!
[02:39] <compstomp> Would anyone familiar with the cmake compilation process for the videolan x265 codec have an understanding why I'm getting this strange, but not complex, error? http://pastebin.com/cRmD0Ad1  Line 489 should read: /home/sauser/Software/ffmpeg/ffmpeg_build/lib/pkgconfig/x265.pc
[02:47] <c_14> eh, hrm. I might have found the issue. Get rid of the -DLIB_INSTALL_DIR and the -DCMAKE_CURRENT_BINARY_DIR
[02:48] <c_14> The cmake actually uses the CMAKE_CURRENT_BINARY_DIR as the source location of the x265.pc file
[02:48] <c_14> So if you change it, it won't find the pc file and won't copy it to the pkgconfig folder
[02:49] <c_14> Set BIN_INSTALL_DIR instead
[02:49] <c_14> My cmake foo is not very strong.
[02:53] <compstomp> Hey you got me to the point that after just moving the .pc file its actually compiling!
[03:41] <Wader8> hello
[03:42] <Wader8> im trying to do RTMP to RTSP live-reconversion
[03:42] <Wader8> but the server doesn't start and there's no error
[03:59] <Wader8> http://justpaste.it/i19n
[05:12] <diegoviola> I'm trying to change the font of an ASS subtitle
[05:12] <diegoviola> the ASS file has something like this:
[05:12] <diegoviola> Style: Default,Arial,16,&Hffffff,&Hffffff,&H0,&H0,0,0,0,1,1,0,2,10,10,10,0,0
[05:12] <diegoviola> I change Arial to something else and it still looks the same
[05:12] <diegoviola> any ideas?
[05:16] <diegoviola> nvm got it to work
[08:48] <Aartsie> Hi all
[08:49] <Aartsie> i got something really strange, when i set the fps on 30 VLC shows me that the frame rate is 1000 ? how is this possible ?
[09:26] <Aartsie>  i'v find out the problem, the streaming fps is not constant
[09:26] <Aartsie> it will going down... how more frames it sends how lower it goes
[10:07] <Aartsie> i have make some logs https://gist.github.com/anonymous/b2af1c5c63b95361dcd1
[10:52] <Aartsie> Is there someone who can help me with this ?
[12:43] <pnade> Anyone happen to have a copy of the CEA-708-E spec?
[13:04] <grumper> hi
[13:04] <grumper> https://www.ffmpeg.org/ffmpeg-filters.html#Examples-40 lists "a quick emboss effect"
[13:04] <grumper> when trying to get it going I get what seems like a syntax error
[13:04] <grumper> ffmpeg -filter_complex format=gray,geq=lum_expr='(p(X,Y)+(256-p(X-4,Y-4)))/2' -f matroska - | ffplay -i -
[13:04] <grumper> what am I doing wrong?
[13:05] <grumper> (I am currently just testing it to see if it applies - I want to convert a small graphic to an embossed-like image in the top right corner, something like a watery-watermark)
[13:13] <grumper> ah I see...
[13:54] <grumper> in the geq filter
[13:54] <grumper> why does lum=p(X,Y) work as expected (leaving the image intact)
[13:55] <grumper> yet lum=lum(X,Y) doesn't?
[14:29] <grumper> in a complex filter how can I ask for the size of a particular input (not part of the current filter chain)
[14:36] <grumper> you guys don't talk much do you ;)
[15:48] <saste> grumper: there is no way, you need to rely on external scripting
[16:45] <Aartsie> Hi all is it possible to set the  1k tbn, 15 tbc ?
[16:45] <Aartsie> now the input tbn and tbc is different from the output
[16:53] <rsully> encoding with libx264: is it possible to use one crf value for the first X seconds of the video, then another crf value for the remainder?
[16:57] <c_14> rsully: you can encode the X seconds at one crf, cut the recording at that point, encode the rest of the video at another crf and then concat
[17:02] <Aartsie> what is crf ? i'm using it but don't know what it is
[17:02] <c_14> constant rate factor
[17:02] <c_14> Basically a mechanism to ensure that the "visual quality" of a video is constant over time.
[17:03] <Aartsie> thank you c_14
[17:03] <Aartsie> c_14: do you know how to set the tbn ?
[17:04] <Aartsie> The input is 1200k tbn and the output is 1k tbn so i think thats not good right ?
[17:06] <rsully> Armada found this post from 2 years ago http://ffmpeg.org/pipermail/ffmpeg-user/2012-November/011391.html
[17:06] <rsully> Aartsie * sorry
[17:08] <Aartsie> rsully: oke so it is not possible to change them :)
[17:09] <rsully> yeah unless you're doing some super critical video editing it doesn't look like there is any need to modify them either
[17:10] <Aartsie> rsully: ok :) the problem i have is some latacy of 13 seconds
[17:10] <Aartsie> rsully: but i don't know how to improve that on a rtmp stream
[17:11] <rsully> what is your use of ffmpeg? I mostly just use it for thumbnails and converting videos to mp4, so I've never dealt with latency
[17:13] <rsully> you also might want to check this guide https://trac.ffmpeg.org/wiki/StreamingGuide
[17:13] <Aartsie> i have a raspberry pi camera so it will converting from RAW H264 to x264 and stream it by rtmp
[17:13] <Aartsie> yes thank you i've already see that
[17:14] <rsully> how are you serving the rtmp stream?
[17:15] <Aartsie> rsully: /opt/vc/bin/raspivid -t 0 -fps 15 --width 1280 --height 720 -v -o - | ffmpeg -framerate 15 -re -i - -vcodec copy -r 15 -g 30 -preset ultrafast -maxrate 2400k -bufsize 960k -f flv rtmp://192.168.1.53/live/test
[17:16] <rsully> ooh I didn't even know ffmpeg could do that
[17:17] <Aartsie> rsully: hahaha ok no problem :) ffmpeg is really nice
[17:17] <kepstin-laptop> Aartsie: most of your output options there are completely ignored because you are using -vcodec copy
[17:17] <kepstin-laptop> since copy isn't reencoding the video
[17:18] <diegoviola> when I encode a movie with -target ntsc-dvd I always get 16:9 res, is there a way to get 4:3?
[17:18] <diegoviola> for DVD
[17:18] <kepstin-laptop> diegoviola: it should automatically set the output aspect ratio correctly if your input video is correct...
[17:19] <diegoviola> ok
[17:19] <diegoviola> ty
[17:22] <kepstin-laptop> diegoviola: if your input video isn't correct, you should look at the 'setdar' video filter in ffmpeg; if your input is 16:9 and you want to convert it to 4:3, then try the crop filter.
[17:28] <diegoviola> the input aspect ratio is correct
[17:52] <pierre__> hi, is anyone experienced with muxing raw h264 frame stream into mp4 container, i assume i have trouble with setting up the extradata as it was written at: http://www.szatmary.org/blog/25, I am using avformat from ffmpeg version 2.4.x., after setting up extradata which sps = 6 bytes and pps = 2 bytes, and succesfully container is created i use mplayer to player my file and mplayer prints errors about deco
[17:52] <pierre__> ding some of the frames, each key frames are succesfully decoded and renderer and P/B aren't, is someone able to give me some adivces upon the issue ?
[18:00] <Mavrik> pierre__, check if your input stream is in AnnexB format
[18:00] <Mavrik> if it is, you'll have to strip all the PSS/SPS packets out of it and only write them once in the header
[18:04] <pierre__> this is what i do, pps and sps frames comes separetly to my muxer, once i receive them i create avcc from them and put that data into contextcodec.extradata then skiping av_write_frame with those frames, next frames are placed to the av_write_frame, btw is it correct to write each frame (VCL) with annex b to mp4 container ?
[18:08] <pierre__> i will give you more light on the issue, I have recorder which stores raw h264 frames in custom conterner, frames are stored already in annex b format, the next step is to export the recorded material and throw those frames into muxer, and this is the problem end of the pipline, the muxer
[18:21] <xvzf> hi there, I do not see Subtitle stream here: http://pastebin.centos.org/13946/ but in the original video there is one: http://vimeo.com/43687450 how could this be?
[18:32] <relaxed> xvzf: maybe the player overlays the subs
[18:36] <xvzf> relaxed, so simply I did not download the subtitles, because vimeo does not let me that?
[18:54] <relaxed> xvzf: I'm just guessing, of course, but if that is what's going on- yes
[19:32] <fhenning09> How can I remove only the first ten seconds of a directory full of tv shows so that my .srt files will be displayed properly?
[19:33] <c_14> for i in dir/*; do ffmpeg -ss 10 -i "$i" "${i%.*}_short.mkv"; done
[19:34] <rsully> fhenning09 i would consider updatting the srt files instead of the video files
[19:34] <fhenning09> well they have some dudes twitter banner is on for ten seconds so i dunno
[19:35] <rsully> that sucks. i would try to find the original source without that (whoever sync'd the subtitles must have had it?)
[19:44] <fhenning09> c_14: Thanks was what i was looking for just might b a while
[19:45] <llogan> fhenning09: you may also want to add "-c copy"
[19:45] <kepstin-laptop> well, with -c copy it won't be able to get the time exactly correct - although it is likely that the first frame after the banner will be a keyframe, for what it's worth.
[19:46] <rsully> won't it likely get it incorrect anyways because the -ss is before the -i?
[19:46] <kepstin-laptop> nah, -ss before -i should be frame accurate if you're reencoding the video.
[19:47] <rsully> hmm ok. i always have issues when trying to generate a png frame
[19:49] <fhenning09> http://pastebin.com/XTYK6UP5
[19:50] <fhenning09> very detailed manpage
[19:52] <fhenning09> -ss position (input/output)
[19:52] <fhenning09>            When used as an input option (before "-i"), seeks in this input file to position. Note the in most formats it is not possible to seek exactly, so
[19:52] <fhenning09>            ffmpeg will seek to the closest seek point before position.  When transcoding and -accurate_seek is enabled (the default), this extra segment between
[19:53] <fhenning09>            the seek point and position will be decoded and discarded. When doing stream copy or when -noaccurate_seek is used, it will be preserved.-ss position (input/output)
[19:53] <fhenning09>            When used as an input option (before "-i"), seeks in this input file to position. Note the in most formats it is not possible to seek exactly, so
[19:53] <fhenning09>            ffmpeg will seek to the closest seek point before position.  When transcoding and -accurate_seek is enabled (the default), this extra segment between
[19:53] <fhenning09>            the seek point and position will be decoded and discarded. When doing stream copy or when -noaccurate_seek is used, it will be preserved.-ss position (input/output)
[19:53] <llogan> use pastebin
[19:53] <fhenning09>            When used as an input option (before "-i"), seeks in this input file to position. Note the in most formats it is not possible to seek exactly, so
[19:53] <fhenning09>            ffmpeg will seek to the closest seek point before position.  When transcoding and -accurate_seek is enabled (the default), this extra segment between
[19:53] <fhenning09>            the seek point and position will be decoded and discarded. When doing stream copy or when -noaccurate_seek is used, it will be preserved.
[19:53] <rsully> well that was useless
[19:54] <fhenning09> http://pastebin.com/FFAvysK8
[19:54] <fhenning09> sorry
[20:00] <uex1fi> Hi folks
[20:01] <uex1fi> Is there a modern binary of FFmpeg which has libfdk_aac?
[20:01] <c_14> No.
[20:02] <uex1fi> :(
[20:02] <c_14> The libfdk_aac license prohibits binary redistribution.
[20:02] <JEEB> it's not distributable so you can only build it yourself :P
[20:02] <uex1fi> Okay.  Well, I'm trying to get this result: http://sinclairmediatech.com/building-ffmpeg-with-libx265/
[20:02] <uex1fi> I see.
[20:02] <uex1fi> I'm just trying to avoid all the messy building process
[20:02] <uex1fi> I would like to try libx265 with libfdk_aac.
[20:03] <uex1fi> Hmm
[20:03] <JEEB> you mean x264 probably, since x265 is not yet ready to be usable unless you are trying to do some very very low bit rate scenario
[20:03] <uex1fi> oh, i actually mean x265 (hevc)
[20:04] <uex1fi> i need low file size
[20:04] <JEEB> well, what kind of low
[20:04] <llogan> enabled gpl && die_license_disabled_gpl nonfree libfdk_aac
[20:04] <uex1fi> JEEB: that's the question.  that's what I want to experiment with.
[20:04] <JEEB> because where x265 beats x264 is where both look bad, but x265 just looks better
[20:05] <JEEB> if you just mean "as visually lossless as possible but still compressed quite a bit" then x264 is probably what you still want
[20:05] <uex1fi> I'm trying to make acceptable proxy videos for enormous DV-AVI files
[20:05] <llogan> for editing?
[20:05] <uex1fi> No, for searching auto-captions and viewing the results
[20:05] <uex1fi> I have hundreds of hours.  like 730 GB
[20:06] <JEEB> I haven't tested since end of september or so, but I don't think much has changed since - so if you actually use a bit rate when the x264 psychovisual opts start working, then x264 is better
[20:06] <uex1fi> It may be acceptable to sacrifice a little quality
[20:06] <JEEB> a bit...  where x265 wins is where both suck and x265 just sucks somewhat less :P
[20:06] <uex1fi> JEEB: haha
[20:07] <uex1fi> but i mean, isn't it supposed to be half the file size?
[20:07] <llogan> JEEB: what about encoding time?
[20:07] <JEEB> no
[20:07] <JEEB> llogan, x265 was way way slower
[20:07] <llogan> i haven't tried it in a long time
[20:07] <JEEB> placebo+ with x265 (everything except ME or so at max), placebo with x264
[20:08] <uex1fi> for me, file size is important
[20:08] <uex1fi> i'm seeing if i can cram these videos onto a large thumb drive
[20:08] <JEEB> uex1fi, the specification's theoretical (tested with the reference implementation and PSNR) improvement is somewhere around 30% , but then the real world steps in
[20:08] <uex1fi> which may not be realistic, but i'm trying
[20:08] <JEEB> real world meaning implementations
[20:08] <uex1fi> what do you mean
[20:08] <uex1fi> i know i can play them in vlc
[20:09] <JEEB> as in, you don't just magically get the theoretical performance improvement
[20:09] <uex1fi> ok
[20:09] <JEEB> esp. when the implementation of the previous format is just SoDamnGood
[20:09] <JEEB> with mpeg-4 part 2 it was simpler
[20:09] <JEEB> it had no deblock and no CABAC
[20:09] <JEEB> (in-loop deblocking I mean)
[20:10] <JEEB> so it was rather simple to hop onto AVC within a couple of years
[20:10] <uex1fi> all right
[20:10] <JEEB> now we're 1.5 years or so from the specification, and the previous format's implementation is damn good
[20:10] <uex1fi> but hevc is (basically) always smaller file size at the same quality as x264?
[20:11] <JEEB> uhh
[20:11] <JEEB> at this point x265 (the best current HEVC implementation) only wins over x264 in visual quality in very very low bit rate scenarios
[20:11] <JEEB> at the same size
[20:11] <uex1fi> ok
[20:11] <uex1fi> then
[20:11] <uex1fi> Have you ever used Freemake video converter?
[20:12] <uex1fi> I used that a while back to convert hundreds of videos to MP4.
[20:12] <uex1fi> (I still have the original videos, of course.)
[20:12] <llogan> looks like one of those GPL violators.
[20:12] <uex1fi> So -- is it possible to get a better-looking encode?
[20:12] <uex1fi> At a smaller size?
[20:13] <JEEB> as soon as the bit rate scenario you are going for is somewhere along where x264's psychovisual opts are actually working good,, x264 wins
[20:13] <JEEB> (at very low rates the psychovisual opts actually make the picture look somewhat worse)
[20:13] <rsully> JEEB what bitrate would that be?
[20:13] <uex1fi> okay.  i'm not familiar with those options
[20:13] <JEEB> rsully, there are no specific rates
[20:13] <uex1fi> so i need help
[20:13] <JEEB> and it's mostly psy-rd/trellis
[20:14] <JEEB> I think AQ is still useful in that part?
[20:14] <JEEB> basically, you will notice if you go low enough :P if it generally looks good then you're not there yet.
[20:14] <uex1fi> if I can upload maybe a 20-second dv-avi, does someone want to mess with it?
[20:15] <JEEB> anyways, if you want a realistic alternative for relatively well compressed video, just use x264 and pick the slowest preset that is still fast enough for you
[20:15] <kepstin-laptop> uex1fi: use x264, set the preset as slow as you can handle, use crf mode if you don't need a fixed file size, and 2-pass bitrate mode if you do need a fixed filesize.
[20:16] <uex1fi> it doesn't need to be literally fixed, but generally quite small and well-compressed
[20:16] <JEEB> which is what crf is for
[20:16] <uex1fi> ok then
[20:16] <JEEB> start with 23 and go up if it still looks good, down if it looks bad
[20:16] <JEEB> then you will hit the highest crf value that still looks "good enough" for you
[20:16] <kepstin-laptop> crf is "constant rate factor", it's an arbitrary number where bigger numbers give you worse video quality/smaller files.
[20:17] <uex1fi> ok
[20:17] <JEEB> which is the most amount of compression you will get, basically
[20:17] <uex1fi> would you recommend libfdk_aac for audio?
[20:17] <rsully> i'm curious how that compares to libvo_aacenc
[20:18] <JEEB> much better
[20:18] <kepstin-laptop> libvo_aacenc is horribly bad.
[20:18] <JEEB> even the internal aac encoder is better than vo_aacenc
[20:18] <uex1fi> then... my video source is interlaced.
[20:18] <rsully> ffmpeg is defaulting to libvo_aacenc for me with mp4 output
[20:18] <kepstin-laptop> uex1fi: for best video compression, deinterlace it before compressing.
[20:18] <JEEB> yes, because someone decided it's better in whatever crazy way :P
[20:18] <uex1fi> hmm
[20:19] <uex1fi> so an interlaced x264 file is not smaller?
[20:19] <uex1fi> smaller file size
[20:19] <rsully> JEEB what should i force it to use? i'm using osx binary
[20:19] <JEEB> -c:a aac -strict experimental
[20:19] <llogan> or you could compile
[20:19] <llogan> even with brew if you prefer
[20:19] <rsully> llogan and then use libfdk_aac?
[20:20] <llogan> yes
[20:20] <llogan> you'd have to compile fdk too
[20:20] <uex1fi> because I assumed that interlaced is less data than progressive
[20:20] <rsully> how much better is libfdk_aac than the builtin one
[20:20] <kepstin-laptop> in most cases, i would expect the original interlaced video to be slightly bigger than a deinterlaced copy, both encoded with x264
[20:20] <uex1fi> interesting... so deinterlaced can actually be smaller
[20:20] <llogan> rsully: depends on how much you trust your own ears or a japanese audio fanatic
[20:21] <kepstin-laptop> uex1fi: assuming that you have a 60 fields per second interlaced video, and deinterlace it to 30 frames per second
[20:21] <llogan> rsully: http://trac.ffmpeg.org/wiki/CompilationGuide/MacOSX#ffmpegthroughHomebrew
[20:21] <llogan> may be useful. i don't know.
[20:21] <rsully> llogan yeah i usually use homebrew, i was just doing some encodes on a freshly installed computer and didnt feel like downloading xcode
[20:21] <uex1fi> this is NTSC 29.97 video
[20:21] <rsully> llogan now i know how much of a bad idea that was
[20:22] <llogan> depends on how lazy you feel like being
[20:22] <llogan> or use the quicktime aac encoder. it's good
[20:22] <llogan> and then remux
[20:22] <kepstin-laptop> uex1fi: 60 fields per second interlaced and 30 frames per second progressive is the same amount of "raw" video data, but video encoders generally can do better predicition with progressive frames
[20:23] <uex1fi> makes sense
[20:24] <uex1fi> ok, so besides deinterlacing, crf mode, and two-pass, should i mess with any other settings?
[20:24] <uex1fi> can i squeeze out more quality?
[20:24] <kepstin-laptop> use either crf or two pass; they are different (and conflicting)
[20:25] <kepstin-laptop> uex1fi: don't bother touching any of the x264 options other than the -preset
[20:25] <uex1fi> ok thanks
[20:25] <uex1fi> then which is better?  crf or two-pass?
[20:26] <uex1fi> two-pass gives a lower file size, i believe
[20:26] <kepstin-laptop> in crf mode you pick a quality and get filesize determined automatically; in 2-pass mode you pick a filesize and get a quality determined automatically
[20:26] <kepstin-laptop> the relative quality of crf and 2-pass modes is effectively identical
[20:27] <kepstin-laptop> (in fact, the way 2-pass mode works in x264 is the first pass calculates the crf needed to get the desired filesize, and the second pass is just a crf encode)
[20:28] <uex1fi> hmm okay
[20:28] <uex1fi> so crf isn't a blindly constant quality
[20:29] <uex1fi> i mean, if the screen is black for 10 seconds, will it lower the bitrate?
[20:31] <kepstin-laptop> plain black screens are easy to encode, so x264 won't use very many bits on that section of the video, probably...
[20:31] <uex1fi> ok, thanks for the info.
[20:32] <kepstin-laptop> that's try of pretty much any codec tho, at least when you're not doing a one-pass constant bitrate encode.
[20:32] <kepstin-laptop> don't do a 1-pass constant bitrate encode unless you're doing live video streaming :)
[20:33] <uex1fi> yeah haha
[20:33] <uex1fi> i'll try it out
[20:33] <uex1fi> thanks everyone
[20:33] <uex1fi> see you later
[20:34] <kepstin-laptop> I am so glad the x264 devs put that preset system in, those websites with random sets of x264 options that nobody really understood were getting annoying :/
[20:37] <rsully> llogan are there any options i don't want when i compile with homebrew? should i just enable all?
[20:38] <llogan> just enable what you're going to use
[20:39] <rsully> well i didn't even know i had to specify --with-fd-aac but apparently it is so much better. just don't want to miss out on something like that agaib
[20:40] <llogan> --with-fdk-aac --with-freetype --with-libass  --with-libvorbis --with-libvpx
[20:40] <llogan> and whatever you need for libx264 support
[20:40] <llogan> i don't know what --with-tools is
[20:41] <kepstin-laptop> might as well enable opus too, it's lots of fun :)
[20:45] <rsully> alright recompiling ffmpeg now with about 5 options more than i usually use
[20:45] <rsully> so this should only take like an hour
[20:47] <llogan> rsully: what does "brew info ffmpeg" say about --with-tools?
[20:52] <rsully> lol 'Enable additional FFmpeg tools'
[20:52] <llogan> ok. thanks for looking.
[20:52] <rsully> i don't see any ffmpeg-* binaries
[20:53] <rsully> just does this https://github.com/Homebrew/homebrew/blob/5e00a9e354c8c60207591d9185655612c4f3517d/Library/Formula/ffmpeg.rb#L145-L148
[20:54] <llogan> ah, ok. not typically useful for most users
[20:55] <rsully> i still don't know what is in that dir it installed though
[20:55] <rsully> ah all the ff* tools like ffprobe, ffserver
[20:55] <llogan> the stuff in ffmpeg/tools (in the source directory)
[20:57] <rsully> doesn't homebrew cleanup the src dir? can't find anything useful in /usr/local
[20:58] <llogan> i don't really know anything about brew
[21:17] <uex1fi> hello
[21:17] <uex1fi> does 10-bit x264 produce a smaller file size than 8-bit?
[21:19] <kepstin-laptop> uex1fi: given roughly the same output quality, I think you can get smaller encodes with 10bit, yeah
[21:20] <kepstin-laptop> note that the -crf values between 8bit and 10bit are not comparable.
[21:20] <uex1fi> right
[21:20] <uex1fi> are there any ffmpeg windows builds that have this?
[21:21] <uex1fi> maybe this: http://sourceforge.net/projects/ffmpeg-hi/
[21:21] <kepstin-laptop> uex1fi: well, that's silly, they're distributing a non-redistributable build
[21:22] <kepstin-laptop> with fdk-aac in there, it's a license violation.
[21:22] <rsully> yay licensing?
[21:22] <uex1fi> ok
[21:25] <uex1fi> any significant reason not to use 10-bit?
[21:26] <kepstin-laptop> there's basically no support for 10bit in any hardware decoders, and limited player support. You can't use it for mobile or any fixed-function hardware (bluray players, etc)
[21:27] <uex1fi> ok
[21:30] <uex1fi> all right, thanks
[21:30] <uex1fi> see you later
[21:31] <kepstin-laptop> It proved to be a pretty big gain in the anime scene; the increased accuracy of 10bit meant fewer bit needed when using lots of reference frames, and the 10bit colour space made background gradients and stuff look nicer.
[21:32] <klaxa> based Daiz, etc.
[21:32] <kepstin-laptop> of course "big gain", when half the encoders started making multi-gigabyte files because they could :/
[21:33] <uex1fi> yeah, that's interesting...
[21:33] <uex1fi> so really, 10-bit is better, but just not supported widely
[21:33] <uex1fi> ?
[21:34] <kepstin-laptop> the drawbacks are that it's somewhat slower (i think? haven't tested this personally) and is not widely supported for playback, yeah
[21:35] <kepstin-laptop> i don't thing there's any time when it'll give worse quality than 8bit, at any rate.
[21:36] <kepstin-laptop> I seem to recall that it behaved better when you are doing multiple generations of lossy encoding, but dunno where I saw that.
[21:40] <uex1fi> wow, so many options to sift through
[21:40] <uex1fi> haha
[21:44] <uex1fi> see you later
[21:45] <rsully> JEEB llogan libfaac vs libfdk_aac ? what flags should i use? ffmpeg is now defaulting to libfaac (compiled from homebrew now, instead of binary)
[21:45] <JEEB> fdk
[21:46] <JEEB> faac is worse than fdk
[21:46] <rsully> how big of a difference are we talking?
[21:49] <llogan> does brew enable libfaac by default or did you add some sort of --with-faac?
[21:49] <llogan> if you also have fdk, then use -c:a libfdk_aac
[21:50] <rsully> brew enables libfaac by default
[21:50] <llogan> dumb
[21:50] <llogan> http://trac.ffmpeg.org/wiki/Encode/AAC
[21:50] <llogan> also, just listen to them to compare. preferrably ABX if you feel up to it
[21:50] <rsully> do both have the same 14kHz cut off?
[21:51] <llogan> i don't know
[21:51] <llogan> i don't use faac
[21:51] <rsully> i'll do an encode of both and checkout the spectrum analyzer
[21:51] <llogan> ok, but you should listen too
[21:52] <rsully> llogan aac page doesn't mention abx
[21:54] <llogan> i didn't provide it for abx
[21:54] <llogan> just general info about each encoder
[21:54] <llogan> examples, etc
[22:06] <Cracki> cheers.
[22:06] <Cracki> anyone wanna talk about lagarith? I figure this is faster than twitter.
[22:07] <llogan> Cracki: you should submit a bug report
[22:07] <llogan> include the ffmpeg command, the complete console output, and the sample file
[22:07] <llogan> of course you can search for an existing related report first, (not that i can think of an existing one ATM)
[22:08] <llogan> https://trac.ffmpeg.org/
[22:08] <Cracki> i've looked but google only turned up open bugs
[22:08] <Cracki> so I figure either nobody bothers or I'm having a different issue
[22:09] <llogan> then submitting a bug report is the best way then
[22:09] <Cracki> ugh now I have to make up another password. ok...
[22:14] <Cracki> ok, about to create the ticket
[22:14] <llogan> thanks
[22:18] <rsully> if i encode an mpg to one video file and one audio file and then mux them together is it possible the end result won't be in sync?
[22:21] <llogan> Cracki: you forgot the complete ffmpeg console output
[22:22] <Cracki> oh right, I'll attach that. thanks.
[22:22] <llogan> and please explain how it was created and what plays is correctly (as you did on twitter)
[22:24] <llogan> Cracki: and you may be asked to test ffmpeg from current git master since your build is about two months old
[22:24] <llogan> shit, how is it nov 18 already?
[22:25] <Cracki> are nightly builds (zeranoe) ok?
[22:25] <llogan> yes
[22:25] <Cracki> then i'll do just that
[22:25] <llogan> thanks. i'll be back in an hour if you have other questions
[22:44] <Cracki> rsully, good question. in your place, I'd try to find videos where the audio or video have offsets (ffprobe can give machine readable output)
[22:45] <rsully> any examples of what i'm looking for?
[22:46] <francesco_> Hello. I don't know if this is the proper channel to ask. I'm not an expert of "ffmpeg". I can't understand why, when I convert  a video from a format into another, the quality gets worse. Am I doing something wrong? Thank you.
[22:46] <c_14> You're reencoding.
[22:46] <c_14> use -c copy
[22:46] <Cracki> uh if you just do an ffprobe on a file, you'll see Duration: ..., start: 0.000000 etc
[22:46] <Cracki> (@rsully)
[22:47] <rsully> Cracki ok i see that, so how should i compensate for that? my video input has start=0.04 and my audio file input has start=1
[22:47] <Cracki> francesco_, video compression is lossy because it saves bits. if you squeeze video too much, it loses information.
[22:47] <c_14> rsully: -itsoffset
[22:48] <francesco_> Cracki, I'm trying to convert a FLV video into an AVI, to watch it with my DVD reader. I'm simply doing "ffmpeg -i myfile.flv myfile.avi".
[22:49] <Cracki> yeah that's too little. ffmpeg will choose some default codec and a really low bit rate.
[22:49] <francesco_> Cracki, what should I do?
[22:49] <Cracki> francesco_, if you do ffprobe myfile.flv, what audio and video codecs does it say?
[22:49] <francesco_> I was told that that was they way chosen by default to obtain the best quality.
[22:49] <rsully> c_14 is there a way to just say "figure it out"?
[22:50] <francesco_> I didn't try.
[22:50] <francesco_> Let me try.
[22:50] <c_14> rsully: maybe with async or vsync or one of those funky ones
[22:50] <c_14> It _should_ normally just work.
[22:50] <Cracki> francesco_, definitely not. the defaults are supposed to look ugly, so people know to set appropriate values.
[22:50] <francesco_> Cracki, I understand.
[22:50] <c_14> The x264 defaults are decent, but I don't think avi choses x264
[22:50] <Cracki> that too
[22:52] <c_14> *chooses
[22:52] <rsully> c_14 so by default it shoudl account for the start times?
[22:52] <c_14> Normally yes.
[22:53] <francesco_> Cracki, I don't have ffprobe installed. I'm installing it.
[22:53] <Cracki> if it's a random flv, i'd start with something like ffmpeg -i myfile.flv -c:a mp3 -b:a 64k -c:v mpeg4 -b:v 2000k myfile.avi
[22:53] <rsully> c_14 ok just wanted to check. i had encoded a bunch of mpg to mp4, and then realized i didn't use fdk_aac, so now i'm trying to take the audio from the mpg and the video (copy) from the mp4 so i don't waste time reencoding
[22:55] <francesco_> I can't install ffprobe. I don't know why. :(
[22:55] <Cracki> then skip ffprobe
[22:56] <francesco_> I think it's a problem of dependencies.
[22:56] <Cracki> when you do ffmpeg with just input and output file, what does it say on the terminal?
[22:56] <Cracki> (it's reporting some information on the input)
[22:57] <francesco_> It did when I tried to convert it. I didn't pay attention. It shows the conversion of the file.
[22:57] <Cracki> before that
[23:00] <francesco_> Cracki, which details do you need?
[23:01] <Cracki> video and audio codec of the input file
[23:01] <francesco_> Duration: 00:56:20.16, start: 0.000000, bitrate: 64 kb/s
[23:01] <francesco_>     Stream #0.0: Video: vp6f, yuv420p, 528x304, 25 tbr, 1k tbn, 1k tbc
[23:01] <francesco_>     Stream #0.1: Audio: mp3, 22050 Hz, stereo, s16, 64 kb/s
[23:01] <Cracki> i don't need those. you can just convert the video to whatever.
[23:01] <Cracki> ah yes
[23:02] <Cracki> that's a nice small video
[23:02] <francesco_> When I simply convert it into an AVI, the quality gets worse.
[23:02] <Cracki> ffmpeg -i myfile.flv -c:a copy -c:v mpeg4 -b:v 1000k myfile.avi
[23:02] <Cracki> that should do nicely
[23:02] <Cracki> file might get bigger but it'll be as sharp as the original
[23:02] <francesco_> Cracki, what does it mean, exactly?
[23:03] <Cracki> -c:a is "codec:audio" and "copy the stream"
[23:03] <Cracki> so the audio is copied without change.
[23:03] <Cracki> -c:v asks for mpeg4 (think xvid) and -b:v asks for 1 Mbit/s which is plenty for that video resolution
[23:04] <francesco_> I'll try so. Any idea of why I can't install ffprobe?
[23:04] <Cracki> that's between you, your system packet manager and the support channel of your operating system ;)
[23:05] <Cracki> either you have ffprobe already or they packaged it somewhere nobody will find it
[23:06] <francesco_> Cracki, unrecognized option -c:v.
[23:06] <Cracki> uh -vcodec
[23:06] <Cracki> same for -acodec
[23:07] <Cracki> also -b 1000k instead of -b:v, I figure
[23:08] <francesco_> Ok. Old version of ffmpeg?
[23:08] <francesco_> It seems it's doing fine, now.
[23:08] <rsully> Cracki any reason mpeg4 over x264?
[23:08] <Cracki> dvd players might be too old to handle that
[23:09] <rsully> ah yeah
[23:09] <Cracki> mpeg2 ok, mpeg4 if they're advertising "xvid/divx"
[23:10] <Cracki> ya old versions of ffmpeg don't understand stream specifiers (:a and :v)
[23:10] <francesco_> I think I need to update my OS with a new one, but I should free my HDD first of all the junk that I have. :)
[23:11] <fhenning09> Was just gonna let you know that that command worked like a charm earlier cut it down to where they show up as they were supposed to thanks
[23:11] <fhenning09> the subs i mean
[23:18] <francesco_> Cracki, the quality is pretty much the same. The original one seems more "bright", though. I think I have to work on the options that you showed me, and that I didn't know. Further suggestion?
[23:19] <Cracki> nothing so far. the brightness can be related to different level specifications. there's 0-255 and 16-235.
[23:19] <Cracki> if you find anything on this, try it.
[23:20] <Cracki> some player software can misinterpret levels too
[23:20] <francesco_> Cracki, perhaps I'm confusing brightness with more definition. :(
[23:21] <Cracki> hmhm. if the image looks faded and blacks/whites aren't black/white, then that's it.
[23:21] <Cracki> if the picture looks blurry, that might be because that video has a really odd resolution.
[23:21] <Cracki> you can try to have ffmpeg rescale the video. -vf scale=...
[23:21] <Cracki> depends on what your dvd player works best with, or what display is attached
[23:22] <francesco_> Where could I find further details about video formats. I'm not an expert. Just to know what I'm talking about.
[23:23] <Cracki> uh I'm not aware of a decent article on that.
[23:23] <Cracki> DVDs have some defined formats (resolution, aspect ratio, frame rate, ...)
[23:24] <francesco_> Ok. Thank you very much.
[23:26] <Cracki> llogan, I'm not sure how to feel about the last comment on my ticket. yes, it's variable frame rate, insofar as null frames should have been produced by lagarith.
[23:49] <llogan> Cracki: i didn't really get to look at it much yet. if ffplay or ffmpeg output looks different than the lagarith native decoder then to me that's a ffmpeg bug
[23:50] <llogan> ...usually
[23:50] <Cracki> the person on the ticket referenced some other tickets that look like the behavior is known and patches exist
[23:51] <Cracki> but hey, avconv does even crazier stuff, so ffmpeg is ahead ;)
[23:52] <llogan> cehoyos triages most tickets, and knows most about the existance of other tickets, but his comments are his opinions
[23:52] <llogan> (again i didn't really look yet)
[23:52] <Cracki> i understand :)
[23:54] <Cracki> I understand "first level" work perfectly well *g*
[00:00] --- Wed Nov 19 2014


More information about the Ffmpeg-devel-irc mailing list