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

Wed Nov 14 03:05:02 EET 2018

[00:06:34 CET] <auri_> Hello! I'm currently working with ffmpeg (cli) doing MPEG-DASH encoding/segmentation of lossless (FLAC) audio and have encountered interesting behaviour - it sets "codecs" xml attribute (part of MPD.Period.AdaptationSet.Representation) to "fLaC" and not "flac", where latter is the only way browsers accept it
[00:07:18 CET] <auri_> command is `ffmpeg -i <infile.flac> -c:a copy -strict -2 -f dash manifest.mpd`, nothing fancy
[00:08:14 CET] <JEEB> hint 1: -strict -2 is actually "-strict experimental"
[00:08:31 CET] <JEEB> otherwise i think it's a mktag issue
[00:08:51 CET] <BtbN> I think that's the official fourcc for flac
[00:09:11 CET] <JEEB> yea, the ogg/flacdec lavf things use that identifier
[00:09:14 CET] <JEEB> fLaC
[00:09:31 CET] <auri_> if thats the case, should I report it as a bug to mozilla since firefox doesn't accept it?
[00:09:39 CET] <JEEB> no, that's separate
[00:09:45 CET] <JEEB> need to find the specification for it
[00:10:22 CET] <JEEB> https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt
[00:10:33 CET] <JEEB> > + The codingname of the sample entry is 'fLaC'.
[00:10:45 CET] <JEEB> ok, so the mp4 side sample entry identifier is that
[00:12:31 CET] <auri_> I was hesitant to ask here because its just the browsers that won't accept it
[00:12:40 CET] <auri_> players like vlc and mpv play it back just fine
[00:12:48 CET] <JEEB> yes, because mpv f.ex. just uses lavf
[00:12:55 CET] <JEEB> VLC has its own mp4 demuxer
[00:13:15 CET] <JEEB> but it seems like it was never properly finalized, and the specification doesn't touch the DASH manifest side
[00:13:39 CET] <auri_> oh, its always good to stumble on undocumented behaviour
[00:13:50 CET] <auri_> right now I just modify the manifest myself
[00:14:01 CET] <auri_> s/fLaC/flac/ so all players accept it
[00:14:17 CET] <JEEB> yes, so they clearly take teh identifier fLaC inside the container
[00:17:10 CET] <JEEB> auri_: I see a manual string identifier in dashenc.c
[00:18:09 CET] <JEEB> if you want to test it try adding this line http://up-cat.net/p/6b76769f
[00:18:47 CET] <JEEB> if that works then that might just be worth a patch since we've got at least one (1) user
[00:19:21 CET] <auri_> lemme build it real quick
[00:19:30 CET] <auri_> I'll be back with the results in ~10 minutes
[00:22:06 CET] <auri_> JEEB: that worked
[00:22:25 CET] <auri_> it now outputs a proper codecs attribute
[00:23:11 CET] <JEEB> I'd like that identifier be specified somewhere, although I guess it might be something browser-side/generic content type identifier
[00:23:33 CET] <JEEB> but great to know that that's enough for it
[00:23:33 CET] <auri_> whatwg wiki says it should be codecs=flac
[00:23:44 CET] <auri_> *shrug*
[00:23:53 CET] <auri_> oh yes while I'm still here
[00:25:14 CET] <auri_> was there ever patch for an option like -initial_offset (-f segment) for dashenc
[00:25:38 CET] <auri_> I know Plex fork has it and I skimmed over their impl, seems simple enough
[00:26:02 CET] <JEEB> oh yes, people seem to really like that on the muxer side while in general they should just be offsetting their input timestamps a la -itsoffset
[00:26:23 CET] <JEEB> (itsoffset being an ffmpeg.c option)
[00:26:45 CET] <auri_> that changes segment filenames?
[00:26:58 CET] <JEEB> well that sounds like the initial timestamp offset, no?
[00:27:03 CET] <JEEB> so that timestamps don't start at zero
[00:27:15 CET] <auri_> makes sense yeah
[00:27:33 CET] <auri_> so after all the option is there, just in a different way
[00:27:49 CET] <auri_> thanks for letting me know
[00:27:51 CET] <JEEB> there's a generic ffmpeg.c option for it, but I think you need to utilize -copyts with it or so
[00:28:03 CET] <JEEB> or some other -vsync mode than the default
[00:28:23 CET] <JEEB> vsync is just a fancy wording for ffmpeg.c dropping or duplicating frames :P
[00:28:34 CET] <JEEB> (also the logic can make a grown man cry)
[00:28:40 CET] <auri_> I'll see what I can do with it tomorrow, EU times suck
[00:28:53 CET] <auri_> basically I need it to handle seeking in a streaming application
[00:29:08 CET] <auri_> kill ffmpeg -> restart wit -ss and skipped segments
[00:29:37 CET] <auri_> unless there's a better way to handle it I'm not aware of
[00:31:43 CET] <JEEB> at some point using the APIs becomes a viable alternative
[06:45:59 CET] <KombuchaKip> Hey everyone. I'd really appreciate a code review of my custom AVIOContext for reading media from memory: https://pastebin.com/NGALFw8Y
[11:13:36 CET] <termos> I have an incoming stream where time `pts` of the audio and video is out of sync by a constant amount, is there a way to fix this somehow?
[11:14:27 CET] <termos> I thought of offsetting one of them by the difference of `pts` in the first incoming packages, but they always seem to have `pts` 0
[11:29:52 CET] <ponyrider> seems like there is a well known issue surrounding trimming a video with -c copy? what is the work around for this?
[11:30:24 CET] <ponyrider> the command i have is: ffmpeg -i video.mp4 -ss 00:00:10 -to 00:00:15 -c copy output.mp4
[11:31:14 CET] <durandal_1707> you cant trim exact with copy, it just can not work with lossy encodes with inter frames
[11:31:44 CET] <ponyrider> SO says: ffmpeg -ss 191 -i vid.mp4 -vcodec libx264 -acodec libmp3lame -t 6 someoutput3.mp4
[11:32:01 CET] <ponyrider> to re-encode. is this what you would recommend?
[11:32:27 CET] <ponyrider> durandal_1707: ^
[11:33:04 CET] <durandal_1707> re-encode will degrade quality
[11:33:16 CET] <durandal_1707> with above line
[11:33:41 CET] <ponyrider> what is the solution to get a more precise trim as lossless as possible?
[11:34:02 CET] <Mavrik> Black magic?
[11:35:16 CET] <ponyrider> i just want to trim youtube videos ... :\
[11:36:01 CET] <Mavrik> Noone is stopping you, but there are fundamental limitations around trimming videos stored in modern formats.
[11:36:11 CET] <Mavrik> And caring about lossless trimming for YT content is a bit wierd.
[11:36:21 CET] <ponyrider> well i dont mind about the losses so much
[11:36:32 CET] <ponyrider> just a precise trim. sometimes it works. sometimes it doesnt
[11:39:43 CET] <furq> ponyrider: -ss 123 -i foo.mp4 -t 456 -c:v libx264 -crf 20 -c:a copy out.mp4
[11:39:58 CET] <furq> also you probably want to download vp9 from youtube if you're doing further editing to it
[11:41:03 CET] <ponyrider> alright if that's the best answer i will take it!
[11:41:29 CET] <furq> idk about best but it works and it's not a huge amount of hassle
[11:41:54 CET] <furq> in an ideal world you'd only reencode the first and last gop and then stitch it together
[11:42:07 CET] <furq> but that is a lot of hassle and if you're clipping six seconds then there's only going to be one or two gops anyway
[11:44:36 CET] <ponyrider> i just want accurate trim w no hassle thank you v much
[12:00:59 CET] <ponyrider> the -to option is faulty
[12:01:08 CET] <ponyrider> its giving me a video of 44 seconds longs
[12:02:21 CET] <furq> -to has to be in the same place as -ss
[12:02:35 CET] <furq> -ss as an input option and -to as an output option doesn't work
[12:02:39 CET] <furq> or it does, but it just does the same thing as -t
[12:02:42 CET] <ponyrider> i see so -ss cannot go before -i?
[12:02:51 CET] <furq> put them both before -i
[12:03:00 CET] <furq> or both after, i don't think it matters if you're reencoding the video
[12:03:18 CET] <furq> but yeah -ss/-t/-to behave differently depending on whether they're input or output options
[12:04:03 CET] <relaxed> isn't -ss more accurate when placedafter the input -i ?
[12:10:57 CET] <ponyrider> ok furq its working well the quality is not any worse either thanks man
[12:14:34 CET] <furq> relaxed: i don't think it matters if accurate_seek is enabled
[12:14:37 CET] <furq> which it is by default
[14:58:54 CET] <somy> hi
[14:59:31 CET] <somy> I'm trying to modify ffplay to use hwdec on rockchip and I'm a bit lost
[15:00:55 CET] <somy> It' doesn't output anything, I must do something wrong but as soon as it uses the queues to store  decoded stuff I get no image..
[15:01:12 CET] <somy> any pointers on where to look for ?
[15:55:40 CET] <plalorenz> I want to create a video from images. Let's say I have 1000 images that are named like: "index_dynamic_dynamic_dynamic_dynamic.jpg" so index would go from 0 to 999 and dynamic parts of the file name would be various information. I have tried to create the video with this command: https://pastebin.com/FDwmPX72 but it's not sequential. I know that I am able to say %d in the file name, but how do I mix %d with *?
[17:03:00 CET] Last message repeated 1 time(s).
[18:22:17 CET] <KombuchaKip> Hey everyone. I'd really appreciate a code review of my custom AVIOContext for reading media from memory: https://pastebin.com/NGALFw8Y
[19:01:35 CET] <Hello71> pretty sure that already exists
[19:01:46 CET] <Hello71> also eww c++
[19:19:38 CET] <KombuchaKip> Hello71: Sorry, what already exists?
[21:29:48 CET] <somy> Does anybody know howto use av_frame_ref / unref / free in hwdec context?
[21:50:30 CET] <BtbN> Same way as usual?
[21:55:13 CET] <somy> I'm a bit lost either I get a double free, if I use free or the hwedc "explode" trying to free leaked data (because they weren't freed...
[22:44:17 CET] <leif> So, is `av_register_all` no longer required to call for ffmpeg 4?
[22:46:21 CET] <JEEB> yes
[22:46:59 CET] <JEEB> the list is static nowadays since the ability to register formats during run-time was not possible to use from the outside (since it required private symbols)
[22:48:17 CET] <leif> JEEB: makes sense. So basically programs can work otherwise the same, just without calling it?)
[22:49:19 CET] <JEEB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/APIchanges;h=db1879e6e2379d6de28b0d4d9a37b7e6a16f1dc6;hb=HEAD#l62
[22:49:44 CET] <JEEB> search around that for av_register_all and see the notes about newly added functions
[22:49:50 CET] <JEEB> but generally, yes
[22:53:31 CET] <leif> JEEB: okay cool, thanks.
[23:30:42 CET] <Pdrome> Hi is the the right place to ask a question about FFmpeg?
[23:31:11 CET] <JEEB> yes
[23:32:23 CET] <Pdrome> Thanks. I wanted to ask: Does FFmpeg use any code owned by RAD Game Tools?
[23:32:45 CET] <JEEB> not that I know. all of the closed source stuff as far as I know has been reverse engineered
[23:33:48 CET] <JEEB> so unless a) RAD game tools contributed some code to FFmpeg (under LGPL) or b) someone got access to RAD Game Tools code and put it in , there should be no RAD Game Tools code in FFmpeg
[23:34:26 CET] <JEEB> after reading your question I had to add case a) as well, since I own the copyright to the code I contribute to FFmpeg
[23:34:27 CET] <Pdrome> The reason I ask is that I was doing research into gamedev about 2 years ago and found a mailing list entry whereby the FFmpeg devs had got hold of RAD Game Tools source code maybe through a leak etc and I wanted to know what the llegal situation is there ragrding FFmpeg
[23:35:39 CET] <pink_mist> the legal situation is that the ffmpeg devs would not be allowed to use said code unless RAD Game Tools specifically gave them a license to do so
[23:35:52 CET] <JEEB> yes
[23:36:34 CET] <JEEB> but if someone just studied the code and wrote his own, that is the author's thing.
[23:36:46 CET] <JEEB> although that's still less kosher than RE
[23:37:07 CET] <Pdrome> controversial question I know, but I am hesitant to use FFmpeg for commercial projects given my findings as I dont know if the FFmpeg project could be liable and in turn myself for using FFmpeg.
[23:37:47 CET] <JEEB> nothing much controversial about it.
[23:38:15 CET] <pink_mist> pretty sure all the code in ffmpeg has been thoroughly vetted so that the authors have given the appropriate license for the code
[23:38:20 CET] <JEEB> if someone else's code was used verbatim that's always bad
[23:38:29 CET] <Mavrik> Sue Google, see what they say, resolve once and for all :P
[23:38:47 CET] <JEEB> if you can provide a reference and ask for details on the mailing list or the issue tracker that could get the ball rolling
[23:40:37 CET] <Pdrome> JEEB are you a dev? I can post the mailinglist link regarding the source code possible usage
[23:41:07 CET] <Pdrome> It was FFmpegs own mailing list btw. Let me just refind it...
[23:41:28 CET] <JEEB> Pdrome: also for the record the history between one of the people implementing RAD game tools' formats and RAD Game Tools seemed to be generally positive. they seemed to winkingly link info on new bink formats etc to the guy
[23:42:52 CET] <JEEB> and if someone would come after you for using FFmpeg it'd probably be the IP owners for actually standardized formats
[23:43:01 CET] <JEEB> as opposed to something like RAD
[23:43:05 CET] <JEEB> IANAL of course
[23:44:35 CET] <Pdrome> cheers JEEB, I am slightly reassured. Would love to get input from contribs regarding the mailing list entry I found. Still looking for it...
[23:44:45 CET] <JEEB> sure, agree with that
[23:49:19 CET] <Pdrome> Doh! Can't find it by re-googling but here's an interesting quote:
[23:49:21 CET] <Pdrome> Rad Game Tools claimed that the MPC interface to the DLLs was based on leaked/proprietary information which is why they compelled MPC to remove support. But not before I reverse engineered and documented the DLL interfaces: see http://wiki.multimedia.cx/index.php?title=RAD_Game_Tools_Bink_API and http://wiki.multimedia.cx/index.php?title=RAD_Game_Tools_Smacker_API . RGT once contacted me and requested that I remove those descriptions fr
[23:49:41 CET] <Pdrome> from here: https://multimedia.cx/eggs/bink-video-in-ffmpeg/
[23:50:06 CET] <Pdrome> I must have the mailing list entry bookmarked on another machine
[23:50:25 CET] <JEEB> ok, FFmpeg doesn't utilize the official RAD APIs
[23:50:49 CET] <JEEB> that talks about the interfaces against RAD's own libraries
[23:51:14 CET] <JEEB> seems like at some point Gabest's MPC (the media player I guess) had support for the APIs
[23:51:43 CET] <Pdrome> I am gutted I can't find the mailinglist entry - it was very clear
[23:52:13 CET] <Pdrome> When I do find it I will pop back and post again, thanks so far though for your adive and thoughts
[23:52:48 CET] <JEEB> so basically what that means is that mpc used interfaces (probably headers) which were leaked and not under an open source license, and thus incompatible with being in an open source thing (like MPC)
[23:53:07 CET] <JEEB> and those interfaces are against RAD's binkw*.dll I guess
[23:53:27 CET] <JEEB> now, FFmpeg's stuff is of course completely separate from the bink DLLs
[23:54:20 CET] <Pdrome> Here's a hypothetical... If FFmpeg did use RADs algorithms etc, would that be illegal if it was acquired through means of a RAD game tools source code leak from somewhere?
[23:55:07 CET] <JEEB> if the code was verbatim RAD code then that's not kosher
[23:55:17 CET] <Pdrome> as my above is closest to what I remember the mailing list alluded to
[23:57:13 CET] <JEEB> that said, since it's kostya I'd find it rather unlikely that he would have done something like that. esp. given him having fans (?) within RAD seemingly sending him challenges ("psst, did you know that we have *another* new format around? ;)")
[23:57:41 CET] <JEEB> and given that he's rather capable in actual RE as it's become obvious during the years
[23:57:57 CET] <JEEB> doesn't make it an impossibility of course
[23:59:26 CET] <JEEB> hah, he has just started poking at real's new china format according to his own blog :P
[23:59:31 CET] <Pdrome> that is my other thought... where would the FFmpeg project stand if it uses rads source code from a leak but it is just rewritten etc + if other aspects not leaked were reverse engineered?
[00:00:00 CET] --- Wed Nov 14 2018