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

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


[00:01] <J_Darnley> If I had the skill I would probably attempt to replace the whole filter graph code with Lua.
[00:02] <J_Darnley> I would force everyone who needed escaping to instead use a file/script
[00:03] <ubitux> you can still use a file...
[00:03] <ubitux> it's just a "fonctional" logic :P
[00:03] <ubitux> functional*
[00:04] <ubitux> i kind of enjoy eval actually now
[00:04] Action: ubitux prepares for insults
[00:04] <J_Darnley> It is fun learning to (ab)use a specialized language
[00:04] <ubitux> the registers thing is not exactly handy though
[00:05] <ubitux> i mean, st() and ld() or fine but... not that could be better
[00:07] <ubitux> ffplay -f lavfi "aevalsrc='if(eq(floor(t),ld(2)),st(0,random(4)*3000+1000));st(2,floor(t)+1);st(1,mod(t,1));(0.6*sin(1*ld(0)*ld(1))+0.4*sin(2*ld(0)*ld(1)))*exp(-4*ld(1))'"
[00:07] <ubitux> this is my personal pride
[00:08] <J_Darnley> :)
[00:08] <ubitux> now i need to plug it some real melody
[00:20] <Compn> matlab plugin for ffmpeg ;)
[00:20] Action: Compn runs
[00:22] <ubitux> it's too bad i can't have arrays with eval though
[00:34] <J_Darnley> Hmm...  Now I'm getting a strange problem.
[00:35] <J_Darnley> I am returning -1 from filter_frame in my A->V filter.
[00:35] <J_Darnley> This seems to be causing some (apparently) infinite loop with requests to my filter.
[00:36] <J_Darnley> But I am stopping with my debugging for the night.
[00:36] <J_Darnley> Perhaps I need to rebase my ffmpeg source.
[00:43] <michaelni> ubitux, what libavfilter email ?
[00:46] <michaelni> btw speaking of libavfilter and escaping, ive posted a patch months ago that basically removes all the need for escaping
[00:46] <michaelni> To FFmpeg devel (2.8K) [FFmpeg-devel] [PATCH] avutil/avstring: support asymmetric escaping in av_get_token()
[00:48] <llogan> michaelni: i presume "[FFmpeg-devel] Evolution of lavfi's design and API"
[01:05] <michaelni> llogan, it appears i didnt receive that mail (yet)
[01:23] <llogan> michaelni: odd. it's in the archives though https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-October/164429.html
[01:31] <michaelni> llogan, yes it was some local issue on my side, not completely sure what exactly but the mail is here
[01:38] <michaelni> llogan, seems i did run a apt-get upgrade a few seconds before i received that mail, somehow that made mutt miss the new mail, it appeared when i restarted mutt, havnt seen this before
[01:38] <llogan> i'll blame your usage of ubuntu
[03:19] <michaelni> ubitux, btw, that aevalsrc cmd you posted is cool :)
[04:59] <cone-475> ffmpeg.git 03Michael Niedermayer 07master:cebe8c809568: avformat/format: Use av_match_name() instead of list in av_match_ext()
[04:59] <cone-475> ffmpeg.git 03Michael Niedermayer 07master:3c0b98dced39: avutil/avstring: Reimplement av_match_list()
[05:03] <hungnv> I still looking for the way to transcode mpegts to mpegts without changing its duration, timestamp... Hope there's someone start looking at that issue...
[05:12] <rcombs> hungnv: use -mpegts_copyts 1 -copyts -vsync 0
[05:14] <hungnv> rcombs, implement -copyts using api is simply does not rescale timestamp when decode and encode frame, right? 
[05:15] <rcombs> right
[05:16] <hungnv> thanks, hope it works
[05:32] <hungnv> rcombs, no different, ffmpeg still changes start time and duration with these options
[05:37] <rcombs> what are the source and final start and end timestamps?
[05:38] <hungnv> source :  Duration: 00:00:15.08, start: 1.000000, bitrate: 1208 kb/s , output: Duration: 00:00:15.09, start: 0.989089, bitrate: 1129 kb/s 
[05:38] <hungnv> command I use: ./ffmpeg_g -y -i ~/video0.ts -vcodec libx264 -vb 500000 -s 640x360 -f mpegts -aspect 16:9 -g 25 -keyint_min 50 -vf scale=640:-1 -copyts -mpegts_copyts 1 -vsync 0 ~/hung.ts 
[05:38] <rcombs> you can read the actual timestamps with `ffprobe -show_frames`
[05:41] <hungnv> rcombs, http://pastebin.com/PH6zrXLn 
[05:47] <rcombs> hmm, interesting that the final timestamps match
[05:47] <rcombs> can you reproduce this using ffmpeg CLI?
[05:48] <hungnv> ok, give me seconds 
[05:51] <hungnv> http://pastebin.com/3MzAjdXX , it's the same thought 
[05:51] <rcombs> alright, got a sample source .ts file and the full command line you used?
[05:54] <hungnv> rcombs, actually I opened a trac tickets 1 week ago 
[05:54] <rcombs> link?
[05:54] <hungnv> https://trac.ffmpeg.org/ticket/4037 
[05:55] <hungnv> but I will update with -mpegts_copyts 1 -vsync 0 -copyts to ticket  
[05:59] <hungnv> rcombs, https://trac.ffmpeg.org/ticket/4037#comment:29 
[06:14] <rcombs> hungnv: looks like it has to do with the audio codec, possibly something preroll-related
[06:14] <rcombs> hungnv: it works for me with `-acodec copy`
[06:14] <hungnv> really?
[06:14] <rcombs> yup
[06:15] <rcombs> and judging by that ticket, I wouldn't imagine you actually need to re-encode audio for this
[06:15] <hungnv> Actually I did try looking around changing various option with audio codec yesterday, got bad luck!
[06:15] <hungnv> rcombs, exactly 
[06:20] <hungnv> yes, I works for me too
[06:20] <hungnv> you're amazing :)
[06:20] <rcombs> huzzah!
[06:21] <hungnv> one more question, do I have to implement -mpegts_copyts 1 and -vsync 0 or I just need to add the options before open the encoder?
[06:22] <hungnv> like ret = av_dict_set(&option, "mpegts_copyts", "1", 0); ?
[06:22] <rcombs> mpegts_copyts is a format option
[06:22] <rcombs> yes
[06:22] <hungnv> nice!
[06:22] <rcombs> vsync is an ffmpeg option; the value 0 is "passthrough" (i.e. it doesn't change timestamps at all)
[06:28] <hungnv> thank so much rcombs!
[06:30] <rcombs> welcome
[06:49] <ubitux> michaelni: yeah as llogan said, Nicolas' mail
[06:50] <ubitux> michaelni: the aevalsrc is just the one i wrote months ago which is present in the wiki with explanations (fancy filter thing); i need to add a real melody or something though, with a procedural algorithm or something :p
[06:54] Action: debianuser finally ported one more aevalsrc line for ubitux collection
[06:54] <debianuser> ffplay -f lavfi "aevalsrc='st(0,t*8192);st(1,mod(ld(0),4096));st(2,mod(ld(0)*(mod(floor(ld(0)/32768),2)*2+(mod(floor(ld(0)/16384),2)*mod(floor(ld(0)/32768),2))+6)/6,128));st(5,0);st(6,1);st(7,ld(0)/64);st(8,ld(2));while(gt(63,ld(6)),st(5,ld(5)+ld(6)*gt(not(eq(mod(ld(7),2),mod(floor(ld(7)/4),2)))+mod(floor(ld(7)/64),2)+mod(ld(8),2),.9));st(6,ld(6)*2);st(7,floor(ld(7)/2));st(8,floor(ld(8)/2)));(mod(floor(768/(ld(1)+1)),2)*32+ld(2)*ld(1)/8192+ld(5))/2
[06:54] <ubitux> debianuser: it's truncated by your irc client
[06:55] <ubitux> (512 char limit etc)
[06:55] <debianuser> It's 456
[06:55] <ubitux> yes, because of your username etc
[06:56] <debianuser> :(
[06:56] <ubitux> last part is "ld(5))/2"
[06:56] <ubitux> can you pastebin it somewhere or something?
[06:56] <debianuser> Heh. :) ...ld(5))/256'"
[06:57] <ubitux> oh
[06:57] <ubitux> okay
[06:57] <ubitux> !!
[06:57] <ubitux> awesome!
[07:00] <Compn> what is this trickery
[07:01] <ubitux> ...ld(5))/256',asplit[out0],showspectrum=mode=separate:color=intensity:slide=1:scale=cbrt[out1]" for pretty output
[07:02] <Compn> that messes with the audio
[07:03] <Compn> for some strange reason
[07:03] Action: Compn sleeps
[09:12] <ubitux> michaelni: oh, thanks for 9bdb7a6c1a8bcc36cf276107fb2e6fca12687d40 :)
[10:10] <ubitux> debianuser: so did you port an existing code or is it written from scratch?
[10:40] <xata> Hello
[10:41] <xata> I want to use ffmpeg to demux the video stream, what part of ffmpeg libraries should i dig into?
[10:42] <ubitux> this is a question for #ffmpeg
[10:42] <ubitux> look at doc/examples
[10:42] <ubitux> (and to answer precisely, libavformat)
[10:43] <xata> ubitux: Oh, i see. This # is for developing the ffmpeg, not using ffmpeg. Thanks though
[13:21] <wm4> ubitux: so it looks like some subtitle formats read the file fully, some don't
[13:22] <wm4> e.g. srt -> it's fully read into memory on init
[13:22] <wm4> pgs -> it's read incrementally
[13:22] <wm4> vobsub reads .idx fully, but the .sub file apparently not, so it counts as incrementally read too
[13:23] <wm4> now... for fully read files, there's no need to keep the file open or to do demuxing in a thread (to protect against slow/high latency network)
[13:23] <wm4> but for things like pgs or vobsub, you want that
[13:24] <wm4> but the application can't know which is required, except encoding internal ffmpeg knowledge about the codecs
[13:24] <wm4> would a flag for "fully read" be reasonable?
[13:31] <cone-216> ffmpeg.git 03Michael Niedermayer 07master:2de9c5ed98e4: avutil/avstring: fix hardcoded separator in av_match_list()
[14:03] <ubitux> wm4: almost all text subs can have their order totally fucked up, and they are often very small, so indeed we preload them completely
[14:03] <ubitux> it helps with seeking and the overall logic
[14:04] <ubitux> the .idx is text as well, and is basically the index, so indeed we preload this only
[14:05] <ubitux> wm4: i guess we could add a flag indeed; what's the use case?
[14:05] <wm4> for mpv (and probably any other player), there are two problems:
[14:05] <wm4> 1. the file is kept open for no reason
[14:05] <ubitux> streamed or something?
[14:05] <wm4> 2. network performance - network can be slow or stall, so if data must be read from network, we want to start a thread and run the demuxer inside the thread
[14:06] <wm4> but of course that would be a major waste of resources if it's not needed
[14:07] <ubitux> is it really going to waste anything?
[14:07] <ubitux> it will just be an inactive thread
[14:07] <ubitux> is it really a waste of process to keep the fd open?
[14:07] <ubitux> of ressources*
[14:07] <Compn> asking that question in a project where i've seen people optimize for an increase of 3 cpu cycles ;P
[14:08] <ubitux> it's not the same context
[14:11] <wm4> ubitux: consider loading 100 external subtitles
[14:16] <ubitux> wm4: ok
[14:19] <ubitux> wm4: so should idx have the full read flag or not?
[14:19] <wm4> ubitux: no, because reading packets still can read from the source
[14:19] <wm4> i.e. from network
[14:25] <ubitux> wm4: untested @ http://b.pkh.me/0001-avformat-WIP-add-AVFMT_FULLREAD-for-standalone-subti.patch
[14:26] <wm4> ubitux: looks good IMO
[14:26] <wm4> maybe clarify that even seeking doesn't access the underlying stream
[14:26] <ubitux> ok
[14:27] <wm4> or: that after opening, no further accesses to the avio are made
[14:27] <ubitux> i'll send tonight if you make me think about it (ping me in about 5-6 hours)
[14:27] <wm4> ok
[14:27] <ubitux> i'll clarify the doc etc
[15:44] <cone-216> ffmpeg.git 03Michael Niedermayer 07master:24cd4e5071a7: avformat/hls: forward whitelists to mpegts demuxer
[15:44] <cone-216> ffmpeg.git 03Michael Niedermayer 07master:c5e337431b79: avformat/sapdec: Forward whitelists to sdp demuxer
[16:02] <Daemon404> g 42
[17:09] <debianuser> ubitux: I just ported the code I've seen years ago to aevalsrc. I can explain its basic ideas if you're curious. But I don't remember where the algo came from. Some demoscene-related forum, maybe... It could be amiga assembler code initially. :)
[18:09] <cone-216> ffmpeg.git 03James Almer 07master:7292b0477ac8: x86/hpeldsp: fix loop in {avg,avg_no_rnd}_pixels16_x2_mmx
[18:10] <rcombs> echo "main(i){for(i=0;;i++)putchar(((i*(i>>8|i>>9)&46&i>>8))^(i&i>>13|i>>6));}" | gcc -x c - && ./a.out | ffplay -f u8 -
[18:31] <jamrial> rcombs: black magic
[18:32] <wm4> far too scary
[18:32] <wm4> ubitux: you wanted me to remind you!
[18:38] <cone-216> ffmpeg.git 03Michael Niedermayer 07master:ad5f861b8ce3: avformat/libquvi: Forward whitelists to subdemuxer
[18:38] <cone-216> ffmpeg.git 03Michael Niedermayer 07master:ad83cfec5ad2: avformat/mpeg: Forward whitelists to the mpegps demuxer
[18:38] <cone-216> ffmpeg.git 03Michael Niedermayer 07master:b76234c00c7c: avformat/avidec: Forward whitelists to the subtitle demuxer
[18:38] <cone-216> ffmpeg.git 03Michael Niedermayer 07master:feb9057b838e: Forward whitelists to the asf demuxer
[18:38] <cone-216> ffmpeg.git 03Michael Niedermayer 07master:5ea0753a1536: avformat/concatdec: Forward whitelists to the subdemuxers.
[18:53] <ubitux> wm4: yup
[18:53] <ubitux> will do
[18:58] <wm4> thanks
[19:32] <debianuser> rcombs: Now convert that to aevalsrc syntax! ;)
[19:33] <rcombs> debianuser: I tried, actually, and got stuck on& I'm not quite sure
[19:35] <debianuser> let me guess - a missing XOR, OR and AND operations :)
[20:58] <cone-216> ffmpeg.git 03Andrey Utkin 07master:70c9d400087c: avformat/http: pass return code from http_open_cnx_internal() on its failure
[21:12] <SH_> Hello
[22:40] <jfhs_> hello, I'm not sure if I should write here or on ffmpeg, but it seems more as dev question. I'm now trying to encode subtitles to ass (from scratch, not re-encode, that's the crucial point) and ended-up with problem that subtitle header (containing style information, etc) is not written, only subtitle events. I've spent some time with sources, and it seems problem is in following. Subtitle header is written by write_header from avformat/assenc.c and 
[22:40] <jfhs_> it gets it from avctx->extradata, which is filled only in ass_encode_init from avcodec/assenc.c. And here (as I think) is the problem, this function just copies avctx->subtitle_header to avctx->extradata. So let's see where subtitle_header is filled, and that's only in decoding parts, that's why for re-encoding everything works fine (if avcodec_copy_context is used) and fails for newly created stream. I tested all this using PyAV python binding, so 
[22:40] <jfhs_> may be that's error in it, but according to source code, it's as I described. So I thought, maybe ass_encode_init should check and fill subtitle_header, if it is empty? Or maybe you have some other solution?
[23:09] <ubitux> jfhs_: "encode subtitles to ass, from scratch, not re-encode", wut?
[23:10] <ubitux> can you translate this to a ffmpeg command line so i understand what you mean?
[23:10] <jfhs_> I mean that it's not like ffmpeg -i input.srt out.ass
[23:10] <jfhs_> but create new subtitle stream, and then put there some AVSubtitle
[23:11] <ubitux> you have to fill the extradata with the header
[23:11] <ubitux> also, if no encode... why not work on the packet itself?
[23:12] <ubitux> using AVSubtitle means you'll have to "encode" it to ASS
[23:12] <ubitux> (which is currently doing something horrible that i'm trying to change)
[23:12] <jfhs_> I do encode packets
[23:13] <jfhs_> but I want it to be universal, so if I encode srt, I don't need any header
[23:13] <jfhs_> but if it's ass, I need it
[23:14] <ubitux> so you just want to feed the ass muxer with your already crafted packets?
[23:15] <ubitux> sorry if i'm a bit slow, but i don't see where AVSubtitles can be in use in your workflow
[23:15] <ubitux> it looks like you're just acting like a demuxer
[23:15] <jfhs_> I pass AVSubtitle to avcodec_encode_subtitle, then make a packet from it, and then mux it to container
[23:16] <ubitux> alright
[23:18] <ubitux> so the subtitles encoders are parsing the avctx->subtitle_header
[23:18] <jfhs_> they're not, they just write it, if it's there
[23:18] <ubitux> which is basically a ass header to interpret the markup into the Dialogues
[23:18] <ubitux> what?
[23:18] <ubitux> no
[23:19] <ubitux> the ass encoder is copying the subtitle header to its extradata
[23:19] <ubitux> because the ass muxer will need access to it
[23:19] <ubitux> to dump it at the top of the file
[23:19] <jfhs_> encoder, or decoder?
[23:19] <ubitux> encoder
[23:19] <ubitux> and the srt encoder reads it to understand the markup
[23:19] <ubitux> and don't put it in extradata because the srt muxer doesn't need it
[23:20] <ubitux> doesn't*
[23:20] <ubitux> i'm talking about libavcodec/{srt,ass}enc.c
[23:20] <jfhs_> well, where encoder should get smth to parse?
[23:20] <jfhs_> https://www.ffmpeg.org/doxygen/trunk/libavcodec_2assenc_8c.html#a5c382ba08a02cc6ea7732b3467266497
[23:20] <jfhs_> ass_encode_init, just copies subtitle_header to extradata
[23:21] <ubitux> that's what i said
[23:21] <jfhs_> yeah, but subtitle_header is empty
[23:21] <ubitux> the ass encoder doesn't need to do much about the Dialogues which are actually in ASS
[23:21] <jfhs_> never filled by anyone
[23:22] <ubitux> it's definitely filled
[23:22] <jfhs_> it's filled only on decoding
[23:22] <ubitux> yes
[23:22] <jfhs_> https://www.ffmpeg.org/doxygen/trunk/structAVCodecContext.html#ab781cbaef6311226481e65a7f1a6d049
[23:22] <jfhs_> I've looked all usages from here
[23:23] <jfhs_> soo, if I create new stream
[23:23] <jfhs_> there was no decoding using thats new stream encoder
[23:23] <jfhs_> and this filled isn't filled
[23:23] <jfhs_> *field
[23:24] <ubitux> well aren't you doing the decoding part?
[23:25] <jfhs_> I do, but that's not the point
[23:25] <jfhs_> I can copy that field
[23:25] <jfhs_> but what if I'm jsut generating subtitles
[23:25] <ubitux> you're supposed to generate a header
[23:26] <ubitux> the ffmpeg decoders use ff_ass_subtitle_header_default()
[23:26] <cehoyos> michaelni: I have pushed the patch that prints an error if "-vsync 0" and "-r" are used together to github. Please merge if you think it's ok.
[23:26] <ubitux> jfhs_: if you're generating subtitles, you're suppose to generate ASS, so you need a header anyway
[23:27] <jfhs_> okay, then will do it
[23:27] <jfhs_> thanks for explaining :)
[23:28] <ubitux> jfhs_: just curious, may i ask why you're not using ffmpeg decoders?
[23:30] <jfhs_> well, I'm using, but I use python binding, and I didn't copy streamcontext, but created new stream
[23:31] <jfhs_> with new encoder, which had that field empty, and so I had no headers in resulting file
[23:32] <cone-216> ffmpeg.git 03Michael Niedermayer 07master:a1d06a0121cb: avcodec/options_table: Fix codec_whitelist flags
[23:32] <cone-216> ffmpeg.git 03Michael Niedermayer 07master:00dbd7c4aee6: avcodec/utils: Print the codec name that is missing on the whitelist
[23:41] <cehoyos> kierank: Could you upload the installer for Archimedia Master Player?
[23:46] <cone-216> ffmpeg.git 03Carl Eugen Hoyos 07master:7a649e07830c: Print an error if -r and -vsync 0 are used together.
[23:46] <cone-216> ffmpeg.git 03Michael Niedermayer 07master:20aac40571a5: Merge remote-tracking branch 'cehoyos/master'
[23:47] <ubitux> wm4: sent, sorry about the delay
[00:00] --- Fri Oct 24 2014


More information about the Ffmpeg-devel-irc mailing list