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

Mon Sep 2 03:05:04 EEST 2019

[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