PS: You can quickly grab the example program here to reproduce the issue, but I think you have your own examples, try it out. Which greatly disrupts the whole idea of frame pts'es. In this example, the input of the encoder is camera captured frames with CIF resolution. A common command line input is shown below. We have modied mpeg such that encoded bitstreams are sent to receiver over UDP packets, or saved locally, or both. Well, it was working perfect in 3.x kernel, but suddenly on 4.x kernel, regardless of all needed flags set and passed - the input data in timestamp structure doesn't correspond to any of the outputs bits given anymore in the way we use them. It calls x264 library to encode frames captured by camera into H.264 bitstreams. configure -enable-gpl -enable-libx264 ERROR: libx264 not found If you think configure made a mistake, make sure you are using the latest version from Git. configure -enable-gpl -enable-libx264 bu I get. This works, since MFC uses V4L2_BUF_FLAG_TIMESTAMP_COPY flag for its queues, and input timestamp glued to input frames is just copied to output timestamp of output buffers, where we pick it up and get our pts back effectively knowing which frame is this corresponding to what we feed. I tried to enable h.264 with this guide How to quickly compile FFmpeg with libx264 (x264, H.264).
So, in the end, these two numbers in timeval struct doesn't make sense by themselves, but serve as two halves of double that can be glued back. We doesn't do that as intended (with number of seconds and useconds), but more on a smart move, mapping bits of double (64 bits) into bits of two int32. When using decoding, we glue timestamps to frames in v4l2_buffer structure in the timestamp field, which is timeval struct (two int32). Wanna really interesting task beneficial for education and community?
0 kommentar(er)
