Newest 'x264' Questions - Stack Overflow

Les articles publiés sur le site

• h264 RTP timestamp

  26 octobre 2024, par user269090

  I have a confusion about the timestamp of h264 RTP packet. I know the wall clock rate of video is 90KHz which I defined in the SIP SDP. The frame rate of my encoder is not exactly 30 FPS, it is variable. It varies from 15 FPS to 30 FPS on the fly. So, I cannot use any fixed timestamp.

  Could any one tell me the timestamp of the following encoded packet.
  After 0 milisecond encoded RTP timestamp = 0 (Let the starting timestamp 0)
  After 50 milisecond encoded RTP timestamp = ?
  After 40 milisecond encoded RTP timestamp = ?
  After 33 milisecond encoded RTP timestamp = ?
  

  What is the formula when the encoded frame rate is variable?

  Thank you in advance.

• x264/x265 options for fast decoding while preserving quality

  18 août 2024, par user3301993

  I want to encode some videos in H264 and H265, and I would like to ask for help in order to chose the adequate options in x264/x265.

  • My first priority is video quality. Lossless would be the best quality for example
  • My second priority is fast decoding speed (ie: I would like faster decoding without sacrificing quality)
    • fast decoding for me means that the decoding machine would use less CPU resources reading the resulting video
    • Less RAM consumption would be a plus
    • Latency is not important
  • I don't care that much if the output file ends up bigger. Also, encoding speed is not important

  I'm aware of the option -tune fastdecode in both x264 and x265. But apparently the quality gets a bit worse using it.

  For x264:

  -tune fastdecode is equivalent to --no-cabac --no-deblock --no-weightb --weightp 0 (My source is x264 --fullhelp)

  Which options preserve quality ?

  For x265:

  -tune fastdecode is equivalent to --no-deblock --no-sao --no-weightp --no-weightb --no-b-intra (according to x265 doc)

  Again, which options preserve quality ?

  I tried to read some documentation on these options, but I'm afraid I'm too stupid to understand if they preserve quality or not.

  To explain further what I mean by "preserving quality":

  I don't understand what the cabac option does exactly. But let's say for example that it adds some extra lossless compression, resulting in a smaller video file, but the decoding machine would need to do extra work to decompress the file

  In that case, the --no-cabac option would skip that extra compression, resulting in no loss of quality, with a bigger file size, and the decoding machine would not need to decompress the extra compression, saving CPU work on the decoding side

  In this scenario, I would like to add the --no-cabac option, as it speeds up decoding, while preserving quality.

  I hope I could get my point across

  Can anyone help me pick the right options ?

  Thanks in advance

• How to check 'Output bit depth' of the libx264 library in ffmpeg ?

  26 mai 2024, par Greg

  According to the x264 Encoding Guide, the crf scale depends on whether x264 is 8-bit or 10-bit. Supposedly x264 --help shows the Output bit depth. But on Windows ffmpeg -h full doesn't say anything about Output bit depth and the crf scale option is described as from -1 to FLT_MAX. How can I check if my ffmpeg is using 8-bit or 10-bit version of the libx264 library?

• I use ffmpeg to encode and create MPEG file from a source MP4 file. In Mac the encoding is good but in windows it creates random green pixels [closed]

  24 mai 2024, par Amudhan R

  I use ffmpeg 3.4.2 version to encode and create an MPEG-TS file using H.264 encoding. In both Windows and Mac the ffmpeg creates the video without any error. But the resultant video from windows having a green pixels on certain frames. No idea why this is happening.

  Below is the encoding command:

  ffmpeg -i VIDEO_SOURCE.mp4 -vf scale=720:480 -c:v libx264 -b:v 2M -minrate 2M -maxrate 2M -bufsize 2M -level:v 40 -profile:v main -bf:v 2 -r 30 -crf 22 -x264-params 'keyint=3:min-keyint=3:ref=2:8x8dct=0:weightp=1:subme=6:rc-lookahead=30' -c:a aac -b:a 130k -ar 48000 -f mpegts -filter_complex alimiter=level_in=1:level_out=1:limit=0.15:attack=7:release=100:level=0 VIDEO_ENCODED.mpeg

  But the resultant video from windows having green pixels on certain frames. No idea why this is happening.

• Is it still possible to compile modern x264 with the nal long start code used prior to release r1510 ?

  25 avril 2024, par Bryan Knowles

  I'm currently nerding out on old technology with HD-DVDs. The only freely available muxer is hddvdmux, I'm using MultiAVCHD for this. Beginning with r1510, x264 switched to short start packets for NAL HRD (from what I understand). This makes the stream incompatible with hddvdmux. deank on doom9 patched hddvdmux to accept short start codes, but in doing so, the video file plays too quickly and the audio goes out of sync. The results I'm getting from the 2009 release of x264 leave much to be desired in comparison to modern releases, and I'd like to get those benefits while still maintaining compatibility with the original hddvdmux. Is it possible? If so... Any chance someone could compile a Windows binary for me with that change? (I think it needs to be 32 bit, but not sure)

  I've tried multiple options with MultiAVCHD 4.1, fell back to 4.0 but am seeing weird rainbowing effects in the color from the extremely old version if x264. I admit I haven't dived in to programming, but seemed like a single change might be a reasonable request from someone already knowledgeable.