Customized rtmpdump binaries with patch file

[KSV]

Originally Posted by RedPenguin

Damn KSV are you good! I made this single change only and it worked immediately! Also just to double verify, I deleted the dir and reused git, made same change, and works again.

Though as far as you know, this should not break anything else in the patch?

so my initial guess was correct. old version doesn't sends back any BWcheck response. my version is sending this but default response function in official rtmpdump doesn't seems correct. i have added a similar function to rtmpsrv long ago. i will copy that one instead. try with following patch on fresh repo.

http://pastebin.com/nsrK1uXH

[RedPenguin]

Originally Posted by KSV

so my initial guess was correct. old version doesn't sends back any BWcheck response. my version is sending this but default response function in official rtmpdump doesn't seems correct. i have added a similar function to rtmpsrv long ago. i will copy that one instead. try with following patch on fresh repo.

http://pastebin.com/nsrK1uXH

That patch breaks it again, but as a note, not sure if this was intended or not but when applying the patch:

"patch unexpectedly ends in middle of line"

but seemed to apply otherwise.

[KSV]

Originally Posted by RedPenguin

That patch breaks it again, but as a note, not sure if this was intended or not but when applying the patch:

"patch unexpectedly ends in middle of line"

but seemed to apply otherwise.

try with following and also post the debug log of this one.

http://pastebin.com/Bgznqcrc

[RedPenguin]

Originally Posted by KSV

try with following and also post the debug log of this one.

http://pastebin.com/Bgznqcrc

This patch seems to work every time.

I tried getting a debug log but for some reason my method using rtmpexplorer to stop rtmpsrv real quick and run rtmpdump manually fails as it runs rtmpdump too fast thus invalidating said token.

Is there some way to code rtmpsrv to always do -z or something to rtmpdump?

I know rtmpsrv sometimes has a -i option but I can't seem to get RTMPExplorer(X) nor RTMPDumpHelper to pass said option to rtmpsrv though it appears your patch must not have -i anyway.

Every now and then it will not start recording, but I noticed that before on the your 2011-07-11 version. It's like sometimes you had to restart the stream about 3 times before it starts recording, but most times it works on first try.

[KSV]

Originally Posted by RedPenguin

I know rtmpsrv sometimes has a -i option but I can't seem to get RTMPExplorer(X) nor RTMPDumpHelper to pass said option to rtmpsrv though it appears your patch must not have -i anyway.

rtmpsrv doesn't have any i switch.

try the following one. it automatically adds -z switch to rtmpdump command. if stream doesn't work with this one i will remove the BWrespose. it's not worth spending any more time. it doesn't affect downloading anyway.

http://pastebin.com/7va19cpt

rtmpsrv 2>Debug.txt

http://pastebin.com/7va19cpt

[RedPenguin]

Originally Posted by KSV

rtmpsrv doesn't have any i switch.
l[/url]

Well I meant the one svnpenn worked on a little while back:
http://lists.mplayerhq.hu/pipermail/...ber/002183.htm

Originally Posted by KSV

try the following one. it automatically adds -z switch to rtmpdump command. if stream doesn't work with this one i will remove the BWrespose. it's not worth spending any more time. it doesn't affect downloading anyway.

http://pastebin.com/7va19cpt

rtmpsrv 2>Debug.txt

http://pastebin.com/7va19cpt

Played the stream 3 times and each time it worked, seems flawless now .

[flocked]

Could anyone please compile it for mac? thanks!!

[RedPenguin]

Originally Posted by flocked

Could anyone please compile it for mac? thanks!!

Actually very funny you would ask, being I am basically working on it at this very moment.

Some folks over at XBMC seem to want librtmp for Apple TV 1 which is simply MacOS anyway.

I am currently working on getting a cross-compiler going for MacOS and will just make the exectuables and librtmp for anybody who wants them.

[alexanderd]

Originally Posted by KSV

1. add timestamp to detected filename (rtmpsrv and rtmpsuck) to avoid overwriting the streams

Thank you so much for that, KSV!

After some testing.
Unfortunately,latest release still overwrites live stream
Every time it's saved with the same filename.
I use RTMPDumpHelper+RTMPSuck

WARNING: Trying different position for client digest!
Processing connect
       app : live?ovpfv=2.1.4
  flashVer : WIN 11,6,602,180
    swfUrl : http://www.c-span.org/cspanVideoHD.swf?src=cspan1
     tcUrl : rtmp://cp82346.live.edgefcs.net:1935/live?ovpfv=2.1.4
   pageUrl : http://www.c-span.org/Live-Video/C-SPAN/
      live : yes
  Playpath : CSPAN1@14845
 Saving as : CSPAN1@14845.flv
INFO: Metadata:
INFO:   presetname              Custom
INFO:   creationdate            Sun Mar 10 09:55:08 2013
INFO:   videodevice             Osprey-230 Video Device 1
INFO:   framerate               30.00
INFO:   width                   320.00
INFO:   height                  240.00
INFO:   videocodecid            VP62
INFO:   videodatarate           300.00
INFO:   videokeyframe_frequency 5.00
INFO:   audiodevice             Osprey-230 Audio Device 1
INFO:   audiosamplerate         22050.00
INFO:   audiochannels           2.00
INFO:   audioinputvolume        75.00
INFO:   audiocodecid            .mp3
INFO:   audiodatarate           40.00
WARNING: ignoring too small audio packet: size: 0
ERROR: Request timeout/select failed, ignoring request
Closing connection... done!

WARNING: ignoring too small audio packet: size: 0
ERROR: RTMP_ReadPacket, failed to read RTMP packet header
Closing connection... done!

WARNING: Trying different position for client digest!
Processing connect
       app : live?ovpfv=2.1.4
  flashVer : WIN 11,6,602,180
    swfUrl : http://www.c-span.org/cspanVideoHD.swf?src=cspan1
     tcUrl : rtmp://cp82346.live.edgefcs.net:1935/live?ovpfv=2.1.4
   pageUrl : http://www.c-span.org/Live-Video/C-SPAN/
      live : yes
  Playpath : CSPAN1@14845
 Saving as : CSPAN1@14845.flv
INFO: Metadata:
INFO:   presetname              Custom
INFO:   creationdate            Sun Mar 10 09:55:08 2013
INFO:   videodevice             Osprey-230 Video Device 1
INFO:   framerate               30.00
INFO:   width                   320.00
INFO:   height                  240.00
INFO:   videocodecid            VP62
INFO:   videodatarate           300.00
INFO:   videokeyframe_frequency 5.00
INFO:   audiodevice             Osprey-230 Audio Device 1
INFO:   audiosamplerate         22050.00
INFO:   audiochannels           2.00
INFO:   audioinputvolume        75.00
INFO:   audiocodecid            .mp3
INFO:   audiodatarate           40.00
WARNING: ignoring too small audio packet: size: 0
WARNING: ignoring too small audio packet: size: 0
WARNING: Trying different position for client digest!
Processing connect
       app : samaalive
  flashVer : WIN 11,6,602,180
    swfUrl : http://beta.cdn.livestation.com/play...ion-player.swf
     tcUrl : rtmp://38.96.148.99:1935/samaalive
   pageUrl : http://www.livestation.com/
      live : yes
  Playpath : samaalive
 Saving as : samaalive.flv
INFO: Metadata:
INFO:   width                   480.00
INFO:   height                  270.00
INFO:   framerate               25.00
INFO:   videodatarate           200.00
INFO:   videocodecid            avc1
INFO:   audiodatarate           40.00
INFO:   audiocodecid            mp4a
WARNING: ignoring too small audio packet: size: 0
      live : yes
  Playpath : samaalive
 Saving as : samaalive.flv
INFO: Metadata:
INFO:   width                   480.00
INFO:   height                  270.00
INFO:   framerate               25.00
INFO:   videodatarate           200.00
INFO:   videocodecid            avc1
INFO:   audiodatarate           40.00
INFO:   audiocodecid            mp4a
WARNING: ignoring too small audio packet: size: 0
ERROR: Request timeout/select failed, ignoring request
Closing connection... done!

[KSV]

i have fixed another rtmpdump bug in which flv header was set with wrong data type (audio/video marker) which is yet another regression due to those array types. though file may play normally in most players rtmpdump was looking for the wrong type of keyframes while resuming.

another enhancement included is that upon resuming it was looking for keyframes with timestamp 0 only but now it searches other non zero timestamps too (timestamps are adjusted accordingly for this resume drift). so it's able to resume in those cases also where our required keyframe has nonzero timestamp.

Test case for both bugs:

rtmpdump -r "rtmpt://h2a.rtp.pt/vodrtp" -y "nas2.share/videos/auto/planetamusica/planetamusica_1_20120317" -o planetamusica_1_201203171.flv

@RedPenguin
your problem seems more like server configuration issue because the same response is accepted by other servers without any problem. anyway i have disabled it in my patches for compatibility reasons.

@alexanderd
it seems like you are using old binaries not the updated ones posted in first post.