Recherche avancée

Sur d’autres sites (14781)

• kmsgrab : Fix DRM format definitions

  15 septembre 2017, par Mark Thompson

  kmsgrab : Fix DRM format definitions
  All DRM formats are defined in terms of little-endian words, so RGB formats
  
  like XRGB actually have the elements in the opposite order order in memory
  
  to the order they are in the name.
  This does not affect YUYV and similar YUV 4:2:2 formats, which are in the
  
  expected order.
  

  • [DH] libavdevice/kmsgrab.c

• h264_omx = mostly black videos, libx264 too slow, audio slows everything down

  11 août 2017, par Brendan Grant

  I’m attempting to port a live tv transcoding app from Windows (on .net core) to work on a Raspberry Pi 3.

  Under the hood I uses ffmpeg to take in an mpeg2 stream from a local networked tv tuner and spit out a local HLS stream which is exposed via a custom http server.

  FFmpeg on Linux is configured for build as following :

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

  Seeing perf issues early on, I tried to boil it down to a simpler form and started using a VOB from a 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 matter of seconds, this drops to not only under 30 FPS, but down to the low teens.

  The following runs plenty fast, and is able to keep up when pointed to the tv stream... only all but the first ts file will end up being black (but with audio)... which it turns out the previous line also suffers from :

  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"

  Aside from the oddity of my choice of audio codecs (ie accepting what is already there vs choosing something else) would so slow down the stream, I also discovered that in order to have visible video... I have to go without hardware assistance.

  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 turn out video which shows up... and with good audio, except both are too slow in terms of FPS to be able to keep up with a live tv stream.

  Is there something I am missing here to be able to get ffmpeg to be able to handle turning an mpeg2 stream into an h.264 one... and have the resulting files have video ?

  To save space here, I’ve put the console logs on pastebin.

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

  As I think about it more, the "[mpegts @ 0x2fe0be0] H.264 bitstream error, startcode missing, size 082 drop=0 speed=3.07x" error may be related, but when looking at a longer session we do not see them as regular (as I would think) to obliterate the entire video stream on later files whose sizes are inline with the first : https://pastebin.com/J1EzTqgK

• mdec : stop preferring the simple IDCT.

  21 juin 2017, par Ronald S. Bultje

  mdec : stop preferring the simple IDCT.
  This was added in e3e3c82555e2382125195c1ba9f34b5a43299abc, probably
  
  as a workaround for the fact that the quant table was not permutated
  
  and the IDCT coefficients are, meaning that you'd only get correct
  
  reconstruction if the IDCT permutation was an identity matrix, which
  
  happens to be the case when you use the simple IDCT. The quant table
  
  permutation bug was fixed in 42dd1434bf6a7230e4175c08fcfabc3ba51a0463,
  
  meaning this workaround is no longer necessary.
  In practical terms, before 42dd1434bf6a7230e4175c08fcfabc3ba51a0463,
  
  the PSNR between decodes of the fate-mdec using simple (C) or simplemmx
  
  IDCTs was 35. After 42dd1434bf6a7230e4175c08fcfabc3ba51a0463, it's 90.
  

  • [DH] libavcodec/mdec.c