[Ffmpeg-devel-irc] ffmpeg.log.20171229
burek
burek021 at gmail.com
Sat Dec 30 03:05:02 EET 2017
[00:40:31 CET] <buu> Is there some way to pause a running ffplay process via ssh
[00:41:19 CET] <tdr> control-z maybe
[00:41:46 CET] <buu> I guess
[00:41:49 CET] <buu> It doesn't respond to signals?
[00:41:50 CET] <c_14> pkill -STOP ffplay
[00:42:10 CET] <tdr> control-z is stop
[00:42:15 CET] <c_14> yeah
[00:42:21 CET] <c_14> but you don't need the running shell for it
[00:42:25 CET] <tdr> true
[00:43:21 CET] <buu> Is there some philosophical reason ffplay doesn't have any form of IPC based controls?
[00:43:32 CET] <c_14> Nobody implemented it?
[00:43:35 CET] <buu> It seems like the kind of thing that would have wandered in over the years
[00:43:50 CET] <c_14> ffplay doesn't see much development
[00:43:57 CET] <c_14> at least in terms of new features
[00:44:11 CET] <tdr> buu, because many things use ffmpeg as a background process, and you'd control through them
[00:44:54 CET] <buu> I've never entirely understood the relationship
[00:45:04 CET] <buu> Can you replicate ffplay functionality via flags to ffmpeg?
[00:45:26 CET] <c_14> there is an sdl output which can kind of do some video display things
[00:45:28 CET] <c_14> but not really
[00:46:22 CET] <buu> Hmm
[00:46:30 CET] <buu> So if I wrote in some ipc for ffplay would it get accepted?
[00:46:51 CET] <c_14> maybe
[00:47:04 CET] <c_14> seems like the sort of thing that might get argued over though
[00:47:17 CET] <buu> I mean, I would have thought if it was likely to be accepted it would have already been accepted over the many years of its existence
[00:49:12 CET] <c_14> If you can maybe use a different video player like mpv which already has IPC support?
[01:51:14 CET] <FishPencil> Likely a long shot, but is anyone here familiar with the bluray format? I'm not sure what channel to ask this in.
[01:53:44 CET] <FishPencil> I'd like to know how audio channels are selected when an item is played back. If I select a play option from the menu with commentary enabled, I see the same mpls file opened and the same m2ts opened, but the audio playing is indeed the commentary. What's controlling this?
[02:03:22 CET] <kepstin> FishPencil: the bluray menus are implemented in java code that controls some playback functionality including selecting which audio track to use
[02:04:15 CET] <kepstin> (dvd was similar, but it had a far more limited bytecode instead of java)
[02:04:56 CET] <FishPencil> kepstin: Awesome, thank you. So what does the mpls actually control then? marks and in/out times?
[02:07:22 CET] <FishPencil> I'm also not entirely sure what the difference between a "title" and a "playlist" is
[02:07:46 CET] <SilenceDogood> Hello. I am trying to convert a red+cyan anaglyph 3D video from a DVD to a greyscale SBS video for watching on mobile VR
[02:07:48 CET] <kepstin> hmm, i'm not familiar with what exactly is in the mpls stuff, but iirc it is at its core just a playlist that says "this title is made from these m2ts files", then the menus select by playlist file rather than referring to m2ts files directly
[02:08:29 CET] <SilenceDogood> My problem is that the stereo3d filter seems to be designed for going the other direction, from side by side to anaglyph, but not from anaglyph to side by side. https://ffmpeg.org/ffmpeg-filters.html#stereo3d
[02:08:35 CET] Action: kepstin is more familiar with the dvd format, where "title" had a somewhat different technical meaning than it does in m2ts.
[02:09:14 CET] <kepstin> SilenceDogood: converting from anaglyph to separate the pictures is a difficult problem
[02:09:50 CET] <kepstin> i guess it's just not something the fitler dev was able to figure out a good solution for
[02:09:54 CET] <SilenceDogood> kepstin It shouldn't be when the original video is greyscale should it?
[02:11:42 CET] <kepstin> hmm, I suppose that might make it easier, but still a hard problem.
[02:12:07 CET] <SilenceDogood> I find two other records of people doing this online
[02:12:24 CET] <SilenceDogood> one is "Frankenstein VR" https://github.com/olir/Frankenstein
[02:12:35 CET] <SilenceDogood> it uses ffmpeg as a basis but I can't seem to get it to work at all.
[02:12:55 CET] <SilenceDogood> The other is this, which is avisynth based http://www.dvinfo.net/forum/3d-stereoscopic-production-delivery/489934-how-convert-anaglyph-side-side-5.html
[02:17:03 CET] <kepstin> yeah, and that's multi-step, requires a separate copy of the 2d version of the video, and a bunch of parameter tweaking to get the output right
[02:17:26 CET] <kepstin> might be possible to port something like that to an ffmpeg filter, i suppose :/
[02:17:28 CET] <SilenceDogood> There is no 2D version of this. It's a greyscale 3D video
[02:18:16 CET] <SilenceDogood> The reason for wanting a separate 2D version in that method is in order to preserve color which isn't there in greyscale films
[02:21:48 CET] <kepstin> right, well, all I can tell you is that there's currently no way to convert from anaglyph to some other 3d format using ffmpeg, until someone contributes a filter/patch to do it :/
[02:22:17 CET] <SilenceDogood> OK that's actually helpful info kepstin. Thanks
[02:22:28 CET] <kepstin> although with greyscale... hmm.
[02:22:28 CET] <SilenceDogood> Just wanted to make sure it wasn't hiding somewhere I hadn't found
[02:22:52 CET] <kepstin> you might just be able to use plain color filters to extract one side or the other, and merge them in a different way afterwards
[02:23:17 CET] <SilenceDogood> That's how I'd assume the process would work, yeah
[02:23:36 CET] <SilenceDogood> This video proves Frankenstein VR has worked at least for the guy who made it. https://vimeo.com/222956494
[02:24:06 CET] <kepstin> which you might be able to do using colorchannelmixer or one of the lut filters
[02:24:30 CET] <SilenceDogood> My goal is actually to convert Dangeresque Three: The Criminal Projective :)
[02:24:56 CET] <SilenceDogood> from the Strong Bad's Cool Game for Attractive People DVD
[02:25:16 CET] <SilenceDogood> It's just 8 minutes and 16 seconds
[02:26:12 CET] <kepstin> hmm, that's a fairly modern source with a clean digital cyan/red 3d. probably won't be too bad.
[02:26:35 CET] <kepstin> aside from all the issues due to chroma subsampling and whatnot
[02:32:23 CET] <kepstin> hmm. that case is actually simple enough. convert to rgb, use the red channel as one eye, and the not-red (probably just use green) as the other eye
[02:32:41 CET] <kepstin> might need some other adjustment to get the levels to match up tho
[02:35:23 CET] <SilenceDogood> green and blue make cyan right? In that case, maybe make the right eye be a combination of the green and blue channels?
[02:39:07 CET] <kepstin> adding the blue probably won't do much, thanks to quirks of how YCbCr video formats work
[02:39:30 CET] <kepstin> note that the red channel will be noticably lower resolution/quality than the other color.
[02:40:55 CET] <kepstin> i suspect that's probably why green/magenta is popular nowadays, I bet it encodes better into YCbCr formats with subsampled chroma.
[02:42:20 CET] <kepstin> but yeah, give the 'colorchannelmixer' filter a shot, you can play around with mixing a bit with that.
[02:52:04 CET] <SilenceDogood> I'm trying to get that AnaglyphExtract.avs file to work tho
[03:09:14 CET] <SilenceDogood> kepstin, that AVS file seems to be working actually. I was missing the needed parameter file. I can't wait to process this and try it out! :)
[03:25:16 CET] <SilenceDogood> and of course while it'll open in virtualdub filtermod just fine, it won't actually export without giving some kind of crashing error :( apparently it doesn't know where my ffmpeg lives
[05:10:04 CET] <vlad_> hello, I'm writing some C++ code that calls the ffmpeg libraries
[05:10:40 CET] <vlad_> for some reason avcodec_descriptor_get_by_name doesn't seem to know about h264_nvenc
[05:11:00 CET] <vlad_> the ffmpeg binary takes -c:v h264_nvenc just fine
[05:11:04 CET] <SilenceDogood> What the hell. My AVS script splits up the anaglyph footage just fine visually, but the audio goes out of sync!! :(
[07:37:27 CET] <ruto> hello. In <libavdevice\dshow.c> i see, that dshow may receive options like 'list_devices', 'crossbar_video_input_pin_number' etc. But i am not found how i can send this commands to device from my code. Can anyone help me with it? Maybe give me simple example?
[08:57:02 CET] <Guest43283> Hello everyone! Could someone help me with the following question: https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=15&t=5388
[10:11:04 CET] <d4re> whats a .vtt file?
[10:11:04 CET] <d4re> in relation to hls stream?
[10:11:11 CET] <d4re> oh subs
[10:11:13 CET] <d4re> ok
[10:58:19 CET] <kazuma_> use x264 Guest43283
[10:59:52 CET] <kazuma_> you can capture the programs window with gdigrab
[11:00:28 CET] <kazuma_> use "-offset_x 0 -offset_y 0" to set it's position on your screen
[11:24:57 CET] <Guest43283> _kazuma, the post changed a bit. Could you maybe read it again, then things are clearer. I would be glad to hear your answers :) https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=15&t=5388&p=12987#p12987
[11:40:08 CET] <meepmeep> hello
[11:48:59 CET] <meepmeep> i'm using ffmpeg on ubuntu (3.4.1-1~xenial), my input file has mutiple subtitle stream (0:2, 0:3 and 0:4), and with "-c:s copy", only 0:2 is mapped on the ouput file. Any idea why ?
[11:50:11 CET] <sfan5> ffmpeg will only map the "best" stream by default
[11:50:54 CET] <sfan5> add a -map 0
[11:52:11 CET] <meepmeep> indeed, thanj you
[11:53:24 CET] <meepmeep> thank*
[13:09:02 CET] <broman> can someone please help me? I have several video files (and they keep coming) and I need to stream them with ffmpeg... I already do that, but as I hop from one file to the other, there's a delay on my rtmp server...
[13:21:05 CET] <BtbN> broman, sounds normal and expected to me
[13:21:34 CET] <BtbN> You'll have to write a custom application if you want a continous stream
[13:25:26 CET] <broman> omg
[13:26:27 CET] <BtbN> ffmpeg.c can work with a given set of input files on invocation. But an ever expanding list of files is not really possible, unless you have something like a HLS stream or so
[14:05:27 CET] <DHE> or other creative solutions, like a pipe-based input and some application that concatenates videos into it (in a concatenation-friendly format of course)
[14:47:44 CET] <linuxthefish> hi, I have a list of files like "03-20171229132605-11.jpg" "03-20171229132605-12.jpg" etc for a time lapse, but when I use "ffmpeg -r 30 -i %04d.jpg -s hd480 -vcodec libx264 -vpre hq time-lapse.mp4" it tells me that it can't find them
[14:47:47 CET] <linuxthefish> "Could find no file with path '%04d.jpg' and index in the range 0-4"
[14:48:14 CET] <linuxthefish> but when i use "-i *.jpg" it asks if I want to overwrite the files, which is not what I want, I want to make them into a video!
[14:49:18 CET] <klaxa> did you try ffmpeg -i "03-20171229132605-%d.jpg" [rest] ?
[14:49:39 CET] <klaxa> if that doesn't work, you could also do: cat *.jpg | ffmpeg -f image2pipe -i - [rest]
[14:50:06 CET] <linuxthefish> but they all have different names in front, like "01-20171229115914-15.jpg" and "05-20171229133323-11.jpg"
[14:50:10 CET] <linuxthefish> ah i'll try that thanks
[14:50:14 CET] <linuxthefish> i'm not good with regex sorry
[14:50:28 CET] <klaxa> nobody was born knowing things :)
[14:53:33 CET] <linuxthefish> thanks, that works for finding them!
[14:54:33 CET] <linuxthefish> for the presets I have "/usr/share/ffmpeg/libvpx-360p.ffpreset", but using "-s hd480 -vcodec libvpx" tells me "Could not find tag for codec vp8 in stream #0, codec not currently supported in container"
[14:54:47 CET] <linuxthefish> I don't mind what format it gives as long as it's video
[14:55:40 CET] <klaxa> mkv is one of the most flexible containers in existence
[14:55:46 CET] <klaxa> just change .mp4 into .mkv
[14:56:14 CET] <linuxthefish> yep that works perfect, thanks so much for your help! :)
[14:56:29 CET] <klaxa> :)
[14:57:28 CET] <therage3> With the disadvantage that some older devices don't support it, even if the codecs and streams contained within are.
[14:58:01 CET] <therage3> In this aspect, .mp4 *probably* is more supported, I guess.
[14:59:35 CET] <linuxthefish> ah it's ok, it's just for messing around with time lapses :D
[14:59:40 CET] <therage3> Yeah.
[15:33:01 CET] <masin> !welcome
[15:33:21 CET] <masin> mhh & no bot answering :-/
[15:33:33 CET] <masin> "!welcome"
[15:33:38 CET] <masin> !welcome
[15:34:03 CET] <masin> still no bot answering. well, whatever &
[15:35:23 CET] <masin> can anybody tell me how I can understand this message: " Last message repeated 26 times [linebreak] Past duration 0.999992 too large 1256kB time=00:00:15.85 bitrate= 648.8kbits/s dup=0 drop=1 speed=2.05x" ?
[15:35:51 CET] <masin> what's up with the "Past duration 0.9999& too large"?
[15:36:22 CET] <BtbN> From how I understand it, it basically means the timestamps or the framerate are messed up
[15:36:30 CET] <masin> and could it have any connection to my encoding always crashing after 5 to 15 minutes?
[15:39:05 CET] <masin> BtbN: Is there any way to fix this?
[15:41:25 CET] <slime938> „„„„„„„„„„„„ IRC.SUPERNETS.ORG IS HOSTING THE DDOS AND FLOODING CHALLENGE..PLEASE SEE VAP0R IN #SUPERBOWL FOR DETAILS!! capbqbcy: daddesio dingbat beemo_ceniza stevenliu hexhaxtron buu the_k mateo` merzo rav0 zcx aphirst luc4 A3G1S dreamon M6HZ therage3 codebam petecout_ Sharkigator Guest43283 nfobot durandal_1707 Kei_N iive michaelni dashcloud_ ivanich rcdilorenzo IHAVENONICK R
[15:41:28 CET] <slime938> „„„„„„„„„„„„„ IRC.SUPERNETS.ORG IS HOSTING THE DDOS AND FLOODING CHALLENGE..PLEASE SEE VAP0R IN #SUPERBOWL FOR DETAILS!! absuxnrqmi: durandal_1707 gix- rcdilorenzo dreamon darklink beaver daddesio Sharkigator ivanich linuxthefish buu Kei_N rav0 dingbat petecout_ jnollette merzo mateo` road|runner thebombzen Raku beemo_ceniza IHAVENONICK codebam nfobot relaxed djk Tachyo
[15:41:37 CET] <slime938> „„„„„„„„„„„„„„ IRC.SUPERNETS.ORG IS HOSTING THE DDOS AND FLOODING CHALLENGE..PLEASE SEE VAP0R IN #SUPERBOWL FOR DETAILS!! dxtjwpgfvr: relaxed djk michaelni aptalca beemo_ceniza meepmeep durandal_1707 rcdilorenzo voip_1 merzo beaver masin rav0 DasMoeh IHAVENONICK A3G1S Tachyon petecout_ luc4 linuxthefish aphirst dv_ hfb stevenliu mateo` jbermudes gix- Stels Crac
[15:41:42 CET] <therage3> !ops slime938 spam
[15:41:42 CET] <slime938> „„„„„„„„„„„„„„„„„„„ IRC.SUPERNETS.ORG IS HOSTING THE DDOS AND FLOODING CHALLENGE..PLEASE SEE VAP0R IN #SUPERBOWL FOR DETAILS!! tdawi: DasMoeh dashcloud_ Tachyon meepmeep Stels road|runner dingbat ivanich petecout_ darklink kazuma_ M6HZ Cracki stevenliu masin d4re jbermudes therage3 djk LRN rav0 Kei_N buu dreamon rela
[15:41:49 CET] <therage3> thanks
[15:44:12 CET] <celyr> this one didn't went that far
[15:44:13 CET] <celyr> lel
[15:44:20 CET] <celyr> I give it a 2
[15:44:52 CET] <therage3> well, they got banned before the spammed the whole channel
[15:49:53 CET] <infinisil> A filter that matches any message that contains more than 10 nicks would be nice
[15:52:53 CET] <therage3> freenode actually has a bot, Sigyn, that watches for that stuff
[17:07:45 CET] <M6HZ> Hello, is there a way to reduce the lag between two `ts` segments of a `m3u8` stream using ffplay ?
[17:08:54 CET] <Darxus> When I try to view the webm videos I created with ffmpeg on firefox on android, I get an error saying that they can't be played because they're corrupted. Other webm videos I've tested work with my android browser. Other browsers work with my webm videos. I think I should report this as a bug to both, and link them to each other?
[17:09:02 CET] <Darxus> One of my videos: http://www.eternalmachinery.com/ecar/tbucket18crf55.webm
[17:09:37 CET] <c_14> probably hbd
[17:10:00 CET] <c_14> yuv444p not sure browsers support that
[17:10:09 CET] <c_14> use -pix_fmt yuv420p
[17:24:54 CET] <M6HZ> Darxus, I remember having had this very same issue, I think it was needed to pass an option to solve it.
[17:26:58 CET] <Darxus> M6HZ: Thanks, any guesses what option?
[17:29:13 CET] <Darxus> I've submitted a bug to firefox, working on ffmpeg: https://support.mozilla.org/en-US/questions/1197193
[17:36:27 CET] <M6HZ> Darxus, Maybe you should try the one that c_14 has recommended. https://superuser.com/questions/988296/ffmpeg-encoding-to-vp9-results-in-google-chrome-unplayable-video-while-to-vp8-w
[17:36:41 CET] <klaxa> was about to say, c_14 just told you what was going on
[17:38:01 CET] <Darxus> Thank all three of you, I missed that line. I was just about to try that from web search results.
[17:45:55 CET] <Darxus> Now android firefox just fails to load it without giving an error :/
[17:46:48 CET] <Darxus> fmpeg -framerate 60 -i tbucket%04d.png -c:v libvpx-vp9 -crf 55 -b:v 0 -pix_fmt yuv420p tbucket18crf55yuv420p.webm
[17:56:13 CET] <Darxus> Ugh. After rebooting my phone, with yuv420p the file works if I view it directly, but embedded in a page it still says it's corrupted. Okay now viewing it directly isn't working again.
[18:07:37 CET] <Darxus> Oh hey, now the webmproject.org test video won't load either. No errors. Great.
[18:08:12 CET] <twid> How to cal pts if pts for raw frame is not known?
[18:26:55 CET] <dinkan> @alexpigment: Thanks for your response. I'm trying to stream it directly from a Linux machine using multicast and the client is VLC player. Observed some improvement when I used pkt_size=1300. Does that give you any clue? Thanks in advance.
[18:30:03 CET] <alexpigment> dinkan: i'm really not familiar with the technical limitations of all that, or where the quality bottleneck is
[18:30:29 CET] <alexpigment> i just wanted to make sure you weren't trying to play the 1440x1080 interlaced video on a device or browser that doesn't support the format properly (most probably won't)
[18:30:33 CET] <Darxus> Ahh, the version that works on webmproject.org is vp8, I'm using vp9. (Probably surprising no one.)
[18:32:03 CET] <alexpigment> dinkan: out of curiosity, though, the video plays fine locally on the client PC in VLC, right?
[18:51:48 CET] <Darxus> I added all my results to the firefox bug I opened: https://support.mozilla.org/en-US/questions/1197193#answer-1056784
[18:52:59 CET] <alexpigment> darkus: you accidentally wrote "yuv420p" in the "summary"
[18:53:02 CET] <alexpigment> er
[18:53:05 CET] <alexpigment> *Darxus
[18:53:37 CET] <alexpigment> to be fair, yuv444p doesn't work in a lot of players. pretty sure it doesn't work in Windows Media Player
[18:54:08 CET] <Darxus> alexpigment: Thanks, I'm not surprised I got that wrong somewhere.
[18:54:37 CET] <Darxus> Fixed.
[18:54:40 CET] <alexpigment> it's ok, i saw that line (wasn't really following the stuff above) and was like wait, yuv420p videos fail???
[18:54:45 CET] <alexpigment> cool
[18:54:58 CET] <furq> 4:4:4 was only added relatively recently to firefox on desktop
[18:55:16 CET] <furq> on android i assume it's restricted to whatever mediacodec (or whatever it's called) supports
[18:55:24 CET] <alexpigment> furq: do you think it "works" by just ignoring some of the chroma information?
[18:55:30 CET] <furq> no it actually works
[18:55:35 CET] <alexpigment> well that's good to know
[18:55:43 CET] <furq> it falls back to software decoding on desktop
[18:55:50 CET] <Darxus> furq: Yeah but 4:4:4 works on chrome on android.
[18:55:51 CET] <alexpigment> makes sense
[18:55:54 CET] <furq> oh
[18:56:00 CET] <furq> weird
[18:56:04 CET] <Darxus> Yeah.
[18:56:10 CET] <furq> does 4:4:4 vp9 work in desktop firefox
[18:56:18 CET] <Darxus> furq: Yes, and chrome on android.
[18:56:21 CET] <furq> nice
[18:56:24 CET] <furq> yeah that's definitely worth a report then
[18:56:33 CET] <alexpigment> i wonder if android gpus even have 444 native support on the hardware decoder
[18:56:36 CET] <furq> not a lot of phones have vp9 hwdec at all
[18:56:43 CET] <Darxus> Thanks. I have the three tests up currently at the top of: http://www.eternalmachinery.com/ecar/
[18:56:54 CET] <Darxus> But I doubt you need to actually see that, and I need to delete the two problematic ones.
[18:57:07 CET] <furq> so there must be a software decoding fallback for any vp9 on android
[18:57:17 CET] <furq> although whether that's part of chrome or mediacodec i don't know
[18:57:17 CET] <alexpigment> Darxus: if vp9 and/or yuv444p mean that android devices have to play in software, i can actually understand why they'd not play it
[18:57:52 CET] <alexpigment> kind of like when apple blocked flash on mobile a long time ago, because they knew it would be an insanely huge battery drain and reflect negatively on their prodcuts
[18:58:17 CET] <Darxus> alexpigment: Sure, but they should throw a better freaking error than file is corrupt.
[18:58:21 CET] <tdr> (and force upstream to change their minds about supporting it)
[18:58:29 CET] <alexpigment> Darxus: i can't argue with that
[18:58:35 CET] <therage3> alexpigment: as opposed to downclocking their iPhone CPUs behind people's backs as the battery performance dropped
[18:58:45 CET] <furq> yeah firefox has always given "file is corrupt" about completely valid files that it can't decode
[18:58:46 CET] <therage3> </end Apple rant>
[18:58:53 CET] <furq> or valid streams that it doesn't know how to play
[18:58:57 CET] <furq> it's dumb
[18:59:04 CET] <alexpigment> therage3: eh, i think that story is a bit more complicated than can be explained in a headline, but still
[18:59:18 CET] <furq> the downclocking thing is overblown really
[18:59:36 CET] <furq> i agree it should be configurable but that's what you get when you buy into apple stuff
[18:59:40 CET] <tdr> furq, at that point, you'd think a user's filetype bindings (default apps) could also be to blame
[18:59:44 CET] <alexpigment> what people should really be talking about is that iOS gets more bloated every version with no way to turn off bloat features that definitely slow down your older devices
[18:59:50 CET] <Darxus> https://trac.ffmpeg.org/wiki/Encode/H.264 has a Compatability section that makes a couple suggestions for maximizing browser compatibility. I think https://trac.ffmpeg.org/wiki/Encode/VP9 should have a similar section suggesting vp8?
[18:59:57 CET] <therage3> alexpigment: there are nuances, and while it is true that downclocking the CPU can help keep batteries performing well for longer, the problem seems to have been how Apple weren't really forthright with what they were doing
[19:00:04 CET] <furq> Darxus: are you saying vp9 doesn't play at all in firefox on android
[19:00:08 CET] <furq> because that's super broken if that's the case
[19:00:08 CET] <alexpigment> the battery slowdown thing i'd assume is a drop in the bucket compared to new-ios-version bloat
[19:00:12 CET] <Darxus> furq: Yes.
[19:00:13 CET] <tdr> alexpigment, the same could be said for nearly all os's .. they rarely ever get smaller or easier to trim down
[19:00:17 CET] <furq> what device are you checking this on
[19:00:23 CET] <Darxus> furq: LG G6.
[19:00:24 CET] <therage3> Because iPhone users were noticing a slowdown in their phones and thought that new apps weren't optimized for them
[19:00:33 CET] <furq> huh
[19:00:34 CET] <therage3> And not the actual reason
[19:00:35 CET] <furq> that's brand new isn't it
[19:00:41 CET] <Darxus> furq: Yes.
[19:00:43 CET] <alexpigment> therage3: the deal is that you don't have to be forthright about that. it's not really their responsibility to be 100% transparent on the innerworkings of the device
[19:00:45 CET] <tdr> furq, new (again)
[19:00:47 CET] <furq> i figured it was firefox only playing back codecs with hwdec
[19:00:53 CET] <furq> but i would assume a brand new flagship would have vp9 hwdec
[19:01:14 CET] <alexpigment> tdr: yes, but i think that's more worthy of a headline than this battery slowdown thing, which is probably more alarming on paper than in practice
[19:01:19 CET] <therage3> alexpigment: well, if the phone is getting _noticeably_ slower, then that does sort of make people wonder, "OK, just what is going on here..."
[19:01:57 CET] <furq> i don't really know enough about android to speculate on what it's doing internally
[19:02:11 CET] <alexpigment> therage3: if you keep your phone up to date, it's going to be slower with most major OS upgrades, full battery life or not
[19:02:23 CET] <therage3> alexpigment: hmmm
[19:02:44 CET] <therage3> that would actually be a good experiment to try out on a Linux phone (I don't mean Android)
[19:02:50 CET] <alexpigment> sources: my iphone 4, my iphone 5s
[19:03:08 CET] <Darxus> So no objections to me adding Compatability sections to the vp9 and vp8 sections of the wiki?
[19:03:22 CET] <alexpigment> well, linux doesn't have a horse in the race. they aren't pressured to make new features to sell new devices (the same features that cause the slowdowns)
[19:03:44 CET] <furq> i would hold off until they respond because that just sounds broken
[19:03:46 CET] <therage3> alexpigment: yeah, it's a shame that Ubuntu thing died down, I was actually looking forward to it
[19:03:57 CET] <furq> there shouldn't really be anything that plays vp8 and not vp9
[19:04:13 CET] <alexpigment> furq: are you talking about hwdecs or not?
[19:04:17 CET] <furq> no i mean in general
[19:04:28 CET] <furq> vp8 hwdec isn't a thing at all afaik
[19:04:36 CET] <alexpigment> fair enough
[19:04:43 CET] <furq> unless it's something you get for free with vp9 hwdec
[19:04:49 CET] <furq> the point still applies then though
[19:05:18 CET] <furq> Darxus: it might be worth a proper bug report rather than just a support forum post
[19:05:19 CET] <alexpigment> i'm just saying that playing both vp8 well and vp9 well is not a given. i would prob not want to watch vp9 on mobile without hardware support
[19:05:38 CET] <furq> i would expect it to be either both or neither
[19:05:51 CET] <alexpigment> anyway, i also agree with reporting all this in the proper channels. they can at least give a response
[19:06:18 CET] <furq> now for the fun task of figuring out whether that phone actually has vp9 hwdec
[19:07:03 CET] <Darxus> furq: Bug report to ffmpeg?
[19:07:08 CET] <furq> no, to firefox
[19:07:16 CET] <Darxus> furq: Oh, that's not what I did?
[19:07:44 CET] <Darxus> Ah, I see, thanks, I'll do that.
[19:09:13 CET] <furq> apparently firefox on android has a builtin vp9 software decoder
[19:09:22 CET] <alexpigment> "At the same time, Qualcomm upgraded the hardware decode abilities of the SoC to support HEVC 10-bit and VP9."
[19:09:23 CET] <furq> and as of two years ago it was enabled by default
[19:09:27 CET] <alexpigment> that's for the adreno 530
[19:09:30 CET] <furq> so that should definitely play
[19:09:36 CET] <furq> and yeah the phone should have hwdec for it
[19:09:52 CET] <furq> i wonder if it's maybe messing up the detection because it's such a new phone
[19:09:57 CET] <alexpigment> maybe
[19:10:00 CET] <furq> it's only a couple of months old afaik
[19:10:15 CET] <alexpigment> or maybe because phones didn't have vp9 before this, they just haven't implemented vp9 hwdec support
[19:10:35 CET] <alexpigment> (and they don't have software support either due to not wanting to support a presumably slow format on mobile)
[19:11:06 CET] <furq> https://bugzilla.mozilla.org/show_bug.cgi?id=1261273
[19:11:09 CET] <furq> it looks like they've had it for a while
[19:14:20 CET] <alexpigment> Darxus: out of curiosity, did you try 30fps as a test?
[19:14:52 CET] <alexpigment> and also, did you try anything with a modulus of 8 or 16?
[19:15:01 CET] <alexpigment> e.g. 1280x720?
[19:15:12 CET] <alexpigment> or 640x360?
[19:16:12 CET] <Darxus> alexpigment: I haven't, I will, thanks.
[19:16:50 CET] <alexpigment> np. hardware decoders often have certain resolutions they'll support and ones they won't. a lot of things won't encode/decode at numbers that aren't divisible by at least 2, if not 4 or 8 or 16
[19:17:57 CET] <alexpigment> granted requiring resolutions divisible by 8 or 16 is extremely rare in modern times, but that's existed in the past
[19:19:06 CET] <alexpigment> and 480p widescreen has been a problem since it existed basically. some things like 848, some things like 852, some things like 854
[19:20:38 CET] <Darxus> Oh that's interesting, looks like vp8 defaults to 4:2:0.
[19:20:54 CET] <alexpigment> most things *should* default to 4:2:0
[19:21:11 CET] <alexpigment> at least consumer formats
[19:21:23 CET] <Darxus> alexpigment: Should ffmpeg's vp9 default to 4:2:0? I realize this argument has happened.
[19:21:38 CET] <alexpigment> it depends on the source i'd guess
[19:21:55 CET] <alexpigment> it probably preserves the input because it can support all modes
[19:22:12 CET] <Darxus> Incompatible pixel format 'yuv444p' for codec 'libvpx', auto-selecting format 'yuv420p'
[19:22:15 CET] <Darxus> Huh.
[19:22:23 CET] <Darxus> alexpigment: Yup.
[19:22:28 CET] <alexpigment> yeah, vp8 apparently doesn't support it ;)
[19:29:19 CET] <Darxus> Ugh, the worst part is the inconsistency. Now it's saying a vp8 file is corrupt when embedded in a page, but playing it fine when loaded directly.
[19:30:54 CET] <alexpigment> welcome to the world of QA
[19:31:02 CET] <alexpigment> nothing is usually as simple as it seems
[19:31:05 CET] <alexpigment> ;)
[19:31:23 CET] <alexpigment> that's why i was asking about the resolutions and frame rates
[19:31:29 CET] <Darxus> I've been a programmer for a while, I'm not surprised, just disappointed :)
[19:31:43 CET] <alexpigment> because a 640x360 at 30fps might work, and really confuse the hell out of the actual situation
[19:32:00 CET] <alexpigment> Darxus: completely understandable
[19:32:47 CET] <dinkan> @alexpigment: That's correct, meaning the video plays alright on the client PC in VLC.
[19:34:21 CET] <alexpigment> dinkan: just wanted to check. well, the rest of the problem is completely above my knowledge level, maybe restate the details and someone here can help
[19:46:07 CET] <Darxus> alexpigment: vp9 at 640x360 at 30fps 4:2:0 is not working, but I haven't gotten the vp8 one to work a second time embedded.
[19:46:53 CET] <alexpigment> Darxus: well, that should be enough testing for vp9 then
[19:54:45 CET] <Darxus> Hmm, this is now playing on my phone: https://bugzilla.mozilla.org/show_bug.cgi?id=949525#c9
[19:54:51 CET] <Darxus> The vp9 video they apparently use for build testing.
[19:56:47 CET] <Darxus> This is pretty madenning. It's not playing now.
[20:02:20 CET] <Darxus> Huh, I now have vp9 444 not playing, vp9 420, and vp8 420 playing.
[20:08:42 CET] <Darxus> Well, at least this is consistent: Kill all apps, reboot, play their cake test vp9 file, works, load my ecar page, fails, try playing cake file again, fails.
[20:13:38 CET] <alexpigment> Darxus: is there a special mime type you have to use in the html?
[20:14:08 CET] <alexpigment> (i've mostly used actual players like jplayer and flowplayer, so I'm admittedly green on pure HTML5 video embedding)
[20:14:21 CET] <Darxus> alexpigment: For the html or the video? I'm not serving a particular mime type for .webm files.
[20:14:47 CET] <Darxus> It's just embedded with: <video src="tbucket18crf55yuv420pvp8.webm" autoplay="true" loop="true" controls="true"/>
[20:15:06 CET] <alexpigment> i wonder if you need to do like type="video/vp9" or something like that
[20:15:18 CET] <alexpigment> lemme look for the actual format type
[20:15:37 CET] <Darxus> alexpigment: It's an inconsistent problem, something is definitely glitching here.
[20:15:57 CET] <alexpigment> k
[20:16:19 CET] <alexpigment> i thought you were saying it works in the browser, but not when embedded in the page
[20:16:31 CET] <alexpigment> maybe i misunderstood what you meant when you said "load my ecar page, fails"
[20:16:35 CET] <Darxus> Hah, I'm pretty sure this is it. After it tries to load the ogv on that page, it won't play any more vp8/9 files.
[20:17:08 CET] <Darxus> I meant that after I load this web page, it won't play vp9 files: http://www.eternalmachinery.com/ecar/
[20:17:13 CET] <alexpigment> anyway, for what it's worth, it's just type="video/webm"
[20:17:20 CET] <Darxus> And I think it's the fact that it contains an ogg vorbis file that's freaking it out.
[20:17:24 CET] <Darxus> Thanks.
[20:17:42 CET] <alexpigment> admittedly, ogg vorbis freaks me out too
[20:17:48 CET] <Darxus> Hah.
[20:17:55 CET] <alexpigment> :)
[20:18:04 CET] <therage3> heh, why?
[20:18:15 CET] <alexpigment> because that was the only way to get to the joke ;)
[20:18:47 CET] Action: therage3 is confused
[20:19:05 CET] <alexpigment> therage3: don't worry about it. i made a dad joke
[20:19:07 CET] <alexpigment> i'm not proud of it
[20:19:12 CET] <therage3> oh I see haha
[20:19:15 CET] <alexpigment> *hangs head in shame*
[20:19:21 CET] <therage3> meh, Ogg isn't _that_ new
[20:20:23 CET] <Darxus> Oh, I meant ogg theora, not vorbis, sorry.
[20:20:37 CET] <Darxus> And its creators seem to agree that it's obsolete. Which is why I'm now fighting with webm.
[20:20:56 CET] <alexpigment> it is indeed
[20:21:11 CET] <alexpigment> it was never even a real contendor with h.264
[20:21:23 CET] <Darxus> YES!
[20:21:53 CET] <Darxus> Reboot, play firefox test vp9 file, works, play ogg theora file, fails, play same vp9 file, fails.
[20:21:56 CET] Action: Darxus dies.
[20:22:40 CET] <alexpigment> anyway, since this is all about the presence of one file type versus the other, it may be worth defining file types for each one. in case it's just a matter of assuming theora for all videos after it plays the ogg
[20:22:46 CET] <alexpigment> type="video/ogg"
[20:22:52 CET] <alexpigment> then type="video/webm"
[20:23:08 CET] <alexpigment> not saying that's the problem, but it's worth a try and it's technically the "right" way to do it
[20:24:17 CET] <furq> don't use theora at all any more
[20:24:35 CET] <furq> the last browser that could play theora but not h264 or vp9 was like firefox 38 on linux or something
[20:25:41 CET] <alexpigment> and fortunatey, you should be able to get away with a re-encode from theora to vp9 with very little quality loss or file size increase
[20:25:53 CET] <furq> i mean this is still broken and worth a bug report
[20:25:58 CET] <furq> but the workaround is to not use theora
[20:26:01 CET] <alexpigment> since you're really jumping over two successive formats
[20:26:05 CET] <furq> and you lose nothing by not doing that
[20:26:51 CET] <Darxus> furq: Yeah the theora file is 6 years old.
[20:28:41 CET] <Darxus> I think in addition to this glitch related to theora, it also doesn't support vp9 444. But before loading the ogv, v09 420 and vp8 work.
[20:28:48 CET] <Darxus> vp9 420 and vp8 work.
[20:28:52 CET] <Darxus> My poor brain.
[20:29:31 CET] <alexpigment> going back, that *could* still be related to the hwdec situation
[20:29:44 CET] <alexpigment> but then again, you said that chrome played it
[20:30:20 CET] <alexpigment> i don't have much android experience, but is there a way to view CPU usage and see if the yuv420 and yuv444 are night and day in terms of CPU usage?
[20:30:38 CET] <alexpigment> (in chrome, i mean)
[20:31:06 CET] <Darxus> Oh no. I just tried to play the theora file, then successfully played their cake test vp9 file.
[20:31:09 CET] <alexpigment> if so, it could mean that chrome is pushing the yuv444 to cpu and firefox isn't
[20:31:29 CET] <alexpigment> right, but you're saying that firefox doesn't play the yuv444 still
[20:31:38 CET] <Darxus> Yes.
[20:33:09 CET] <alexpigment> in which case, if you play the yuv420p file in chrome, then play the yuv444p file in chrome (which presumably both work), if you can see what the CPU usage is, you may be able to confirm whether it's using the hardware decoder for both, or if it's pushing the yuv444p to the software decoder. and that might help explain the issue better
[20:33:51 CET] <alexpigment> the theora thing, of course, is another issue altogether
[20:34:25 CET] <alexpigment> and one that probably has gone unreported because it's unlikely to find theora and vp9 on the same page, i'd guess
[20:34:42 CET] <Darxus> It's not (just) the theora file :(
[20:34:51 CET] <alexpigment> is it any non-vp9 file?
[20:35:15 CET] <Darxus> My testing seems to be complicated by firefox rendering pages whenever I look at the list of open tabs.
[20:35:15 CET] <alexpigment> like does it happen with a vp8 and a vp9 file on the same page?
[20:35:47 CET] <Darxus> There's a vp8 and theora file on this same page, which does still seem to consistently cause the problem.
[20:35:52 CET] <alexpigment> ahhh, that sounds like one of those "features" they can advertise as benefits but just end up as detriments
[20:36:06 CET] <Darxus> ?
[20:36:18 CET] <alexpigment> well, if it's preloading pages, that's probably a "feature"
[20:36:23 CET] <Darxus> Oh, right, that.
[20:36:57 CET] <alexpigment> anyway, if you have, say, vp8 in place of theora, does the vp9 file have the same problem?
[20:39:24 CET] <unkmar> I use Debian and have been unable to make ffmpeg happy with my webcam. No luck with my rawvideo pix_map settings.
[20:40:06 CET] <unkmar> The camera works fine in VLC. It is a GSPCA SPA505.
[20:41:10 CET] <Darxus> Uugh, I can't figure it out.
[20:47:14 CET] Action: Darxus cries.
[20:47:17 CET] <Darxus> I just don't know.
[20:49:00 CET] <unkmar> https://pastebin.com/v0YaJR12
[20:50:09 CET] <Darxus> Maybe it's just that the page is ridiculously humongous.
[20:50:12 CET] <c_14> unkmar: does it output rgb maybe?
[20:51:45 CET] <c_14> try -list_formats all instead of 1
[20:51:50 CET] <unkmar> c_14: I'm not sure I understand your question. It is a USB cam. It does have a Video port that I could attach to a Video capture card. I do NOT have one of those.
[20:52:37 CET] <unkmar> c_14: Sorry, That IS all formats. and I did rerun the command changed to all instead of one. It only has that Raw format.
[20:52:51 CET] <c_14> In the first non list_formats call you explicitly request YYUV, try dropping that?
[20:53:18 CET] <unkmar> Yeah, that fails too.
[20:53:26 CET] <c_14> same error?
[20:54:26 CET] <unkmar> Cannot find a proper format for codec 'rawvideo' (id 14), pixel format 'none' (id -1) --- Assertion *codec_id != AV_CODEC_ID_NONE failed at libavdevice/v4l2.c:808
[20:55:06 CET] <c_14> try -pix_fmt rgb0 maybe
[20:55:33 CET] <c_14> when you open the device in vlc can you get info about it, like device/file/stream properties or w/e?
[20:55:40 CET] <unkmar> that fails too. At least we are trying things I didn't know.
[20:56:09 CET] <unkmar> Well... Currently, I have ssh only to the system.
[20:57:00 CET] <unkmar> I am accessing by remote. Which is why I wanted ffmpeg to work. Was hoping to stream the data. :(
[20:57:15 CET] <c_14> can you try dumping info using the v4l2 tools?
[20:57:54 CET] <unkmar> And, all my attempts at transcoding with vlc fail with a Floating point exception. :(
[20:57:58 CET] <unkmar> Yes, I have v4l2 tools.
[20:58:55 CET] <unkmar> https://pastebin.com/fH5ak3xw
[21:00:00 CET] <c_14> try --all instead of --info?
[21:00:34 CET] <unkmar> I had just realized that.
[21:01:07 CET] <unkmar> $ v4l2-ctl --all
[21:01:07 CET] <unkmar> Driver Info (not using libv4l2):
[21:01:08 CET] <unkmar> Driver name : spca505
[21:01:08 CET] <unkmar> Card type : USB Camera (0733:0430)
[21:01:08 CET] <unkmar> Bus info : usb-0000:00:1d.0-1.6.3
[21:01:10 CET] <unkmar> Driver version: 4.9.51
[21:01:12 CET] <unkmar> Capabilities : 0x85200001
[21:01:15 CET] <unkmar> Video Capture
[21:01:17 CET] <unkmar> Read/Write
[21:01:20 CET] <unkmar> Streaming
[21:01:22 CET] <unkmar> Extended Pix Format
[21:01:25 CET] <unkmar> Device Capabilities
[21:01:27 CET] <unkmar> Device Caps : 0x05200001
[21:01:30 CET] <unkmar> Video Capture
[21:01:32 CET] <unkmar> Read/Write
[21:01:35 CET] <unkmar> Streaming
[21:01:37 CET] <unkmar> Extended Pix Format
[21:01:40 CET] <unkmar> Priority: 2
[21:01:42 CET] <unkmar> Video input : 0 (spca505: ok)
[21:01:45 CET] <unkmar> Format Video Capture:
[21:01:47 CET] <unkmar> Width/Height : 352/288
[21:01:48 CET] <alexpigment> i'm scared to know how long this will go on :)
[21:01:50 CET] <unkmar> Pixel Format : 'S505'
[21:01:52 CET] <unkmar> Field : None
[21:01:55 CET] <unkmar> Bytes per Line : 352
[21:01:58 CET] <unkmar> Size Image : 152064
[21:02:00 CET] <unkmar> Colorspace : sRGB
[21:02:02 CET] <unkmar> Transfer Function : Default
[21:02:05 CET] <unkmar> YCbCr/HSV Encoding: Default
[21:02:07 CET] <unkmar> Quantization : Default
[21:02:10 CET] <unkmar> Flags :
[21:02:12 CET] <unkmar> Streaming Parameters Video Capture:
[21:02:15 CET] <unkmar> Frames per second: invalid (0/0)
[21:02:17 CET] <unkmar> Read buffers : 2
[21:02:20 CET] <unkmar> User Controls
[21:02:22 CET] <unkmar> brightness (int) : min=0 max=255 step=1 default=127 value=127 flags=slider
[21:02:25 CET] <unkmar> Ugh.
[21:02:28 CET] <unkmar> https://pastebin.com/a264npjz
[21:02:30 CET] <unkmar> That was not intended. I hit the wrong key to cancel.
[21:09:29 CET] <c_14> looks like ffmpeg doesn't support the pixel format you need for that device, or at least doesn't support that identifier
[21:10:14 CET] <unkmar> Okay. That is what I had assumed. But I don't know as much as you about it.
[00:00:00 CET] --- Sat Dec 30 2017
More information about the Ffmpeg-devel-irc
mailing list