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

[burek]

[00:03:56 CEST] <rcombs> trying to come up with a way to handle poorly-muxed files better in lavf
[00:04:15 CEST] <rcombs> specifically, stuff where the packets are poorly interleaved 
[00:05:03 CEST] <rcombs> apparently transferring a video taken on an iPhone to a Windows machine produces an MP4 with alternating large chunks of video and audio packets
[00:05:40 CEST] <rcombs> and I've seen a few other sources of similar files crop up lately
[00:06:31 CEST] <rcombs> it's usually fine on disk, but it absolutely fucks up HTTP
[00:06:50 CEST] <rcombs> in mpv, it's _sometimes_ fine, depending on timing
[00:07:53 CEST] <rcombs> if the cache manages to pre-fill to the next seek target before the seek happens
[00:10:00 CEST] <rcombs> I'm thinking, maybe the demuxer could call an avio function to "hint" what stream the next seek will be for
[00:11:11 CEST] <rcombs> and if the "hints" are opaque, you could also use this to read trailers without having to reset your transfer to seek back
[00:12:46 CEST] <rcombs> a smart cache like mpv's could either open a new underlying AVIO context or just read ahead with an existing one depending on the distance
[00:13:22 CEST] <rcombs> not sure what I'd want plain avio to do
[00:48:34 CEST] <rcombs> the alternative would be for the demuxer to read the packets linearly in file order, and have lavf or the consumer deal with the poor interleave
[01:15:46 CEST] <atomnuker> I think that's smarter, read packets in order and store info on the type of packet and its location
[01:17:44 CEST] <atomnuker> so you'd have a per-stream queue, and if the client requests a packet from a stream with no packets you'd return averror_eagain to request more data
[08:44:01 CEST] <gagandeepsingh> atomnuker: have you checked the mail i sent you?
[08:48:20 CEST] <rcombs> atomnuker: well AVPacket already stores all that info; we'd just need either a way for lavf to buffer and reinterleave packets, or a way for the consumer to opt-in to receiving poorly-interleaved packets
[08:49:22 CEST] <rcombs> though I do still like the idea of being able to open an extra connection to read trailers, since that could save an RTT at startup in anything that has important data at the end (often e.g. mp4, mkv)
[08:49:31 CEST] <rcombs> id3v2, even
[11:30:22 CEST] <gagandeepsingh> kierank:are you busy today as well?
[11:31:29 CEST] <kierank> Yes, will have to look during weekend
[11:32:15 CEST] <gagandeepsingh> alright
[11:33:12 CEST] <gagandeepsingh> i am having some problem in the initial frames and then the next frames are decoded properly so that is why i am seeking help now
[11:47:47 CEST] <durandal_1707> gagandeepsingh: where is your code?
[11:48:07 CEST] <gagandeepsingh> right now i can send you a link to dropbox file
[11:48:10 CEST] <gagandeepsingh> will that be fine
[11:48:17 CEST] <gagandeepsingh> or a rough patch file
[11:48:30 CEST] <gagandeepsingh> the patch is not what i will  submit for final review
[11:48:45 CEST] <durandal_1707> no, i hate dropbox, just paste full file
[11:48:54 CEST] <gagandeepsingh> pastebin?
[11:48:59 CEST] <durandal_1707> sure
[11:49:18 CEST] <gagandeepsingh> gimme a sec
[11:51:45 CEST] <gagandeepsingh> durandal_1707: https://pastebin.com/09xaV0Sp
[11:53:52 CEST] <gagandeepsingh> durandal_1707: here is cfhd.h 
[11:53:53 CEST] <gagandeepsingh> https://pastebin.com/dH0qLiyc
[12:02:02 CEST] <durandal_1707> gagandeepsingh: please post link again, my stupid windows box died yet again (become unresponsive)
[12:03:46 CEST] <gagandeepsingh> durandal_1707: https://pastebin.com/09xaV0Sp
[12:03:57 CEST] <gagandeepsingh> cfhd.h : https://pastebin.com/dH0qLiyc
[12:06:47 CEST] <durandal_1707> gagandeepsingh: why you commented out code at line 916 in cfhd.c ?
[12:07:56 CEST] <gagandeepsingh> i think i had done that for running mountain sample
[12:08:32 CEST] <gagandeepsingh> it was just an error check and mountain sample was not having certain tags in 1st packet
[12:09:16 CEST] <gagandeepsingh> namely image width and height
[12:09:32 CEST] <gagandeepsingh> but i will need to confirm it again as it was a month ago
[12:10:38 CEST] <gagandeepsingh> also for frame threading i will be allocating more memory for temporary buffers to work independently
[12:11:04 CEST] <gagandeepsingh> but i only want you to check how i managed to break only intra frame sample decoding
[12:13:08 CEST] <durandal_1707> gagandeepsingh: why you always left shift progress1 ?
[12:13:54 CEST] <durandal_1707> i thought it should be hardcoded, so when you put it to some number, like 10, and await same number 10 it will continue execution
[12:14:24 CEST] <durandal_1707> currently it could wait indefinetely..
[12:15:02 CEST] <gagandeepsingh> i can hardcode certainly, but i didn't think how waiting indefinetely could happen?
[12:16:28 CEST] <durandal_1707> well, because you shift, and do not use simple +1 it could break after 31 shifts :-)
[12:17:09 CEST] <gagandeepsingh> would it reach 31 shifts before ending run?
[12:17:30 CEST] <durandal_1707> gagandeepsingh: dunno, you should know that better :-)
[12:17:43 CEST] <gagandeepsingh> ok, i will see to it
[12:18:55 CEST] <durandal_1707> the progress argument tell how far you have decoded that frame
[12:19:25 CEST] <durandal_1707> and if another frame needs certain area you can signal it
[12:19:34 CEST] <durandal_1707> and wait for it
[12:20:13 CEST] <gagandeepsingh> yeah, that was the idea
[12:20:38 CEST] <gagandeepsingh> progress1 is for first frame, progress2 is for second frame
[12:21:14 CEST] <gagandeepsingh> s->picture is the frame that thread will return in the supplied frame
[12:21:30 CEST] <gagandeepsingh> s->connection is the one the thread need to await for progress
[12:22:37 CEST] <gagandeepsingh> for the p frame thread the s->picture and s->connection address is supplied by update_thread_context
[12:23:06 CEST] <gagandeepsingh> the frames are stored with the intra frame decoding thread
[12:23:26 CEST] <gagandeepsingh> although 2 frames are allocated for every thread at the init
[12:25:23 CEST] <JEEB> (56
[12:27:28 CEST] <durandal_1707> gagandeepsingh: line 1118, should report be before frame ref?
[12:29:13 CEST] <gagandeepsingh> that is intra only stuff, reporting doesnt matter here
[12:29:29 CEST] <gagandeepsingh> just added it for consistency
[12:29:37 CEST] <gagandeepsingh> the intra only code ends there
[12:30:14 CEST] <gagandeepsingh> initially i wasn't aware i would have to use av_frame_copy_props from the supplied frame and that was causing trouble
[12:30:35 CEST] <gagandeepsingh> still i am managing to break the intra only decoding
[12:31:20 CEST] <gagandeepsingh> code below that is all ip frame
[12:32:59 CEST] <durandal_1707> gagandeepsingh: you nowhere use ff_thread_ref_frame
[12:35:38 CEST] <gagandeepsingh> i don't think i needed it, it creates a buffer ref for progress, buffer ref for frame buffer, and copies owner
[12:36:11 CEST] <gagandeepsingh> av_frame_ref is sufficient to create buffer ref for the supplied frame once decoding is done
[12:36:52 CEST] <gagandeepsingh> and i don't think i get an allocated frame buffer from the supplied frame?
[12:37:14 CEST] <gagandeepsingh> supplied frame is the one passed to the cfhd_decode function
[12:37:27 CEST] <durandal_1707> you need it if one thread needs frame of another thread, to be used in update_thread_context
[12:37:58 CEST] <gagandeepsingh> i am not having different threads write data to another frame
[12:38:08 CEST] <gagandeepsingh> each thread gets to write data to its frame
[12:38:13 CEST] <durandal_1707> gagandeepsingh: so only intra videos are broken, how broken?
[12:38:44 CEST] <gagandeepsingh> the first few frames give seg fault, but sometimes ffplay is able to run it completely and the later frames are perfectly decoded
[12:39:06 CEST] <durandal_1707> but first frames are corrupted?
[12:39:16 CEST] <gagandeepsingh> yeah, corrupted is the word
[12:39:54 CEST] <gagandeepsingh> only sometimes the ffplay will run the file with corrupted frames, otherwise just seg fault and crash
[12:41:10 CEST] <durandal_1707> gagandeepsingh: and non-intra videos always decodes fine, have you measured speed up with ffmpeg -threads X -i Y -f null - ?
[12:41:37 CEST] <durandal_1707> for X = 1 and X = number of cpu cores?
[12:41:58 CEST] <gagandeepsingh> ip files are also like this, but i reckon fixing the intra first should be a lot easier than the ones where communication between threads is to be accounted for
[12:45:24 CEST] <durandal_1707> gagandeepsingh: if you are on linux? have you debugged crash with valgrind?
[12:45:39 CEST] <gagandeepsingh> don't know what that is?
[12:46:25 CEST] <durandal_1707> http://valgrind.org/
[12:46:28 CEST] <gagandeepsingh> let me look into it
[12:46:43 CEST] <gagandeepsingh> some memory debugging tool, seeing it, will try it
[12:50:18 CEST] <cone-963> ffmpeg 03Jun Zhao 07master:1581caa7ca6f: lavc/hevcdec: add ONLY_IF_THREADS_ENABLED where it is missing.
[12:50:23 CEST] <durandal_1707> gagandeepsingh: you are missing .init_thread_copy
[12:54:12 CEST] <gagandeepsingh> durandal_1707: going to class will talk later tonight.
[12:54:33 CEST] <gagandeepsingh> thanks for taking a look at the code
[15:21:17 CEST] <durandal_1707> jamrial: for you only sample where door opens decodes with artifacts?
[15:22:15 CEST] <jamrial> durandal_1707: no, both looked broken. pixel columns shifted all around
[15:22:54 CEST] <durandal_1707> perhaps i pushed something bad ...
[15:25:51 CEST] <durandal_1707> jamrial: could you try to do fresh git pull and recheck it? you are on 64bit?
[15:26:39 CEST] <jamrial> durandal_1707: yes, give me a minute
[15:40:41 CEST] <jamrial> durandal11707: https://0x0.st/s4xV.png https://0x0.st/s4xW.png
[15:43:02 CEST] <durandal11707> funny, perhaps default permutation on x64 is not none?
[15:51:03 CEST] <kierank> durandal11707: yes looks like transpose dct
[15:51:52 CEST] <durandal11707> but on x32 it decodes fine but with artifacts on door opening
[15:57:51 CEST] <jdarnley> Oh man.  I remember the fallout from changing the mpeg dct.  Is this another corner case We ddin't find att he time?
[15:58:28 CEST] <jdarnley> *we didn't find at the time
[16:05:03 CEST] <durandal11707> lol, all the time i was using idct none
[18:37:03 CEST] <gagandeepsingh> durandal_1707: any leads?
[18:37:35 CEST] <durandal_1707> gagandeepsingh: use valgrind
[18:37:41 CEST] <durandal_1707> i will not do your work
[18:41:46 CEST] <durandal_1707> or gdb, or any sane debugger
[18:42:39 CEST] <gagandeepsingh> ok, you still helped a lot by looking at the file and perhaps even to you the syntax that i have written is sane?
[18:43:18 CEST] <gagandeepsingh> will be trying out valgrind next, this is new to me. Thanks
[18:43:21 CEST] <durandal_1707> gagandeepsingh: well, do not do guessing game if you can use right tools for the job
[18:43:41 CEST] <durandal_1707> gagandeepsingh: using valgrind is trivial if you are on linux
[18:44:05 CEST] <gagandeepsingh> sure, i am on linux
[20:05:45 CEST] <durandal_1707> jamrial: try latest github (i did forced push) if you want...
[20:21:21 CEST] <jamrial> durandal_1707: sure
[21:02:43 CEST] <cone-446> ffmpeg 03Kyle Swanson 07master:87cc7e8d4ef8: lavfi/vf_libvmaf: update to use libvmaf v1.3.9
[21:16:22 CEST] <jamrial> durandal_1707: looks good now. the door opening is still full of artifacts, though
[00:00:00 CEST] --- Sat Aug 11 2018