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

[burek]

[03:04] <hightall> hello every
[03:04] <hightall> hi
[03:04] <hightall> any one?
[03:05] <hightall> is this ffmpeg channel?
[03:05] <hightall> somebody help me
[03:05] <sacarasc> hightall: Most IRC communication is asynchronous, that means you shouldn't wait for an answer like that, but just ask your actual question.
[03:06] <hightall> how can i compile ffmpeg with vsz
[03:07] <hightall> how can I compile ffmpeg with vsa
[03:10] <sacarasc> hightallyht: What is vsa?
[03:11] <hightallyht> it is a gcc parameter
[04:15] <hightall> hello
[04:16] <hightall> q_bit hello
[06:45] <metaphysician> .ffpreset files should contain option=value pairs. How do I add the -vn  (disable video recording) flag to a .ffpreset?
[10:54] <jarainf> Is it possible to use a x11grab in a complex filtergraph?
[10:54] <jarainf> I'm currently stuck with:
[10:54] <jarainf> Stream specifier 'in' in filtergraph description [in]setpts=PTS-STARTPTS[x11grab] matches no streams.
[11:17] <Aiena> is it pssible to tell ffmpeg to grab a specific window only for screen capture ?
[11:18] <Aiena> e.g. if I specifiy the pid to it ?
[11:20] <Aiena> i mean fo it to capture actuin within a specific open application only
[11:20] <Aiena> no matter where it moves
[12:29] <pespin> Hi, I'm trying to use ffmpeg to encode a real time streaming with h264 (x64 encoder). I am using "zerolatency" option, and as far as I see now I get 1 frame delay latency
[12:30] <pespin> I need to drop the latency to 0 frames.
[12:30] <pespin> I think it's related to the fact that ffmepg sets x264's "b_vfr_input" property to 1, which adds that 1 frame of extra latency
[12:31] <pespin> I can't find the way of disabling it through ffmpeg API though :/
[12:31] <pespin> any hints appreciated :)
[12:40] <Aiena> pespin no idea
[12:40] <Aiena> I am seeking help too
[12:40] <Aiena> I CANT;T GET -QSCAL 0 TO WORK
[12:40] <Aiena> *-qscale 0
[12:45] <Aiena> pespin do you know which video codec is best for encoding with windows ?
[12:46] <pespin> Aiena: what does "best" mean in this case? :P
[12:46] <Aiena> pespin which is not too lossy
[12:46] <Aiena> msmpegv2 wokrs everywhere ?
[12:47] <Aiena> pespin or a decent codec to encode with and preserve quality when encoding into avi's
[12:47] <Aiena> ffv1 seems to not play on windows
[12:49] <Aiena> pespin okmpeg leads to too much graniness
[12:54] <pespin> Aiena: I guess most people use h264 or vp8
[12:58] <Aiena> thanks pespin
[12:58] <Aiena> pespin what is the best container for windows and linux ?
[12:58] <Aiena> sometihng which works out of the box with WMP and can be encoded in linux ?
[12:59] <pespin> Aiena: no idea about containers
[12:59] <Aiena> OK thanks
[12:59] <Aiena> pespin what format do you normally encode in ?
[12:59] <Aiena> .mpg ?
[12:59] <Aiena> and also what bitrate do you normally use ?
[13:02] <pespin> Aiena: I don't do video files :)
[13:02] <Aiena> pespin OK sorry to bother you
[13:02] <Aiena> But thanls for the h264 tip
[13:02] <Aiena> really helped a lot
[13:02] <pespin> np!
[13:03] <Aiena> this channle is so quiet with so many people
[13:03] <Aiena> I just can;t fathom why (:
[13:03] <Aiena> you were one of the few who responded :P
[14:16] <Obi-Wan_> hello guys
[14:16] <Obi-Wan_> I was looking for someone to help
[14:19] <zap0> i helped, once.
[14:19] <Obi-Wan_> I have an MPEG-TS with an AVC/H.264 video and an AAC audio
[14:19] <Obi-Wan_> sorry but I am a newbie
[14:20] <Obi-Wan_> I would like to convert boath audio and video into one .MPEG file
[14:20] <Obi-Wan_> thank you, zap0 this can be the second time :)
[14:21] <zap0> sounds like a newbie/common  problem.  i would bet all my monies, and all my neighbours monies that there is an example of this on the examples page.
[14:22] <Obi-Wan_> also in case of this input file?
[14:22] <Obi-Wan_> http://pastebin.com/5ibTc76H
[14:24] <Obi-Wan_> what I should looking for, zap0? (and where, please)?
[14:27] <jarainf> Obi-Wan_, do you want to ictv it?
[14:29] <Aiena> HI zap0
[14:29] <Obi-Wan_> sorry, what do you mean with ictv ?
[14:29] <Obi-Wan_> (thank you jarainf for you reply)
[14:30] <Obi-Wan_> hello Aiena
[14:30] <Aiena> Hi
[14:30] <jarainf> do you want to deinterlace it and decimate it to 23.976 fps?
[14:30] <Obi-Wan_> no, no
[14:31] <Obi-Wan_> I simply need to generate a .MPEG file
[14:31] <Obi-Wan_> I will rip the result with avidemux later
[14:31] <Aiena> jarainf do you know which codec and video contaner is best across all platforms ?
[14:31] <jarainf> Aiena, I would recommend matroska (.mkv)
[14:31] <Aiena> and vcodec ?
[14:32] <jarainf> x264
[14:32] <Aiena> ffv1 does n ot work well on windows
[14:32] <Aiena> Ok jarainf how would I boots the quality of the x264 video ?
[14:32] <Aiena> boost
[14:32] <Aiena> also it complains about data not in sync leading to frame loss
[14:32] <jarainf> Aiena, what do you mean by boost?
[14:33] <Aiena> I mean increase the quality what bitrate should I use ?
[14:33] <Aiena> reduce presense of artifacts due to compression
[14:33] <Obi-Wan_> jarainf, of course I would like to leave the quality the same
[14:34] <jarainf> Obi-Wan_, try ffmpeg -i input -c copy -f mpeg output.mpeg
[14:34] <blight> hi guys
[14:34] <Obi-Wan_> hi blight
[14:34] <blight> does anybody know if there is a lossless audio format which i can put into mp4 together with h264 videoß
[14:34] <jarainf> Aiena, if you already have artifacts in your source there is no way to "boost" its quality by simply reencoding it
[14:35] <blight> i know mkv works with h264+flac but thats not supported by the app with which i want to open the video
[14:35] <Aiena> jarainf the source is the x11grab itself
[14:35] <jarainf> Ah
[14:35] <Aiena> i.e. a grab of my desktop so the source is clean
[14:36] <Aiena> i just altered the script to capture a specific window area by using data from xwinfo
[14:36] <jarainf> Aiena, how does your current command look like?
[14:37] <Aiena> ffmpeg -f x11grab -y -r 24 -s $WIN_GEO -i :0.0+$WIN_XY -vcodec h264 $NAME.mp4
[14:37] <Aiena> WIN_XY is the offset and WIN_GEO  is the size here
[14:37] <Aiena> $NAME is name of file specified in the shell jarainf
[14:37] <Obi-Wan_> jarainf, sorry to bother you again ... would you be so kind to tell me if I can reach my goal with ffmpeg?
[14:38] <jarainf> Obi-Wan_, did you try my command?
[14:38] <Aiena> jarainf it is designed to capture video with no audio
[14:38] <Obi-Wan_> no, sorry ... I thought you where talking with someone else
[14:38] <jarainf> Aiena, so you are currently having problems with artifacts?
[14:38] <Obi-Wan_> :/
[14:39] <Obi-Wan_> now I got it
[14:39] <Aiena> jarainf yes a bit I just need to increase the bit rate a bit more
[14:39] <Aiena> but not sure how or if its desirable
[14:39] <jarainf> You should try first by setting presets
[14:40] <Aiena> presets like ?
[14:40] <JEEB> if you are not trying to hit a specific file size over time (average bit rate over the whole file), then use the crf rate control (which is the default one for libx264). -crf 23 is the default, and higher uses less rate and lower uses more rate. Use the highest that still looks good
[14:41] <JEEB> as for presets, those control speed vs compression settings
[14:41] <jarainf> Aiena, ffmpeg -y -i input -c:v h264 -preset -tune -f mp4 /dev/null
[14:41] <jarainf> I don't know if output to /dev/null is simulated in windows
[14:41] <JEEB> it's NUL on windows
[14:41] <jarainf> But this should give you a list of available presets
[14:41] <JEEB> and no, it will most probably just tell you that -tune is not a valid preset :P
[14:42] <jarainf> Ah, thank you JEEB
[14:42] <JEEB> if you are doing realtime encoding you probably want to pick a preset that's still fast enough
[14:42] <JEEB> also personally I wouldn't do a "final encode" live
[14:42] <JEEB> because realtime encoding puts constraints on you
[14:42] <JEEB> personally I would just use crf zero (or quantizer zero) to losslessly encode the clip
[14:42] <JEEB> and then encode with a slower preset afterwards for final distro
[14:44] <JEEB> http://mewiki.project357.com/wiki/X264_Settings#preset
[14:44] <JEEB> list of presets, btw
[14:47] <Aiena> JEEB so what would you recommend I just dump raw frames and then encode more slowly later ? also how would I do this two phase operration I read the guides inline but ffmpeg is complex and there are so many ways of doing something that it is confusing
[14:47] <Aiena> also they don;t explain what they are doing very well often
[14:47] <JEEB> not raw frames
[14:47] <JEEB> lossless compression is compression
[14:47] <JEEB> it's just that you get what you pushed into the encoder when you decode it :P
[14:47] <Obi-Wan_> jarainf, thank you this is the result > http://pastebin.com/3U6Ky2a0 <
[14:48] <Obi-Wan_> but unfortunately I cannot see any video
[14:48] <Obi-Wan_> :(
[14:48] <JEEB> Aiena, you already have most of the stuff up until the input done, and it's not really that hard after that
[14:48] <Obi-Wan_> my input is available here > http://www.hdpvrcapture.com/hdpvrcapturev3/samples/20131211_102729-1920x1080p30.ts <
[14:48] <JEEB> -c:v libx264 -crf 0 -preset preset_that_is_fast_enough_for_you
[14:48] <JEEB> that should give you lossless 4:2:0 YCbCr
[14:49] <Aiena> ok I have to google the -crf 0  option
[14:49] <JEEB> and then you tweak the crf and preset to your liking after you have captured
[14:49] <JEEB> crf is constant rate factor
[14:49] <JEEB> zero with 8bit x264 is a special value, sets lossless coding
[14:49] <JEEB> same as setting the quantizer to zero
[14:49] <JEEB> higher bit depth x264 has that value go negative, so you want to use quantizer zero in those cases
[14:50] <Aiena> ok
[14:50] <JEEB> (otherwise the CRF value range goes bonkers, by adjusting where the "zero" is one can use similar CRF values between bit depths)
[14:50] <JEEB> (for lossy that is)
[14:51] <Aiena> JEEB "ffmpeg -f x11grab -y -r 24 -s $WIN_GEO -i :0.0+$WIN_XY -vcodec h264 -crf 0   $NAME.mp4" would be correct ? where win_geo is the size and win_xy is the offset ?
[14:51] <Obi-Wan_> jarainf, I examined the result with mediainfo
[14:51] <JEEB> yes, that would use the "medium" preset (default for x264) and c:v/vcodec h264 just happens to work, the actual encoder is called "libx264"
[14:52] <Obi-Wan_> it seems that the output is againg AVC and not MPEG-2
[14:52] <JEEB> just that you only have libx264 as a AVC/H.264 encoder, so it probably auto-picks by that
[14:52] <JEEB> when you set "h264" as the encoder
[14:52] <Aiena> JEEB so I should replace h264 with libx264?
[14:52] <JEEB> do as you wish, I don't see another H.264 encoder picking pace by now :P
[14:53] <JEEB> but libx264 gets less weird looks
[14:53] <Aiena> Ok
[14:53] <jarainf> Obi-Wan_, ohgod
[14:53] <jarainf> I'm sorry
[14:53] <JEEB> because it sets the encoder specifically, and many people helping probably aren't going to be expecting that you are using the auto-mapping
[14:53] <jarainf> I misread the mediainfo
[14:54] <Aiena> JEEB Ok
[14:54] <Obi-Wan_> jarainf, it's my fault
[14:54] <Obi-Wan_> probably I was not clear enough
[14:54] <Obi-Wan_> :(
[14:54] <jarainf> Na, it was
[14:54] <jarainf> it was mine*
[14:55] <Obi-Wan_> no problem
[14:55] <Obi-Wan_> I will patiently wait
[14:55] <Obi-Wan_> :)
[14:57] <jarainf> ffmpeg -i input -vcodec mpeg2video -acodec copy -f mpeg output.mpeg should do the trick, but you'll get artifacts from reencoding
[14:58] <Obi-Wan_> what do you mean with get artifacts from reencoding?
[14:58] <JEEB> the default for most video encoders is 200kbps
[14:58] <JEEB> and mpeg-1 feature set
[14:59] <Aiena> JEEB how would I specify "libx264-lossless_fast" preset ? woud I say -preset libx264-lossless_fast.ffpreset $NAME.mp4 ?
[14:59] <JEEB> ugh, no
[14:59] <Aiena> then
[14:59] <JEEB> that command line is short enough by itself, isn't it?
[14:59] <JEEB> also the setting for setting the derpy ffpreset files is -vpre
[15:00] <JEEB> not -preset
[15:00] <Aiena> Ok
[15:00] <JEEB> -preset is a x264-specific setting that sets the libx264 preset
[15:00] <Aiena> ok a bit confusing sigh
[15:00] <JEEB> like -preset fast, which sets the 'fast' preset from the list of presets that can be easily seen @ http://mewiki.project357.com/wiki/X264_Settings#preset
[15:01] <Aiena> i ingnored it and just specified libx264 FILENAME
[15:01] <JEEB> yes, default preset is 'medium'
[15:01] <Aiena> ok
[15:02] <jarainf> Obi-Wan_, -acodec libmp3lame
[15:02] <Aiena> but slower the better in this aspect for quality
[15:02] <blight> so lame!
[15:02] <blight> -acodec flac !
[15:02] <blight> :p
[15:02] <JEEB> Aiena, only with lossy, lossless coding just has you compress the data more or less
[15:02] <jarainf> Obi-Wan_, you might need that, I'm not sure if .mpeg supports aac
[15:02] <JEEB> if you're doing live encoding you most probably will want to use a fast'ish preset
[15:02] <Aiena> JEEBok so since I set crf 0 the preset is irrelevant
[15:03] <Aiena> JEEB ok so since I set crf 0 the preset is irrelevant
[15:03] <JEEB> not irrelevant, it sets the amount of CPU power used for compression
[15:03] <Aiena> Ok
[15:03] <JEEB> but it is irrelevant for quality, yes
[15:03] <JEEB> you just get a bigger or a smaller file
[15:04] <Aiena> JEEB how do I make ffmpeg use both cores (i have 2 cores 4 threads but hyperthreading does not make much of a difference)
[15:04] <JEEB> libx264 should be defaulting to as many threads as you have CPUs (including virtual ones) by default as long as your build isn't 2-3 years old
[15:04] <Aiena> No its latest
[15:05] <Aiena> JEEB I am using 2.1.3
[15:05] <Aiena> or recent enough
[15:05] <Aiena> yeah it seems up to date
[15:07] <jarainf> 8
[15:07] <Obi-Wan_> jarainf, the conversion works fine
[15:07] <Obi-Wan_> but the quality is very low
[15:08] <Obi-Wan_> is it possible to keep the same quality?
[15:08] <Aiena> JEEB I get extremelty small file sizes with h264 (670kb for like 10 seconds) but the quality is not as good with crf 0 I can't figure out why
[15:09] <jarainf> Obi-Wan_, you can set the videobitrate with -b:v
[15:09] <JEEB> the only difference would be the colorspace, libx264's encoder defaults to 4:2:0 for compatibility reasons
[15:09] <jarainf> But as far as I know mpeg2 does not support lossless reencoding
[15:09] <JEEB> Aiena, you can see what you're comparing against
[15:09] <JEEB> by comparing the logs of whatever you encoded first
[15:09] <JEEB> and whatever you just encoded
[15:09] <Aiena> JEEB I am comparing against the output of the ffv1 codec
[15:09] <JEEB> well look what colorspace it used :P
[15:09] <Obi-Wan_> jarainf, and what about mpeg1?
[15:10] <JEEB> it should tell you if it used rgb, or if it used yuvXXXp or whatever
[15:10] <jarainf> it's worse
[15:12] <Obi-Wan_> jarainf, do you think that -qscale 1 is a good option?
[15:12] <JEEB> Aiena, if you're indeed comparing ffv1 encoding in RGB and libx264 in yuv420p, then you can just switch from the libx264 encoder to the "libx264rgb" one, which is pretty much the same, it just defaults to RGB instead of 4:2:0 YCbCr
[15:13] <jarainf> Obi-Wan_, you should try yourself
[15:14] <jarainf> I would go for 2 or 3 though
[15:15] <Obi-Wan_> -qscale 1 is the maximum quality I can reach, right?
[15:15] <jarainf> yes.
[15:15] <JEEB> Aiena, do note though that for final distribution, if you want your stuff to be widely supported, 4:4:4 modes are a no-go (RGB and 4:4:4 YCbCr are the things encoded with the 4:4:4 mode), as it's not supported by any commercial decoder
[15:16] <JEEB> (and that is why the non-rgb libx264 "encoder" defaults to 4:2:0 YCbCr)
[15:17] <Obi-Wan_> thank you jarainf
[15:17] <Obi-Wan_> I have also found these options
[15:17] <Obi-Wan_> -pix_fmt yuv422p -qscale 1 -qmin 1 -intra -an
[15:17] <Obi-Wan_> do they make sense for you to improve quality?
[15:20] <jarainf> they probably do
[15:20] <jarainf> while -an disables audio
[15:20] <jarainf> -intra does give you only I-Frames though
[15:20] <jarainf> afaik
[15:20] <jarainf> but dont quote me on that
[15:21] <Obi-Wan_> ok :)
[15:24] <Obi-Wan_> jarainf, just one couple of things
[15:25] <Obi-Wan_> > ffmpeg -i [INPUT] -vcodec mpeg2video -qscale 1 -acodec mp2 -b 320k -f mpeg output.mpeg <
[15:26] <Obi-Wan_> does it make sens for you?
[15:27] <jarainf> Uh
[15:27] <jarainf> -b sets your bitrate
[15:27] <jarainf> so you'd set the bitrate to 320k
[15:28] <Obi-Wan_> it's constant bitrate encoding, right?
[15:29] <JEEB> just -b is ambiguous
[15:29] <JEEB> use -b:a for audio
[15:29] <JEEB> and -qscale:v for video
[15:31] <jarainf> what JEEB said
[15:35] <Obi-Wan_> thank you JEEB and jarainf
[15:35] <Obi-Wan_> I also have this error:
[15:35] <Obi-Wan_> [h264 @ 03029800] Cannot use next picture in error concealment
[15:35] <Obi-Wan_> [h264 @ 03029800] concealing 110 DC, 110 AC, 110 MV errors in P frame
[15:35] <Obi-Wan_> after a lots of frames processed with no errors
[15:37] <Obi-Wan_> this is the complete result
[15:37] <Obi-Wan_> http://pastebin.com/76xwtmuw
[15:40] <jarainf> A p-frame is a predicted frame
[15:41] <jarainf> It's basically a diff from a frame presented before this one
[15:41] <Obi-Wan_> so, it's an info, a warning or an error?
[15:41] <jarainf> I'm only guessing here, but due to the nature of encodes it might be the case that the i-frame on which this p-frame relies may not be in the transportstream
[15:42] <jarainf> the encode should still be fine
[15:42] <jarainf> it's no fatal error :3
[15:42] <Aiena> I get tihs message
[15:42] <Aiena> [swscaler @ 0x74f180] deprecated pixel format used, make sure you did set range correctly
[15:42] <Aiena> No pixel format specified, yuv444p for H.264 encoding chosen.
[15:42] <Aiena> Use -pix_fmt yuv420p for compatibility with outdated media players.
[15:42] <Aiena> How should I address it ?
[15:42] <Obi-Wan_> jarainf, and what about this warning?
[15:43] <Obi-Wan_> [mpeg @ 0303f020] VBV buffer size not set, muxing may fail
[15:43] <Obi-Wan_> should I set the VBV buffer?
[15:43] <jarainf> Aiena, you probably want to use -pix_fmt yuv420
[15:44] <JEEB> Aiena, post command and full log :P
[15:44] <JEEB> on pastebin
[15:44] <Aiena> ok
[15:44] <JEEB> and link your pastebin here
[15:45] <Aiena> JEEB http://pastebin.com/7Dcq9Mmr
[15:45] <Obi-Wan_> jarainf, and the other strange thing is that VLC is not able to detect the duration of the output :(
[15:45] <Obi-Wan_> I am not sure everything went fine :'(
[15:45] <JEEB> Aiena, that doesn't contain the actual ffmpeg command :P
[15:45] <jarainf> Huh.
[15:45] <Aiena> JEEB can I pm you the script ?
[15:45] <JEEB> no
[15:46] <Aiena> Ok
[15:46] <JEEB> just note what the hell you're doing there with ffmpeg and that's it
[15:46] <jarainf> Obi-Wan_, VBV stands for Video Buffering Verifier
[15:46] <jarainf> It basically ensures, that an mpeg encode can be properly decoded
[15:47] <Obi-Wan_> well, thank you
[15:47] <Aiena> Ok
[15:47] <Aiena> one sec
[15:47] <Obi-Wan_> so, what I can do to solve this warning?
[15:47] <jarainf> I don't really get what a verified buffering verifier buffer should be, though.
[15:48] <JEEB> jarainf, Obi-Wan_ -- basically mpeg-ts and probably mpeg-ps are made for bandwidth limited muxing (you set VBV variables and it muxes accordingly, and adds extra padding when needed to hit the set maxrate over bufsize)
[15:48] <JEEB> basically it's saying that he hasn't set that and thus depending on the muxing mode it might fail
[15:48] <JEEB> that's more or less what it means
[15:48] <JEEB> if the output works fine, then that's fine
[15:48] <jarainf> Ah, that makes sense.
[15:49] <Obi-Wan_> JEEB: YEAH, thank you ... but the result is strange
[15:49] <Obi-Wan_> VPL is not able to detect the lenght of the file, for example
[15:49] <Obi-Wan_> *VLC not VPL sorry
[15:49] <JEEB> well given the container
[15:49] <Aiena> JEEB http://pastebin.com/tqA5ff02 should do it
[15:50] <JEEB> any length is guesswork :P
[15:50] <JEEB> Aiena, surprising that it picks 4:4:4 YCbCr by default
[15:50] <Obi-Wan_> JEEB, sorry I did not understand
[15:50] <JEEB> you probably want RGB, though
[15:51] <Aiena> JEEB but RGB will work well on windows too ?
[15:51] <Aiena> h264RGB ?
[15:51] <Aiena> also files are ultra light this makes text rendering is specific cases not sharp enough
[15:51] <JEEB> Aiena, well didn't we just goddamn go over that it's better to capture stuff in lossless and then encode it with better compression for final distribution or whatever
[15:52] <JEEB> also way to go ignoring the crf recommendation
[15:52] <Aiena> JEEB we did but you said crf 0 was lossless
[15:52] <JEEB> yes
[15:52] <JEEB> you are using -b:v 1000k
[15:53] <JEEB> so unless you posted the wrong information (I JUST NEEDED THE FUCKING FFMPEG LINE FOR FUCK'S SAKE), you are just trying to play with me
[15:53] <JEEB> Obi-Wan_, the mpeg-ps container has no length information in it, so the only way to guess the length is when the mux is of constant rate and thus you can just divide the file size with the mux rate
[15:53] <Aiena> JEEB got disconnected what was the last line I mentioned ?
[15:54] <jarainf> <Aiena> BEEJ we did but you said crf 0 was lossless
[15:54] <JEEB> Aiena, I'm sorry, find someone else to waste time because you clearly are ignoring any recommendations.
[15:56] <Aiena> JEEB alright I am sorry I did try your recommendations I did exactly as told except that I used -b:v to try to understand how that option worked
[15:56] <Aiena> I am sorry if I ghurt your feelings in any way.
[15:57] <Obi-Wan_> JEEB, so a MPEG .TS container should be better?
[15:57] <JEEB> you didn't, it's just aggravating when people clearly ignore when you're trying to guide them to a good way of doing things
[15:57] <JEEB> Obi-Wan_, > implying that has it either
[15:58] <jarainf> Obi-Wan_, wasn't the whole point to have an mpeg container?
[15:58] <JEEB> although what players do to guess the length in those containers can depend, so everything depends on what the flying derp you want :D
[15:59] <Obi-Wan_> OK!
[15:59] <Obi-Wan_> when I will be at home I will try to see if audio and video are in sync
[15:59] <Aiena> JEEB I took everything you told me into consideration I was just experimenting at the end sorry. Jee what is the difference beween -qp 0 and -crf 0
[15:59] <jarainf> Obi-Wan_, btw, why do you need to reencode the ts?
[16:00] <Obi-Wan_> jarainf, the issue is that I have an Hauppage HD PVR recorder
[16:00] <JEEB> Aiena, quantizer zero works with all bit depths in x264 (8,9,10) while crf 0 only works with 8bit
[16:00] <Obi-Wan_> it records in AVC/H.264 and this is not well handled by AVIdemux
[16:00] <Aiena> Ok and how do I set the bit depth for the h264 codec ?
[16:00] <JEEB> you can't on runtime
[16:00] <JEEB> it's a build-time thing
[16:00] <Obi-Wan_> so I need to convert H.264 to MPEG
[16:01] <Obi-Wan_> and so to be handled by AVIdemux without issues
[16:01] <Aiena> JEEB Ok thank you for all your help
[16:01] <Aiena> I will ask you if I am unsure of something.
[16:01] <jarainf> Obi-Wan_, what do you need AVIdemux for?
[16:01] <Obi-Wan_> does it make sens for you, jarainf?
[16:01] <Obi-Wan_> I use it to encode the video in Xvid/MP3
[16:01] <Obi-Wan_> after applying filters
[16:02] <Obi-Wan_> such as deinterlacing
[16:02] <Obi-Wan_> cropping
[16:02] <Obi-Wan_> resizing
[16:02] <Obi-Wan_> and so on
[16:02] <jnvsor> Is flac a good lossless audio codec?
[16:02] <jarainf> you can do all that in ffmpeg too
[16:02] <Obi-Wan_> Yes, you are right
[16:03] <Obi-Wan_> but, as you know I am a newbie
[16:03] <Obi-Wan_> and not very confident with command lines tools
[16:03] <Obi-Wan_> last question, please
[16:03] <Obi-Wan_> how can I transform from 30fps to standard PAL 25 fps?
[16:04] <Dark-knight> anybody want to play a free fps with me?
[16:07] <Dark-knight> im done re-muxing all my videos
[16:07] <Aiena> JEEB I let my freind on windows test the h264 encoded stream it is not playable on windows with WMP. I read somewhere that windows sometimes does not play a strem if audio is not present or somethig how do I put a dummy silet audio track ?
[16:07] <jarainf> Obi-Wan_, -vf=fps decimates the stream to a default of 25 fps
[16:08] <Aiena> I encoded it with the regular -crf 0 option
[16:08] <JEEB> well, d'uh
[16:08] <jarainf> But I'm not sure if that's enough to be PAL conform or how it handles with interlaced frames
[16:08] <JEEB> seriously, I went over this already
[16:08] <Aiena> JEEB let me look up
[16:08] <Aiena> one sec
[16:09] <JEEB> 1) lossless is not supported in commercial decoders 2) anything but 4:2:0 -||-
[16:09] <Obi-Wan_> jarainf, -vf=fps seems to be not a valid options
[16:09] <JEEB> so for the file for distribution you will want to use the non-rgb encoder and crf higher than 0
[16:10] <Aiena> Ok I did not know about crf 0 not being supported I knew about RGB not being supported
[16:10] <Aiena> from you
[16:10] <Aiena> JEEB they don;t mention it https://trac.ffmpeg.org/wiki/x264EncodingGuide either
[16:11] <jarainf> Obi-Wan_, -vf "fps=fps=25"
[16:11] <jarainf> or -vf "fps"
[16:11] <JEEB> 23 is the default, lower makes x264 do less error, higher makes x264 do more error. thus for lossy you pick the highest value that still looks good
[16:11] <Aiena> Ok I am testing with 18
[16:12] <Aiena> -crf 18
[16:15] <Aiena> JEEB even with -crf 18 it is not working on windows
[16:15] <Aiena> JEEB can I try adding a dummy audio channel ?
[16:16] <Aiena> how would I do that
[16:16] <Aiena> JEEB also is mp4 an ok container for h264 video ?
[16:16] <Aiena> or is it a container issue ?
[16:17] <Obi-Wan_> thenk you once more, jarainf
[16:17] <JEEB> Aiena, show current line and log
[16:17] <Obi-Wan_> -vf "fps=fps=25" is fine
[16:17] <JEEB> pastebin
[16:17] <Aiena> JEEB one moment
[16:18] <Obi-Wan_> since I know that the max bitrate is 18.8 Mbps
[16:18] <Obi-Wan_> do you know if I can set this
[16:18] <Obi-Wan_> ad a cbr for the output
[16:19] <Obi-Wan_> I am not sure but in this way I should reach the max quality
[16:19] <jarainf> Obi-Wan_, -vf fps does the same, -vf=fps just doesn't work because of syntax
[16:19] <jarainf> I'm a bit tired.
[16:19] <jarainf> Obi-Wan_, setting a constant bit rate does not improve quality
[16:19] <jarainf> bit rate is not directly proportional to quality
[16:21] <Aiena> JEEB HERE http://pastebin.com/4NzJTXVq
[16:21] <Aiena> *here
[16:21] <JEEB> interesting
[16:22] <JEEB> I would think that version would default to 4:2:0
[16:22] <JEEB> -pix_fmt yuv420p then after -i
[16:22] <Aiena> Ah "4:4:4 8-bit"
[16:22] <Aiena> ok adding
[16:24] <Obi-Wan_> jarainf: I'm very sorry to make you tired ... I will be silent, now. ;-)
[16:24] <Aiena> JEEB should there be a space between " -pix_fmt yuv420p"  and  ":0.0+$WIN_XY" like " -i -pix_fmt yuv420p :0.0+$WIN_XY " or should it be with no space like " -i -pix_fmt yuv420p:0.0+$WIN_XY " ?
[16:24] <jarainf> Obi-Wan_, it's not your fault. After all it's rather me giving you a hard time.
[16:25] <JEEB> Aiena, what do you think ":0.0+$WIN_XY" is?
[16:25] <Aiena> that is offset
[16:25] <JEEB> isn't it a parameter for -i
[16:25] <Aiena> oops
[16:25] <JEEB> thus, if it's a parameter, why are you adding something in between the setting and the parameter :P
[16:26] <JEEB> I did say "after -i" but that means, after setting the input
[16:26] <Aiena> yeah my mistake
[16:26] <Aiena> sorry
[16:26] <Aiena> thaks for pointing it out
[16:28] <Aiena> JEEB "ffmpeg -f x11grab -y -r 24 -s $WIN_GEO -i :0.0+$WIN_XY -pix_fmt yuv420p -vcodec libx264 -crf 18 $NAME.mp4" seems ok to you ?
[16:28] <JEEB> yes
[16:28] <Aiena> OK thanks encoding a new test video
[16:29] <Obi-Wan_> jarainf, I promise this to you ... just the real last thing :)
[16:30] <Obi-Wan_> do you know if there is a loseless codec alternative to MPEG?
[16:30] <jarainf> You can do lossless encodings in x264
[16:31] <jarainf> But you wont be able to fit them into an .mpeg :3
[16:31] <jarainf> but x264 works fine with .mp4
[16:31] <Obi-Wan_> :( unfortunately it's not managed by avidemux :(
[16:32] <jarainf> Obi-Wan_, I think it would suit your needs if you encode tranports-streams in ffmpeg
[16:32] <jangle> Greetings all.  What parts of the library are responsible for parsing an h264 annex b file and passing the data to a decoder?
[16:33] <jarainf> Obi-Wan_, ffmpeg -i transportstream -vf "fieldmatch, yadif=deint=1, decimate, scale=width:heigth" -c:v libx264 -c:a copy -preset slow output.mp4
[16:33] <Obi-Wan_> jarainf, do you mean what we have done now, or other encodings?
[16:34] <Obi-Wan_> but I already have a .mp4 file
[16:34] <jarainf> This will deinterlace your input and decimate it to 23.976 fps
[16:34] <jarainf> It will also scale it to width:height
[16:34] <jarainf> which you would need to specify then
[16:35] <jarainf> Obi-Wan_, is it interlaced?
[16:35] <Obi-Wan_> sometimes yes
[16:35] <Obi-Wan_> sometimes not
[16:36] <Obi-Wan_> and what about from my source to .VOB?
[16:36] <Obi-Wan_> is it better from wyk or not?
[16:36] <Obi-Wan_> compared with the MPEG conversion we have just done?
[16:38] <jarainf> I'm sorry but I don't really get why you need to reencode the stream
[16:39] <jarainf> Your recorder supports x264 and avidemux seems to support mp4 and x264
[16:40] <jarainf> Obi-Wan_, all these are just container formats, it really depends on the reencode you do
[16:41] <jarainf> as in the codec you use
[16:41] <Obi-Wan_> AVIdemux is NOT able to REALLY support
[16:41] <Obi-Wan_> AVC/H.264 codec
[16:41] <Obi-Wan_> at the end of the conversion audio and video goes out of sync
[16:42] <Obi-Wan_> the only option I have is using Xmedia Recode
[16:42] <jarainf> Uhm
[16:42] <jarainf> I doubt that
[16:42] <jarainf> since it uses libx264 and ffmpeg
[16:42] <Obi-Wan_> Do you doubt what?
[16:42] <Obi-Wan_> I have tried
[16:43] <jarainf> Obi-Wan_, does it do that only for interlaced streams?
[16:43] <jarainf> >While Avidemux uses built-in libavcodec from FFmpeg for H.264 decoding, it needs an additional (external) library for H.264 encoding. Therefore Avidemux uses x264.
[16:43] <Obi-Wan_> no, I don't think so
[16:43] <Obi-Wan_> but I am not 100% sure
[16:43] <jarainf> you should test that
[16:43] <jarainf> If it does it only for interlaced streams
[16:44] <jarainf> Then it's probably related to your attempt of ivtcing
[16:44] <Obi-Wan_> no, sorry
[16:44] <Obi-Wan_> the real issue
[16:44] <Obi-Wan_> I have found is from 3-5 seconds of silence
[16:44] <Obi-Wan_> at the beginning of the converted video
[16:45] <jarainf> Obi-Wan_, does it also do that for long videos?
[16:45] <jarainf> or is there a longer period of silence?
[16:50] <jnvsor> I notice niether the ./configure nor the documentation mention flac - is it just baked in and assumed to work?
[16:51] <Obi-Wan_> I do not really know, jarainf
[16:51] <Obi-Wan_> but the other issue is that AVIdemux 2.6 does not support XviD open libraries anymore
[16:53] <jarainf> Obi-Wan_, after processing the files with avidemux, what do you use them for?
[16:55] <Obi-Wan_> sharing, playing on TV and so on
[16:55] <Obi-Wan_> now I have to leave or I will loose the train
[16:56] <jarainf> Obi-Wan_, yeah, see you
[16:56] <Obi-Wan_> thank you very much for your support (also to JEEB)
[16:56] <jarainf> You should try to get rid of avidemux
[16:56] <jarainf> If it's really the fault of avidemux
[16:56] <Obi-Wan_> I will try
[16:56] <Obi-Wan_> and I will probably come back to you
[16:56] <jarainf> feel free to do so
[16:57] <Obi-Wan_> but I think it's an avidemux issue
[16:57] <Obi-Wan_> since with Xmedia Recode
[16:57] <Obi-Wan_> everything is fine
[16:57] <Obi-Wan_> :)
[16:57] <jarainf> honestly, I really can't imagine it being an avidemux issue
[16:57] <Obi-Wan_> bye bye talk to you next time
[17:00] <Aiena> JEEB when using -pix_fmt yuv420p the height of the screen should be divisible by 2 ?
[17:01] <JEEB> the encoded picture should be, yes
[17:01] <JEEB> due to chroma subsampling
[17:01] <Aiena> OK that is why the encoder fails
[17:01] <Aiena> hmm
[17:01] <Aiena> I do not know what to do in this case
[17:01] <JEEB> you can use -vf scale to resize the picture
[17:02] <JEEB> after -i
[17:02] <JEEB> http://ffmpeg.org/ffmpeg-all.html
[17:02] <JEEB> ctrl+F here and you should see both options and examples
[17:04] <Aiena> hmm there is a 0vf frames and a -vf filtergraph
[17:04] <Aiena> the thing is many of these technical terms are alien to me.
[17:04] <Aiena> But let me read more
[17:05] <JEEB> uhh what
[17:05] <JEEB> just ctrl+F for "-vf scale"
[17:05] <JEEB> the scale video filter
[17:06] <Aiena> OK thank you JEEB
[17:11] <Aiena> JEEB is there a way to make h264 encode at a 4000k bit trate constantly
[17:11] <Aiena> or is bitrate limited by the crf factor adncannot go beyond that ?
[17:12] <Aiena> JEEB "ffmpeg -f x11grab -y -r 24 -s $WIN_GEO -i :0.0+$WIN_XY -pix_fmt yuv420p -vf scale=1280:720 -vcodec libx264 -b:v 4000k -minrate 4000k -maxrate 4000k -bufsize 1835k $NAME.mp4" is my current line.
[17:12] <Aiena> I tried to follow a documentation example
[17:13] <JEEB> why the flying fuck do people use -minrate
[17:13] <JEEB> are they fucking dumb
[17:13] <JEEB> anyways, why the fuck would you want fucking pseudo-CBR
[17:14] <JEEB> I've once again lost what the flying fuck you're actually trying to do
[17:16] <Aiena> JEEB ok I was looking at the video and I can't get the text to be sharper. I don;t mind the file being larger. Currently with gh264 enocidng I get files sizes of 400kb for 10 seconds
[17:16] <JEEB> why was your fucking first idea to switch all to something else instead of just using the goddamn tool I had told you
[17:16] <JEEB> which was the CRF value
[17:17] <Aiena> JEEB with CRF too the text is blurry
[17:17] <JEEB> THAT IS BULLSHIT
[17:17] <JEEB> I mean
[17:17] <Aiena> I personally think it is sharp enough
[17:17] <JEEB> CRF does the exact same thing
[17:17] <JEEB> it just sets a rate factor and encodes to it
[17:17] <Aiena> yeah I read and re read the documentation
[17:18] <JEEB> doing 2pass encoding for a bit rate and CRF value for the same file size give the same fucking quality
[17:18] <Aiena> and I was convinced that everything yopiu said was right
[17:18] <JEEB> so as fucking long as you're in the same bit rate spectrum
[17:18] <JEEB> then you are getting the same quality
[17:18] <Aiena> ok
[17:18] <JEEB> so you are either comparing apples to oranges (completely different rates)
[17:18] <JEEB> or you have no idea what 4:2:0 YCbCr and why it looks different to RGB
[17:19] <Aiena> Probably thee other person viewing the video expects something else
[17:19] <JEEB> asdf
[17:19] <JEEB> stop going into conclusions
[17:19] <JEEB> for fuck's sake
[17:19] <JEEB> there are two alternatives
[17:20] <Aiena> Ok
[17:20] <JEEB> the average bit rate of the results (The CRF value you used vs ABR bit rate mode) is different
[17:20] <JEEB> OR
[17:20] <JEEB> one of the clips is 4:2:0 and the other isn't
[17:20] <JEEB> these are the ONLY TWO REASONS WHY YOU WOULD HAVE A DIFFERENCE
[17:21] <JEEB> and if you see a difference and they're both 4:2:0 then just fucking adjust the CRF value accordingly goddamnit
[17:21] <JEEB> instead of saying fuckdumb things like "with CRF the text is blurry"
[17:21] <Aiena> Ok
[17:21] <Aiena> JEEB so the real answer is to switch to an RGB codec
[17:22] <JEEB> well, what the fuck was even compared
[17:22] <jarainf> Wat
[17:22] <JEEB> I'm not an esper
[17:22] <Aiena> JEEB ffv1 versus CRF
[17:22] <JEEB> I'm trying to tell you the two possible sources of differences
[17:22] <Aiena> *libx264 sorry
[17:23] <JEEB> what!?
[17:23] <Aiena> ffv1 vs libx264
[17:23] <Aiena> ffv1 as you mentioned is an RGB one
[17:23] <JEEB> did you make sure that you're comparing the same pixel format output from both?
[17:23] <Aiena> let me rerender one moment
[17:23] <JEEB> if you're comparing RGB to 4:2:0 YCbCr then you're going to see the difference :P
[17:24] <JEEB> because you lose information when converting one to another
[17:24] <Aiena> JEEB  is there a good RGB cross paltform format assuming the video is going to palyed obnly on PC's ?
[17:24] <JEEB> Aiena, "no"
[17:24] <JEEB> at least not for vanilla installations of systems
[17:25] <JEEB> which is what I thought you were aiming for
[17:25] <Aiena> Even with Windows media player installed
[17:25] <JEEB> that is part of "vanilla installation" for me :P
[17:25] <JEEB> and I still don't know your final use case
[17:26] <JEEB> as in, I don't know if you really want to start looking for something very dumb to get RGB (and literally no compression), or if you can just live with 4:2:0 and use something normal and generally supported
[17:26] <Aiena> JEEB so basically flv's are also YCbcR (luminance and chrominance) like telivision ?
[17:26] <JEEB> flv is a container
[17:27] <Aiena> Ok
[17:27] <JEEB> but yes, most if not all video in FLV container is 4:2:0
[17:27] <JEEB> YCbCr
[17:27] <JEEB> heck, most video all around is YCbCr, and in 99%+ of all cases 4:2:0
[17:27] <JEEB> (in production you generally can see 4:2:2 if interlacing is touched)
[17:28] <JEEB> (but end user stuff is pretty much wholly 4:2:0)
[17:29] <Aiena> Ok
[17:29] <Aiena> then I do not know my freind really expected
[17:29] <Aiena> (sigh)
[17:33] <Venti^> Aiena: maybe try turning off true type? then chroma subsampling shouldn't matter
[17:33] <Aiena> Venti^ that is a good Idea but I don;t know how to do that on my linux system
[17:33] <Aiena> let me google it
[17:33] <JEEB> ? truetype, what?
[17:34] <Venti^> font smoothing for lcd's
[17:34] <JEEB> nothing is used in the ffmpeg command that would have /anything/ to do with that
[17:34] <JEEB> oh
[17:34] <JEEB> so to make the source content different?
[17:34] <JEEB> so it might look better with chroma subsampling
[17:34] <JEEB> you kind of noted it in a way that just brought up question marks all over in my brain
[17:35] <JEEB> because freetype in ffmpeg generally means the lulzy ASS subtitle rendering filter
[17:35] <JEEB> which definitely isn't used here
[17:35] <Aiena> Venti^ actually its freetype
[17:36] <Aiena> perhaps font rasterisatyion has something to do with it
[17:36] <Aiena> rasterisation
[17:36] <JEEB> also one old trick was to first resize to 2x width/height and then convert to 4:2:0 YCbCr from RGB
[17:36] <JEEB> the video becomes twice as big, but at least you're kind of unaffected by chroma subsampling
[17:37] <JEEB> (you have to use nearest neighbor resizing, of course)
[17:37] <Venti^> JEEB: I couldn't think of any other reason why chroma subsampling would matter for text blurriness
[17:37] <JEEB> Venti^, well you generally lose contrast after the RGB->YCbCr conversion plus the subsampling
[17:38] <JEEB> I'm not so sure it can be fully mitigated by disabling font smoothing
[17:38] <Aiena> JEEB probably that is the issue but there is no real way around it
[17:38] <Aiena> even with -crf 0
[17:38] <rsdrsdrsd> Is there a universal method to etrieve the height of a video with ffprobe or ffmpeg? With ffprobe I get the info back and can parse it, but sometimes the video stream is on a different index
[17:38] <JEEB> Aiena, there is the "workaround" I noted :P
[17:38] <JEEB> 2x nearest neighbor resize
[17:39] <Aiena> upscale or downscale ?
[17:39] <Aiena> with -vf ?
[17:39] <JEEB> upscale, naturally
[17:39] <Aiena> Ok
[17:39] <JEEB> also make sure with -v debug that it actually first resizes and then converts
[17:40] <JEEB> because it becomes useless if it first converts and then resizes that
[17:40] <Aiena> shoud i put -v debug after -vf=*:* ?
[17:40] <JEEB> you can put it pretty much everywhere, I usually put it in the input options' side (before -i)
[17:40] <JEEB> and it will spam a lot
[17:41] <Aiena> ok can I pastebin output for you to look at ?
[17:41] <Aiena> JEEB someone suggested something like this online -level 3.1 what does that mean ?
[17:42] <Aiena> along with libx264 ?
[17:42] <JEEB> it sets a level and is completely unrelated to this problem
[17:42] <Aiena> ok
[17:42] <JEEB> levels are more or less flags that tell the decoder that it will need X amount of memory to decode the stream
[17:43] <JEEB> just like profiles are things that tell the decoder which features it will need to decode the stream :P
[17:44] <JEEB> scale=w=2*iw:h=2*ih -sws_flags neighbor
[17:44] <JEEB> this should do 2x upscale with nearest neighbor
[17:44] <Aiena> JEEB I thought "-vf scale=2560:1440 "
[17:45] <Aiena> for 720p
[17:45] <JEEB> yes, you can set the actual numbers as well, but it's just simpler to tell it "2x input width/height please"
[17:45] <Aiena> my screen is 1366x768 so cannot get larger than that and I need multiples of 2
[17:46] <Aiena> JEEB actually I tghink so this will be make any resolutioin a mutiple of 2 automatically
[17:46] <Aiena> so that will sove the other problem of enforcing a fixed size
[17:46] <Aiena> solve
[17:46] <JEEB> yes, multiplying by two kind of does that :P
[17:47] <Aiena> JEEB so I shoud replace -vf scale=2560"1440 with "-vf scale=w=2*iw:h=2*ih -sws_flags neighbor"
[17:47] <JEEB> basically yeah
[17:47] <Aiena> Ok trying
[17:48] <Aiena> thank you so much for your patience I know that it taking too much time to wrap my mind around certain ffmpeg concepts
[17:48] <JEEB> oh, you might also need the full_chroma_inp and full_chroma_int flags
[17:49] <JEEB> -sws_flags neighbor+full_chroma_inp+full_chroma_int
[17:50] <JEEB> sets nearest neighbor, and sets some "use chroma better" flags that I'm still not sure what they do exactly :P
[17:50] <Aiena> ok I will try but quality has improved
[17:50] <Aiena> pretty neat thanks JEEB
[17:51] <JEEB> now to just make sure it doesn't first convert the pixel format and then resize
[17:51] <JEEB> but I guess if it looks better then it most probably isn't doing that
[17:51] <JEEB> -v debug should show what kind of filter chains it makes internally I think?
[17:51] <Aiena> Ooh forgot to add the -v debug flag
[17:51] <Aiena> one sec
[17:51] <Aiena> thanks for reminding
[17:52] <JEEB> but yeah, since 4:2:0 basically means that chroma has one value per 2x2 area,  the only thing to kind of mitigate its damage is to upscale 2x
[17:52] <JEEB> of course even that is not perfect
[17:54] <Aiena> JEEB debug output http://pastebin.com/Mjwj9rCy
[17:54] <Aiena> is it doing what it is supposed to do ?
[17:55] <Aiena> because I cannot interepret that output. It has a lot in it I don't know what to look fo
[17:57] <JEEB> meh, swscale is so silent
[17:57] <JEEB> [Parsed_scale_0 @ 0x2583700] w:1366 h:741 fmt:bgr0 sar:0/1 -> w:2732 h:1482 fmt:yuv420p sar:0/1 flags:0x6010
[17:57] <JEEB> this is the input and output of your resizing
[17:57] <JEEB> (and other things)
[17:58] <JEEB> but yeah, if it looks better there's a big chance it actually resizes first
[17:58] <Aiena> ok so the output does not indicate which operation happened first
[17:58] <Aiena> JEEB will upscaling 4x be better ?
[17:58] <JEEB> no
[17:59] <Aiena> Ok
[17:59] <JEEB> "4:2:0 basically means that chroma has one value per 2x2 area"
[17:59] <JEEB> that's where the 2x upscale thing comes from :P
[18:00] <Aiena> JEEB what if I use lanczos instead of neighbor ?
[18:00] <Aiena> for upscaling ?
[18:00] <Aiena> i know lanczos is better for downscaling usually
[18:00] <JEEB> well then you are no longer making the process less reversable'ish :P
[18:00] <JEEB> uhh
[18:00] <JEEB> remove the less
[18:00] <JEEB> basically you can reverse nearest neighbor scaling rather easily
[18:01] <Aiena> Ok
[18:04] <Aiena> JEEB suppose I encode at 2x scale and then downscale later again the text will become blurry right ?
[18:04] <Aiena> Downscale with ffmpeg to the actual resolution
[18:05] <klaxa> depends on the algorithm i think
[18:05] <JEEB> Aiena, well the idea was to get around chroma subsampling by having all details be at least of the size 2x2...
[18:06] <Aiena> OK so resizing the output post rendering will not matter
[18:06] <JEEB> "post rendering"?
[18:06] <JEEB> you mean during playback?
[18:06] <JEEB> yes, the idea is that you can then have the playback side enjoy it in any way it wants
[18:06] <Aiena> i mean after rendering/encoding from the screen into the original file
[18:07] <JEEB> since stuff generally gets converted to RGB first, before being scaled
[18:07] <JEEB> so resizing during playback is just fine
[18:07] <Aiena> Ok but resizing withh ffmpeg itself is not ?
[18:08] <Aiena> with ffmpeg the source mpg
[18:08] <JEEB> but wasn't your idea to create a file that was playable on "vanilla" systems?
[18:09] <JEEB> I really am having difficulty trying to parse what you're trying to say
[18:09] <Aiena> jeeb isnt mp4 just a container ?
[18:09] <JEEB> yes?
[18:09] <Aiena> so if the video in it is h264 it should play on WMP right
[18:09] <JEEB> if it's 4:2:0 and not lossless, yes
[18:10] <Aiena> ok let me look at my log
[18:12] <JEEB> anyways, as I still didn't understand your ffmpeg/resizing question, here's a generic answer: after you have the 2x 4:2:0 YCbCr content, you cannot downscale that in the same pixel format if you do not want to lose the effect you gain by upscaling it to begin with (not having details that are smaller than 2x2)
[18:13] <JEEB> you can make the playback window smaller during playback because at that point the picture has already been converted to RGB in most cases, and thus you have no subsampling
[18:19] <Aiena> Ok
[18:19] <Aiena> SO downscaling with ffmpeg will in effect make the output the same as if it was upscaled and rendered normally
[18:19] <Aiena> thanks JEEB
[18:23] <jangle> I guess my question now boils down to, when packing nals from h264 into an AVPacket structure, does avcodec_decode_video2 accept "chunked" decoding, where I should load one nal at a time into avpacket and then make the decode call?  Or does the AVPacket need to be filled with a full frame worth of nals before the decode, and if so, should they be packed with startcodes or just be sequential raw nal payloads?
[20:09] <kingsob> I am trying to invert a video, but getting an error "Error setting option pixel_aspect to value -1/1."  --> http://paste.ubuntu.com/7080930/
[20:36] <kingsob> it seems ffmpeg can't do anything with my video that has the SAR -1:1 DAR -71:40
[20:44] <Aiena> kingsob well I can;t help you there
[21:03] <kingsob> I was able to use h264_mp4toannexb to extract the bit stream, then encode back to h264
[21:03] <kingsob> but that doesn't seem ideal
[21:33] <Snaggle> I'm building ffmpeg-head, and although I don't explicitly enable the jack indev, -ljack is still added to EXTRALIBS.  According to the configure output, jack is not in the enabled indevs either.  This lazy linking to -ljack causes runtime failures if the jack library is removed (since it was not expected to be linked to).  Is this a bug in the configure jack check (that's when -ljack first seems to be added into the EXTRALIBS
[21:33] <Snaggle> stream) ?
[21:35] <klaxa> can you pastebin your config.log?
[21:38] <Snaggle> klaxa: http://pastebin.com/8Ccn4EUA
[21:39] <Snaggle> oops.  that's actually for ffmpeg-2.1.4, but same thing happens with git-head
[21:39] <klaxa> it's listed as an indev device
[21:39] <klaxa> can you explicitly disable it?
[21:43] <Snaggle> klaxa: yes, i can explicitly disable it via configure parameters.  But I would have thought that if the "check_func sem_timedwait" function failed (which is part of the "enabled jack_indev" test) failed, then -ljack wouldn't be added to EXTRAFLAGS.  But it seems that just passing the first check_lib2 test adds -ljack to EXTRAFLAGS.  config.h and config.mak both have the jack_indev as disabled.
[21:44] <klaxa> that's weird, i think jack isn't tested for functionality, but presence, so if it is present it is added to the build
[21:44] <klaxa> like every other library
[21:46] <Snaggle> right.  I think since the check is this: enabled jack_indev && check_lib2 jack/jack.h jack_client_open -ljack && check_func sem_timedwait, that passing check_lib2, -ljack is added, and then when check_func fails, the jack indev is disabled, but -ljack from the previous test function is not removed from EXTRAFLAGS.  I'm going to see if bracketing it fixes
[22:04] <DX099> hello, is there a way for ffmeg to be able to write metadata to aac files ?
[22:06] <jnvsor> ffmpeg -i file.aac xxx -c copy file.aac replace xxx with stuff from the docs: http://www.ffmpeg.org/ffmpeg-all.html#AC_002d3-Metadata
[22:07] <DX099> jnvsor, I'm actually converting from flac. More like "ffmpeg -i myfile.flac -c:a libfdk_aac -vbr 4 -map_metadata 0 output.aac"
[22:08] <DX099> but output.aac doesn't have any metadata even though ffmpeg displays them
[22:12] <jnvsor> does ffprobe display the metadata?
[22:13] <DX099> yes, there's no problem for original .flac file metadata, they're displayed correctly by ffprobe and at convert time by ffmpeg
[22:23] <DX099> http://trac.ffmpeg.org/wiki/AACEncodingGuide#Metadata , according to this , there should be no problem setting the metadata to .aac but it just doesn't work...
[00:00] --- Thu Mar 13 2014