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

[burek]

[00:08] <llogan> saste: what do you think about moving the compile guide from using Git to source snapshots? 6MB vs ~60MB (shallow Git repo) vs ~130? MB full git
[00:09] <saste> llogan, what compile guide?
[00:09] <llogan> Ubuntu
[00:09] <saste> provide both instructions, assuming the user wants to update
[00:10] <saste> otherwise just suggest to use the snapshot
[00:10] <llogan> updating is simple with snapsho too. just download a new one
[00:10] <saste> indeed i don't like git is used for external libs (I'd prefer just to download snapshot)
[00:16] <clever> i'm wondering, how does ffmpeg and h264 deal with B frames exiting the decoder out of order?
[00:17] <clever> saste: you could also use a shallow git clone, which wont get the entire history, but can still update easily
[00:19] <llogan> clever: that's what the guide in question is currently doing
[00:19] <clever> ah
[00:19] <clever> the problem i can see with downloading a whole new checkout, is that its not as compact as a diff would be
[00:20] <wm4> can a shallow clone actually git pull?
[00:20] <clever> yeah
[00:20] <llogan> apparently. although when users "git pull" the shallow repo it becomes almost as large as the full repo
[00:20] <llogan> side effect is that ./version.sh acts weird
[00:20] <clever> ah yeah, i can see how that would happen
[00:20] <clever> pull will just get ANY missing objects
[00:20] <llogan> it you expect N-59728-g77d2a1c version will report N-39025-g77d2a1c
[00:21] <llogan> on a shallow pulled repo
[00:21] <clever> but it think there is pull --depth also
[00:21] <llogan> why didn't i think of that?
[00:21] <llogan> git is hard. lets go shopping.
[00:22] <clever> i find that git is better then svn, i'm able to make commits on my changes without having to ask for any kind of admin access
[00:25] <saste> llogan, if you want my opinion, snapshots for external libs, and git clone for ffmpeg
[00:25] <saste> but that's somehow subjective
[00:25] Action: saste going to bed
[00:25] <llogan> i was going to ask why exactly...
[00:26] <clever> wm4, llogan: do either of you happen to know some of the h264 decoder details?
[00:26] <llogan> clever: no, sorry.
[00:27] <saste> llogan, because that way it's easer to update ffmpeg
[00:28] <saste> external libs don't need to be updated so often
[00:28] <clever> i think i want to do something with AV_PICTURE_TYPE_B after reading h264.c
[00:29] <llogan> saste: i'm not sure how often users are followign the update instructions. once in a while because i notice the verison weirdness...but i'll give the snapshots a try.
[00:31] <wm4> clever: what are you even messing with?
[00:31] <clever> wm4: omx decode on the raspberry pi
[00:31] <wm4> I don't think asking random people whether they know something will lead to much progress
[00:31] <clever> the frames are exiting the hw decoder out of order
[00:31] <clever> 1 2 0 5 4 3 7 6 9 8 12 11 10 15 14 13 18 ...
[00:32] <clever> it seems to be because the B frames are referencing 'future' frames which where encoded into the file as 'past' frames, so they are available at the right time
[00:32] <clever> and they have to be re-ordered before rendering
[00:33] <nevcairiel> did you create a whole new decoder now, or a hwaccel for the h264 decoder?
[00:33] <clever> hwaccel modile within h264
[00:33] <clever> module*
[00:33] <nevcairiel> it should handle re-ordering for you then
[00:33] <clever> and due to latency in the hardware decoder, i'm returning frames late
[00:34] <clever> when you ask for frame #5, i output frame #4 or #3
[00:34] <nevcairiel> that will break it :)
[00:34] <clever> yeah, i wondered about that when i first set it up that way
[00:34] <nevcairiel> it'll give you the bitstream of a frame, and it expects that frame back
[00:34] <nevcairiel> or re-ordering wont work
[00:34] <clever> it takes about 0.03 seconds to return the frame i think
[00:34] <clever> and it wasnt having enough cpu time left to actualy run at real-time
[00:35] <clever> i'll see if i can undo that mess
[00:37] <clever> nevcairiel: the other major issue i have, is that the api is async, so i have to just block on a mutex in rpi_h264_end_frame and waste cpu time while waiting for a frame to decode
[00:38] <clever> so the thread is completely tied up until the gpu is done
[00:38] <nevcairiel> sounds like the api is horrible
[00:38] <clever> you call a fill function, and at some point in the future, it runs a callback on its own thread
[00:39] <clever> but ffmpeg expects things things right away, so i have to add pthread_cond_wait to the end_frame function
[00:40] <clever> and if rendering and decoding run in the same thread, pthread_cond_wait completely halts all rendering
[01:08] <smarter> BBB: I forgot, how do you do cycle counting when optimising assembly?
[01:08] <smarter> I think you used some code from ffmpeg
[01:10] <cone-535> ffmpeg.git 03Michael Niedermayer 07master:7f9697aa114c: avformat/nutdec: fix packet end clearing
[01:11] <michaelni> smarter, one way is START/STOP_TIMER
[01:12] <smarter> right, that's what I was trying to remember
[01:13] <smarter> michaelni: can you use them to benchmark part of a function in assembly?
[01:17] <smarter> I guess I can just put them around the C code and hope there's not too much noise
[01:19] <michaelni> yes, also the less code is executed the more you would have to expect to see effects from the benchmark code itself influence the result
[01:19] <michaelni> so even if you could put *_TIMER between each asm instruction the result would be meaningless
[01:22] <smarter> I see :)
[01:23] <smarter> also I think the perf tool should help to understand the impact of each instruction, once I'll understand how it works
[02:15] <Zeranoe1> Any ideas why FFmpeg might be encoding the audio of a file to have one less frame than the video?
[02:17] <Compn> Zeranoe : what command line
[02:18] <Zeranoe1> Compn: More of a general question, it's actually amv-codec-tools which uses an old FFmpeg. I keep having playback issues because one audio frame less keeps ending up in the output file
[02:20] <Zeranoe1> could it have anything to do with frame types?
[02:21] <cone-535> ffmpeg.git 03Michael Niedermayer 07master:4162ceea9368: avformat/mxfdec: check avio_read(UID) result
[02:22] <michaelni> Zeranoe1, amv is intra only so there should be no b frames
[02:23] <Daemon404> well he said audioframe
[02:23] <Daemon404> isnt it just adpcm?
[02:24] <Compn> amv is crap, so i'm not surprised there are problems
[02:24] <Zeranoe1> Daemon404: It's a little different, the device will only play amv audio from amv-codec-tools
[02:24] <llogan> Zeranoe1: are you in China?
[02:24] <Compn> Zeranoe : wasnt there an amv fix in a recent ffmpeg ?
[02:25] <Zeranoe1> llogan: No, this is for someone else who is too cheap to buy decent hardware...
[02:25] <llogan> i hope you charge them enough to make it up
[02:26] <llogan> Skinflint tax
[02:26] <Zeranoe1> lol
[02:26] <michaelni> also are you sure, that the problem you see is related to there being a frame less ?
[02:27] <Zeranoe1> Yes, the format error on the device happens only at the very end, and it will play any video with the same number of frames. Took me forever to get to this point 
[02:29] <michaelni> maybe ask nicolas about it, he worked on the end of stream code in ffmpeg IIRC
[02:43] <Zeranoe1> Is there any way to force ffmpeg to mux a adpcm_ima_wav? I don't think it supports it
[02:50] <cone-535> ffmpeg.git 03Justin Ruggles 07master:aa69cbc9e082: flac muxer: add option to disable writing the global header
[02:50] <cone-535> ffmpeg.git 03Michael Niedermayer 07master:3b8299c1e1c7: Merge commit 'aa69cbc9e08281db6ecb98a2c8b4f60e8b12e558'
[02:59] <michaelni> Zeranoe1, what do you mean by mux ?
[02:59] <michaelni> if you mean encode a file with adpcm_ima_wav as audio codec, theres -acodec for that
[03:01] <Zeranoe1> michaelni: Sorry I meant adpcm_ima_amv, which FFmpeg cant encode. Can I mux it if I can encode it with something else?
[03:02] <michaelni> probably not, i faintly remember there was some trickery needed for amv audio
[03:23] <cone-535> ffmpeg.git 03Vittorio Giovara 07master:a7d0e7ead95e: lavfi: add framepack filter
[03:23] <cone-535> ffmpeg.git 03Michael Niedermayer 07master:402a41140685: Merge commit 'a7d0e7ead95e584c4866617f046b2493066975c6'
[03:34] <cone-535> ffmpeg.git 03Vittorio Giovara 07master:11d704dc94c0: fate: add framepack filter test
[03:34] <cone-535> ffmpeg.git 03Michael Niedermayer 07master:7f2367fb9ec0: Merge commit '11d704dc94c029058ac366f85951f6728638fb9c'
[03:36] <cone-535> ffmpeg.git 03Vittorio Giovara 07master:d44bd7fb27d4: avfilter: add documentation for needs_writable
[03:36] <cone-535> ffmpeg.git 03Michael Niedermayer 07master:48276731d604: Merge commit 'd44bd7fb27d4121512eae0ffce5e48bac25e82dc'
[03:42] <cone-535> ffmpeg.git 03Vittorio Giovara 07master:5655732c77f2: avfilter: add needs_writable field to the internal AVFilterPad structure
[03:42] <cone-535> ffmpeg.git 03Michael Niedermayer 07master:8788d316062e: Merge commit '5655732c77f2df9c1dfbddc30cd4844390a6921f'
[03:57] <cone-535> ffmpeg.git 03Vittorio Giovara 07master:abb5e37f64c4: avfilter: fix leaks on error in ff_filter_frame
[03:57] <cone-535> ffmpeg.git 03Michael Niedermayer 07master:d9481dcd612b: Merge commit 'abb5e37f64c48bba8bd0fde2bada0f7544defa24'
[04:06] <cone-535> ffmpeg.git 03Vittorio Giovara 07master:02b9fafcca58: avutil: do not use avcodec header in frame.h
[04:06] <cone-535> ffmpeg.git 03Michael Niedermayer 07master:c47fc0339a7f: Merge remote-tracking branch 'qatar/master'
[06:07] <cone-535> ffmpeg.git 03Michael Niedermayer 07master:34e90b2e6d66: fate: fix MSS2 tests on big endian
[08:08] <Zeranoe> What is a 'K' flag in ffprobe's frame output for audio?
[08:09] <nevcairiel> keyframe, i presume
[08:12] <Zeranoe> I'm trying to match a file, does adpcm_ima_wav produce all keyframes by default? if not, could that be set somehow
[08:13] <nevcairiel> most audio codecs are all keyframes
[08:36] <Zeranoe> This is a really odd file... it has nb_frames=2 and nb_read_frames=3490
[08:37] <Zeranoe> Also, what is this '00000000: f907'
[13:49] <cone-737> ffmpeg.git 03Carl Eugen Hoyos 07master:693a36b6f8ca: Unscaled 16bit packed RGB to planar GBR converter.
[13:49] <cone-737> ffmpeg.git 03Carl Eugen Hoyos 07master:8b7cce441ce6: Support signed j2k images via libopenjpeg.
[13:49] <cone-737> ffmpeg.git 03Carl Eugen Hoyos 07master:8298b54179c9: Fix libopenjpeg colour range adjust for 8<bpp<16.
[14:08] <cone-737> ffmpeg.git 03Carl Eugen Hoyos 07release/2.1:6ce835d77f76: Fix libopenjpeg colour range adjust for 8<bpp<16.
[15:39] <ubitux> michaelni: are you ok with the dvb patch?
[15:40] <ubitux> i will do the nit styles, fate test and apply tonight (will be faster than explaining again)
[15:42] <JEEB> btw, is the yellowness of fate right now due to some non-updated samples on the fate boxes?
[15:42] <JEEB> although I guess not
[15:42] <JEEB> MSS2 test fails with a single picture's hash
[15:45] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:4cb9c2013662: avformat/avisynth simplify packet allocation
[15:52] <michaelni> ubitux, no objection to dvb
[15:54] <michaelni> JEEB, theres a bug in mss or demuxer
[15:56] <ubitux> michaelni: ok thx, i'll have a look to the pjs patch asap btw
[15:56] <ubitux> tonight probably
[15:57] <michaelni> thx
[17:12] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:e1d8ef4c21f6: avcodec/mss2: fix chroma dimensions
[17:22] <smarter> any idea why the following change (use int16_t intead of int for a two-element array to simplify the assembly): https://github.com/smarter/libav/commit/5ffd7fc90e18ac0f23bf465c8bde4d0440cc1845 increases the number of cycles spent on chroma deblocking?
[17:43] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:ab9d7e0b120c: swscale: fix rgb48Toxyz12() endianness
[17:59] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:e2bb185e62e3: nut: Support XYZ12 rawvideo
[19:46] <j-b> http://googleonlinesecurity.blogspot.fr/2014/01/ffmpeg-and-thousand-fixes.html
[19:57] <Compn> j-b : ah, they wrote an article when they hit 500 or 600 too a few months ago
[19:58] <Compn> Until we can declare both projects "fuzz clean" we recommend that people refrain from using either of the two projects to process untrusted media files. 
[19:58] <Compn> lol
[19:58] <j-b> yeah
[19:58] <j-b> I laughed at that
[19:58] <j-b> Media formats are insane
[20:00] <Compn> oh they both have personal blog posts on this
[20:01] <Compn> yeah , i guess its possible that someone would craft a malicious file to take over a video plugin or vlc
[20:01] <Compn> which they do with windows media player all of the time (or used to)
[20:02] <Daemon404> his git log isnt very true
[20:03] <Compn> http://j00ru.vexillium.org/?p=2211
[20:03] <Daemon404> the grep will also turn up libav's fixe which ffmpeg may have copletely ignored
[20:03] <Compn> has some interesting detail
[20:03] <Daemon404> or fixed the same thing
[20:05] <nevcairiel> its unlikely that libav fixes went completely ignored, either ffmpeg already had the fix (most of the time differently, because you know, libav needs to re-write it), or it was merged. I suppose there may be the occasional case where some circumstance may have led to it not being merged completely, but its far more likely stuff turns up double, then stuff turning up which isn't fixed in ffmpeg :p
[20:05] <Compn> Daemon404 : j00ru's blog details the number of michael fixes directly
[20:06] <Compn> er michael and libav
[20:06] <nevcairiel> you could take the ffmpeg list, deduct the libav list, and get some kind of meaning from it :d
[20:06] <Compn> its on his blog already :P
[20:08] <Compn> at the bottom is the numbers
[20:08] <Compn> perfectly laid out
[20:08] <Compn> by developer even
[20:08] <Compn> of both projects
[20:08] <nevcairiel> yeah except that all the libav commits are also in ffmpeg
[20:09] <Compn> maybe you should submit a bug advisory to j00ru about his blog numbers :D
[20:10] <Daemon404> Compn, i fid it weird that there are 3 posts that are pretty close
[20:10] <Daemon404> wording is exact same in soem areas
[20:10] Action: Daemon404 bets the PR hounds mangled them
[20:10] <Compn> its a joint blog post and they both work at googles ?
[20:11] <Compn> and its english posted on a french google site. so add in language barrier
[20:12] Action: Compn wonders how many people use mplayer anymore
[20:12] <Compn> or xine
[20:12] <Compn> i guess xine was the default media player in some distros
[20:12] <Daemon404> i dont think anyone uses xine at all
[20:12] <Compn> j-b : how come vlc isnt the default player in all distros? :P
[20:13] Action: funman uses mplayer
[20:13] <Compn> yay
[21:06] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:396ddcf22d55: avformat/flvdec: initialize context before reading from it
[21:20] <cone-737> ffmpeg.git 03Martin Storsjö 07master:f8558780bbbb: fate: Explicitly specify the rgb555le pixel format for the mss2 rgb555 tests
[21:21] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:c881f46a9c7e: Merge remote-tracking branch 'qatar/master'
[22:59] <ubitux> michaelni: can i have the pjs file please?
[23:17] <michaelni> ubitux, see your inbox
[23:21] <ubitux> thx
[23:46] <cone-737> ffmpeg.git 03Michael Niedermayer 07master:a1ed1c219348: avformat/matroskadec: check generic audio deinterleaver sub_packet_size against frame_size
[23:58] <j-b> Compn: why would VLC be the default?
[00:00] --- Sat Jan 11 2014