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

[burek]

[02:07:42 CEST] <finalsummer> what is the proper way to fix hls .ts files that give a huge amount of 'Non-monotonous DTS in output stream' errors?
[02:08:24 CEST] <finalsummer> ffmpeg -fflags +igndts -i input.ts -codec copy test.ts
[02:08:41 CEST] <finalsummer> gives me audio errors and no audio with ffplay
[02:08:52 CEST] <finalsummer> [mpegts @ 0x7f1d00000940] start time for stream 1 is not set in estimate_timings_from_pts
[02:08:59 CEST] <finalsummer> [mpegts @ 0x7f1d00000940] Could not find codec parameters for stream 1 (Audio: aac ([15][0][0][0] / 0x000F), 0 channels): unspecified sample format
[03:45:19 CEST] <finalsummer> https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226706.html
[03:45:53 CEST] <finalsummer> this patch solved my issue, i am not sure if something similar has been implemented upstream since it was written though
[04:47:47 CEST] <T-D> if i want to upload a audio file to http website and i want people to play the audio without saving the file; what is best audio format to use
[04:52:20 CEST] <fling> finalsummer: what is the command line you are using?
[04:52:39 CEST] <fling> T-D: mp4
[04:54:43 CEST] <pink_mist> T-D: https://caniuse.com/#search=audio%20format has a few different ones, and the corresponding browsers/versions they work in
[04:55:09 CEST] <furq> T-D: aac in m4a is the most universally supported
[04:55:24 CEST] <T-D> furq ok thanks
[04:55:37 CEST] <furq> but if you already have it in mp3 then that's also fine
[04:55:42 CEST] <T-D> is m4a different from .mp4 or they are exaclty same
[04:55:48 CEST] <furq> they're more or less the same
[05:00:23 CEST] <fling> I'm going to try 0001-Introduce-force_dts_monotonicity-to-fix-timestamp-no.patch too
[05:04:26 CEST] <FishPencil> Is 4fps normal for vp9 encoding on an i7 at 4Ghz? I'm only seeing usage around 40%
[05:06:11 CEST] <fling> FishPencil: probably yes
[05:06:37 CEST] <FishPencil> jeez
[05:07:42 CEST] <furq> yeah vpx has terrible multithreading
[05:14:40 CEST] <fling> -force_dts_monotonicity does not really help
[05:15:26 CEST] <fling> [video4linux2,v4l2 @ 0x55cdfcc8e3a0] Incoming DTS error 200035, offsetting subsequent timestamps by 200035 to correct
[05:16:56 CEST] <fling> if 200035 is error number then they are also coming out of order :D
[05:17:19 CEST] <fling> also pulse dts are out of order too. Could this mean I have something wrong with my kernel?
[05:17:28 CEST] <fling> otoh I tested it on different hosts&
[05:30:28 CEST] <fling> JEEB: https://bpaste.net/show/1Em4
[05:31:05 CEST] <fling> JEEB: getting some bad dts in pulse also. Could this mean the muxer is actually bad in addition? :P
[09:13:24 CEST] <KodiakIT[m]> OK, couple questions: A) are there particular opts to strip certain (possibly non-standard?) tags from files with ffmpeg, or roughly equivalently, to only preserve certain ones on conversion? B) Is there any way to take multiple videos (namely widescreen and letterbox versions) and encode them in such a way as to then allow a user/the program to choose which video stream to use on playback?
[10:31:55 CEST] <finalsummer> -force_dts_monotonicity doesn't 'fix' it since the timestamp on the output is several hours wrong i just realized but i don't get any dts errors after it
[10:32:42 CEST] <finalsummer> fling: just ffmpeg -force_dts_monotonicity -i input.ts -codec copy test.ts
[10:32:58 CEST] <finalsummer> it fills the screen with messages but there aren't any when decoding it
[10:33:09 CEST] <finalsummer> decoding the output file that is
[10:45:21 CEST] <fling> finalsummer: is not there any better patch? :D
[10:45:36 CEST] <fling> Or should I find one for the kernel?
[10:47:41 CEST] <JEEB> fling: I hope you didn't start diving into the whole timestamp issues before figuring out the possible blocking issues :P
[10:47:51 CEST] <JEEB> because that was the one that was actually breaking your stream, not this
[10:48:14 CEST] <JEEB> and no, I think we pretty much validated with -debug_ts that the non-monotonic timestamps were coming from the lavd device
[10:48:20 CEST] <JEEB> I don't know how the *muxer* is at all related
[10:48:38 CEST] <JEEB> so either it's your device(s) or the lavd code
[11:06:48 CEST] <finalsummer> my file is a captured HLS stream. i have no idea, sorry
[11:36:02 CEST] <fling> JEEB: but I also see wrong timestamps in pulse!
[11:37:00 CEST] <JEEB> I don't think that's anything new?
[11:37:10 CEST] <JEEB> although it could be
[11:37:26 CEST] <JEEB> I don't remember the debug_ts output that you posted yesterday by heart
[11:39:53 CEST] <fling> I only noticed after patching ffmpeg
[11:40:10 CEST] <fling> heads are not for remembering!
[11:40:21 CEST] <JEEB> debug_ts had all that info btw. no idea what you patched and where
[11:41:56 CEST] <fling> JEEB: this patch https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/226706.html
[11:44:32 CEST] <JEEB> yea, I'm not sure how relevant that is to your case to be completely fair. I really wish you had kept to the one problem first, and then looked into the A/V desync after you had figured out the blocking problem (or what I supposed was a blocking problem)
[11:57:08 CEST] <fling> ok
[00:00:00 CEST] --- Mon Sep  9 2019