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

[burek]

[01:12:14 CEST] <cone-905> ffmpeg 03Jacob Trimble 07master:7e22f5d457fa: avformat/mov: Expose encryption info to the app.
[01:12:15 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:0898a3d99099: avcodec/jpeg2000dec: Check that there are enough bytes for all tiles
[01:12:16 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:652d7c6348f9: avcodec/jpeg2000dec: Fixes invalid shifts in jpeg2000_decode_packets_po_iteration()
[01:12:17 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:70832333bba3: avcodec/shorten: Fix undefined integer overflow
[01:12:18 CEST] <cone-905> ffmpeg 03Michael Niedermayer 07master:3b10bb8772c7: avcodec/shorten: Fix undefined addition in shorten_decode_frame()
[10:26:04 CEST] <gagandeep> kierank: have read on posix threads programming to get an idea of what the basic terms are in the last 2 days
[10:26:15 CEST] <gagandeep> seen what slice and frame multithreading is
[10:26:30 CEST] <kierank> Did you look at pngdec
[10:26:37 CEST] <kierank> You should implement frame threading first
[10:26:37 CEST] <gagandeep> looking at it
[10:26:45 CEST] <gagandeep> why frame threading
[10:27:21 CEST] <JEEB> generally faster and you don't need to split images
[10:28:27 CEST] <gagandeep> but in cfhd case the frames are mixed such that there is no derived frame from previous frame
[10:28:56 CEST] <gagandeep> the 3d transformer is just a filter that mixes the 2 frames together
[10:28:57 CEST] <JEEB> yes, which makes it even simpler :P
[10:29:07 CEST] <JEEB> if you don't need to synchronize
[10:29:45 CEST] <JEEB> if there's any dependency on other frames you might need to do some synchronization but you should focus on getting intra-only images done with frame threading first
[10:30:08 CEST] <JEEB> then you can start making P pictures work with frame threading
[10:30:55 CEST] <gagandeep> so by frame threading you mean just couple the ip together as if i frame and decode the distinct ip group with each thread
[10:33:10 CEST] <gagandeep> will focus of frame threading for now then, thanks
[10:33:26 CEST] <JEEB> no
[10:33:34 CEST] <gagandeep> ?
[10:33:45 CEST] <JEEB> it is just one of the two threading modes in libavcodec
[10:33:53 CEST] <gagandeep> yeah i know
[10:33:53 CEST] <JEEB> one handles separate images, another handles parts of a single image
[10:34:34 CEST] <JEEB> the first step would be to get just plain I pictures going, and the following would be to make there be synchronization that the required parts of the reference frame are decoded so you can thread the other picture
[10:34:43 CEST] <JEEB> s/thread the other/decode the other picture/
[10:35:33 CEST] <JEEB> with I pictures only it's simple because they don't have dependencies :P and frame threading lets you just handle a separate frame decoding process fully in each thread
[10:35:44 CEST] <gagandeep> k, understood
[10:35:55 CEST] <gagandeep> sync the inverse temporal
[10:36:27 CEST] <gagandeep> the two threads can then afterwards decode their seperate pics
[10:37:11 CEST] <JEEB> I think what kierank was trying to say is "start with frame threading" (and I pictures first). that way you get a grasp of how the frame threading works and you don't (yet) have to add the synchronization of threads against their references
[10:37:25 CEST] <JEEB> then after you get that done you can start adding support for P pictures and synchronization
[10:37:39 CEST] <kierank> gagandeep: the hard part is doing referencing with frame threads
[10:37:42 CEST] <kierank> There is a dependency
[10:37:56 CEST] <JEEB> yes, which is why I first. then synchronization after you've got a grasp on what the frame threading does
[10:38:20 CEST] <JEEB> (and you get some streams already working instead of punching your head through a table and not getting correct results)
[10:38:31 CEST] <nevcairiel> frame threading for pure I frames doesnt really require knowing anything, just activate it and it works
[10:38:43 CEST] <JEEB> true
[10:38:55 CEST] <JEEB> and make sure there are separate contexts if you have per-frame contexts?
[10:40:28 CEST] <gagandeep> pngdec must be using slice threading i assume
[10:41:11 CEST] <kierank> nevcairiel: yes, that works out of the box for cfhd, I implemented it
[10:41:24 CEST] <kierank> But now we have pframes we need some intelligence
[10:41:51 CEST] <kierank> CFHD doesnt have slices
[10:42:51 CEST] <gagandeep> really?, filters can be made to work in slices
[10:49:45 CEST] <nevcairiel> that would be slice threading for a later step
[10:52:07 CEST] <gagandeep> yeah
[10:54:36 CEST] <gagandeep> pngdec has in .capabilities = AV_CODEC_CAP_FRAME_THREADS
[10:55:26 CEST] <gagandeep> so why is it using frame threads, even though it is just one frame (image)
[13:22:27 CEST] <nevcairiel> you can have a video stream with all  PNGs
[13:22:32 CEST] <nevcairiel> although its not very common i guess
[13:26:26 CEST] <Compn> its lossless video too :)
[13:26:59 CEST] <Compn> this was long before ffv1 , back when the options were huffyuv or raw really
[13:27:41 CEST] <Compn> except there were multiple 3rd party png decoders , and huffyuv was not as popular as a format to transfer
[13:28:13 CEST] <Compn> so it was png, mpg and ..... wmv2 / rm and quicktime svq3 heh
[13:28:25 CEST] <Compn> and mjpeg for lossy "image" video
[13:28:39 CEST] <Compn> the cold cold days of the codec wars
[13:30:23 CEST] <Compn> how can you have a codec war then bandwidth was sparse, and video sizes were postage stamps?!
[13:31:39 CEST] <Compn> you 4k ultra uhd 1080 noscope 360 yolo people dont know about the dark days, when realmedia ruled the world
[13:36:35 CEST] <Compn> course this is the dev channel, most of you remember
[13:38:41 CEST] <atomnuker> realmedia and even their cook codec still rules the world, you know, just a different one
[13:57:37 CEST] <cone-229> ffmpeg 03Michael Niedermayer 07master:bd27a9364ca2: avcodec/mpeg4videodec: Remove use of FF_PROFILE_MPEG4_SIMPLE_STUDIO as indicator of studio profile
[13:57:38 CEST] <cone-229> ffmpeg 03Michael Niedermayer 07master:00f98d23b146: avcodec/ac3dec: Check channel_map index
[13:57:39 CEST] <cone-229> ffmpeg 03Michael Niedermayer 07master:4423085ca500: avcodec/truemotion2: Check len in tm2_read_stream()
[13:57:40 CEST] <cone-229> ffmpeg 03Michael Niedermayer 07master:267ba2aa9635: avcodec/indeo4: Check for end of bitstream in decode_mb_info()
[15:39:37 CEST] <BradleyS> rle > png
[15:40:14 CEST] <BradleyS> aka Apple Animation codec
[15:40:47 CEST] <BradleyS> can still be used for lossless 8-bit in a pinch
[18:51:17 CEST] <cone-814> ffmpeg 03Shlomi Fish 07master:1ecdcb61b0ac: lavfi/weave: Refactor two near-identical clauses.
[18:55:00 CEST] <cone-814> ffmpeg 03Carl Eugen Hoyos 07master:e25c25ebd817: lavc/atrac9tab: Add inclusion guards.
[20:19:27 CEST] <JEEB> atomnuker: were you using some random person's built at9tool?
[20:19:31 CEST] <JEEB> or did you find something else
[20:22:47 CEST] <atomnuker> no, the sound forge 10 plugin
[20:23:19 CEST] <JEEB> I haven't run this myself, but seems to be a tool from the SDK
[20:23:21 CEST] <JEEB> http://www.mediafire.com/file/8dmlm54w48b86jw/at9tool.exe
[20:23:39 CEST] <JEEB> supposedly does encoding and decoding
[20:24:51 CEST] <JEEB> http://up-cat.net/p/3ded9f7c
[20:24:59 CEST] <JEEB> (once again, haven't run the binary myself)
[20:25:40 CEST] <JEEB> if it's only an encoder, sorry. the description noted it was both an encoder and decoder (´4@)
[20:26:01 CEST] <JEEB> I should probably at some point poke at the SDK in a VM and see if I can get a decoder linked
[20:26:43 CEST] <JEEB> ah yes
[20:26:43 CEST] <JEEB> -d : decode to file1 to file2(16bit linear PCM wav file)
[20:26:51 CEST] <JEEB> so yes, it seems to be a decoder
[20:58:12 CEST] <rindolf> hi all
[20:58:19 CEST] <cone-814> ffmpeg 03James Almer 07master:a61b56624b99: avcodec/atrac9tab: add missing header include
[22:28:42 CEST] <cone-814> ffmpeg 03Marton Balint 07master:00a2652df3bf: avformat/mxfdec: add support for clip wrapped essences
[22:28:43 CEST] <cone-814> ffmpeg 03Marton Balint 07master:afd09131ff58: avformat/mxfdec: fix indentation and rename mxf_read_packet_old
[22:28:44 CEST] <cone-814> ffmpeg 03Marton Balint 07master:c6fff3d32f4e: avformat/mxfdec: take into account index_edit_rate
[22:28:45 CEST] <cone-814> ffmpeg 03Marton Balint 07master:5861bc9e7569: avformat/mxfdec: guess constant byte count indexes based on track duration
[22:28:46 CEST] <cone-814> ffmpeg 03Marton Balint 07master:e37741d26a1e: avformat/mxfdec: add support for opAtom without index
[22:52:18 CEST] <January> rindolf: hi
[22:52:49 CEST] <rindolf> January: hi
[22:53:00 CEST] <rindolf> January: happy 4 july
[22:56:30 CEST] <January> why is it happy?
[22:57:22 CEST] <thardin> happy white slaveowners not having to pay taxes day
[23:01:11 CEST] <rindolf> January: it is happy because my patch to ffmpeg was applied, and i sent a new one
[23:01:33 CEST] <j-b> wow, baptiste is alive?
[23:01:40 CEST] <JEEB> yup
[23:02:13 CEST] <j-b> really cool.
[23:02:34 CEST] <j-b> Is Paul back on IRC? 
[23:02:36 CEST] <j-b> :'(
[23:02:42 CEST] Action: j-b sad panda
[23:04:26 CEST] <baptiste> back from the dead :)
[23:05:11 CEST] <j-b> baptiste: still at Hulu?
[23:06:07 CEST] <thardin> woah
[23:06:33 CEST] <January> rindolf: cool, what did your patch do?
[23:07:01 CEST] <rindolf> January: refactoring
[23:12:35 CEST] <baptiste> j-b, actually I'm at Snapchat now 
[23:12:50 CEST] <j-b> baptiste: is it nice?
[23:13:33 CEST] <baptiste> yeah, it's cool, and it's in LA, which is convenient for me
[23:16:04 CEST] <cone-814> ffmpeg 03Michael Niedermayer 07master:5aba5b89d0b1: avcodec/mpeg4videodec: Check for bitstream end in read_quant_matrix_ext()
[23:20:54 CEST] <baptiste> j-b, what's up with you, where are you now ?
[23:22:58 CEST] <j-b> baptiste: Paris, in the summer
[00:00:00 CEST] --- Thu Jul  5 2018