[Ffmpeg-devel-irc] ffmpeg-devel.log.20180305
burek
burek021 at gmail.com
Tue Mar 6 03:05:03 EET 2018
[01:17:06 CET] <cone-397> ffmpeg 03Matt Wolenetz 07master:133ddd38750a: avformat/mov: Initialize a potential gap in ctts_data in mov_build_index
[01:49:31 CET] <gagandeep> Compn: which directory in the ffmpeg samples has interlaced videos
[01:51:20 CET] <gagandeep> Compn: or is there some method of searching for them, as the last time i discussed with you about deinterlacing, i have seen the attatched cineform file in windows media player and it was perfectly deinterlaced
[01:52:39 CET] <gagandeep> Compn: after that i learned that ffplay can also deinterlace videos using filter like yadif and did that on the file but it didn't really do much to the video, so i want to test out the filter more and see what kind of results to expect
[02:00:13 CET] <Compn> gagandeep
[02:01:31 CET] <Compn> hmm
[02:01:32 CET] <Compn> let me see
[02:05:42 CET] <Compn> gagandeep : https://xiph-media.net/video/derf/y4m/foreman_qcif.y4m
[02:06:35 CET] <Compn> oops
[02:06:36 CET] <Compn> not that
[02:07:08 CET] <Compn> hurgh
[02:15:03 CET] <Compn> http://samples.ffmpeg.org/MPEG-VOB/interlaced/tv2-1_25.mpg
[02:15:04 CET] <Compn> looks good
[02:18:38 CET] <Compn> hmm i cant reproduce the decoding errors here
[02:18:39 CET] <Compn> weird
[02:20:25 CET] <Compn> gagandeep : btw, kierank is mentor on the cineform project
[02:20:30 CET] <Compn> gagandeep : so please ask him for help :)
[02:38:32 CET] <gagandeep> Compn: i have asked kierank many times over the past 5 days but he hasn't been replying :/ and i mean ffmpeg is overwhelming, so if i don't break under the pressure it would be pretty miraculous at this point
[02:39:09 CET] <gagandeep> Compn: by the way thanks
[03:19:40 CET] <liyou> i demux h264 from ts file by ffmpeg, and i find some code in the output 264 file: E0 00 00 00 01 CE 8C 4D. how to remove the code?
[09:29:14 CET] <cone-682> ffmpeg 03Tobias Rapp 07master:a194e9c41598: fftools/ffmpeg: fix progress log message in case pts is not available
[09:29:15 CET] <cone-682> ffmpeg 03Tobias Rapp 07master:69995a94d840: fftools/ffmpeg: update print_report to use AVBPrint API
[10:40:37 CET] <rcombs> >Thanks for the great work so far.
[10:40:40 CET] <rcombs> lol thanks I guess
[10:40:49 CET] <rcombs> does anyone have any ideas on how to handle the tiling bullshit
[10:41:20 CET] <rcombs> I don't want it to be an ffmpeg.c hack but I really don't see any other way to do it
[10:41:31 CET] <rcombs> since it needs post-decoder processing
[10:41:57 CET] <JEEB> yea, and we don't want to stick it into the HEVC decoder either
[10:41:58 CET] <JEEB> lol
[10:43:32 CET] <rcombs> particularly since then it'd have to separately go into every HEVC decoder anyone used
[10:43:50 CET] <rcombs> actually
[10:44:23 CET] <rcombs> I wonder if you could rewrite a grid of tiles into a single valid frame
[10:44:37 CET] <rcombs> since all the borders would be at macroblock boundaries&
[10:46:55 CET] <rcombs> I'm not gonna learn enough HEVC to figure out how to do that, though
[10:47:12 CET] <rcombs> also the format allows the extradata to be different in different tiles, even though I'm pretty sure nobody's ever going to use that
[11:00:29 CET] <JEEB> hah, gotta love that perverted format
[11:03:42 CET] <manishv> can anyone tell how to do testing of a bug after changing some code?
[11:05:39 CET] <manishv> I want to do testing of some bug but how to check whether it works fine after code modification or not?
[12:01:00 CET] <gagandeep> kierank: i have looked in the codec and decoder files of cineform-sdk and have found that there are certain 'INTERLACED_FLAGS' associated with the cineform encoded files and they use a different vertical high pass filter so how do i access the interlace flags on files and further process them
[12:06:10 CET] <gagandeep> guys what should i read about to understand how to access the flags of a video stream or file
[12:06:28 CET] <Oleg> Hi all. I work on als encoder and in documentation there is term "approximate common factor of floating-point sequence". How I can compute it ?
[12:06:40 CET] <Oleg> can somebody explain this term&
[12:06:43 CET] <Oleg> ?
[12:07:23 CET] <gagandeep> basically i need to access the flag that tells if the video is interlaced or progressive and based on that change the decoding filter a bit for wavelet inverse transform
[12:09:20 CET] <gagandeep> durandal_1707: can you help me with my question that i posted above?
[12:19:55 CET] <kierank> gagandeep: i can help you in 2-3 hours
[12:23:23 CET] <gagandeep> kierank: welcome back :)
[12:27:01 CET] <leriano7> hello!
[12:27:03 CET] <leriano7> can I write here my shell command to check ?
[12:31:49 CET] <jdarnley> what?
[12:32:10 CET] <jdarnley> if you want help with using ffmpeg then I suggest the #ffmpeg channel
[13:40:46 CET] <BBB> kierank: I think theres enough outstanding objections that it wont be committed as-is, right?
[13:40:54 CET] <BBB> or did the review process change recently?
[13:43:06 CET] <durandal_1707> "will apply"
[15:06:57 CET] <jamrial> jkqxz: ping, and ignore the accidental ping in #videolan :p
[15:12:11 CET] <jkqxz> jamrial: Pong.
[15:12:26 CET] <jamrial> jkqxz: https://0x0.st/smSx.patch
[15:14:10 CET] <jamrial> the malloc + memcpy seems pointless in ff_cbs_write_packet(), seeing there's always buffer allocated and ready to use
[15:15:17 CET] <jamrial> it's faster on big packets, of course, and makes no real difference on small ones
[15:16:02 CET] <jkqxz> Yeah. I have more stuff eliminating it in some of the other cases, too.
[15:17:50 CET] <jkqxz> I was also considering doing something to return references to the fragment write buffer for H.264 (eliminating that copy as well), but whether it helps depends on what the user does with the result.
[15:20:08 CET] <jkqxz> Do you have a particular aim in mind which needs high performance from CBS writing?
[15:21:15 CET] <jamrial> not really, just saw a low hanging fruit and picked it
[15:22:37 CET] <jamrial> and if you mean making ff_h2645_packet_split() return each nal unit as a refcounted buffer, i'm not sure that's a good idea. allocating all those buffers is going to be slower than the current single rbsp buffer
[15:23:43 CET] <jkqxz> I wonder whether the realloc() actually helps anything in the write.
[15:24:56 CET] <jamrial> the realloc in cbs_h2645_assemble_fragment?
[15:25:31 CET] <jkqxz> I was meaning the writing into priv->write_buffer and then copying out. If that was a refcounted buffer and we called make_writable() before using it then there could be win if the user doesn't buffer packets.
[15:26:54 CET] <jkqxz> Yeah, that one. It exists because emulation prevention could expand the buffer by 50% in theory, but in reality (for nondegenerate cases) it's basically zero.
[15:28:34 CET] <jamrial> i tried a h264 file and it seems to reduce the packet to 3/4 of max_size most of the time
[15:29:47 CET] <jamrial> https://pastebin.com/raw/qcvnxXic
[15:29:58 CET] <jkqxz> It's not difficult to make degenerate slices in CABAC mode which end up being pretty much all zeroes. The average case is far less than that, though.
[15:31:08 CET] <jkqxz> Those numbers look pretty close to the no-change 2/3 value?
[15:33:20 CET] <jamrial> not sure i follow. but then again i'm not really familiar with this code :p
[15:33:37 CET] <jkqxz> Patch above LGTM. Maybe adjust max_size in cbs_h2645_assemble_fragment() to include the padding (so that the realloc is always a shrink), but I doubt it matters.
[15:35:11 CET] <jkqxz> Emulation prevention can expand the file by 50%, so the max size is set to that. If your new value there is 2/3 of the old value then nothing has happened.
[15:35:30 CET] <jkqxz> (That is, no (or very little) emulation prevention was actually applied.)
[15:35:43 CET] <jamrial> i see
[15:39:06 CET] <jamrial> jkqxz: like this https://0x0.st/smS6.patch ?
[15:40:30 CET] <jamrial> mmh, maybe it's simpler to just add the padding to the malloc call instead
[15:41:41 CET] <jkqxz> Yeah, the assert() on max_size is off if you do it like that. (Though it should never be hit...)
[15:41:58 CET] <jamrial> https://0x0.st/smSI.patch
[15:44:31 CET] <jkqxz> LGTM :)
[15:45:45 CET] <cone-682> ffmpeg 03James Almer 07master:df3a2ff7670a: avcodec/cbs: use a reference to the assembled CodedBitstreamFragment buffer when writing packets
[16:01:36 CET] <gagandeep> kierank: i was busy and i missed the time you alloted me, i think let me prepare a list of questions and you tell me a suitable time when you can answer them
[16:02:37 CET] <gagandeep> kierank: also i will still be afk for the next 2 hrs, so i am really sorry i couldn't contact you at the time you allocated
[16:03:33 CET] <gagandeep> kierank: by the way if you want you can send me some instructions at deepgagan231197 at gmail.com
[16:21:57 CET] <durandal_1707> gagandeep_: have you found flag in bitstream that marks interlaced material?
[16:45:20 CET] <kierank> BBB: dunno
[17:50:14 CET] <gagandeep_> durandal_1707: was afk, the flag was given in codec.h and codec.c
[17:52:05 CET] <gagandeep_> along with the structure of INTERLACED_STRUCTURE like only one field flag, with their bits #define and further a macro for checking the interlace structure
[17:52:46 CET] <jdarnley> atomnuker, others: can I ask you to reproduce a crash for me?
[17:53:08 CET] <jdarnley> apply this patch https://pastebin.com/VHaX5fDb and build
[17:53:36 CET] <jdarnley> then run ./ffmpeg -loglevel debug -f lavfi -i 'testsrc2=hd720, format=yuv422p10' -vframes 10 -interlaced 1 temp.vc2
[17:54:05 CET] <jdarnley> and see if it crashes with this message "Assertion n <= s->buf_end - s->buf_ptr failed at libavcodec/put_bits.h:337"
[17:58:13 CET] <gagandeep_> kierank: there is some macro defined in codec.h called THREADED_WORKER, are those for using multiple threads of a core in processor
[17:58:34 CET] <kierank> what is codec.h?
[17:58:43 CET] <kierank> in the cineform code sure, but it's irrelevant for gsoc
[17:58:51 CET] <kierank> all you care about is fixing the codec bugs
[17:58:58 CET] <kierank> and understanding how the cineform code is different to ffmpeg
[17:59:36 CET] <gagandeep_> kierank: so have you seen the interlaced flags in codec.h in Codec directory of cineform-sdk
[18:00:11 CET] <kierank> yes but completely unrelated
[18:00:44 CET] <kierank> gagandeep_: see readme
[18:00:45 CET] <kierank> he explains there
[18:01:11 CET] <gagandeep_> ok, also in the wavelet.c in example directory, the interlaced was using vertical transform of 22 wavelet for first level
[18:01:45 CET] <gagandeep_> in cfhd.c only 26 wavelet transform is used, so do you think it will do the trick
[18:03:41 CET] <kierank> not sure what "22" wavelet refers to
[18:05:03 CET] <gagandeep_> in the high pass filter only dest[(i>>2) +half] = src[i]-src[i+1]
[18:05:26 CET] <gagandeep_> whereas in 26 wavelet that 11* 4* 1* formula is used
[18:05:35 CET] <atomnuker> jdarnley: yes
[18:05:41 CET] <atomnuker> also you don't need a patch
[18:05:46 CET] <atomnuker> or a special setting
[18:05:49 CET] <atomnuker> there's already one
[18:05:56 CET] <atomnuker> its called -field_order tt
[18:06:32 CET] <jdarnley> thanks * 2
[18:10:57 CET] <gagandeep_> kierank: let me check the wavelet.c from the Codec directory, i think the interlace error is due to different inverse transform
[18:11:27 CET] <kierank> that could be the solution, but basically see if you get a good picture
[18:15:27 CET] <gagandeep_> kierank: also i just found there is temporal transform implemented in some filters, but that i don't need to look, only try invert spatial transform for interlaced
[18:16:15 CET] <kierank> yes
[18:16:59 CET] <gagandeep_> also, if you want you can set a time for the day when you are available
[18:17:24 CET] <gagandeep_> i mean that would be comfortable for both of us
[18:18:10 CET] <gagandeep_> i am at IST(INDIAN STANDARD TIME) +5:30
[18:19:35 CET] <gagandeep_> kierank: thanks and goodbye
[21:18:23 CET] <llogan> Anyone getting a "Gateway Timeout" when trying to log into trac? Timo said he can't login and gets that message, but I can't dupe it.
[21:18:44 CET] Action: llogan too lazy to look at logs yet
[21:20:55 CET] <klaxa> i can log in
[21:22:05 CET] Action: durandal_1707 too lazy to log in
[21:22:13 CET] <llogan> BtbN: are you Timo? (Apparently I can't remember names anymore...engage dementia)
[21:22:19 CET] <BtbN> yes
[21:22:43 CET] <BtbN> I'll push something in like 5-50 minutes(whenever configure finishes) to help a bit with the situation
[21:23:03 CET] <llogan> does your BtbN account not work either?
[21:23:10 CET] <BtbN> it's oromit on trac
[21:23:17 CET] <llogan> there is also a Btbn
[21:23:24 CET] <BtbN> That's not mine then.
[21:23:52 CET] <BtbN> At least I don't recall ever using that on trac
[21:24:07 CET] <llogan> email domain on that one is btbn.de
[21:24:20 CET] <BtbN> weird. You can just delete it then I guess. I'm not using it.
[21:24:43 CET] <BtbN> but login worked now instantly for me as well
[21:24:59 CET] <BtbN> The last like 5 days it just kept loading forever and then gave me a gateway timeout page from nginx or something
[21:26:23 CET] <llogan> ok. if only all issues fixed themselves like that...
[21:30:19 CET] <durandal_1707> any good administrator should check logs all the time to know if someone bad have entered system
[21:30:41 CET] <BtbN> I think it's just easily overloaded
[21:31:31 CET] <cone-545> ffmpeg 03Timo Rothenpieler 07master:5787908e8c63: configure: rename cuda to ffnvcodec
[21:31:45 CET] <llogan> durandal_1707: want the job?
[21:32:42 CET] <durandal_1707> llogan: administrator job is worst: underpaid and stressfull
[21:32:55 CET] <llogan> this has no pay
[21:45:07 CET] <cone-545> ffmpeg 03Rostislav Pehlivanov 07master:8218249f1f04: parseutils: accept only full "ms" suffix
[21:47:20 CET] <wm4> thus underpaid
[21:49:17 CET] <atomnuker> jamrial / nevcairiel: could either of you take a look at the SBC mmx asm patch on the ML? looked fine to me but maybe someone else should take a look as well
[21:50:08 CET] <durandal_1707> atomnuker: you havent asked me? how dare you! i know assembly the best
[21:50:32 CET] <atomnuker> go ahead then
[21:50:56 CET] <atomnuker> it looks straightforward
[21:51:20 CET] <durandal_1707> it is just copy paste mmx port, isnt it?
[21:51:46 CET] <atomnuker> port? well its from another library afaik
[21:56:43 CET] <durandal_1707> i guess calling emms only in one function is enough? Guess nobody will add float code between calls ...
[21:58:09 CET] <durandal_1707> actually it calls it twice ...
[22:00:28 CET] <durandal_1707> atomnuker: better remove that emms call from assembly...., it calls emms_c right after....
[22:01:35 CET] <atomnuker> maybe we should reject this on the grounds its mmx only and instead make the author or someone else rewrite it so it uses sse
[22:01:46 CET] <jamrial> atomnuker: no
[22:02:00 CET] <atomnuker> there are still CPUs without SSE but MMX?
[22:02:09 CET] <atomnuker> (well historically there are)
[22:02:53 CET] <jamrial> it's already written and if it's measurably better than c then no reason to reject it, simple as that
[22:03:17 CET] <jamrial> of course an sse2 version would be ideal, but if he doesn't want to write it then i doubt anyone else will bother
[22:09:39 CET] <BtbN> llogan, you don't happen to be able to setup a github mirror of the nv-codec-headers repo?
[22:13:25 CET] <llogan> BtbN: I don't know shit about github, but I may be able to add you so you can do it.
[22:13:34 CET] <BtbN> I am added
[22:13:43 CET] <BtbN> but I have no clue how the mirroring works
[22:13:55 CET] <BtbN> also, I can't create new repos anyway
[22:15:09 CET] <llogan> I bet TimothyGu knows but he seems busy.
[22:15:33 CET] <llogan> i'll look at it in a little while
[22:26:51 CET] <llogan> BtbN: looks like I'm in the "members" team with michael and timothy but I have no admin rights for the FFmpeg organization...I used to, IIRC.
[22:37:50 CET] <michaelni> BtbN, i can create a repo for the FFmpeg org on github i think. What should it be called? should it be a clone or a new repo ?
[22:38:25 CET] <BtbN> michaelni, automatic mirror of http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git
[22:38:26 CET] <BtbN> same name I guess
[22:38:56 CET] <michaelni> about mirroriing there are at least 2 scripts mirroring stuff
[22:39:17 CET] <BtbN> I can just keep it in sync manually until that is sorted. It's not exactly high traffic
[22:40:14 CET] <michaelni> i dont remember exactly about the mirroring, timothy runs one set of scripts for mirroring ...
[22:40:39 CET] <BtbN> TimothyGu, ^
[22:41:32 CET] <BtbN> If you could just create the repo for now that'd be nice. Mirroring stuff can be sorted out later.
[22:41:51 CET] <BtbN> Github has more visibility for users, so having it there would hopefully help with the confusion about the nvidia headers move.
[22:44:29 CET] <michaelni> "fatal: repository 'http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git/' not found", so i guess i should create a new empty repo
[22:52:47 CET] <jamrial> michaelni: try https://git.videolan.org/git/ffmpeg/nv-codec-headers.git ?
[22:53:31 CET] <michaelni> BtbN, created https://github.com/FFmpeg/nv-codec-headers (as empty repo you can push the clone to it) you should be admin of this now
[23:19:44 CET] <BtbN> thanks
[23:32:34 CET] <cone-545> ffmpeg 03Ruiling Song 07master:8ca39b855a7b: qsv: Default PicStruct to progressive
[23:32:35 CET] <cone-545> ffmpeg 03Mark Thompson 07master:085a2eb8e273: Merge commit '8ca39b855a7b0e4d9f726fa9d285bc8edcb953e6'
[23:34:57 CET] <cone-545> ffmpeg 03James Almer 07master:dc40e64adb17: hvcc: zero initialize the nal buffers past the last written byte
[23:34:58 CET] <cone-545> ffmpeg 03Mark Thompson 07master:706d2c66e8e5: Merge commit 'dc40e64adb1712b1209c018914a44f809bc32664'
[23:46:36 CET] <jkqxz> wbs: Anything special I should do for merging e2399e0c1aeb110456405d23e211066fab6cb041?
[23:46:54 CET] <jkqxz> It looks like it merges straightforwardly with two minor edits, but I'm not sure how to test it.
[23:55:26 CET] <jamrial> jkqxz: i'm not actually sure the issue mentioned in that commit affects us
[23:55:39 CET] <jamrial> i've seen fate reports with early configure failures
[23:56:45 CET] <jkqxz> It looks harmless to apply anyway.
[23:56:53 CET] <jkqxz> Or should I just skip it?
[23:57:45 CET] <jamrial> michaelni: what do you think re ^
[23:58:06 CET] <jamrial> no real way to test this without actually sending a report to the fate server
[00:00:00 CET] --- Tue Mar 6 2018
More information about the Ffmpeg-devel-irc
mailing list