[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%20... ? [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