Recherche avancée

Sur d’autres sites (11617)

• Stop doing this in your encoder comparisons

  14 juin 2010, par Dark Shikari — Uncategorized

  I’ll do a more detailed post later on how to properly compare encoders, but lately I’ve seen a lot of people doing something in particular that demonstrates they have no idea what they’re doing.

  PSNR is not a very good metric. But it’s useful for one thing : if every encoder optimizes for it, you can effectively measure how good those encoders are at optimizing for PSNR. Certainly this doesn’t tell you everything you want to know, but it can give you a good approximation of “how good the encoder is at optimizing for SOMETHING“. The hope is that this is decently close to the visual results. This of course can fail to be the case if one encoder has psy optimizations and the other does not.

  But it only works to begin with if both encoders are optimized for PSNR. If one optimizes for, say, SSIM, and one optimizes for PSNR, comparing PSNR numbers is completely meaningless. If anything, it’s worse than meaningless — it will bias enormously towards the encoder that is tuned towards PSNR, for obvious reasons.

  And yet people keep doing this.

  They keep comparing x264 against other encoders which are tuned against PSNR. But they don’t tell x264 to also tune for PSNR (–tune psnr, it’s not hard !), and surprise surprise, x264 loses. Of course, these people never bother to actually look at the output ; if they did, they’d notice that x264 usually looks quite a bit better despite having lower PSNR.

  This happens so often that I suspect this is largely being done intentionally in order to cheat in encoder comparisons. Or perhaps it’s because tons of people who know absolutely nothing about video coding insist on doing comparisons without checking their methodology. Whatever it is, it clearly demonstrates that the person doing the test doesn’t understand what PSNR is or why it is used.

  Another victim of this is Theora Ptalarbvorm, which optimizes for SSIM at the expense of PSNR — an absolutely great decision for visual quality. And of course if you just blindly compare Ptalarbvorm (1.2) and Thusnelda (1.1), you’ll notice Ptalarbvorm has much lower PSNR ! Clearly, it must be a worse encoder, right ?

  Stop doing this. And call out the people who insist on cheating.

• Stop doing this in your encoder comparisons

  14 juin 2010, par Dark Shikari — Uncategorized

  I’ll do a more detailed post later on how to properly compare encoders, but lately I’ve seen a lot of people doing something in particular that demonstrates they have no idea what they’re doing.

  PSNR is not a very good metric. But it’s useful for one thing : if every encoder optimizes for it, you can effectively measure how good those encoders are at optimizing for PSNR. Certainly this doesn’t tell you everything you want to know, but it can give you a good approximation of “how good the encoder is at optimizing for SOMETHING“. The hope is that this is decently close to the visual results. This of course can fail to be the case if one encoder has psy optimizations and the other does not.

  But it only works to begin with if both encoders are optimized for PSNR. If one optimizes for, say, SSIM, and one optimizes for PSNR, comparing PSNR numbers is completely meaningless. If anything, it’s worse than meaningless — it will bias enormously towards the encoder that is tuned towards PSNR, for obvious reasons.

  And yet people keep doing this.

  They keep comparing x264 against other encoders which are tuned against PSNR. But they don’t tell x264 to also tune for PSNR (–tune psnr, it’s not hard !), and surprise surprise, x264 loses. Of course, these people never bother to actually look at the output ; if they did, they’d notice that x264 usually looks quite a bit better despite having lower PSNR.

  This happens so often that I suspect this is largely being done intentionally in order to cheat in encoder comparisons. Or perhaps it’s because tons of people who know absolutely nothing about video coding insist on doing comparisons without checking their methodology. Whatever it is, it clearly demonstrates that the person doing the test doesn’t understand what PSNR is or why it is used.

  Another victim of this is Theora Ptalarbvorm, which optimizes for SSIM at the expense of PSNR — an absolutely great decision for visual quality. And of course if you just blindly compare Ptalarbvorm (1.2) and Thusnelda (1.1), you’ll notice Ptalarbvorm has much lower PSNR ! Clearly, it must be a worse encoder, right ?

  Stop doing this. And call out the people who insist on cheating.

• Fix CBR output for IP multicasting video

  19 août 2014, par ddhung

  I’m using ffmpeg for transcoding live ip multicasting video on server linux Centos 5.9 OS. This is my ffmpeg command

  ffmpeg -i "udp:// x.x.x.x:6000?fifo_size=1000000&overrun_nonfatal=1&timeout=1000000" -filter:v yadif=0:-1:1 -vcodec libx264 -vprofile main -level 30 -tune zerolatency -pass 1 -b:v 900k -minrate 900k -maxrate 900k -bufsize 900k -x264opts nal_hrd=cbr:rc_lookahead=40:interlaced=1:scenecut=0:cabac=1:keyint=120:deblock=0,0:aud=1:qpmin=16:qpmax=51:qpstep=10:ref=2:mixed-refs=1:subme=9:me=esa:chroma_me=0:merange=64:8x8dct=0:fast_pskip=0:chroma_qp_offset=0:trellis=2:psy=0:bframes=0:weightp=2:sliced_threads -s:v 720x576 -r:v 25 -force_key_frames 'expr:gte(t,n_forced*3)' -threads 0 -acodec aac -strict -2 -ac 1 -ar 32000 -b:a 32k -filter:a volume=1 -f mpegts -muxrate 1400k udp://x.x.x.x:6000?pkt_size=1316

  My output video is for broadcasting so I have to configure CBR video output by feature –muxrate. But when I watch this stream on VLC the bitrate change very much not constant. The null packet is very high to force cbr mpeg2ts output.

  I also measure IP output video by HST3000 JDSU equipment and I see the measurement result is very bad as images.
  The PCR Jitter, IGMP Latency, Jitter Max which is not good as measurement standard by JDSU

  I try many way to change the ffmpeg command but not successful. The bitrate changes sometime > 1400kbps a lot. I think the problem may be the bitrate not constant. I have heard to change the muxrate output is CBR, it had to be change the code C mpegtsenc.c in libavformat library to new patch.
  So could you help me fix this problem and make the measurment result is better.
  Thank you so much.

  Best Regards