Re: [FFmpeg-user] Robustness on processing transport streams (TS)?

2018-12-27 Thread Moritz Barsnick
On Thu, Dec 27, 2018 at 22:21:26 +0100, Uwe Freese wrote:
> -async   A... simplified 1 parameter audio 
> timestamp matching, 0(disabled), 1(filling and trimming), >1(maximum 
> stretch/squeeze in samples per second) (from INT_MIN to INT_MAX) (default 0)

That's the swresample option, not the ffmpeg option. "swr simple 1
parameter async, similar to ffmpegs -async"

> Why does it say "float" and at the end "from INT_MIN to INT_MAX"? It's 
> also defined like that in the code in libswresample/options.c, also for 
> other parameters.

*shrug*

ffmpeg's "-async" option is defined differently.

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".

Re: [FFmpeg-user] Robustness on processing transport streams (TS)?

2018-12-27 Thread Carl Eugen Hoyos
2018-12-27 22:21 GMT+01:00, Uwe Freese :

>> A long time back, there was ProjectX to fix transport streams, I
>> believe there is another program now (suggested by the HandBrake
>> user support) but I forgot its name.
>
> ProjectX doesn't work with HD.

HD should have no issues, h264 support is very limited iirc.

> Under Win, I used "TSDoctor", but I'm now working on
> Linux only and didn't find anything appropriate.

That's probably what I read about.

> But it seems ffmpeg is then enough for this purpose (I'm not expecting
> "very damaged" recordings).
>
>> To "insert silence", FFmpeg needs the "-async 1" option or the
>> corresponding filter chain.
>
> Very good hint, thanks!
>
> Just a small point I'm curious about. Help says:
>
> -async   A... simplified 1 parameter audio
> timestamp matching, 0(disabled), 1(filling and trimming), >1(maximum
> stretch/squeeze in samples per second) (from INT_MIN to INT_MAX) (default 0)
>
> Why does it say "float" and at the end "from INT_MIN to INT_MAX"? It's
> also defined like that in the code in libswresample/options.c, also for
> other parameters.
>
> {"async", "simplified 1 parameter audio timestamp
> matching, 0(disabled), 1(filling and trimming), >1(maximum
> stretch/squeeze in samples per second)"
>  ,
> OFFSET(async)  , AV_OPT_TYPE_FLOAT ,{.dbl=0
> }, INT_MIN, INT_MAX   , PARAM },
>
> A bug, or how does it make sense to use INT border values with a float?

I don't know but I believe this values are already too large for real
use cases.

Carl Eugen
___
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] Robustness on processing transport streams (TS)?

2018-12-27 Thread Uwe Freese

Hello,

If you have an input file that crashes FFmpeg, please share it!

It was only crashing Avidemux when seeking to the end. - "Sorry". ;-)

A long time back, there was ProjectX to fix transport streams, I
believe there is another program now (suggested by the HandBrake
user support) but I forgot its name.


ProjectX doesn't work with HD. Under Win, I used "TSDoctor", but I'm 
now working on Linux only and didn't find anything appropriate.


But it seems ffmpeg is then enough for this purpose (I'm not expecting 
"very damaged" recordings).



To "insert silence", FFmpeg needs the "-async 1" option or the
corresponding filter chain.


Very good hint, thanks!

Just a small point I'm curious about. Help says:

-async   A... simplified 1 parameter audio 
timestamp matching, 0(disabled), 1(filling and trimming), >1(maximum 
stretch/squeeze in samples per second) (from INT_MIN to INT_MAX) (default 0)


Why does it say "float" and at the end "from INT_MIN to INT_MAX"? It's 
also defined like that in the code in libswresample/options.c, also for 
other parameters.


{"async"    , "simplified 1 parameter audio timestamp 
matching, 0(disabled), 1(filling and trimming), >1(maximum 
stretch/squeeze in samples per second)"
    , 
OFFSET(async)  , AV_OPT_TYPE_FLOAT ,{.dbl=0 
}, INT_MIN, INT_MAX   , PARAM },


A bug, or how does it make sense to use INT border values with a float?

Regards,
Uwe

___
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] Robustness on processing transport streams (TS)?

2018-12-27 Thread Carl Eugen Hoyos
2018-12-27 15:14 GMT+01:00, Uwe Freese :

> how robust and precise especially regarding a/v sync is ffmpeg when
> processing transport streams (*.ts) files from TV recordings?

I have seen many samples that can be transcoded in-sync with FFmpeg.

> Some programs (e.g. Avidemux on Linux) have problems (crash)

If you have an input file that crashes FFmpeg, please share it!

> with some *.ts files I have, and I thought it maybe is a good idea
> to first convert my input to a "raw" file with:
>
> ffmpeg -i input.ts -map 0:v:0 -c:v huffyuv -map 0:a -c:a pcm_s16le
> -sn temp.mkv

I would assume that this makes possible problems with A/V sync
immutable. Always use the original input file for transcoding.

A long time back, there was ProjectX to fix transport streams, I
believe there is another program now (suggested by the HandBrake
user support) but I forgot its name.

To "insert silence", FFmpeg needs the "-async 1" option or the
corresponding filter chain.

Carl Eugen
___
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] Robustness on processing transport streams (TS)?

2018-12-27 Thread Uwe Freese

Hello,

how robust and precise especially regarding a/v sync is ffmpeg when 
processing transport streams (*.ts) files from TV recordings?


Some programs (e.g. Avidemux on Linux) have problems (crash) with some 
*.ts files I have, and I thought it maybe is a good idea to first 
convert my input to a "raw" file with:


ffmpeg -i input.ts -map 0:v:0 -c:v huffyuv -map 0:a -c:a pcm_s16le -sn 
temp.mkv


and use that hopefully "corrected" version for further processing (and 
encoding).



Question is, does ffmpeg a good job detecting gaps and errors and fill 
out the produces audio streams with silence etc, so they stay in sync?


I mean, when I play whatever corrupt file in VLC, it does a good job in 
this. How is it in ffmpeg?


Any other program that someone suggests to (pre)process and "correct" 
such ts files under Linux?



Some example output I had for a TV recording (which is not from a bad 
reception or so - it's totally ok when playing it back):


$ ffmpeg -i input.ts -map 0:v:0 -c:v huffyuv -map 0:a -c:a pcm_s16le -sn 
temp.mkv

ffmpeg version 3.2.12-1~deb9u1 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 6.3.0 (Debian 6.3.0-18+deb9u1) 20170516
  configuration: --prefix=/usr --extra-version='1~deb9u1' 
--toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu 
--incdir=/usr/include/x86_64-linux-gnu --enable-gpl --disable-stripping 
--enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa 
--enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca 
--enable-libcdio --enable-libebur128 --enable-libflite 
--enable-libfontconfig --enable-libfreetype --enable-libfribidi 
--enable-libgme --enable-libgsm --enable-libmp3lame --enable-libopenjpeg 
--enable-libopenmpt --enable-libopus --enable-libpulse 
--enable-librubberband --enable-libshine --enable-libsnappy 
--enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora 
--enable-libtwolame --enable-libvorbis --enable-libvpx 
--enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid 
--enable-libzmq --enable-libzvbi --enable-omx --enable-openal 
--enable-opengl --enable-sdl2 --enable-libdc1394 --enable-libiec61883 
--enable-chromaprint --enable-frei0r --enable-libopencv --enable-libx264 
--enable-shared

  libavutil  55. 34.101 / 55. 34.101
  libavcodec 57. 64.101 / 57. 64.101
  libavformat    57. 56.101 / 57. 56.101
  libavdevice    57.  1.100 / 57.  1.100
  libavfilter 6. 65.100 /  6. 65.100
  libavresample   3.  1.  0 /  3.  1.  0
  libswscale  4.  2.100 /  4.  2.100
  libswresample   2.  3.100 /  2.  3.100
  libpostproc    54.  1.100 / 54.  1.100
[h264 @ 0x558e3216ee00] SPS unavailable in decode_picture_timing
[h264 @ 0x558e3216ee00] non-existing PPS 0 referenced
[h264 @ 0x558e3216ee00] SPS unavailable in decode_picture_timing
[h264 @ 0x558e3216ee00] non-existing PPS 0 referenced
[h264 @ 0x558e3216ee00] decode_slice_header error
[h264 @ 0x558e3216ee00] no frame!
[h264 @ 0x558e3216ee00] SPS unavailable in decode_picture_timing
[h264 @ 0x558e3216ee00] non-existing PPS 0 referenced
[h264 @ 0x558e3216ee00] SPS unavailable in decode_picture_timing
[h264 @ 0x558e3216ee00] non-existing PPS 0 referenced
[h264 @ 0x558e3216ee00] decode_slice_header error
[h264 @ 0x558e3216ee00] no frame!
[h264 @ 0x558e3216ee00] SPS unavailable in decode_picture_timing
[h264 @ 0x558e3216ee00] non-existing PPS 0 referenced
[h264 @ 0x558e3216ee00] SPS unavailable in decode_picture_timing
[h264 @ 0x558e3216ee00] non-existing PPS 0 referenced
[h264 @ 0x558e3216ee00] decode_slice_header error
[h264 @ 0x558e3216ee00] no frame!
[h264 @ 0x558e3216ee00] SPS unavailable in decode_picture_timing
[h264 @ 0x558e3216ee00] non-existing PPS 0 referenced
[h264 @ 0x558e3216ee00] SPS unavailable in decode_picture_timing
[h264 @ 0x558e3216ee00] non-existing PPS 0 referenced
[h264 @ 0x558e3216ee00] decode_slice_header error
[h264 @ 0x558e3216ee00] no frame!
[h264 @ 0x558e3216ee00] SPS unavailable in decode_picture_timing
[h264 @ 0x558e3216ee00] non-existing PPS 0 referenced
[h264 @ 0x558e3216ee00] SPS unavailable in decode_picture_timing
[h264 @ 0x558e3216ee00] non-existing PPS 0 referenced
[h264 @ 0x558e3216ee00] decode_slice_header error
[h264 @ 0x558e3216ee00] no frame!
[h264 @ 0x558e3216ee00] SPS unavailable in decode_picture_timing
[h264 @ 0x558e3216ee00] non-existing PPS 0 referenced
[h264 @ 0x558e3216ee00] SPS unavailable in decode_picture_timing
[h264 @ 0x558e3216ee00] non-existing PPS 0 referenced
[h264 @ 0x558e3216ee00] decode_slice_header error
[h264 @ 0x558e3216ee00] no frame!
[h264 @ 0x558e3216ee00] SPS unavailable in decode_picture_timing
[h264 @ 0x558e3216ee00] non-existing PPS 0 referenced
[h264 @ 0x558e3216ee00] SPS unavailable in decode_picture_timing
[h264 @ 0x558e3216ee00] non-existing PPS 0 referenced
[h264 @ 0x558e3216ee00] decode_slice_header error
[h264 @ 0x558e3216ee00] no frame!
[h264 @ 0x558e3216ee00] SPS unavailable in decode_picture_timing
[h264 @ 0x558e3216ee00] non-existing PPS 0 referenced