Re: [FFmpeg-user] mp4 concatenation (muxer) problems -- invalid output?

[Erik Dobberkau]

Hi John,

just to make sure I get this right, are you trying to build an advanced
version of Vantage Camera Ingest? Have fun then... ;-)

Let's go trough this step by step to find out if your approach makes sense:

Obviously you're trying to concat recordings from a DSLR.
-> Why are there gaps in between? They shouldn't be there, if the camera is
continuously on record.

When done with the video, you want to replace the audio (of the lng
video file) with a continuous mp3 audio track that is in sync all of the
time?

Well...

You can only concat files with matching parameters (and different moov
atoms if they're not raw files, like transport streams) if you want to get
a decent result, which means you have to do the following:
- Get the exact timecode difference between each of the adjacent files ( ->
exiftool is your friend, use ffprobe and exiftool in a nice script to do
the math... )
- Based on that difference, create matching splice files from the first
frame of the "next" clip for each gap with matching video and audio
parameters to the source clips (-> use anullsrc to add blank audio to an
image). Your mileage will vary here because DSLR cameras use evil magic to
record video... your ffmeg cmd line will (need to) be much longer than it
is now.
- Concat everything
- Replace the audio (though I recommend transcoding the mp3 to aac before
and make sure it matches. And even if it does, I bet it won't be lip-sync
all the time, but it depends how perfect you need the result to be).

I don't think it's likely to get a single-line solution for your task.

Regards,
Erik
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] mp4 concatenation (muxer) problems -- invalid output?

[John A Hawkinson]

Hi:

I filed a bug yesterday and Cigaes suggested my problem wasn't
really a bug and I should seek out help here, so I'm doing so. (Would it
be better for me to try to do this in html email with some markup instead
of plain text? Sorry there's so much ffmpeg/ffprobe output involved.)
See https://trac.ffmpeg.org/ticket/6163 and especially "short1.mp4" at 
https://trac.ffmpeg.org/attachment/ticket/6162/short1.mp4

My ultimate goal is to take a series of MP4 video files that are
recorded nearly consecutive with a few seconds of gap in between, and
stitch them together with freeze-frames, and replace their audio with
separately-recorded mp3 audio, all ideally without having to do major
transcoding or being stuck with expensive realtime rendering steps.  The
target of this workflow is typically Youtube. (My workflow for this
tends to involve lining up the clips in Premiere Pro, exporting an EDL,
and then producing ffmpeg commandlines from the EDL.)  I've done this
successfully in the past, although this time I am running into problems.



I cut down my original 24-minute MP4 video to a 1-second version
for test replication purposes with "ffmpeg -t 1 -i ../MVI_6105.mp4 -c
copy short1.mp4" (See
https://trac.ffmpeg.org/ticket/6162?replyto=6#comment:1
for the ffmpeg output).

Then I extracted a PNG still with "ffmpeg -i short1.mp4 -frames:v 1
-f image2 f1.png"; so far so good.

My intention is to then produce a freeze-frame MP4 from that still
and concatenate it with the original video, and that's where I start to
run into problems. Cigaes suggested that having audio in in "short1.mp4"
but not in the video from the freeze-frame meant I was not obeying the 
concat demuxer requirement of "All files must have the same streams
(same codecs, same time base, etc.)." requirement. In the past I thought
I had done this successfully, but to avoid those issues while
investigating the bug, I re-extracted the 1-second video with "-an" to
remove audio:

pb3:test jhawk$ ffmpeg -t 1 -i ../MVI_6105.mp4 -c copy -an short1s.mp4
ffmpeg version git-2017-02-19-3206ea4 Copyright (c) 2000-2017 the FFmpeg
developers
  built with Apple LLVM version 7.0.2 (clang-700.1.81)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/HEAD-3206ea4
  --enable-shared --enable-pthreads --enable-gpl --enable-version3
  --enable-hardcoded-tables --enable-avresample --cc=clang
  --host-cflags= --host-ldflags= --enable-libmp3lame --enable-libx264
  --enable-libxvid --enable-opencl --disable-lzma --enable-vda
  libavutil  55. 47.100 / 55. 47.100
  libavcodec 57. 80.101 / 57. 80.101
  libavformat57. 66.102 / 57. 66.102
  libavdevice57.  2.100 / 57.  2.100
  libavfilter 6. 73.100 /  6. 73.100
  libavresample   3.  2.  0 /  3.  2.  0
  libswscale  4.  3.101 /  4.  3.101
  libswresample   2.  4.100 /  2.  4.100
  libpostproc54.  2.100 / 54.  2.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '../MVI_6105.mp4':
  Metadata:
major_brand : mp42
minor_version   : 1
compatible_brands: mp42avc1CAEP
copyright   : 
copyright-eng   : 
creation_time   : 2017-02-14T22:11:24.00Z
  Duration: 00:24:26.57, start: 0.00, bitrate: 7509 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661),
yuv420p(tv, bt709), 1280x720, 7372 kb/s, 29.97 fps, 29.97 tbr, 30k
tbn, 60k tbc (default)
Metadata:
  creation_time   : 2017-02-14T22:11:24.00Z
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz,
stereo, fltp, 127 kb/s (default)
Metadata:
  creation_time   : 2017-02-14T22:11:24.00Z
Output #0, mp4, to 'short1s.mp4':
  Metadata:
major_brand : mp42
minor_version   : 1
compatible_brands: mp42avc1CAEP
copyright   : 
copyright-eng   : 
encoder : Lavf57.66.102
Stream #0:0(eng): Video: h264 (High) ([33][0][0][0] / 0x0021),
yuv420p(tv, bt709), 1280x720, q=2-31, 7372 kb/s, 29.97 fps, 29.97
tbr, 30k tbn, 30k tbc (default)
Metadata:
  creation_time   : 2017-02-14T22:11:24.00Z
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
frame=   33 fps=0.0 q=-1.0 Lsize=1153kB time=00:00:00.96
bitrate=9764.4kbits/s speed= 310x
video:1152kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB
muxing overhead: 0.100941%

--

Here's the ffprobe output:

pb3:test jhawk$ ffprobe short1s.mp4
ffprobe version git-2017-02-19-3206ea4 Copyright (c) 2007-2017 the
FFmpeg developers
  built with Apple LLVM version 7.0.2 (clang-700.1.81)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/HEAD-3206ea4
  --enable-shared --enable-pthreads --enable-gpl --enable-version3
  --enable-hardcoded-tables --enable-avresample --cc=clang
  --host-cflags= --host-ldflags= --enable-libmp3lame --enable-libx264
  --enable-libxvid --enable-opencl --disable-lzma --enable-vda
  libavutil  55. 47.100 / 55. 47.100
  libavcodec 57. 80.101 / 57. 80.101
  libavformat57. 

Re: [FFmpeg-user] ffmpeg concat issue

[Cley Faye]

2017-02-17 23:49 GMT+01:00 Mark Hatch :

>
> Any thoughts?


​Hi,​

​You should​ probably send to the list the command *with* the complete
console output when it fails, in addition to what you expect to happen.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Bug in FFMPEG Alsa?

[christina zou]

Hi Nicolas,

> I suspect the difference might be related to the period time. FFmpeg
uses the lowest possible period time to allow low-latency uses, but it
makes for heavier CPU consumption.

I actually ran a test where I ran Arecord using FFMPEG's period_size and
buffer_size settings. Even when those settings are identical, FFMPEG still
takes 95% CPU and Arecord takes 5%.

You can see the full console results of this test in my FFMPEG bug file, if
you scroll to the 2 console output logs: https://trac.ffmpeg.org/ticket/6156

> For your next tests, I urge you to make sure no audio conversions
happens. You can do that with -c copy.

I also ran tests where I did 0 audio conversion in FFMPEG. Simply -c copy.
Incredibly, this still uses 95% CPU!

Command:

ffmpeg -loglevel debug -f alsa -acodec pcm_s32le -i mic_sv -c copy -f null -

Full console output: http://vpaste.net/N1U5b

Thanks,

C
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Bug in FFMPEG Alsa?

[Nicolas George]

Le nonidi 29 pluviôse, an CCXXV, christina zou a écrit :
> Here is the result of your two commands:

> 1. time ffmpeg -i temp_arecord.wav temp_ffmpeg.wav
> real 0m3.154s
> user 0m1.230s

> 2. time ffmpeg -i temp_arecord.wav -c copy temp_ffmpeg2.wav
> real 0m0.986s
> user 0m0.510s

(for a 27-seconds input)

Well, the issue is obviously not what I suspected, i.e. that the 32->16
bits conversion was too slow for the CPU, since it apparently takes less
than 12% of real-time.

I suspect the difference might be related to the period time. FFmpeg
uses the lowest possible period time to allow low-latency uses, but it
makes for heavier CPU consumption.

FFmpeg does not have an option to change the period time, but if you can
patch and build it yourself, you can hardcode something in
libavdevice/alsa.c near line 254.

You can also try lowering the period size in arecord and see if it
increases CPU consumption. But since arecord's work is simpler than
ffmpeg's, it may probably not be enough to observe similar results.
Still, it would be interesting.

For your next tests, I urge you to make sure no audio conversions
happens. You can do that with -c copy.

It would also be interesting to see the definition of the mic_sv PCM in
the ALSA configuration. It might be a little hard to find it in the
spaghetti configuration files.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Bug in FFMPEG Alsa?

[christina zou]

Nicolas,

You're right and I understand your point. Apologies that I have top-posted
several times. I'll make sure to avoid it from now on.

This community is my last hope, as I've been stuck on this issue for over a
month. If I've been hasty about formatting in my frustration, it's my
fault. I appreciate anyone taking the time to read these messages.

Thanks,
Christina
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Bug in FFMPEG Alsa?

[Nicolas George]

Le nonidi 29 pluviôse, an CCXXV, Phil Rhodes a écrit :
> Don't worry about it - it isn't very important, and Carl has no formal
> authority to tell you what to do.

Replying to the troll, for once.

Carl Eugen has no formal authority on anybody on the list. But he, like
anybody else, has the authority of withholding his help.

Since he is one of the most helpful persons on this list, especially
since he is the one who endeavours to help even the hopelessly clueless
that nobody else gives a damn about, alienating him is really not a good
idea.

I myself make extensive use of that right of not helping obnoxious
people.

The first someone top-posts, I tell them "Please remember that
top-posting is forbidden on this list; if you do not know what it means,
look it up.". If there is a second time, I just stop replying to them,
exactly as in this thread.

Well, I am not a monster, if they forget once or twice later and
apologize, they deserve a second chance. But if they just ignore the
demand, too bad for them.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Bug in FFMPEG Alsa?

[christina zou]

Hi,

You're right. The 3Mbps speed is as expected.

However, this still doesn't explain why my FFmpeg command requires 95% of
my device's CPU to record raw audio audio, when the equivalent Arecord
command takes 5% of my CPU.

Again, here are my two commands:

arecord -v -r48000 -c2 -fS32_LE --period-size=16384
--buffer-size=65536 -Dmic_sv -twav /dev/null

ffmpeg -f alsa -acodec pcm_s32le -i mic_sv -c copy -f null -





On Sat, Feb 18, 2017 at 12:38 PM, Moritz Barsnick  wrote:

> On Fri, Feb 17, 2017 at 20:56:25 -0800, christina zou wrote:
> > 2. My ALSA bitrate is shown as 3072 kbps. This seems high - I only have a
> > Pi Zero. Is this a value I can manually set?
>
> Why is that high and why should a Pi not be able to handle a standard
> audio stream? 32 bits per sample, 48000 samples per second, two
> channels, that makes exactly 3072000 bits per second. There's nothing
> that can (or should) be done about that, that's how uncompressed audio
> works.
>
> If you can get your ALSA device to output less bts per sample, or less
> samples per second, you can reduce that rate, but I still don't
> understand why.
>
> Moritz
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".