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

[burek]

[05:13:28 CEST] <cone-294> ffmpeg 03Rostislav Pehlivanov 07master:04a8e03ef093: opusenc: remove unused variable
[10:41:26 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:b7a741223df5: ffmpeg: add -(no)find_stream_info expert option
[10:41:27 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:d7ea14c5e228: ffmpeg: reindent after previous commit
[10:41:28 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:998687f1b23d: ffplay: add -(no)find_stream_info expert option
[10:41:29 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:af50fbaaeb68: ffplay: reindent after previous commit
[10:41:30 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:8e0d5b354e70: ffprobe: add -(no)find_stream_info expert option
[10:41:31 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:dad54e3c29dc: ffprobe: reindent after previous commit
[12:06:15 CEST] <cone-092> ffmpeg 03Carl Eugen Hoyos 07master:4c1aac893c27: lavc/jpeg2000dec: Read the sample aspect ratio from the jp2 resolution box.
[13:02:38 CEST] <J_Darnley> Is a user allowed to change AVCodecContext.global_quality at will during an encode?
[13:46:27 CEST] <J_Darnley> Crap!  What did I do now?  Why is the old code crashing?
[13:46:55 CEST] <trapp> Hi! I have a (new) FATE test that crashes and thus I try to investigate using valgrind.
[13:48:09 CEST] <trapp> Unfortunately the stack report contains only addresses, no symbols as FATE seems to run ./ffmpeg 
[13:48:09 CEST] <trapp> Is there a way to make FATE use ./ffmpeg_g instead?
[13:48:38 CEST] <nevcairiel> just run the fate command with V=1 and manually replace the command
[13:49:38 CEST] <trapp> I tried but it seems that valgrind confuses its own options with those forwarded to ffmpeg.
[13:50:37 CEST] <nevcairiel> using V=1 tells you the exact command fate executes, so you can take that and run it through valgrind easily
[14:04:34 CEST] <JEEB> is there anything else than hysterical raisins regarding the naming of av_read_frame?
[15:21:50 CEST] <BBB> JEEB: hysterical raisins = historical reasons?
[15:31:28 CEST] <JEEB> BBB: yea
[16:18:02 CEST] <kier[work]> what's the difference between an AVCodec and an AVCodecDescriptor?
[16:26:33 CEST] <durandal_170> nicolas have tendecy to ignore mails and then to have extraordinary interest on patches he have no clue about
[16:29:03 CEST] <nevcairiel> kier[work]: AVCodec is an implementation of a codec, AVCodecDescriptor describes the codec
[16:30:06 CEST] <kier[work]> ah, I see. thanks
[17:42:12 CEST] <ldts> I will be posting updated patches of Alexis Balliers v4l2 ffmpeg support (just rebased them on ffmpeg's master and posted to my github https://github.com/ldts/FFmpeg/commits/v4l2-upstream after testing with db820 hw decoder). My question is, what is the expected procedure for FATE tests that are not supported on every platform (not every platform has v4l2 encoder/decoder hardware)? shall I look for a way to disable the tests?
[17:42:51 CEST] <nevcairiel> Tests that require hardware are probably not a good idea
[17:43:49 CEST] <ldts> nevcairiel:  ah ok so there are already uses cases ...ok I will check what they do then.
[17:44:37 CEST] <ldts> aballier:  ^^
[18:10:23 CEST] <aballier> ldts: there is vim2m but I don't think that's suitable here
[18:15:05 CEST] <ldts> aballier:  I have been looking at the makefiles but I am not sure how to disable this. at the moment it is failing on ./data/fate/vc1_sa00040.err (since my server doesnt have /dev/videox obviously)
[18:19:31 CEST] <ldts> aballier:  I suppose I can give vim2m a go and see if the tests pass (not sure how will it respond to decoding requests) but might be better to just disable them?
[18:36:07 CEST] <ldts> nevcairiel:  would you know how to stop the automated test framework from using a driver? https://hastebin.com/ruboqububa.rb
[18:44:09 CEST] <jkqxz> ldts:  You've put your decoder in the wrong place in the codec table, so it is always chosen by default.
[18:45:19 CEST] <ldts> jkqxz:  ah ok, thanks for the hint. will review that.
[18:47:38 CEST] <ldts> jkqxz:  so I should select a hw accelerator instead I guess?
[18:51:56 CEST] <jkqxz> Er, no?  What are you trying to do?
[18:52:14 CEST] <jkqxz> This is a standalone decoder only, right?  (Not a hwaccel?)
[18:53:46 CEST] <ldts> it is also an encoder. the patch uses the V4L2 api to do video encoding and decoding (ie, you can use it to hw accelerate video decoding instead of using the cpu; the decoded frames can then be fed to the display)
[18:55:23 CEST] <jkqxz> To fix the problem you are hitting there, put the VC-1 decoder in the right place in the list (i.e. after the normal VC-1 decoder).
[18:56:29 CEST] <jkqxz> Typically we don't have tests for hardware codecs, because you need the hardware and the ways of calling them varies a bit too much.
[18:57:24 CEST] <jkqxz> The real hwaccels which are tightly-coupled to the internal decoders are testable by setting HWACCEL as a make option for fate, but that's about it.
[18:58:02 CEST] <ldts> yes makes sense. however will the tests not continue exercising all of the registered decoders until it reaches the new vc1_v4l2m2m?
[18:58:39 CEST] <ldts> the v4l2 patchset enables all the V4L2 supported hw encoders/decoders by the way (I guess it is like the VA API?)
[18:59:08 CEST] <jkqxz> No, because the test is for VC-1.  It finds the normal VC-1 decoder first and uses that, and doesn't look for another.
[18:59:09 CEST] <nevcairiel> it only tests the first decoder of a given format, unless those decoders have tests that specifically call them out by name
[18:59:30 CEST] <ldts> jkqxz:  understood. thanks a lot!
[19:00:07 CEST] <jkqxz> VAAPI uses the hwaccel infrastructure, which is different.  You have a standalone decoder only.
[19:03:46 CEST] <ldts> sorry, not sure what you mean? V4L2 API is an interface to hw accel infrastructure not a single decoder. Maybe I am misunderstanding you?
[19:04:22 CEST] <jkqxz> Looking at these patches, the V4LBuffer thing seems like a V4L2-only implementation of generic hwframes by adding a lot of specific API.
[19:05:15 CEST] <jkqxz> V4L2 API offers a set of standalone whole-stream decoders.
[19:05:57 CEST] <jkqxz> The AVHWAccel infrastructure in ffmpeg is used with slice decoders, such as those offered by DXVA2, VAAPI or VDPAU.
[19:07:53 CEST] <jkqxz> CUVID and NVENC is probably the closer to what you have?
[19:08:10 CEST] <cone-839> ffmpeg 03Marton Balint 07master:cc0916bfc27e: avdevice/decklink_dec: add support for decoding teletext from 10bit ancillary data
[19:08:11 CEST] <cone-839> ffmpeg 03Marton Balint 07master:9b937958907d: avdevice/decklink_dec: add support for receiving op47 teletext
[19:12:17 CEST] <ldts> by slice decoders you mean the ffmpeg hwaccel api doesnt support full frames? yes v4l2 is supposed to work with full frames but smaller regions can also be stitched by the upper layers (we did something like this for Xerox). The API is flexible enough to stream data to ISPs for filtering and processing...
[19:13:46 CEST] <ldts> jkqxz:  I am using the patchset to test on this hw (ffplay): http://wccftech.com/dragonboard-820c-computer-snapdragon-820/ 
[19:15:10 CEST] <ldts> jkqxz:  the decoder/encoder driver (https://lwn.net/Articles/697956/) is now upstream in kernel.org (was recently merged)
[19:16:55 CEST] <jkqxz> What I was meaning was to disagree with your comment of "I guess it is like the VA API?".  It is completely unlike it, because it isn't the same sort of decoder at all.
[19:17:09 CEST] <jkqxz> So comparing to how VAAPI works is not very useful.
[19:18:53 CEST] <ldts> jkqxz:  ah I see; well it wasnt meant to be functional comparison but just to highlight the fact that is an interface to a number of hw encoders/decoders but also scanners/cameras/isps etc (so not a standalone decoder).
[19:19:23 CEST] <ldts> jkqxz:  I hope it makes sense to integrate within ffmpeg?
[19:19:33 CEST] <ldts> s/within/with
[19:21:52 CEST] <jkqxz> Yes, V4L2 encode/decode is definitely appropriate to integrate.
[19:22:20 CEST] <jkqxz> I think the approach with a lot of avpriv_ functions doing magical V4L2-only things is going to be a hard sell, though.
[19:24:18 CEST] <ldts> jkqxz:  ok, I suppose we will have to go through a number of versions before it is accepted? I will be welcoming suggestions and comments of course!
[19:25:15 CEST] <ldts> last piece of code I upstreamed (uboot port for Poplar) took only 7 revisions (about 2 months). so that will be my target :)
[19:54:48 CEST] <jkqxz> ldts:  Can you pass DRM objects for V4L2 around without needing to map them?  Comparing userspace virtual pointers doesn't really seem like the right way to carry that information to me.
[20:17:54 CEST] <kierank> is there a way of seeing how many frames avcodec has buffered internally
[20:17:56 CEST] <kierank> like x264 does
[21:09:42 CEST] <Compn> kierank : do you need frame buffer count for all codecs or just h264 ?
[21:27:09 CEST] <J_Darnley> I'm all out of ideas.
[21:27:23 CEST] <J_Darnley> I output the right number of slies now.
[21:27:33 CEST] <J_Darnley> I memset some padding to 0
[21:27:55 CEST] <J_Darnley> I can't compare with a "reference" encoder becaus ethey don't work.
[21:28:18 CEST] <J_Darnley> I still get junk data in my output.
[21:29:03 CEST] <atomnuker> printf debugging, lol
[21:53:20 CEST] <cone-839> ffmpeg 03Rostislav Pehlivanov 07master:79450adfc80b: opus: simplify coarse energy beta coefficients
[22:11:52 CEST] <durandal_170> im sick of nicolas bad mouthing
[22:16:00 CEST] <cone-839> ffmpeg 03Michael Niedermayer 07master:2886142e0c3b: avcodec/aacdec_template (fixed point): Check gain in decode_cce() to avoid undefined shifts later
[22:16:01 CEST] <cone-839> ffmpeg 03Michael Niedermayer 07master:c61715e2c505: avcodec/htmlsubtitles: Be a bit more picky on syntax
[22:21:11 CEST] <atomnuker> durandal_170: chill
[22:21:26 CEST] <atomnuker> having read the thread I don't see anything wrong with either approach
[22:22:04 CEST] <atomnuker> I think it might be better to have a separate demuxer though, the format seems close to a game format
[22:22:45 CEST] <atomnuker> having it in the img2 demuxer would just add junk packet rejection there
[22:22:55 CEST] <durandal_170> its not about demuxer/parser but some nonsense design nicolas have in his head
[22:24:41 CEST] <durandal_170> basically decoder should have all header bits because of additional metadata
[22:26:02 CEST] <atomnuker> yeah, this is totally like a game format
[22:26:35 CEST] <durandal_170> and nicolas said that it duplicates logic, which is normal to me and no way to avoid
[22:28:59 CEST] <durandal_170> so i will need to get into nicolas head to found out what solution is even possible
[00:00:00 CEST] --- Wed Jul 19 2017