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

[burek]

[01:11] <Catoptromancy> moo
[01:11] <Catoptromancy> im ripping CDs into a single track flac
[01:11] <Catoptromancy> been using cdparanioa to make .raws and then converting to flac with audacity
[01:12] <Catoptromancy> besides being a much easier way, I think I did something wrong
[01:12] <Catoptromancy> there seems like there should be an easier way
[01:12] <Catoptromancy> i ripped a CD with $cdparanoia -p 1-9
[01:13] <Catoptromancy> and the default settings to load it were mono, but it plays at half speed
[01:13] <Catoptromancy> and is listenable (not pure)
[01:13] <Catoptromancy> noise
[02:08] <Catoptromancy> maybe ill rip to .wav
[02:08] <Catoptromancy> and then convert to flac
[02:10] <yawnzi> When I scale an mkv video (720p) that has subtitles to 848x480, the subtitles of the output don't display properly (not scaled to the output's size; [parts of] upper and lower subs are cut off). command line used: ffmpeg -i in.mkv -s 848x480 -s:c copy out.mkv
[02:10] <yawnzi> Here is a screenshot of input and the resultant output http://i.imgur.com/DbH66.jpg
[02:10] <yawnzi> How do I get subs' display region(?) to scale with the video?
[03:45] <youlysses> In transcoding video, will ffmpeg try to export the resulting file into similar quality if no parameters are set? I have spring break coming up, and I want to start the converting all my videos to ogv on my always-on box... :-U
[04:29] <rcombs> so, I'm trying to use ffmpeg to extract frames from a video as PNGs, and they're coming out about 11MB for a 1080p video
[04:29] <rcombs> that kind of size seems rather insane for a single file
[04:29] <rcombs> for a _single frame_
[04:30] <rcombs> I'm doing -ss <time> -i "/path/to/file.mkv" -vframes 1 -y -vcodec png -f image2 -
[04:34] <beware> i am looking for ffmpeg 0.49pre1, can i get this from the git repository?
[04:38] <klaxa> i... doubt it
[04:39] <beware> is the svn repoistory still available?
[04:39] <klaxa> judging from the version number it's pre-git
[04:39] <beware> i read they wanted to take the svn repository down, but i'd keep it up just so one can get old versions from it
[04:44] <beware> oh, svn still runs. i can checkout from it
[04:54] <rcombs> just out of curiosity, why do you want a version that old?
[04:56] <rcombs> note: I still need help with those insane PNG sizes
[05:08] <relaxed> rcombs: why don't use you use a lossy image format?
[05:08] <rcombs> relaxed: I'm trying to get lossless image captures to show the quality of the original video
[05:09] <rcombs> relaxed: using a lossy format wouldn't demonstrate the original quality
[05:10] <relaxed> pngcrush might help
[05:11] <relaxed> but lossless is usually huge
[05:11] <rcombs> still, 11MB for a 1920x1080 file is insane
[05:12] <rcombs> that's bigger than it should be uncompressed
[05:12] <rcombs> and this is animation
[05:13] <klaxa> hmm... try pngcrush?
[05:13] <klaxa> oh wait was already mentioned
[05:14] <klaxa> also, depending on colorspace it might be bigger than your average raw bitmap
[05:15] <rcombs> 10bit RGB?
[05:15] <klaxa> hmm... you say it's animation, is it anime encoded with high 10 profile?
[05:15] <rcombs> yes
[05:16] <klaxa> can you paste the ffmpeg output?
[05:16] <rcombs> sure, sec
[05:16] <klaxa> it might say something about colorspace conversions
[05:18] <rcombs> https://gist.github.com/5105553
[05:19] <rcombs> rgb48be?
[05:19] <klaxa> rgb 48-bits big endian i guess :P
[05:19] Action: rcombs isn't particularly familiar with color profiles
[05:20] <klaxa> read that as: "so many bits my display can't even hold anymore"
[05:20] <klaxa> try running png-crush on it if that doesn't help, reduce bits
[05:21] <klaxa> to use 24 bits (8-bit per channel i guess) add -pix_fmt rgb24
[05:21] <klaxa> i don't know how it will downscale the 10-bit color depth to 8-bit color depth though
[05:22] <klaxa> will definitely lose some information, but since displays are 8-bit only anyway and png is lossless, it *should* look fine
[05:22] <klaxa> well... end-user displays
[05:22] <relaxed> rcombs: add -filter:v format=rgb24 and see how much smaller it is.
[05:22] <jbermudes> Does anyone know how to have FFMPEG use certain settings for the webcam such as brightness, gain, etc.? I've found out about v4l2-ctl, but that only seems to work once. Afterwards, it resets
[05:23] <klaxa> oh? is -pix_fmt to be deprecated?
[05:23] <klaxa> or is using -filter:v format just... better?
[05:23] <relaxed> jbermudes: script v4l2-ctl to be called right before grabbing with ffmpeg.
[05:24] <relaxed> klaxa: they are synonymous but the filter is more flexible.
[05:24] <klaxa> i see
[05:25] <jbermudes> relaxed: Ah, good idea. Thanks
[05:26] <rcombs> relaxed: trying
[05:26] <relaxed> of course, it's not lossless
[05:28] <rcombs> relaxed: still just as huge
[05:29] <klaxa> wut
[05:29] <klaxa> still 11 megs for 1080p png? in rgb24?
[05:29] <rcombs> yep
[05:29] <rcombs>     Stream #0:0(eng): Video: png, rgb24, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 90k tbn, 23.98 tbc
[05:30] <rcombs> 11,509,816
[05:30] <klaxa> mmhh... well run pngcrush with that
[05:31] <rcombs> video:2505kB audio:0kB subtitle:0 global headers:0kB muxing overhead -100.000858%
[05:31] <rcombs> I suppose I can chuck pngcrush in the pipeline
[05:31] <klaxa> well it's designed for what you want, so why not use it?
[05:32] <rcombs> it just seems like something ffmpeg should do natively
[05:32] <klaxa> heh, i remember i used sox for real-time audio processing for skype calls with my family
[05:32] <rcombs> that sounds like fun
[05:32] <klaxa> >your microphone has so much noise!
[05:32] <klaxa> apply noise-filter and noise-gate, problem solve
[05:32] <klaxa> *solged
[05:32] <klaxa> *solved
[05:33] <beware> i want to suggest that the SVN is kept running, so people can use it to get old versions of ffmpeg if they need it
[05:33] <rcombs> beware: what's your use-case for versions that old?
[05:34] <beware> stepmania 3.9. in general, data structures of the API of ffmpeg/libavcodec are volatile
[05:34] <beware> as in, constantly changing
[05:34] <klaxa> oh right, i remember your nick now
[05:34] <beware> so a program expects a certain version of ffmpeg
[05:34] <beware> oh?
[05:34] <relaxed> beware: Can you not checkout from git based on dates? Or was that info lost?
[05:35] <beware> git contains nothing that predates it
[05:35] <beware> (so about 2 years old)
[05:35] <klaxa> yeah you asked once why libxvid doesn't encode as well... bitrate-accuate as mpeg4
[05:35] <beware> i managed to get the version i need, from the svn
[05:35] <beware> yes. i asked things about that
[05:35] <klaxa> are stepmania-files for 3.9 not compatible with newer versions?
[05:35] <beware> i ended up encoding with mencoder's libxvid
[05:35] <beware> which produced the best results
[05:35] <klaxa> but... libxvid == libxvid
[05:36] <klaxa> it's not coded in ffmpeg nor mencoder :V
[05:36] <beware> someone who has ported/compiled SM 3.9 to linux before advised me to use ffmpeg 0.49pre1
[05:36] <klaxa> i see
[05:36] <beware> klaxa: in my experience, if i encoded with ffmpeg, i got a certain undesireable artefact, which i didn't get with mencoder. maybe due to xvid options
[05:36] <beware> im not sure if ffmpeg exposes all xvid options
[05:36] <rcombs> and no matter what's doing the encoding, xvid is worse than H.264
[05:36] <klaxa> mmh probably
[05:36] <klaxa> well, stepmania is a time-sensitive game
[05:37] <klaxa> fast decoding is important
[05:37] <beware> yes, but that (it being worse than h264) is outside of the scope of the problem, as in, it's not relevant
[05:37] <klaxa> and xvid is faster than h264
[05:37] <beware> exactly
[05:37] <beware> i used xvid for compatibility, decoding speed, and momentum (as in, it has always been done that way)
[05:37] <klaxa> although i like my stepmania videos to be HD :P
[05:37] <beware> i like them in the native max-extreme resolution (304x176)
[05:38] <beware> that project (these vids) has been finished and released
[05:38] <beware> i am now working on another, related, project
[05:38] <beware> (that uses these vids)
[05:38] <klaxa> i encoded nadeko sengoku's OP with placebo preset in x264 just to use it with stepmania
[05:39] <klaxa> however, i used my x264 10-bit build although i wanted to make it hardware compatible >_<
[05:39] <beware> i am against hi10 for that reason (compatibility)
[05:39] <beware> it also goes against my principle of making infrequent, big, leaps
[05:39] <beware> the last such leap that i acknowledge/care about is h264
[05:39] <beware> the next one will probably be h265
[05:40] <klaxa> well yeah i mean you can't really stop it in the anime "scene" so to speak
[05:40] <beware> the anime scene is bleeding edge for the sake of it
[05:40] <beware> they're idiots imo
[05:40] <beware> generally, "scene" = extremists
[05:40] <klaxa> not exaclty
[05:40] <klaxa> every other scene still uses the high profile, some even still release in xvid 175 mb fixed size
[05:41] <beware> "there is a CCCP beta that supports it now. thats good enough, we can start to require it"
[05:41] <beware> oh, xvid 175 mv
[05:41] <beware> mb*
[05:41] <klaxa> anyways, anime encoders are pretty stupid because they can't into encoding :V
[05:41] <rcombs> 10-bit = better gradients, lower filesize
[05:41] <klaxa> (I'm not claiming that i can)
[05:41] <klaxa> rcombs: i beg to differ
[05:41] <beware> http://www.bircd.org/annoyances/anime-ep-sizes/ <--- this, about 175 mb episodes
[05:41] <klaxa> better gradients, yes
[05:42] <beware> i simply don't care about the small quality increase that hi10 offers
[05:42] <beware> i find other things more important
[05:42] <klaxa> but the genius anime encoders think: "hey, let's just fuck with the filesize nobody cares about storage anymore anyways"
[05:42] <beware> i tend to put a great weight on logistics and compatibility
[05:43] <klaxa> well i like the quality increase and you can really tell that gradients look way better, but it's a two sided sword
[05:43] <beware> i think picture quality, in anime, is mostly pointless. like wine tasting.
[05:43] <rcombs> klaxa: eh, 10bit tends towards lower file sizes in H.264
[05:43] <klaxa> rcombs: the filesize *would* be smaller if they were encoding with the same quality, however since they increase the quality, filesize stays the same or increases even
[05:44] <rcombs> klaxa: depending on who's encoding
[05:44] <klaxa> exaclty
[05:44] <rcombs> personally, I prefer quality over filesize
[05:44] <klaxa> *exactly
[05:44] <klaxa> i occasionally enjoy bloatgirls
[05:45] <rcombs> I know a few people who pull off very high-quality anime at very low filesize
[05:45] <beware> anyway so 175 mb for an episode is the worst possible size to standardize on, because it's 1% bigger than what fits 26 episodes on a dvd
[05:45] <rcombs> klaxa: ooh, them
[05:45] <rcombs> klaxa: so much fun, both bigger files AND more blur!
[05:45] <klaxa> ikr?
[05:45] <rcombs> beware: oh, because optical storage is how the world works, right
[05:45] <klaxa> well exactly 4 fit on a DVD
[05:46] <klaxa> *CD
[05:46] <klaxa> grr
[05:46] <beware> rcombs: but making the episodes 175 mb (instead of, say 172 mb), gains nothing. it only loses something (the ability to put a season on a dvd)
[05:46] <beware> so there is no compromise here
[05:46] <beware> yes,
[05:46] <klaxa> that was the initial thought
[05:46] <beware> but if the ep is 172 mb, you can *still* also fit 4 on a cd
[05:46] <beware> *and* 26 on a dvd
[05:46] <rcombs> beware: that little bit of additional size bumps the quality a tiny bit
[05:46] <klaxa> meh
[05:46] <beware> it bumps it 1%. i don't care about that
[05:46] Action: rcombs ripped a few CDs today, actually
[05:46] <beware> if you standardize on "4 on a cd" or on any size whatsoever,
[05:46] <rcombs> my first time using an optical drive in& I think it's years now
[05:46] <beware> you're already choosing conformance to a size over quality
[05:46] <beware> so that argument goes out of the window
[05:47] <rcombs> file size is a crap way to standardize regardless
[05:47] <beware> i think 1% difference doesn't matter, and 172 mb is a better size than 175 mb
[05:47] <klaxa> the reason was to burn them on CDs and watch them on your TV
[05:47] <beware> but i do what i tend to do when i am unhappy about something: don't do it
[05:47] <beware> i don't watch anime anymore
[05:47] <klaxa> that's what they had in mind when they defined that scene standard
[05:48] <rcombs> beware: I don't think I've ever even owned a device that can play video off a CD, not counting computers of course
[05:48] <beware> (there's very little that i still do, because everything sucks in one way or another)
[06:07] <avinashrbhat> how can i remove a set of frames (say 00:00 - 00:05) using ffmpeg?
[06:08] <klaxa> use -ss and -t or -to to extract the parts you want
[06:09] <klaxa> for 00:00 to 00:05 (i'm guessing mm:ss) you would just do: ffmpeg -i input -ss 5 -c copy output
[06:10] <klaxa> however, depending on the used video-codec you might have to re-encode to produce a proper file
[06:11] <klaxa> avinashrbhat: ^
[10:32] <raket> how to create vcd with ffmpeg?
[10:32] <raket> ffmpeg -i a.avi -f vcd out.mpg?
[10:33] <raket> -target vcd
[10:33] <raket> thank you.
[11:05] <Auree> Hi, I have a problem http://pastebin.com/ey1Qvsgv
[11:05] <Auree> I would really appreciate some help
[11:27] <Mavrik-> Auree, first of all, you're using libav, not ffmpeg
[11:27] <Mavrik-> Auree, second of all, mpeg2video is a video codec, not a format :)
[11:27] <Mavrik-> Auree, and as you can see by "E", only "encode" of raw mpeg2video is supported
[11:37] <relaxed> Auree: omit -f mpeg2video
[12:00] <Auree> relaxed: Mavrik: thank you, I've installed an older version, it works now
[12:01] <Auree> the thing is, this command is hardcoded in a legacy project, I would prefer not to change the code, but to make the command work on my machine instead
[12:11] <raket> what the heck, thanks for great ffmpeg and happy 201337! http://www.youtube.com/watch?v=_wt7xdEfNdM .. :)
[13:18] <gryffus> hello, i have problem with ffmpeg x11grab... I want to make video of my PC while being under heavy load... The problem is that the video is "fast" when playing. I guess it is because many frames get dropped because of the load... Is here any preset/solution to record desktop which is under heavy load without affecting FPS/speed of the recorded video?
[13:51] <Mavrik-> gryffus, huh, not really
[13:51] <Mavrik-> gryffus, are you actually encoding video? or just grabbing raw frames?
[13:52] <gryffus> Mavrik-: just grabbing
[13:53] <gryffus> Mavrik-: but speed of resulting video is very fast
[13:54] <gryffus> ffmpeg -f x11grab -r 25 -s 1366x768 -i :0.0 /tmp/out.mpg is what i use
[13:56] <Mavrik-> um
[13:56] <Mavrik-> that actually does use compression
[13:56] <Mavrik-> and pretty terrible at that probably
[14:23] <gryffus> Mavrik-: so what options should i use to be less resource expensive?
[14:28] <Mavrik-> gryffus, output raw video or huffyuv video
[14:28] <Mavrik-> and then reencode later
[14:42] <gryffus> Mavrik-: could you please show me on the command i posted?
[14:43] <Mavrik-> I kinda don't have time to do a parameter lookup for you, can you just google it please?
[14:43] <gryffus> ok, sry
[16:09] <Yulth> Hi everyone!
[16:10] <Mavrik-> heya :)
[16:10] <Yulth> How Can I copy all metadata from one file to another except the Album or Cover Art?
[16:11] <Yulth> the option -map_metadata 0:s:0 copy all metadata including Album Art
[16:11] <relaxed> Yulth: -vn should exclude it
[16:11] <relaxed> since it's treated as a video stream
[16:13] <relaxed> or -map 0:a
[16:13] <Yulth> relaxed: but I'm looking for an audio stream. it's valid anyway?
[16:13] <Yulth> mmm, I'm going to try it
[16:14] <relaxed> what do you mean "looking"?
[16:16] <Yulth> sorry, I meant, I'm trying to transcode from one format to another and I've realized that some audio files have really heavy album arts (2-3 Mbytes O_O ) and I need to preserve all metadata except Album Art :)
[16:34] <Crackeraki> Hello ppl, is there any good full guide of install ffmpeg on windows or linux? I followed few, but they do not do complete install, examples after them dont working in my case.
[17:54] <tmatth> hey i'm getting very jittery playback with the following ffplay v4l2 command:
[17:54] <tmatth> http://pastebin.com/GLWUKhuA
[18:25] <epifanio> hi all
[18:26] <epifanio> i'm generating a video starting form a series of png, i'm using the sane command on a linux machine and on mac osx
[18:26] <epifanio> but for some reason the video produced  with osx, doesn't display in my browser
[18:26] <epifanio> while the video produced by linux works fine
[18:27] <epifanio> is there any itility i can run on the video output to see if a codec is missed, or to check general info that can help to understand what's the difference between the 2 video oputput ?
[18:29] <epifanio> on osx i installed ffmpeg using homebrew --HEAD (so it is the git version)
[18:30] <Mavrik> epifanio, ffmpeg's ffprobe :)
[18:30] <epifanio> Mavrik: thanks i'll run it on both videos
[18:30] <relaxed> epifanio: most likely you need -pix_fmt yuv420p
[18:31] <epifanio> in the  ffmpeg instruction ?
[18:31] <Mavrik> just run the ffprobe
[18:31] <Mavrik> if there's a difference in pixel formats you'll see it in the output
[18:31] <Mavrik> let's not do silly guesswork :P
[18:39] <relaxed> I prefer educated guess.
[18:39] <epifanio> Mavrik:   i got this http://paste.debian.net/240338/
[18:40] <relaxed> and I was right
[18:40] <epifanio> i'm using the same png's on both machine, then i run the same instruction to generate the video
[18:41] <relaxed> The OS X version tries to use the same pixel format, which causes the problem.
[18:42] <relaxed> your browser expects the format to be yuv420p
[18:43] <epifanio> relaxed:  great! i added the option :  "-pix_fmt yuv420p"  to the ffmpeg instruction and now the results from osx is loaded correctly in my browser (this case crhome)
[18:43] <epifanio> the same video doesn't load on safari/firefox i guess for missing codec
[18:44] <epifanio> but that's a browser issue :)
[18:44] <relaxed> you can add it to both commands to be sure if there are changes it will output the same pixel format.
[18:50] <epifanio> yep :) i added it to my code, cool!
[19:01] <epifanio> Mavrik: relaxed :  thanks for the help!
[20:17] <octe> this might be more of a codec/formats question but, i'm using ffmpeg to transcode a video to a pipe, i would like to use mp4 but my understanding is that it's impossible with a non-seekable output
[20:17] <octe> i'm showing the result on a web page with the html5 video tag, and it seems you have to use mp4 if you're using h264?
[20:17] <octe> what would my options be, transcode to a file and serve that file?
[20:18] <octe> is it even possible to serve an mp4-file generated on the fly?
[20:19] <JEEBsv> with the fragments feature, yes
[20:19] <JEEBsv> otherwise there is just one index, which has to be created after the file has been fully created otherwise
[20:21] <octe> cool, that seems to work with some options
[20:21] <octe> -movflags frag_keyframe+empty_moov
[20:22] <JEEBsv> naturally it depends on how intelligent the demuxer on the player's side is, but yeah -- at least it would let you "stream" "mp4"-like containers
[20:24] <octe> i'm a bit confused, people talking about what formats are supported say h264 for example
[20:24] <octe> but you would still need a container like mp4, mkv or whatever, right>?
[20:24] <octe> people seem to equate h264 and mp4
[20:24] <JEEBsv> because that's the container most "HTML5 video" things have implemented
[20:25] <JEEBsv> for H.264/AAC
[20:25] <JEEBsv> (video/audio)
[20:25] <octe> webm support seems alright too
[20:25] <JEEBsv> that's a limited subset of matroska
[20:26] <JEEBsv> vp8 + vorbis + limited subset of matroska = "webm"
[20:26] <JEEBsv> but try putting H.264/AAC into matroska and have that read by a browser :P
[20:27] <octe> matroska is mkv?
[20:27] <JEEBsv> yes
[20:27] <JEEBsv> anyways, those things generally have really limited things that they support
[20:27] <JEEBsv> so it's basically "certain audio and video format in certain container" kind of thing
[20:28] <JEEBsv> you don't really have the right to select
[20:28] <octe> yeah
[20:28] <octe> i'm just trying to generate a video in the correct formats for most devices to support
[20:29] <octe> mainly out of curiousity
[20:29] <JEEBsv> also, anyone who really thought that VP8 was patent-free can now go and get their hat and eat it :)
[20:29] <JEEBsv> http://www.businesswire.com/news/home/20130307006192/en/Google-MPEG-LA-Announce-Agreement-Covering-VP8
[20:29] <teratorn> you need to support h264 and vp8, then
[20:29] <teratorn> if you want to support all devices out of the box
[20:29] <octe> h264+aac+mp4 and vp8+vorbis+webm then?
[20:30] <teratorn> so h264/aac/mp4 and vp8/vorbis/mkv (aka "webm")
[20:30] <teratorn> ;)
[20:30] <JEEBsv> yup
[20:30] <octe> hehe
[20:30] <octe> i'm annoyed, i have a phone8 i'm testing on and it doesn't even request the video stream
[20:30] <octe> i thought they were supposed to have at least h264 support
[20:33] <alx-> i'm trying to generate a video from still images. this works, but when i upload it to youtube, the timing is either way off, or the video can't be converted.
[20:33] <alx-> this is the command i'm using cat #{photo_urls} | ffmpeg -f image2pipe -r 1/5 -vcodec mjpeg -i - -vcodec libx264 #{temp_path}/#{id}.avi
[20:36] <teratorn> JEEBsv: isn't that the problem, though? nobody freaking KNOWS if something that complex is patent encumbered, not really, not until it is tested in court - and then the court may go against your best technical assessment.
[20:37] <JEEBsv> you can by now pretty much with basic thought get to the point where you can be sure that by creating anything you are effectively breaking some US patent
[20:37] <JEEBsv> most probably
[20:37] <teratorn> JEEBsv: ahahaha. probably, yes.
[20:37] <JEEBsv> I'm just enjoying the fact that the people who really thought there could be something patent-free will FFFUUU at this
[20:37] <LithosLaptop> alx-: Youtube is a bit picky, yesterday I stuggled to get a way to upload a FLAC in different containers, I had to resort to an AVI containing LPCM with one still image at 23.98fps
[20:37] <JEEBsv> it was esp. obvious because VP8 was such a similar format to H.264/AVC anyways
[20:38] <gmaxwell> JEEBsv: You're confused, sadly.
[20:38] <gmaxwell> Right now people were blocking the inclusion of VP8 in WebRTC due to patent fud by H264 licensors. What google is doing is substantially putting that specific fud to bed, nothing more.
[20:39] <teratorn> gmaxwell: yeah, it sounded like a pre-emptive strike to head that crap off at the pass, to me
[20:39] <gmaxwell> And 'patent free' ... uh. Google holds patents on VP8  did before it was ever released, in fact. But the patents are available under RF licenses.
[20:39] <JEEBsv> yes, I'm just mostly noting how ridiculous some people were by thinking that something like VP8 was 'patent free'
[20:40] <JEEBsv> nothing less, nothing more
[20:40] <JEEBsv> the licensing for VP8 will most probably be free
[20:40] <JEEBsv> otherwise it wouldn't make much sense
[20:40] <iive> only things that are 20-25 years old are patent free.
[20:40] <gmaxwell> JEEBsv: what people were those? They were stupid to begin with as noted, google held patents on VP8 prior to it being released.
[20:40] <teratorn> but I already want VP9 :-(
[20:40] <JEEBsv> gmaxwell: yes they were
[20:41] <teratorn> gmaxwell: well, that doesn't necessarily mean that google had ALL the relevant patents
[20:41] <JEEBsv> also if you look at my text I never said "bwahaha now people will have to pay!" etc.
[20:41] <gmaxwell> JEEBsv: and any rights sublicensable by google which are needed for VP8 are already RF, so no 'likely' needed. (see the existing VP8 patent licenses)
[20:41] <gmaxwell> teratorn: sure sure, but just saying that I don't think anyone was saying VP8 was free of patents, becuase it very explicitly wasn't.
[20:42] <JEEBsv> Oh you'd be surprised
[20:42] <JEEBsv> how many people started using VP8 on the basis that it was 'patent free'
[20:42] <JEEBsv> (mostly FOSS-related people)
[20:42] <teratorn> don't listen to "people" when it comes to video codec patents, I guess
[20:42] <gmaxwell> JEEBsv: No, they used it because it is free of _royalty bearing_ patents.
[20:43] <teratorn> so, webrtc is codec/format agnostic, then?
[20:43] <teratorn> or are they specifying certain ones?
[20:43] <JEEBsv> gmaxwell: in any case I was just noting on the ridiculousness of someone saying that something is 'patent free', that's all
[20:43] <gmaxwell> teratorn: There is a set of mandatory to implement codecs so that it'll actually interoperate. E.g. Opus is required for audio. You can support other things and use them instead, but at a minimum all implementations must support opus.
[20:44] <teratorn> ok, that is cool
[20:44] <JEEBsv> if one only cares about the royalties, then it all doesn't really change from how it was before :)
[20:44] <gmaxwell> teratorn: It was proposed that VP8 be made MTI for video in it... but the decision is really close to tied on that.
[20:44] <JEEBsv> it'd be really surprising if Google would take money now for the relicensing :)
[20:45] <gmaxwell> JEEBsv: the existing VP8 license already covers any sublicensable rights recieved by google. So not just 'surprising' but a violation of their prior contracts.
[20:45] <teratorn> gmaxwell: with chrome and firefox being the prime implementors, hopefully VP8 will reach de-facto interop status, even if the standards idiots can't agree
[20:45] <JEEBsv> :)
[20:45] <teratorn> and opera
[20:45] <Mavrik> right
[20:45] <JEEBsv> well, VP8 came to the party quite late
[20:45] <gmaxwell> teratorn: perhaps, but defacto interop is still.... eehhhhh.. Esp because IE and Safari exist... plus lots and lots of things like video phones, implementations on mobile devices, etc.
[20:46] <JEEBsv> at least with VP9 Google is somewhat on time
[20:46] <teratorn> gmaxwell: implementations that don't exist yet, though ;-)
[20:46] <JEEBsv> with HEVC being about finished
[20:46] <JEEBsv> and mobile devices need ASICs, software decoding isn't really an option :)
[20:46] <gmaxwell> teratorn: well, ericson and cisco have implementations.
[20:46] <gmaxwell> teratorn: as does MSFT but I don't think they've even demoed it.
[20:46] <teratorn> huh
[20:47] <teratorn> can't anyone agree that webrtc needs at least one decent RF video codec as a minimum requirement?
[20:47] <teratorn> seems like a no-brainer
[20:47] <gmaxwell> teratorn: most people agree. But there is enough fud about VP8 to jam the process. Hopefully this announcement fixes that.
[20:48] <JEEBsv> well, at least with that announcement it is clear that quite a few VP8-related patents from other companies are also licensed
[20:48] <JEEBsv> so it's not only Google now
[20:49] <gmaxwell> JEEBsv: If you'll note, I used the words "sublicensable rights recieved by google"
[20:49] <JEEBsv> :)
[20:50] <JEEBsv> personally I don't really care that much about VP8, but I'll have to see how VP9 goes
[20:50] <JEEBsv> they seem to be going further than HEVC with the "needed computational power" side of things
[21:19] <alx-> llogan: https://gist.github.com/anonymous/5111465
[21:24] <llogan> alx-: i recall YouTube having trouble with 1 fps. Try adding "-r 2" as an output option.
[21:25] <llogan> and you shouldn't need cat with numerically sequential inputs, and/or if your build supports "-pattern_type glob"
[21:25] <alx-> llogan: still doesn't work. however, if i add a 5th image, it works!
[21:26] <llogan> weird. i'll blame YT.
[21:26] <alx-> are there any alternatives to ffmpeg?
[21:27] <llogan> blasphemy!
[21:27] <alx-> lol
[22:20] <thcipriani> Is there a sensible set of defaults for configuring ffmpeg for use on a web server backend? I'm trying to standardize and I'm sure this is a problem that's been solved before&
[22:22] <Mavrik> thcipriani, depends on what do you want to do
[22:22] <Mavrik> and what do you mean by "defaults" :)
[22:24] <thcipriani> What I want to do is to ensure is that conversion from mov,ogv,wmv,3gp,avi,m4v,mpg,mpeg, and flv to mp4 is possible
[22:28] <Mavrik> thcipriani, well, you'll have to set at least: 1.) video quality 2.) encoding preset 3.) encoding profile 4.) video pixel format 5.) audio sample rate 6.) audio channels 7.) audio quality
[22:28] <Mavrik> and resolution if you'll do scaling
[22:28] <Mavrik> also, deinterlace filter for interlaced input :)
[22:28] <thcipriani>  oh, sorry, I should've been clearerI meant configuration as in compiling ffmpeg from source
[22:29] <thcipriani> like which flags to pass to ./configure --etc
[22:29] <Mavrik> um
[22:30] <Mavrik> since you didn't say what kind of output you're generating... it's nothing much I can say
[22:30] <Mavrik> compile everything + additional encoder libs you need
[22:31] <thcipriani> only mp4 output
[22:31] <thcipriani> from mov,ogv,wmv,3gp,avi,m4v,mpg,mpeg, and flv to mp4
[22:32] <thcipriani> h.264video + aacaudio in an mp4 container
[22:46] <llogan> also 8.) setting scheduling priority if desired
[22:47] <llogan> --enable-gpl --enable-libx264 for video. audi depends on the AAC encoder you want to use
[22:47] <llogan> probably fdk-aac, so --enable-nonfree --enable-libfdk-aac
[22:48] <llogan> thcipriani: also see https://ffmpeg.org/trac/ffmpeg/wiki/x264EncodingGuide
[22:48] <llogan> and https://ffmpeg.org/trac/ffmpeg/wiki/AACEncodingGuide
[22:49] <thcipriani> cool, thanks, that gives me a place to start testing
[22:50] <llogan> and add "-movflags faststart" to your encoding command so your video can begin playback before it is completely downloaded
[22:51] <llogan> of course you will need to install x264 and fdk-aac first.
[23:25] <Pinhole> The result of http://fpaste.org/TJe3/ plays nicely on mplayer, but on a settop box it seems to pulse and finish in half the time.  Any thoughts?
[23:27] <Pinhole> I am trying to make a single image with some tones in a wav file into an mpeg4 ts stream.
[23:36] <llogan> Pinhole: are you sure the device can handle "profile High, level 2.2"?
[23:37] <llogan> also, libx264 should ignore -q:v, and if it doesn't you should use -crf instead
[23:37] <llogan> -loop_input is deprecated, use -loop 1
[23:37] <Pinhole> I don't really know anything.  I'll look at crf.
[23:37] <JEEB> -q:v probably sets constant QP
[23:38] <JEEB> which is something you shouldn't use with x264
[23:38] <JEEB> (because crf is a better mode for "constant quality")
[23:38] <JEEB> most other encoders just don't have a similar mode
[23:39] <JEEB> so constant QP is the "best" thing to use with those
[23:39] <JEEB> (if you don't want to use bit rate based encoding)
[23:39] <llogan> i just checked and recent does ignore q:v
[23:39] <JEEB> interesting
[23:40] <JEEB> so rc doesn't get set to qp
[23:40] <JEEB> ?
[23:40] <llogan> -crf 23 default
[23:40] <JEEB> rc=qp or something along those lines in the libx264's settings line
[23:40] <JEEB> yes, I know the default is crf 23
[23:41] <JEEB> and yeah, just checked here
[23:41] <JEEB> rc=crf and crf=23.0 with -q:v 15
[23:41] <JEEB> nice, ffmpeg doesn't let you use QP mode too easily with libx264 :)
[23:47] <Pinhole> I don't think the video settings are the problem, as the image shows.  It's the audio that seems to be wrong.
[23:49] <llogan> hard to make a guess without knowing anything about the device
[00:00] --- Fri Mar  8 2013