I'm trying to adapt a code in order to add a sound capture feature (on a live stream), with the help of ffmpeg and directshow.
When i try to play with ffplay the AVIsynth file, everything works perfectly i've got the audio and video. But when i open this input file by code i only find the video stream.
The Avs file :
V = DirectShowSource("Decklink_HDMI.grf", fps=10, framecount=1000000000, seek=false, audio=false)
A = DirectShowSource("Decklink_Audio.grf", fps=1, framecount=1000000000, video=false)
AudioDub(V, A)
The opening code :
ffmpeg::AVInputFormat * ifmt;
ifmt = ffmpeg::av_find_input_format("avs");
// Open input file
if(ffmpeg::avformat_open_input(&pFormatCtx, filename.toStdString().c_str(), ifmt, NULL) != 0)
When i make a variable lookout on gdb just after the opening.
i'm looking at nb_streams in pFormatCtx->nb_streams and it's at 1
The only stream i can find in pFormatCtx->stream is a video one. And that's why i'm not able to capture the sound.
So i'm asking if i'm doing something wrong with my opening or if i miss something.
Ps : I know the code shown is short but the problem appears at this very step !
Thank you
Kurt
-- EDIT --
I've also noticed that when I dump the AVFormatContext the video stream got a 456x32 size.
And i can find this very same size of the window displayed when i try to launch a corrupted script with ffplay.
The original video format when i play the correct script with ffplay is of 1920x1080
I think my problem is maybe deeper than the simple fact of not being able to get the audio stream.
I'm trying to find out how to know the error message that is displayed on this 456x32 windows
-- EDIT2 --
I Find out what is written on this image and my problem is solved, badly placed avs script an old one was is place.
I'm ashamed.
My bad,
A badly placed avs file was my problem.
Anyway ffmpeg is a bit painful in his way of showing error, being forced to make a snapshot without any error msg or exception raised (or maybe did i failled).
Related
If you run the command-line version of unrar it logs out vital information when an archive fails to extract.
I'm trying to do the same thing with the unrar DLL.
I've already had to make some changes to the DLL source code to support registering my own callback to handle extraction progress properly.
Now I want to handle error reporting properly.
There is really no documentation on using unrar source.
So I have a working callback function that can be called
CommandData *Cmd
Cmd->ErrorCallback(ERAR_BAD_DATA, Arc.FileName, ArcFileName);
The function works great if I call it next to my progress DLL (so I know the callback works), but I just can't figure out where the errors are being handled.
Specifically I'm after handling the code ERAR_BAD_DATA which I found is handled in extract.cpp ... but that code just doesn't seem to get run.
I also found some calls to RarErrorToDll ... I put the callback there too, nothing.
Any help would be hugely appreciated.
for a bit of context, this is what I was previously doing to catch errors.
bool archiveCorrupt = false;
while((read_header_code = RARReadHeader(archive_data, &header_data)) == 0)
{
process_file_code = RARProcessFile(archive_data, RAR_EXTRACT, m_output_dir, NULL);
if(process_file_code)
{
qDebug() << "Error extracting volume!"
<< header_data.ArcName << " "
<< " with error: " << process_file_code;
archiveCorrupt = true;
break;
}
}
The reason this approach doesn't work is that the error code process_file_code tells you what went wrong, but the archive name in header_data.ArcName is the archive that the file started in, not necessarily where the corruption was. I'm dealing with multi-part archives where one large file will span multiple archives ... so I need to know which archive(s) is corrupt, not just the archive the file started in.
EDIT:
Here is a link to the unrar source code
So I've discovered a place in extract.cpp line 670 that I can place the callback and it does return an error code to my app.
ErrHandler.SetErrorCode(RARX_CRC);
#ifdef RARDLL
Cmd->ErrorCallback(RARX_CRC, Arc.FileName, ArcFileName);
However, this has the same issue as before, where it returns the error at the end of processing the file extracting, rather than at the place where the CRC fails.
If I run the unrar command-line app that you can download from the rarlabs site, it seems to handle it properly and returns the correct error. I can't find text for those errors anywhere in the unrar source, so I can only assume that the unrar source doesn't actually build the unrar app they publish on their site.
Extracting from SL - Cinematic Guitars.part02.rar
... SL - Cinematic Guitars/Cinematic Guitars/Samples/Cinematic Guitars_001.nkx 16%
SL - Cinematic Guitars/Cinematic Guitars/Samples/Cinematic Guitars_001.nkx : packed data CRC failed in volume SL - Cinematic Guitars.part02.rar
I eventually found the answer, after lots of trial and error.
My issue was, I was comparing an old command line version of unrar to the newer source code when looking for the error messages.
The error message has changed in the new source code and is now
packed data checksum error in volume
This is defined in loclang.hpp and called from uiconsole.cpp in the function uiMsgStore:Msg when the error code is UIERROR_CHECKSUMPACKED
This gets called from volume.cpp on line 25
I have added my callback here, and it catches the error perfectly.
I hope this helps someone else if they ever have the misfortune of having to hack unrar source code.
This is driving me up the wall..
I've got a very simple SDL2 program.
It has a array of 3 SDL_Texture pointers.
These textures are filled as follows:
SDL_Texture *myarray[15];
SDL_Surface *surface;
for(int i=0;i<3;i++)
{
char filename[] = "X.bmp";
filename[0] = i + '0';
surface = SDL_LoadBMP(filename);
myarray[i] = SDL_CreateTextureFromSurface(myrenderer,surface);
SDL_FreeSurface(surface);
}
This works, no errors.
In the main loop (which is just a standard event loop waiting for SDL_QUIT, keystrokes and a user-event which a SDL_Timer puts in the event queue every second) I just do (for the timer triggered event):
idx = (idx+1) % 3; // idx is global var initially 0.
SDL_RenderClear(myrenderer);
SDL_RenderCopy(myrenderer, myarray[idx], NULL, NULL);
SDL_RendererPresent(myrenderer);
This works fine for 0.bmp and 1.bmp, but the 3rd image (2.bmp) simply shows as a black field.
This is structural.
If I alternate the first 2 images they are both fine.
If I alternate the 2nd and 3rd image the 3rd image doesn't show.
If I use more than 3 images then 3 and upwards show as black.
Loading order doesn't matter. It starts going wrong with the 3rd image loaded from disk.
All images are properly formatted BMP's.
I even saved 2.bmp back to disk under a different name by using SDL_SaveBMP() after it was loaded to make sure it got loaded in memory OK. The new file is bit for bit identical to the original.
This program, without modifications and the same bmp files, works fine on OSX (XCode5) and Windows (VC++ 2012 Express).
The problem only shows on the Raspberry PI.
I have placed explicit error checks on every call that can leave a result/error-code (not shown in the samples above for brevity) but all of them show "no error".
I have used the latest stable source set of www.libsdl.org and compiled as instructed (configure, make, make install, etc.).
Anybody got any idea what could be going on ?
P.S.
Keyboard input doesn't seem to work either on my PI, but I haven't delved into that yet.
Answering myself as I finally figured it out myself...
I finally went back to the README-raspberrypi.txt that came with the SDL2 sources.
I didn't read it carefully enough the first time around...
Problem 1: I'am running on a FULL-HD display. The PI's default GPU memory is 64MB which is not enough for large displays and double-buffering. As suggested in the README I increased this to 128MB and this solved the black image problem.
Problem 2: Text input wasn't working because my user-account was not in the input group. I had added the default "pi" account to the input group initially, but when I later started using another account I forgot to add that user to the group.
In short: Caught by my own (too) quick skimming of the documentation.
I'm working on a software which uses FFMPEG C++ libs to make an acquisition from an UDP streaming.
FFMPEG (1.2) is implemented and running but I get some errors (acquisition crashes and restarts). The log displays the following message:
*Circular buffer overrun. To avoid, increase fifo_size URL option. To survive in such case, use overrun_nonfatal option*
I searched online for documentation about how to use this option, but I only got informations about how to use when running directly ffmpeg executable.
Would someone know how to set the correct option in my C++ code to:
- increase fifo_size
- use overrun_nonfatal option
Thanks
The same option works from command line or C++ libraries, you need to modify your UDP URL as follows:
If you original URL looks like this:
udp://#239.1.1.7:5107
Add the fifo_size and overrun parameters like this:
"udp://#239.1.1.7:5107?overrun_nonfatal=1&fifo_size=50000000"
Remember to escape the URL with quotes.
overrun_nonfatal=1 prevents ffmpeg from exiting, it can recover in most circumstances.
fifo_size=50000000 uses a 50MB udp input buffer (default 5MB)
The only documentation is in the source code:
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/udp.c;h=5b5c7cb7dfc1aed3f71ea0c3e980be54757d3c62;hb=dd0a9b78db0eeea72183bd3f5bc5fe51a5d3f537
I don't have enough reputation to comment the other answer, but if I did I would say that studying the source linked in the answer:
fifo_size is measured as multiples of 188 Byte (packets) according to the line:
s->circular_buffer_size = strtol(buf, NULL, 10)*188;
so whilst Grant is roughly correct that "default 5MB", because of the line:
s->circular_buffer_size = 7*188*4096;
If you want a circular buffer of 50MB you should really set the fifo_size parameter to something closer to 50*1024*1024/188 otherwise 50000000 will give 50000000*188 bytes which is closer to 8965MB!
I am writing a program that uses OpenCV and involves intrinsic and distortion parameters. These parameters are loaded from .xml files saved on disc. I use the following commands in my opening declarations to load the files:
CvMat *intrinsic = (CvMat*)cvLoad("Intrinsics.xml");
CvMat *distortion = (CvMat*)cvLoad("Distortion.xml");
This works fine as long as the files are in the program's working directory. When they are not, the program crashes without any indication of the nature of the error. I have made the mistake of not having the xml files located correctly multiple times before, and I would like to make this easier to troubleshoot in the future.
I would like to create a guard against the files failing to load. Perhaps if they are not present my program could display an error message and exit gracefully. I saw the method suggested here, and it should work for me, but I was wondering if there was a cleaner way to do it without including another header.
For example, the OpenCV function cvQueryFrame returns 0 if it does not return a frame. I use the code
frame = cvQueryFrame(capture);
if(!frame)
{
printf("ERROR: Could not get frame from webcam.");
exit(-1);
}
to exit the program if cvQueryFrame fails to return a frame. I would like to do something similar with my matrix loading commands. Is this possible, and if so, how should I do it?
I checked the OpenCV documentation and could not find a description of cvLoad's behaviour when it cannot find the file specified so I am not sure how to proceed.
I am writing this project in C++ and running it on Windows 7.
It works. Go ahead and try it yourself:
CvMat *distortion = (CvMat*)cvLoad("Distortion.xml");
if (!distortion)
{
printf("!!! cvLoad failed");
exit(-1);
}
I am fetching the call-logs, appending them on information note using:
CAknInformationNote* note = new (ELeave) CAknInformationNote;
note->ExecuteLD(callLogs);
I perfectly run on emulator (show all call-logs on note) but nothing shows up when run on the actual device (a Nokia N73). Any ideas?
i think you should use some kind of file logging(you can even use RFile) and see till what point your application executing.i am assuming you dont see a crash/panic on hardware.i doubt if you are able to get the call logs properly first on device.