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

[burek]

[01:20:44 CET] <uau> wm4: about that "There also should be no need to call register_all in the existing API," argument, can't that just be read as repeating the claim that you can register individual codecs instead of calling register_all?
[01:22:10 CET] <uau> (whereas you seem to read it as saying that an ideal system should not require calling ANY register functions necessarily)
[01:22:24 CET] <Chloe> uau: this isnt about 'registering' in the old sense, this is about allowing the library to use external components
[01:22:42 CET] <Chloe> the new API doesnt require any register functions to use all the internal components
[01:23:47 CET] <uau> Chloe: i think you have the context wrong probably
[01:24:03 CET] <uau> i'm specifically referring to an argument about what michael said on the mailing list
[01:55:41 CET] <cone-875> ffmpeg 03Nikolas Bowe 07master:ce8a12fb7227: avformat/flvdec: Set broken_sizes for FlixEngine.
[01:55:41 CET] <cone-875> ffmpeg 03Gyan Doshi 07master:b6652f5100af: avutil/timecode: fix starting frame number for 59.94 fps
[10:35:22 CET] <jdarnley> Can someone explain the difference between av_frame_mov_ref() and av_frame_ref()?
[10:36:01 CET] <jdarnley> Why would I one or the other when outputting a frame from a decoder?
[10:36:54 CET] <jdarnley> I think av_frame_ref implies I still want to use the picture data in it but I'm not really sure.
[10:42:30 CET] <nevcairiel> well, move_ref moves the reference, so your "source" is empty after
[10:42:39 CET] <nevcairiel> plain _ref creates a new ref, ie. basically a copy
[10:42:47 CET] <nevcairiel> (without copying data)
[10:46:20 CET] <jdarnley> Hm.  How does av_buffer_unref() come into play?
[10:46:44 CET] <jdarnley> If I don't need the picture data anymore should I call that immediately after move_ref or ref?
[10:47:02 CET] <nevcairiel> if you move_ref you dont need to unref the source, its empty after, but you can if you want to, it does no harm
[10:47:14 CET] <nevcairiel> and if you plan to do _ref and _unref after, you should use move_ref =p
[10:48:22 CET] <jdarnley> Makes sense.  A related but not really important question: why does ref return an error code but move_ref is void?
[10:48:50 CET] <nevcairiel> move_ref is literally just *dst = *src; memset(src,0);
[10:48:55 CET] <nevcairiel> ref actually allocates things
[10:49:32 CET] <jdarnley> Thanks
[11:41:30 CET] <mateo`> I'm implementing audio support in our MediaCodec wrapper. Turns out it is slow as hell. Decoding AAC LC using our wrapper gives 8x decoding speed vs 240x for our native software decoder (on the same device).
[11:42:44 CET] <mateo`> I've done some test directly in Java which gives 9x, and 18x using the async API which is still meh~
[11:45:56 CET] <jdarnley> Dammit!
[11:46:53 CET] <jdarnley> Dumping the picture data immediately after the idwt shows green is "the correct picture".
[11:48:02 CET] <jdarnley> But it switches between a light green and a dark green
[11:48:19 CET] <jdarnley> I need to check the encoder then.
[14:38:09 CET] <cone-579> ffmpeg 03Bela Bodecs 07master:85e6a33bdfdd: hlsenc: Fixing HLS_TEMP_FILE usage with HLS_SECOND_LEVEL_SEGMENT_...
[17:30:42 CET] <cone-579> ffmpeg 03Stefan Pöschel 07master:8720d3ffddbb: lavf/mpegts: add supplementary audio descriptor
[18:04:04 CET] <gagandeep> kierank: i have sent an introduction mail to the mailing list, that i will be looking into the cineform and anyone having suggestions regarding anything should message me. is this alright?
[18:05:26 CET] <gagandeep> wm4: i have used another email address to register to the mailing list.
[18:06:28 CET] <wm4> great that it worked
[18:07:38 CET] <gagandeep> wm4:yeah, and i have also sent an introduction mail regarding that i will be looking into cineform, and anyone having any suggestions can message me regarding that
[18:07:56 CET] <wm4> we don't usually do introduction mails - it's not wrong to send one but it might feel like a cold welcome due to no big reaction
[18:09:00 CET] <gagandeep> that is also good, still my first time at gsoc so i thought following a guide won't be that bad.. :)
[18:09:22 CET] <wm4> also I see your mail, so apparently it works
[18:09:46 CET] <gagandeep> great!
[18:10:33 CET] <wm4> you should make sure to configure your mail client to sort all ffmpeg-devel mail into its own folder, or you'll get flooded with unrelated discussions and patches
[18:11:07 CET] <gagandeep> yeah, great idea, thanks
[18:47:36 CET] <jdarnley> atomnuker: when you have time could you give a comment on the two vc2enc patches I just sent to the list?  Particularly whether you think the second one is worthwhile.  Thank you.
[20:48:59 CET] <atomnuker> jdarnley: I don't get it
[20:49:02 CET] <atomnuker> the second patch
[20:49:09 CET] <atomnuker> why was it being reset on every frame
[20:49:11 CET] <atomnuker> as well as next_parse_offset
[22:11:12 CET] <jdarnley> Why was it being reset?  I don't know.  Perhaps it would be correct if you consider each frame to be in its own Sequence.
[22:11:13 CET] <jdarnley> The line dates back to the original commit  (ec9e87c922a) according to git blame.
[22:12:57 CET] <jdarnley> next_parse_offset should be reset because it stores the position in the PutBitsContext buffer where the next_offset value should be written when it is later known.
[22:13:35 CET] <atomnuker> shouldn't both not be reset?
[22:26:19 CET] <jdarnley> No, not based on the way the current code is.
[22:26:42 CET] <jdarnley> An End Sequence will always be written at the end of a packet and its length is fixed.
[22:47:57 CET] <cone-904> ffmpeg 03Aman Gupta 07master:61ecfbc32aa2: avformat/dump: tag AV_DISPOSITION_DESCRIPTIONS streams
[22:47:57 CET] <cone-904> ffmpeg 03Aman Gupta 07master:4f40d64e0098: avformat/mpegts: set AV_DISPOSITION_DEPENDENT for mix_type=0 supplementary audio
[23:18:39 CET] <MercyXfe> _   _      _   _    _        _        _______  _______  _______  _______
[23:18:39 CET] Last message repeated 2 time(s).
[23:18:39 CET] <MercyXfe> ( ) ( )    ( ) ( )  ( \      ( \      (  ___  )(       )(  ___  )(  ____ \
[23:18:45 CET] Last message repeated 2 time(s).
[23:18:45 CET] <MercyXfe> _| |_| |_  _| |_| |_ | (      | (      | (   ) || () () || (   ) || (    \/
[23:18:47 CET] Last message repeated 2 time(s).
[23:18:47 CET] <MercyXfe> (_   _   _)(_   _   _)| |      | |      | (___) || || || || (___) || (_____
[23:18:51 CET] Last message repeated 2 time(s).
[23:18:51 CET] <MercyXfe> _| (_) |_  _| (_) |_ | |      | |      |  ___  || |(_)| ||  ___  |(_____  )
[23:18:55 CET] Last message repeated 2 time(s).
[23:18:55 CET] <MercyXfe> (_   _   _)(_   _   _)| |      | |      | (   ) || |   | || (   ) |      ) |
[23:19:00 CET] Last message repeated 2 time(s).
[23:19:00 CET] <MercyXfe> | | | |    | | | |  | (____/\| (____/\| )   ( || )   ( || )   ( |/\____) |
[23:19:05 CET] Last message repeated 2 time(s).
[23:19:05 CET] <MercyXfe> (_) (_)    (_) (_)  (_______/(_______/|/     \||/     \||/     \|\_______)
[23:19:13 CET] Last message repeated 2 time(s).
[23:19:13 CET] <MercyXfe> ##LLAMAS
[23:19:14 CET] Last message repeated 2 time(s).
[23:19:14 CET] <MercyXfe> relaxed cone-904 jrmuizel gagandeep_ hreinnbeck Rodn3y feepk CoreX wm4 phh RiCON griffinp trfl tguillem lesderid graphitemaster j45 Myrsloik TheRyuu [-T-] smarter ps-auxw WizBright sfan5 andrey_utkin JEEB lexano jkqxz WebHome gnafu ritsuka RT|AO SingingTree luminarys kraft Wessie igitoor TD-Linux kevmitch cbsrobot_ mixi blb chouquette jya Fenrirthviti mistym Ahti333_ keith tmatth reynaldo aballier Tzimmo peloverde ldts atomnuker raytiley_ jfmcarreir
[23:19:17 CET] <jdarnley> Your ascii art is too wide
[23:19:35 CET] <sfan5> aw
[23:19:44 CET] <sfan5> usually i just get highlighted here if one of my patches is merged
[23:45:37 CET] <gagandeep_> kierank: what are these structs ending with suffix 'Context' mean like avcodeccontex and cfhdcontext?
[23:50:22 CET] <gagandeep_> guys what are the structs ending with 'Context' mean in libavcodec?
[23:52:09 CET] <JEEB> it is an instance of a decoder or encoder
[23:52:29 CET] <JEEB> all the libraries generally have contexts you can initialize
[23:52:43 CET] <jdarnley> AVCodecContext is the public facing one containing common data for all encoders and decoders
[23:53:02 CET] <jdarnley> user options and the like
[23:53:49 CET] <gagandeep_> okay, anything else?
[23:53:57 CET] <jdarnley> Others like "cfhdcontext" is where a specific codec would store its private data
[23:54:16 CET] <jdarnley> So it can keep track of its own state
[23:55:17 CET] <gagandeep_> alright, thanks
[00:00:00 CET] --- Sat Feb 24 2018