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

[burek]

[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