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

[burek]

[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 at 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%20Pi%20%28Raspbian%29 ?
[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