H264_omx = mostly black videos, libx264 is too slow, sound slows everything down

I am trying to port a real-time transcoding application from Windows (on a .net kernel) to work with Raspberry Pi 3.

Under the hood, I use ffmpeg to take the mpeg2 stream from the local network TV tuner and spit out the local HLS stream that opens through the user HTTP server.

FFmpeg for Linux is configured to build as follows:

sudo ./configure --arch=armhf --target-os=linux --enable-gpl --enable-libx264 --enable-nonfree --enable-mmal --enable-omx --enable-omx-rpi 

Having seen the primary problem at an early stage, I tried to minimize it to a simpler form and started using VOB from DVD (also mpeg2), take the following example:

 ffmpeg -i VTS_01_2.VOB -c:a aac -c:v h264_omx -b:v 256k -hls_time 3 -hls_wrap 30 "/media/usb1/foo.m3u8" 

Within a few seconds, it drops not only to 30 FPS, but also to low teens.

The following actions are performed very quickly and can keep up when the tv stream is indicated ... only everything except the first ts file will be black (but with sound) ... what turns out to be the previous line also suffers:

 ffmpeg -i VTS_01_2.VOB -c:a copy -c:v h264_omx -b:v 256k -hls_time 3 -hls_wrap 30 "/media/usb1/foo.m3u8" 

Besides the strangeness of my choice of audio codecs (that is, accepting that already exists against choosing something else), it will slow down the stream, I also found that in order to have a visible video ... I need to go without hardware support.

 ffmpeg -i VTS_01_2.VOB -c:a aac -c:v libx264 -b:v 256k -hls_time 3 -hls_wrap 30 "/media/usb1/foo.m3u8" 

and

 ffmpeg -i VTS_01_2.VOB -c:a copy -c:v libx264 -b:v 256k -hls_time 3 -hls_wrap 30 "/media/usb1/foo.m3u8" 

both result in a video that appears ... and with good sound, except that they are too slow in terms of FPS to be able to support live streaming.

Is there something that I am missing so that ffmpeg can handle the conversion of the mpeg2 stream to h.264 ... and result in video files?

To save space, I put console logs on pastebin.

h264_omx: https://pastebin.com/GK3zN4aB libx264: https://pastebin.com/uEdCwk47

As I think more about this, the error [[mpegts @ 0x2fe0be0] H.264 bitstream error, startcode missing, size 082 drop = 0 speed = 3.07x "may be related, but when viewing a longer session we do not consider them as ordinary (as I thought) to erase the entire video stream to later files, the sizes of which are built into the first: https://pastebin.com/J1EzTqgK

+5
source share

Source: https://habr.com/ru/post/1269661/


All Articles