Invalid EXT-X-TARGETDURATION for first fragment in HLS stream

[shwetanks]

I am observing an invalid target-duration for first fragment when publishing to a nginx-rtmp server using SrsPublisher#startPublish Following is a .m3u8 file generated in the process and some logs from nginx-rtmp module are also attached (please notice the large value 204963823041217)

EXTM3U

EXT-X-VERSION:3

EXT-X-MEDIA-SEQUENCE:0

EXT-X-TARGETDURATION:204963823041217

EXTINF:204963823041217.156,

894888126341857280-0.ts

EXTINF:2.151,

894888126341857280-1.ts

EXTINF:2.109,

894888126341857280-2.ts

EXTINF:2.150,

894888126341857280-3.ts

EXTINF:2.141,

894888126341857280-4.ts

EXTINF:2.154,

...

attached - detailed debug of nginx-rtmp from publish start to first fragment write

invalid_first_frame_duration.txt

what could it be?

Thank You!

[begeekmyfriend]

Yasea does nothing with HLS or any fragment. The stream is only published under RTMP. It is nginx-rtmp that translates the packaging protocol. I am afraid it is a bug of nginx-rtmp module.

[shwetanks]

Thanks! apparently the timestamp of first fragment is incorrect to be causing this. i'll close this here and figure it on nginx-rtmp module source.

[begeekmyfriend]

You can dump all time stamp in RTMP module to check whether they are correct or not.

[shubham0390]

This happens when there is a lag between audio and video frames while

I/SrsFlvMuxer: worker: send frame type=9, dts=302, size=131072B /RtmpConnection: wrote packet: RTMP Video, size: 19993 /RtmpConnection: wrote packet: RTMP Video, size: 3525 D/RtmpConnection: wrote packet: RTMP Video, size: 2473 D/RtmpConnection: wrote packet: RTMP Audio, size: 11 D/RtmpConnection: wrote packet: RTMP Audio, size: 192 D/RtmpConnection: wrote packet: RTMP Audio, size: 192

in above logs, you can see we have a noticeable lag between audio and video frame.what are the possible reason for it and how can we solve this?

following are the devices where we are able to reproduce this issue every time LENOVO VIBE K5 Motorola Moto Z Play(32 bit) Xiaomi Redmi Note 4 (64 bit) Samsung On7 Pro (32 bit) Motorola Moto E3 Power (32 Bit) Oppo A37F (64 bit) LG Nexus 5 ( 32 bit)

@begeekmyfriend

[shwetanks]

Hi Leo..we did some research on this on several devices and narrowed it down to 32 bit devices on which we can consistently recreate the issue. there also are some 64 bit devices e.g. Oppo (64bit) and Lenovo (64bit). we're looking for some instructions on where exactly it might be going wrong. is it just the way devices handle buffer before writing to network? or does it remain a known issue.

i agree it might not be particularly related to the library and the protocol handler must handle out-of-sync AV streams before stitching them together for delivery. i am looking for some pointers we can work with. thanks again for help!

known devices causing this:

LENOVO VIBE K5 Motorola Moto Z Play(32 bit) Xiaomi Redmi Note 4 Samsung On7 Pro (32 bit) Motorola Moto E3 Power (32 Bit) Oppo A37F LG Nexus 5 ( 32 bit)

[begeekmyfriend]

Did you sync the latest version or have you tried some other RTMP server like SRS 2.0 release?

[shwetanks]

thanks Leo, will update you shortly..we're on it (using expanded PCM buffer) nginx-rtmp is pretty much integrated with our wide delivery network but we're looking into other options as well to plug this gap on servers

[shwetanks]

11-21 16:46:54.785 4160-4866/com.myapp E/AndroidRuntime: FATAL EXCEPTION: Thread-1442 Process: com.myapp, PID: 4160 java.nio.BufferOverflowException at java.nio.Buffer.checkPutBounds(Buffer.java:183) at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:356) at net.ossrs.yasea.SrsEncoder.onGetPcmFrame(SrsEncoder.java:354) at net.ossrs.yasea.SrsPublisher$2.run(SrsPublisher.java:118) at java.lang.Thread.run(Thread.java:818) 11-21 16:46:54.804 756-4764/? E/mm-camera: 1965: isp_util_update_hw_param: saved zoom level:0

-- sorry this didn't work out. we'll keep trying. thanks for help!

[begeekmyfriend]

It seems that the PCM buffer size has to be 4096 for microphone reading. I suggest SRS 2.0 release for testing.

[begeekmyfriend]

FYI #554

[smolyakoff]

@shwetanks, did you manage to find any solution for this issue?

[leeapted]

I'm also very interested in any solutions.