[FFmpeg-user] ffmpeg generated h.264 stream

[Kenneth Fields]

hi,

Wondering if anyone has any insight about h.264 byte code stream:

The ffmpeg command line is:

  fmpeg\" -s 320x240 -f avfoundation -r 30.00 -i \"0:none\" -c:v libx264 
-preset ultrafast -tune zerolatency -x264opts 
crf=20:vbv-maxrate=3000:vbv-bufsize=100:intra-refresh=1:slice-max-size=1500:keyint=30:ref=1
 -b:v 1000 -an -f mpegts -threads 8 -profile:v baseline -level 3.0 -pix_fmt 
yuv420p udp://127.0.0.1:5564 "  

  In theory, the elementary stream in h.264 should be like this:  
view here: http://artsmesh.io/notice/15153 
 
So the key is to generate individual NALUs from H.264 stream. So we should get 
the bitstream like this:   
view here: http://artsmesh.io/conversation/15160 

We need get the real NALU type like this: 0x1F & NALU type. So 0x27 is equal 
0x67.

Normally, we should just have these NALU type(after the operation of 0x1F & 
NALU type):

1: slice of a non-IDR picture.  (P frame)

5: slice of an IDR picture. (I frame)

6: Supplemental enhancement information. (SEI)

7: Sequence parameter set. (SPS parameter)

8: Picture parameter set. (PPS parameter)",  

9: Access unit delimiter.

But what I get from udp is like this from the first  UDP packet:

In this udp datagram, something doesn’t make sense, after the 0x0001start 
code header, the NALU type is 0xff, and the second one is 0xf0, both of them 
are undefined in h.264.

view here: http://artsmesh.io/notice/15154 
So I’m having trouble finding out why the h.264 stream is not working.

And is that true that the start code header is always four bytes, "0x 0001"

Sent out to the ffmpeg list for Whisky Zed
 
 

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

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

Re: [FFmpeg-user] Low latency H.264 streaming with ffmpeg

[Kenneth Fields]

yes, we’re having the same issue now.
but -benchmark also really degrades the stream.
Is there any options possible for -benchmark (moderate, strict)?

Ken



> mplayer -benchmark has been the only client I've found with reasonable
> latency, though I'm sure there are others/more.
> I've gotten pretty low latency before with ultrafast+zerolatency
> 
> Basically my advice is "be wary of ffplay (and vlc)" I'm not sure if
> its latency is low enough...


> On Jan 13, 2016, at 2:30 AM, Roger Pack  wrote:
> 
> On 1/12/16, Greger Burman > wrote:
>> I would like to hear from anyone who has experience with low latency video
>> streaming and ffmpeg.
>> 
>> In my application I take video from a PCIe capture device and stream live
>> over network. The end to end latency must be below 200ms otherwise it is
>> not usable. Let us assume that the network latency is near zero. This
>> question is about encoder+decoder+buffering latency.
>> 
>> Very low latency can be achieved when using the x264 encoder by using
>> settings like tune zerolatency. From my own testing with x264 (without
>> ffmpeg) I can confirm that this works. I have measured approx 90 ms (3
>> frames) of latency added by encoder+decoder combined. Awesome.
>> 
>> Sadly I have been unable to get anywhere near those numbers when using
>> ffmpeg and libx264. As player I use either ffplay or a dot-net player built
>> on the ffmpeg libraries, with about equal results. The lowest end to end
>> latency I have seen is 400-500ms. That includes capture latency also.
> 
> 
> https://trac.ffmpeg.org/wiki/StreamingGuide 
> 
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org 
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user 
> 
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[FFmpeg-user] Syphon Ffmpeg bridge

[Kenneth Fields]

Dear all,
Is there any news of late regarding a syphon bridge to/from ffmpeg?
I found a couple old posting on v002:
http://v002.info/forums/topic/syphon-piped-to-ffmpeg/ 


Thanks in advance,
Ken


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

[FFmpeg-user] Real-time HAP encoded streaming

[Kenneth Fields]

Hi,
in general documentation, 
Supported External Libraries, Formats, Codecs or Features 
=
I see Vidvox HAP under 2.1 file formats and not under video codecs. 
Can real-time HAP encoded network streaming be done? Anyone stats 
or reports on P2P HAP encoded streaming latency?

A normal, H.264 codec is unusable for p2p conferencing/performing as it
takes seconds to encode. I send audio separately (uncompressed
with Jacktrip), so the audio gets there first, without compression delay.

We want to use the GPU for HAP encoding.

On wikipedia:
https://en.wikipedia.org/wiki/List_of_codecs 

I see:
Realtime[edit 
]
Hap/Hap Alpha/Hap Q
VIDVOX hap codec
FFmpeg
DXV Codec
Resolume DXV Codec
FFmpeg (decoder only)

Thanks,
Ken
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[FFmpeg-user] hap/snappy

[Kenneth Fields]

Hi,
trying to compile a version of ffmpeg with hap/snappy & have been unsuccessful 
so far, even with non-static libraries. compiling ffmpeg via home-brew.
Having a look at homebrew commits, I can see the "with-snappy” option is 
available for the compile.  
Trying a compile via homebrew:

brew reinstall ffmpeg --with-fdk-aac --with-ffplay --with-libquvi 
--with-libvorbis --with-libvpx --with-opus --with-snappy

It gives me an error: Snappy library not found - which is the same error I get 
when trying to compile locally on my machine using static libraries.  If I try 
to use the static snappy library I’ve manually inserted via pkg-manager: 

brew reinstall ffmpeg --with-fdk-aac --with-ffplay --with-libquvi 
--with-libvorbis --with-libvpx --with-opus --with-libsnappy

The install actually works, but it seems to just skip right over the libsnappy 
library in this case & just installs a standard version of ffmpeg.  I’ve been 
trying various p2p commands to be sure I don’t have the library enabled with 
ffmpeg, like: 

ffmpeg -f avfoundation -r 30 -i "0" -s 640x480 -vcodec hap -preset fast 
-threads 0 -pix_fmt yuv420p -f hap_q udp://10.0.1.9:1234 

This fails with an error that hap isn’t a suitable format.

Thanks,
Ken


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