Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

September 2019

2 participants
80 discussions

ffmpeg.log.20190818
by burek 03 Sep '19

03 Sep '19

[00:37:40 CEST] <Thomas_J> I am getting "Input/output error" and "cannot set channel count to 2" with an input device "hw:CARD=2,DEV=0. anybody, any ideas? [00:39:08 CEST] <Thomas_J> This device us a USB extrnal heqdphone adaptor. [00:43:41 CEST] <cehoyos> The external adaptor likely only supports mono [00:49:50 CEST] <Thomas_J> true but shouldn't ffmpeg by default use 1 channel instead of 2? [00:55:53 CEST] <Thomas_J> When I tried to set the input with -ac:1, I get "hw:CARD=Device,DEV=0: Protocol not found". [00:57:28 CEST] <furq> it's -ac 1 [00:57:46 CEST] <Thomas_J> Aahhh [00:58:48 CEST] <Thomas_J> that worked. Thanks. [10:25:36 CEST] <snatcher> what's the difference between audio formats u8 s16 s32 s16p etc? [10:31:44 CEST] <DHE> 's'=signed, 'u'=unsigned integers [10:33:40 CEST] <snatcher> also there is u8p s16p s32p [10:36:28 CEST] <DHE> planer [10:36:36 CEST] <DHE> like yuv420 vs yuv420p [16:10:22 CEST] <Didier_Spaier> Hello, here configuration of ffmpg 4.2 with the option --enable-libopencv (having opencv 4.1 installed) fails because opencv/cxcore.h is not found. If I am correct this file is part of a deprecated opencv API. Any update planned to be able to link against a recent opencv? [16:12:01 CEST] <Mavrik> You'll probably have to write a patch yourself, there's probably not many OCV users [16:13:53 CEST] <JEEB> Didier_Spaier: I think they removed the C API completely [16:14:01 CEST] <JEEB> so you're left with a separate C++ one [16:14:09 CEST] <JEEB> if I recall the related issue correctly [16:14:52 CEST] <durandal_1707> why you need opencv at all? [16:15:15 CEST] <JEEB> we might have some C++ code building in FFmpeg already, but genearlly we just use C APIs of C++ projects :P [16:16:56 CEST] <Didier_Spaier> JEEB: so if I understand well, for now all I can do is downgrade opencv to have it linked to by ffmpeg? [16:17:10 CEST] <JEEB> if you really need whatever the opencv thing provides, yes [16:17:17 CEST] <JEEB> within FFmpeg that is [16:17:56 CEST] <Didier_Spaier> So I will do that for now, thanks for the answer. [16:20:30 CEST] <Didier_Spaier> durandal_1707: I don't personally need opencv, but as the maintainer of the Slint distribution http://slint.fr I want to package ffmpeg with as many features as I can, not knowing what features will be used by each Slint user. [17:34:56 CEST] <AiNA_TE> if i need to delogo and crop a video at the same time [17:35:18 CEST] <AiNA_TE> do i need to change my delogo co-ordinates to account for the crop applied [17:36:04 CEST] <AiNA_TE> like if my delogo started at a width of 10, and i needed to crop 2 from the left, do i change delogo to start at width of 8? [17:36:12 CEST] <AiNA_TE> or just leave it as it is [17:39:00 CEST] <pink_mist> depends if you crop first or delogo first [19:54:13 CEST] <Hackerpcs> I'm not sure if it's ontopic, but how could I get the direct URL for the flash player here? http://www.echoes.gr/el/player [20:12:08 CEST] <DHE> flash player? most browsers don't do plugins anymore [20:12:11 CEST] <DHE> also pretty sure that's off topic [20:13:56 CEST] <Hackerpcs> Sorry. I found a solution if anyone wonders https://moshekaplanblog.wordpress.com/2014/10/23/downloading-an-rmtp-stream/ [20:14:38 CEST] <pink_mist> heh, that link is misspelling rtmp [22:25:20 CEST] <Hackerpcs> Can I use the additional parameters (app, playpath) etc for rtmp input? https://ffmpeg.org/ffmpeg-protocols.html#rtmp [22:27:46 CEST] <durandal_1707> its in documentation [22:30:35 CEST] <Hackerpcs> https://pastebin.com/N5WZV6bx -- rtmpdump works but passing the same arguments to ffmpeg doesn't [22:37:51 CEST] <durandal_1707> Post full uncut command line you used [22:38:58 CEST] <Hackerpcs> it's on the pastebin above [22:43:56 CEST] <durandal_1707> what error you get? [22:45:29 CEST] <Hackerpcs> rtmp server sent error - rtmp server requested close - rtmp://85.17.75.147:1935/echoes_relay/: Unknown error occurred [22:48:00 CEST] <durandal_1707> put options after -i ? [22:49:23 CEST] <Hackerpcs> trying it on the build provided by ubuntu server's 19.04 (N-93748-g19f1eaa) gives me "[http @ 0x56373ca7d0c0] HTTP error 404 Not Found - [rtmp @ 0x56373ca7c380] Cannot open connection http://www.echoes.gr/index.swf/[[DYNAMIC]]/1/[[DYNAMIC]]/2. - rtmp://85.17.75.147:1935/echoes_relay/: Server returned 404 Not Found" [22:50:06 CEST] <Hackerpcs> the error about the url with "DYNAMIC" in it is present also on rtmpdump but it doesn't matter there, it proceeds to download it [22:50:48 CEST] <Hackerpcs> that argument doesn't seem to be needed at all, I can remove it from rtmpdump [22:51:23 CEST] <Hackerpcs> Putting the -i before the options results the same and I'd guess the options aren't utilized at all that way because I don't get the error that way about the URL [22:52:16 CEST] <durandal_1707> are you usinng librtmp with ffmpeg? [22:52:28 CEST] <Hackerpcs> on ubuntu with the options after -i it results in "Server error: Connection failed: Application rejected connection." so the options are disregarded that way [22:53:37 CEST] <Hackerpcs> on Windows yes, on Ubuntu the repo build doesn't use it [22:58:57 CEST] <Hackerpcs> does it work for you with the systax from the pastebin? [22:59:34 CEST] <durandal_1707> im on phone so cant test unti tommorow [23:29:34 CEST] <Oldest> does 60fps video double size of 30fps of same content? [23:30:02 CEST] <Oldest> does 60fps video create double file size of 30fps of same content? [23:32:10 CEST] <durandal_1707> no [23:32:20 CEST] <Oldest> why not [23:32:23 CEST] <DHE> not unless it's uncompressed [23:32:35 CEST] <Oldest> shouldn't it be doubled based on math [23:32:46 CEST] <durandal_1707> no [23:34:36 CEST] <Oldest> can 60fps video create similar file size as 30fps of same content then? [23:36:37 CEST] <Mavrik> Depends. [23:36:55 CEST] <DHE> compression is under user control. if you specifically request, say, 5 megabit video, the resulting video will be 5 megabits regardless of resolution or framerate (2 pass mode may be required for consistency) [23:39:45 CEST] <kepstin> the closer frames are together in time (higher framerate), then they're usually more similar to each-other, which means the encoder can reuse more data from frame to frame. if set the gop size based on time, there'll be more frames per gop too [23:40:05 CEST] <kepstin> which means for the same visual quality, a 60fps video will usually be less than twice the size of 30fps video [00:00:00 CEST] --- Mon Aug 19 2019

1 0

ffmpeg-devel.log.20190902
by burek 03 Sep '19

03 Sep '19

[00:42:04 CEST] <xmichael> Hello all [00:42:10 CEST] <xmichael> Hello all, I have run into an issue when using HLS and fragmentation, and also I think a bug with respect to the use_temp_file parameter [00:42:14 CEST] <xmichael> I posted about it here on reddit https://www.reddit.com/r/ffmpeg/comments/cyahv0/fragmented_hls_outputting_a… [00:42:58 CEST] <xmichael> I've made a really budget code change to work around the use_temp_file issue. I do not think a temp file should be exclusively enforced if the output is to file. Many file systems support reading and writing at the same time [00:43:29 CEST] <xmichael> The ability to write to disk and read the file being created is desirable for low latency goals [00:48:45 CEST] <nicolas17> xmichael: event vs VOD is written into the playlist header, what does your playlist say? [00:49:59 CEST] <xmichael> #EXTM3U#EXT-X-VERSION:7#EXT-X-TARGETDURATION:2#EXT-X-MEDIA-SEQUENCE:0#EXT-X-PLAYLIST-TYPE:EVENT#EXT-X-MAP:URI="init.mp4"#EXT-X-DISCONTINUITY [00:50:23 CEST] <nicolas17> so it *doesn't* think you're trying to make a vod [00:50:53 CEST] <xmichael> Correct. I've updated from git without any luck [00:51:19 CEST] <xmichael> Err, sorry let me restate that. It gets that I want an event, yet no matter the flags the playlist only appends [00:51:51 CEST] <xmichael> current command is ffmpeg -y -loglevel info -i rtsp://192.168.1.241 -g 60 -c libx264 -tune zerolatency \-hls_segment_type fmp4 \-hls_time 2 \-hls_list_size 3 \-hls_flags delete_segments+append_list+split_by_time \-hls_playlist_type event /opt/www/east/east.m3u8 [00:52:11 CEST] <nicolas17> what do you mean "it only appends"? isn't that what append_list is for? [00:53:35 CEST] <xmichael> with or without append_list as a flag, the playlist grows indefinitely [00:53:54 CEST] <nicolas17> huh [00:54:00 CEST] <nicolas17> "hls_playlist_type event" sets hls_list_size to 0 [00:54:21 CEST] <nevcairiel> EVENT type playlists are defined that way, nothing can ever be deleted from them [00:54:29 CEST] <nevcairiel> if you want stuff to be removed, dont use event [00:54:40 CEST] <nicolas17> so there's three types? [00:54:43 CEST] <nicolas17> vod, event, and nothing? [00:54:58 CEST] <xmichael> I am only aware of event and vod, according to the documentation. I don't see a 3rd type. [00:55:22 CEST] <nevcairiel> a live sliding-window playlist h as no type entry [00:55:39 CEST] <xmichael> It is my understanding that VOD would have a playlist that grows until the entire transcode is created, and a EVENT would be a live stream that circles through a playlist using the specified number of segments defined by hls_list_size [00:55:48 CEST] <nevcairiel> thats wrong [00:55:53 CEST] <nicolas17> xmichael: looks like what you want is no type at all [00:56:14 CEST] <xmichael> I see in the documentation what nevcairiel just noted, hls_playlist_type_event sets hls_list_size to 0, but that doesn't seem to make sense with my understand at least (: [00:56:36 CEST] <nevcairiel> a VOD playlist has to be complete 100% before its being served to the user, a EVENT type playlist can still be growing while you already serve it, but you can never remove from it [00:56:49 CEST] <nevcairiel> a "live" playlist has no type indicator, and you can remove from it [00:57:23 CEST] <xmichael> thank you folks, I did not see that in the documentation. [00:57:36 CEST] <xmichael> I don't quite understand what an EVENT is, but fair enough, without that defined I am good [00:57:40 CEST] <nevcairiel> serving HLS assumes that one already knows the basics of HLS playlists [00:58:00 CEST] <xmichael> Ok, so my second discovery and my little hack with respect to the use_temp_file flag [00:58:11 CEST] <xmichael> The evaluator says that if it is outputting to file, then always use temp file [00:58:43 CEST] <xmichael> As I mentioned in my initial question as well, I don't think that is the most desirable way to operator. No reason I can think that a temp file should be forced simply because it is writing to a file system??? [00:59:26 CEST] <nevcairiel> I'm not quite sure a HLS client would necessarily like getting a partial segment file [00:59:32 CEST] <nicolas17> looks like it uses a temp file for non-VOD by default [01:00:03 CEST] <nevcairiel> i believe the segment is only added to the playlist once its complete, so its mood anyway [01:00:28 CEST] <xmichael> /int use_temp_file = is_file_proto && ((hls->flags & HLS_TEMP_FILE) || hls->master_publish_rate); [01:00:36 CEST] <xmichael> is_file_proto is hit in all cases [01:00:57 CEST] <nicolas17> that's && so it has to meet the second condition too [01:02:51 CEST] <xmichael> Sure. let me try once more without my modified code [01:03:12 CEST] <xmichael> and of course without hls_playlist_type event :) [01:05:01 CEST] <xmichael> It looks like even without hls_playlist_type defined [01:05:04 CEST] <xmichael> [hls @ 0x5c56900] Opening '/opt/www/east/east2.m4s' for writingA dup=28 drop=5 speed=1.13x[hls @ 0x5c56900] Opening '/opt/www/east/east.m3u8.tmp' for writing [01:05:23 CEST] <nicolas17> I don't get why you don't want temp files [01:05:37 CEST] <nevcairiel> using it for the playlist itself is rather important, otherwise you might get a partial playlist as its being updated, and that would be very bad [01:05:39 CEST] <xmichael> I don't want a temp file, because I want to be able to serve the file that is being written if necessary [01:05:47 CEST] <nevcairiel> you can't anyway [01:05:52 CEST] <xmichael> why not? [01:05:55 CEST] <nicolas17> the playlist won't reference those files until they are done being written anyway [01:06:07 CEST] <nevcairiel> because serving a partial segment would be illegal according to HLS [01:06:33 CEST] <nevcairiel> segment-based streaming formats are not ideal for low latency due to that fact [01:07:31 CEST] <xmichael> the file being written to disk is in the play list [01:07:48 CEST] <xmichael> I've just made the segment size 30 seconds and I can see the file actively being written in the playlist [01:08:16 CEST] <nicolas17> so the playlist references a file that doesn't exist? [01:09:14 CEST] <xmichael> the play list appears to be updated to include the new file, and then the file is created and data is being written to it [01:09:27 CEST] <xmichael> the file is 100% in the list while it is still be written to [01:09:48 CEST] <nicolas17> you mean while its corresponding .tmp file is being written to? [01:11:05 CEST] <xmichael> uhh [01:12:09 CEST] <xmichael> Not using the code in github no. However if I force use_temp_file to 0, the file is in the playlist [01:12:19 CEST] <nicolas17> if ffmpeg is using temp files, it should be creating a .tmp, writing to it, and then renaming it to remove the .tmp extension [01:12:32 CEST] <nicolas17> you'd never see a partial .ts file [01:12:54 CEST] <xmichael> but that is what I want to do :) [01:13:08 CEST] <nevcairiel> you cant serve partial files for HLS, its simply not going to be valid. what if a client downloads it, is it supposed to check back later if it grew after it got it? that just doesnt make any sense [01:13:14 CEST] <nevcairiel> its just not possible [01:13:15 CEST] <nicolas17> my question is if you're seeing the .ts referenced in the playlist while it doesn't exist (because it didn't get renamed yet) [01:13:37 CEST] <xmichael> nevcairiel; yes I serve the file using http chunk-encoding. So the client will read until EOF [01:13:58 CEST] <nicolas17> you don't know if the webserver will hit EOF and terminate the transfer before ffmpeg finishes writing the file [01:13:59 CEST] <nevcairiel> but neither the webserver nor the client can know if the segment is complete or not [01:14:02 CEST] <nevcairiel> so that doesnt work. [01:14:07 CEST] <xmichael> nicolas17: not in the code from github, only in my hacked code where I force use_temp_file = 0 [01:14:15 CEST] <nicolas17> so you broke it :P [01:14:27 CEST] <xmichael> hahah [01:15:07 CEST] <xmichael> You are both right and I am wrong, however I still want to do it. The logic I have is that serving a partially done file is still more desirable than the player having nothing to play [01:15:20 CEST] <nicolas17> playlists don't reference partial files, or files that don't exist because they weren't renamed from .tmp yet, guess your half-change broke that invariant [01:15:32 CEST] <xmichael> Since playback is in realtime, and the source is real time. The player can't really beat the encoder at creating the file. [01:16:12 CEST] <nevcairiel> playing a partial file is absolutely worse then playing nothing, because if the player doesnt get a complete file, it m ight just miss content entirely [01:16:46 CEST] <nevcairiel> downloads from the webserver are not in realtime, they go as fast as the browser can do it [01:17:11 CEST] <nevcairiel> so if it creates a new file with one frame in it only, and a browser would g rab it, it would not come back and see if there is more to grab later [01:17:14 CEST] <nevcairiel> it would just bail [01:17:16 CEST] <xmichael> umn, right that little detail the file will be downloaded as fast as possible [01:17:43 CEST] <nicolas17> it would also think it's time to get the next one and it would *also* be a partial file [01:17:52 CEST] <xmichael> I guess buffering my chunk-encoded transfer wouldn't be to stellar either hah [01:18:08 CEST] <nicolas17> (only way for the client to get "in sync" and start receiving complete files is if it pauses for a second) [01:18:40 CEST] <nevcairiel> one could do a very low-latency live streaming thing with HLS if one would control the encoder, segmenter and web server in one piece of software, so that you can make the webserver block as long as you know there is more content coming [01:18:41 CEST] <xmichael> I guess my grand dream of providing slightly lower latency HLS by making that last file available if necessary might not be happening. I felt that chunk-encoding was going to be my answer as then I can deliver a file of unknown size [01:18:47 CEST] <nevcairiel> but alas, you can't do that with a lot more work :p [01:19:00 CEST] <nevcairiel> without* [01:19:33 CEST] <xmichael> I did make the webserver, there are not really any off the self webservers that allow you to serve files already open using chunk-encoding [01:19:45 CEST] <nicolas17> if you want lower latency, use a smaller segment; if you want <2s latency, HLS might not be the right solution ^^ [01:20:15 CEST] <nicolas17> man I remember when Twitch had a latency of like 30s [01:20:30 CEST] <xmichael> See I am ok with ~4 seconds of latency, however three x 2 second segments don't always work. Simply because the 3rd file is not available [01:20:42 CEST] <cone-529> ffmpeg 03Raphaël Zumer 07master:8821d1f56e18: avutil/pixfmt: Add EBU Tech. 3213-E AVColorPrimaries value [01:20:42 CEST] <cone-529> ffmpeg 03Raphaël Zumer 07master:08dfd57fd83a: avfilter: Support EBU Tech. 3213-E primaries values [01:20:42 CEST] <cone-529> ffmpeg 03Raphaël Zumer 07master:a12b629ae129: avcodec: Support EBU Tech. 3213-E primaries values [01:20:53 CEST] <xmichael> This was my great idea, 3 x 2 second segments produced from ffmpeg, and use chunk encoding to server the 3rd file as it is being written if necessary [01:22:11 CEST] <xmichael> Actually, I would technically slow the file down on the transfer. Since I know the approximate size by evaluating the other files on disk. [01:22:19 CEST] <xmichael> thought that is getting pretty hacky (: [01:23:31 CEST] <nicolas17> if you wrote your own webserver, you can make requests to 123.ts read from 123.ts.tmp instead, and you can wait for the rename as a reliable indication that it's complete [01:23:43 CEST] <nicolas17> but I still think this is all a bad idea :P [01:24:28 CEST] <xmichael> ohh, that is actually kind of brilliant [01:25:41 CEST] <xmichael> I use a loop to read the files while (bytesRemaining > 0) currently [01:26:20 CEST] <xmichael> thank you I might not have to abandon this crazy idea just yet! ;D [01:26:20 CEST] <BradleyS> i'm not sure why you'd need to serve the file as it's being written, just keep writing chunks of a few seconds or more, and serve those as they become available and are needed [01:27:01 CEST] <BradleyS> akamai chops up streams into multiple smaller .ts, not sure if it's mpeg-dash specifically [01:27:13 CEST] <xmichael> bradleys: the issue is the latency. realistically to serve globally with any level of reliability you need 3 segments 3 seconds long [01:27:38 CEST] <nicolas17> tbh hls_list_size 3 seems low [01:28:07 CEST] <xmichael> right, I've experimented with 1 second segments and 5 segments total, but still not ideal [01:28:17 CEST] <nicolas17> the reason to have few segments in the playlist is to avoid the playlist itself getting too large [01:28:36 CEST] <nicolas17> pretty sure clients will try to start from the last segment anyway [01:28:54 CEST] <xmichael> depending on the player, they often only play the last available file [01:29:53 CEST] <nevcairiel> the spec at least says that in live playlists you should start at the end [01:30:15 CEST] <xmichael> -hls_segment_type fmp4 [01:30:20 CEST] <nevcairiel> so making it bigger has no real downside except perhaps allow clients that have a bit of buffering to be a bit more graceful [01:30:44 CEST] <xmichael> this type still seems to be governed by they key frame interval [01:33:40 CEST] <nevcairiel> HLS mandates that every segment must start with a keyframe [01:34:31 CEST] <xmichael> Ok, so one last crazy idea then. Why can't my web server make a play list with a single file and a length of 1 million seconds. When a player comes along I feed using chunked encoding the latest data produced by ffmpeg into that session? [01:35:11 CEST] <xmichael> open ffmpeg's playlist, grab the next file in the list and output to the player, append, append, append the same session using chunked-encoding. the player never disconnects [01:35:15 CEST] <nicolas17> if you do that you don't need HLS [01:35:18 CEST] <nicolas17> or a playlist [01:35:28 CEST] <BradleyS> i meant have the entire payload be 3-second long .ts [01:35:42 CEST] <nevcairiel> many HLS devices will try to cache segments, and will absolutely die on such a hack [01:35:46 CEST] <BradleyS> or 2x3, then 10x10, then ... [01:36:20 CEST] <BradleyS> so you're not reading bytes from an open file as they hit the disk [01:36:55 CEST] <xmichael> the cache segments, that will be the burn... grr [01:37:06 CEST] <xmichael> bradleys: I'm not sure what you mean? [01:37:27 CEST] <nevcairiel> if you want low latency just use progressive mpegts streaming [01:37:45 CEST] <BradleyS> "use chunk encoding to server the 3rd file as it is being written if necessary" [01:37:54 CEST] <BradleyS> seems brittle [01:37:56 CEST] <xmichael> nevcairiel: is there a way to do that without getting into the mess of WebRTC? [01:38:00 CEST] <BtbN> Or copy what Twitch did to HLS. They do HLS with sub second streamer to viewer latency [01:39:07 CEST] <BtbN> iirc Mixer just opens a WebSocket connection to the server, and the server sends some (fragmented) mp4 stream the Browser can feed directly to the Media API [01:39:50 CEST] <nevcairiel> HLS and DASH had one primary design goal, easy CDN support - not low latency [01:40:42 CEST] <BtbN> Twitch basically just adds 3 "future segments" to the playlist, with special tags for the player. And the player then goes ahead and tried to pre-load them early [01:40:58 CEST] <xmichael> BtbN: That is pretty easy to do using jsmpeg, however with h264 that because next to impossible [01:41:07 CEST] <BtbN> what? [01:41:21 CEST] <xmichael> Twitch as I understand it, serves the last file as it is being written [01:41:37 CEST] <BtbN> I doubt Twitch writes any files anywhere. [01:41:48 CEST] <nevcairiel> if you control both server and client, you can get away with a bunch of extra nonsense [01:41:50 CEST] <BtbN> They are doing some heavy magic in their CDN [01:43:27 CEST] <xmichael> Thanks everyone for the comments, I'm sad now though :b [01:44:18 CEST] <xmichael> It just feels there should be an easier way to serve relatively low latency video without so many hoops. The commercial options all tend to have some tie in with WebRTC but the RFC 's associated with it are just a mess [01:44:26 CEST] <nicolas17> BtbN: I think they do write files, the player can get like 30 seconds behind [01:44:48 CEST] <BtbN> nicolas17, I'd assume their server just has an in-memory buffer and serves from there [01:44:53 CEST] <BtbN> there is simply no time to write to files [01:45:16 CEST] <xmichael> why would there not be time to write to files? [01:45:25 CEST] <nicolas17> actually longer, users can create clips from the last minute or two of the live stream [01:45:59 CEST] <BtbN> Because they manage to have streamer to viewer latency of less than one second [01:46:15 CEST] <BtbN> That means the server to browser latency must be closer to <0.2 seconds, which is insane [01:47:31 CEST] <nicolas17> segments are 2s long [01:47:43 CEST] <nicolas17> and yeah now I see they have an "EXT-X-TWITCH-PREFETCH" thing [01:47:49 CEST] <nicolas17> with future segments [01:47:58 CEST] <xmichael> well Skype and the like do it without much effort. What twitch doesn't isn't grown breaking, but what I can't understand is how they use some variation of HLS to do it [01:48:08 CEST] <BtbN> Skype does not use HLS lol [01:48:16 CEST] <BtbN> That's WebRTC and custom protocols [01:48:19 CEST] <nicolas17> stuff like Skype can even be p2p [01:48:45 CEST] <nicolas17> you don't have to deal with CDNs for one-to-one video [01:48:47 CEST] <BtbN> rabb.it also uses WebRTC, with quite impressive results [01:48:55 CEST] <nicolas17> RIP rabb.it [01:58:21 CEST] <xmichael> kast.gg eh [01:59:08 CEST] <xmichael> that has me way of topic.. I just wanted to make a nice little open source solution to provide slightly lower latency hls [01:59:30 CEST] <xmichael> I thought I had it all beat with the idea of making the last file available thanks to chunk encoding... [07:34:47 CEST] <cone-046> ffmpeg 03Limin Wang 07master:75aea52a1051: lavf/hlsenc: refine the get_relative_url function to avoid extra malloc for relation path [07:36:45 CEST] <cone-046> ffmpeg 03Steven Liu 07master:2183def1a54c: avfilter/vf_delogo: support expr in delogo filter [07:42:20 CEST] <cone-046> ffmpeg 03Steven Liu 07master:2a21487b9ea1: avformat/dashdec: start from the root uri when baseURL is start with '/' [10:53:31 CEST] <cone-046> ffmpeg 03Nick Renieris 07master:40abff05d245: lavc/mjpegdec: Decode Huffman-coded lossless JPEGs embedded in DNGs [10:53:32 CEST] <cone-046> ffmpeg 03Nick Renieris 07master:c31c70892978: lavc/tiff: Decode embedded JPEGs in DNG images [10:53:33 CEST] <cone-046> ffmpeg 03Nick Renieris 07master:4c8c4f2d43d5: lavc/tiff: Convert DNGs to sRGB color space [10:53:34 CEST] <cone-046> ffmpeg 03Nick Renieris 07master:6763192cff8f: lavc/tiff: Apply color scaling to uncompressed DNGs [10:53:35 CEST] <cone-046> ffmpeg 03Nick Renieris 07master:03f95403eb11: lavc/jpegtables: Handle multiple mappings to the same value [10:53:36 CEST] <cone-046> ffmpeg 03Nick Renieris 07master:f98a8666de6c: lavc/tiff: Fix edge case with full-length/width tiles [10:53:37 CEST] <cone-046> ffmpeg 03Nick Renieris 07master:33b6752a708f: lavc/tiff: Don't apply strips-related logic to tiled images [10:53:38 CEST] <cone-046> ffmpeg 03Nick Renieris 07master:c510ed2ee8b3: lavc/tiff: Force DNG pixel data endianness on an edge case [10:53:39 CEST] <cone-046> ffmpeg 03Nick Renieris 07master:a75a9e8f64ec: lavc/mjpegdec: Enable decoding of single-component bayer images [10:53:40 CEST] <cone-046> ffmpeg 03Nick Renieris 07master:31acdf4351a1: lavc/tiff: Support decoding of DNGs with single-component JPEGs [10:53:41 CEST] <cone-046> ffmpeg 03Nick Renieris 07master:c44aa7f1761b: lavc/tiff: Decode 10-bit and 14-bit DNG images [10:53:42 CEST] <cone-046> ffmpeg 03Nick Renieris 07master:fcf0ebc4a95e: lavc/mjpegdec: Skip unknown APPx marker on bayer images [10:53:43 CEST] <cone-046> ffmpeg 03Nick Renieris 07master:9280e4b2918c: lavc/tiff: Support DNGs with striped (non-tiled) JPEGs images [10:53:44 CEST] <cone-046> ffmpeg 03Nick Renieris 07master:15776ca18298: lavc/tiff: Default-initialize WhiteLevel DNG tag value [10:53:45 CEST] <cone-046> ffmpeg 03Nick Renieris 07master:63689b16ad72: lavc/tiff: Enable decoding of LinearRaw images [10:53:46 CEST] <cone-046> ffmpeg 03Paul B Mahol 07master:d7529b03bac4: avcodec/tiff: set color_trc, remove sRGB conversion [10:53:47 CEST] <cone-046> ffmpeg 03Paul B Mahol 07master:cae29820777f: avcodec/tiff: rewrite lut handling [10:53:48 CEST] <cone-046> ffmpeg 03Paul B Mahol 07master:30f4464e220b: avfilter/vf_v360: rename fb format to barrel [10:53:49 CEST] <cone-046> ffmpeg 03Paul B Mahol 07master:6037dfa47ad1: avfilter/vf_v360: extend description of eac format [10:53:50 CEST] <cone-046> ffmpeg 03Paul B Mahol 07master:067e6323492b: avfilter/vf_v360: fix some small code style issues [10:53:51 CEST] <cone-046> ffmpeg 03Paul B Mahol 07master:e0fab59624c6: avfilter/vf_v360: set much smaller limit to w/h [12:04:25 CEST] <J_Darnley> What restrictions does h264 put on slice shape? [12:04:59 CEST] <J_Darnley> Isn't there something about them being rectangualr? [12:05:18 CEST] <J_Darnley> Whole rows of macroblocks? [12:08:21 CEST] <jkqxz> In baseline profile they can be absolutely anything with no restrictions (any subset of macroblocks in the frame). [12:08:34 CEST] <thardin> even non-contiguous? [12:08:40 CEST] <jkqxz> Yes. [12:08:48 CEST] <J_Darnley> lol [12:08:52 CEST] <thardin> doesn't being that general waste bits? [12:09:23 CEST] <J_Darnley> I'm sure this is constrained baseline or the usual supersets (main, high, etc) [12:09:29 CEST] <jkqxz> In other profiles they have to be in raster scan order. [12:10:08 CEST] <thardin> http://iphome.hhi.de/wiegand/assets/pdfs/DIC_H264_07.pdf slides 11-12 [12:10:13 CEST] <jkqxz> thardin: It's generally recommended to make your slices vaguely sane, but the standard lets you do stupid stuff if you want. [12:10:31 CEST] <jkqxz> This is probably the main reason why noone supports baseline profile, of course. [12:13:33 CEST] <kierank> J_Darnley: afaik no restrictions [12:14:03 CEST] <kierank> hence why I can only support rectangular slices I think [12:14:20 CEST] <kierank> which I think is fine, it never worked before [12:15:29 CEST] <jkqxz> The DVD/Bluray and I think some broadcast standards require slices to be rectangular. [12:16:43 CEST] <nevcairiel> baseline profile is full of so much insanity [12:24:50 CEST] <J_Darnley> It must be restrictions from other sources that I am thinking of. [12:24:57 CEST] <J_Darnley> not the spec [12:57:17 CEST] <kierank> J_Darnley: I left my notebook at home but I drew out all the combinations that were possible [12:57:28 CEST] <kierank> the only type we are sure to support is rectangular [12:57:39 CEST] <kierank> for any other combination you can have a slice along the row that you don't know has finished yet [13:05:16 CEST] <J_Darnley> sample with 4 bframes [13:05:23 CEST] <J_Darnley> let us see how it decodes [13:07:32 CEST] <J_Darnley> segfault [13:07:33 CEST] <J_Darnley> lol [13:08:14 CEST] <J_Darnley> memcpy in the test program [13:08:38 CEST] <J_Darnley> oh, yes... [13:08:50 CEST] <J_Darnley> I'd better find the cif file and use that [13:08:56 CEST] <J_Darnley> not 4cif [13:12:04 CEST] <J_Darnley> thanks media.xiph.org for sending that y4m as test/plain [13:12:11 CEST] <J_Darnley> *text/plain [13:15:47 CEST] <kierank> oh yeah that's so annoying [13:16:05 CEST] <kierank> I have trolled xipjh [13:17:28 CEST] <J_Darnley> out of 10 frames I got 2 decoded [13:18:38 CEST] <J_Darnley> frame 0 matches (as it should being an iframe [13:18:55 CEST] <J_Darnley> frame 1 is blank green (zero filles I guess) [13:18:57 CEST] <kierank> did you use --slice-threads? [13:19:08 CEST] <J_Darnley> yes [13:19:27 CEST] <kierank> we probably could just warn if it has bframes [13:19:36 CEST] <kierank> and draw_horiz is enabled [13:20:28 CEST] <J_Darnley> frame 2 has misplaced macroblocks and is out of order [13:21:04 CEST] <J_Darnley> was frame 1 for the normal received frame [13:21:53 CEST] <J_Darnley> and the md5 sum was the same [13:27:12 CEST] Action: J_Darnley will check whether normal decoding works [13:32:47 CEST] <kierank> I think non reordered worked [13:33:41 CEST] <J_Darnley> I meant brames with normal frame decoding, just to ensure nothing else broke [13:34:06 CEST] <kierank> Ah [13:34:27 CEST] <J_Darnley> so I just run fate in the end [13:56:30 CEST] <vel0city> durandal_1707: nice, so it was possible (and easy) to auto apply colorspace conversion after all [13:56:57 CEST] <vel0city> durandal_1707: about the LUT changes, why remove the size & offset checks? [13:58:03 CEST] <durandal_1707> not needed now [13:58:32 CEST] <vel0city> oh, right, you're not iterating with count [13:58:36 CEST] <vel0city> cool [13:59:27 CEST] <durandal_1707> and there is bytestream2 used [14:01:45 CEST] <durandal_1707> note that most players ignore color trc from avframes [14:02:03 CEST] <JEEB> "what? it's not gamma?! what is this blasphemy!" [14:02:06 CEST] <durandal_1707> at least ffplay [14:03:06 CEST] <JEEB> you could in theory utilize zscale or something to convert it [14:04:07 CEST] <durandal_1707> swscale is so old and abandoned [14:04:46 CEST] <JEEB> it was made in early 2000s :P also it has the stuff that nobody would probably want to reimplement in alternative libraries (the less common things like palette formats etc) [14:08:23 CEST] <Lynne> I was wanting to write a swscale replacement that worked on hardware frames as well, but kind of gave up on it [14:19:01 CEST] <durandal_1707> why you gave up on it? [14:21:46 CEST] <BtbN> swscale to work on arbitrary hardware frames seems like quite a task, given that there's like half a dozen entirely different kinds [14:22:10 CEST] <nevcairiel> software algorithms in mapped hardware frames would also be icnredibly slow [14:22:23 CEST] <nevcairiel> memory is not made equal afterall [14:23:07 CEST] <BtbN> I wonder if for the pad/crop/transpose CUDA filters it would make sense to put them into the scale file. [14:23:34 CEST] <BtbN> Cause otherwise, if each gets its own entire vf_*_cuda.c file, it will duplicate massive amounts of code [14:25:13 CEST] <durandal_1707> file != filter [14:25:35 CEST] <BtbN> Yes, it's more of a stylistic question really [14:25:47 CEST] <BtbN> Potentially one could also write a CUDA-filter-helper, that abstracts away most of the boilerplate [14:27:30 CEST] <Lynne> it would only work on opencl and vulkan frames, because correctness would be very important [14:27:48 CEST] <Lynne> and it wouldn't have been fast either as I'd do everything in XYZ colorspace [14:27:51 CEST] <BtbN> Are there even "OpenCL frames"? [14:28:28 CEST] <Lynne> yeah? they're pretty normal, images with some memory bound to them [14:28:47 CEST] <BtbN> I remember the OpenCL filter all doing upload->proc->download [14:38:47 CEST] <Lynne> that must be the old opencl filters you're talking about, the ocl hwcontext does uploading/downloading/mapping, its normal [14:48:26 CEST] <Lynne> the cuda->vulkan interop could work though, if the cuda context allocates all memory with vulkan and then stores a ref somewhere so it can map it back [14:49:13 CEST] <Lynne> seems to be how nvidia expects you to do it with all interops, just import into cuda and then rely on memory aliasing [14:49:19 CEST] <BtbN> I don't think there is any Vulken<->CUDA interop as of yet [14:49:29 CEST] <BtbN> *a [14:49:42 CEST] <BtbN> Also, CUDA/NVENC has pretty specific pixel format and alignment requirements [14:53:42 CEST] <Lynne> there is, you can import vulkan into cuda, just not the other way around [14:54:35 CEST] <Lynne> mpv uses it [14:56:56 CEST] <BtbN> For decoding that is sadly not useful [14:57:08 CEST] <BtbN> but if you software-decode and then hw-upload to a vulken frame, you could map those to CUDA [14:57:29 CEST] <BtbN> For CUDA to Vulkan you would be forced to copy [14:57:59 CEST] <BtbN> We might be able to repurpose the strange dedicated hwupload_cuda to be able to take Vulken frames as input [14:59:03 CEST] <BtbN> It's impossible to decode straight to a Vulken frame, since nvdec/cuvid just gives you a CUdevptr that's mapped to the frame [15:00:34 CEST] <Lynne> oic, I thought you allocated a cuda frame and gave it that to decode into [15:01:03 CEST] <BtbN> A on-gpu memcpy is pretty cheap though, and doing it once isn't a big issue [15:01:37 CEST] <BtbN> The legacy cuviddec decoder actually does just that anyway, either to a frame in ram or another CUDA frame [15:02:00 CEST] <BtbN> But the actual nvdec hwaccel constructs an AVFrame out of the mapped NVDEC output [15:04:09 CEST] <Lynne> how would you do a gpu memcpy with vulkan and cuda though? [15:04:56 CEST] <BtbN> You do whatever you need to do to get a CUdevptr that maps to a Vulkan frame, and then call memcpy? [15:05:17 CEST] <Lynne> oh, right [15:05:30 CEST] <BtbN> or cuMemcpy2D rather [15:56:06 CEST] <BtbN> Hm, one interesting thing is... a potential CUDA transpose filter could operate in-place with no copy [15:56:39 CEST] <BtbN> But the benefits of doing that seem not worth it, given the issues that would create with the entire rest of libavfilter [15:58:24 CEST] <Lynne> does it? I've tested in-place filtering, I know it worked without issues [16:01:58 CEST] <J_Darnley> Does ffmpeg have a typical style for multi-line comments which aren't doxy ones? [16:10:06 CEST] <JEEB> seems to differ between even functions in a single module [16:13:10 CEST] <J_Darnley> Okay, I'll just do something nest and compact here [16:13:16 CEST] <J_Darnley> *neat [16:14:36 CEST] <JEEB> (basically just look at the mix of /* */ and multi-line // in movenc.c for example :) [16:19:39 CEST] <cone-083> ffmpeg 03Paul B Mahol 07master:6b0903075694: avfilter/vf_delogo: unbreak fate [16:41:05 CEST] <BtbN> You'd end up with a frame where its dimensions potentially mismatch those of its hwframes_ctx. I don't think that's a good idea to do. [16:48:37 CEST] <cone-083> ffmpeg 03Paul B Mahol 07master:fbaa395917e1: avfilter/vf_v360: remove not needed items from ThreadData [16:56:04 CEST] <Lynne> BtbN: its fine as long as they dont change then, right? [16:56:18 CEST] <Lynne> the speed gains are significant [17:10:47 CEST] <durandal_1707> anybody wants to write SIMD assembly for me? [17:32:50 CEST] <kierank> durandal_1707: no, learn yourself [17:38:32 CEST] <Lynne> durandal_1707: if its interesting [17:48:15 CEST] <J_Darnley> durandal_1707: for what do you want simd this time? the 360 filter? [17:50:38 CEST] <durandal_1707> bilinear interpolation remap for slice [17:51:55 CEST] <durandal_1707> i wonder whats max speedup one could expect [17:52:53 CEST] <durandal_1707> i guess nearest function cant be made faster [17:53:31 CEST] <durandal_1707> yes for v360 filter [18:03:18 CEST] <Lynne> not interested. close to having the fastest ever avgblur shader written for reals this time once I refactor more [18:03:30 CEST] <durandal_1707> lol [18:07:12 CEST] <BtbN> Lynne, nvenv for example get the dimension information from the hwframes ctx [18:07:16 CEST] <BtbN> *nvenc [18:07:23 CEST] <philipl> BtbN: yeah. You'd write a filter that takes the cuda frame and gpu copies it to a vulkan frame using the interop as a kind of hwupload. The equivalent hwdownload would be easier, as you could actually zero-copy it [18:08:49 CEST] <Lynne> anyone wants to try writing that? [18:09:04 CEST] <philipl> I could try. I wrote interop for mpv. [18:09:25 CEST] <philipl> Doing it properly requires a lot of annoying semaphore management though. [18:10:13 CEST] <cone-083> ffmpeg 03Michael Niedermayer 07master:daf92cc074c5: avcodec/vp3: Check for end of input in 2 places of vp4_unpack_macroblocks() [18:10:14 CEST] <cone-083> ffmpeg 03Michael Niedermayer 07master:b54031a6e93d: avcodec/bgmc: Check input space in ff_bgmc_decode_init() [18:10:37 CEST] <philipl> Lynne: Do you have a git repo somewhere with your changes, or just those patches you linked to yesterday? [18:10:56 CEST] <BtbN> ffmpeg would first need Vulkan hwcontext support before it even makes sense [18:11:11 CEST] <philipl> BtbN: that's why it would have to go on top of Lynne's patches [18:11:36 CEST] <Lynne> just a patch, https://0x0.st/z4IJ.patch [18:11:54 CEST] <BtbN> Is that based on Atomnukers old patches? [18:11:58 CEST] <Lynne> you'll need to add the download to vulkan_map_to, and the upload (to cuda) to vulkan_map_from [18:12:02 CEST] <Lynne> yes [18:12:23 CEST] <Lynne> oh, and it would be nice to add a derive_device case for cuda [18:12:32 CEST] <philipl> Definitely needs derive_device [18:13:13 CEST] <philipl> Lynne: what's the use-case for the non-vaapi drm interop? I don't know what other interesting drm source/sinks are. [18:13:38 CEST] <Lynne> kmsgrab [18:13:52 CEST] <philipl> ah [18:14:03 CEST] <Lynne> for quick and easy derive_device you can just set the vendor_id in the search stuct to nvidia [18:14:29 CEST] <philipl> You're supposed to do UUID matching, which is what I put in mpv. [18:14:44 CEST] <Lynne> is it identical between vulkan and cuda? [18:14:59 CEST] <philipl> Yes. It's the only thing that nvidia guarantee [18:15:27 CEST] <philipl> I'll look at this in the next few days. [18:15:49 CEST] <philipl> Fun isn't quite the right work, but I can't help myself. [18:20:08 CEST] <Lynne> btw how do you guarantee that the gpu memcpy has finished? [18:20:16 CEST] <Lynne> for cuda->vulkan [18:22:04 CEST] <philipl> that is the semaphores. [18:22:19 CEST] <philipl> you import a semaphore from vulkan and signal it. [18:22:44 CEST] <philipl> so many lines of code. [18:23:09 CEST] <Lynne> so imported semaphores are signalled correctly on both apis? nice [18:23:25 CEST] <philipl> yes. and you can signal in both directions. [18:24:14 CEST] <philipl> I needed all of that to make the mpv interop work as the vulkan images are reused. so have to sync write and then make sure the read completes before writing the next frame. [18:26:59 CEST] <Lynne> at least nvidia care about sync, drm does not expose any semaphores used internally, and nor does vaapi [18:27:33 CEST] <durandal_1707> kierank: do not be so mean [18:27:41 CEST] <kierank> durandal_1707: lol [18:36:18 CEST] <philipl> Lynne: I know you wrote all that code, but it might not be crazy to use libplacebo for the hwcontext. It wraps a bunch of the vulkan in a useful way. [18:37:03 CEST] <philipl> haasn: paging hassn. [18:43:27 CEST] <Lynne> that's just not happening. [18:46:04 CEST] <durandal_1707> why? [18:48:55 CEST] <Lynne> durandal_1707: many reasons. no one packages it, the abstractions are mostly rendering-side biased, probably slower, needs more code written for interops [18:52:31 CEST] <durandal_1707> where are jamrial and mkver when you need them? [18:53:17 CEST] <jamrial> ? [18:53:56 CEST] <durandal_1707> see mkv bug? [18:54:25 CEST] <durandal_1707> apparently slow seeking [19:04:34 CEST] <nevcairiel> its probably the same bug that was already reported a few days ago [19:08:34 CEST] <jamrial> unlikely, the commit they tested is after the latest fix [19:08:39 CEST] <cone-083> ffmpeg 03Andrey Semashev 07master:7ea2710ec4d1: configure: Update libmysofa check with a new symbol. [19:28:12 CEST] <durandal_1707> i can not reproduce this [19:29:07 CEST] <cone-083> ffmpeg 03Pavel Koshevoy 07master:6b57a294a328: lavc/v4l2_m2m: don't close the file descriptor we don't own [19:31:44 CEST] <jamrial> i get a delay of a couple seconds, but nowhere near the 20+ seconds mentioned in the ticket [19:39:30 CEST] <jamrial> there are like 87k cuepoints in this output [19:45:45 CEST] <durandal_1707> i get no delay at all [20:28:40 CEST] <Lynne> avgblur_opencl = 480fps, avgblur_vulkan = 491 fps, I now for reals have the fastest ever avgblur shader, and I can make it faster still [20:29:50 CEST] <Lynne> first I need to find a heisenbug where a third allocation makes descriptor templates explode though [20:30:13 CEST] <JEEB> :) [20:30:16 CEST] <JEEB> 'grats [20:31:30 CEST] <Lynne> meh, I have the nvidia machine up, I'll try my luck at the interop, it is never not time to fast [20:41:47 CEST] <philipl> Lynne: check out the mpv code if you want to chase down the cuda interop. [20:42:45 CEST] <philipl> One thing I'll predict. The mapping API is expensive - they really want you to re-use images. So you'll want to map frames from the pool and keep them mapped and re-use them as much as possible. [21:04:25 CEST] <durandal_1707> whats point giving giberish text into fuzz fixing commits if such text is not freely available to wider audience [21:24:45 CEST] <Lynne> can I get a CUdevice from a CUcontext or CUstream? [21:25:26 CEST] <philipl> Lynne: I don't think so. Never tried. [21:26:12 CEST] <philipl> No, you can. [21:26:14 CEST] <philipl> https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__CTX.html#group__C… [21:27:31 CEST] <philipl> You'd need to add the function prototype to our headers. [21:28:06 CEST] <Lynne> cuCtxGetDevice? [21:28:33 CEST] <BtbN> Why would you need that though? We always carry the device around, don't we? [21:28:42 CEST] <Lynne> cuCtxGetDevice(*device) so the context is a global state? [21:28:51 CEST] <nevcairiel> its thread-local state [21:29:02 CEST] <Lynne> yeah, I can add CUdevice to libavutil/hwcontext_cuda_internal.h [21:29:17 CEST] <BtbN> Is it really not in there somewhere already? [21:29:53 CEST] <BtbN> Doesn't look like it, no. What do you need it for? [21:31:52 CEST] <Lynne> cuDeviceGetUuid [21:32:31 CEST] <durandal_1707> if nobody gonna help me do SIMD i will do it, so you all can be disapointed by not helping [21:33:18 CEST] <kierank> durandal_1707: just learn [21:33:22 CEST] <kierank> I can teach [21:33:25 CEST] <kierank> I taught atomnuker [21:33:45 CEST] <durandal_1707> you cant ride bike? [21:34:07 CEST] <kierank> eh? [21:35:30 CEST] <durandal_1707> i learned SIMD already, but i need much more experienced SIMD developer to show me little tricks of trade [21:37:01 CEST] <kierank> ask Gramner [21:37:06 CEST] <kierank> write code, ask Gramner to help improve [21:38:12 CEST] <cone-083> ffmpeg 03Michael Niedermayer 07master:64ac8a6e697e: avcodec/apedec: Fix integer overflow in filter_fast_3320() [21:38:14 CEST] <cone-083> ffmpeg 03Michael Niedermayer 07master:8ae5d2cbb254: vcodec/apedec: Fix integer overflow in filter_3800() [21:38:14 CEST] <cone-083> ffmpeg 03Michael Niedermayer 07master:361b3c873ee0: avcodec/pngdec: Optimize has_trns code [21:38:15 CEST] <cone-083> ffmpeg 03Michael Niedermayer 07master:0ee886988e75: avcodec/ralf: fix undefined shift [21:38:16 CEST] <cone-083> ffmpeg 03Michael Niedermayer 07master:4778407ab3b5: avcodec/ralf: fix undefined shift in extend_code() [21:38:19 CEST] <durandal_1707> he is dav1d busy [21:46:08 CEST] <tmm1> jkqxz: re: dummy drm device, for v4l2 the decoder support both drm and software formats, so using alloc/init to force a dummy drm device like rkmpp doesn't work. there's also v4l2 filters and encoders which would ideally share one global hwcontext instead of each creating their own dummy [22:00:43 CEST] <cone-083> ffmpeg 03Marton Balint 07master:73e0035812cc: docs/formats: fix max_interleave_delta default [22:00:44 CEST] <cone-083> ffmpeg 03Marton Balint 07master:f4eb7d84a7c2: avformat/mpegtsenc: fix flushing of audio packets [22:01:38 CEST] <Lynne> do I need to call cuCtxPushCurrent/Pop before/after the cuMemcpy2DAsync? [22:14:21 CEST] <philipl> Lynne: yes. [22:22:36 CEST] <cone-083> ffmpeg 03Marton Balint 07release/4.2:3a17fe2bdd57: avformat/mpegts: fix teletext PTS when selecting teletext streams only [22:22:37 CEST] <cone-083> ffmpeg 03Marton Balint 07release/4.2:b4e910370992: avformat/avidec: add support for recognizing HEVC fourcc when demuxing [22:33:04 CEST] <tmm1> jkqxz: so for example you can decode without hwaccel to get pix_fmt=nv12, or with hwaccel for pix_fmt=drm_prime: https://paste.ubuntu.com/p/268XmYcMF9/. if you think it would be cleaner to add a new v4l2 hwaccel i can do that instead, but it doesn't seem like there's a standard api to map/hwupload frames since each implementation uses its own gpu memory allocator apis [22:48:17 CEST] <Lynne> tmm1: own gpu allocation apis? as in proprietary ones? [22:52:47 CEST] <cone-083> ffmpeg 03Aman Gupta 07master:b022d9ba288a: avcodec/omx: fix xFramerate calculation [22:53:34 CEST] <cone-083> ffmpeg 03Aman Gupta 07release/4.2:0f8e2a0b8644: avcodec/omx: fix xFramerate calculation [22:56:07 CEST] <tmm1> Lynne: i believe so, for instance on android there's a new ION allocator that standardizes nvidia/nvmap ti/cmem qualcomm/pmem [22:57:00 CEST] <tmm1> on rpi you need the CMA allocator [22:57:42 CEST] <tmm1> my understanding of this stuff is still rudimentary, but it seems like there is no one way to get gpu memory that you can copy the frame into [23:08:38 CEST] <Lynne> philipl: I need the WidthInBytes stride to do a memcpy, and there's no way to get it in vulkan [23:09:14 CEST] <Lynne> vkGetImageSubresourceLayout only works for linear images and the tiling must be optimal to import into cuda [23:11:05 CEST] <Lynne> er, srcPitch and dstPitch [23:12:00 CEST] <cone-083> ffmpeg 03Andriy Gelman 07master:ef43a4d6b38d: avformat: Add ZeroMQ as a protocol [23:21:35 CEST] <xmichael> https://developer.apple.com/videos/play/wwdc2019/502/ [23:21:50 CEST] <xmichael> https://developer.apple.com/documentation/http_live_streaming/protocol_exte… [23:22:42 CEST] <philipl> Lynne: so, you are doing a memcpy to a cuda array. That means you have no dstPitch, and the width in bytes is the width of the actual image (srcPitch captures the actual stride) [23:23:40 CEST] <philipl> https://github.com/mpv-player/mpv/blob/master/video/out/hwdec/hwdec_cuda.c#… [23:26:28 CEST] <philipl> and just generally: https://github.com/mpv-player/mpv/blob/master/video/out/hwdec/hwdec_cuda_vk… [23:32:02 CEST] <Lynne> philipl: its not a cuda array though, its a standard CUdeviceptr I get from cuExternalMemoryGetMappedBuffer [23:32:32 CEST] <Lynne> couldn't I just do a 1D memcpy? [00:00:00 CEST] --- Tue Sep 3 2019

1 0

ffmpeg.log.20190902
by burek 03 Sep '19

03 Sep '19

[00:00:04 CEST] <JEEB> Xogium: yea that's the problem. you get the index and stuff every time [00:00:26 CEST] <JEEB> so the parser is expecting [header][data][data]... [00:00:33 CEST] <Xogium> hmm [00:00:39 CEST] <JEEB> and you're giving [header][data][data][header][data][data] [00:00:55 CEST] <JEEB> that's where the "error parsing the packet header" comes [00:01:02 CEST] <Xogium> right [00:01:07 CEST] <Xogium> now I understand [00:01:12 CEST] <klaxa> i think with mp3 that worked reasonably well, but also did not change metadata (i.e. playtime was displayed incorrectly) [00:01:15 CEST] <JEEB> since it's expecting an opus packet header but suddenly there's something ?!?! [00:01:25 CEST] <nicolas17> ogg has a file header apart from the per-page header? [00:01:32 CEST] <Xogium> so how are we supposed to make proper chained opus ? [00:03:02 CEST] <Xogium> the new ffmpeg encoder in liquidsoap has this exact same problem [00:03:54 CEST] <JEEB> nicolas17: I have no idea; but something is badly confusing the OGG+opus reader [00:04:03 CEST] <JEEB> either it is some OGG thing or an opus thing [00:04:09 CEST] <JEEB> (or the reader is buggy) [00:04:24 CEST] <Xogium> JEEB: should I try with ogg itself ? [00:05:57 CEST] <klaxa> why couldn't we get a better standard container for opus? D: [00:08:55 CEST] <Xogium> hmm [00:09:13 CEST] <Xogium> I've converted the same music from flac to ogg, let's see [00:09:13 CEST] <Lynne> for the same reason it also got the awful vorbis channel mapping syntax and a wasteful 1-2 byte header [00:09:43 CEST] <nicolas17> I was just reading this about ogg being crap :P https://hardwarebug.org/2010/03/03/ogg-objections/ [00:11:59 CEST] <JEEB> Xogium: anyways, try just remuxing with the opus extension and see how parsers like that [00:13:03 CEST] <Xogium> JEEB: how exactly should I do this ? I'm not good at ffmpeg just yet lol [00:13:41 CEST] <Xogium> okay so our mister in .ogg also says invalid audio pts, but doesn't complain about failing to parse header lol [00:14:19 CEST] <JEEB> Xogium: I did note the full command a bit up there [00:14:21 CEST] <JEEB> the -c copy one [00:14:25 CEST] <JEEB> if you scroll in the chat log [00:15:46 CEST] <Xogium> oh sorry I must have missed [00:18:10 CEST] <Xogium> I don't understand how this is supposed to work, this would grab an opus file and copy it to another opus file ? But that wouldn't concatenate 2 opus files would it [00:19:05 CEST] <Xogium> also trying to think how we could use this in liquidsoap [00:44:10 CEST] <Xogium> JEEB: anyway I just thought of something& You'd think that the opus guys would have found a way to detect this sort of issue in their stream if you use opusinfo& But no, they are totally normal streams, which confused me even more because when I first asked for help today I honestly thing that ffmpeg was at fault, since opusinfo claimed my file was perfectly alright [00:44:17 CEST] <Xogium> *honestly thought [00:44:22 CEST] <Xogium> sorry getting tired hehe [04:37:55 CEST] <roasted> I'm trying to figure out how to use ffmpeg to convert videos to use the cineform codec. The lack of examples (and some other forum posts) seem to suggest it's not possible, that ffmpeg can input cineform but cannot output cineform. Is this accurate? [04:38:39 CEST] <nicolas17> that's correct [04:38:43 CEST] <nicolas17> check ffmpeg -codecs [04:38:56 CEST] <nicolas17> D.V.L. cfhd Cineform HD [04:39:03 CEST] <nicolas17> D..... = Decoding supported [04:39:05 CEST] <nicolas17> .E.... = Encoding supported [04:51:15 CEST] <roasted> nicolas17: I see. Thanks for the insight. Might look into DNxHD or something along those lines then. [04:51:30 CEST] <roasted> (looking to re-render different clips for video editing shot on an iphone 8) [05:48:06 CEST] <Hello71> what's wrong with x264 [05:48:48 CEST] <nicolas17> cineform seems to be intra-only? [08:50:47 CEST] <JAK-Zero> hey, I'm trying to remove all of the parts of a video where nothing happens, basically anything that doesn't contain motion. [08:50:57 CEST] <JAK-Zero> `-vf mpdecimate,setpts=N/FRAME_RATE/TB` seems to work, as the output video just plays the parts from the original video with motion, but the total video length is the same. The audio is also desynced, I think it's actually playing the whole audio track. [08:51:05 CEST] <JAK-Zero> Is it possible to make it so that the audio from the motionless sections is removed as well? [08:57:16 CEST] <JAK-Zero> yes, it seems like the audio caused the extra playback length, removing the audio with `-an` shortens it to just the sections with motion [10:44:14 CEST] <cpplearner> Guys, is there any case where `time_base`'s `nom`(=nominator) is not 1? I want to just divide pts/dts by denominator to convert it into seconds. [10:44:56 CEST] <cpplearner> I mean `numerator`. [10:46:29 CEST] <JEEB> cpplearner: I would just utilize av_rescale_xxx for it [10:47:18 CEST] <JEEB> although I think there was one that took timestamp + time base and gave you the seconds [10:47:42 CEST] <cpplearner> Hmm, okay. I'll look into those API. Thanks! =) [10:49:58 CEST] <JEEB> cpplearner: apparently things do timestamp * av_q2d(time_base) [10:50:05 CEST] <JEEB> which ends up being a double [10:50:18 CEST] <JEEB> so you get something like 1.3435252 out of it [10:50:50 CEST] <JEEB> there might be better functions, but that's what's being used @ ffprobe :) [11:00:54 CEST] <JAK-Zero> could it be possible to get timecodes from mpdecimate? That way I could get the audio from the active parts and add it back to the video [11:02:14 CEST] <JAK-Zero> then again, if I had the timecodes, I could just splice together the active parts from the source video [12:05:53 CEST] <c_14> JAK-Zero: try the freezedetect filter maybe? [12:07:23 CEST] <JAK-Zero> I'll give that a shot, thanks [12:08:25 CEST] <kepstin> cpplearner: an example is the framerates used in ntsc territories for video, where the nominal timebase is usually something like 1001/30000 [13:31:06 CEST] <Xogium> JEEB: hi :) it seems that it is ffmpeg that is at fault here, for the opus stream. Of course I'm no expert, but from what I know, it is perfectly normal to see [header][data][data][EOS][header]... in a stream. It's chained, and it needs multiple headers, one at each new song, otherwise how do you update metadata ? It's not like in mp3 where you can embed that inside of the stream itself [13:31:50 CEST] <JEEB> Xogium: if that is valid according to OGG then the demuxer needs to be updated. as I noted that was one of the possibilities [13:31:55 CEST] <Xogium> maybe ffmpeg's parser just doesn't react to the EOS ? [13:31:58 CEST] <JEEB> I just have no idea about how OGG works :P [13:32:09 CEST] <JEEB> you could try making an issue on trac with a sample [13:32:20 CEST] <JEEB> with possible quotes/links to references [13:32:53 CEST] <Xogium> JEEB: aye. From what I've gathered this is how chained opus and chained ogg/vorbis work [13:33:52 CEST] <Xogium> so I think that 2 things could happen here, either ffmpeg's parser doesn't notice the EOS and so it hits the headers of the next song and is like huh ? Or the parser is simply not made to handle this [13:34:51 CEST] <Xogium> fixing this would honestly help a ton with opus on webradio, soooo many things rely on ffmpeg [13:37:37 CEST] <Xogium> I can definitely open an issue and provide a sample [13:39:46 CEST] <Xogium> I just need good quotes and etc, there might be some rfc as well& [14:31:30 CEST] <Processus42> Hello there. I'm seeking for help regarding the bn argument of the afftdn filter. I'd like to know what are the "15 bands" the filter documentation is talking about, and what values it expects for them. [14:53:04 CEST] <durandal_1707> Processus42: its numbers you got when you enable noise scanning [14:55:41 CEST] <durandal_1707> sample_noise start [14:55:58 CEST] <durandal_1707> sample_noise stop [14:56:28 CEST] <durandal_1707> this are commands and arguments [14:56:45 CEST] <durandal_1707> you can set them with asendcmd [15:08:28 CEST] <Processus42> durandal_1707: Thanks, I'll give it a try [15:10:18 CEST] <Xogium> durandal_1707, JEEB: for what it's worth, I've just tested with opusenc to make sure that it wasn't something bad with my files or bogus in any way. Same problem so I really think ffmpeg is wrong here. The rfc for ogg encapsulated opus stream seems to show this fact too, it is okay to put headers many times in a stream as long as there's EOS set appropriately between each of the streams [15:11:02 CEST] <durandal_1707> open bug report [15:11:09 CEST] <Xogium> durandal_1707: aye I will [17:49:55 CEST] <Processus42> durandal_1707: Thanks, this is what I needed [00:00:00 CEST] --- Tue Sep 3 2019

1 0

ffmpeg-devel.log.20190901
by burek 02 Sep '19

02 Sep '19

[03:00:35 CEST] <jamrial> Chagall: ping the patches on the ml. devs in general don't look at patchwork [03:28:07 CEST] <Chagall> jamrial: I did it once and got no answer, but will try one more time... [13:55:55 CEST] <thardin> is there a compile-time constant for maximum Y res? [13:58:57 CEST] <thardin> I only see INT_MAX, which seems excessive [14:00:28 CEST] <thardin> nm, UINT16_MAX works well enough in this case [14:16:41 CEST] <vel0city> durandal_1707: Maybe because of the post processing it does, or just the the colorspace transformation [15:06:06 CEST] <kierank> thardin: we need to be able to handle Hubble telescope resolution [15:06:41 CEST] <JEEB> that reference reminds me of https://www.youtube.com/watch?v=JRLVFn9z0Gc [15:08:00 CEST] <thardin> kierank: I don't think even the hubble outputs that large frames [15:08:37 CEST] <kierank> JEEB: I am slightly obsessed by that photo [15:08:44 CEST] <kierank> Having seen an nrol launch [15:08:51 CEST] <thardin> 65536x65536 isn't entirely outside the range of possibilities [15:09:22 CEST] <thardin> not in cinepak however, which caps at 65535x65535 [15:09:53 CEST] <thardin> which means I save on a dynamic allocation [15:10:50 CEST] <JEEB> kierank: fun :) [15:15:56 CEST] <thardin> there we go, header and strip parsing refactored [15:16:27 CEST] <thardin> michaelni_: I've made cinepak.c sanity check the size of each strip (which depends on mode) [15:17:03 CEST] <thardin> and this parsing is separated from the actual decoding, so it should be nice and fast [17:13:12 CEST] <Lynne> any way to reset some hwcontext-specific avframe state when a frame is being resued? [17:18:51 CEST] <Lynne> else I'm left with a stale semaphore from the last frame that has no way to be signalled [21:24:21 CEST] <Lynne> if anyone wants to test 5000 lines of vulkan apply https://0x0.st/z4IJ.patch and https://0x0.st/z4Iy.patch [21:25:13 CEST] <Lynne> will work on amd, does have vaapi/drm interop, and has the fastest avgblur shader ever writter [21:25:43 CEST] <JEEB> nice [21:45:08 CEST] <durandal_1707> Lynne: what is fps of shader? [21:48:21 CEST] <durandal_1707> compared to cpu one [21:59:01 CEST] <Lynne> durandal_1707: its not a fair comparison, but at 9x9 it gets 266 fps on CPU, ~110 on a 960m with just an upload, no download, 35 fps on an intel with mapping from vaapi, no download [22:05:50 CEST] <durandal_1707> Lynne: what resolution? [22:06:22 CEST] <Lynne> 1280x720, 8 threads for cpu [22:07:48 CEST] <durandal_1707> if you cant make stupid avgblur faster than cpu than all is lost [22:09:17 CEST] <Lynne> yeah, nevermind about the fastest avgblur shader ever written, opencl gets 500 fps on the 960m, I still need to optimize it [22:09:21 CEST] <durandal_1707> or you use crappy gpu [22:10:22 CEST] <Lynne> such a shame, the way it handled overlap with so little branches and 2*radius lookups max per instance was clever [22:14:31 CEST] <BradleyS> nice work :) [22:15:01 CEST] Action: BradleyS throws something at durandal_1707 [22:16:48 CEST] Action: durandal_1707 evades BradleyS hit [22:18:22 CEST] <BradleyS> i underestimated your dexterity stat [00:00:00 CEST] --- Mon Sep 2 2019

1 0

ffmpeg.log.20190901
by burek 02 Sep '19

02 Sep '19

[00:06:02 CEST] <pink_mist> -shortest would only cut off the end of the one that's longer [00:06:07 CEST] <pink_mist> wouldn't help with syncing at all [00:06:29 CEST] <pink_mist> (and I have no idea how you'd go about syncing, or I'd give more useful help) [00:07:00 CEST] <FooNess> You may have to use a specialized audio editor on the audio stream. [00:07:03 CEST] <FooNess> Like Audacity. [00:07:11 CEST] <furq> setpts or atempo [00:07:21 CEST] <FooNess> Maybe slow it down/speed it up so that its length matches the video? I dunno. [12:08:40 CEST] <rooth> pink_mist, FooNess, furq: Thank you for your pointers! [12:38:07 CEST] <JEEB> rooth: you might want to try out -advanced_editlist 0 [12:38:14 CEST] <JEEB> if your input is mp4 [12:38:18 CEST] <JEEB> put that before input [12:38:43 CEST] <JEEB> that disables the wonderful advanced edit list implementation made by GOOG [12:39:16 CEST] <JEEB> I'm not sure if it would cause gradual a/v desync, but it's always worth a try :P [17:01:43 CEST] <hseg> Hi. The HLS demuxer warns it cannot support subtitles, but I can't find documentation on this online. [17:04:47 CEST] <hseg> Examplpe: Following the instructions on https://github.com/ytdl-org/youtube-dl/issues/16094#issuecomment-504864056 to get the m3u8 url of RWBY V6E1, I get the following output when ffprobing the url: http://ix.io/1TZs [17:05:24 CEST] <hseg> Note in particular the lines matching "Can't support the subtitle" [17:28:34 CEST] <JEEB> hseg: yes, the HLS meta demuxer doesn't support subtitles [17:28:57 CEST] <JEEB> it's not impossible to support it but I think the timestamp mapping etc was partially what kept people from doing it [18:08:47 CEST] <hseg> K. Too bad [18:09:09 CEST] <JEEB> watches are always pelcome [18:09:16 CEST] <hseg> If it itches enough, I'll give it a shot [18:09:39 CEST] <hseg> What's the issue with timestamp mapping, for future reference? [18:09:59 CEST] <JEEB> it has a mapping of a point in the time to a specific MPEG-TS timestamp [18:10:18 CEST] <JEEB> which somehow expects you to have access to the MPEG-TS timestamps on the layer that handles your subtitles? [18:10:21 CEST] <JEEB> it's weird [18:10:37 CEST] <JEEB> wonder how many things actually try to sync that to MPEG-TS timestamps instead of just taking them as timestamps in 1/9000 [18:10:42 CEST] <JEEB> *90000 [18:10:51 CEST] <JEEB> you can see them in the beginning of webvtt samples [18:12:03 CEST] <hseg> Ah. So the timestamp is by mpeg-ts chunk, which might be variable-length, but in practice is uniform enough that a fixed step might be enough? [18:13:14 CEST] <JEEB> hseg: usually it's used to note that timestamp 0 of this vtt segment is MPEG-TS timestamp XYZ [18:13:19 CEST] <JEEB> and as if you're supposed to sync it [18:13:23 CEST] <JEEB> I should check if it's mentioned in the spec [18:14:46 CEST] <JEEB> https://tools.ietf.org/html/rfc8216#section-3.5 [18:14:55 CEST] <JEEB> yea the X-TIMESTAMP-MAP part [18:15:37 CEST] <JEEB> I guess you could just attempt to interpret that within the vtt stream [18:15:43 CEST] <JEEB> instead of going to the MPEG-TS one [18:28:17 CEST] Action: DHE wants to try out fmp4-based HLS. mpegts has way too much overhead. [18:31:44 CEST] <JEEB> yea if the clients support it, it's way better as an alternative IMHO [18:35:45 CEST] <Xogium> hi people. I was wondering, are there plans to improve chained opus/chained ogg support ? Or should players consider such warnings as 'invalid audio pts' and 'failed to parse packet header' and 'failed to decode audio' as non-fatal ? I'm asking because I have mpv here that keeps playing the stream but prints that sort of stuff at every new song, and audacious that treats this as fatal and ends up playback [18:35:51 CEST] <Xogium> right then and there [18:37:19 CEST] <Xogium> so don't know who's acting right and who's being a bit too harsh/tolerating here [18:39:59 CEST] <Xogium> ffplay complains about packet headers and invalid pts too, but treats these as warning I suppose, since it keeps playing back audio [19:25:24 CEST] <Lynne> Xogium: there's a patch, but link a stream or file [19:26:06 CEST] <Lynne> there were only 2 existing sources of chained opus, one test file and one buggy icecast stream that looked nothing like the test file [19:27:51 CEST] <Xogium> Lynne: sure, sec [19:32:54 CEST] <durandal_1707> Lynne: how that stream was buggy? [19:33:57 CEST] <Xogium> Lynne: here's an opus file that I created by doing cat on multiple files and sending the result in a single opus file https://plik.root.gg/file/FLvH311DzZz0ulyu/aLXuGGeIZjwnXmYp/come_over.opus [19:34:04 CEST] <Xogium> they were all encoded with ffmpeg [19:34:53 CEST] <Xogium> and here is a stream fragment from icecast, with ffmpeg encoding in realtime: https://plik.root.gg/file/xPQT1w7u9lCa7daW/z0O5hahAskDrAgYa/stream.opus [19:36:30 CEST] <durandal_1707> not sure ffmpeg encoders is correct and doing only cat is ok [19:36:32 CEST] <Lynne> durandal_1707: it was missing extradata packets on switches [19:37:11 CEST] <Xogium> durandal_1707: what do you mean exactly ? [19:37:31 CEST] <Xogium> sorry have trouble there, english isn't my native language :) [19:39:57 CEST] <Xogium> if cat isn't the proper way to create chained opus files, then how should I try this ? [19:40:29 CEST] <Xogium> still& Both using cat and encoding for icecast results in the same behavior for here [19:41:22 CEST] <durandal_1707> how was second sample created? [19:42:22 CEST] <Xogium> durandal_1707: for now I kept it simple, used ffmpeg to encode in opus and used oggfwd to send to icecast [19:45:08 CEST] <Xogium> the new ffmpeg encoder that the liquidsoap project has been working on also has the same behavior, down to what opusinfo says on a stream sample [19:45:23 CEST] <cpplearner> Guys, is there any audio counterpart of I-frame in video? I mean, can I safely decode a specific audio packet without worrying about key-frame? [19:46:10 CEST] <cpplearner> So, I'm now saving key-frame timestamps of a video for later use. But, I'm not sure I have to worry about the audio. [19:47:39 CEST] <JEEB> cpplearner: so in general audio formats are intra only, but for example AC-4 has inter frames. in general you need to care about audio frame lengths and such. [19:48:53 CEST] <cpplearner> Oh, that's good. =) Thanks for the info. [19:49:28 CEST] <Xogium> so, are my samples bugged or ? [19:50:05 CEST] <Xogium> I mean does ffmpeg has a real reason to complain here or it is just meant as harmless warnings ? [20:01:44 CEST] <durandal_1707> Xogium: give file with better quality and with no silence in transition [20:05:22 CEST] <Xogium> durandal_1707: oh boy that's gonna be complicated for silence& Unless ffmpeg has a tool for silence removal ? [20:06:13 CEST] <durandal_1707> Xogium: all your songs have silence in transition? [20:06:28 CEST] <Xogium> yeah :/ [20:06:35 CEST] <durandal_1707> point is to not have clicks [20:06:46 CEST] <durandal_1707> when switching [20:07:18 CEST] <durandal_1707> when sikence is in transition you can not check it at all [20:09:56 CEST] <Xogium> hmm I do have some music in flac, I could convert them in opus, but they do have silence at start and end [20:27:48 CEST] <kepstin> cpplearner: although most audio codecs don't have intra frames, some of them do require that you start decoding the audio a few frames before the point that you actually want the audio from [20:29:59 CEST] <kepstin> with opus in particular they recommend you start decoding 80ms (usually 4 frames, with 20ms frames) before the point you want audio from for the decoder to converge [20:32:35 CEST] <kepstin> but that's the same soffset for any frame, you don't have to worry about any particular frames being special. [20:40:45 CEST] <Xogium> I can't figure how I could provide opus files without silence [20:41:23 CEST] <Xogium> trim too much and you just cause more clicking in the file :S [20:51:24 CEST] <rooth> JEEB: Thanks to you as well for your pointer earlier! (Not the quickest reply from my side, family etc..) [20:51:38 CEST] <JEEB> rooth: no problemos [20:51:49 CEST] <JEEB> I've been now writing this e-mail for at least two hours :P [21:06:10 CEST] <Xogium> durandal_1707: well, I can't seem to remove the silence correctly in my files, I could provide files in better quality but that wouldn't be good enough would it ? [21:07:41 CEST] <Xogium> all that I tried so far massacres the audio plenty [21:08:35 CEST] <durandal_1707> Xogium: do not trim, buy music without silence transitions [21:09:11 CEST] <Xogium> well all that I got so far have this stupid blank at start and end :/ [21:09:44 CEST] <Xogium> music from game of thrones and various other artists, they all have this [21:12:24 CEST] <Xogium> I guess I'm a bit screwed unless you know some place where they sell musics without silence transitions [21:16:13 CEST] <kepstin> note that the ogg opus header has an end trimming field (number of samples to discard from end) which a good player will read, so if the player has gapless support it can do seamless transitions from one file to the other [21:16:37 CEST] <kepstin> but there's no way to just concatenate lossy encoded audio into a single stream without introducing artifacts [21:18:38 CEST] <Xogium> kepstin: nod, I figured, but in this case here I am trying to figure what is wrong with the stream in opus such that when playing it ffmpeg complains about 'invalid audio pts' and 'failed parsing packet header' and etc. and durandal_1707 asked me for a better quality sample and without silence transition between each chained opus stream [21:20:20 CEST] <Xogium> better quality no problem, but no silence between each chained opus stream, huh& [21:20:28 CEST] <kepstin> Xogium: hmm. [21:20:31 CEST] <Xogium> I fall short here [21:20:39 CEST] <kepstin> oh, interesting, the ogg opus spec actually has a note about this: https://tools.ietf.org/html/rfc7845#section-7.2 [21:21:50 CEST] <kepstin> there probably isn't any way to do that with ffmpeg :/ [21:22:15 CEST] <Xogium> kepstin: would this explain the errors I'm seeing ? [21:22:40 CEST] <kepstin> no, you still shouldn't be seeing errors [21:22:48 CEST] <richar_d> can the warning `[mp4 @ 0x7ff70d043200] track 1: codec frame size is not set` be safely ignored? it's displayed when I copy an AC3 stream from a Maktrosa container to an MPEG-4 container [21:22:48 CEST] <Xogium> hrm [21:23:07 CEST] <kepstin> that doc just provides a special encoding method that can be used to avoid discontinuities (audible glitches) in continuous playback [21:23:18 CEST] <Xogium> ah, nod [21:24:10 CEST] <Xogium> not sure how to go further with these errors, I guess I need to find where to get musics w/o silence transitions [21:25:12 CEST] <kepstin> Xogium: one thing to check - did you make sure that the files being chained all get different serial numbers? [21:25:32 CEST] <kepstin> concatenating two files which have the same serial number of the stream won't work [21:25:53 CEST] <Xogium> let me check [21:26:31 CEST] <Xogium> yes, all of the 8 streams have a different serial [21:27:04 CEST] <Xogium> in fact opusinfo considers them good [21:27:13 CEST] <Xogium> no warning or errors of any kind [21:29:08 CEST] <Xogium> er I think I gave a wrong sample of stream there, the stream.opus sample. Let me redo it [21:29:25 CEST] <Xogium> the come over.opus is a good one, the one done with cat [21:29:34 CEST] <Xogium> just gonna redo the icecast sample, sec [21:32:40 CEST] <Xogium> not that I'd be useful I'm afraid, but well [21:32:47 CEST] <Xogium> *it'd be useful, rather [21:35:09 CEST] <Xogium> here's the sample of the icecast stream, sorry for the mess. Encoded with ffmpeg on the fly: https://plik.root.gg/file/7se5NH6OI90Se2iK/ppQ1LBfprVnk3AG8/stream.opus [21:36:56 CEST] <Xogium> and the raction of audacious is rather hardcore [21:37:00 CEST] <Xogium> *reaction [21:37:02 CEST] <Xogium> ERROR ffaudio-core.cc:188 [opus]: <0x7fe43805a780> Error parsing the packet header. [21:37:05 CEST] <Xogium> ERROR ffaudio-core.cc:223 [log_result]: avcodec_send_packet failed: Invalid data found when processing input [21:37:08 CEST] <Xogium> ERROR playback.cc:376 [finish_playback_locked]: Playback finished with error. [21:37:29 CEST] <Xogium> and it never gets to the second music in the stream [21:38:50 CEST] <Xogium> vlc is acting weird, it skips the first few msec of the 2nd stream, gets silenced for a bit, then resumes playback as if nothing happened. Only mpv is playing normally along with ffplay, even though they both complain [21:43:02 CEST] <Xogium> so, whatever is up with those streams opusinfo can't tell, that at least I know [22:07:13 CEST] <Xogium> kepstin: I know it's probably impossible to do anything with the samples I posted, but do you notice something wrong ? I don't know what tools to use to check, honestly and that is all I've got unless I get my hands on musics without silence transitions [22:08:29 CEST] <durandal_1707> you can take track and split it in two [22:09:23 CEST] <Xogium> durandal_1707: silence at the start / end won't matter ? I thought they really did [22:09:43 CEST] <Xogium> that is, silence at the start of the first track, and end of the second track [22:10:24 CEST] <durandal_1707> does not matter [22:11:11 CEST] <Xogium> oh, okay, and how do I chain them, if cat isn't suitable for this ? [22:15:56 CEST] <durandal_1707> dunno, try cat [23:00:24 CEST] <Xogium> durandal_1707: here you go, I had some fun with segment filter& Not my best cut but I hope it is good enough https://plik.root.gg/file/4wIBbyB8ky6xxgBx/rziFe4Pdgea8yb3W/out2.opus [23:46:05 CEST] <Xogium> durandal_1707: also I noticed that if I ask mpv to loop the current file, it will only loop first or second part of the entire opus stream depending on what part I was when I toggled it. Shouldn't the whole stream be looped, unless they each count as different file ? [23:51:22 CEST] <JEEB> each effectively is if it's concatenated ogg [23:51:57 CEST] <Xogium> ah [23:52:48 CEST] <Xogium> well this explains that part, at least. Now why's ffmpeg angry at these concatenated ogg [23:56:35 CEST] <Xogium> each individual non-concatenated opus stream is perfectly fine when played, however soon as they are in a chain ffmpeg gets annoyed [23:57:21 CEST] <Xogium> this is what mpv says [23:57:24 CEST] <Xogium> [ffmpeg/audio] opus: Error parsing the packet header. [23:57:26 CEST] <Xogium> Error decoding audio. [23:57:40 CEST] <JEEB> it gets a header where it expects just packets I think [23:57:43 CEST] <Xogium> Invalid audio PTS: 55.000000 -> -0.006500 [23:57:54 CEST] <JEEB> and then finally it gets the new index [23:58:01 CEST] <Xogium> so [23:58:04 CEST] <JEEB> it warns that "whoa there the time just went backwards" [23:58:14 CEST] <Xogium> is my stream bogus, or is ffmpeg acting up ? [23:58:42 CEST] <JEEB> the stream is indeed badly confusing FFmpeg [23:58:47 CEST] <Xogium> and how can I make it not bogus if so ? [23:59:16 CEST] <JEEB> make it a singular continuous ogg mux? [23:59:34 CEST] <Xogium> I took parts of a music that I encoded with ffmpeg, then used: cat part1.opus part2.opus part3.opus >music.opus [23:59:48 CEST] <JEEB> probably might even work with ffmpeg -v verbose -i INPUT -c copy OUT.opus [00:00:00 CEST] --- Mon Sep 2 2019

1 0

ffmpeg-devel.log.20190725
by burek 01 Sep '19

01 Sep '19

[00:07:51 CEST] <cone-031> ffmpeg 03Michael Niedermayer 07master:923d5c489fd4: avcodec/utils: fix leak of subtitle_header on error path [00:48:16 CEST] <tmm1> how feasible would it be to use a bsf to extract h264 reordering information? [00:51:16 CEST] <mkver> Do you mean simply to extract the value from the SPS's VUI (if it is present)? [00:51:43 CEST] <iive> about that VLC CVS... how is .mp4 POC for mkv bug?! [00:52:19 CEST] <mkver> You can rename a Matroska file to .mp4. [00:52:28 CEST] <jamrial> yeah, it's using the wrong extension [00:52:34 CEST] <mkver> Or do you want to actually determine the amount of reorder frames from the bitstream? [00:54:51 CEST] <nevcairiel> knowing some history, sounds like another approach of trying to work with apples insane hardware decoder API which for some insane reason forgot to re-order frames in its decoder [00:55:35 CEST] <mkver> So the decoder outputs frames in decoding order? [00:55:49 CEST] <tmm1> yea the vt decoder in async mode has a long standing problem where frames don't come back in decode order [00:56:20 CEST] <tmm1> however currently i'm working on something else.. i'm using h264_metadata=a53_cc=extract to pull out caption data and i need to reorder it into picture order before i can decode it [00:56:54 CEST] <nevcairiel> thats really the same problem though, and not easy. You need a lot of an actual decoder [00:57:28 CEST] <tmm1> so not a simple field i can pull out of the bitstream, bummer [00:57:58 CEST] <nevcairiel> CC design is also one of those insanities that'll haunt us until the end of time, mostly because its mandatory by US law [00:58:08 CEST] <mkver> H.264 has several ways of indicating output order, depending on the SPS's pic_order_cnt_type. [00:59:37 CEST] <mkver> The most flexible only gives you the least serious bits of the pic order count and lets you unwrap them by yourself, thereby generating output order. [01:01:02 CEST] <mkver> But if the packets have correct timestamps, you could actually avoid taking a look at the bitstream yourself. [01:01:18 CEST] <tmm1> i see, so the signal to determine order can vary depending on the h264 bitstream features used [01:01:26 CEST] <mkver> Yes. [01:02:07 CEST] <nevcairiel> I've long advocated against relying on timestamps for re-ordering, and I'll continue to do so. They are notoriously unreliable [01:03:03 CEST] <tmm1> i'm using PTS now and it mostly works, but i've started to hit cases where it no longer does [01:03:32 CEST] <mkver> Such as? [01:05:44 CEST] <tmm1> it was reliable on broadcast mpegts streams, but not on some iptv/hls streams i'm testing [01:06:28 CEST] <tmm1> broadcast streams generally have both PTS and DTS set, but many hls encoder seem to skip DTS and i guess the PTS are also not accurate [01:06:50 CEST] <tmm1> or maybe there's some other bug in my hls stream handling [01:07:41 CEST] <mkver> Are the CC specs actually publically available? [01:08:29 CEST] <tmm1> hm i don't recall. the wikipedia page is pretty good, i used that when i was working on ccaption_dec.c [11:13:48 CEST] <durandal_1707> kierank: can you apply adxenc patch for me, looks like nobody cares to review it [11:26:46 CEST] <kierank> durandal_1707: yes in office [13:08:19 CEST] <durandal_1707> vel0city: perhaps you need to check number of components for mjpeg change, to not break file michealni found [13:36:14 CEST] <durandal_1707> IRC disrupts [13:46:29 CEST] <vel0city> @durandal_1707: I'll try that [13:50:34 CEST] <vel0city> or the precision, 16 vs 8 [13:56:25 CEST] <vel0city> first gotta narrow it down [13:57:42 CEST] <vel0city> ah was the vpred path [14:00:34 CEST] <vel0city> k I'll just check for s->bayer which is already s->lossless == 1 && nb_components == 2 [14:04:03 CEST] <Lynne> why was it marked as bayer btw? [14:05:27 CEST] <vel0city> because it's bayer encoded. mjpegdec.c doesn't do the debayering, but it was the most fitting name I could think of. I could have called it 'dng' to be more specific but I liked bayer better [14:43:24 CEST] <whiteboard> Hi ! Is it possible to make AVPacket side data persistent ? I mean adding AVPacket side data in a bitstream filter and being able to recover the same AVPacket side data with a different one without chaining the two filters. [15:38:21 CEST] <mkver> whiteboard: Most bsf just operate on the packet data and just pass through any side data that the packet already had. [15:46:42 CEST] <Lynne> I think its about attaching side data to the actual data of the packets [15:47:23 CEST] <Lynne> the answer is it depends on the codec, and you can't be sure that whatever the packets are passed through won't drop it [16:08:21 CEST] <kierank> durandal_1707: I am leaving irc [16:08:25 CEST] <kierank> nicholas says is is bad [16:08:28 CEST] <kierank> it* [16:11:13 CEST] <kierank> let's move to slack instead [16:11:20 CEST] <kierank> or fax [16:12:02 CEST] <jamrial> or google wave. is that still working? [16:13:23 CEST] <kierank> lol [16:13:25 CEST] <cone-071> ffmpeg 03Paul B Mahol 07master:cc6a1f141762: avcodec/adxenc: add EOF header [16:31:16 CEST] <gnafu> kierank, jamrial: Carrier pigeon, of course. [16:31:20 CEST] <gnafu> Or smoke signals in a pinch. [16:31:30 CEST] <gnafu> This whole IRC business is aa bit too real-time for my taste. [16:31:35 CEST] <gnafu> s/aa/a/ [16:58:51 CEST] <Lynne> semaphores are the future [17:31:36 CEST] <durandal_1707> IRC is past, present and future [17:32:36 CEST] <durandal_1707> anybody against applying IMM5 decoder? [17:53:19 CEST] <jamrial_> durandal_1707: is concatenated and decodable h264/hevc packets within imm5 a real world case? have you seen something like that in the wild? [17:54:06 CEST] <jamrial_> the same could be done to any kind of input. i don't see why we're taking it into consideration for this specific codec [17:54:34 CEST] <kurosu> jamrial_: dame comment some days ago basically [17:55:15 CEST] <kurosu> I expect crafted files to change the codec on a frame basis and thus making no sense [17:56:03 CEST] <durandal_1707> jamrial_: i'm not accepting hacks in demuxer, this is decoder [17:56:11 CEST] <kurosu> My suggestion was to maybe delay opening the decoder until the first frame and keep it. If it changes, bail out, asking for a sample [17:56:57 CEST] <durandal_1707> you do not need to delay anything [17:57:11 CEST] <durandal_1707> opening decoder does not hurt [21:41:21 CEST] <Compn> durandal_1707, michaelni says he doesnt think anything is blocking photosensitive filter [21:41:38 CEST] <Compn> <michaelni> Compnn, i dont think theres anything blocking it, at least nothing i found. There are some areas which can be improved as i mentioned on the ML [21:49:03 CEST] <durandal_1707> Compn: then i will apply it after i get back from vacation [21:49:21 CEST] <Compn> enjoy vacation [21:49:51 CEST] <durandal_1707> can't, must read ffmpeg-devel mailing-list every day [00:00:00 CEST] --- Fri Jul 26 2019

1 0

ffmpeg-devel.log.20190728
by burek 01 Sep '19

01 Sep '19

[00:00:49 CEST] <Lynne> is there any way to completely disable v4l2_m2m? [00:01:04 CEST] <Lynne> its always enabled, even with --disable-everything --disable-autodetect [00:01:57 CEST] <JEEB> welcome to that list of stuff that always gets probed&enabled [00:02:25 CEST] <JEEB> I wonder if it was alsa or something similar that I had to disable by commenting out the check in configure [00:02:47 CEST] <JEEB> something something "system libraries" [00:03:13 CEST] <JEEB> in theory "disable-xxxx" should work, but I didn't have that work too well as I think the things on that one list get auto-enabled [00:03:24 CEST] <JEEB> (or I failed at using the correct command) [00:04:50 CEST] <Lynne> nope, adding --disable-hwaccel --disable-v4l2-m2m doesn't work. [05:56:02 CEST] <soreau> In case anyone is interested, I filed https://bugs.freedesktop.org/show_bug.cgi?id=111235 (gallium_drv_video.so report support for packed headers) [06:23:24 CEST] <soreau> jkqxz: do you think I should submit the patch to mesa-devel list with a link to the bug report as well? [09:47:11 CEST] <durandal_1707> vel0city: i see no point in working for speed, when it should first work correctly [09:59:39 CEST] <vel0city> @durandal_1707: ok, agreed [13:46:50 CEST] <durandal_1707> Lynne: where we will store rnn models? [14:00:14 CEST] <Lynne> durandal_1707: dunno, a separate repo somewhere sounds good [14:01:48 CEST] <Lynne> we could always upload them on aws and stream them via some restful api over http [16:14:46 CEST] <Lynne> durandal_1707: where do you plan to use the double fft? [16:16:57 CEST] <durandal_1707> Lynne: in libavfilter/af_afir.c [18:16:23 CEST] <jkqxz> soreau: No, because packed headers aren't supported by that driver. Making it say that they are just moves the problem to a different place and makes it weirder. [18:17:13 CEST] <soreau> jkqxz: So it's producing a 'bad' mkv but it just happens to work because video players are lenient? [18:17:15 CEST] <jkqxz> With that change, lavc will include headers in the extradata and pass them to the driver, but the driver will ignore them and generate something completely different. You'll end up making even more broken files, where the header data doesn't match the stream at all. (But which will still work with some decoders because of the inline headers, though in fewer cases than no headers because seeking will [18:17:21 CEST] <jkqxz> break too.) [18:18:06 CEST] <soreau> jkqxz: so what's the problem with just implementing proper packed header support in the driver? [18:19:45 CEST] <jkqxz> Nothing, that's exactly the right solution. [18:19:56 CEST] <soreau> I don't even know what this means. Does the gpu have to do work to produce the headers or can it be a static header reused with things that need to be changed, changed? [18:20:37 CEST] <soreau> how do you even know where to start on something like this [18:21:24 CEST] <soreau> I'd love to do it, I just don't know how or what to do [18:21:43 CEST] <soreau> presumably the intel vaapi driver implements packed headers? [18:22:00 CEST] <jkqxz> Yes. [18:22:26 CEST] <soreau> so maybe I could peek in there to fill in some blanks [18:22:47 CEST] <JEEB> I know we support multiple parameter set things in mp4 out of band nowadays, but do we have an interface/callback for the things to call when they want to pass new parameter sets to us? [18:22:52 CEST] <durandal_1707> how to setup irc logger bot for ffmpeg channels? the current one is clearly dead. [18:22:54 CEST] <JEEB> as in, in encoders [18:23:02 CEST] <jkqxz> I'm not sure it's even possible on Polaris with publicly available information, though. Raven Ridge+ (VCN targets) do look like they can do it, and it's vaguely on my todo list to look at at some point. [18:23:15 CEST] <soreau> jkqxz: you mean packed headers? [18:23:59 CEST] <jkqxz> Yes. [18:27:19 CEST] <soreau> jkqxz: What does the gpu have to do? Can't it just have a function to produce headers using plain cpu/software? [18:29:17 CEST] <JEEB> if you can receive the paramter sets etc from the hw encoder [18:29:40 CEST] <JEEB> if the API is in-band you can also embed a parser and extract the parameter sets etc :P [18:29:47 CEST] <JEEB> and pass them out as out of band things [18:30:07 CEST] <JEEB> the problem of course is then that you have to keep checking if it duplicates them on each GOP [18:30:13 CEST] <jkqxz> You don't want the hardware to have anything to do with generating headers, you just want it to insert the headers provided by the caller. The AMD stuff has weird proprietary blobs running on a separate processor inside their hardware which messes with some of this in an unhelpful way, though. [18:30:25 CEST] <JEEB> or if you got a new set of parameter sets [18:33:51 CEST] <soreau> jkqxz: Why can't the caller just insert them? :P [18:36:38 CEST] <soreau> jkqxz: isn't it just like the first frame? or not always true [19:27:42 CEST] <cone-024> ffmpeg 03Andreas Rheinhardt 07master:c2a91645c5b5: mpeg2_metadata, cbs_mpeg2: Fix handling of colour_description [19:27:47 CEST] <cone-024> ffmpeg 03Andreas Rheinhardt 07master:b71a0367a6e7: cbs: Remove useless initializations [19:27:47 CEST] <cone-024> ffmpeg 03Andreas Rheinhardt 07master:d9182f04caa5: cbs_mpeg2: Fix parsing of picture and slice headers [19:27:47 CEST] <cone-024> ffmpeg 03Andreas Rheinhardt 07master:43a188847cce: av1/h264_metadata: Don't reinitialize data [19:30:39 CEST] <soreau> How can I check a video file to see if it has proper packed headers? [19:32:32 CEST] <thardin> what kind of file? [19:32:45 CEST] <soreau> mkv or mp4? [19:33:09 CEST] <soreau> or any kind [19:57:31 CEST] <jkqxz> Look at trace_headers and make sure extradata and anything inline matches. [20:06:23 CEST] <cone-024> ffmpeg 03Andreas Rheinhardt 07master:abb2e9ac3cb9: vp9_metadata: Improve spec-compliance and warnings [20:06:53 CEST] <soreau> jkqxz: So run `ffmpeg -i input.mkv -c:v copy -bsf:v trace_headers`? I don't see anything that says extradata or inline [20:08:53 CEST] <jkqxz> Then your file probably has no headers. (Try with a file made with something else for comparison.) [20:10:13 CEST] <soreau> does metadata == extradata? [20:10:50 CEST] <jkqxz> No. You'll get a line explicitly saying "Extradata" in the trace_headers output. [20:11:17 CEST] <soreau> Do I actually need to specify an output file? [20:12:44 CEST] <soreau> I get "Trailing options were found on the commandline." [20:13:06 CEST] <soreau> maybe it's not using trace_headers I am passing [20:17:57 CEST] <JEEB> ffmpeg -i FILE -map 0:v -bsf:v trace_headers -vframes 1 -f null - [20:18:10 CEST] <JEEB> possibly redirect stderr into a file with 2> blah.log [20:18:26 CEST] <JEEB> that should give you all the things that happen until the first frame is decoded [20:18:49 CEST] <JEEB> also I probably forgot -c copy there :P [20:21:43 CEST] <soreau> JEEB: thanks, is there no way to just dump this to stdout/err? [20:22:21 CEST] <soreau> oh right, eliminate the redirect [20:27:45 CEST] <soreau> Some files show "4 bytes left at end of AVCC header." but most that I've created with ffmpeg show nothing at all [20:29:14 CEST] <jkqxz> The lines after "Extradata" but before any "Packet:" lines are the extradata. [20:30:07 CEST] <soreau> and what's the inline stuff? [20:31:34 CEST] <JEEB> inline stuff comes in packets [20:31:48 CEST] <JEEB> extradata is what's in the extradata field that is the out-of-band initialization data [20:32:24 CEST] <soreau> How do I view inline stuff? [20:32:51 CEST] <JEEB> it should be there [20:33:30 CEST] <soreau> I don't see anything that says inline [20:33:38 CEST] <JEEB> no [20:33:40 CEST] <soreau> where are you talking about? [20:33:55 CEST] <JEEB> in-band (data in packets) and out-of-band (extradata) [20:34:11 CEST] <soreau> I'm askig how to view the inline data [20:34:39 CEST] <soreau> I'm kinda surprised there isn't some programmatic way to verify headers are valid [20:35:00 CEST] <soreau> Is there a video player that is known to reject invalid headers or anything? [20:35:24 CEST] <JEEB> within lavc there's the parsing functionality utilized by trace_headers [20:36:07 CEST] <JEEB> soreau: you can view it just the same way as the extradata stuff [20:36:28 CEST] <soreau> JEEB: I don't see anything that says inline though [20:36:32 CEST] <JEEB> of course not [20:36:40 CEST] <JEEB> "inline" is not a word we use within the FFmpeg framework [20:36:46 CEST] <JEEB> nor is in-band or out-of-band [20:36:56 CEST] <JEEB> it's just words to mean if the data is in the (av)packets or the extradata [20:37:00 CEST] <soreau> ok so how do I view the inline data? [20:37:12 CEST] <JEEB> jsut let me post a quote of a dump I just did with trace_headers [20:39:15 CEST] <JEEB> soreau: http://up-cat.net/p/c2b91d58 [20:39:30 CEST] <JEEB> the first part is what's in extradata which is where stuff from f.ex. mp4's AVCc is put [20:39:46 CEST] <JEEB> then you have stuff that comes out of packets, that's in-band. [20:39:51 CEST] <JEEB> like the SEI that comes out first there [20:40:11 CEST] <JEEB> parameter sets in packets = "headers" in-band [20:40:26 CEST] <JEEB> I hope this makes the output of trace_headers a bit more understandable :P [20:40:58 CEST] <JEEB> so in here we have SPS and PPS in extradata (out-of-band, from the container header like AVCc) [20:41:07 CEST] <JEEB> and then SEI and a slice header from in-band [20:44:02 CEST] <JEEB> now if I use this same thing with an MPEG-TS file I will most likely get the SPS/PPS within a packet [20:44:17 CEST] <JEEB> as MPEG-TS has decoder initialization data within the strema [20:44:19 CEST] <JEEB> *strea, [20:44:22 CEST] <JEEB> *stream [20:44:57 CEST] <soreau> JEEB: Look for parameter sets (SPS, PPS, VPS) for in-band "headers" <-- I don't see SPS, PPS, VPS anywhere but this line [20:45:17 CEST] <soreau> and also I see no wway to compare extradata with inline data [20:45:45 CEST] <thardin> what do you actually want to do? [20:45:54 CEST] <soreau> <jkqxz> Look at trace_headers and make sure extradata and anything inline matches. <-- is there a programmatic way to do this? [20:46:14 CEST] <JEEB> if you don't have grep -i -B1 "parameter set" anywhere else than in extradata, then there are no in-band parameter sets :P [20:46:32 CEST] <soreau> thardin: trying to find a reliable test to validate packed headers [20:46:43 CEST] <JEEB> soreau: yes. feed the packets' data to the same functionality that the trace_headers stuff uses? [20:46:54 CEST] <JEEB> if you really want to parse that [20:47:09 CEST] <JEEB> otherwise you can just a binary check :P [20:47:10 CEST] <JEEB> if they match [20:47:36 CEST] <soreau> I mean if there's no video player that checks this, then what's the point? Why does it matter if the headers are ok or not? [20:47:52 CEST] <thardin> what do you mean by packed headers? [20:48:09 CEST] <thardin> if you want your videos to work in $PLAYER then you need to test in that player [20:48:28 CEST] <thardin> there are validators for some formats [20:48:36 CEST] <thardin> sometimes that's enough, but not always [20:49:24 CEST] <JEEB> soreau: many software players just take whatever they take last so if your last set of parameter sets are correct they might "just work", accidentally :P still doesn't make any more sense to write incorrect parameter sets into the AVCc block of mp4 [20:49:42 CEST] <soreau> thardin: The problem is that for instance when trying to use vaapi with gallium state tracker, it doesn't have packed header support so it produces a video file that's apparently technically wrong but I'm trying to discover why these headers even matter [20:50:08 CEST] <thardin> ah [20:50:15 CEST] <soreau> thardin: and mkv checks but mp4 doesn't (though it might in the future) so vaapi wont work for mkv and mp4 containers as output [20:50:33 CEST] <thardin> sounds like missing extradata [20:51:24 CEST] <soreau> and I've found out that the driver caller has the header and the driver is supposed to add it but there are complications with missing hw specs apparently so I am trying to figure out if the caller can just add the headers afterward or something [20:51:31 CEST] <JEEB> soreau: we've made FFmpeg based stuff way too resilient to broken crap, but that doesn't mean that you should create more code that creates even more spec-breaking or incorrect files vOv [20:51:51 CEST] <cone-024> ffmpeg 03Shiyou Yin 07master:62e6b634a802: avcodec/mips: [loongson] refine process of setting block as 0 in h264dsp_mmi. [20:52:01 CEST] <soreau> JEEB: that's why I'm wanting to do something to fix it [20:52:16 CEST] <JEEB> yup, and as you can see I've tried to help you :P [20:52:33 CEST] <soreau> JEEB: so how would I do a binary check or whatever you were talking about? [20:52:47 CEST] <JEEB> is there a memory compare thing? [20:52:51 CEST] <JEEB> just check if the bytes are the same [20:53:01 CEST] <soreau> I have no idea how to do this [20:53:10 CEST] <thardin> there are tools that will pick apart an h.264 stream for you [20:53:34 CEST] <soreau> thardin: But is there something that will just say headers are valid or not [20:53:44 CEST] <thardin> uhm, that probably depends [20:54:00 CEST] <JEEB> if you want an actual parser then the stuff used by trace_headers exists [20:54:01 CEST] <JEEB> as I noted [20:54:06 CEST] <JEEB> it will error out on incorrect data :P [20:54:20 CEST] <soreau> JEEB: but you're not telling me how to do this [20:54:28 CEST] <JEEB> of course not, I've barely looked at the API! [20:54:31 CEST] <JEEB> I cannot know everything [20:54:31 CEST] <soreau> I have no idea to do what you're talking about [20:54:32 CEST] <JEEB> sorry [20:54:41 CEST] <JEEB> see for cbs_ [20:54:43 CEST] <JEEB> in libavcodec/ [20:54:52 CEST] <JEEB> then you know as much as I do [20:55:03 CEST] <JEEB> libavcodec/cbs.h [20:55:14 CEST] <thardin> a friend of mine wrote his own goloumb decoder for dealing with h.264 stuff [20:55:32 CEST] <thardin> maybe there's something similar around [20:55:41 CEST] <thardin> or that trace_headers thing yes [20:55:52 CEST] <JEEB> the CBS stuff is the closest we have for coded bit stream parsing as far as I can tell [20:57:10 CEST] <JEEB> soreau: but if you do not want to get discouraged by hopping into this coding stuff, my recommendation as noted before would be to just compare the text output of trace_headers between different paramter sets etc [20:57:26 CEST] <JEEB> if you like coding then you have CBS framework right there [20:57:45 CEST] <JEEB> I have no idea how to use it, but the trace_headers and a few other bit stream filters are already using it [21:04:11 CEST] <soreau> JEEB: coding isn't the problem, I just don't know why there isn't something like this if having invalid headers is a 'problem' [21:04:41 CEST] <JEEB> very good question [21:05:16 CEST] <JEEB> in some cases there's an explode mode [21:05:16 CEST] <soreau> If something like this is in fact needed, there should be a dedicated program for it IMO [21:05:38 CEST] <JEEB> I do agree [21:05:42 CEST] <soreau> or a program that can be used for this purpose at least [21:06:10 CEST] <soreau> I mean even if someone were to implement proper packed header support in the driver, how would you know if it's working or not? [21:06:27 CEST] <JEEB> we have some checkers for isobmff and matroska I think, but that's for the container level in general. they don't take opinion on the actual data within in many ways [21:06:31 CEST] <soreau> from what I can tell so far, there isn't a clear cut way [21:06:53 CEST] <JEEB> soreau: don't output any parameter sets in packets and see if it plays [21:07:37 CEST] <JEEB> of course FFmpeg itself sucks at this check because you can probably have Annex B in the extradata and the effing thing might still play through FFmpeg's parser&decoder :P [21:09:41 CEST] <JEEB> there's seemingly a bit stream filter called extract_extradata which seems to have an option to remove parameter sets etc from streams when they are in-band [21:09:57 CEST] <JEEB> I have never used it but it might be useful for testing [21:10:09 CEST] <soreau> I mean if this extradata was comparable to the inline stuff I probably could write a script to parse stuff and compare but it's like these values don't even remotely match [21:10:15 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#extract_005fextradata [21:10:26 CEST] <soreau> between extradata and inline, the stuff isn;t comparable [21:12:20 CEST] <JEEB> I don't 100% remember if extradata field contains the whole AVCc which is the mp4 structure, or just the parameter sets [21:12:49 CEST] <JEEB> if it's the full AVCc structure then you will have to of course parse the actual parameter sets from that [21:13:08 CEST] <JEEB> but as I noted, the trace_headers filter already does that [21:13:18 CEST] <JEEB> for me it output the values of the parameter sets from the extradata nicely [21:13:34 CEST] <JEEB> and then if I would have another set in the stream then that would pop up in there as well [21:13:56 CEST] <JEEB> I am not sure if I have such an example on hand right now so I can't exactly give you a nice example :P [21:14:09 CEST] <JEEB> if I do trace_headers on MPEG-TS I get stuff in-band only [21:14:20 CEST] <soreau> JEEB: you're speaking greek to me. I need to know what I'm comparing because it isn't obvious [21:15:09 CEST] <JEEB> well, sorry. clearly I suck at helping people [21:17:27 CEST] <soreau> Extradata: Sequence Parameter Set, Picture Parameter Set; Inline: Supplemental Enhancement Information, User Data Unregistered, Slice Header [21:17:46 CEST] <soreau> jkqxz: what is supposed to match to what? [21:18:33 CEST] <JEEB> the parameter sets are supposed to match to the actual stream (aka "the stream should be decode'able" [21:18:50 CEST] <JEEB> somehow there was an understanding that you had something that generated files with parameter sets in-band [21:18:59 CEST] <JEEB> so you would have packets that would contain paramter sets [21:19:17 CEST] <JEEB> my example only had SEI in there in front because it properly had the paramter sets only in the extradata [21:20:00 CEST] <JEEB> I would have given an example with parameter sets in both places if I had such [21:21:40 CEST] <soreau> <JEEB> the parameter sets are supposed to match to the actual stream <-- So Sequence Parameter Set and Picture Parameter Set parameters should be compared to what? Supplemental Enhancement Information and Slice Header? [21:21:58 CEST] <JEEB> did you read the last two messages I wrote? [21:22:12 CEST] <JEEB> you would have the same kind of SPS/PPS within the stream (in packets) [21:22:12 CEST] <soreau> JEEB: yes but I'm having trouble understanding [21:22:25 CEST] <soreau> I don't know what SEI, SPS/PPA is [21:22:35 CEST] <JEEB> SEI is Supplemental Enhancement Information [21:22:47 CEST] <JEEB> PPS is Picture Parameter Set, SPS is Sequence Parameter Set [21:23:08 CEST] <soreau> ok but how does that invalidate my question? [21:23:35 CEST] <soreau> I'm trying to figure out what to compare against each other to know if it's a valid header [21:23:40 CEST] <JEEB> it doesn't, I just noted that I had just said that if I had such an example that the earlier discussion looked like you were having, you would have the parameter sets in *both* [21:24:05 CEST] <JEEB> if you only have parameter sets in extradata then that's of course great [21:24:47 CEST] <JEEB> for H.264 it's the SPS and PPS that matter for decoder initialization; those have to be right [21:24:54 CEST] <JEEB> for HEVC I think it is SPS, PPS and VPS [21:25:05 CEST] <JEEB> all of those are _something_ parameter sets [21:25:12 CEST] <soreau> but if I am to write some tool I need to know for sure [21:25:19 CEST] <soreau> is there no real documentation about this? [21:25:39 CEST] <JEEB> at this point I'm confused about what you are exactly confused about [21:25:51 CEST] <JEEB> possibly as confused as you are towards WTF I've talking about [21:25:55 CEST] <JEEB> *I'm [21:26:10 CEST] <JEEB> also please let's have one thing verified first [21:26:35 CEST] <JEEB> let's see if the problem to begin with was what I expected from how your discussion with jkqxz went [21:27:13 CEST] <JEEB> `ffmpeg -i FILE -c copy -map 0:v -bsf:v trace_headers -vframes 1 -f null - 2> blah.log` [21:27:23 CEST] <JEEB> do this on one of those files that was generated with the problematic encoder [21:27:30 CEST] <JEEB> and that would fail now with matroska [21:27:56 CEST] <JEEB> then paste the AVBSFContext parser stuff [21:28:02 CEST] <JEEB> onto a pastebin.com or gist or something [21:28:04 CEST] <JEEB> and link here [21:28:23 CEST] <JEEB> or just paste the full log [21:28:28 CEST] <JEEB> in pastebin/gist/whatever [21:28:30 CEST] <JEEB> and link here [21:29:17 CEST] <JEEB> I just want to verify what that supposed broken file looks like :P [21:29:54 CEST] <soreau> JEEB: https://www.hastebin.com/raw/uzamojodem [21:29:57 CEST] <JEEB> thank you [21:30:30 CEST] <JEEB> ok, that one shows that you have parameter sets both in extradata and in the stream [21:30:41 CEST] <soreau> JEEB: what does that mean? [21:31:30 CEST] <JEEB> it means that the decoder initialization data is both in the stream and in the container structure for decoder initialization [21:31:44 CEST] <JEEB> they look pretty similar [21:31:55 CEST] <JEEB> if you look at the SPS and PPS values between the two [21:34:25 CEST] <JEEB> or actually no, the one in extradata has a lot of various additional values; sps is much longer [21:35:02 CEST] <soreau> yea that's another question I had, does it matter if one or the other has extra entries or do they have to perfectly match [21:36:16 CEST] <jkqxz> They're not compatible. Some of the fields affecting slice parsing are different, like log2_max_pic_order_cnt_lsb_minus4. [21:36:22 CEST] <JEEB> right [21:36:50 CEST] <soreau> jkqxz: how can I know all the criteria? [21:37:20 CEST] <JEEB> I would expect the encoder to give you those parameters of its encode [21:37:39 CEST] <jkqxz> And transform_8x8_mode_flag, which changes a lot of the macroblock layer. [21:37:57 CEST] <jkqxz> soreau: By reading the standard. [21:38:10 CEST] <jkqxz> (As facetious as that sounds, there isn't really any better answer.) [21:38:34 CEST] Action: soreau doesn't even know where the standard is [21:38:44 CEST] <JEEB> https://www.itu.int/rec/T-REC-H.264/en [21:39:14 CEST] <JEEB> latest one is pre-published so grab the 04/17 one [21:39:24 CEST] <JEEB> https://www.itu.int/rec/T-REC-H.264-201704-S/en [21:39:56 CEST] <JEEB> anyways, in the worst case you could just wait in the encoder until you have the first packet from the encoder and parse the parameter sets from there? [21:40:09 CEST] <JEEB> and set extradata at that point? [21:40:18 CEST] <JEEB> not sure how well that works with our framework, though [21:40:49 CEST] <soreau> yea I want to know if the caller can write the header too [21:41:09 CEST] <JEEB> you *can* but you'll have to generate it according to the spec with the parameters of the encoder [21:41:27 CEST] <JEEB> and if the encoder anyways outputs parameter sets in-band then why not extract that? [21:41:46 CEST] <soreau> according to jkqxz, the caller already has the header generated to pass to the driver [21:41:57 CEST] <JEEB> ok, that's great then [21:42:10 CEST] <soreau> but the gallium driver doesn't support writing it so I was just wondering if the caller can [21:42:10 CEST] <JEEB> then why are the two parameter sets different? :D [21:43:05 CEST] <JEEB> soreau: theoretically you can very much write headers by yourself but the problem is that you are supposed to match that with whatever the encoder itself is going to configure itself for :D [21:43:33 CEST] <JEEB> and when you are guessing I can see stuff like what you have in your paste happening [21:43:45 CEST] <JEEB> maybe I am just mis-understanding something of course [21:43:46 CEST] <soreau> JEEB: well if it's the one passing the headers, I presume they should already be correct [21:44:05 CEST] <JEEB> yes, I would presume the headers in the stream that came from the encoder apparently should be what the encoder wants to write [21:44:12 CEST] <JEEB> I may be incorrect of course [21:44:31 CEST] <JEEB> but that is why I noted the possibility of extracting the headers from the first packet of data that you get from the encoder [21:45:40 CEST] <soreau> yea if the generated headers aren't correct that's another matter but it reportedly works with intel ok so I guess they're correct.. [21:45:48 CEST] <soreau> but without a header checking tool, who knows [21:46:08 CEST] <JEEB> well the paste already contains all the values that you would be comparing/checking [21:46:40 CEST] <JEEB> you would get an error from the decoder if at that point the values would be incorrect [21:47:26 CEST] <soreau> JEEB: what would give an error? [21:47:49 CEST] <JEEB> the decoder. if actual decoder initialization related values do not match what's in the actual coded pictures then you will get an error [21:50:08 CEST] <soreau> JEEB: are you suggesting this could be a header checker? [21:50:18 CEST] <JEEB> and now you've officially lost me [00:00:00 CEST] --- Mon Jul 29 2019

1 0

ffmpeg-devel.log.20190811
by burek 01 Sep '19

01 Sep '19

[00:02:32 CEST] <jgb> who do i have to beg if i want to get this fixed: https://trac.ffmpeg.org/ticket/7912 [00:03:16 CEST] <BtbN> spamming on IRC will for sure make everyone very enthusiastic [00:03:50 CEST] <jgb> btbn do you mean unenthusiastic [00:04:23 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:e82a619c2a15: lavc/frame_thread_encoder: Do not memcpy() from NULL. [00:07:03 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:ac457a3bc589: lavc/vc2enc_dwt: Avoid left-shifting a negative value. [00:25:42 CEST] <jgb> i will pay $$$ to get this fixed: https://trac.ffmpeg.org/ticket/7912 [00:26:40 CEST] <BtbN> So write it as bounty into the ticket and hope someone cares enough. [00:27:00 CEST] <BtbN> spamming both channels here only gets people annoyed [00:27:16 CEST] <jgb> btbn are you someone that is capable of fixing that? [00:27:47 CEST] <BtbN> I have no idea what "that" even is. I only see you cross-spamming links on IRC. [00:27:57 CEST] <jgb> https://trac.ffmpeg.org/ticket/7912 [00:28:06 CEST] <BtbN> Yes, I saw the link. A lot. [00:28:10 CEST] <jgb> btbn are you someone that is capable of fixing that? [00:28:17 CEST] <jgb> yes or no [00:29:19 CEST] <jgb> it's simple yes or no question [00:34:14 CEST] <kierank> jgb: write that in the ticket [00:34:18 CEST] <kierank> say you will give $$$ [00:34:25 CEST] <jgb> kierank are you someone that is capable of fixing that? [00:34:29 CEST] <kierank> no [00:34:36 CEST] <kierank> but putting it in the ticket might find someone [00:35:11 CEST] <jgb> kierank i see [00:35:24 CEST] <jgb> kierank who do you think has most capable of fixing that [00:35:31 CEST] <kierank> no idea [00:35:39 CEST] <kierank> I don't use neckbeard subtitle formats [00:35:39 CEST] <jgb> okay, thanks for the answer [00:36:09 CEST] <jgb> i don't understand why btbn cannot answer a simple yes or question [00:36:41 CEST] <kierank> he does not have to answer to you [00:36:47 CEST] <kierank> he is a volunteer in his free time [00:36:54 CEST] <BtbN> Because BtbN went to the toilet. [00:36:54 CEST] <kierank> (or she) [00:37:14 CEST] <jgb> btbn oh sorry, so what is the answer then [00:37:29 CEST] <BtbN> And I still haven't looked at the ticket. I don't have time to fix stuff anyway at the moment. [00:37:46 CEST] <BtbN> But seriously, put a bounty into the ticket, spamming IRC will only get people annoyed enough to not care out of spite. [00:38:34 CEST] <jgb> mpv can playback the sample.mkv fine which relies on ffmpeg [00:38:54 CEST] <jgb> but ffmpeg has problems; which i don't understand [00:39:32 CEST] <BtbN> So, that ticket looks more like an issue with the srt muxer, than with anything else. I doubt mpv remuxed the subs to srt. [00:39:59 CEST] <jgb> mpv displays subtitle at correct times [00:40:30 CEST] <BtbN> Yes, so? Why would it need to invoke the srt muxer/encoder for that? [00:41:41 CEST] <jgb> then what would it invoke? [00:42:09 CEST] <BtbN> Nothing, it just "decodes" the subtitles and displays them. [00:42:20 CEST] <jgb> i see [00:43:07 CEST] <jgb> why can't "ffmpeg -f lavfi -i movie=SrG.mkv[out+subcc] out.srt" just decode the subtitle and display them [00:43:37 CEST] <BtbN> Because you're telling it to encode to srt. [00:44:00 CEST] <jgb> i see [00:44:34 CEST] <jgb> so bug must be in the "encoding to srt" part? you are saying [00:45:03 CEST] <BtbN> That's literally what that ticket is about [00:45:33 CEST] <jgb> btbn sounds like you are someone capable of fixing this [00:45:50 CEST] <BtbN> Because I'm able to read a very short ticket? [00:46:55 CEST] <BtbN> I have no clue about the srt muxer. Post the bounty on the ticket and see if it motivates anyone. [00:47:35 CEST] <jgb> btbn okay thanks for the help [02:08:02 CEST] <cone-841> ffmpeg 03Carl Eugen Hoyos 07master:2828f5b0d8e4: lavc/r210enc: Fix undefined behaviour encoding r10k. [02:19:11 CEST] <philipl> Why not use mkvextract? [02:19:49 CEST] <jgb> philipl that works even less [02:23:01 CEST] <jgb> philipl https://gitlab.com/mbunkus/mkvtoolnix/issues/2602 [02:25:51 CEST] <nevcairiel> CC are not a track in the container (ie. MKV), which is why its unlikely that any such demuxer supports it [02:27:01 CEST] <nevcairiel> CC is a horrible format, and noone likes working with it, so don't expect any enthusiasm to fix such issues on any side [02:27:56 CEST] <jgb> nevcairiel then why does ffmpeg -f lavfi -i movie=SrG.mkv[out+subcc] out.srt work "partially" [02:28:17 CEST] <jgb> not fully obviously [02:28:48 CEST] <nevcairiel> because that decodes the entire video to find the CC data, its ugly and slow, but its possible because ffmpeg also has decoders, and not just a demuxer [02:28:51 CEST] <mkver> Because lavfi doesn't set the correct timebase, which means it defaults to the 90kHz clock of mpeg. [02:29:08 CEST] <mkver> This is wrong by a factor of 90 (for your file). [02:29:54 CEST] <jgb> mkver no it display all the subtitle in the first 10 seconds [02:30:30 CEST] <nicolas17> how long is the video? [02:30:34 CEST] <mkver> Because the timebase is wrong by a factor of 90. [02:31:48 CEST] <mkver> 5:02. If you multiply all the srt's timestamps and durations by 90, it ends at 4:58.89 [02:33:03 CEST] <jgb> nicolas 5min 2 seconds but it displays all the subtitles in first 4 seconds [02:33:46 CEST] <jgb> it ends at 4:58.89?? huh [02:33:50 CEST] <jgb> it displays all the subtitles in first 4 seconds [02:34:18 CEST] <mkver> IF you multiply all the timestamps (start+end) by a factor of 90... [02:34:23 CEST] <nicolas17> 5 minutes / 90 = 3.3 seconds [02:34:37 CEST] <nevcairiel> so presumably calling avpriv_set_pts_info in create_subcc_streams then should fix it? [02:34:56 CEST] <jgb> nicolas17 wow you are right [02:35:11 CEST] <mkver> You of course need to know the correct timebase (the one from the actual source stream). [02:35:42 CEST] <nevcairiel> thats the same as the video stream of course, since thats the timestamps it gets from the sidedata [02:36:08 CEST] <mkver> Yes. [02:37:12 CEST] <jgb> mkver how do i get rid of /90 [02:37:22 CEST] <jgb> that ffmpeg likes to do [02:37:49 CEST] <jgb> 146 [02:37:49 CEST] <jgb> 00:00:03,308 --> 00:00:03,321 [02:37:49 CEST] <jgb> <font face="Monospace">{\an7}\h\h\hI cant help it. [02:38:15 CEST] <jgb> that's the last srt line [02:38:50 CEST] <nevcairiel> so possibly something like this https://pastebin.com/0KCV7m7K .. entirely untested [02:38:51 CEST] <mkver> You could simply use e.g. MKVToolNix to stretch the subtitles by a factor of 90. Or you could use SubtitleEdit for the job. [02:41:17 CEST] <jgb> nevcairiel can you test it please: video sample is: https://x0.at/SrG.mkv [02:41:53 CEST] <nevcairiel> its almost 3am and i'm going to sleep now [02:42:32 CEST] <mkver> Good night! [02:44:12 CEST] <jgb> mkver wow it worked with mkvtoolnix [02:44:22 CEST] <jgb> but it uses mks ; some weird format [02:44:32 CEST] <mkver> It is a Matroska file. [02:44:35 CEST] <nevcairiel> mks is just a mkv with only a subtitle in it [02:44:49 CEST] <jgb> i want srt format [02:44:58 CEST] <mkver> Use mkvextract on the mks. [02:45:11 CEST] <mkver> Or ffmpeg or SubtitleEdit. [02:45:51 CEST] <jgb> mkver wow you are very smart: how did you know about factor of 90 [02:48:52 CEST] <mkver> This was my initial guess: cc data usually lives in containers with a 90kHz clock; Matroska usually uses a 1kHz clock. Given that the timestamps are monotonically increasing and given that this procedure usually works, I guessed that there is a hardcoded timebase of 90kHz somewhere. [02:49:23 CEST] <mkver> So I looked if the subtitles streched by a factor of 90 fitted the video and they did. [02:51:52 CEST] <jgb> this must be simple fix then [02:51:53 CEST] <nevcairiel> 90khz is the default timebase if none is set, so that makes sense [02:53:32 CEST] <Compnno> jgb, does mplayer -dumpsub options work at all ? :D [02:53:40 CEST] <Compnno> if its cc , probably not ;D [02:53:56 CEST] <jgb> compnno not sure, i don't use mplayer [02:54:06 CEST] <nevcairiel> anyhow someone try my patch if you want, i think it might solve it, otherwise maybe I remember tomorrow to try it [02:54:37 CEST] <mkver> nevcairiel: Your patch sets the wraparound bits to 64; couldn't this break mpegts input? [02:55:06 CEST] <nevcairiel> thats irrelevant at that point [02:55:14 CEST] <nevcairiel> its also the exact same thing thats done for the video stream itself [02:55:28 CEST] <nevcairiel> i litereally copied the timebase stuff from one function further down [02:56:08 CEST] <mkver> Ok, I see. [02:56:58 CEST] <Compnno> nevcairiel, are you missing a ) or am i blind [02:58:04 CEST] <Compnno> oh wow that text disappeared , my bad it was a font problem [02:58:11 CEST] <Compnno> firefox what are you doing [03:11:50 CEST] <mkver> Btw: The newest version of ccextractor can directly extract cc tracks of videos in Matroska. [03:24:27 CEST] <jgb> that is horrible program [03:37:31 CEST] <jgb> mkver ffmpeg is creating <font face="Monospace"> </font> on every line [03:37:37 CEST] <jgb> how do i remove this [03:48:09 CEST] <mkver> You can use SubtitleEdit: Select all the subtitles, right click on them and use "Normal (Remove formatting)" [03:52:13 CEST] <jgb> wow thanks, you are so smart [04:55:51 CEST] <nicolas17> libx264 defaults to crf 23, is that set by ffmpeg or by libx264? [04:56:41 CEST] <nicolas17> looking at libx264.c it seems the crf defaults to -1 so I'm *guessing* the libx264 library turns that into 23 [12:04:21 CEST] <durandal_1707> test test [12:08:50 CEST] <cone-364> ffmpeg 03Thilo Borgmann 07master:33186028fcf7: MAINTAINERS: Add my GnuPG fingerprint. [13:22:43 CEST] <durandal_1707> michaelni: whats needed to be on security ml? [14:41:17 CEST] <kierank> michaelni: just put durandal_1707 on the security ml [14:41:20 CEST] <kierank> stop blocking things [14:41:43 CEST] <kierank> nobody blocked you like this when you got access [15:33:19 CEST] <Chagall> what do I need to do to assign a version to a patch set? [15:33:19 CEST] <Chagall> generate a patch on top of another? [15:42:58 CEST] <jdarnley> Chagall: there's an option to give to format-patch or send-email [15:56:16 CEST] <Chagall> I'm setting in-reply-to but it does not seem to set a version [15:59:02 CEST] <Chagall> I guess this one is unrelated but I couldn't find anything else about setting a version in the format-patch or send-email docs [16:00:38 CEST] <jamrial> Chagall: i think you just format-pach them, then use a text editor [16:03:08 CEST] <Chagall> okay [16:03:53 CEST] <jdarnley> -v <n>, --reroll-count=<n> Mark the series as the <n>-th iteration of the topic. [16:07:23 CEST] <Chagall> thanks... I was ctrl+fing version [16:24:04 CEST] <jdarnley> I was too at first [16:53:32 CEST] <cone-625> ffmpeg 03Limin Wang 07master:391b67fcb58f: lavc/videotoolboxenc: add hdr10, linear, hlg color transfer function for videotoolboxenc [16:53:32 CEST] <cone-625> ffmpeg 03Limin Wang 07master:1ee863a7b05a: lavc/videotoolboxenc: make transfer_fnc initialized for unsupport function [18:35:19 CEST] <durandal_1707> ubitux: do you still read gmail mails? [18:37:21 CEST] <cehoyos> jamrial, michaelni: No comment from me on vbv_delay [18:47:20 CEST] <durandal_1707> cehoyos: did we ever met? and where? [18:47:39 CEST] <cehoyos> I don't think so but who knows;-) [18:48:34 CEST] <durandal_1707> if you never was in croatia, then we never met [18:49:15 CEST] <cehoyos> I was at the airport in Zagred several times (always in green) and as a child I drove to Bosnia once [18:50:19 CEST] <kierank> cehoyos: i thought you said you met paul [18:50:36 CEST] <cehoyos> No, I don't think so [18:51:27 CEST] <cehoyos> I should really visit Rijeka at some point though [19:07:09 CEST] <ubitux> durandal_1707: nope [19:09:58 CEST] <durandal_1707> than whats mail to contact you? [19:16:19 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:da93e2b14218: avcodec/aacdec_template: fix integer overflow in imdct_and_windowing() [19:16:20 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:b153ba1c2e03: avcodec/vc1_block: fix invalid shift in vc1_decode_p_mb() [19:16:21 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:c9415e815a99: avcodec/vc1_block: Fix invalid shifts in vc1_decode_i_blocks() [19:16:22 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:70432eac0b51: avcodec/pngdec: consider chunk size in minimal size check [19:16:23 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:02346292a334: avcodec/alsdec: fix mantisse shift [19:16:24 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:ce652324062a: avcodec/alsdec: Fix integer overflow of raw_samples in decode_blocks() [19:16:25 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:fad3ec89b7a6: avcodec/alsdec: Fix integer overflows of raw_samples in decode_var_block_data() [19:16:26 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:e8bb949ade40: avcodec/mpc8: Fix 32bit mask/enum [19:16:27 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:52b564ef1323: avformat/vividas: Fix infinite loop in header parser [19:16:28 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:1d72b5d2d522: avformat/vividas: Fix another infinite loop [19:16:30 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:9cd1e939cf26: avcodec/dds: Use ff_set_dimensions() [19:16:31 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:1fedba3c350a: avcodec/tiff: Enforce increasing offsets [19:16:32 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:950a21e83c74: avcodec/scpr: Use av_memcpy_backptr() in type 17 and 33 [19:16:33 CEST] <cone-625> ffmpeg 03Michael Niedermayer 07master:da8936969fe6: avcodec/hevc_refs: Optimize 16bit generate_missing_ref() [19:20:24 CEST] <ubitux> durandal_1707: the latest one that pops up in the git history [20:03:04 CEST] <tmm1> jkqxz: if the rc params being sent to libva are the same, do you have any other hunches on what might be different since ffmpeg 4.1 that would cause vbr not to work on some chips [20:12:00 CEST] <thardin> what is with these terrible hacks in ff_read_riff_info() [20:21:24 CEST] <thardin> postel's principle is a plague on computing [20:57:06 CEST] <durandal_1707> thardin: what about hacks? [20:58:29 CEST] <durandal_1707> michaelni: why are you ignoring my requests? [21:04:52 CEST] <thardin> durandal_1707: the avio_seek() thing in there for one. it's not covered by FATE, there's no explanation for it [21:08:03 CEST] <thardin> it got added in a merge commit [21:09:53 CEST] <thardin> it's not a huge deal of course, it's just that I find lavf is an excellent example of the "shotgun parser" anti-pattern [21:11:49 CEST] <thardin> hence all these fuzz fixes [21:21:21 CEST] <thardin> background: I've been playing around with parser combinators recently (https://github.com/UpstandingHackers/hammer) and gave writing a RIFF WAVE parser a shot [21:22:14 CEST] <thardin> after which it became abundantly clear why getting different multimedia software to cooperate is such a huge mess [21:44:49 CEST] <durandal_1707> pm me if i missed reply [21:57:05 CEST] <durandal_1707> pm if you are just bored [22:03:24 CEST] <Lynne> working on mlp got you bored? [22:03:28 CEST] <durandal_1707> anybody good with fractals math? [22:03:48 CEST] <durandal_1707> mlp is history nobody use [22:05:53 CEST] <durandal_1707> i want to zoom and pan inside sierpinski carpet [22:06:12 CEST] <durandal_1707> writing new vsrc filter [22:06:44 CEST] <durandal_1707> mlp need to wait until im back on linux [22:11:25 CEST] <durandal_1707> i need your prompt reply [22:23:36 CEST] <cehoyos> thardin: Ticket 1821 [22:26:50 CEST] <durandal_1707> what about it? [22:28:06 CEST] <cehoyos> What about what? [22:28:56 CEST] <durandal_1707> what about what about what about that ticket? [22:33:41 CEST] <cehoyos> Tomas asked about samples and explanation for a particular line of code, both are in ticket 1821 [22:34:05 CEST] <thardin> cehoyos: yet another case of being accomodating to broken encoders instead of making them fix their shit [22:34:40 CEST] <cehoyos> You misunderstand: FFmpeg is not a file validator, it aims to demuxer / decode everything that's in the wild [22:35:41 CEST] <thardin> I know [22:35:57 CEST] <cehoyos> It should also aim to fix regressions, sadly that's a little out-of-style nowadays;-( [22:36:27 CEST] <thardin> maybe one way to look at it is ffmpeg encodes all the ways in which other programs are broken [22:36:52 CEST] <BtbN> no, it should encode as correct as it possibly can [22:37:02 CEST] <BtbN> And be lenient while decoding [22:37:38 CEST] <thardin> this is postel's principle again. it's wrong [22:38:23 CEST] <durandal_1707> this vc++ 2015 line should be removed [22:38:28 CEST] <thardin> being lenient creates ever-increasing make-work [22:38:44 CEST] <BtbN> Not being lenient will break a ton of files [22:38:47 CEST] <thardin> partly because it's determining whether two decoders do the same thing is undecidable [22:38:56 CEST] <thardin> -it's [22:40:10 CEST] <durandal_1707> please close useless bug reports like one above [22:40:40 CEST] <thardin> I just have this nagging feeling that a huge class of problems will arise due to two or more multimedia capable programs having different opinions of what a given file *is* [22:41:15 CEST] <thardin> a bit like how different URI decoder implementations cause endless security problems [22:41:24 CEST] <durandal_1707> there is code to check for strict compliance [22:41:42 CEST] <BtbN> Being lenient about what a parser accepts does not mean leaving security holes [22:41:51 CEST] <BtbN> obviously leniency ends where it would leave security issues... [22:42:17 CEST] <thardin> I disagree. lenience often makes parsers harder to understand [22:42:20 CEST] <BtbN> Things get fun when the spec requires you to have a security issue to be compliant [22:42:22 CEST] <cehoyos> thardin: I wonder if I understand you correctly - are you talking about the file that starts with a jpg image and then becomes an mp3 audio file? [22:42:42 CEST] <thardin> cehoyos: that could be one issue. that's sadly not really solvable [22:42:49 CEST] <BtbN> ffmpeg aims to be real-world useable, not to the book following standards. [22:42:59 CEST] <cehoyos> Because for 99% of the samples, I believe there is no doubt what they are, the remaining ones have no "correct" solution, whatever is done can be useful (ex falso quod libet) [22:43:02 CEST] <BtbN> And there are _a lot_ of broken files out there people want to play [22:43:26 CEST] <thardin> indeed [22:48:26 CEST] <thardin> one issue is that a lot of things end up being cargo culted, especially when not in FATE [22:49:48 CEST] <durandal_1707> really. post examples. [22:50:50 CEST] <BtbN> There once were a bunch of people wo said similar things, and started writing new parsers in rust. Their stuff ended up being several magnitudes slower. But they sure were correct and safe. [22:52:17 CEST] <durandal_1707> rust is almost fast as C [22:52:35 CEST] <BtbN> It is, rust was not what made it slow. [22:53:03 CEST] <durandal_1707> then what was it? [22:53:23 CEST] <BtbN> It being a 100% strict implementation with implicit consistency checks everywhere [22:53:59 CEST] <BtbN> I think it was a h264 parser they re-implemented or something. And it was almost unable to keep up in real time. [22:54:07 CEST] <durandal_1707> ugh [22:54:46 CEST] <thardin> you can make that stuff cast though, if you use the right tools [22:54:49 CEST] <BtbN> They wrote a blog-post about their findings somewhere on Mozillas pages [22:54:51 CEST] <thardin> s/cast/fast/ [22:55:23 CEST] <BtbN> So then you make a safe implementation, and start introducing hacks to make it fast. Fantastic. [22:55:32 CEST] <BtbN> Same thing, just backwards. [22:55:53 CEST] <thardin> no. you can for example generate a correct implementation that compiles to a fast one [22:56:46 CEST] <thardin> there's no need for paranoid checks if you know everything is correct [22:57:00 CEST] <BtbN> How do you know everything is correct if you don't check everything? [22:57:36 CEST] <durandal_1707> lol [22:58:11 CEST] <thardin> that entirely depends. you don't need array bounds checks if your tooling checks all the way through that nothing can write out of bounds [22:58:28 CEST] <thardin> then your code is fast, and can't crash [22:58:35 CEST] <thardin> just as an example [22:58:53 CEST] <BtbN> Sounds like something that doesn't work in reality. [22:59:32 CEST] <thardin> it does. I have some embedded code that works exactly that way [23:00:04 CEST] <BtbN> If you're parsing a potentially malicious file, you can't just assume stuff is just right. You need to check everything that can cause harm. [23:00:21 CEST] <thardin> yes, and reject or otherwise deal with such files. that will always be the case [23:00:30 CEST] <thardin> unless you want exploits of course [23:00:39 CEST] <BtbN> So we do need the checks after all. [23:01:13 CEST] <thardin> of course. but you can be very specific about what checks are needed [23:01:40 CEST] <BtbN> That's what the current code is trying to do. And clearly doing that is hard to get 100% correct. [23:01:48 CEST] <thardin> yep [23:02:17 CEST] <thardin> I have about 1200 lines of verified code in one project [23:02:37 CEST] <durandal_1707> verified how? [23:03:00 CEST] <thardin> frama-c, and related backends (why3, coq, alt-ergo etc.) [23:04:30 CEST] <thardin> that's a bit extreme tho, since the amount of code I'm able to produce is in the 10s of lines per day [23:04:33 CEST] <cehoyos> https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=7413 Does anybody know what this is about? [23:06:35 CEST] <thardin> the trick is finding a sweet spot. it's no use if you end up being entirely unproductive [23:07:15 CEST] <BtbN> fuzzing seems to be pretty effective at finding a bunch of weird edge cases nobody ever thought about [23:07:30 CEST] <thardin> yeah fuzzing is great. afl especially [23:07:42 CEST] <thardin> but it's also a huge hack [23:08:35 CEST] <durandal_1707> cehoyos: http://ffmpeg.org/ffmpeg-codecs.html#libtwolame [23:08:35 CEST] <thardin> I've been meaning to write a blog post comparing some of these methods. cost vs benefit. if formal verification was cheap enough it'd be ideal [23:09:07 CEST] <thardin> it's only recently become useful enough to produce code at the reta of tens of lines per day rather than 1-2 lines per day [23:09:49 CEST] <cehoyos> Bitstream peak data == energy level? Don't we also need this in the native encoder? [23:10:16 CEST] <durandal_1707> useless stuff [23:12:41 CEST] <cehoyos> The user seemed to indicate that the files don't completely work in some editors without it [23:12:56 CEST] <cehoyos> But do you know if bitstream peak data and energy level are the same thing? [23:13:19 CEST] <durandal_1707> ask authors of audition [23:13:52 CEST] <BtbN> it's probably some hack to allow audio editors to show a peek meter without decoding [23:18:26 CEST] <cehoyos> It appears more like a part of the mp2 specification than a hack... [23:19:44 CEST] <durandal_1707> google is your friend [23:20:46 CEST] <durandal_1707> how fuzzing can be huge hack? nonsense [23:26:34 CEST] <thardin> not fuzzing itself, but the fact that we need to use it [23:27:39 CEST] <thardin> we are extremely poor in how much we can reason about our code [23:27:44 CEST] <BtbN> feel free to start a rewrite from scatch with validated code. [23:27:51 CEST] <thardin> static analysis helps a bit, but only so much [23:28:44 CEST] <thardin> BtbN: I've done some experiments in that direction, but it's.. slow-going. the parser combiner approach seems like it gives better returns [23:31:14 CEST] <thardin> and one can just put ffmpeg inside a vm as a way to deal with untrusted input [23:31:44 CEST] <BtbN> ... [23:31:51 CEST] <Compnno> i still say with enough input we can assert everything [23:32:01 CEST] <Compnno> e.g. youtube or facebook sample size [23:32:10 CEST] <Compnno> then sandbox the assert fails [23:33:01 CEST] <Compnno> an avi header, for example should almost always fall within a known range... [23:41:57 CEST] <Compnno> of course the code would get ugly. would need a way to organize a ton of assertion values [23:42:03 CEST] <cone-574> ffmpeg 03Marton Balint 07master:686755f02b02: avcodec/encode: only allow undersized audio frames if they are the last [23:43:59 CEST] <cone-574> ffmpeg 03Carl Eugen Hoyos 07master:ea56af889560: lavc/zmbvenc: Do not left-shift negative values. [00:00:00 CEST] --- Mon Aug 12 2019

1 0

ffmpeg-devel.log.20190831
by burek 01 Sep '19

01 Sep '19

[00:18:39 CEST] <kierank> apparently deblock is 3 pixels [00:18:44 CEST] <kierank> so who knows where that magic number comes from [00:39:26 CEST] <BBB> kierank: 16 is probably "bottom of mb" (instead of top, which is mb_y)? [00:41:45 CEST] <kierank> yes but why does it do "top -= deblock_border;" [00:41:51 CEST] <kierank> where deblock_border = (16+4) [00:42:03 CEST] <kierank> that's 100% illegal in slice threads, mode [00:42:22 CEST] <kierank> I need to add logic for deblock_mode=2 [00:42:26 CEST] <kierank> detect the top of the slice [00:42:55 CEST] <kierank> I need to read up on how the edges work in ffmpeg [01:03:22 CEST] <kierank> I don't understand why ff_thread_report_progress is called before deblock [01:03:33 CEST] <kierank> how can you tell downstream threads the frame is ready for use if it's not deblocked [01:04:26 CEST] <kierank> probably doesn't matter in frame thread mode [01:04:30 CEST] <kierank> single thread decoding a frame [01:04:41 CEST] <kierank> probably only matters in sliced threads and deblock_mode=1 mode [01:04:49 CEST] <kierank> which is rare/impossible [01:48:08 CEST] <kierank> ok starts to make sense [03:34:06 CEST] <kierank> so how do I know when I'm at the end of the slice [03:34:14 CEST] <kierank> sl->next_slice_idx is wrong often [13:37:36 CEST] <Lynne> anyone with an amd card on linux to test vulkan? [14:55:09 CEST] <cone-081> ffmpeg 03Paul B Mahol 07master:c79d6728a755: avfilter/vf_v360: add cubemap 1x6 layout [16:13:48 CEST] <jkqxz> Lynne: <http://www.jkqxz.net/~mrt/eac3ba932a16aab5465425e41a3a4567/vulkaninfo> (Mesa 19.2.0-rc1). [16:18:27 CEST] <ubitux> jamrial: i looked into the coverage thing [16:18:29 CEST] <ubitux> but i get "lcov: ERROR: no valid records found in tracefile coverage.info.in [16:18:43 CEST] <ubitux> are you actually able to make it work locally? [16:18:53 CEST] <ubitux> or it's a problem on my side? [16:19:37 CEST] <jamrial> i just looked at http://coverage.ffmpeg.org/ and saw the last run was may 2018, so assumed your client died or got stuck [16:19:48 CEST] <jamrial> didn't try to run lcov locally [16:19:59 CEST] <ubitux> the compilation works fine, the fate run passes as well [16:20:07 CEST] <ubitux> but make lcov raises that error here [16:20:17 CEST] <ubitux> with a lot of warnings such as: [16:20:19 CEST] <ubitux> geninfo: WARNING: cannot find an entry for vp8.c##ff77268aa0f07be80ca01b01d1b9e93e.gcov in .gcno file, skipping file! [16:20:30 CEST] <ubitux> (probably all files, leading to the finale error i pasted) [16:20:56 CEST] <jamrial> maybe a package update broke it [16:21:15 CEST] <ubitux> i tried upgrading lcov but got the same issue [16:21:39 CEST] <jamrial> :( [16:29:42 CEST] <jkqxz> tmm1: If you need an empty device it's probably better to make it with alloc()/init() rather than adding hacks to create(). [16:30:29 CEST] <Lynne> jkqxz: that's very basic, there's basically nothing to test there, I thought at least you'd be able to import/export fds/dmabufs like on intel [17:29:01 CEST] <durandal_1707> ubitux: clean all environment of stalled files? [17:29:20 CEST] <ubitux> isn't fate doing that at every run? [17:29:37 CEST] <durandal_1707> dunno [17:35:24 CEST] <cone-081> ffmpeg 03Michael Niedermayer 07master:a370582ba9c4: tools/target_dec_fuzzer: Init parsepkt [18:15:04 CEST] <cone-081> ffmpeg 03Marton Balint 07master:765c56bfa903: avformat/mpegts: fix teletext PTS when selecting teletext streams only [18:15:05 CEST] <cone-081> ffmpeg 03Marton Balint 07master:2e31774b409d: avformat/avidec: add support for recognizing HEVC fourcc when demuxing [18:15:06 CEST] <cone-081> ffmpeg 03Marton Balint 07master:ce1fcc8cede2: avformat/utils: return pending IO error on EOF in av_read_frame() [18:17:15 CEST] <JEEB> did we have any PGS samples in fate? [18:17:22 CEST] <JEEB> checked under subs and it didn't seem to have [18:17:29 CEST] <JEEB> *sub/ [18:17:58 CEST] <JEEB> I'm thinking of finally getting to making that FATE test for that one sub2video use case which I think is still borked in master [18:18:15 CEST] <JEEB> which I didn't merge my fix for because I never had the time to get the FATE test going :P [18:19:13 CEST] <JEEB> nothing under tests for "pgs" in git grep [18:19:16 CEST] <JEEB> so I guess we don't [18:19:41 CEST] <JEEB> I'll test with the DVD subtitle file first I guess [18:20:02 CEST] <JEEB> if it has something specific with the mux of the PGS-in-MPEG-TS file, then I'll have to poke a bit more [18:33:41 CEST] <kierank> durandal_1707: I fixed bug kinfa [18:33:44 CEST] <kierank> Kinda [18:41:40 CEST] <cone-081> ffmpeg 03Michael Niedermayer 07master:679f34089060: avutil/mathematics: Fix 2 overflows in av_add_stable() [18:41:41 CEST] <cone-081> ffmpeg 03Michael Niedermayer 07master:6962fd586e1a: avcodec/vc1_block: Check for double escapes [18:41:42 CEST] <cone-081> ffmpeg 03Michael Niedermayer 07master:9c6b4004928e: avcodec/vc1dec: Require res_sprite for wmv3images [18:41:43 CEST] <cone-081> ffmpeg 03Michael Niedermayer 07master:fe536b6d9984: avcodec/vc1_block: Check the return code from vc1_decode_p_block() [18:41:44 CEST] <cone-081> ffmpeg 03Michael Niedermayer 07master:5a3dee65d4fa: tools/target_dec_fuzzer: adjust pixel threshold for TRUEMOTION2, as it allows coding gigantic images on tiny input [18:41:45 CEST] <cone-081> ffmpeg 03Michael Niedermayer 07master:cc78783ce5e8: avcodec/truemotion2: Fix multiple integer overflows in tm2_null_res_block() [18:43:00 CEST] <cpplearner> Guys, I want to save a complete list of I-frame timestamps to seek in demand. In this case, which timestamp do I need to save, pts or dts? [18:51:11 CEST] <cpplearner> Sorry, I'll ask in #ffmpeg. Have a nice day! [18:54:58 CEST] <thardin> both, probably [19:35:17 CEST] <thardin> hum, cinepak.c accepts empty frames if they come with a palette change [19:35:22 CEST] <thardin> something the vintage decoders do not [19:52:29 CEST] <jamrial> thardin: 9033920bec9 should be reverted once my ff_reget_buffer patch is commited [19:55:14 CEST] <thardin> agreed [19:55:27 CEST] <thardin> so this nonsense has been going on for at least a year [19:56:17 CEST] <thardin> silently accepting and outputing nothing is like the worst thing one can do [19:56:44 CEST] <thardin> I'm going to have it simply reject any file where the strips don't cover the entire frame [20:02:38 CEST] <durandal_1707> vel0city: why dngs have darker colors compared to dcraw? [20:30:16 CEST] <kierank> Very quiet today [20:52:21 CEST] <thardin> I also see it counts a frame as a keyframe if the first strip is marked as intra, even if the rest of them are not [20:52:45 CEST] <thardin> which could explain why it outputs crap on seeking in certain files [20:53:33 CEST] <jamrial> thardin: it should unref s->frame on seeking, so it needs a flush() callback [20:54:57 CEST] <thardin> adding a TODO about that [22:07:25 CEST] <durandal_1707> kierank: fixed issue? [22:08:03 CEST] <JEEB> pushing out frames not yet done [22:08:43 CEST] <kierank> durandal_1707: kind of [22:08:46 CEST] <kierank> bframes don't work [22:08:53 CEST] <kierank> but you should be using bframes in lowlatency mode [22:10:12 CEST] <durandal_1707> never worked with bframes [22:10:21 CEST] <kierank> code was not touched for 11 years [23:48:07 CEST] <Chagall> can I get a review on patches 14408, 14409, 14410? [00:00:00 CEST] --- Sun Sep 1 2019

1 0

ffmpeg.log.20190831
by burek 01 Sep '19

01 Sep '19

[01:17:13 CEST] <kevinnn> does anyone have any suggestions as to how to make x264 compress quicker? [01:17:29 CEST] <kevinnn> Here's the tunings I currently have: https://pastebin.com/KecTc1Js [01:18:42 CEST] <BtbN> use a faster preset [01:19:06 CEST] <kevinnn> I have tuned ultrafast [01:19:09 CEST] <kevinnn> as you can see [01:19:21 CEST] <kevinnn> I am trying to encode at 60fps [01:19:32 CEST] <kevinnn> but the encoder is barely able to encode at 60fps [01:19:52 CEST] <kevinnn> often taking anywhere from 10ms to 20ms [01:24:40 CEST] <kevinnn> x264 is also using a fairly high amount of CPU as well, pretty much putting all 4 of my cores at 50%. anyway to reduce this? [01:39:31 CEST] <furq> kevinnn: do you actually need zerolatency [01:42:25 CEST] <furq> i guess from intra refresh and the fact that you're measuring frame timings that you do [01:45:23 CEST] <kevinnn> furq: yes it is a live stream [01:45:30 CEST] <kevinnn> sorry for taking a few minutes to reply [01:45:41 CEST] <kevinnn> so I really need this to be live [01:46:04 CEST] <kevinnn> I am willing to sacrifice on quality big time if it'll save me CPU [01:46:14 CEST] <kevinnn> can't sacrifice on FPS... [01:46:30 CEST] <kevinnn> also I don't control the resolution of the images coming in [01:50:03 CEST] <furq> there's not really any more you can do to sacrifice quality [01:50:15 CEST] <furq> you could probably bump the thread count though [03:30:56 CEST] <fling> How to buffer for a second before the output? [05:16:43 CEST] <kepstin> kevinnn: your use case is a good candidate for a hardware encoder if you have one on the system (intel quicksync? nvidia gpu?) [05:27:27 CEST] <fling> How do I read a pipe from gstreamer? [05:27:48 CEST] <ossifrage> mp4 is a really annoying format, not being able to play a stream that is currently being encoded [05:28:00 CEST] <fling> ossifrage: try nut [05:28:07 CEST] <fling> ossifrage: you can also have multiple outputs [05:28:33 CEST] <ossifrage> nut? [05:28:58 CEST] <fling> nut [05:29:07 CEST] <ossifrage> what is nut? [05:29:22 CEST] <ossifrage> (google was not helpful) [05:29:39 CEST] <fling> ffmpeg -f whatever & -c:v something /where/is/your/output.nut [05:29:47 CEST] <fling> ossifrage: just another container [05:29:50 CEST] <ossifrage> ah [05:29:56 CEST] <fling> ossifrage: also survives out of space condidions :P [05:32:44 CEST] <furq> ossifrage: https://ffmpeg.org/nut.html [05:33:40 CEST] <ossifrage> I guess nut could be useful for playing, but sadly for what I'm trying to do I'm stuck with mp4 [05:34:02 CEST] <fling> ossifrage: what are you trying to do? [05:34:05 CEST] <furq> you can just remux to mp4 when you're done [05:34:29 CEST] <fling> ossifrage: also you can have the second nut pipe output to ffplay [05:34:35 CEST] <fling> ossifrage: to be able to watche what are you recording [05:36:32 CEST] <ossifrage> okay nut is cool: " File is apparently being appended to, will keep retrying with timeouts." [05:38:55 CEST] <ossifrage> fling, the end result needs to be playable in a web browser without help, so h.264+mp4 is pretty much the only option [05:39:36 CEST] <fling> >> < ossifrage> mp4 is a really annoying format, not being able to play a stream that is currently being encoded [05:39:48 CEST] <fling> just add the second nut output and pipe it to ffplay [05:39:59 CEST] <fling> to be able to play it [05:40:53 CEST] <furq> that's not really ideal because that'll kill the whole process if you close the player [05:41:02 CEST] <ossifrage> (this is kinda funny to watch, the input is 4fps, the output is 30fps, but it is being heavily buffered, so it has this neat start/stop playback) [05:41:54 CEST] <furq> with that said if this is a live input then using mp4 will also give you an unplayable file if anything goes wrong [05:42:01 CEST] <furq> so you should really use something else and remux [05:42:24 CEST] <furq> (this is true for all inputs but presumably if an encode of a file source drops out you'd just start again) [05:43:37 CEST] <ossifrage> furq yeah it is coming off a live camera (I was playing with making a timelapse) but if do it for real I'll be doing it in C not in the shell [05:44:04 CEST] <furq> you'd still have the same problem if you're using lavf [05:46:46 CEST] <ossifrage> Yeah, it is the silly stuff in this project that has been hard. Dealing with the hardware is easy, multiplexing the video and getting it to play back in a browser has been a pain in the ass [05:47:58 CEST] <fling> tree live inputs/outputs not worked fine with ffmpeg so I tried to use gstreamer istead [05:48:08 CEST] <fling> but with gstreamer I'm getting fps spikes on the output [05:48:21 CEST] <fling> it is playing at 1000fps then 0fps for couple of seconds [05:49:49 CEST] <fling> The idea is to pipe it via ffmpeg to fix fps :P [05:53:03 CEST] <fling> So how do I buffer the input for a second before starting the output? [05:54:00 CEST] <ossifrage> is there a way to force the file input to retry with timeouts? When I was coding at 4fps mpv/ffmpeg would detect the file being appended, but at 1fps it doesn't [05:54:33 CEST] <fling> ossifrage: what are you trying to do? :P [05:54:44 CEST] <fling> maybe use pipe instead of the file? [05:55:48 CEST] <ossifrage> fling, I was amazed it magically detected that the file was being appended to (input 4fps, output 30fps) but at 1fps in the time between writes was too long for it to detect the append [05:56:27 CEST] <ossifrage> (there is a follow option) [06:02:03 CEST] <ossifrage> Ah, it gets upset near the live edge: "Last frame must have been damaged 36438323 > 36385256 + 32767" [06:03:43 CEST] <fling> named pipe [06:08:33 CEST] <ossifrage> fling, got it to work with 'ffplay -follow 1 blah.nut [06:09:13 CEST] <ossifrage> the data is safe on disk and I get to watch it consume frames [06:09:34 CEST] <fling> ok [06:14:01 CEST] <ossifrage> at 0.25fps, the internal ffmpeg buffer is really large [06:32:30 CEST] <fling> Is not there a workaround for three or more live inputs/output? [10:40:33 CEST] <fling> How to pipe from gstreamer properly? [10:40:47 CEST] <fling> Can I tell it to buffer the input for a second before doing output? [11:16:58 CEST] <durandal_1707> this is not gstreamer support channel [13:54:46 CEST] <richar_d> does anyone know what options to pass to ffmpeg to output iOS-compatible video? [13:55:10 CEST] <BtbN> define "iOS Compatible video". [13:56:04 CEST] <richar_d> video that plays on recent Apple devices [13:56:15 CEST] <BtbN> And what constraints does that impose? [13:56:23 CEST] <BtbN> Does it not play any standard formats? [14:02:25 CEST] <richar_d> they support, among other formats, MPEG-4, YUV420p, AVC, Main L3.1, and I have a command that outputs videos that meet this specification, but I remember having some problems playing them when I last attempted this a few months ago. I was hoping someone else had done the hard work& [14:05:27 CEST] <BtbN> I'd expect them to play any standard mp4 [14:05:32 CEST] <BtbN> if not, they're not worth their money really [14:06:43 CEST] <pink_mist> well they aren't worth their money [14:06:54 CEST] <pink_mist> half the price and they'd be much closer [14:09:24 CEST] <JEEB> richar_d: the container depends on what you're trying to do (streaming, files stuck on the device), but generally any modern iOS device since 3GS or whatever it was should more or less take as video H.264 high or main profile, level 4.1 with any sane resolution. and then audio is AAC. [14:09:31 CEST] <JEEB> it's not really harder than that :P [15:32:04 CEST] <mknod> Hello. [15:32:08 CEST] <mknod> cat <(ffmpeg -i music.m4a -f singlejpeg -) > /dev/null [15:32:25 CEST] <mknod> Does anyone know why ffmpeg hangs? [15:44:14 CEST] <durandal_1707> mknod: from where you got that line? [15:44:57 CEST] <mknod> durandal_1707, I wrote it myself. Why I need or want to use this syntax is not really relevant though... Since this is just supposed to work :) [15:45:50 CEST] <mknod> this specific line is just for illustration [15:46:10 CEST] <durandal_1707> i first time see that [15:46:51 CEST] <durandal_1707> which shell is that? [15:47:04 CEST] <mknod> Bash [15:47:17 CEST] <durandal_1707> and what you try to accomplish? [15:48:07 CEST] <durandal_1707> -f singlejpeg muxer does not exist [15:48:14 CEST] <mknod> avoiding to write a temporary file by using a process substitution instead [15:48:15 CEST] <mknod> https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Process-Su… [15:48:48 CEST] <mknod> durandal_1707, it's not my problem. `ffmpeg -i music.m4a -f singlejpeg - > /dev/null` does work. [15:55:58 CEST] <durandal_1707> doesnt hang here [15:56:33 CEST] <mknod> durandal_1707, I got it. It's somehow waiting for user input on stdin [15:56:51 CEST] <mknod> so feeding stdin with /dev/null fixed it [15:57:16 CEST] <JEEB> durandal_1707: it does funny enough. see -formats |grep "jpeg" [15:58:11 CEST] <JEEB> mknod: stderr should contain anything ffmpeg.c outputs and I can't see in that limited command line anything that would make it request stdin input o_O [15:58:39 CEST] <durandal_1707> JEEB: committer is guess who, its silly change for different mime type [15:59:02 CEST] <JEEB> I know that if you were to have a normal file as output it would ask if you want to rewrite it, but I don't see any other reason for it to require input o_O [15:59:08 CEST] <JEEB> "-" is stdout after all [16:00:21 CEST] <mknod> JEEB, I'm guessing it's because you can interact with it using keyboard inputs? [16:00:55 CEST] <JEEB> mknod: you technically can with stuff like left/right arrow to change the log level, but it shouldn't *require* any of that [16:01:33 CEST] <JEEB> I've got plenty of shell scripts where I set output to stdout just to make sure FFmpeg can't use any tricks it could utilize when having something seekable written [16:01:44 CEST] <JEEB> and it never required a forced input from the shell [16:02:14 CEST] <mknod> just running ffmpeg in the background results in the same weird behavior [16:02:24 CEST] <mknod> ffmpeg -i music.m4a -f singlejpeg - > /dev/null & [16:02:29 CEST] <mknod> ... hangs forever [16:02:42 CEST] <JEEB> if true sounds like a boog in ffmpeg.c [16:03:05 CEST] <JEEB> I wonder if there's an option to disable the key inputs if that really is what's blocking it [16:03:10 CEST] <mknod> I swear it's true [16:03:37 CEST] <JEEB> ah [16:03:39 CEST] <JEEB> -stdin 0 [16:03:42 CEST] <JEEB> try that [16:03:55 CEST] <JEEB> that seems to control the boolean stdin_interaction [16:04:17 CEST] <JEEB> which then controls calls to "check_keyboard_interaction" [16:05:55 CEST] <mknod> seems promising especially after reading the manpage but, same issue [16:06:33 CEST] <mknod> and they do mention < /dev/null as an alternative [16:06:40 CEST] <TheDrode> Morning! [16:06:43 CEST] <JEEB> lol [16:07:12 CEST] <JEEB> anyways, you can check if there's an issue already on trac regarding this. not sure how much one can do about it and which part is then causing it :P [16:08:15 CEST] <mknod> JEEB, let's consider this solved for now, I seem to have another problem [16:09:25 CEST] <mknod> ffmpeg -loop 1 -framerate 2 -i <(ffmpeg -i "$file_input" -f singlejpeg - < /dev/null) -i "$file_input" -c:v libx264 -preset medium -tune stillimage -crf 18 -c:a copy -shortest -pix_fmt yuv420p "$file_output" [16:09:36 CEST] <mknod> this is the full command [16:09:58 CEST] <mknod> I can't figure out how to force the input format to JPEF [16:10:01 CEST] <mknod> JPEG* [16:10:54 CEST] <JEEB> could it be that you want to just get the embedded image out? [16:11:02 CEST] <mknod> to a temporary file? [16:11:09 CEST] <JEEB> no, I mean in general [16:11:09 CEST] <mknod> please, no! [16:11:32 CEST] <JEEB> like if you are taking in a file re-encoding the video track into it extracting it as a JPEG [16:11:39 CEST] <JEEB> *-extracting it [16:11:41 CEST] <TheDrode> I am still trying to get the colable5011 device to work, the video is mostly clean but, i keep getting this artifacts sometimes, this is the command: [16:11:42 CEST] <TheDrode> https://anonymousfiles.io/yKP15lF4/ [16:11:45 CEST] <JEEB> because that's not extraction but re-encoding [16:11:53 CEST] <TheDrode> ffmpeg -loglevel debug -f hls -re -i http://192.168.201.3:5080/LiveApp/streams/005903764339232681635560.m3u8 -vcodec copy -s 1920x1080 -deinterlace -tune zerolatency -acodec mp2 -ab 64k -ac 1 -ar 44100 -f rtp_mpegts -fec prompeg=l=10:d=10 -r 23 rtp://10.10.13.3:1001 [16:11:57 CEST] <mknod> JEEB, the input file is an audio file [16:11:59 CEST] <TheDrode> nothing weird on logfile [16:12:05 CEST] <JEEB> mknod: I could gather that [16:12:46 CEST] <mknod> I may have missed your point [16:13:07 CEST] <JEEB> but then you are making a video out of it, and you want that to be JPEG? at that point I'm starting to question if you actually needed to re-encode it [16:13:23 CEST] <JEEB> thus I'm trying to gather what the overall thing you're trying to do is [16:13:24 CEST] <mknod> JEEB, no, the video is mkv [16:14:14 CEST] <mknod> basically I'm trying to convert a properly tagged audio file into a youtube friendly video, using the audio AND the cover image from the input file [16:14:27 CEST] <JEEB> ok, so in that case you do not want JPEG for the output of the video [16:14:44 CEST] <mknod> the output of the video is mkv [16:14:45 CEST] <JEEB> also if you are making a *video* with more than one frame, stillvideo will not be to your liking I think [16:14:56 CEST] <mknod> file_output="${meta_artist} - ${meta_title}.mkv" [16:14:59 CEST] <mknod> ^ this [16:15:00 CEST] <JEEB> although I'm not sure if stillvideo sets keyint to 1 [16:15:40 CEST] <JEEB> mknod: ok so what you want is for the image to be repeated at a certain frame rate until the audio finishes [16:16:17 CEST] <mknod> JEEB, I used an example from the ffmpeg website as a starting point, and this does work if I provide a regular JPEG file [16:16:37 CEST] <mknod> me being too lazy to use an intermediate temporary file is the problem here [16:16:59 CEST] <JEEB> I'm not fully understanding why you just don't map the "video" stream from the audio file to begin with [16:17:14 CEST] <JEEB> why teh whole subprocess and all [16:17:29 CEST] <JEEB> even temporary files sound weird in this case [16:17:32 CEST] <kepstin> mknod: hmm? no intermediate file needed, adding a static picture to an audio track can be done easily with a single ffmpeg command [16:17:36 CEST] <JEEB> yea [16:18:04 CEST] <JEEB> kepstin: if you have the filter to duplicate frames at a frame rate and all in your memory or link somewhere, please feel free [16:18:28 CEST] <mknod> kepstin / JEEB, that's where I started: http://trac.ffmpeg.org/wiki/Encode/YouTube [16:18:30 CEST] <JEEB> I don't remember the video filter that duplicates a frame so you can use -shortest and end when the music finishes [16:18:51 CEST] <mknod> I'm tweaking the command from the third example [16:19:20 CEST] <kepstin> ffmpeg -i audio.mp4 -i picture.jpg -vf loop=loop=-1:size=1:start=0 -map 0:a -map 1:v -c:a copy -shortest output.mp4 [16:19:33 CEST] <JEEB> kepstin: he has a music file with tagged picture [16:19:45 CEST] <JEEB> so he probably wants to map the video and audio track from the audio file [16:20:12 CEST] <kepstin> oh, does it show up as a video track in the ffprobe output on the file? [16:20:13 CEST] <mknod> yes. I want to use the embedded image (could equally use exiftool for the job) [16:20:25 CEST] <kepstin> if so, drop the -i picture.jpg and change the -map 1:v to -map 0:v [16:21:47 CEST] <JEEB> also looking at the example on that trac page just a remux into mkv apparently works with just one frame in the video? [16:22:03 CEST] <JEEB> I have no idea if that actually works with youtube, but if it does that's actually quite a bit more simple [16:22:18 CEST] <JEEB> this example http://trac.ffmpeg.org/wiki/Encode/YouTube#Utilizingtheincludedalbumcoverart [16:22:19 CEST] <mknod> looks like because the video file is exactly the same size as the audio file [16:24:32 CEST] <mknod> JEEB, nice find [16:25:12 CEST] <kepstin> note that even if that works in youtube, it's problematic in general since many players will have trouble seeking in such a file. [16:25:24 CEST] <JEEB> kepstin: youtube does frame rate conversion anyways [16:25:29 CEST] <JEEB> so as long as it takes that in, it should be ok [16:27:45 CEST] <mknod> I'm still curious as to how force the input format when providing a anonymous pipe instead of a regular file [16:28:07 CEST] <JEEB> container format is -f before -i [16:28:08 CEST] <mknod> such as -i <(file content is output to stdout here) [16:28:26 CEST] <JEEB> for example -f mpegts -i - [16:28:32 CEST] <mknod> yes, but couldn't find any working forlat for JPEG [16:28:40 CEST] <mknod> format* [16:28:50 CEST] <JEEB> jpeg_pipe or mjpeg [16:29:01 CEST] <mknod> "The video has failed to process. Please make sure you are uploading a supported file type." [16:29:08 CEST] <JEEB> aww [16:29:15 CEST] <JEEB> then go with the loop filter kepstin noted [16:29:24 CEST] <JEEB> with just mapping the video and audio streams from the input file [16:30:27 CEST] <JEEB> mknod: you can see formats by doing `ffmpeg -formats |grep jpeg` for example [16:30:36 CEST] <mknod> JEEB, yes, I did already [16:30:49 CEST] <mknod> and neither jpeg_pipe nor mjpeg helped [16:30:52 CEST] <JEEB> mjpeg I think is the classic thing for raw JPEG. D means it's implemented for inputs, E for outputs [16:31:07 CEST] <JEEB> mknod: that's really weird... [16:34:05 CEST] <mknod> that's the current (non working) command: [16:34:17 CEST] <mknod> ffmpeg -loop 1 -framerate 2 -f jpeg_pipe -i <(ffmpeg -i "$file_input" -f singlejpeg - < /dev/null) -i "$file_input" -c:v libx264 -preset medium -tune stillimage -crf 18 -c:a copy -shortest -pix_fmt yuv420p "$file_output" [16:34:35 CEST] <mknod> singlejpeg would have been more than adequate [16:34:40 CEST] <JEEB> btw, I think you should give kepstin's last single-input alternative a go first :P [16:34:53 CEST] <JEEB> since that definitely seems like the sane solution instead of doing a random JPEG re-encode in the middle [16:34:55 CEST] <mknod> I failed to understand their solution [16:35:09 CEST] Action: mknod never played with ffmpeg before [16:35:30 CEST] <JEEB> you have a single input, with two streams. you map the video and audio. you pass the video stream into a filter that you tell to duplicate that first frame for all eternity [16:35:44 CEST] <kepstin> here, i'll retype it all together: ffmpeg -i "$file_input" -vf loop=loop=-1:size=1:start=0 -map 0:a -map 0:v -c:a copy -shortest output.mp4 [16:36:02 CEST] <JEEB> then you map the audio stream and have that copied or re-encoded. then add -shortest to finish when the shortest stream finishes (which will be audio) [16:36:18 CEST] <JEEB> (because the video is an eternal loop) [16:36:23 CEST] <kepstin> and note that you should also add the encoding options (-pix_fmt yuv420p in particular) [16:36:52 CEST] <JEEB> because while looking into the peculiarities of FFmpeg is fun, just using a single command seems like the much saner alternative to get to where you seemingly want to go [16:37:17 CEST] <JEEB> without temporary files or using a sub-process to generate another JPEG out of the original JPEG [16:37:47 CEST] <JEEB> (we can then look into the peculiarities if you still care after you've got your workflow rolling) [16:37:47 CEST] <mknod> <JEEB> you have a single input, with two streams. [16:38:13 CEST] <mknod> are you referring to the embedded cover art as the second stream? [16:38:23 CEST] <JEEB> yes, because FFmpeg most often exposes it so [16:38:29 CEST] <JEEB> (with audio files) [16:39:20 CEST] <mknod> mmhm, what an unfortunate way to handle the metadata [16:39:33 CEST] <mknod> (which an embedded image is) [16:40:03 CEST] <JEEB> at least we then got a field that gets transferred if the demuxer notes it's cover art [16:40:16 CEST] <JEEB> so that applications not really interested in cover art but only actual video streams can handle it [16:41:43 CEST] <mknod> ffmpeg -i "06 Allies.m4a" -vf loop=loop=-1:size=1:start=0 -map 0:a -map 0:v -c:a copy -shortest -pix_fmt yuv420p output.mp4 [16:41:55 CEST] <mknod> is that correct kepstin? [16:42:54 CEST] <kepstin> something like that, yeah. [16:43:27 CEST] <kepstin> (note that in most ffmpeg builds, mp4 defaults to using libx264 video encoder with -crf 23 -preset medium, consider adding encoder options if you want something else) [16:43:28 CEST] <mknod> for some reason ffmpeg always complains when requiring it to write a .mp4, but .mkv seems to work [16:43:55 CEST] <JEEB> are you by chance outputting to a pipe? [16:44:13 CEST] <mknod> nope [16:44:26 CEST] <JEEB> then you might want to add -v verbose there and pastebin the log [16:44:28 CEST] <JEEB> thank you [16:44:38 CEST] <JEEB> and link the pastebin or whatever here [16:45:41 CEST] <mknod> what verbose level would you want me to use? [16:46:03 CEST] <JEEB> -v verbose [16:46:10 CEST] <JEEB> debug is way too verbose and verbose adds useful info [16:47:47 CEST] <mknod> https://termbin.com/pnq9 [16:47:53 CEST] <mknod> redirected both stderr and stdout [16:48:00 CEST] <JEEB> ah, alac [16:48:27 CEST] <JEEB> separate -c:a copy with -b:a 192k -c:a aac or so :) [16:48:33 CEST] <JEEB> s/separate/replace/ [16:48:39 CEST] <mknod> I'm literally lost in translation [16:49:07 CEST] <JEEB> basically the mp4 writer is crying foul when being fed alac audio [16:49:14 CEST] <JEEB> which -c:a copy is copying from input [16:49:27 CEST] <JEEB> not sure if that crying foul at this point is valid, but that's what you've got [16:49:49 CEST] <JEEB> thus, switching from copying the stream to re-encoding to 192 kbps AAC [16:49:58 CEST] <JEEB> which will go into the gaping mouth of the mp4 writer fine [16:50:33 CEST] <JEEB> hopefully this explains what the difference is and what went wrong in that log of yours [16:50:38 CEST] <JEEB> specifically > [mp4 @ 0x7fcf9980a800] Could not find tag for codec alac in stream #0, codec not currently supported in container [16:50:43 CEST] <JEEB> is the log line that showed the error [16:51:48 CEST] <JEEB> it would probably let you write the same thing from the smae module by just replacing mp4 with m4a which changes the mode the mp4 writer is operating under ;) [16:51:54 CEST] <mknod> JEEB, do you want me to provide the ALAC? [16:51:56 CEST] <JEEB> or mov [16:52:00 CEST] <JEEB> mknod: no need for that [16:52:19 CEST] <mknod> ffmpeg -v verbose -i "06 Allies.m4a" -vf loop=loop=-1:size=1:start=0 -map 0:a -map 0:v -b:a 192k -c:a aac -shortest -pix_fmt yuv420p output.mp4 [16:52:28 CEST] <JEEB> yup [16:52:36 CEST] <JEEB> that should go OK [16:53:06 CEST] <mknod> https://termbin.com/o75p [16:53:57 CEST] <JEEB> your FFmpeg seems drunk, or the error is higher there in the list [16:53:59 CEST] <JEEB> > Could not find tag for codec h264 in stream #1, codec not currently supported in container [16:54:03 CEST] <JEEB> "pardon my french?" [16:54:40 CEST] <mknod> I'm french too. Maybe that's why? [16:54:42 CEST] <JEEB> or the actual error is > Frame rate very high for a muxer not efficiently supporting it. [16:54:59 CEST] <JEEB> which you could attempt to fix with adding fps filter at the end of the filter chain [16:55:19 CEST] <JEEB> -vf 'loop=loop=-1:size=1:start=0,fps=24' [16:55:25 CEST] <JEEB> something like that, I think? [16:55:49 CEST] <JEEB> if that is valid and doesn't fix it, your FFmpeg is very, very drunk [16:56:02 CEST] <mknod> Ok, I'm too clueless about ffmpeg and video encoding in general. I'll dig the topic more prior to trying to get a working command. [16:56:29 CEST] <JEEB> the final error makes no sense and thus I'm trying to troubleshoot [16:57:34 CEST] <mknod> why I considered providing you the ALAC [16:57:50 CEST] <JEEB> I have some ALAC files and that really isn't the problem :) [16:58:08 CEST] <JEEB> the video track is the problem - the mp4 writer for some reason is saying it can't into h264. which is ?!?!?! [16:58:46 CEST] <JEEB> which made me think the problem was the error before that about the high frame rate that either the input or the filter module end up with (or at least high time base, which is what the error is technically about) [16:59:02 CEST] <mknod> I'm got to go but will give it another try or ten later for sure [16:59:10 CEST] <JEEB> sure [16:59:54 CEST] <mknod> thanks JEEB & kepstin [17:03:50 CEST] <fling> Can I tell it to buffer the input for a second before doing output? [17:04:46 CEST] <JEEB> can I ask why you are asking that? what are you attempting to do? [17:12:48 CEST] <fling> JEEB: I'm trying to stabilize fps in a gstreamer output [17:12:57 CEST] <fling> gstreamer -> ffmpeg -> rtmp [17:13:53 CEST] <JEEB> stdin shouldn't find an EOF so the issue is with something else? [17:14:50 CEST] <fling> I've not tried it yet ^ [17:15:07 CEST] <fling> Not piping from gstreamer yet I mean. Still not figured out how to do so properly : [17:16:09 CEST] <fling> gstreamer issue is it playing back to fast to a live rtmp output resulting in 1000 fps spikes with couple of 0fps seconds afterwards [17:16:42 CEST] <JEEB> so what are you using gstreamer for? [17:16:44 CEST] <fling> ffmpeg issue is my lack of knowledge of how to buffer the input for few seconds before starting to write the output [17:17:29 CEST] <fling> I'm using gstreamer to workaround ffmpeg's single threaded muxer not working nicely with three or more live inputs/outputs [17:17:37 CEST] <JEEB> ok [17:17:52 CEST] <JEEB> so where is the 1000fps coming from then if it's live input? [17:18:31 CEST] <fling> gstreamer is muxing h264 with aac encoded from pulse [17:18:46 CEST] <fling> Not sure where the fps spikes are coming from [17:18:52 CEST] <JEEB> what is your output container from gstreamer? [17:18:54 CEST] <fling> file output works just fine [17:19:03 CEST] <fling> flv for rtmp I'm having issues with [17:25:09 CEST] <another> mknod: JEEB: the ipod muxer supports alac [17:25:34 CEST] <JEEB> yes, but that isn't the problem at that point when mp4 is rejecting H.264 :P [17:28:34 CEST] <another> yes. i got that. fps filter [17:28:47 CEST] <another> however ipod doesn't support h264 :( [17:30:34 CEST] <another> *sigh* just use matroska i guess [17:31:52 CEST] <fling> or nut [17:32:20 CEST] <another> does youtube support as input? [17:34:16 CEST] <fling> JEEB: fps is not jumping when I'm muxing h264 alone without pulse [17:34:21 CEST] <fling> JEEB: this also works just fine with ffmpeg btw [17:34:42 CEST] <fling> pulseaudio sucks! ;D [17:35:19 CEST] <another> water is wet [17:40:58 CEST] <durandal_1707> no [17:41:09 CEST] <durandal_1707> pulseaudio rocks [17:41:21 CEST] <durandal_1707> you know nothing [17:41:51 CEST] <dastan> hello people [17:47:19 CEST] Action: fling does not know a thing [17:49:19 CEST] <qeed> the pulse of amerika [18:05:44 CEST] <JEEB> pulseaudio is OK, but like with all APIs you need to know how2 utilize it [18:05:54 CEST] <JEEB> all audio APIs tend to be anal about some things [18:50:48 CEST] <cpplearner> Guys, I want to save a complete list of I-frame timestamps to seek in demand. In this case, which timestamp do I need to save, pts or dts? [18:53:55 CEST] <Mavrik> dts. [18:54:07 CEST] <Mavrik> For decoding :) [18:54:29 CEST] <Mavrik> I-frames will have PTS == DTS anyway [18:54:36 CEST] <Mavrik> Otherwise they're not I-frames you need :) [18:57:56 CEST] <DHE> I've seen i-frames with pts>dts [19:00:16 CEST] <JEEB> yes, with b-frames you need delay :) [19:00:19 CEST] <JEEB> for the re-order later [19:01:17 CEST] <cpplearner> Hmm, can I ask you what ultimately dts != pts mean? I'm a newbie in this field. =/ [19:01:47 CEST] <DHE> When you have B frames (B stands for between), frames in the order I, P, B, P will actually be written to disk in the order 1,2,4,3 [19:02:10 CEST] <DHE> so there's the decode timestamp/order and the presentation/display order [19:02:49 CEST] <cpplearner> Oh, that's interesting. But, I-frame always holds pts=dts? [19:05:04 CEST] <DHE> it is required that dts <= pts since you can't show a frame that isn't decoded yet. so sometimes we'll give the first I frame dts=0 even though it's shown at time 1 for ordering and delayed processing reasons [19:09:29 CEST] <DHE> can't really say more, except I've seen x264 do it, and the x264 people know more about video encoding than I do so I trust them. :) [19:13:07 CEST] <cpplearner> Thanks for giving me some context. =) [20:07:33 CEST] <TheDrode> can i add... Don't know 3 seconds buffer [20:07:40 CEST] <TheDrode> ? [20:49:14 CEST] <johnjay> does ffmpeg have a way to dump all keyframes from an xvid codec file? [20:49:29 CEST] <JEEB> what sort of dumping. just the data into a JSON file or? [20:49:36 CEST] <johnjay> just raw images [20:49:52 CEST] <johnjay> i want to find an image possibly embedded in a video and only clue i have is it's a scene change [20:49:57 CEST] <johnjay> which generally is a key frame [20:50:16 CEST] <JEEB> not sure if ffmpeg.c has the selection based on frame type (only process X), but you definitely can do that with a video filter [20:50:17 CEST] <furq> -skip_frame nokey -i foo.avi out%03d.png [20:50:25 CEST] <JEEB> ok, there we go [20:50:27 CEST] <johnjay> ah thanks furq [20:50:31 CEST] <furq> or yeah the select filter has frame type selection [20:50:32 CEST] <johnjay> really i want any scene change but [20:50:39 CEST] <johnjay> i assume this is good enough [20:50:40 CEST] <furq> i think it might also have scenecut detection [20:50:46 CEST] <JEEB> it also has that, yes [20:50:50 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#select_002c-aselect [20:51:09 CEST] <JEEB> if someone has the time they should compare if scxvid (yes lol) or scenecut has better detection [20:51:33 CEST] <johnjay> scxvid...? [20:51:37 CEST] <johnjay> lol [20:51:41 CEST] <JEEB> scxvid is the classic tool which outputs frame times so that subtitle timers can get scene cut times [20:52:46 CEST] <JEEB> johnjay: it's still used bv people doing subtitles because its algorithm is better than x264's for scenecut purposes :) [20:52:59 CEST] <JEEB> basically it's xvid's scenecut algorithm ripped into a separate app [20:53:13 CEST] <JEEB> you run some raw YCbCr video through it and it outputs a text file [20:53:35 CEST] <johnjay> i see [21:36:24 CEST] <der_richter> from my tests the 'scene change detection' was better with scxvid [21:37:00 CEST] <der_richter> or rather it detected more scenes changes, might have had a bit more false positives though [21:37:07 CEST] <der_richter> it has been a while sinc ei tested it [23:16:21 CEST] <rooth> A bit of a dumb question. I've got an mp4-file with 1:audio stream and 1:video stream. The audio starts off fine but gets out of sync the longer the video runs, e.g. good in the start but slowly the audio lags behind. Is there any smart way I can get the video and audio synced? ... [23:16:26 CEST] <rooth> ... Should I use the -shortest option or something else? [00:00:00 CEST] --- Sun Sep 1 2019

1 0