Re: [Libav-user] Is a delayed transcoding start for mp2 unavoidable due to format or tuneable?

2018-03-05 Thread Sebastian Guttenberg
I found a workaround now, involving the linux-command 'dd‘ .
Instead of using the original command which has 4 seconds of delay:

ffmpeg  -ss 4:0:0 -i M0495978.MP2 testLocal.mp3
I’m now using the following combination of dd (on Linux, in order to cut a 
portion of a file) and ffmpeg without noticable delay:

dd ibs=1152 skip=60 count=200 if=
M0495978.MP2
 | ffmpeg -i pipe:0 test.mp3

In my example file, my frames have a constant frame size of 1152 bytes with a 
duration of 24ms. So I skip 60 blocks of 24ms which correspond to 4 hours.
This command starts transcoding without any noticable delay!
(See also the discussion around my related question 
http://ffmpeg.org/pipermail/libav-user/2018-March/010973.html)

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


[Libav-user] Is a delayed transcoding start for mp2 unavoidable due to format or tuneable?

2018-02-19 Thread Sebastian Guttenberg
Hello, I’m new to this mailing list, so please let me know, if I’m at the wrong 
place to pose this question. 
As it might lead to modifying the source-code, I was wondering to pose it at 
ffmpeg-devel instead but decided for this mailing-group first …
 
Following problem:
When I transcode a long mp2 (for example one with 04:03:07.22, i.e. more than 4 
hours) 
to mp3 with a transcoding starting point close to the end (-ss 04:00:00) then 
it takes ffmpeg 
(depending on the disk and processor of course) on my machine almost 4 seconds 
to start the transcoding process. 
The server where I actually want to run it, seems to have slower disk and/or 
processor and has delays up to 18 seconds! 
The transcoding itself is fast with around 35x speed. But the delay at the 
beginning is a real problem for streaming.
If the transcoding start is at the beginning (i.e. dropping the '-ss' option), 
then there is no delay and the transcoding starts immediately.
The delays seem to be specific to the mp2-format. For a transcoding from e.g. 
the wma - format to mp3, there is no noticeable delay.
It seems that the decoder is somehow running through the whole file to 
determine the correct timestamp to start the transcoding from. 
So my question is, is there anything one can do about it? I might even be 
willing to try improving the source code on this matter 
(if I understand it and modulo the fact that I’m not very familiar with c), 
or is there no point in trying to improve it, because the delay is due to the 
mp2-format itself? 
(I.e. maybe there are no timecodes stored with the frames, and one has to count 
the packages to determine the timecode, or something like that?)

In the following is my command-line input and the output in debug-loglevel. The 
delay happens right after the lines:
"[mp3 @ 0x7fe2fc001400] Estimating duration from bitrate, this may be inaccurate
[mp3 @ 0x7fe2fc001400] After avformat_find_stream_info() pos: 58368 bytes 
read:98432 seeks:2 frames:50  "
and before the lines
"Input #0, mp3, from 'M0495978.MP2':
  Duration: 04:03:07.22, start: 0.00, bitrate: 384 kb/s
Stream #0:0, 50, 1/14112000: Audio: mp2, 48000 Hz, stereo, s16p, 384 kb/s
Successfully opened the file. „

The complete input/output:
ffmpeg  -ss 4:0:0 -i M0495978.MP2 -loglevel debug testLocal.mp3

ffmpeg version 3.0.2 Copyright (c) 2000-2016 the FFmpeg developers
  built with llvm-gcc 4.2.1 (LLVM build 2336.11.00)
  configuration: --prefix=/Volumes/Ramdisk/sw --enable-gpl --enable-pthreads 
--enable-version3 --enable-libspeex --enable-libvpx --disable-decoder=libvpx 
--enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264 
--enable-avfilter --enable-libopencore_amrwb --enable-libopencore_amrnb 
--enable-filters --enable-libgsm --enable-libvidstab --enable-libx265 
--disable-doc --arch=x86_64 --enable-runtime-cpudetect
  libavutil  55. 17.103 / 55. 17.103
  libavcodec 57. 24.102 / 57. 24.102
  libavformat57. 25.100 / 57. 25.100
  libavdevice57.  0.101 / 57.  0.101
  libavfilter 6. 31.100 /  6. 31.100
  libswscale  4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc54.  0.100 / 54.  0.100
Splitting the commandline.
Reading option '-ss' ... matched as option 'ss' (set the start time offset) 
with argument '4:0:0'.
Reading option '-i' ... matched as input file with argument 'M0495978.MP2'.
Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) 
with argument 'debug'.
Reading option 'testLocal.mp3' ... matched as output file.
Finished splitting the commandline.
Parsing a group of options: global .
Applying option loglevel (set logging level) with argument debug.
Successfully parsed a group of options.
Parsing a group of options: input file M0495978.MP2.
Applying option ss (set the start time offset) with argument 4:0:0.
Successfully parsed a group of options.
Opening an input file: M0495978.MP2.
[file @ 0x7fdfb57067a0] Setting default whitelist 'file,crypto'
[mp3 @ 0x7fdfb6000a00] Format mp3 probed with size=8192 and score=51
[mp3 @ 0x7fdfb6000a00] Skipping 0 bytes of junk at 0.
[mp3 @ 0x7fdfb6000a00] Before avformat_find_stream_info() pos: 0 bytes 
read:65664 seeks:2
[mp3 @ 0x7fdfb6000a00] All info found
[mp3 @ 0x7fdfb6000a00] Estimating duration from bitrate, this may be inaccurate
[mp3 @ 0x7fdfb6000a00] After avformat_find_stream_info() pos: 58368 bytes 
read:98432 seeks:2 frames:50

Input #0, mp3, from 'M0495978.MP2':
  Duration: 04:03:07.22, start: 0.00, bitrate: 384 kb/s
Stream #0:0, 50, 1/14112000: Audio: mp2, 48000 Hz, stereo, s16p, 384 kb/s
Successfully opened the file.
Parsing a group of options: output file testLocal.mp3.
Successfully parsed a group of options.
Opening an output file: testLocal.mp3.
[file @ 0x7fdfb5707740] Setting default whitelist 'file,crypto'
Successfully opened the file.
detected 8 logical cores
[graph 0 input from stream 0:0 @ 0x7fdfb5500460] Setting 'time_base' to value 
'1/48000'
[graph 0 input from s