Tomas Janousek | 1 Jan 2010 18:03
Picon
Gravatar

Re: Fix issues relating to input/output files being pipes/FIFOs

----- Forwarded message from Tomas Janousek <tomi <at> nomi.cz> -----

Date: Thu, 24 Dec 2009 11:11:33 +0100
From: Tomas Janousek <tomi <at> nomi.cz>
To: Steven Walters <kemuri9 <at> gmail.com>
Subject: Re: Fix issues relating to input/output files being pipes/FIFOs
User-Agent: Mutt/1.5.20 (2009-06-14)

Hello,

On Sun, Nov 08, 2009 at 01:07:28AM +0000, Steven Walters wrote:
> Fix issues relating to input/output files being pipes/FIFOs

This patch broke two-pass encoding on Samba shares on 32-bit machines. The
problem here is that _FILE_OFFSET_BITS in osdep.h is set too late and doesn't
have any effect, hence 32-bit fstat is used and fails, because CIFS has really
big inode numbers.

>  <at>  <at>  -63,6 +63,7  <at>  <at>  do {\
>  /****************************************************************************
>   * Includes
>   ****************************************************************************/
> +#include <sys/stat.h>
>  #include "osdep.h"
>  #include <stdarg.h>
>  #include <stddef.h>

For example here, you include a system header _before_ _FILE_OFFSET_BITS are
set. This happens elsewhere in x264 as well, so I suggest that you just add
relevant -D options to CFLAGS. I can confirm that adding it to --extra-cflags
(Continue reading)

Arindam Biswas | 2 Jan 2010 08:14
Picon

Reference picture selection

Hi,
I am using x264 for live video stream encoding and then it is transmitted over rtp. In my server application I get feedback from my rtp client about which particular frame has been received by the decoder without any error. So for my next frame encoding I want to reference from that frame which has been received by decoder.
To do this I am dropping frame from my encoder's DPB.

I am trying this code for frame dropping in the reference list.

x264_frame_t ** frames = h->frames.reference
while(*frames)
{
      if( *frames->i_poc  != received_poc)
              x264_frame_push_unused(h, x264_frame_shift(frames));
      else
             frames++
}

I have inserted this code in x264_encoder_encode function just before
 if( x264_reference_update( h ) )
        return -1;
I is it the right code and right place? Do I need to do anything else for frame dropping?

I have checked h->frames.reference is a 16 size array, Does that mean x264 always keeps 16 frames in its DPB?

If I find that received_poc is 10 frames earlier ( aasume poc=n) than the current frame to be encoded and if it is available in my DPB then after encoding at my client's decoder reference buffer will that nth frame be still available for referencing?

Thanks
Arindam

_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Jason Garrett-Glaser | 2 Jan 2010 08:35
Picon

Re: Reference picture selection

On Sat, Jan 2, 2010 at 2:14 AM, Arindam Biswas <send2ari <at> gmail.com> wrote:
> Hi,
> I am using x264 for live video stream encoding and then it is transmitted
> over rtp. In my server application I get feedback from my rtp client about
> which particular frame has been received by the decoder without any error.
> So for my next frame encoding I want to reference from that frame which has
> been received by decoder.
> To do this I am dropping frame from my encoder's DPB.

You might find periodic intra refresh a far better option for
resilient streaming.  It'll be committed in a few days to weeks and
there's a test patch in this thread if you're interested:

http://forum.doom9.org/showthread.php?t=151733

Unlike feedback mechanisms (e.g. ignoring refs in the DPB, sending new
I-frames), it requires no extra latency.  When combined with
one-slice-per-packet, it's been reported to be resilient to packet
loss up to 15-25%.  Additionally, a new receiver can jump on the
stream at any point without the need for keyframes.  Furthermore, your
method has only two states for a frame: dropped and not dropped,
despite the fact that one usually loses only one packet, not the whole
frame, which may be rather inefficient, especially at high packet
losses.

But if you do want to implement what you're talking about, the best
way to do it is to modify the reference list reordering functions.
Dropping frames from the DPB is way too complicated and unnecessary.

> I have checked h->frames.reference is a 16 size array, Does that mean x264
> always keeps 16 frames in its DPB?

No, that's just the max size.

> If I find that received_poc is 10 frames earlier ( aasume poc=n) than the
> current frame to be encoded and if it is available in my DPB then after
> encoding at my client's decoder reference buffer will that nth frame be
> still available for referencing?

Only if your --ref is high enough.

Dark Shikari
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

Arindam Biswas | 2 Jan 2010 10:32
Picon

Re: Reference picture selection

Thank you for your response. I will defenitely try out periodic intra refresh.

I am streaming 480P and 720P video over wireless and using vlc media player at client end for playback. I have configured x264 keyint max 15, keyint min 5, and 8 slices per frame.
In the normal condition I am getting 5% packet loss and I am using rate adaptation and
retransmission to recover from that.
But in case of interference the loss is going as high as 50% and I am seeing stall, artifact in vlc media player and some times vlc player just gives up.
After checking wireshark packet capture I found consecutive 5 to 10 frame loss in case of interference. This is the reason why I was thinking about dynamic reference picture selection based on client's feedback. Will this technique help in this kind of scenario?

Can you suggest me if there is any other techniques, special kind of encoder profiling which can be quickly implemented on x264/ patch available  in order to reduce stalls, jerks, artifacts at vlc player end.

Thanks
Arindam
 

On Fri, Jan 1, 2010 at 11:35 PM, Jason Garrett-Glaser <darkshikari <at> gmail.com> wrote:
On Sat, Jan 2, 2010 at 2:14 AM, Arindam Biswas <send2ari <at> gmail.com> wrote:
> Hi,
> I am using x264 for live video stream encoding and then it is transmitted
> over rtp. In my server application I get feedback from my rtp client about
> which particular frame has been received by the decoder without any error.
> So for my next frame encoding I want to reference from that frame which has
> been received by decoder.
> To do this I am dropping frame from my encoder's DPB.

You might find periodic intra refresh a far better option for
resilient streaming.  It'll be committed in a few days to weeks and
there's a test patch in this thread if you're interested:

http://forum.doom9.org/showthread.php?t=151733

Unlike feedback mechanisms (e.g. ignoring refs in the DPB, sending new
I-frames), it requires no extra latency.  When combined with
one-slice-per-packet, it's been reported to be resilient to packet
loss up to 15-25%.  Additionally, a new receiver can jump on the
stream at any point without the need for keyframes.  Furthermore, your
method has only two states for a frame: dropped and not dropped,
despite the fact that one usually loses only one packet, not the whole
frame, which may be rather inefficient, especially at high packet
losses.

But if you do want to implement what you're talking about, the best
way to do it is to modify the reference list reordering functions.
Dropping frames from the DPB is way too complicated and unnecessary.

> I have checked h->frames.reference is a 16 size array, Does that mean x264
> always keeps 16 frames in its DPB?

No, that's just the max size.

> If I find that received_poc is 10 frames earlier ( aasume poc=n) than the
> current frame to be encoded and if it is available in my DPB then after
> encoding at my client's decoder reference buffer will that nth frame be
> still available for referencing?

Only if your --ref is high enough.

Dark Shikari
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Jason Garrett-Glaser | 2 Jan 2010 18:17
Picon

Re: Reference picture selection

On Sat, Jan 2, 2010 at 4:32 AM, Arindam Biswas <send2ari <at> gmail.com> wrote:
> Thank you for your response. I will defenitely try out periodic intra
> refresh.
>
> I am streaming 480P and 720P video over wireless and using vlc media player
> at client end for playback. I have configured x264 keyint max 15, keyint min
> 5, and 8 slices per frame.

Why not use a slice size rather than a static number of slices per frame?

Larger frames are more likely to have packet loss, so it makes sense
to try to localize the error.

Additionally, do note that libavcodec-based media players can only
decode frames up to MAX_SLICES in size, which is defined somewhere
around libavcodec.

> In the normal condition I am getting 5% packet loss and I am using rate
> adaptation and
> retransmission to recover from that.
> But in case of interference the loss is going as high as 50% and I am seeing
> stall, artifact in vlc media player and some times vlc player just gives up.
> After checking wireshark packet capture I found consecutive 5 to 10 frame
> loss in case of interference. This is the reason why I was thinking about
> dynamic reference picture selection based on client's feedback. Will this
> technique help in this kind of scenario?

Maybe, but I'd think it would be a better idea to try to recover from
the failure quickly rather than keeping around a dozen reference
frames and having to accept a full roundtrip latency time to modify
the encoder's behavior.

Dark Shikari
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

kumar gokhare | 3 Jan 2010 18:02
Picon

Motion Vectors Data

Hello,


I am a student from North Carolina State University and I am using the x264 project for my thesis research. I was going through code and needed some help in pointing out some information. Can you point to the place where the raw motion vectors are stored in the data structures which are fed to vlc. I want to pre-process the co-efficients(after quantization) just before they are fed to entropy coder. It would be great if you could mention specific fields, as I am little confused with the presence of several buffers and caches.

thanks,
Kumar
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel
Jason Garrett-Glaser | 3 Jan 2010 18:10
Picon

Re: Motion Vectors Data

On Sun, Jan 3, 2010 at 12:02 PM, kumar gokhare <kumar.gokhare <at> gmail.com> wrote:
> Hello,
> I am a student from North Carolina State University and I am using the x264
> project for my thesis research. I was going through code and needed some
> help in pointing out some information. Can you point to the place where the
> raw motion vectors are stored in the data structures which are fed to vlc. I
> want to pre-process the co-efficients(after quantization) just before they
> are fed to entropy coder. It would be great if you could mention specific
> fields, as I am little confused with the presence of several buffers and
> caches.
> thanks,
> Kumar

Motion vectors for the current MB are h->mb.cache.mv and DCT
coefficients for the current MB are h->mb.dct.

Motion vectors for the whole frame are in h->mb.mv and are stored
there after each MB is finished encoding.  This is also available as
x264_frame_t->mv.

If you have detailed questions, I suggest you ask on IRC (#x264dev, Freenode).

Dark Shikari
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

vmrsss | 3 Jan 2010 23:21
Picon

crash with x264 64bit on mac os x 10.5.8

Hello everybody. 

Running x264 64bit (compiled with llvm-gcc-4.2) on mac os x 10.5.8

> > x264 --version
> x264 0.80.1376+56 47740e0
> built on Jan  3 2010, gcc: 4.2.1 (Based on Apple Inc. build 5555) (LLVM build 2064.3)

with these parameters:

> x264 stream.y4m --threads auto --crf 22 --bframes 4 --b-adapt 2 --b-pyramid normal --direct auto
--weightb --ref 6 --mixed-refs --subme 9 --me umh --trellis 2 --sar 64:45 --level 31 --output file.264

I systematically get the crash reported below in cpu_capabilities.h (the same code compiled at 32bit on
the same architecture by the same compile runs that command just fine, albeit slow).

Does anybody know what's going on?

Thanks.

> Process:         x264 [73449]
> Path:            /usr/local/bin/x264
> Identifier:      x264
> Version:         ??? (???)
> Code Type:       X86-64 (Native)
> Parent Process:  bash [384]
> 
> Date/Time:       2010-01-03 21:32:34.499 +0000
> OS Version:      Mac OS X 10.5.8 (9L30)
> Report Version:  6
> Anonymous UUID:  20D11D39-3AAC-446A-9EB7-797D8F6C3BAA
> 
> Exception Type:  EXC_BAD_ACCESS (SIGBUS)
> Exception Codes: KERN_PROTECTION_FAILURE at 0x00000001006d9ffc
> Crashed Thread:  1
> 
> Thread 0:
> 0   libSystem.B.dylib                   0x00007fff81c1edc2 __semwait_signal + 10
> 
> Thread 1 Crashed:
> 0   libSystem.B.dylib                   0x00007fffffe00f3e __memcpy + 1950 (cpu_capabilities.h:246)
> 
> Thread 2:
> 0   libSystem.B.dylib                   0x00007fff81cfe596 read$NOCANCEL + 10
> 1   libSystem.B.dylib                   0x00007fff81c4c5cd _sread + 19
> 2   libSystem.B.dylib                   0x00007fff81c4c582 __srefill + 313
> 3   libSystem.B.dylib                   0x00007fff81c5225e fread + 164
> 4   x264                                0x00000001000044ee main + 12238
> 5   ???                                 0x000000454d415246 0 + 297648869958
> 6   libSystem.B.dylib                   0x00007fff81c45d4d thread_start + 13
> 
> Thread 1 crashed with X86 Thread State (64-bit):
>   rax: 0x0000000000001200  rbx: 0x0000000000000001  rcx: 0xfffffffffff82380  rdx: 0x0000000000000036
>   rdi: 0x0000000100758f30  rsi: 0x0000000100757c9c  rbp: 0x0000000100753f10  rsp: 0x0000000100753f10
>    r8: 0x00000001002126f0   r9: 0x0000000000000000  r10: 0x00000000000000fc  r11: 0x0000000100758efa
>   r12: 0x0000000000000003  r13: 0x0000000000000003  r14: 0x0000000100758efa  r15: 0xffffffffffffffff
>   rip: 0x00007fffffe00f3e  rfl: 0x0000000000010282  cr2: 0x00000001006d9ffc
> 
> Binary Images:
>        0x100000000 -        0x100102ff7 +x264 ??? (???) <4eafd6295f41d705091f565b974fe7c7> /usr/local/bin/x264
>     0x7fff5fc00000 -     0x7fff5fc2e643  dyld 97.1 (???) <1d1ba42c89e77cfe2558a3c66129fff6> /usr/lib/dyld
>     0x7fff81c17000 -     0x7fff81da2ffb  libSystem.B.dylib ??? (???) <714d2608b5acae3ad5364897c49868fa> /usr/lib/libSystem.B.dylib
>     0x7fff82971000 -     0x7fff8297dff1  libgcc_s.1.dylib ??? (???) <6fc905606335f261db4da9529c7e2711> /usr/lib/libgcc_s.1.dylib
>     0x7fff83cdf000 -     0x7fff83ce3fff  libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib
>     0x7fffffe00000 -     0x7fffffe01780  libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib
> 
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

David Conrad | 3 Jan 2010 23:33
Picon

Re: crash with x264 64bit on mac os x 10.5.8

On Jan 3, 2010, at 5:21 PM, vmrsss wrote:

> Hello everybody. 
> 
> Running x264 64bit (compiled with llvm-gcc-4.2) on mac os x 10.5.8
> 
>>> x264 --version
>> x264 0.80.1376+56 47740e0
>> built on Jan  3 2010, gcc: 4.2.1 (Based on Apple Inc. build 5555) (LLVM build 2064.3)
> 
> with these parameters:
> 
>> x264 stream.y4m --threads auto --crf 22 --bframes 4 --b-adapt 2 --b-pyramid normal --direct auto
--weightb --ref 6 --mixed-refs --subme 9 --me umh --trellis 2 --sar 64:45 --level 31 --output file.264
> 
> I systematically get the crash reported below in cpu_capabilities.h (the same code compiled at 32bit on
the same architecture by the same compile runs that command just fine, albeit slow).
> 
> Does anybody know what's going on?

Works here on 10.6.2 with llvm-gcc build 2206.
Try updating XCode and building origin/master; one of your 56 local patches might be the culprit.
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel

Philip Spencer | 5 Jan 2010 19:41
Picon
Picon
Favicon

Behaviour of Annex B encoding: bug or not?

First a disclaimer: I know very little about the H.264 spec, and am just 
trying to resolve an interoperability issue we are having, so please bear 
with me if I misstate or misunderstand something.

In the routine x264_nal_encode (in common/common.c), the flag b_annexb 
controls whether or not to add a NAL start code (00 00 00 01) to the 
beginning of the packet, but does not control whether or not to do the 
escaping of sequences of the form 00 00 00/1/2/3 by inserting a 03 byte 
into the third position -- that escaping is ALWAYS done, even if b_annexb 
is not set.

Is this a bug, or is it meant to be that way? (I don't have access to the 
text of Annex B).

It certainly breaks interoperability with several devices. In particular, 
x264 cannot be used with the Ekiga softphone application to communicate 
with the "LifeSize Room" brand of videoconferencing equipment: that device
expects non-Annex-B packets over RTP, and cannot handle the extra 03 byte 
that is inserted. The result is that the session parameters (like stream 
resolution and other such settings, which often contain multiple zero 
bytes in a row) get completely garbled because of the Annex-B bytestream 
encoding.

Also, if one attempts to sniff the network traffic with software such as 
WireShark, it too chokes on the unexpected 03 bytes in RTP packets.

It would seem to me that this is a bug: if Annex B bytestream encoding is 
not desired, such as for an RTP packet, then the extra escape bytes should 
not be inserted.

On our system, I have applied the patch below to common.c and then
H.264 connectivity to the LifeSize Room videoconferencing equipment works 
just fine.

On the other hand, from a quick glance at the source code of the reference 
encoder/decoder, it seems that it behaves the same way as x264: always 
inserts the escape byte. Is this a bug in the reference encoder/decoder 
too, or does the text of Annex B specify that ALL H.264 streams should 
have the extra bytes inserted, even when bytestream encoding is not being 
used?

In the latter case, then obviously the LifeSize brand videoconference 
units are buggy, but since I know they interperate will over H.264 with a 
wide range of units from other manufacturers there must be a lot of buggy 
devices out there -- would it be worth adding an extra flag to x264 that 
says "do bytestream encoding only in Annex B mode, for compatibility with
devices that cannot handle it in RTP mode"?

Here is the patch we are using to make x264 work with our LifeSize Room 
videoconference units:

--- common/common.c.orig    2009-10-20 19:06:53.000000000 -0400
+++ common/common.c 2009-10-20 19:06:44.000000000 -0400
 <at>  <at>  -730,7 +730,7  <at>  <at> 
              *dst++ = 0x03;
              i_count = 0;
          }
-        if( *src == 0 )
+        if( *src == 0  && b_annexb )
              i_count++;
          else
              i_count = 0;

Thanks,

Philip Spencer

--------------------------------------------+-------------------------------
Philip Spencer  pspencer <at> fields.utoronto.ca | Director of Computing Services
Room 336        (416)-348-9710  ext3036     | The Fields Institute for
222 College St, Toronto ON M5T 3J1 Canada   | Research in Mathematical Sciences
_______________________________________________
x264-devel mailing list
x264-devel <at> videolan.org
http://mailman.videolan.org/listinfo/x264-devel


Gmane