hverkuil: are you still looking for H264 parser library? I have an app for displaying H264 bitstream headers (PPS, SPS, frames, etc.) which uses https://github.com/aizvorski/h264bitstream
if you limit yourself to raw bitstream (without container), I think this should be good fit
jernej: interesting, I'll take a look at that.
Hello.
Is this patch merged? -> https://patchwork.kernel.org/patch/6874491/
I'm having issues with c920 where timestamps are going backwards atleast at the beginning of the stream
fling: yes, it's merged.
Is not there anything I can do?
sorry, I don't know anything about that. pinchartl might know.
pinchartl: Hello.
Probably best to post a query to the linux-media mailinglist.
I already read a lot of mailing lists about c920 and no real solutions to the issue
fling: hi
which kernel are you running ? the patch got merged in v4.4
pinchartl: 4.20
and what is the value of the uvcvideo hwtimestamps module parameter ?
you can check with cat /sys/module/uvcvideo/parameters/hwtimestamps
pinchartl: it is 0
pinchartl: still timestamps are mangled at the start of the stream
pinchartl: so I'm getting issues musing it with audio for a live stream
works for file output with minor issues
that's weird, the timestamps should be generated in software, so they shouldn't jump around
pinchartl: https://bpaste.net/show/fTIS
fling: I don't dispute the fact that you're having an issue with timestamps, but I don't know where it comes from
pinchartl: should be coming from the kernel by the default https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavdevice/v4l2.c;h=446a243cf8b7f9070ab57df1c728031b703c1f13;hb=HEAD#l1101
fling: can you try capturing frames with yavta and see if the timestamp issue persists ?
pinchartl: can't get it to work with h264 format
ah yes indeed
sorry, I can't really help you. this needs to be debugged
pinchartl: I'm having the similar issue with gstreamer also, so should not be an ffmpeg issue
fling: it may be a kernel-side issue, but it still needs to be debugged
I don't know where it comes from
What can I do? :>
debug it ? :-) find out if the timestamps come directly from the kernel, and if they do, find out why they're no monotonic
s/no monotonic/not monotonic/
you could possibly print them to the kernel log at DQBUF time in the uvcvideo driver (or maybe in vb2)
so I could just enable the logging somehow? would be nice and simple then
I'm not sure there are logging statements for that
you may need to add some
but in any case, you will have to figure out why it's not correct
I have to go I'm afraid
have a nice weekend, and good luck :-)
At first it is not correct because of the hardware itself
cya
thanks! ;>
with the hw timestamps disabled, the timestamps are generated in software, it shouldn't have anything to do with the hardware