Recherche avancée

Sur d’autres sites (5600)

• Simply beyond ridiculous

  7 mai 2010, par Dark Shikari — H.265, speed

  For the past few years, various improvements on H.264 have been periodically proposed, ranging from larger transforms to better intra prediction. These finally came together in the JCT-VC meeting this past April, where over two dozen proposals were made for a next-generation video coding standard. Of course, all of these were in very rough-draft form ; it will likely take years to filter it down into a usable standard. In the process, they’ll pick the most useful features (hopefully) from each proposal and combine them into something a bit more sane. But, of course, it all has to start somewhere.

  A number of features were common : larger block sizes, larger transform sizes, fancier interpolation filters, improved intra prediction schemes, improved motion vector prediction, increased internal bit depth, new entropy coding schemes, and so forth. A lot of these are potentially quite promising and resolve a lot of complaints I’ve had about H.264, so I decided to try out the proposal that appeared the most interesting : the Samsung+BBC proposal (A124), which claims compression improvements of around 40%.

  The proposal combines a bouillabaisse of new features, ranging from a 12-tap interpolation filter to 12thpel motion compensation and transforms as large as 64×64. Overall, I would say it’s a good proposal and I don’t doubt their results given the sheer volume of useful features they’ve dumped into it. I was a bit worried about complexity, however, as 12-tap interpolation filters don’t exactly scream “fast”.

  I prepared myself for the slowness of an unoptimized encoder implementation, compiled their tool, and started a test encode with their recommended settings.

  I waited. The first frame, an I-frame, completed.

  I took a nap.

  I waited. The second frame, a P-frame, was done.

  I played a game of Settlers.

  I waited. The third frame, a B-frame, was done.

  I worked on a term paper.

  I waited. The fourth frame, a B-frame, was done.

  After a full 6 hours, 8 frames had encoded. Yes, at this rate, it would take a full two weeks to encode 10 seconds of HD video. On a Core i7. This is not merely slow ; this is over 1000 times slower than x264 on “placebo” mode. This is so slow that it is not merely impractical ; it is impossible to even test. This encoder is apparently designed for some sort of hypothetical future computer from space. And word from other developers is that the Intel proposal is even slower.

  This has led me to suspect that there is a great deal of cheating going on in the H.265 proposals. The goal of the proposals, of course, is to pick the best feature set for the next generation video compression standard. But there is an extra motivation : organizations whose features get accepted get patents on the resulting standard, and thus income. With such large sums of money in the picture, dishonesty becomes all the more profitable.

  There is a set of rules, of course, to limit how the proposals can optimize their encoders. If different encoders use different optimization techniques, the results will no longer be comparable — remember, they are trying to compare compression features, not methods of optimizing encoder-side decisions. Thus all encoders are required to use a constant quantizer, specified frame types, and so forth. But there are no limits on how slow an encoder can be or what algorithms it can use.

  It would be one thing if the proposed encoder was a mere 10 times slower than the current reference ; that would be reasonable, given the low level of optimization and higher complexity of the new standard. But this is beyond ridiculous. With the prize given to whoever can eke out the most PSNR at a given quantizer at the lowest bitrate (with no limits on speed), we’re just going to get an arms race of slow encoders, with every company trying to use the most ridiculous optimizations possible, even if they involve encoding the frame 100,000 times over to choose the optimal parameters. And the end result will be as I encountered here : encoders so slow that they are simply impossible to even test.

  Such an arms race certainly does little good in optimizing for reality where we don’t have 30 years to encode an HD movie : a feature that gives great compression improvements is useless if it’s impossible to optimize for in a reasonable amount of time. Certainly once the standard is finalized practical encoders will be written — but it makes no sense to optimize the standard for a use-case that doesn’t exist. And even attempting to “optimize” anything is difficult when encoding a few seconds of video takes weeks.

  Update : The people involved have contacted me and insist that there was in fact no cheating going on. This is probably correct ; the problem appears to be that the rules that were set out were simply not strict enough, making many changes that I would intuitively consider “cheating” to be perfectly allowed, and thus everyone can do it.

  I would like to apologize if I implied that the results weren’t valid ; they are — the Samsung-BBC proposal is definitely one of the best, which is why I picked it to test with. It’s just that I think any situation in which it’s impossible to test your own software is unreasonable, and thus the entire situation is an inherently broken one, given the lax rules, slow baseline encoder, and no restrictions on compute time.

• Android FFMPEG library crashes on Lollipop

  27 juillet 2015, par Laurent Gorse

  I’m using this open-source library to encode RTMP streams for my live streaming app :

  https://github.com/cine-io/cineio-broadcast-android

  The library is based on FFMPEG with libRTMP, and is open-source. It build the following native shared library :
  https://github.com/cine-io/ffmpegbridge

  Which relies on this :
  https://github.com/cine-io/android-ffmpeg-with-rtmp

  The issue is Lollipop compatibility. There’s a notorious issue where libraries need to be recompiled with PIE, but usually the thrown error is specific and states that "all binaries must be compiled with PIE".

  However, as soon as I start streaming on Android 5.+, this is the error I get from the backtrace :

  D/CrashAnrDetector(  903): Build: samsung/klteuc/klteatt:5.0/LRX21T/G900AUCU4BOF2:user/release-keys
  
  D/CrashAnrDetector(  903): Hardware: MSM8974
  
  D/CrashAnrDetector(  903): Revision: 14
  
  D/CrashAnrDetector(  903): Bootloader: G900AUCU4BOF2
  
  D/CrashAnrDetector(  903): Radio: unknown
  
  D/CrashAnrDetector(  903): Kernel: Linux version 3.4.0-4432708 (dpi@SWDD6014) (gcc version 4.8 (GCC) ) #1 SMP PREEMPT Thu Jun 18 17:58:46 KST 2015
  
  D/CrashAnrDetector(  903): 
  
  D/CrashAnrDetector(  903): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
  
  D/CrashAnrDetector(  903): Build fingerprint: 'samsung/klteuc/klteatt:5.0/LRX21T/G900AUCU4BOF2:user/release-keys'
  
  D/CrashAnrDetector(  903): Revision: '14'
  
  D/CrashAnrDetector(  903): ABI: 'arm'
  
  D/CrashAnrDetector(  903): pid: 18365, tid: 18877, name: FFmpeg  >>> com.streem.mobile.android <<<
  
  D/CrashAnrDetector(  903): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x68
  
  D/CrashAnrDetector(  903):     r0 00000000  r1 9c9c1038  r2 00000003  r3 80000000
  
  D/CrashAnrDetector(  903):     r4 00017002  r5 9c9e2a64  r6 a0c46400  r7 afb6d400
  
  D/CrashAnrDetector(  903):     r8 00000002  r9 00000002  sl b3b6a680  fp 00000000
  
  D/CrashAnrDetector(  903):     ip b3b70100  sp 9f88f838  lr 9c8bafa8  pc 9c898438  cpsr 600f0010
  
  D/CrashAnrDetector(  903):     d0  0000000000000000  d1  0000000000000000
  
  D/CrashAnrDetector(  903):     d2  6572745356412074  d3  5f656d69742e6d61
  
  D/CrashAnrDetector(  903):     d4  0000000000000000  d5  0000000300000004
  
  D/CrashAnrDetector(  903):     d6  0000000000000000  d7  ffff000000000000
  
  D/CrashAnrDetector(  903):     d8  c3d80000c4ca8000  d9  3f8000003f800000
  
  D/CrashAnrDetector(  903):     d10 0000000000000000  d11 0000000000000000
  
  D/CrashAnrDetector(  903):     d12 0000000000000000  d13 0000000000000000
  
  D/CrashAnrDetector(  903):     d14 0000000000000000  d15 0000000000000000
  
  D/CrashAnrDetector(  903):     d16 564120676e697355  d17 632e6d6165727453
  
  D/CrashAnrDetector(  903):     d18 6d69742e6365646f  d19 6120657361625f65
  
  D/CrashAnrDetector(  903):     d20 656d697420612073  d21 6e69682065736162
  
  D/CrashAnrDetector(  903):     d22 656874206f742074  d23 6920726578756d20
  
  D/CrashAnrDetector(  903):     d24 0000000000000000  d25 0000000000000000
  
  D/CrashAnrDetector(  903):     d26 0001000100010001  d27 0002000100010001
  
  D/CrashAnrDetector(  903):     d28 0080008000800080  d29 0080008000800080
  
  D/CrashAnrDetector(  903):     d30 0800080008000800  d31 0800080008000800
  
  D/CrashAnrDetector(  903):     scr 20000011
  
  D/CrashAnrDetector(  903): 
  
  D/CrashAnrDetector(  903): backtrace:
  
  D/CrashAnrDetector(  903):     #00 pc 00038438  /data/app/com.streem.mobile.android-2/lib/arm/libavformat-56.so (avio_write)
  
  D/CrashAnrDetector(  903):     #01 pc 0005afa4  /data/app/com.streem.mobile.android-2/lib/arm/libavformat-56.so
  
  D/CrashAnrDetector(  903): 
  
  D/CrashAnrDetector(  903): stack:
  
  D/CrashAnrDetector(  903):          9f88f7f8  afb6d400  
  
  D/CrashAnrDetector(  903):          9f88f7fc  00000004  
  
  D/CrashAnrDetector(  903):          9f88f800  00000001  
  
  D/CrashAnrDetector(  903):          9f88f804  b3b6a680  
  
  D/CrashAnrDetector(  903):          9f88f808  00000000  
  
  D/CrashAnrDetector(  903):          9f88f80c  b6f34a9d  /system/lib/libc.so (posix_memalign+12)
  
  D/CrashAnrDetector(  903):          9f88f810  7fffffdf  /dev/ashmem/dalvik-alloc-space-gap (deleted)
  
  D/CrashAnrDetector(  903):          9f88f814  9ee5393c  /data/app/com.streem.mobile.android-2/lib/arm/libavutil-54.so (av_malloc+80)
  
  D/CrashAnrDetector(  903):          9f88f818  9c9e2a64  /data/app/com.streem.mobile.android-2/lib/arm/libavformat-56.so
  
  D/CrashAnrDetector(  903):          9f88f81c  b3bf1cd0  
  
  D/CrashAnrDetector(  903):          9f88f820  00017002  
  
  D/CrashAnrDetector(  903):          9f88f824  b3bf1cd0  
  
  D/CrashAnrDetector(  903):          9f88f828  b3b70128  
  
  D/CrashAnrDetector(  903):          9f88f82c  00017002  
  
  D/CrashAnrDetector(  903):          9f88f830  9c9e2a64  /data/app/com.streem.mobile.android-2/lib/arm/libavformat-56.so
  
  D/CrashAnrDetector(  903):          9f88f834  9c8baf54  /data/app/com.streem.mobile.android-2/lib/arm/libavformat-56.so
  
  D/CrashAnrDetector(  903):     #00  9f88f838  00000000  
  
  D/CrashAnrDetector(  903):          ........  ........
  
  D/CrashAnrDetector(  903):     #01  9f88f838  00000000  
  
  D/CrashAnrDetector(  903):          9f88f83c  00000019  
  
  D/CrashAnrDetector(  903):          9f88f840  afb6d400  
  
  D/CrashAnrDetector(  903):          9f88f844  9c9c11f0  /data/app/com.streem.mobile.android-2/lib/arm/libavformat-56.so
  
  D/CrashAnrDetector(  903):          9f88f848  9c9c1110  /data/app/com.streem.mobile.android-2/lib/arm/libavformat-56.so
  
  D/CrashAnrDetector(  903):          9f88f84c  9c9c109c  /data/app/com.streem.mobile.android-2/lib/arm/libavformat-56.so
  
  D/CrashAnrDetector(  903):          9f88f850  7fffffff  /dev/ashmem/dalvik-alloc-space-gap (deleted)
  
  D/CrashAnrDetector(  903):          9f88f854  00000000  
  
  D/CrashAnrDetector(  903):          9f88f858  b3bbcba8  
  
  D/CrashAnrDetector(  903):          9f88f85c  00000000  
  
  D/CrashAnrDetector(  903):          9f88f860  a0c46874  
  
  D/CrashAnrDetector(  903):          9f88f864  9c9cf9d4  /data/app/com.streem.mobile.android-2/lib/arm/libavformat-56.so
  
  D/CrashAnrDetector(  903):          9f88f868  a0c46400  
  
  D/CrashAnrDetector(  903):          9f88f86c  00000001  
  
  D/CrashAnrDetector(  903):          9f88f870  b3b70100  
  
  D/CrashAnrDetector(  903):          9f88f874  00000019  
  
  D/CrashAnrDetector(  903): 
  
  D/CrashAnrDetector(  903): memory near r1:
  
  D/CrashAnrDetector(  903):     9c9c1018 00000000 6f6e6749 676e6972 74656d20  
  
  D/CrashAnrDetector(  903):     9c9c1028 74616461 6f662061 73252072 0000000a  
  
  D/CrashAnrDetector(  903):     9c9c1038 00564c46 6d207461 2074736f 20656e6f  
  
  D/CrashAnrDetector(  903):     9c9c1048 65646976 7473206f 6d616572 20736920  
  
  D/CrashAnrDetector(  903):     9c9c1058 70707573 6574726f 6e692064 766c6620  
  
  D/CrashAnrDetector(  903):     9c9c1068 0000000a 63207325 6365646f 20732520  
  
  D/CrashAnrDetector(  903):     9c9c1078 20746f6e 706d6f63 62697461 7720656c  
  
  D/CrashAnrDetector(  903):     9c9c1088 20687469 0a766c66 00000000 65646956  
  
  D/CrashAnrDetector(  903):     9c9c1098 0000006f 6978754d 5620676e 69203650  
  
  D/CrashAnrDetector(  903):     9c9c10a8 6c66206e 69772076 70206c6c 75646f72  
  
  D/CrashAnrDetector(  903):     9c9c10b8 66206563 7070696c 76206465 6f656469  
  
  D/CrashAnrDetector(  903):     9c9c10c8 206e6f20 79616c70 6b636
  
  D/CrashAnrDetector(  903): processName:com.streem.mobile.android
  
  D/CrashAnrDetector(  903): broadcastEvent : com.streem.mobile.android SYSTEM_TOMBSTONE

  I’d appreciate any help available in debugging the issue.

• avformat/evc_muxer : Added muxer to handle writing EVC encoded data into file or outpu...

  15 juin 2023, par Dawid Kozinski

  avformat/evc_muxer : Added muxer to handle writing EVC encoded data into file or output bytestream
   Provided AVOutputFormat structure describing EVC output format (ff_evc_muxer)
  
   Added documentation for EVC muxer
  Signed-off-by : Dawid Kozinski <d.kozinski@samsung.com>
  

  • [DH] doc/muxers.texi
  • [DH] libavformat/Makefile
  • [DH] libavformat/allformats.c
  • [DH] libavformat/rawenc.c