[Ffmpeg-devel-irc] ffmpeg-devel.log.20131217
burek
burek021 at gmail.com
Wed Dec 18 02:05:02 CET 2013
[00:06] <cone-86> ffmpeg.git 03Diego Biurrun 07master:11bb5e10c365: build: Define __printf__ to __gnu_printf__ on MinGW*/gcc
[00:06] <cone-86> ffmpeg.git 03Michael Niedermayer 07master:a67387913eb0: Merge commit '11bb5e10c36539bcc303ceaac6f88d9ecb66e07f'
[00:37] <cone-86> ffmpeg.git 03Diego Biurrun 07master:0d882e9e7b78: avutil: Remove deprecated intfloat_readwrite code
[00:37] <cone-86> ffmpeg.git 03Michael Niedermayer 07master:196f7da7c818: Merge remote-tracking branch 'qatar/master'
[01:14] <cone-86> ffmpeg.git 03Michael Niedermayer 07master:ec464c96831a: avcodec/utils: av_register_codec & hwaccel() that work in O(1) time
[01:14] <cone-86> ffmpeg.git 03Michael Niedermayer 07master:49f10c9cb185: avformat/format: av_register_output_format() and av_register_intput_format() that work in O(1) time
[01:35] <Zeranoe> Is there any more information about pp=fq? http://www.ffmpeg.org/ffmpeg-all.html#pp it just says fq/forceQuant[|quantizer] without any options for quantizer. I'm trying to get fixed tables somehow
[01:37] <cone-86> ffmpeg.git 03Stoian Ivanov 07master:5fe415f0f415: UDP: join multicast group on the interface specified with &localaddr=
[01:38] <michaelni> Zeranoe, a number between 1 and 31 or so should work as quantizer
[01:40] <Zeranoe> michaelni: Thanks, will this help at all with "fixed rather than variable quantisation tables". Is there any option for that?
[01:44] <michaelni> iam not sure i understand your question
[01:47] <Zeranoe> michaelni: I'm back to the amv issue, and I'm trying to get a file working with a device. the amv format (http://en.wikipedia.org/wiki/AMV_video_format) call of fixed quanisation tables. I'm not sure why my settings don't work with some input videos, but other videos do work. I encode both videos with the same settings, so something must be passing through
[01:48] <michaelni> sounds unrelated to -vf pp
[01:49] <michaelni> you use qscale instead of bitrate ?
[01:49] <Zeranoe> michaelni: Yup
[01:51] <Zeranoe> michaelni: I guess the player has issues at the end of the file, I don't know if that narrows it down at all. I even tried dumping it to uncompressed and then encoding that, but still got the end error
[01:54] <Zeranoe> It seems that converting mp4 files downloaded from youtube will work on the device after being encoded with ffmpeg and amv-codec-tools. So something about those input files makes the output work, I have no idea why
[01:55] Action: michaelni has no idea either
[01:55] <Zeranoe> :(
[02:58] <cone-86> ffmpeg.git 03Michael Niedermayer 07master:745c40a47f88: avcodec/gifdec: check that the correct number of bytes was decoded
[03:47] <clever> Daemon404: you about?
[04:11] <Compnn> we should chip in to buy zeranoe a real mp4 player ,not some amv thing :D
[04:12] <clever> Compnn: i think i just figured out the codec config problems
[04:13] <clever> all packets that omxplayer sends in, are prefixed with a 4 byte size
[04:13] <clever> my initial checks for that kind of thing where thrown off, because the first 'packet' actualy contained 2 such packets
[04:17] <clever> now i just have to deal with byte order issues...
[04:34] <clever> Compnn: i think its working, but now i'm back to a corrupt stack!
[05:00] <Compnn> using str versions of functions ?
[05:00] <Compnn> did you dump omxplayer to assembler and just reverse engineer that ?
[05:08] <clever> Compn: i just compiled omxplayer from source
[05:08] <clever> *** glibc detected *** /160g/rpi/mplayer/mplayer: double free or corruption (out): 0xb0f3d020 ***
[05:11] <clever> still trying to figure this out now, ive been over the code multiple times, and it should only have freed that pointer once
[05:11] <Compn> grep -i free *
[05:11] <clever> i already did a search in the file, only one line ever deals with at pointer and free
[05:11] <clever> av_free(inframe->v);
[05:11] <clever> no other line anywhere mentions the bad pointer and free
[05:12] <Compn> what if you remove that line
[05:12] <clever> and acording to gdb, it crashes the first time i run that line
[05:12] <clever> i'll comment it out and see what happens
[05:12] <Compn> you're thinking of a 'double free'
[05:12] <Compn> oh nm
[05:12] Action: Compn cant read lol
[05:13] <clever> v is allocated in 2 places
[05:13] <clever> decoder->frame->v = av_malloc(newframe->vstride * (decoder->height/2));
[05:13] <clever> decoder->frame->v = av_malloc(pic->f.linesize[2] * (decoder->height/2));
[05:13] <clever> both look fine to me
[05:18] <clever> Compn: with the free commented out it works
[05:18] <Compn> of course it works
[05:18] <Compn> because i am genius
[05:18] <clever> and its likely leaking a whole v plane on every frame
[05:18] <clever> 500kb per frame, 30 fps
[05:18] <Compn> likely ?
[05:18] <Compn> we dont use words like that here
[05:18] <Compn> we use words like valgrind
[05:19] <clever> and valgrind uses words like 'wtf is omx, that memory was never initialized!'
[05:19] <clever> and 'oh, let me eat all you disk space with debug symbols'
[05:20] <Compn> well then run top when its playing
[05:20] <Compn> double free means its being freed elsewheres
[05:20] <clever> except its imposible for it to be free'd anywhere else
[05:20] <clever> valgrind loading up...
[05:21] <clever> ==3087== Conditional jump or move depends on uninitialised value(s)
[05:21] <clever> ==3087== at 0x4837A54: memcpy (mc_replace_strmem.c:838)
[05:21] <clever> ==3087== by 0x4AE159B: ilcs_pass_buffer (in /opt/vc/lib/libopenmaxil.so)
[05:21] <clever> all over the place! :D
[05:22] <clever> --3087-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
[05:22] <clever> ok, that didnt go very well
[05:22] <Compn> ehe
[05:22] <Compn> impossible you say
[05:22] <clever> lets see, 48mb
[05:23] <clever> 57mb
[05:23] <clever> 63mb
[05:23] <clever> yeah, its leaking!
[05:23] <Compn> oom is fun :P
[05:23] <clever> except when you have swap on SD cards
[05:24] <clever> let me double check the log files i just made...
[05:24] <clever> copying 0xb13db220(960) to 0x35d6cb0(976), height 536
[05:24] <clever> copying 0x35d6cb0(976) to 0xb540eea8(976), height 536
[05:24] <clever> deleting frame 0x2840040 y0xb0061020 u0x30d97d0 v0x35d6cb0
[05:24] <clever> ok, it populates the v plane, then copies the v plane to ffmpeg, then tries to release it
[05:24] <clever> and never mentions the same pointer again
[05:26] <clever> so its not a double-free when its commented out, and nothing is reusing frames
[05:27] <Compn> are you using memcpy or av_memcpy ?
[05:27] <Compn> av_fastmemcpy
[05:27] <Compn> whatever
[05:27] <clever> memcpy, via libcofi_rpi.so
[05:27] <clever> which i have to comment out, valgrind claims its an illegal instruction
[05:27] <Compn> you do what now
[05:27] <Compn> lol
[05:28] <clever> its a special lib that replaces the stock memcpy with one that gets much better performance
[05:28] <clever> some kind of broadcom extension
[05:28] <clever> which valgrind doesnt know about
[05:28] <Compn> could you use standard memcpy and see if the free works then ? or is it completely diff ?
[05:28] <clever> the standard memcpy also works, just wont be as fast
[05:29] <clever> but i'm already getting 2 fps, so who cares!
[05:29] <Compn> i'm just guessing at straws, so my advice isnt great :)
[05:29] <clever> https://github.com/simonjhall/copies-and-fills has more info
[05:30] <clever> stock memcpy, a single free call, and it screams double-free
[05:30] <Compn> you sure ffmpeg isnt freeing somewhere
[05:31] <Compn> because ffmpeg does that
[05:31] <Compn> lots of free
[05:31] <clever> i never pass ffmpeg a copy of this pointer
[05:31] <clever> its a custom frame struct, to hold things between the async callback and the avframe
[05:32] <clever> the only time it leaves my file is memcpy, printf, and av_free
[05:33] <Compn> are you free'ing inframe or v ?
[05:33] Action: Compn dont know coding
[05:33] <clever> both, in order
[05:33] <clever> Compn: http://pastebin.com/CsGkuPWv
[05:34] <Compn> oh easy
[05:34] <Compn> put the last free above the first 3 :)
[05:35] <clever> then the memory for the struct will be 'free' and another thread may overwrite the pointers
[05:35] <clever> before i have a chance to free them properly
[05:35] <clever> and its c, it isnt capable of recursively releasing a complex struct
[05:35] <clever> thats the kind of hidden bug that valgrind is great for
[05:38] <Compn> well im out of idears
[05:38] <Compn> wait for smart people :)
[05:39] <Compn> gdb wont tell you where the second free is ?
[05:39] <Compn> or is corrupt
[05:39] <clever> gdb wont even give me a backtrace
[05:39] <clever> corrupt stack it claims
[05:39] <clever> and free is used too much to just put a breakpoint on it, thats what valgrind is for
[05:43] <clever> Compn: ok, i'll just disable the entire frame mess!
[06:07] <clever> Compn: there, it now works without my double buffering hack
[06:07] <clever> and yay!!, it works on other files
[06:07] <clever> without having to recompile!
[06:09] <clever> and 720 is almost at a usable fps
[06:38] <Guest61581> Is there some kind of prioritization system for the Trac issues?
[06:50] <clever> Compn: getting 20 fps now!, but there is some frame drop
[06:50] <clever> and thats with a software pixel format change!
[06:50] <clever> fbdev doesnt like yuv420, and i havent fixed it yet
[06:54] Action: Compn afk
[06:55] <clever> A: 71.8 V: 66.5 A-V: 5.277 ct: 0.430 0/ 0 20% 68% 14.9% 1868 0
[06:55] <clever> ok, thats enough for one night
[06:55] <clever> except for the frame drop and xv replacement, its nearly done
[06:57] <clever> and ass subs are fully working
[06:57] <clever> hard to say how well it will run once scaled up, but its looking good
[06:58] Action: clever heads to bed
[10:18] <llogan> saste: any reason why @code is used for options and such instead of @option in texi?
[10:21] Action: llogan goes to bed but will look for replies, if any, in the morning
[10:26] <saste> llogan, where?
[11:07] <saste> [h264 @ 0x23ec080] non-existing PPS referenced
[11:07] <saste> what does this ^^ mean?
[11:44] <michaelni> saste, that a slice refers to a pps that doesnt exist
[11:45] <saste> michaelni, what is a PPS?
[11:45] <michaelni> picture parameter set
[11:46] <saste> michaelni, alright, but can you say why it happens?
[11:46] <saste> for the long story, see my mail on ffmpeg-devel
[11:47] <nevcairiel> usually such messages only show up briefly at the beginning of a badly-cut stream, when the decoder has not seen the PPS yet
[11:47] <michaelni> pps wont be repeated for every slice so when you start decoding at a random point you can run into slices that refer to a pps that hasnt bee seen
[11:48] <saste> michaelni, even if the starting packet is a key-packet?
[11:49] <saste> what's wrong with my assumption: key packet -> decodable I frame
[11:49] <nevcairiel> just because a packet contains a keyframe, does not mean the SPS/PPS are necessarily available yet. Ideally they should always preceed a I/IDR frame, but thats no guarantee
[11:51] <michaelni> also you can use -debug 1 to see whats in the h264 stream from the decoders point of view
[11:51] <saste> nevcairiel, so basically there is no reliable way to split a H.264 stream at key-packets?
[11:51] <nevcairiel> you could go digging for the PPS in question and manually ensure its present at the cut point
[11:53] <saste> nevcairiel, yes but not very practical
[11:53] <nevcairiel> in many streams the SPS/PPS is the same through the whole stream
[11:53] <michaelni> or just dump the pps&sps before the key frame you choose
[11:53] <nevcairiel> so you could just chekc extradata
[11:54] <nevcairiel> and put it into the stream
[11:54] <saste> can this be done programmatically with some already existing bsf?
[13:07] <kierank> 10:50 AM <"nevcairiel> just because a packet contains a keyframe, does not mean the SPS/PPS are necessarily available yet. Ideally they should always preceed a I/IDR frame, but thats no guarantee
[13:07] <kierank> they should for an IDR otherwise it's out of spec
[13:08] <nevcairiel> as if everyone produces files that are correct
[13:09] <iive> I think that they do for IDR, but IDR is rarely used.
[14:08] Action: ubitux wonders why trac makes any difference between search & query
[14:09] <ubitux> one is completely useless and the most simple to find
[14:09] <ubitux> and the other is pretty relevant and hard to find
[14:30] <michaelni> ubitux, i wondered about that too
[14:30] <michaelni> someone should maybe improve the user interface
[14:30] <ubitux> i don't actually even know how to access the /query link
[14:30] <ubitux> i just have it in my history since carl pointed it out
[14:31] <michaelni> view tickets, custom query
[14:31] <michaelni> but its impossible to find if one doesnt know where to look
[14:31] <ubitux> mmh ok
[14:32] <michaelni> also if someone has a patch to some template or ini file for trac to improve this ... send it to me
[14:41] <cone-410> ffmpeg.git 03Michael Niedermayer 07master:6aed7bfd8453: avcodec: use av_frame_unref() to set frame defaults
[14:41] <cone-410> ffmpeg.git 03Michael Niedermayer 07master:5abdda214df5: avcodec/utils: implement avcodec_alloc_frame() through av_alloc_frame()
[15:52] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:c5f7c8f9a9a1: avcodec/svq3: set last/next frames to defaults before use
[15:52] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:fca7943850ec: avcodec/diracdec: avoid depending on sizeof(AVFrame)
[16:54] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:c81234651f76: avcodec/msvideo1enc: drop dependancy on sizeof(AVFrame)
[16:54] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:5b3f4b3ef590: avcodec/mjpegenc: drop dependancy on sizeof(AVFrame)
[16:54] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:1458f0647ca0: avcodec/libopenjpegenc: drop dependancy on sizeof(AVFrame)
[17:18] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:8443b27072a0: avcodec/j2kenc: drop dependancy on sizeof(AVFrame)
[17:18] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:b8f4410ff60b: avcodec/flashsv2enc: drop dependancy on sizeof(AVFrame)
[17:18] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:bf1c87ee7ab1: ffprobe: drop dependancy on sizeof(AVFrame)
[17:38] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:3c8b085764ed: avcodec/libvorbisenc: drop dependancy on sizeof(AVFrame)
[17:38] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:c90f31146e8b: avcodec/utils: drop 2 dependancies on sizeof(AVFrame)
[18:09] <cone-446> ffmpeg.git 03Peter Holik 07master:6fd99e78def3: png: add a standalone parser
[18:09] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:47cc61686494: Merge commit '6fd99e78def3c795bdd0bc31f3ae0998d24bc94c'
[18:14] <cone-446> ffmpeg.git 03Vittorio Giovara 07master:eddff165b4cd: fate: add utility function to test parser, demuxer, and decoder
[18:14] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:b22989da47be: Merge commit 'eddff165b4cdc1f064245a4bad6f4265581c12b1'
[19:04] <cone-446> ffmpeg.git 03Vittorio Giovara 07master:cfb4ee309777: fate: add a pngparser test
[19:04] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:682b28b41098: Merge commit 'cfb4ee30977732674d30c20e93a761c33c743972'
[19:11] <cone-446> ffmpeg.git 03Luca Barbato 07master:3a149e23d37f: hevc: Refactor decode_nal_sei_frame_packing_arrangement
[19:11] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:4e1dc600a16e: Merge commit '3a149e23d37f06d49ab0bb013a3b9cb0224bba5c'
[19:35] <llogan> saste: in decoders.text for example: @code{--enable-lib}
[19:35] <llogan> texinfo says: you should use @code for an expression in a program, for the name of a variable or function used in a program, or for a keyword in a programming language.
[19:38] <cone-446> ffmpeg.git 03Vittorio Giovara 07master:3d9fc21e593a: h264: Refactor decode_frame_packing_arrangement
[19:38] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:d6acf45ec280: Merge commit '3d9fc21e593aa89b5877bd739268499b079052f2'
[19:54] <cone-446> ffmpeg.git 03Vittorio Giovara 07master:bd316109b333: apidoc: fix warning from stereo3d.h
[19:54] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:9be63be1b285: Merge remote-tracking branch 'qatar/master'
[19:58] <saste> llogan, what do you suggest to use instead?
[19:58] <saste> also i consider the option in a script as a sort of "expression in a program"
[19:59] <saste> the real alternative is probably @option{...}
[20:03] <llogan> saste: yes, @option
[20:03] <saste> llogan, patch welcome :)
[21:13] <dorileo> hi guys... I need to determine if an mpeg ts file's packet size is TS_PACKET_SIZE || TS_DVHS_PACKET_SIZE || TS_FEC_PACKET_SIZE but as far as I could see mpegts.c doesn't expose it anywhere, is there any "correct" way to get this information?
[21:14] <michaelni> its found during probing but IIRC not exportet
[21:15] <dorileo> btw, AVContextFormat structure has a packet_size field but I couldn't see where it's set as well, I'm thinking about sending a patch changing mpegts.c to set raw_packet_size to AVContextFormat->packet_size.
[21:15] <dorileo> michaelni: do you know if AVContextFormat->packet_size is set anywhere? I couldn't find it.
[21:16] <dorileo> michaelni: what do you think about setting AVContextFormat->packet_size = MpegTSContext->raw_packet_size ?
[21:24] <michaelni> probably possible, someone would have to test it and submit a patch, alternatively it could be exportet as private AVOption
[21:24] <dorileo> michaelni: sounds better using AVOption.
[21:25] <dorileo> michaelni: I can cook it up.
[21:25] <michaelni> ok
[21:41] <dorileo> michaelni: by "exported as private AVOPtion" do you mean setting adding it to AVFOrmatContext's metadata dict?
[21:49] <dorileo> michaelni: don't worry, I got it.
[22:08] <cone-446> ffmpeg.git 03Michael Niedermayer 07master:3e626548ce6d: avcodec/vc1dec: use av_mallocz for luma_mv
[23:56] <kierank> what a stupid discussion
[23:56] <kierank> it's clear ttx in wtv is not working but carl wants him to use a transport stream
[00:00] --- Wed Dec 18 2013
More information about the Ffmpeg-devel-irc
mailing list