both video & audio run as fast as possible - ffmpeg - c

using this code example (dranger - ffmpeg):
https://github.com/arashafiei/dranger-ffmpeg-tuto/blob/master/tutorial03.c
and dranger tutorial for ffmpeg:
http://dranger.com/ffmpeg/tutorial02.html
The video runs as fast as possible but it makes sense because there is no timer and we just extract the frames as soon as we have them ready. But for some reason, the sound also runs as fast as possible even though he says that it shouldn't.
I'm using mac os x (Maybe that has something to do with it).
Any suggestions?

Try adding:
aCodecCtx = pFormatCtx->streams[audioStream]->codec;
> aCodecCtx->request_sample_fmt = AV_SAMPLE_FMT_S16;

Related

Using parallel decoder in libavcodec/ffmpeg

The problem
I am writing a simple program in C language which makes use of libavcodec (https://github.com/Dr-Noob/framepos/blob/master/framepos.c)
I have been working with h264 videos. While the decoding works, I can see that it's very slow, since it only uses 1 CPU core (I checked it with top). On the other hand, I know that ffmpeg, which uses the same libavocdec installed in my system, makes use of the parallel h264 decoder. I can test it with:
ffmpeg -c:v h264 -i test.mkv -f null -
With top I can see that it's running in parallel, and the speed is noticeably faster. I would like a solution that always gives me the possibility of decoding the video using all the CPU cores, not only in the case of the h264 codec.
My research so far
Looking at the ffmpeg code, one can see that, to obtain the AVCodec, it uses the function find_codec_or_die. This will end up using avcodec_find_decoder_by_name. Actually, if in my program I use this function, asking for the h264 decoder, I still get the sequential version. Moreover, using gdb in ffmpeg I have seen that the AVCodec in ffmpeg is called ff_h264_decoder, while in my code, gdb does not know which specific type is the codec. The ff suffix makes me think that this one is the parallel decoder (because it looks like ff has something to do with parallel in the ffmpeg context (https://ffmpeg.org/doxygen/2.7/pthread__frame_8c.html)). However, it seems that I am unable to get this codec.
What can I do to decode video in parallel using libavcodec in C?
Posting gkv311 comment as an answer for future reference.
AVCodec does not have multi-threading functionality. It is stored inside AVCodecContex. So, a posible scheme to run the codec in parallel:
AVCodec *codec = avcodec_find_decoder
AVCodecContext *ctx = avcodec_alloc_context3
ctx->thread_count = n_threads;
ctx->thread_type = FF_THREAD_FRAME;
avcodec_open2(ctx, fmt_ctx->video_codec, NULL)

CommandSequence taking too long to download

With both DKPy-SITL and our APM2 board, the wait_ready method is causing our program to raise an API Exception due to the command list (waypoints) taking too long to download. In the past (with droneapi) this wasn't an issue for me. Some waypoints are being downloaded, but the process takes about 10 seconds for each one, which leads me to believe something weird is going on.
Are there any ways to speed up the download process? I've posted the relevant code below.
self.vehicle = connect(connection_string, baud=baud_rate,
status_printer=dronekit_printer, wait_ready=True)
and later in another asynchronous method
def commands(self):
commands = self.vehicle.commands
commands.download()
commands.wait_ready()
return commands
The error occurs on commands.wait_ready(). There has to be a faster way to download commands than sitting there for over 30 seconds on an i7 4790k processor, especially since I've run the same code off a slower computer in the past with droneapi. If need be, I can raise an issue on the dronekit github as well.
I had the same issue. First time download call always goes well (0 commands). Once you have uploaded some commands the second time you try to download it fails ('Timeout' exception).
What I did to solve this was calling clear without download after the first time.
Something like this:
cmds = vehicle.commands
if not cmds.count > 0:
# Download
cmds.download()
# Wait until download is finished
cmds.wait_ready()
cmds.clear()
# Add / Modify the commands here and then upload them

How to recover from infinite reboot loops in NodeMCU?

My NodeMCU program has gone in to infinite reboot loop.
My code is functionally working but any action I try to do, e.g. file.remove("init.lua") or even just =node.heap(), it panics and reboots saying: PANIC: unprotected error in call to Lua API (not enough memory).
Because of this, I'm not able to change any code or delete init.lua to stop automatic code execution.
How do I recover?
I tried re-flashing another version of NodeMCU, but it started emitting garbage in serial port.
Then, I recalled that NodeMCU had two extra files: blank.bin and esp_init_data_default.bin.
I flashed them at 0x7E000 and 0x7C000 respectively.
They are also available as INTERNAL://BLANK and INTERNAL://DEFAULT in the NodeMCU flasher.
This booted the new NodeMCU firmware, all my files were gone and I'm out of infinite reboot loop.
Flash the following files:
0x00000.bin to 0x00000
0x10000.bin to 0x10000
And, the address for esp_init_data_default.bin depends on the size of your module's flash.
0x7c000 for 512 kB, modules like ESP-01, -03, -07 etc.
0xfc000 for 1 MB, modules like ESP8285, PSF-A85
0x1fc000 for 2 MB
0x3fc000 for 4 MB, modules like ESP-12E, NodeMCU devkit 1.0, WeMos D1 mini
Then, after flashing those binaries format its file system (run "file.format()" using ESPlorer) before flashing any other binaries.
Downloads Link
I've just finished working through a similar problem. In my case it was end-user error that caused a need to forcibly wipe init.lua, but I think both problems could be solved similarly. (For completeness, my problem was putting a far-too-short dsleep() call in init.lua, leaving the board resetting itself immediately upon starting init.lua.)
I tried flashing new NodeMCU firmware, writing blank.bin and esp_init_data_default.bin to 0x7E000 and 0x7C000, and also writing 0x00000.bin to 0x00000 and 0x10000.bin to 0x10000. None of these things helped in my case.
My hardware is an Adafruit Huzzah ESP8266 breakout (ESP-12), with 4MB of flash.
What worked for me was:
Download the NONOS SDK from Espressif (I used version 1.5.2 from http://bbs.espressif.com/viewtopic.php?f=46&t=1702).
Unzip it to get at boot_v1.2.bin, user1.1024.new.2.bin, blank.bin, and esp_init_data_default.bin (under bin/ and bin/at/).
Flash the following files to the specified memory locations:
boot_v1.2.bin to 0x00000
user1.1024.new.2.bin to 0x010000
esp_init_data_default.bin to 0xfc000
blank.bin to 0x7e000
Note about flashing:
I used esptool.py 1.2.1.
Because of the nature of my problem, I was only able to write changes to the flash when in programming mode (i.e. after booting with GPIO0 held down to GND).
I found that I needed to reset the board between each step (else invocations of esptool.py after the first would fail).
Erased the flash. esptool.py --port <your/port> erase_flash
Then I was able to write a new firmware. I used a stock nodeMCU 0.9.5 just to isolate variables, but I strongly suspect any firmware would work at this point.
The only think that worked for me was python flash tool esptool in ubuntu, windows flashtool never deleted init.lua and reboot loop.
Commands (ubuntu):
git clone https://github.com/themadinventor/esptool.git
cd esptool
python esptool.py -h
ls -l /dev/tty*
nodemcu_latest.bin can be downloaded from github or anywhere.
sudo python esptool.py -p /dev/ttyUSB0 --baud 460800 write_flash --flash_size=8m 0 nodemcu_latest.bin

c - GTK3.0 GUI freezes when using "g_spawn_async_with_pipes()"

I've written a very simple front end for ffmpeg (converting stuff: video -> mp3) in GTK3.0/C for linux. For spawning ffmpeg I use g_spawn_async_with_pipes(). I thought this was the right way to execute stuff like that without having the GUI freeze up - but it does though. So - how can I prevent it from freezing - so I can f.e. display a spinner?
You might need to add something like"
while (gtk_events_pending ()) {
gtk_main_iteration_do (FALSE);
}
That is, to let GTK process the pending events (like drawing the UI).
I suppose you are processing the output of ffmpeg with g_io_add_watch
or similar.

need AT-Command to copy files from sd-card

i have usb-modem that i can comunicate with it using AT-Command.
i can send and recive sms using it.
we know that we can insert an SD-Card into the usb-modem and use it as a storage device
but i been stuck for days searching how i can work on files on sd card using AT-Command??
please help. thanks in advance
I don't think you can do this. The AT command-set is only for doing "phonestuff". Calling, texting (which in itself is an extension), and such.
The usual reason for usb-modems to have built-in storage is so you can store the drivers there. This would let you use the modem on any computer without needing to connect to the internet to get the drivers.
Are you sure the modem doesn't expose the card as a drive as other USB devices do (e.g cameras, phones, etceteras)? I can't see a way of retrieving files off it using ATxx commands.
Edit, I did a little digging and found this:
https://wiki.archlinux.org/index.php/Huawei_E1550_3G_modem#AT_commands
And I am wondering if any of the following can point you in the right direction:
AT^U2DIAG=0 - the device is only Modem
AT^U2DIAG=1 - device is in modem mode + CD ROM
AT^U2DIAG=255 - the device in modem mode + CD ROM + Card Reader
AT^U2DIAG=256 - the device in modem mode + Card Reader
AT+CPIN=<PIN-CODE> - enter PIN-code
AT+CUSD=1,<PDU-encoded-USSD-code>,15 - USSD request, result can be found (probably) in /dev/ttyUSB2.
So it would appear you can put the device in a card-reader mode using AT^U2DIAG=256. I'd be interested to see if, when you execute this, whether your drive will then be mapped. I can't really find anything to get files off it after you do this.

Resources