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

[burek]

[00:23] <pinPoint> I have question, can ffmpeg be used to address issues with videos?
[00:23] <pinPoint> corruption from let's say drive collapsing, etc?
[00:23] <pinPoint> I have the file but it is a R3D file... :/
[00:37] <telly> im trying to compile ffmpeg for raspberry pi, but he says libx264 not found though there is libx264.a in the path i supply with -extra-ldflags
[00:37] <telly> what can i try to fix this?
[00:39] <Keshl> I don't know, but if you get it to work, can'ya tell me how the performence is? XD
[00:41] <telly> ;D
[00:41] <telly> well i mean he can take the whole day, hes got the time? :P
[00:42] <pinPoint> heh
[00:42] <pinPoint> is anyone aware of MP4Repair.org?
[00:43] <Keshl> pinPoint: Both sites are unreated by WOT.
[00:43] <Keshl> Chances are both the .com and .org site are malware distributors.
[00:43] <pinPoint> unreated by WOT?
[00:43] <Keshl> WOT, web of trust. It's a group that has user-made reveiws for basically every /known/ website.
[00:44] <Keshl> And both the .com and .org sites are totally unrated.
[00:44] <pinPoint> are you serious?
[00:44] <Keshl> Yeah.
[00:44] <Keshl> Generally it works.
[00:44] <Keshl> http://www.mywot.com/en/scorecard/mp4repair.org?utm_source=addon&utm_content=rw-viewsc
[00:44] <Keshl> http://www.mywot.com/en/scorecard/mp4repair.com?utm_source=addon&utm_content=rw-viewsc
[00:44] <Keshl> Just search in the upper right corner, or go hug the addon for Chrome or Firefox.
[00:45] <pinPoint> unrated is true
[00:45] <pinPoint> but the point of the site is to repair damaged video files
[00:45] <Keshl> And after some quick checks of my own...
[00:45] <pinPoint> and they talk about ffmpeg
[00:45] <Keshl> Yeah, this is just... Don't download stuff from them, you /will/ catch something.
[00:45] <pinPoint> there is nothing to download
[00:45] <Keshl> Exactly.
[00:46] <pinPoint> http://mp4repair.org/blog/
[00:46] <pinPoint> look at their blog
[00:46] <pinPoint> its a legitimate site
[00:46] <Keshl> Link's there, it changes the page, nothing comes up. I'm sensing, failed exploit.
[00:46] <pinPoint> how is that even possible?
[00:46] <Keshl> Ah, I get what they're doiung.
[00:46] <Keshl> They're not really repairing it, they're generating it.
[00:47] <Keshl> Basically they're using motion estimation to track where pixels /might/ go, and then fill in the holes like JPEG decompression does.
[00:47] <Keshl> It works for video, somewhat, but won't be an exact match, and the longer the gap the less accurate it'll be.
[00:47] <Keshl> Audio's highly questionable.
[00:47] <Keshl> Frankly you can do this for free.
[00:48] <pinPoint> well I was wondering if anyone was aware of what they use to address issues with videos?
[00:48] <Keshl> Either grab software that's designed for motion estimation (There's a lot around, but good luck getting it to run. It's /really/ picky stuff), or tweak ffmpeg's X264 compression algorithm a bit.
[00:48] <pinPoint> because the site was able to preview R3D screenshots from a damaged .R3D file
[00:48] <Keshl> I mean, all you really need is it to do motion estimation for every pixel at once no matter what.
[00:48] <pinPoint> how are they pulling it off and could I do the same here at home?
[00:48] <Keshl> pinPoint: Read my posts.
[00:49] <pinPoint> i did
[00:49] <Keshl> Normally X264 only estimates some pixels depending on the settings you (or ffmpeg) passes to it.
[00:49] <pinPoint>  compression alogrithm huh?
[00:49] <pinPoint> it's not an x264 file
[00:49] <Keshl> All you gotta do is make it do it to /every/ pixel, no matter the cirumstances, and it'll "repair" the file.
[00:49] <Keshl> Doesn't need to be.
[00:49] <pinPoint> it's redcode raw codec
[00:50] <Keshl> It can be any input, you just need to run it through X264.
[00:50] <Keshl> With some tweaks.
[00:50] <Keshl> Dunno how to do those, I just know that's what you (and they) need (and do) do.
[00:50] <pinPoint> yeah, i'm sorta new to this
[00:50] <Keshl> pinPoint: Might wanna spoend a month or so reading up on the terms and current trends then.
[00:50] <Keshl> *spend
[00:50] <Keshl> Video (en/trans/re/etc)coding is a /lot/ more in-depth than you think.
[00:50] <pinPoint> so they are doing about the same thing?
[00:51] <Keshl> The exact same thing.
[00:51] <Keshl> In fact, they probably use ffmpeg and X264 to do it.
[00:51] <pinPoint> i gave them a damaged file and the generated a preview...
[00:51] <pinPoint> I myself use a hex editor to get about 20 frames fixed out of 21 seconds of lost footage
[00:51] <Keshl> And the fact their site is so poorly designed makes me think the patch's dead simple, or that there might be some obscure set of paramaters that can do it.
[00:51] <pinPoint> my way was way toooo painful
[00:52] <pinPoint> Keshl: they said this "REDCODE .r3d files can be parsed by identifying blocks of data with the atom structure:
[00:52] <pinPoint> 32-bits length + token + payload
[00:52] <pinPoint> "
[00:53] <pinPoint> http://pastebin.com/mqiLwdEF
[00:53] <Keshl> I'm assuming by "broken" you mean "the file has been corrupted in such a way that entire frames need to be discarded"
[00:53] <pinPoint> probably
[00:53] <pinPoint> it was a challenge from a forum on the internet
[00:53] <Keshl> Then the way I wrote above will work.
[00:54] <pinPoint> well
[00:54] Action: pinPoint is confused
[00:54] <Keshl> Like I said. Read stuff for a month. <É<
[00:55] <Keshl> This is a very in-depth and complicated topic. A lot of people don't think it's that hard, but really, there's a LOT to this stuff.
[00:55] <Keshl> Just go to Wikipedia, /read/ (don't skim!) the /entire/ article, and keep clicking "see also" links. For a month. Seriously.
[00:55] <Keshl> And basically any other links if they use terms you don't fully understand.
[00:56] <Keshl> (And as of now, assume that's all of them. A lot of people, and I mean a lot, take this stuff for granted and think "oh 720p is always better than 1080p" or "oh 480p is worse than 1080i" when in reality it's the opposite.)
[00:57] <Keshl> (And "a bigger file means more quality" is another mis-conception.. "it's better to scale video up before playing it rather than in real-time" is another.. "higher compression means slower framerates" is a biggie..)
[00:57] <Keshl> (None of those things are true, by the way. A lot of people think they are, but the exact opposite is.)
[00:59] <pinPoint> what if the files i'm dealing with are 4096x2160?
[00:59] <pinPoint> same routine?
[00:59] <Keshl> No matter the input, same routene.
[01:00] <Keshl> Frames are frames are frames are frames, oÉo.
[01:01] <pinPoint> not to sound like broken record, in wikipedia, where or what do I start searching/reading about?
[01:01] <Keshl> http://en.wikipedia.org/wiki/FFmpeg oÉo, and literally, if there is /any/ word in blue that you don't fully understand, ctrl click it and read that tab right away.
[01:01] <Keshl> Do a depth-first search of what you don't know.
[01:02] <Keshl> Do not skip things, if you're "iffy" on something, read the entire page.
[01:02] <Keshl> There is no fast way to do this. oÉo.
[01:02] <pinPoint> that will lead me to understanding a repair process down the road say 3months?
[01:02] <Keshl> It might. It depends on how fast you read, how much you absorb and how much fluid intelligence you have. oÉo.
[01:03] <pinPoint> i'm savvy with the computers
[01:03] <pinPoint> i build my own I mean
[01:03] <Keshl> That means nothing. XD
[01:03] <pinPoint> trolol
[01:03] <Keshl> Hardware != software, not by a mile.
[01:03] <pinPoint> I did c++ 2yrs in HS, plus ~2 semesters in college.
[01:03] <pinPoint> its been a while however
[01:07] <pinPoint> Keshl: thanks
[01:10] <Keshl> Welcomes, oÉo
[01:10] <Keshl> And good luck -É-
[01:11] <pinPoint> yeah, no kidding. :)
[01:11] Action: pinPoint dead man walking.
[02:09] <zN0z> hi, I would like to know if it is possible to create variables in a command line to store values of one file to be used to format another
[02:21] <nfkd> Hello, #ffmpeg
[02:21] <nfkd> We are working in a Skype replacement over #InsertProjectNameHere
[02:21] <nfkd> And considering using ffmpeg
[02:21] <nfkd> http://tox.im/
[02:22] <nfkd> I guess you guys would be interested
[02:22] <klaxa> looks promising
[02:23] <nfkd> Hopefully
[02:23] <klaxa> oh it's p2p?
[02:23] <nfkd> Yes, DHT
[02:23] <nfkd> Decentralized, for better security
[02:23] <nfkd> No central server
[02:23] <klaxa> i like that idea
[03:20] <sacredchao> I am using Kdenlive to edit videos (using ffmpeg for the actual A/V encoding) and I am trying to make a profile with 384k CBR AAC LC audio + x264 1080p video at 12Mb/s
[03:22] <sacredchao> The command line switches I am using however seem to produce a file that VLC and mplayer cannot determine the bitrate of EITHER the audio or video stream via normal methods
[03:22] <sacredchao> hq=1 acodec=aac ab=384k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=12000k vb=12000k g=250 bf=3 b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar pass=%passes
[03:23] <sacredchao> Obviously I am doing something wrong.  The destination is YouTube.
[03:23] <Aprel> Any luck with ffprobe?
[03:24] <sacredchao>    Stream #0.0: Video: h264 (High), yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 30 fps, 30 tbr, 1k tbn, 60 tbc (default)
[03:24] <sacredchao>     Stream #0.1: Audio: aac, 48000 Hz, stereo, s16 (default)
[03:24] <Aprel> I find (maybe moreso with VBR files) vlc and totem can't figure the bitrate, but play it fine otherwise.
[03:24] <sacredchao> mediainfo cannot determine bitrate either
[03:25] <Aprel> Does the file play fine otherwise?
[03:25] <sacredchao> Yes.
[03:25] <sacredchao> The problem is that I changed the video bitrate and the filesize was exactly the same as the previous render
[03:26] <sacredchao> So I don't know if there is some limit configured elsewhere, but I need to make a render that is under 500MB for Vimeo and it keeps being 547MB
[03:28] <Aprel> As a last resort, you could use kdenlive to output the file in some format close to raw video/audio, and then use ffmpeg to do the encoding on that file. It's possible kdenlive is mucking it up. I've have many problems with that software :/
[03:37] <sacredchao> Also, I read that there are better AAC encoding libraries to use besides the one built into ffmpeg
[03:37] <sacredchao> Is this true, and does ffmpeg need to be specifically compiled to make use of them?
[03:41] <Aprel> I don't know about that. I use ffmpeg for aac encoding and it's fine for me. I haven't heard of the encoding being particularly poorer to any other open source library codec
[03:41] <relaxed> sacredchao: yes, compile ffmpeg with libfdk-aac support
[03:43] <relaxed> if you need a specific size use two pass encoding
[03:44] <relaxed> you can learn how to do both by following the ffmpeg compile guide and the x264 encoding guide, both found in the wiki.
[03:53] <sacredchao> relaxed: OKay thanks, I will stick with simply using 'aac' for now and concentrate on 2-pass encoding
[03:54] <sacredchao> On the wiki it simply reminds you of the bitrate = file size / duration formula before getting into 2-pass CLI switches
[03:54] <sacredchao> I have a 394 second video I want at 500MB wth 384k audio
[03:54] <sacredchao> So I am changing vb=10000k
[03:55] <sacredchao> I wonder why this formula doesn't work just as well for 1-pass encoding.  The wiki doesn't explain this.
[04:09] <relaxed> the second pass is used to avaerage out the bits to achieve your size.
[04:10] <relaxed> average*
[05:04] <johnnny22> hey
[05:04] <johnnny22> woah ffmpeg 2.0
[05:06] <johnnny22> I was wondering what's the best way to get ffmpeg to encode from a pipe into a file that only keeps the last X seconds of video
[05:07] <johnnny22> and / or what keywords I could use to search for that technique
[05:26] <johnnny22> i guess the best approach is to have a sort of buffer
[09:06] <YeahBuddy> Hi everybody.  Just built ffmpeg on a Raspberry Pi.  Seems to have worked, but I have no idea where it was installed.  So my question is A. Where is it?  B. What's the easiest way to determine this from makefiles?
[09:07] <YeahBuddy> BTW, this is a Debian derivative.
[09:14] <YeahBuddy> This is a talkative bunch.
[09:18] <dv-> use the which command
[09:18] <dv-> which ffmpeg
[09:19] <YeahBuddy> this returns nothing
[09:22] <YeahBuddy> It could be that I'm an ass and forgot to run make install
[09:22] <YeahBuddy> In fact, it's looking a lot like that
[09:22] <YeahBuddy> I blame the bourbon
[09:23] <YeahBuddy> Oh look, there it is right where one might expect: /usr/local/bin
[09:23] <YeahBuddy> Well thanks for your help.
[09:23] <YeahBuddy> I'm going to celebrate with chocolate chips.
[10:24] <ThePuppetMaster> hi @all
[10:26] <ThePuppetMaster> i have a shot question .. i try to create a atrle movie from png files. i need the alpha chan of the png inside the new movie. but if i encode it, ffmpeg shows me on the INPUT test: Stream #0:0: Video: png, rgb24, .... but, rgb24 is not argb ... what i need to do that ffmpeg read the png as argb?
[10:27] <ThePuppetMaster> thats the output of ffmpeg: http://pastebin.com/D1aAYV0h
[12:26] <anddam> slightly OT: is it actually possible to cut an MP3 file without recoding?
[12:29] <JEEB> yes
[12:30] <JEEB> compressed audio streams generally consist of independently decode'able chunks, so if you cut at those you get lossless cutting
[12:30] <JEEB> the size of the chunks depends on the format/encoder/settings, but lossy encoders generally don't have too long ones, while f.ex. FLAC can have rather long ones
[12:31] <anddam> is the chunks' length fixed in MP3 case?
[12:31] <anddam> I see, thanks
[12:31] <JEEB> I would say no :P
[12:31] <anddam> so it can be done but at whole chunks granularity
[12:31] <anddam> pretty much like minecraft
[12:32] <JEEB> just like cutting video at random access points :)
[12:33] <JEEB> (of course with video there are other things to consider as well, such as how the extradata is set and so forth)
[12:33] <JEEB> anyways, ffmpeg with -ss and -t before -i (if it fails then move -t to after -i I guess?) and -c copy should work? :)
[12:34] <JEEB> of course when the stream is in a container it's simpler to cut, dot-mp3 is generally a raw MPEG-1 Layer 3 audio stream, and those don't exactly make seeking simple :)
[12:36] <anddam> :ls
[12:51] <anddam> ok, that was the wrong vim buffer
[12:52] <anddam> JEEB: thanks, bye
[12:52] <Fjorgynn> :D
[18:19] <Fjorgynn> 1,5 GHz Snapdragon S4 Pro
[22:38] <exutux> hi
[23:00] <exutux> guys I'll try to grab desktop video in a selected area but http://paste.ubuntu.com/5908953/ whats wrong in the command?
[23:02] <exutux> is it possible to grab desktop in a selected region?
[23:03] <klaxa> yes, what is your display resolution?
[23:03] <klaxa> because my first guess is, the area you want to record is out of your display bounds
[23:03] <exutux> current 1366 x 768
[23:04] <klaxa> okay so
[23:04] <klaxa> >1024x768 -i :0.0+100,200
[23:04] <klaxa> that will be out of bounds
[23:04] <klaxa> because you will be recording the rectangle: (100,200), (1124, 968)
[23:04] <exutux> uhm how can I find right bound?
[23:05] <klaxa> you can't record outside of your display
[23:05] <klaxa> so your resolution kinda defines your bound
[23:07] <llogan> exutux: you can use xwininfo if you want the coordinates for a certain window
[23:08] <llogan> http://pastebin.com/xuYUmnGU
[23:09] <llogan> also the defaults for flv output are going to be crappy.
[23:11] <llogan> generally for capturing the screen a fast encoder is used, then this output is re-encoded later.
[23:12] <llogan> ffmpeg -f x11grab -r 25 -s 1024x768 -i :0.0 -codec:v libx264 -preset ultrafast -crf 0 output.mp4
[23:12] <exutux> llogan: thank I'm reading
[23:13] <exutux> llogan: yeah but in this case it will grab all screen
[23:13] <llogan> yes, because i don't know the coordinates that you want
[23:14] <llogan> that was just an example for you to modify
[23:16] <llogan> then you can re-encode the first output to whatever you like: ffmpeg -i output.mp4 -codec:v libx264 -preset slow -crf 22 output2
[23:16] <llogan> of course if your computer is fast enough you can just do one command
[23:17] <llogan> and you may also need to add -pix_fmt yuv420p as an output option for the second command
[23:17] <exutux> http://paste.ubuntu.com/5908992/
[23:18] <exutux> so X 49 an Y 24?
[23:19] <exutux> by clicking in differnets areas results is always the same
[23:20] <llogan> -s 1317x744 -i :0.0+49,24
[23:20] <llogan> you click the window you want to record and it should give you the details of that particular window
[23:22] <exutux> llogan: well I get understanting maybe :D
[23:29] <exutux> llogan:
[23:29] <exutux> ffmpeg -f alsa -ac 2 -i pulse -r 15 -s 1244x614 -f x11grab -i :0.0+63,121 -acodec libmp3lame -ab 96k -ar 48000 -ac 2 -vcodec libx264  -crf 30 -threads 2 test.mkv
[23:29] <exutux> :D thanks
[23:30] <exutux> klaxa: thanks to you too
[23:30] <llogan> are you going to upload this to youtube or something?
[23:30] <llogan> because -crf 30 seems high
[23:32] <exutux> llogan: nope not now
[23:32] <exutux> llogan: btw which is right crf ?
[23:32] <llogan> screencasting can probably benefit from a higher frame rate
[23:33] <llogan> https://trac.ffmpeg.org/wiki/x264EncodingGuide
[23:33] <llogan> there is no "right" crf. it's subjective.
[23:33] <llogan> unless you're uploading to a video sharing site, then use -crf 18 since they will re-encode it anyway.
[23:34] <exutux> llogan: ok
[23:34] <klaxa> youtube re-encodes are meh though
[23:35] <klaxa> i have seen a guy that upscales his videos a little bit from 1080p to 1192p so he gets the "original source" quality
[23:35] <klaxa> also applys a sharpening filter to make up for the weird scaling
[23:35] <klaxa> don't know what i should think of that
[23:36] <llogan> i think he has a lot of time on his hands
[23:36] <klaxa> mmh
[23:36] <llogan> "time on his hands". english is weird.
[23:37] <llogan> i'm going to go chop down a tree and then chop it up.
[23:39] <exutux> :D
[23:53] <exutux> bye
[23:53] <exutux> and thanks again
[00:00] --- Thu Jul 25 2013