July 2018 - Ffmpeg-devel-irc - lists.ffmpeg.org

ffmpeg-devel.log.20180704
by burek 05 Jul '18

05 Jul '18

[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

1 0

ffmpeg.log.20180704
by burek 05 Jul '18

05 Jul '18

[01:37:53 CEST] <leif> When ffprobe shows `60 kb/s (default)` is that saying that ffmpeg couldn't figure out what the bitrate was, or its using whatever the default for the container is? [01:37:58 CEST] <leif> (Or something else) [03:55:20 CEST] <^Neo> Good evening friends, I have an HDMI capture card and want to capture Dolby Digital AC3 coming in as IEC61937 and convert it to regular AC3... I haven't been able to find a command line example for it though :( [10:56:40 CEST] <Nacht> Heh, the encoding speed for AV1 is almost funny ^^ [11:00:44 CEST] <bencoh> how do you define "almost funny" in this context? :) [11:03:07 CEST] <TheAMM> You almost laugh at how slow it is but then get sad over how slow it is [11:03:19 CEST] <TheAMM> Because it's happening to you, schadenfreude doesn't tip it over to the fun side [11:03:58 CEST] <Nacht> Exactly that :D [11:04:11 CEST] <bencoh> :D [11:04:25 CEST] <Nacht> I was expecting slow, like really slow. But it seems I have still have too high standards [11:04:54 CEST] <TheAMM> Encoding sub-1fps is a special kind of hell [11:05:04 CEST] <TheAMM> (although my laptop manages that easily with vp9) [11:06:13 CEST] <Nacht> I haven't got the fastest of laptops there is. But it's nice to know I got a new method of torturing it now [11:12:52 CEST] <atbd> hi, i'm creating a program which cut a tiny portion of a video and transcode mpegts to mp4. It works except for video's duration, ffprobe returns a false one (37s instead of 19s). I'm setting AVFormatContext::duration and also AVStream::duration but no changement. How can i set the right duration ? [11:49:30 CEST] <DHE> yeah I encoded a minute or two of video over a few weeks... AV1 needs a LOT of work... [14:22:25 CEST] <lkiesow> Hi, I'm trying to extract and scale an image to a specific resolution and save it as JPEG using FFmpeg. Scaling it to a resolution like 250x144 or 250x146 works but not 250x145. The encoder always seems to generate an even resolution. It does work if I output a PNG file instead. Any idea what I can do about that? Is it possible to generate JPEG files with uneven width? [14:28:42 CEST] <furq> lkiesow: -pix_fmt yuv444p [14:29:10 CEST] <^Neo> Is there a way to capture a dolby digital IEC 61937 stream from an ALSA hardware input? [14:31:44 CEST] <DHE> lkiesow: many codecs have such restrictions due to the underlying encoding spec requiring it [14:32:00 CEST] <DHE> as for alterantives, have you tried other applications like ImageMagick and seeing if they do produce what you want? [14:39:08 CEST] <lkiesow> furq: Makes sense, thanks. png would automatically choose rgb24.That's why it did work. But using jpeg I was using yuvj420p. Changing that makes it work. [14:39:23 CEST] <furq> oh yeah i guess yuvj44p [14:39:24 CEST] <furq> 444p [14:40:28 CEST] <lkiesow> DHE: JPEG itself does not have that restriction and I want to use FFmpeg since it's an automated process and we are using FFmpeg for lot's of other stuff as well [14:41:04 CEST] <lkiesow> It was just that switching from png to jpeg broke the command which confused me :) [14:41:16 CEST] <DHE> oh... yeah yuv444 makes sense... [14:41:46 CEST] <lkiesow> again, thanks for the hint. That helped. And now& back to work :D [15:28:05 CEST] <dtatulea> Hi. I am streaming a h264 video (avc3 MP4) over WebSocket to a Media Source Extension Source Buffer. Ffox and Chrome can handle it on Linux, but on Windows, Firefox and Edge can't handle it: the first frame is shown but no updates after that. Any ideas where I could start looking into this? ffplay doesn't show any errors or warnings either... [15:28:34 CEST] <dtatulea> I was directed from the firefox #media channel to this channel. [15:29:07 CEST] <JEEB> on linux they're probably using FFmpeg, on windows they're using the included (most likely hwdec-backed) Media Foundation decoders [15:29:21 CEST] <JEEB> testing the same bit stream in the Windows Videos app probably will help? [15:29:47 CEST] <JEEB> (or windows media player although I guess that is now more dead than it isn't) [15:32:06 CEST] <dtatulea> JEEB: yep, doesn't work there [15:34:08 CEST] <JEEB> dtatulea: pastebin result of `ffprobe -v verbose FILE` [15:34:11 CEST] <JEEB> and link here [15:35:44 CEST] <dtatulea> https://pastebin.mozilla.org/9089101 [15:41:46 CEST] <dtatulea> JEEB: I wonder if it makes sense to build the basic player from the windows media foundation sdk and try to play that file. Maybe I get more information about what is wrong. [15:42:27 CEST] <Blacker47> maybe 120 fps is a bit too high? [15:44:55 CEST] <DHE> avc3 as the fourcc? [15:48:26 CEST] <dtatulea> Blacker47: when encoding, the frame rate is 25. But as I dumped the mp4 data to a file instead of streaming, there's nothing to indicate time. [15:49:41 CEST] <JEEB> if that's just the time base I don't think that's a real problem? [15:49:52 CEST] <JEEB> since FFmpeg makes files with pretty big time bases [15:50:00 CEST] <JEEB> and those work [15:50:19 CEST] <JEEB> if it's actual frame rate of the samples' PTS then that can be a problem [15:51:34 CEST] <DHE> it could be, but if it's really also only 1 reference frame and 1024x1024 pixels, it sounds like it might still make level 4.x decoder requirements.. right? [15:52:01 CEST] <DHE> just an estimate without breaking out the calculator [15:57:05 CEST] <JEEB> I think profile/level should be mentioned in the pastebin, no? [15:57:14 CEST] <JEEB> I don't have the time to check it myself, unfortunately [15:57:23 CEST] <dtatulea> If not, I can let you know what they are. [15:59:34 CEST] <dtatulea> Constrained High Profile, Level 3. [16:00:03 CEST] <furq> "constrained high"? [16:00:25 CEST] <furq> oh that is actually a thing [16:00:30 CEST] <furq> i've never seen anyone use that before [16:00:39 CEST] <DHE> yeah, there's actually a lot of profiles no one really uses [16:01:17 CEST] <dtatulea> Actually, I think it's only High. [16:01:24 CEST] <dtatulea> 100 [16:01:38 CEST] <dtatulea> with constrain set 0 [16:01:54 CEST] <furq> i can't imagine there are any decoders that distinguish between the two [16:02:13 CEST] <furq> certainly not software or consumer gpu ones [16:02:36 CEST] <^Neo> JEEB, you seem very smart, any idea about my IEC61937/ALSA question? [16:02:41 CEST] <DHE> it's really just a question of whether the decoder supports a specific feature. "main" + any 1 "high" feature = a "high" profile video [16:05:19 CEST] <DHE> and a "high" decoder should have no problem with any lower profile (constrained high, main, baseline, constrained baseline... did I miss any?) [16:05:21 CEST] <dtatulea> DHE: Regarding the "avc3 as the fourcc", yes? [16:05:36 CEST] <DHE> dtatulea: well iirc the right fourcc is "avc1" [16:05:42 CEST] <dtatulea> s/yes?/yes./ [16:05:50 CEST] <furq> DHE: you forgot progressive high [16:06:14 CEST] <DHE> is there such thing as Intra-High? (keyframes only) [16:06:53 CEST] <furq> and acid high, hard high, detroit high [16:07:17 CEST] Action: DHE goes to read the wikipedia article on h264, clearly he's behind the times [16:07:49 CEST] <furq> there are a bunch of intra high profiles but they're all for 10-bit or 4:2:2/4:4:4 [16:07:57 CEST] <dtatulea> DHE: You mean in the mp4 ftyp or in the visual sample entry? For the visual sample entry I need it to specify that it's avcC. [16:08:01 CEST] <andriy> whois kam187_ [16:10:29 CEST] <JEEB> ^Neo: looking at the changes I have to review in ALSA-related code in other projects I don't want to comment on it since I will probably not find too much positive to say about it [16:10:43 CEST] <JEEB> partially because I don't think there's a "best practices" thing for ALSA's APIs either [16:18:21 CEST] <Nonakto> Hello, I need to display a video (.mp4) on a web page by creating a video stream (no file!). Anybody have any information? Tell me where to look? Thank you! [16:19:47 CEST] <DHE> like, encode and render on demand? [16:20:09 CEST] <Nonakto> yes [16:21:07 CEST] <DHE> besides being a potential CPU consumption risk, MP4 doesn't lend itself to that very well. it's really intended to be a pre-rendered file [16:22:16 CEST] <Nonakto> Okay thanks :) [16:28:56 CEST] <dtatulea> DHE: How about streaming live content over to a Media Source Extension? You still need to use MP4 then. [16:29:26 CEST] <dtatulea> There is no other way. Or? [16:41:22 CEST] <DHE> dtatulea: well there are fragmented MP4 files, but I'm mainly concerned that transcoding will be involved... [16:42:36 CEST] <Mavrik> muxing at least [16:42:42 CEST] <Mavrik> DASH uses MP4 files right? [16:43:45 CEST] <JEEB> it can use fmp4, matroska or mpeg-ts [16:43:46 CEST] <JEEB> :D [16:43:55 CEST] <JEEB> FFmpeg supports two out of those [16:47:47 CEST] <Mavrik> The question is more what do browsers support :) [16:47:55 CEST] <Mavrik> I have somewhere in my mind that only MP4 really works. [16:48:25 CEST] <DHE> iirc Dash originally specified fmp4 as the file format. so that will certainly be best supported [16:48:32 CEST] <JEEB> both matroska and fmp4 seem to work last I tested [16:48:41 CEST] <JEEB> of course matroska is the webm subset [16:48:46 CEST] <JEEB> so vp9+stuff [16:57:27 CEST] <andriy_> Hello, when looking through libavcodec code I noticed that some functions have an underscore between "av" and "codec", while others don't. i.e. avcodec_find_encoder_by_name vs av_codec_set_pkt_timebase. Does the additional underscore mean anything? [16:59:24 CEST] <JEEB> av_* are just general public API symbols in FFmpeg, avcodec notes it's specific to avcodec (also could be hysterical raisins) [17:02:17 CEST] <andriy_> thanks JEEB [23:17:17 CEST] <Hello71> JEEB: doesn't ffmpeg support decoding mpegts [00:00:00 CEST] --- Thu Jul 5 2018

1 0

ffmpeg-devel.log.20180703
by burek 04 Jul '18

04 Jul '18

[00:46:57 CEST] <Compn> why is j-b reviewing video filter patches :D [00:47:22 CEST] <j-b> Compn: well, if I did, I would have objected before... [00:48:18 CEST] <Compn> why is this patch 1.8mb [00:49:07 CEST] <Compn> why is it using floats [00:49:09 CEST] <Compn> harumph [01:14:01 CEST] <cone-872> ffmpeg 03Danil Iashchenko 07master:581bafa83b9c: lavfi: add sobel, prewitt, roberts filters [01:59:31 CEST] <BBB> Compn: floast are ok [01:59:37 CEST] <BBB> Compn: a lot of code does floats nowadays [01:59:43 CEST] <BBB> Im not saying its great, but its what people do [01:59:51 CEST] <BBB> prolly because gpus are float-based [01:59:59 CEST] <BBB> also, floats are easier to code [02:00:15 CEST] <BBB> 0.5*x is easier than 0x80*x>>8 [02:00:58 CEST] <nevcairiel> the AI stuff is all about GPUs, they even use half-precision just to compute stuff faster [03:20:11 CEST] <cone-872> ffmpeg 03James Almer 07master:3c4af577aa50: configure: add missing swscale to avfilter when sr filter is enabled [17:30:00 CEST] <atomnuker> any volunteers to compile some atrac9 binary examples under windows so they can decode some fate references? [17:31:11 CEST] <BtbN> You mean compile ffmpeg on windows? [17:32:36 CEST] <atomnuker> nope, unfortunately [17:32:53 CEST] <atomnuker> compile the examples that came with the binary atrac9 dll from sony [17:33:38 CEST] <BtbN> oh god [17:36:08 CEST] <atomnuker> they should be easy to compile, there's an msvc project file and everything, do keep in mind I know exactly nothing about compiling anything under windows [17:45:16 CEST] <BtbN> Are they freely available for download? [17:51:49 CEST] <atomnuker> nope, but I have them [17:57:09 CEST] <BtbN> I can totaly just hit build on an MSVC project, assuming it doesn't need some ancient version [18:00:13 CEST] <jamrial> inb4 msvc 2005 [18:03:16 CEST] <atomnuker> the Version string in the .vcproj says Version="9.00", no idea what that translates into [18:03:36 CEST] <BtbN> 2008... [18:04:12 CEST] <atomnuker> erm, right, that narrows it down a bit [18:04:24 CEST] <BtbN> it's not even a vcxproj [18:04:55 CEST] <atomnuker> welp, it did come with a soundforge plugin, I'll try to install whatever version of that the plugin requires and give it a go [18:05:09 CEST] <BtbN> Don't even have access to that old MSVC anymore [18:09:04 CEST] <atomnuker> the sound forge 10 pro the plugin requires is number 2 on the pirate bay search for "sound forge", sorted by seeds [20:08:27 CEST] <JEEB> &32 [20:52:26 CEST] <atomnuker> good news: my decoder matches what sony's binary decoder outputs [20:52:44 CEST] <JEEB> \o/ [20:52:47 CEST] <atomnuker> bad news: the binary decoder I have is too old and doesn't support band extension [20:52:52 CEST] <JEEB> :< [20:53:00 CEST] <atomnuker> so I'll have to use the output from my decoder as a reference [20:53:08 CEST] <atomnuker> it wouldn't have mattered that much though [20:53:20 CEST] <atomnuker> because band extension does have a PNS-like mode [20:53:40 CEST] <atomnuker> which means random numbers, which would have meant a really really high fuzz which wouldn't have been all that useful [21:15:41 CEST] <cone-905> ffmpeg 03Rostislav Pehlivanov 07master:755e61839926: lavc: implement an ATRAC9 decoder [21:15:41 CEST] <cone-905> ffmpeg 03Rostislav Pehlivanov 07master:9fececb6f335: riff: add ATRAC9 guid [21:56:45 CEST] <atomnuker> grr, sound forge has apparently resampled the audio, and its resampler doesn't seem to be one of the best [21:57:21 CEST] <kierank> atomnuker: did you move to nice [21:57:24 CEST] <atomnuker> time seems stretched compared to the lavc decoder yet the duration's the same and the spectrum matches [21:59:18 CEST] <atomnuker> kierank: nope, just seem to have more motivation now, thanks to which I am actively learning French every day, instead of once a month [22:00:05 CEST] <atomnuker> I also would like to know how the vote in 2 days plays out because fuck if I have to live in a place with such crap [22:00:21 CEST] <kierank> what vote [22:00:27 CEST] <atomnuker> article 11 and 13 [22:03:10 CEST] <iive> the new copyright thing? [22:08:15 CEST] <JEEB> atomnuker: btw I wonder how the MPEG-PS stuff should be done. [22:08:21 CEST] <JEEB> for ATRAC3 and ATRAC9 [22:08:39 CEST] <JEEB> because it's the same data, but you get a header with the values that are usually in the WAV headers [22:09:05 CEST] <JEEB> so either you make a parser that sets values into an AVCodecContext (which IIRC is not kosher) [22:09:45 CEST] <JEEB> or you make the WAV demuxer add the header to each packet and the parser just parses the packets [22:09:59 CEST] <JEEB> would require changes in the decoder to not base on the values in the header, though [22:13:42 CEST] <atomnuker> is there mpeg-ps with atrac9 audio? [22:14:00 CEST] <atomnuker> parsers setting avctx values is perfectly reasonable [22:14:21 CEST] <atomnuker> but the thing is there are some other stuff in the header like frames inside a superframe that the decoder needs to know somehow [22:14:46 CEST] <atomnuker> I don't think there's a mechanism for private parser -> decoder data [22:15:44 CEST] <JEEB> I /think/ it exists but I haven't double-checked. I just assumed they kept on the same thing with ATRAC9/Vita/PS4 [22:15:48 CEST] <JEEB> lemme double-check [22:17:33 CEST] <atomnuker> most of the included cutscenes I have from vita games are standard mp4 files with h264 and aac [22:18:11 CEST] <JEEB> yea, I have that from the fate thing too. I have some vita games myself but my fw version is just higher than where I can freely browse it around [22:27:54 CEST] <JEEB> atomnuker: ok, I left some pokes around so we'll see. but you say parsers modifying AVCodecContext values is kosher? I think that was the original reason why the original versions back in ye olden days got nack'd due to threading worries? [22:54:41 CEST] <atomnuker> JEEB: I think parsers are mainly there so you don't have to fully decode a packet to know stuff like resolution or pixfmt [00:00:00 CEST] --- Wed Jul 4 2018

1 0

ffmpeg.log.20180703
by burek 04 Jul '18

04 Jul '18

[00:24:36 CEST] <SortaCore> sup folk [00:24:45 CEST] <SortaCore> I need to use image2 with jpegs to make an mp4 [00:24:49 CEST] <SortaCore> in C++ [00:26:22 CEST] <DHE> you can give the image2 demuxer the same options you would the ffmpeg cli, largely using the AVDictionary for options like framerate and glob rules, and it should do most of the work on its side [00:26:33 CEST] <DHE> have you seen the doxygen docs and the example programs? [00:27:00 CEST] <SortaCore> nope, I have code for RTSP -> MP4, I'm just wondering what difference there would be [00:27:08 CEST] <SortaCore> any resources would help [00:27:33 CEST] <SortaCore> and gotchas like using variable framerate with different jpegs [00:27:59 CEST] <SortaCore> RTSP H264 -> H264 MP4, so now it's JPEG list -> H264 MP4 [00:28:04 CEST] <DHE> well image2 assumes a constant framerate which you can set [00:30:25 CEST] <DHE> so, I guess avformat_open_input(&avfctx, "*.jpg", av_find_input_format("image2"), NULL); // should be largely effective if you're okay with defaults from image2 [00:30:25 CEST] <SortaCore> my current plan is to take my RTSP code, throw out the decoder, image2 for jpg seems to use mjpeg so throw that in instead, and pass each frame to the decoder [00:31:58 CEST] <DHE> the main concern is going to be colourspace. usually H264 wants yuv420, but jpeg will produce something else that will require conversion [00:32:39 CEST] <SortaCore> I already have X -> YUV420P/NV12 conversion between decoder and encoder [00:32:53 CEST] <DHE> nice [00:33:01 CEST] <SortaCore> since I had Intel QSV as one of the possible H264 encoders, and it didn't take YUV420 [00:33:27 CEST] <SortaCore> it's just what steps I have to exchange and which are no longer necessary [00:49:46 CEST] <SortaCore> you said fixed frame rate DHE? [00:50:04 CEST] <DHE> that's how image2 works [00:50:14 CEST] <DHE> you're free to play around with the pts and time_base of the output streams, but that's on you [00:50:17 CEST] <SortaCore> how much of an issue is that, something I can't work around by messing with AVPacket dts/pts timings? [00:50:21 CEST] <DHE> and for mp4, preferably duration. [00:50:22 CEST] <campones> hi there, any ideas why my compilation failed? https://pastebin.com/EeDeJTVg [00:50:37 CEST] <campones> ubuntu 16 x64 , fresh install [15:56:09 CEST] <darkdrgn2k3> i am pulling a stream from RTMP to process with ffmpeg [15:56:24 CEST] <darkdrgn2k3> if the RTMP stream stops/changes ffmpeg stops workign with errors "PTS .....st:0 invalid dropping" [15:56:39 CEST] <darkdrgn2k3> is tehre anyway to prevent this or at very east have ffmpeg exit so it can be retarted [16:23:09 CEST] <roxlu> hi, I've got two h264 video streams which seem pretty identical but one doesn't want to playback. When I use ffprobe to check fo differences I see that the one that doesn't work has [SAR] and [DAR] in the info lines. The one that does work is missing those. [16:24:04 CEST] <roxlu> does ffmpeg extract the [SAR],[DAR] info from a nal? [16:24:52 CEST] <JEEB> that's *one* of the places it will attempt to read the info from. then there's the container [16:25:33 CEST] <roxlu> JEEB: thanks. when the info is stored in a nal, does it get this from the VUI? or SPS maybe? [16:25:54 CEST] <roxlu> .. well.. I'm trying to figure out how to "remove" this info so that ffprobe shows the same info [16:40:05 CEST] <roxlu> I was trying to remove some stuff: https://gist.github.com/roxlu/e0714c7e2792bef3061f6e084e9a866c [16:40:11 CEST] <roxlu> but not sure why I get an error there [16:44:43 CEST] <DHE> I think you just want "-delete_filler 1 -bsf h264_metadata" [16:44:54 CEST] <roxlu> DHE: yeah this works, https://gist.github.com/roxlu/e0714c7e2792bef3061f6e084e9a866c#file-gistfil… [16:46:17 CEST] <roxlu> but that still doesn't remove the sei, sadly :) [16:46:27 CEST] <DHE> as for how it works, ffmpeg will do a small amount of video decoding to discover all the information about the video, including resolution and maybe SAR/DAR [16:48:19 CEST] <roxlu> thanks, wondering why it's not in my other stream though. but I think the SEI or VUI is one of the reasons why one stream is not working correctly (not sure what though). But I'm trying to find a way to remove that nal [16:55:52 CEST] <roxlu> what I just did: extract .h264 from not working .mkv, convert that into .ts, then convert .ts back into a .mkv ..<-- this .mkv can be played back (?) [16:58:57 CEST] <DHE> sounds like there's something wrong with the mkv headers then. mkv does support a lot of features like setting aspect ratios. [17:22:16 CEST] <utack> is it to be expected that ffprobe ouputs a "pict_type="?"" for all frames in an av1 stream? [17:23:34 CEST] <kepstin> utack: probably depends on the ffmpeg and av1 library versions. The av1 support is pretty fresh still, and probably incomplete. [17:23:49 CEST] <utack> yeah, i guess it is normal [17:47:35 CEST] <keglevich> I have a perfect CBR mpegts files...stream them in VLC, perfect straight bitrate line... I'd like to stream them over UDP and I'm using the following command: ffmpeg -re -i input.ts -vcodec copy -acodec copy -f mpegts "udp://239.1.1.1:5000?pkt_size=1316" [17:48:33 CEST] <furq> keglevich: you probably need -muxrate [17:48:38 CEST] <keglevich> the output I'm getting at udp://@239.1.1.1:5000 has lots of bitrate bursts, lots of spikes, ups and down for about +-30%...the stream isn't CBR as it should be [17:49:18 CEST] <DHE> you'll need -muxrate set to the stream muxrate (add 10% to the basic bitrates), and add -bitrate (same number) [17:49:20 CEST] <keglevich> what am I doing wrong? I tried all possible output combinations with bitrate, burst_bits, buffer_size, etc....nothing helps...I also tried different formats, all the same..UDP output simply isn't stable CBR [17:49:33 CEST] <keglevich> that's also something I tried...doesn't help much [17:50:23 CEST] <keglevich> ffmpeg -re -i input.ts -vcodec copy -acodec copy -f mpegts -muxrate 6600k "udp://239.1.1.1:5000?pkt_size=1316&bitrate=6600000" ...if that's what you had in mind? [17:50:40 CEST] <DHE> I think so, but I've always used "-bitrate 6600k" [17:50:51 CEST] <keglevich> minrate, maxrate, video-bitrate are 6000k [17:51:08 CEST] <DHE> well then you're using the wrong number. add some for the audio as well [17:51:12 CEST] <kepstin> keglevich: setting bitrate doesn't make sense when using -vcodec copy [17:51:15 CEST] <furq> right [17:51:17 CEST] <furq> or maxrate [17:51:25 CEST] <DHE> kepstin: -bitrate is an option for udp:// output [17:51:33 CEST] <keglevich> yes [17:51:45 CEST] <keglevich> bitrate is output option [17:51:48 CEST] <furq> doesn't that need to be in the url params though [17:52:06 CEST] <kepstin> oh, that's supposed to be a packet pacing option for the udp output? [17:52:15 CEST] <DHE> yes [17:52:28 CEST] <furq> the docs don't mention that it accepts those as cli options [17:52:36 CEST] <furq> but i've never tried it [17:52:38 CEST] <DHE> it's relatively new. you might need ffmpeg 3.4 or newer [17:52:57 CEST] <DHE> https://ffmpeg.org/ffmpeg-protocols.html#udp [17:53:00 CEST] <furq> i'd probably put it in the params anyway so it's not confusing [17:53:16 CEST] <keglevich> ffmpeg -re-i input.mp4 -c:v mpeg2video -pix_fmt yuv420p -r 25 -g 50 -b:v 5000k -c:a mp2 -ac 2 -b:a 192k -ar 48000 -minrate 5000k -maxrate 5000k -bufsize 700k -muxrate 5450k -pcr_period 30 -f mpegts "udp://239.8.1.181:5000?pkt_size=1316&bitrate=5450000" [17:53:33 CEST] <DHE> missing a space between -re and -i [17:53:46 CEST] <keglevich> that's the direct command I also tried...same result...I mean, same result If I make CBR .ts output first of if I do it directly to UDP [17:53:53 CEST] <keglevich> yes ok, just a typo [17:54:17 CEST] <keglevich> worth mentioning...CBR ts.out is perfect...it's just the issue to make UDP CBR [17:54:31 CEST] <furq> well yeah when you restream that over udp it remuxes it [17:54:32 CEST] <keglevich> if I play ts.out in VLC player...perfect CBR stream [17:54:37 CEST] <furq> so you'll need to set all of the muxer options again [17:54:48 CEST] <keglevich> if I try to "pipe" it to UDP out...no more perfect CBR, lots of spikes, and bursts [17:54:58 CEST] <DHE> I'd use ffmpeg ... -muxrate 5800k -bitrate 5800k udp://239.8.1.181:5000?pkt_size=1316 [17:55:25 CEST] <keglevich> hmm...is this even the right syntax, shouldn't be bitrate used as udp parameter? [17:55:36 CEST] <furq> apparently it can be either [17:55:44 CEST] <keglevich> let my try... [17:55:44 CEST] <DHE> like I said, this is what I've been using and I know it works. so I'm going this way [17:55:59 CEST] <keglevich> 3 mins...I'll report back [18:01:12 CEST] <keglevich> the result is actually the same...bitrate jumps from around 5000k to about 6200k in small bursts...long line is seen as CBR, but short intervals, lots of jumps [18:02:41 CEST] <keglevich> https://imgur.com/Un0COq1 [18:02:53 CEST] <keglevich> that's what I get...but the line should be straight... [18:03:33 CEST] <keglevich> worth mentioning...If i stream different formats, some jump more, some less... [18:03:47 CEST] <keglevich> but in VLC if I play them directly...straight line [18:04:26 CEST] <keglevich> tried all possible combinations with ffmpeg, also different ffmpeg versions...seems like that's really an issue with ffmpeg, or I'm just missing some parameters...maybe some special network adapter settings? [18:04:35 CEST] <keglevich> I also tried on different NIC's..same results [18:11:04 CEST] <keglevich> strange thing is, if I look at ffmpeg cli...the output is constantly exactly 5800k (a few bits up or down) and speed 1x...so the generated stream is perfect...when that stream is piped to UDP output, the bursts appear...why? [18:11:46 CEST] <furq> keglevich: the bitrate in the stats line is the average for the whole output [18:11:49 CEST] <furq> it's not a rolling average [18:11:57 CEST] <keglevich> ah ok [18:12:26 CEST] <keglevich> but if I write the output to -f mpegts out.ts and then I play out.ts in VLC player...it's also perfect CBR stream bitrate [18:12:42 CEST] <keglevich> the issues only appear when I try to stream it over UDP [18:12:54 CEST] <keglevich> stream bursts are about 1mbit up/down [18:13:05 CEST] <keglevich> as seen in graph [18:13:28 CEST] <keglevich> I'd just like toget rid of these spikes somehow...if it's even possible [18:34:52 CEST] <keglevich> I'd be very glad if someone still has any kind of ideas what I should try to improve the bad CBR UDP output in ffmpeg [18:38:17 CEST] <DHE> I suspect it's caused by irregularities in the processing speed when using the -re option... [18:39:30 CEST] <DHE> that's just a guess though [18:40:25 CEST] <keglevich> hmm...probably not, I also tried different inputs (NDI for instance) and the result is nearly the same [18:41:00 CEST] <keglevich> although...encoding NDI input maybe, but just maybe, produces a bit less spikes... [18:41:45 CEST] <keglevich> strange thing is still, something I don't understand...if I use same command, and pipe output to .ts file...that file plays in VLC perfect CBR all the time [18:41:59 CEST] <keglevich> so I guess, there's still something with UDP output [18:43:02 CEST] <DHE> I'm suspecting it's not getting an even input rate... which is why my money is on the -re parameter [18:43:20 CEST] <DHE> as in, udp:// isn't getting a nice big buffer to fill [18:44:03 CEST] <keglevich> hmm...shouldn't muxrate do the job and fill the missing space with zeros so the output should be straight all the time? [18:45:48 CEST] <DHE> maybe, but the main ffmpeg thread is sleep()'ing to maintain an input file read rate, not a consistent output rate [18:47:25 CEST] <DHE> I'm suspecting you're seeing bursts of the output sender getting starved [18:50:42 CEST] <keglevich> this could be possible...but why then 1mbit jumps over the max muxrate? [18:52:06 CEST] <keglevich> if minrate=maxrate=5000k and muxrate=5800k...why then stream jumps occasionally to about 6500+k? [18:52:56 CEST] <DHE> minrate and maxrate are options for the video encoder to contrain its bitrate. muxrate is an option for the mpegts muxer to pad the stream to that exact bitrate. [18:53:00 CEST] <keglevich> jumps down are not that concerning anway...but I'd like to get rid at least of jups over the max allowed bitrate [18:53:31 CEST] <DHE> I haven't checked the source, but I suspect the udp output will burst if it goes idle to make up for the lost time [18:53:38 CEST] <keglevich> I'm sending this stream to hardware muxers, so the stream should have any too big jumps over the max allowed bandwidth [18:54:01 CEST] <keglevich> maybe that's true [18:54:42 CEST] <keglevich> I searched all around the net to find something documented on this topic, without any luck [18:55:08 CEST] <DHE> if you're okay with code mods, what I'd try is adding a pre-roll to udp.c so that transmission is delayed until the buffer fills up some certain amount. like, maybe 0.3 seconds or so (so around 1/3 of the bitrate) [18:55:22 CEST] <DHE> this is my best guess though. I'm too busy to research or try it myself right now [18:55:40 CEST] <DHE> but I do have something similar myself using ffmpeg, but not using -re because the source is also realtime [18:59:12 CEST] <keglevich> hmm, this seems as a big challenge for me... [21:23:06 CEST] <roxlu> hey, when you send h264 over rtp, how do you deal with AUD, do you simply skip those? [22:00:05 CEST] <GuiToris> Hello, I very frequently deshake my videos. In the wiki it's advised to use unsharp filter (unsharp=5:5:0.8:3:3:0.4) I thought I would read the unsharp filter's description but it's beyond my comprehension. luma matrix horizontal size and other stuffs. So what should I do, I can't figure out the right numbers because I don't know what they mean. Should I use this 5:5:0.8:3:3:0.4 or should I leave unsharp filter out? [22:07:22 CEST] <saml> what's deshake? [22:08:03 CEST] <saml> https://ffmpeg.org/ffmpeg-filters.html#deshake looks like it's a thing [22:08:41 CEST] <GuiToris> I can use deshake but I can't use unsharp filter [22:08:52 CEST] <GuiToris> how can I get the right numbers? [22:09:03 CEST] <saml> unsharp filter sharpens or blurs [22:09:24 CEST] <GuiToris> I could read the description, I just don't know which numbers should I use [22:09:39 CEST] <saml> link to the wiki you're reading? [22:10:14 CEST] <saml> only you can try various numbers or remove unsharp filter and see if the result is good [22:17:33 CEST] <GuiToris> that's very time consuming since I don't know what I should see [22:17:51 CEST] <GuiToris> do you happen to know if gimp uses similar numbers? [22:18:05 CEST] <GuiToris> I could unsharp an image there and apply it to the whole video [22:28:57 CEST] <ChocolateArmpits> GuiToris, "luma" series of parameters influence luma, "chroma" series influences chroma [22:29:15 CEST] <ChocolateArmpits> for each you can then set the horizontal or vertical weight [22:29:47 CEST] <ChocolateArmpits> for example you can force the video to be sharpned more in the horizontal direction rather than vertical by making the vertical value higher [22:30:40 CEST] <GuiToris> ChocolateArmpits, is there a number which is always good? [22:30:51 CEST] <ChocolateArmpits> finally "amount" parameter controls what type of effect is applied, negative for bluring, positive for sharpening, and by how much each effect is added [22:31:40 CEST] <ChocolateArmpits> well that depends on your material, generally bigger matrix size yields slower performance, not to mention the filter isn't threaded [22:31:58 CEST] <ChocolateArmpits> it also depends on the resolution of material [22:32:37 CEST] <ChocolateArmpits> start with the defaults and if you feel like it's not there keep increasing the amount applied [22:33:23 CEST] <ChocolateArmpits> if the edges that get applied through sharpening are too wide, lower the matrix size parameters [22:33:33 CEST] <ChocolateArmpits> if they aren't pronounced enough, increase their value [22:33:53 CEST] <ChocolateArmpits> It really comes down to the resolution of material really in my experience [22:34:36 CEST] <GuiToris> I think I should increase them. The default values arent noticable [22:34:47 CEST] <GuiToris> thank you for your explanation, it's a lot clearer [22:34:49 CEST] <ChocolateArmpits> so increase both size and the width [22:34:54 CEST] <ChocolateArmpits> ehhh [22:35:09 CEST] <ChocolateArmpits> matrix size for both horizontal and vertical and the amount [22:35:27 CEST] <ChocolateArmpits> The default for chroma is no amount is applied, so effectively only luma gets sharpened [22:37:02 CEST] <ChocolateArmpits> >by making the vertical value higher [22:37:09 CEST] <ChocolateArmpits> eh meant the horizontal value [22:38:17 CEST] <ChocolateArmpits> Also specifying each direction separately can help to equally sharpen anamorphic material, like 720x576 that gets displayed as 16:9 [22:38:24 CEST] <GuiToris> if chroma amount is 0, will chroma x 3 , y 3 look the same as chroma x 23 , y 23? [22:38:50 CEST] <ChocolateArmpits> well yeah it should [22:38:58 CEST] <ChocolateArmpits> as in no effect whatsoerver for chroma [22:39:15 CEST] <ChocolateArmpits> >>a value of zero will disable the effect [22:39:26 CEST] <ChocolateArmpits> straight from the docs [22:39:33 CEST] <GuiToris> I don't get it why are they 5 by default if amount is 0? [22:40:38 CEST] <ChocolateArmpits> someone probably wanted to match luma as 0 isn't an option for matrix size [22:41:01 CEST] <ChocolateArmpits> there's nothing to be bothered about really [22:46:39 CEST] <GuiToris> I still need a little help, I modified the original 5:5:1 ... to 8:8:1 and I got : Invalid even size for luma matrix size 8x8 [22:47:04 CEST] <GuiToris> what did I mess up? [22:47:07 CEST] <kepstin> you have to use odd numbers [22:47:26 CEST] <GuiToris> ahh [22:47:29 CEST] <GuiToris> you're right [22:47:32 CEST] <GuiToris> it's in the description [22:47:38 CEST] <GuiToris> it escaped my attention [22:47:39 CEST] <GuiToris> thanks [22:49:28 CEST] <GuiToris> at last, I see something [22:49:36 CEST] <GuiToris> thank you for your help [22:53:26 CEST] <GuiToris> can I create only 1 image at the third second to compare them? [22:55:45 CEST] <lays147> Hello guys.I have this command line to convert a mp4 video. https://pastebin.com/zP3yMQfv however I'm having problem in an another encoder that I have in my company, that apparently when handling i-frames, it blows up because expects i-frames between 0 and 1 and its receiving 15 and 3. I added the -keyint_min command but the command isnt working [22:55:48 CEST] <lays147> any idea on how to solve this? [22:59:11 CEST] <kepstin> GuiToris: sure, use "-ss 3" before the input filename to seek to 3s, and "-vframes 1" before the output filename to write only one frame. [23:01:35 CEST] <GuiToris> kepstin, awesome thanks [23:04:08 CEST] <ChocolateArmpits> lays147, is the encoder actually producing a video with these parameters "-g 32 -keyint_min 15 -bf 16" ??? [23:04:52 CEST] <ChocolateArmpits> those are something I would expect an mpeg2 not to support [23:05:07 CEST] <ChocolateArmpits> encoder* [23:06:49 CEST] <lays147> ChocolateArmpits: sorry, the keyint argument isnt on the original command line [23:07:02 CEST] <lays147> Was just a try that I forgot to remove on the paste [23:07:28 CEST] <ChocolateArmpits> lays147, nevermind that, gop length should go maximum to 15, 12 is more typical [23:07:28 CEST] <lays147> The issue is that the video from that ffmpeg, when goes to an another video rendering process, blows up. [23:08:53 CEST] <ChocolateArmpits> not to mention b-frames only up to 3 frames [23:09:39 CEST] <clovisw> Hi, I tried to understand a command with these parameter, -filter_complex "[0:v]scale=1920:1080[bg1];[bg1][1:v]overlay=W-w:H-h", I dont understand reading docs, what is [0:v] [bg1] and [1:v], [23:10:09 CEST] <Mavrik> clovisw: the names in brackets are inputs outputs [23:10:12 CEST] <ChocolateArmpits> lays147, try these: -g 12 -bf 2 [23:10:23 CEST] <ChocolateArmpits> lays147, and remove keyint_min [23:11:03 CEST] <Mavrik> clovisw: [0:v] is video stream in first input [23:11:08 CEST] <lays147> ChocolateArmpits: ok trying [23:11:12 CEST] <Mavrik> clovisw: [1:v] is video stream in second input, etc. [23:11:35 CEST] <Mavrik> clovisw: so you have several filters here - one that takes something from [0:v], scales it and then sends it to [bg1] output [23:11:50 CEST] <Mavrik> and then another which takes video from [bg1] and [1:v] and then makes an overlay [23:12:12 CEST] <clovisw> its a kind of watermark, but just see before, without that brackets [23:12:20 CEST] <clovisw> I think I now understand [23:12:22 CEST] <ChocolateArmpits> lays147, are you transcoding to xdcam spec or something? [23:12:27 CEST] <clovisw> thanks Mavrik! [23:12:50 CEST] <Mavrik> yeah [23:14:12 CEST] <lays147> ChocolateArmpits: yes [23:15:00 CEST] <ChocolateArmpits> lays147, did you look in this page ? http://www.deb-indus.org/tuto/ffmpeg-howto.htm#Encoding_XDCAM-HD-50_FCP [23:15:52 CEST] <ChocolateArmpits> those encoding settings can make the process pretty slow [23:16:06 CEST] <lays147> ChocolateArmpits: nope. I didnt made that command. Was another guy and now I'am fixing the mess without knowing anything about this [23:17:13 CEST] <ChocolateArmpits> anyways first complete the previous render [23:19:10 CEST] <lays147> ChocolateArmpits: we are using XDCAm 60Mbps [23:19:22 CEST] <ChocolateArmpits> You mean 50mbps [23:20:19 CEST] <ChocolateArmpits> It goes from 35Mbps for 4:2:0 video to 50Mbps for 4:2:2 [00:00:00 CEST] --- Wed Jul 4 2018

1 0

ffmpeg-devel.log.20180702
by burek 03 Jul '18

03 Jul '18

[11:39:23 CEST] <jdarnley> For the draw_horiz_band callback, is there some pointer somewhere in ffmpeg's man structs I can put my state in? [11:39:29 CEST] <jdarnley> I will need to have a way to do something with the data in the callback. [11:41:50 CEST] <jdarnley> What's the term usually used for this thing? "opaque"? [11:46:29 CEST] <jdarnley> I think I want to use AVCodecContext.opaque for that [11:47:41 CEST] <nevcairiel> dont you have a codec context for that [11:48:20 CEST] <nevcairiel> opaque is not interpreted by avcodec ever [11:48:29 CEST] <nevcairiel> unless thats what you want and i misunderstood [11:55:46 CEST] <jdarnley> Ah, maybe you do. I don't mean for the decoder, I mean for the user of the library. [11:56:19 CEST] <nevcairiel> thats indeed what opaque is for [11:56:21 CEST] <jdarnley> But then I wasn't very clear. [11:57:02 CEST] <jdarnley> Anyway it turns out that we already use opaque for exactly what I wanted to use it for. [13:43:47 CEST] <cone-010> ffmpeg 03Marton Balint 07master:b181cd359b87: ffmpeg: factorize input thread creation and destruction [13:43:48 CEST] <cone-010> ffmpeg 03Marton Balint 07master:da36bcbeb78c: ffmpeg: fix -stream_loop with multiple inputs [13:43:49 CEST] <cone-010> ffmpeg 03Marton Balint 07master:06a8d7ff00f5: avformat/apngdec: set pts to AV_NOPTS_VALUE [13:54:26 CEST] <atomnuker> wow, an apng decoder commit [13:56:19 CEST] <atomnuker> *demuxer [14:06:29 CEST] <cone-010> ffmpeg 03Michael Niedermayer 07master:d24c9e55f64e: avcodec/dvdsubdec: Check for fully transparent rectangles earlier [15:41:05 CEST] <BtbN> Is trac down? [15:42:09 CEST] <nevcairiel> apparently [18:46:39 CEST] <cone-630> ffmpeg 03Sergey Lavrushkin 07master:575b7189908e: Adds ESPCN super resolution filter merged with SRCNN filter. [18:46:40 CEST] <cone-630> ffmpeg 03Pedro Arthur 07master:54b425a7fad3: libavfilter: vf_sr.c remove warnings [18:56:29 CEST] <j-b> libavfilter/dnn_espcn.h | 12637 +++++++++++++++++++++++++++++++++++++ [18:56:33 CEST] <j-b> Where is the source? [18:56:50 CEST] <JEEB> I think that was brought up at least once :D [18:57:34 CEST] <j-b> by me [18:57:36 CEST] <j-b> of course [18:57:52 CEST] <j-b> This is a huge blob of an array, that we don't know how it was generated. [18:58:02 CEST] <JEEB> yup [18:58:23 CEST] <j-b> If it was a trained NN, where is the training data? [18:58:26 CEST] <j-b> How do we reproduce? [18:58:45 CEST] <nevcairiel> ask the author, not us =p [18:59:26 CEST] <j-b> well, it shouldn't be merged. [18:59:51 CEST] <nevcairiel> maybe that information is readily available and you just didnt see it [19:03:42 CEST] <j-b> sure. But I kind of doubt it. [19:06:12 CEST] <j-b> Seriously, I don't think tensorflow code should be inside libavfilter. [19:06:25 CEST] <j-b> but that's just my opinion. [19:39:51 CEST] <atomnuker> neural network libs are usually a huge pain to get going, and they usually only work on proprietary crap [19:46:48 CEST] <jamrial> jkqxz: ping [19:51:42 CEST] <j-b> and of course, apache2 [19:55:53 CEST] <jamrial> j-b: does this mean the filter should be gpl3? lgpl3? [19:56:03 CEST] <j-b> jamrial: well, LGPLv3 is a minimum [19:56:16 CEST] <j-b> but sorry, this filter should not be in FFmpeg at all. [19:56:31 CEST] <j-b> It is based on some research papers and codes that are not open source at all. [19:56:56 CEST] <j-b> It is based on NN where the data and training models are not available/documented [19:57:14 CEST] <j-b> Sure, NN are fun, but come on. [19:57:48 CEST] <thardin> there may also be patent treachery sfoot [19:57:52 CEST] <thardin> afoot [19:58:22 CEST] <j-b> Especially for filters that are easy to add externally. [19:58:47 CEST] <atomnuker> welp, we do have support for nnedi, though its weights need to be specified as an external file [20:02:18 CEST] <j-b> I mean, there are 1million cool filters out there. Do all deserve to be 1st party? [20:47:38 CEST] <jkqxz> jamrial: Pong. [21:05:58 CEST] <jamrial> jkqxz: https://github.com/jamrial/FFmpeg/commits/av1_parse [21:06:04 CEST] <jamrial> it's fine if you'd rather keep everything contained within your cbs code instead of using that split code (afaik cbs_av1 should have zero copy for read usage) [21:06:27 CEST] <jamrial> but i figured you'd find the extract_extradata implementation useful [21:12:30 CEST] <atomnuker> btw here's a horrifying thought TD-Linux told me of: if av1 hadn't gone for its custom OBUs but for H264 style NALS h2645 parse would have had to be modified to support av1 [21:12:47 CEST] <atomnuker> h26451? [21:13:18 CEST] <kierank> nal_parse [21:14:16 CEST] <jamrial> i essentially used h2645_parse to write that av1_parse code [21:18:19 CEST] <atomnuker> y-yeah, it was a struggle getting it to be different [21:29:52 CEST] <atomnuker> (btw you can blame TD-Linux for having them being called OBUs) [21:30:08 CEST] <atomnuker> or thank him, whichever [21:41:56 CEST] <jkqxz> Yeah, I think I'd prefer to keep that code in cbs-land so that it's all safe and traceable. [21:42:18 CEST] <jkqxz> I should get back to that stuff at some point. And write av1_metadata. [21:43:13 CEST] <jamrial> jkqxz: extract_extradata will need to be written using cbs_av1 then [21:43:31 CEST] <jamrial> for containers like ivf and annex-b [21:59:50 CEST] <jamrial> we'll probably have to adapt the libaom wrapper somehow until a native decoder lands, since mp4/matroska may not have sequence header or temporal delimiter obus within packets [22:14:38 CEST] <durandal_1707> j-b: well you do not use lavfi, so why should you care at all? [22:15:06 CEST] <j-b> durandal_1707: why do I care about the license? [22:16:23 CEST] <durandal_1707> set of numbers have license now? [22:16:53 CEST] <j-b> random numbers taken out of nowhere are usually considered as non-open-source, yes [22:17:01 CEST] <j-b> remove from most linux distributions [22:17:19 CEST] <j-b> especially if they are not random [22:19:10 CEST] <durandal_1707> please then remove all my code from FFmpeg! [22:20:15 CEST] <j-b> That escalated quickly. [22:36:47 CEST] <TD-Linux> I originally suggested not calling them NALs because I thought it would be confusing if we had something called NALs that were incompatible with h264 NALs [22:41:44 CEST] <gnafu> j-b: I'm not even sure you could say that escalated :-P. [22:43:28 CEST] <BradleyS> clearly a neural network should determine the probability and extent of escalation [22:46:13 CEST] <atomnuker> that article about using neural networks to do nanosecond time precision synchronization was ridiculous [22:46:15 CEST] <January> BradleyS: but where would you get weights under an acceptable license if weights cant be licensed? [22:46:50 CEST] <January> atomnuker: imagine not using hardware to do nanosecond synchronisation [22:49:04 CEST] <BradleyS> 27276399 9592726 93874810 63990 626728281 [22:49:20 CEST] <BradleyS> libre [22:49:52 CEST] <j-b> gnafu: sorry, I did not think that would be controversial to ask for the source of such a big array of numbers [22:50:31 CEST] <JEEB> it really isn't [22:50:46 CEST] <BradleyS> 73728 16638 294937 <- pay up for those ones though [22:51:04 CEST] <j-b> reductio ad absurdi. [22:51:04 CEST] <BradleyS> (it isn't) [22:51:05 CEST] <JEEB> and we already have one example where the weights were not put into lavfi, nnedi3 [22:51:12 CEST] <jamrial> durandal_1707 was just being himself [22:51:16 CEST] <JEEB> yes [22:51:26 CEST] <j-b> for nnedi, this was done on purpose [22:51:39 CEST] <JEEB> yes, of course [22:51:40 CEST] <j-b> (IIRC) [22:51:47 CEST] Action: BradleyS removes cone hat [22:51:56 CEST] <BradleyS> does that satisfy? :D [22:51:59 CEST] <j-b> lol [22:52:24 CEST] <j-b> BradleyS: don't shoot the messenger [22:52:35 CEST] <j-b> I know what distributions et al. will say [22:54:32 CEST] <gnafu> j-b: I'm with you. I was saying I felt like their reaction was so sudden that it didn't really escalate. It just spontaneously combusted. [22:57:10 CEST] <j-b> JEEB: I feel that this will come more and more often for NN-data. [22:57:39 CEST] <gnafu> It seems like a wild new frontier, sorta lawless and untamed. [22:57:55 CEST] <gnafu> Which I suppose just means it needs to be trained with more data ;-). [22:58:05 CEST] <BradleyS> i assume the nnedi3 data is large [22:58:16 CEST] <j-b> atomnuker: any way of following your FFv2 progress? [22:58:30 CEST] <BradleyS> hence the externalization, but perhaps that is a good practice in general [22:59:07 CEST] <j-b> well, I'd prefer a simple way to retrain with different data-set [23:00:13 CEST] <BradleyS> yes, the proof is better than the product [23:00:40 CEST] <BradleyS> at least where the former cannot be gleaned from the latter easily [23:01:20 CEST] <gnafu> Reproducibility seems like a good thing to want. [23:01:41 CEST] <JEEB> yup [23:02:12 CEST] <j-b> We had the same issue, in the past, in VLC, where a lot of artwork was bitmaps, without the "true" source [23:02:34 CEST] <j-b> and of course, as soon as the guy who did the bitmaps went away, they are un-modifiable. [23:02:49 CEST] <j-b> So now, we mandate SVG [23:03:28 CEST] <j-b> Which are the vector model used in the editing soft [23:03:32 CEST] <s55> That sounds like a familiar problem the HandBrake logo is still a single layer PSD :( [23:03:34 CEST] <BradleyS> handbrake's current icon/logo is only available as high res bitmap due to the original contributor not providing and then losing the vector [23:03:38 CEST] <BradleyS> jinx [23:04:33 CEST] <atomnuker> j-b: well I got a gh repo branch https://github.com/atomnuker/FFmpeg/tree/exp_ffv2_daala but I tweet if I've done something I think is interesting [23:42:31 CEST] <j-b> cool. [00:00:00 CEST] --- Tue Jul 3 2018

1 0

ffmpeg.log.20180702
by burek 03 Jul '18

03 Jul '18

[06:56:13 CEST] <acos> So I settled on lossles h264 as capture format for these VHS tapes. Only took me 70 tries to settle on a good command. [06:56:49 CEST] <TheAMM> What was the focus of the trial and erroring? [06:56:57 CEST] <acos> Kept getting errors [06:57:10 CEST] <acos> Noob to ffmpeg but ya [06:57:19 CEST] <TheAMM> What sort of capture device do you have? [06:57:28 CEST] <acos> So many flags on this. Still cant figure out how to fix the sync issue [06:57:41 CEST] <acos> Will have to process it after the fact. It's a USB capture device. [06:57:42 CEST] <TheAMM> No that I'm trying to solve your issues posthumously, but I'm interested in capture devices [06:57:48 CEST] <TheAMM> Not* [06:57:52 CEST] <acos> Aw :( [06:58:15 CEST] <TheAMM> I record some of my PS4 gameplay using v4l2 and alsa [06:58:23 CEST] <acos> Cool [06:58:33 CEST] <TheAMM> I've simply accepted that I have to go manually sync the a/v after I've finished [06:59:16 CEST] <acos> Ya it's just as a fshow device it won't let me use itsoffset command [06:59:18 CEST] <TheAMM> (which is kind of a bother because there are no nice hints on the PS4 menu, all transitions are fades and such) [07:00:05 CEST] <TheAMM> There's setpts and setapts, and adelay [07:00:26 CEST] <acos> Hmm wonder how to use that [07:04:28 CEST] <TheAMM> You can rewrite the timestamps with setpts and setapts, but I'm no expert on them [12:36:26 CEST] <King_DuckZ> hi, I have this function: https://paste.debian.net/1031661/ and I don't seem to be ever entering the loop - I think it's normal since my test video is 10 identical frames [12:37:12 CEST] <King_DuckZ> but then my output is a file the whose size is 242 bytes and has no streams, am I missing something in there or is the problem coming from somewhere else? [12:37:23 CEST] <BtbN> What kind of language even is that? oO [12:38:04 CEST] <King_DuckZ> BtbN: it's c++ [12:38:16 CEST] <BtbN> C++ doesn't have a "not" keyword. [12:38:48 CEST] <furq> #define not ! [12:39:01 CEST] <King_DuckZ> it does if you include ciso646, or even if you don't, in gcc [12:39:03 CEST] <BtbN> And you will need a better logic to check the receive_packet result than that in either case [12:39:47 CEST] <campones> hello, i m currently trying to compile on ubuntu 16, fresh install and I get this [12:39:48 CEST] <campones> https://i.gyazo.com/3bb385e635f07dd10dbb4be525642523.png [12:39:51 CEST] <BtbN> At the very least to Tell EAGAIN from actual error [12:40:15 CEST] <campones> here is my config : ./configure --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-libfdk_aac --enable-libvorbis --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libvpx --enable-libvorbis --enable-libopus --enable-librtmp --enable-libass --enable-libfreetype --extra-libs=-ldl --enable-openssl [12:41:06 CEST] <campones> what is broken here, any ideas? thanks [12:42:03 CEST] <BtbN> An image of plain text... great [12:42:48 CEST] <King_DuckZ> BtbN: so something like while (not r and r != EAGAIN) {}, with r being avcodec_receive_packet's return value? [12:43:19 CEST] <BtbN> That logic would always be true. [12:43:23 CEST] <campones> would it change anything if it was a pastebin? [12:43:56 CEST] <BtbN> There's an example of the intended workflow in the docs of one of the two functions [12:44:59 CEST] <King_DuckZ> BtbN: the examples are full with deprecated stuff, as a ffmpeg noob they just confused a lot [12:45:24 CEST] <campones> https://pastebin.com/EeDeJTVg [12:45:29 CEST] <BtbN> What? No they are not. Random stuff you find in years old blogposts is [12:49:14 CEST] <King_DuckZ> BtbN: https://www.ffmpeg.org/doxygen/4.0/encode__audio_8c_source.html#l00095 is that a good example? [12:50:05 CEST] <King_DuckZ> I don't need to call unref tho... or do I? [12:50:41 CEST] <BtbN> https://www.ffmpeg.org/doxygen/trunk/group__lavc__decoding.html#ga9395cb802… describes the basic workflow [12:52:38 CEST] <campones> http://www.ffmpeg.org/doxygen/trunk/tests_2mpeg12framerate_8c.html [12:52:48 CEST] <campones> from yesterday.. and now I m failing to compile.. [12:52:50 CEST] <campones> could be related? [12:54:39 CEST] <King_DuckZ> BtbN: AVERROR(EAGAIN): user must read output with avcodec_receive_packet() (once all output is read, the packet should be resent) [12:55:00 CEST] <King_DuckZ> but the code I linked just doesn't seem to care about that, so which one should I believe? [12:55:07 CEST] <King_DuckZ> that's why I said I find it confusing [15:27:37 CEST] <King_DuckZ> I'm still very confused about that process [15:28:05 CEST] <King_DuckZ> BtbN: is it wrong to use avcodec_send_frame() and av_interleaved_write_frame() together? [15:28:18 CEST] <JEEB> the latter is AVPackets, right? [15:28:24 CEST] <BtbN> Aren't they from completely different libs? [15:28:26 CEST] <JEEB> which is IIRC badly misnamed given the current structs [15:28:29 CEST] <King_DuckZ> idk [15:28:33 CEST] <JEEB> just like the read_frame one [15:28:39 CEST] <JEEB> which reads an AVPacket out of input [15:29:12 CEST] <JEEB> the decoding/encoding thing should be relatively straightforward, you send stuff into a decoder or encoder, and then receive from it, and then there's an error that tells you to do the other thing [15:29:34 CEST] <JEEB> simplest is with say H.264 decoding, where you have to feed the decoder N AVPackets before you get your first decoded AVFrame [15:30:20 CEST] <King_DuckZ> JEEB: right, it *should*, but I'm lost in a maze of stuff that takes ownership of other stuff, but only sometimes, others who don't do that, examples that use different functions and ultimately my 262 bytes output file with no streams :( [15:30:37 CEST] <JEEB> until you have fed enough the receive_frame thing will keep returning EAGAIN [15:31:01 CEST] <JEEB> and all of the code I *know* has to follow this, how the function/loop is specifically done is a different issue altogether :P [15:31:12 CEST] <JEEB> this page gives just one example https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [15:31:17 CEST] <King_DuckZ> I don't need decoding since input frames come from somewhere else already, I only have to do encoding [15:31:23 CEST] <JEEB> right [15:31:31 CEST] <JEEB> so you send avframes and receive avpackets [15:33:47 CEST] <King_DuckZ> right, I've got this now, after fixing as per BtbN's suggestions: https://paste.debian.net/1031688/ [15:34:14 CEST] <JEEB> $dayjob time so definitely not reading any code right now :P [15:44:13 CEST] <acos> So I settled on lossles h264 as capture format for these VHS tapes. Only took me 70 tries to settle on a good command. [15:44:26 CEST] <acos> It's hard to get a good video LOL [15:44:55 CEST] <BtbN> With lossless video it's pretty easy [15:48:40 CEST] <King_DuckZ> is anyone able to review my code please? [15:48:44 CEST] <Mavrik> Lossless for VHS is quite optimistic tho :) [15:49:15 CEST] <King_DuckZ> could it be the pkt I'm passing to av_interleaved_write_frame() can't be reused? since that function claims to take ownership of that pointer? [15:52:27 CEST] <BtbN> Just look at the documentation for it... https://www.ffmpeg.org/doxygen/trunk/group__lavf__encoding.html#ga37352ed2c… [15:52:39 CEST] <BtbN> "If the packet is reference-counted, this function will take ownership of this reference and unreference it later when it sees fit. The caller must not access the data through this reference after this function returns." [15:52:47 CEST] <acos> Noob at ffmpeg. Yes fell asleep before stopping creature. Got 90gb file [15:53:49 CEST] <King_DuckZ> BtbN: yeah I've been staring at that for a bit now - "If the packet is reference-counted, this function will take ownership of this reference and unreference it later when it sees fit. The caller must not access the data through this reference after this function returns." [15:54:31 CEST] <BtbN> Seems pretty clear to me? [15:54:32 CEST] <King_DuckZ> how can I tell if it's ref-counted or not? does that sentence mean that my code is wrong if pkt always points to the same object? [15:55:05 CEST] <King_DuckZ> BtbN: can you explain then please? because I don't get it [15:55:30 CEST] <BtbN> It takes ownership of it, and keeps it for later. That's the whole point of the function. [15:56:37 CEST] <King_DuckZ> so it's definitely doing that? [15:56:54 CEST] <BtbN> It's the whole point of the interleaved in its name [15:58:45 CEST] <King_DuckZ> which means I have to av_packet_alloc() right after the call to av_interleaved_write_frame(), so the next time avcodec_receive_packet() is called it will have a fresh packet pointer? [15:59:47 CEST] <BtbN> You need to unref/free it first, otherwise you'll leak it [16:01:44 CEST] <King_DuckZ> I thought av_interleaved_write_frame() would do that? since it's got ownership now? [16:01:50 CEST] <Mavrik> Basically av_interleaved_write_frame will take away the data buffer of the packet [16:01:55 CEST] <Mavrik> So you shouldn't use it again. [16:02:08 CEST] <Mavrik> You need to free the packet you passed in and allocate new buffer for more data. [16:04:24 CEST] <King_DuckZ> see why I find it confusing? so a call to the av_packet_free/av_packet_all is the correct thing here? [16:04:33 CEST] <King_DuckZ> alloc [16:05:00 CEST] <Mavrik> Not sure what do you mean by that question :/ [16:05:20 CEST] <King_DuckZ> T_T [16:06:54 CEST] <mpodien> how do i tell ffmpeg to transcode file into an .mp4 without adding this extension to the output filename? [16:07:01 CEST] <furq> -f mp4 [16:07:10 CEST] <mpodien> thanks a bunch! [16:08:37 CEST] <King_DuckZ> well it's not crashing if I free it, so all this talk about taking ownership was a lie after all [16:08:55 CEST] <King_DuckZ> but my output is still the 262 bytes thing [16:09:26 CEST] <Mavrik> uhh. [16:11:27 CEST] <BtbN> Yes, the documentation and the code sure is a lie... [16:12:25 CEST] <King_DuckZ> so, at the end of my input I call the encode() function I linked earlier with a null frame, then I call av_write_trailer() and finally avformat_free_context(), is there anything missing? [16:12:55 CEST] <BtbN> You should read up on how reference counting works [16:13:13 CEST] <BtbN> the whole point of it is to count references, so only the free of the last reference actually frees thing... [16:14:44 CEST] <King_DuckZ> wut? what about av_packet_unref() then? I thought that's what did the count decrement [16:15:04 CEST] <BtbN> free implicitly calls it [16:17:13 CEST] <King_DuckZ> ok, so that clears up some confusion at least, and explains why my code is not crashing [16:31:31 CEST] <Mavrik> I think the confusing part here is that "take ownership" usually means ownership of the buffer only, not the whole struct. [16:34:59 CEST] <King_DuckZ> Mavrik: yup, I'd never call free() or delete on a buffer of whose I don't have ownership [16:35:32 CEST] <King_DuckZ> and I'd expect an unref() function to clean up automatically when the count drops to 0 [16:36:12 CEST] <King_DuckZ> of whom [16:39:38 CEST] <DHE> even so sometimes there's confusion about whether a ref is made by the called function or whether it takes your ref [16:40:04 CEST] <Mavrik> I usually just double check in source :( [16:59:01 CEST] <King_DuckZ> avformat_write_header() is returning 0 but my output is still empty... any idea on how one would debug a problem like this? [17:01:30 CEST] <Mavrik> You usually need to write trailer and close output to finish the file. [17:02:18 CEST] <King_DuckZ> avformat_free_context() == close output? [17:02:21 CEST] <DHE> maybe there's nothing to write by the format yet, maybe there's a write buffer [17:06:35 CEST] <acos> How was I supposed to capture VHS tape? Was fighting the crossbar for hours. [17:40:01 CEST] <King_DuckZ> DHE: what do you mean it's got nothing to write? [17:40:44 CEST] <King_DuckZ> I do call encode() passing a null frame, if that's what you mean, and I can see that in my console as well, since I put a printf in there [17:59:28 CEST] <King_DuckZ> heh it turns out I wasn't increasing frame->pts [17:59:56 CEST] <King_DuckZ> now the file size looks better, but I don't think increasing is correct yet [18:00:19 CEST] <King_DuckZ> I should be doing += some_magic_value, amirite? [18:13:50 CEST] <JEEB> King_DuckZ: you have a time base and the PTS [18:14:55 CEST] <JEEB> PTS is ticks, and the time base is how many ticks in that sample will be at. [18:15:01 CEST] <JEEB> argh no [18:15:15 CEST] <JEEB> PTS is ticks at how many ticks in that sample should be presented at [18:15:22 CEST] <JEEB> and time base is how many ticks is 1 second [18:16:05 CEST] <JEEB> amd I think currently you need to set the time base in the encoder [18:16:13 CEST] <JEEB> since AVFrames don't (yet) have time bases [18:16:21 CEST] <JEEB> as an example [18:16:26 CEST] <JEEB> if you have 24/1 fps [18:16:30 CEST] <JEEB> your time base is 1/24 [18:16:37 CEST] <JEEB> and each sample +1s the pts [18:18:28 CEST] <King_DuckZ> just +1? not +1/24? [18:18:42 CEST] <King_DuckZ> or some crazy denominator, since it's an int? [18:18:45 CEST] <JEEB> 1*(1/24) [18:18:47 CEST] <JEEB> is 1/24 [18:19:05 CEST] <JEEB> pts of 24 with time base of 1/24 thus is 1 second [18:20:28 CEST] <JEEB> but yea, the muxer's AVStream time base can be different due to various things like "lol this container only has timestamps at a time base of 1/90000 [18:20:42 CEST] <JEEB> there's a function to scale the timestamps between two time bases [18:21:29 CEST] <JEEB> if AVFrames and AVPackets had their own time bases that could in theory be taken care of automagically, but unfortunately that's not the case yet [18:22:17 CEST] <JEEB> av_packet_rescale_ts [18:22:18 CEST] <JEEB> it seem [18:22:20 CEST] <JEEB> *seems [18:22:42 CEST] <JEEB> you give it an AVPacket and the encoder time base and the AVStream->time_base [18:22:43 CEST] <King_DuckZ> I don't understand, if I only have to do ++, then what do I need to scale? [18:22:54 CEST] <King_DuckZ> not pts, right? [18:23:07 CEST] <JEEB> ok, so you have your encoder, with time base of say 1/24 [18:23:12 CEST] <King_DuckZ> yes [18:23:17 CEST] <JEEB> now you f.ex. try to mux into FLV or MPEG-TS [18:23:31 CEST] <JEEB> these containers have a hard-coded time base (zomg!) [18:23:39 CEST] <JEEB> FLV has 1/1000 [18:23:44 CEST] <JEEB> MPEG-TS has 1/90000 [18:23:54 CEST] <JEEB> so after you get the AVPacket from an encoder [18:24:08 CEST] <JEEB> you have to rescale the pts/dts/duration to the output AVStream's time_base [18:24:21 CEST] <JEEB> and in general the MP4 muxer also likes to poke your time base [18:24:44 CEST] <JEEB> thankfully there's a helper function for that [18:24:58 CEST] <King_DuckZ> hm that would explain why my video terminates instantly, I tried mpg and mp4... though mkv worked fine [18:25:03 CEST] <JEEB> av_packet_rescale_ts(pkt, encoder_time_base, avstream->time_base) [18:26:07 CEST] <JEEB> for mp4 you get extra points if your AVPackets also have teh duration field set (the encoder might set this for you, probably not) [18:27:15 CEST] <King_DuckZ> I can set everything all the time, it's just that I didn't know I had to :/ [18:27:49 CEST] <JEEB> not having it set is not a problem [18:28:06 CEST] <JEEB> it's just that mp4 likes if you have it set, otherwise it calculates the duration from the packets [18:29:12 CEST] <JEEB> also for the record, this timestamp rescaling thing I can see being used by at least a few examples, including the "transcoding" one which IIRC even used the new decoding/encoding APIs. not that I vouch for any of the examples, unfortunately [18:29:33 CEST] <JEEB> some of them do things rather backwards and/or were created when specific helpers for f.ex. "black frame generation" just weren't available [18:29:50 CEST] <JEEB> also I liked the example that just skips muxing and just fwrites AVPackets' contents into a file [18:29:56 CEST] <JEEB> which might be valid, or maybe not... [18:29:58 CEST] <King_DuckZ> yeah, I noticed lots of stuff going on, but when you have no idea it just looks like it's churning stuff [18:30:22 CEST] <King_DuckZ> variable names are not super helpful either... c, oc, st, pts.... [18:32:11 CEST] <King_DuckZ> so if I got it right, I need to adjust that timestamp *after* I got my packet from avcodec_receive_packet() but *before* I pass it on to av_interleaved_write_frame(), correct? [18:32:19 CEST] <JEEB> yup [18:32:42 CEST] <King_DuckZ> and it's not like I have to adjust the number myself, that helper function will do it for me if I just pass it the whole packet, right? [18:32:47 CEST] <JEEB> yes [18:32:57 CEST] <JEEB> because thank goodness someone added that helper [18:33:09 CEST] <King_DuckZ> cool, I'm understanding something today! :) [18:34:11 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__packet.html#gae5c86e4d93f… [18:34:32 CEST] <JEEB> and yea, a total protip is to search `site:ffmpeg doxygen trunk KEYWORD` [18:34:42 CEST] <JEEB> when you need docs for something [18:35:19 CEST] <JEEB> also that first one was supposed to be ffmpeg.org [18:35:21 CEST] <JEEB> I fail as usual [18:36:03 CEST] <atomnuker> wait, what? [18:36:15 CEST] <atomnuker> you should definitely set the PTS of the avframe [18:36:25 CEST] <King_DuckZ> lol it's allright, I don't use google, I just go to ffmpeg's doc page and use the search box there ;) [18:36:31 CEST] <JEEB> yes, I thought that was already being done atomnuker [18:36:33 CEST] <atomnuker> the avpkt inherits the avframe PTS, though the encoder's free to mod it [18:36:37 CEST] <JEEB> yes [18:36:48 CEST] <JEEB> did I miss the part where this poor bastard doesn't set any PTS to begin with? [18:37:00 CEST] Action: King_DuckZ nods [18:37:03 CEST] <JEEB> I did start with explaining the concept of time_base and what PTS is [18:37:14 CEST] <atomnuker> oh k, nvm then [18:37:17 CEST] <King_DuckZ> which is why I was getting an empty mp4 T_T [18:37:28 CEST] <King_DuckZ> as it turned out [18:38:29 CEST] <King_DuckZ> btw JEEB, an AVCodecContext is the encoder, right? the object that will give me the source time_base? [18:38:58 CEST] <JEEB> it can also be the decoder, but yes - in your case that's the encoder [18:39:08 CEST] <JEEB> and you should be trying to set the time base for it [18:39:18 CEST] <JEEB> it will probably derp at you at initialization if the time base is bad [18:39:50 CEST] <King_DuckZ> likely somewhere it's set, I remember mucking around with denominators and frame rates and such [18:40:25 CEST] <King_DuckZ> I struggle to believe I wrote a wrapper that kinda works with the little understanding I have of anything ffmpeg [18:41:17 CEST] <King_DuckZ> when we will finally opensource this, you guys need to spam my wrapper as the way to do ffmpeg in c++ :p [18:45:36 CEST] <King_DuckZ> does pts need to start from 1 or something? because those changes rid me of all the "non strict monotonic pts" warnings I was getting except the first one [18:45:42 CEST] <acos> Why does avi default to mpeg4? I wanted raw avi uncompressed frames. [18:46:11 CEST] <JEEB> acos: because each container has defaults for video/audio [18:46:24 CEST] <JEEB> if you need something specific you just have to set it [18:46:36 CEST] <acos> :( so what do I have to type to get another format. Wish it was easy. [18:46:54 CEST] <JEEB> -c:v rawvideo [18:46:58 CEST] <JEEB> if I recall correctly [18:47:18 CEST] <acos> Does the ss command work to clip from crf0 libx264? [18:48:43 CEST] <acos> ThanksJEEB [18:55:04 CEST] <King_DuckZ> the avstream's time_base should be set automatically, no? [18:55:19 CEST] <King_DuckZ> ah no nvm [18:55:23 CEST] <King_DuckZ> I'm setting it [18:55:32 CEST] <JEEB> and it can then override it if it feels like it [18:55:56 CEST] <King_DuckZ> so the one from the codec is the one that is set automatically? [18:56:34 CEST] <JEEB> pretty sure it doesn' [18:56:37 CEST] <JEEB> doesn't [18:57:11 CEST] <King_DuckZ> ok so that must be why I'm getting an empty video again [18:57:25 CEST] <King_DuckZ> and: invalid DTS: pts IS LESS THAN dts [18:58:04 CEST] <King_DuckZ> and: Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly [19:00:18 CEST] <King_DuckZ> time to go home, thanks for your help everyone! [19:00:26 CEST] <King_DuckZ> I'll bother you tomorrow again! :p [20:21:47 CEST] <godzirra> Hi everyone. [20:23:03 CEST] <godzirra> Can anyone help me out for a moment? I'm trying to figure out why this works: ffmpeg -i lion-sample.mp4 -nostats -hide_banner -loglevel verbose -f mp3 ./output.mp3 ... But this does not. I get an error saying stream 1, offset 0x45cf: partial file, pipe:0: Invalid data found when processing input : cat lion-sample.mp4 | ffmpeg -i pipe:0 -nostats -hide_banner -loglevel verbose -f mp3 ./output.mp3 [20:23:30 CEST] <JEEB> you mostly cannot access mp4 files without seeking [20:23:37 CEST] <JEEB> and cat kind of doesn't let you seek [20:23:42 CEST] <JEEB> as in, stdin [20:23:44 CEST] <godzirra> So I'll almost always need the entire mp4 file, so I shouldn't use pipes? [20:23:59 CEST] <JEEB> due to various indices etc being at the end rather often, yes [20:24:07 CEST] <godzirra> bummer. Okay, thanks. [22:17:07 CEST] <darkdrgn2k> anyy reason when i add output_ts_offset to the mix the video gets verry choppy [22:37:49 CEST] <lvlscape> anyone here have expirence using ksmgrab? trying to have ffmpeg grab the video from a window that isnt part of x11 or the framebuffer.. i believe its an EGL window as it runs a fullscreen application a linux server without an x-enviroment/xserver installed. [22:40:43 CEST] <lvlscape> i set the cap_sys_admin+ep for ffmpeg in hopes of trying kmsgrab, tinking it would grab the video further down the pipe.. but kmsgrab isnt recognized, so styarted looking through docs for recompile flags, or if it was a compaitibility, or unsure if im even ont he right approach. i think the EGL window is comign from SDL/SDL2 device.. which is a supported ffmpeg device.. but when looking up how it works in [22:40:45 CEST] <lvlscape> the documentation it appears as if people oly output to SDL / SDL2 devices from ffmpeg, not using them as input [22:41:54 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-devices.html#kmsgrab [22:42:04 CEST] <JEEB> that's the kmsgrab documentation and examples [22:47:50 CEST] <lvlscape> JEEB: understood, when i try thos examples i get "Unknown input format: 'kmsgrab'" which leads me to think that either 1- i ened to recompile ffmpeg with a flag to enable , 2- im usinf incorrectly, however after a search, found a mentiont o "setcap cap_sys_admin+ep" on ffmpeg to escelate its privlige for thsi input, which i tried ot no success or 3- it just isnt compatible with my device for some reason, [22:47:51 CEST] <lvlscape> which i cant find documentation for how to check. i was able to find a docuemnt explaining how X11 + kms/drm + framebuffers all work together https://imgur.com/a/aeod2Am [22:48:23 CEST] <JEEB> lvlscape: your FFmpeg needs to be new enough and kmsgrab has to be in input devices [22:48:35 CEST] <JEEB> (when you configure) [22:49:18 CEST] <lvlscape> JEEB: gotcha, yeah its def not on my 'ffmpeg -devices' output . though i did build from source. [22:49:29 CEST] <JEEB> it requires libdrm at the very least http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=1d1b6dc3b133f45a… [22:49:37 CEST] <JEEB> as in, the development headers and libraries and pkg-config file [22:49:48 CEST] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=configure;h=1d1b6dc3b133f45a… [22:50:01 CEST] <lvlscape> that makes a lot of sense, since kms/drm seem synonomoys. [22:50:05 CEST] <JEEB> (this sets libdrm as a dependency of kmsgrab) [00:00:00 CEST] --- Tue Jul 3 2018

1 0

ffmpeg-devel.log.20180701
by burek 02 Jul '18

02 Jul '18

[01:47:00 CEST] <BBB> atomnuker: <3 nice work [06:53:31 CEST] <atomnuker> for some reason the timestamps out of the decoder are INT64_MIN [06:53:54 CEST] <atomnuker> I think I need to specialcase atrac9 in utils.c like the other atrac codecs ;/ [11:08:46 CEST] <kaot> Hi everyone! Quick question: I submitted a patch set (libavformat/aadec) several days ago. I wonder what's going to happen with it? Do I need to find a sponsor or something to get it included into the codebase? [11:09:49 CEST] <durandal_1707> just bump patch with new mail requesting action for it after several days [11:13:43 CEST] <kaot> ok, thanks, will do [13:46:27 CEST] <atomnuker> michaelni: could you upload https://pars.ee/temp/atrac9_fate.tar.gz to fate? I've sent a patch to add a atrac9 testing [14:03:14 CEST] <JEEB> atomnuker: ooh, test samples :D [14:27:26 CEST] <j-b> awesome [14:46:05 CEST] <michaelni> atomnuker, test fails on qemu mips. Before uploading, am i correct that making the samples smaller is not a good idea ? [14:46:22 CEST] <michaelni> about the failure see ML i just posted it [15:07:02 CEST] <DXK77> I am trying to extract image from .mp4 file, but it just mangled the .png output filename from the batch file [15:08:17 CEST] <jdarnley> Batch file huh? Are you aware that % is a special character in them? [15:08:21 CEST] <atomnuker> michaelni: yeah, I knew they would, sample 2 uses PNS which needs random numbers, which the lfg outputs [15:08:29 CEST] <DXK77> Could not open file : outputC:\ffmpeg\1.bat5d.png [15:08:53 CEST] <jdarnley> Yep. Learn to work your shell. [15:09:12 CEST] <DXK77> is there a frontend for ffmpeg that can extract specific timecodes [15:10:28 CEST] <DXK77> why won't this work in batch file? "C:\ffmpeg\bin\ffmpeg.exe" -i "input.mp4" "frames/out-%03d.jpg" [15:12:15 CEST] <jdarnley> Because %0 gets substituted for the 0th argument to the batch file [15:15:06 CEST] <jdarnley> If you want to learn more I suggest this website https://ss64.com/which I have found extremely useful in the past. [15:15:19 CEST] <jdarnley> And take all further support questions to #ffmpeg [15:15:38 CEST] <jdarnley> I mean https://ss64.com/ [15:15:45 CEST] Action: jdarnley curses his spacebar [15:15:53 CEST] <DXK77> thanks! much appreciated :) [16:55:14 CEST] <michaelni> atomnuker, the lfg should output the same numbers on mips and x86, or did i misunderstand what you meant ? [17:19:49 CEST] <atomnuker> michaelni: the lfg is float-based, so that's not guaranteed [17:20:07 CEST] <atomnuker> or maybe its the imdct which is non bitexact [17:20:23 CEST] <atomnuker> anyway, it needs a fuzz value so now I know about how much it ought to be [17:20:29 CEST] <michaelni> i thought you meant the integer one [17:21:00 CEST] <atomnuker> no, I'm using the float one, not the alfg or mlfg variants, those output 32bit uints [17:21:51 CEST] <atomnuker> I've asked someone to decode the files with the reference decoder to see how they compare, though if someone here has a windows machine handy and wants to help I can send the binaries over [17:25:45 CEST] <michaelni> not me, my windows box has not been used for years, but ill test with the updated ref files when i see them [17:27:25 CEST] <atomnuker> thanks [00:00:00 CEST] --- Mon Jul 2 2018

1 0

ffmpeg.log.20180701
by burek 02 Jul '18

02 Jul '18

[03:54:04 CEST] <Hello71> isn't -buffer_size in *bytes* anyways [03:54:42 CEST] <Hello71> also wtf is this avplay crap [03:55:23 CEST] <furq> welcome to drama from 7 years ago [04:20:02 CEST] <Hello71> I mean it hasn't exactly ended [04:23:24 CEST] <Hello71> although with both ubuntu and debian switching back to ffmpeg it looks like libav is pretty dead [05:26:35 CEST] <Soni> what's ffplay -f alsa hw:0 ? [05:26:48 CEST] <Soni> it keeps running into xrun [05:28:05 CEST] <Soni> oh I had it muted, that's why it wasn't playing [05:28:25 CEST] <Soni> wait, it's playing without ffplay [05:28:28 CEST] <Soni> what [05:29:01 CEST] <Soni> I have no idea what's happening [05:31:55 CEST] <Hello71> some hacker got your ip with a gui in visual basic [05:32:09 CEST] <Soni> oh wait [05:32:11 CEST] <Soni> oooh [05:32:16 CEST] <Soni> I'm an idiot [05:34:35 CEST] <Soni> if I up the mic volume in alsa's "playback" mixer, it goes to playback, right? [05:37:11 CEST] <Hello71> maybe [05:37:14 CEST] <Hello71> depends on your card [05:37:16 CEST] <Hello71> but probably not [05:38:02 CEST] <Hello71> 108 commits since jan 1 vs 46377 [05:38:47 CEST] <Soni> well, it does seem to be playing [05:38:52 CEST] <Soni> which is, weird [05:40:31 CEST] <Hello71> pretty doorknob dead there [05:55:28 CEST] <lvlscape> Has anyone here ever used ffmpeg to try and record an EDL / SDL output that wasnt part of x11 for x11grab? [05:57:16 CEST] <lvlscape> use case is when some application run a graphical application from headless server without a xserver setup [05:59:30 CEST] <lvlscape> so grabbing the framebuffer with ffmpeg -f fbdev .. isnt right, as theres no tty session of output as we can tell .... stop me if im speaking gibberish [06:04:53 CEST] <lvlscape> oh, i may need to use kmsgrab i think.. reading more now [06:14:27 CEST] <lvlscape> ohhhh, sdl2 is part of the -devices area.. we have been having a blast today [06:15:03 CEST] <lvlscape> 3-4 of us spent 12+ hours in ffmpeg, it wa sa lot of fun, im makign ntoes and i hoped this for hail marys, but i feel liek its like almos tthere [06:22:05 CEST] <lvlscape> we know another application is making an SDL output... ffmpeg devices can see sdl/sdl2 .... though the documentation looks liek ffmpeg liks to output to sdl... looking for exampels of someone using sdl as an input.. [07:28:30 CEST] <anickname> where can I see the log for this channel [11:40:47 CEST] <myki> Greetings, I need your help please... I want to trim all silences from an mp3, and all command lines i find with google fail, generally triming only the first silence at the begining... <<ffmpeg -version>> returns <<ffmpeg version N-91024-g293a6e8332>>. Can you help me, please ? [15:45:25 CEST] <Cecil> I want to concatenate two videos. For this I use: [15:45:25 CEST] <Cecil> ffmpeg -i "concat:MVI_6797Shrinked.mov|MVI_6798Shrinked.mov" -c copy educational.mov [15:45:25 CEST] <Cecil> But only the first video ends up in educatinal.mov. So I am doing something wrong. But what? [16:01:19 CEST] <Blacker47> Cecil, try the -f concat method: https://trac.ffmpeg.org/wiki/Concatenate [16:01:51 CEST] <phot0n> Cecil, https://stackoverflow.com/questions/5415006/ffmpeg-combine-merge-multiple-m… [16:01:56 CEST] <JEEB> &34 [16:25:11 CEST] <Cecil> I did something like -f concat in the past, but this needs an extra file. I had hope to do it without it. But if that is not going to work: so be it. [16:25:18 CEST] <Cecil> Thanks anyway. [16:25:31 CEST] <Hello71> <() [16:25:46 CEST] <Hello71> process substitution [16:29:45 CEST] <DHE> or just pipe input [16:30:28 CEST] <Cecil> What do you mean by that? [16:33:42 CEST] <DHE> something like: echo -e "file File1\nfile File2" | ffmpeg -f concat -i - .... [16:34:31 CEST] <DHE> come on, get creative... [16:39:16 CEST] <Cecil> I tried: [16:39:16 CEST] <Cecil> echo -e "file MVI_6797Shrinked.mov\nfile MVI_6798Shrinked.mov" | ffmpeg -f concat -i - -c copy educational.mov [16:39:16 CEST] <Cecil> But this gives: [16:39:16 CEST] <Cecil> [file @ 0x563f214d1780] Protocol not on whitelist 'crypto'! [16:39:16 CEST] <Cecil> [concat @ 0x563f214c7e40] Impossible to open 'MVI_6797Shrinked.mov' [16:39:18 CEST] <Cecil> pipe:: Invalid argument [17:02:02 CEST] <TrIPpY> Hi. I have an issue with ffmpeg 4.0.1 on linux together with libfdk-aac 1.6. No errors in ffbuild/config.log , no make errors. Is in same location as other ext libs: /usr/local/lib and pkgconfig and .pc file is also there. When i run ffmpeg binary: cannot open shared object and quits. Any ideas. [17:02:08 CEST] <TrIPpY> ? [17:03:41 CEST] <TrIPpY> internet searches did not Give much results [17:05:46 CEST] <TrIPpY> except to run ldconfig and check /etc/ld.so.conf [17:05:58 CEST] <TrIPpY> and reboot [17:09:26 CEST] <TrIPpY> I didn't do make install. I think its ok to run from location where unpacked and compiled right? I pretty die sure [17:10:09 CEST] <TrIPpY> pretty sure i did that before like that too [17:11:16 CEST] <TrIPpY> oh built all libs and ffmpeg static BTW [17:23:21 CEST] <TrIPpY> conn check... [17:45:00 CEST] Last message repeated 1 time(s). [17:50:00 CEST] <JEEB> uh-huh [18:07:29 CEST] <TrIPpY> anybody Any Idea How to prevent Being Disconnected from irc? [18:08:17 CEST] <c3r1c3-Win> 1. Have a good client. [18:08:23 CEST] <c3r1c3-Win> 2. Have a good internet connection [18:08:39 CEST] <c3r1c3-Win> 3. Connect to a good server. [18:08:41 CEST] <TrIPpY> haha keep alives? [18:11:54 CEST] <TrIPpY> conn is ok im sure. im on chat.freenode.net:6697. client is a free one from play store [18:15:51 CEST] <TrIPpY> nobody have an idea about my problem? [18:18:28 CEST] <BtbN> Don't run an IRC client on Android, which agressively power-saves [18:18:46 CEST] <BtbN> IRC is not energy efficient for a phone. [18:18:52 CEST] <BtbN> It can't go to sleep, ever. [18:25:33 CEST] <TrIPpY> yeah [18:26:11 CEST] <DHE> sounds like what you want is a bouncer [18:28:12 CEST] <TrIPpY> but Android van run things in the backgroud too. like my ssh client. never disconnects. i also set to keep wifi active [18:28:38 CEST] <TrIPpY> i [18:29:07 CEST] <DHE> different protocols have different rules. ssh defaults on most platforms have pretty weak keepalive requirements [18:29:18 CEST] <DHE> whereas IRC is a lot tougher [18:29:52 CEST] <TrIPpY> rember it now .i think mirc back in the day had an setting to csend keep alives [18:30:25 CEST] <TrIPpY> thu [18:30:39 CEST] <DHE> client side keepalvies might work, but it's still not going to be pleasant on a cellphone battery to be waking up every 30-60 seconds like that [18:31:23 CEST] <DHE> and transitioning between cellular and wifi will still disconnect you [18:31:44 CEST] <TrIPpY> this one has an option to reconnect auto matically. But shortest interval is a minute. Well better than nothing. [18:32:33 CEST] <TrIPpY> yeah it should reconnect in that case [18:33:27 CEST] <DHE> right, but during that time it still loses messages on IRC and it spams everyone with quit/join messages [18:33:46 CEST] <TrIPpY> true [18:35:43 CEST] <TrIPpY> but the idea about my problem i meant the ffmpeg thingy [18:38:42 CEST] <TrIPpY> but thanks for the response to the irc question as well [19:26:25 CEST] <BtbN> IRC and SSH both are not fit for mobile use. [19:26:34 CEST] <BtbN> They will drain your battery pretty quick [19:26:50 CEST] <BtbN> Android is not able to keep TCP connections alive and go to sleep [19:41:40 CEST] <TrIPpY> If You Say So [19:41:57 CEST] <TrIPpY> trying For The First Day Today so you don't have Any Experience [19:42:23 CEST] <BtbN> ...? [19:42:25 CEST] <TrIPpY> me i mean voice recognition [19:43:09 CEST] <TrIPpY> on Android [19:45:48 CEST] <TrIPpY> aren't a few packet exchanges per few minutes enough on irc? [19:46:22 CEST] <BtbN> A TCP connection cannot stay alive without constant interaction though [19:52:09 CEST] <sfan5> says who? [19:53:24 CEST] <BtbN> rfc5482 [19:53:36 CEST] <TrIPpY> yeah but thats no obligation to keep a network session between hosts alive [19:54:07 CEST] <BtbN> phones also tend to switch IPs and network connections [19:54:21 CEST] <TrIPpY> yeah tru [19:54:32 CEST] <BtbN> but the deep sleep is the way bigger issue [19:54:52 CEST] <TrIPpY> as we discussed reconnection needed [19:55:18 CEST] <BtbN> That would also burn a lot of battery every time. [19:55:26 CEST] <BtbN> Get a bouncer if you don't want to miss chat. [19:55:48 CEST] <TrIPpY> some software doesnt allow sessions to continue from a different ipadress im sure [19:56:57 CEST] <TrIPpY> perhaps most [19:58:29 CEST] <BtbN> IRC doesn't have sessions [20:01:38 CEST] <TrIPpY> no? what is it that gets disconnected then. Yiu stay in there for a certain time and when a timeout is reached. server says bye. and network connections are no longer existant [20:03:19 CEST] <TrIPpY> after that for sure anyway. or client or user reconnects. [20:03:55 CEST] <TrIPpY> but thats starting from scratch [20:08:22 CEST] <TrIPpY> if network connection gets severed A timeout also occurs ofcourse. server also drops the session. And client probably assumes after a timeout because of the lack of answers in latter case [20:08:53 CEST] <TrIPpY> that session is over [20:17:07 CEST] <sfan5> BtbN: rfc 5482 defines behaviour when data is left unacknowledged, if a TCP connection is idle you can leave it like that indefinitely [20:18:46 CEST] <BtbN> If the IRC server would stay silent for minutes at a time, sure [20:19:29 CEST] <sfan5> IRC has its own keepalive mechanisms, I meant tcp in general [20:21:32 CEST] <BtbN> If the TCP connection dies, IRC will be dead as well [20:59:07 CEST] <TrIPpY> <TrIPpY> Hi. I have a question... ffmpeg 4.0.1 on linux together with libfdk-aac 1.6. No errors in ffbuild/config.log , no make errors. Is in same location as other ext libs: /usr/local/lib and pkgconfig and .pc file is also there. When i run ffmpeg binary: cannot open shared object and quits. [20:59:46 CEST] <TrIPpY> <TrIPpY> I didn't do make install. I think its ok to run from location where unpacked and compiled right? [21:00:40 CEST] <TrIPpY> oh built all libs and ffmpeg static BTW [21:02:27 CEST] <DHE> sounds like an ldconfig issue... [21:10:31 CEST] <TrIPpY> ldconfig version? [21:11:24 CEST] <TrIPpY> good day btw [21:18:12 CEST] <TrIPpY> oh you mean run it? tried that and rebooted [21:22:43 CEST] <TrIPpY> or must ldconfig before making ffmpeg? [21:34:16 CEST] <DHE> you don't need to reboot [21:34:39 CEST] <DHE> echo /usr/local/lib > /etc/ld.so.conf.d/usrlocal.conf ; ldconfig [21:35:30 CEST] <BtbN> it's clearly not static if it needs ldconfig [21:36:40 CEST] <DHE> ffmpeg with --enable-static doesn't mean the binary is static. it means the ffmpeg libs are built for static linking [21:37:06 CEST] <DHE> the ffmpeg binaries still depend on system (and 3rd party) libraries on the system. and generally if both shared and static are available, gcc prefers shared [21:48:35 CEST] <TrIPpY> that did the job. Thanks a bunch. the ldconfig only makes sense when the path is added somewhere ld.so.conf.d then... learned a new thing! thanks [21:49:07 CEST] <DHE> I'm mildly annoyed that such an entry isn't just on every system by default [21:49:39 CEST] <DHE> but BtbN is right. this isn't REALLY a static link. this binary may not reliably run on other systems. especially since you clearly have local dependencies [21:50:03 CEST] <TrIPpY> so patg is quiet common ? [21:50:28 CEST] <DHE> huh? [21:51:03 CEST] <TrIPpY> weird since i configured al libs and ffmpeg with that option [21:51:07 CEST] <BtbN> /usr/local is not standard, no [21:51:47 CEST] <TrIPpY> option: --enable-static [21:52:21 CEST] <DHE> that builds libavcodec.a instead of libavcodec.so, etc [21:52:37 CEST] <DHE> doesn't build with libc.a instead of libc.so and so on [21:52:53 CEST] <DHE> you'll want --extra-cflags=-static [21:53:06 CEST] <TrIPpY> so that is why it is not default in ld.so.conf on linux systems [21:53:19 CEST] <DHE> and be prepared that it may fail to build and require some work [21:53:42 CEST] <DHE> /usr/local isn't where any standard package goes. but it is pretty common for hand-built software [21:54:15 CEST] <TrIPpY> it already works now... i'm happy. [21:54:23 CEST] <JEEB> yea, debian/ubuntu tends to have /usr/local/lib under ld.conf, red hat things tend to not to [21:54:36 CEST] <JEEB> "it depends" is the general reply I guess [21:55:01 CEST] <DHE> can confirm redhat... [21:55:11 CEST] <TrIPpY> ah that' my problem then... the distro... haha [21:55:48 CEST] <TrIPpY> fedora too i csn confirm now. but same family [21:55:50 CEST] <JEEB> not really a problem as long as you keep in mind when you build shared libs [21:56:58 CEST] <DHE> now that /usr/local/lib is added, it shouldnt' be a problem going forward on this system... [21:57:26 CEST] <TrIPpY> yeah it already works... directly after [21:57:34 CEST] <TrIPpY> problem solved [21:58:48 CEST] <TrIPpY> kind of weird that its only a problem for fdkaac and not for libx264 en libopus [21:59:14 CEST] <BtbN> it will fail on whatever lib it comes across first [21:59:32 CEST] <TrIPpY> compiled them too also install into /usr/local [21:59:40 CEST] <BtbN> so? [21:59:45 CEST] <TrIPpY> ah ofcourse [21:59:48 CEST] <BtbN> It has to fine one of them first... [21:59:54 CEST] <BtbN> *d [22:00:18 CEST] <TrIPpY> yeak it loads fdkaac first apperently [22:00:32 CEST] <DHE> x264 by default builds in static mode, so that is a non issue [22:00:58 CEST] <TrIPpY> static link or binary? [22:02:30 CEST] <DHE> libx264.a instead of libx264.so [22:02:43 CEST] <DHE> ffmpeg has no choice but to be static linked with x264, so no issue there [22:03:00 CEST] <DHE> fdk-aac does both, and gcc prefers the dynamic link by default, and you end up in this mess [22:08:23 CEST] <TrIPpY> aha .a is not shared [22:09:33 CEST] <TrIPpY> ah ok fdkaac should do static by default too [22:11:13 CEST] <DHE> yes, but similarly you'll have to remove the existing dynamic library [22:11:19 CEST] <DHE> since it's already installed [22:13:32 CEST] <TrIPpY> help me out plz ... installed already because ? [22:14:02 CEST] <TrIPpY> fdkaac does both? [22:14:45 CEST] <DHE> you built a shared library, even if you didn't intend to, and then ran `make install` [22:17:14 CEST] <TrIPpY> yes but if it does not exist yet then it's no problem right? [22:17:54 CEST] <TrIPpY> you mean it gets overwritten right? [22:18:12 CEST] <TrIPpY> if already on the system [22:22:29 CEST] <DHE> this is more an issue of uninstalling it... [22:24:29 CEST] <TrIPpY> i thought packages only get uninstalled. compiled and installed from source needs to be msnually removed right? [22:33:48 CEST] <TrIPpY> thanks s bunch for the solution and the extra wisdom [00:00:00 CEST] --- Mon Jul 2 2018

1 0

ffmpeg-devel.log.20180630
by burek 01 Jul '18

01 Jul '18

[00:43:20 CEST] <cone-230> ffmpeg 03Wang Cao 07master:5a99e00023c0: libavformat/yuv4mpeg: Add color range support for Y4M Add color_range support in Y4M. [00:43:20 CEST] <cone-230> ffmpeg 03Michael Niedermayer 07master:d08d4a8c7387: avcodec/vc1_block: Fix mqaunt check for negative values [01:37:43 CEST] <thardin> woop, figured out how to get gapless clickless CDs going [01:37:54 CEST] <thardin> and I see some mxfdec patches [11:08:53 CEST] <atomnuker> durandal_1707: look what hit the ML this morning [11:17:26 CEST] <JEEB> &/34 [11:17:28 CEST] <JEEB> funky [16:15:21 CEST] <cone-363> ffmpeg 03Michael Niedermayer 07master:9f0077cc0397: tools/target_dec_fuzzer: Fix parser_avctx memleak on error path [18:06:25 CEST] <Gramner> c language lawyers: why does gcc complain about casting x** to const x * const *? it makes everything const! I know that casting x** to const x** is an error since that could allow a const pointer to become non-const but I really can't see what's wrong with the former [18:09:51 CEST] <nevcairiel> i thought that conversion could work [18:18:13 CEST] <Gramner> x* to const x* and x** to x * const * works. so that narrows it down to x * const * to const x * const * somehow being an error [18:26:00 CEST] <atomnuker> maybe they forgot to add this case as an exception [18:47:59 CEST] <Gramner> works with g++ but not gcc which is also interesting. c++ obviously superior! /s [18:55:19 CEST] <iive> cast giving error instead of warning? [18:55:48 CEST] <Gramner> it warns when implicitly cast [18:55:55 CEST] <Gramner> e.g. calling a function [18:57:09 CEST] <Gramner> https://pastebin.com/jdBYuwX3 [19:00:10 CEST] <Gramner> if you explicitly cast it to be identical to the function arg type it works, but that's super ugly [21:35:09 CEST] <JEEB> http://up-cat.net/p/3a173449 [21:35:37 CEST] <JEEB> noticed this because I'm not yet specifically disabling avdevice in my test building [21:36:02 CEST] <JEEB> wonder if this is something that should be poked at towards the NDK people or if this might hit some other clang-based compilation thing as well [00:00:00 CEST] --- Sun Jul 1 2018

1 0

ffmpeg.log.20180630
by burek 01 Jul '18

01 Jul '18

[02:04:15 CEST] <dscully> temp: see line 1783 of https://github.com/FFmpeg/FFmpeg/blob/master/fftools/ffmpeg.c [02:35:09 CEST] <fa0> Hello [02:36:01 CEST] <fa0> I'm using ffmpeg-3.4.2, and I'm taking larger videos and re-encoding them, so they will be smaller, I'm running this in a script; [02:36:02 CEST] <fa0> urxvt -g 120x32 -e ffmpeg -i "$i" -c:v libx264 -preset veryfast -crf 20 -c:a copy "$OUTPUT/${i%.*}.mkv" [02:37:13 CEST] <fa0> If I use Handbrake 1.1.0 and set it as VeryFast 720p30 which also and make it the same -preset veryfast -crf 20, I end up with Handbrake producing video sizes around 50MB smaller... [02:37:47 CEST] <fa0> I'm not sure what I can do, so the video size will be comparable, but ffmpeg producing larger, I don't get what Handbrake setting is giving better compression [02:47:03 CEST] <fa0> I guess just doing, '-c:v libx264 -preset veryfast -crf 20 -c:a copy' isn't producing best compression, need some other option(s), or this is as good as it gets? [02:47:40 CEST] <DHE> -crf is a generic one-pass quality selector, with lower numbers being higher quality (obviously at higher file size) [02:48:07 CEST] <DHE> I don't use handbrake, but for x264 there's two main modes of operation: crf and fixed bitrate. (and variants thereof) [03:00:53 CEST] <Trel> I don't have a windows machine handy to check on at the moment, but does the windows builds support stdin for input? [03:01:13 CEST] <Trel> or pipes in general? [03:03:28 CEST] <iive> fa0, is the resolution of both files the same? same fps ? also both are using libx264 so check what versions are using and what options are the providing to it [03:03:54 CEST] <iive> also, deinterlace? [03:10:52 CEST] <fa0> same rez,fps, x264 [03:12:41 CEST] <fa0> Handbrakes has these filters set; 'Interlace Detection' - Fast 'Deinterlace: Decomb' [03:12:43 CEST] <fa0> hmm [03:19:11 CEST] <fa0> Well there's only so much time in the day, LOL, maybe I better stick to handbrake for the more complex, and stick to myffmpeg for simple jobs... [03:19:12 CEST] <fa0> hmm [03:21:33 CEST] <fa0> DHE: thanks [03:22:20 CEST] <fa0> I was watching Mr Robot last night, and they were using ffmpeg LOL [03:22:51 CEST] <fa0> ffmpeg was on TV! :P [12:49:20 CEST] <wpwpwpwp> hi [12:49:35 CEST] <wpwpwpwp> I got a bunch of WAV files and I want to combine/merge + convert them all into a single MP3 file. [12:49:56 CEST] <wpwpwpwp> Ideally by just selecting them in Windows Explorer, in context menu hitting "combine to mp3" [12:50:09 CEST] <wpwpwpwp> this would be cool - are there any tools like this / frontends / GUIs for ffmpeg? or lame? [12:58:49 CEST] <DHE> while you can do it in a single ffmpeg command, it requires a small amount of scripting. either the concat demuxer (which should make a temp file on disk listing all .wav files) or the concat filter can assemble it all together [12:59:00 CEST] <DHE> see also the ffmpeg wiki page on concatenation [13:01:31 CEST] <wpwpwpwp> DHE: ffmpeg is very good in understand audio/video formats, right? [13:01:41 CEST] <wpwpwpwp> DHE: can it also concatenate audio files without affecting quality? (re-encoding)? [13:02:09 CEST] <DHE> well converting wav files to mp3 isn't possbile without reencoding [13:02:39 CEST] <wpwpwpwp> DHE: so FFMPEG can concatenate + convert in single step? [13:02:47 CEST] <wpwpwpwp> DHE: right, converting to MP3 is re-encoding :D [13:02:59 CEST] <wpwpwpwp> DHE: is there a little nifty command line command I can run for this? [13:03:35 CEST] <remlap> yes, there is [13:03:59 CEST] <furq> for f in *.wav; do printf "file %q\n"; done | ffmpeg -f concat -protocol_whitelist file,pipe -safe 0 -i - -q:a 0 out.mp3 [13:04:01 CEST] <remlap> https://rg3.github.io/youtube-dl/supportedsites.html [13:04:28 CEST] <wpwpwpwp> thx [13:04:37 CEST] <DHE> your printf needs some love, but that works on linux, and maybe windows with bash? [13:04:43 CEST] <wpwpwpwp> furq: this may sound obscene, but can I run this also in Batch? [13:04:48 CEST] <furq> nope [13:04:50 CEST] <wpwpwpwp> ah ok [13:04:55 CEST] <wpwpwpwp> I will run it on WSL then [13:04:59 CEST] <remlap> how many files are there [13:05:05 CEST] <wpwpwpwp> about 6 max [13:05:06 CEST] <furq> if you have wsl then yeah that'll work fine [13:05:23 CEST] <remlap> read the url i listed it wont take long to do them manually [13:05:36 CEST] <DHE> this command just writes out the list of files into a pipe. making it a text file and then running ffmpeg on the text file is probably most straight-forward, but requires a temporary file be created [13:05:37 CEST] <furq> why are you telling him to use youtube-dl to concat wavs [13:05:45 CEST] <remlap> shit sake [13:05:47 CEST] <remlap> wrong url [13:05:51 CEST] <wpwpwpwp> lol [13:05:51 CEST] <remlap> linux paste buffers ugh [13:05:56 CEST] <remlap> https://trac.ffmpeg.org/wiki/Concatenate [13:05:57 CEST] <wpwpwpwp> OK, I installed ffmpeg on WSL and run it there [13:06:06 CEST] <furq> i mean yeah it's good to read that anyway [13:06:12 CEST] <furq> to understand the one-liner i just pasted [13:06:16 CEST] <wpwpwpwp> there is no windows tool or simple tool for this :( [13:06:19 CEST] <remlap> thanks for noticing furq [13:06:38 CEST] <remlap> I have ctrl+v on one button of my mouse and middle click on another [13:06:42 CEST] <remlap> so easy confuse myself [13:07:04 CEST] <remlap> I need better paste buffer management [13:07:12 CEST] <wpwpwpwp> Unrecognized option 'protocol_whitelist'. [13:07:20 CEST] <furq> how old is this ffmpeg [13:07:23 CEST] <DHE> older version of ffmpeg then [13:07:29 CEST] <wpwpwpwp> aha [13:07:32 CEST] <wpwpwpwp> can I still run it? [13:07:33 CEST] <wpwpwpwp> plssss [13:07:38 CEST] <furq> just remove that and it'll work i guess [13:07:41 CEST] <wpwpwpwp> thx [13:07:56 CEST] <wpwpwpwp> [concat @ 0x2305420] Impossible to open '' [13:07:57 CEST] <wpwpwpwp> hmmm [13:08:00 CEST] <furq> DHE: is there any login shell people actually use that doesn't support printf %q [13:08:21 CEST] <furq> oh lol nvm i see [13:08:26 CEST] <DHE> :) [13:08:32 CEST] <furq> wpwpwpwp: printf "file %q\n" "$f" [13:09:29 CEST] <wpwpwpwp> alright, some stuff happened apparently [13:09:47 CEST] <wpwpwpwp> wow that was fast [13:09:51 CEST] <wpwpwpwp> I had to check [13:10:01 CEST] <wpwpwpwp> ok, bonus points: can I add a 2second pause between each? :D [13:10:11 CEST] <DHE> yes... [13:10:35 CEST] <remlap> if its six why not simply write the six files in a txt file and then ffmpeg -f concact -i file.txt out.mp3 [13:10:56 CEST] <remlap> not like theres a 100 files or something silly [13:11:17 CEST] <wpwpwpwp> remlap: hm, I could try to make a windows batch file out of it and then add a context menu handler to registry [13:11:26 CEST] <wpwpwpwp> DHE: is there a "pause" or "empty" filter? :D [13:11:46 CEST] <remlap> how often you planning to do this [13:11:50 CEST] <remlap> so its not a one time thing? [13:11:55 CEST] <DHE> wpwpwpwp: anullsrc [13:12:00 CEST] <wpwpwpwp> indeed, it hapens more often [13:12:09 CEST] <remlap> then I understand [13:12:10 CEST] <wpwpwpwp> hmmm, I use an android audio recorder that creates wav for each recording [13:12:16 CEST] <wpwpwpwp> I want to combine them often to mp3 for sending [13:12:26 CEST] <wpwpwpwp> DHE: how can I add annullsrc into the command? :D [13:13:07 CEST] <DHE> wpwpwpwp: lavfi with anullsrc to the spec matching the WAVs, and setting the duration to 2 seconds [13:13:38 CEST] <remlap> be easier to use audacity at that point [13:13:54 CEST] <remlap> but again not automatic [13:13:58 CEST] <remlap> im thinking shit today [13:13:59 CEST] <DHE> https://ffmpeg.org/ffmpeg-formats.html#concat-1 the docs for the concat inputs [13:15:42 CEST] <wpwpwpwp> OK, any nice android app (it can even cost a bit) that can record voice + then save to mp3 in the end? :) [13:20:28 CEST] <furq> wpwpwpwp: make an empty 2-second wav and then printf "file %q\nfile 'silence.wav'\n" "$f" [13:20:37 CEST] <furq> that's the least annoying way i can think of [13:21:00 CEST] <DHE> that also works... [13:21:20 CEST] <furq> you can't use lavfi sources in the concat demuxer can you [13:21:24 CEST] <furq> that would make life simpler [13:21:39 CEST] <remlap> til there is no stock audio recorder on android [13:21:41 CEST] <remlap> good god [13:21:45 CEST] <DHE> well why not? use `lavfi` as the format rather than `file` [13:22:00 CEST] <furq> does that work [13:22:20 CEST] <DHE> hmm.... let me check [13:22:30 CEST] <furq> i don't see lavfi listed as a directive [13:23:32 CEST] <DHE> well never mind me then... [16:01:19 CEST] <phot0n> is there a way to get the average bitrate of a bunch of videos located in a folder? with either ffmpeg or ffprobe [16:02:12 CEST] <DHE> ffprobe can provide its estimate on each individual video. the rest is up to you though [16:02:45 CEST] <phot0n> i see, and for each individual video, is there a specific option I need to invoke for it to tell me the average bitrate? [16:02:52 CEST] <phot0n> with ffprobe I mean [16:03:16 CEST] <DHE> just run it on the video, there's a bitrate printed out. if you want something more machine parsable you'll want additional options. [16:04:10 CEST] <phot0n> but is that bitrate for the video stream, or everything, including audio and muxing overhead? [16:04:17 CEST] <phot0n> because that's something that always confused me [16:04:18 CEST] <DHE> everything [16:04:29 CEST] <phot0n> ugh [16:04:30 CEST] <DHE> you might get bitrates on the individual streams as well, depending [16:04:38 CEST] <phot0n> depending on...? [16:04:54 CEST] <DHE> mainly the codec. some are fixed bitrate, some are not [16:05:14 CEST] <phot0n> well, if it's fixed bitrate, whatever option that reports average bitrate will just give me that fixed bitrate, I assume [16:05:23 CEST] <DHE> figuring out each stream's bitrate reliably requires reading the whole file and actually counting [16:05:29 CEST] <phot0n> I see [16:05:42 CEST] <DHE> but yes, a fixed bitrate codec is easily measured with a short sample [16:05:49 CEST] <phot0n> i mean yeah that's sensible, it needs to see how big the video stream is and then what its duration is [16:05:56 CEST] <phot0n> and then calculate [16:06:09 CEST] <DHE> well the duration is usually easily measured. that's how the whole-file bitrate is calculated so quickly [16:06:15 CEST] <phot0n> right [16:06:31 CEST] <DHE> but if you want to split it into audio, video, and container overheads, you have to do it the hard way [16:06:48 CEST] <phot0n> heh and what is this hard way? o.o [16:08:34 CEST] <DHE> I like to use ffmpeg -i FILE_TO_TEST -c copy -f null /dev/null just let it run, look at the statistics at the end [16:08:46 CEST] <DHE> some math required though [16:08:55 CEST] <phot0n> nice [16:08:58 CEST] <phot0n> all right I'll give that a go [16:55:57 CEST] <pagios> hi all, how can i convert an rtsp stream to rtmp please? any example? [16:56:07 CEST] <pagios> only transmuxing [17:12:47 CEST] <anickname> hey [17:13:00 CEST] <anickname> I want to build ffmpeg from source using Cygwin [17:13:12 CEST] <anickname> the only thing I'm going to be doing is converting mp4 / mp3 / flac files to wav [17:13:19 CEST] <anickname> I want it to be static binary [17:13:21 CEST] <anickname> how do I do this [17:14:41 CEST] <BtbN> You're not going to get a static binary from cygwin [17:14:49 CEST] <BtbN> it will at the very least always need the cygwin libraries [17:15:57 CEST] <CoreX> best to just use what is online and compiled already [17:16:11 CEST] <CoreX> for that type of task [17:16:53 CEST] <anickname> I know [17:17:05 CEST] <anickname> I want it to be a static binary that depends on Cygwin [17:17:26 CEST] <anickname> because the paths that are being passed to ffmpeg are POSIX and it doesn't work with the windows binary [17:18:08 CEST] <anickname> so I need to compile a static binary via cygwin [17:18:37 CEST] <DHE> well you always depend on the cygwin.dll [17:18:52 CEST] <BtbN> cygwin straight up does not support static binaries [17:19:07 CEST] <BtbN> you probably mean "without external dependencies". Which you will get if you just build it. [17:19:21 CEST] <BtbN> Not with a lot of features, but the basics will be there. [17:19:24 CEST] <anickname> that's what I mean, without external dependencies :P [17:19:42 CEST] <anickname> I want to depend on the cygwin.dll in order to support POSIX input paths :P [17:19:58 CEST] <BtbN> Just use cygpath with a norla binary? [17:20:14 CEST] <anickname> huh? [17:20:33 CEST] <anickname> Basically I'm running commands like this [17:20:33 CEST] <BtbN> cygpath -w gives you the windows path for any cygwin aware path [17:20:44 CEST] <CoreX> best to check out https://ffmpeg.org/platform.html and you might find the anwser there [17:20:45 CEST] <anickname> really [17:20:58 CEST] <BtbN> And winpty also helps with cli applications to behave properly [17:21:02 CEST] <anickname> well [17:21:05 CEST] <anickname> you're awesome [17:21:12 CEST] <anickname> thank you, I needed that :) [17:21:33 CEST] <BtbN> cygpath isn't even a cygwin tool, as weird as that seems with its name [17:21:55 CEST] <anickname> it's not? [17:21:58 CEST] <anickname> what is it [17:23:52 CEST] <anickname> oh also I know this isn't a cygwin channel [17:24:34 CEST] <anickname> but you know how cygwin built binaries require other dlls, like it'll say Missing openblas.dll or whatever, if you include that .dll, will you also have to include any of its dependencies [17:33:03 CEST] <TheWild> hello [17:42:27 CEST] <TheWild> well, okay. I wanted to report a trouble with my video that I have uploaded to drivehq through ftp... but well, I have puzzle for you: what could go wrong? [17:42:53 CEST] <TheWild> the hint is that it happened during upload and it's a drivehq fault [17:45:02 CEST] <pagios> hi all, how can i convert an rtsp stream to rtmp please? any example? [22:33:50 CEST] <kubast2> Hey can someone run me through utilising hardware vp9 encoder in kaby lake(nvidia optimus) ? [22:34:42 CEST] <kubast2> gonna check first [22:34:46 CEST] <kubast2> if I can do it actually [22:37:25 CEST] <kubast2> ok got hevc to work [22:39:30 CEST] <kubast2> Kaby Lake gen9.5 VP9 profile 2 decode; VP9, H.265 Main10 encode. [22:39:38 CEST] <kubast2> VP9 encode :think: [22:40:03 CEST] <kubast2> maybe pixel format ? [22:42:08 CEST] <kubast2> my guess is that format= needs to be changed ince p010 is 10bit ? [22:44:40 CEST] <atomnuker> yep, p010 is usually what hardware deals with [22:45:12 CEST] <kubast2> vp8 works fine for nv12 [22:45:20 CEST] <kubast2> can't use vp9_vaapi with nv12 [22:45:30 CEST] <kubast2> *vp8_vaapi [22:45:49 CEST] <kubast2> Failed to create encode pipeline configuration: 25 (an invalid/unsupported value was supplied). [22:46:13 CEST] <kubast2> tried render device 129 since I also have that [22:46:57 CEST] <kubast2> yeah device129/192 might be nvidia driver [22:47:43 CEST] <kubast2> yeah I can input 10bit vp8_vaapi can't encode with vp9_vaapi on ubuntu 18.04 [22:47:50 CEST] <kubast2> with 8bit and 10bit [22:51:35 CEST] <kubast2> I mean I guess hevc works [22:51:40 CEST] <kubast2> http://dpaste.com/0PJKF98.txt atomnuker [22:52:26 CEST] <pagios> anyone here? [22:52:40 CEST] <pagios> corrupted macroblock 18 31 (total_coeff=-1) getting distorted pictures when playing [22:52:44 CEST] <pagios> lot of errors any idea? [22:53:09 CEST] <pagios> ffmpeg -i rtsp://..../profile3 -threads 4 -f flv -r 10 -s 320x240 -an rtmp://localhost:1935/mytv/myStream [22:53:18 CEST] <ChocolateArmpits> pagios, what version are you using ? [22:53:20 CEST] <pagios> how can i improve on that? [22:53:56 CEST] <pagios> ChocolateArmpits, ffmpeg version 3.4.2-2 [22:54:13 CEST] <pagios> ChocolateArmpits, if i try to play the rtsp in vlc it works fine [22:55:30 CEST] <pagios> ChocolateArmpits, https://i.imgur.com/QDKwkfs.png [22:56:31 CEST] <ChocolateArmpits> pagios, can you try forcing rtsp over tcp ? [22:56:37 CEST] <ChocolateArmpits> -rtsp_transport tcp [22:58:04 CEST] <pagios> ChocolateArmpits, same problem [22:58:37 CEST] <pagios> ChocolateArmpits, https://i.imgur.com/5do5X3V.png [22:59:58 CEST] <ChocolateArmpits> pagios, did you use rtsp_transport as an input option? [23:00:34 CEST] <pagios> ChocolateArmpits, ffmpeg -i rtsp://.../profile3 -rtsp_transport tcp -f flv [23:00:45 CEST] <ChocolateArmpits> you need to use it in front of the input -i [23:00:50 CEST] <pagios> oh ok [23:01:38 CEST] <ChocolateArmpits> the default if for rtsp to communicate over udp, which can result in lost packets, tcp should be more stable albeit at some slight latency. [23:01:44 CEST] <ChocolateArmpits> is* [23:02:33 CEST] <pagios> so ffmpeg rtsp_transport tcp -i rtsp://.. [23:03:03 CEST] <ChocolateArmpits> ye with the rest of command as you had previously specified [23:03:12 CEST] <ChocolateArmpits> uh don't forget the dash [23:03:14 CEST] <pagios> ChocolateArmpits, [NULL @ 0x5620e7883dc0] Unable to find a suitable output format for 'rtsp_transport' [23:03:16 CEST] <ChocolateArmpits> in fron of the option [23:03:19 CEST] <pagios> ok :) [23:04:17 CEST] <pagios> it works :))) [23:04:20 CEST] <pagios> Thanks ChocolateArmpits [23:04:30 CEST] <ChocolateArmpits> np [23:04:49 CEST] <pagios> i still get some stuff though [h264 @ 0x562353f0e060] SEI type 187 size 968 truncated at 77 [23:04:58 CEST] <ChocolateArmpits> :/ [23:05:21 CEST] <ChocolateArmpits> but it's not as bad? [23:05:26 CEST] <pagios> no it is good [23:06:00 CEST] <ChocolateArmpits> did you get on process initialization? [23:06:03 CEST] <ChocolateArmpits> them& [23:06:05 CEST] <ChocolateArmpits> them* [23:06:10 CEST] <pagios> whats that [23:06:16 CEST] <ChocolateArmpits> When starting transcoding [23:06:42 CEST] <ChocolateArmpits> As in those errors only show up when starting the process and don't when it continues [23:07:01 CEST] <pagios> ChocolateArmpits, https://i.imgur.com/DvEAI01.png [23:08:48 CEST] <pagios> ChocolateArmpits, they stay there [23:08:53 CEST] <pagios> in the middle too not only start [23:09:03 CEST] <ChocolateArmpits> hmm [23:11:33 CEST] <pagios> ChocolateArmpits, it is not very stable [23:14:22 CEST] <pagios> ChocolateArmpits, i get from avplay: Invalid data found when processing input [23:14:29 CEST] <pagios> and sometimes the stream doesnt start [23:15:14 CEST] <ChocolateArmpits> pagios, is the network itself not overburdened? [23:15:21 CEST] <pagios> no it is fine i guess [23:22:06 CEST] <ChocolateArmpits> pagios, try adding -buffer_size 10M in front of -i [23:22:13 CEST] <ChocolateArmpits> 10 megabits should be enough of a buffer [23:22:37 CEST] <ChocolateArmpits> though you may want to scale it down if it fails [23:22:43 CEST] <ChocolateArmpits> likely to -buffer_size 64k [23:23:11 CEST] <ChocolateArmpits> I'm just looking at particular solutions [00:00:00 CEST] --- Sun Jul 1 2018

1 0