For the same video segment chromecast CAF receiver takes longer time to download comparing with PWA, android etc.
By say same video segment, I mean same host(url).
Things I have tried:
In CAF receiver inspector, I tracked the time taken for each segment to download. Then I played with web browser on the same segments. The time taken for chromecast to download each segment is tripled.
Copy the segment host url, use my macbook terminal: wget + segment host It only takes 0.5 seconds to download the segment, where in chromecast it takes 3-10 seconds to download.
Related
I am currently using Kdenlive, but have also used ffmpeg when I have the simple task of adding audio to a video that does not yet have audio. Since it is just a matter of putting the video file together with the audio, it seems like it ought to be simple. Is there something about encoding mp4's that means it must take a lot of processing to complete?
I have good hardware (i7 6700k and gtx 1080), but kdenlive currently estimates 2.5 hours to complete adding audio to a 10 minute video.
Without more info (encoder, settings, video width x height, instructions to duplicate the behavior, etc) we can only guess. It's probably re-encoding the video instead of only muxing it. Encoding is CPU intensive and takes a long time. Although 2.5 hours for 10 minutes seems excessive, but there is not enough info in the question to say why it takes this long.
If you want to add audio with ffmpeg see How to add a new audio into a video using ffmpeg? This will allow you to mux the video (and optionally the audio) without encoding it: like a copy and paste.
I'm trying to check 360 Video performance with version 11.62465, the 360 video output can't reach to 60P when we play FHD#60P 360 video. The video decode will update video frame in every 14ms~17 ms, but the application can't call SbPlayerGetCurrentFrame() 16ms, then the drop frame happens. The drop frame rate is nearly 20%. I tried to use chrome://tracing/ check the performance and found that sometimes the rasterizer lasted 40ms, the CPU duration is only 8ms, does this mean the GPU ability is not enough? Will the cobalt render thread be blocked by other modules?
If the CPU duration per-frame is 8ms, then it does sound like the GPU is not powerful enough to process each video frame fast enough. The Cobalt render thread should never be blocked by other modules, though it may be worth double checking that your implementation of SbPlayerGetCurrentFrame() is not taking a long time to render (perhaps it acquires a lock?).
You can use chrome://tracing/ to check the performance of the renderer when a non-360 FHD#60P video is playing, and compare that performance to when a 360 video is playing. This will tell you whether the renderer's performance is affected by the decode-to-texture process or not.
I'm working with a Raspberry Pi 3 that has a ribbon PiCamera. My problem is that I cannot get the still (not video) frame rate to be workable. In my application, the camera acts like a scanner using only a single row of each frame to watch things go by. While the concept is fine, what's killing me is the frame rate which I cannot get above 30 FPS.
A perfect solution would be for someone out there taking the raspicam source, stripped it down and tuning it for speed, and bolting it up to OpenCV. Has anyone done this? Did it work?
The Ava Group in Spain (https://www.uco.es/investiga/grupos/ava/node/40) took an initial stab at this, but their still frame rate is also limited to 30 FPS.
I'm converting my video to mp4 H.264 with ffmpeg than changing the moov atom to front with qt-faststart, so I can stream the video.
Everything works fine with small videos 5-10 minute, but when it comes to large ones 1-2 hrs it can take a significant time to start playing. it loads 6-10mb and only than start playing the video.
In flv that's not the case, it plays immediately no matter how large the video is. How can i fix that?
It is just the nature of the formats. The moov atom contains all the metadata for every frame of audio or video in the file. So, the more frames, the larger the moov. By putting all this metatadata in one place, it makes seeking within a file much easier. Once you have downloaded the moov, the player knows exactly what byte in the file to request to seek to a specific frame or time. An FLV file is sent one frame at a time, there is no index of frame locations, this makes seeking extremely difficult for the player.
You can try making the moov smaller by ensuring your video is not in variable frame rate, and that you do not have unnecessary data (such as movie posters) embedded in the metadata. Having the server send gzip streams may help as well as the moov should compress well.
I am developing an application in J2ME which have to processes images continuously taken from mobile camera. Its purpose is to detect the movement of the mobile and move an object on the screen. i am using
videoControl.getSnapshot("encoding=png&width=100&height=100");
to take images. But the problem is that it is taking about 4 sec to capture next image. It is very slow process.
Is there any way to get image faster?
Since mobile camera has 15 fps Video Recording Frame Rate, Cant we use that capability to capture images faster?
Currently I am targeting for Nokia E5 (target can be changed if not supported.)