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

[burek]

[00:15] <J_Darnley> What pixel format are you giving as input?
[00:15] <J_Darnley> Green sounds like there are chroma planes set to 0.
[00:16] <Orix> AV_PIX_FMT_YUV420P
[00:18] <J_Darnley> Then either use a grayscale one or set the chroma to 128
[00:21] <ubitux> smarter: i think you can extract the planes with something like ffmpeg -i ... out%d.Y or something
[00:21] <Orix> i wanted to avoid passing the grayscale format into the swscale but that seems to work
[00:22] <smarter> ubitux: hmm
[00:28] <Orix> is there a way to check a flag for grayscale? I see in Rad Tools it says "File type: grayscale"
[00:28] <Orix> anyway to check that with ffmpeg?
[00:29] <J_Darnley> Do you mean "check a file"?
[00:30] <J_Darnley> ffprobe and ffmpeg can both print info about files.
[00:30] <J_Darnley> They should both print the pixel format found in a file
[00:30] <J_Darnley> They won't check content though.
[00:31] <Orix> Using the API, not using ffprobe or ffmpeg. The api is reporting the pixel format AV_PIX_FMT_YUV420P but I get a green layer on top of the video. If I force it to use AV_PIX_FMT_GRAY8 as the source format it looks fine (but the other videos become gray scale)
[00:35] <J_Darnley> In that case I don't know.
[00:45] <iive> Orix: what is the original codec used by the file?
[00:45] <iive> is it possible that you are not using correctly the chroma planes and somehow zero them.
[01:09] <Orix> iive: the codec is bink and its reporting as AV_PIX_FMT_YUV420P
[01:11] <iive> Orix: do you get green if you play it with ffplay?
[01:11] <Orix> let me try
[01:11] <Orix> Yes, I get green with ffplay
[01:13] <cone-109> ffmpeg.git 03Diego Biurrun 07master:c3c96deb5f8c: fft-test: Check memory allocations
[01:13] <cone-109> ffmpeg.git 03Michael Niedermayer 07master:074bb7515e33: Merge commit 'c3c96deb5f8cbbdb700ba97920ceedddacb5dcb9'
[01:13] <cone-109> ffmpeg.git 03Michael Niedermayer 07master:629e5e28f70a: avcodec/fft-test: fix memory alloc checks
[01:14] <iive> then it might be codec problem, kshishkov is the person who knows most about bink, he is however libav developer, if he is ineterested in bink samples at all.
[01:14] <iive> do you have other files that have same issue?
[01:14] <Orix> nope, just that one
[01:15] <Orix> and the only difference i can see is Rad Tools tells me that format is Grayscale while the other is Color
[01:16] <iive> if I remember correctly, libavcodec image allocations fills chroma samples with 0x80, specifically to give gray image instead of green one.
[01:17] <iive> it might be bug, or improper codec handling.
[01:17] <Orix> i'm pretty fresh to ffmpeg so i haven't gone digging into the implementation yet
[01:17] <Orix> makes me feel better that ffplay shows it as green as well
[01:17] <iive> do you have bink encoder? something that could produce small sample file?
[01:18] <Orix> hmm, no not off hand. I can look at generating one though
[01:19] <iive> well, in any case it would be good idea to fill bugreport and provide sample, to ffmpeg or/and libav
[01:21] <michaelni> yes, please open a bug report at trac.ffmpeg.org
[01:21] <Orix> alright, will do. i'll see about getting a sample file
[01:22] <michaelni> thanks
[01:35] <kierank> any suggestions about how to make the opus parser special case ts input
[01:43] <cone-109> ffmpeg.git 03Diego Biurrun 07master:6133d65861f2: fft-test: K&R formatting cosmetics
[01:44] <cone-109> ffmpeg.git 03Michael Niedermayer 07master:02ea384abd8e: Merge commit '6133d65861f265d429ade53e910fe877c95a1615'
[01:51] <BBB> what is max_transform_hierarchy_depth_intra/inter in the sps?
[01:51] <BBB> I mean, I can see what the code does, but its all crypto-nonsense to me; what is the english-language meaning of that element?
[02:00] <cone-109> ffmpeg.git 03Diego Biurrun 07master:d0de7330b973: fft-test: Pass correct struct members to (i)dct functions
[02:00] <cone-109> ffmpeg.git 03Michael Niedermayer 07master:ab0f78ea7777: Merge commit 'd0de7330b973b354e2ceb0b99fd545b868b0a9c4'
[02:16] <llogan> git bisecting. did understand why it didn't pinpoint regression after many bisects. realized i was running ffmpeg instead of ./ffmpeg. beer desire increased.
[02:16] <llogan> *didn't
[02:22] <cone-109> ffmpeg.git 03Diego Biurrun 07master:ce2e858f5b34: http: K&R formatting cosmetics
[02:22] <cone-109> ffmpeg.git 03Michael Niedermayer 07master:8b59ab1af0dd: Merge commit 'ce2e858f5b3416c2d54f7f8c14e901f75c48b785'
[05:22] <cone-109> ffmpeg.git 03Lukasz Marek 07master:97392553656a: lavfi/src_movie: remove frame from priv context
[05:22] <cone-109> ffmpeg.git 03Lukasz Marek 07master:f7539562522b: lavfi/src_movie: minor simplifications
[08:05] <kurosu_> BBB: that's the log2 scale between a intra/inter CU and the transform blocks it can contain
[08:06] <kurosu_> another view is, there's a quadtree of transform syntax (last coeff, cbp, etc), and it's its level
[08:06] <kurosu_> the partitioning of the coding block may have an impact but I don't recall well
[08:07] <kurosu_> I'd say it's like the 8x8 transform flag in avc except it can go deeper
[08:07] <kurosu_> regarding the threading api, I don't know
[08:08] <kurosu_> big blocks are probably required to need it, but ffvp9 is so much faster (and those probabilities being reused between frames) that I wonder
[08:09] <kurosu_> I would have thought it could be reused there, but I didn't plan to perform a study on how reusable it is
[08:10] <mraulet> might be good to encode a sequence with max ctb size == 16
[08:10] <kurosu_> mostly, you told me you had tested something similar in ffvp9 and it didn't help - and I wanted to see for myself
[08:11] <kurosu_> mraulet, hi
[08:11] <mraulet> hi
[08:11] <kurosu_> I know you have another threading for shvc, didn't quite check how compatible they were
[08:12] <kurosu_> but it works in openhevc and the few sequences I tested
[08:12] <mraulet> it is from my point of view
[08:12] <kurosu_> (they were main)
[08:12] <mraulet> I havent tested it but I dont see any compatibilty issue with what you propose
[08:13] <kurosu_> you were more concerned about threading over slices/tiles and over frames
[08:13] <mraulet> yes
[08:13] <kurosu_> the 2 being mixed could not play well
[08:13] <mraulet> but this is also what we have in shvc
[08:13] <mraulet> we do have 2 decoders running in parallel
[08:14] <kurosu_> unfortunately, neither ffmpeg nor the test sequences I had can help evaluate it
[08:14] <mraulet> using the FB technology to start as early as possible the upper layer
[08:14] <mraulet> me too
[08:14] <mraulet> people are using big blocks :-)
[08:14] <mraulet> it helps in compression efficiency
[08:15] <kurosu_> anyway, that api mostly works with high threading - not much of a difference on dual cores
[08:16] <mraulet> I think I will port it into openhevc and see what it gives on samples I have
[08:17] <kurosu_> beware that you introduced and used a thread_frame_ctx in lieue of a thrad_ctx
[08:17] <kurosu_> needs to be changed in the new api code
[08:20] <kurosu_> I was wondering if a 2-steps api could help - seeing how the following line lags at least one CTB after the current one
[08:20] <kurosu_> but that's mostly hevc, so I didn't bother
[08:22] <kurosu_> other question I asked myself: how reusable was x265 asm (I'm thinking of MC), except for the gpl they have instead of lgpl
[08:24] <mraulet> the most interesting part from x265 are idcts and sao asm :-)
[08:25] <kurosu_> it seems they only have up to 8x8 ?
[08:25] <kurosu_> dct16/dct32 are the most consuming ones iirc
[08:28] <mraulet> yes they are
[08:29] <mraulet> especially idct32
[08:29] <mraulet> you need a compromise in between unrolling the code and putting loops
[13:03] <BBB> kurosu_: I guess I see, if e.g. the CU size is 32x32, then this says how many levels deeper the TU can go (e.g. if its only 32x32 or 16x16, its 1); that would then mean that for a 8x8 CU, both 8x8 and 4x4 TUs are available, right?
[15:27] <cone-739> ffmpeg.git 03Carl Eugen Hoyos 07master:badcd3da81ac: Print a warning instead of requesting a sample for an invalid exif tag.
[16:32] <cone-739> ffmpeg.git 03Timothy Gu 07master:c508adb22366: hevc: propagate error code from set_sps()
[18:26] <cone-739> ffmpeg.git 03Carl Eugen Hoyos 07master:ef21b3d38e61: Ignore xing number of frames if the file is larger than indicated.
[18:26] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:183bbc2af1dc: Merge remote-tracking branch 'cehoyos/master'
[18:26] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:3c6e220a8c2d: avformat/matroskaenc: Factor mkv_start_new_cluster() out
[18:27] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:7923aa0fba6b: avformat/matroskaenc: Start new cluster if relative timestamp could not otherwise be stored
[19:04] <cone-739> ffmpeg.git 03Nidhi Makhijani 07master:436ced244fad: mpegenccontext: Remove unused opaque pointer
[19:04] <cone-739> ffmpeg.git 03Michael Niedermayer 07master:ce8e27e0ed2d: Merge commit '436ced244fadcde2c0b925627920e84b25482542'
[19:43] <kurosu_> BBB: yes, for 32x32, given a minimal transform size of 4, it can go up to 3
[19:43] <kurosu_> and of course is at least 1 for 64x64 
[19:45] <kurosu_> I think TUs are not allowed to cross PUs, so anything besides 2Nx2N also forces 1 at least iirc
[20:11] <kurosu_> BBB: in any case, maybe you can ask on #x265 too - I suppose you no longer jeopardize the soul of your firstborn by doing so ;)
[20:17] <ubitux> Timothy_Gu: you didn't fix WebVTT decoder into encoder in the Release Notes.
[20:17] <ubitux> i believe i pointed that out
[21:34] <Timothy_Gu> ubitux: oh shoot. I didn't read your mail completely. You can commit a fix for this right now.
[21:34] <ubitux> i prefer if you fix it yourself
[21:35] <ubitux> and in the branch in particular because we link to it
[23:41] <cone-135> ffmpeg.git 03Michael Niedermayer 07master:d44b8f0a4724: avformat/matroskaenc: print a warning when the relative timestamp wouldnt fit in 16bit
[23:41] <cone-135> ffmpeg.git 03Michael Niedermayer 07master:383a04a12773: avformat/mux: keep AVPacket fields consistent in ff_write_chained()
[23:41] <cone-135> ffmpeg.git 03Michael Niedermayer 07master:351b22caae65: avformat/mux: support re-interleaving packets in ff_write_chained()
[23:41] <cone-135> ffmpeg.git 03Michael Niedermayer 07master:66ae994c544a: avformat/segment: re-interleave packets if needed
[00:00] --- Fri Jul 25 2014