Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

November 2013

1 participants
60 discussions

ffmpeg-devel.log.20131124
by burek 25 Nov '13

25 Nov '13

[00:51] <clever> anybody here know h264 internals? [00:54] <JEEB> I would say the thing that knows H.264 best is the specification ;) [00:56] <{V}> H.264 spec is the singularity? [01:24] <BBB> clever: I know ffh264 decoder internals somewhat [01:24] <BBB> clever: but never ask to ask; just ask [01:24] <BBB> I'm also getting a nearly watchable image with 2pass decoding for ffvp9-frame-mt [01:24] <BBB> not quite right yet, but getting somewhere [01:25] <clever> BBB: i'm trying to add omx decode to mplayer, and ive almost got it working [01:25] <clever> btu the h264 slices arent quiet right, so the gpu core is rejecting them [01:25] <clever> i need to figure out what the differences are in the bitstream, but i dont know enough about h264 to do that [01:26] <clever> i can modify a working player to hexdump each slice [01:26] <BBB> oh, mplayer, sorry cantdo [01:26] <BBB> figure out how to do it in ffmpeg/ffplay/whatever [01:26] <BBB> I don't do mplayer, piece of crap software [01:26] <clever> the problems are within the ffmpeg part of mplayer [01:27] <BBB> then reproduce it in ffmpeg alone [01:27] <clever> i can modify my code to output raw yuv420 frames [01:27] <clever> then it would work with an unmodified mplayer [01:27] <BBB> ffmpeg has hardware accelration pathways [01:27] <clever> purely ffmpeg changes [01:27] <clever> i'm using those, they are half the problem [01:28] <clever> the h264 track in a mkv file starts with this [01:28] <clever> 00000000 00 00 00 01 67 64 00 29 ac 34 e5 01 e0 08 7b 01 |....gd.).4....{.| [01:28] <clever> 00000010 10 00 19 74 f0 04 c4 b4 08 f1 83 19 60 00 00 00 |...t........`...| [01:28] <clever> and if i feed that track directly to omx, it plays perfectly [01:29] <clever> but the stuff sent to the hwaccel decode_slice, lacks that header, and the start code 0x00 0x00 0x01 [01:29] <clever> if you give me about an hour, i can modify things to work purely within ffmpeg, at the cost of cpu usage durring playback [01:30] <clever> BBB: oh, one more thing [01:30] <clever> do you know if its possible to detect which vo mplayer is using with an ffmpeg hwaccel module? [01:30] <clever> and change how it works internaly [01:31] <BBB> I don't know anything about mplayer [01:31] <clever> ok, i'll just ignore that issue for now [01:31] <BBB> if you can od it in ffmpeg, I can try to help [01:31] <clever> let me grab a fresh checkout of ffmpeg and modify it to have hardware accel [01:31] <BBB> it sounds to me like ffmpeg may be eating the startcode [01:31] <clever> right now, my ffmpeg patch is similar to vdpau, it dumps the slice data to the vo module in mplayer [01:32] <clever> ive checked the official pi code, and its using codec->extradata and extradata_size to get arround the problem [01:32] <clever> and those fields contain the exact same data when using mplayer [01:32] <BBB> right, the slice data lacks the startcodes, that's because the slice data is basically post-nal parsing so we don't need it anymore [01:32] <BBB> if you need it in hw, you need to re-add it [01:32] <clever> but it doesnt work if i use that [01:32] <clever> yep [01:32] <BBB> I wouldn't be surprised if vdpau did that also [01:32] <clever> thats where i got the idea from [01:32] <clever> using the exact same code as the vdpau codec [01:32] <BBB> hm, but that doesn't work? [01:33] <clever> however, the codec config at the start is also needed [01:33] <BBB> hm... interesting [01:33] <clever> 00000000 00 00 00 01 67 64 00 29 ac 34 e5 01 e0 08 7b 01 |....gd.).4....{.| [01:33] <BBB> sps/pps? [01:33] <clever> 00000010 10 00 19 74 f0 04 c4 b4 08 f1 83 19 60 00 00 00 |...t........`...| [01:33] <clever> this piece, which is 637 bytes long [01:33] <clever> if i stick that into a file, and modify ffmpeg to insert it before the 1st slice, it decodes perfectly [01:33] <BBB> that's extradata [01:33] <BBB> typicaly [01:33] <BBB> (if you play, say, a mp4 file) [01:33] <clever> extradata is 41 bytes, not 637 bytes [01:34] <clever> and extradata doesnt work when i use it the same way [01:34] <BBB> is that 0000016764 thing in your mp4 file? [01:35] <clever> mkv file, and thats in the raw h264 track after i do mkvextract tracks foo.mkv 1:raw [01:35] <clever> if i send that raw file to the omx core, it decodes perfectly [01:35] <clever> ive been told a few days ago, that mkvextract is converting it slightly durring extraction [01:35] <clever> and its in a different format inside the raw mkv file [01:37] <BBB> it is [01:37] <BBB> 67 is sps... so ... [01:37] <clever> ive also checked the source of the official player, that is using extradata [01:37] <clever> and its extradata matches the extradata in ffmpeg perfectly [01:37] <BBB> that should normally be in extradata [01:38] <clever> but that doesnt work in my code [01:38] <BBB> I'm not sure why it thinks it's 41 bytes, that's maybe somewhat small [01:38] <clever> the 41 byte header has some similar binary strings [01:38] <BBB> are there other codes (beyond sps) in that 637 byte segment? [01:38] <clever> yes, there is a whole ascii string [01:38] <clever> let me pastebin it [01:39] <clever> BBB: http://pastebin.com/kVXL2363 [01:44] <clever> BBB: i'm guessing the ascii part is just a comment, and isnt required for decoding? [01:47] <BBB> yes [01:48] <clever> ok, let me try doing a patch against just ffmpeg and nothing more [01:48] <BBB> so I think you just need the parts before that and you should be ok (which, I expect, is very similar to the nal in extradata, or maybe a slightly unescaped version thereof) [01:49] <clever> i just noticed that there is an 0x00 0x00 0x01 in that header, which i dont think its sending [01:49] <clever> i'm checking that one last thing before i do the full ffmpeg patch [01:50] <BBB> you mean tripple 00 01? [01:50] <clever> 00000000 00 00 00 01 67 64 00 29 ac 34 e5 01 e0 08 7b 01 |....gd.).4....{.| [01:50] <clever> the first 3 or 4 bytes of this, the 0x67 is also missing [01:50] <BBB> hm... [01:50] <BBB> yeah that's kinda important [01:50] <BBB> the 67 tells your hw that it's the sps [01:51] <clever> thats the kind of thing i need help with! [01:51] <clever> i dont know that a byte like that is so important, lol [01:51] <clever> compiling... [01:53] <BBB> 00 00 00 01 tells your hw "this is the start of", 67 means "sps" (68 would be pps, etc.) [01:53] <BBB> so yes that one byte is kinda critical, but in general never chop any byte off, bad idea [01:54] <clever> yeah [01:54] <clever> the tricky part is that ffmpeg strips them out on me [01:54] <clever> and doesnt tell me how many bytes it took out [01:54] <clever> and it doesnt help when the entire system locks up if you send it bad data [01:55] <clever> 00000000 00 00 00 01 67 64 00 29 ac 34 e5 01 e0 08 7b 01 |....gd.).4....{.| [01:55] <clever> 00000000 00 00 01 67 01 64 00 33 ff e1 00 19 67 64 00 33 ...g.d.3....gd.3 [01:55] <clever> i think i should be stripping the 0x01 out now, to align things, and i forgot a 0x00 [01:57] <clever> hmmm, odd, there is another 0x6764 within the extra data [01:57] <clever> within 16 bytes of the start [01:58] <BBB> I'm not sure why you want to strip the 00 off, but if the hw expects that, I guess it's ok [01:58] <clever> i'm not really sure what the hardware expects, black box [01:59] <JEEB> clever, 14496-15 explains the extradata >:| [01:59] <BBB> :) [01:59] <clever> all i have is a few examples of what does work [01:59] <clever> JEEB: the omx docs make more sense then the h264 docs, lol [01:59] <JEEB> ... [02:00] <clever> 00000000 00 00 00 01 67 64 00 33 ff e1 00 19 67 64 00 33 ....gd.3....gd.3 [02:00] <clever> ok, that looks close enough, lets see what 120 frames does [02:00] <clever> nothin [02:00] <clever> ok, out the door with mplayer, lets try raw ffmpeg [02:00] <JEEB> clever, so you don't understand the pseudocode part of AVC decoder configuration record? [02:01] <clever> JEEB: its pretty cryptic, and it starts right after that key 0x67 byte that BBB just explained [02:01] <JEEB> the aligned(8) class AVCDecoderConfigurationRecord { } thing [02:01] <clever> i dont think it even mentions the 00000001 and 67 part [02:02] <JEEB> I have no idea what you're talking about, but the goddamn semantics after the pseudocode should explain it rather goddamn well [02:02] <clever> 00000000 00 00 00 01 67 64 00 29 ac 34 e5 01 e0 08 7b 01 |....gd.).4....{.| [02:02] <Paranoialmaniac> 09:28 (clever) the h264 track in a mkv file starts with this [02:02] <Paranoialmaniac> 09:28 (clever) 00000000 00 00 00 01 67 64 00 29 ac 34 e5 01 e0 08 7b 01 |....gd.).4....{.| [02:02] <clever> the first 5 bytes of this header [02:02] <Paranoialmaniac> wut [02:02] <JEEB> WHAT HEADER [02:02] <JEEB> what the hell are you talking about? [02:02] <JEEB> extradata? [02:02] <JEEB> in-band data? [02:02] <clever> JEEB: the raw h264 track in the mkv file [02:02] <JEEB> .... [02:02] <clever> i dumped it with mkvextract [02:03] <BBB> I believe in mkv it's inline [02:03] <BBB> in mp4 it's in the spps, i.e. global header [02:03] <JEEB> ok, so you're dealing with annex b you've extracted with mkvextract? [02:03] <clever> yeah, i think mkvextract converted it over [02:03] <BBB> in both cases it's extracted into extradata [02:03] <JEEB> that's not AVCc [02:03] <clever> JEEB: if you say so, ive no idea what this should be refered to as [02:03] <Paranoialmaniac> h264 in mkv doesn't use any start codes [02:03] <clever> just how i got it, and that it works [02:04] <clever> let me try and patch ffmpeg to decode on its own, and then get back to you [02:04] <clever> take mplayer out of the equation [02:04] <JEEB> clever, if you extract a raw H.264 stream, that's in 99.9999% of all cases (except the failcases and hurr durr dumps) ANNEX B [02:04] <clever> ah [02:04] <JEEB> defined in the actual H.264 specification, Annex B [02:04] <clever> and the omx core seems to handle that perfectly [02:04] <JEEB> mp4 and mkv use a DIFFERENT PACKAGING, which is usually called AVCc [02:05] <JEEB> that is defined in 14496-15 [02:05] <clever> if i run the demo app on it, or modify mplayer/ffmpeg to recreate it, it works perfectly [02:05] <JEEB> both deal with the same thing, NAL units [02:05] <JEEB> Annex B has start codes [02:05] <clever> oh, wait a sec [02:05] <clever> you just gave me an idea, i'm doing half and half [02:05] <clever> i'm using mkv extradata, with startcodes injected [02:06] <JEEB> no you are not unless you have murdered your goddamn stream during extraction [02:06] <JEEB> and if you used mkvextract I would believe it doesn't fuck up like that [02:06] <JEEB> (I would like to believe) [02:06] <clever> i'm using the nal units that ffmpeg provides to the hwaccel module [02:06] <clever> and manualy adding start codes to each slice [02:06] <JEEB> http://www.itu.int/rec/T-REC-H.264-201304-I/ [02:06] <clever> let me try one last thing with mplayer [02:06] <JEEB> Annex B in this defines the goddamn "Annex B" raw byte stream format [02:07] <JEEB> it's really irritating looking at you doing random crap because you have no idea what you're dealing with [02:07] <clever> yeah, i really do have no clue what i'm doing, i'm surprised ive gotten this far [02:08] <clever> ok, about 5 minutes to try a few things, then i'll just patch ffmpeg and see what it does [02:10] <JEEB> please... do us and yourself a favor and for once read the goddamn spec [02:10] <JEEB> and if you don't understand something, ASK [02:10] <JEEB> instead of just fucking trying to poke a haystack with a needle, trying to find a person from inside of it [02:10] <clever> i think i know whats wrong now [02:11] <clever> i'm feeding it the mkv extradata, and then mangling the slices into ANNEX B format, messing it up [02:12] <clever> that explains why the annex b slice data only works when i use the annex b header from the extracted stream [02:13] <JEEB> I'd really, really like it if you'd stop for a while and asked what you didn't understand of the 14496-15 extradata [02:13] <JEEB> as you said you didn't understand it [02:13] <clever> i was starting to, several of the fixed bits matched up with the extradata [02:13] <clever> but then i discovered omxplayer is sending the exact same extradata and getting different results [02:14] <clever> so i stopped focusing on that part, it wasnt a variable [02:15] <JEEB> <clever> JEEB: the omx docs make more sense then the h264 docs, lol [02:15] <JEEB> this makes me very, very worried [02:15] <JEEB> if you can't understand the AVCDecoderConfigurationRecord definition then something's wrong [02:15] <clever> i was starting to figure those out [02:16] <clever> but lost interest when i noticed that omxplayer is sending the exact same data and getting different results [02:16] <clever> and moved on to comparing other parts [02:16] <JEEB> still, saying what you said is very troubling [02:18] <JEEB> anyways, I just wish you would just step a few steps backwards [02:18] <JEEB> and started at your first problem regarding either of the stream formats [02:18] <JEEB> and thus we can actually start taking you the right way instead of "I don't understand ANYTHING but I TOTALLY HACKED THIS" [02:18] <clever> i think the current problem is that i'm mixing formats, so i'm trying to undo that and see what happens [02:24] <clever> ok, i need to stop and fsck things [02:24] <clever> too many improper shutdowns [02:28] <clever> uh oh, half a dozen files to /lost+found [02:38] <Compn> JEEB : the fun part is watching clever hack his way left and right :) [02:38] <clever> good thing i just saved a git diff of this [02:38] <clever> the fs corruption renamed nearly every key file [02:38] <Compn> good thing you dont have any backup do you ? [02:39] <Compn> most of these clouds give free 3gb space [02:39] <Compn> cant you hook up some autobackup thing ? [02:39] <clever> ive compiled in dropbox before [02:39] <clever> it ended with complaints about 5 files being edited giving 5 popups per minute on another box :P [02:40] <clever> and i dont think the pi has dropbox binaries [02:40] <Compn> http://www.tourocloudbackup.com/ [02:40] <clever> let me restore things from patch [02:40] <Compn> 3gb from hitachi (western digital) [02:41] <Compn> Personal [02:41] <Compn> Free [02:41] <Compn> Get 10GB secure storage with 250MB file upload size [02:41] <Compn> https://www.box.com/pricing/ [02:41] <Compn> 10gb free with box [02:41] <clever> simpler to just use nfs [02:41] <Compn> hell just email your code to yourself :) [02:41] <clever> Filesystem Size Used Avail Use% Mounted on [02:41] <clever> rob1:/media/videos/4tb 3.7T 1.5T 2.3T 40% /media/videos/4tb [02:41] <clever> ive got the room [02:41] <clever> i just didnt want to deal with the delays [02:41] <Compn> ehe [02:42] <clever> but now the sd card is full, so i have no option [02:42] <clever> was within minutes of fixing it, i think [02:42] <clever> then the card goes 'nope!' and eats it [02:43] <clever> pretty sure it was me yanking the cord a dozen times [03:28] <clever> JEEB: another problem i may need help with soon, after the h264 decode issues [03:28] <clever> how to work the omx tunnels into the code right [03:29] <clever> currently, the ffmpeg hwaccel module just ships the bitstream directly to the mplayer vo, thru a custom pixel format [03:29] <clever> so mplayer does ALL of the omx work [03:29] <clever> i could modify it to decode it into yuv420 images, and then ship the frames down as proper frames [03:29] <clever> but then there is extra cpu load [03:30] <clever> so i want to be able to do both, based on conditions/options [03:30] <clever> if your using omx to decode and render, just do everything within the gpu [03:30] <clever> if your using omx to decode and fbdev or xv to render, just output yuv420 [03:30] <clever> and if video filters are enabled, yuv420 [04:03] <cone-902> ffmpeg.git 03Michael Niedermayer 07master:3d5a5e86be2a: avcodec/jpeg2000dec: Check precno before using it in JPEG2000_PGOD_CPRL [05:03] <cone-902> ffmpeg.git 03Diego Biurrun 07master:f187557ab461: build: more fine-grained dependencies for documentation build tools [05:03] <cone-902> ffmpeg.git 03Michael Niedermayer 07master:c0237d19a026: Merge commit 'f187557ab4612776f7f527ecf3d40062975c3e4c' [05:07] <clever> Compn: i thought i was within minutes of fixing things! [05:07] <clever> then i get fs corruption, twice in a row [05:11] <cone-902> ffmpeg.git 03Tim Walker 07master:48b24bd2d208: ac3dec: Fix out-of-array read [05:11] <cone-902> ffmpeg.git 03Michael Niedermayer 07master:ceaaf0d97e7f: Merge commit '48b24bd2d208ce0f124029ac4c5ac5cb1fca4175' [05:20] <cone-902> ffmpeg.git 03Diego Biurrun 07master:0eeeb9647e9c: mpegaudiodec: Consistently handle fixed/float templating [05:20] <cone-902> ffmpeg.git 03Michael Niedermayer 07master:f67ec7f3a269: Merge commit '0eeeb9647e9c92c9edfd0b18c7cb5da7ac666f85' [05:21] <Compn> clever : well you did it all before, so it wont be hard to do it again :) [05:21] <Compn> if you were that close of course [05:24] <clever> Compn: i put patches up on the rpi forum just last night [05:24] <clever> so i can just checkout the source and apply the patches, following my own directions [05:24] <clever> i was doing that, then the fs corruption hit me again [05:32] <cone-902> ffmpeg.git 03Diego Biurrun 07master:8f8bc92365a9: Add missing #includes for *INT64_MAX and *INT64_C [05:32] <cone-902> ffmpeg.git 03Michael Niedermayer 07master:ccdfa3e2711c: Merge remote-tracking branch 'qatar/master' [08:50] <wm4> clever: lol what, fs corruption? [08:51] <clever> wm4: yeah, i somehow broke the sd card after recompiling mplayer 50+ times [08:51] <clever> its so bad that apt-get crashes, the .postinst script turned into raw binary garbage [09:18] <ubitux> clever: wut, can't you just use tmpfs? [09:19] <clever> ubitux: less then 256mb ram [09:19] <clever> ffmpeg alone takes ~220mb [09:19] <clever> plus the ram to link the stuff [09:19] <ubitux> wait, you are compiling on the rpi directly? oO [09:19] <clever> yes [09:19] <ubitux> why dont you just cross compil? [09:19] <clever> i didnt want to risk even more complications [09:19] <ubitux> and upload the binary to the tmpfs [09:20] <clever> as it turns out, if you forget a certain -D flag, the get buffer function silently hangs [09:20] <clever> without any obvious cause, even after heavy debugging [09:21] <clever> cross compiling just adds even more risk for complications [09:22] <ubitux> compiling on the rpi is most likely slow, it breaks your hw, and thus causes a lot of complications :) [09:22] <clever> i didnt expect the sd card to expire so quickly [09:22] <clever> just 3 or 4 days of compiling nuked it [09:23] <clever> ive reflashed a new card, and put the build directory on nfs [09:23] <clever> so it wont be loading the sd card any further [09:23] <clever> sd is totaly idle [09:28] <wm4> btw. a tmpfs can be resized [09:28] <clever> wm4: yeah, ive done that 100's of times [09:28] <clever> when ram+swap had enough room [09:28] <clever> but with 256mb ram, no :P [09:28] <clever> and with swap on the SD card, back to the original problem [09:29] <wm4> swap on a sd card sounds so wrong [09:29] <clever> i once had to create 3 or 4 swap files, totaling 6gig, just to get mongodb to compile in a tmpfs [09:29] <clever> i thought it would be done after another gig [09:29] <clever> then it kept growing, and growing, and growing [09:30] <clever> i think they where staticly linking everything, with debug info [09:30] <clever> 700mb per program, all sharing the same libs [09:30] <clever> then copying it to a dist dir, doubling the usage [09:30] <wm4> "why not just copy paste from ffplay into libavfilter?" --the mailing list [09:30] <wm4> jesus [09:31] <clever> that makes no sense [09:31] <clever> dont see how such stuff would even work? [09:32] <wm4> someone is trying to make a videoplayer using libavdevice [09:32] <wm4> or trying to turn ffplay into a library [09:34] <clever> wm4: did you see what i said above about hwaccel thru hw video output vs yuv420 frames? [09:34] <wm4> yeah [09:35] <ubitux> arh diego removing --disable-doc [09:35] <clever> do you know how i could detect which video output module is in use, and just do the right thing automaticaly? [09:35] <ubitux> wth [09:35] <wm4> clever: passing hardware surfaces down to the VO will be harder, but probably also more efficient? [09:35] <wm4> clever: also, is the omx code reusable outside of the rpi? [09:35] <clever> i dont think so [09:35] <wm4> then I'd just see what's most efficient on the rpi [09:35] <clever> but omx has what are called tunnels, you link the video_decode to video_render, and then just forget about it [09:36] <clever> so you dont pass surfaces arround at all, you just give it h264 bitstream data and it comes out the hdmi [09:36] <wm4> oh [09:36] <wm4> that sounds very against mplayer's (or most player's) architecture [09:36] <clever> yeah [09:36] <clever> you can ignore that, and read yuv420 frames out of video_decode [09:37] <wm4> can you get EGL-something? [09:37] <clever> but that will increase the memory bandwidth usage [09:37] <clever> it also has tunnels that can connect to egl [09:37] <wm4> there's certain interop for omx->EGL, but I don't know details [09:37] <clever> reading anything from the gpu requires copying it from a gpu buffer to an arm buffer [09:37] <clever> and then to render it again, you have to copy it the other way [09:37] <clever> so thats atleast 2 memcpy's for every full frame of data [09:37] <wm4> I'd expect EGL interop wouldn't have this cost [09:37] <clever> plus one to get it from the input buffer to the output buffer [09:38] <clever> so 3 memcpy's, plus whatever video filter logic adds [09:38] <clever> let me double check the egl stuff [09:39] <clever> http://ext.earthtools.ca/firmware/documentation/ilcomponents/index.html [09:39] <clever> yep, you can connect video_decode to egl_render, and it will draw things to an EGL image [09:39] <clever> what happens next, i have no clue [09:40] <clever> can you use the GL operations to make the gpu apply text overlays? [09:40] <wm4> I suppose you could treat an EGLImage as video surface [09:40] <wm4> and render it on a VO that uses GLES [09:40] <clever> and how would that interact with things like -vf ass and -vf screenshot? [09:41] <clever> or just the osd in general [09:41] <wm4> OSD would just draw text on top of it using OpenGL drawing commands [09:41] <wm4> video filters can't work with it [09:41] <clever> the entire reason i started this was to get -vf ass to work [09:41] <wm4> subtitles (via libass) can be rendered via EOSD (i.e. the VO does it) [09:42] <wm4> screenshots... well uh, mplayer has nothing for it, but my mplayer fork allows VOs to take screenshots [09:42] <clever> ah [09:42] <clever> could some -vf options be modified to be GL aware? [09:42] <wm4> and most time you don't need extra video filters [09:42] <wm4> perhaps [09:42] <clever> and then use GL draw operations? [09:43] <wm4> but this would be expensive and complicated [09:43] <clever> i was just thinking, might that improve the ass render cpu usage? [09:43] <wm4> if you're looking at vf_ass, nope [09:43] <clever> making the gpu do all the heavy draw operations [09:43] <wm4> doing it on the VO can improve efficiency [09:43] <wm4> this is also how vo_vdpau does it [09:43] <clever> the other issue i have right now is av sync [09:43] <wm4> vdpau passes opaque vdpau video surfaces to the VO [09:44] <clever> omx is designed to handle EVERYTHING [09:44] <clever> h264 bitstream goes into video_decode [09:44] <clever> mp3 bitstream goes into audio_decode [09:44] <wm4> yeah, OMX is apparently obnoxious like this, it's more like dshow or gstreamer than ffmpeg [09:44] <clever> video_decode -> video_scheduler [09:44] <clever> clock -> video_scheduler [09:44] <clever> clock -> audio something [09:44] <clever> video_scheduler -> video render [09:44] <clever> and then it just stays in sync on its own [09:45] <clever> all you do is feed it bitstream data [09:45] <clever> and if you throw read_media into the mix, you dont even do that [09:45] <clever> it reads files on its own [09:45] <clever> and handles all demux [09:45] <wm4> yep [09:45] <clever> its more like an all in one solution to <video> [09:45] <wm4> it's a video playback framework [09:46] <clever> its even got gpu side drm logic [09:46] <clever> but thats a black box by design, nobody would give me keys to even test it :P [09:46] <clever> for my testing, i just took the clock and scheduler out completely [09:47] <clever> so it will render frames as fast as it possibly can [09:47] <clever> only limited by how often draw_slice gets called to feed it [09:47] <clever> something else, if i was to make it output yuv420 frames, that would make gpu assisted ffmpeg transcodes work [09:47] <clever> am i right? [09:48] <wm4> (and btw. this kind of high level API is what ffmpeg should have too, i.e. so you don't have to bother doing the demuxer->decoder glue manually) [09:48] <wm4> what would be the point of transcoding with rpi be [09:49] <clever> the power usage it has [09:50] <clever> under 5 watts to be able to transcode video content in realtime [09:50] <clever> streaming it to devices which lack the ability to handle the codec, maybe rendering ass into the stream transparently [09:51] <wm4> wouldn't that mean using mplayer to transcode? [09:51] <wm4> because ffmpeg has no easy way to just hardsub a file [09:51] <clever> ffmpeg doesnt have ass? [09:52] <clever> ah [09:52] <clever> so it would have to be mencoder then [09:52] <clever> same basic idea though [09:52] <ubitux> meh [09:52] <wm4> mencoder is a rotting corpse [09:52] <wm4> don't touch it [09:52] <wm4> ffmpeg does have an ass renderer [09:52] <ubitux> it has [09:52] <wm4> but it can't automatically use the ass subtitle track of the source file [09:53] <wm4> because ffmpeg devs are too busy bikeshedding and overdesigning [09:53] <ubitux> meh cant read [09:53] <clever> thats easy enough to fix [09:53] <ubitux> wm4: oh come on :)) [09:53] <ubitux> np ot [09:53] <clever> mkvextract and a pre-extract phase [09:53] <clever> i'm already doing that for some files [09:53] <clever> hmmm, where did that script go [09:53] <wm4> yeah, that would work [09:53] <wm4> you could even use ffmpeg to extract [09:53] <wm4> probably [09:53] <clever> time ffmpeg -i "$1" -s "$2" -vcodec mpeg4 -acodec libfaac -ac 2 -ar 48000 -r 24 -ab 64000 -aspect 16:9 -filter:0:0 ass="$3" -b:v 1000k "$4" [09:53] <clever> oh, i'm already even using ffmpeg to do it [09:54] <wm4> or vf-ass can just take a video file, and use its sub track [09:54] <ubitux> you don't even need to extract [09:54] <clever> does it handle the embeded fonts? [09:54] <ubitux> problem is, it likely won't honor the fonts and stuff [09:54] <clever> ive been having to manualy extract those and copy them to ~/.fonts/ [09:54] <clever> ahhh [09:54] <clever> still easy enough to script that step [09:54] <ubitux> yeah you have to extract them [09:55] <clever> so with the right hwaccel encode and decode, the above command could do realtime transcode and hardsub on a pi [09:55] <clever> at the cost of ~3 memcpy per frame [09:55] <wm4> ubitux: couldn't you add that to vf_ass? [09:55] <wm4> doesn't sound hard [09:56] <ubitux> add what? [09:56] <clever> omx also has a resize module, so i can downscale things before the 1st memcpy [09:56] <wm4> fonts from multiplexed files [09:56] <clever> would require some decoder argument hackery, but it would massively cut down on memory bandwidth [09:56] <ubitux> it's within libavfilter, you don't have access to the format and sub/data streams [09:56] <ubitux> unless you meant vf subtitles? [09:57] <wm4> clever: at this point, it just sounds like you should use omx and libass manually, without involving ffmpeg or mplayer [09:57] <wm4> ubitux: right [09:57] <clever> wm4: the whole reason i started, is because i prefer all the existing features/control in mplayer [09:57] <clever> and it was painfull to watch omxplayer reinvent the wheel, one feature at a time [09:57] <ubitux> maybe we can yeah but well [09:57] <clever> for example, i dont think it has lirc yet, the cli status is poor, limited subtitle control [09:58] <clever> no input configuration at all, all keybinds are hard-coded [09:58] <wm4> well, omxplayer is more like a demo... [09:58] <clever> which they keep trying to turn into a full player, one small piece at a time [09:59] <clever> also, omxplayer doesnt feel like a demo app [09:59] <clever> hello_video is a demo app [10:00] <clever> hello_video locks the system up if you give it anything muxed [10:00] <clever> it only works on raw video tracks [10:00] <clever> and has zero controls [10:01] <wm4> how does the omx stuff give you raw video data? [10:01] <wm4> i.e. yuv [10:01] <clever> the video_decode module outputs yuv420 frames [10:01] <clever> you either connect that to a module which accepts yuv420, or you read it directly [10:02] <clever> if you connect it together with tunnels, then the data stays within the gpu, sharing buffers [10:02] <wm4> I mean, maybe you'd be able to avoid a memcpy, if it gives you a pointer to the data directly [10:02] <clever> all data going in and out of the gpu is memcpy'd once for each direction [10:02] <clever> and i'm not sure if you can reuse the buffer it gives on another module [10:03] <clever> so you might need to memcpy it from 1 buffer to another [10:03] <clever> do you know if the pi has XV? [10:03] <clever> or it might be better to just use fbdev set directly to the video resolution [10:04] <clever> fbdev would get you down to 2 memcpy for sure [10:04] <wm4> uh no idea, but I'd suspect that gles is the best way to output graphics on such a device [10:04] <clever> and the gpu resize module could be used to cheat the memory bandwidth, at the cost of resolution [10:05] <clever> hmmmm, i wonder if ass already works on gles [10:05] Action: clever looks [10:05] <wm4> AFAIK mplayer has some extremely hacky gles output [10:05] <clever> nope, no -vo gles on my laptop yet [10:05] <wm4> which probably doesn't work on rpi without punching it a few times [10:05] <wm4> it's in vo_gl [10:05] <clever> that isnt there either [10:06] <clever> need to enable it in portage [10:08] <clever> strange, no gl* in the use flags [10:08] <clever> ah, there it is, opengl [10:11] <clever> ok, guess i was wrong about the problem [10:11] <clever> its outputing random garbage, and locked up solid [10:11] <clever> not even the serial port responds [10:11] <wm4> wut [10:12] <clever> sending it extradata, then slices without the startcode, causes the entire system to lock up solid [10:12] <clever> i'll do what i was going to do with BBB then, take mplayer out of the equation [10:12] <clever> ffplay alone [10:14] <clever> and just to verify [10:14] <clever> mplayer -vo gl2 -sub test.ass -vf ass foo.mp4 [10:15] <clever> this correctly renders under a normal x86 laptop [10:15] <wm4> why gl2? [10:15] <clever> so if the opengl libs are compatible, and i can pass it a gl handle to an existing gpu texture, that could work under the pi [10:15] <clever> gl OpenGL [10:15] <clever> gl2 X11 (OpenGL) - multiple textures version [10:15] <wm4> why gl2? [10:15] <clever> this implied that gl lacks x11 support? [10:15] <wm4> no [10:16] <wm4> gl2 is a steaming pile of shit, but users tend to use it, because it sounds like gl version 2 [10:16] <clever> then why is it trying to say that gl2 has x11, and gl doesnt say either way? [10:16] <wm4> because the description is full of shit [10:16] <clever> ok, trying -vo gl [10:16] <clever> also works perfectly [10:17] <clever> so that is a valid route under the rpi, if the gl libs are compatible [10:17] <clever> does ffmpeg have any support to do gl surfaces properly, or is it another hack with custom pixel formats? [10:18] <clever> and what happens if the codec gets used against -vo fbdev for example? [10:18] <clever> does it just hard fail, can it detect and switch to yuv420? [10:18] <wm4> no, ffmpeg doesn't know GL, but I don't see how it matters [10:18] <wm4> maybe [10:18] <clever> i'll figure that out when i redo this all to decode in ffmpeg [10:19] <wm4> so you're somehow trying to achieve multiple things... [10:19] <clever> just trying different attack angles [10:19] <clever> while trying to keep it flexible and performing good [10:19] <clever> yes, i'm asking too much of myself, lol [10:20] <clever> brb [10:28] <clever> back [10:28] <clever> since i'm redoing things anyways, i might as well try to cross compile it [11:06] <ubitux> BBB: what's the range of E, I, H? [0;0xff]? [11:17] <ubitux> if it's within [0;0xff) that would be great [11:19] <clever> clever@sakura /media/videos/4tb/rpi/ffmpeg $ ls [11:19] <clever> ls: cannot access doc: No such file or directory [11:19] <clever> great, the nfs server is messing with me again, claiming files dont exist, right after telling ls they did [12:09] <clever> hmmm, how do i enable ffplay? [12:09] <clever> i see ffplay.c tied to CONFIG_FFPLAY, but no option in configure [12:10] <clever> config.h:#define CONFIG_FFPLAY 0 [12:10] <clever> and i cant even figure out how its being set to 0 when the string doesnt exist in configure??? [12:11] <beastd> it is enabled by default if you have the necessary build dependencies [12:11] <beastd> do you have libsdl and headers around? [12:11] <clever> not yet [12:11] <clever> let me get the sysroot mounted [12:12] <clever> and do you know how to do cross compile and distcc?, all hosts are x86, target is arm [12:12] <clever> so its not the usual make calls gcc on arm and runs wrong gcc on x86 problem [12:14] <ubitux> http://trac.ffmpeg.org/wiki/How%20to%20compile%20FFmpeg%20for%20Raspberry%2… ? [12:15] <clever> ive already used crossdev to get a crosscompiler on all hosts [12:16] <clever> and that mentions everything except sdl [12:16] <clever> let me mount the pi root on the compile system and give configure the right args [12:39] <cone-406> ffmpeg.git 03Carl Eugen Hoyos 07master:e043298cb1b9: lavf/mpegenc: Print a warning if ac3, pcm_s16be or dts are muxed into mpeg1. [12:55] <BBB> ubitux: oh, much smaller [12:56] <BBB> ubitux: see the tables in vp9.c [12:56] <BBB> I believe I can look at the exact ranges, but yes it definitely fits in a byte [13:23] <clever> ubitux: --sysroot breaks the build, cannot find crti.o: No such file or directory [13:23] <clever> ./configure --cross-prefix=arm-linux-gnueabihf- --target-os=linux --arch=arm --enable-cross-compile --sysroot=/mnt/bcmroot/ [13:23] <clever> so i cant use what i think are the correct cross-compile flags [13:23] <clever> /mnt/bcmroot/usr/lib/arm-linux-gnueabihf/crt1.o [13:26] Action: clever heads to bed [13:32] <ubitux> BBB: ah great in that case [13:33] <ubitux> clever: i can't help you with cross compile [13:43] <ubitux> BBB: i planed to use and abuse pshufb and masks, am i doing right? [14:21] <BBB> ubitux: absolutely [14:23] <ubitux> i'm still looking for a p-sub-abs-byte instr. though [14:23] <BBB> por(psubusb(a-b),psubusb(b-a))? [14:24] <ubitux> mmh [14:24] <ubitux> thx :) [14:24] <BBB> you can occasionally check the vp8 loopfilter, there's quite some similarities in the setup phase [14:24] <BBB> so some of that should be copiable [14:25] <BBB> copyable? [14:25] <BBB> not in code, but in concept [14:25] <BBB> (since the exact values likely changed, but the logic is very similar) [14:25] <ubitux> ok [14:28] <BBB> I think mt works [14:28] <BBB> haven't done any complete fate runs but my sample file looks faster and so on [14:28] <BBB> and visually correct [14:29] <ubitux> how faster does it get? [14:29] <ubitux> (does libvpx has threading decode?) [14:59] <BBB> 6.2sec to 3.98sec 1->2 thr [14:59] <BBB> \o/ [14:59] <BBB> bbl [15:00] <beastd> BBB: Nice speed up! [15:17] <ubitux> can i load data directly in a xmm register? [15:27] <ubitux> oh, trac upgrade. [15:33] <beastd> ubitux: yes, i did it. [15:34] <ubitux> :) [16:29] <Daemon404> ubitux, ping [16:30] <ubitux> Daemon404: pong [16:30] <Daemon404> ubitux, did you have any other commentso n makedef besides the $'' [16:30] <Daemon404> im going to fix this in teh c99-to-c89 repo [16:30] <Daemon404> before proper patch is sent [16:30] <ubitux> the trap thing [16:31] <ubitux> and i think that's all [16:31] <Daemon404> trap thing [16:31] <Daemon404> ? [16:31] <ubitux> yes the cleanup of temp files using trap [16:32] <ubitux> cleanup() { rm -f xxxx } trap EXIT cleanup [16:32] <ubitux> or sth like that [16:32] <Daemon404> hmm ok [16:32] <Daemon404> does our configure have that? [16:32] <ubitux> configure:trap 'rm -f -- $TMPFILES' EXIT [16:33] <Daemon404> hm k [16:55] <rexbron> Quick question, I can't seem to access the tracker. I'm getting redirected to its.ffmpeg.org and get no further. Is this only on my end? [16:56] <Daemon404> fails here too [16:59] <rexbron> k [16:59] <rexbron> thanks Daemon404 [17:00] <ubitux> ping beastd [17:02] <beastd> looking at it [17:12] <beastd> rexbron: the redirect is OK. now it should be working again. can you confirm? [17:12] <Daemon404> works for me now [17:12] <Daemon404> what dos 'its' stand for btw [17:13] <beastd> issue tracking system [17:13] <Daemon404> o. [17:13] <beastd> we use it for now. but it will not be needed once migration is complete [17:13] <Daemon404> migration to what? [17:14] <beastd> different trac version on a different machine [17:14] <Daemon404> ah ok [17:18] <rexbron> beastd: Works! [17:18] <beastd> rexbron: good. thanks for bringing it up here. [18:26] <saste> what's going on with trac today? [18:27] <ubitux> beastd is taking over it [18:27] <beastd> saste: do you have sth specific? [18:28] <saste> beastd, a notice on the website, a mailing list message telling that the server will not be available due to maintainance seems proper [18:31] <beastd> saste: trac should be available. [18:33] <beastd> saste: trac should be available. i can post a notice on the MLs next time [18:39] <Compn> interesting kinda http://www.willus.com/author/ffmpegbmark.shtml [18:46] <ubitux> we have a problem with the version? [18:46] <ubitux> first time i hear this complain [18:46] <beastd> ubitux: yes, just read that too. [18:48] <ubitux> most likely a tag issue [18:48] <beastd> i think he would be fine with plain default git describe output. [18:49] <ubitux> ah that's the describe thing [18:50] <Compn> he wants to know which branch is which daily build [18:50] <Compn> :P [18:50] <ubitux> sounds legit [18:52] <wm4> lol [18:52] <wm4> they're comparing ffmpeg and libav - each built by different people? [18:52] <wm4> that's almost like comparing apples and oranges [18:52] <ubitux> [~/src/ffmpeg]- git describe --tags --match N [18:52] <ubitux> N-58419-gbea9394 [18:52] <ubitux> [~/src/ffmpeg]- git describe --always [18:52] <ubitux> n2.0-3816-gbea9394 [18:52] <ubitux> we do the first one since 40222b926b6d2f7d08aeeff756de3ade36121396 [18:53] <ubitux> maybe we could mix both [18:58] <Compn> wm4 : shh :D [18:59] <Compn> wm4 : its like comparing ... apples and oranges, yes. the benchmarks that are +-1s arent that useful anyhow [18:59] <Daemon404> something something dezicycles [19:00] <Compn> but the ogv thing sounds like a bug [19:00] <Compn> Daemon404 : you still a libav guy? maybe you could report ogv problem to them? [19:00] <Daemon404> "a libav guy [19:00] Action: Daemon404 facedesk [19:01] <Compn> a guy who talks to them, i mean [19:01] <Compn> libav developer [19:02] <Compn> brb internet disconnection time [19:02] <ubitux> hard part is not to talk to them [19:02] <ubitux> it's to get an answer [19:02] <Compn> lol yes that too [19:36] <saste> beastd, http://ffmpeg.org/trac/ffmpeg -> 404 [19:36] <saste> only its.ffmpeg.org/ is working [19:40] <cone-682> ffmpeg.git 03Stefano Sabatini 07master:8446bb33d1d0: doc/outdevs/sdl: fix confusing text about window_fullscreen default value [19:40] <cone-682> ffmpeg.git 03Stefano Sabatini 07master:25c675b5a744: lavd/sdl: do not manually free window_title and icon_title fields [19:43] <Timothy_Gu> beastd, is there a special reason why it's called "its".ffmpeg.off? [19:44] <Timothy_Gu> Sorry its.ffmpeg.org. Freaking Android keyboard autocomplete. [19:45] <ubitux> 17:13:01 <@beastd> issue tracking system [19:45] <ubitux> Timothy_Gu ^ [19:45] <Timothy_Gu> ubitux: ah [19:45] <beastd> yes [19:45] <beastd> Timothy_Gu: everything should be working with the trac.ffmpeg.org too [19:49] <beastd> saste: should be working now. you picked the one case out of all ffmpeg.org/trac/ffmpeg URLs that was not working. Sorry for the inconvenience. [19:50] <beastd> saste: Did you have that as a bookmark? [19:50] <saste> beastd, yes, i fixed the bookmark [19:50] <saste> now the old address works fine as well [19:50] <Timothy_Gu> saste: I was doing a Google Code-In task recently. And it was about fixing Trac wiki. [19:51] <saste> Timothy_Gu, what's wrong with the trac wiki? [19:51] <Timothy_Gu> saste: well it was fixing another project's wiki [19:52] <beastd> saste: trac.ffmpeg.org should be future proof. [19:52] <Timothy_Gu> saste: and I thought of FF's trac. And I found this page https://its.ffmpeg.org/wiki/TitleIndex [19:53] <BBB> ubitux: loading data into xmm register, what do you mean other than mova? [19:53] <ubitux> BBB: i mean mova xmm0, 1234 instead of mova xmm0, [xxx] [19:54] <ubitux> but it seems there is no direct way [19:54] <ubitux> at least without various trick [19:54] <ubitux> not important though [19:54] <BBB> just declare rodata [19:54] <Timothy_Gu> saste: IMO it's in serious need of a categorization [19:55] <BBB> pw_1234: dw 1,2,3,4,5,6,7,8 [19:55] <beastd> Timothy_Gu: probably. also we have TracTags. that may also be of help for the wiki pages. [19:57] <Timothy_Gu> beastd: maybe, I don't know. I don't have time to renovate the wiki anyways. I'm just pointing out the wiki messiness here. [19:58] <BBB> funny typo just now [19:58] <BBB> it was actually 3.8, not 3.98 [19:58] <BBB> not sure where that 9 came from [19:58] <BBB> was in a hurry I guess [19:58] <BBB> anyway I can get it down another notch if I work another few minutes [19:59] <BBB> not bad for a 2pass decoding stage in the mt case [19:59] <ubitux> BBB: yes but i wanted to avoid it for some reason, really i was just curious if there was a way [20:00] <BBB> only for some cosntants [20:00] <BBB> for e.g. 0xffffff or 0x000000, yes [20:00] <BBB> for easily derived versions thereof, in 2 instructions, yes [20:00] <BBB> otherwise, no [20:00] <ubitux> yep, ok [20:02] <Timothy_Gu> Just a random thought. Someone backport http://git.videolan.org/?p=ffmpeg.git;a=history;f=libpostproc;hb=HEAD to http://git.videolan.org/?p=libpostproc.git;a=shortlog ? [20:31] <saste> ubitux, any way to select subtitles text encoding? ^^ [20:31] <saste> sub_charenc option seems a bit underdocumented (what does it take as argument?) [20:32] <ubitux> no, but shouldn't be hard to add [20:32] <saste> ubitux, sub_chardec? [20:32] <beastd> sub_charenc is input encoding isn't it? [20:33] <ubitux> yes, despite the name [20:33] <ubitux> nicolas insisted on that name [20:33] <ubitux> beastd: input subtitles character encoding utf-8 [20:34] <saste> shouldn't already work then selecting the correct input text encoding? [20:34] <saste> what's missing? [20:35] <saste> we should probably have an option for metadata as well [20:35] <ubitux> it takes anything returned by iconv -l [20:35] <ubitux> oh wait i misread what you said saste sorry [20:36] <saste> yes but reading the docs it is not clear at all [20:36] <ubitux> i though you meant picking the stream [20:36] <wm4> saste: at least utf-16 doesn't work [20:36] <wm4> everything else sort of works [20:36] <wm4> but nicolas wants automagic demuxer level non-working charset detection [20:36] <wm4> and wrote an utterly broken patch which was supposed to handle this [20:37] <saste> was that integrated or what? [20:37] <wm4> no [20:39] <saste> but... can I set the input text encoding? will it be converted to sane UTF-8 which can then be rendered correctly? [20:41] <ubitux> yes [20:41] <ubitux> <@saste> ubitux, sub_chardec? // subtitles charset encoding, it's the option to specify it for the input [20:42] <saste> ubitux, what happens if libiconv was not linked? [20:42] <ubitux> it will convert from this charset to utf-8 [20:42] <ubitux> it won't work [20:42] <saste> uhm i guess we need to extend the docs in every case [20:50] <cone-682> ffmpeg.git 03Michael Niedermayer 07master:76dad833e96c: avformat/asfdec: remove duplicated packet_segments reset [20:50] <cone-682> ffmpeg.git 03Alberto Delmás 07master:edf7d15eb04f: avformat/asfdec: reset packet_time_start when asf_read_frame_header() failed [20:50] <cone-682> ffmpeg.git 03Michael Niedermayer 07master:e78d0381874f: avformat/asfdec: ignore packet_segments [21:45] <wm4> so, what is it what libavformat outputs as PTS values for avi when genpts is disabled? [23:03] <BBB> ubitux: ok threads=2 doesn't pass fate yet (a few off by ones, likely loopfilter offset not exact in oneof my calculations) but it works mostly otherwise... I can upload for some first round of review or leave it local, let me know [23:33] <cone-682> ffmpeg.git 03Derek Buitenhuis 07master:dedfa00107db: build: Import makedef script from c99-to-c89 [23:33] <cone-682> ffmpeg.git 03Michael Niedermayer 07master:988bda8a691b: Merge remote-tracking branch 'qatar/master' [00:00] --- Mon Nov 25 2013

1 0

ffmpeg.log.20131124
by burek 25 Nov '13

25 Nov '13

[06:00] <matador007> Hmm [10:37] <Videogamer555> I've got a problem with FFMPEG. I'm trying to convert 10 single BMP frames into a ten second video clip at 30fps. [10:39] <Videogamer555> The idea is that it will duplicate each frame 30 times so that it will run at a standard 30fps, but still last a whole 10 seconds (instead of 1/3rd of a second as would happen if you played 10 frames at 30fps). [10:40] <Videogamer555> My input are raw image data (BMP files) and likewise the output video file should be a raw BGR24 AVI file. [10:41] <Videogamer555> Each frame is labeled fx.bmp where the f is litteral, x is a number from 0 to 9, so the frames are f0.bmp to f9.bmp [10:41] <Videogamer555> My command line is ffmpeg.exe -f image2 -r 1 -i f%%01d.bmp -pix_fmt bgr24 -f avi -vcodec rawvideo -r 30 video.avi [10:41] <Videogamer555> -f image2 tells it that the input will be images [10:42] <Videogamer555> -r 1 tells it that it should consider the input frames to be at a framrate of 1fps. [10:43] <Videogamer555> -i f%%01d.bmp means the filename starts with a literal f letter, %% is to a batch file the same as % is to directly typing in the command line, and 0 is padding char and 1d means it is one digit and .bmp is literal. [10:44] <viric> Videogamer555: the manpage has an example for that, isn't it? [10:44] <Videogamer555> Then the output pixel format is specified, the output file format and output codec being raw image data, and the intended playback rate is 30fps. [10:44] <Videogamer555> BUt there's one problem. [10:44] <Videogamer555> It doesn't work. [10:45] <Videogamer555> It SHOULD duplicate the frames as needed, but it doesn't. [10:45] <Videogamer555> Instead it uses duplicate AVI index entries to refer to the same frame, as needed. [10:45] <Videogamer555> But Windows Media Player doesn't recognize this technique. [10:45] <Videogamer555> And it expects one frame for each index in the AVI file. [10:46] <Videogamer555> So it refuses to play it, though VLC player plays it fine. [10:46] <Videogamer555> Is there a way to force FFMPEG to produce duplicate frames, and NOT just duplicate index entries? [10:46] <viric> ah no idea [10:47] <beastd> Videogamer555: what happens if you use http://ffmpeg.org/ffmpeg-all.html#fps-1 [10:48] <Videogamer555> Virtualdub works correctly using this technique, and as far a I know it uses FFMPEG as the engine behind it all. But FFMPEG is a bulky program that has tons of features that I'm not using, with lots of buttons, and a simple command line in a bat file is much nicer and smaller for such a simple task. [10:49] <Videogamer555> Is this "fps" command a filter name, or a new direct command? [10:50] <beastd> Videogamer555: it is a filter name. you could use it instead of the -r at the output file likw with -vf fps=fps=30 [10:50] <Videogamer555> I meant VDUB is a bit bulky, but FFMPEG is smaller so is more desirable. [10:51] <Videogamer555> By the way why should I have to use a filter, if there is already a native FFMPEG command? Seems like the native command is brokern. [10:51] <Videogamer555> *broken. [10:51] <Videogamer555> Also isn't the proper filter command -vf fps=30 ? [10:52] <Videogamer555> Why did you have it like -vf fps=fps=30 with the fps= in there twice? [10:54] <Videogamer555> Seems like the output is still incompatible with WMP even though I'm now using the filter (though now the frames are being properly duplicated). [10:55] <Videogamer555> Is it a known problem that FFMPEG's output is incompatible with Windows XP's version of WMPlayer? I think it worked fine in Windows 7 WMPlayer, but now I'm using a WinXP comp and there's a problem. What's going on. [10:55] <Videogamer555> ? [10:58] <Videogamer555> And still a bug with getting the last frame right. It doesn't duplicate the last of the 10 frames, so the last frame flashes on the screen for 1/30th of a second, even in VLC player. I don't know who makes FFMPEG, but it seems there program is full of bugs, especially bugs near end of video (last frame errors). [11:04] <beastd> I was away for 10 minutes and now Videogamer555 is gone. [11:11] <relaxed> beastd: "Ain't nobody got time for that" [11:14] <beastd> :9 [11:14] <beastd> :) [14:02] <cian1500ww> Hi guys, I'm having problems killing an ffmpeg process invoked with the python subprocess module. When I kill from the process from the command line I get the following output: http://paste.ubuntu.com/6468480/ but when I kill it from with python with os.kill() I get the following output: http://paste.ubuntu.com/6468477/ It doesn't exit cleanly and leaves behind a corrupt video file. Any ideas why this [14:02] <cian1500ww> happening? [14:04] <cian1500ww> So, os.kill(ffmpeg.pid) gives me: http://paste.ubuntu.com/6468480/ where as "$ kill ffmpeg.pid" gives me: http://paste.ubuntu.com/6468477/ [14:15] <Samus_Aran> anyone know how timestamps work if you cut a segment from a video, then apply a filter like fade in. will the fade in be applied to the original whole video length, or to the cut segment? [19:17] <CaptainAmerica> hi [19:18] <CaptainAmerica> is it there a way to use opengl game as a live source ? [19:18] <klaxa> i think there was a project aiming exactly at that [19:18] <klaxa> it wasn't ffmpeg though [19:19] <CaptainAmerica> oh... no i wanted to do it with ffmeg i thought may some plugin was available [19:20] <sacarasc> Does X capturing not work for it? [19:20] <klaxa> you can use x11grab to gram from X [19:20] <klaxa> yeah [19:22] <CaptainAmerica> x11grab is a ffmpeg plugin ? [19:22] <klaxa> it's an input format [19:23] <CaptainAmerica> hmmm thanks i'll try to find some info about it [19:23] <klaxa> CaptainAmerica: https://its.ffmpeg.org/wiki/How%20to%20grab%20the%20desktop%20%28screen%29%… [19:23] <klaxa> args [19:28] <ss_haze> hello everyone using ffmpeg [19:29] <ss_haze> ffmpeg -i file.mov -ab 56 -ar 44100 -b 200 -r 15 -s 1280x720 -f flv file.flv [19:29] <ss_haze> I'm using this [19:29] <ss_haze> but it gives low res [19:29] <ss_haze> how do I get best quality convert [19:29] <ss_haze> sacarasc, I'm doing this via php [19:30] <ss_haze> should I dump [19:30] <sacarasc> You should run the command and give the output! [19:30] <ss_haze> can I just keep orginal framerate quality and stuff [19:34] <klaxa> quality is subjective [19:34] <sacarasc> So, it's not about resolution, but about quality? [19:35] <sacarasc> Use a better coded. [19:35] <sacarasc> *codec [19:35] <sacarasc> Use a higher than 200 bits per second bitrate. [19:35] <sacarasc> (If you don't have it as 200k, it will be just 200.) [19:37] <ss_haze> res could also stay the same [19:37] <ss_haze> I just need other format for h264 vid to go in firefox [19:37] <klaxa> vp8 in webm [19:37] <ss_haze> yes [19:37] <klaxa> ffmpeg -i video.mkv out.webm [19:38] <klaxa> that should set everything you need [19:38] <sacarasc> I thought firefox did H264 these days, at least on Windows? [19:38] <klaxa> since webm is so restricted [20:00] <bio-tty> is there a program like sox, that can dump the filter it has designed from my specification? [20:00] <bio-tty> let's say i provide parameters for sox to apply a highpass filter. and then i want the A array for a FIR filter, that i can import in another tool. [20:08] <ss_haze> this does nothing [20:08] <ss_haze> ffmpeg -i ".$file_path." -vcodec copy -acodec copy -y webm ".$file_path2." [20:09] <klaxa> no no no [20:09] <klaxa> don't copy the audio and video codec [20:09] <LithosLaptop2> if the source doesn't contain Vorbis/Opus + VP8/VP9 video then it wont work [20:23] <ss_haze> ffmpeg -i ".$file_path." ".$file_path3." [20:23] <ss_haze> this gives me corrupt file [20:23] <ss_haze> ffmpeg -i ".$file_path." ".$file_path2." and this gives webm file with bad quality [20:28] <ss_haze> .flv is corrupt [20:28] <ss_haze> and .webm is bad [20:28] <ss_haze> so why [20:28] <ss_haze> ? [20:29] <klaxa> paste ffmpeg --version [20:29] <klaxa> and you can crank up the quantiziers for webm [20:30] <klaxa> or rather vp8/vp9 [20:34] <lvella> I've read somewhere that codec rv40 is similar to h264, so I am wondering, wouldn't it be possible transform a rv40 stream into a h264 stream on the fly, to take advantage of h264 decoding hardware? [20:35] <klaxa> i doubt it [20:35] <klaxa> windows video codec 9 is similar to h264 too afaik [20:35] <klaxa> vp8 is "similar" too [20:35] <klaxa> you could re-encode on the fly [20:36] <klaxa> depending on the video you will need quite a powerful cpu though [20:36] <klaxa> but then you can just use the cpu to decode [20:37] <lvella> the device I want to play it has a very weak CPU, but has also a x264 hardware decoder [20:38] <klaxa> *h264 [20:38] <ss_haze> 0.6.0-svn [20:39] <ss_haze> ffmpeg version 0.8.9-4:0.8.9-0ubuntu0.12.04.1 [20:39] <klaxa> oh... ogd... [20:39] <klaxa> *god [20:40] <klaxa> that's old [20:43] <ss_haze> how do I get newer \ [20:43] <ss_haze> I use ubuntu LTS [20:43] <klaxa> compile from source or get a static build [20:43] <klaxa> or don't use ubuntu LTS [20:44] <klaxa> but i guess that's out of question [20:44] <ss_haze> why would ffmpeg -i ".$file_path." ".$file_path3." [20:44] <ss_haze> give bad output [20:44] <ss_haze> anyway [20:45] <klaxa> because we don't even know what those variables expand to [20:45] <klaxa> the filename ending of the output parameter determines what codecs are used by default [20:46] <ss_haze> file paths [20:46] <ss_haze> images/video/randomnumber.mov [20:46] <ss_haze> images/video/randomnumber.webm [20:47] <ss_haze> atleast [20:47] <ss_haze> ffmpeg -y -i ".$file_path." -vframes 1 -ss 00:01:60 -an -vcodec png -f rawvideo -s 1280x720 ".$png_path4." [20:47] <klaxa> it will be a) because your ffmpeg is old and 2) you should specify more parameters determining quality, e.g. -ab 96k -vb 700k or something [20:47] <ss_haze> this gives screenshot [20:48] <ss_haze> then give me arguments for best quality [20:48] <ss_haze> flv is corrupted and contains no data [20:48] <ss_haze> omg [20:50] <klaxa> you should seriously update your ffmpeg [20:51] <ss_haze> repo [20:51] <ss_haze> pls [20:52] <ss_haze> ppa:jon-severinsson/ffmpeg [20:59] <ss_haze> ffmpeg version 0.10.9-7:0.10.9-1~precise1 [20:59] <ss_haze> now I have [21:02] <ss_haze> webm still is bad [21:02] <ss_haze> and flv contains no stream [21:15] <ss_haze> http://paste.ubuntu.com/6470488/ [21:15] <ss_haze> as you can see [21:21] <ss_haze> https://phpacademy.org/topics/convert-uploaded-videos-to-flash-and-webm-vid… [21:21] <ss_haze> ok here is the full post [21:21] <ss_haze> if anybody wants to check full code [21:22] <ss_haze> on this [21:48] <ss_haze> so [21:48] <ss_haze> nobody knows why it happens like that? [21:50] <ss_haze> http://paste.ubuntu.com/6470676/ [21:50] <ss_haze> this what happens in terminal [21:53] <ss_haze> http://paste.ubuntu.com/6470687/ [21:53] <ss_haze> this is what happens with webm convertation [22:13] <ss_haze> I got something with adding some arguments in that line [22:13] <ss_haze> flv still in making [23:58] <cbsrobot> ss_haze: if you want to encore to webm consider reading: https://trac.ffmpeg.org/wiki/vpxEncodingGuide [23:59] <ss_haze> cbsrobot, I already got trought my problem [23:59] <ss_haze> thanks anyway [23:59] <cbsrobot> ok, and flv nowadays supports h264 in flv [00:00] --- Mon Nov 25 2013

1 0

ffmpeg-devel.log.20131123
by burek 24 Nov '13

24 Nov '13

[01:18] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:bd8d28e2d271: avcodec/hnm4video: check dimensions for validity [01:18] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:5c4aa72b75c1: avformat/hnm: check chunk_size == 0 [01:18] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:ffe31c654d0e: avcodec/hnm4video: check writeoffset in decode_interframe_v4a() [01:28] <llogan> how can i get access to files in upload.ffmpeg.org? [01:33] <BBB> hah it compiles [01:33] <BBB> that's about time [01:33] <BBB> ofc it crashes, but that's fixable [01:39] <beastd> BBB: congrats! keep on going :) [03:01] <Compn> hmmm llogan [03:01] <Compn> i thought i sent him infos [09:58] <cone-821> ffmpeg.git 03Reimar Döffinger 07master:97a0bad87c8d: Add --enable-rpath option to add -Wl,-rpath to pkg-config files. [12:18] <cone-821> ffmpeg.git 03Diego Biurrun 07master:c16bfb147df8: swscale: x86: Consistently use lowercase function name suffixes [12:18] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:8733b363ac3b: Merge commit 'c16bfb147df8a9d350e8a0dbc01937b78faf5949' [13:29] <ubitux> i don't understand this vdpau thing& [13:30] <ubitux> why isn't it an output device like sdl & xv? [13:30] <ubitux> also, what's the use case? [13:31] <nevcairiel> what vdpau thing [13:31] <ubitux> what has just been comitted to avconv [13:31] <nevcairiel> oh that [13:31] <ubitux> vdpau "decoding" [13:31] <ubitux> but with x11 stuff [13:31] <nevcairiel> isnt that just an implementation of the hwaccel [13:32] <ubitux> there are 2 things about vdpau; decoding, and presentation, right? [13:32] <nevcairiel> primary motiviation was being able to test hwaccels [13:32] <nevcairiel> no idea [13:32] <ubitux> this one seems to be about presentation [13:33] <ubitux> well i don't even get how it works, so i'll wait for the merge [13:34] <nevcairiel> i dont know stuff about vdpau, but it looks like it does about the same things you would do when you implemented dxva hwaccel decoding [13:35] <ubitux> it looks like something that belongs in ffplay to me but well [13:36] <nevcairiel> such APIs usually require an X session to function, which is where the X11 stuff comes in i guess [13:36] <ubitux> we already have some accelerated *decoding* through the <codec>_<accel> [13:36] <ubitux> ok [13:36] <nevcairiel> those codecs are ugly hacks and shouldnt exist [13:36] <ubitux> ah, they're meant to be replaced by this new thing? [13:37] <nevcairiel> i dunno, since libav doesnt really have th em [13:37] <ubitux> they do [13:37] <ubitux> at least they show up with ./configure --list-hwaccels [13:37] <nevcairiel> and what was added here just makes use of those hwaccels [13:38] <nevcairiel> since you cant just enable it without user-app code to handle it [13:38] <nevcairiel> or well, of one hwaccel [13:39] <nevcairiel> which is why the hwaccels are generally never tested properly [13:39] <nevcairiel> since no native ffmpeg/libav tool supported them [13:41] <ubitux> mmh [13:42] <cone-821> ffmpeg.git 03Tim Walker 07master:b53285462263: ac3: implement request_channel_layout. [13:42] <iive> one of hwaccel work like parsers. the applications links to x11, allocates buffers, the avcodec just parses packets and extrancts the relevant bitstreams. [13:42] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:2e5780a53f43: Merge commit 'b53285462263ef8a795f0e289abd5799b4c57652' [13:42] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:2cbf27b08a49: libavcodec/ac3dec: fix channel_layout [13:42] <ubitux> indeed, it seems i can't naively do ffmpeg -c:v h264_vdpau -i foobar.mp4 -f null - [13:43] <iive> other hwaccel (vaapi i think) do the allocation on their own, this however means that avcodec should link to X and call X functions. [13:43] <nevcairiel> i thought that might still work, since michael didnt merge the removal of the old vdpau decoders [13:43] <ubitux> i have some decoding errors here [13:43] <ubitux> "no frame!" [13:43] <ubitux> "decode_slice_header error" [13:43] <nevcairiel> hm, i dunno, no idea if it needs user app code as well [13:43] <ubitux> and various other errors following [13:44] <nevcairiel> there are others that can work out of the box [13:44] <iive> now, some of the hwaccels can do the decoding on card, then read it back to the system memory. [13:44] <nevcairiel> vda i think has one [13:44] <iive> some don't. [13:44] <nevcairiel> but they really shouldnt exist [13:44] <ubitux> all that hwaccel stuff looks quite messy :) [13:44] <nevcairiel> either the user app should make use of the AVHWAccel, or someone should propose a HWAccel v2 that takes care of all plumbing as well [13:44] <ubitux> btw, somehow unrelated, how hard is the move from sdl to sdl2? [13:45] <ubitux> (wondering about our ffplay) [13:46] <iive> i though the plan is putting the X functions into libavdevice, It already handles X functions and it could be provided as default allocation/decoding for the applications. [13:46] <ubitux> http://wiki.libsdl.org/MigrationGuide mmh [13:46] <wm4> ubitux: yeah that stuff was supposed to test hwaccel [13:47] <wm4> ubitux: and for testing it's probably also better to actually read the decoded data back to memory [13:47] <wm4> so you can verify the results [13:47] <wm4> hacking vdpau display into ffplay would probably be half a nightmare [13:48] <wm4> and the old pseudo decoders like vdpau_h264 were indeed removed from Libav, but not from ffmpeg [13:48] <wm4> no idea why [13:48] <wm4> they're redundant [13:48] <ubitux> i see them in libav [13:48] <wm4> they just have a slightly different API [13:48] <wm4> where [13:48] <ubitux> maybe it was an old checkout, just a sec [13:48] <wm4> hm or was it h264_vdpau [13:48] <iive> well, in case you want to have vdpau decoding that outputs yuv420 raw image, how are you going to do it? [13:49] <ubitux> wm4: 13:37:38 <@ubitux> at least they show up with ./configure --list-hwaccels [13:49] <wm4> iive: do the same thing as avconv just did [13:49] <wm4> iive: and in general, this is completely useless and slow [13:49] <wm4> for video conversion uses I mean [13:49] <iive> ?? [13:49] <wm4> ubitux: ok, hwaccel != pseudo decoder [13:49] <wm4> as in AVCodec [13:49] <wm4> iive: ??? [13:49] <iive> please explain. [13:50] <wm4> what's there to explain [13:50] <wm4> it's just slow [13:50] <wm4> slower than software decoding, usually [13:51] <iive> well, it is not done by the cpu, so more cpu for the encoder :P [13:51] <cone-821> ffmpeg.git 03Tim Walker 07master:d4df02131b55: ac3dec: Remove write-only channel_layout field from AC3DecodeContext [13:51] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:94194bdcd7bf: Merge commit 'd4df02131b5522a99a4e6035368484e809706ed5' [13:51] <wm4> iive: it also lets the cpu wait [13:52] <wm4> well, not sure, maybe ffmpeg has some multithreading weirdness so that this won't matter [13:52] <wm4> but all in all supporting readback seems to be rather questionable [13:52] <wm4> so it's fine if this is not natively supported by libavcodec [13:53] <iive> well, there is no reason for the readback to be slow. Unless the raw image is in nv12 form in the card and the drivers do naive nv12->yv12 conversion. [13:53] <iive> pcie bandwidth is big enough in both directions, afaik [13:54] <wm4> there are various reasons why this would be slow [13:54] <wm4> including hw decoders made for realtime use, not for being as fast as possible [13:54] <wm4> +being [13:54] <wm4> but yeah, this exposed pathetic libswscale speed for nv12->yv12 [13:55] <ubitux> this should be fixed [13:55] <wm4> patches welcome [13:55] <ubitux> no i mean, it's fixed [13:55] <iive> as I said, you don't need it to be fast, in order to be useful. There are just too many presumptions based on the current perks, that could be easily improved. [13:55] <wm4> didn't elenril complain it's still slow? [13:55] <iive> i though michael fixed it. [13:55] <ubitux> wm4: dunno [13:55] <iive> the swscale conversion. I remember some commits for nv12/21 [13:56] <wm4> also I remember mentioning this idea (testing hwaccel through readback) with reimar on the mailing list, and he considered it not useful for multiple reasons [13:56] <wm4> ubitux, iive: yes AFAIK elenril used these patches [13:57] <wm4> iive: when we implemented proper vda support (native display instead of readback via the ffmpeg "decoder") we actually observed 2-2.5x reduction in CPU usage [13:57] <wm4> I mean, implemented it in mpv [13:57] <wm4> ffmpeg has a proper vda hwaccel [13:59] <iive> once again. this is not theoretical limitation. [14:01] <iive> pcie bandwidth should have same in both directions. This means that it should take the same cpu utilization to upload yv12 image, as it is to read a raw image to the card. [14:01] <wm4> I don't think it's that simple [14:01] <iive> if there is such huge slowdown, then it is probably driver issue, that tries a naive conversion. [14:01] <wm4> GPU memory is a weird thing [14:01] <wm4> for example, I'm pretty sure vdpau/nvidia stores video internally as separate fields, and probably even in a tiled way [14:02] <iive> this could be improved by the driver. [14:02] <iive> well... then swscale would support tiled formats too. [14:02] <pigoz> wm4: iirc ffmpeg's vda decoder also does a memcpy [14:02] <pigoz> so readback + memcpy [14:04] <iive> look. it is ok to don't use a feature that is slow. [14:05] <iive> it is not OK to design an API in a way that doesn't allow that feature at all. especially when there is no theoretical reason for it to be slow. (Some features are slow on theory too...). [14:05] <wm4> what if it's slow in practice [14:06] <iive> then, find out why it is slow in practice. [14:08] <iive> sometimes it is slow, because nobody uses it. if you don't use it, it would never be optimized. [14:08] <wm4> sigh [14:09] <wm4> nobody would introduce such complicated APIs like they did with hardware decoding if the easier way (i.e. readback) would have been just as fast [14:09] <wm4> but it's designed this way because shuffling memory from the GPU to the CPU is inherently slow [14:10] <iive> it is not just as fast. because in the best case it involves 2 memcpy. one from the card and one to the card. [14:10] <iive> it doesn't mean it is not useful. [14:11] <pigoz> iive: it is slow because whoever contributed to mplayer's is misguided and just wants their gui to work with shitty mmap. since they need readback anyway, they thought it was a good idea. [14:11] <pigoz> in practice it's so wasteful that software decoding is almost as fast! [14:40] <cone-821> ffmpeg.git 03Anton Khirnov 07master:07fd0a221928: avconv: add infrastructure for using hwaccels [14:40] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:62e10c375968: Merge commit '07fd0a22192805d56c635eb294dc26b0a54ae325' [14:52] <cone-821> ffmpeg.git 03Anton Khirnov 07master:7671dd7cd7d5: avconv: add support for VDPAU decoding [14:53] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:3e641b4842b8: Merge commit '7671dd7cd7d51bbd637cc46d8f104a141bc355ea' [15:00] <cone-821> ffmpeg.git 03Alexandra Khirnova 07master:6f270da61b8c: libschroedingerenc: do not assert on values from external libraries [15:00] <cone-821> ffmpeg.git 03Michael Niedermayer 07master:f63ee2aa14ec: Merge remote-tracking branch 'qatar/master' [17:05] <ubitux> meh #2835 is fun [17:13] <ubitux> -hwaccel none 530 fps [17:13] <ubitux> -hwaccel vdpau 50 fps [17:13] <ubitux> fun [17:21] <ubitux> it crashes if hwaccel can not be initialized [17:24] <wm4> anton already has a patch for this [17:30] <ubitux> it's not an assert [17:31] <ubitux> it doesn't happen all the time (threading related) [17:32] <ubitux> http://pastie.org/pastes/8503519/text [17:33] <nevcairiel> its possible threading with hwaccel is broken in ffmpeg, i dont think it was ever tested [17:34] <ubitux> mmh? [17:35] <nevcairiel> the real question however is, why is exit_program being called from a frame worker thread? :p [17:35] <nevcairiel> that seems like bad karma [17:38] <ubitux> it's hard to reproduce with valgrind [17:38] <ubitux> it happens with libav as well [17:43] <wm4> nevcairiel: supposedly, vlc uses threading + hwaccel just fine [17:44] <wm4> mplayer also tries to do, but its code is literally full of hacks, including comments that curse libavcodec's threading behavior [17:45] <nevcairiel> comments which are probably completely out of date now [17:45] <wm4> likely [17:59] <cone-821> ffmpeg.git 03James Zern 07master:6819eaf31bf8: libvpxdec: set CODEC_CAP_DR1 for vp9 [17:59] <cone-821> ffmpeg.git 03James Zern 07master:34e32d646413: libvpxenc: update cpu-used default [18:22] <rexbron> Does ffmpeg copy over all metadata from a Broadcase Wave file when trimming? Timecode and Frame Rate from a Sound Devices 664T got stripped out. It show up in ffprobe but -codec:a copy only seems to carry over some of it. Would uploading a sample of the input and output to the tracker be helpful? [18:27] <JEEB> there was IIRC a way to force ffmpeg to copy over all metadata as well, codec:a copy should have copied all of the in-band actual audio data [18:30] <rexbron> JEEB: I'll file a bug on the tracker [18:31] <JEEB> try the full metadata copy at first [18:31] <JEEB> since -c/codec:a doesn't really touch that [18:32] <rexbron> JEEB: I'm not familiar with how to do that [18:33] <JEEB> -map_metadata <number of the input> [18:34] <JEEB> as far as I can see [18:36] <rexbron> JEEB: Same results [18:36] <JEEB> k [18:36] <rexbron> I wonder if it is because the wav muxer doesn't support the writting of those fields yet [18:37] <JEEB> anyways, search for similar issues on trac, and if there's none feel free to report it with a sample [18:37] <JEEB> possibly [18:38] <rexbron> hmm, well it shows up in the output metadata of the encoding ffmpeg command, but ffprobe doesn't see it and neither does Davinci Resolve [18:42] <rexbron> ffprobe also sees the metadata in the original file [18:46] <rexbron> what is the ffmpeg ftp server for samples? Trac limits attachments to 2.5mb [18:50] <wm4> apropos wav, is ac3 in wav standard? [18:50] <wm4> especially if it uses the same format tag as s16? [19:05] <kierank> yes [19:05] <kierank> it's designed to go over spdif or aes3 [19:05] <kierank> neither of those cables have any concept of data format [19:05] <kierank> they just send out stereo bytes [19:05] <kierank> s/bytes/pairs [19:06] <JEEB> btw, how does lavf/lavc handle possible spdif content muxed into a PCM audio track? [19:07] <wm4> kierank: interesting and disgusting [19:07] <JEEB> can I just push it out of the demuxer as PCM, or do I have to do something special? [19:07] <wm4> yes that would be interesting to know [19:07] <kierank> should work as pcm [19:07] <JEEB> ok [19:07] <kierank> alignment is important though [19:08] <JEEB> then I can pretty much rewrite the earthsoft dv demuxer stuff compared to the Japanese guy's patch [19:08] <JEEB> because he had some really funky checks in the demuxer for various spdif'd stuff [19:08] <JEEB> (IIRC unrelated to alignment) [19:09] <kierank> alignment is effectively the pts [19:09] <JEEB> alrighty [19:11] <JEEB> oh right, the demuxer tries to extract it I think... :| not something I'd do in the demuxer to be honest if lavc in general can handle it [19:11] <JEEB> /* search for IEC 61937 Burst-preamble */ [19:11] <JEEB> etc. [19:12] <wm4> well, the demuxer has to signal the correct codec [19:12] <wm4> because on the decoder side, it's too late for that [19:13] <JEEB> ok, so "should work as pcm" doesn't mean that [19:13] <wm4> AFAIK not, if you're talking about what AVStream->codec will identify [19:59] <kierank> JEEB: yes the burst preamble is what signals the codec [19:59] <kierank> lavc can't deal with it [19:59] <JEEB> ok [21:07] <cone-984> ffmpeg.git 03Michael Niedermayer 07master:321b33876262: avcodec/hnm4video: allocate frame only when theres a coded frame [21:07] <ubitux> HOSTCC doc/print_options.o [21:07] <ubitux> HOSTCC? really? oO [21:14] <ubitux> BBB: since the dc-only patch, most of the time is spent in 32x32 and the loop filters [21:14] <ubitux> they really are slow [21:14] <ubitux> i'm almost tempted to look at them :p [21:23] <ubitux> BBB: i'm going to start on lf instead of idct 16 [21:43] <ubitux> BBB: http://b.pkh.me/0001-avcodec-vp9dsp-remove-unused-stride-parameter-in-loo.p… opinion? [21:55] <wm4> why are people trying to coerce a muxer API into a video player output API [21:55] <wm4> his deserves the "fucking retarded" label [21:55] <wm4> +this [21:57] <Plorkyeran> playing and muxing are conceptually vaguely similar things [21:57] <Plorkyeran> and programmers love reusing abtractions [22:02] <BBB> ubitux: sure [22:03] <BBB> ubitux: and yes 32x32 I know [22:03] <ubitux> BBB: so what's the trick with lf? [22:03] <ubitux> i'm looking at loop_filter_h_4_8() [22:03] <BBB> ubitux: to make things slightly easier for us to develop step-by-step, I was considering the following: have a (non-vp9dsp) set of function ptr tables that take a VP9DSPContext argument, and then have them select which specialization to take [22:03] <ubitux> the c version looks like this: http://pastie.org/8503989 [22:04] <BBB> the default implementation for dc-only would be your specialcase code, and for all other cases the current c base full versions [22:04] <BBB> but then we could easily specialize a 2x2 32x32 or 4x4 16x16 without needing to dig our eyes out to complete all assembly before it can be committed [22:04] <BBB> that would help e.g. with writing a super-fast ssse3 dc-only for all [22:04] <BBB> that would speed up 16x16 and 32x32 by a lot also [22:05] <BBB> and a 2x2 and 4x4 does cover most practical 32x32 cases [22:05] <BBB> we can leave the rest as C then [22:05] <BBB> wdyt? [22:05] <BBB> the trick with lf is: do the vertical filter (horizontal edge between a top/bottom block) first [22:05] <ubitux> will the dc only really benefit from the asm versions? [22:06] <BBB> no they all will [22:06] <BBB> but the dc is easier to write [22:06] <BBB> I'm trying to get stuff out faster rather than slower, and adjust code/development to that end [22:06] <BBB> then the filter: you'll notice there's 8px 4/8/16wd versions [22:06] <ubitux> main benefit of this would be to ease the writing of those functions [22:07] <ubitux> so i'm not against [22:07] <BBB> these are not called often but meant for mmx or so [22:07] <BBB> then there's 16px functions, same idea [22:07] <BBB> they are 16wd, or a mix2 of 4/4 or 8/8 or 4/8 or 8/4 wd [22:07] <ubitux> right [22:07] <BBB> that's because edges between these types of lfs only have a length of 8px [22:08] <BBB> so we merge 2 so we can do sse2/ssse3 (16byte) registers [22:08] <BBB> do everything in bytes, obviously [22:08] <BBB> ignore 8px maybe, focus on 16px first (maybe 4wd) [22:08] <BBB> and you'll see it's not hard to do it without stack on x86-64 [22:09] <BBB> 8wd is basically 'do some threshold trick to see whether we do 8wd or 4wd loopfilter' (i.e. 4wd is a strict subset of 8wd) [22:09] <BBB> runtime selected [22:10] <ubitux> ETOOMUCHINFO [22:10] <ubitux> just a sec [22:10] <BBB> oh [22:10] <BBB> well, start with 4/4wd 16px [22:10] <BBB> it's easy [22:10] <BBB> or, well, about as easy as a loopfilter will ever get [22:11] <ubitux> i was ignoring the 16 and mix2 so far [22:11] <ubitux> since 16 was calling 8 [22:11] <BBB> that's just a c'ism [22:11] <BBB> ignore c, it's stupid [22:11] <ubitux> mmh [22:12] <BBB> I prepared it that way for asm purposes [22:12] <BBB> sse2/ssse3 is 16bytes right [22:12] <BBB> so we want to do 16 bytes (if 1 byte is 1 pixel) per call to the simd function [22:12] <BBB> that's why we mix 2 [22:12] <ubitux> but, the 8 versions are supposed to be called as well, right? [22:12] <BBB> yes, but not as often [22:12] <BBB> look at the backtrace of the callers [22:13] <ubitux> oh indeed [22:13] <BBB> most of the time, the backtrace of 8 is 16 [22:13] <BBB> once in a while, it's mix2 [22:13] <BBB> very rarely is it called in and by itself [22:13] <BBB> that's expected, it makes sense for non-random noise content [22:14] <BBB> (non-'random noise') [22:14] <ubitux> ok [22:14] <ubitux> al'right, so i need to focus on 16 directly [22:16] <ubitux> 22:08:19 <@BBB> do everything in bytes, obviously // what do you mean? no simd? [22:16] <ubitux> oO [22:16] <BBB> byte-wise simd [22:16] <BBB> i.e. use all byte instructions [22:16] <BBB> paddb, paddusb, etc. [22:16] <ubitux> ah, ok [22:17] <ubitux> that's cool if i can do that :) [22:17] <BBB> that way you can do it loopless [22:21] <cone-984> ffmpeg.git 03Clément BSsch 07master:bea93944653f: avcodec/vp9dsp: remove unused stride parameter in loop_filter(). [22:21] <ubitux> ok [22:22] <ubitux> let's try this then [22:22] <BBB> \o/ [22:22] <BBB> I have an almost-working patch for mt [22:22] <BBB> that is, it works in single-threaded mode [22:22] <ubitux> haha [22:22] <BBB> (I know, that sounds entirely useless) [22:22] <BBB> (but really, it's quite something IMO) [22:23] <ubitux> :) [22:30] <ubitux> BBB: v version will be calling h version with a transpose? [22:30] <ubitux> or they will be more [22:30] <ubitux> ? [22:31] <BBB> exactly right [22:31] <BBB> I don't know how we'll do a 16x16 transpose btw [22:31] <BBB> but we'll figure that out [22:31] <BBB> probably 2x16x8 or so [22:32] <BBB> or maybe imaginatively speaking it's not that hard, never thought much about it [22:52] <durandal_1707> gmake: *** No rule to make target ibavcodec/dct32_fixed.o'. Stop. [22:53] <durandal_1707> gmake: *** No rule to make target `libavcodec/dct32.c', needed by `libavcodec/dct32_fixed.o'. Stop. [22:55] <ubitux> durandal_1707: the dependency thing again [22:55] <ubitux> you need to make distclean / git clean -fdx [22:56] <ubitux> or just edit/drop the .d [22:59] <nevcairiel> I dont get why people dont just clean when they get such an error instead of complain [23:00] <durandal_1707> i dont get why people change stuff [23:02] <nevcairiel> we should totally stop developing, change is bad! [23:03] <durandal_1707> developing is not K&R [23:05] <ubitux> nevcairiel: re-running configure should be enough, but it doesn't work [23:05] <ubitux> those rename are a pita [23:06] <nevcairiel> configure doesnt generate d files, make does, but it fails at tracking changes to its own make files [23:08] <lukaszmluki> Hi, is Stefano online? [23:09] <ubitux> he left a few hours ago (nickname: saste) [23:09] <nevcairiel> he doesnt appear to be here right now [23:09] <lukaszmluki> maybe some else know... he mentioned "custom widget filter", do you know what it is? [23:10] <ubitux> which thread? [23:10] <lukaszmluki> Move ffplay engine to separate library, 7th post [23:12] <durandal_1707> ffprobe.c:348:15: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides] [23:17] <ubitux> lukaszmluki: i guess he just invented a name for this potential special purpose filter [23:18] <lukaszmluki> so it doesn't exist yet? :D [23:18] <ubitux> yes, it seems to be your job :) [23:19] <lukaszmluki> ok, i'll try to catch him tommorow to confirm that, but I greped and nothing similar to it found :] [23:19] <lukaszmluki> ok, thx [23:25] <cone-984> ffmpeg.git 03Paul B Mahol 07master:638d79a9d080: ffprobe: use designated initializer for AVClass [23:36] Action: BBB agrees with durandal_1707 [23:37] <BBB> I don't care about whether people do k&r or not, but please let's not call it development [23:37] <Daemon404> let's not call it k&r [23:37] <ubitux> let's not [23:37] <BBB> diego&r? [23:37] <ubitux> diego&luca&koda [23:44] <lukaszmluki> what is k&r? [23:57] <{V}> lukaszmluki, Kernighan and Ritchie probably. [00:00] --- Sun Nov 24 2013

1 0

ffmpeg.log.20131123
by burek 24 Nov '13

24 Nov '13

[03:55] <ensoe> ffmpeg -f alsa -ac 2 -i hw:0,0 -f x11grab -r 30 -s $(xwininfo -root | grep 'geometry' | awk '{print $2;}') -i :0.0 -acodec pcm_s16le -vcodec libx264 -preset ultrafast -crf 0 -threads 0 -y desktop0recording.avi [03:55] <ensoe> how would I have to adjust this to actually only capture a certain section of my screen? I'd like to be able to draw a frame where it should record. Can that be done? [08:40] <easyfab> I'd like to create a batch under windows with ffmpeg like this : http://pastebin.com/KLvgDgxC but with scale. [08:41] <easyfab> Is it possible to do something like : if iw > 720p do scale else don't ? [08:42] <easyfab> ih > 720p [08:44] <easyfab> So to scale only if the file iput height is > 720p ? [08:55] <ubitux> easyfab: -vf scale='max(iw,720):-1' ? [08:56] <ubitux> -vf "scale='max(iw,720)':-1" [08:56] <ubitux> actually, min() [09:12] <easyfab> ubitux: thanks min() is what I needed -> -vf scale="trunc(oh*a/2)*2:'min(ih,720)'" [18:19] <rexbron> Does anyone know how to get ffmpeg to copy over all metadata from a Broadcase Wave file when trimming. Timecode from a Sound Devices 664T got stripped out. It show up in ffprobe but -codec:a copy only seems to carry over some of it [19:21] <intracube> hi, does anyone know how to write custom metadata with ffmpeg/libx264? [19:22] <intracube> I'm trying to add some information that's not carried over from a set of video files when transcoding [19:22] <intracube> specifically adding 'Scan order' 'Top Field First' [19:22] <sacarasc> -metadata cheese="yes please" [19:22] <sacarasc> I think you have to do a -metadata for each piece you want to add. [19:23] <intracube> ah kewl, thanks sacarasc :) [19:24] <intracube> hmm, that doesn't seem to work [19:25] <intracube> does it need to be associated with a particular stream? [19:25] <intracube> (I'm looking at what mediainfo is reporting back) [19:39] <intracube> oh, so ffmpeg doesn't support all key=value options: http://multimedia.cx/eggs/supplying-ffmpeg-with-metadata/ [19:43] <saste> the muxer should complain in case of invalid metadata [19:43] <saste> i suppose it's easier to write a blog entry than a patch :) [19:44] <intracube> saste: it's failing silently [19:44] <intracube> and different containers support a different range of key=value pairs [19:45] <saste> intracube, patch/report welcome [19:45] <intracube> ;P [19:45] <intracube> well, I can report at least :) [19:46] <Logicgate> hey guys, if I was to read a video file via text to get the data (h264 encoded AAC mp4), what charset should I use not to lose any data [19:46] <Logicgate> Im basically trying to upload the file via an http protocol, reading the contents of the mp4 via php and ajaxing it over to an S3 bucket [19:46] <Logicgate> I seem to fail to find the right charset [19:49] <saste> Logicgate, why are you abusing HTTP to send data as text, in the first place? [19:55] <LithosLaptop> Logicgate: it doesn't have to be text [19:55] <LithosLaptop> HTTP can handle binary [19:56] <LithosLaptop> but if you MUST send it with text then all you have to do is Base64 the data as text [19:57] <LithosLaptop> -*Base64 encode [19:58] <LithosLaptop> on the other side just Base64 decode the text to get the binary data again [19:59] <LithosLaptop> charset won't matter [19:59] <LithosLaptop> ASCII will work [00:00] --- Sun Nov 24 2013

1 0

ffmpeg-devel.log.20131122
by burek 23 Nov '13

23 Nov '13

[01:37] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:7c98c834e0a2: avformat/avidec: also print position in print_tag() [01:37] <cone-670> ffmpeg.git 03gcocherel 07master:36658c978f5d: hevc : update hevc_ps.c [01:37] <cone-670> ffmpeg.git 03gcocherel 07master:fb7d70c1cd95: hevc : add hevc profile [02:36] <cone-670> ffmpeg.git 03Michael Niedermayer 07master:9cbe834dfd49: avformat/avidec: Skip duplicate strf chunks [09:08] <plepere> is there something to do for my asm to be able to compile for 32bit ? [09:09] <plepere> bacause when I try cross compiling, I get errors that my registers are 64-bit [09:12] <nevcairiel> do you use the q postfix? [09:13] <plepere> it doesn't ring a bell, so I guess not [09:13] <plepere> what is it ? [09:13] <nevcairiel> like r9q [09:13] <plepere> oh [09:13] <nevcairiel> because no quadword registers on 32-bit [09:13] <plepere> ok [09:14] <plepere> so I should replace all rX by rXq ? [09:14] <nevcairiel> no, you should not use q :) [09:14] <plepere> ok [09:14] <nevcairiel> also, 32-bit might not have enough registers [09:15] <wcpan_> hi, how could I 'discard' an AVPacket ? [09:16] <nevcairiel> you only get up to r6 on 32-bit, iirc [09:16] <plepere> well I do have a undefined symbol `r7' (first use) error. But I doubt that there are less than 8 registers [09:16] <plepere> ouch [09:16] <nevcairiel> 7 registers, plus the stack pointer [09:16] <plepere> how do I use my arguments then ? [09:16] <nevcairiel> from the stack [09:16] <plepere> ok [09:17] <nevcairiel> how many arguments does that function have? [09:17] <plepere> 9 [09:17] <wcpan_> i found that if i don't do avcodec_decode_* after av_read_frame, i'll receive like 'reference frame missing' error log [09:17] <nevcairiel> and you need to access all arguments in the asm? [09:18] <plepere> eventually, yes [09:18] <plepere> but for a simple case, I can need only use the first 6 [09:19] <nevcairiel> might need to get smart about the parameter usage then, and load them from the stack only when needed to save registers [09:20] <nevcairiel> sadly i'm not that experienced with such stack optimizations either [09:20] <plepere> ok [09:22] <plepere> but how do I put the arguments in the stack ? [09:23] <plepere> since cglobal puts the arguments in registers [09:24] <nevcairiel> all arguments are on the stack by default, cglobal only puts them in registers if you tell it to, so just tell it that you have less arguments then you really do, and it wont touch them, and you can do it manually [09:24] <plepere> ok [09:26] <plepere> so just to make sure : to access the arguments, I can only push/pop. [09:27] <nevcairiel> you should probably access the parameters directly via memory address, and not push/pop them [09:27] <nevcairiel> i believe the asm macros have some helpers for that [09:27] <nevcairiel> but i forgot how that worked [09:27] <plepere> ok, I'll dig in the x86util then [09:30] <plepere> thank you [09:31] <ubitux> mmh i'm using "strideq", "dstq", ... does that mean it won't work on 32? [09:31] <ubitux> (it seems to, so far) [09:32] <nevcairiel> maybe its smart and maps the q to native size [09:32] <nevcairiel> i dunno [09:49] <ubitux> michaelni: about the incoming doc examples build patchset from Diego, i'm assuming we can merge it; it will allow building them within FATE; though the Makefile should be kept as well as a demonstration for how to build them when using packages [09:49] <ubitux> (the Makefile = the one in doc/examples) [09:50] <ubitux> i'll update the examples/README when it's done [09:55] <clever> ubitux: got any time to help with my 264 issues? [09:55] <ubitux> i can try, but you know, i'm not familiar with what you are doing [09:55] <ubitux> but sure go ahead, ask the channel [09:55] <clever> the issue, is that ffmpeg is removing a header from the start of the h264 stream [09:56] <clever> i have managed to exract it from one file: http://pastebin.com/7LyarVYy [09:56] <clever> but the size of the header is different in each file, and the contents differ [09:56] <clever> so i'm not sure how to modify ffmpeg to give that header on demand [09:57] <ubitux> how large was the extradata already? [09:57] <clever> and until i can figure out what the data in it means, i cant easily see if the chunks of data i'm finding are valid [09:57] <clever> about 60 bytes [09:57] <ubitux> doesn't it contain the top content (and all the x264 encode comment is stripped)? [09:57] <clever> and inserting that at the start just gave a blank screen [09:57] <ubitux> did you compare the data? is the the same or unrelated? [09:57] <clever> it has some similar binary codes, but parts of it differ [09:57] <clever> several of the first bytes are different [09:58] <ubitux> what's your format? [09:58] <clever> let me put av_hex_dump back on [09:58] <clever> my format? [09:58] <ubitux> the container [09:58] <ubitux> mov/mp4? mts? [09:58] <clever> mkv [09:58] <clever> ubitux: http://www.auby.no/files/video_tests/h264_1080p_hp_4.1_40mbps_birds.mkv this file to be exact [09:58] <clever> thats where the header in the pastebin came from [09:59] <clever> if i hard-code ffmpeg to inject that header from a file, it works perfectly [09:59] <clever> but if i use extradata, i just get a black image [10:00] <clever> ubitux: http://pastebin.com/6XSvLrM3 this has the extradata bytes [10:01] <ubitux> add 0x00 0x00 at the beginning :-° [10:01] <clever> *tries* [10:01] <nevcairiel> that wont work [10:01] <nevcairiel> mkv uses different start codes [10:01] <ubitux> oh erm [10:02] <nevcairiel> mkv extradata usually has a 2 byte length code before every NAL [10:02] <nevcairiel> well in fact, mkv extradata is its own special format [10:02] <JEEB> matroska uses AVCc pretty much [10:02] <nevcairiel> the same as mp4 h264 extradata [10:02] <JEEB> yup [10:02] <clever> nevcairiel: looking at my last pastebin, lines 2 and 7, which one looks like mkv mangling? [10:03] <nevcairiel> there is no mangling [10:03] <nevcairiel> thats just how it works [10:03] <clever> why does the header start with 0x0000 then? [10:03] <clever> the 2 byte lenght code is 0 ?? [10:03] <nevcairiel> because mkv is different then raw video streams [10:03] <JEEB> grab a copy of 14496-15 for details :P [10:03] <clever> the omx decoder seems to function better with the raw video streams [10:04] <clever> JEEB: yeah, thats kinda what i need, to make sense of this binary souo [10:04] <clever> soup* [10:04] <nevcairiel> the 0x00000001 start code is replaced by a length code [10:04] <JEEB> matroska uses the same extradata as 14496-15 and the same idea of having length + contents of NAL in a packet [10:04] <JEEB> the length field's size is set in the extradata [10:04] <clever> nevcairiel: ah, i see the 4 byte code now, *looks more* [10:05] <clever> so the 4 byte 00 00 00 01 gets replaced by a 2 byte size? [10:05] <JEEB> uhh [10:05] <JEEB> no [10:05] <JEEB> it gets replaced by a length field of the size that's set in the extradata [10:05] <JEEB> as I said [10:05] <nevcairiel> its usually a 4 byte size, but that information is carried in extradata, except in extradata, there its always 2 [10:05] <clever> because the header in the other hexdump starts with 01 64 00 29 [10:05] <clever> ah [10:06] <nevcairiel> read the standard that describes mp4/mkv extradata [10:06] <JEEB> oh right, the size is set in the extradata [10:06] <clever> so the extradata starts with 0x01 0x64 as the length [10:06] <nevcairiel> no [10:06] <JEEB> clever, just read 14496-15 [10:06] <nevcairiel> read the standard that describes mp4/mkv extradata [10:06] <nevcairiel> its not pure h264 NALs [10:06] <JEEB> H.264 in Matroska copies the extradata format [10:06] <nevcairiel> it contains extra info [10:06] <JEEB> basically stop right here and now, and grab a copy of 14496-15 :P [10:07] <clever> i punched that into google, it gave me 14481 [10:07] <clever> silly built in calculator, lol [10:07] <nevcairiel> put iso in front [10:08] <clever> and is mkvextract doing anything special to convert that back?, why am i getting the 0x00 00 00 01 when i extract the video track? [10:08] <nevcairiel> raw video tracks are usually always annexb, so yes, it converts this back [10:08] <clever> ah [10:08] <clever> so its not that ffmpeg is stripping it out, but mkvextract converted it on me [10:09] <clever> and i'm a bit confused as to how omxplayer even works, because ive read its code, and its working perfectly fine with extradata [10:10] <clever> but if i use the extradata in ffmpeg, it doesnt [10:11] <clever> JEEB: any section i should read first in this doc? [10:11] <clever> hmmm odd, this one is only 29 pages long [10:11] <nevcairiel> look for avcC [10:11] <nevcairiel> avc configuration record [10:12] <clever> found it on page 20, *reads* [10:16] <clever> JEEB: the omx docs make more sense then 14496-15, lol [10:16] <ubitux> don't we have helpers already do deal with thos NALs ? [10:16] <clever> ubitux: my decode_slice function is being ran by h264_decode_nal_units, which strips the 0x00 0x00 0x01 start code off every slice [10:17] <clever> and i'm having to re-insert those as i pass the stream to the gpu [10:17] <clever> vdpau does the exact same thing for those start codes [10:17] <clever> hmmm, how does vdpau handle this header?, *looks* [10:19] <nevcairiel> vdpau is a slice-level decoder, it only gets slice data, not the raw header [10:19] <clever> ah [10:19] <nevcairiel> the information in these headers is put into different data structures and submitted that way [10:19] <clever> omx seems to work best if i give it the raw stream, the same way mkvextract gives it [10:20] <ubitux> did you try to feed it a raw stream from ffmpeg? [10:20] <ubitux> like, ffmpeg -i in.mkv out.h264 [10:21] <clever> *looks* [10:21] <clever> i think thats re-encoding everything as it goes, not just extracting it [10:21] <JEEB> clever, well the stuff that is done in Matroska is exactly the same as the avc configuration record [10:21] <clever> its only working at 3 fps [10:21] <ubitux> clever: -c copy [10:21] <JEEB> so you should be able to parse its info [10:22] <JEEB> and decode the included parameter sets [10:22] <JEEB> and then you will also get the length of the in-band length field [10:23] <clever> JEEB: the pdf starts with class AVCConfigurationBox extends Box(`avcC`) { AVCDecoderConfigurationRecord() AVCConfig; } [10:23] <clever> but that doesnt really say what the avcC its extending is, or what AVCDecoderConfigurationRecord is [10:24] <clever> ah AVCDecoderConfigurationRecord is up 2 pages, *reads* [10:25] <clever> yeah, that one seems to match up with the extradata fields [10:26] <clever> ubitux: let me try the output of ffmpeg on the gpu... [10:28] <clever> ubitux: yep, ffmpeg -i h264_1080p_hp_4.1_40mbps_birds.mkv out.h264 -c copy plays perfectly when fed into the gpu [10:28] <ubitux> well then look how the raw is generated [10:29] <ubitux> :) [10:29] <clever> and the header in that is different as well [10:29] <clever> 00000010 00 00 09 1c 00 01 b4 d0 3c 60 c6 58 00 00 00 01 |........<`.X....| [10:29] <clever> nothing like the other 2 headers, it doesnt have the gd.).4 pattern in it [10:29] <ubitux> no header at all maybe [10:30] <clever> it still has the ascii in it later on [10:30] <clever> 00000080 74 70 3a 2f 2f 77 77 77 2e 76 69 64 65 6f 6c 61 |tp://www.videola| [10:30] <clever> at a different offset then the mkvextract output [10:31] <clever> ubitux: any clue where i should look for that code? [10:31] <ubitux> the raw muxer is libavformat/rawenc.c [10:32] <ubitux> and basically, it's just calling a write(pkt->data, pkt->size) [10:32] <clever> avio_write(s->pb, pkt->data, pkt->size); [10:32] <clever> yeah, thats it, lol [10:32] Action: clever scratches head [10:33] <clever> so why is it coming out in a 3rd completely different header [10:33] <ubitux> try to hex dump the data this raw muxer is writing [10:33] <ubitux> and look if the x264 string header is one of these packet [10:34] <ubitux> otherwise, it's written from somewhere else [10:34] <ubitux> (which would look strange to me and i'm curious where that would happen) [10:34] <clever> let me compile a 4th ffmpeg then [10:35] <clever> ive got one for the vdpau disection, one inside mplayer, one in omxplayer, and now another for the rawenc debug! [10:35] <clever> isnt that the entire point of dynamic libraries? lol [10:37] <ubitux> :) [10:52] <cone-332> ffmpeg.git 03Anton Khirnov 07master:074c769de93b: h264_cavlc: check the size of the intra PCM data. [10:52] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:ededb5ffed79: Merge commit '074c769de93bf12e9f44d77e58a8c7167f9dfb13' [10:57] <clever> ubitux: Encoder (codec none) not found for output stream #0:0 [10:57] <clever> it wont copy now that ive compiled it from source [11:05] <cone-332> ffmpeg.git 03Anton Khirnov 07master:c453723ad7d1: gifdec: check that the image dimensions are non-zero [11:05] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:8b2578ab452f: Merge commit 'c453723ad7d14abc5e82677eebaa6025fa598f08' [11:05] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:564ae836fb7b: avcodec/gifdec: print error if image is not within dimensions [11:27] <ubitux> should we drop all the *.d files at configure time so we don't need to make distclean after some files are moved, but just re-run the configure? [11:28] <wm4> ubitux: that sounds like a good idea [11:28] <wm4> but remove them only if configure didn't detect any changes, I guess? [11:28] <wm4> s/didn't/did [11:29] <ubitux> the changes are currently detected by Makefile iirc [11:29] <ubitux> (we could make the Makefile call make config btw when that happens) [11:29] <ubitux> (but i'm assuming this will annoy ppl) [11:30] <ubitux> wm4: what would be the benefit? [11:30] <wm4> or just switch to autoconf [11:30] <ubitux> lol plz [11:30] <wm4> rerunning configure if nothing changes (i.e. same config.h) should not force recompilation of everything [11:30] <wm4> or use waf or other hipster shit if you hate autoconf too much [11:31] <ubitux> recompilation? [11:31] <ubitux> i'm just talking about the deps [11:31] <wm4> well, if you remove the deps, you should remove the .o files too [11:31] <ubitux> this should not cause any recompilation where not expected [11:31] <ubitux> wm4: why? [11:31] <wm4> I'm not sure how ffmpeg's build system works, but normally dep files are generated as part of compilation [11:31] <ubitux> mmh [11:32] <wm4> and if the dep files are just deleted, the dependencies won't taken into account at all [11:32] <ubitux> they will be re-generated [11:32] <ubitux> the .o won't have any ref [11:32] <ubitux> unless i'm missing something [11:32] <ubitux> the idea is drop all the .d at configure since it will re-gen them [11:33] <ubitux> if there are remaining .o it doesn't matter, they won't be referenced anywhere [11:34] <wm4> configure generates .d? interesting... [11:34] <ubitux> maybe i missed something [11:34] <ubitux> you shouldn't listen too much to me [11:34] <clever> ubitux: cant debug ffmpeg to see how it dumps the h264 stream, it just cant when compiled from source [11:34] <wm4> or you to me [11:35] <clever> Encoder (codec none) not found for output stream #0:0 [11:35] <ubitux> what cmd line? [11:35] <clever> clever@c2d ~/builds/ffmpeg $ ./ffmpeg -i /media/videos/4tb/rpi/h264_1080p_hp_4.1_40mbps_birds.mkv out.h264 -c copy [11:35] <clever> identical to last time [11:35] <ubitux> move -c copy before out.h264 [11:35] <ubitux> it's an output option [11:35] <ubitux> (how old was your ffmpeg? o_o) [11:35] <clever> clever@c2d /media/videos/4tb/rpi $ ffmpeg -i h264_1080p_hp_4.1_40mbps_birds.mkv out.h264 -c copy [11:35] <clever> the old one worked fine that way, let me check [11:36] <clever> ffmpeg version 1.0.7 Copyright (c) 2000-2013 the FFmpeg developers [11:36] <ubitux> yeah right, welcome to prehistory [11:36] <clever> yet the copyright includes the current year? lol [11:36] <wm4> 2013... not that old [11:36] <ubitux> it's the rev [11:37] <nevcairiel> still 1.0 [11:37] <ubitux> unless i'm missing something [11:37] <clever> ok, now its a spam-fest [11:37] <ubitux> 1.0 was released in 2012 [11:37] <clever> its hexdumping all 200mb [11:37] <ubitux> ofc [11:37] <ubitux> use |less and check the first packets [11:37] <clever> yep [11:38] <clever> 00000000 00 00 02 53 06 05 ff ff 4f dc 45 e9 bd e6 d9 48 ...S....O.E....H [11:38] <clever> 00000010 b7 96 2c d8 20 d9 23 ee ef 78 32 36 34 20 2d 20 ..,. .#..x264 - [11:38] <clever> thats not what 1.0.7 put into the file [11:39] <clever> let me do another dump and compare... [11:39] <ubitux> :D [11:39] <ubitux> check if the raw still works :p [11:40] <clever> yeah [11:40] <clever> -rw-r--r-- 1 pi pi 76M Nov 22 05:26 out.h264 [11:40] <clever> -rw-r--r-- 1 pi pi 110M Nov 22 06:39 latest.h264 [11:40] <clever> size differs massively [11:41] <clever> ubitux: and output is completely blank [11:41] <clever> so updating to the latest git has broken it [11:42] <clever> OMXPlayerSubtitles.cpp:172:22: error: steady_clock is not a member of std::chrono [11:42] <clever> ubitux: maybe you can figure this one out? [11:42] <wm4> hm what do subtitles have to do with this? [11:43] <clever> wm4: omxplayer uses the extradata from its checkout of ffmpeg, and it works perfectly fine [11:43] <clever> so i'm trying to av_hex_dump that [11:43] <clever> but i cant even get omxplayer to compile [11:43] <clever> due to the above error [11:43] <wm4> apparently std::chrono is C++11 crap [11:43] <wm4> so you need to update your C++ compiler? [11:44] <clever> the prepare script installed gcc 4.7 [11:44] <clever> so i should be running the right compiler [11:49] <ubitux> that error doesn't look related to ffmpeg :p [11:50] <clever> yeah, i'm trying to figure out how omxplayer even works in the first place [11:50] <clever> because its using the same extradata stuff, and it having totaly different results [11:53] <clever> only other thing i can think of, is that the omx code sends extradata by itself, *tries* [11:53] <cone-332> ffmpeg.git 03Anton Khirnov 07master:1f3e56b6dcc1: gifdec: convert to bytestream2 [11:53] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:7a88b7a9ad7a: Merge commit '1f3e56b6dcc163a705704e98569d4850a31d651c' [11:59] <clever> nope, nothing [12:00] <clever> ubitux: correction, i get a few lines that almost look like noise on the 10 foot composite cable, but it only happens when i run the program [12:01] <cone-332> ffmpeg.git 03Anton Khirnov 07master:f0259a587ee3: h264: check buffer size before accessing it [12:01] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:fe540ae6b72a: Merge commit 'f0259a587ee3419dd894873ea617b4c98eeaca1c' [12:05] <Skannan> Hello I receiving the below error while installing ffmpeg during the script installation [12:06] <Skannan> cd /usr/local/cpffmpeg/share/man/man1 && ln -sf mplayer.1 mencoder.1 [12:06] <Skannan> install -m 755 -s mplayer /usr/local/cpffmpeg/bin [12:06] <Skannan> Installation of mplayer.tar.gz ....... Completed [12:06] <Skannan> Installation of FFMPEG ....... started [12:06] <Skannan> Removing old source [12:06] <Skannan> Cloning into ffmpeg... [12:06] <Skannan> remote: Counting objects: 336283, done. [12:06] <Skannan> remote: Compressing objects: 100% (76395/76395), done. [12:06] <Skannan> remote: Total 336283 (delta 267069), reused 327256 (delta 259365) [12:06] <Skannan> Receiving objects: 100% (336283/336283), 81.47 MiB | 3.86 MiB/s, done. [12:06] <Skannan> Resolving deltas: 100% (267069/267069), done. [12:06] <Skannan> ERROR: libx264 not found [12:06] <Skannan> If you think configure made a mistake, make sure you are using the latest [12:06] <Skannan> version from Git. If the latest version fails, report the problem to the [12:06] <Skannan> help plz [12:08] <ubitux> ask #ffmpeg [12:08] <ubitux> and stop spamming [12:09] <cone-332> ffmpeg.git 03Anton Khirnov 07master:30be1ea33e55: matroskadec: pad EBML_BIN data. [12:09] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:1ddc849bde0d: Merge commit '30be1ea33e5525266ad871bed60b1893a53caeaf' [12:11] <cone-332> ffmpeg.git 03Aurelien Jacobs 07master:8b516f154a0a: matroskadec: use correct compression parameters for current track CodecPrivate [12:11] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:d86e27758f4d: Merge commit '8b516f154a0a08655cec2d13d12aadc58cae0b1c' [12:27] <cone-332> ffmpeg.git 03Anton Khirnov 07master:ca41c72c6d95: motionpixels: clip VLC codes. [12:27] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:8c63ee4296a8: Merge commit 'ca41c72c6d9515d9045bd3b68104525dee81b8d0' [12:34] <cone-332> ffmpeg.git 03Anton Khirnov 07master:de4ec972c06d: vc1: fix a memleak. [12:35] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:d7fbb63122b8: Merge commit 'de4ec972c06d9047bc1b73bb13f858a5d77d8df0' [12:40] <cone-332> ffmpeg.git 03Anton Khirnov 07master:ce9bba5340a5: avidec: fix a memleak in the dv init code. [12:40] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:4b3b702f9256: Merge commit 'ce9bba5340a5fb6f38974a19af019dd6aa2da035' [12:49] <cone-332> ffmpeg.git 03Anton Khirnov 07master:c918e08b9cc9: truemotion1: make sure index does not go out of bounds [12:49] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:bdf831859f0d: Merge commit 'c918e08b9cc9ce8d06159c51da55ec5ab018039a' [12:53] <cone-332> ffmpeg.git 03Anton Khirnov 07master:430d12196432: pcx: round up in bits->bytes conversion in a buffer size check [12:53] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:8617be28d074: Merge commit '430d12196432ded13f011a3bf7690f03c9b2e5d6' [13:02] <cone-332> ffmpeg.git 03Diego Biurrun 07master:0ba8ba165b84: aacps: Adjust some const qualifiers to suppress warnings [13:02] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:9e22b8aca0fd: Merge remote-tracking branch 'qatar/master' [13:04] <ubitux> any idea why most (all?) the arm assembly has numbered labels instead of named one? [13:06] <ubitux> i see some named labels in jrevdct_arm.S but that's really one of the few ones [13:06] <ubitux> i'm assuming it's exporting syms while numbering doesn't? [13:06] <ubitux> (the '.' thing in x86 doesn't work for the arm assembler?) [13:10] <wm4> isn't it a gas thing? [13:22] <ubitux> dunno [13:22] <ubitux> probably :p [13:48] <saste> wbs: can you explain this?: https://trac.ffmpeg.org/ticket/3158 [13:49] <wbs> saste: yes, VBR is a "if it works for you, good for you, if it doesn't, don't complain" thing [13:50] <wbs> VBR is not supported at all in the library as it comes from upstream, I just removed some lines of code that made it impossible to enable the code that actually is there [13:50] <wbs> so for some bitrate/samplerate/vbr mode combinations it works, for some it doesn't [13:51] <wbs> and there should have been a warning when you try to use VBR mode that says "if this doesn't work, then don't use VBR mode", why not read that and follow what it says? [13:52] <saste> wbs, yes, i'll close the ticket and stress that in the docs [13:55] <clever> ubitux: ah, i found the std::chrono problem [13:55] <clever> ubitux: the script to prepare everything including gcc 4.7, tried to use bash features in sh [13:55] <clever> so it failed to setup 4.7 properly [13:59] <ubitux> wtf audacity still requires a 2yrs old ffmpeg [14:09] <wm4> lol audacity [14:10] <JEEB> I think that was one of the apps that the debian maintainer had to kick in the arse as well [14:19] <ubitux> JEEB: and what happened? [14:28] <db0__> hi guys [14:28] <db0__> ubitux asked me to re-design the website [14:28] <JEEB> ubitux, I would guess either upstream got a patch that used newer APIs, they fixed it themselves or debian now patches audacity to work with newer APIs [14:28] <ubitux> JEEB: 'k, thx [14:29] <db0__> I just wanted your opinion on the global color: white on black or black on white? [14:29] <ubitux> saste: you were curious about the progress, ^ [14:29] <JEEB> or... [14:29] Action: JEEB checks a few things [14:31] <JEEB> http://packages.debian.org/jessie/audacity [14:31] <JEEB> seems like debian doesn't have avcodec as a dependency for audacity any more [14:31] <ubitux> yeah ok i see [14:32] <JEEB> and then the version from unstable has it re-enabled agian [14:32] <JEEB> *again [14:32] <JEEB> with an ass-old avcodec :| [14:33] <JEEB> seems like they couldn't get them to update the API usage [14:33] <JEEB> excuse me while I herp a derp [14:33] <wm4> to be fair, the API changes are always horrible [14:33] <wm4> I don't understand why ffmpeg doesn't just emulate old APIs [14:42] <nevcairiel> I hate endless emulation layers [14:43] <nevcairiel> once you start they just bloat up and you can never clean up [14:43] <av500> allways put an emulation layer into a wrapper [14:56] <saste> ubitux, db0__: ideally it would be nice to support multiple CSS layouts [14:58] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:80c85460fd1b: doc/encoders/libfdk_aac: use @ref to reference libfaac [14:58] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:9459569897a2: doc/encoders/libfdk_aac: fix a few typos [14:58] <ubitux> saste: you can harass db0__ only i'm not responsible anymore ;) [14:58] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:e2ad4e65a1d3: doc/encoders/libfdk_aac: state that VBR support is experimental [14:58] <saste> db0__, can you already show something? [14:58] <saste> a link to an experimental website, a png? [15:04] <db0__> saste: it looks terrible [15:04] <db0__> http://db0.galo.pe/ffmpeg-web/htdocs/ [15:05] <Romain___> it's very nice, sober [15:09] <saste> db0__, project colors have been white, green, and grey, but this can be changed [15:10] <saste> about the embedded logo in the menu bar [15:10] <ubitux> db0__: if you can make the <table> readable, that would be nice [15:10] <ubitux> (different colors for odd & even lines) [15:10] <saste> this may be a good idea, on the other hand we couldn't show custom logos no more [15:10] <db0__> saste: I planned to use those colors [15:10] <saste> what i mostly dislike about the current ffmpeg design: [15:11] <saste> the box around headers, which are a bit ugly and look old style [15:11] <saste> sick green color used for h3 headers [15:11] <db0__> ubitux told me the logo is now owned by libav so I have to design a new one [15:11] <ubitux> the small one you used, yes [15:12] <ubitux> we have a favicon you can use though [15:12] <Compn> dropdown menus ? [15:12] <db0__> isn't it the same...? [15:12] <ubitux> db0__: no [15:12] <db0__> ok [15:13] <Compn> db0__ : i dont like dropdown menus much [15:13] <ubitux> http://ffmpeg.org/favicon.png ` http://libav.org/favicon.png [15:13] <ubitux> it represents the same thing ofc :p [15:13] <saste> ubitux, "is now owned by libav" [15:13] Action: ubitux doesn't like much dropdown menus either [15:13] <JEEB> reminds me that stunt by mru was one of the dumbest things in 2011 [15:13] <ubitux> saste: i didn't word it like this ;) [15:13] <saste> that was never properly demonstrated [15:14] <JEEB> not to mention that mru finally left libav a few months ago, which I kind of like in a way :P [15:14] <saste> indeed the whole thing is much controverted [15:14] <db0__> that's what most flat websites use today, but i can change it [15:14] <ubitux> saste: yeah but let's put aside the flaming :) [15:14] <saste> ubitux, yes, but don't assume wrong things [15:15] <ubitux> db0__, Compn; the thing i don't like with drop down menu is that we generally have to look for things in those menus [15:15] <ubitux> if they are always expanded, we locate them much faster [15:16] <ubitux> JEEB: if we get the logo back, do you think it will bring back mru to libav? [15:17] <ubitux> let's try, they might thank us ;) [15:17] <JEEB> haha [15:17] <nevcairiel> doubtful, he left for reasons [15:17] <JEEB> yeah [15:17] <JEEB> "everyone else is dumb", which seemed to be his motto in surprisingly many things [15:18] <nevcairiel> its called arrogance [15:18] <JEEB> yup [15:18] <ubitux> let's not bitch about dead ppl, they can't defend themselves [15:18] <JEEB> ( [15:19] <ubitux> ok, with the exception of steve jobs, we can bitch on this one i guess [15:19] <Compn> yea, get on with it guys [15:19] <Compn> forget the logo [15:19] <Compn> whats next :) [15:19] <Compn> someone porting spp filter and finally rm -rf libmpcodecs ? [15:19] <ubitux> spp is ported [15:47] <ubitux> btw, any feedback on cross compiling ffmpeg with clang vs with a random gcc toolchain? [15:49] <Mavrik> huh... ffmpeg compile breaks very nicely with LTO [15:50] <ubitux> (s/clang/llvm) [15:50] <ubitux> Mavrik: you need to disable inline asm [15:51] <Mavrik> mhm [15:51] <Mavrik> figured that's not supported properly yet :) [15:51] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:320389f88b42: lavu/dict.h: apply various fixes/extensions to doxy [15:51] <JEEB> ubitux, the last I tried clang 3.3 it was all fine'ish? [15:51] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:e782eea183ba: lavu/dict.h: extend/clarify docs for av_dict_parse_string() [15:52] <JEEB> had to build my own clang and use it because the gcc and clang that came with os x 10.6 and some early xcode 4 were too old :) [15:52] <ubitux> JEEB: i've heard "it's slower and creates bigger binaries" [15:52] <ubitux> so i was wondering if i should mess with a toolchain or no [15:52] <JEEB> yes, the optimization isn't as good [15:52] <JEEB> at least with x86_64 [15:52] <JEEB> or IA32 [15:53] <JEEB> also clang-built binaries might not always be liked by gdb [15:53] <ubitux> ah sorry, i'm talking about cross compiling for arm [15:53] <Mavrik> depends on which ARM [15:53] <Mavrik> I've found clang to be horribly broken for some platforms... would probably work for Apple devices which compile their apps with clang now [15:53] <ubitux> arm7, cortex a8 [16:02] <sspiff> ubitux: that's ARMv7, not ARM7 [16:02] <ubitux> yeah sorry [16:02] <ubitux> not familiar with all those naming :) [16:03] <ubitux> btw, anyone heard about http://en.wikipedia.org/wiki/MMX_%28instruction_set%29#MMX_in_embedded_appl… ? [16:03] <ubitux> should/could we support such thing? (port mmx code to arm?) [16:05] <wm4> "Intel Wireless MMX Technology" [16:05] <wm4> wow [16:05] <wm4> did the marketing team have their hands in that again [16:05] <av500> thats so old [16:05] <wm4> reminds me of the "internet" shit in pentium 3 [16:05] <ubitux> simd over wifi [16:05] <sspiff> av500: I think marvell still sells PXA things [16:06] <av500> yes [16:06] <av500> hotrodded ARM9s with wMMX [16:07] <sspiff> av500: also in-house designs [16:07] <sspiff> they have them on application processors, it seems [16:08] <ubitux> the point is, most hw decoder are still shitty, so if they have wmmx/wmmx2, maybe we could use our current x86 mmx optims somehow [16:08] <ubitux> typically this thing: http://www.solid-run.com/mw/index.php?title=CuBox_hardware_specification [16:09] <sspiff> their sheeva plugs and P4J has it, so that's quite a few devices [16:09] <sspiff> ubitux: I know that thing, not sure if many people have one/run ffmpeg on it though [16:09] <av500> that thing will note decode HD even with wmmx [16:09] <av500> it does not with neon on other SoCs [16:10] <ubitux> even with threading? [16:10] <ubitux> it's a dual core [16:10] <av500> no [16:10] <av500> or well, maybe taking like 100% cpu [16:11] <av500> then why not use the HW decoder? [16:12] <ubitux> because it sucks i guess [16:12] <av500> dunno why it should [16:12] <ubitux> what about 10-bits? [16:13] <av500> nope [16:13] <av500> good luck with 10bit HD in SW though :) [16:13] <ubitux> well then& [16:13] <ubitux> yeah sure [16:16] <saste> who knows why we kept git-howto.txt? [16:16] <saste> michaelni, ? [16:17] <michaelni> saste, dunno, i took a quick look at the texi when the question was posted ... [16:19] <ubitux> av500: do you know hw decoder supporting 10bit? vmeta maybe? [16:19] <av500> vmwhat? [16:20] <ubitux> vMeta [16:20] <ubitux> marvell again [16:29] <ubitux> well i guess nothing supports 10-bit [16:32] <av500> no demand for it :) [16:34] <ubitux> i demand! [16:35] <av500> :) [16:35] <av500> now become CEO at marvell [16:35] <ubitux> sadness :( [16:55] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:68590650f05f: lavu/avstring: add av_utf8_decode() function [16:55] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:e87190f5d20d: ffprobe: check for errors, and abort immediately [16:55] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:11cba3ba9df1: ffprobe: add support for nested options in writer contexts [16:55] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:cbba331aa02f: ffprobe: implement string validation setting [16:56] Action: ubitux reviewing saste commits post push [16:56] <ubitux> saste: you don't need to add a comma after the last "NB" entry in enums [16:57] <ubitux> same for { NULL } trailing entry in stables [17:02] <cone-332> ffmpeg.git 03Stefano Sabatini 07master:d20241c9b1f3: ffprobe: remove various useless "," [17:02] <ubitux> :) [17:06] <saste> http://ffmpeg.org/trac/ffmpeg/query?status=!closed&component=FFprobe [17:06] <saste> ubitux, i leave that to you :) [17:08] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:7865759409b2: avformat/avidec: Dont assert the existence of an index for video streams. [17:08] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:ba992711f79c: avcodec/hnm4video: check that packetsize is at least 8 [17:08] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:6060234d43dc: avcodec/mjpegdec: check len in mjpeg_decode_app() more completely [17:08] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:0398b7cbd39a: avcodec/hnm4video: check intraframe size [17:11] <ubitux> saste: -f lavfi ftw [17:11] <ubitux> saste: i might do it if you simplify the api ;) [17:13] <saste> michaelni, ok to remove git-howto.texi [17:13] <saste> ? [17:47] <cone-332> ffmpeg.git 03Zhang Rui 07master:393d80cc278e: http: Support relative URL redirection [17:47] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:1d19f1b196c7: Merge commit '393d80cc278e2b2f5c9e7805db176e6f28335a33' [18:07] <cone-332> ffmpeg.git 03Martin Storsjö 07master:be4edda6731a: http: Expose the content location via an AVOption [18:08] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:15b2ec57ccae: Merge commit 'be4edda6731a341d3fdeaa0e57753dc396790362' [18:15] <cone-332> ffmpeg.git 03Martin Storsjö 07master:8c929098141e: hls: Check whether the AVIOContext contains a new redirected URL [18:16] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:9440e4706793: Merge commit '8c929098141ebc94ad3f303521c520bb3dc6d8f6' [18:28] <cone-332> ffmpeg.git 03Martin Storsjö 07master:56c2337004d5: hls: Avoid reading outside of the allocated array [18:28] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:9c00f9ada690: Merge remote-tracking branch 'qatar/master' [18:32] <db0__> do you mind if I rewrite some pages? [18:33] <db0__> I want to make it much simpler, add big buttons that are easy to find and replace long sentences by important keywords [19:02] <ubitux> db0__: yes, but track each change so we can review them [19:58] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:e4eb2c957b68: avcodec/rv10: revert hunk from ce9f5b13ed1eb1882479574c12af24cf0e2b8aaf [19:58] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:2e97e244097c: avformat/ipmovie: check OPCODE_INIT_VIDEO_BUFFERS size more completely [20:17] <ubitux> BBB: ping [20:17] <ubitux> BBB: opinion on http://b.pkh.me/0001-avcodec-vp9dsp-add-DC-only-versions-for-idct-idct.patch ? [20:23] <BBB> that's a pretty good gain actually [20:23] <BBB> sure why not [20:24] <ubitux> i might get even more easily [20:27] <BBB> how so? [20:28] <ubitux> moving out the t rounding [20:28] <BBB> hm yes [20:28] <BBB> I wonder if the compiler would know that [20:28] <BBB> compilers always have surprisingly obnoxious behaviour [20:32] <ubitux> mmh strangely it looks a little slower [20:32] <ubitux> i guess i'll keep that version [20:37] <cone-332> ffmpeg.git 03Clément BSsch 07master:64821f5a7cc8: avcodec/vp9dsp: add DC only versions for idct/idct. [20:51] <siriussirius> hi [20:52] <siriussirius> are there any news about MVC support on ffmpeg? [20:56] <Compn> siriussirius : h264 3d you mean ? [20:56] <Compn> er 3d bluray [20:56] <Compn> i mean [20:56] <siriussirius> yep [20:56] <Compn> i dont think anyones working on it , no [20:56] <Compn> not many h264 people , not many 3d blurays, i wonder if we even have many samples [20:56] <Compn> should ask vlc ... [20:57] <Compn> i bet hes got 3d bluray porn [20:57] <Daemon404> nobody anywhere gives any crap about 3d bluray afaik [20:57] <Daemon404> ... maybe j-b [20:57] <Daemon404> but iirc he doesnt. [20:57] <Compn> he asked about it at vdd [20:57] <Compn> because 3d hardware should be getting real cheap now [20:57] <Daemon404> he calle it a fad, and low priority [20:57] <Daemon404> didnt he? [20:57] <siriussirius> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_of_Code_2013#H.264_… [20:57] <Daemon404> anyway i definitely dont care [20:57] <Compn> of course its a fad, but theres no open source for that market [20:58] <Daemon404> i think it looks like crap [20:58] <Daemon404> and it makes my head hurt [20:58] <Daemon404> literally. [20:58] <Compn> many people get headaches with 3d tech [20:58] <siriussirius> thats true, specially with active glasses [20:58] <Compn> siriussirius : do you have 3d discs ? [20:58] <siriussirius> but passive ones are fine [20:59] <siriussirius> yep [20:59] <Compn> which ones ? [20:59] <Compn> avatar ? [21:00] <siriussirius> yep, Despicable Me 2 [21:01] <siriussirius> Gravity in the near future [21:01] <Daemon404> they all have a blurry look to me [21:01] <siriussirius> that deserves to be watched in 3D [21:02] <siriussirius> ok [21:02] <siriussirius> that's all, I just wonder if someone starts to work on it [21:02] <siriussirius> thank you guys [21:02] <siriussirius> ;) [21:03] <Compn> no problem [21:03] <Compn> just curious what people are watching :) [21:04] <siriussirius> nye! [21:04] <siriussirius> bye! [21:09] <llogan> michaelni: I still have the message delete button on trac [21:09] <llogan> s/message/ticket [21:09] <michaelni> ? [21:10] <llogan> you mentioned that you did not want that functionality via the web interface [21:11] <michaelni> llogan, true but theres too much spam [21:12] <llogan> ok [22:27] <BBB> ubitux: I'd be surprised if it was slower, would expect it more or less to have no effect if the compiler was clever, but what do I know [22:28] <ubitux> yeah i was surprised as well, but didn't investigate much [22:28] <BBB> fair enough, not crazy important I suppose [22:28] <BBB> good speed gain though [22:28] <BBB> I'm 3/4 done with frame-mt I think [22:28] <ubitux> awesome :) [22:28] <BBB> have two pieces that need some refactoring [22:47] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:a7f27453f64d: avformat/mov: Check that we have a stream before accessing it in mov_read_ares() [22:47] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:5a08ba5381cf: avcodec/hnm4video: check offset in decode_interframe_v4() more completely [22:47] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:78446f0d9d6a: avcodec/hnm4video: fix write offset checks in decode_interframe_v4() [22:47] <cone-332> ffmpeg.git 03Michael Niedermayer 07master:b33f3246e2ec: avcodec/hnm4video: fix missing newlines in error messages [23:27] <cone-332> ffmpeg.git 03Clément BSsch 07master:004f3b154b7c: avcodec/vp9dsp: pass dconly bit as macro argument. [23:28] <ubitux> BBB: and so you kept the fb[]? [23:29] <BBB> no [23:29] <BBB> but I'm not sure it's optimal [23:29] <BBB> let me finish mt so I can figure it out and then I'll know what to do with that patch [23:29] <BBB> I finished one of the refactorings and am now doing the second, then I'll probably need to debug for a few days, and then it should work [00:00] --- Sat Nov 23 2013

1 0

ffmpeg.log.20131122
by burek 23 Nov '13

23 Nov '13

[00:04] <cbsrobot> sirEgghead: read line 4 of http://pastebin.com/wRTEfXU3 [00:06] <sirEgghead> cbsrobot, lol that works. I actually found my old notes for compiling it as well. :) [00:07] <cbsrobot> sirEgghead: I think you can drop --enable-avfilter [00:08] <cbsrobot> and ofc you can also follow: http://ffmpeg.org/trac/ffmpeg/wiki/CentosCompilationGuide [00:20] <Eduard_Munteanu> Is there a way to concat arbitrarily different files? [00:21] <Eduard_Munteanu> I want to build a larger video from smaller parts, possibly using different formats, codecs etc [00:26] <llogan> Eduard_Munteanu: you can try the concat filter. you will have to make them have a uniform screen size, frame rate, etc which can be done in the filterchain with scale and fps filters [00:26] <llogan> http://ffmpeg.org/ffmpeg-filters.html#concat [00:27] <Eduard_Munteanu> llogan: yeah, I can do that, but IIRC it doesn't support different video lengths nicely [00:28] <Eduard_Munteanu> Unless I'm misinterpreting this: "The concat filter will use the duration of the longest stream in each segment (except the last one), and if necessary pad shorter audio streams with silence." [00:28] <Eduard_Munteanu> llogan: I haven't tried it yet, seeing that warning [00:42] <Nothing4You> hey there, can someone explain to me the difference of using e.g. --enable-libxvid vs using the native encoder? [00:44] <JEEB> the native one can possibly be better [00:45] <JEEB> but the documentation on it is scarce [00:45] <JEEB> and the defaults are pre-2012 ffmpeg [00:45] <JEEB> aka crappy [00:45] <JEEB> libxvid is simpler to use [00:45] <JEEB> but possibly cannot get to as good results even after tweaking things up to eleven [00:45] <JEEB> people usually use libxvid because of the simplicity [00:46] <Nothing4You> ok, thanks for the info [01:18] <cadabra> I'm trying to run `ffmpeg -i foo.mp4 -vf scale=... out.xxx` and failing because it can't determine the format for xxx. Can I tell ffmpeg to use the input format for output without changing the extension? [01:20] <relaxed> cadabra: -f $format_name [01:20] <relaxed> what format do you want? [01:20] <cadabra> The same as the input, whatever it is. [01:21] <cadabra> Currently trying to find a way to print just the input format in a way in which -c:v will accept. [01:21] <cadabra> I'm a little confused about the streams though. My file has video and audio. Cool. Are there files with more streams than these two? Do I have to specify formats per stream? [01:24] <cadabra> I guess I can grep and sed through `ffmpeg -i foo.mp4` to get the input format. Just wondering if there's a straight-forward way to say "use the input format for all streams" without having to cobble something like this together... [04:17] <Fusl> hey guys... is there someone who can explain me how to tell ffmpeg to write audio headers once per output-flush to stdout for a stream? for example: i use the following command to convert a mp3 file to codec vorbis and format ogg: /usr/bin/ffmpeg -loglevel quiet -re -i pipe:0 -ab 175k -ac 2 -acodec vorbis -ar 44100 -flags2 local_header -preset ultrafast -strict -2 -f ogg pipe:1 ... but when i skip the header or seek to x bytes in the file [07:20] <Sweetie43> hi [07:21] <Sweetie43> i am using ffmpeg to transcode an udp stream but when the stream is not ready ffmpeg doesn't display any error, ffmpeg seems to never end, and i can't even even end it with the q like i usually do [07:22] <Sweetie43> and when the stream is available again ffmpeg is still working [07:23] <Sweetie43> is it possible to make ffmpeg ends when it can't get the connection ? and why when it's waiting for it i can't stop it with q [07:23] <Sweetie43> any idea ? [10:50] <SirCmpwn> is it possible to set a target bitrate for specific parts of a file? [10:51] <SirCmpwn> so I could, say, have minutes 1 to 3 by one bitrate, and 3 to 5 be another [10:51] <SirCmpwn> AVC/AAC [11:01] <Mavrik> nope [11:02] <Mavrik> depending on what your goal is, CRF mode for x264 can be an approximation of it [11:03] <SirCmpwn> the goal is to get better results by manually tailoring the bitrate to achieve a good quality at the lowest possible bitrate in different parts of a video [11:04] <Mavrik> I very much doubt you can do that on a whim [11:04] <Mavrik> without rewriting encoders themselves [11:05] <SirCmpwn> I wonder if I could work with raw streams (outside of a container) [11:05] <SirCmpwn> make seperate ones for each segment of video that should have a different bitrate [11:05] <SirCmpwn> and concatenate them with some more magic [11:06] <relaxed> probably could, but would the trouble be worth the gain? [11:06] <SirCmpwn> dunno [11:06] <SirCmpwn> I'm curious to see how effective it'd be [11:06] <Mavrik> SirCmpwn, well stream quality segmenters for streaming servers do that already [11:06] <Mavrik> but... honestly... it's pointless [11:07] <Mavrik> the gains aren't really worth the trouble [11:07] <SirCmpwn> not much to be gained? [11:07] <SirCmpwn> alright, I'll take your word for it [11:07] <Mavrik> if you don't have "hard" bitrate target use CRF mode in x264 [11:07] <Mavrik> which will vary bitrate according to complexity of the stream and desired quality [11:07] <SirCmpwn> will do [11:07] <Mavrik> SirCmpwn, otherwise, check how streaming servers do bitrate switching [11:12] <JEEB> SirCmpwn, you can use zones with x264opts I think? But yes, I recommend using CRF in that case (you can set a CRF value per zone) [11:12] <SirCmpwn> thanks, JEEB [11:29] <MrPingouin> hello, does anyone know how to display only integer values when using "expr" ? [11:49] <SirCmpwn> is there any way to simplify what ffmpeg outputs to stdout to make it a little more machine readable? [11:52] <MrPingouin> you want to parse the output ? [11:53] <SirCmpwn> yes [11:54] <MrPingouin> that's a good question, what kind of tokens do you want to retrieve ? [11:56] <SirCmpwn> stream info [11:56] <SirCmpwn> I'll be running videos through ffmpeg anyway [11:56] <SirCmpwn> and I want to parse the output to learn what streams are there [12:18] <Skannan> Hi, I'm receiving the below error during the script installation [12:18] <Skannan> Installation of mplayer.tar.gz ....... Completed [12:18] <Skannan> Installation of FFMPEG ....... started [12:18] <Skannan> Removing old source [12:18] <Skannan> Cloning into ffmpeg... [12:18] <Skannan> remote: Counting objects: 336283, done. [12:18] <Skannan> remote: Compressing objects: 100% (76395/76395), done. [12:18] <Skannan> remote: Total 336283 (delta 267069), reused 327256 (delta 259365) [12:18] <Skannan> Receiving objects: 100% (336283/336283), 81.47 MiB | 3.86 MiB/s, done. [12:18] <Skannan> Resolving deltas: 100% (267069/267069), done. [12:18] <Skannan> ERROR: libx264 not found [12:18] <Skannan> If you think configure made a mistake, make sure you are using the latest [12:18] <Skannan> version from Git. If the latest version fails, report the problem to the [12:18] <Skannan> ffmpeg-user(a)ffmpeg.org mailing list or IRC #ffmpeg on irc.freenode.net. [12:18] <Skannan> Include the log file "config.log" produced by configure as this will help [12:18] <Skannan> solving the problem. [12:18] <Skannan> plz help [12:18] <moodytabooty> Hello [12:18] <Skannan> Hi [12:19] <SirCmpwn> Skannan: did you, umm, install libx264 [12:19] <moodytabooty> All I want to do is change my 720p animu to 480p [12:19] <moodytabooty> I want to be able to run a command like: # ffmpeg -i input.mkv -s 848x480 output.mkv [12:19] <SirCmpwn> moodytabooty: you want -vf "scale=w:h" [12:19] <moodytabooty> This used to work, but I accidentally uninstalled ffmpeg last week and had to reinstall it from source [12:20] <moodytabooty> Okay, I'll try that [12:20] <Skannan> SirCmpwn: libx264 was ont installed. Do i need to install libx264? [12:20] <moodytabooty> When I run it with no other flags, the output is all pixely and stuff, and when I do something like -codec copy the filsize is INSANELY huge like bigger than the input file [12:20] <SirCmpwn> Skannan: you do indeed need to install libx264, or remove it from your ./configure invocation [12:21] <SirCmpwn> Skannan: it's an important codec, though, you probably want it [12:21] <SirCmpwn> moodytabooty: you want to research bitrates [12:21] <SirCmpwn> moodytabooty: google "ffmpeg bitrate" and look around [12:22] <moodytabooty> yeah i noticed the bitrates were really small [12:22] <SirCmpwn> lower bitrate -> smaller file [12:22] <moodytabooty> on my old transcodes the bitrate seemed to just carry over from the input file [12:22] <moodytabooty> now its not doing that [12:22] <moodytabooty> or maybe it didnt carry over but it was at least "smart" and kept it as something that looks good [12:23] <SirCmpwn> well, -codec copy is probably a bad idea [12:23] <moodytabooty> why's that? [12:23] <SirCmpwn> I'd probably go as far as to call it a bad idea all the time unless you know for sure why you need it [12:24] <SirCmpwn> it's not doing what you think it's doing [12:24] <Skannan> SirCmpwn: Ok I will install libx264 and then retry by installing the ffmpeg script again [12:24] <SirCmpwn> Skannan: which flavor of linux are you using? [12:24] <moodytabooty> well, basically i dont want to touch anything but the resolution [12:24] <SirCmpwn> moodytabooty: you still have to re-encode it when you change the res [12:24] <Skannan> SirCmpwn: Red Hat Enterprise Linux Server release 5.9 (Tikanga) [12:25] <SirCmpwn> Skannan: alright [12:25] <SirCmpwn> why did I start answering questions [12:25] <moodytabooty> but i noticed even when i ran # ffmpeg -i input.mkv anything.mkv it looked like crap [12:25] <SirCmpwn> I need to sleep [12:25] <SirCmpwn> moodytabooty: research bitrates [12:25] <SirCmpwn> good luck both of you, and good night [12:26] <moodytabooty> goodnight [12:26] <Skannan> SirCmpwn: I've installed libx264 so I will start installing the ffmpeg installation script again [12:36] <moodytabooty> ugh [12:36] <moodytabooty> i dont get why something that used to work would stop working or suddenly need a million commands just because i reinstalled it [13:09] <jita> I want to pipe the output of ffmpeg to some application. But the issue i am having that the encoding is not being accepted. I am using vcodec as libx264 and -f (format) as MP4. The produced output does not play. [13:09] <jita> Any ideas ? [13:12] <jita> Currently using this command "ffmpeg -i - -acodec aac -strict -2 -ab 128k -vcodec libx264 -f mp4 -profile:v baseline - [13:13] <ubitux> mp4 in a pipe is a very bad idea [13:14] <ubitux> because it will compute the header at the end [13:14] <ubitux> and a seekable output is recommended [13:16] <jita> ubitux: what could i possibly use? I want to make the output video compatible with html5 video players which support x264 with mpeg4 container [13:17] <ubitux> what's the point of sending it to another app if you use ffmpeg for the whole encoding/muxing chain? [13:18] <jita> ubitux: I am using it from python api, I want to convert the video file and store it on amazon S3 server as django filefield [13:18] <moodytabooty> ubitux: how do i change the resolution of a video file? [13:18] <sacarasc> moodytabooty: -vf scale=w:h [13:19] <ubitux> jita: dunno, you could mux to a segmented format such as hls and upload per chunk [13:19] <ubitux> or push raw data and mux it on amazon server [13:25] <moodytabooty> doesnt work [13:25] <moodytabooty> it changes the resolution but it makes the video all pixelated and low quality [13:25] <jita> ubitux: is there anything wrong in this log? [13:26] <jita> https://dpaste.de/aBbD [13:26] <moodytabooty> it used to work though which is what confuses me [13:26] <moodytabooty> then i reinstalled ffmpeg and everythings troublesome [13:26] <moodytabooty> before the command: ffmpeg -i example.mkv -s wxh output.mkv was all i needed [13:26] <ubitux> jita: yes, it's old, and missing the cmd line used [13:27] <jita> ubitux: I used the same command ffmpeg -i - -acodec aac -strict -2 -ab 128k -vcodec libx264 -f mp4 -profile:v baseline - from python api [13:28] <ubitux> and so what's the problem with it? [13:29] <jita> $ file VID_20131121_225533_3.mp4 [13:29] <jita> VID_20131121_225533_3.mp4: data [13:29] <moodytabooty> ugh [13:29] <moodytabooty> so frustrated [13:29] <jita> it does not recognise the file and cannot play it [13:29] <jita> although the file is not empty [13:31] <jita> ubitux: I am sorry that output was with -f matroska with -f mp4 I get this https://dpaste.de/tgJ7 [13:33] <sacarasc> moodytabooty: What you probably want is: ffmpeg -i input.mkv -c:a copy -c:s copy -c:v libx264 -preset:v veryslow -crf 20 output.mkv [13:34] <sacarasc> moodytabooty: Sorry... ffmpeg -i input.mkv -c:a copy -c:s copy -vf scale=-1:480 -c:v libx264 -preset:v veryslow -crf 20 output.mkv [13:35] <ubitux> sacarasc: -map 0 -c copy -c:v libx264 probably [13:35] <ubitux> jita: can it be played with ffplay? [13:35] <ubitux> jita: also, "[mp4 @ 0x7fb9bc005400] muxer does not support non seekable output" [13:36] <ubitux> you can't use the mp4 muxer in a pipe [13:36] <jita> ubitux: which one should i use then ? [13:36] <ubitux> i told you [13:40] <jita> ubitux: should I change vcodec too ? [13:41] <ubitux> i don't know what you solution you choosed [14:17] <tiksa> hi guys, I'd like to use concat filter to concat a video and an image. In video + video case, the way to do is like: [v1][a1][v2][a2]concat=n=2:v=1:a=1[out1][out2]. but I put video+audio like this: [v1][a1][i1]concat=n=2:v=1:a=1[out1][out2], doesn't work :( [14:18] <tiksa> is there a way, for example, to add a "null" audio stream for image? [15:51] <NewFfmpegUser> Hi. Frames of a video file can be indexed. Can I extract a frame from a video file by giving a frame index to ffmpeg? [15:51] <NewFfmpegUser> A quick Google search produced examples in which extracting is done by giving a time offset as input. However, I would like to give a frame index [15:57] <saste> NewFfmpegUser, no way, but you can preprocess the file and get the key-frames -> time map [16:02] <NewFfmpegUser> saste: True. Somehow I just hoped that ffmpeg would be more convenient in terms of accepting input parameters [16:05] <NewFfmpegUser> saste: Have you any tips how to read the framerate from a video file with ffmpeg? I can read the frame count with the help of this (http://stackoverflow.com/questions/2017843/fetch-frame-count-with-ffmpeg) [16:21] <chakie_laptop> hi, i'm trying to get ffmpeg to do some rtp-streaming between two systems on a LAN. Nothing seems to get streamed to the network. [16:22] <chakie_laptop> this is a complete run: http://pastebin.com/nE1BxRFy [16:22] <chakie_laptop> the commandline is: ./ffmpeg -rtbufsize 100M -f dshow -an -i video="VF0520 Live! Cam Sync" -vcodec libx264 -preset fast -tune zerolatency -f rtp rtp://192.168.1.12:2000 [16:23] <chakie_laptop> i'd tried a lot of options and most of those have been added one at at time to see if there was any difference [16:23] <chakie_laptop> a similar command line can stream perfectly from another system A (windows 7 too) and is received fine on B, but B can not stream to A [16:24] <chakie_laptop> the CPU is more or less idle when ffmpeg runs (1-2% load it seems), all firewalls are closed, the hosts see each other etc [16:25] <chakie_laptop> when starting the stream i see the normal "statistics" tick for a second or two, up to perhaps 40-50 frames, then it all freezes and the "frame dropped!" messages start. after they start, nothing more happens [16:27] <chakie_laptop> i have a hard time seeing how 40-50 vga sized images can overflow anything (the -s 640x480) parameter seems to be missing from that particular commandline [16:52] <chakie_laptop> hm, ok, there is probably a better forum somewhere [17:49] <chakie_laptop> tachyean: not really [17:52] <jita> Is there a way to use output pipe format which is comatabile with HTML5 player? mp4 does not work for output pipe as it errors out [17:52] <jita> cant use mpeg-ts it is not detected in html5 player [17:52] <jita> neither flash player [20:02] <lroe> can someone help me figure out why this isn't working: http://paste.debian.net/hidden/7710f2f6/ [20:03] <klaxa> use -f image2 before -i core.png.* [20:03] <klaxa> also avconv support is in #libav [20:03] <lroe> ah, sorry, when I run ffmpeg on the cli it says that it is deprecated for avconv so I assumed... [20:04] <klaxa> bad wording by some package maintainers apparently [20:23] <fonso> Hey, I've been there yesterday, asking for a Amazon AWS tutorial and I followed the tutorial and it is Ok, but now if I run the command "ffmpeg -version" it only run as root, did it isn't necessary to run as other users? If I use me own user it don't recognize the command, only root. Also, where is ffmpeg localizated? Sorry for the poor english :-) Have a nice weekend! [20:27] <llogan> fonso_: where is the ffmpeg binary? [20:28] <fonso_> llogan: In Ubuntu is /usr/local/bin/ffmpeg , But CentOS (Amazon AWS) the /usr/local/bin is empty [20:28] <llogan> did you follow a guide to compile and install it? [20:29] <fonso_> yeap, as they suggested me, and it is OK [20:29] <llogan> which guide? [20:29] <fonso_> Here : http://ffmpeg.org/trac/ffmpeg/wiki/CentosCompilationGuide [20:29] <llogan> that will "install" ffmpeg in the home directory of the user (specifically ~/bin). [20:30] <fonso_> yes it is there [20:30] <llogan> the advantage is that it does not interfere with the package management system or any programs that depend on a "ffmpeg" from the repositories (more of an issue for ubuntu) [20:31] <fonso_> but how another user will see it ? [20:31] <llogan> and you do not need super user or root to compile (only to get some dependencies) [20:31] <llogan> but other users can't use it unless you move or install binary or update the $PATH [20:32] <fonso_> so I must update the $PATH ? [20:32] <llogan> that's one method [20:32] <fonso_> I can even remember how to do this [20:32] <fonso_> by the way, the $PATH of the current user so must be modified? [20:33] <fonso_> cause if I go to /root/bin it shows me permission denied [20:33] <llogan> you could do that. probably easiest is to copy the binary to somewhere in the $PATH of all users and see what happens [20:34] <fonso_> just copy from /root/bin/* to an $PATH dir maybe solves my problem?? [20:34] <llogan> i guess so [20:34] <fonso_> thanks, I will try it [20:34] <fonso_> =0) [20:34] <tachyean> helo [20:35] <fonso_> hello [20:35] <tachyean> i'm trying to pipe a rtmp live stream comming from a AMS server trough rtmpdump to ffmpeg, if the stream starts broadcasting after the rtmpdum starts listenning ffmpeg is working as it should ... but if the stream is already started when i'm running the pipe it's like ffmpeg doesn't recognize the header of the video [20:35] <tachyean> hello* [20:35] <tachyean> :) [20:35] <tachyean> any ideea on why that happends? [20:35] <llogan> why not use ffmpeg? it supports rtmp input protocol [20:36] <tachyean> i tryed at first, doesn't work on AMS [20:36] <tachyean> this is the only way i got it working [20:37] <tachyean> rtmpdump -> pipe -> ffmpeg [20:37] <llogan> the actual ffmpeg command and complete console output is always more useful that "doesn't work". [20:38] <llogan> which is the most common "error" in human history [20:38] <tachyean> is there a way to force the header information into the input file? [20:38] <tachyean> i see [20:38] <tachyean> 1 min [20:42] <tachyean> http://pastebin.com/dHADZ8jz [20:43] <tachyean> i`ve used pastebin [20:43] <tachyean> oO [20:43] <tachyean> there is no code pasted in channel [20:45] <tachyean> ffmpeg rtmp rip is working if i try to stream it from nginx but not from AMS [20:45] <tachyean> i'm prety sure it has something to do with the header of the video file [20:46] <llogan> you used pastebin, you included a partial command, and you did not include any of the console output. [20:47] <llogan> ah, mayne that was your complete command? looks weird with the odd option placement [20:47] <tachyean> that was the complete command [20:48] <tachyean> i cannot paste the console output now, i'm not at work anymore :/ and have no access to that stream ... [20:50] <tachyean> i'll try again some other day maybee [20:51] <tachyean> with the console paste ... [20:52] <tachyean> there is no way tho to overwrite the header of a input file on the fly? [21:04] <cadabra> I'm trying to create a really low quality version of a file, for proxy editing purposes. I'm passing "-vf scale=iw/4:-1 -q:v 31 -q:a 31". I'd like to also halve the framerate without changing the timing, but -r won't accept "ir/2". Any suggestions? Any other simple options I could be passing to further minimize the output file? [21:13] <sirEgghead> I have some mkv files that contain subtitle tracks. I'm trying to get them overlayed onto the main video track when I transcode the video, but it is not working. I followed the directions at https://trac.ffmpeg.org/wiki/How%20to%20burn%20subtitles%20into%20the%20vid… to no avail. Here is an example of my command and output. http://pastebin.com/7XQL5VCk The video converts just fine, but there are no subtitles displayed. Obviously the subtitle tr [21:13] <sirEgghead> ack is no longer in the container as well. [21:15] <sirEgghead> llogan, I did. The link is in my message. [21:15] <llogan> and the COMPLETE console output [21:15] <cadabra> llogan: http://pastebin.com/QTr0de75 [21:15] <sirEgghead> The COMPLETE output is about 500 lines that say "sub2video: non-bitmap subtitlee= 226842kB time=00:24:39.05 bitrate=1256.4kbits/s dup=0 drop=247" over and over again. That is the only thing missing from my output that I pasted. [21:17] <sirEgghead> llogan, my terminal buffer doesn't go back far enough to show all of them anyway. But there are 3 lines shown on the output anyway. [21:18] <llogan> sirEgghead: where is the version and configure info? where is the info on the input streams? you can, of course, omit the repeating lines. [21:18] <sirEgghead> llogan, one sec and I will get you the configure info. [21:19] <sirEgghead> llogan, I reran the command and cancelled it as it began so that you may see the initial information. http://pastebin.com/cfkkZpVb [21:20] <llogan> cadabra: libvo_aacenc is worse than the native encoder (and libvo_aacenc ignores -q:a anyway). -f mp4 is superfluous. [21:21] <cadabra> llogan: if I leave out -f mp4, I get "Unable to find a suitable output format for 'GOPR0164.LRV'". It doesn't like the LRV extension. What I really want is "use same encoding as input file" [21:21] <llogan> ah, i didn't see "lrv". [21:22] <vlt> Hello. How do I take the video of one file and the audio of another (video) file (both .mp4 container) and mux them together in copy-only mode? [21:23] <llogan> vlt: ffmpeg -i video.mp4 -i audio.mp4 -map 0:v:0 -map 1:a:0 -codec copy out.mp4 [21:23] <cadabra> Should I pass something other than -f mp4 to switch away from libvo_aacenc? [21:24] <llogan> vlt: also see http://ffmpeg.org/ffmpeg.html#Stream-specifiers-1 http://ffmpeg.org/ffmpeg.html#Stream-copy http://ffmpeg.org/ffmpeg.html#Advanced-options [21:24] <cadabra> I don't think I need -pix_fmt yuv420p, because looking at the camera's original lrv files, they're all yuvj420p anyway [21:24] <llogan> cadabra: you can leave -f mp4. you can try -codec:a aac -strict experimental, but i'm unsure of the -q:a ranges and i doubt it will help that much [21:25] <cadabra> Alright [21:26] <llogan> there is also the fps filter but it does not have "ir" type options: http://ffmpeg.org/ffmpeg-filters.html#fps-1 [21:26] <sirEgghead> llogan, here is a paste that is a little bit better. I hit q once the process started and let it cancel. I hope this has all of the information that you need. http://pastebin.com/ne58Bb3U [21:27] <cadabra> llogan: should I grep and sed the input frame rate out of "ffmpeg -i" to divide it and pass it to -r? Or is that going to get me into some other kind of trouble? [21:28] <cadabra> And what's the difference between -r and the fps filter? [21:28] <cadabra> Other than the additional options [21:28] <llogan> i'm not sure...for any of those questions [21:41] <sirEgghead> I have some mkv files that contain subtitle tracks. I'm trying to get them overlayed onto the main video track when I transcode the video, but it is not working. I followed the directions at https://trac.ffmpeg.org/wiki/How%20to%20burn%20subtitles%20into%20the%20vid… to no avail. Here is an example of my command and output. http://pastebin.com/ne58Bb3U The video converts just fine, but there are no subtitles displayed. Obviously the subtitle tr [21:41] <sirEgghead> ack is no longer in the container as well. Please note that my paste contains output from a command that was started and cancelled so that I could gather the information of my ffmpeg compilation and the media in question and eliminate the unecessary repeating lines. :) [21:56] <cbsrobot> sirEgghead: I guess you need to compile with libfreetype [21:56] <sirEgghead> cbsrobot, ah. Thank you very much. Let me recompile and I will get back to you with the results. [21:57] <cbsrobot> sirEgghead: see http://ffmpeg.org/trac/ffmpeg/wiki/CentosCompilationGuide [21:57] <sirEgghead> cbsrobot, Thanks. :) [21:58] <cbsrobot> and while you're at it add libfdk_aac [21:58] <sirEgghead> cbsrobot, alrighty. [21:58] <beastd> I guess there is more to it. The subtitles are not picture subtitles. That means you should compile with libass [22:00] <sirEgghead> beastd, will do. [22:03] <beastd> sirEgghead: when you have build with those deps. you need to do it this I think: first extract the subtitles with sth like "ffmpeg -i IN.mkv SUBS.srt" then in a second step like described first in the wiki "ffmpeg -i IN.mkg -vf subtitles=SUBS.srt OUT.avi" [22:05] <sirEgghead> beastd, I will try it all out and let everyone know of my results once I am finished. I am installing prereqs at the moment and will recompiled and run another test transcode. I appreciate everyone's input thus far :) [22:26] <vlt> llogan: Thank you. [22:26] <vlt> llogan: Problem: I get an audio only result. [22:27] <vlt> My input #0 has an h264 stream "#0.0", input #1 "#1.0" and "#1.1". [22:29] <vlt> The command you gave says it maps #0:0 -> #0:0 (copy) and #1:1 -> #0:1 (copy) [22:30] <vlt> But tells me "video:0kB audio:2423kB global headers:0kB muxing overhead 1.465455%" in the stats while the result has only a #0.0 audio stream. [22:30] <vlt> Any idea? [00:00] --- Sat Nov 23 2013

1 0

ffmpeg-devel.log.20131121
by burek 22 Nov '13

22 Nov '13

[01:26] <Zeranoe> Could it be possible there is a bug in FFmpeg that is processor specific? This user is reporting a crash with libass: http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1484 [01:27] <BBB> could be optimization that is mislabeled [01:27] <BBB> happens regularly [01:28] <BBB> need backtrace to confirm [01:28] <Zeranoe> BBB: Interesting... I cant reproduce it, but I'll ask him for one [01:29] <Zeranoe> BBB: Is it GCC or FFmpeg? [01:29] <wm4> I'm going to laugh if it's just fontconfig being stuck or so [01:30] <wm4> and by stuck I mean slowly doing its thing of scanning the windows font folder [01:30] <Zeranoe> wm4: Would that produce a crash or a hang though [01:30] <wm4> an apparent hang [01:30] <Zeranoe> Hm [01:31] <Zeranoe> So fonts and backtrace. Anything else to ask from this guy [01:37] <saste> Zeranoe, his blood? [02:02] <BBB> Zeranoe: it'd likely be ffmpeg [02:03] <BBB> Zeranoe: but in some cases (typically this meant someone gave configure weird arguments), it can be gcc also (but then it's really still our bug, telling gcc to use instructions it shouldn't use) [02:07] <Zeranoe> BBB: Well hes using my builds, and I never do anything wrong ever... sooooo [02:16] <BBB> Zeranoe: right, but ffmpeg is also bug-free[tm], soooo :) [02:35] <{V}> must be user error then :) [02:43] <iive> there might be an fontconfig bug. [02:45] <Zeranoe> iive: That only effects certain CPUs? [02:46] <iive> suuuure. well, there was once a user who had some old setup files... unfortunately he removed them and couldn't reproduce the problem anymore. [02:48] <Zeranoe> Off topic: I hate the new gnome in Debian testing. [02:50] <iive> i guess you are late for the party. people have been hating new gnome for years... [02:52] <Zeranoe> I've hated it before this, but before the layout just sucked. Now it doesn't even work. [02:57] <Compn> Zeranoe : debian and ubuntu are on our shit list [02:58] <Zeranoe> Compn: Whats spared, Slackware? [03:02] <Zeranoe> I'm actually curious as to what distro most FFmpeg's devs are using [03:03] <Compn> good question. i dont know [03:03] <Compn> the last one i installed was ubuntu, that was before the ceo decided to be a dick about everything [03:03] <Compn> so i'm looking for a new one as well [03:04] <Compn> arch is popular [03:04] <Zeranoe> Compn: Unity is worse than Gnome [03:04] <Zeranoe> Just by a little though [03:10] <Zeranoe> Wow, theres a whole page for it: http://en.wikipedia.org/wiki/Controversy_over_GNOME_3 [03:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:98fc81b20d63: avformat/utils: move side data merge after parser [03:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:01923bab9850: avcodec: move end zeroing code from av_packet_split_side_data() to avcodec_decode_subtitle2() [03:24] <cone-853> ffmpeg.git 03Michael Niedermayer 07master:f0f75dfa344c: avformat/utils: inject audio skip side data before the side data merge code [03:30] <michaelni> ubitux, the issue outlined in 01923bab9850 might need your attention [03:31] <BBB> Zeranoe: mac :) [03:32] <Zeranoe> I somehow doubt most devs use macs [03:32] <BBB> a few do [03:33] <Zeranoe> michaelni: What do you use as an OS? [03:34] <michaelni> linux (its ubuntu atm, was debian a while ago, iam not really attached to any distro, i might try others ...) [03:36] <michaelni> i do also have various other OSs for testing & development [03:36] <Zeranoe> interesting... Do you know if most devs are using Ubuntu? [03:37] <michaelni> hmm, no idea [03:46] <smarter> BBB: has work begun on multithreading ffvp9? I'd like to help [04:18] <clever> Compn: do you happen to know anything about the h264 format in detail? [04:18] <clever> or anybody else? [04:18] <clever> ive narrowed down my problem to something about the h264 stream not being right [04:18] <Compn> no, i'm mostly a troll here :) [04:19] <clever> i modified my mplayer code to dump the raw bitstream to a file, then aimed the demo app at it [04:19] <clever> and the demo app produces the same problem as mplayer, no output [04:19] <clever> so it must be the bitstream, not my code [04:20] <Compn> or mplayer dump is wrong [04:20] <Compn> howd you dump it ? [04:20] <clever> i added a write() call directly in the draw_slice function, right before i copy it into an omx buffer [04:21] <clever> so its dumping the exact same data i give to the gpu [04:21] <clever> which should be the exact data given to the codec _decode_slice function [04:21] <Compn> unless swscale stepped in [04:21] <Compn> or something nasty like that [04:22] <clever> how would swscale play with the h264 bitstream? [04:23] <Compn> oh i'm thinking of regular vo, not hwaccel [04:23] <Compn> my bad [04:24] <clever> let me throw mkvextract at the problem, rip the h264 stream out of the mkv file properly, and compare things [04:24] <Compn> or mplayer -dumpvideo [04:24] <clever> sample.h264: JVT NAL sequence, H.264 video @ L 41 [04:25] <Compn> there might be an h264 bitstream filter too [04:25] <Compn> not sure if you need that [04:25] <clever> /opt/vc/src/hello_pi/hello_video/test.h264: JVT NAL sequence, H.264 video, main @ L 41 [04:25] <clever> ok, file claims that my sample file is the same as the demo video [04:26] <clever> so if i run the demo app on that... [04:26] <clever> pi@pi ~/ilclient $ time make && time ./video /media/videos/4tb/dcc/sample.h264 [04:26] <clever> Compn: yep, this sample file plays perfectly in the demo app [04:27] <clever> /tmp/bitstream: data [04:27] <clever> but the data being dumped by my vo module, isnt a match [04:27] <clever> decode_slice isnt giving me the right data [04:30] <clever> Compn: let me redo these tests with some sample data that doesnt scream "yar i'm a pirate" [04:30] <Compn> so i was right :) [04:31] <Compn> aww, dont worry, we all know you're a pirate [04:31] <clever> you do, but the omx guys dont :P [04:32] <clever> videotrack: JVT NAL sequence, H.264 video @ L 41 [04:32] <clever> ok, the demo app has no demux ability, it cant handle mkv files [04:32] <clever> and its ignoring ctrl+C [04:32] <clever> and -9 [04:35] <Compn> love it when hardware locks up software [04:36] <clever> Compn: http://www.auby.no/files/video_tests/h264_1080p_hp_4.1_40mbps_birds.mkv holy! [04:36] <clever> that has to be CG?? :O [04:36] <clever> (oh, and the raw video track plays fine on the demo app) [04:51] <clever> Compn: http://pastebin.com/ne5AeJMv look at lines 41-45 vs 48-52 [04:58] <clever> Compn: i also see the vdpau start_code_prefix in the raw video track from an mkv file [04:58] <clever> so it might not be vdpau code, but h264 code [08:14] <wcpan_> hi, does avformat_open_input accept unix domain socket? [08:55] <plepere> in ffmpeg, do I have to add a line somewhere to add my .asm file to compilation or just adding it in the libavcodec/x86 is enough ? [09:17] <plepere> I manually modified the makefile in the libavcodec/x86/. Is this ok ? [09:21] <ubitux> plepere: yes, you have to reference the .o in the Makefile [10:06] <sspiff> ubitux: my patch is not getting any love (or hate!) on the mailing list :( [10:06] <ubitux> sspiff: yeah i'm sorry i need to review it [10:07] <ubitux> what day is today... [10:07] <ubitux> mmh, can you wait until tomorrow? [10:08] <sspiff> ubitux: I can wait until 2014, I was just worried nobody cared anymore! [10:09] <durandal_1707> what patch? [10:10] <ubitux> durandal_1707: dvb fix [10:11] <ubitux> the pkt queue system in ffmpeg [10:11] <ubitux> [FFmpeg-devel] [PATCH] Added queueing for OutputStreams to sidestep DVB subtitle encoding bug. [10:11] <ubitux> this one ^ [10:21] <clever> ubitux: ok, ive almost got hardware decode working [10:22] <ubitux> hw decode? [10:22] <clever> now i need ffmpeg to provide some data from the video track, not sure where to get it from [10:22] <clever> http://pastebin.com/ne5AeJMv [10:22] <clever> do you see the 2 hexdumps in this pastebin? [10:22] <ubitux> oh yeah i remember, the rpi thing, cool thing [10:22] <clever> the dump on lines 48 thru 52, is the data given to hwaccel decode_slice [10:23] <clever> the dump from lines 1 thru 40 is a header in the video track that was stripped out [10:23] <clever> the omx code in the gpu needs that header to function [10:23] <clever> i hacked decode_slice to pull the header from a file on disk and inject it, and everything works [10:24] <clever> but the header is different for every file, and thats just nasty [10:24] <ubitux> did you check extradata? [10:24] <clever> where would the extradata be? [10:24] <ubitux> st->codec->extradata{,_size} [10:24] <clever> *looks* [10:24] <ubitux> av_hex_dump() it [10:25] <clever> AVCodecContext == st? [10:25] <ubitux> AVStream [10:25] <clever> oh, that function would have been usefull [10:25] <clever> all i have in the hwaccel module is a AVCodecContext* [10:25] <ubitux> codec is the codec context [10:26] <clever> oh, so i already have what i want, *tries* [10:26] <ubitux> so av_hex_dump(stdout, avctx->extradata, avctx->extradata_size); [10:26] <ubitux> probably [10:26] <ubitux> hopefully there is something [10:26] <ubitux> and hopefully that's what you're looking for [10:26] <clever> i got the header in the pastebin by running mkvextract on the sample file [10:27] <clever> and then comparing the hexdump to the data decode_slice gets [10:27] <clever> libavcodec/rpi_h264.c:25:2: error: implicit declaration of function 'av_hex_dump' [-Werror=implicit-function-declaration] [10:27] <ubitux> yeah it's in libavformat hehe (doesn't belong here) [10:28] <clever> yeah, i see it now, grep just found it [10:28] <clever> ubitux: did you hear of the double free i found? [10:29] <plepere> it compiles ! but I have a seg fault on a 2D table. to access table[X][Y] of a table[7][16], should I do [table + 16*X+Y] ? [10:31] <ubitux> clever: i remember, somehow [10:32] <clever> so once i get this header problem out of the way, i think the only remaining issue is stuttering and av sync [10:32] <clever> right now, the draw_slice function directly renders frames, skipping draw_image entirely [10:33] <clever> hmmm, i think the stuttering was my debug code, dumping the bitstream to the SD card [10:33] <clever> its smoother now that thats off [10:33] <clever> ubitux: but the hexdump from extradata isnt anywhere near the size [10:34] <clever> its about 0x27 bytes, not ~0x280 [10:34] <clever> oh, its the first 0x27 bytes of the header i want [10:34] <ubitux> maybe some stuff is stripped and only the part you need is available :p [10:34] <clever> hmmmmm, i wonder what will happen if i just try it anyways [10:36] <clever> hmmm, its not an exact match, but it is similar [10:36] <clever> i have no clue how h264 encoding works, so i cant tell what the differences mean [10:37] <clever> i'll let the gpu tell me, simpler [10:39] <clever> ubitux: nope, back to a solid black image [10:40] <clever> whatever that is, it isnt enough [10:40] <ubitux> mmh too bad [10:41] <clever> how much do you know about h264? [10:41] <ubitux> almost nothing [10:41] <clever> ok, so we are in the same boat, lol [10:42] <clever> hmmm, h264.c field_end calls the hwaccel->end_frame function [10:42] <clever> and if its vdpau, it also specialy called ff_vdpau_h264_picture_complete [10:43] <clever> strange, since vdpau uses the hwaccel hooks [10:43] <clever> decode_nal_units handles start_frame [10:44] <clever> and decode_slice [10:47] <clever> ok, decode_nal_units takes a buf and a size in, lets dump that! [10:56] <clever> ubitux: the magic buffer is in there! [10:56] <ubitux> great :) [10:56] <clever> but this appears to be called for every packet of data [10:56] <clever> need to isolate which one is the magic header, and somehow feed it to the hwaccel [10:57] <clever> with almost no clue what i'm actualy looking for [10:57] <clever> and to make things a bit worse, the header goes thru decode_nal_units before it loads my hwaccel module [10:57] <clever> so i have to store it somewhere in the codec data [10:58] <clever> No such audio driver 'alsa' [10:58] <clever> aha, thats why i cant hear anything! [11:00] <clever> ubitux: which package was that in debian based systems? [11:00] <ubitux> like i know ._. [11:00] <clever> i'll just grab my old ubuntu box to death [11:01] <clever> ./alsa/asoundlib.h [11:01] <clever> libasound2-dev.list:/usr/include/alsa/asoundlib.h [11:01] <clever> ah, thats why i couldnt find it, alsa isnt in the name [11:06] <ubitux> plepere: http://pastie.org/8497757 [11:08] <plepere> ok thanks [11:11] <plepere> hmm, still gives a seg fault [11:18] <sspiff> hmmm, I'm trying to skip MPEG demuxing, but it seems like my packets still need to pass by the dvbsub_parser, and don't [11:19] <sspiff> how can I make the packets I pass to decode_subtitle2 go through the parser first? [11:19] <wm4> wow that's some verbose spam [11:20] <sspiff> that's some messed up markov chain action :) [11:22] <wm4> how did they even get the idea to spam TRAC [11:22] <wm4> or do they just scrape the internet for post forms [11:24] <ubitux> you think they have AI to look for registering/login logics, and post randomly? [11:24] <ubitux> (i mean generic logic, not a trac specific code) [11:25] <wm4> why not [11:25] <sspiff> wm4: they just look for post forms with a textarea [11:26] <sspiff> ubitux: I would think so, why the hell would you target TRAC specifically? [11:26] <ubitux> yeah that's what i'm wondering [11:26] <sspiff> not only is it low yield (spamming a blog comment is likely to get more views than something on trac, people watching track generally know not to click on any links in this kind of thing) [11:26] <ubitux> maybe because it's easy (they most likely have a template) [11:27] <sspiff> my parentheses are wrong, but whatever! [11:27] <sspiff> ubitux: could be, but I think they just "try" register forms [11:27] <ubitux> also, the point is to pollute the internet; so they might expect search engines to crawl them [11:27] <plepere> dafuq I just read :) [11:28] <sspiff> plepere: I think http://en.wikipedia.org/wiki/Markov_chain#Markov_text_generators [11:28] <sspiff> ubitux: good point [11:28] <sspiff> crawlers do hit trac, so if trac is easy, they might target trac [11:28] <clever> sspiff: that reminds me, my wiki has been flooded with spam, sometimes i sit down and delete 100 articles in a row [11:28] <clever> its getting thru even with email validation enabled [11:29] <sspiff> clever: all you need is a bot that can set up webmail accounts or your own domains [11:29] <ubitux> michaelni: can you give me permissions to delete trac entries? [11:29] <ubitux> or just delete this shit yourself :p [11:29] <clever> sspiff: i checked, every single one was @hotmail.com [11:29] <clever> i'm back to 7 pages of spam on my wiki [11:29] <clever> i should sit down and nuke it again [11:30] <ubitux> also, we could add a very simple captcha [11:30] <plepere> actually, for SteamOS, do we have any info on the tech behind its "gaming" over LAN ? [11:30] <ubitux> another quite method is to add hidden input [11:30] <ubitux> +useful [11:31] <ubitux> input(s) [11:31] <sspiff> ubitux: yeah but isn't that easy to fix for the spammers? [11:31] <ubitux> and if one or more hidden input is filled, you fail [11:31] <ubitux> sspiff: not that simple [11:31] <ubitux> because you need to evaluate css [11:31] <sspiff> ah right [11:31] <sspiff> I see [11:31] <clever> ubitux: the wiki software has a hidden input with a noonce code, you must read the page, and return the right code in that input to get thru [11:31] <sspiff> yeah, I thought <input type=hidden> [11:32] <clever> i had trouble with that when writting a greasemonkey script to delete with 1 click [11:32] <ubitux> clever: some kind of captcha/question [11:32] <ubitux> but that's annoying for users [11:32] <clever> yeah [11:44] <michaelni> ubitux, tiket deleted [11:44] <ubitux> thx [11:45] <clever> ubitux: i'm off to bed now, letting things recompile with alsa before i take another stab at things [11:45] <ubitux> :) [11:50] <ubitux> Daemon404: don't wanna use trap? [11:50] <ubitux> also IFS=$'... will add a $ in IFS [11:51] <michaelni> about trac spam: [11:51] <michaelni> Feb 21 13:47:44 <michaelni> also in case i worded it unclearly, some volunteer needs to get us api keys for akismet and the others listed at http://trac.edgewall.org/wiki/SpamFilter with exception of where they key is just for training the external service) [11:51] <michaelni> Nov 09 18:12:30 <michaelni> kierank, trac supports several spam filter services, like akismet, typepad, defensio, http:bl. But all these need API keys AFAIK. If someone provides such keys i can enter them in trac, that may (or may not) improve spam filtering [11:52] <ubitux> Daemon404: i think you want either IFS=$'\n' or what you have without $, 'need to check [11:52] <ubitux> also, rm -f instead of rm, and probably in the trap EXIT [12:02] <saste> ubitux: you going to review my ffprobe patches? [12:02] <saste> otherwise i'll probably push the whole patchset, since nobody is going to review it [12:04] <ubitux> i have tons of things to review :( [12:07] <cone-461> ffmpeg.git 03Sean McGovern 07master:a7b87ca9111b: libxavs: rename and fix a variable name [12:07] <cone-461> ffmpeg.git 03Michael Niedermayer 07master:074b89f1e235: Merge commit 'a7b87ca9111bafb220ab94d53ab4e4ed48111800' [12:17] <cone-461> ffmpeg.git 03Martin Storsjö 07master:ea9f7173ae91: configure: Avoid requiring c99wrap for working around msys path issues [12:17] <cone-461> ffmpeg.git 03Michael Niedermayer 07master:8c9df116cd57: Merge remote-tracking branch 'qatar/master' [12:27] <Daemon404> ubitux, thatbisnt portable [12:27] <Daemon404> it was originally that [12:27] <Daemon404> doesnt worknon bsd [12:31] <ubitux> Daemon404: yes but current version is not correct [12:31] <ubitux> it includes a '$' in the IFS [12:33] <Daemon404> oh the 2nd has $ [12:33] <Daemon404> yes that should be removed [12:42] <BBB> smarter: yeah, mostly done already [12:42] <BBB> smarter: but I can put it up and you can finish it if you like, I did most of the plumbing, the progress reporting itself is basically outstanding [12:43] <BBB> oh and one refactoring [12:45] <smarter> BBB: did you both frame-threading and tile-threading? [12:46] <smarter> *do both [12:48] <ubitux> saste: what's the patch order for ffprobe? [12:48] <ubitux> nested option and then string validation? [12:48] <ubitux> am i missing one? [12:53] <cone-461> ffmpeg.git 03Clément BSsch 07master:4e70eeef3a5e: cmdutils: randomize spaces after 69cf626f9. [12:56] <saste> ubitux: lavu/avstring: add av_utf8_decode() function [12:57] <saste> ffprobe: check for errors, and abort immediately [12:57] <saste> ffprobe: add support for nested options in writer contexts [12:57] <saste> ffprobe: implement string validation setting [12:58] <saste> i'm automatically setting utf8 validation flags depending on the writer [12:58] <saste> i could expose them as well, as writer generic options, but then it will need more automatic setup [12:58] <saste> and i suppose users won't be happy in case they have metadata in weird charsets, which is unfortunately very likely [12:59] <saste> ffprobe: implement string validation setting [12:59] <saste> this is the patch which affects interface the most, so that's the one which needs a second look [13:02] <BBB> smarter: only frame so far; tile is easier actually [13:02] <BBB> smarter: I can leave tile for you if you want, it's not hard, just some mild trickiness with the loopfilter [13:15] <smarter> I could try :) [13:16] <smarter> I haven't done anything related to threading in ffmpeg/libav yet [13:22] <Compn> smarter : we could use vc1 threading too, i think :) [13:23] <ubitux> why not let it die instead? [13:23] <smarter> less interesting :P [13:26] <BBB> vc1 should die, yes [13:26] <saste> ubitux: av_malloc() and childrean [13:27] <BBB> sure, you can tile-mt, it's not super-hard, ask questions :) [13:27] <av500> but porn needs vc1 [13:27] <BBB> you need synchronization if you want to do the loopfilter inline [13:27] <saste> don't think that comprises av_realloc() [13:27] <BBB> since it crosses tile boundaries [13:30] <ubitux> saste: dunno, i see realloc in the code [13:31] <saste> wow, running unsharp from libavutil, now that's a hack [13:33] <wm4> it just takes some seconds! [14:09] <plepere> ok, I'm getting slightly annoyed by this. preparing a pastebin of all the data I got. [14:14] <michaelni> /home/fate/fate/x86_64-debian-asan-144800/install/lib/libavcodec.a: No space left on device [14:17] Action: michaelni deletes 1.5g of crap [14:17] Action: Compn getting ready to install 4TB drive [14:20] <plepere> http://pastebin.com/WUw29Uws [14:21] <plepere> so basically, r7 is supposed to be a value, but gives me an error, and I only get a good value by copying the lower byte from r7 to another register. [14:22] <plepere> "my" is between 1 and 8 [14:22] <plepere> or 7 [14:22] <nevcairiel> is this on 64-bit? [14:23] <plepere> yes [14:23] <cone-461> ffmpeg.git 03Michael Niedermayer 07master:fdc0b3f8c19f: avcodec/utils: remove unused variable [14:23] <nevcairiel> the fucntion parameter is an int, so you might need to zero-extend it, i guess [14:24] <plepere> doesn't it do it by default when putting an argument in a register ? [14:24] <nevcairiel> there was a reason that all of the stride parameters where changed to ptrdiff_t so the compiler zero-extends for you [14:25] <plepere> ok [14:25] <plepere> so I need to change the type to uint8_t or ptrdiff_t ? [14:25] <nevcairiel> %if ARCH_X86_64 [14:25] <nevcairiel> movsxd r2, r2d [14:25] <nevcairiel> %endif [14:25] <nevcairiel> something like this is done in many other places [14:25] <plepere> ok [14:25] <plepere> ah, it explains a lot ! [14:26] <plepere> thanks [14:27] <plepere> yay, runs now ! [14:47] <cone-461> ffmpeg.git 03Xidorn Quan 07master:973b1a6b9070: vda_h264_dec: backup context before overriding [14:47] <cone-461> ffmpeg.git 03Michael Niedermayer 07master:78bfc417d430: Merge branch 'master' of https://github.com/upsuper/ffmpeg-vdadec [15:58] <sspiff> ubitux: are you clement? [15:58] <ubitux> yes [15:58] <sspiff> alright [16:05] <sspiff> for my patch: the remuxing (-map and -scodec copy) doesn't work, but this is a different problem (the data is present in the TS but doesn't show up to the decoder, I haven't figured out why yet) [16:05] <sspiff> the recoding to dvbsub (-scodec dvbsub) case works [16:06] <sspiff> I originally intended to keep track of only one packet, but the problem is that the subtitles can overlap randomly, that's why I introduced the queue [16:06] <ubitux> what is "the decoder"? did you try with mplayer/mpv or vlc? [16:07] <sspiff> we're talking about subtitle-only TS'es, so no [16:07] <ubitux> subtitles can overlap randomly? is your code handling that? [16:07] <sspiff> yes [16:07] <sspiff> and in the sample, subtitles don't dissappear before 2 or 3 more subtitles have appeared (or more) [16:08] <sspiff> so you need to keep track of all the pending "clear" packets [16:08] <sspiff> the code is dirty (the dvb sub specific code in there was already pretty hacky tbh), I know [16:08] <ubitux> so multiple sub starting at different ts, and all of them being clear later? [16:08] <ubitux> (can you clear just one of them?) [16:09] <sspiff> ubitux: I think so, I'll have to check, but I think so [16:09] <sspiff> I'll see if I get the same appear/disappear sequences as the original, but playing a recoded sample with vlc worked fine IIRC [16:18] <ubitux> sspiff: did you contact marton btw? [16:19] <ubitux> he had to deal with a similar issue with the dvb teletext decoder [16:19] <ubitux> i don't know what's the state of this [16:20] <ubitux> and really, if you could fix the dvb subtitles properly (instead of adding a workaround in ffmpeg.c) that would be great [16:20] <sspiff> I'll do some tests, fix the tabbing issue, and switch to av_packet_ref/av_packet_unref [16:21] <sspiff> I haven't talked to marton yet [16:21] <sspiff> ubitux: the problem is that I don't know of a way to trigger the clear packet out-of-sequence from the codec [16:21] <sspiff> since they generate AVSubtitles, not AVPackets [16:22] <sspiff> I understand that you'd prefer a real fix, but I'm not entirely sure that's possible with the current API [16:22] <sspiff> caching the packets in the encoder might work, I'll check it out [16:22] <sspiff> haven't really looked to much at encoding [16:55] <ubitux> why do the cosmetics guys insist on breaking inline if/switch-cases :( [18:48] <cone-171> ffmpeg.git 03Vittorio Giovara 07master:305d3d9f1f7f: mpeg4videoenc: restore macro parentheses [18:48] <cone-171> ffmpeg.git 03Michael Niedermayer 07master:bc140fb568df: Merge commit '305d3d9f1f7f0bdc18744f376a0ff5b012e4e6cf' [19:04] <cone-171> ffmpeg.git 03Vittorio Giovara 07master:874838dc6589: fate: add one select filter test [19:04] <cone-171> ffmpeg.git 03Michael Niedermayer 07master:a486dec4fd8f: Merge commit '874838dc6589d978611c89a40694a5074f892a76' [19:08] <cone-171> ffmpeg.git 03Vittorio Giovara 07master:d28fc7b29a72: avconv_filter: add new line after error message [19:08] <cone-171> ffmpeg.git 03Michael Niedermayer 07master:c8a0a2e990ba: Merge commit 'd28fc7b29a728bd2f88c10121abbd0442c341746' [19:14] <cone-171> ffmpeg.git 03Vittorio Giovara 07master:dd249245d012: filter docs: reference scale and fps filters [19:14] <cone-171> ffmpeg.git 03Michael Niedermayer 07master:c0caf7e81493: Merge commit 'dd249245d012c1eceb57c166e256fc95e74f4bb1' [19:31] <cone-171> ffmpeg.git 03Diego Biurrun 07master:ac0e03bab001: dct/fft: Give consistent names to fixed/float template files [19:31] <cone-171> ffmpeg.git 03Michael Niedermayer 07master:6a7980e2cd4b: Merge remote-tracking branch 'qatar/master' [20:40] <llogan> michaelni: https://trac.ffmpeg.org/ticket/222 last comment is spam with attachment [20:40] <llogan> same with https://trac.ffmpeg.org/ticket/993 [20:49] <michaelni> llogan, why do you tell me ?, you should be able to delete them i think [20:50] <michaelni> i mean if you click on the attachment then theres a button "delete attachment" [20:50] <michaelni> or did i forgot some permission? [20:56] <ubitux> llogan: "TIP XX: add -f xv - at the end of your transcode line to visually follow the status" [20:56] <ubitux> (or sdl or whatever) [21:08] <llogan> michaelni: yes. user error. there was no delete option until i clicked on the attachment. [21:09] <llogan> i tohught it was a comment with an attachment, but it is an attachment with a comment [21:10] <llogan> but i can't get rid of "domtheo" user...if it exists [21:10] <llogan> ubitux: thanks! [21:15] <llogan> ubitux: it really slows down encoding [21:16] <ubitux> s/xv/sdl/ for more portability [21:16] <ubitux> but only 1 window allowed [21:16] <ubitux> (sdl2 might be a better output) [21:16] <ubitux> (i've heard it supports multiple output windows, and it's more portable than xv) [21:35] <michaelni> llogan, domtheo deleted [21:39] <mraulet> michaelni: some commits merge to our master brnch [21:40] <mraulet> https://github.com/OpenHEVC/FFmpeg/compare/243eb17278...829c7ac690 [21:54] <michaelni> mraulet, adding a field in the middle of AVCodecContext breaks ABI (unless all fields afterwards where accessed only through wrapers) [21:54] <michaelni> also the patchset seems to break fate-h264-lossless [21:58] <michaelni> and theres trailing whitespace in there (our git hooks reject such commits so i would not be able to push that [21:58] <michaelni> ) [22:34] <mraulet> ok [22:38] <mraulet> https://github.com/OpenHEVC/FFmpeg/commit/12bbfdba1899d11044d2bd8457159fc8b… [22:38] <mraulet> https://github.com/OpenHEVC/FFmpeg/commit/b68d306b3b29bda8351b1702e6a55654e… [22:39] <mraulet> and https://github.com/OpenHEVC/FFmpeg/commit/14341c6d9a6885657ba365807223e96a6… [22:39] <mraulet> can be applied [22:47] <michaelni> libavcodec/hevc.c:379:36: error: PTL has no member named general_PTL [22:53] <cone-670> ffmpeg.git 03gcocherel 07master:0afa254d4efd: hevc : fix pcm(cherry picked from commit 12bbfdba1899d11044d2bd8457159fc8b4b52a76) [22:53] <cone-670> ffmpeg.git 03gcocherel 07master:81d0252dacc2: hevc : update hls_decode_neighbour(cherry picked from commit 14341c6d9a6885657ba365807223e96a67d6c0ed) [23:07] <ubitux> why is the "cherry-pick" message inlined? [23:07] <ubitux> is it a bug in -x? [23:08] <Eduard_Munteanu> I'm thinking of patching a mplayer slave-like interface into ffplay, to control it. Would such a change be accepted? [23:09] <ubitux> lol [23:10] <ubitux> mplayer slave thing is shitty, that's one of the reason it was dropped from mpv [23:10] <ubitux> you should consider a better approach [23:11] <cone-670> ffmpeg.git 03Clément BSsch 07master:616da5954268: avcodec/x86/vp9dsp: merge a few SWAP together. [23:13] <michaelni> ubitux, dont ask me if its a bug in -x or a feature [23:14] <ubitux> it's supposed to be added in the description [23:14] <ubitux> at least that was the case last time i used it [23:14] <ubitux> this inline thing looks broken somewhere [23:22] <cone-670> ffmpeg.git 03Stefano Sabatini 07master:98786aa2f05d: lavfi/aevalsrc: initialize pointer to expression to NULL [23:24] <ubitux> BBB: so using rsp to play with the stack will also work on 32-bit? [23:24] <ubitux> (not that it matters much in my case since i'm using the 16 xmm registers but i'm curious) [23:31] <cone-670> ffmpeg.git 03Stefano Sabatini 07master:50a28b13936b: doc/examples: do not check NULL values for avcodec_close() [23:34] <BBB> ubitux: cglobal func, args, gprs, xmmregs, stack_memory, names[] [23:34] <BBB> ubitux: if you don't ever need rXm, use -stack_memory, which indicates it won't use an extra register [23:35] <BBB> ubitux: i.e. saves a reigster, may sometimes be relevant [23:39] <Eduard_Munteanu> ubitux: yes, I don't mean to duplicate it [23:40] <Eduard_Munteanu> Right now I just need a way to queue files for playing. [00:00] --- Fri Nov 22 2013

1 0

ffmpeg.log.20131121
by burek 22 Nov '13

22 Nov '13

[00:30] <grkblood> im trying to figure out a way to pipe a live stream to ffmpeg for transcoding but I'm failing pretty badly. This is what I have so far. The stream in the command is from npr. How can I make this work? wget http://nprdmp.ic.llnwd.net/stream/nprdmp_live01_mp3 | ffmpeg -i pipe:0 -f ogg -acodec libspeex pipe:1 | mplayer - -cache 1000 [00:31] <relaxed> mplayer can play that stream directly. [00:31] <grkblood> right, but this is just an example [00:31] <grkblood> the core of what I'm trying to do is for something else [00:32] <grkblood> I got it anyways. wget -O - http://nprdmp.ic.llnwd.net/stream/nprdmp_live01_mp3 | ffmpeg -i pipe:0 -f ogg pipe:1 | mplayer - -cache 1000 [00:33] <relaxed> why are you involving wget? [00:34] <grkblood> to pipe to ffmpeg [00:34] <grkblood> is there another way to pipe a live straem in to stdin of ffmpeg? [00:34] <relaxed> ffmpeg should be able to decode the stream as well. [00:35] <grkblood> well, just piping in the link to the stream doesnt work for me [00:36] <relaxed> ffmpeg -i 'http://nprdmp.ic.llnwd.net/stream/nprdmp_live01_mp3' ... [00:37] <grkblood> yea, that doesnt work for me [00:38] <grkblood> did you test that? [00:38] <relaxed> this works here: ffmpeg -i 'http://nprdmp.ic.llnwd.net/stream/nprdmp_live01_mp3' -c:a libvorbis -f ogg -y /dev/null [00:39] <relaxed> upgrade ffmpeg if it doesn't for you. [00:39] <relaxed> http://johnvansickle.com/ffmpeg/ [00:39] <grkblood> im on ubuntu and using the packaged version with avconv right now [00:40] <grkblood> ill try it in a bit on a vm [00:41] <grkblood> thanks [00:41] <relaxed> work with my avconv too [00:41] <grkblood> Unrecognized option 'c:a' [00:41] <grkblood> Failed to set value 'libvorbis' for option 'c:a' [00:42] <grkblood> thats what i get [00:42] <relaxed> use -acodec instead [00:45] <grkblood> ya, that seems to record but then when I try to pipe it to mplayer instead with ...-acodec libvorbis -f ogg pipe:1 | mplayer - -cache 1000 I start havign issues again [00:46] <grkblood> something with piping and streams that ffmpeg doesnt seem to like [00:47] <grkblood> Stream #0.0 -> #0.0 [00:47] <grkblood> Press ctrl-c to stop encoding [00:47] <grkblood> [mp3 @ 0x142f520] Header missing [00:47] <grkblood> Error while decoding stream #0.0 [00:47] <grkblood> Cache fill: 4.90% (50143 bytes) size= 49kB time=17.31 bitrate= 23.2kbit [01:29] <relaxed> grkblood: ... -f ogg pipe:1 2>/dev/null | mplayer ... [01:31] <grkblood> thanks [06:04] <qasd_> Hi. How to set videodevice (vebcam) for grabbing? [06:04] <qasd_> *in windows [06:06] <qasd_> for example: ffmpeg -i ??? out.avi [06:08] <qasd_> what i could to write instead of (???) ? [06:25] <qasd_> why option list-indevs do not work in ffmpeg on windows? [06:35] <relaxed> qasd_: https://trac.ffmpeg.org/wiki/How%20to%20capture%20a%20webcam%20input [07:07] <qasd_> relaxed: thank you [08:56] <sspiff> can someone tell me what parsers in ffmpeg are, and where they fit in the pipeline of formats, codecs and filters? [11:31] <Valdiralita> hey, can i convert a video to an mp3 and add a album cover without calling ffmpeg twice? [11:34] <plepere> I'm currently playing videos with ffplay using ffplay -i <video path> [11:35] <plepere> but the player doesn't stop when the video is done. is there an option to close the player once the decoding is done ? [11:35] <ubitux> -autoexit [11:35] <ubitux> (it's useful to seek back after the end) [11:36] <ubitux> Valdiralita: yes [11:37] <plepere> thanks [11:38] <plepere> works like a charm [11:38] <plepere> well, the player part at least [11:42] <Valdiralita> ubitux, so, how can i achive this? i tried this but it just creates a normal mp3 file: ffmpeg -i "1.mp4" -i "1.jpg" -b:a 320K -vn -n -map 0 -map 1 "out.mp3" [11:43] <ubitux> and it didn't work? [11:43] <Valdiralita> no [11:43] <ubitux> (what's -n?) [11:44] <ubitux> ah, no overwrite k [11:44] <Valdiralita> afaik to overwrite existing file [11:44] <Valdiralita> doenstn matter now :p [11:44] <ubitux> it's the opposite effect [11:44] <ubitux> -y force overwrite [11:45] <Valdiralita> http://hastebin.com/lukofehima.hs [11:45] <Valdiralita> here you go [11:48] <Valdiralita> the out.mp3 file i a regular mp3 file without a cover [11:48] <relaxed> won't -vn block the jpg? [11:49] <Valdiralita> yeah, i want to block the video from the mp4 and get an image instead [11:50] <relaxed> ffmpeg -i "1.mp4" -i "1.jpg" -b:a 320K -map 0:a -map 1:v "out.mp3" [11:51] <Valdiralita> yeah, that worked. thank you! [11:51] <relaxed> ffmpeg treats the jpg as a video stream too, so -vn was blocking it. [11:52] <relaxed> I wish -*n would go away [11:53] <Valdiralita> okay, so this is just setting the inputs to the corresponding video and audio streams [11:54] <relaxed> 0:a = audio from first input; 1:v = video from second input [11:54] <Valdiralita> ok, just what i thought. thanks [12:02] <Romain___> hi, I'm trying to create a swf file from a gif (animated), the problem is that ffmpeg doesn't seems to support transparency, someone would have an idea? [12:02] <Romain___> sry for english.. [12:05] <Romain___> i've tried to use gif2swf instead, but it's very bugged.. [12:19] <Eduard_Munteanu> Hi. Any chance I could control ffplay through a FIFO / pipe, to implement an automated player? I just need to load and seek into files. [12:26] <relaxed> Eduard_Munteanu: you can with mplayer [12:27] <Eduard_Munteanu> Hm, I was trying to avoid mplayer. Unless... [12:27] <Eduard_Munteanu> Can mplayer sync time to the system clock? [12:28] <Eduard_Munteanu> I sort of implemented it myself but I'd rather not go there again. [12:30] <Eduard_Munteanu> Oh... [12:31] <Eduard_Munteanu> I think I can just concat my streams into a loop and run ffplay on it. [13:47] <surviv0r> guys i have one quick question: can i chain muxers. for example tee and segmenter ? [13:52] <surviv0r> i'm generating x264 mp4 and HLS segments with the exact same params with this command http://pastebin.com/nPTHRpRU can i chain them the reserve some CPU power [14:09] <saste> surviv0r, tee [14:13] <surviv0r> saste, tee seems to not accept options with no value like - flag -global_header check out the command and output here http://pastebin.com/5WQEbgeJ [14:16] <efyx> Hi, I just updated my ffmpeg and I get a bunch of "ffmpeg/libavcodec/avcodec.h:1040:16: warning: 'destruct' is deprecated" and "warning: 'priv' is deprecated" [14:16] <efyx> Is this normal? [14:19] <saste> surviv0r, wrong syntax [14:19] <saste> flags:global_header this is wrong [14:20] <surviv0r> what would be the right syntax? flags=-global_header ? [14:23] <saste> surviv0r, -flags:v +global_header ... /tmp/currentTest2/720/DC0017400000.mp4|[bsfs/v=dump_extra:f=segment:segment_time=10:segment_list=/tmp/currentTest2/720/playlist.m3u8:segment_format=mpegts]/tmp/currentTest2/720/stream%04d.ts" [14:25] <saste> see also http://ffmpeg.org/ffmpeg-bitstream-filters.html#dump_005fextra [14:25] <saste> note that it will increase overhead, since both global and key-packets header will be kept [14:26] <saste> i don't think there is some way to avoid it [14:45] <surviv0r> well now here's the output after fixing the syntax http://pastebin.com/CJPCvQhV [14:45] <surviv0r> and after trying to fix the error message here's what happened http://pastebin.com/qbHz9guh [14:56] <Eduard_Munteanu> Is there an efficient transport for ffserver "broadcasting" to localhost? [14:57] <MrPingouin> hello world [14:57] <Eduard_Munteanu> I wonder if I can use ffserver to decode videos and submit them to a player. [14:58] <ryannathans> Eduard_Munteanu: streaming? [14:59] <MrPingouin> does anyone knows if there's an easy way to handle padding when using videofilter drawtext + frame number ? [14:59] <Eduard_Munteanu> ryannathans: not really, I'm writing an application to control and play files in a loop. I was wondering if I can control ffserver and wire its output into ffplay. [14:59] <MrPingouin> for now it's working like 0, 1, 2, etc, I would need 00000, 00001, etc [15:00] <MrPingouin> I guess it might be possible writing an expression, but I was lookin for some kind of "%05d" syntax [15:12] <saste> surviv0r, -flags +global_header, and remove the -bsf:a option [18:46] <Bella> hi [18:46] <Guest78329> i'm trying to use vlc as a source for ffmpeg, udp local connection and i get [mpeg4 @ 0292b080] get_buffer() failed (-22 00000000) [18:47] <Guest78329> [mpeg4 @ 0292b080] releasing zombie picture [18:58] <mikepack> Question: I'm looking to concatenate 2 mp4 videos together, and I'm wondering if it's possible to join the two without having to re-transcode them again as it's creating the output (joined) mp4. Any help is appreciated! [19:01] <Guest78329> use mp4join [19:03] <therube> mikepack: https://trac.ffmpeg.org/wiki/How%20to%20concatenate%20%28join,%20merge%29%2… [19:05] <mikepack> therube: thanks, but I think that reencodes the output [19:06] <mikepack> Guest78329: thanks! I'm looking for something like that that's usable programmatically (from the command line) [19:06] <therube> not necesasrily [19:09] <Guest78329> mikepack use mp4box [19:10] <mikepack> therube: is there a way to not reencode it? [19:10] <mikepack> Guest78329: thanks! [19:10] <Guest78329> nope [19:20] <fonso> Hey there, I have a question about FFMPEG installation on Amazon EC2 server. Is there any tutorial to do this? [19:21] <Guest78329> no [19:25] <fonso> Well thanks. [19:26] <Guest78329> what do you want to do ? [19:27] <fonso> Install ffmpeg in a amazon aws instance, but my linux knowledge is very tiny... [19:28] <therube> mikepack: http://pastebin.com/W6MbmzrQ [19:28] <klaxa> fonso, usually you can just install it through the distro's package manager [19:28] <klaxa> alternatively you can download a static build [19:29] <klaxa> static builds only depend on the kernel and the libc i think [19:29] <fonso> Tnx a lot. [19:29] <Guest78329> http://ffmpeg.org/trac/ffmpeg/wiki/CentosCompilationGuide [19:30] <mikepack> therube: I think that's reencoding the file, though I'm not entirely sure. Looks like it from line 49 [19:32] <therube> mikepack: no it is not. so long as the file "parameters" are the same, it need not re-encode. it can simply join, without reencode, in a few seconds [19:34] <Guest78329> if the sizes are the same [19:38] <mikepack> therube: Thanks. Is there a good way to verify it's not reencoding? [19:42] <therube> mikepack: use the same command line, but remove the '-c copy', so you'll have, ffmpeg -f concat -i flist out.mp4 & you'll see that it does reencode [19:44] <mikepack> therube: I'll play around with that, thanks! I appreciate your help [19:45] <therube> note "copy" vs "mpeg4 -> libx264)", Stream #0:1 -> #0:0 (copy), Stream #0:1 -> #0:0 (mpeg4 -> libx264) [19:57] <BeWilled> Hello, I have one question please. Is there a program to detect the resolution, bitrate and codec...etc of a video? [19:58] <sacarasc> ffprobe can do it, so can mediainfo. [20:00] <BeWilled> thanks [20:10] <Guest78329> Bewilled you can use ffmpeg for that [20:10] <Guest78329> with onlyl the file as a parametre [20:10] <Guest78329> only* [20:11] <BeWilled> Guest78329: in machine readable format? [20:12] <sacarasc> ffprobe is the part of ffmpeg that does that, it can output to multiple different formats. As can mediainfo. [20:12] <Guest78329> i just use java to split infos [20:12] <Guest78329> it's easy [20:13] <Guest78329> no need of probe [20:13] <sacarasc> That's silly. [20:13] <Guest78329> nothing is silly when you can do it easily [20:14] <sacarasc> You could do it easier other ways, though, so it is silly. [20:22] <Bella11911> hi [20:24] <Bella11911> when i use ffmpeg with an udp source i get get_buffer() failed [20:26] <jezeniel> guys how can i add two or more filters in ffmpeg? i am using -af afade=t=in:ss=0:d=2;afade=t=out:st=35:d=2 OUTPUT [20:27] <jezeniel> btw i am using -af afade=t=in:ss=0:d=2,afade=t=out:st=35:d=2 OUTPUT comma not semicolon but the second filter doesn't work only the fade in [20:28] <Bella11911> https://trac.ffmpeg.org/wiki/FilteringGuide [20:30] <jezeniel> Bella11911: i've read that. but the audio part (afade specifically what i am trying to use) did not mention how to use both fade in or fade out in one command.. [20:32] <Bella11911> ffmpeg -i INPUT -af afade=t=in:st=50:d=4,afade=t=out:st=125:d=5 OUTPUT [21:01] <fonso> bye! [21:07] <Bella11911> getting zombie pictures error with an udp source , any help ? [21:27] <Bella11911> http://pastie.org/8499245#1 [21:28] <Bella11911> sometimes after a while it works and sometimes not [21:28] <norbert_> not such which channel to ask this, but would you say "lame -V0 -q0 --vbr-new" is better or "lame --preset cbr 320", if I can pick either? [21:29] <norbert_> it's about encoding, so I decided to ask here :P [21:36] <Plorkyeran> v0 is normally equal in quality to 320 at a nontrivially smaller size [21:37] <norbert_> ok, I'll pick the V0 line then :) [21:42] <llogan> Bella11911: that's not the complete output [22:03] <Bella11911> how's that not complete ?? [23:08] <Rager> hi [23:08] <Rager> I'm trying to use libffmpeg from JNI, and I don't really know where to start [23:09] <Rager> my end goal is to transcode arbitrary videos (probably h263 or h264, based on what android creates) into x264 mp4's [23:09] <JEEB> unfortunately libffmpeg is not something provided by ffmpeg [23:09] <Rager> oh, bother [23:09] <JEEB> ffmpeg contains various libraries, but none of them are called libffmpeg :) [23:09] <Rager> libffmpeg.so was built from the ffmpeg sources [23:10] <JEEB> yes, it's probably a library that uses the ffmpeg libraries underneath [23:10] <JEEB> but you can't exactly ask here how to use something we have no idea of :) [23:10] <Rager> it's a library file I literally compiled *from the ffmpeg source* [23:10] <Rager> like [23:11] <JEEB> uhh [23:11] <Rager> the actual official git repos for ffmpeg and the required libs for the various formats [23:11] <JEEB> you do not get a libffmpeg.so or .a from ffmpeg [23:12] <JEEB> you get libavcodec, libavformat, libswscale, libswresample, libavresample, libavdevice, libpostproc... [23:12] <JEEB> if I remembered them all :P [23:12] <JEEB> if you want help on the libraries ffmpeg provides, then this is the right place [23:13] <Rager> I guess to figure out what to ask you [23:13] <Rager> I need to figure out how to relate to you what this lib file I'm working with is [23:14] <JEEB> ok [23:15] <JEEB> what you seem to be talking of [23:15] <JEEB> is [23:15] <JEEB> https://github.com/lince/libffmpeg-c [23:15] <Rager> no [23:15] <JEEB> that creates a libffmpeg.so [23:15] <Rager> that is not what I am talking about: this is - https://github.com/bubbanat/AndroidFFmpeg [23:15] <Rager> the code that gets compiled into the "libffmpeg.so" file in question is from these repos: https://github.com/bubbanat/AndroidFFmpeg/blob/master/.gitmodules [23:16] <Rager> this script is what actually builds it: https://github.com/bubbanat/AndroidFFmpeg/blob/master/FFmpegLibrary/jni/bui… [23:17] <Rager> ah, it's just a lib created by this script that has the aforementioned libraries in it, I believe [23:17] <Rager> (the ones you said that you get) [23:18] <JEEB> yes, it's a wrapper library around quite a few libraries it seems [23:18] <Rager> what would I use to tear apart the binary to see the symbol table? [23:19] <Rager> sorry, that was silly - installing a tool, now [23:19] <JEEB> have you already looked at the example they have in their repo? [23:20] <Rager> I've been reading and trying to understand, yes [23:20] <Rager> also been trying to understand ffmpeg's sample code for decoding a video stream [23:21] <Rager> but that one doesn't explain how to deal with container formats [23:21] <JEEB> I just used the current avformat/avcodec APIs some time ago [23:21] <JEEB> for the first time [23:21] Action: JEEB usually codes within lavc/lavf [23:21] <JEEB> didn't seem too hard :) [23:22] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/examples/demuxing_decodi… [23:22] <JEEB> this one is a relatively good example [23:23] <Rager> I guess part of the problem is that I don't understand the workflows at hand, here [23:24] <JEEB> it's pretty straightforward to get started [23:24] <JEEB> 1) av_register_all() [23:24] <JEEB> registers all formats etc. [23:25] <JEEB> 2) create a AVFormatContext pointer with avformat_alloc_context() [23:25] <JEEB> or well, create the actual thing with the function [23:25] <JEEB> and have a pointer to it [23:26] <JEEB> 3) if you don't want to do any special I/O, just open a file with avformat_open_input() [23:27] <JEEB> 4) do basic checks on the input with avformat_find_stream_info() [23:27] <Rager> going through that code you linked and trying to trace out the logic of the steps [23:28] <JEEB> and at the point of avformat_find_stream_info() you should now have a basic list of the streams in the file [23:30] <Rager> ok [23:31] <Rager> at that point, I have an input file, an output file, and stream information on the input file [23:33] <sirEgghead> I have some mkv files that contain subtitles. I would like to select these subtitles when converting with ffmpeg. At https://trac.ffmpeg.org/wiki/How%20to%20burn%20subtitles%20into%20the%20vid… it says to use the "-filter_complex" option. I followed the directions exactly and I get "ffmpeg: failed to set value '[0:v][0:s]overlay[v]' for option 'filter_complex'" in return when trying it out. [23:36] <Rager> I'll keep reading, JEEB [23:36] <sirEgghead> http://pastebin.com/wRTEfXU3 for the full input and output for my problem. [23:39] <JEEB> Rager, if it's files and you don't need any custom IO for them that you'd need to wrap around, then using libavformat as-is for the file interaction should be fine :) [23:39] <JEEB> one lavf context for input, another for output [23:47] <saste> sirEgghead, ffmpeg version N-32076-g4ca6a15, Copyright (c) 2000-2011 -> two years old ffmpeg [23:49] <sirEgghead> saste, that might do it. Lol. [23:49] <sirEgghead> saste, sounds like the last time I compiled it. [23:50] <sirEgghead> saste, would you know if my command was good for the subtitles? [23:50] <sirEgghead> Would at least like to know I'm not just spinning my wheels. :) [23:50] <saste> i hope so [23:50] <saste> you'll need to update anyway [23:51] <sirEgghead> Alrighty. Let me do that and I'll get back with you. Thank you very much. [23:53] <sirEgghead> I haven't updated it in so long for a couple of reasons. 1. Because it's been doing everything I need it to just fine, until now. 2. I don't remember all the options I used to compile it. :P [00:00] --- Fri Nov 22 2013

1 0

ffmpeg-devel.log.20131120
by burek 21 Nov '13

21 Nov '13

[00:29] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:f95b5d2a114e: cmdutils: cosmetics [00:29] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:05493c6e724a: avcodec/avpacket: correctly set the number of side data elements in av_copy_packet_side_data() [00:29] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:df87cfd798d1: ffmpeg: fix do_streamcopy() so it copies side data too [00:46] <michaelni_> wm4, 1120 0:42 To FFmpeg devel (1.9K) [FFmpeg-devel] [PATCH] [RFC] avformat/options_table: do not merge sidedata by default [02:37] <BBB> ubitux: I'm not sure my patch is actually a good idea, I'm considering retracting it [02:37] <BBB> ubitux: it doesn't play well with frame-mt [03:25] <cone-128> ffmpeg.git 03Michael Niedermayer 07release/2.1:9422cd85a081: update for 2.1.1 [04:08] <cone-128> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.1.1': unknown revision or path not in the working tree. [04:08] <cone-128> Use '--' to separate paths from revisions [04:08] <cone-128> refs/tags/n2.1.1:HEAD: ffmpeg: fix do_streamcopy() so it copies side data too [04:22] <cone-128> ffmpeg.git 03Tim Walker 07master:ffb0af7f17eb: ac3dec: simplify an expression [04:22] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:61f40fbb528d: Merge commit 'ffb0af7f17eb0da86e9b140e86a1404d3c6c9e79' [04:45] <cone-128> ffmpeg.git 03Derek Buitenhuis 07master:03f6d4e0f168: win{32,64}: Hard disable symbol versioning [04:45] <cone-128> ffmpeg.git 03Michael Niedermayer 07master:bb7f3ddd4254: Merge remote-tracking branch 'qatar/master' [09:23] <ubitux> BBB: ok [09:23] <ubitux> BBB: you're working on mt? [09:56] <ubitux> BBB: there is indeed quite some time spent in idct 16 and 32 [09:57] <ubitux> also strangely in the memset of decode_b [09:58] <ubitux> heh, and loop filters [10:01] <ubitux> http://b.pkh.me/vp9cg.png [10:07] <saste> llogan, you there? [10:07] <ubitux> i'd like to know too [10:09] <saste> i'm reading the ubuntu compilation guide, and it is confusing, especially for new users [10:09] <saste> with lot of non-working path magik [11:02] <ubitux> michaelni: "also converting between sample rates needs a delay" (swr) [11:03] <ubitux> what is this delay used for? [11:03] <ubitux> i'm doing a 48k to 44.1k, there is a delay of 16, except at the first call [11:03] <ubitux> i'm wondering why [11:04] <ubitux> also, the rescale rounding formula used to estimate the output buffer size is over estimated by a large margin [11:14] <plepere> hmmmm [11:15] <plepere> I'm trying to use a table declared in a .h when I'm in asm [11:15] <plepere> did a cextern hevc_epel_filters [11:15] <plepere> with ff_hevc_epel_filters being the table called in C [11:15] <plepere> relocation R_X86_64_32 against `ff_hevc_epel_filters' can not be used when making a shared object; [11:15] <plepere> I get this error when compiling [11:17] <plepere> it's telling me to recompile with -fPIC, but I'm already compiling with that [11:49] <highgod> Hi, I want ask a question about hevc decoder, does ffmpeg write it or using OpenHEVC? Thanks [11:51] <JEEB> it's smarter's decoder. OpenHEVC project uses it as well. OpenHEVC has also developed some features and optimizations in smarter's decoder [11:51] <nevcairiel> openhevc was a fork from smarters work, who wrote it for libav [11:51] <nevcairiel> so basically, it was a collaboration between the two [11:52] <highgod> JEEB: what is smarter's decoder? Thanks [11:52] <JEEB> basically the "OpenHEVC" part as such is just the C++ API they made around a hacked-up libavcodec [11:53] <JEEB> highgod, it is what smarter wrote as libav's summer of code project last year, and has been more or less looking at how the development has continued since [11:58] <ubitux> plepere: i think you need to duplicate it [11:59] <nevcairiel> how do other things do that? i saw the h263 loop filter has a table, for example [12:00] <ubitux> plepere: mmh maybe using cextern [12:00] <ubitux> ah my bad. [12:00] Action: ubitux gets a brain [12:01] <nevcairiel> h263_loop_filter_strength is used in h263 asm, the table is defined in some other C file [12:01] <nevcairiel> so somehow it works [12:01] <michaelni> ubitux, you can do it without a delay, its then called nearest neighghbor resampling [12:02] <ubitux> michaelni: where is the code doing that? [12:02] <nevcairiel> it loads the address of the table into a register and then uses that register to calculate stuff, it doesnt use the table directly in address calculatons [12:02] <nevcairiel> not sure if that matters [12:02] <michaelni> ubitux, it was a joke [12:02] <ubitux> :( [12:03] <michaelni> you need a delay if you want it to sound in a way a human will be wiling to listen to [12:03] <nevcairiel> ubitux: in short, any quality resampling has a dealy ;) [12:03] <ubitux> mmh [12:04] <ubitux> so i was willing to avoid resampling all my data but i guess i'd better not do it [12:04] <ubitux> how/where is the delay estimated? [12:04] <ubitux> also, why is the delay estimate so high with the given formula? [12:05] <michaelni> the delay is half the filter length (within rounding more or less) [12:06] <ubitux> ok [12:06] <Compn> let me check the copyright [12:06] <Compn> oops [12:06] <michaelni> it can differ from that though when compensating inaccurate sample rates (that is what -async did) [12:06] Action: Compn lagged [12:16] <michaelni> but i guess if it differs with "async" actually depends on how you define delay [12:21] <ubitux> michaelni: is it safe to flush with swr_convert() and then start again a convert like nothing happened? [12:28] <michaelni> flushed would have to be reset and the buffer contents would have to be cleared otherwise there would be extra samples output from the flushing i think [12:30] <michaelni> see resample_flush() for the cod that adds the samples [12:30] <ubitux> yes sure i'm clearing my output buffer after the flushing, and the input buffer is somehow reset [12:30] <ubitux> unless you mean sth else? [12:30] <michaelni> SwrContext.flushed [12:32] <ubitux> (would it be safer to re-call swr_init()?) [12:32] <michaelni> its the simple solution [12:32] <ubitux> it's leak safe? [12:33] <michaelni> you have many questions :) [12:33] <ubitux> :D [12:33] <michaelni> it should be i think [12:33] <michaelni> but anything can be buggy [12:34] <michaelni> also if someone write a testcase that compares continuing after flush with and without init then iam happy to fix it so both produce the same output [12:35] <ubitux> i might write a test case [12:35] <ubitux> i'm assuming it's useful in case of seeking [12:35] <michaelni> hmm, yes could be [12:36] <ubitux> speaking of seeking am i the only one to expect some kind of laggy a/v sync catch up after seeking with ffplay? [12:36] <ubitux> i thought i opened a ticket for this but i can't find it anymore [12:36] <ubitux> maybe i just complained on irc actually. [13:05] <BBB> ubitux: yeah, I noticed that too [13:06] <BBB> I'm almost considering doing 32x32 and 16x16 partially in intrinsics, it's just such a pain to do it in plain asm [13:06] <BBB> but I'm not sure yet [13:06] <BBB> I needed something else for the little time I have, and 32x32 is just too much ATM :( [13:06] <BBB> so mt seemed useful [13:09] <plepere> is it not OK to use intrinsics in ffmpeg ? [13:12] <ubitux> BBB: we don't have any intrinsics, i'd say it's not a good idea [13:12] <ubitux> and well, i can try to do it if you don't want anymore [13:13] <ubitux> BBB: do intrinsics, objdump, copy paste, optimize :p [13:15] <ubitux> BBB: did you start 16x16? [13:26] <BBB> ubitux: no [13:26] <ubitux> should i? [13:26] <BBB> ubitux: I basically haven't touched any code for at least 4 weeks now, except for an odd patch [13:26] <BBB> yeah please do [13:26] <BBB> you know the logic from the 8x8 [13:26] <ubitux> 16x16 so? [13:27] <ubitux> yeah well i cheated with 8x8 [13:27] <BBB> the only thing to keep in mind is to do the 16x16 in 2 8x16 passes [13:27] <BBB> and store the result on the stack between the two passes [13:27] <ubitux> on the stack, ok [13:27] <BBB> for an example, see e.g. h264 mmx 8x8 or so [13:27] <ubitux> ok [13:27] <BBB> like the C code does [13:28] <ubitux> what about the transpose? [13:28] <BBB> so pass 1, transpose, store, pass1, transpose, store, pass 2, add_and_store, pass2, add_and_store [13:28] <BBB> for the full one [13:28] <ubitux> oh mmh [13:28] <BBB> and then the 8x8/4x4/2x2/1x1 become just trivial simplifications thereof [13:29] <ubitux> ok [13:41] <ubitux> BBB: the 16x8 will require to play with the stack though [13:41] <BBB> yes likely [13:41] <ubitux> i probably need to do a 2x8x8 [13:41] <BBB> well you can't really do that right [13:41] <BBB> all parts of the 16x8 interact with each other [13:42] <ubitux> yeah right [13:42] <BBB> you can't easily separate the 16x8 in anything smaller that is not 16xsomething [13:42] <ubitux> but i mean i can't process 16 at once [13:42] <BBB> you can do 16x4, but that doesn't help at all except when on mmx ;) [13:42] <BBB> right, yes [13:42] <BBB> so you need to swap stuff to/from stack when needed, just like a regular compiler would do with c functions [13:42] <BBB> and the trick is to do that "optimally" [13:43] <BBB> that's why I was thinking intrinsics for 16x16/32x32 (still written in the 16x8 per pass method, ofc) [13:46] <ubitux> you think the compiler will deal well playing with the stack? [13:47] <nevcairiel> just do what ubitux suggested, look at what the compiler did and clean the code :p [13:51] <nevcairiel> and while i personally like intrinsics for some quick inline optimizations, they seem to be frowned upon [13:57] <BBB> ubitux: it did ok in libvpx, but very version/brand-specific [13:57] <BBB> ubitux: e.g. you'll run into clang and gcc and msvc doing different things [13:57] <BBB> ubitux: it'll work, but it'll perform differently [13:57] <BBB> and that may not be what you want [13:58] <BBB> ubitux: but it'll work ok yes, that's what compilers are optimized for, finding dependency paths and minimizing the amount of "stuff" they have to do to a binary to give the same output as your code [13:58] <BBB> I'm not sure though [14:20] <saste> llogan, ping [15:47] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:cccdaa406a29: avcodec/h261enc: avoid use of current/previous_mba [15:47] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:6c04c5f733d3: avcodec/h261enc: dont use current_mv_x/y [15:48] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:ec312c1fd0d8: fate: test -mbd rd for h261 [15:59] <Daemon404> hey Compn do you know if you have a sample of 24-bit wma lossless? [15:59] <Daemon404> i can only find 16 bit in the archive [16:23] <cone-814> ffmpeg.git 03Clément BSsch 07master:3e69f7c22106: avfilter/showspectrum: add win_func option. [16:23] <Daemon404> Compn, nvm found one [16:23] <ubitux> no window is really bad [16:24] <ubitux> and hamming is definitely worse than hann [16:24] <ubitux> any win func suggestion welcome [16:25] <merbanan> blackmann is the best [16:25] <ubitux> ok [16:25] <merbanan> with my definition of best [16:30] <wm4> so, can Ben Boeckel's ogg mid-stream tag update patches be merged? [16:37] <merbanan> yes coz of his name [16:37] <merbanan> good name [16:38] <cone-814> ffmpeg.git 03Clément BSsch 07master:9c8b24080638: avfilter/showspectrum: add blackman window. [16:38] <cone-814> ffmpeg.git 03Clément BSsch 07master:9343fc30e28c: avfilter/showspectrum: reindent const options. [16:38] <cone-814> ffmpeg.git 03Clément BSsch 07master:ddaf543aa663: avfilter/showspectrum: use 0 dummies for range in const. [16:39] <ubitux> merbanan: thx [16:43] <merbanan> was it nicer ? [16:43] <ubitux> i can't really tell [16:43] <ubitux> it looks too similar to hann [16:44] <ubitux> merbanan: you can try with ./ffplay -f lavfi amovie=bla.mp3,showspectrum=mode=separate:color=intensity:slide=1:scale=cbrt:win_func=blackman [16:56] <ubitux> merbanan: http://lucy.pkh.me/winfunc/ [16:57] <merbanan> do you do any overlap ? [16:57] <ubitux> what do you mean? [16:57] <ubitux> (this was generated with for f in none hann hamming blackman; do ./ffmpeg -i ~/music/heart.flac -filter_complex showspectrum=mode=separate:color=intensity:slide=1:scale=cbrt:win_func=$f -ss 10 -frames:v 1 -y showspectrum_$f.png; done) [16:58] <merbanan> you should overlap the spectrum rendering to get rid of the block artifacts [17:00] <merbanan> ie do more fft's then needed [17:02] <ubitux> mmh yeah that could be nice to add [17:03] <merbanan> the output will look much better [17:41] <cone-814> ffmpeg.git 03Ben Boeckel 07master:1e506a2cc586: avcodec: add side_data type for updated metadata [17:41] <cone-814> ffmpeg.git 03Ben Boeckel 07master:51a84a6bca61: avpacket: add pack/unpack functions for AVDictionary [17:41] <cone-814> ffmpeg.git 03Ben Boeckel 07master:c28b61caf0e3: Document new APIs for av_packet_{un, }pack_dictionary() [17:41] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:fcb1b0078d38: avcodec/avpacket: use size_t, fix potential integer overflow [18:47] <cone-814> ffmpeg.git 03Ben Boeckel 07master:34b7c82dd3d7: avcodec/utils: use the unpack_dictionary function [19:34] <wm4> michaelni: your recent size_t commit would leak data if allocation of a more than 2GB sized metadata side data element succeeded [19:34] <wm4> maybe that's pedantic, OTOH I don't know why to limit side data at 2GB, and not, say 100 MB or SIZE_MAX [19:47] <michaelni> 100mb could be done >int_max cannot as the size is returned in a int [19:47] <michaelni> ill fix the leak in a moment [19:50] <michaelni> one could of course also switch to size_t, though iam not sure if that woudnt just move the need of the check to the callers [19:51] <cone-814> ffmpeg.git 03Michael Niedermayer 07master:e50278348a31: avcodec/avpacket: fix order of operations in case of too large allocation [21:41] <kwizart> hello, [21:41] <kwizart> shall we enable thumb on ARM (armv7hl) by default ? [21:42] <kwizart> for a 'general purpose' distro binary built ? [21:43] <kwizart> specially current libavcodec/arm/dca.h has: [21:43] <Compn> no idea [21:43] <kwizart> #if HAVE_ARMV6_INLINE && AV_GCC_VERSION_AT_LEAST(4,4) && !CONFIG_THUMB [21:43] <Compn> if an arm device doesnt have thumb support, does it crash ? [21:43] <kwizart> and the alternative is neon (which cannot be assumed because of tegra2) [21:44] <Compn> i'd just try with/without thumb on a bunch of devices and report speed benchs to find out if yay or nay :P [21:44] <Compn> instead of aks first, just benchmark first :) [21:44] <kwizart> I think all armv7 has thumb, but I undertand thumb as a reduced instruction set [21:44] <Compn> or wait for arm master to awaken [21:46] Action: Compn afk [21:47] <kwizart> ok thx [00:00] --- Thu Nov 21 2013

1 0

ffmpeg.log.20131120
by burek 21 Nov '13

21 Nov '13

[03:02] <ryannathans> I did a .\ffmpeg.exe -i G:\11\%04d.jpg -codec:v libtheora -qscale:v 10 output.ogg every odd second of the video is the first frame [03:02] <ryannathans> What did I do wrong? [03:05] <ryannathans> Oh wow. My image sequence is corrupted. [03:20] <shevy> does ffmpeg accept more than one file via -i ? [04:07] <relaxed> shevy: yes, ffmpeg -i 1.ext -i 2.ext ... [04:37] <shevy> relaxed ok cool [07:07] <ryannathans> With ffmpeg, am I able to pull frames from a cctv card (already done, in jpg form) and encode them to a video realtime? [07:07] <ryannathans> I guess it's a jpeg stream encoded to ogg [13:17] <Samus_Aran> I was testing encoding a short clip at various libx264 -preset's: slow, medium, fast, ultrafast. they all came out to 60MB, except for the ultrafast which was 82MB [13:17] <Samus_Aran> any idea why the presets aren't changing the output size at all over that huge range? [13:18] <Samus_Aran> sample command: ffmpeg -y -threads 1 -i 00145.MTS -acodec pcm_s16le -filter:v 'scale=2048:-1, unsharp=luma_amount=1.3' -vcodec libx264 -preset medium -crf 14 -sn test-2K-crf14-medium.mkv [13:19] <JEEB> the crf value does not mean the same thing over presets [13:20] <JEEB> anyways, there _is_ a difference between the presets, just that ultrafast is the "dumbest", and thus you most probably get a relatively big change with that [13:21] <JEEB> just pick the slowest preset that is fast enough for your use case [13:22] <JEEB> (note: I wouldn't be surprised if with the same crf and one of the slower presets you'd actually get a _bigger_ file than with some of the faster ones, because the encoder will "see" more things, which of course also affects the results of the CRF algorithm) [13:22] <Samus_Aran> 640KB difference between fast and slow, not really worth using the slower ones, I guess [13:22] <Samus_Aran> my computer takes ages on medium [13:22] <JEEB> as my note just mentioned, you can't really just compare the file sizes between presets :P [13:22] <JEEB> since the result is not the same [13:23] <Samus_Aran> right. I don't get why they make video encoders so confusing [13:23] <JEEB> but yes, if you have a slow PC and you want it to go faster, that is a proper reason to just pick a faster one [13:24] <Samus_Aran> it just seemed odd that there was an enormous jump of 22MB when there's only a 640KB jump between slow and fast [13:24] <Samus_Aran> I should try the veryfast one and see how that goes [13:26] <Samus_Aran> when I was playing with crf, and capturing a single frame to compare, it was easy to tell apart crf0 and crf18, which I thought was supposed to be visually lossless [13:27] <Samus_Aran> crf14 and crf0 look slightly different, but it's hard to notice one being better or worse [13:28] <JEEB> there is no one true number [13:28] <JEEB> one of the most generic reasons for that is first of all that people have different perceptions of quality [13:29] <Samus_Aran> I am very impressed with the unsharp mask filter on content from my Sony camera, combined with the upscaling it looks better than the original [13:29] <Samus_Aran> I'm upscaling so YouTube gives more bits when it downscales [13:29] <Samus_Aran> now I want to try out other filters, there's so many [13:29] <JEEB> second of all, if you encode f.ex. SD stuff and then view it on a HD screen you will have the artifacts zoomed, so they matter more [13:30] <JEEB> so yeah... you can generally find your preferred CRF value depending on the type of the source (animation, computer generated graphics, live action with grain etc. etc.) and the resolution [13:31] <Samus_Aran> I almost always need to use unsharp mask on photos from this camera, as they are always under-sharp. didn't know I could do it so easily for video [13:31] <Samus_Aran> super impressed [13:31] <Samus_Aran> when I was comparing single frames at various crf values, sometimes one area of the image would be better at one crf, and another area worse [13:32] <Samus_Aran> like line definition versus shaded areas [13:32] <JEEB> I really am not going to go into that because it's up to you how to rape your video @ filtering . Just gonna say that it's a brain thing with sharpening, at least with quick comparisons your brain will like the "sharper" picture. [13:33] <Samus_Aran> for me the difference is things like fabric that actually look like fabric once sharpened [13:33] <Samus_Aran> blurry mess otherwise [13:34] <Samus_Aran> I'm going to be fiddling with the amount so it's not overdone [13:40] <Samus_Aran> veryfast at crf14 is 5MB less than fast [13:42] <Samus_Aran> it doesn't make any sense at all how -preset slow can produce an 8% larger file than -preset veryfast [13:46] <JEEB> <JEEB> (note: I wouldn't be surprised if with the same crf and one of the slower presets you'd actually get a _bigger_ file than with some of the faster ones, because the encoder will "see" more things, which of course also affects the results of the CRF algorithm) [13:50] <Samus_Aran> JEEB: that doesn't explain an enormous 8% difference in the opposite direction from fast to veryfast [16:34] <Mavrik> hmm, is there a case where DVB subtitles might have different DTS than PTS? [16:57] <dharriso> Hi guys im using the ffmpeg API to transcode an MP4 file that contains a single track audio file. This works as expected no problems. My question is why does the MP4 file have twice the amount of sample than the input audio file. So input file has 5768 samples and the output has 1156 samples [16:58] <dharriso> Im using ffmpeg 0.8, libfdk for AAC audio encoding [16:58] <viric> 0.8? very old [16:58] <dharriso> viric: yes i know [16:59] <dharriso> we are looking to upgrade sometime soon but we have legacy [17:09] <LithosLaptop> maybe the output sample rate doubled? [17:15] <dharriso> LithosLaptop: I keep sample rate, channels the same as the original but reduce the bitrate by 50% [17:16] <dharriso> sample rate is 44100 [17:16] <dharriso> input audio is HE-AAC LC v1 [17:17] <LithosLaptop> and output is LC-AAC? [17:19] <dharriso> yes [17:19] <dharriso> AAC LC 44100, 2 channels [17:21] <dharriso> so is that the ssue going to LC for HE-AAC [17:21] <dharriso> showing my ignorance of these details [17:21] <LithosLaptop> 44.1Khz HE-AACv2 = LC-AAC 22.05Khz + SBR Info to recreate 44.1Khz [17:23] <dharriso> so is that what you wuld expect in relation to doublin the samples [17:23] <dharriso> i mean doubling the number of samples [17:24] <LithosLaptop> to confirm maybe encode try encoding to HE-AAC with -profile:a aac_he [17:25] <LithosLaptop> *to confirm maybe try encoding to HE-AAC with -profile:a aac_he [17:25] <dharriso> yes will try that now thanks [17:26] <LithosLaptop> or -profile:a aac_he_v2 [17:27] <dharriso> alternaively reduce sample rate to 22050? [17:27] <dharriso> will try this now [17:33] <slackerr> how to tell ffmpeg make progressive frame while encoding if source is interlaced [17:42] <dharriso> LithosLaptop: set the profile to HE-AACv2 as you suggested and now I get the same number of samples as before [17:43] <dharriso> i mean the same number of sample for input and output 5768 [17:43] <dharriso> this is what i wanted to understand thanks [17:45] <LithosLaptop> cool [17:45] <LithosLaptop> no prob [17:49] <dharriso> LithosLaptop: recommend any reference material i could read some background on this [17:51] <LithosLaptop> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.129.4563&rep=rep1&… [17:59] <dharriso> LithosLaptop: thanks [18:06] <K1978> Hi! I am wondering if this http://superuser.com/questions/678450/copy-multiple-parts-of-a-video-to-a-s… is possible using ffmpeg? [18:09] <therube> speaking of HE-AAC & in particular on lower bitrates, 32kbps, on playback, when i seek, i'l typically hear "glitches", pops or "tears". is that "normal" or some sort of failure in the decoder? [18:12] <therube> i notice that in MPLayer, ffplay, MPC, perhaps less so in VLC, not certain, & then a quick look with Winamp, it was hard to determine because they reduce output volume level on seeking (or something like that) [18:19] <therube> [aac @ 029e02e0] Reserved SBR extensions is not implemented. [18:48] <viric> screen -r [18:48] <viric> oops [18:49] <klaxa> tmux > screen [18:52] <viric> I'm lazy to relearn. But GPL > BSD [18:53] <Mavrik> yellow > brown [19:00] <klaxa> e^(pi * i) <3 [19:01] <viric> agreed [19:57] <Zeranoe1> When using -vf ass=subtitles.ass should the subtitles be burned onto the resulting video? I'm not seeing them show up. [20:00] <cbsrobot> Ithink you can use subtiles=file.ass nowadays [20:00] <cbsrobot> *subtitles=file.ass [20:01] <cbsrobot> if you have freetype and fontconfig enabled it should work [20:04] <Zeranoe1> I'm not seeing them in the output video... But I don't get any errors and libass seems to be reading each line [23:45] <mbrain_> hi, i have 20.000 images and i want to create a timelapse video but it will be huge video. so i want to input every 60th photo. like 001.jpg 061.jpg 122.jpg... [23:46] <mbrain_> what should be the input pattern? [23:49] <mbrain_> no one? :( [00:00] --- Thu Nov 21 2013

1 0