Re: [FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
Hello, Am 28.12.18 um 01:59 schrieb Nicolas George: Uwe Freese (2018-12-27): Good. But then I totally don't understand why that 64:45 is not used and stored at mkv container level as well. Since you have not provided the full information necessary to explain, nobody will be able to. I think the answer from Carl Eugen (about MKV doesn't store SAR) covers it already. But what info didn't I give? I was asked for the command line and a complete console output, which I sent (26.12. 15:13), and am not aware of some other missing info, sorry. 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)?
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] Question about handling / unwanted changes of SAR in ffmpeg
Hello, Instead, the better solution would then be to give the SAR to whatever calculates the SAR to store at container level not as a double or int, but as a "AVRational", which contains the "num" and "den" values (in this case 64 and 45)? This is exactly what FFmpeg does (since forever). Good. But then I totally don't understand why that 64:45 is not used and stored at mkv container level as well. 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".
[FFmpeg-user] Robustness on processing transport streams (TS)?
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 [h26
Re: [FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
Am 26.12.18 um 15:08 schrieb Reino Wijnsma: Stream #0:0: Video: h264 (High), yuv420p(progressive), 688x560 [SAR 64:45 DAR 2752:1575], SAR 172:121 DAR 7396:4235, 50 fps, 50 tbr, 1k tbn, 100 tbc (default) What does SAR (and DAR) mean in the brackets compared to the second SAR 172:121, which is slightly different? As far as I know: 688x 64/45 = 978,49w 978,49 x 1575/2752 = 560h --> 978x560 @ bitstream level 688x 172/121 = 977,98w 977,98 x 4235/7396 = 560h --> 977x560 @ container level So when I understand correctly, it could be that somewhere in ffmpeg, the 64/45 is rounded to 978, given to another function / class calculating the SAR for the container level, and this calculates to 172/121, which is best matching for 978? Instead, the better solution would then be to give the SAR to whatever calculates the SAR to store at container level not as a double or int, but as a "AVRational", which contains the "num" and "den" values (in this case 64 and 45)? Could this be done, or is there a reason not to do that? 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] Question about handling / unwanted changes of SAR in ffmpeg
.4: 16.9% 75.5% 7.6% [libx264 @ 0x55bf2ce415c0] mb P I16..4: 3.9% 10.9% 0.8% P16..4: 37.1% 9.6% 5.0% 0.0% 0.0% skip:32.7% [libx264 @ 0x55bf2ce415c0] mb B I16..4: 0.3% 0.6% 0.0% B16..8: 24.1% 2.0% 0.3% direct: 4.3% skip:68.3% L0:40.1% L1:50.3% BI: 9.6% [libx264 @ 0x55bf2ce415c0] 8x8 transform intra:70.3% inter:86.6% [libx264 @ 0x55bf2ce415c0] coded y,uvDC,uvAC intra: 43.7% 69.7% 24.5% inter: 7.3% 19.5% 1.1% [libx264 @ 0x55bf2ce415c0] i16 v,h,dc,p: 51% 19% 8% 23% [libx264 @ 0x55bf2ce415c0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 37% 14% 26% 3% 3% 5% 3% 6% 3% [libx264 @ 0x55bf2ce415c0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 42% 16% 12% 4% 5% 7% 4% 6% 3% [libx264 @ 0x55bf2ce415c0] i8c dc,h,v,p: 39% 17% 36% 8% [libx264 @ 0x55bf2ce415c0] Weighted P-Frames: Y:0.7% UV:0.7% [libx264 @ 0x55bf2ce415c0] ref P L0: 63.2% 10.5% 16.7% 9.5% 0.1% [libx264 @ 0x55bf2ce415c0] ref B L0: 87.8% 9.4% 2.7% [libx264 @ 0x55bf2ce415c0] ref B L1: 97.8% 2.2% [libx264 @ 0x55bf2ce415c0] kb/s:708.14 Regards, Uwe Am 26.12.18 um 12:44 schrieb Carl Eugen Hoyos: Am 26.12.2018 um 12:23 schrieb Uwe Freese : Am 26.12.18 um 02:00 schrieb Carl Eugen Hoyos: I'm confused about how ffmpeg handles the SAR (sample aspect ratio) and changes it. Maybe someone can explain why this happens: I've a video from TV with original size 720x576 pixels (PAL), which shall be shown as 16:9 aspect ratio. The SAR of the input video is correctly shown as 64:45 (resulting in 720*64 / 576*45 = 46080 / 25920 = 16 / 9 display aspect ratio). When I crop black borders SAR is expected to change if you crop. Rounding can be different for different codecs and containers. Why? The DAR, yes. But the SAR should stay the same. And it does regarding the first output from ffmpeg in the brackets. Yes. Please provide the command line you tested together with the complete, uncut console output. If your question was „why are there two SARs/DARs?“, the answer is that container and codec may contain different information: Although it is common to trust the container, this is just an arbitrary decision. 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 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] Question about handling / unwanted changes of SAR in ffmpeg
Hello, Am 26.12.18 um 02:00 schrieb Carl Eugen Hoyos: I'm confused about how ffmpeg handles the SAR (sample aspect ratio) and changes it. Maybe someone can explain why this happens: I've a video from TV with original size 720x576 pixels (PAL), which shall be shown as 16:9 aspect ratio. The SAR of the input video is correctly shown as 64:45 (resulting in 720*64 / 576*45 = 46080 / 25920 = 16 / 9 display aspect ratio). When I crop black borders SAR is expected to change if you crop. Rounding can be different for different codecs and containers. Why? The DAR, yes. But the SAR should stay the same. And it does regarding the first output from ffmpeg in the brackets. My questions remain: What does SAR (and DAR) mean in the brackets compared to the second SAR 172:121, which is slightly different? Stream #0:0: Video: h264 (High), yuv420p(progressive), 688x560 [SAR 64:45 DAR 2752:1575], SAR 172:121 DAR 7396:4235, 50 fps, 50 tbr, 1k tbn, 100 tbc (default) Why isn't the second one also telling the same SAR 64:45 (which would be the correct one)? I don't see how 64:45 is rounded to 172:121. :) 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".
[FFmpeg-user] Question about handling / unwanted changes of SAR in ffmpeg
Hello, I'm confused about how ffmpeg handles the SAR (sample aspect ratio) and changes it. Maybe someone can explain why this happens: I've a video from TV with original size 720x576 pixels (PAL), which shall be shown as 16:9 aspect ratio. The SAR of the input video is correctly shown as 64:45 (resulting in 720*64 / 576*45 = 46080 / 25920 = 16 / 9 display aspect ratio). When I crop black borders and encode this video using x264 codec and mkv format, ffprobe shows about the result: Stream #0:0: Video: h264 (High), yuv420p(progressive), 688x560 [SAR 64:45 DAR 2752:1575], SAR 172:121 DAR 7396:4235, 50 fps, 50 tbr, 1k tbn, 100 tbc (default) What does SAR (and DAR) mean in the brackets compared to the second SAR 172:121, which is slightly different? Why isn't the second one also telling the same SAR 64:45 (which would be the correct one)? It gets stranger when I convert the video a second time using "ffmpeg -i video_encode_x264.mkv test.mkv". ffmpeg seems to use the second (wrong) SAR and shows: Output: Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), yuv420p, 688x560 [SAR 172:121 DAR 7396:4235], q=-1--1, 50 fps, 1k tbn, 50 tbc (default) Why is ffmpeg now using the second (wrong) SAR? 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".
