I am developing an android application. I am sending stream (audio+video) from Mobile to Wowza. I am using Libstreaming library for streaming. The video quality is too bad. How can we improve it (atleast some text should be readable.)
In my code if you see I have commented the video quality (bad with mentioned parameters) method. If i uncomment it, It shows the green cover over the video screen.
And also, is it possible to make quality device independent ?
My streaming code is:
mSession = SessionBuilder
.getInstance()
.setContext(getApplicationContext())
.setAudioEncoder(SessionBuilder.AUDIO_AAC)
.setAudioQuality(new AudioQuality(8000, 16000))
.setVideoEncoder(SessionBuilder.VIDEO_H264)
//.setVideoQuality(new VideoQuality(352, 288, 30, 300000))
.setCamera(CameraInfo.CAMERA_FACING_BACK)
.setSurfaceView(mSurfaceView).setPreviewOrientation(0)
.setCallback(this).build();
Thanks.
Related
I've been using the Xamarin libVLCSharp player for a while on iOS and Android and it works well. I've added a transcoding feature, but for some reason my libVLCSharp code works fine to transcode on Android (change codec, bitrate, fps), but the same transcode media options on iOS (iPhone 12 pro, iOS 14.4.2) produce no changes in the output video file compared to the input video file. I have attached the sample video file which I am attempting to transcode.
Here is my C# code (which contains the transcode media options that works on Android, but not iOS):
Core.Initialize();
_vlc = new LibVLC();
_player = new LibVLCSharp.Shared.MediaPlayer(_vlc);
_media = new Media(_vlc, _source, FromType.FromPath);
_media.AddOption ($":sout=#transcode{{vcodec=h264,vb=700000,acodec=aac,ab=96,channels=2,samplerate=44100,scodec=none}}:std{{access=file,mux=ts,dst={destination}}}");
var result = _player.Play(_media);
Any help or pointers on why this transcoding command is not producing any change in the output media file compared to the original would be greatly appreciated!
iOS Logfile
https://drive.google.com/file/d/1C0UGzE7hqCJYozTvubyK1BKWcZvG18VY/view
Sample file I'm using to test transcoding:
https://drive.google.com/file/d/1MvJKJnu2ii6XMANuWRkHLqmu78e9x03q/view
Try with
$":sout=#transcode{venc={module=avcodec{codec=h264_videotoolbox}, vcodec=h264},venc={module=vpx{quality-mode=2},vcodec=VP80},samplerate=44100,soverlay}:file{dst={destination},mux=ts}"
Feel free to remove unnecessary options, but from my findings this exact string should work.
I am able to use the moviepy library to add a watermark to a section of video. However when I do this it is taking the watermarked segment, and creating a new file with it. I am trying to figure out if it is possible to simply splice in the edited part back into the original video, as moviepy is EXTREMELY slow writing to the disk, so the smaller the segment the better.
I was thinking maybe using shutil?
video = mp.VideoFileClip("C:\\Users\\admin\\Desktop\\Test\\demovideo.mp4").subclip(10,20)
logo = (mp.ImageClip("C:\\Users\\admin\\Desktop\\Watermark\\watermarkpic.png")
.set_duration(20)
.resize(height=20) # if you need to resize...
.margin(right=8, bottom=8, opacity=0) # (optional) logo-border padding
.set_pos(("right","bottom")))
final = mp.CompositeVideoClip([video, logo])
final.write_videofile("C:\\Users\\admin\\Desktop\\output\\demovideo(watermarked).mp4", audio = True, progress_bar = False)
Is there a way to copy the 10 second watermarked snippet back into the original video file? Or is there another library that allows me to do this?
What is slow in your use case is the fact that Moviepy needs to decode and reencode each frame of the movie. If you want speed, I believe there are ways to ask FFMPEG to copy video segments without rencoding.
So you could use ffmpeg to cut the video into 3 subclips (before.mp4/fragment.mp4/after.mp4), only process fragment.mp4, then reconcatenate all clips together with ffmpeg.
The cutting into 3 clips using ffmpeg can be done from moviepy:
https://github.com/Zulko/moviepy/blob/master/moviepy/video/io/ffmpeg_tools.py#L27
However for concatenating everything together you may need to call ffmpeg directly.
I am trying to write a C++/Qt program for linux, where I take a still image photo from a webcam, make some transformations to a photo (cropping, resizing, etc.), and save it to a jpeg file.
But I have encountered some problems. The main problem is that standart UVC (usb video device class) linux driver currently does not support direct still image capture: http://www.ideasonboard.org/uvc/ .
So, there are two possible ways to capture still image. You can take one frame from the video stream from the camera, or you can take a separate photo, like a digital portable camera. The second way is not supported in linux uvc driver, so the first method is the only way. But the problem is, that if you want to take a frame from the video stream, the size of the photo can't be bigger than the size of video in the video preview window. So, if I want to take 2 megapixel photo, I must start videostream with the size 1600x1200, which is not so comfortable (At least, in Qt the size of the videostream depends on the videopreview window size).
I know that there is video for linux 2 API, which may be helpful in this task, but I don't know how to use it. I am currently learning gstreamer, but I can't now figure out how to do what I need using these tools.
So, I will appreciate any help. I think it is not a hard problem for people who know Linux, GStreamer, v4l2 API, and other linux-specific things.
By the way, the program will be used only with web-camera Logitech C270 HD.
Please, help me. I don't know what API or framework can help me do this. May be you know.
Unfortunately the C4V2 calls in opencv did not work for still image capture with any camera I have tried out of the box using the UVC driver.
To debug the issue I have been playing with trying to accomplish this with c code calling c4v2 directly.
I have been playing with the example code found here. It uses the method of pulling frames from the video stream.
You can compile it with:
gcc -O2 -Wall `pkg-config --cflags --libs libv4l2` filename.c -o filename
I have experimented with 3 logitech cameras. The best of the lot seems to be the Logitech C910. But even it has significant issues.
Here are the problems I have encountered trying to accomplish your same task with this code.
It works pretty much every time with width and height set to 1920x1080.
When I query other possibilities directly from the command line using for example:
v4l2-ctl --list-formats-ext
and I try some of the other "available" smaller sizes it hangs in the select waiting for the camera to release the buffer.
Also when I try to set other sizes directly from the command line using for example:
v4l2-ctl -v height=320 -v width=240 -v pixelformat=YUYV
Then check with
v4l2-ctl -V
I find that it returns the correct pixel format but quite often not the correct size.
Apparently this camera which is listed on the UVC site as being UVC and therefore v4l2 compatible is not up to snuff. I suspect it is just as bad for other cameras. The other two I tried were also listed as compatible on the site but had worse problems.
I did some more testing on the LogitechC910 after I posted this. I thought I would post the results in case it helps someone else out.
I wrote a script to test v4l2 grabber code mentioned above on all the formats the camera claims it supports when it is queried with v4l2 here are the results:
640x480 => Hangs on clearing buffer
160x120 => Works
176x144 => Works
320x176 => Works
320x240 => Works
432x240 => Works
352x288 => Works
544x288 => Works
640x360 => Works
752x416 => Hangs on clearing buffer
800x448 => Hangs on clearing buffer
864x480 => Works
960x544 => Works
1024x576 => Works
800x600 => Works
1184x656 => Works
960x720 => Works
1280x720 => Works
1392x768 => Works
1504x832 => Works
1600x896 => Works
1280x960 => Works
1712x960 => Works
1792x1008 => Works
1920x1080 => Works
1600x1200 => Works
2048x1536 => Works
2592x1944 => Hangs on clearing buffer.
It turns out that the default setting of 640x480 doesnt work and that is what trapped me and most others who have posted on message boards.
Since it is grabbing a video frame the first frame it grabs when starting up may have incorrect exposure (often black or close to it). I believe this is because since it is being used as a video camera it adjusts exposure as it goes and doesnt care about the first frames. I believe this also trapped me and other who saw the first frame as black or nearly black and thought it was some kind of error. Later frames have the correct exposure
It turns out that opencv with python wrappers works fine with this camera if you avoid the land mines listed above and ignore all the error messages. The error messages are due to the fact while the camera accepts v4l2 commands it doesnt respond correctly. So if you set the width it actually gets set correctly but it responds with an incorrect width.
To run under opencv with python wrappers you can do the following:
import cv2
import numpy
cap = cv2.VideoCapture(0) #ignore the errors
cap.set(3, 960) #Set the width important because the default will timeout
#ignore the error or false response
cap.set(4, 544) #Set the height ignore the errors
r, frame = cap.read()
cv2.imwrite("test.jpg", frame)
**Download And Install 'mplayer'**
mplayer -vo png -frames 1 tv://
mplayer -vo png -frames 1 tv://
might give a green screen output as the camera is not yet ready.
mplayer -vo png -frames 2 tv://
You can try increasing the number of frames and choose a number from which the camera gives correct images.
What about this program?
#include<opencv2/opencv.hpp>
using namespace cv;
int main()
{
VideoCapture webcam;
webcam.open(0);
Mat frame;
char key;
while(true)
{
webcam >> frame;
imshow("My Webcam",frame);
key = waitKey(10);
if(key=='s')
break;
}
imwrite("webcam_capture.jpg", frame);
webcam.release();
return 0;
}
This will capture a picture of maximum size allowed by your webcam. Now you can add effects or resize the captured image with Qt. And OpenCV is very very easy to integrate with Qt, :)
Greetings fellow amazonians
We have certain f4v files from webtvinteractive.com that are not working from a streaming distribution. The cloudfront diagnostic tool indicates the file is not found but from a download distribution they play all ok fine ??
When inspecting the codec the only difference we see is that the audio is encoded as MPEG audio layer 1/2/3 (mpga) instead of AAC (mp4a)
Also noticed that VP6F is used but that is a Abobe proprietary codec so it should stream all ok from Flash Media Server
Here is the test tool url:
http://d1k5ny0m6d4zlj.cloudfront.net/diag/CFStreamingDiag.html
s3dbhkulzq9ndp.cloudfront.net
teaser.f4v (ok)
EM2_H264.f4v (NOT ok)
StreamLen Response: 0 ??
Received an answer from AWS team member
Posted by: RonS#AWS
Posted on: Oct 10, 2011 7:29 AM
https://forums.aws.amazon.com/message.jspa?messageID=284676
Hi, I downloaded both of your video objects and ran flvcheck (http://help.adobe.com/en_US/FlashMediaServer/3.5_AdminGuide/WS5b3ccc516d4fbf351e63e3d119f29261b7-7ffc.html) against them.
The teaser.f4v is apparently OK according to flvcheck, but EM2_H264 gets this:
11-10-10 07:10:25 Error: -26 File appears to be FLV with wrong extension. EM2_H264.f4v
If I rename the file to have a .flv extension, I get "Found backward timestamp".
I suspect the FMS software we're using will have the same complaints about that file that flvcheck does.
flvcheck is available for download here (you'll need to register with Adobe): http://www.adobe.com/products/flashmediaserver/tool_downloads/
Hey I'm following Derek Molloy's tutorial:
http://derekmolloy.ie/beaglebone/beaglebone-video-capture-and-image-processing-on-embedded-linux-using-opencv/#comment-30209
Using a Logitech c310 webcam, that is supported by the Linux UVC drivers.
root#beaglebone:/boneCV# v4l2-ctl --all
Driver Info (not using libv4l2):
Driver name : uvcvideo
Card type : UVC Camera (046d:081b)
Bus info : usb-musb-hdrc.1.auto-1
Driver version: 3.8.13
Capabilities : 0x84000001
Video Capture
Streaming
Format Video Capture:
Width/Height : 640/480
Pixel Format : 'YUYV'
Field : None
Bytes per Line: 1280
Size Image : 614400
Colorspace : SRGB
Crop Capability Video Capture:
Bounds : Left 0, Top 0, Width 640, Height 480
Default : Left 0, Top 0, Width 640, Height 480
Pixel Aspect: 1/1
Video input : 0 (Camera 1: ok)
Streaming Parameters Video Capture:
Capabilities : timeperframe
Frames per second: 30.000 (30/1)
Read buffers : 0
Priority: 2
So we can see it is read by the Beagleboard no problem.
When I try to capture the video, I simply get this error:
root#beaglebone:/boneCV# ./capture -f -c 600 -o > output.raw
Force Format 1
select timeout
Looking at other threads, people don't seem to know how to answer this question, can anyone with experience on this project help me out?
If you compare the image size of YUYV and that of MJPEG you will notice that the former is much larger than the latter. BBB has limited bandwidth on its USB port so thats why you cannot operate your camera in YUYV format. MJPEG outputs compressed video stream. Different opencv versions tend to change the resolution that you set with v4l2-ctl command so you have to change the resolution in the boneCV code. I'm not sure how its done in c++ but in python, check Changing camera resolution in opencv code. According to Matthew, Bandwidth limitations he tested and found out the bandwidth to be 13.2MB/s.
Well I can say the issue is resolved. After rebooting and trying the camera again after several hours, it magically seems to work.
The only thing I changed is the capture call to be simpler it is now:
./capture -o > output.raw
I haven't converted the raw file to mpeg4 yet, since I'm installing ffmpeg as I type this, however I can confirm that grabbing still images is working. The filesize of the output.raw is confirmation that it is indeed capturing video as well. If anyone finds this and is stuck, I will be glad to give assistance as much as I can.
Strangely, it only seems to capture video after using the picture grabber program first. So there must be something the grabber is initializing that isn't happening in the capture.
UPDATE: Ok it turns out that the YUYV video mode is not working but the mjpeg does, putting it into grabber mode initialized mjpeg mode and that's why it worked. Not sure why YUYV doesn't work yet.