I have a website with an HTML5 audio element whose audio data shall be served via a cgi script.
The markup is rather simple:
<audio controls>
<source type="audio/mpeg" src="audio.cgi?test.mp3">
<em>Me, your browser does not support HTML5 audio</em>
</audio>
The cgi is written in C++ and is pretty simple too, I know there is need of optimizing, e.g. reading the whole file in a buffer is really bad, but that's not the point.
This basic version kinda works, meaning the audio is played, but the player does not display the full length and one can only seek through the track in parts that have already been played.
If the audio file is placed in a location accessible via the web-server everything works fine.
The difference between these two methods seems to be, that the client issues a partial-content request if the latter method is chosen and an ordinary 200 if I try to serve the audio data via the cgi at once.
I wanted to implement partial-content serving into the cgi but I failed to read out the environment variable Request-Range, which is needed to serve the requested part of data.
This leads me to my questions:
Why does the HTML5 player not display the full length of the track if I'm serving the audio data via the cgi script?
Would implementing a partial-content handling solve this issue?
If the partial-content handling is the right approach, how would I access the required environment variables in apache, since I have not found anything about them? Do I need to send a complete HTTP header indicating partial-content is coming, so the client knows he needs to send the required fields?
This is the source of the .cgi:
void serveAudio()
{
//tried these, were not the right ones
//getenv("HTTP_RANGE");
//getenv("HTTP_CONTENT_RANGE");
ifstream in(audioFile, ios::binary | ios::ate);
size_t size = in.tellg();
char *buffer = new char[size];
in.seekg(0, ios::beg);
in.read(buffer, size);
cout<<"Content-Type: audio/mpeg\n\n";
cout.write(buffer, size);
}
Any suggestions and helpful comments are appreciated!
Thanks in advance!
P.S.:
Forgot to mention that this behaviour applies to FF 31 and IE 11.
Related
I'm stuck and I need help.
I'm trying to write the correct code for sending back an image file so the web browser can render it. It can send back text/html just fine, but image/* is not working.
You can see the code and the URL is shown below.
https://github.com/MagnusTiberius/iocphttpd/blob/master/iocphttpl/SocketCompletionPortServer.cpp
What the browser is receiving is just a few bytes of image data.
I tried vector, std::string and const char* to set the values of WSABUF, but still the same few bytes are sent over.
Please let know what is the missing piece to make this one work.
Thanks in advance.
Here's your problem:
PerIoData->LPBuffer = _strdup(str.c_str());
The _strdup function only copies up until the first null, so it cannot be used to copy binary data. Consider using malloc and memcpy if you don't want to use the C++ library.
The alternate implementation (in the false branch) is also incorrect, because it saves the data in an object (vc) that goes out of scope before the I/O is completed. You could instead do something like
vector<char> * vc = new vector<char>;
Purpose: I am monitoring file writes in a particular directory on iOS using BSD kernel queues, and poll for file sizes to determine write ends (when the size stops changing). The basic idea is to refresh a folder only after any number of file copies coming from iTunes sync. I have a completely working Objective-C implementation for this but I have my reasons for needing to implement the same thing in C++ only.
Problem: The one thing stopping me is that I can't find a C or C++ API that will get the correct file size during a write. Presumably, one must exist because Objective-C's [NSFileManager attributesOfItemAtPath:] seems to work and we all know it is just calling a C API underneath.
Failed Solutions:
I have tried using stat() and lstat() to get st_size and even st_blocks for allocated block count, and they return correct sizes for most files in a directory, but when there is a file write happening that file's size never changes between poll intervals, and every subsequent file iterated in that directory have a bad size.
I have tried using fseek and ftell but they are also resulting in a very similar issue.
I have also tried modified date instead of size using stat() and st_mtimespec, and the date doesn't appear to change during a write - not that I expected it to.
Going back to NSFileManager's ability to give me the right values, does anyone have an idea what C API call that [NSFileManager attributesOfItemAtPath:] is actually using underneath?
Thanks in advance.
Update:
It appears that this has less to do with in-progress write operations and more with specific files. After closer inspection there are some files which always return a size, and other files that never return a size when using the C API (but will work fine with the Objective-C API). Even creating a copy of the "good" files the C API does not want to give a size for the copy but works fine with the original "good" file. I have both failures and successes with text (xml) files and binary (zip) files. I am using iTunes to add these files to the iPad's app's Documents directory. It is an iPad Mini Retina.
Update 2 - Answer:
Probably any of the above file size methods will work, if your path isn't invisibly trashed, like mine was. See accepted answer on why the path was trashed.
Well this weird behavior turned out to be a problem with the paths, which result in strings that will print normally, but are likely trashed in memory enough that file descriptors sometimes didn't like it (thus only occurring in certain file paths). I was using the dirent API to iterate over the files in a directory and concatenating the dir path and file name erroneously.
Bad Path Concatenation: Obviously (or apparently not-so-obvious at runtime) str-copying over three times is not going to end well.
char* fullPath = (char*)malloc(strlen(dir) + strlen(file) + 2);
strcpy(fullPath, dir);
strcpy(fullPath, "/");
strcpy(fullPath, file);
long sizeBytes = getSize(fullPath);
free(fullPath);
Correct Path Concatenation: Use proper str-concatenation.
char* fullPath = (char*)malloc(strlen(dir) + strlen(file) + 2);
strcpy(fullPath, dir);
strcat(fullPath, "/");
strcat(fullPath, file);
long sizeBytes = getSize(fullPath);
free(fullPath);
Long story short, it was sloppy work on my part, via two typos.
I sincerely apologize if this has been asked before, however I was unable to find a suitable answer that appeared similar to my current situation. I am developing an app with MoSync using the MAUI because of the same appearance across all platforms. I am running into issues with understanding MAHandles, as well as how to go about sending the SQLite information to a web address. The SQLite commands will then be converted to MySQL commands using a RedBean PHP script, and then sent to the permanent database.
My biggest concerns are 2 items:
1.Declaring connections that are usable through MAHandles (I have already gotten the SQLite commands working without using MAHandles, however declaring the database address in the resources.lstx still evades me)
2.Declaring MAHandles in general.
Also, I understand that strings are much more effective, however I disregard that fact due to the age of MAUI and it's capabilities appear much smoother when using char arrays.
I can provide additional clarification if needed so that I can help speed this process up.
Thank you ahead of time, and hopefully this will help others trying their hands at MoSync's immaculate product.
I have no experience with SQLite whatsoever, but I'm assuming handling SQLite commands is the job of your server-side application. To be clear, you are sending SQLite commands from your mobile app to a server-side app via a URL, correct? If you need help on this you should search "CGI". CGI is essentially a way to execute a server-side application with arguments via an http:// request.
This means your app should have a manager that constructs a URL with the right SQLite commands based on the input events sent to your mobile app (buttons, text fields, etc).
As far as Mosync goes, MAHandles can be used for many things including downloading.
Take a look at the MAUtil::DownloadListener class on Mosync's doxygen pages.
You will see that there are full descriptions of 5 pure virtual functions that you will need to implement.
The bulk of your code will probably be in finishedDownloading( Downloader* dl, MAHandle data ). It is here that the MAHandle "data", will point to the beginning of the data segment that you downloaded.
I read my data into a char* since I am downloading text.
Here's a snippet:
void MainScreen::finishedDownloading( Downloader* dl, MAHandle data )
{
char* mData = new char[ maGetDataSize( data ) + 1 ];
memset( mData, 0, maGetDataSize( data ) + 1 );
maReadData( data, mData, 0, maGetDataSize( data ) );
// Destroy the store
maDestroyObject( data );
// Do something with mData;
}
Here's one example of setting the font of NativeUI::Widget text using an MAHandle:
MAHandle font = maFontLoadDefault( FONT_TYPE_SERIF |
FONT_TYPE_MONOSPACE |
FONT_STYLE_NORMAL, 0, Dimensions::DIM_LIST_ELEM_FONT_SIZE );
ListViewItem* items = new ListViewItem();
items -> setFont( font );
After making a small video recorder application and being able to play that video again. I would like to make the possibility to pick X seconds from the video and put that into a new .MP4 file (or overwrite the old one, that would be even better).
I am using the MoSync C++ Native UI and VideoViewer. I know I can get the position and that part is all fine, and according to the MoSync documentation.
char buf[BUFFER_SIZE];
maWidgetGetProperty(videoViewHandle,
MAW_VIDEO_VIEW_CURRENT_POSITION,
buf,
BUFFER_SIZE);
int seconds = 5;
//So here I need to make a new file ranging from buf to buf + seconds
However, I have absolutely no clue as to where to look for this. Should I use mp4 header files and create my own mp4 (how is this even done? and is this cross-compatible?).
Will appreciate any advice/help you can offer!
Below is the code I am using to play a video
QFile* file =new QFile(“C:\\Video\\test.avi”);
media->setCurrentSource(Phonon::MediaSource(file));
media->play();
Using this code the playback fails -what I see is the play bar at the bottom but the video never starts.
If I change the code to the following everything works as expected
media->setCurrentSource(Phonon::MediaSource(“C:\\Video\\test.avi”));
media->play();
Are there additional initialization steps required when using an iodevice? Ultimately my code will be using a custom iodevice which is not working as well.
This is an old post, but I wanted to clear up any confusion out in case it will help someone in the future.
QT does allow you to pass Phonon::MediaSource() a QIODevice. We successfully deployed our solution by creating our own subclass of QIODevice.
The reason it was not working for me was QT was having an issue with the codec I was using. When you use the QIO device you don't get the same format support as you would if you pass a string.
One other thing to note, while this solution works great on windows. On a mac when using the QIO device the entire file will be loaded into memory before it plays. In my case this was a deal breaker. Having an encrypted file is usless if the first thing you do is de-crypt the entire file and load it into memory.
From the Phonon::MediaSource documentation:
Warning: On Windows, we only support QIODevices containing the avi,
mp3, or mpg formats. Use the constructor that takes a file name to
open files (the Qt backend does not use a QFile internally).
I think that the last line should answer your question. Instead of a QFile, you can use a QString, or call the function QFile::fileName like this:
QFile* file =new QFile(“C:\\Video\\test.avi”);
media->setCurrentSource(Phonon::MediaSource(file->fileName()));
media->play();
If you take a careful look in the [Phonon Module docu][1], you will see that MediaSource cannot be constructed with QFile*.
By the way I don't see in your code any phonon paths. At least you should create audio sink and connect it with the mediaobject:
Phonon::AudioOutput *audioOut = new PhononAudioOutpu(Phonon::MusicCategory);//or the category you need
Phonon::createPath(mediaObject, audioOutput);
mediaObject->play();
Works fine with QFile