Re: [FFmpeg-user] Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scaler_0'

2018-02-14 Thread Garri Djavadyan

On 2018-02-13 23:56, James Girotti wrote:

Recently, I faced transcoding issues with fully hardware nvdec/nvenc
scheme. Particularly, my FFmpeg feed fails with the following error 
after

30-60 minutes of live transcoding:


I have recently encountered this as well, but with DVD video material.



As I understand, some parameters change after 30-60 minutes in video
stream and FFmpeg tries to use software scaler in fully hardware 
scheme.
But I can't figure out exact reasons to act against the problem. I 
will be

very grateful if someone could direct me. I use following cmd line:

---
/usr/local/ffmpeg/bin/ffmpeg -analyzeduration 100M -probesize 100M
-loglevel debug -hwaccel_device 1 -hwaccel cuvid -c:v h264_cuvid 
-deint 2

-drop_second_field 1 -i udp://224.4.4.13:1013?fifo_siz
e=25_nonfatal=1 -map p:1011:0 -map p:1011:1 -c:v 
h264_nvenc

-profile:v high -level 4.1 -b:v 2048k -c:a libfdk_aac -b:a 128k -af
aresample=async=1000 -f mpegts http://192.168.0.10/15/mpegts



The solution I used was to drop the all the "hwaccel" parameters, still
using hw-decoding and encoding. This does impact performance, but it
ensures that if the stream contains material of a different pixel 
format

that the sws can correct it and transcoding will continue.


James, thank you very much for the advise. I've solved the issue using 
partially hardware transcoding (h264_cuvid -> system memory -> 
h264_nvenc), so the cmd line now is:


---
/usr/local/ffmpeg/bin/ffmpeg -analyzeduration 100M -probesize 100M 
-loglevel debug -c:v h264_cuvid -deint 2 -drop_second_field 1 -gpu 1 -i 
udp://224.4.4.13:1013?fifo_size=25_nonfatal=1 -map p:1011:0 
-map p:1011:1 -c:v h264_nvenc -gpu 1 -profile:v high -level 4.1 -b:v 
2048k -c:a libfdk_aac -b:a 128k -af aresample=async=1000 -f mpegts 
http://192.168.0.10/15/mpegts

---



I'm not sure if this is a regression in ffmpeg/nvidia or just bad video
material. I hadn't ever run into this until about a month ago. And it's
happened on several videos from different DVD's. I didn't dig into it, 
I
just dropped the hwaccel parameters and moved on with my life. I wonder 
if

it's actually a problem in the hw-decoder, but I didn't see any error
messages to prove that.



After migration to partially hardware transcoding, I don't see any calls 
for sws in debug log any more, but the following periodical messages 
from h264_cuvid:


[h264_cuvid @ 0x5616844a6c00] Format nv12 chosen by get_format().
[h264_cuvid @ 0x5616844a6c00] Formats: Original: nv12 | HW: nv12 | SW: 
nv12



I noticed that aspect ratio of TV programs changes over the time 
(visually) on the problem stream, but the actual SAR/DAR never changes 
(inspected by ffprobe periodically).



Garri
___
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] Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scaler_0'

2018-02-13 Thread James Girotti
>
> Recently, I faced transcoding issues with fully hardware nvdec/nvenc
> scheme. Particularly, my FFmpeg feed fails with the following error after
> 30-60 minutes of live transcoding:
>

I have recently encountered this as well, but with DVD video material.


> As I understand, some parameters change after 30-60 minutes in video
> stream and FFmpeg tries to use software scaler in fully hardware scheme.
> But I can't figure out exact reasons to act against the problem. I will be
> very grateful if someone could direct me. I use following cmd line:
>
> ---
> /usr/local/ffmpeg/bin/ffmpeg -analyzeduration 100M -probesize 100M
> -loglevel debug -hwaccel_device 1 -hwaccel cuvid -c:v h264_cuvid -deint 2
> -drop_second_field 1 -i udp://224.4.4.13:1013?fifo_siz
> e=25_nonfatal=1 -map p:1011:0 -map p:1011:1 -c:v h264_nvenc
> -profile:v high -level 4.1 -b:v 2048k -c:a libfdk_aac -b:a 128k -af
> aresample=async=1000 -f mpegts http://192.168.0.10/15/mpegts


The solution I used was to drop the all the "hwaccel" parameters, still
using hw-decoding and encoding. This does impact performance, but it
ensures that if the stream contains material of a different pixel format
that the sws can correct it and transcoding will continue.

I'm not sure if this is a regression in ffmpeg/nvidia or just bad video
material. I hadn't ever run into this until about a month ago. And it's
happened on several videos from different DVD's. I didn't dig into it, I
just dropped the hwaccel parameters and moved on with my life. I wonder if
it's actually a problem in the hw-decoder, but I didn't see any error
messages to prove that.
___
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".