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

burek burek021 at gmail.com
Fri Oct 17 02:05:02 CEST 2014


[00:02] <cone-712> ffmpeg.git 03Martin Storsjö 07master:ced7238cd01c: rtpdec_hevc: Use av_realloc instead of av_malloc+memcpy
[00:02] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:f09162c06bba: Merge commit 'ced7238cd01cc2199acf9225305628641a27c1d7'
[00:09] <cone-712> ffmpeg.git 03Martin Storsjö 07master:79dd756e143a: rtmpproto: Fix a typo
[00:09] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:917f86f47908: Merge commit '79dd756e143a54efc25d64e90505f0dca6cbc4ec'
[01:04] <randomdude123> guys.
[01:04] <Compn> yes.
[01:04] <randomdude123> can anybody comment on this weird requirement by RCS spec:
[01:04] <randomdude123> http://stackoverflow.com/questions/26393553/h264-rtp-and-packetization-mode-no-stap-a-in-baseline-h264-rtp
[01:04] <randomdude123> this is about h264 and STAP-A in RTP
[01:06] <Compn> i see
[01:06] <Compn> have to ask people who work on rtp h264 code
[01:06] <Compn> which does not include me :)
[01:06] <Compn> wait around for someone to asnwer
[01:06] <Compn> or ask on list
[01:06] <Daemon404> probably will be a bit
[01:07] <Daemon404> most are european and asleep
[01:07] <Daemon404> maybe.
[01:43] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:2f7bd04afb29: avcodec/avcodec: fix non doxy comment
[01:43] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:7b6a97edd1b5: avcodec/avcodec: more verbose documentation for time_base
[01:43] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:46f52274f38d: avformat/oggparsedirac: use AVCodecContext.framerate
[01:49] <rcombs> https://www.dropbox.com/s/bwv99lz0xtbckpn/Maken-Ki%21%20-%20S01E02.mkv?dl=0 <-- apparently ffmpeg can't seek in this file
[01:50] <rcombs> `ffmpeg -ss 922 -i 'Maken-Ki! - S01E02.mkv' -c copy -map 0 -y out.mkv` gives output starting at the beginning of the file
[02:11] <randomdude123> i'll hang around, untill they wake up :) would like to know what ppl familiar with that stuff can say about the spec
[02:13] <wm4> rcombs: seeks perfectly well in mpv, even with the lavf demuxer
[02:13] <rcombs> wm4: yeah, I'm confused about what's going wrong
[02:14] <wm4> rcombs: so I conclude it's some kind of obscure ffmpeg.c problem
[02:14] <rcombs> things go wrong when using either -copyts or -c copy
[02:14] <wm4> ah
[02:14] <rcombs> seems likely (which is why I filed the component undetermined, instead of avformat)
[02:47] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:004f1c6cf13a: avformat/utils: Try to correct the codec_framerate in ff_compute_frame_duration() for the encoding case
[02:47] <cone-712> ffmpeg.git 03Michael Niedermayer 07master:d267a0f8c1a8: avformat/util: Simplify av_guess_frame_rate() by using AVCodecContext.framerate
[04:13] <rcombs> ^ just realized that didn't actually submit due to the description limit
[04:22] <cone-712> ffmpeg.git 03Di Wu 07master:0e406aba14a8: mpegts: add the judgement if a new program is created successfully
[09:20] <sophiejjj> reynaldo: there?
[12:08] <cone-322> ffmpeg.git 03Carl Eugen Hoyos 07master:392b4b663c45: Fix initialisers in dct-test.c.
[12:38] <cone-322> ffmpeg.git 03Michael Lynch 07master:460b509a34fb: rtsp: Check a memory allocation
[12:39] <cone-322> ffmpeg.git 03Michael Niedermayer 07master:293a8e426fc0: Merge commit '460b509a34fb5fad3bedac8429f53594d3923ea8'
[12:54] <cone-322> ffmpeg.git 03Mika Raento 07master:979932378ae3: ismindex: use tfhd default duration if no sample duration
[12:54] <cone-322> ffmpeg.git 03Michael Niedermayer 07master:a9b613b60e51: Merge commit '979932378ae3fbf452e312eb759cc7ce175f78de'
[13:29] <BBB> iive: https://wiki.videolan.org/X264_asm_intro/
[13:36] <iive> BBB: i think kierank already pointed that out.
[13:45] <ubitux> kierank: aren't you looking for sine or aevalsrc audio filters?
[13:46] <ubitux> won't be exactly accurate but that can be done with aevalsrc
[13:46] <BBB> oh, sorry, missed that
[13:47] <kierank> ubitux: it can be done but it's not guaranteed to be frame accurate
[13:47] <kierank> which is the point of a lipsync test
[13:51] <Daemon404> why would you use lavfi at all for something so simple?
[13:55] <ubitux> kierank: ffplay -f lavfi "aevalsrc='st(1,mod(t,2));sin(440*2*PI*ld(1))*exp(-5*ld(1))|st(1,mod(t+1,2));sin(440*2*PI*ld(1))*exp(-5*ld(1))'"
[13:55] <ubitux> (i know that's not what you want but well.)
[13:56] <Daemon404> or you could write 3 lines of C
[13:56] <kierank> Daemon404: that's what i did for a static tone
[13:56] <kierank> and probably extend it for a lipsync test (ntsc is problematic)
[13:57] <ubitux> ffplay -f lavfi "testsrc[out0];aevalsrc='st(1,mod(t,2));sin(440*2*PI*ld(1))*exp(-5*ld(1))|st(1,mod(t+1,2));sin(440*2*PI*ld(1))*exp(-5*ld(1))'[out1]"
[13:57] <ubitux> now you include a showwaves and you have a cute thing
[13:58] Action: Daemon404 wipes up the vomit ubitux just barfed into the channel
[13:58] <ubitux> :(
[13:59] Action: ubitux http://z0r.de/4098
[14:00] <Daemon404> cant view that on android
[14:00] <ubitux> you really miss something
[14:03] <espes__> maybe a long shot, but do these look like sane aac-eld packets? https://gist.github.com/espes/4dc4b3c0538beac12f68
[14:03] <espes__> or some obvious transport?
[14:03] <espes__> this is from an rtp stream that is /supposed/ to be rfc3640, but clearly not :/
[14:40] <cone-322> ffmpeg.git 03Michael Niedermayer 07master:411be72dcbc9: avfilter/vf_noise: fix high resolution support
[14:40] <cone-322> ffmpeg.git 03Michael Niedermayer 07master:aba61b22f70f: avfilter/vf_noise: move shift calculation to filter_frame()
[15:04] <jeetu> @michaelni ,,,,,,hlo sir ,the task you gave me yestrdy about  audio filter,i am working on it.........  actly sir i am doing it on java platform,,,,so jst wanna confirm whether it's okay or i need to switch on some other language platform??????
[15:06] <jeetu> Or is there any particular language you would suggest???
[15:06] <J_Darnley> 1 comma, 1 full stop, and 1 question mark, please.
[15:07] <J_Darnley> FFmpeg is a C project.  We will want a filter that can easily be linked into the libavfilter library.
[15:07] <michaelni> jeetu, FFmpeg is written in ANSI/ISO C
[15:07] <michaelni> jeetu, you know C ?
[15:08] <jeetu> yes sir ,i do
[15:11] <iive> jeetu: and in case you might need something like fast fourier transform, there are already dsp routines for that.
[15:16] <michaelni> jeetu, look at 21b092de7c1e2d7fae24ceca3aa2f8f9f1730cfc, thats the addition of the sine audio source filter, you could add DTMF numbers->PCM into that. The PCM->DTMF numbers would be a separate filter
[15:18] <michaelni> also that commit is a good example of what is needed to add a new filter
[15:23] <jeetu> okay sir ,
[16:33] <cone-322> ffmpeg.git 03Michael Niedermayer 07master:ed3efbcd0c84: avfilter/vf_noise: use per component rand_shift
[16:33] <cone-322> ffmpeg.git 03Michael Niedermayer 07master:4f1a252fd3f0: avfilter/vf_noise: Use a separate seed for each plane
[16:33] <cone-322> ffmpeg.git 03Benoit Fouet 07master:8bcf425d06a2: avformat/id3v2: silence a warning when CONFIG_ZLIB is unset.
[17:17] <arwa> how do I malloc new space ? What does av_mallocz do??
[17:17] <kierank> it zeros out the array
[17:17] <kierank> well the memory
[17:17] <kierank> imagine it like av_calloc
[17:17] <BtbN> it makes sure it's alligned and fills it with zeros.
[17:18] <arwa> ummm...i dont know av_calloc
[17:19] <arwa> if I want to malloc a chunk of memory of size double the previous image...what do i do?
[17:24] <J_Darnley> Isn't there a realloc function?
[17:26] <J_Darnley> arwa: yes, av_realloc
[17:28] <J_Darnley> look at libavutil/mem.h for the various memory functions.
[17:28] <ubitux> arwa: you're doing it wrong
[17:28] <ubitux> arwa: you want to configure your outlink with 2x the dimensions
[17:28] <ubitux> and use the get_buffer function
[17:29] <ubitux> look at how hqx does it
[17:29] <ubitux> (i'm assuming you're still in the filter)
[17:29] <ubitux> if you want an extra buffer, the you have various alloc frame utils
[17:32] <arwa> okay, but when I tried to follow the things done in hqx, I am getting this error -->  lvalue required as left operand of assignment
[17:32] <arwa> what does it mean?
[17:33] <arwa> I am getting error for this line --> "out->data[0] + j*out->linesize[0] + i*3 = in->data[0] + (int)(j/2) * in->linesize[0] + (int)(i/2)*3;" 
[17:33] <arwa> Why can I not do this?
[17:35] <wm4> never say "I get an error"
[17:35] <wm4> say WHAT error you get
[17:36] <arwa> "lvalue required as left operand of assignment"
[17:36] <arwa> Sorry :/ But I already mentioned the error..!! 
[17:37] <wm4> I didn't read
[17:37] <ubitux> arwa: this is not valid c
[17:37] <wm4> yeah, you're writing something like "123 = variable;"
[17:38] <arwa> okay
[17:38] <wm4> instead of "pointer + 123 = 5;" you want "*(pointer + 123) = 5;"
[17:40] <arwa> okay
[17:40] <arwa> thanks
[17:40] <arwa> :D
[17:49] <J_Darnley> Oh come on!  That should be pointer[123] = 5
[17:51] <J_Darnley> And in the specific example: out->data[0][j * out->linesize[0] + i * 3] = ...
[17:52] <J_Darnley> I also wonder why you are casting i/2 to an int, is i not an integer type?
[18:00] <randomdude123> can anybody comment on this weird requirement by a spec:
[18:01] <randomdude123> http://stackoverflow.com/questions/26393553/h264-rtp-and-packetization-mode-no-stap-a-in-baseline-h264-rtp
[18:01] <randomdude123> this is about h264 and STAP-A in RTP
[21:25] <DocC> anybody in here familiar with the dshow components of ffmpeg under windows?
[21:26] <wm4> never ask to ask
[21:27] <wm4> because that's how you ensure the highest chance you'll never get an answer
[21:28] <DocC> fair enough.  I'm encountering an incompatibility between capturing with dshow in ffmpeg under windows using the latest generation of blackmagic design 4k decklink cards
[21:28] <BtbN> DirectShow is one huge incompatiblity.
[21:29] <BtbN> You basicaly have to write code for every single device.
[21:31] <DocC> good to know
[21:31] <DocC> I have several c developers on staff I can assign to the project
[21:32] <BtbN> ffmpeg only supports very basic stuff, like webcams. Capturecards are way too much.
[21:32] <DocC> I see
[21:32] <BtbN> They are poorly documented, if at all, and add proprietary extensions that couldn't even be used in ffmpeg.
[21:32] <DocC> the old generation blackmagic cards work fine
[21:33] <ubitux> we have indev for decklink
[21:33] <DocC> I saw there was an option to --enable-decklink
[21:33] <ubitux> yes
[21:33] <DocC> that will bypass dshow and go directly to the BMD hardware?
[21:33] <kierank> BtbN: not true
[21:33] <kierank> the blackmagic api is gpl compatible
[21:34] <BtbN> They have an entire _API_?
[21:34] <DocC> our application is hd capture and realtime x264 encoding, btw
[21:34] <BtbN> The ones for Roxio and Hauppauge are not.
[21:34] <DocC> and the results are spectacular with 1080p SDI in
[21:34] <kierank> BtbN: yes, known as capturing properly
[21:34] <kierank> in a professional environment
[21:35] <DocC> so it sounds like skipping the -f dshow is what to try next
[21:35] <DocC> I'll test it with our 4k cards
[21:35] <J_Darnley> I always read that as "deliberately more complicated than it has to be"
[21:35] <kierank> DocC: what is broken about the 4k cards
[21:36] <kierank> J_Darnley: feel free to explain how you would provide audio in sync on linux
[21:36] <DocC> when capturing 1920x1080p at greater than 24 fps, the start time is erroneously large
[21:36] <kierank> when alsa doesn't provide you timestamps
[21:36] <DocC> like 7M seconds
[21:36] <J_Darnley> Isn't it a continuous stream of samples at a given rate?
[21:36] <kierank> J_Darnley: yes and linux gives you two file descriptors
[21:36] <kierank> how do you open both at the same time
[21:36] <kierank> and sync up audio and video when you have no timestamps
[21:37] <J_Darnley> If fopen that slow?
[21:37] <kierank> it's nondeterministic
[21:37] <kierank> that's the problem
[21:38] <J_Darnley> Okay, you have problem with that.  I have a problem with TV or "studio" levels and interlacing.  Neither of which shoule exist today.
[21:38] <kierank> tv levels make perfect sense
[21:39] <kierank> how do you deal with filter overshoots?
[21:39] <kierank> in 0-255?
[21:39] <wm4> J_Darnley: but why wouldn't you fix ALSA?
[21:39] <kierank> wm4: they don't want to fix alsa
[21:39] <kierank> I went to the summit last year
[21:39] <J_Darnley> Saturating arithmetic?
[21:39] <kierank> and so you end up with blotches on the screen where the filter overshoots
[21:39] <rcombs> J_Darnley: how about overscan
[21:39] <prabhy> hey,i wanted to know if i  can convert gcc asm to yasm or nasm,or is it compulsory to convert it to yasm
[21:40] <wm4> kierank: what was their answer as to how sync should be done?
[21:40] <kierank> yasm
[21:40] <kierank> wm4: "must be done in alsa"
[21:40] <JEEB> prabhy, this project only takes in IA32 and x86_64 asm in yasm form
[21:40] <J_Darnley> What else does a TV show when you get "overshoots"?
[21:40] <JEEB> inline asm is only allowed on architectures where separate asm files are not possible
[21:41] <J_Darnley> Don't most things clip to TV range?
[21:41] <prabhy> ok
[21:42] <DocC> http://pastebin.com/MQqV7JZd
[21:42] <kierank> at the consumer yes but you have to bear in mind these signals pass through crazy infrastructure
[21:43] <kierank> so you end up filtering again and again
[21:43] <DocC> pastebin of the decklink capture bug I'm encountering
[21:43] <kierank> and doing that on clipped values screws you
[21:43] <J_Darnley> "crazy infrastructure" and you want to keep it going?
[21:44] <J_Darnley> With enough craziness it sounds like you'll be clipping at 0-255 eventually.
[21:44] <kierank> well yes, you are going to have  your cable company processing the video
[21:44] <kierank> and possibly a distributor along the way
[21:44] <kierank> cnn for example is processed many many times
[21:44] <kierank> before it gets to your home
[21:45] <kierank> no because you're only allowed 2% or so of the picture as overshoot/undershoot iirc
[21:45] <wm4> processed for what?
[21:45] <kierank> wm4: framerate converted, re-encoded etc
[21:45] <J_Darnley> To remove quality ofcourse
[21:46] <wm4> "crazy infrastructure" I guess
[21:49] <rcombs> interlaced, de-interlaced, re-interlaced, over-scanned, under-scanned, window-boxed, cropped, stretched, squeezed&
[21:49] <wm4> NSA'd!
[21:49] <rcombs> if it's a movie made on film, then along with over- and under-scanned it got outright scanned at some point
[21:50] <rcombs> and telecined, inverse-telecined, pulled up, pulled down, and sped up if you're in Europe
[21:51] <rcombs> I have a feeling one could write a highly amusing song about all this
[21:51] <wm4> and then converted to analogue by sending it through ancient cable TV links
[21:52] <wm4> it's ironic that my mom's new TV looks much worse than the old CRT she had
[21:54] <J_Darnley> rcombs: in the style of the elements song or weird al's "hardware store"?
[21:55] <rcombs> J_Darnley: either could be great
[21:55] <rcombs> I was just thinking of xkcd's Every Major's Terrible, but that's the same tune as the elements song anyway
[21:56] Action: J_Darnley hasn't heard that
[21:56] <llogan> wm4: what's with these tvs lately? i don't know what postprocessing crap is going on, but it looks like shit.
[21:56] <J_Darnley> 200Hz interpolation!
[21:57] <llogan> early 2000 soap opera vision
[21:57] <rcombs> https://www.youtube.com/watch?v=pRexBMPeRTo from http://xkcd.com/1052/
[21:58] <wm4> llogan: dunno, just cheap shit
[22:36] <cone-322> ffmpeg.git 03Michael Niedermayer 07master:080c846f5999: swresample: do not put multiple statements in one line
[22:36] <cone-322> ffmpeg.git 03Michael Niedermayer 07master:f6bb2cd1b048: swresample/resample: fix invert_initial_buffer() after flush
[23:43] <ubitux> can anyone comment on http://www.cccp-project.net/forums/index.php?topic=6826.0 that it should be fixed?
[23:43] <ubitux> JEEB maybe?
[23:43] <ubitux> (i'd actually like these people to test :p)
[23:59] <J_Darnley> in case that JEEB isn't here, JEEBsv ^^
[00:00] --- Fri Oct 17 2014


More information about the Ffmpeg-devel-irc mailing list