[FFmpeg-user] Determine when h.264 TS/UDP frame rate has changed in C/C++

[Kevin Hise]

I'm decoding an h.264 video as TS over UDP from a Haivision encoder.
When I change the video output from the camera from one resolution
(like 720p) to something else (say 1080p) I can see a change in the
video context or the parser structures that indicate the new video
resolution.

However when I change the video to something that has the same
resolution BUT A DIFFERENT FRAME RATE (say from 59.9 to 60, or from 60
to 50) the video still properly decodes but none of the AVRational
values that should compute to the frame rate change...they all seem to
contain the same value from whatever the video frame rate was when
decoding started.

Even the API function "av guess frame rate" returns the original frame
rate, not the actual current rate.

Is there any way to determine what the *current* frame rate is,
without having to destroy and recreate the decoder context and parser?
Is there a way to determine that something has changed in the video
and the parser had to do some "thinking" (like it seems to do) so that
it could continue with decoding?

I need to know so I can update some rendering and timing values.

Thanks!
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffplay with Havision Makito X video encoder, H.264 stream, and "intra refresh" option enabled

[Kevin Hise]

On Sat, Oct 31, 2020 at 4:41 AM Carl Eugen Hoyos  wrote:
>
> Am Do., 29. Okt. 2020 um 17:44 Uhr schrieb Kevin Hise :
> >
> > I've attached 2 sample files (google drive links) captured using netcat (or
> > 'nc' on my Slackware box)...one showing video without the "intra refresh"
> > option enabled, and the other with.
> >
> >
> > The commands I've used to record and play back the video files are like so:
> >
> > nc -ul -s 233.254.1.1 -p 8000 >video.file
> >
> > cat video.file | nc -q 0 -bu 233.254.1.2 8000
>
> (Unrelated: The files you attached are already transport streams,
> no need to pipe them through nc)
>
> > The ffplay command line is:
> >
> > ffplay udp://233.254.1.2:8000
>
> You can use "-flags2 +showall" to decode the file (and -copyinkf to copy
> the video stream to allow testing other players).
>
> I am not convinced that the stream is sane, feel free to do more
> tests and report back. (I believe I remember other bugs in Makito
> encoders.)
>
> Please find out what "top-posting" means and remember to avoid it here.
>
> Carl Eugen
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Thank you, Carl. Knowing that the "-flags2 +showall" option exists
(and that it applies) is very helpful...and I've found the option
already useful in my "video wall" application by setting the context
structure's 'flags2' member. I passed the info up to the Havision tech
that contacted me...maybe that will help them. Not sure.

...and I'll try to wrestle with gmail and it's top-posting preference
and generally crappy email client implementation. :)

Thanks again.

--kev
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffplay with Havision Makito X video encoder, H.264 stream, and "intra refresh" option enabled

[Kevin Hise]

I've attached 2 sample files (google drive links) captured using netcat (or
'nc' on my Slackware box)...one showing video without the "intra refresh"
option enabled, and the other with.


The commands I've used to record and play back the video files are like so:

nc -ul -s 233.254.1.1 -p 8000 >video.file

cat video.file | nc -q 0 -bu 233.254.1.2 8000


The ffplay command line is:

ffplay udp://233.254.1.2:8000


If you play the "intra refresh" video back no video will be displayed in
the ffplay window (no window appears).

If you first play the "not intra refresh" video, the video window *does*
appear, then when that's done leave the ffplay window running (video has
stopped) and then play the "intra refresh" video file, the "intra refresh"
video does play, and it looks like some artifacts are "cleaned" off I guess
while the intra-refresh frames are processed like they're supposed to be.

It may be possible to simply "seed" the decoder logic with a black keyframe
and then let it recover from that (which is a C/C++ question, I'd assume).


The files are about 30MB each, and about 30 seconds or a little more. I
think the google drive links are shared properly.



https://drive.google.com/file/d/1rY8FMl8dQxZS29IR8OBw2yZt7S0PS4q2/view?usp=sharing
 not-intra-refesh.video


https://drive.google.com/file/d/1vrWWuDqQCe0MDQW3HxipJUPgl2eO7D8-/view?usp=sharing
 intra-refresh.video



Any help with ideas debugging is appreciated.

--kev


On Wed, Oct 28, 2020 at 10:59 PM Edward Park  wrote:

> Hi,
>
> > It was suggested here that I "attach a file" but I'm not sure how that
> > can be done with FFMPEG since it's unable to decode the video it
> > doesn't seem to write anything to a file when you try to record the
> > stream.
>
> I don’t know about the issue you’re describing but I think nc (or it might
> be netcat depending on your system) to save the raw data you’re  using as
> the input would be best for recreating the sample as a file from a udp
> stream.
>
> Regards,
> Ted Park
>
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffplay with Havision Makito X video encoder, H.264 stream, and "intra refresh" option enabled

[Kevin Hise]

Can I re-ask this question?

The Haivision (sorry...it's misspelled in the subject) Makito-X
encoder has a "intra refresh" setting that isn't supported by FFPLAY.
The Haivision hardware encoder takes SDI input and encodes it into
h.264 which is sent as transport stream over UDP. When you attempt to
display video with FFMPEG or FFPLAY, it eventually starts playing
video...I assume it waits for several minutes before a full key frame
is randomly sent and decoding can begin, but I'm not sure.

I'm wondering if there are any h.264 settings or other debug /
diagnostic info I can look into that might help me understand why. The
Haivision engineers may or may not be aware...since it decodes
correctly on their hardware it may not be their issue.

It was suggested here that I "attach a file" but I'm not sure how that
can be done with FFMPEG since it's unable to decode the video it
doesn't seem to write anything to a file when you try to record the
stream.

Would this question be a better one for the development mailing list, instead?

Thanks for any assistance.

--kev

On Tue, Oct 13, 2020 at 12:53 PM Kevin Hise  wrote:
>
> "of the file generated" not sure what that means, still. FFMPEG
> doesn't create much of a file with "-vcodec copy" as an option when I
> try to record the TS stream to a file. 5 or 10 seconds...which should
> be 1 MB per second or so...is only about 750 KB. I've attached it
> here.
>
> On Sat, Oct 10, 2020 at 4:14 AM Reto Kromer  wrote:
> >
> > Kevin Hise wrote:
> >
> > >Err...sample file of what?
> >
> > Of the file generated.
> >
> > ___
> > ffmpeg-user mailing list
> > ffmpeg-user@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-user
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffplay with Havision Makito X video encoder, H.264 stream, and "intra refresh" option enabled

[Kevin Hise]

Err...sample file of what? It's an encoder...a piece of hardware. I've
not tried writing the TS to a file and seeing if that also exhibits
the same behavior...either played back directly from the file or as a
file that's streamed back over the network as UDP to be decoded and
displayed by a player.

Guessing that it's likely 1MB / sec or so...so maybe a few seconds can
be attached as an email. I'll see what I can come up with. Thanks.

--kev

On Fri, Oct 9, 2020 at 4:17 PM Carl Eugen Hoyos  wrote:
>
>
>
> > Am 10.10.2020 um 01:13 schrieb Kevin Hise :
> >
> > I'm looking for some ideas about decoding an H.264 video stream
> > encoded by a Haivision Makito-X encoder and using its "intra refresh"
> > option.
> >
> > When the option is enabled (e.g. turning intra refresh "on") the video
> > decode is delayed by several minutes
>
> Please provide a sample file.
>
> Carl Eugen
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] ffplay with Havision Makito X video encoder, H.264 stream, and "intra refresh" option enabled

[Kevin Hise]

I'm looking for some ideas about decoding an H.264 video stream
encoded by a Haivision Makito-X encoder and using its "intra refresh"
option.

When the option is enabled (e.g. turning intra refresh "on") the video
decode is delayed by several minutes...perhaps 30 to 45 minutes...I
assume because at some point the encoder randomly ends up sending out
a key frame (?) which allows the decode process to begin decoding.

Up until that point however there is no video. I've tried this in
FFMPEG 4.2, 4.3 and also using VLCall have the same behavior.

I see lots of comments about ffmpeg supporting intra refresh but
nothing specific to anyone using it with other encoders, so I don't
know if intra refresh is encoder specific.

My question eventually ties into some ffmpeg software that I maintain
that implements a "video wall"...but I don't think is directly
programming related here.

Thank you.

--kev
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".