RTMP resume

Re: RTMP resume

tong2shot — Sat, 14 Feb 2015 10:32:42 +0000

The bug is in v2.3.3. v2.3.4 fixed the bug.

Re: RTMP resume

rancor — Sat, 14 Feb 2015 10:17:40 +0000

tong2shot Wrote:
-------------------------------------------------------
> @rancor: Are you using rtmp plugin v2.3.4?

No, I returned to the previous version.

Re: RTMP resume

tong2shot — Sat, 14 Feb 2015 08:47:29 +0000

@rancor: Are you using rtmp plugin v2.3.4?

Re: RTMP resume

rancor — Sat, 14 Feb 2015 08:26:41 +0000

Confirm errors with sound after instalation new rtmp plugin. FLV files after remux in FLV Extract to mkv - no sound.

Re: RTMP resume

tong2shot — Sat, 14 Feb 2015 07:38:32 +0000

Yes, sorry again about that. I misremember why and when I changed the timestamp condition from < to <=. Previously I tried to implement RTMP resume by tracking pos and timestamp online, but unfortunately there are conditions that would produce corrupted flv files, when they're resumed. And probably during that experiment when I tried to resume, the server sent endless packets, that were marked as identical packet, then I changed the timestamp condition, and it worked.

I didn't change the timestamp condition, and tried another method (current method). When I tested using SMPlayer and VLC, the files are played just fine. But I didn't realize that there are audio gaps in VLC.

For your question #1: FRD plugin repo only offers the latest version of plugins. As workaround, I don't know, maybe you can setup version control system (Git, or something like that), then create batch script to commit the changes on plugin directory before starting FRD. I haven't tried that.

Re: RTMP resume

TVjunkie — Sat, 14 Feb 2015 06:56:43 +0000

tong2shot Wrote:
-------------------------------------------------------
> RTMP plugin has just been released.

Thank you for fixing the calamitous rtmp plugin v2.3.3 (tu):)-D
I was about to go mad, as all of my yesterday's BBC downloads
(in FLV format) were somehow corrupt:
1. My main player MPC-BE wouldn't play the audio track at all,
or would crash!
2. VLC would also crash on attempting to seek the file:

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	vlc.exe
  Application Version:	2.1.5.0
  Application Timestamp:	00000004
  Fault Module Name:	libavcodec_plugin.dll
  Fault Module Version:	0.0.0.0
  Fault Module Timestamp:	00000000
  Exception Code:	40000015
  Exception Offset:	007bfdb4
  OS Version:	6.0.6002.2.2.0.768.3
  Locale ID:	1032
  Additional Information 1:	a9f5
  Additional Information 2:	c61298b4369c0da3ef0315b96f1a59cc
  Additional Information 3:	02a0
  Additional Information 4:	8948c2d45745adae569f60536b4aee51

I could somehow watch the files on laptop with MPC-HC (latest stable 1.7.8)
but I have a hardware player connected to TV which does not support the FLV container,
only the MP4 container (and in a peculiar way only if MP4Box is used to remux).
I use a batch file for the remux
(it employs FLVExtractCL+MP4Box, if anyone's interested here it is:

@echo off

echo *** Extract (demux) media streams from FLV ***
FOR %%F in (*.flv) DO FLVExtractCL -v -a "%%F"

echo *** Mux raw streams to MP4 container ***

REN "*.264" "Video.264"
REN "*.aac" "Audio.aac"

MP4Box -brand mp42 -delay 1=1 -add "Video.264:name=AVC Video Stream:lang=eng:fps=25.000" -add "Audio.aac:name=AAC LC Audio Stream:lang=eng:mpeg4" -itags tool="MP4Box-0.4.6-dev-ir5-x86-shared.Kurtnoise.12-Jun-2010" "Remuxed.mp4"

FOR %%N in (*.flv) DO REN "Remuxed.mp4" "%%~nN.mp4"

echo MP4 FILE CREATED SUCCESSFULLY...
echo.
echo WARNING: WILL THEN DELETE RAW STREAMS!
echo [If you don't want this, close (X) the Command Prompt Window]

PAUSE

DEL "Video.264"
DEL "Audio.aac"

echo WARNING: WILL THEN DELETE ORIGINAL FILE!
echo [If you don't want this, close (X) the Command Prompt Window]

PAUSE

DEL "*.flv"

echo REMUX TO MP4 CONTAINER COMPLETED SUCCESSFULLY :-)

PAUSE

:END

)
but when remuxing those files for TV viewing, MP4Box would import
a raw audio stream with wrong bitrate & 0 channels (!):

*** Extract (demux) media streams from FLV ***
FLV Extract CL v1.6.3
Copyright 2006-2012 J.D. Purcell
[www.moitah.net]

True Frame Rate: 25 (25/1)
Average Frame Rate: 25 (25/1)

Finished.
*** Mux raw streams to MP4 container ***
AVC-H264 import - frame size 832 x 468 at 25.000 FPS
Import results: 16715 samples - Slices: 147 I 5575 P 10993 B - 16848 SEI - 133 I
DR
AAC import  - sample rate 30464 - MPEG-4 audio - 0 channel
Saving to Remuxed.mp4: 0.500 secs Interleaving
MP4 FILE CREATED SUCCESSFULLY...

The resulting MP4 file would have BAD metadata (wrong duration - among others...)
and WOULD CRASH every media player on my system (win32)!
I was about to post about it in grave frustration, when your update just came in!
MANY THANKS!
The pity is I have to re-download 3GB:-( worth of stuff

I take this opportunity to raise a related issue:
1) when something goes wrong in an updated plugin,
the FRD user does not have a way to revert back to a previous
working version of the plugin, unless - which is what I do for
plugins of my main interest - back up prior to updating.
Is there a public plugin repo one can access to grab a previous version?
2) Some "functional/internal" plugins, like rtmp, applehls, adobehds, tor, geoip etc.,
DO NOT SHOW UP in FRD's plugin list;
the user can't easily say on which version of those he/she is,
and cannot control the update of those plugins.
I had my rtmp230.frp backup for today's downloads,
but I couldn't disable its update function;
I had to untick rtmp 2.3.3 every time FRD picked it up
(among other updated plugins...)
Would you consider this issue, possibly in the next
major release of FRD?

Again, many thanks to you (and to maxedi,
who reported it first)!:-)

Re: RTMP resume

tong2shot — Thu, 12 Feb 2015 22:26:29 +0000

ntoskrnl Wrote:
-------------------------------------------------------
> As for the timestamp < or <= issue, I think JPEXS
> had problems with a certain site when using <. I
> can't remember the details as it was years ago. I
> guess we can change the behavior later if any
> problems arise.

timestamp < is completely broken when I tested it, no packet can be processed further, it somehow trapped in endless process. I agree, we'll find solution if any problems arise.

RTMP plugin has just been released.

Re: RTMP resume

ntoskrnl — Thu, 12 Feb 2015 15:41:19 +0000

tong2shot Wrote:
-------------------------------------------------------
> getKeyFrameInfo() takes what FlvStreamWriter
> produced as input (flv file), and FlvStreamWriter
> takes decoded RTMP packet as input. So I don't
> think it needs to be decoded again.

You are right, I must have confused RTMP packet headers and FLV packet headers. Nevermind that paragraph. :-)

As for the timestamp < or <= issue, I think JPEXS had problems with a certain site when using <. I can't remember the details as it was years ago. I guess we can change the behavior later if any problems arise.

Re: RTMP resume

tong2shot — Wed, 11 Feb 2015 21:56:12 +0000

ntoskrnl Wrote:
-------------------------------------------------------
> Looks pretty good. The only problem is that
> multiple packets with the same timestamp are
> valid. I'm not sure how we should handle this;
> maybe we should check what the last timestamp the
> file contains is and then truncate it to remove
> all packets with that timestamp?

It's the same behaviour as previous version. As long as video player can play the file, I think it's not a problem. I tested the resulted flv files with 3 different video players : VLC (which uses its own backend), SMPlayer (which uses MPlayer as backend), and Dragon Player (which uses Phonon, which in my system uses GStreamer as backend). And all 3 players played the flv files just fine.

I haven't look at FLV specs in details, maybe it says something about this issue?

> getKeyFrameInfo() duplicates some of the code in
> Header.decode(), and you will also see why
> tempTimestamp == 0 is valid. :-) Tiny packets
> automatically use the previous timestamp. There
> are also extended timestamps. Maybe it's possible
> to somehow reuse the code in Header.decode().

getKeyFrameInfo() takes what FlvStreamWriter produced as input (flv file), and FlvStreamWriter takes decoded RTMP packet as input. So I don't think it needs to be decoded again.

getKeyFrameInfo() is basically simplified version of OpenResumeFile() and GetLastKeyframe() combined from rtmpdump.c of rtmpdump project.

And we already implemented the exact same thing several times : video2audio (audio conversion/extraction), mp4parser (audio extraction from flv file), etc.

Re: ivysilani Ceska Televize

tong2shot — Sat, 31 Jan 2015 23:21:30 +0000

I'll look into it further in few days. I don't have much spare time to spend to look into code and do some tests, in between.

Thanks for the hints. :-)

Re: ivysilani Ceska Televize

ntoskrnl — Sat, 31 Jan 2015 20:24:05 +0000

Looks pretty good. The only problem is that multiple packets with the same timestamp are valid. I'm not sure how we should handle this; maybe we should check what the last timestamp the file contains is and then truncate it to remove all packets with that timestamp?

getKeyFrameInfo() duplicates some of the code in Header.decode(), and you will also see why tempTimestamp == 0 is valid. :-) Tiny packets automatically use the previous timestamp. There are also extended timestamps. Maybe it's possible to somehow reuse the code in Header.decode().

Re: ivysilani Ceska Televize

ad48 — Sat, 31 Jan 2015 16:23:24 +0000

I had problems with rtmp,there was freeze video sometimes.

RTMP resume

tong2shot — Sat, 31 Jan 2015 10:42:21 +0000

ntoskrnl Wrote:
-------------------------------------------------------
> RTMP resume is possible; rtmpdump supports it. I
> think I've tried to implement it even; not sure
> why I didn't finish it.

I think I've just gotten RTMP resume working. I've just committed the code. I haven't released it, in case you want to make some changes.

It needs some more tests. I only tested it with few samples, because such tests are painful with my slow connection.

Edit: split from "ivysilani Ceska Televize"